Web Services Overview

Web Services Overview

The Web service movement is an amazing technology to watch take off. One of the most interesting things to keep in mind about Web services is that they just use technologies we already had—XML and HTTP[1]—to create the foundation for an evolutionary shift in how corporations do business on the World Wide Web. But the impact of Web services does not limit itself to between businesses over the Internet; it is also revolutionizing application integration inside the enterprise. This section will provide a brief overview of Web service concepts and technologies. If you are familiar with Web services, you may want to skip this section and go directly to Section 11.2.

So what are Web services?[2] To the business person, Web services are a powerful integration architecture that enables applications to interact dynamically across networks, through the use of open Internet technologies.[3] To a programmer this really means that Web services are software components described via WSDL[4] that are capable of being accessed via standard network protocols such as SOAP[5] over HTTP. Because a Web service's programming interface and access information is described in WSDL, which is a language-independent XML description file, we can say that Web services are interface oriented. This means that they present a modular face and behavior to their clients. Internally, the implementation of the service may be very well designed and modular, or it could be a thin facade over existing or legacy software that is hardly modular. The point is that the client doesn't have to know how it is implemented, just that it supports this nice modular-looking interface.

Another benefit of a service being described is that the description can be published in a directory and then found by clients later. The client uses the binding information in the WSDL service description to invoke the Web service. The description and binding information also makes it possible to compose a Web service as part of another Web service. This all creates a marvelous loose coupling between the service and the clients that use it. Clients are loosely coupled both to how the service is implemented and to when the service was implemented and published.

We'll review what SOAP and WSDL are later in Section 11.1.2. First let's understand the roots of the Web services architecture, the service-oriented architecture.

1 Service-Oriented Architecture

Service-oriented architectures (SOAs), as illustrated in Figure, have been around in academia for some time. There are also standards and products—CORBA, for example—that support SOA-style interactions. Web services are a realization of the service-oriented architecture with cross-industry momentum. Web services add XML-expressed interfaces, flexible communication choices, flexible registry choices, searchable registries, and Internet support to the existing CORBA realization of SOA.

1. Service-Oriented Architecture


In a service-oriented architecture you, a service provider, have a software component you wish to make available to your clients over a network. That software component is the service implementation. You now create a service description for it. There are two types of information in the complete service description: functional and nonfunctional. The functional description is used directly by the client and describes the mechanics that a client must know to invoke your service—that is, the interface and binding data. You may also want to include additional functional description to detail to your clients your security requirements and perhaps how long they should wait before a timeout, among other things. The nonfunctional description is the rest of the information that clients will need to find your service and decide to use your service. The nonfunctional metadata should at least include what business owns and runs the service, and what the categorization taxonomy of the service is. You might also include additional interesting information, such as the cost of using your service.

The description of your service is used to publish it in a registry, directory, or repository of service descriptions. After publication, the registry also has a copy of your service description. Later a service requester needs to use a service just like yours. The service requester, or client, finds your service in the registry and retrieves the WSDL from the registry. Now the client developer can write code to invoke the service based on the WSDL. The fact that clients for Web services can be written and deployed long after the service gives us lifecycle decoupling. Given the development tools that are currently available, the client development environment will generate a stub (or proxy) for the service. These stubs would usually completely hide the WSDL and SOAP transport from the client developer. This stub would do the actual bind to the service provider and then invoke the service. The use of client stubs is already supported by JAX-RPC,[6] AXIS,[7] IBM's WebSphere Application Developer and Web Services Tool Kit,[8] and Sun's Sun ONE.[9]

2 Web Service Stack

Let's look at the concepts and technologies necessary to create a service-oriented architecture for e-business. It is easier to talk about this in terms of a Web service conceptual stack;[10] we will use IBM's stack to illustrate this discussion. The stacks from other vendors all have very similar layers, sometimes rearranged and sometimes split into three stacks: wire, description, and discovery.

In the stack shown in Figure, the lower three boxes are grouped together. These boxes represent the interoperable Web service stack: the network layer, the XML-based messaging layer, and the description layer. The network layer can be any TCP/IP-based network transport. Realistically, the transport you pick for your service will limit who can find and use your service. If you use a widely deployed transport like HTTP, your service is available to a vast number of potential clients and your cost of entry is very low; that is, the cost of access to the Web and a Web server is low. If you use a proprietary transport, such as WebSphere MQ,[11] then only WebSphere MQ clients can access your Web service. This is OK if your potential clients are all within your enterprise and already run MQ clients. Basically you need to pick a transport according to the location from which you think the service will be accessed, the degree of interoperability required, existing network and messaging infrastructure in place between you and your potential clients, and the degree of reliability and security that is required.

