- From: Satish Thatte <satisht@microsoft.com>
- Date: Thu, 7 Dec 2000 16:43:07 -0800
- To: "'Burdett, David'" <david.burdett@commerceone.com>, "'David E. Cleary'" <davec@progress.com>, Michael Champion <mchamp@mediaone.net>, xml-dist-app@w3.org
David, I don't want to turn this into an XP vs ebXML slugfest, but the reason I said I can think of many missions for which a lightweight XML-based protocol would be required and built on top of XP and ebXML/TRP would be altogether a failure in that "mission critical" role. is simply that ebXML is a relatively fixed protocol for a specific purpose with no extensibility model that allows design of new protocol elements for new "mission critical" requirements. The fact that it forces the use of multipart MIME packaging could be a practical problem in some cases but is a conceptually less important limitation. What this means to me is that XP is approaching the layering problem the right way, by building an enabling protocol framework with a general model for extensibility, composition, intermediaries, and so on, rather than a closed protocol for a fixed requirement set. Satish -----Original Message----- From: Burdett, David [mailto:david.burdett@commerceone.com] Sent: Thursday, December 07, 2000 2:22 PM To: Satish Thatte; 'David E. Cleary'; Michael Champion; xml-dist-app@w3.org Subject: RE: SOAP and ebXML I want to respond to a number of emails in one. Firstly James Snell said that ... "There is, however, a tendency to minimalize SOAP into nothing more than a simple XML RPC mechanism that gives the appearance that ... it is not a suitable mechanism for mission critical, complex business applications." I have never thought this. What is mission critical to one person is not to another, and I completely understand and accept that a lightweight protocol might be absolutely essential as the only way for some applications to work. Secondly I would disagree with Satish when he says ... "I can think of many missions for which a lightweight XML-based protocol would be required and built on top of XP and ebXML/TRP would be altogether a failure in that "mission critical" role." The key thing about ebXML/TRP is that it starts by trying to solve a larger problem and then making parts of the soloution optional if they are not needed. If you were to use ebXML/TRP in its most minimalist way, you would end up with something that is not that much different in complexity and scope than SOAP, the main difference would be that the "body" in a SOAP message would always be in a separate MIME part in ebXML. This is good news in that it ought to mean that the work of the two groups should be able to converge. It is also might be bad news in that unless we are careful we might re-invent the wheel yet again. Either way as long as we are aware of this risk we should be able to work out something that works for everyone. Regards David -----Original Message----- From: Satish Thatte [mailto:satisht@microsoft.com] Sent: Thursday, December 07, 2000 12:36 PM To: 'David E. Cleary'; Michael Champion; xml-dist-app@w3.org Subject: RE: SOAP and ebXML David, You are absolutely right. BizTalk Framework started with the same general requirements as ebXML/TRP including 1. Transport independence 2. Ability to carry arbitrary content 3. Reliable delivery 4. Message level security Although early versions of BizTalk Framework were designed from scratch without reference to SOAP, in the 2.0 version we were able to rebase the framework completely to build on SOAP. In so far as XP plans to provide an extensible protocol framework in the SOAP tradition, there is absolutely no reason why we cannot use XP to build a protocol that fulfills the set of requirements ebXML's transport/routing/packaging work is based on. I don't think it is meaningful to talk in terms of "mission critical" vs "non mission critical". What is mission critical obviously depends on the mission. I can think of many missions for which a lightweight XML-based protocol would be required and built on top of XP and ebXML/TRP would be altogether a failure in that "mission critical" role. The point is that XP enables a much wider class of mission critical protocols, whereas ebXML focuses on a more specific B2B mission reflected in its specific requirements. Satish -----Original Message----- From: David E. Cleary [mailto:davec@progress.com] Sent: Thursday, December 07, 2000 8:02 AM To: Michael Champion; xml-dist-app@w3.org Subject: RE: SOAP and ebXML > I'm wondering if participants here agree with the notion that SOAP is for > simple services and ebXML for mission critical transactions. If so, what > about ebXML makes it more suitable for mission critical work? > (Transaction > processing support, maybe?) I agree with the notion that ebXML is not appropriate for every uses case, and that SOAP is a better choice for many applications. What I do not agree with is that SOAP can not be the base upon which something such as ebXML could be built. A perfect example of this is BizTalk. It has the same requirements as ebXML, but is built on top of SOAP. So, in conclusion, my point is that XP can be used for mission critical work if you build the required services on top of it. David Cleary Progress Software
Received on Thursday, 7 December 2000 19:47:48 UTC