Have you noticed there really arent a lot of exciting new thingshappening in the corporate IT world? The economy has put a damperon everything. What may well be the last Comdex was poorlyattended. Microsoft and the Justice Department finally reached anagreement, and no one cares. There seems to be a lot of hype aboutTablet PCs (yawn) and Blade Servers (double yawn) and wireless. Iread this morning more than 500,000 IT jobs simply disappeared inthe last year. The pundits are suggesting we technical types needto rush out and get some more education so we can find a real job.Poorly run IT departments are perceived as just another serviceprovider that can easily be replaced or outsourced (see Ouch!below).

None of this has stopped the big guys from trying to get moremoney from us. The major hardware/software/solution companies aretrying their best to get us to migrate all of our software to Webservices platforms. This stuff (Web services) has been around for acouple of years now, and while it is very cool technology, wehavent seen a massive wave of adoptions. Maybe thats because we areall well satisfied with our second-generation Web servers andreally dont want to spend the resources to upgrade again. Maybe weare concerned about security issues. And then maybe we just dontbelieve the underlying standards are well enough established.

StandardsWhat Standards?

First, lets offer a broad definition of Web services as modularapplications that expose a standards-based interface accessibleusing current Web technologies (HTTP over TCP/IP). For example, youcould offer a claims submission application that could be utilizedover the Internet as long as the user knew where the interfaceexisted and how it could be accessed. Web services are based oncertain standards so any application attempting to access apublished service will know how to interact with that service. Theprimary standards on which Web services are built are XML, SOAP,WSDL, and UDDI. The first three are specified by the W3C (WorldWide Web Consortium). XML (eXtensible Markup Language) is a taggedmeta-language that is now the standard for nonproprietary dataexchange among systems. SOAP (Simple Object Access Protocol) was aMicrosoft standard for packaging messages (it is often referred toas a message envelope). It describes an XML-based protocol forexchanging messages. WSDL (Web Services Description Language) wasbrewed up by Microsoft and IBM. It is an XML format for describingnetwork services as a set of endpoints operating on messagescontaining either document-oriented or procedure-orientedinformation. So here we have three standards, all used to implementWeb services, all vendor independent, and all owned by the W3C. Thelatter two were created specifically for use in Web services. Thatcombination pretty much says to me these standards generally willbe used and accepted by anyone wishing to publish a Web service.The fourth standard, UDDI (Uniform Description Discovery andIntegration), is a little different. UDDI did not become a part ofthe W3C standards. It is maintained by OASIS (Organization for theAdvancement of Structured Information Standards), which is anot-for-profit, global consortium that drives the development,convergence, and adoption of e-business standards. It was foundedin 1993 under the name SGML Open as a consortium of vendors andusers devoted to developing guidelines for interoperability amongproducts that support the Standard Generalized Markup Language(SGML). When XML gained the limelight, the consortium changed itsname.

UDDI

UDDI provides a cross-platform, cross-industry standard forpublishing Web services. In laymans terms it provides a publicregistry that says here I am ready for e-commerce and heres how todo it. The initial hype claimed companies engaged in e-commercewould publish their data, and the world would beat a path to their(virtual) doorstep. The scenario ran like this: My company makesball bearings that hundreds of other manufacturing firms can use. Iannounce my readiness to sell my bearings using UDDI and provide aWeb service that potential customers can use to purchase bearings.Not only do I increase sales, I have streamlined the process. Greatidea, 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 businessesto register information about their companies on a public registry.UDDI then goes the extra step by providing an API whereby those Webservices can be automatically queried. Three goals of UDDI areto:

Allow a business to publish itself to the registry.

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

Share information about how a user may interact with thatbusiness, 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 theregistry using a Web browser. The interface is not specified inUDDI and is left to the implementer, so theres no guarantee everyportal to the business registry will be free. The business registryprovides three conceptual components:

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

The yellow pages, which define the particular business lines andservices that a firm provides. Here you can use industry-standardcodes like NAIC and UN/SPSC as well as describe the geographicaldistribution of a firms services. The yellow pages, orbusinessService, provide descriptive information about a particularfamily of business services. Each businessService structure has asingle businessEntity parent. It is an optional registry entry thatmay contain one logical child data structure or more of a singlebusinessEntity. There are only four elements in this datastructure.

The green pages, which provide the technical information aboutthe Web services a company offers. Using a standard format, abusiness is able to publish the specific methods it has implementedfor e-commerce and provide links to those services. The green pagesprovide a lot of technical informationonly some of which isinteresting, and that bit is named the tModel. The tModel providesa means to describe all information about a Web service necessaryto interoperate with the service. The tModel describes how aservice behaves, what conventions it follows, and what standards orspecifications it is compliant with. The tModel provides thecomplete and necessary technical specifications for a Webapplication.

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 toa 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 beyondthe standard phone book data. Most businesses are reluctant topublish specific program interface information to a public datastore. I know I would be. It appears the initial expectations forUDDI were overblown. It isnt realistic to expect an e-commerceapplication to search the registries to find a hitherto unknownbusiness partner and then automatically conduct a businesstransaction with that partner. There are also security issues. Idoubt you would want a full description of your program interfacein a publicly accessible registry. That doesnt mean UDDI doesnthave a place in Web services . . . just a little different placethan originally thought.

Secure UDDI?

Most of the apparent objections to UDDI can be readily solved bymoving the registry behind a firewall or another secure area. Largemultinational corporations can use UDDI on the firewall-protectedcorporate intranet for use by different divisions of theorganization. Relatively secure Web services can be implemented byplacing the registry and the application in a secured DMZ for useby business partners. General-use Web services such as commonutility functions or basic calculators can be left hanging on theInternet with a published UDDI.

Insurance?

Is there a way we can apply UDDI and Web services in theinsurance industry? Sure. I can think of a number of scenarios. Onethat comes to mind involves carriers that arent dependent on acaptive producer force. Independent agents deal with many differentcarriers and many different proprietary systems. Imagine a genericpolicy application system that could query a UDDI database andadapt itself to the specified interface. Different carriers wouldprovide a UDDI registry behind a secure extranet that could only beaccessed by authorized agents. The agent would enter data as wellas any company-specific information. The client application canquery the UDDI registry using standard SOAP messaging and determinethe appropriate interface. An XML data stream can then betransmitted to the carriers Web application over HTTPS (SecureSocket Layer). This would solve any number of current problems. Arecent survey determined that independent agents felt most hamperedby having to use multiple proprietary pieces of software toadminister policies from different carriers. In this model, oneproperly designed bit of agency software can access multiplecarriers Web services by adopting currently available Web servicestandards.

Are we ready for that kind of cooperation? Do we achieve acertain amount of security in forcing independents to use oursoftware? I dont know. I do know there is a limited market outthere, and if we can provide the technology to grab even a smalladditional share of that market, then we are really doing our jobsas information professionals. Web services are here to stay. Youcan provide Web service applications without publishing anyinformation, or you can judiciously use UDDI to publish enoughinformation to make your Web services more readily available. Yourchoice.

Ouch!

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