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

[Rachel Foerster <rachelf@ix.netcom.com>]

Williiam,

speak for yourself! I refuse to sit in a dunce's chair with gum or anything
else on my nose!!!! Even with you, William!

Still luv ya!

And furthermore, comments did not assert nor do I believe that there is no
value in the CPP/CPA. I see the value....it's just not in "discovering" a
trading partner, but in having a mechanism to electronically establish the
electronic interface. With this I'm in total agreement....just not the
discovery aspect of this or UDDI.

Rachel

-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@novannet.com]
Sent: Monday, November 26, 2001 4:45 PM
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>