Chapter 8: Web Services for Application Integration

In this chapter, we introduce the Web services technology and the associated standards. We bring to light key aspects of the WSDL and SOAP specification such that readers are able to discern the relationships between WSDL constructs and the corresponding SOAP message constructs. The evolution of systems integration and emergence of Web services as a new way of integrating disparate applications and systems are discussed. The chapter's emphasis is on WSDL, SOAP, and other aspects of Web services technology.

The concepts learned in this chapter are subsequently applied in the creation of a Web service, in the context of our sample application using BEA-provided IDE called WebLogic Workshop. This is covered in the section "GreaterCause B2B Integration," which discusses the integration requirements, the rationale for selecting an appropriate architecture, followed by complete Web service implementation. Web services are built on a stack of technologies in which XML plays an important role in the overall architecture. This chapter does not talk about XML technologies nor the pertinent APIs. To learn more about XML, a good place to begin is http://java.sun.com/xml, http://www.xml.org (hosted by OASIS) and http://www.w3.org/TR/REC-xml (XML specification).

Introduction to Web Services

Software technology emerged from linkage of programming statements into object code and linkage of object code into monolithic programs (applications). Monolithic programs were developed using many different programming languages and operating systems–specific system linkers. Early requirements for process and data integration gave birth to a new business: the systems integration. Systems integration, after years of evolution, arrived at Enterprise Application Integration (EAI). EAI space created a host of new technologies, tools, and processes, and in some cases development methodologies. EAI competitions also created confusing terminologies such as data-centric EAI, process-centric EAI, message-centric EAI, and object broker EAI. Each EAI segment tried to address part of the old "systems integration" problem, but in nonintegrated and broken ways, such as data, process, objects, and messages. Although, traditional EAI made a great improvement in building "integrated solutions," the artificial marketing-driven separation of integration as a whole failed to converge the EAI technology into a uniform eBusiness application construction platform.

On the other hand, the necessity of conducting business on the World Wide Web created an extremely complex set of requirements for building eBusiness applications. Constructing eBusiness applications requires the integration of business functions that are embedded in thousands of applications, each implemented in different programming languages, object models, messaging systems, databases, and operating system platforms. The integration itself is dynamically driven by the business rules and requirements, that is, it is the business rules that decide what business function, and therefore application, should be executed next. Traditional EAI failed because it did not allow for the diversity of things to be integrated in a standard manner and did not deal with business functions at all.

Taking a low-level tour of a single execution thread in an eBusiness application, that is, performing a business function, one may discover that a specific application interface (legacy, CORBA, J2EE, .NET, or just pure Java) has to be invoked within the required application context. The application context (with or without transaction) may include the application adapter, the messages/parameters that need to be sent to the application, and the application execution engine. The execution engine may be a proprietary application server, a CORBA server, a J2EE server, a .NET server, or it may just be a stand-alone JVM. The execution context may include a Web server (Apache, Tomcat, IIS, and so on). The execution itself may result in generating some new information that needs to be fetched into the next thread of execution in order to perform the next business function. With traditional EAI, extensive development had to take place to develop the adapters and the required messages. The business rules have to be coded either in the applications, adapters, or messages, or all of these entities. Changes to the business rules require changes in execution order, applications, adapters, messages, and other contextual information.

One of the complex spaces that never standardized in the traditional EAI approach was the messaging mechanism. In fact, the proliferation of messaging models resulted in creation of several messaging systems by many EAI vendors. Each messaging system suggests its own way of adapter development, communication models, and protocols. The emergence of XML not only unified the application-messaging paradigm, but it has created significant opportunities for infrastructure vendors to simplify, in a cost-effective manner, the construction of eBusiness applications. Although XML can be used in many different ways, in the context of Web services it can be thought as the "language of the Internet." By "language of the Internet" we mean the XML representation of the information or messages exchanged between the applications. Web services are computer programs that are accessible through the Web. In a typical Web services scenario, a business application sends a request, represented as XML, to a Web service at a given URI. The remote service receives the request, processes it, and returns a response. The XML-based request and response messages are based on a standard format called Simple Object Access Protocol (SOAP). The SOAP specification defines bindings for using SOAP in combination with HTTP and HTTP extension framework; however, SOAP can be potentially used with a variety of other protocols.

Web services cover the RPC model that is epitomized by the EJB or CORBA models and hold the promise of knocking down barriers among operating systems, programming languages, and geography, all in a secure, standards-based manner. Web services and consumers of Web services are typically businesses, making Web services predominantly business-to-business transactions. An enterprise can be the provider of Web services and also the consumer of other Web services. For example, an automobile parts distributor could be in the consumer role when it uses a Web service to check the availability of specific automobile parts, and in the provider role when it supplies prospective customers with different vendors’ prices for the automobile parts.

