In-Depth

The elements of Web services

What technologies support Web services and what is ready for prime time? The answers can be confusing. Like any new technology, most of the current action surrounding Web services is just talk and experimentation. The basic building blocks have been laid, but questions abound about what additional pieces need to fall into place.

Nonetheless, some companies are not waiting for all the ''i's'' to be dotted and the ''t's'' to be crossed. Galileo International, a travel service subsidiary of Cendant Corp. headquartered in Parsippany, N.J., has been looking for ways to broaden its corporate travel services, providing corporate clients greater leeway to plan trips, book reservations and gain flexible reporting capabilities without having to ''dumb'' the application down using conventional HTML Web pages. It wanted to provide capabilities, like wizards, that are taken for granted in desktop apps. But the initial version of its app, which required Microsoft-based clients, would have had limited usefulness in the real world. Web services proved the only viable deployment alternative.

''Web services are effective at two levels,'' said Glen Zwart, principal engineer at Galileo. ''First you expose the host system, then you add pieces of logic that make the host system useful.'' But, he conceded, Web services as an emerging technology provides some speed bumps. ''We need a real security model,'' said Zwart, noting that for now, his development team has to use homegrown logic for essential functions such as authenticating users and authorizing access.

According to Steven VanRoekel, director of Web services technical marketing at Microsoft, Web services promise to restore some of the functionality taken away when the Web dumbed down classic GUI clients. ''The GUI introduced ideas like polymorphism, where every app understood commands like copy, paste and print. Web services could give much of that back,'' he said.

Web services could also provide the technology building blocks for deconstructing apps into a series of functions or services that can be accessed using RPC-like transactions or loosely coupled, asynchronous transactions completed with intermediary brokers. Using brokers, Web service requests do not have to know how or where services are deployed -- a significant change from conventional client/server or distributed computing architectures.

What does it take to make this happen? What are the building blocks, and what technologies are ready for production today? At first glance, the answers seem simple. An introductory demo by XMethods Inc. at the XML and Web services One conferences brought a half-dozen vendors together to stage a rudimentary procurement app using the basic building blocks of Web services: SOAP messages, WSDL service definitions and UDDI services directories. In the demo, the mechanics of passing service requests, lookups and responses was the easy part, said Tony Hong, president of XMethods, San Jose, Calif., who directed the project.

''In the real world,'' said Hong, ''the heavy lifting will happen where trading partners agree on business ground rules.''

If only it were that easy. With Web services, however, much of the transaction services that are taken for granted with conventional software and OS environments have to be reinvented and implemented in an environment where the parties, apps and underlying systems involved in processing an application might not be known until runtime -- if they are known at all. Suddenly, concepts like two-phase commit sound quaint, because the transaction might require more intermediaries than a conventional transaction processing application. And if the service request travels outside the firewall, security requirements for authentication, authorization and confidentiality will snowball. Furthermore, the challenge of figuring out how to manage, test and maintain service levels in loosely coupled environments -- where almost anything goes -- could prove challenging, to say the least.

Starting points
The original premise behind Web services is deceptively simple. It starts with XML, a text-based, Unicode language that accomplishes for structured data what ASCII did for plain text: It provides a neutral format that has become practically ubiquitous. Web services add standard interfaces for communicating structured messages over standard protocols like HTTP, defining business services and providing rudimentary directories of available services.

Web services are also designed to be flexible. They can be structured as conventional, synchronous RPC-style transactions where data types and request/response methods are strictly defined. Or they can be deployed as asynchronous, complex transactions that involve multiple parties, loosely structured document exchanges or just about anything in between.

Web services start with SOAP, the predominant Web services messaging format. Used for sending XML-based messages over protocols like HTTP, SOAP's popularity is due to its simplicity and flexibility. Its headers provide an envelope that describes the type of content in the message, directions on how to process the message and the sender's identity. Content may be structured or unstructured, in whatever manner the sender chooses.

