Web services allow you to build applications out of services from service providers. Alternatively, you could build a service and provide it to service requesters to help them build their applications. But the Internet is a huge place. How do you find the services you need to build your app? How do you ensure their quality? If you create a service, how can you get people to use it? Web services need to be published and discovered. Lets first explore what we mean by publishing. If you are a business owner and you're looking for customers what do you do? Before the internet, you had a few options. You could locate your store in a main street so that potential customers could pass by and see what services you were offering. You could put your business in the Yellow Pages of the phone book so that people could find you by the type of service that you offer. You could also take out ads in local media. With the advent of the Internet, there are now more options. Search engines, for example, act as another kind of phone book where people can find your business either by your business name or by the type of services that you offer. But how do you advertise your web service? This is what we call publishing. And the first framework for publishing was UDDI, which stands for Universal Description Discovery and Integration. UDDI was conceived and launched in the year 2000 by three companies. Ariba, Microsoft and IBM. It was intended to be used to specify a universal registry and broker web services using XML and WSDL to structure data about the web services and how they were provided. The UDDI standard is now managed by OASIS, the Organization for the Advancement of Structured Information Standards. A non-profit that also manages a variety of other open standards. Since UDDI is a protocol for publishing and discovery and not a specific implementation, it's not tied to a specific registry. UDDI is a standard for both the discovery and publishing aspects of web services. It is not a necessary component of implementing web services. If you already know which web services you would like to use and how to bind to them, then you don't need a discovery mechanism. Conversely, if you develop a service for use with a few specific applications and combined your service to them directly, you do not need to publish your web service. However, UDDI is a useful standard for bringing service requester and service providers together. Let's see how it works. This diagram shows the general overview of how UDDI is used. Service providers first publish themselves and their services to a UDD registry. Once they are published, potential service requesters can search the registry. They do this by searching elements of the WSDL description or other descriptions of the service or service providers. Once the service requester finds a service they want to use, they can bind to it using the WSDL descriptions. After the service requester is bound to the service by generating the code for the necessary messaging patterns, the service requester can invoke the service. Publishing registers information about the service with a UDDI registry including information about the service provider, the service itself and various technical descriptions of the service. The UDDI registry assigns the service a uniform resource identifier or URI which is a unique reference that is used to invoke the service. The information encapsulated in the UDDI standard is contained in three categories: White Pages, Yellow Pages and Green Pages. White pages, like the real White Pages of a phone book, is where you can find basic information about the business. In real White Pages, this may just be the business name and phone number. But the White Pages in UDDI can contain a lot more information than that. At the very least, there will be the business name, a short description and contact information. Another common piece of information found here is a unique business identification number. Yellow Pages, just like the Yellow Pages in a phone book, contain information about the service or industry that the business is in. This may include more detailed industry information like hierarchical information about the industry. This will be similar to looking up a business in the Yellow Pages, except now you can search for pizza which is under delivery, which is in turn under food. In our example, exchange rates are a subset of currency services etcetera. Green Pages contain the technical details of how to use the service. We will discuss this a bit more in a moment. The information encapsulated in UDDI falls into four data structures. Business entity contains information about the business, roughly corresponding to the White Pages. Business service describes the services that the business is offering. One business can have many services but a service can only have one business that owns it. This roughly corresponds to the Yellow Pages of the UDDI. Binding template gives the necessary information needed to invoke the service in question. Binding refers to the service requester generating the necessary communication to invoke the service. So, the binding template contains a description of this interface. One service may actually have different interfaces. So, it's possible for one business service to have more than one binding template. tModel gives more detailed information about the service. This could include references to the protocols used by the service or detailed technical specifications of the service. The tModel is a flexible data structure that can represent any abstract concept. And tModels can be nested to provide various meanings. For web services, one of these tModels will reference a WSDL description of the service. The binding template and tModels that it references together form the Green Page of UDDI entry. These are the technical descriptions of the service. UDDI specifies web services for publishing so service providers publish to a registry through SOP messages. Service providers can add, delete or modify entries in the registry. Some examples of operations are save_business, save_service, save_binding, save_tModel, as well as delete commands for these elements. UDDI also specifies web services for discovery accessed by SOP messages. Commands to search for services include find_business, find_service, find_binding and find_tModel. You can then request information using commands like get_businessdetail, get_servicedetail etcetera. The would be service requester uses these commands to find services and get information about the service interface. Once a service requester has information about the service interface, it can dynamically bind to it. In other words, it can generate the necessary code to access the interface for the service. Like publishing, this detail is often hidden from the developer. Instead, developers often use web portals to search for services. So far, we've talked about binding as if it's a highly dynamic runtime activity. This is technically possible but think about what it means for a developer. If an application developer doesn't know in advance what errors might occur or what exceptions may be generated, then it's difficult or impossible to create robust code. If a web service is being provided by a business that will charge for its use, the businesses will have to have contracts or agreements which are generally handled by humans rather than programmatically. For these and other reasons, service discovery is usually a design time activity. The binding itself can still be automated although even this can be challenging since it would require the interface description to be completely unambiguous. In reality, discovery is usually performed by a human developer while binding is at least monitored and tested by a human developer. UDDI is one of the foundational standards of web services along with SOP and WSDL. It's a very useful mechanism with which service requesters and service providers can find each other and interact. UDDI allows service providers to publish their services and service requesters to search these published results to discover the service that they need. Bringing service providers and service requesters together is an essential part of creating an effective service ecosystem. That's true whether it's UDDI or some other mechanism to publish and discover services.
