UDDI

UDDI provides a cross-platform, cross-industry standard for publishing Web services. In laymans terms it provides a public registry that says here I am ready for e-commerce and heres how to do it. The initial hype claimed companies engaged in e-commerce would publish their data, and the world would beat a path to their (virtual) doorstep. The scenario ran like this: My company makes ball bearings that hundreds of other manufacturing firms can use. I announce my readiness to sell my bearings using UDDI and provide a Web service that potential customers can use to purchase bearings. Not only do I increase sales, I have streamlined the process. Great idea, but we arent selling bearings, and as near as I can tell, that particular scenario hasnt panned out.

UDDI is designed for registering or discovering Web services. Using well-established Internet protocols, UDDI allows businesses to register information about their companies on a public registry. UDDI then goes the extra step by providing an API whereby those Web services can be automatically queried. Three goals of UDDI are to:

Allow a business to publish itself to the registry.

Allow users to discover a business with which they may want to do business.

Share information about how a user may interact with that business, using online Web services.

The most publicly visible part of UDDI is the business registry. IBM, Microsoft, SAP, Ariba, and others provide free access to the registry using a Web browser. The interface is not specified in UDDI and is left to the implementer, so theres no guarantee every portal to the business registry will be free. The business registry provides three conceptual components:

The white pages, which include the most general and basic business information such as address, contact names and numbers, and known business identifiers. The white pages, or businessEntity, provide core information about the party publishing the information. This data structure contains all known information about a business or entity. It is the top-level data structure in the XML schema.

The yellow pages, which define the particular business lines and services that a firm provides. Here you can use industry-standard codes like NAIC and UN/SPSC as well as describe the geographical distribution of a firms services. The yellow pages, or businessService, provide descriptive information about a particular family of business services. Each businessService structure has a single businessEntity parent. It is an optional registry entry that may contain one logical child data structure or more of a single businessEntity. There are only four elements in this data structure.

The green pages, which provide the technical information about the Web services a company offers. Using a standard format, a business is able to publish the specific methods it has implemented for e-commerce and provide links to those services. The green pages provide a lot of technical informationonly some of which is interesting, and that bit is named the tModel. The tModel provides a means to describe all information about a Web service necessary to interoperate with the service. The tModel describes how a service behaves, what conventions it follows, and what standards or specifications it is compliant with. The tModel provides the complete and necessary technical specifications for a Web application.

Is Anyone Using It?

Wonderful, but is anyone using UDDI to implement Web services? As you browse the existing UDDI registries (here are some links to a couple of public UDDI registries: http://wsindex.org/pages/ UDDI/Registeries/; http://directory. google.com/Top/Computers/Programming/Internet/Web_Services/UDDI/_Registeries/), you find there really isnt a lot of information out there beyond the standard phone book data. Most businesses are reluctant to publish specific program interface information to a public data store. I know I would be. It appears the initial expectations for UDDI were overblown. It isnt realistic to expect an e-commerce application to search the registries to find a hitherto unknown business partner and then automatically conduct a business transaction with that partner. There are also security issues. I doubt you would want a full description of your program interface in a publicly accessible registry. That doesnt mean UDDI doesnt have a place in Web services . . . just a little different place than originally thought.

Secure UDDI?

Most of the apparent objections to UDDI can be readily solved by moving the registry behind a firewall or another secure area. Large multinational corporations can use UDDI on the firewall-protected corporate intranet for use by different divisions of the organization. Relatively secure Web services can be implemented by placing the registry and the application in a secured DMZ for use by business partners. General-use Web services such as common utility functions or basic calculators can be left hanging on the Internet with a published UDDI.

Insurance?

Is there a way we can apply UDDI and Web services in the insurance industry? Sure. I can think of a number of scenarios. One that comes to mind involves carriers that arent dependent on a captive producer force. Independent agents deal with many different carriers and many different proprietary systems. Imagine a generic policy application system that could query a UDDI database and adapt itself to the specified interface. Different carriers would provide a UDDI registry behind a secure extranet that could only be accessed by authorized agents. The agent would enter data as well as any company-specific information. The client application can query the UDDI registry using standard SOAP messaging and determine the appropriate interface. An XML data stream can then be transmitted to the carriers Web application over HTTPS (Secure Socket Layer). This would solve any number of current problems. A recent survey determined that independent agents felt most hampered by having to use multiple proprietary pieces of software to administer policies from different carriers. In this model, one properly designed bit of agency software can access multiple carriers Web services by adopting currently available Web service standards.

Are we ready for that kind of cooperation? Do we achieve a certain amount of security in forcing independents to use our software? I dont know. I do know there is a limited market out there, and if we can provide the technology to grab even a small additional share of that market, then we are really doing our jobs as information professionals. Web services are here to stay. You can provide Web service applications without publishing any information, or you can judiciously use UDDI to publish enough information to make your Web services more readily available. Your choice.

Ouch!

Maybe we are to blame if we in IT are perceived as dispensable. If you see your function as nothing more than improving existing work processes, then shame on you. Like it or not, the PC and Internet revolution has changed the way consumers will spend their hard-earned dollars. You notice I didnt say the revolution changed the way we do businessbecause in many cases it hasnt. Most businesses have used technology to streamline process and offer new sales channels, but they havent really changed their business model. The really successful guys will be the ones who adapt their current business model to satisfy consumer needs in a wired world (and I dont mean just selling your current product online).