Spaced-Based Architecture by GigaSpaces

Posted on | 22 April 2008 |
Tags: gigaspaces | java | soa

Lately, I’ve been researching Space-based Architecture as provided by Gigaspaces. I am especially interested in this because I believe that scalability will become a more and more prominent issue as applications deal with an increasing amount of data.

In a service oriented architecture, the services are loosely coupled to each other with the promise of reusability and improved performance in a distributed environment. However, while services are usually stateless, a business process (use case) often span more than one service, which communicate via a centralized component: a database or a messaging provider. In a tier-based architecture, problems with scalability may negate any improvements made by the distribution of services. Gigaspaces provides a solution in the form of XAP (eXtreme Application Platform), an application server built to enable linear scalability. Linear scalability means a one-to-one ratio between machines added to the deployment and the performance gained, making scaling predictable in costs and effort.

GigaSpaces argues that tier-based architecture is the nemesis to linear scalability. In fact, the architecture itself is the bottleneck, not unoptimized component. This is because in a tier-based architecture, as scability patches are introduced, the communication between the tiers become more complicated and expensive. The complex interaction between tiers and between physical machines in the deployment cause problems with latency and data consistency. Possible problems with tier-based architecture are bottlenecked access to the database, bottlenecked access to a centralized messaging provider, messaging overhead, network latency, inefficient clustering, and unreliable failover recovery. GigaSpaces addresses each of those problems by providing a platform that enables space-based architecture.

The whitepaper, “Scaling Spring Applications in 4 Easy Steps”, introduces a four-step approach to achieve the implementation of a space-based architecture.

1) Virtualizing Data
In the first step, virtualizing the database using the IMDG (In-Memory Data Grid) reduces I/O latency to the database. The IMDG (In-Memory Data Grid) provides consistency, availability, and reliability of application state and can be made as reliable as needed - from keeping in memory for fast access, to asynchonous batch writing to database, to direct write/read. It is not only more efficient, but more reliable than a database, by providing failover recovery and memory usage monitor to prevent memory crashes, which helps in tracing memory problems. Although virtualizing the database reduces I/O latency, the need for each tier to access a centralized messaging provider and the need for two-phased commit of distributed transactions when using a centralized transaction manager are still bottlenecks in the system.

2) Virtualizing Messaging
In the second step, virtualized messaging is achieved by creating a data bus to consolidate messaging and data in the same place. The data bus is implemented in the IMDG as a JMS façade acting as the messaging provider. This requires minimal changes to applications using the JMS API. Data affinity, or colocating related data, removes the need for a distributed transaction manager.

3) Virtualizing Application
The third step towards a space-based architecture is to create self-sufficient processing units by packaging the business logic together with the data and messaging middleware. In practice, this means putting all the services required for an entire business process in one processing unit. Because each processing unit is self-sufficient, requiring no external component access, packaging business logic, messaging, and data together enables linear scaling and minimal latency. XAP takes care of content-based routing and automatic detection of service availability to enable dynamic scaling. Within a processing unit, the business logic is hooked into the messaging and data middleware with the “polling container”, which allows the business logic to be notified of changes with the messaging/data space.

4) Virtualizing Deployment
The fourth and final step is virtualizing deployment using the OpenSpaces Deployment Framework, which provides the administrator an overview of the entire deployment scope. The OpenSpaces Deployment Framework uses a SLA(Service Level Agreement)-driven container to dynamically scale up (or down) application resources bundled in processing units and to adhere to the service-level agreements by automatically detecting and recovering from failures.

The above four steps effectively transitions an existing application to a space-based architecture. The beauty of it is that using GigaSpaces’ XAP is completely transparent to all concerned - to the designer, developer, administrator, and client. An application deployed in XAP acts as one single server.

References:

Comments