yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Computing
Conference & Expo
November 2-4, 2009 NYC
Register Today and SAVE !..

2008 West
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
Red Hat
The Opening of Virtualization
User Environment Management – The Third Layer of the Desktop
Cloud Computing for Business Agility
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Return on Assests: Bringing Visibility to your SOA Strategy
Managing Hybrid Endpoint Environments
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
How Can AJAX Improve Homeland Security?
Beyond Widgets: What a RIA Platform Should Offer
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
In many cases, the end of the year gives you time to step back and take stock of the last 12 months. This is when many of us take a hard look at what worked and what did not, complete performance reviews, and formulate plans for the coming year. For me, it is all of those things plus a time when I u...
Was the Universal Service Registry a Dream?
A combination of the features in UDDI and RDF may just make the dream come true

It is sometimes beneficial to stop what you're doing, take a look around, and see where you've come from and where you are going. This regrouping is taking place right now across the software industry and is focused on the problem space of Web service description, discovery, and integration. At a high level, this article briefly discusses the progress made to date at solving the problem, describes the benefits and shortcomings of current technology, and presents a vision of the possible future of Web services infrastructure. At its most fundamental level, this article deals with the idea of programmatically locating a Web service that satisfies a specific need and then (programmatically) integrating that service into an application.

SOAP 1.1 (Simple Object Access Protocol) was published as a W3C Note in May 2000 and has since become an industry-standard format for enabling XML-based messaging and remote procedure calls. WSDL 1.1 (Web Services Definition Language) was published as a W3C Note in March 2001 and, despite some ambiguity that has proven a significant hurdle to interoperability, has gained widespread industry support as a mechanism for describing message structure and required transport details. UDDI (Universal Description, Discovery and Integration), the third member (after WSDL and SOAP) of the Web service standards triumvirate, was first published in September 2000.

However, in contrast to its siblings UDDI has not enjoyed the same level of industry acceptance. It is particularly relevant in this article because it is the industry's first attempt to solve the problem of discovery and integration of Web services, in particular as discovery and integration support Web service reuse and sharing. The need to reuse and share services is arguably the most compelling argument for service-oriented architectures (SOAs).

Several factors contributed to UDDI's lackluster start out of the gate.

  • UDDI was a specification that was ahead of its time. It was designed to enable management of large numbers of Web services, but at the time of its release, companies tended to have relatively few Web services to manage. Only now, after four years, are companies reaching the point where the number of Web services justifies the need for a registry to aid in organization and discovery of services.
  • UDDI was originally intended to serve as a Universal Service Registry that would be a panacea for all the problems of discovery and integration with Web services-based applications. This intention has yet to become a reality. Currently, a search of the registries hosted by companies like IBM and Microsoft typically yields a set of services that are unregulated and thus unreliable - services that do not work, or have been posted by companies that no longer exist, and so on. Enterprises are therefore not using these public forums to organize services and develop meaningful business relationships.
  • The UDDI specification has suffered owing to its somewhat esoteric nomenclature, which includes terms such as "tModels" and "BindingTemplates." These terms, while digestible to the infrastructure developers who are building the plumbing, are not as palatable to developers who are writing business-specific applications. These terms negatively affect the usability of UDDI.
