On Tue, 10 Apr 2007 11:45:05 -0600 (MDT)
Doug Tody <dtody-at-nrao.edu> wrote:
> On Tue, 10 Apr 2007, Mark Taylor wrote:
>
> > To respond to Doug's comment about wanting various alternative
> > argument transport formats, this could be only one (the default?)
> > of several possible argument transport formats. For instance
> > instead of passing individual arguments in this way you could have
> > a single _argblock attribute which passes a packed data structure
> > containing the information.
>
> I just want to amplify this point. It appears that everyone agrees
> that it is a good thing to separate the messaging mechanism from
> the message content; the messaging infrastructure shouldn't know or
> care what is in the message, it just delivers it. We can go one step
> further and specify that the infrastructure just delivers the message
> payload as an opaque blob of some sort, and it is up to another layer
> of software to compose or interpret the message.
To take this a step further, if you use, e.g., Java interfaces, you can specify what the underlying messaging infrastructure should be capable of, and leave it up to the programmer to implement the details. This way you can specify that the underlying protocol should have the ability to, e.g., use transactions, guarantee delivery, yada, etc. In essence, the interface is the contract-wrapper around the underlying protocol.
That way, the next-gen (or whatever it will be--still PLASTIC?) hub can be coded against the interface, and rely upon "injection" of the messaging implementation. The hub doesn't have to change with different protocols. Only the implementation of the interface has to change in order to adapt the messaging implementation. This depends on who is deploying the hub.
>
> Hence in this view what we have are the basic messaging model,
> specifying the message attributes and available delivery semantics,
> one or more message content models, specifying the message payload,
> and one or more messaging protocols, specifying how a client
> application interacts with the messaging infrastructure.
>
So, I think my response was a restatement Doug's last sentence above.
Phil Received on 2007-04-10Z20:11:51