RE: [business-transaction] SOAP Bindings Stuff

[Mark Potts <mark.potts@talkingblocks.com>]

Jim

I don't entirely agree with this and we need to be very careful here from an
interoperability perspective  - if you look at the ebXML and RossetttaNet
standards even though SOAP literal and RPC style were available they have
maintained the document style for good reason...

Besides the business process protocol standards the document style is also
very much a Microsoft position  -and one I think the rest will follow or
have already adopted. SOAP’so greatest value is for interoperability, and
section 5 tends to make out that SOAP encoding allows for tighter type
definition, which is not true ( you can define types in the XSD for the SOAP
literal, and even more validation rules). I think that everyone will come
round to XML messaging and use literal-style SOAP. Ina previous meeting
James Tauber, Mark Hale and myself had this very discussion and concluded
document style was the way to go. RPC mechanism makes little sense to me as
the objects themselves that are passed are only a container for the public
state of an object (no behaviour), so why not simply make it a document that
can be defined through schema and validated.

Adding Microsoft to the supporting cast here is a little false and reflects
Microsoft's forward looking strategy in my opinion, but the reality is they
are in line with everyone else bad that makes for good interop. Looking at
Section 5, it was meant to standardise the RPC encoding mechanism such that
a Microsoft Client or Server could communicate with a Java Server or Client
, both making RPC call locally and Proxy's and Listeners marshalling the XML
to and from local object structures. The reason Microsoft have jumped on the
document style however can be seen from statements they have made recently:
"if you just need to call methods on remote objects over the Web, consider
using your platform’s RPC mechanism instead of SOAP". The reason for this is
that .NET removing can use a binary serialization and operate over HTTP
whether it’s using SOAP or the binary format.

Having said that the literal gives you about 90% of what you need, its just
that you have to have a gateways in and out of domains that allow RPC
invocation on one side and messaging on the other - and for that we have a
role called the Communicator!

Cheers

-----Original Message-----
From: WEBBER,JIM (HP-UnitedKingdom,ex1) [mailto:jim_webber@hp.com]
Sent: Saturday, October 27, 2001 9:22 AM
To: BTP (E-mail)
Subject: [business-transaction] SOAP Bindings Stuff


[This messages has been delayed because my laptop decided to play up, sorry]
Hello BTP'ers,

Yesterday afternoon (as Alastair announced) we held a small teleconference
to discuss the SOAP bindings for BTP. In attendance were myself, Mark
Little, Alastair Green, Alex Ceponkus , and later on Bill Pope.

In essence what was agreed (and informally I might add, this was more a case
of discussing a seemingly shared implementation-oriented problem) was that
SOAP RPC is the way to go for our SOAP bindings as opposed to SOAP messages.
However, there were two distinct trains of thought on how to proceed under
that scheme (the stuff in <opinion /> tags are my thoughts on the
conversation in the cold light of day).

The first of the two schemes (AG) was that a BTP service would expose a
single method over SOAP (something akin to a doIt() method) which would
accept as its argument a BTP message, which would be propagated to some
additional logic which would then "do the right thing" inside the stack. The
rationale for this approach is that it has minimal impact on the spec as it
stands and is relatively simple to understand since there is only one method
to think about. From an implementation perspective (AG & AC) suggested that
with the relative immaturity of some SOAP implementations that this approach
is the only realistic option.

<opinion>This scheme seems to be equivalent to running SOAP messages on top
of SOAP RPC, which would then require a dispatch mechanism inside the stack
which itself is RPC like</opinion>

The second of the two schemes (JW) was to treat a BTP service as any other
Web Service and expose all of the necessary methods over SOAP, with the
supporting notion that the SOAP server can handle interception for context
insertion/removal. This scheme does not require any additional dispatch
since it can be handled by the SOAP implementation's RPC mechanism.
Furthermore, it divides the interface into the kinds of methods that I would
expect a transaction manager to possess. From an implementation perspective
(JW) suggested that it would in fact be easier to interoperate if we had a
less coarse-grained interface to the Web Service, and that from an uptake
point of view, simpler but more methods are more akin to the kinds of Web
Services that people are used to seeing and thus would be comfortable with.
AG's response to this was that it is only us (i.e. BTP implementers) that
would ever see these interfaces and so it isn't really an issue. My
perspective was that I wanted the same level of ease of implementation in my
Web Service (even though it is a transaction manager) as anyone else
implementing a Web Service would get.

<opinion>This scheme would involve some significant work on the spec, and
may cause further delay to its release. However I think interoperability
would be best served this way and it is certainly the case that SOAP RPC
with context (in the SOAP header) insertion/extraction can be handled
relatively cleanly by the popular SOAP implementations.</opinion>

It was also suggested (JW) that a face to face meeting on these issues (with
the benefit of a whiteboard) would help all those involved to better
understand these issues and resolve a solution. AG kindly offered to host
such a meeting at the Choreology offices in London and it was agreed by
those in attendance that such a meeting would probably be a good idea.

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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>