RE: [business-transaction] SOAP Bindings Stuff

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

Jim (sorry the first was sent without the spell check or proof read)!

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 (ill discuss later in this mail)  - and one I
think the industry as a whole will follow or
have already adopted. SOAP’s greatest value is for interoperability, and
section 5 of the SOAP spec makes an argument for SOAP encoding thus allowing
tighter type
definition, which in my opinion is incorrect ( you can define types in the
XSD for the SOAP
literal, and even more validation rules). I think everyone is looking at
Document style not RPC
and will use use literal-style SOAP. In a previous meeting
James Tauber, Mark Hale and myself had this very discussion and concluded
document style was the way to go. RPC in the realm of BTP, and it could be
argued any other B2B/A2A type interaction  makes little sense, 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 and .Net to the supporting cast in this argument is a
little
false and reflects and we need to be careful. Microsoft does support the use
of RPC style as well as document style, but for separate reasons in my
opinion. Looking at
Section 5 of the SOAP spec, 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 on one hand
support both and had both in the spec  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 remoting can use a binary serialization and operate over HTTP
whether it’s using SOAP or the binary format. Document style is the way to
go if you have to interoperate if you don't and Microsoft is on both sides
use the RPC style there over internet protocols.

Having said that in my opinion 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>


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