Ask yourself a question: "Is throughput of my SOA environment impacting users?" If the answer is "yes", you're not alone. Based on several recent surveys of Global 2000 corporations, including reports published in 2005 by In-Stat/ Reed Elsevier Business Information Network and Summit Strategies, Inc., 76 percent of responders from financial services, transportation, telecommunication, and global manufacturing industries have identified throughput as one of the hottest issues they'll be grappling with in 2006 when developing and deploying SOA-driven enterprise software -- especially when using Web services.
The same responders have presented a similar picture as to why throughput is such an issue: business needs demand the handling of thousands of service requests per second (SRS) in real time or near-real time to update stock, dispatch financial and order information within enterprise boundaries and globally across the extended value chain. In addition to high volumes, SOA-based solutions often are required to permit message exchanges in a number of formats such as ACORD, IFX, and TINA, and through multiple protocols like HTTP or JMS, handle bottlenecks at peak times without reducing service levels, and provide a comprehensive audit trail.
At the heart of the SOA-enabling technologies like Web services are XML-based information exchanges between service requesters and service providers. XML has provided significant advantages, but these advantages come at the price of performance and throughput.
First, XML-encoded messages are larger than binary messages, by six to eight times, on average. And they are getting much larger -- entire documents, such as purchase orders with extended shipping information, credit reports, detailed maps, and product catalogs, are "flying" in-and-out. Message sizes of 40K bytes and over are common nowadays.
Second, message bindings to programmatic objects and data manipulations involving XML-encoding ultimately require more computation in comparison to data and/or object passing over RMI/IIOP, for example.
Often the end result is that a server at the service endpoint may not be able to handle the throughput the Web services network demands. The price for this is loss of service requests.
The throughput issue in high-volume (1000-plus SRS) systems is especially troublesome because it requires a multi-faceted solution, many components of which are still emerging. For example, the industry is working on a set of standards grouped under the label "fast Web services." These standards attempt to solve XML-encoding problems by defining binary-based messages that consume less bandwidth, are faster, and require less memory to be processed.
Meanwhile, increasing capacity is currently the most common approach to ensure high-throughput in systems with high-volume and heterogeneous messaging.
There are several ways to increase capacity. The first is to increase the physical resources available for consumption by service providers, that is, at the service endpoint side. Upgrading servers (for example, bringing more powerful hardware with more CPUs, or faster chips) or adding additional servers (for example, expanding horizontally or by using server clustering) are the most popular actions, although they are often expensive because of the increased recurring software expenses and high management costs.
Another approach is to use vertical scaling techniques to expand the number of available application server nodes (images) like with the multi-cell model introduced by WebSphere® Application Server Network Deployment. This approach can be effective, but, by itself, it just provides a "lift" in capacity for message processing with Web services (on average, the potential percentage increase of throughput is 25-35 percent) rather than multi-fold increases (many times over) in comparison to the existing throughput level. As a result, the immediate workload needs may be covered, but long-term capacity requirements remain unanswered.
So, is there anything that can be done on top of both horizontal and vertical scaling in order to contain capacity growth? And, is there a technology solution that is available to do it now? Fortunately, the answer to both questions is "yes."
The high-performance message-oriented middleware (MOM) community has long advocated intelligently disaggregating message processing tasks into smaller systems tied together to reinsure scalability. The ultimate goal here is to create an optimized computing environment that combines the best characteristics of traditional scaling methods -- the ability to scale applications vertically or horizontally, and architectural approaches that allow controlling many individual processes (such as XML processing, access to business objects, and access to enterprise data sources) in a distributed fashion -- deployed as an overlay network of application-level message processors.
Focus on the parts, not the whole; or, divide and conquer
Most of the current SOA technologies used for message handling processing are developed in the context of a sequential message interception model. Apache's Axis or similar frameworks are good examples, as in Figure 1:
Figure 1. Service enabler
As seen in Figure 1, a Web services enabler acts as an abstraction layer that provides various "channels" to access the needed services. The incoming XML message is assessed on arrival through a particular channel to determine the destination service. There could be multiple "filters" provided they are bound to the destination service that allows the interception and manipulation of both request and response message, for example, transforms one-format messages into new formats. Potentially, those filters serve as a policy enforcement layer where the message is first checked from the security and Quality of Service (QoS) standpoints, and then is queued for processing.
A channel is a logical path to service providers. Also, it may be utilized as a static "routing" switch. In SOA, the responsibility for channel selection belongs to the Web services enabler that, in turn, enables the service infrastructure to have more control over the application of filters, like with Axis' SOAP handler chains.
Although such a messaging model creates the perception of "disaggregated" messaging because different channels can be designed for different protocols, (for example, HTTP and JMS from the physical implementation standpoint), overall, the resulting architecture is monolithic in nature since it's supported entirely in the core system running as centralized servers or similarly configured server clusters.
Systems designed for large target audiences with diverse XML messaging are faced with highly non-linear utilization of functionality: at different points in time, some functionality, such as transforming message formats, is utilized by a small percentage of the workload versus all of the other functionality. Broadly speaking, incorporating all of the message processing functionality into the core platform makes it unnecessarily "overcommitted," which creates unreasonable workload expectations and increases the scalability challenges for the platform.
Consequently, architectural approaches where the development of a XML message processing layer requires the understanding of each of the underlying service components are inappropriate. Instead, a divide-and-conquer approach should be adopted, whereby components addressing similar client needs, such as security enforcement or transformation, are grouped together, and these groups are deployed separately across the network of servers.
In a nutshell: Segmenting the XML message workload into "like" functions and using processing resources according to the functional segmentation is critical to producing consistent response times, and it is absolutely necessary for ensuring high throughput levels in Web Services-based systems.
The application of the segmenting workload technique is commonly used in the J2EE architecture. For example, often the segmentation is directly applied along the presentation (Web server) and business tiers -- that is, these tiers are often separated and supported by different servers.
But, in the context of high-volume Web services, segmentation needs to be applied at a more granular level -- separating message processing into segments that can be more easily tuned, and therefore provide more consistent scaling and response times, even if such technique may require more complex service management mechanisms.
Sure, if segmentation of XML messaging were easy, it would be more pervasive today. An issue with this technique is how to implement the segmentation. Most importantly, the architecture calls for a multi-tiered approach for intercepting XML messages. How do we do it correctly? Also, after segmenting the workload, additional infrastructure might be required to balance physical workload among the segments. That brings another question, "What is the most cost-effective scheme for segment-oriented load balancing?" The following discussion will answer some of those questions, and give you tips and tricks for tackling the problems with SOA messaging.
Two predominant architectural patterns are used for XML message processing in SOA environments, depicted in Figure 2:
- Message interceptor gateway pattern - for centralizing and coordinating XML message-related tasks before the Web services tier; it is similar to the facade or adaptor patterns; it plays the role of a "proxy" (front-end) to the Web Services infrastructure for performing the bulk of message processing tasks like security enforcement or mediation before messages reach service endpoints, or in other words, intercepting messages coming in to a service.
- Message inspector pattern - for performing XML message-related tasks entirely within the Web services tier, that is, processing messages after they have arrived at a service.
Figure 2. Message processing
The message interceptor gateway pattern is commonly used to handle Web service invocations between Internet and intranet environments. Specifically, it is applied when making internal Web services available outside the enterprise boundaries, and making external Web services available to internal systems.
One of the main advantages of the gateway pattern is that it allows for services to be offered over protocols that they were not originally designed for. Also, if there are several different implementations of the same service, a mechanism for choosing the most appropriate target service for each incoming request can be implemented within the gateway.
The message inspector pattern is used to handle Web service invocations within enterprises, for intra-enterprise purposes. This pattern is most effective for validating parameters before invoking a transaction. The validation of application-specific parameters includes validating XML schemas, and associated aspects of business data and its characteristics such as data type such as string or integer, format, length, range, and verifying for character-set, locale, context, and allowable values (especially, null values handling).
In terms of pattern implementations, the most common implementation technique for both patterns is to use JAX-RPC handlers that have been defined by JSR 101 and 921 (see Resources). JAX-RPC handlers are becoming widespread because, regardless of whether handlers are deployed inside or outside the Web services tier, they can provide fine-grained interrogations of SOAP-formatted messages, whether over HTTP or JMS, including bi-directional modifications of most elements of SOAP body and headers. However, JAX-RPC has limitations. Most importantly, it is usable only for SOAP-formatted messages, and it cannot modify message part types or sequence of message interrogations that is sometimes critical in high-volume situations.
What does WebSphere Application Server V6 bring to the table?
Let me reiterate the essence of the introduced architectural approach based on the "divide and conquer" principle. The approach is all about providing XML message processing capabilities with both of the above patterns, and enabling those capabilities to be delivered in a distributed, over-the-network fashion that takes full advantage of the heterogeneity that makes SOA unique.
This architectural approach represents the evolution of the concept of separation of concerns within the application logic tier, specifically, between application logic, which deals in "service functionalities" as complete units of available application functionality, and application logic, which deals in "service presentation" -- how to present to a service consumer the best available service regardless of how the actual request is formulated and over which protocol it is delivered.
You may say, "Wait a minute. Isn't that what an Enterprise Service Bus (EBS) is all about?" If we would consider ESB to be an architectural pattern, not a particular technology, then the answer is "yes." In terms of functionality, EBS is a "front-end" to service endpoints positioned to provide protocol/transport mappings, security functions, mediation of message structure, auditing of SOAP messages, and so on. But, unfortunately, the current commercial ESB implementations do not provide an easily configurable option for segmenting functions and distributing segments across the network of server containers like, for example, Java Virtual Machines. But, if we would consider ESB to be not just a pattern but a specific technology, then an implementation of segmentation-oriented messaging architectures, similar to that described here, can not be equated with traditional ESB technologies. Furthermore, implementations of segmentation-oriented architectures for SOA should be viewed as beyond ESB. So, there is no turn-key technology yet that explicitly implements segmentation according to the presented architecture patterns.
However, what is interesting from the practical implementation standpoint, WebSphere Application Server Version 6 provides the necessary capabilities for segmenting and distributing message processing across multiple server containers. Let's examine this point in detail.
WebSphere Application Server V6 is the first release of WebSphere Application Server that explicitly addresses the subject of message segmentation. WebSphere Application Server V6 has originated a new framework, referred to as "Service Integration Bus" or SIBus. The SIBus is positioned to play the role of a distinct layer (logical and also physical, if needed) between service requestors and service providers, enabling both interception and inspection of messages for purposes of protocol switching, security support, routing, and transformation of messages.
The SIBus provides more than what normally constitutes an ESB for the following key reasons:
- It uses familiar JAX-RPC handlers and something new -- so-called "mediators" -- in one framework, enabling direct application control over both SOAP and non-SOAP messaging.
- It takes the existing service destinations and replaces them dynamically and seamlessly with newly generated endpoints using so-called "inbound and outbound" Web services.
- It allows configuring gateway and proxy services for instituting a single point of control over incoming Web services requests in order to perform protocol transformation between messages (for example, switching between SOAP/HTTP and SOAP/JMS services). Introduced in WebSphere Application Server Version 5, the Web Services gateway is extended in WebSphere Application Server Version 6 to allow more than one target service for a single gateway service endpoint. Furthermore, multiple gateway instances can be defined in order to partition or segment gateway and proxy services, allowing easy scaling.
- It provides a specific construct for grouping of the EIBus resources called Buss Objects. A Buss Object, also referred to as "buss" in the WebSphere Application Server Version 6 documentation, is a logical grouping construct, upon which all other resources (gateway/proxy services, mediators, inbound/outbound services, and so on) are defined.
What can be done with mediators?
An EIBus mediator is a stateless session EJB that implements the com.ibm.websphere.sib.mediation.handler.MediationHandler interface and relies on some specific deployment descriptor configuration details, identifying it as an EIBus mediator. Mediators can be used in addition to JAX-RPC handlers, especially, when it is necessary to:
- Transform a message from one format to another, especially, when dealing with complex industry-specific format transformations (such as ACORD-to-from-IFX).
- Access and augment message content to add or remove data, or repackage message parts of the reply (outbound) XML documents.
- Select the most appropriate target service by redirecting ports.
The process of creating a mediator is similar to creating any EJB. It starts with creating an enterprise application containing an EJB that will play the role of a mediator. Then, a mediation handler class needs to be created that will implement the com.ibm.websphere.sib.mediation.handler.MediationHandler interface, and the needed logic is added to this class. Finally, the EJB deployment descriptor is updated to add the newly created mediator to the mediation handler list. Mediation handler lists may contain one or more mediations, and they control the order in which mediations are executed.
EIBus mediators can be associated with any destination within a particular bus to create a mediated destination. For example, you can associate a mediator with a gateway service for processing request and reply messages, or with an outbound service to orchestrate dynamic port selection/redirection to the most appropriate target service. Nevertheless, considering the context of this article is "segmentation" of message processing, mediators are the most appealing for implementing the message inspector pattern.
The core segmentation patterns with WebSphere Application Server V6
Figure 3 illustrates the core segmentation patterns realizable with WebSphere Application Server V6. Figure 3 pins down the following two key points:
- Use of the Web Services Gateway together with inbound services as an interceptor allows you to apply the same handler and mediation list across a large number of different service consumers requesting information from multiple target Web Services over different bindings (SOAP/HHTP or SOAP/JMS); the gateway eliminates a need of having to create individual interceptor-type (or proxy) services for each type of consumer-target service interactions.
- Use of outbound services in conjunction with outbound services with mediation lists allows applying a single transformation or configuration resource to many Web Services.
Figure 3. Segmentation patterns
The following real-world scenario illustrates those approaches and how to adopt a segmentation-oriented pattern-based architecture as shown in Figure 3 for high-volume SOA systems:
Presume we are dealing with a credit evaluation and authorization system that serves:
- Banks
- Insurers
- Car dealerships
- Apartment renters
- Etc.
Since we are dealing with highly confidential nature of information provided by the system, the key business problems related to message processing in this scenario can be categorized as follows:
- Instituting a common security processing capability -- authentication/ authorization of requests, message origin verification, and, probably, enabling element level security (not all credit information should be made available to all of the consumers).
- Providing for message logging and auditing.
- Providing for message interoperability -- since multiple different consumers need to be served, support for multiple formats for message exchanges should be enabled (for example, IFX for servicing banks, ACORD - insurers, proprietary - renters, and so on.)
- Providing message routing to multiple endpoints based on payload size and message representation (for example, some requests may require a full credit report to be sent back; others, just the credit score).
Figure 4 depicts one of the potential architecture strategies for handling the cited scenario. This strategy uses the pattern "A" illustrated in Figure 3 - Using Web Services Gateway. As depicted in Figure 4, the strategy is based on creating channels for different bindings tightly coupled to the mediator hierarchy that governs all possible transformation choices across the consumers and service providers. Such a strategy results in a design capable of optimizing the service distribution mechanism to work with different levels of filtering (subject, content, content plus rules) or to support different formats of message payload, such as XML, PDF and JPEG.
Figure 4. Optimizing the service distribution mechanism
Although EIBus introduced in WebSphere Application Server V6 is primarily a logical construct, it could be externalized physically with WebSphere Application Server clusters. When externalized physically, a single bus can play the role of a group of one or more interconnected WebSphere Application Server V6 servers or clusters, acting as the group of messaging engines associated with certain properties or capabilities defined as the group members such as inbound/outbound services, mediators, or JAX-RPC handlers. Applications connect to one of the messaging engines implemented using depicted in the article patterns, and then access the group's properties.
- Participate in the discussion forum.
-
Check out IBM Redbook, "WebSphere Version 6 Web Services Handbook - Development and Deployment", on how to configure and work with the Web Services Gateway in the SIBus.
-
Get familiar with Configure a Service Integration Bus in a network deployment environment to learn how to install and configure an IBM WebSphere Application Server V6.0.x cluster for different patterns (developerWorks, March 2005).
-
Check out the WebSphere Application Server zone on developerWorks for related information on working with the SIBus.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
