[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC