In the enterprise IT environment today, modern middleware technologies make it easier to expose existing or new business applications as sets of services. However, with the mashup of cloud-based services and enterprise data center services, the visibility of how a service created today will be used in the future gets murkier.

This is because it's difficult to predict how a service will be consumed over long periods of time and by which consumers, and further how the service may be integrated with other services or legacy applications to create new composite services. It also remains a challenge to architect services in such a way that service upgrades don't affect consumers unpredictably. The hype of "just create services with an Enterprise Service Bus (ESB) and you'll have the benefits of a service architecture such as lower costs and software reuse" typically leads to services proliferation and little reuse.

Does this sound familiar? How many architects try to solve this problem simply with hardware-based XML and security gateway appliances as a point of control? The prevailing theory is that any change in consumer behavior or the service itself can be easily mediated at such a device since it requires no coding. "Most" changes can be made through XML-based policy changes. Hardware appliances, however, are inflexible, expensive, and miss the mark against widespread data center trends such as virtualization and cost reduction through capital (server) reuse.

Usage Models for Service Intermediaries
Service reuse is a tough nut to crack because it requires addressing the service architecture at the infrastructure level. But is a hardware appliance the right choice? Initially designed to address problems around XML processing, hardware XML and security gateway appliances have morphed their offerings often enough that they're become the middleware "gold dust" that makes life easier for rest of the IT environment. Deploying these hardware appliances in data centers was an unfortunate reality of moving to a services architecture due to security, performance, and governance concerns. While the data centers have moved towards consolidation to reduce power, heat, and maintenance costs through application virtualization and even network virtualization, the apparent need for hardware appliances sticks out like a sore thumb.

Let's clear the cobwebs. What need are we trying to address with hardware appliances? For starters, in a service-based environment, we may need to know the answers to several operational questions like who is using the service and which version are they using? Are the consumers authorized to use this service? Is the service provisioned to handle the load coming from this new consumer? Can service interactions be assured of conforming to business application usage policy? Can the operators see the consolidated exceptions to the policy compliance? Can the XML data transformations required in the service interaction be accelerated for better scalability? Is the proper level of security being enforced in these service interactions? Can all of this be done outside of the service container environment so the necessary level of decoupling between services and their usage criteria is maintained to ensure maximum reuse? These questions can all be categorized as service governance-related requirements.

The next level of usage of XML and security gateway appliances is best described as a service mediation usage model. In these scenarios some of the ugly underbelly of a services architecture gets addressed. The service consumers may be interested in asynchronous communication with a service designed for a request/response message model, the service consumer may have a different transport support requirement than that supported by the consumer, and worse still, either the producer or consumer may not be a service at all, but rather a legacy application that must be bridged due to business requirements. Service mediation scenarios can be addressed by ESBs, however, SOA appliances claim to offer easier options in terms of time and resource requirements to get the job done.

Limitations of Hardware XML & Security Gateway Appliances
Since the first XML and security gateway appliances were released by early start-ups such as Sarvega and Datapower (later acquired by Intel and IBM, respectively), the IT landscape has shifted markedly.

For one, the hardware architecture has evolved rapidly. General-purpose computing is moving aggressively towards a multi-core environment. We are looking at 16- or even 32-core processors soon. On the other hand, most SOA middleware technologies still aren't ready to fully utilize multi-core and the underlying virtual machines require a significant rewrite that's a few years away. For most business computing using SOA, the challenge in multi-core environments is figuring out which components of the processing can be parallelized and how to avoid race conditions.

On the other hand, in this economic environment, the strong gets stronger and weak companies go out of business. Data centers continue to consolidate and get bigger, with increased focus on green IT that requires less cooling and space. Virtualization as a core data center trend is growing larger - with the addition of cores the ability to host multiple application servers on single-server hardware allows for more efficient data center usage.

In such a changing environment, slow-to-evolve and non-extensible point appliances for service governance, integration, and security with specialized XML hardware are unlikely to be the best route for enterprise SOA.

The financial constraints on IT are likely to become even more severe, resulting in a search for options that deliver performance and functionality. These options must avoid the upfront expense of customized hardware appliances, with their expensive data center footprint, specialized server node overhead, and high upgrade costs.

Soft Appliance - The Next Generation of Service Mediation Infrastructure
In this changing environment, a multi-core optimized software infrastructure with a common service runtime proves advantageous. This form factor offers governance, integration, mediation, and "headless" manageability - delivering dramatic efficiencies from an operations standpoint. The soft appliance should be deployable alongside service containers in the same native or virtual machine, or in a virtual container by itself, or on a standalone server node. In all cases the soft appliance should deliver the same performance as a specialized hardware appliance at a lower price point.

Intel's Software and Services Group has released such a tool in SOA Expressway that is highly tuned for the multi-core architecture and provides the full service governance, integration and mediation functionality with an Eclipse-based design-time environment. It makes a services architecture deployment in a multi-core environment significantly scaleable and manageable.

