RE: Ebxml, BizTalk et al

[Dick Brooks <dick@8760.com>]

Steven,

I attended the ebXML meeting in Boston last week and provided some of the
BizTalk/ebXML analysis. The following is my analysis of the two:

SIMILARITIES:

- Both are trying to solve the same problem; reliable, secure delivery of
multimedia payloads.

- Both use MIME to package multimedia payloads in request messages.

- Both use XML to describe header level information in a "header document".

- Both contain routing information, message identification and support for
QOS functions, including reliability and delivery constraints in their
header document.

- There are common "tag names" (e.g. to and from ).

DIFFERENCES

- ALL ebXML exchanges (both request and response) use a single packaging
structure (MIME multipart/related);
  BizTalk defines two packaging structures for requests, XML only for a
single payload and MIME multipart/related for
  multiple payloads, all BizTalk responses are XML only.

- ebXML defines a packaging hierarchy with one mandatory "header container"
and one optional "payload container". The
  payload container can contain a simple single body part or a complicated
nesting multipart/*, this allows the entire payload to be signed/encrypted.
BizTalk uses a flat packaging structure where each part exists at the same
level as the header. It is possible for a BizTalk message to be structured
in exactly the same way as ebXML through the use of a multipart/*, but this
is an implementation decision.

- BizTalk uses SOAP to encapsulate "header level information" and responses,
ebXML does not use SOAP.

- ebXML supports both synchronous and asynchronous delivery of response
messages; BizTalk only allows asynchronous delivery of response messages

- ebXML contains routing information in both request and response messages
(to party, from party); BizTalk does not contain routing information in a
response message (but I believe this may change in the next BizTalk spec).

- ebXML supports three processing modes:
	- one-way/no response
	- Synchronous Request-Response (a.k.a. RPC)
	- Fire and Forget/Full Messaging
  BizTalk supports one-way/no response and Fire and Forget/Full Messaging.

- The ebXML packaging spec references S/MIME (RFC 2633) and PGP/MIME (RFC
2015) standards for encryption and digital signature and the ebXML header
spec references XML Dsig for more granular signature requirements than
provided by RFC 2633 and RFC 2015;
Encryption and Digital Signature specifications are expected to be addressed
in a later version of the BizTalk spec.


Hope this helps.

Dick Brooks
http://www.8760.com/




-----Original Message-----
From: Steven Livingstone [mailto:s.livingstone@btinternet.com]
Sent: Friday, July 14, 2000 6:41 PM
To: ebXML-architecture@lists.oasis-open.org
Subject: Ebxml, Biztalk et al


List-Subscribe:
 <mailto:ebxml-architecture-request@lists.ebxml.org?body=subscribe>
List-Unsubscribe:
 <mailto:ebxml-architecture-request@lists.ebxml.org?body=unsubscribe>
List-Archive: <http://lists.ebxml.org/archives/ebxml-architecture>
List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
 <mailto:ebxml-architecture-request@lists.ebxml.org?body=help>

I hope this is the correct list for this question.

I am looking for a paper reviewing the similarities and differences, pros
and cons between Ebxml and similar initiatives, BizTalk in particular.

Any views from this list would also be appreciated !

Thanks,
Steven

Author and Reviewer,
Professional XML, ASP XML, Beginners XML,
Pro Site Server, Pro Site Server Commerce
Wrox Press, http://www.wrox.com

Steven Livingstone
Glasgow, Scotland.
07771 957 280 or +447771957280