The brass ring of Web services is the Web Services Definition Language (WSDL), the mechanism for specifying how a service operates. WSDL consists of a structured XML document that specifies endpoints (the operations that are performed) and the messages that define the subject of the data. More importantly, WSDL specifies the bindings (where the services are to be deployed on the network) and provides the flexibility for deploying services in RPC or loosely coupled forms. Better yet, by making binding a separate header, WSDL definitions are extremely portable and reusable.

In effect, WSDL furnishes the ground rules for conducting business using Web services. Some observers say getting WSDL straight could be half the battle in setting up business interactions using Web services.

''The fact that the WSDL documents were defined in advance meant that 80% of our effort was defining things like what the physical interfaces would look like and how to handle faults,'' recalled Sam Ruby, a specialist for IBM, who participated in the XMethods demo.

Then there is Universal Description, Discovery and Integration (UDDI), a mechanism by which Web services can be registered and have their interfaces discovered. Providing a rudimentary registry of Web services, WSDL names the service provider, categorizes the service, and includes technical descriptions of the service being made available. Currently viewed as an optional function for Web services, UDDI is required when the interfaces and specifics of the service provider and the actual service to be performed are not known in advance. Ultimately, the real value of UDDI may be its ability to provide an intermediary layer that eliminates the need for Web service requests to know anything about the services they are requesting -- a capability that could be especially useful if the identity of the provider or the physical location of the service on the network changes.

UDDI is not the only registry proposal out there. E-business XML (ebXML), a broad framework for defining e-business collaborations, includes proposals for registries, messaging and other functions. ''It's more than a UDDI registry, and not a rival to SOAP,'' noted Patrick Gannon, president of the standards group OASIS. Although it is endorsed by special interest groups like Covisint (an automotive industry B2B exchange), ACORD (an insurance industry organization) and HR-XML (focused on human resources transactions), questions remain about the level of ebXML's market acceptance.

''While ebXML started with enormous customer feedback, it has not progressed as well as UDDI, where real products have come out,'' claimed Siva Darivemula, market manager, WebSphere strategic business initiatives at IBM, and the former president of UDDI.org.

Order in the court
In the real world, transactions need to be secure, manageable and reliable. And to make Web services useful for businesses, there needs to be a way to codify business rules to build the Web services equivalent of applications. These requirements are far from unique to Web services.

But they are likely to be far more complex. ''One of our biggest challenges for Web services today is how to authenticate the cardholder seamlessly, which requires directories to talk to directories,'' said Simon Pugh, vice president of infrastructure, standards and alliances for credit-card network MasterCard.

With Web services, the security and business logic management functions traditionally performed at the operating system, application or database levels must now be managed in the free space environment of the Internet. The challenge is analogous to state management in the Web's early days, where responsibility was assumed by application server middleware based on Java, Microsoft or other technology.

The difference this time is that the standards cannot be driven by the Java Community Process or Microsoft alone, because Web services are supposed to be multivendor. Compounding the challenge is the possibility that, with Web services, the application logic processing and data access authorizations might be handled on a chain of servers across different organizations and platforms. While some transactions might be conventional RPCs, others may require longer-lived processes that cannot be managed by simple concepts of state maintenance.

Not surprisingly, the Web services standards land rush is currently centered in the gray areas of transaction management, process flow, coordination and security. Of these functions, security standards are the furthest along because consensus is gathering around two key standards: Security Assertion Markup Language (SAML) and WS-Security.

Battening down the hatches
SAML provides the authorization and authentication functions required for many Web services security functions, and it enables capabilities like single sign-on. With Version 1.0 finalized last spring, SAML provides digitally signed tokens to the recipient of a Web services request. These tokens can be restricted in a variety of ways. For example, they can carry firm expiration times and selective authorizations for different portions of the message -- features that may be useful given the Web's latency and the fact that responses to a Web services request may require participation from more than one party.

