[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-dev] ebXML registry and UDDI comparisons
|
An awful lot of functionality that gets
shipped is never used. That is the software business – like you say “consumer
empowerment sales tactic”. The built in support for UDDI has been
there for a while, and adoption is still more limited than you would expect. My
word processor has built in support for French characters and spelling but that
doesn’t mean I use the functions. I could not agree more with this statement:
“I do believe
that ebXML Registry has a defensible niche in B2B collaboration in specific
verticals. Whether there is enough of a vendor ecosystem and innovation around
ebXML to sustain it is another matter.” Healthcare and
automotive seem to be areas with the most current adoption. You might also look
at geos – ebXML is a bit hotter in Asia Pac. From:
Daniel Feygin [mailto:feygin@unitspace.com] Jørgen, I personally do
not see any new ebXML registries coming or a compelling reason for them to
come. The only viable ebXML Registry implementations I know of (Infravio [1]
and Sun [2]) support both ebXML and UDDI, which I take as a consumer
empowerment sales tactic. In my admittedly biased view, the momentum is
certainly on the UDDI side with all SOA-enabling infrastructure
(message/protocol intermediation brokers, development and management
tools) shipping with built-in support for UDDI only. Because registry is not so
much a feature of an architecture as it is its platform supporting specific
capabilities, its value is proportional to the number of systems that leverage
it. There simply isn't enough of a market opportunity or a viable go-to-market
strategy for an alternative universal registry standard at this time. Although SOA
transformation is what drives a lot of infrastructure spending these days, I do
believe that ebXML Registry has a defensible niche in B2B collaboration in
specific verticals. Whether there is enough of a vendor ecosystem and
innovation around ebXML to sustain it is another matter. Somewhat tangential
to your inquiry, I may note that if you are accessing the registry from within
a Java platform, you may use JAXR (Java API for XML Registries), which is
designed to support both ebXML and UDDI information models and API's
through a common client interface. However it is unlikely that you will be able
to run the same code against both ebXML and UDDI registries without change. Regards, Daniel [2] http://www.sun.com/products/soa/registry/ From:
Jørgen Thyme [mailto:jt@globeteam.com] I have looked at the specs for v3 for the ebXML registry.
Although the information model looks more detailed than in UDDI my immediate
thinking was that adding my taxonomies in UDDI I can achieve a lot. And there
are several implementations of UDDI. What are your thoughts? Will vendors of UDDI registries add
ebXML registry functionality to their existing products? Or will there be a
complete new set of registry products coming? Best regards / Med
venlig hilsen Jørgen Thyme Development Team
Mobil: +45 40 90 41 67 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]