[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [business-transaction] SOAP Bindings Stuff
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC