Applications Messaging Standard

[John Taylor]

On 8 Feb 2007, at 17:42, Doug Tody wrote:

> On Thu, 8 Feb 2007, Alasdair Allan wrote:
>
>> Doug Tody wrote:
>>>    o	Separate protocol from implementation.  That is, we should be
>>>    	able to implement a message bus/hub in different languages such
>>> 	as Java or C, or layer the protocol on top of an existing robust
>>> 	messaging infrastructure such as D-Bus, MPI, PVM, ActiveMQ,
>>> 	Ice, CORBA, etc.  It is fine to have a simple hub (or two)
>>> 	developed as part of the standard, which doesn't queue messages,
>>> 	guarantee delivery, and so forth.
>>
>> Yes, but. Surely the entirely point is that one application that  
>> supports this messaging protocol can talk (possibly via some sort  
>> of messaging hub, although we shouldn't entirely rule out peer-to- 
>> peer at this stage), if we're required to support all of these  
>> that isn't possible. What's the point of having a standard that  
>> doesn't let one application that supports it talk to another  
>> application that supports it?
>
> The point is not to "support" all the mentioned messaging  
> technologies,
> but rather to define a simple messaging protocol which is sufficiently
> independent of implementation to be possible to implement on top of
> any sufficiently general messaging infrastructure.


So if I understand this correctly, you want to abstract out the  
operations and semantics that are needed.  For instance (to take  
PLASTIC is an example), we have the operations

register
request
requestAsynch
getRegisteredIds
.....


and these operations are independent of whatever wire protocol sits  
underneath?