2. Web Service Conceptual Stack


Now we layer on the transport an XML-based messaging layer. Today this is predominantly SOAP. SOAP is a simple, standardized enveloping mechanism for communicating document-centric and remote procedure calls using XML. SOAP is a very flexible protocol because of the way it defines the ability to incorporate orthogonal extensions to the message using SOAP headers.

The Web services description layer, shown in Figure, uses XML to describe both the service interface and the service implementation. The service interface is composed of dataType designations that are used to compose message definitions. These message definitions are used to define the input, output, and failure messages of an operation. Sets of operations are used to define a portType element. The portType is conceptually equivalent to a Java interface. A binding definition defines how the messages in the operations are actually put on the wire. A port definition associates a binding element with a location where the service can be accessed. A set of port definitions can be aggregated into a service definition. Port aggregations can be created for various reasons; for example, all port elements for all bindings to the same portType definition may be a service, or a set of portType instances, which may all use the same binding definition, that work together to support a service. Services are typically what are published.

3. Description Stack


The publication layer loosely defines publication to be any way that a Web service description has been made available to a client. It can be be as crude as sneakernet, where the file is copied to a disk and walked or mailed to your potential clients. Or it can be e-mailed directly to your clients. Alternatively, you can make your WSDL description available at an FTP site or at a URL. You would still need to publish the URL in these cases. This URL could also be used to publish to a WSIL document,[12] which simply lists all the WSDL URLs available on a system. In more sophisticated publications, you can publish to a searchable registry or directory like UDDI[13] or a repository like ebXML's Registry and Repository.[14]

The discovery layer is defined as loosely as the publication layer. For files on disks, discovery can mean simply accessing those files locally. For FTP sites or URL publications, it just means doing a get to retrieve the WSDL document. For UDDI, you would need a UDDI client to be able to query the registry to find the WSDL document you need. Discovery can be done during development or by the software while it is executing.

The service flow layer allows service composition and flow definition. The interface-oriented nature of Web services makes it easy to build new Web services that use existing ones. It also makes a service a natural "activity" in a work flow. BPEL4WS[15] is a work flow description language available from IBM, BEA, and Microsoft. The vertical bars represent functionality that needs to be addressed at all layers of the stack. Keep in mind that the solution for one layer may be completely independent of a solution at another layer. For example, the Security/Trust/Privacy vertical in Figure will need to be addressed at the networking layer, SSL,[16] as well as the XML messaging layer, ws-security.[17] This will potentially cause additional information to be added to the description. Security at the publication and discovery layers would include requiring logons to the service registry or selecting a registry whose integrity you trust. Likewise, other qualities of service are required at different layers of the stack. For the network layer, you might require a reliable network, like that provided by WebSphere MQ or specified by HTTP-R,[18] a reliable messaging protocol using HTTP.

This chapter is not intended to be a tutorial on Web services or the technologies used to implement them. A significant amount of material available in books, in articles, and on the Web provides a more in-depth education on this topic. Recommended reading includes the "Web Services Conceptual Architecture"[19] white paper, "Building Web Services with Java,"[20] and "Programming Web Services with SOAP."[21]

The Management vertical in Figure is the focus of this chapter. Let's take a look at it layer by layer first; then we'll concentrate on how to use JMX to enable Web services and Web service infrastructures to be managed. Here are the layers:

  • Network. We can manage the network layer by using a network management system for the TCP/IP network. Some network managers—for example, HP's OpenView—also support JMX. We will not address network management in this chapter.

  • Description. The description layer could include management metadata, or it could include the description of a separate management port for a service. We will discuss this in detail in the next section.

  • Publication and discovery. Managing the publication and discovery layers would include ensuring that the important service registries and repositories are active, available, and performing well. This is similar to managing name servers today. We will discuss the instrumentation and management of registries in this chapter.

  • Work flow. Work flows typically have applications to execute them and generally a management application to manage them. This application may use or expose JMX MBeans. In the Web services area, work flows will be exposed as Web services, so the discussion on managing Web services applies to managing a work flow. We will not specifically address the management of work flows in this chapter.

Remembering the SOA triangle, we will look at how to manage the registry and the service. Services typically run in a Web service execution environment, like AXIS, JAX-RPC, IBM WebSphere Application Server, or BEA WebLogic, so we will also look at how to manage the execution environment. We will look at how to manage each of these components from two points of view: the owner of the component and the user of the component.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows