Re: [business-transaction] SOAP Bindings Stuff

[Alastair Green <alastair.green@choreology.com>]

Jim,

I think that the best way to progress this is a) meet whenever the messaging
subgroup wants (via James Tauber its chair), however it makes sense, offer still
open for a whiteboard session in London, and b) just as important -- all
concerned to put forward worked examples of their approaches in the concrete. I
believe your scheme is, if not infeasible, overly complex and loses the vital
(nay, brilliant) crossover that SOAP provides between messaging and RPC. I do
not believe these two approaches are counterposed, and agree with Ed Cobb and
Scott Dietzen of BEA that asynchronicity is a valuable feature to retain and
promote. (Not coming to the same conclusion as Ed does, about BTP, obviously).

I think Bill and Alex are thinking of coming up with some kind of concrete
proposal, which sounds like a good way to go.

Alastair

"WEBBER,JIM (HP-UnitedKingdom,ex1)" wrote:

> [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>
begin:vcard 
n:Green;Alastair J.
tel;cell:+44 795-841 2107
tel;fax:+44 207-670 1785
tel;work:+44 207-670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
adr:;;13 Austin Friars;London;;EC2N 2JX;England
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
fn:Alastair J. Green
end:vcard