The first wave of integrating storage, computing, and networking hardware helped businesses move from client/server to Internet-based peer-to-peer networks. A second wave of integrating applications on top of the hardware infrastructure promised to deliver unprecedented economies of scale. In today's enterprise IT model, applications exposed as services need to be integrated seamlessly with other applications distributed across the network to generate the best operational efficiencies. Messaging-oriented middleware is at the heart of enabling seamless or "effortless" integration between a business's core assets: its applications and data residing on the network.

However, integrating multi-vendor applications with diverse infrastructure and legacy applications is a daunting task. In a recent report -a leading analyst reports that Global 3500 firms will spend an average of $6.4 million each in 2007 on Service Oriented Integration and process management budgets, and less than 35% of the projects come in on time and on budget. So why are SOA project schedules so unpredictable? Incumbent first-generation SOA solutions consist of a patchwork of point products that are struggling to meet the performance, scalability, flexibility, and security demanded by modern distributed business applications. In contrast to an age of irrational exuberance, throwing more hardware and customized software at the problem is no longer a viable option for most businesses. Since early 2003, the Enterprise Service Bus (ESB) has emerged as a standards-based Services Orchestration Platform, typically built on a distributed peer-to-peer service-grid architecture that enables high-performance, scalable, and affordable SOA solutions.

A distributed Enterprise Service Grid typically consists of the following server components:

• Enterprise Server (ES): The ES forms a centralized repository for security policies, business process configuration and logs, monitoring, debugging facilities, and reusable services
• Peer Servers (PS): These lightweight servers can be installed on handheld devices as easily as on back-end enterprise servers. With a local store-and-forward service, PSs enable a peer-to-peer data transport thereby generating huge economies of scale
• MQServer: A standards-based JMS messaging server that supports an arbitrary number of PSs communicating with an arbitrary number of ESs - thereby enabling a brokered peer-to-peer services orchestration platform in which control information flows through a centralized server (the ES) while data flows concurrently between connected Peer Servers (PSs).
• Services Orchestration Tools: A set of developer-centric tools that enable the composition, governance, monitoring, debugging, and creation of reusable services.
• Built-in Adapters: ESBs typically include hundreds of available pre-built adapters for packaged as well as legacy applications.

Scalable Performance
Applications and data are the lifeblood of a business. Faced with dynamically changing customer, partner, and supplier requirements, businesses need to integrate a large number of applications - exposed as services - in multiple data formats across dispersed geographic locations. Traditional middleware integration solutions consist of Business Process GUIs hooked into a distributed services layer as shown below.

An arbitrary number of standalone applications can be integrated to represent a workflow that could model, for instance, a financial transaction processing package. The hub-and-spoke messaging middleware also uses standards-based protocols (TCP/IP, HTTP, and others) to process and manage the messages supporting a set of workflows.

All messaging traffic between distributed services consisting of control and data packets must traverse the HUB - also referred to as an Integration Server (IS). As traffic requirements scale, the IS becomes a performance bottleneck and a single point of failure. IS clusters can help create redundancies that increase availability - at a high cost of increased complexity and money. Most IS clusters rely on multicast mechanisms to relay messages. The multicast mechanism is very inefficient in terms of bandwidth use, especially when delivering certified/guaranteed messages - as demonstrated in several benchmarks. While composing services into composite applications remains the key value of an SOA solution, underlying hub-and-spoke architectures are weak in delivering scalable performance and guaranteed message delivery at high rates.

The Brokered Peer-to-Peer architecture of a modern distributed Service-Grid platform provides near-linear scalable performance at highly affordable costs. The distributed Service-Grid architecture splits up data traffic among an arbitrary number of lightweight peer servers and controls the traffic with enterprise servers supporting all centralized functions. An Enterprise Service Grid Network consists of Peer Servers (PS) connected to a set of Enterprise Servers (ES) via a JMS messaging backbone as shown in Figure 1.

As seen in Figure 2, the distributed peer-to-peer architecture of an Enterprise Service Grid provides several benefits:

1)  Store and Forward. Peer Servers (at $1k/each) with their local store/forward mechanisms and a micro-messaging server enable fine-grain control over the performance scalability of data traffic

2)  Enterprise-Class Backbone. JMS-compliant MQ servers typically support over 10,000 messages/sec and a large number of concurrent connections thereby providing a very scalable enterprise-class messaging backbone. With a dual-redundant configuration that supports failover, the MQ backbone deploys an arbitrary number of PS (data traffic) and ES (control traffic) at very affordable costs. This provides a build-as-you-grow scalability model with no downtime or added complexities.

3)  Enterprise Servers (ES) are constantly updated with all control traffic from any of the PS peers. The MQServer arbitrates between outgoing traffic from the ES to the PS servers and performs many-to-one de-multiplexing for this traffic. The JMS-compliant MQServer also typically supports sophisticated load-balancing algorithms such as round robin, weighted round robin, and Intelligent Load Balancing (ILB) - to provide the efficient use of all PS and ES deployments in the system. The distributed Service-Grid architecture inherently provides for a highly scalable performance envelope. SOA architects can achieve very fine-grained control to match their performance requirements without trading off scalability or reliability goals as measured by the following parameters:

• Number of messages per second (aggregate throughput through the system)
• Size of the messages (5KB, 100KB, 1MB, 5MB)
• Number of concurrent applications/users supported
• Messaging Quality of Service (MQOS): delivery class (normal v/s guaranteed delivery)
• MQOS: Total Latency (total application-to-application latency via Integration Servers)