SOA/BPM performance best practices (Deployment and application packaging)

Current SOA runtime environments are usually implemented on J2EE based application servers. Business applications are deployed to these environments as one or more SCA modules.

Using common object libraries
Often a set of such business applications shares common definitions for data and interfaces and classical application design considerations suggest to put such common objects into a common objects library module.
Some current SOA runtime environments however treat such packaging schemas in a maybe unexpected manner. The module specific class loader for module one finds a reference to another module (the common objects library) and loads that module. When then the module specific class loader for module two loads its module's code and find a reference to another module (again the common objects library) it loads that module. This continues for all the application modules. The fact, that the platform's application class loaders have no knowledge about what has been loaded by other application level class loaders already leads to the effect, that a shared object library module is actually shared “by copying”. And if the memory footprint of a single copy of that shared object library is several hundred megabytes, the available heap space can be exhausted pretty fast.
Such excessive memory usage does not necessarily have a performance impact, but when the JVM's garbage collection takes place, the responsiveness of the affected applications can suffer dramatically.
A less memory consuming approach in this case would be to define one library module per application module. While this approach definitively requires more development and packaging effort, it can considerable reduce the overall memory requirement. Up to 57% reduction have been observed.

Modularization effects
One of the internally used benchmark workloads is organized as three SCA modules because that seemed the most natural model a production application implementation – one module creates the business events and one consumes them, while the module in between contains the business logic responsible for synchronization. For ease of code maintenance an SCA developer may be tempted to separate an application into more modules. In order to demonstrate the performance costs incurred with modularization, the benchmark's three modules were organized into two and one SCA module.

Measurements indicate a throughput improvement of 14% in the two module version and of 32% in the one module version, both relative to the original workload implementation. As might be expected, data sharing among SCA components is more expensive across modules than it is for components within the same module (where additional optimizations are available).