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.
tx
Mike
Clark
-----Original Message-----
From: Thomas B Winans
[mailto:]
Sent: 02 September 2004
15:09
To: Faisal Khan
Cc:
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
