Hi
all,
I
agree with Governor. I am currently at the Asia ebXML EAC meeting in
Hong Kong. We have seen quite a number of
case
studies in Asia revolving on work that utilises ebXML (e.g. DTTN (Digital
Transportation and Trading Network) in Hong Kong
that
leverages ebMS but not the registry at the moment, e-Taiwan
project, Sony Music in Hong Kong etc.).
Regards,
Dr.Patrick Chan
OASIS
Asia-Pacific Representative
Mobile: +65 96288583
Email:
www.oasis-open.org
-----Original Message-----
From: Governor James
[mailto:]
Sent: Wednesday, June 22, 2005 11:01
PM
To: Daniel Feygin; Jørgen Thyme;
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:]
Sent: 22 June 2005 15:44
To: 'Jørgen Thyme';
Subject: RE: [uddi-dev] ebXML registry
and UDDI comparisons
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
[1] http://www.infravio.com/products.php#x-reg
[2] http://www.sun.com/products/soa/registry/
From: Jørgen Thyme
[mailto:]
Sent: Wednesday, June 22, 2005 4:54
PM
To:
Subject: [uddi-dev] ebXML registry and
UDDI comparisons
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
Globeteam A/S
Gentoftegade 118-120
DK-2820
Gentofte
Tlf.: +45 70
26 29 70
Fax.: +45 70 26 29 80
Mobil: +45 40 90
41 67
