RE: [ebxml-msg] Groups - Comparing Messaging Systems for B2B - ebXML, AS2/EDIINI, VAN, WS-I/WSDl web services (Comparing messaging systems for B2B.ppt) uploaded

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

David:

 

Looks better to me.

 

I still think you might get some flak for your treatment of "synchronous and asynchronous" - Getting a "later"  async response is something that you may achieve with Web services, although requires the client to deploy its own Web service... (rather inconvenient) The notion of conversation you mention is also key here, as supported by ebMS. That goes beyond async responses. Yet again one could argue that Web services allow for BPEL correlation sets, for corelating several messages on the long run. So a "Partial" vote on WS  here would get you a larger consensus...

 

On second look, I would remove the entire "WSDL" column - not really comparable with the other messaging protocols, or could be seen as one aspect of WS-I. (also:  Reliable message delivery mechanism is kind of supported as WSDL annotation by attaching WS-Policy assertions.)

 

Cheers,

Jacques

 

 

 

---

From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Tuesday, March 20, 2007 1:07 PM
To: Durand, Jacques R.
Cc: ebxml-jc@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - Comparing Messaging Systems for B2B - ebXML, AS2/EDIINI, VAN, WS-I/WSDl web services (Comparing messaging systems for B2B.ppt) uploaded

Jacques,

 

See my notes below - I had to make adjustments - and I've stored these as presenter notes in slide 3.

 

Thanks, DW

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: RE: [ebxml-msg] Groups - Comparing Messaging Systems for B2B -
ebXML, AS2/EDIINI, VAN,   WS-I/WSDl web services (Comparing messaging
systems for B2B.ppt) uploaded
From: "Durand, Jacques R." <JDurand@us.fujitsu.com>
Date: Mon, March 19, 2007 10:30 pm
To: <david@drrw.info>
Cc: <ebxml-jc@lists.oasis-open.org>

David:

Slides look much more complete now - yet are at the right level of summarization for readers in a hurry.

Sorry for late feedback and few more suggestions:

Slide #2: 5th bullet (WS-I definition: replace "interoperability profile - series of complex extension mechanisms"  with "interoperability profiles - best practices and rules for combining WS standards".

 

>>> Yes but this loses the sense that this is complex.  "Best practices and rules" sounds like its easy!

       I added - "with extensive interdependencies" to capture that essence.

<<<

Slide #3:

Discussion in JC this morning: I suggested that some of your table entries would benefit from some explanation in a comment section (or slide notes?).

My personal feedback / questions on some entries (these would benefit from a word of explanation):

-Business process workflow enabled: need explanations to help reader (is it more like: supportive of Business process workflow at message header level)

>>> Done

- Role and action use support in envelope (need explanations. more genrally: business meta-data in header?)

>>> Done

- EDI payloads support (WS-I AP profile supports attachments, so the case could be made here that os supports payloads of any kind - although ebMS is richer in meta-data describing these).

>>> Done

- Built-in audit log and tracking: maybe what we mean here is the ability to log significant business meta-data (extracted from message header) without touching payloads? In that case yes, ebMS supports this but not WS stacks. Could be reworded: Supports [non-intrusive] audit log and tracking.

>>> What I meant here is that ebMS has direct spec' support and mechanisms - rather than ad hoc stuff. Also error handling, notification, acks, etc - that make this predictable - not vendor implementation specific.  I added wording to cover this off.

<<<

- Uses web services infrastructure --> "Based on protocol-level [or message-level] Web service standards" or "uses protocol-level Web service infrastructure" (advantage: implementations can leverage existing Web services stacks and tools, e.g. Axis2, etc. )

>>> Done

- Asynchronous and Synchronous support: do we mean "Suport for non-addressable or intermittently connected partners" (e.g. meaning Pull feature).

>>> No - this is simple - synchronous means you have to respond in real time on a connection.  In asynchronous - you establish a conversation and the reply is pending and can be at a later time.  Noted as that.

<<<

- Service & Operation levels authorization: a few words of explanation ( "different from conventional authentication of a sender: enforcing the right of a sender to use a particular Operation or Action [, or a particular message transfer mode, or to refer to a particular agreement between parties]")

>>> Done