Share: |


A big challenge for companies was to accelerate development of their business application to provide more value to their customers or to address a new market before their competitors.   J2EE platforms provide this value allowing developer to not take care of targeted infrastructure and to easily reuse existing modules. To simplify, now developers only take care of the business logic and don't need to think about the fact that the application will run on a cluster, on a specific OS using a specific database, they don't need to implement messaging services, basically they don’t need to take care on low layer and can focus on business logic.

The point is that if developers don't need any more to take care of low level layers because of the abstraction layers provided by J2EEplatforms, this last one still needs to be setup, managed and maintained by operation. If J2EE platform allowed more productivity for development it added complexity for operation. Bottom line is that to move application from test to production could take more time than to develop  the application itself and operation becomes a bottleneck.


More and more company try to automate J2EE platform management and many of them have a lot of scripts to do so. Each time an upgrade is done they need to review their scripts or to rebuild them. The need to have solution to automate this area is clear and there is some try to use server automation tools to achieve this. Usually, server automation tools won't provide so much value than homemade scripts. Why? Because server automation tools are server centric when an application, a J2EE platform are not server centric. For example, when I want to configure a JDBC provider, I don't want to setup this service for a specific OS instance or physical server, I want to setup this service for a Java server (JVM) or a Cluster that are part of my J2EE infrastructure. And on the last case, Cluster may means several physical server at the low layer level.


For automation, in J2EE context, I need a tool that allows me to create a package for a service or an application that is independent of the topology of my J2EE infrastructure as they maybe different on the different environment used to test, qualify the application before pushing it on production. Without this kind of feature, that means I need to create a package for each kind of topology and environment which seriously decrease automation capabilities and value.

Being able to manage J2EE platforms through the abstraction layer with topology independency capability is even critical with virtualization and Cloud computing as topology could move very fast.


Conclusion is that to get real value from automation on J2EE platforms, the automation tool needs to be able to address those platforms through their native API with enough abstraction, package parameterization and topology independence enablement  capabilities. By the way, low layer management capabilities are also required for initial provisioning of J2EE infrastructure. The good news is that BARA could help to achieve J2EE platform management automation. First of all, BARA is on top of BSA that allows to do initial provisioning of J2EE platforms like installing WebSphere or WebLogic. But ARA provides capabilities to not be server centric but to target J2EE objects with enough abstraction layer to act on the same way for different J2EE platforms and to provide topology independency. What I mean here is that with ARA I could deploy the same application package to either standalone server (JVM) or to Clusters which enable real application release management. I get J2EE platform management automation with infrastructure independency from physical severs to cloud through virtualization.