In This Chapter
Today organizations not only require solid approaches to developing software, they also need to recognize how they can be leveraged across and beyond the enterprise. An up-and-coming measurement of the success of an organization is how quickly it can leverage its business processes and data, information and knowledge fluidly and seamlessly across their enterprise, regardless of the source, in order to make real-time decisions. This phenomena is known as the Time-to-Share objective, where the emphasis is on how quickly business process and data, information and knowledge can be shared rather than made available (Time-to-Market). Availability does not necessarily guarantee accessibility.
The objective of this chapter is to introduce you to a technology approach that enables organizations to share data and business logic, and access external data sources and syndicated services, regardless of their residencies, without bridging the connections through extensive development efforts or “hard wiring.” This technology approach is known as Web services.
There is a saying, “A message is more important than its medium,” but in some cases, depending on the context, the opposite is true, “The medium is more important than its message.” Certainly the approach the information technology revolution has taken in the past decade has focused on the medium. From a medium perspective, multi-platform languages (Java) and application-development specifications (J2EE) have pioneered a means for designing and constructing very robust, scalable, and distributed component-based business solutions.
These business solutions can easily be deployed into pervasive networked computing environments, such as PDAs, cellular phones, personal computers, and application servers. From the message perspective, HTTP (Hypertext Transfer Protocol) and XML (Extensible Markup Language) have become the industry-standard, system-independent data transfer and messaging protocols. However, the focus of this technology revolution has primarily been in the area of architecting a new wave of applications that interact with the end users through a Web browser.
However, to achieve a federated enterprise architecture enabling Business to Business (B2B) or Enterprise Application Integration (EAI) operations, there is a minimal requirement for applications to communicate among themselves. The traditional mechanism to achieve B2B or EAI is through exposing an application’s functionality through a series of application programming interfaces (APIs). This type of integration is known as a point-to-point integration mechanism, and does not scale well because applications have their own proprietary APIs, which are often bound to hardware platforms and the implementation software platforms. For this reason, point-to-point proprietary integration solutions do not solve the stovepiped application integration dilemma in a cost-effective, maintainable, or extensible manner.
In order for communication to be achieved between applications written in different programming languages and on different platforms, typically a common gateway or proprietary adapter needs to be available, as illustrated in Figure 7.1. The role of this gateway or adapter is to provide interpretation services for service requests or responses on behalf of the communicating applications.
Note
Gateways and proprietary adapters require specific knowledge of all the communicating applications. This proposition can be very complex and expensive because consultants from the gateway and adapter vendors will need to be resourced to achieve any level of success. To mitigate this complexity and expense, use adapters that are based on proven industry-accepted integration standards such as the Java Connector Architecture, which is part of the J2EE specification.
Web services is a technology approach whose characteristics are well suited for bridging together information systems, even if they are implemented on disparate platforms or through differing technologies. For this reason, Web services can enable organizations to strengthen their value propositions by revealing their core competencies through a suite of interoperable software solutions, which may exist internally or externally to the enterprise.
To enable this feat, a Web service can be conceptually thought of as a self-contained, coarse-grained, self-describing, loosely coupled programmable component that can be exposed as a service-oriented system on a network and invoked across the Web (Intranet, Extranet, or Internet). The functionality of a Web service is enabled through one or more methods that process incoming messages, which can be either document or procedure-oriented. Web services can exist as independent providers of services or can collaborate with other Web services to provide a suite of services. Architecturally, a Web service can be considered a network-centric, services-oriented architecture connected over the Web as opposed to a system of distributed object-oriented components interfaced via object-specific protocols (CORBA over IIOP, COM over DCOM, and Java over RMI).
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.
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 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.
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.
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).
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
For a detailed discussion of WSDL, see Chapter 29.
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.
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.
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.
It was mentioned in the beginning of Chapter 2, “J2EE Software Development Methodologies,” that the computing industry recognizes very clearly the failure rate of application development efforts, which is currently running at approximately 70%. Because every IT project has its own nuances of challenges, technology itself is not the only factor for such a dismal failure rate. However, the consequences of adopting a specific technology can very easily contribute to the success or failure of an IT project, even if it is deferred to another point-in-time.
To avoid being a contributor to this statistic, organizations are beginning to think differently and ask themselves what nirvana would look like for a business solution from an enterprise standpoint. This is a major shift from the traditional deliver the application by just meeting the requirements paradigm. Organizations recognize that today’s business solutions are susceptible to becoming legacy in the near future if they do not consider:
The longevity or sustained growth of the business solution.
The participation of the business solution in an enterprise Time-to-Share model, where its business process and associated domains of data, information, and knowledge may need to be leverageable (shared and accessible) to the organization, not today, but sometime in the life of the business solution.
It is extremely rare to see computing heavyweights such as IBM, Microsoft, Sun, BEA, Oracle, HP, and others agree on anything, yet they all concur Web services will be the native language of the next generation of Internet-based applications.
Web services hold a promise of simplifying integration across many aspects of the enterprise by providing:
Interoperability among distributed business systems that span diverse hardware and software platforms.
Accessibility of applications through firewalls using ubiquitous Web protocols (HTTP/HTTPS).
A cross-platform, cross-language data model (XML) that enables interaction between heterogeneous distributed applications.
Based upon the above attributes, Web services can provide the following business value propositions to organizations:
The acceptance of XML as the standard for exposing Web services, as opposed to platform-specific APIs, will reduce the costs and skills required to integrate both components within a system and across systems.
Web services will enable easier B2C and B2B automation, and hence, the capability to build and sustain relationships between business partners and customers.
Improve efficiencies through delivering better services, cheaper and faster.
Greater enterprise agility by providing a network-centric approach to the business services within an organization.
Provide an enhanced spectrum of revenue streams through interactions with untapped legacy business value chains.
A long-term reduction in technical training expenses by the adoption of a corporate-wide strategy for enabling Web services through standard technologies and supporting platforms.
A cost-effective and efficient approach to integration of systems, by the insulation of the EAI marketplace.
Provide the foundation services for a portal framework that needs to encompass content, business systems, and internal or external (non-)syndicated services.
Because the Web services technology is very new, in order for organizations to participate in the Web services landscape, an investment is required in the adoption of the Web services–related technologies and required skills.
The Web services technology is under evolution, similar to that of J2EE. For this reason, it is imperative organizations first prove the fundamental principles of Web services and upon success provide standards for designing, developing, and deploying Web services. Without proven standards, user organizations run the risk of misapplying this technology and incurring extra cost in both development and execution of software systems.