SOA stacks are a hot topic. Actually, stacks are hot in general and SOA is no exception. A software stack is created
when applications and services that would typically run on their own are integrated into what looks like a stand-alone solution.
Some extreme examples of software stacks are the Linksys routers and TiVo digital video recorders. In these examples, several software components, including the Linux operating system, are combined and distributed as a single appliance. Appliances bring software stacks one step farther by distributing the components within a hardware device. Most stacks are not this ambitious, although I would expect that as stacks become more popular, several may evolve into hardware appliances.
And the more commoditized and generic the solution is, the easier it is to create a stack because the individual components in the stack can adhere to industry standards. However, to motivate engineers to build a stack, the solution also requires some level of complexity. If the solution space is relatively straightforward, it would be easier to rebuild functionality rather than try to integrate an existing solution into a stack.
This is why SOA middleware solutions are such a fertile ground for stacks. The problem domain is complex, but the solutions are standardized. And delivering solutions as a stack is very compelling because the components within the stack maintain their autonomy. So stacks not only have the benefit of reuse from system integration, but they also have the benefit of the components within the stack and have the ability to continue to evolve and improve on their own organically.
It is similar to having a distributed team of engineers, each working on their own product and area of expertise, but the individual products also seamlessly integrate into a larger solution stack that is greater than the sum of the individual components.
Stacks vary in terms of maturity, but a reasonably mature stack should include a common install and update procedure so the end users are not aware of the components within the stack. It should also have unified administration and configuration, such as creating a set of administration pages that uses an underlying JMX API that each individual component in the stack exposes.
To remain a stack, however, the components should not be tightly integrated together. Rather, each component within the stack maintains its own product roadmap and can evolve on its own. As an unfortunate side effect, software providers can get stack-happy, and once the product managers realize the relatively low effort of integrating components into their software solution when compared to engineering, they can request that all sorts of modules be integrated.
Once a product begins to lose its functional cohesion, it also loses its benefits as a software solution because the users of the solution get confused as to what the solution actually is supposed to be. It is easy to find examples of software stacks that have components included into them that make the consumer scratch their heads at why the component was included in the stack at all, but if the product manager can avoid these temptations, then the stack assembly method of delivering software can be extremely compelling for the end user.
Open source software helps to facilitate the building of software stacks. It is not a coincidence that the popularity of stacks coincides with the mainstream arrival of open source software. There are five primary reasons for this:
- Open source typically builds to standards
- Integrators have access to the source
- Integrators can become committers themselves
- Open source licensing is very friendly to integrating and distributing into other solutions, especially other open source solutions
- Open source roadmaps are typically transparent on some JIRA-type roadmaps
Examples of major components of SOA open source software stacks
These stacks are relatively new as SOA open source stacks are a new and evolving concept, but they are mature enough to warrant consideration when looking to implement an SOA solution and certainly should be evaluated as they continue to evolve. The functionality these stacks provide differ in specific implementation, but in general they all include components that provide SOA middleware capabilities such as: Guaranteed message transport, data transformation, transactional support, message orchestration and service discovery.
And these SOA open source software stacks are evolving constantly. LogicBlaze recently announced that they are now including the LifeRay portal to the FUSE stack. A question can arise if portal functionality belongs in a SOA technology suite, but it is undeniable that open source SOA stacks have arrived and are evolving.
The stack architecture is a good trend to recognize and monitor in general. Stack-based architectures are showing up everywhere, especially with open source components. Having the knowledge of how stacks differ from basic systems integration, including their benefits and drawbacks, is a useful perspective when evaluating any stack-based solution.
If your organization is considering SOA infrastructure, look at the new open source stacks. And when reviewing the stack, it is helpful to not only view the solution as an autonomous solution set, but also as a stack of interrelating components, each with its own motivation, engineering team, capability and roadmap.
This perspective will not only help you when evaluating stack-based solutions, but will also give your organization increased awareness of how the solution is constructed and how it will fit into your overall SOA strategy.
About the author
Adam Michelson has more than a decade of technology implementation experience. Adam is currently the director of service-oriented and enterprise architecture for Optaros Inc., an international consulting and systems integration firm that provides enterprises with best-fit solutions to IT business challenges, maximizing the benefits of open source software.