Re: CNET.com - News - Enterprise Computing - Microsoft,IBM setasiderivalry to cr

[Christopher Ferris <chris.ferris@east.sun.com>]

Jim,

We too, have studied the SOAP1.1 specification quite thoroughly.
As you point out, technically, this would not be a challenge.

However, as you point out in your last sentence, it does not
meet all of the requirements for ebXML. There-in lies the rub.

The issue of separation of the header from the payload you cite is
one of the requirements which is quite important for a number
of reasons.

- intermediary nodes, such as brokers or routers, will need
to have access to the headers, but for security reasons, should
not have access to the content. Separating the headers from the
payload allows for encryption of the payload while at the same
time, permitting access to the headers so that routing decisions
can be made without the need to share the encryption key with
an intermediary node(s). It would seem to me that the same
set of requirements for secure e-mail apply to e-business messaging.
The headers and body are effectively separate parts. Effective
solutions exist for S/MIME and PGP/MIME which can be effectively
employed to enabling the payload to be separately signed and encrypted from
the headers.

- it is likely that an ebXML gateway into an
enterprise will be employed in many cases to allow for messages
to traverse a firewall. Its purpose will be to make a determination
as to the disposition of the message and pass it on to an internal
ebXML server for processing. By having the payload and headers
in a single XML document, it would need to parse the entire 
document (which might be quite large). This additional parsing
would degrade the overall performance of the gateway, especially
given that its role is to check the headers to determine if the
message is permitted to pass through (e.g. a TPA for the partner
is present), harden the message, and then route it to the appropriate 
internal service for processing of the payload.

- on a related note, it is clear to me that given the previous
two issues (extra-firewall processing and encryption) that SOAP
is an ineffective solution. I cannot imagine that any enterprise
would EVER expose its encryption keys external to its firewall.
However, given that a SOAP message is a single document, if
signed and encrypted, access to the encryption keys external
to the enterprise firewall would be a necessesity in order
to decrypt the message to determine its disposition and handling.

- a single SOAP document is an ineffective envelope for an XML 
*document*. A document would need to be enclosed in a CDATA element.
This added encoding overhead is an unnecessary burden, and is
more complicated to process. Use of a MIME multipart envelope
is a far more natural packaging solution than is XML. An approach
such as has been taken by BizTalk adds unnecesary complexity
to the processing of a message. I would rather than the ebXML
TR&P processing be consistent for *all* messages than to have
to resort to a bi-modal processing of messages. It only adds to
the performance overhead to have to make this additional
determination as to correct handling of the message.

- similarly, SOAP is an ineffective solution for enveloping
binary data. This is key to the success of any e-solution (IMHO)
as it is necessary, and a key requirement of ebXML, that whatever
solution is employed offer a smooth transition for EDI and
other emergent XML vocabularies. We must recognise that
many enterprises which have deployed EDI exchanges with
their business partners will not be willing to invest in
a re-tooling of these deployments in the near term. EDI is not
going away for quite some time to come, and any e-business
solution will necessarily need to accomodate these legacy
systems. MIME offers a natural packaging for binary data
which is also quite suitable for XML.

- one of the prime directives of ebXML is to enable SMEs to
participate in electronic business without the need to make 
substantial investments in new hardware or software. MIME
encoding is nearly ubiquitously supported by mail clients
and by many browsers. It is conceivable that an SME could
get by with use of a mail agent as their ebXML service handler
using MIME. Use of SOAP as the envelope would necessarily require
unnecessary investment in new software *which does not yet exist*.

I certainly wish that someone would clarify the purpose of SOAP
for me. It is trying to be many things, but it isn't clear to
me that it offers any benefit as a total package. It has a default
encoding specified which, on its own, may have merit in certain
cases, but is clearly not adequate or even suitable for all purposes.
It is attempting to provide a packaging solution. But, as described
above, is inadequate for many purposes. In addition, the encoding
scheme is suitable for encoding of RPCs, but unnecessary for
encoding of documents.

It has defined a protocol of sorts for handling extensions. However,
the approach taken (mustUnderstand) is VERY suspect with regards
to interoperability. Interoperability is a core requirement for
e-business and for ebXML. It is not clear to many that interoperability
is a core requirement for certain of the authors of the SOAP specification.
In fact, the opposite might be more in line with certain motivations.

It has defined a protocol for "routing" (actor) which is clearly
not e-business friendly based upon the current specification.
Having a requirement that the SOAP message be *altered* (removal
of the actor elements after processing, before forwarding to the
next in the chain) makes signing of the message a complex if
not impossible proposition given the current available solutions
for digital signing of documents. (DSig might work, but is NOT 
yet a W3C recommendation)

e-business is not, and should not be RPC-centric. It is all about
the exchange of *documents* or messages. RPCs are too tightly coupled 
to be effective for the asynchronous nature of e-business. 

IBM's involvement in SOAP for 1.1 toned down the RPC-centric aspects 
of SOAP, with the express intent of enabling it to support asynchronous 
messaging. However, it is not clear as to whether this has proven to be
effective. Clearly, there is nothing in the SOAP spec which expressly 
defines a messaging protocol (to, from, service, etc.
headers are not defined). Hence, it would be necessary to have these
defined separately. 

It is not clear to me that SOAP offers any value add in this 
particular space over what we have already defined for ebXML.

Of course, there is no reason whatsoever why ebXML TR&P could 
not be effectively used to transmit a SOAP message as its payload.
Use of SOAP for the converse is a less than optimal if not practical
solution.

Cheers,

Chris

James McCarthy wrote:
> 
> Dick,
> 
> I have looked at the SOAP 1.1 spec and have implemented a parser for it. The
> specification is so broad except for the specification of data types.
> 
> I believe it would be trivial to put the ebXML headers in the SOAP header
> and the payload in a SOAP body. The only thing this would really require
> would be to define two namespaces, one for the ebXML headers and one by the
> application for its payload and then use the SOAP wrapper instead of MIME.
> 
> A simple specification document like the MIME wrapper spec should take care
> of the whole argument. Then we would have "ebXML over SOAP".
> 
> I know this would not meet some of the ebXML requirements (mostly that the
> headers and payload are separate documents). But it would clarify the
> purpose of SOAP and our position in regards to SOAP.
> 
> What do you think?
> 
> Jim McCarthy
> WebXi, Inc.
> http://www.webxi.com
> 
> -----Original Message-----
> From: Dick Brooks [mailto:dick@8760.com]
> Sent: Friday, August 04, 2000 6:45 PM
> To: Ebxml
> Subject: CNET.com - News - Enterprise Computing - Microsoft,IBM set
> aside rivalry to cr
> 
> FYI.... I've had more than one person ask me if the Sun/IBM disagreement
> would affect ebXML's chances...
> 
> This press release isn't helping matters.
> 
> Dick

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903