Just like hardware appliances, it's deployable on general-purpose servers in minutes rather than days. For common service intermediary patterns, it requires no coding. The software appliance offers a "service router"-style architecture, delivering mediation capabilities that can deal with heterogeneous service and legacy environments, as well as different messaging patterns supported in service interactions. The product offers common shared security enforcement for XML threat protection, identity verification, authorization, access control, and auditing. It can be deployed to use its Eclipse-based governance infrastructure or can be used in conjunction with other design-time SOA governance solutions from major software providers. The service router is unique in its ability to take highly normalized and unstructured information and bind that information to new abstract schemas that better match the business systems that use them, such as a single representation of customer data, order information, or a product.

While leveraging traditional runtime and design-time SOA governance technology works fine for smaller domains, enterprise-wide service governance must manage both policies and services at high transaction volumes without becoming the bottleneck. Here again Intel's SOA Expressway makes it possible without resorting to customized hardware appliance by scaling service mediation and XML processing on multi-core.

We'll review three different performance scenarios to evaluate the performance of SOA Expressway as a service intermediary on a multi-core architecture. The detailed methodology and test cases used will be made available at the Intel SOA Products web site. We used SOA Expressway's Eclipse-based Service Designer to visually create and test the service policies for the governance and mediation scenarios.

The Intel SOA Expressway was configured on two separate quad-core dual processor machines (8 cores), first one based on Quad-Core Intel Xeon Processor 5400 and second on the Intel's new Intel Core i7 processor ( both machines with 2 quad-core processors for a total of 8 cores and running Red Hat Linux 2.6 with 8GB or higher memory) platform. We tested for both the absolute highest throughput and highest throughput at lowest latency to observe the scalability of the solution on both platforms.

For the service mediation scenario, we used a REST-like XML-over-HTTP service to process purchase orders (see Figure 1). Intel SOA Expressway was configured to act as a mediation solution for this service with a policy to validate the XML payload defined by the XML schema definition The policy then transforms the purchase orders to a normalized form using XSL and updates the billing address. The policy then validates the resulting transformed output message for schema conformance and routes the message to the right instance of the back-end service based on the country to which the order is being shipped. As Figure 2 shows the Intel Xeon Processor 5400 based server demonstrated a performance of 8,600 tps at an average latency of 5.17 msec, while the Intel Core i7 processor based server demonstrated the best throughput of 12500 tps at about the same average latency. Compared to many hardware appliances, this performance is 300-500% better without requiring any customized hardware.

For the service governance scenario, we created a set of SOAP 1.1 doc/literal style purchase order Web Services and hosted them in Apache Axis2. These services exposed methods for creating, canceling, updating, and sending purchase orders. Intel SOA Expressway was configured to act as an SOA governance solution with a policy that required SOAP 1.1 schema validation and SOAP body payload validation on the incoming request, forwarding the request to the purchase order Web Service, and applying digital signatures and encryption on response. The signature policy used was WS-Security with RSA-SHA1 and exclusive canonicalization, and for encryption, the policy was WS-Security with 3DES-CBC applied to the SOAP body.

Three sets of tests were run for governance: A pass-through case (pure service virtualization), schema validation only, and then the full governance workflow (see Figure 3) (validation and WS-Security with signatures and encryption). To configure the policy SOA Expressway obtains the service definition and policy definition from a registry/repository and then virtualizes the service. This is done in a proxy mode by changing the service definition to point to the address of the virtual service container and provisioning a policy that defines the real service container as the destination for the request.

While we can imagine more complex service mediation and SOA governance scenarios such as XML threat protection, authentication, authorization, and FIFO processing, the scenarios used in this test showcase some of the more compute-intensive operations. These tests demonstrate that a new generation of service intermediaries optimized for general-purpose multi-core servers can address very high-end transaction processing volumes (see Figure 4).

Platform Test Details

• Intel® SOA Expressway v2.0 on Intel Xeon
• Dual Processor Intel(R) Xeon(R) CPU X5560
  @ 2.80GHz Nehalem-EP
• Manufacturer: Supermicro
• Memory: 6x2GB 1333 DDR3 RDIMMs (12G total)
• Operating System: Red Hat Linux AS 4
• Intel® SOA Expressway v2.0 on HP ProLiant
• Platform: HP ProLiant DL360 G5
• Dual Processor
• Manufacturer: HP
• Memory: 4x2GB FBD PC2-5300 (8G total)
• Client: High performance generic HTTP Linux client
• Server: Standard low-latency HTTP web server
• 4X Quadcore: Genuine Intel(R) CPU @ 2.40GHz
• Memory:  16G
• Red Hat Linux AS4
• Default settings were used for Intel® SOA Expressway

Footnotes:
Performance tests and ratings are measured using specific computer systems and/or components and reflect the approximate performance of Intel products as measured by those tests. Any difference in system hardware or software design or configuration may affect actual performance. Buyers should consult other sources of information to evaluate the performance of systems or components they are considering purchasing.