William Kammerer wrote:
>
> Since ebXML eventually caved in to... oops!! ... "merged with" SOAP - see
"ebXML Integrates SOAP Into Messaging Services Specification," at
> http://www.ebxml.org/news/pr_20010222.htm -  it wouldn't be too surprising
to see the same thing happen with UDDI.

Let's get this technically correct.  ebXML didn't "merge" with anyone.  If
anything, they adopted SOAP as their messaging service specification.  Why
go out and invent another messaging specification if there's one on the
market that works perfectly fine.  SOAP is platform-agnostic so I'm not sure
what the problem is with ebXML moving the effort forward a little faster.

Now let's talk about UDDI.  Since UDDI is built using SOAP as it's messaging
specification and it provides a common registry function for registering
services why not move this train down the tracks a little faster.  UDDI is
another working standard that has been implemented.  As such, shouldn't
ebXML consider it for their inventory and if it doesn't completely meet
their needs then extend UDDI accordingly?

>
> Normally I would have to be dragged kicking and screaming to a dump like
Vienna - after all, I live in the cultural mecca of the West here in
> Columbus, Ohio. But I'm probably going to make the sacrifice  and get to
the ebXML meeting there in May so I can have a front row seat
> if Captain ebXML tangles with the UDDI Avenger.  See http://www.ebxml.at/.

The problem with standards bodies these days is that they all think their
way is the best and have no desire to collaborate with other groups where it
makes sense.  Applause to ebXML for cutting through the red tape and keeping
the process moving.  Just because a standard comes from an industry
consortium doesn't taint the standard.  Heck, if you look at the committees
at some of these standards bodies they are essentially industry consortiums
in their own right.

While we're drawing the Napster parallels, let's consider the EDI world and
these efforts.  If you really look at it, the trad EDIers can be somewhat
likened to RIAA.  The process works, transactions are fulfilled, what's the
problem?  And, by the way, these rogue process are nothing but a bunch of
young kids just wanting things free.  In reality, the process stinks (it
takes forever to find a service and establish it - forever being relative to
I-net speed), transactions are hard to fulfill (especially if you're a mom
and pop shop), and Houston, we have a problem that needs fixing.  Either
trad EDI embrace some new methods or get out of the way of progress.
----------------------------------------------------------------------------
-
Randy Bear
USAA - I/T Architecture
Phone: (210) 913-2142   Email: [EMAIL PROTECTED]
...the opinions expressed are those of the author and not those of USAA...

=======================================================================
To contact the list owner:  mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/

Reply via email to