RE: [business-transaction] SOAP Bindings Stuff

["WEBBER,JIM (HP-UnitedKingdom,ex1)" <jim_webber@hp.com>]

Alastair:

I know, given the current climate of wanting to get the spec finished ASAP,
that these comments won't be all that welcome, but I've been thinking about
the interfaces to a BTP service again, in the context of "rich" RPC versus
the "doWork" style.

I think we might have been slightly narrow in our view of the problem as far
as thinking about hiding all of the detail behind some standard API goes.
Almost certainly we will be able to wrap all of the client-application side
complexity behind some standard API on the Java side of things (e.g. via
whatever comes from the JAXTX effort).

However, I think we have not done our best to think outside of the Java
platform because I suspect we are all predominantaly Java advocates. In say
.Net world, the chances are that we won't have a standard API for
interacting with BTP services (i.e. transaction managers) and so people will
be forced to cobble their own proxies together from the descriptions offered
by those services. Now, of those services offer only a "doWork" method, it
is a difficult task to craft one's own proxy, whereas if the BTP service
offers a richer description and set of SOAP endpoints then the process of
talking to that service is significantly simplified.

As far as the whiteboard session/messaging SC meeting goes, I think it would
be a good idea. As far as the SOAP bindings go, perhaps we should think
about having two sets of bindings, one for SOAP Messages, and one for SOAP
RPC. Then vendors would have the choice of which of those bindings they want
to implement.

Jim
--
Dr. James Webber
Hewlett-Packard Arjuna Lab
http://www.arjuna.com