[ebxml-dev] RE: Public usage scenario documents (BTP)

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

At 05:34 AM 5/28/02, you wrote:
> Dear Marty, As far as ignoring
> ebXML messaging - I would not put it that strongly.  I think that
> there is the usual gradation that goes something like:
>     ordinary messaging (e.g. SOAP, ebXML messaging,
> ...)
>     reliable messaging (e.g. ebXML reliable messaging,
> HTTPR, ...?)
>     transactional messaging (e.g. BTP, ...?)
> Best Regards     Tony
> A M Fletcher
> Choreology Ltd., 13 Austin Friars, London EC2N
> 2JX     UK

    There are a couple of issues perhaps being
conflated.

    First, words like "reliable" should take
quantifiers.  No schema is reliable, if we posit a
sufficiently catastrophic event.  As Marty suggested, boxcars of
baked beans have different risk thresholds than real-time securities
clearinghouse transactions.  I think Tony's suggestion that ebXML further
define the reliability of "reliable" messaging is a good
one.  The imminent BTP primer might also consider its own statement
of reliability qualifications.   

    Second, "reliability" may reside at
various layers of a stack of specifications.  Tony's
positioning remark compares apples to oranges by mentioning the ebXML
transport layer and the BTP business choreography
layer.   Shared signals and retry rules (BPSS/UMM) and unilateral workflow engine logs (BTP) are two legitimate different ways to address reliability at the higher end of the stack.  They have different user requirements.  As a key BTP member and sponsor, Tony no doubt feels strongly about BTP.  Personally I think that the ebXML BP methodology also has some strengths.   I do not know enough about BTP's relation to specific vendor offerings, or potential for one trading partner to grab control, to evaluate exactly how BTP might interop with ebXML layers yet, but it is being studied with an open mind by our BPSS and CPPA teams.  Tony has been an important contributor in the latter.

    ebXML is at a bit of a disadvantage in competitive standards jockeying, as we are an open standard, and our mandate is to remain architecturally open to interoperability with anyone at any layer.   Whether or not they say nice things about our work.   On the whole though I think this openness is more of a virtue than a drawback.
     
Regards   Jamie Clark

~ James Bryce Clark 
~ VP and General Counsel, McLure-Moynihan Inc.   www.mmiec.com
~ Chair, ABA CLCC 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.