Service Oriented Architecture

Building dynamic e business applications, which leverage a variety of existing application systems, and deriving a set of new reusable components requires careful planning and a good architectural direction. WAS provides support for the Service Oriented Architecture (SOA). The SOA concepts and corresponding support in WAS are built upon J2EE and web services concepts and leverage the basic infrastructure of WebSphere.

In the diagram above, we see that the SOA is split into a triad of Service Provider, Service Requester, and Service Registry. The Service Provider corresponds to the J2EE developer, assembler, and deployer platform roles. Publishing can be associated with J2EE application deployment. There is no single standard Service Registry yet, but Universal Description, Discovery, and Integration (UDDI) is as close as you can get for web services. The act of publishing a service not only provides an address or means of locating the service (as in JNDI), but it also provides a description of the service using Web Services Description Language (WSDL).

This programming-model-agnostic description allows any number of different software platforms to access each other. A client does this by first finding the description of a service, binding to the services location, and using the description to send requests to the service. The details of this will be covered in Chapter 8. The important thing to remember is that web services are for providing access to business functions and data while J2EE is focused on providing technology for implementing new business capabilities.

The Architecture Challenge

The challenge to architects, given the various mechanisms for defining and exposing interfaces is to choose which of these interfaces is appropriate for a given set of business function. In the Plants-By-WebSphere application, we have chosen to expose certain functions in very specific ways, but it is not always easy to anticipate the way in which business logic may be used over time, or the best way to expose it to satisfy those requirements. This section looks at the various ways that business logic can be exposed. The following sections will examine a way to tie them all back together.

First, we could expose this capability as merely a JavaBean or a basic Java interface. This interface would be one that was very efficient and fast. It also would only be useful to Java programmers that had no expectations on qualities of service and were happy to call this through a Java language interface. This is a high speed, tightly coupled type of interface. The only separation of interface from implementation here is at the Java-language level. Note that the implementation in this case could use JDBC or the Java 2 Connector architecture CCI interface and a CICS application, depending on where the business function really resided.

Next, we could choose to place this business function in with all its inherent qualities of service. The simplest rendering of this would be using a stateless session bean. That stateless session bean could then make calls to the appropriate back end system.

This stateless session bean then provides the opportunity for remote access, meaning that an RMI/IIOP connection to the application server JVM is possible and appropriate for accessing this service. This makes the service inherently more reusable because it can now be accessed from more environments. In fact, in addition to remote Java access, it now can be accessed from CORBA clients such as C++ or accessed using the ActiveX client, which is part of WAS.

Further, it is possible to provide traditional web service access to this business function. A WSDL interface to this service can easily be created and traditional SOAP/HTTP access is quick to follow. Here then we have some different quality-of-service challenges. The security and transactions story is somewhat more complicated. Inbound transactional context cannot be transferred onto the request on the serverside. However, the declarative model for the stateless session bean is still available as a mechanism to establish quality-of-service attributes. The overhead and translations necessary to access this Java code from a SOAP/HTTP client is obviously more than any of the previously discussed access patterns. Taking the inbound SOAP/HTTP request, demarshaling the request, and finding the proper implementation to dispatch on is more costly than the inbound EJB path.

Additional combinations of technologies can be applied to provide additional ways of accessing this basic set of functions. An MDB could be used to drive the business function as just one more example. Each of the combinations will bring to bear a set of performance overheads, a mechanism for dealing with management, and establishment of the environment in which the business logic is to run. Different combinations are also possible. For example, one can go directly from an inbound SOAP/HTTP request to a JavaBean, skipping the EJB if that quality-of-service attribute is not relevant.

The net result here is that the number of combinations can become significant. Each of these combinations comes with a different set of interfaces, and demands a different programming model for clients using these services.

The Service Bus

It would be nice if there were a consistent means for describing and accessing services in the variety of manners just described. Fortunately, there is one available using WSDL.

WSDL – Another Look

WSDL, as it turns out, is a good way to describe any kind of service. Upon further analysis, the "W" in WSDL is a bit too restrictive. The inventors of WSDL have equipped the language with a smart extensibility mechanism, which allows you to describe any kind of service, be it a web service or some other type of "service".

The following diagram shows the WSDL document architecture:

In the top section of the WSDL document, you can see the abstract service interface definition. The service interface in WSDL is called a portType. PortTypes consist of one or more operations with input and output. The input and output are described by messages. Service messages are typed using XML Schema.

The section at the bottom allows you to describe how the service interface is implemented and where you can find it.

The service location is described by a service-provider-specific port extensibility element. The service implementation is described by service-provider specific extensibility elements in the binding section. WebSphere supports the following service-provider-specific bindings: SOAP, Java 2 Connectors, JavaBean, stateless session EJB, flow, and transform. These are some of the same things described in the previous section. Flows and transforms will be described in Chapter 10 when we dig deeper into the workflow capabilities of WebSphere.

So to summarize, we have a mechanism now, WSDL, that lets us describe services as follows:

The Architecture

If we put this together, fold in the idea of a service that can call a service, we get to the bus:

The particular bindings are not important other than to note that a variety can exist, even within the J2EE programming model. This consistent mechanism for expressing the interface to a service, irrespective of the implementation technology or the location of the implementation is a good start. Services calling other services or creating services from services is often called service composition. Further explanation of this will come in Chapter 11.

Some additional factoring and separation of concerns is necessary to complete the SOA. This is explored in the next section.

The Interfaces

Services actually involve a number of interfaces, all of them described in WSDL. The first set of interfaces arises when we split the interfaces into an interface and implementation binding file. The interface WSDL file contains the interface of the service along with the message and type descriptions. Messages and type descriptions could also be in separate files. The implementation-binding WSDL file contains the binding to the service provider along with its location. These bindings allow any number of implementations of business function to be described. In fact, it is possible that a single implementation can be described by multiple bindings.

Putting it All Together

What we have seen so far in this section is architecture for specifying services that support a number of inbound client types as well as multiple implementation technologies. We have seen WSDL used as the anchor for describing the various interfaces and implementations.

Initially, services can be developed by wrapping existing programs or Connectors. A varied set of inbound bindings can be expressed to allow access for various types of clients to these services. Each binding type comes with some inherent qualities of service and performance overhead. However, the pay-as-you-go strategy is evident here. If local Java access is needed, for example, an inbound binding can be created for that. This binding does not incur the overhead of a binding that would be present in a SOAP inbound binding. This flexibility should encourage the use of service based architecture because there is no fixed performance penalty inherent in such an architecture.

While this is all good, the service based approach is not the only architecture to be employed for what happens on the server. Underneath each of the services, we will still find the utilization of the full power of the J2EE programming model. In the next chapter, we will begin to dig into more details on how J2EE and web services complement each other.