SOA platform basics

Before we begin to look at the specifics of the J2EE and .NET platforms, let's first establish some of the common aspects of the physical development and runtime environments required to build and implement SOA-compliant services.

18.1.1. Basic platform building blocks

Taking a step back from SOA for a moment, let's start by defining the rudimentary building blocks of a software technology platform. The realization of a software program puts forth some basic requirements, mainly:

• We need a development environment with which to program and assemble the software program. This environment must provide us with a development tool that supports a programming language.
• We need a runtime for which we will be designing our software (because it provides the environment that will eventually host the software).
• We need APIs that expose features and functions offered by the runtime so that we can build our software program to interact with and take advantage of these features and functions.
• Finally, we need an operating system on which to deploy the runtime, APIs, and the software program. The operating system interfaces with the underlying hardware and likely will provide additional services that can be used by the software program (through the use of additional APIs).

Each of these requirements can be represented as a layer that establishes a base architecture model (Figure 18.1).

Figure 18.1. Fundamental software technology architecture layers.

 

18.1.2. Common SOA platform layers

As we established early on in this book, contemporary SOA is a distributed architectural model, built using Web services. Therefore, an SOA-capable development and runtime platform will be geared toward a distributed programming architecture that provides support for the Web services technology set.

As a result, we have two new requirements:

• We need the ability to partition software programs into self-contained and composable units of processing logic (components) capable of communicating with each other within and across instances of the runtime.
• We need the ability to encapsulate and expose application logic through industry standard Web services technologies.

To upgrade our fundamental architecture model so that we can build service-oriented solutions, we need to add new layers to represent the requirements we just identified (Figure 18.2).

Figure 18.2. The common layers required by a development and runtime platform for building SOA.

 

18.1.3. Relationship between SOA layers and technologies

When we introduce components and Web services to our architecture model, we end up with a number of different relationships forged between the fundamental architecture layers and the specific technologies introduced by the Web services framework (namely, WSDL, SOAP, UDDI, and the WS-* specifications).

To better understand these dynamics, let's briefly review the requirements for each of the primary relationships.

• The Web Technology layer needs to provide support for the first-generation Web services technology set to enable us to build a primitive SOA.
• The Web Technology layer needs to provide support for WS-* specifications for us to fulfill some of the contemporary SOA characteristics.
• The Web Technology layer needs to provide a means of assembling and implementing its technology support into Web services.
• The Component Technology layer needs to support encapsulation by Web services.
• The Runtime layer needs to be capable of hosting components and Web services.
• The Runtime layer needs to provide a series of APIs in support of components and Web services.
• The APIs layer needs to provide functions that support the development and processing of components and Web services technologies.

Figure 18.3 illustrates these relationships.

Figure 18.3. A logical view of the basic relationships between the core parts of a service-oriented architecture.

 

18.1.4. Fundamental service technology architecture

So far we've established the overall pieces that comprise a fundamental, abstract service-oriented architecture. What is of further interest to us are the specifics behind the relationship between the Web Technology and Component Technology layers.

By studying this relationship, we can learn how service providers and service requestors within an SOA can be designed, leading us to define a service-level architecture.

Service processing tasks

As we've established in previous chapters, service providers are commonly expected to perform the following tasks:

• Supply a public interface (WSDL definition) that allows it to be accessed and invoked by a service requestor.
• Receive a SOAP message sent to it by a service requestor.
• Process the header blocks within the SOAP message.
• Validate and parse the payload of the SOAP message.
• Transform the message payload contents into a different format.
• Encapsulate business processing logic that will do something with the received SOAP message contents.
• Assemble a SOAP message containing the response to the original request SOAP message from the service requestor.
• Transform the contents of the message back into the format expected by the service requestor.
• Transmit the response SOAP message back to the service requestor.

Service providers are designed to facilitate service requestors. A service requestor can be any piece of software capable of communicating with a service provider. Service requestors are commonly expected to:

• Contain business processing logic that calls a service provider for a particular reason.
• Interpret (and possibly discover) a service provider's WSDL definition.
• Assemble a SOAP request message (including any required headers) in compliance with the service provider WSDL definition.
• Transform the contents of the SOAP message so that they comply with the format expected by the service provider.
• Transmit the SOAP request message to the service provider.
• Receive a SOAP response message from the service provider.
• Validate and parse the payload of the SOAP response message received by the service provider.
• Transform the SOAP payload into a different format.
• Process SOAP header blocks within the message.

