FW: [ebxml-msg-comment] Public Comment

[Pete Wenzel <pete@seebeyond.com>]

FYI.  Is everyone subscribed to the comment list?  Does this
require followup?

--Pete

----- Forwarded message from comment-form@oasis-open.org -----

Date: 11 Feb 2005 07:58:08 -0000
To: ebxml-msg-comment@lists.oasis-open.org
From: comment-form@oasis-open.org
Subject: [ebxml-msg-comment] Public Comment

Comment from: daneel_p@yahoo.com

Hi,

Recently, a committee/group was considering only the use of AS2 for communication of business specific information and connectivity to the related industry wide registry.  

After some discussions, there is now a willingness to also consider ebMS.  However, as part of the process, a document that specifies the appropriateness of ebMS and its architecture (eg, for a registry with dual protocol) has been requested.  I've been asked to assist in this... As a matter of fact, we have already implemented ebXML based templates for various business documents (PO, Invoice etc) between retailers and suppliers so it was a natural step.  

I would like to seek comments, advise and verification on some of the relevant points related to consideration of AS2 and ebMS in two areas.  I would also, of course, be grateful for any other comments...

1. ebMS Appropriateness:  In the area of ebMS appropriateness wrt AS2, I believe it sufficient to demonstrate ebMS to be of minimally equal of AS2, if not better.  I have read both the "e-Business Messaging Interchange Assessment" Whitepaper from the OASIS/CEFACT JMT Team (May 2003) and Drummond Group's DGI Guide on "AS2, ebXML or SOAP: Which Messaging Standard to Select for Your Supply Chain and Why" and found them really useful but would like to check/asks a few questions.  Specifically, not sure if some of the claims are dated etc... eg.

a. Drummond states to choose AS2 now and move towards ebMS or SOAP later as ebMS is still in early adoption whilst AS2 is more mature (how's about for registry?).  Is that a still valid claim today?

b. Drummond states that both standards can be used to transfer any type of data, but JMT says that AS2 is heavily based on EDI style payloads and mechanisms (I couldn't find any specifics on what this means?)... is that a special case understanding I need to have?

c. Drummond also stated that ebMS is only starting in production and garnered attention from vertical and MNCs whilst AS2 adoption has been growing exponentially with high adoption in Retail and CPG (esp thru UCC & Wal-Mart).  Is that a current status?


2. Technical Architecture: In the area of implementation architecture, I think I have no problem on the end-end components.  

a. I have some questions on whether a dual-protocol (AS2 & ebMS) registry has been something anyone has done before? 

b. And whether there are any particular "traps" I should be aware of...

c. I couldn't, technically, see any component that the AS2 implementation that isn't duplicable (I only need a 1-way mapping?) on ebMS whether wrapper or payload structure.  It looks like AS2 has a few choices that are made at implementation time, but that can equally be mapped to ebMS.  Is there something I'm missing?  I could equally bind the ebMS implementation to HTTP/HTTPS like AS2 to simplify connectivity choices if needed.  The only thing was "Data Compression" which was highlighted in Drummond, I'm not sure if that's an ebMS issue?  

d. I think the "tricky" issue would be in the various supplier and retailer IDs/accounts across the different protocols... any thoughts on this welcomed.

Well those are the things that crossed my mind when I was thinking thru this, am opened to other suggestions for sure!

My thanks for anyone who read this far!  I look forward to any exchange, responses or feedback...

Thanks!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daneel Pang        
daneel_p@yahoo.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two err is human.  Three? Challenged!
Eventually, everything will be there...
I need this yesterday.

----- End forwarded message -----

-- 
Pete Wenzel <pete@seebeyond.com>
Senior Architect, SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)