Any component or application can be packaged as a Web service as long as it
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:
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 ProtocolsWeb 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 :
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:
For a detailed discussion of WSDL, see Chapter 29. Universal Discovery Description and IntegrationThe 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
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 ServicesThe 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 :
|