[ebxml-dev] RE: Public usage scenario documents

[James Bryce Clark <jamie.clark@mmiec.com>]

At 03:47 PM 5/25/02, Cutler, Roger (RogerCutler) wrote:
> I'd like to get some input and help
> from ebXML.  And I have mentioned ebXML
> in previous conference calls -- not disparagingly but with a certain
> feeling
> of confusion. ***

Some confusion is understandable.  We lost several months of
marketing momentum in 2001, due to the obvious economic vortex, and an
untimely reorganization when several vendors decamped to a more
proprietary, vendor-owned venue that became WS-I.  However, the
substantive work has progressed uninterrupted -- we are still long on
technical experts and user alpha tests, if short on
marketeers.   

> *** I am not
> trying to get into business requirements per se, but only as they drive
> the
> technical infrastructure requirements.  This is a rather delicate
> balance, ***

Whew.  No kidding.  Often it requires being agnostic and
ambivalent on technical issues to a degree that annoys software
designers.  Your missing-message-23 case is a good example.  I
don't know if we are right, either, but permit me to describe how the
"delicate balance" seems to work for us:
   -- Business requirements ("talking to users") tell
us that some people will use systems with low-metadata, "dumb"
document-based messages that need ordinality to be tacked on from the
outside by some messaging-counter or workflow service.  There is no
other way for such exchanges to detect missing or async out-of-sequence
parts.  Without it, they can't play in our sandbox.
   --  The same process tells us that others will use
systems driven by shared data objects with managed states that carry
their own binding choreography.   Imposing message-order as a
mandatory overlay would destroy the sequencing model on which such a
system hinges.  Impose an overriding dumb message numbering system,
and they can't play in our sandbox.
  --  So the net business requirement imposed on our technical
architecture is that we must permit both methodologies, and
provide a platform-neutral way to elect which one governs a message
exchange.  
There are perhaps a dozen similar compromises in ebXML standards. 
They may result in less elegance or compactness, but I think they are
necessary to modularity, easy adoption and vendor neutrality.  Which
are our imperatives and, I think, the reason a lot of industries feel
safe using our stuff.

> *** Although
> it is not exactly the subject of the note I am responding to, I might
> also mention that I am kind of bemused by the ebXML reliable messaging
> spec -- *** Is this going to get re-done?  Extended or fixed? 
> By whom?

You have heard technical views from Duane, Marty and others.  Of course,
users and vendors might vary on how reliable "reliable" must
be.  I'm not enough of a technician to have a view.  But I can
answer your specific question.  There is a continuing, live ebXML
messaging team organized as an OASIS TC, visible at
http://www.oasis-open.org/committees/ebxml-msg/.  
It is responsible for continuing versioning of the standard, and I
understand they are already making plans for v3.0.   Personally
I am pleased that there is a viable alternative to efforts elsewhere to
embrace and extend SOAP into a proprietary-lock-in trap. 
Regards   Jamie Clark

~ James Bryce Clark
~ VP and General Counsel, McLure-Moynihan Inc.   www.mmiec.com
~ Chair, ABA Business Law Subcommittee on Electronic Commerce  
~ www.abanet.org/buslaw/cyber/ecommerce/ecommerce.html
~ 1 818 597 9475   jamie.clark@mmiec.com   jbc@lawyer.com
~ This message is neither legal advice nor a binding signature.  Ask me why.