Complementing SAML is WS-Security, a framework that does not actually enforce security policies per se, but specifies what security technologies (such as Kerberos or PKI) are to be employed to perform those functions. OASIS is just beginning to tackle this specification, a job that could prove challenging.

''We will probably limit ourselves to the basics, not on the semantics of how to perform security,'' noted Hal Lockhart, a member of the OASIS joint security committee and W3C liaison. ''This technical committee won't be the end-all for Web services security; it's a first step.''

Like any work in progress, Web services security has plenty of rough edges. Proposals in many areas, like encryption and authorization, still have critical gaps. Current XML Encryption and XML Signature proposals continue to lack specs that prevent corruption of encrypted data and signatures as they pass through the various parsers used by each party in a multi-party transaction.

Then there are issues like what levels of security standards should cover. For example, there is an ongoing debate regarding whether security policy headers, like those spelled out in the proposed XACML standard, are necessary, and whether the concept must also cover content ownership and access -- a key concern for publishers who routinely deal with intellectual property rights issues in their businesses.

''We need a clear distinction because overlapping standards could mean chaos,'' said Chet Ensign, a spokesperson for the online publisher Lexis/Nexis, who mentioned the need to clarify intellectual property rights at a recent Web services security forum organized by OASIS and the W3C.

According to OASIS' Lockhart, questions of security policy and digital rights management might be too hot to handle for now. ''We are unsure what will become part of the long-term agenda,'' he said. ''The current thinking is that digital rights management might be too specific for the types of documents exchanged via Web services.''

Where's the beef?
The heart of any business application is the business logic --  the business rules, interactions and workflows that represent how users work with the system and how business processes are automated. If applications require the processing of transactions, it is necessary to take protective measures that ensure that completed transactions are acknowledged and interrupted transactions are rolled back. In scenarios where several business processes are integrated, a traffic cop or broker is necessary to ensure that the interactions follow existing business rules and priorities.

In conventional applications, all of these services are typically managed within the application, database, or a third-party integration broker or messaging system that performs these tasks using its own proprietary technologies. However, the open-air nature of Web services rules out the use of proprietary technologies, especially when multiple players, organizations and platforms are involved.

The flexibility of Web services makes business process integration and coordination more complex than typical inside-the-firewall EAI scenarios. While Web services could include conventional RPCs against known systems, it could also involve more complex, longer-duration, asynchronous transactions that must factor in the latencies of the Internet as well as scenarios involving multiple parties whose identities might not be known until runtime or later. In these scenarios, conventional RPC mechanisms, such as two-phase commits, are no longer adequate.

Furthermore, measures such as ensuring authenticity, acknowledgement, rollbacks and completion grow more critical when they are conducted outside the protective cocoons of conventional transaction systems.

For example, a procurement request might involve not only a buyer and seller, but third parties like credit and transportation providers. Additionally, the transaction may or may not be instantaneous. And even if the original service request sounds simple, providing assurance that the service request was answered, in an environment where multiple organizations inside and outside the firewall are involved, might trigger a series of transactions that could be interrupted if one link in the chain -- such as the ability to get financing, delivery on the requested date or even the transmission of an acknowledgement -- is broken.

Among the questions to be answered: Can the identities of all parties be verified, and are they authorized to make or process the service requests? If any link in the chain is broken, are there business rules specifying alternate options and do transactions have to be rolled back? If they have to be rolled back, to what point? And is there any way to perform all these assurances in a non-proprietary way so that  everyone involved can decipher the service requests and responses?

A number of organizations whose memberships overlap, have jumped into the fray, proposing a wide array of complementary and competing standards proposals. It starts with tags for defining services supporting conventional RPC synchronous transactions and longer-duration asynchronous transactions. That is complemented with an array of proposals addressing business processes, including process modeling that offers tags for defining business processes; workflow languages that chain related activities into business processes; and choreography, a function that addresses the integration brokering role traditionally performed by EAI tools and messaging middleware inside the firewall.

There are numerous competing proposals for process definition languages, including BPML, developed by BPMI.org, and XML Process Definition Language (XPDL), sponsored by the Workflow Management Coalition. Then there are languages specifying business collaboration, such as the Business Transaction Protocol (BTP), directed by OASIS, and ebXML BPSS, managed by UN/Cefact. And there are proposals for choreographing all these processes, such as Web services Choreography Interface (WSCI), which the W3C has agreed to consider.

Amid all the chatter, IBM, Microsoft and BEA unilaterally trumped their own ''better'' solution, the awkwardly named Business Process Execution Language For Web Services (BPEL4WS). This framework contains three proposed specs, including Business Process Execution Language (BPEL), a workflow language that converges earlier proposals from IBM and Microsoft; WS-Transaction, which defines services for conventional RPC and long-running transactions; and WS-Coordination, which provides the choreography.

''With Microsoft and IBM, we saw partners that could broaden the appeal and technical input of the work we had been doing,'' said John Kiger, director of Web services marketing at BEA, which co-developed BTP, BPML and WSCI.

Many groups with rival proposals have ramped up the spin control, claiming the IBM/Microsoft/BEA proposal validates their original bright ideas.

''BPEL is very close to BPML,'' said Ismael Ghalimi, chairman of BPMI.org and cofounder of workflow software vendor Intalio Inc., San Mateo, Calif., who claims that while the syntaxes are different, the underlying technology and structures are the same. ''Future extensions of BPEL are already covered by BPML,'' he added.

Countered BEA's Kiger, ''We did not publish any blueprints of where to go with BPEL.''

Who's on first?
The question to be answered is whether the standards process is open and democratic, or being hijacked by back-room deals that drive the public agenda. MasterCard's Pugh voiced concern that while the WS-Security proposals are a small step forward, he still perceives it 'as too much of an IBM/Microsoft initiative.'

Responded OASIS' Gannon:''SAML [a complementary proposal] emerged as a result of 32 vendors who submitted their own ideas and converged them.''

And given the necessity for standards groups rather than vendor consortia to drive the technology framework, figuring out who is responsible for what is almost as challenging as deciphering all the competing and complementary standards proposals themselves.

While the W3C might seem the logical place for standards-making, in reality, a growing array of technology organizations are laying claim to approving standards, defining testbeds or functioning as moral intermediaries. A sampling of the groups entering the fray besides the W3C include OASIS, a group first formed to promote SGML (the grandfather of HTML and XML); the Object Management Group (OMG), which seeks to ensure that proposed standards are compatible with its Model-Driven Architecture initiative; the Open Applications Group, which focuses on application integration and B2B collaboration; and the Distributed Management Task Force, which is lobbying for Web services standards covering remote systems administration.

The lure of Web services is the promise of interoperability and the flexibility of the services-oriented architecture. Given that technology development is still in its infancy, the wish lists for standards remain diverse, ranging from digital access rights for intellectual property to vertical industry-specific tags and meta-directory standards. Nonetheless, reality may start seeping in.

''We don't expect the W3C or other standards organizations to solve 100% of our requirements,'' admitted Stephen Whitlock, security architect for The Boeing Company, Chicago, at a recent OASIS/W3C security forum.

So much of the standards debate pinpoints functionality that may be ahead of current user demand. ''The workflow and choreography proposals aren't relevant to us today,'' noted Galileo's Zwart. ''Maybe, when we go down the road and push 'travel-related' products such as golf packages, it would be very nice to have a transaction model to coordinate booking among multiple suppliers,'' he said.

Not that Galileo's business is not complicated today. For example, the permutations of booking a single round-trip ticket between two cities can number up to 10 to the 30th power. But, conceded Zwart, do not confuse convoluted fare structures with the actual booking process itself.

''Today, the travel industry uses relatively simple, straightforward transactions,'' he said.

Most   Popular