Other Web Services Initiatives

SOAP, BizTalk, and ebXML are all fairly well-established initiatives, but the emergence of the Web Services movement has inspired a host of new ones. The Web Services label originally applied to the use of three specific protocols: SOAP; Web Services Description Language (WSDL); and Universal Description, Discovery, and Integration (UDDI). Together, they formed a stack very similar to that found in distributed object computing. Both have a wire protocol, an interface description language, and a discovery mechanism. This similarity naturally made Web Services as originally conceived better suited to remote interface architectures. However, as technologists and developers considered how to connect applications over the Internet, the Web Services movement came to embrace both remote interface and business messaging architectures.

Basic Web Services Stack

Initially, the goal of the basic Web Services stack was to lower the barrier to connecting applications using the Internet. Typically, you would decide to connect at the application level rather than the business process level for two reasons. In the first case, you might be attempting to integrate several enterprise applications to support a particular business goal. Bringing together accounting, manufacturing, and shipping applications for automated order processing is one example.

In the second case, you might be trying to assemble a complete Web application from a group of more modular services. Using third-party express shipping price and local sales tax calculators to improve an online shopping application is one example. Developers have a great deal of experience from the world of distributed objects that reveals where the difficulties in these tasks lie. By using XML at ever-higher levels in the software stack, they hope to minimize these barriers.

There is a common misconception that Web Services can eliminate the custom programming associated with application integration. In most cases, this is simply not possible, but Web Services can greatly reduce the amount of programming. The first point of leverage comes in providing a common communications model. Using only one model to program increases productivity. Moreover, once developers can assume they have a common model, they can invest in more sophisticated tools to support this model.

As discussed in Chapter 5, most of the major application server vendors include utilities for automatically publishing application components as Web Services and for generating the client code to access them. Some also provide graphical modeling and lightweight scripting environments for assembling multiple Web Services into a higher-level application. Even with these features, the realities of software integration mean that most applications will still require some amount of traditional programming.

The protocols in the basic stack are very straightforward. As with the other initiatives covered so far, we use SOAP as the standardized plumbing. Unfortunately, as we saw in the SOAP example, using SOAP in a remote interface application requires knowledge of the target application. Developers need to use the correct tags to format the function call and know how to interpret the tags from the return value.

WSDL provides a standardized way for an application to publish its SOAP-accessible functions. It serves the same purpose as an interface definition language for a distributed object system. While the particular syntax is complicated, the basic concepts are relatively standard. A coherent Web Service in WSDL is called a portType and has a group of related functions called operations. So a "Foo Company Shipping" port type may have "New Shipment," "Change Shipment," and "Status" operations. Each operation has input and output messages, whose formats are defined using XML Schema.

The set of operations for a WSDL port type define the logical interface for the service. WSDL also provides for the definition of the communication interfaces. It uses the concept of a binding to represent a potential communications interface, such as a specific transport and a particular URL. A given Web Service may support different bindings for the same port type. This separation gives a Web Service provider a great deal of flexibility, such as offering different levels of service for different users. The free version of a Web Service accessed through one URL would have a higher quality of service compared to the paid version of the service accessed through a different URL.

Of course, even if a provider goes to the trouble of creating a WSDL description of its Web Service, potential users have to find this service. The whole purpose of WSDL is so a user can access a service without a lengthy communication with the provider. But this brings up the likely possibility that the user won't know about every Web Service that could fulfill his needs. The UDDI protocol fills this gap. UDDI is essentially a directory for Web Services. Providers can submit descriptions of their services and accompanying interface descriptions. Users can search for services that deliver what they require. Ariba, IBM, and Microsoft are working together to offer top-level public directories based on UDDI. Other organizations may offer directories specialized by topic or industry. An enterprise would probably have its own private UDDI directory if it used Web Services for application integration. Figure 4-7 shows how a sequence of operations using the basic protocol stack helps establish distributed communication.

Figure 4-7. Web Services Protocols in Action

The goal of this Web Services architecture is to lower the cost of interoperability. Compared to past distributed object systems, Web Services offers the advantages of true interoperability among implementations from different vendors. Like such systems, it provides for interface repositories and interface definitions so that developers can quickly access the information necessary to write software that accesses a particular service. However, capitalizing on these benefits requires widespread adoption that is far from certain. The biggest challenge is that Web Services do not allow us to do anything that we couldn't do before. It simply makes it somewhat easier.

Expanding the Protocol Stack

The basic Web Services stack best serves remote interface applications. Discovering, understanding, and programming to remote interfaces are the primary problems, but adding WSDL and UDDI to SOAP is a solution. Security remains unaddressed, but transport level strategies ”such as binding SOAP to HTTPS ”provide a quick fix. Transactions also present an issue, but careful structuring of interfaces can avoid serious problems in most cases. While the basic stack has enough functionality to support remote interface architectures, this is not the case for business document architectures. To support business documents from a practical standpoint as well as a marketing standpoint, the Web Services stack needs to address the issues of extended features that SOAP deferred.

Because business document applications absolutely require reliable messaging, reliability is the biggest gap. As we saw for both BizTalk and ebXML, it is possible to plug this gap with application-specific SOAP header tags. Unfortunately, this approach leads to incompatibilities and duplication of effort among the different applications. Adding reliability to the standard Web Services stack solves the problem more tastefully. There are two approaches: Add reliability to specific transports, and add reliability specifications to SOAP. IBM has a proposal for HTTP-R that adds reliability-related headers to the HTTP transport. Special HTTP-R capable servers can interpret these headers to provide guaranteed delivery and delivery receipts. Adding reliability to a specific transport has the disadvantage of limiting the scope of reliable messaging to that transport. Microsoft has a proposal for WS-Routing that adds tags to SOAP and that describe the reliability requirements of the message. While different transports can fulfill these requirements, it does open the door for different implementations to interpret requirements differently. Most likely, a combination of these approaches ”SOAP-level specifications and enhancements to standard transports ”will fill this gap in the long term .

