[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Registry/Repository questions and comments
In ebXML RegRep Security-003.doc, does "DN" refer to a Distinguished Name? I see that a certificate is required in order to contribute information to the Reg/Rep. But must this certificate be signed by a trusted third-party, or can a self-signed certificate be used? If the latter, what's to keep just anyone from creating entries for General Motors in the Registry? With lights-out open-EDI, I could see the ebXML Registry used to access information on trading partners, and that information has to be completely trustworthy as having come from whom it purportedly represents. Let's talk use cases. In RegistryServicesSpecificationv0-82.pdf, Line 297: Section 5.2.6 "Buyer Discovers The Seller": "The buyer browses the Registry using a Registry Browser GUI tool. The buyer searches the Registry for suitable sellers according to the flexible classification schemes supported by the Registry. For example the buyer may search for all parties that are in the Automotive Industry, play a seller role, support the Rosetta Net PIP3A4 process and sell Car Stereos. The buyer discovers the seller's CPP and decides to engage in a partnership with the seller." 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. This reminds me of "registries" like the Phillips EDI Yellow Pages, which were certainly not used to find alternative suppliers, but rather to obtain current trading partner information like the EDI contact name or VAN and protocol information. Actually, the EDI Yellow Pages was more useful to EDI vendors for hawking their warez. The Yellow Pages was always a marginal business, then eventually moved to CD-Rom and then to the Web by Phillips Publishing, when it was eventually abandoned. This kind of EDI Yellow Pages or Directory stuff has never worked because it didn't make any economic sense. Mike Rawlins would not be as generous as I in appraising the EDI Yellow Pages; see http://www.metronet.com/~rawlins/bookmag.html, where he says "I can't imagine looking up EDI contacts of potential trading partners using this book, as there are much cheaper and more reliable ways to get that information." The typical semi-rational person will ask "What's in it for me?" when asked to laboriously plod through some sort of online registry to enter his company and trading partner information. I know: I just did it for kicks at the Ariba UDDI site, but I don't think there's a rat's ass chance anybody's going to be plowing through the UDDI registry looking for software providers of EDI productivity tools or Web-based EC, based on my SIC code or location in East Bumf*ck, Ohio. More plausible scenarios involve trading partners known to each other who wish to enhance their current relationship. A first scenario would be engaging an SME in the most rudimentary electronic commerce. Take FORESIGHT Corp., for example. We do zilch EC - a classic case of "`the cobbler's children have no shoes." So far it just wouldn't be worth it - a few thousand customers, a few hundred vendors. We're certainly not going to spend the time soliciting trading partners for EC. But you could probably talk our Controller into registering with a "global" ebXML registry saying we're ready and willing to take any kind of invoice via e-mail. Even though most of our vendors are relatively small, and would likewise achieve no economies in searching us out on the ebXML registry, there are a few big or technologically savvy ones who might want to reach us electronically with invoices or statements. As examples: Qwest - the phone company, AEP - the electric company, ADP - the payroll company, the IRS - the protection racket company, American Express, our ISP, and maybe some insurance companies and banks. Each of these outfits have hundreds of thousands or millions of business customers, and it would probably be worth their while to engage us, and every other one of their SME customers, electronically - if only they could "find" us and "hook" up to us electronically. Let's look at Qwest: we get a big itemized phone bill from them each month on paper in the mail. We don't or can't do too much with the bill now - there's just too much detail and can't be put into a spreadsheet. Right now I think Accounts Payable just eyeballs the bill to see if I've made any 1-900 phone sex calls, does a sanity check on the total, and then pays it. What if Qwest "discovered" us in the ebXML Registry, marked as willing to take electronic invoices, even if only in "baby" steps? Maybe we would specify that we want a "print" image in PDF, Word or Excel. Perhaps short of an X12 811 Consolidated Invoice, that's all Qwest would be able to provide for now. Qwest would probably find us by DUNS or Tax ID, information they could easily obtain from D&B or Lycos' Companies Online at http://www.companiesonline.com if they hadn't already asked us for these IDs when we started service with them. Using the company name to search for us would make the "discovery" difficult to automate as the name could be spelled any number of ways. Once they "found" us, they could do a little due diligence - like send a notice to the normal billing address saying they're going to start sending ebXML messages by SMTP instead of the normal printed invoice starting next month to the e-mail address found in the Registry under our entry. They'll confirm that the invoice will be in PDF in a payload attachment, but that we can optionally receive a TCIF XML version of the invoice in the future if we indicate our preference in the ebXML registry. When the invoice comes in via e-mail, Nettie's going to be surprised when she clicks on the message and sees a bunch of XML from the ebXML Header Envelope. Instead, I hope that a plain text or HTML message can be sent along with the ebXML Message Envelope which can be read by a human telling her to click on some attachment in the payload for the PDF file. This all sounds great, even if for the first year or so all we do is read a PDF instead of a printed invoice. If the network effect is great enough, and enough SMEs are thus "discovered," Qwest saves enough for a few management bonuses in printing and postage. We, the SME, always had what we had before, but get it slightly sooner. Win-Win. Later on, we might become more venturesome, and ask Qwest to send us their XML version by noting we're ready to take XML TCIF invoices in the registry. Assuming the XML is accompanied by a style sheet for presentation, we can take our time in getting used to that. When we're ready to take the *big* step, maybe we'll have some means of getting the XML invoice into an Excel spreadsheet or Quick books so we can do cost allocation, which we had never done before. Even at this point, we haven't had to make any investment in software or learn radically new procedures. The ebXML e-mail invoices come into Outlook Express just like any other e-mail. One baby step at a time. As confidence builds, we may even venture out to the ebXML registry looking for our own customers - generally the Global 2000 - who are willing to take invoices by e-mail. If we "discover" more than a hundred or so ready and willing, maybe it will be worthwhile to take the plunge. Perhaps we'll graduate to producing XML invoices. Who knows? All this presupposes adequate security. You have to be sure that some trusted authority has vouched for the certificate being used to "identify" the SO. The only thing that kept me from creating a phony entry for Intel in the UDDI registry was the stupid disclaimer at the start of the process. Normally my conscience wouldn't stop me from wreaking havoc in a case like this, but then I wouldn't be using my own name to talk about it. Would I? William J. Kammerer FORESIGHT Corp. 4950 Blazer Memorial Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "Commerce for a New World"
Powered by eList eXpress LLC