RE: IETF draft on appropriate uses of HTTP

["Eric Newcomer" <eric.newcomer@iona.com>]

Title: RE: IETF draft on appropriate uses of HTTP

IONA's view, for the record, is that V1.1 eliminates 99% of any MSFT-isms that were present before.  Although we are not listed as authors, we submitted several pages of comments and suggestions (we did not write any of the actual text), which were treated very seriously and incorporated to our satisfaction.

 

We are interested in continuing to contribute to the standardization of SOAP through an independent consortium -- W3C is a great place for the work, and we're hoping to make good progress there with everyone's help (including those on this list).  We know SOAP doesn't provide everything ebXML requires, but we think it's a good start, and is extensible enough to add most if not all of those things.

 

We are also investing in helping to develop and standardize CORBA mappings for SOAP as part of ensuring that the goals of SOAP are achieved.  We are very hopeful SOAP may become the de facto and de jure standard for formatted Internet messaging.  We are providing a completely non MSFT implementation in our portal server but we expect to interoperate with MSFT based implementations.  Our goal is to bridge things and facilitate interoperablity rather than endorse or suport proprietary interests.  We feel that MSFT and the other submitters are equally committed to making SOAP a truly open standard.  Otherwise, we wouldn't be here.

 

On the subject of implementations, yes, MSFT as one of the original authors might have some advantage (as any author/editor of any spec does) right now, but:

 

o  This will be eliminated once the spec is under W3C (or whoever) control

o  IBM and DevelopMentor (and others on the SOAP email list) have made reference implementations freely available

 

I would rather go forward, as Kent said, and see if we can all work together on the opportunity here, take advantage of it while we can, rather than look/hope for another initiative later on.

 

Eric

-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Kent Brown
Sent: Thursday, May 11, 2000 12:40 AM
To: Ebxml
Subject: RE: IETF draft on appropriate uses of HTTP

Comments in line:

Vendors and developers worldwide, especially reputable vendors like
IBM, Sun are not going to get down and wrestle in the mud by criticising
Microsoft or SOAP.  Following is my opinion.
<KB>How much do you know about SOAP?  IBM is on the list not only of supporters, but of the authors as well.</KB>

The problem with SOAP is that it was designed and developed at Microsoft,
over an extended period in which the implications of every aspect of SOAP
were carefully considered by Microsoft in its ongoing development of
XML platforms such as MSIE5 and BizTalk server.  This fairly well ensures
the following:

 1.  whatever capabilities exist in Microsoft platforms, SOAP will support
     them marvelously.
<KB> Not true.  For example many of the capabilities of DCOM are not supported at all for the express purpose of interoperability and simplicity.  Much of the encoding rules were gleaned from Java RMI and CORBA technology more than COM.</KB>

 2.  whatever features that could have exist within SOAP, which might have
     similarly maximized the efficiency or fit for other vendors platforms,
     are not necessarily present, and I am being polite, here.
<KB> Not true.  In fact as of now there is no public implementation of SOAP in COM.  The best support to date has been for Java and Perl implementations by DevelopMentor.  The authors have bent over backwards to avoid even the appearance of any affinity to COM or any other MS-specific technology.  Can you provide a specific example?</KB>

 3.  whatever features exist in SOAP, Microsoft's numerous, wellpaid
engineers
     are already up to speed, have a 1 year head start, and developing
     applications with them.
<KB> Actually IBM has forced Microsoft's hand by their rapid release of a Java reference implementation of SOAP.  I've heard

it said by one of the authors that there are more SOAP developers at IBM than at MS</KB>

Microsoft already has overwhelming economic power in the marketplace.
Why would any vendor want to get involved with SOAP?  and go directly into
competition with Microsoft?
<KB>Is ebXML about opposing MS or finding a technical solution to interoperability?</KB>

Other technologies and other vendors and participants are fully capable
of providing solutions without SOAP.  Similarly, if ebXML adopts SOAP, the
result would be a relative weakening of other participants intellectual
contributions.  
<KB>Again, is ebXML about who gets credit or finding the best solution?  Isn't one of the core philosophies to leverage existing technology where possible?</KB>

You can't have it both ways.  If you rollout solutions
that run on Microsoft platforms better, sooner, faster, then ebXML will
not be a level playing field for other vendors and they will not invest
money and mindshare into it.
<KB>From the long list of folks supporting SOAP it looks like a pretty level field to me.  Do you think companies like IBM and Iona are looking at it to help MS?</KB>

No SOAP.  Make it plain XML.
<KB>By the same logic should you say "No ebXML.  Make it plain XML"?  SOAP is about as pure XML as you can get. The only thing that is not "pure XML" is the optional encoding rules.</KB>

Todd Boyle Kirkland WA   www.gldialtone.com

<KB>SOAP in no way addresses all of the goals of ebXML.  It is not the complete solution.  But there is no reason it can't be considered for the part of the problem it does solve.</KB>

Kent Brown
Architectural Consultant
Alpha Technologies
732-980-1800 x207
www.alpha88.com