By “the” UDDI registry, may I assume that
you are referring to the UDDI Business Registry (UBR) – the so-called Public
UDDI Registry? I don’t think Thomas was talking about using the public UBR.
At some point in the future I think the public
UBR will play an important role in the public internet as a registry for public
services, but that certainly isn’t the place where UDDI has the most value
today. Today people should be registering public standards (tModels)
in the UBR, but I have seen very few actual services registered in the UBR.
UDDI’s current role is as a private
registry within an organization, used for SOA management, governance, and
development. Once your efforts with web services passes the prototype and
piloting stages, and you have multiple groups within
your organization developing web services, the situation becomes too complex
for developers to find out about services by word of mouth. You need a standard
mechanism to advertise and discover services.
You could implement some type of ad hoc
means to register services – I’ve seen companies use a Wiki
to do so – but there’s a limit to the scalability of this type of registry. You
can also use a proprietary asset library or registry. A number of companies
have told me that they want more functionality than UDDI provides, so the
proprietary solutions from Blue titan and Infravio
look somewhat appealing. But my recommendation is to stick with the standard.
The key advantage to using UDDI is that it
is the industry standard, and therefore most tools support it. Most web
services development tools provide UDDI browsers, and some also provide UDDI
registration wizards. Many of the web services management (WSM) products also
integrate with UDDI. UDDI is becoming a key component of the web service
provisioning process, and many WSM vendors are using UDDI for SLA
management, too. I know of a number of companies that use UDDI as a key
component in the SOA governance process. They don’t permit developers to deploy
a web service without first registering it in UDDI, and they implement the
governance processes through that registration process.
- Anne
From: Mike Clark
[mailto:mikec@lucin.com]
Sent: Saturday, September 04, 2004
3:35 AM
To: Thomas B Winans; Faisal Khan
Cc: uddi-dev@lists.oasis-open.org
Subject: RE: [uddi-dev] Benefits
of UDDI
I might add that the UDDI registry also
now gets fed into www.salcentral.com.
As Tom mentioned
other vendors or third party companies can
use this information and extend as required.
-----Original Message-----
From: Thomas B Winans
[mailto:tom.winans@concentrum.com]
Sent: 02 September 2004 15:09
To: Faisal Khan
Cc: uddi-dev@lists.oasis-open.org
Subject: Re: [uddi-dev] Benefits
of UDDI
Greetings --
I assume that your requirements eventually call for your web services to be
published for general consumption. While it is probably easier at present to
use a custom directory service, the benefits that I see to sticking with UDDI
(and making it a robust offering from the specification all the way to either a
commercial or open source product -- so I hope vendors are reading this)
include the following:
• Interoperability. This is
undoubtedly the most important of Web Service architectural goals.
• Open and standards-based software
solutions. Standards provide the necessary guidelines for constructing new
software solutions and encapsulating legacy systems with common syntax, making
each system more integrate-able – thereby improving the lifecycle manageability
of these systems, and reducing their cost of ownership.
• Standardized service interfaces
that are clearly traceable to key enterprise tasks (as opposed to data entities
only) and that encapsulate proprietary implementation details at the same time.
For decades we have seen business applications constructed to manage data
entities only, or that incorporate a set of business processes that are, at
best, minimally configurable by users. Their APIs are published at a data
entity level, complicating the task of building application integrations by
making it necessary to understand specifics of application data models and
hardwired business processes. Proper incorporation of Web Services into
business software infrastructure will result in exposing a catalog of business
services that can be reused with at least significantly less regard for their
underlying implementations. Easy reuse of business services engenders business
agility: multiple implementations of a single business service is avoided,
making rapid composition and automation of business processes using these
services straightforward, and the result more easily maintainable.
• Extended business reach. Web
services enable business partners to relate in a more automated way today as a
function of using common syntax and network protocols. Assuming partners
establish a common semantic model for interacting at the business process
level, they can automate their interactions to a greater degree than in the
past – thereby enabling business process automation beyond traditional
enterprise boundaries. The ability to scale beyond traditional boundaries will
be fundamental to making enterprise efforts to globalize successful.
Certainly these benefits have been promised before by other
paradigms and technologies. Object technologies promised reuse. Component and
messaging technologies promised the benefits of standards and the ability to
scale beyond traditional enterprise boundaries. The difference between past
attempts to realize these benefits with other technologies and current attempts
based upon Web Services primarily is that there is broad acceptance of XML,
http, SOAP and WSDL as fundamental standards (de facto or otherwise) for Web
Service-based interaction. And equally fundamental as an emerging standard to
widespread adoption and use of Web Services is UDDI.
Registry technologies are commonplace today. Microsoft has Active Directory and
J2EE has JNDI, both of which leverage LDAP (light weight directory access
protocol). LDAP derives from X.500, and X.500 registries are complex to design,
install and maintain over time. Many IT executives who have the mandate to
demonstrably ensure that corporate technology money is wisely spent also have
many lessons learned relating to registry technologies. CIO’s having experience
with registries are likely to object when Web Services infrastructure vendors
introduce yet another registry to corporate infrastructure – even if they buy
into the long-term benefits of Web Services. They may endorse taking a very
deliberate approach toward Web Service adoption that equates to developing with
Web Services using no registry, and instead, hard-coding connections into the
endpoints, or building small custom registries on top of existing
infrastructure to determine if what they are being told about Web Service
technologies and service-oriented architectures is the same old vendor-serving
hyperbole they’ve seen and heard before wrapped neatly in XML-laden buzzwords.
Such caution is prudent because there is more than enough Web Services-related
hyperbole to go around. Service oriented architecture development is complex,
and an IT organization should be prudent in order for development and operations
to learn the boundaries of Web Service enabled applications with specific
emphasis on UDDI. It is my belief that UDDI, an integral component to a Web
Services-oriented architecture, is not part of the hyperbole. BUT at the same
time, I am certainly aware of how far UDDI needs to go to be robust, and to be
more than a directory. UDDI is advertised by the UDDI committee as a registry.
Unfortunately, UDDI does not really live up to the "registry" part
beyond basic directory services that a human would consume. Basic
categorization of UDDI seems always to have been a bit imprecise (is it a
registry, or is it a yellow pages directory?). The use of the word
"registry" is all over in UDDI docs, so I will take the UDDI spec
team's original intention to be to create a registry. Given that, there are
tremendous deficiencies with UDDI "products" today (either commercial
or free). Notable holes in these products can be seen in the operational and
administration areas. Basic command line UDDI tools are missing. Operational
use cases (such as one that describing how UDDI v3 keys are properly
distributed and managed) are simply not mentioned in the specs, consequently
they are not provisioned by any products (even those used by the public
registry operators). Use cases are not considered for dynamic inquiry/bind --
the use cases the UDDI spec committee considers can be scoped to be
directory-related use cases only ... and then they cannot be considered a
complete basis of same.
With all of that said, I would recommend starting with a UDDI registry and
using the UDDI standards (as they currently are) to make UDDI go as far as they
can go rather than starting with a proprietary registry and expecting to evolve
toward a standard. There are open source versions of UDDI (v2, I am unaware of
v3 as open source) such as Novell's if you'd like to control a UDDI instance,
or there are registries like Systinet's or IBM's with which you can experiment
on line (these are v3). Making UDDI work is, in my view, fundamental to the
success of Web Services at large. Without being overly dramatic, I think there
is much at stake.
Tom Winans
On Sep 2, 2004, at 6:45 AM, Faisal Khan wrote:
Hi All,
Currently i am using simple mysql database for searching my services
(as they are very small in number). Can any body suggest what benefits
i can get if i use UDDI registry for publishing and discovering
webservices.
Thanks in advance for your replies.
regards
Faisal