Campus Technology

Click here to receive your FREE subscription to Campus Technology

News

Grid-Enabled SOA for Scalability

10/26/2007

By Kurt Mackie

With SOA, application silos are separated out and exposed as services. Such an arrangement presents problems in how to share and manage information across these services, Chappell said.

"If you are reusing a given application and Web-enabling it (i.e., via Web services), now the business logic will have a lot more demand on it." He added that IT also must deal with service level agreements on top of that.

Chappell admitted that there's tension between the SOA architects who build these pristine architectures and IT operations personnel. Architects bring the architecture to IT operations saying, "Here, you're responsible for owning this over time. Deploy it, scale it up and make it highly available." There's a bit of a problem there. How does that IT operations person justify how they scale up one process over the other?

SOA requires a too-tight relationship between the architect and those who run it over time. Moreover, IT seeks less complexity, not more.

Aim for Stateless Services
The answer to the scalability conundrum in SOAs is to write your services to be completely stateless in order for them to be highly available, Chappell said.

Being completely stateless means that interactions between the service requestor and the service implementation are stateless. However, as soon as the business logic itself and the service implementation becomes more complex, and also as the longevity of that service increases, then usually the need for statefulness also increases.

Various techniques and patterns have been used over the years to address more complex stateful interactions. One technique is called "state passing by XML payloads." It's largely what's used in BPEL engines today, Chappell said. The state is carried back and forth between the service consumer and the service provider. In the case of the BPEL engine, it packages up the entire context of the business transaction--the XML table, the purchase order, or whatever else is being manipulated, Chappell said.

Another technique involves "a hardwired shared context database." This approach involves a tightly coupled relationship and it's the hardest to do. The request itself passes nothing or some key into some backend data. It's a relationship or contract between the service implementation and a backend database. Every time that service implementation receives a request, it uses that key to reconstruct the context from the backend database and reestablish the application state and put it back into the database when it's done. And that's how the application can deal with having a request get dispatched in multiple instances and still carry the context of the request from one to the next.

The ideal SOA grid is an infrastructure that provides state-aware continuous availability for service infrastructure, application data and processing logic. It allows you to have predictable scalability that scales out linearly, whether it's deployed on two servers or 2,000 servers, across a heterogeneous environment consisting of any combination of high-end or low-cost hardware.

By reducing the dependency of distributed systems, a SOA grid can provide a marked overall increase in performance and throughput. SOA grids can be thought of as linearly scalable shared memory pools that allow you to offload your data to external nodes. The grid can then grow out horizontally as needed.

Finally, while Chappell referred to Tangosol technology in his depiction of grid-enabled SOA, he said that these concepts could be implemented by any vendor using a variety of techniques.

Kurt Mackie is online news editor, Enterprise Group, at 1105 Media Inc. You can contact Kurt at kmackie@1105media.com.

• Campus Technology |
• Education Plaza |
• EduHound |
• T.H.E. Journal

Copyright 1998-2008 1105 Media Inc.. See our Privacy Policy