Re: ebXML will end up being too expensive for small business

["William J. Kammerer" <wkammerer@foresightcorp.com>]

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"