Do any of the following statements sound familiar?
- We need to SOA-enable more of our applications.
- Well be more flexible if we tie our systems together with BPM.
- Richer Web 2.0 interfaces can make it easier for less technical staff to learn and use our application.
Youve probably heard similar statements recently. You may even be running software that at least partially validates some of those value claims. IT derives no small portion of its momentum from a steady stream of new ideas and buzzwords. But the success of an IT organization depends on the ability to separate the fluff from the real stuff.
A main characteristic of IT evolution is that the cool stuff appears ever higher in the stack. Over several decades weve progressed from establishing low-level network protocols for application communication, to distributing application components across the network, to loosely coupled integration using Web services. Along the way, the lower, earlier layers can slip off the radar, perceived as old news, fully baked and no longer worthy of further improvement.
The application server, and its cousin the transaction processing monitor, are prime examples. These containers for program logic, implementing on the one hand Java EE and related standards, and on the other a C/C++/COBOL platform, have been around long enough to be taken for granted. In all the noise about SOA and BPM and composing service-enabled components into flexible solutions, its easy to forget that each of those components, whether pure Web services or service-enabled legacy assets, has to run somewhere, on something. Guess where.
Sum of Its Parts
A composite application is only as good as its constituent components. You might get away with running less critical components in less-than-premium environments, but any mission critical application depends on a number of core components whose reliability and performance are make or break for the entire solution. This cant be papered over or mitigated with SOA or BPM or any other high-in-the-stack technology. You cant speed up a computation or unbreak it at a higher layer that calls it. So at a minimum, the containers for each of the services (SOA or otherwise) within a composite application provide a foundation of fundamental quality of service characteristics.
That the container is make or break for reliability and performance means that it is important, but that doesnt make it a differentiator. And theres more. Certain new functionality can only be practically implemented at a lower layer in the stack. In many cases, a need that emerges at a higher layer, whether at the application itself or at an intervening layer such as SOA, can be most powerfully and effectively addressed at the bottom of the stack.
An example from the Java world is the ability to support real-time behaviorin essence, to deliver a guaranteed and predictable level of responsiveness. Standard Java has an inherent lack of determinism in the way it manages memory. A typical Java program runs for a while and uses memory without the traditional worry about freeing up memory that is no longer needed. The system will occasionally pause the program and clean up memory on the programs behalf.