Re: Applications Messaging Standard

From: John Taylor <jontayler-at-gmail.com>
Date: Thu, 8 Feb 2007 18:44:40 +0000

On 8 Feb 2007, at 18:18, Doug Tody wrote:

> On Thu, 8 Feb 2007, John Taylor wrote:
>
>> On 8 Feb 2007, at 17:42, Doug Tody wrote:
>>> 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?
>
> Exactly, yes.
>
>

K'ching. The penny has dropped. Right - well, I'm all for that then. We still need to discuss wire protocols, but yes, we can do this bit separately.

On the subject of wire protocols: I get the feeling that one of the main objections to PLASTIC is due to its support of JavaRMI as well as xml-rpc. This makes it very difficult to implement a Hub in anything other than Java (although makes no restrictions on the language of the client app). In that case we should make it optional. In fact, I'm in favour of allowing a (small) number of wire optional protocols subject to the following conditions: 1) messages should be "freely" convertible between the protocols (which I guess is another way of saying that the messaging protocol is independent of the wire protocol)
2) it should be possible to build a "Hub"(sorry Mike) that supports all the protocols.

Rule 2) is to ensure that our application-space doesn't get fragmented into mutually inaccessible parts. So, people are free to innovate with new wire protocols, and then if they come to the Apps WG and can persuade everyone there's a good reason to add a new wire protocol it can become part of the standard. That's not a green light to add any old wire protocol to the standard (SOAP anyone?). The standards body's role is to accept or deny requests for new wire protocols, and define how the conversion is done.

My view is that we should "let the market prevail". In 6 months time we can see which wire protocols are popular, which "hub" implementations are being used. We might decide that we need then to make one of more wire protocols mandatory.

Right. That was probably controversial. I'm going to Prague for the weekend before the replies from Alasdair and Mark hit.

Bye for now.

John Received on 2007-02-08Z19:45:06