Applications Messaging Standard

[John Taylor]

On 8 Feb 2007, at 18:08, Mike Fitzpatrick wrote:

> On Thu, 8 Feb 2007, John Taylor wrote:
>
>>
>> On 8 Feb 2007, at 17:19, Doug Tody wrote:
>>
>>> On Thu, 8 Feb 2007, John Taylor wrote:
>>>
>>>> On 8 Feb 2007, at 15:12, 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.
>>>>
>>>> I agree that this is desirable.  There might be a trade off here
>>>> between the wire protocols we can offer in a Hub, and the
>>>> languages it is possible to use to write one.  We probably don't
>>>> need to worry about as many languages as we do for client
>>>> applications messaging though.
>>>
>>> At least for the simpler wire protocols, it should be possible to
>>> implement
>>> the infrastructure with almost any language or technology.
>>
>> Possible, but not necessarily practical.  I'd be happy to live with
>> not being able to write a "Hub" in IDL if that was the sacrifice
>> necessary to include easy-to-use protocols in the hub.  My point is
>> that the set of languages in which we need to write a Hub is
>> different, and probably smaller than, the set of languages we need to
>> support for clients.  It might be useful to know what these languages
>> are so that we can decide what wire protocols are of interest.  It's
>> even possible we could make some or all of the wire protocols
>> optional, but as Mark pointed out, that needs some careful thought.
>
>
> 	Be careful about how you distinguish the messages from the
> transport protocols.  The concept of the 'Hub' comes from the current
> PLASTIC implementation, but it is fair to consider whether a Hub is
> needed at all.

Apologies for the sloppy language - I quoted the word Hub because I  
was too lazy to think up an alternative for "bit of software that  
facilitates messaging".  I'm assuming here that some other software  
will be needed, which might not be the case.

> There are a number of ways to deliver the message that
> don't require a central Hub knowing which applications are available.
> Note one of the use cases we should address is one where multiple  
> users
> are running on the same machine, i.e. do they share a 'Hub' or  
> instantiate
> their own (if so how do they address it).  The problem is the same  
> if we
> ignore a Hub and use a pub-sub or broadcasting method of some kind,  
> how
> are the messages from one user not confused with those from the other?
>
> 	To keep things simple I agree we should be looking at
> single-machine, inter-tool messaging

I think if we are to make any progress then we must have this as our  
first goal.

> -- but department servers still 
> exist in the real world.  By separating the message from the  
> transport,
> a Hub could be written that understands existing PLASTIC and any other
> transport and bridge the two.

Indeed - and Alasdair tells me he has already prototyped such a system.

> Likewise we can avoid worrying about a
> more general LAN/WAN messaging scheme by assuming some clever person
> will write an 'app' that acts as a router between desktops in a much
> bigger system.  Doug's comment about an 'adapter' fall into this same
> catagory of what I shall now declare to be called "support apps".
>
> -Mike
>
>