Service processing logic

Looking at these tasks, it appears that the majority of them require the use of Web technologies. The only task that does not fall into this category is the processing of business logic, where the contents of the SOAP request are used to perform some function that may result in a response. Let's therefore group our service provider and requestor tasks into two distinct categories.

• Message Processing Logic The part of a Web service and its surrounding environment that executes a variety of SOAP message processing tasks. Message processing logic is performed by a combination of runtime services, service agents, as well as service logic related to the processing of the WSDL definition.
• Business Logic The back-end part of a Web service that performs tasks in response to the receipt of SOAP message contents. Business logic is application-specific and can range dramatically in scope, depending on the functionality exposed by the WSDL definition. For example, business logic can consist of a single component providing service-specific functions, or it can be represented by a legacy application that offers only some of its functions via the Web service.

Note

There is no association between the terms "business logic" and "business service." Every type of Web service (application service, business service) has underlying business logic.

Viewing a service provider in this manner allows us to logically partition the service logic, as shown in Figure 18.4.

Figure 18.4. A service provider consisting of message processing and business logic.

We now can divide the original service provider tasks into these two categories, as shown in Table 18.1.

Table 18.1. Service provider logic categorization.

Message Processing Logic	Business Logic
SOAP message receipt and transmission.	Application-specific business processing logic.
SOAP message header processing.
SOAP message payload validation and parsing.
SOAP message payload transformation.

These groups represent logic only, including the messaging logic required to process the WSDL definition. But what about the WSDL itself? This critical piece of a service needs to be distinctly identified, as it relates to and affects a great deal of the surrounding messaging processing logic. To keep things simple we will group the WSDL with other metadata documents (such as policies and schemas) and classify them collectively as the endpoint.

Note

What is represented by the term "endpoint" often varies in different vendor platforms. For the purposes of this book, an endpoint is an implementation of the metadata that comprises the technical service contract. Also note that we only identify the endpoint with a service provider. Although a service requestor may be a Web service in its own right (and therefore also classifiable as a service provider), the endpoint is of most interest to us when a service acts as a service provider.

As shown in Figure 18.5, the endpoint is not located in front of the service message processing logic. Instead, it is wedged within the message processing logic block because some of the runtime components that comprise the message processing logic may be executed prior to the endpoint being contacted by an incoming message. (Examples of this are provided later in this section.)

Figure 18.5. A revised service provider model now including an endpoint within the message processing logic.

Let's move on to the service requestor. As shown in Figure 18.6, the primary difference between how service logic is used in requestors and providers is related to the role of business logic. The business logic part of a service requestor is responsible for initiating an activity (and the resulting SOAP message exchange), whereas the business logic within a service provider responds to an already initiated activity.

Figure 18.6. A service requestor consisting of message processing and business logic.

Table 18.2 revisits the original service requestor tasks and displays abbreviated versions, categorized into two groups.

Table 18.2. Service requestor logic categorization.

Message Processing Logic	Business Logic
WSDL interpretation (and discovery).	Application-specific business processing logic.
SOAP message transmission and receipt.
SOAP message header processing.
SOAP message payload validation and parsing.
SOAP message payload transformation.

 

Message processing logic

Let's now take a closer look at the typical characteristics of the message processing logic of a service provider and service requestor. This part consists of functions or tasks performed by a combination of runtime services and application-specific extensions. It is therefore not easy to nail down which elements of the message processing logic belong exclusively to the service.

For example, Figure 18.7 shows some common processing layers represented by the message processing logic of a service provider. Among these layers are tasks, such as header processing, that are generic and applied to all service providers. Validation or transformation tasks, on the other hand, may involve service-specific XSD schemas and XSLT stylesheets and therefore may be considered exclusive to the service provider (even though validation and transformation tasks themselves are executed by generic runtime processors).

Figure 18.7. An example of the types of processing functions that can comprise the message processing logic of a service.

Although the message processing logic for service requestors and service providers may be similar, there is an important implementation-level difference. The service provider supplies an endpoint that expresses an interface and associated constraints with which all service requestors must comply.

