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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

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

Subject: [ebxml-dev] RE: Public usage scenario documents

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.

[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