The Characteristics of Web Services

Any component or application can be packaged as a Web service as long as it

• Exposes and describes its functionality and attributes so that other Web services and applications understand how to interact with it and invoke its services.

• Registers in some type of directory service that allows it to be discovered within a network environment.

• Can be invoked through a declared API (method) over a network using ubiquitous Web protocols, for example HTTP.

• Always returns a response to an invoking entity.

Note

A request-response communication behavior is the default operation of Synchronous Web services. One-way communications can only be achieved through Asynchronous Web services, which are supported by WebLogic Server.

These touchpoints are the generally adopted characteristics for Web services. To understand how these characteristics can be fulfilled, Web services need to be further discussed in terms of the following supporting open standards, model architectures, and technologies that enable the Web services architecture to be implemented:

• Web Services Standard Protocols

• The Web Services Model ”Service-Oriented Architecture (SOA)

• The Web Services Technology Stack

Note

The Web Services Technology Stack is dependent on the vendor that is implementing Web services. For this reason, the BEA stack and its implementation in the context of the WebLogic Server 7.0 will be discussed in Part VII of this book.

Web Services Standard Protocols

Web services are a platform-independent, standards-based means for achieving asynchronous access to applications in a heterogeneous distributed environment. To facilitate this model for connectivity and interoperability, Web services leverage the industry standard protocols described in the following sections.

Simple Object Access Protocol (SOAP)

To fulfill their vision, Web services must be able to exist in any heterogeneous computing environment and be programming language “independent. Taking the consistency builds competency approach, organizations will need to decide their language of choice for constructing Web services. From a practical and efficient perspective, a programming language that does not limit the deployment environment within an organization should be selected. If portability is a requirement, Java is the natural implementation language for Web services. The combination of Java and the J2EE Platform allows organizations to leverage such benefits as component reusability and built-in infrastructure services such as security, distributed transaction management, and connection pool management, enabling Web services to be deployed in a very scalable, secure, and robust manner.

However, J2EE applications support a network-object interaction model where objects of strictly defined types are transferred between components using a request-response interaction pattern. Such object interactions require an understanding of the object model within which they live. For this reason, object interaction methods are not suited for multi-application interoperability or cross-organizational interactions that must be long lived.

Because XML permits data to be very portable, Web Services leverage the lightweight XML-based protocol named the Simple Object Access Protocol (currently SOAP version 1.2) for invoking services across the Internet and exchanging information in a decentralized and distributed environment. The transport mechanism for SOAP is provided by ubiquitous Web protocols such as HTTP/HTTPS, which enables negotiation of Internet firewalls much better than RMI, IIOP, or DCOM.

SOAP does not define a programming or implementation model. Instead, it defines a modular packaging model and the mechanisms for encoding data within modules. A SOAP message consists of four 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.

• A convention for representing remote procedure calls and responses.

• A binding convention for exchanging messages using an underlying protocol such as HTTP/HTTPS and SMTP.

For a detailed discussion of SOAP, see Chapter 29.

The Web Services Description Language (WSDL)

Each Web service defines and publishes its interfaces (APIs) and other capabilities such as the network protocol for access, the accepted message formats, and how to reach the service using an XML-based standard specification schema known as the Web Services Description Language (WSDL).

Note

In the J2EE world, a WSDL interface definition is analogous to an EJB remote interface.

A WSDL document typically consists of the following elements to describe a Web service:

• Types: XML types corresponding to the various arguments and return types

• Message: An abstract typed definition of the data being communicated

• Operation: An abstract description of an operation provided by the Web service

• Port Type: A collection of operations supported by one or more endpoints

• Binding: A concrete protocol and data format specification for a particular port type

• Port: A single endpoint defined as a combination of a binding and network address

• Service: A collection of related endpoints

For a detailed discussion of WSDL, see Chapter 29.

Universal Discovery Description and Integration

The loose coupling or autonomous nature of Web services allows them to be created dynamically and independently of any application or other Web services that may demand their services. For this reason, Web services require a registration and discovery mechanism that allows them to promote their existence and be located within the context of a network environment, which can exist internally or externally to an organization.

To assist in this area, the Universal Discovery Description and Integration (UDDI) is a specification for a distributed, Web-based information registry of Web services. The UDDI provides a means to publish information about Web services, as well as provide a discovery mechanism to locate Web services and the nature of services they provide.

From a J2EE developer's perspective, a UDDI registry is required to

• Locate the WSDL information about existing Web services.

• Gain the technical details required to interact with specific Web services.

• Avoid creating duplicate or similar Web services.

• Describe its own Web services for others to invoke and use.

A UDDI Business Registry can also be used to locate companies in a given industry with a given type of service, or locate information about how a partner or intended partner has exposed a required Web service.

A Service-Oriented Architecture of Web Services

The Service-Oriented Architecture (SOA), which was initially published by IBM, is a conceptual approach that captures the architecture required to support Web services. The SOA defines three roles ” service provider , service requestor , and service registry , and the interactions between them ”the publish, find, and bind operations, as illustrated in Figure 7.2.

Figure 7.2. The concept of a service-oriented architecture.

Note

In this architecture, a Web service is defined as being the implementation of a service description . A service description is the meta data describing the Web service, which includes the information for a service requestor to access the service it describes, including its interface and location.

In this scenario, the interactions between the roles and operations are defined as follows :

• A Service Provider host defines a service description for a Web service and then publishes it to a service requestor or service registry.

• The Service Requestor is defined as a business that requires certain functions to be satisfied or an application that is looking for and invoking or initiating an interaction with a Web service. The role of the Service Requester is to find the service description (meta data) of a Web service via the Service Registry , which contains sufficient information for the Service Requestor to bind to the Service Provider to use the service. The bind operation is the process that allows an application to connect to a Web service at a particular network address and start interacting with it.

• A Service Registry is a searchable registry of service descriptions where Service Providers publish the service descriptions of their Web services. Service Requestors use the Service Registry to find the service descriptions of Web service, which provides sufficient information to bind to it.