Web services combine the best aspects of component-based development and the Web—delivering true distributed "peer-to-peer" computing. Web services can vary in function from simple operations, like the retrieval of a stock quote, to complex business systems that access and combine information from multiple sources. Web services also can be thought of as the building blocks in the move to distributed computing on the Internet. Enterprise class Web services are usually loosely coupled, asynchronous, and coarse-grained. Loose coupling allows Web service providers to change an implementation without disrupting users. Asynchronous Web services tend to be more scalable than Web services based on Remote Procedure Call (RPC).

There are probably as many definitions of Web service as there are companies building them, but almost all definitions have the following in common:

• Web services expose useful functionality to Web users through a standard Web protocol.In most cases, the protocol used is SOAP.

• Web services provide a way to describe their interfaces in enough detail to allow a user to build a client application to talk to them. This description is usually provided in an XML document called a Web Services Description Language (WSDL) document.

• Web services are registered in directories so that potential users can find them easily. This is done with Universal Discovery, Description, and Integration (UDDI).

A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols.

Once a Web service is defined and implemented, it needs to be described with a WSDL file and registered in UDDI. By exposing existing applications such as XML, Web services will allow users to build new, more powerful applications. For example, a user might develop a purchasing application to automatically obtain price information from a variety of vendors, and allow the user to select a vendor, submit the order, and then track the shipment until it is received. The vendor application, in addition to exposing its services on the Web, might in turn use Web services of other businesses to check the customer's credit, charge the customer's account, and set up the shipment with a shipping company. In the next sections, we discuss the three essential Web services building blocks: SOAP, WSDL, and UDDI. SOAP and WSDL are also covered in detail in later sections. The SOAP specification is available at http://www.w3.org/TR/SOAP, the WSDL specification is available at http://www.w3.org/TR/wsdl, and the UDDI specification is available at http://www.uddi.org.

What Is SOAP?

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML-based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses.

Note

From an architectural perspective, making encoding an integral part of the message makes SOAP language neutral.

SOAP is defined as a communications protocol, but unlike DCOM or CORBA, it does not support object activation and does not rely on any naming service. The XML schema for SOAP messages (schemas.xmlsoap.org/soap/envelope) specifies a standard structure that needs to be supported by any compliant SOAP implementation.

When using CORBA, the IDL had to be compiled to client- and server-side implementation language in order to produce proper stubs and skeletons. When using SOAP, developers will not have to concern themselves with encoding rules because the vendor-provided tools handle serialization (analogous to parameter marshalling in CORBA) and deserialization (analogous to parameter demarshalling in CORBA) of application-defined datatypes.

SOAP defines two separate styles of messages—the RPC-oriented (messages containing parameters and return values) and document-oriented (messages containing documents). The SOAP RPC defines a convention that can be used to represent remote procedure calls and responses. In an RPC-oriented style, a SOAP request containing a callable function (an operation exposed by a Web service) with associated function parameters is sent from the client to the server. The server returns a response with the results of the executed function. Most current implementations of SOAP are based on RPC-style Web service because programmers who are used to developing COM or CORBA applications easily understand the RPC style.

RPC and document-style Web services are discussed in the section "Introduction to Web Services Description Language."

The SOAP specification defines HTTP bindings that describe how a SOAP message can be carried in HTTP messages, with or without the HTTP extension framework. The HTTP binding is optional, but almost all SOAP implementations support it because it's the only standardized protocol for SOAP. For this reason, there's a common misconception that SOAP requires HTTP. Implementation may support SMTP, FTP, RMI/IIOP, or a proprietary messaging protocol, but most current Web services use HTTP because it is ubiquitous. Since HTTP is a core protocol of the Web, most organizations have a network infrastructure that supports HTTP and people who understand how to manage it. Security, monitoring, and load-balancing infrastructure for HTTP are also readily available.

Generally, Developers who use SOAP don't write SOAP messages directly—instead they use a SOAP toolkit to automate their development. For example, vendor tools like CapeClear, PolarLake, Apache Toolkit, and BEA WebLogic Workshop provide facility for automatically generating SOAP interfaces, for existing EJB, Java, CORBA, and .NET components. These server-side interfaces are exposed to the SOAP client as Web services. A practical example of this scenario using the BEA WebLogic Workshop is discussed in the section "GreaterCause B2B Integration," where the vendor tool handles the Web service protocols, allowing the developers to focus on the business logic embedded in the EJB. By the same token, the Microsoft SOAP Toolkit 2.0 translates COM function calls to SOAP.

SOAP Security

Early in its development, SOAP was seen as an HTTP-based protocol, so the assumption was made that HTTP security would be adequate for SOAP. After all, there are thousands of Web applications running today using HTTP security. When SOAP expanded to become a more general-purpose protocol running on top of a number of transports, security became a bigger issue. For example, HTTP provides means for authenticating which user is making a SOAP call, but how does that identity get propagated when the message is routed from HTTP to an SMTP transport? SOAP was designed as a building-block protocol, so fortunately there are already new specifications in the works. The idea is to build on SOAP so it can provide additional security features for Web services. The WS-Security specification describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. It's a mechanism for accommodating a wide variety of security models and encryption technologies—this and related specifications are available at http://www.xml.coverpages.org/ws-security.html. The section "Introduction to Simple Object Access Protocol" presents additional discussion on SOAP.

What Is WSDL?

WSDL stands for Web Services Description Language. A WSDL document contains XML constructs for describing network services as collections of communication endpoints capable of exchanging messages. It also provides a recipe for automating the details involved in application communication. A WSDL file describes SOAP messages and how the messages are exchanged. In other words, WSDL is to SOAP what IDL is to CORBA. Since WSDL is XML, it is readable and editable; however, in most cases, it is generated and consumed by software tools. WSDL specifies, in XML notation, what a request message must contain and what the response message will look like. The notation that a WSDL file uses to describe messages is based on the XML schema standard, which makes the Web services both programming-language neutral and accessible from a wide variety of platforms.

In addition to describing request and response messages, WSDL defines the location of the Web service and the communication protocol used for accessing the service. This means that the WSDL file defines everything required to communicate with a Web service. Fortunately, there are several tools available to read a WSDL file and generate the code required to communicate with a Web service. The existing SOAP toolkits include tools to generate WSDL files from existing program interfaces (such as CORBA IDL, EJB, and .NET components). Like CORBA IDL tools, these tools can generate proxies and stubs used by Web services clients. The WSDL specification can be found at http://www.w3.org/TR/wsdl. The section "Introduction to Web Services Description Language" discusses the details of the WSDL.

What Is UDDI?

Universal Discovery, Description, and Integration can be seen as the yellow pages of Web services. As with traditional yellow pages, one can search for a company that offers the required services, read about the service offered, and contact someone for more information. If the Web service is designed and planned to be accessible by many clients, it should be registered with the UDDI. A UDDI directory entry is an XML document that describes a business and the services it offers. There are three parts to an entry in the UDDI directory. The "white pages" describe the company offering the service—name, address, contacts, and so on. The "yellow pages" include industrial categories based on standard taxonomies such as the North American Industry Classification System and the Standard Industrial Classification. The "green pages" describe the interface to the service in enough detail for someone to write an application to use the Web service. Services are defined through a UDDI document called a Type Model, or tModel. In many cases, the tModel contains a WSDL document that describes a SOAP-based Web service, but the tModel is flexible enough to describe almost any kind of service.

One of the primary potential uses of Web services is for business-to-business integration. For example, a company might expose a movie ticket purchasing Web service that allows its consumers to send requests over the Internet. If a travel agency wanted to purchase movie tickets over the Internet, it would need to search for all vendors who sell movie tickets. To do this, the travel agency will require a directory of all businesses that expose Web services. This directory is called Universal Description, Discovery, and Integration, or UDDI.

Like a typical yellow-pages directory, UDDI provides a database of businesses searchable by the type of business. You typically search using business taxonomy such as the North American Industry Classification System (NAICS) or the Standard Industrial Classification (SIC). You could also search by business name or geographical location. Going back to our example, the travel agency could search UDDI for NAICS and some identifier, perhaps "entertainment." This search would return a list of companies registered with UDDI that sell movie tickets.

Web services exposing functionality for use by other businesses are registered with UDDI. Services are grouped by a type. The service type has a unique identifier and comes from a pool of well-known service types that are registered with UDDI. These service types are called tModels in UDDI terminology. Each tModel has a name, description, and a unique identifier. This unique identifier is a Universal Unique Identifier (UUID) and is called the tModelKey. By having a pool of well-known service types, UDDI makes it possible to find out how to do electronic business with a company. The UDDI directory may be searched in several ways. For example, one can search for providers of a service in a specified geographic location or for business of a specified type. The search may result in information such as contacts, links, and technical data that can be used to evaluate against service requirements.