Welcome!

Microservices Expo Authors: Elizabeth White, Liz McMillan, Pat Romanski, Mehdi Daoudi, Steve Wilson

Related Topics: Microservices Expo

Microservices Expo: Article

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; www.w3.org/TR/owl-features) 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 www.oasis-open.org) 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 www.w3.org) 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 http://inter-locale.com). 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 http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm.)

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 www.daml.org.

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.

Discovery
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 (http://msdn.microsoft.com) or zeroconf (www.zeroconf.org), or even the locators that are pluggable into software solutions such as WebMethods Fabric (www.Webmethods.com). 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 (http://inter-locale.com/whitepaper/iswc2004.pdf) 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.

Integration
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 (www.w3.com)
  • 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.

More Stories By 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.

More Stories By 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.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Alan Karp 12/14/04 07:43:29 PM EST

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.

@MicroservicesExpo Stories
In his session at @DevOpsSummit at 20th Cloud Expo, Kelly Looney, director of DevOps consulting for Skytap, showed how an incremental approach to introducing containers into complex, distributed applications results in modernization with less risk and more reward. He also shared the story of how Skytap used Docker to get out of the business of managing infrastructure, and into the business of delivering innovation and business value. Attendees learned how up-front planning allows for a clean sep...
In IT, we sometimes coin terms for things before we know exactly what they are and how they’ll be used. The resulting terms may capture a common set of aspirations and goals – as “cloud” did broadly for on-demand, self-service, and flexible computing. But such a term can also lump together diverse and even competing practices, technologies, and priorities to the point where important distinctions are glossed over and lost.
Enterprise architects are increasingly adopting multi-cloud strategies as they seek to utilize existing data center assets, leverage the advantages of cloud computing and avoid cloud vendor lock-in. This requires a globally aware traffic management strategy that can monitor infrastructure health across data centers and end-user experience globally, while responding to control changes and system specification at the speed of today’s DevOps teams. In his session at 20th Cloud Expo, Josh Gray, Chie...
"At the keynote this morning we spoke about the value proposition of Nutanix, of having a DevOps culture and a mindset, and the business outcomes of achieving agility and scale, which everybody here is trying to accomplish," noted Mark Lavi, DevOps Solution Architect at Nutanix, in this SYS-CON.tv interview at @DevOpsSummit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
We have already established the importance of APIs in today’s digital world (read about it here). With APIs playing such an important role in keeping us connected, it’s necessary to maintain the API’s performance as well as availability. There are multiple aspects to consider when monitoring APIs, from integration to performance issues, therefore a general monitoring strategy that only accounts for up-time is not ideal.
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
When you focus on a journey from up-close, you look at your own technical and cultural history and how you changed it for the benefit of the customer. This was our starting point: too many integration issues, 13 SWP days and very long cycles. It was evident that in this fast-paced industry we could no longer afford this reality. We needed something that would take us beyond reducing the development lifecycles, CI and Agile methodologies. We made a fundamental difference, even changed our culture...
As many know, the first generation of Cloud Management Platform (CMP) solutions were designed for managing virtual infrastructure (IaaS) and traditional applications. But that’s no longer enough to satisfy evolving and complex business requirements. In his session at 21st Cloud Expo, Scott Davis, Embotics CTO, will explore how next-generation CMPs ensure organizations can manage cloud-native and microservice-based application architectures, while also facilitating agile DevOps methodology. He wi...
Docker is sweeping across startups and enterprises alike, changing the way we build and ship applications. It's the most prominent and widely known software container platform, and it's particularly useful for eliminating common challenges when collaborating on code (like the "it works on my machine" phenomenon that most devs know all too well). With Docker, you can run and manage apps side-by-side - in isolated containers - resulting in better compute density. It's something that many developer...
These days, change is the only constant. In order to adapt and thrive in an ever-advancing and sometimes chaotic workforce, companies must leverage intelligent tools to streamline operations. While we're only at the dawn of machine intelligence, using a workflow manager will benefit your company in both the short and long term. Think: reduced errors, improved efficiency and more empowered employees-and that's just the start. Here are five other reasons workflow automation is leading a revolution...
We have Continuous Integration and we have Continuous Deployment, but what’s continuous across all of what we do is people. Even when tasks are automated, someone wrote the automation. So, Jayne Groll evangelizes about Continuous Everyone. Jayne is the CEO of the DevOps Institute and the author of Agile Service Management Guide. She talked about Continuous Everyone at the 2016 All Day DevOps conference. She describes it as "about people, culture, and collaboration mapped into your value streams....
Cloud adoption is often driven by a desire to increase efficiency, boost agility and save money. All too often, however, the reality involves unpredictable cost spikes and lack of oversight due to resource limitations. In his session at 20th Cloud Expo, Joe Kinsella, CTO and Founder of CloudHealth Technologies, tackled the question: “How do you build a fully optimized cloud?” He will examine: Why TCO is critical to achieving cloud success – and why attendees should be thinking holistically ab...
Docker is on a roll. In the last few years, this container management service has become immensely popular in development, especially given the great fit with agile-based projects and continuous delivery. In this article, I want to take a brief look at how you can use Docker to accelerate and streamline the software development lifecycle (SDLC) process.
We define Hybrid IT as a management approach in which organizations create a workload-centric and value-driven integrated technology stack that may include legacy infrastructure, web-scale architectures, private cloud implementations along with public cloud platforms ranging from Infrastructure-as-a-Service to Software-as-a-Service.
Did you know that you can develop for mainframes in Java? Or that the testing and deployment can be automated across mobile to mainframe? In his session and demo at @DevOpsSummit at 21st Cloud Expo, Dana Boudreau, a Senior Director at CA Technologies, will discuss how increasingly teams are developing with agile methodologies, using modern development environments, and automating testing and deployments, mobile to mainframe.
As DevOps methodologies expand their reach across the enterprise, organizations face the daunting challenge of adapting related cloud strategies to ensure optimal alignment, from managing complexity to ensuring proper governance. How can culture, automation, legacy apps and even budget be reexamined to enable this ongoing shift within the modern software factory?
While some vendors scramble to create and sell you a fancy solution for monitoring your spanking new Amazon Lambdas, hear how you can do it on the cheap using just built-in Java APIs yourself. By exploiting a little-known fact that Lambdas aren’t exactly single-threaded, you can effectively identify hot spots in your serverless code. In his session at @DevOpsSummit at 21st Cloud Expo, Dave Martin, Product owner at CA Technologies, will give a live demonstration and code walkthrough, showing how ...
There are several reasons why businesses migrate their operations to the cloud. Scalability and price are among the most important factors determining this transition. Unlike legacy systems, cloud based businesses can scale on demand. The database and applications in the cloud are not rendered simply from one server located in your headquarters, but is instead distributed across several servers across the world. Such CDNs also bring about greater control in times of uncertainty. A database hack ...
@DevOpsSummit at Cloud Expo taking place Oct 31 - Nov 2, 2017, at the Santa Clara Convention Center, Santa Clara, CA, is co-located with the 21st International Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is ...
API Security is complex! Vendors like Forum Systems, IBM, CA and Axway have invested almost 2 decades of engineering effort and significant capital in building API Security stacks to lockdown APIs. The API Security stack diagram shown below is a building block for rapidly locking down APIs. The four fundamental pillars of API Security - SSL, Identity, Content Validation and deployment architecture - are discussed in detail below.