[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: ebXML will end up being too expensive for small business
Bill Chessman, of Harbinger Corporation, worries about bringing forward a "question which may be inappropriate at this time because a) it's already been answered, or b) it's never been quite answered to anyone's satisfaction and nobody wants to deal with it just now," to wit: "What exactly does everyone think they will get out of ebXML?" As a software vendor, you should only be too happy to have a single grand unified B2B messaging framework, especially for Transport, Packaging and Routing. Today, we have to design our systems to bootstrap themselves off any variety of packaging, whether it be X12.5 and X12.6, ISO 9735 (EDIFACT Syntax), or Tradacoms for EDI Interchanges, or XML frameworks like RNIF V1.1 or BizTalk, etc. etc. Imagine all this stuff thrown away, in favor of ebXML TP&R, as Nikola Stojanovic alluded to. The simple MIME encoded packaging of ebXML TP&R will contain everything we need, such as payload management and identification, security and authentication, and addressing and routing. Everything will be handled consistently, regardless whether EDIFACT, X12 or RosettaNet messages are used. And with the ebXML TP&R, we'll be able to throw away legacy stuff like EDIINT S/MIME (AS1) and HTTP (AS2); the same packaging will work with e-mail or HTTP over the Internet! If all we got out of ebXML was the Transport Packaging and Routing framework, it would be a remarkable success. But the genius propeller heads in TP&R are not the only ones who've been busy the last six months: consider our distributed ebXML repository and registry coming out of the RegRep team. Gone are the days of having to have the message definitions for mapping centralized on your own machines. The closest we ever came in the days of EDI to having truly transportable meta message definitions of our documents was with SEF, igML or IMPDEF. And it was a black art to figure out which appropriate definitions to load: not only did you have to fart around with the GS Version Release Industry Code, you had to somehow munge it with the sender and receiver ID to come up with the unique map ID. The logic for addressing the message definitions in ebXML will be elegant, refined and designed into the framework from the beginning! Besides holding DTDs and schemas for XML documents, or SEF, igML and IMPDEF for EDI, imagine current and instantaneous access to proprietary code lists! There's no limit to the kind of junk we can put in the repository - Java snippets for date-time and UPC validation, and style sheets and formatting routines! And if you're using XML messaging, and can't find a suitable message prototype anywhere in the world, you'll be able to roll your own by using the prefabricated ebXML Core Component library objects. And don't forget about ebXML's Business Process modeling - we'll be able to enforce the proper sequence of long-lived transactions; RosettaNet's PIPs should operate seamlessly under the new ebXML Business Process regime! In short, Bill, you are a witness to a new World Order of B2B Interoperability! If this sounds like hype, then maybe it is: I'm in ebXML Marketing. I tried to get into one of the "real" groups, but just like when they picked teams in elementary school, I wasn't chosen. William J. Kammerer FORESIGHT Corp. 4950 Blazer Memorial Pkwy. Dublin, OH USA 43017-3305 (614) 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "Commerce for a New World"
Powered by eList eXpress LLC