RE: [ebxml-dev] Re: [EDI-L] Announce - Latest Article on ebXML

[Adam Sroka <AdamS@rewardsplus.com>]

Title: RE: [ebxml-dev] Re: [EDI-L] Announce - Latest Article on ebXML

Hi,

I am relatively new to ebXML. However, one of my areas of expertise is distributed AI (MAS). The core of your argument appears to be that businesses don't make decisions about what to buy from whom by opening the yellow pages and flipping around until they find it. I agree, but I would like you to take another look at this from the perspective of an intelligent agent establishing relationships on behalf of the business user.

Agents can have a lot of interesting abilities. An agent on behalf of a buyer can negotiate with agents on behalf of several sellers to arrive at an agreement that best meets certain parameters. For instance, an agent on behalf of a car manufacturer can negotiate with several partners to find the most cost effective source of parts given certain engineering criteria (materials used, strength, measurement tolerances, etc.), and best time to market. The process for humans to do this can take quite a lot of time and effort with a lower chance of success. Whereas, agents who can discover one another through ebXML CPP/CPA and/or UDDI can establish relationships with one another and negotiate a mutually beneficial agreement while the humans are sleeping.

I, along with many others interested in these emerging technologies, believe that the greatest benefit of techniques such as SOAP, UDDI, and ebXML among others is that they enable diverse and independent forms of intelligence to communicate in a universal, open marketplace. I see the fact that more traditional methods of communicating/trading are also enabled by these new standards to be a tremendous benefit, but to see the true power I think you need to look a little further down the path. IMHO

Regards,
Adam Sroka

 -----Original Message-----
From:   William J. Kammerer [mailto:wkammerer@novannet.com]
Sent:   26 November, 2001 17:45
To:     edi-l Yahoo List; ebxml-dev
Subject:        [ebxml-dev] Re: [EDI-L] Announce - Latest Article on ebXML

Many thanks to Mike Rawlins, who shared with us his latest in the hit
series on ebXML: "Market Impact of ebXML Infrastructure Specifications:
Will any achieve critical mass?," at
http://www.rawlinsecconsulting.com/.  As usual, Mike is insightful and
smart, and one should be careful before coming up with a contrary
position.  But here I go:

Mike says ebXML Messaging Services may be left behind in the dust
because "There's a very good chance that SOAP by itself may become the
de facto standard."  ebXML MS and SOAP have different intentions:  SOAP
"is a lightweight protocol for exchange of information in a
decentralized, distributed environment," intended as a replacement for
binary CORBA and DCOM messaging.  ebXML messages, on the other hand, are
heavyweight containers for bulging business payloads.  If SOAP is not a
direct competitor to ebXML MS, maybe W3C's nascent XML Protocol -
described at http://www.w3.org/2000/xp/ -  could be.  In any event,
something like ebXML Messaging services will be needed to provide the
business messaging transport framework for the "digital dial tone" Mike
mentions.  My alternate prediction is that either one or the other
(ebXML MS or XML Protocol) will have a Gartneresque probability of
achieving critical mass of .8.

Of course, as Rachel Foerster pointed out: "Companies do business with
other companies (for the most part) AFTER establishing a business
relationship and determining the business rules of engagement."  If the
ebXML CPA/CPP Trading Partner gizmo were just (or even primarily) for
facilitating interoperability between unknown trading partners, I agree
that it would never see the light of day (in a real implementation).

But there are lots of occasions for two known trading partners to want
to automate mundane agreements.  For example, on the EDI-L list in just
the last few weeks we've heard people asking what the ISA14 was for, and
it ends up it has nothing to do with the X12 997 functional
acknowledgement whose use depends on out-of-band Trading Partner
agreement(s).  And we had the issue of the business response to a
UN/EDIFACT INVOIC message: wouldn't it be nice if one could advertise
(in the CPP) their ability to automate remittance advices, so their
trading partners could automatically ask for one if they were capable of
handling it?   The rough analog of all this - and more - is built into
the ebXML CPP/CPA specification!  Mike gives the CPP/CPA spec a
probability of achieving critical mass of .2;  I'll say it's closer to
.5 or .6.

Speaking of an Open-EDI framework, where buyers "discover" sellers, I
am reminded of the ebXML Registry and Repository specification which
assumed this would be the normal mode of e-business.  Even in the last
draft document developed by ebXML's Reg Rep successor,  the OASIS
Registry TC, "OASIS/ebXML Registry Services Specification v1.02 DRAFT,"
(26 November 2001), we still have the ridiculous scenario which
originally caused my fur to rise:

   5.2.4 Buyer Discovers The Seller. The buyer browses the Registry
   using Classification schemes defined within the Registry using
   a Registry Browser GUI tool to discover a suitable seller. For
   example the buyer may look for all parties that are in the
   Automotive Industry, play a seller role, support the RosettaNet
   PIP3A4 process and sell Car Stereos. The buyer discovers the
   seller's CPP and decides to engage in a partnership with the
   seller.

   5.2.5 CPA Is Established. The buyer unilaterally creates a
   Collaboration Protocol Agreement or CPA as defined by [ebCPP]
   with the seller using the seller's CPP and their own CPP as
   input. The buyer proposes a trading relationship to the seller
   using the unilateral CPA. The seller accepts the proposed CPA
   and the trading relationship is established. Once the seller
   accepts the CPA, the parties may begin to conduct B2B
   transactions as defined by [ebMS].

I commented on this as far back in January:

   I notice that the AIAG is represented among the Reg Rep
   participants.  I might be all wet. I don't know the auto
   business. But c'mon:  would Volkswagen really "discover"
   car stereos this way?  Or is it just because VW doesn't
   have ebXML - to show them they have alternatives - that
   they've put Bosch radios and spark plugs, etc. etc. in
   every VW since the Third Reich? The manufacturers'
   supply chain partnerships are based on long-standing
   relationships involving trust.  Just look at Ford and
   Firestone - it took a trauma like the exploding radials
   to break apart a 98-year company partnership, which
   included Ford-Firestone dynastic marriages along the way!
   This "discovery" crap sounds like e-marketplace hype which
   only analysts and VC would swallow. If Ford wants to
   "discover" a direct supplier, their own buyers and
   engineers know where to look - they don't need ebXML.

See http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00048.html.
Needless to say, I'm not too popular with these opinions (which
obviously were ignored, since the latest rendition of the ebXML Registry
Services document still contains the same mumbo-jumbo).  This is why
Rachel and I have to sit in the corner all alone, wearing our dunce hats
with gum on our noses.

William J. Kammerer
Novannet, LLC.

----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>