SOA (Service Oriented Architecture) is a relatively new paradigm that has evolved through many iterations over the years. SOA revolves around the concept of Web services, which are transforming the way IT departments function today. Web services refers to a modular, self-contained piece of code with a well-defined functionality that you can access across the network. SOA's key components are a service provider, a service consumer and a service registry. UDDI (Universal Description, Discovery and Integration) is an XML-based standard that enables users to create registries where businesses can register their contact information, the services they offer and technical information about them (refer to "UDDI Spec TC" in Resources). Service requestors can search the registry, find a service they need, and interact with that service. Web services are primarily used over the Internet, and a UDDI registry factors out the Web service's location constraint. At once, a UDDI registry can offer a collection of services performing a particular task, letting users pick and choose the one that best suits their particular situation. UDDI has become the de-facto standard for registering services. Its advantages are twofold: first, organizations have a trivial registry for all its services regardless of geographic location, business units and departments; and second, they can consolidate system assets, saving on business cost and time.
Web services are generally self-contained units with an abstract business interface independent of the underlying implementation; the development process needs to be comfortable and it must be easy for the client to access.. From a server perspective, we should be able to create any custom Web service and expose the WSDL (the metadata description for a Web service) to the client, who can connect to it accordingly. The architecture needs a mechanism for accepting and sharing the amendments or changes in a standard and easy manner. The UDDI is central to this architecture; hence, it will suffice. But UDDI still lacks vital information, such as security, and has no strategy for tracking business service changes.
Businesses today are more dynamic than ever before and should be able to adapt to a situation quickly. This implies that business processes should be agile. When a Web service implements a business process, that process could have multiple versions available simultaneously. While older versions may be declared obsolete, they are usually still maintained. For example, a financial business has a Web solution in place that displays the interests for a particular year and month. It needs different versions to keep the formula for changed business trends in the business service. The enterprise architecture needs a configuration management solution that allows both the server and client to be free of version-control hassles. You don't need to explicitly inform every consumer about a version change.
Time and again standards are created to provide a better, simpler protocol for stakeholders to participate in organization-level business integration. With service providers using UDDI ubiquitously, we look at extending UDDI's capabilities; first, by sharing each service's security details so that the client knows how to access the service with the right protocol and policies; and second, by extending the UDDI as a best fit for configuration management of services.
This article explains the need to share security details and the architecture design with the outside world. We then discuss the need for UDDI to bear the business quality process key process area (KPA). We will also propose a technical solution using the current UDDI specification to help manage the enterprise-wide service versioning.
UDDI is an important part of the SOA philosophy, and has a place in the famous Publish -- Find -- Bind triangle. Service providers publish their services in the UDDI, where service requestors can find those services and bind to them using the specified mechanism. UDDI's logical structure is divided into three categories: white pages, yellow pages and green pages. White pages store information about a business and its contact information; yellow pages store information about the services that business offers; and green pages store all the technical information about a service. UDDI is divided into four main data structures:
A BusinessEntity denotes a business that offers a service, which is specified as a BusinessService. The BindingTemplate states how the service requestor can bind to that service. The TModel represents a technical model to which the service conforms. This makes a hierarchical structure for every registry entry; there are also other elements and sub-elements that represent other details, like categorizations and dates.
Proof of Concept: “Enriching UDDI PoC
We'll look closely at different solutions using one of the leading J2EE application servers, IBM WebSphere Application Server v6. This server showcases the multi-version and multi-security policy service interaction using the UDDI node registry. The business tier is a .NET server where we deploy all Web services.
To test the security policy sharing theory, the service provider creates services with two different security policies. To check versioning support, we create two services with different implementations and another service with a different signature or interface altogether. These services are located in a different box in the .NET platform.
At the service registry level, we register all the business services and configure them according to the mechanism discussed in the paper.
At the service consumer end, we categorize the client components into two sections. We build the first set of client components so that the client understands the policy files and equips them to suit the security implementation that the service producer configures. We then use a set of client components to access the different service versions. The mechanism will have exception handling management to adjust itself with the ever-changing versions, and ultimately, access the Web service with less difficulty and effort. We'll build the client stub and custom components on a Java platform of a different box than the ones on which the service registry and service producer are located.
Sharing a security policy
Currently, the UDDI does not represent Web service security. From a business perspective, security in Web services communication is important because most business processes and transactions occur over an insecure Internet. Another constraint is that Web service transactions are more process-to-process oriented rather than human-to-process; therefore, a dynamic security scheme is even more pertinent. With the growing use of Web services, participants in a Web service environment are bound to increase exponentially; hence, we need a scalable and adaptive security mechanism. Standards, like WS-Security, Extensible Access Control Markup Language (XACML) and Security Assertion Markup Language (SAML), talk about a security implementation on the service layer but offer no efficient way to share the security information to ever-changing interaction scenarios. This is where UDDI can help.
To secure a Web service, you usually use security tokens, like username tokens, XML tokens, binary tokens, Kerberos tokens, security certificates like X.509 certificates, and signatures and encryption. The focus is on securing the SOAP message communication between the two parties. Standards like WS-Security and WS-SecurityPolicy (see Resources) provide mechanisms for implementing security for Web services. WS-Security lets you enhance the SOAP message to send security information. WS-SecurityPolicy, the WS-Policy framework provided by industry leaders like IBM, Microsoft, and Verisign, provides a general-purpose model and corresponding syntax to describe and communicate a Web service's policies. WS-Policy defines a base set of constructs that other Web service specifications can use and extend to describe a broad range of service requirements, preferences and capabilities. WS-SecurityPolicy defines a way in which Web services can express their security-related requirements and constraints. A WS-SecurityPolicy file associated with a Web service asserts how you secure messages with respect to token types, cryptographic algorithms and mechanisms used. Using transport-level security is part of the design and allows for evolution over time. The security policy file informs the service requestor of the service's security credentials so that he or she can access it in the specified way. Security is different so we need to decouple it with the actual business service description.
Motivation for a security policy
In general, integrated applications or B2B systems have manual agreements of the security policy. Both applications are bound to this agreement so they update dependent clients in the same way. The producer used to build the service provides a set of security measures and then the client follows the suite to access the service. In the long run, sustaining the agreed-upon accord is difficult. It leads to:
- Manual errors resulting from not intimating partners
- Additional cost of implementing processes over it
- Tendency to have second thoughts to amend the security policy at the service end
Approach to a solution
When businesses list their services in a UDDI registry, the registry stores the WSDL URL in the TModel and the service endpoint in the service's binding template. Service consumers can look up the registry (see "Enriching UDDI proof of concept")and access the endpoint and the WSDL URL. In the same way, we can have a provision in the registry to store the service's security policy files; this means that service requestors know how they can adapt to the service's security policy.
The WS-SecurityPolicy file is associated with a Web service that specifies the security policy that that particular Web service follows. The service requestor must adapt to this policy in his request to invoke the Web service. The UDDI registry needs a mechanism so that the user can look up a Web service's security policy; this is similar to a WSDL lookup. We suggest that the UDDI registry store the URL of the security policy file just as it stores the WSDL URL in the TModel. In the TModel, you store the WSDL URL in the OverviewURL. Since you can have any number of OverviewURLs, you can also store the security policy file in a second OverviewURL in the same TModel. Figure 1 shows the two OverviewURLs in the same TModel in the IBM WebSphere App Server 6 Test UDDI node.
Figure 1. Overview document
You can programmatically retrieve the policy file just as you would WSDL, and you can use it during runtime from a client while invoking the Web service. The client needs to be able to address the security policy as the policy file proposes it.
This gives both parties the flexibility to design the security policy with their particular business needs in mind. You don't have to have a service-level agreement (SLA) defined to share information promptly. The process is pre-built in the architecture so both parties seamlessly connect. Communicating parties share a set of common assumptions about specific policies or protocols through flexible and dynamic exchange of endpoint information in tightly coupled environments.
Following a granular approach, users and clients can share the WSDL file and its respective policy file through UDDI, as Figure 2 shows.
Figure 2. UDDI presence in different phases
This way the business is not only sharing the WSDL but also the security policy.
What we've achieved
We've taken the current UDDI version and created a security management solution. We propose that the upcoming version of UDDI incorporate this change.
UDDI plays a configuration management role
Many approaches have surfaced over the years around versioning Web services. One approach, WS-Versioning, defines constructs for notifying the user of any version-related information changes. WS-Addressing is a collaborative effort among BEA, IBM, Microsoft, SAP, and Sun Microsystems (see Resources) that defines two constructs to convey information in an interoperable manner. Transport protocols and messaging systems typically provide it. These constructs normalize this underlying information into a uniform format that you can process independently of transport or application. The two constructs are endpoint references and message information headers. WS-Addressing also enhances the WS-Versioning standard to address the versioning mechanism.
According to the UDDI v3 specification, "Subscription provides clients, known as subscribers, with the ability to register their interest in receiving information concerning changes made in a UDDI registry. These changes can be scoped based on preferences provided with the request." So UDDI does update the user of information changes but does not show version information.
Motivation for a configuration management solution
A Web service is bound to change with time; for example, a Web service that calculates income tax may change every year. Therefore, you must consider when creating the service's registry. Users should be aware of the latest Web service version and should be able to access an older version whenever they want. Figure 1 depicts this.
Let's use a real-world example to understand the need for versioning. A finance company pays interest on money invested with it. It uses a universally accepted algorithm, or a specific algorithm only the company follows, to calculate the amount of interest incurred. Let's assume the amount is calculated per month and is based on two values: a base value that is always constant and a floating value that can change each month (again based on some algorithm). The user can calculate the interest value for a month by using the company's Web service on the Internet. If the user wants to check the interest for the current month he will use the latest Web service version. If he wants to check what interests he received for previous month(s) he will have to check the older Web service version(s) since the rate of interest will have changed due to the floating value. Now how does a company advertise all Web service versions clearly in a UDDI registry so that the user always gets the correct version? As you can see, version support is an important feature for businesses and end users. Although UDDI is a major standard for Web services and has considerable industry backing, it still does not sufficiently support security and Web service versioning.
As Web services evolve, they naturally become more complex in order to support enterprise-level solutions. With additional information, the Web service becomes a heavyweight component that carries the burden of all information, which can be distributed onto a tier that registers Web services.
These are potential drawbacks around Web service standards:
- The Web service standards make the message construct complex and heavy.
- The Web service diversifies into the service management mechanics rather than handling the granular business logic.
Approach to a solution
We know that in the UDDI data structure, a BusinessEntity contains one or more BusinessService elements, which contain BindingTemplates, which in turn contain TModels. The BusinessEntity, BusinessService and TModel contain IdentifierBag and CategoryBag elements. IdentifierBags identify specific services or businesses while CategoryBags organize UDDI entries in a structured way. You categorize them based on universally accepted classification schemes like UNSPSC, NAICS, ISO 3166 and so on. We put in place a mapping between BindingTemplates and TModels by harnessing the IdentifierBag and/or the CategoryBag. As we are using WebSphere Application Server v6, we can use the CategoryBag and add categorization information through the administration GUI.
Figure 3. Technical model details of WebSphere Application Server v6
We can add versioning information in the CategoryBag using the keyname "Version" and key value as the version number. Since a BindingTemplate already links to a particular BusinessService, we don't need to explicitly map them. However, with UDDI v3, which has CategoryBags in BindingTemplates, we can explicitly map BindingTemplates and BusinessServices by putting the service name in the BindingTemplate's CategoryBag.
Figure 4. Binding details of the WebSphere Application Server v6 admin screen
Now that a TModel links to a BindingTemplate, all we need is the service consumer ((see "Enriching UDDI proof of concept")) to say which service version he wants to use. We can then search TModels (and hence, WSDL URLs) based on version numbers. During runtime, the service consumers can retrieve TModels associated with a particular BindingTemplate and then search for a particular version number in their CategoryBags.
What we've achieved
UDDI plays one of the Capability Maturity Model's (CMM) KPA roles of configuration management in an enterprise solution. Unlike the WS-* standards, UDDI can have multiple versions of Web service descriptions in the repository. This not only allows the service provider to broadcast the latest version but also provides the flexibility to toggle between the different Web service versions, depending on the business requirements. Here are some factors to note:
- Extended UDDI is the description and discovery of the active Web service and its history repository.
- Under the same business entity and business service, the producer can cater to varied consumers with different versions of the same Web service flavor.
- The producer can serve the same Web service flavor to varied customers with isolated security policies as mentioned in the previous section.
- Above all, the UDDI helps the business manage quality configuration management.
The implementation strategy we executed was a UDDI v3 workaround. UDDI does not support versioning registered services. Enterprise-level applications mandate UDDI to own Web service configuration management. This in turn mandates that the next version of UDDI support this elementary approach, which will help architect the SOA-based enterprise application in a complete and quality-savvy approach.
UDDI pushes policy and version information to consumers on the fly. UDDI suffices as a centralized and federated governance and management solution. The execution here was a workaround on the existing standards and platform. You can accomplish this if and only if you incorporate the features into existing UDDI standards.
As we have seen, security and versioning are important aspects in any Web service implementation, and as a business grows, security and versioning issues become more prominent and difficult to ignore. We learned that using an existing and accepted standard to address these issues qualifies as a feasible solution, and demonstrated how we can use UDDI to make Web service clients security- and version-aware without major enterprise-wide changes. By making this small tweak to the UDDI specification, it can be the ideal solution.
- Review the OASIS "UDDI Spec TC," UDDI Spec Technical Committee Draft by Luc Clement, Andrew Hately, Claus von Riegen, Tony Rogers (October 19, 2004)
- Read the Web Services Security Policy Language (WS-SecurityPolicy) specification by Giovanni Della-Libera, et al. (IBM, Microsoft, Verisign, July, 2005)
- Learn more about Web Services Addressing by Robin Cover (Cover Pages, December, 2005)
Get products and technologies
- Read "UDDI4J: Matchmaking for Web Services" by Doug Tidwell (IBM developerworks, 2001)
- Read "UDDI Inadequate for SOA" by Peter Abrahams (IT-director.com, September, 2005)
- Review the developer.com article "Versioning of Web Services: An UDDI Subscription-Based Approach" by Aravilli Srinivasa Rao
- Read "Dynamic Discovery and Invocation of Web Services" by Damian Hagge (IBM developerworks, August, 2001)