This section describes SBA from an application development perspective. It focuses on developing a high-throughput, event-driven, service-oriented application using GigaSpaces XAP and Space-Based Architecture.
Let's take a trading order management application as an example, to understand Space-Based Architecture and its application to GigaSpaces XAP. It is a classic case of an application with highly demanding scalability and latency requirements, in a stateful environment.
A trading application usually consists of a data feed i.e. trade requests, which flow into the system in a standard financial format (e.g. FIX). These feeds need to be matched, with very low latency, against other trades that exist in the market. The business logic typically includes the following steps:
The application needs to provide a 100% guarantee that once a transaction enters the system, it will not be lost. It also needs to keep end-to-end latency (latency from the time the system receives a trade, to the time the business process ends) to a fraction of a millisecond, and ensure that this low latency is not affected by future scaling.
The first step in building such an application with SBA, is to define its business logic components as independent services - Enrichment Service (parsing and validation), Order Book Service (matching and execution), and Reconciliation Service (routing):
To reduce the latency overhead of communication between these services, they are all collocated in a single Virtual Machine (VM). To eliminate the network overhead of communication with the messaging and data tiers, Messaging Grid and Data Grid instances are both collocated in the same VM. All the interaction with all the services is done purely in-process, bringing I/O overhead to a minimum, in both the data and messaging layers.
This collocated unit of work (which includes business logic, messaging and data) is called a Processing Unit. Because the Processing Unit encompasses all application tiers, it represents the application's full latency path. And because everything occurs in-process, latency is reduced to an absolute minimum.
Scaling is achieved simply by adding more Processing Units and spreading the load among them. Scaling does not affect latency, because the application's complexity does not increase. Each transaction is still routed to a single Processing Unit, which handles the entire business transaction in-process, with the same minimal level of latency.
We can see that the trading application guarantees both minimal latency and linear scalability - something that would be impossible with a tier-based, best-of-breed approach (in other words, with separate products to manage business logic, data and messaging).
Processing Unit | Event Containers | The ISpaceProxy Core Middleware Component | Using the GigaSpace Component in the Context of EDA/SOA Applications | Space-Based Remoting | SLA-Driven Container
The following diagram outlines a typical architecture of an application built with OpenSpaces:
At the heart of the application is the processing unit. A processing unit represents the unit of scale and failover of an application. It is built as a self-sufficient unit that can contain all the relevant components required to process a user's transaction within the same unit. This includes:
In XAP.NET, a processing unit can be implemented imperatively (extending an abstract class) or declaratively (XML describes the processing unit components and their relations). It is also possible to extend the abstract processing unit provided in XAP.NET to create a processing unit container using your favorite IoC framework (In Java XAP a Spring Processing Unit container is available).
Event containers are used to abstract the event processing from the event source. This abstraction enables users to build their business logic with minimal binding to the underlying event source, whether it is a space-based event source or not.
Two types of event containers are available in the product:
An event container is simply a class which defines:
Activating the container can be done via code:
The ISpaceProxy component is a .NET POCO driven abstraction of the JavaSpaces specification. JavaSpaces is a service specification. It provides a distributed object exchange/coordination mechanism (which might or might not be persistent) for objects. It can be used to store the system state and implement distributed algorithms. In a space, all communication partners (peers) communicate by sharing states. It is an implementation of the Tuple spaces idea.
Space is used when users want to achieve scalability and availability, while reducing the complexity of the overall system. Processes perform simple operations to write new objects into a space, take objects from a space, or read (make a copy of) objects from a space.
The ISpaceProxy abstraction was designed with the following principles in mind:
The space serves several purposes in an EDA/SOA type of application:
Space-Based Remoting allows for POCO services that are collocated within a specific processing unit to be exposed to remote clients, like any other RMI or RPC service.
The client uses the ExecutorRemotingProxyBuilder<T> to create a space-based dynamic proxy for the service T. The client uses the proxy to invoke methods on the appropriate service instance. The proxy captures the invocation, extracts information on the service-instance, the method-name, and arguments, and invokes a service request on the space using that information. It then blocks for a response, which can be either a successful result or an exception thrown by the remote service.
A processing unit that needs to be export a service uses the DomainServiceHost. The DomainServiceHost creates a service-delegator listener that registers for invocations. The invocation context contains information about the instance that needs to be invoked, the method and the arguments. The delegator uses this information to invoke the appropriate method on the POCO service. If the method returns a value, it captures the value and uses the space to return response Entry.
Benefits compared to RMI:
An OpenSpaces SLA Driven Container that allows you to deploy a processing unit over a dynamic pool of machines, is available through an SLA-driven container, formerly known as the Grid Service Containers - GSCs. The SLA-driven containers are .NET processes that provide a hosting environment for a running processing unit. The Grid Service Manager (GSM) is used to manage the deployment of the processing unit, based on SLA. The SLA definition is part of the processing unit configuration, and is normally named sla.xml. The SLA definition defines: the number of PU instances that need to be running at a given point of time, the scaling policy, the failover policy based on CPU, and memory or application-specific measurement.
The following is a snippet taken from the example SLA definition section of the processing unit Spring configuration:
Next Chapter: Database Integration