Vendor platforms accomplish this by supporting the creation of proxy components. These components exist as part of the message processing logic (Figure 18.8) and are commonly auto-generated from the service provider WSDL definition (and associated service description documents). They end up providing a programmatic interface that mirrors the WSDL definition but complies to the native vendor runtime environment.

Figure 18.8. The message processing logic part of a service requestor includes a proxy component.

Proxies accept method calls issued from the regular vendor platform components that contain the service requestor business logic. The proxies then use vendor runtime services to translate these method calls and associated parameters into SOAP request messages. When the SOAP request is transmitted, the proxy is further able to receive the corresponding SOAP response from the service provider. It then performs the same type of translation, but in reverse.

Note

Proxies can exist as static components or they can be dynamically created. Vendor-specific proxy components are discussed further in the J2EE and .NET sections.

 

Business logic

As we previously established, business logic can exist as a standalone component, housing the intelligence required to either invoke a service provider as part of a business activity or to respond to a request in order to participate in such an activity.

As an independent unit of logic, it is free to act in different roles. For example, Figure 18.9 shows a unit of business logic being encapsulated as part of a service provider but also acting as a service requestor.

Figure 18.9. The same unit of business logic participating within a service provider and a service requestor.

If units of business logic exist as physically separate components, the same business logic can be encapsulated by different service providers, as illustrated in Figure 18.10.

Figure 18.10. One unit of business logic being encapsulated by two different service providers.

Because units of business logic can exist in their native distributed component format, they also can interact with other components that may not necessarily be part of the SOA, as shown in Figure 18.11. This, in fact, is a very common model in distributed environments where components (as opposed to services) are composed to execute specific tasks on behalf of the service provider.

Figure 18.11. The same unit of business logic facilitating a service provider and acting on its own by communicating independently with a separate component.

Note that the service business logic shown in Figure 18.11 may be interacting with a separate native component to complete the processing requested by the service requestor. In this case the second component can be considered as belonging to the overall automation logic encapsulated by the service provider.

Service agents

A type of software program commonly found within the message processing logic of SOA platforms is the service agent. Its primary role is to perform some form of automated processing prior to the transmission and receipt of SOAP messages. As such, service agents are a form of intermediary service.

For example, service agents that reside alongside the service requestor will be engaged after a SOAP message request is issued by the service requestor and before it actually is transmitted to the service provider. Similarly, requestor agents generally kick in upon the initial receipt of a SOAP response, prior to the SOAP message being received by the remaining service requestor logic.

The same goes for service agents that act on the service provider's behalf. They typically pre-process SOAP request messages and intercept SOAP response messages prior to transmission.

Service agents usually address cross-cutting concerns, providing generic functions to alleviate the processing responsibilities of core Web service logic. Examples of the types of tasks performed by service agents include:

• SOAP header processing (Figure 18.12)
• filtering (based on SOAP header or payload content)
• authentication and content-based validation
• logging and auditing
• routing

Figure 18.12. Service agents processing incoming and outgoing SOAP message headers.

An agent program usually exists as a lightweight application with a small memory footprint. It typically is provided by the runtime but also can be custom developed.

Note

What's the difference between a service agent intermediary and an intermediary Web service? The determining factor is typically the availability of a WSDL endpoint. Service agents don't generally have or require one, as they are designed to intercept message traffic automatically. An intermediary that is also a Web service will supply a published WSDL definition, establishing itself as a legitimate endpoint along the message path. Note that a service agent intermediary can be designed to also be a Web service intermediary.

 

18.1.5. Vendor platforms

Let's now explore SOA support provided by both J2EE and .NET platforms. The next two sections consist of the following sub-sections through which each platform is discussed:

• Architecture components
• Runtime environments
• Programming languages
• APIs
• Service providers
• Service requestors
• Service agents
• Platform extensions

Because we are exploring platforms from the perspective that they are comprised of both standards and the vendor manufactured technology that implements and builds upon these standards, we mention example vendor products that can be used to realize parts of a platform.

Even though every effort has been made to provide a balanced and equal documentation of each platform, it should be noted that the difference in vendor support required that some of the documentation be approached differently. For example, because J2EE is a platform supported by multiple vendors, multiple vendor products are mentioned. Because .NET is a platform provided by a single vendor, only that vendor's supporting products are referenced.