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:

Motivations for SOA
As applications get bigger and more mature, and as companies have more and more vested investment in various software packages such as CRMs, there is a motivation to not reinvent the wheel and instead, focus on reusing existing software. To the business, reuse equals cutting of costs, which is music to the ears. From a technical point of view, SOA abstracts away the age old question of programming language and platform. The key word is interoperability. Let’s not fight over Java or .NET or PHP. XML is the language and what’s more, it’s (mostly) human readable.

Messaging
Traditionally, integration of software has been implemented using Remote Procedure Call (RPC), passing data in binary form as opposed to XML. Nowadays, the way to connect software is via messenging. In such an architecture, messages are passed around on a Enterprise Service Bus (ESB), which is the messaging framework that abstracts over the transporting medium. At the very least, ESB provides routing, security, transformation, and validation.

Web Service
Not every service is a web service. To me, a service is closely related to an interface, which is an abstraction on the underlying implementation of a functionality. A service’s interface can be any contract between the software vendors, but in a SOA environment, they are in XML form. And if the interface conforms to a SOAP (Simple Object Access Protocol) or REST (Representational State Transfer) message and comes with a WSDL (Web Services Description Language), then it is considered a web service. There is an open industry initiative to make a registry of available services called UDDI (Universal Description Discovery and Integration). Services can be discovered either at design time or runtime.

Process-Driven Development
Traditional approaches to EAI had been to create an entire application stack that encompassed the various software as underlying components. In contrast, applications within a SOA are designed according to business processes, as opposed to the IT infrastructure. A SOA application enables the workflow of a document instance or task through a business process. To me, a workflow is a state machine of an instance and can be modelled as such in a UML state diagram. The efforts of a company to streamline their business processes is called Business Process Management (BPM). And lately, SOA has become part of the BPM effort. BPEL (Business Process Execution Language) is used to describe the business processes in an abstract (XML) fashion and used to orchestrate the web services that are used.

Vendors
A number of vendors have popped up who claim to provide everything you need to implement a SOA-based application. The front-runners are old-timer Tibco, marketleaders in software like IBM, BEA, and even Oracle, who come from more of an application server background and who have to opportunity to sell their SOA framework to their existing customers and partners, and newcomers like Cordys, who by virtue of having designed from scratch probably has the most well-thought-out technology.

Summary
In this article, I spoke about the motivation for the move to SOA, tied together the terms that are often heard together with SOA. The terms play a part of the technology used within a SOA application and the process by which the applications are developed. Lastly, I named some vendors that provide frameworks to develop SOA applications. The list should be many more and I will add to it as I discover them.

What’s Next
Just at first glance, I had to use more than 10 acronyms just to tell the story. In the next article, I will share what I discovered about SOA governance, which is a fancy term for organizations to keep track of what is going on in their SOA applications. Governance will easily lend to the subject of testing and monitoring. Furthermore, I will discuss how the right balance needs to be reached all the more in a SOA environment between business and IT concerns.