In addition to reliability, there are a number of efforts to add security, transaction, and inspection features to facilitate the execution of both remote interface and business document applications. For the most part, there are no major technical hurdles; it is simply a matter of agreeing on a common model. More interestingly, there is a trend toward trying to replace existing Internet protocols with those better optimized for Web Services. A good example is Direct Internet Message Encapsulation (DIME). This protocol replaces MIME for packaging information in a message. While perfectly possible to perform XML messaging with MIME, it does have a few drawbacks that DIME attempts to address. However, it is an open question as to whether the relatively minor benefits outweigh the cost of replacing a very well- understood and mature protocol with a brand new one. There are even some discussions of replacing HTTP itself. You should be very cautious of such initiatives. The Internet and Web have evolved over time, and shifting fundamental pieces of the infrastructure could have unintended consequences. You should consider using such technology only after satisfying yourself that the benefits are compelling and testing has been rigorous .

Clearly, the proliferation of Web Services protocols may lead to both confusion and incompatibility . Recently, a number of companies founded the Web Services Interoperability Organization (WS-I). These founders included Accenture, BEA, Hewlett-Packard, IBM, Intel, Microsoft, and SAP. As major providers of Web Services products and services, they have pledged to work together to promote compatibility. They plan to promote a common set of core Web Services principles to educate developers and to conduct interoperability tests to ensure their offerings work together smoothly. Hopefully, this cooperative effort can maintain momentum for standards in XML messaging.

Message Flow Languages

There is a potentially strong motivator for Web Services adoption on the horizon. One of the remaining points of intensive labor in using Web Services is the need for programmers to connect services together by writing glue code. There are a number of initiatives in their early stages that aim at specifying yet another level of XML-based information to supplant the need for such programming. Often known as orchestration technologies, these initiatives are attempting to define the glue as XML rather than as traditional programming code.

This concept is not new. Since the invention of distributed components, there has been a lot of talk about wiring applications together. Most attempts to achieve this goal have failed. But the XML-based approach may have a chance because Web Services blur the distinction between behavior and data. In traditional component systems, the actual execution of remote functions is clearly defined as behavior. However, Web Services make this execution a matter of sending the correctly formatted text message, which looks a lot more like data. The advantage is that data is easily transformed.

Most wiring paradigms work perfectly well as long as the output of one remote function matches the requirements for inputs to the next function. Unfortunately, the world is not usually this well ordered. However, because XML is so data oriented and has a companion data transformation language in XSLT, it may be possible to deal with mismatches without dropping into a traditional programming language. Simply apply an XSLT transform on the output of one function to get the input to the next function. Of course, if the difference between output and input are dramatic, the amount of XSLT necessary for the transformation will look more like a program in its own right than a simple scripting fragment.

Another benefit of the XML approach to wiring components is that the description of component assembly is portable. A disadvantage of previous approaches was that the result of wiring components together was either a proprietary file or generated programming code. These approaches limited the portability of the wiring information. With XML-based descriptions of the wiring, they could easily flow from one tool to another and from one vendor's Web Services implementation to another. Of course, the downside is that the server software that interprets these descriptions must be extremely sophisticated.

There are currently two major competing initiatives for wiring together Web Services built using the remote interface architecture: Web Services Flow Language (WSFL) from IBM and XLANG from Microsoft. Both take a very similar approach: They define an assembly of Web Services as a set of possible states. A given state may send or receive messages. Once a message is sent or received, the system moves to another state. They each have elements for specifying the rules by which these state transitions occur and operations for transforming data as it makes these transitions. These descriptions are much too complicated to create by hand, so they rely on flowcharting tools as a graphical interface.

Both WSFL and XLANG are really intended to work with remote interface applications. The problem is that these applications require many operations on small chunks of data. So graphically expressing the message orchestration for an application of any complexity may require so many steps as to erode its advantage over hand coding.

Business document applications are another matter. They require fewer operations on much bigger chunks of data. There are fewer steps to model, and the advantage of transformations is larger.

A big objection to using orchestration for remote interface applications is that this technique really offers little advantage over the existing technique of custom programming. Orchestrating a remote interface application already requires programmer-level understanding of how distributed systems work. A good programmer can create custom programs almost as fast as orchestration diagrams and achieve more flexibility. Moreover, two organizations are unlikely to use the same set of Web services in the same way, so portability of the assembly description is not that much of an advantage. The situation is different for business document applications. Business analysts already use business process modeling tools to communicate within and across enterprises . They are comfortable treating business processes at the abstract level, so they may be able to specify most of a business document application's behavior in a graphical manner.

The challenge is keeping the business document flow language simple enough that it doesn't require programming expertise to create but expressive enough to cover a large variety of business processes. One potential approach to resolving this conflict would be to have several task-specific flow languages rather than one very general one. So one flow language might apply to transportation logistics, while another would apply to insurance claims processing, while yet another would apply to telecommunications service provisioning. The author has had some success with this approach in manufacturing supply chains.

At the time of this writing, the Business Process Management Language (BPML) was the only independent initiative working on a business document flow language, and it's in the early stages. This initiative does suffer the drawback of attempting to define a completely general-purpose flow language. This language is too complicated for business analysts, but it may serve as the foundation for defining more manageable task-specific vocabularies. There is also work occurring within ebXML to make BPSSs into practical and portable machine executable specifications. Hopefully, the CPA and associated BPSS negotiated between two parties will be directly executable by software from multiple vendors in the near future. Furthermore, if enterprises begin demanding business document orchestration, then other public and proprietary solutions will undoubtedly emerge.