Don't Let SODA Ruin Your SOA
Integration logic should be independent of the application server
by Gordon Van Huizen
Applications are increasingly being developed "built to integrate," providing the ability to easily expose key functionality through commonly defined interfaces. Gartner calls this concept SODA, for Services-Oriented Development of Applications, fitting it into the overall landscape of services-oriented architecture (SOA). SODA represents a key activity when making the transition to an SOA. But enterprise architects must be careful not to let SODA impact negatively the effectiveness of their broader SOA initiatives. An overreliance on SODA can reduce overall system flexibility, reuse, and business agility. Here's why.
Making the right architectural decisions is vital to ensuring success with SOA. Choices at all levels-from application interface style to overall system architecture-can seriously affect the long-term value derived from SOA projects. Application infrastructure products on the market today embody architectural directions that should be carefully examined before making development decisions. Two of the most frequently encountered choices for services-oriented integration, application servers, and enterprise service buses (ESBs) can promote radically different architectures depending upon how they are used to build an SOA.
Application server platform vendors have embraced the notion of SODA to aggressively position the use of application servers for integration tasks. On the face of it, the notion that development and integration will converge sounds reasonable. Applications can be built to integrate through service interfaces using SODA. And one can perform cross-application integration through application server-based SODA. The first idea is a good one. The second, in many cases, is not.
The obvious first step to bridging applications is to make them interoperable, which is the fundamental notion behind SODA: application development tools now let you create Web services interfaces that expose application functionality. As Web services implementations become increasingly interoperable, applications will obtain the basic plumbing required to talk to other applications. So far so good.
Now, elevate the view and consider a set of applications. Picture all the key applications within your business. For a small firm, these may be a few dozen applications. For a large enterprise, it could be several hundred to a few thousand. In an ideal SOA, each application's core capabilities would be exposed as services. An integration architect could then bind sets of these services together to implement automated business processes.
The key to such flexibility is composition, a notion that we learned in object-oriented design. When designing objects, we found that rigid relationships between object classes (such as inheritance) greatly limited our flexibility in combining objects. So, we began to consider composition instead. With composition, objects are less bound to the definition of other objects, and can therefore be combined in more varied configurations. A similar idea can be applied to SOAs so we can compose applications at the system level. We need to minimize the amount of knowledge that each application has of other applications. The integration logic, if you will, should be placed in its own layer in the system. This integration tier then performs the functions necessary to bridge multiple applications.
Blurred Layers
With application server-based SODA, these layers get blurred. Suddenly, things like interapplication data transformation are baked into applications. As SODA begins implementing process management, an even greater danger arises. Each application becomes permanently bound to the larger business processes that it supports. Calling sequences between applications become locked in application code. Process models generate fixed applications that must be rebuilt every time a business process changes. Interapplication dependencies are actually worse in this model than with yesterday's point-to-point application connections: global business processes are locked in an ever-increasing number of unmanaged applications. Isn't this the kind of problem that SOAs were intended to solve?
Enterprise service buses, on the other hand, offer an alternative that embraces "built-to-integrate" application development, and are designed from the ground up to support the flexibility, reliability, and manageability of the integration tier. ESBs merge SOA, Web services technology, and XML with a unique distributed deployment architecture to create an easily deployable and manageable infrastructure for integration. Think of an ESB as a logical bus that treats all applications as event-driven services, and is capable of extension across a distributed enterprise.
Application servers can be effectively coupled with ESBs. This coupling promotes a superior architecture, where applications provide their functionality through service interfaces, and the ESB provides the integration tier-the flexible, reliable fabric between the services. The integration logic is configured within the ESB, allowing the greatest potential for architectural flexibility and application reuse.
SODA is a great way to expose applications so that they are ready to integrate. But when it comes time to consider the broader system architecture, make sure that it isn't compromised by hidden architectural choices. Consider instead a multitier system model where the integration logic is pulled out into its own tier. An ESB approach provides an optimal infrastructure for the integration tier.
About the Author
Gordon Van Huizen is the chief technology officer of Sonic Software. Contact Gordon at .
Back to top
|