[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: CNET.com - News - Enterprise Computing - Microsoft,IBM setasiderivalry to cr
Jim,
Please see below.
Cheers,
Chris
James McCarthy wrote:
>
> Chris,
>
> I agree with all of your points. I would never suggest that the ebXML group
> adopt SOAP as its wrapper only that a specification could be put forward for
> passing ebXML via SOAP for those organization caught up in the hype. What
I think that at present, there is nothing but hype. It isn't clear to me
what such a mapping might look like. For certain cases, where there is
but a single XML document as payload, it might be possible to package the
message up using SOAP. However, I fail to see the benefit. A translation
gateway (mapping an ebXML message to SOAP) could be developed, but I do not
see this as something which is in our charter to provide. We have enough
on our plate such as the following:
- reliable messaging
- security
- tpa
- negotiation and discovery
without adding more work which is (IMHO) less critical to the overall
success of ebXML.
> those organizations don't realize is that the lack of specifics in the SOAP
> spec will make interoperability difficult not its simplicity. I assume you
Agreed, and we (ebXML) need to expose this at every opportunity we get.
> have seen the BizTalk 2.0 spec which uses SOAP as its wrapper to carry a
> BizTalk namespace.
Yes, I have studied BizTalk. It is surprisingly similar to ebXML...
It would be great if we could get Microsoft back on board to work WITH us
in our effort to forge a *single* solution and framework which can be applied
to the domain of e-business messaging. We would much rather that there be
but one, as that would only help to gain increased interoperability and would
help us achieve our objective of establishing a *single* global marketplace.
>
> I have been a silent participant for many months on this list and
> unfortunately every time a U.S. meeting is scheduled I have a conflict and
> can not attend. I had hoped to meet you at the Burlington meeting since our
> office is in Burlington as well. I am eager to see more of the great work of
> this group and look forward to implementing support in our product.
I am sorry you couldn't join us in Burlington. We're always interested in
adding new members to our team. Are you going to be in Jan Jose next week?
>
> Sincerely,
>
> Jim McCarthy
> CTO, WebXi, Inc.
> http://www.webxi.com/
>
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> Sent: Saturday, August 05, 2000 11:48 AM
> To: James McCarthy
> Cc: Ebxml
> Subject: Re: CNET.com - News - Enterprise Computing - Microsoft,IBM set
> asiderivalry to cr
>
> 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
--
_/_/_/_/ _/ _/ _/ _/ 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC