OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Ebxml, BizTalk et al


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:


- 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 ).


- 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

-----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-Archive: <http://lists.ebxml.org/archives/ebxml-architecture>
List-Help: <http://lists.ebxml.org/doc/email-manage.html>,

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 !


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC