The system and method of automatically detecting common deployment time dependency for enterprise or OSGI applications using declarative approach and re-use the common depedency for runtime environment.
Publication Date: 2011-Nov-04
The IP.com Prior Art Database
The system and method of automatically detecting common deployment time dependency for enterprise or OSGI applications using declarative approach and re-use the common depedency during runtime by the runtime environment.
Page 01 of 3
The system and method of automatically detecting common deployment time dependency for enterprise or OSGI applications using declarative approach and re -use the common depedency for runtime environment .
In the current scenario if an enterprise application has a dependency on a given library, the library is bundled with the enterprise application for resolving its dependency at runtime. Many of the dependencies are common across the enterprise application and consequently contain redundant library as they are not aware about the dependencies that shipped with other applications. More to this each ear or OSGI bundle will have same or different version of the common dependencies. For example if two applications are using spring and log4j jar, then in typical enterprise deployment environment, the applications are not really aware about the context of the common dependency graph of each other hence they will be bundled with their own version of spring and log4j. This problem is also valid in OSGI bundles, where the same dependent bundles are included and exported by the OSGI dependency.
This disclosure provides a system and method to build a common dependency repository of a bundle (ear/osgi) dynamically by reading the dependencies specification from the osgi bundle or enterprise application. The system and method will create a separate xml based dependency repository (or leverage existing OSGI runtime in case of OSGI container) which can be used across the runtime irrespective of runtime container or the environment in which the application runs. For example in an Application Server run time environment, all the enterprise applications typically have the common dependencies bundled in it. The same is applicable with an osgi runtime environment as the developer of the application will never knows that the targeted runtime will provide the dependencies it is looking for. Though you have a concept of shared library, but again it is confined to the enterprise application using it and not detected at runtime during deployment if other enterprise applications require the same dependency.
This disclosure aims to separate out this particular concern and does have the provision to either automatically detect the dependencies of the ear/bundles beyond deployed or manually it can be extended to have the dependencies on the application. The common libraries will always be available with global scope to make it available based on the registration of the application with it in declarative way.
This disclosure also aims to simplify support issues while updating the enterprise applications or OSGI bundles as part of the fix pack process. The enterprise applications or OSGI bundles are shipped by various products or applications, would have various shared common dependencies, but still each bundle these dependency it on its own package. Now when you go about applying fixpack or upgrades, the process will look at all available profiles and than sta...