OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: ebxml and uddi

Bryan Rasmussen wrote:
> 
> HI
> 
> Going through the enormous amounts of documentation on these
technologies
> there is often discussion of them as being complementary, does anyone
have
> any case studies of real world implementation that show them actually
> complementing each other (I've seen the notes on finding ebxml services
via
> uddi etc.)

I have written an article on this topic titled "UDDI and ebXML Registry:
A Co-Existence Paradigm" that was published on WebServices.org in April
2003[1] - I hope you find it useful. For real-world case studies, the
closest that I can offer is what I described in my September 2003 ebXML
Forum article titled "UDDI and ebXML Registry: A Three-Tier Vision[2]",
in which I describe how UDDI and ebXML Registry can indeed be utilized
in a complementary fashion, on multiple levels (tiers). In that article
I also describe a pilot project for Tier 1, "Reachthrough Capability". 

> Also it seems that ebXML can do everything that UDDI can and more
(except be
> a lot easier to implement than ebXML), is this the case? 

Not sure about which is easier to implement (would depend on the
product, of course) - but in essence, one may consider ebXML Registry to
be a "superset" of UDDI in ways that are described in [1].

> Is this just an
> accidental effect of trying to provide for all business processes? I'm
> asking because it was requested that I do some checking on the possible
> future  feasibility of moving our UDDI repository to an ebXML one, from
my
> viewpoint and tastes this does not seem to be a worthwhile thing to do 
It would depend on your business requirements - i.e. do you have a need
to register/store/maintain/discover the artifacts that ebXML Registry
enables you to store? (which is really anything you'd like, as ebXML
Registry's information model is abstract and designed for any type of
content). More specifically, do you need to store (vs. simply register)
artifacts in a repository? UDDI does not have a repository capability,
but ebXML Registry does. Also, how does the product landscape look for
UDDI? How does it look for ebXML Registry? These are only some of the
factors involved in such a decision.

There is an open-source ebXML Registry SourceForge project called
"ebxmlrr" that you can find at [3]. Farrukh Najmi of Sun Microsystems is
the leader for this project, and he is on this listserv.

(I
> would almost always rather use the smaller technology designed for a
> specific domain, rather than the more general that accidentally covers
the
> domain). It seems more reasonable to build an ebXML repository for
> particular business processes and have those findable via UDDI.

That scenario is certainly possible, given the capabilities of the 2
specifications. It all comes down to your business needs, including
whether or not you can/want to procure 2 products instead of one.

Hope this helps.

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World

[1] http://www.webservices.org/index.php/article/articleview/984/1/24/
[2] http://www.ebxmlforum.org/articles/ebFor_20030824.html
[3] http://www.freebxml.org/
 
> The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The
> list archives are at http://lists.ebxml.org/archives/ebxml-dev/
> To subscribe or unsubscribe from this list use the subscription manager:
> <http://www.oasis-open.org/mlmanage/>

-- 
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton

The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The
list archives are at http://lists.ebxml.org/archives/ebxml-dev/
To subscribe or unsubscribe from this list use the subscription manager: 
<http://www.oasis-open.org/mlmanage/>

<<attachment: winmail.dat>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]