01 April 2003
Untangling the Web
By Ellen Fussell
Weaving structure into business services
The Internet alone can be a maze for manufacturers winding their way through URLs and vendors—looking for help in integrating manufacturing processes. It's a tangled Web of information that needs structure.
That's why a coalition of high-tech suppliers led by IBM, Microsoft, Ariba, and others are hammering away at the details of a Web services standard to help simplify integrating business services (or Web services) using the Internet. It's called the universal description, discovery, and integration (UDDI) project, in motion for several years through the efforts of standards developers and with the backing of more than 300 companies.
"Manufacturing has to work as an integral part of the supply chain planning process," said Roddy Martin, vice president of industry strategy at AMR Research in Boston. Martin said he recognizes the urgency in simplifying the integration process and believes event-based integration between the supply chain and the customer and manufacturer is critical to the agility of manufacturing.
"Software and technology equipment vendors rely on system integration to tie their systems together," he said. This type of integration is crucial in today's demand-driven economy, he said, because "in the past forecast-driven economy, if you make 100 units of a product, you package 100. Now, in the demand-driven scenario, when systems interact with one another on an event basis, you know who's buying your product, so you wait until you've sold 100, and you trigger systems to package 100." They can even be triggered to meet certain customer-driven specifications.
The focus of the UDDI standard is to create an industry effort across platforms and software suppliers to enable systems to talk to one another. "For example, the Internet is often given as the answer to all integration," Martin said. "Yet it's not quite that simple. Systems must be platform independent, not based merely on company systems like Hewlett Packard or Compaq. Complicated systems integration can add massive costs to businesses. That's why standards come into existence—to make open systems a reality so they can connect the Internet to any device," he said. "When a standard is put into place, no matter who you buy your systems from, if they comply to these standards, you'll be able to exchange information between equipment," he said. "That's why this standard is so important."
UDDI binds Web services
UDDI process and new Version 3
UDDI.org is an industry consortium of about 14 companies (IBM, Microsoft, Sun Microsystems, Intel, Compaq, VeriSign, HP, Fujitzu, and others). These companies (in the form of a working group) produce specifications not yet publicly accepted as standards. The working group puts together a candidate draft, then releases it to the community (made up of more than 300 companies) for approval.
UDDI Version 3, released last year, builds on the vision of UDDI, expanding on the foundation of Versions 1 and 2. Version 3 approaches the issue of key generation and the possibility of publishing an entity to another UDDI registry while preserving the key, known as entity promotion. A publisher is permitted to propose a new key for an entity. Users can insert both the key and the entity into the registry. Enhancements include multiregistry topologies, increased security features, improved Web services description language support, a new subscription application programming interface, and core information model advances.
One example would be a service that calculates the cost of shipping a package of a certain size or weight so many miles via a specific carrier. When a business wants to find out which business partners have which services, one option is to call each partner on the phone and try to find the right person to talk with. Another way to solve this problem is an approach that uses a Web services description file on each company's Web site. However, this method depends on a Web crawler that locates each Web site and the location of the services. The problem? This approach lacks a mechanism to ensure consistency in service description formats.
The UDDI specifications offer a solution for wandering Web surfers in that they define a standard way to publish and discover information about Web services. They create an open framework for describing services (such as purchasing and shipping) and integrating business services over the Internet using simple object access protocol (SOAP) and extensible markup language (XML) standards.
The SOAP framework is the product of a collaboration among computer industry giants and small companies that allows one program to invoke service interfaces across the Internet, without sharing a common programming language or distributed object infrastructure. XML and SOAP simplify the integration and interoperability problem through layers. XML provides a cross-platform approach to data encoding and formatting. Built on XML, SOAP defines a simple way to package information for exchange across system boundaries.
The core component of the UDDI project is its business registration, an XML file used to describe a business and its Web services. The information in this registry has three components: white pages (address, contact, and known identifiers), yellow pages (industrial categorization based on standard taxonomies), and green pages (the technical information about services exposed by the business). An XML schema defines the main information model the UDDI registries use.
Developers chose XML because it offers a platform-neutral view of data. UDDI registries promote and help other businesses discover these distributed Web services.
The registry provides practical grounding for the work of developing the specification, said Tom Glover, program manager for Web services standards at IBM in Toronto and managing director for the UDDI business registry. "We didn't want the specification to be some abstract architectural effort," he said.
Glover said to solve problems properly, the working group wanted to create "implementations of the specification and make it available to the public."
Yin and yang
With all this technology backing the Web services protocols, it's still a matter of politics, Martin said. The standardization process is driven by vendors, leaving engineers in a maze when it comes to building their systems to fit the standards.
"The confusing thing for engineers is that there is never one answer," Martin said. "When they're building systems for integration, they can't wait for the standards to be resolved before they put systems together. They need answers to help them meet business needs. So all the political agendas in the industry leave the engineer frustrated."
He said the UDDI standard is "largely driven by the vendor community, which wants to sell systems on the basis of 'my system talks to everyone else's.' But the only way to address that is to get users involved setting these standards." This is difficult, though, Martin said, because companies find it nearly impossible to justify sending users to standards meetings while they're constantly cutting costs.
The standards-writing process is long and involved, he said, and there's no urgency to complete it. If standards users could get involved in the development, "they could articulate their frustrations," he said, "which may spur them on to change priorities to solve real-world users' problems on the integration front."
"There's always a collaboration between the people developing technology and people trying to use it," Glover said. Actually, the people who need standards as well as vendors are driving the development, he said. "People are anxious to start using the technology, and developers are implementing applications based on it," he said. "SOAP, XML, and UDDI are in the eyes of consumers, and companies that need them are pushing for what they need. UDDI is a consortium of mixed users and technology developers. And the industry is coming to grips with most commercial implementations."
Glover said each version of the specification addresses more needs of Web services users, and he agrees users should be on the forefront of development. "It is hard for people to use the material until the standards are created and rolled out," he said.
Martin recommended engineers "stick a stake in the ground" and use the standards as they are today without becoming "so theoretical about the standards [that] they get into a state of indecision," he said. "You have to use the standard pragmatically, but you have to get involved in the standards bodies if you see it won't be able to integrate in the future. Use the standard as it is, but be open to other standards." P