As mentioned earlier, this article will also explore how RDF (Resource Description Framework), a developing technology dedicated to defining and maintaining a Web of relationships between different types of information, fills some of the technology holes that have hindered UDDI's ability to fulfill its promise. Although not one of the mainstream Web services specifications, RDF is capable of providing a technology basis for the discovery and utilization of Web services. Specifically, RDF is an XML-based language for representing information about resources and the relationships between the resources intended for representing metadata about these resources. It is one of the building blocks of the W3C's Semantic Web Initiative. Furthermore, OWL (Web Ontology Language; builds on RDF by providing a formal vocabulary to describe the meaning of classes and properties, thus enabling powerful automated reasoning to be performed on RDF data. While still relatively immature, these standards offer interesting alternatives to the traditional Web services landscape and are worthy of investigation within this context.

Combining the capabilities of the current state of UDDI with the capabilities of RDF and OWL promises to resurrect the quest for the Universal Service Registry. The following sections of this article contemplate the features necessary to build what we're going to call, for the purposes of this article, an Ideal Service Registry (ISR) and how the technologies mentioned earlier will play.

The Ideal Service Registry
The following are some of the features that must be implemented to create an Ideal Service Registry (ISR).

Service Description
It must be easy to describe Web services in an ISR

There are many ways one can define a service in UDDI, which makes publishing and using inquiry results quite difficult. A big step toward usability, at least with regard to publishing services, came about with the publication of a technical note entitled "Using WSDL in a UDDI Registry, Version 2.0" (available at that outlines a set of "best practices" for mapping a service description into a UDDI registry. The best practices outlined in this note led to the incorporation of WSDL (an XML-based method of describing the inputs, outputs, and available methods of a Web service) into the UDDI registry. Following these best practices has greatly simplified the process of publishing a Web service into UDDI. Developers simply supply a WSDL URL and a corresponding "BusinessEntity".

There is no standard for mapping a Web service into an RDF registry, although OWL-S has been released and promises to help satisfy this need. A Web service's metadata, such as a description of what it does, its inputs, its outputs, its pre- and post conditions, along with the technical details of how to physically invoke and interact with the service, can all be described in RDF via vocabulary defined by OWL-S. Encoding the details about a service as RDF greatly increases the ability to semantically discover and use Web services. In an order process, for instance, there needs to be a way to know that after calling the ProcessPO Web service one should next call the CheckPOStatus Web service to gather the status of the order.

A UBR (UDDI Business Registry) must have a standard publication API
The publication API of a registry is a common set of commands that are incorporated into client programs to access the facilities of the registry such as adding, deleting, or modifying a registered service. UDDI is solid in this area because it comes with a standard API defined in WSDL that allows a SOAP interface to the publication API. RDF has a proposal for RDF Net API (available from that defines a SOAP interface for adding, updating, or deleting RDF statements, but it is not a standard and is not tuned for use in defining ISR content.

An ISR must support data described in multiple languages
To accommodate multiple languages, the specific language used in information objects must be described by standard language tags. This allows data to be presented to the person utilizing the information in their preferred spoken/written language (as opposed to programming language.) The latest, most comprehensive proposal is RFC 3066bis (available from Both UDDI and RDF support the xml:lang adornment of literal values, which can be set to RFC 3066bis values. This is a very important concept as it moves the registry beyond the general discovery of business logic and actually increases the usefulness of the information resulting from the use of a service.

An ISR must support multiple categorization hierarchies.
In both UDDI and RDF, you can classify an entry using multiple classification hierarchies.

In UDDI, categorization hierarchies are called "taxonomies." Organizations such as UNSPSC (Universal Standard Products and Services Codes) and NAICS (North American Industry Classification System) have created sets of UDDI technical models, known as tModels, which describe an interesting categorization hierarchy. (For more information, see

RDF calls classification hierarchies "ontologies," which are usually defined using OWL. A number of organizations are creating ontologies. One of the most interesting ontologies is OWL-S, whose authors are trying to create an ontology that will fully define all Web services artifacts and that will include defined places and formats for describing information required during the integration phase of using the registry contents. For more information, see the DARPA Agent Markup Language Homepage at

Categorization hierarchies should come with user-understandable, locale-specific names
UDDI tModels contain a name property, which can be decorated with the xml:lang property. OWL does not currently have a standard way to attach display information to an ontology although RDFS (RDF Schema) has some predefined properties such as rdfs:label and rdfs:comment, which can be used for the human readable display name and description. These can also be decorated with the xml:lang tags.

It should be easy to derive relationships among entries in the UBR
Two categorization hierarchies can each contain a category that defines the same type of item, but the two categories are often named differently in the different structures (for example, "cars" as opposed to "automobiles"). This situation can occur, for example, when the categories were created by two different people or organizations. To rationalize such overlaps, one must be able to indicate that a category in one hierarchy is the same as a category in another hierarchy. Users that query one category will then also get corresponding entries in the other category. This is currently not possible in UDDI, but is the reason OWL was created. This capability is KEY to making registries useful as it allows meta-relationships to be defined that will allow programs to dynamically find alternative services when their intended service is unavailable, for example.

There are two significantly different aspects to discovery. One is the ability to discover registries to query. The other is the ability to find the appropriate service in a registry.

The first problem could be addressed by a number of industry-accepted standards and de facto standards such as WS-Discovery ( or zeroconf (, or even the locators that are pluggable into software solutions such as WebMethods Fabric ( After configuring some locator rules on the client, one can find all the available registries that match those rules. The rules could define something like a UDP broadcast, the URL of a well-known server, or parameters for a SOAP call.

After your tool has discovered one or more registries, you should be able to navigate easily through the entries in a registry. There should be at least three navigation methods:

  • Naive walking through all the entries with links among related entries. Optimally, you should be able to infer links so that relationships can grow without having to define every possible link.
  • Pre-built or user-defined query that returns a specific entry.
  • Query that returns a group of entries, where each entry allows you to navigate to entries that relate to any returned entry. This navigation method is analogous to performing a Google search and then following HTML links from one of the pages returned by the search.
ISR queries must have the following attributes:
The ISR must nicely support querying data with text descriptions in different languages Text-matching queries in the current incarnation of UDDI must be written specifically to the desired language of the return text. This means queries cannot be pre-canned. It also means that even simple queries must know that "en", "en_US", "en_UK" and "en_AU" are all English. If a query was written for just one of the flavors of English a complete set of English results would not be returned.

When reading the description of a Web service, the user should not get back all English entries, just the one entry that best matches the user's desired language. This becomes even more complicated when a user speaks two languages. For instance, for someone that reads French and English, a query must contain OR clauses for "fr", "en", "en_US", "en_UK" and "en_AU", but in UDDI there is no way to define that any French dialect is preferable to any English dialect.

There is a nice proposal from Jeremy Carroll of HP and Addison Phillips of webMethods ( on how to solve this problem nicely for RDF query languages. A similar solution could be implemented as an extension to the existing UDDI inquiry API.

The results of the queries should be filtered based on authorization rules
Even within one company, there are services that some users should see and others they should not. Such a security scheme allows administrators or project leads to set up filters that surface "approved" services to the appropriate developers.

UDDI does not yet have a standard data security implementation. Rudimentary security requires you to have a valid user name and password. After a person has been authorized to access a UDDI registry, he/she can then query all information in the registry. UDDI has no mechanism for selectively sharing a certain subset of information with one group of users and another set of information with another group of users. Many UDDI vendors have added proprietary extensions to support security on the data within the UDDI registry, but the security definitions are not portable.

RDF does not have a standard, meaningful security model, and given its roots in the open world of the Web, there does not seem to be widespread interest in solving this problem.

An ISR needs a standard inquiry API
UDDI comes with a WSDL that defines a SOAP interface to the inquiry API. RDF has a proposal for the RDF Net API that defines a SOAP interface for querying RDF statements, but it is not a standard.

An ISR needs a standard query language
UDDI defines a standard query language. RDF has a proposal for an RDF Net API that defines a SOAP interface for querying RDF statements, but it is not a standard. RDF also does not have a standard query language, although the RDF Data Access Working Group is working to define one.

After a service has been discovered, the following features are required to enable you to create a composite application:

An ISR contains a link to the service's WSDL
Either the full contents of the WSDL or a link to the WSDL must be available for a client to interact with the service via the SOAP protocol. This is a common property of UDDI service entries.

OWL-S can be used to define the elements of the WSDL as RDF. In theory, an OWL-S-aware program could read the RDF information and invoke the service without a WSDL. The UBR needs the ability to generate (preferably dynamically) the WSDL from the RDF data in order to support non OWL-S aware SOAP tools that require the WSDL.

A UBR contains information about the prerequisites of each operation
Most operations that are part of a business process have some sort of context, required call order, or other prerequisite. WSDL does not describe prerequisites of a service invocation, which means that information needs to reside in the UBR itself. The OWL-S project is trying to describe this for RDF.

The Future
For all the limitations of UDDI, there is currently no alternative registry standard that can match its maturity or features. RDF has much interesting potential, but is still far from being a viable ISR. A combination RDF and UDDI implementation needs mature implementations of a number of components and interfaces that are currently in their infancy. These include:

  • A standard query language being worked on by the RDF Data Access Working Group (
  • A query language that usably supports data in multiple languages
  • A comprehensive and standardized programming API
  • A Web services (SOAP, WSDL) API
  • A way to find services across multiple registries
UDDI implementations are solving real-world business problems today and UDDI is not standing still. There are proposals to add RDF features to UDDI. Some UDDI vendors have extended their implementations with more granular security controls, merged service namespace across multiple registries, and identification of equivalent services to allow on-the-fly service failover without requiring hardware clustering. There are solutions for the limitations of UDDI, but it remains to be seen if these and future proposals will be accepted, and if the timeline toward workable implementations will stay ahead of the progress in the RDF world.
About Fred Hartman
Fred Hartman is currently a member of the webMethods Advanced Technology
Group and was previously engineering manager for the webMethods
Integration Server Team and an engineer on webMethods? XML technologies.
Fred has held engineering or management positions for Merant, XDB Systems,
Intellution, IBM and EMC Controls, working on database systems,
middleware, process control systems, and advanced signal processing
networks. Mr. Hartman has a bachelors degree in computer science from the
University of Maryland and a masters degree in computer science from the
University of Iowa. He has previously written about music for Dirty
Linen Magazine.

About Harris Reynolds
Harris Reynolds has been working in software development and systems integration for the past eight years. Most recently he was an enterprise architect at Fannie Mae where he was responsible for the development of messaging architecture supporting internal integration. Prior to consulting for Fannie Mae he was a lead engineer for webMethods working on SOA infrastructure and their underlying service registry. He has also completed projects for several large companies including Amkor Technology, BASF, PricewaterhouseCoopers, and Bank of America.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

This article does a good job explaining some of the shortcomings of the UDDI architecture and makes some suggestions for improving the situation. I just don't think that the suggested improvements will fix the problems.

I see two significant problems. When I'm looking for a pair of pants, the inseam can vary by an inch, but I want the waist size to be exact. I need a way to say that, either in the advertisement or in the query. OWL is an excellent framework for someone to build the ability to infer that a "car" is an "automobile". However, neither UDDI as it exists today nor OWL provides a concept of what constitutes a match.

The second significant problem is the absence of a way to specify a business process. Only the most trivial web services consist of just a WSDL request and reply. The interesting ones consist of a "conversation", a series of interactions that often take different paths for different uses of the same service.

A minor point is tModels. They're a wonderful idea, and I wish we'd invented them for e-speak. The problem is that there's no standard for describing what the tModel stands for. Hence, you either know what one means because you've seen it before, or you assign a person to figure it out.

Qualifier: I am one of the co-authors of the Version 2 specification, and I haven't kept up with recent work on the standard.

Your Feedback
Alan Karp wrote: This article does a good job explaining some of the shortcomings of the UDDI architecture and makes some suggestions for improving the situation. I just don't think that the suggested improvements will fix the problems. I see two significant problems. When I'm looking for a pair of pants, the inseam can vary by an inch, but I want the waist size to be exact. I need a way to say that, either in the advertisement or in the query. OWL is an excellent framework for someone to build the ability to infer that a "car" is an "automobile". However, neither UDDI as it exists today nor OWL provides a concept of what constitutes a match. The second significant problem is the absence of a way to specify a business process. Only the most trivial web services consist of just a WSDL request and reply. The interesting ones consist of a "conversation", a series of interactions that often ta...
SOA World Latest Stories
Most DevOps journeys involve several phases of maturity. Research shows that the inflection point where organizations begin to see maximum value is when they implement tight integration deploying their code to their infrastructure. Success at this level is the last barrier to at-will d...
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus ...
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one l...
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is founda...
SYS-CON Events announced today that DatacenterDynamics has been named “Media Sponsor” of SYS-CON's 18th International Cloud Expo, which will take place on June 7–9, 2016, at the Javits Center in New York City, NY. DatacenterDynamics is a brand of DCD Group, a global B2B media and publ...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)!

Advertise on this site! Contact advertising(at)! 201 802-3021

SYS-CON Featured Whitepapers