Single Source OSGi Enterprise Architecture Pattern
The following article documents an architectural solution to a problem which I’ve encountered in many enterprise computing environments.
Problem:
There are a wide variety of deployment artifacts which cannot be reused between different deployment environments. Copies of the artifacts are taken and modifications are made to enable compatibility for each different execution environment. Component dependencies on different deployment environments cause the code base to diverge over time and become specific to a particular execution environment. This causes the enterprise code base to grow exponentially for only a linear increase in functionality.
Solution and Consequence:
Utilise OSGi as the execution backplane for service, web and desktop applications. This solution delivers a unified approach to the creation, deployment and management of enterprise bundles. The consequence is that a linear relationship is formed between adding enterprise functionality and the size of the code base that enables it.
Structure:
The diagram below shows the architectural structure of this pattern.
Example Strategy and Code:
Example code is available for download at:
https://sourceforge.net/project/showfiles.php?group_id=228168&package_id=301845
Download OSGiEAPattern.zip
The example strategy and code makes use of:
- Equinox as the OSGi execution environment,
- Rich Ajax Platform as the rich web application
- Rich Client Platform as the rich desktop application,
- Apache CXF as the Web Service consumer
- JAX-WS as the service layer
Installing the example code:
Pre requisites:
1. Install eclipse 3.4 (http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/ganymede/SR1/eclipse-java-ganymede-SR1-win32.zip)
2. Install the Rich Client Platform (http://www.eclipse.org/rap/gettingstarted.php)
Running the Rich Desktop Application
Start eclipse and new workspace.
Click window -> prefererences -> Plug in development -> target platform -> tick group plug-ins by location, Select or ensure that the target platform location is the standard directory and not pointing to the rich ajax platform plugins.
Click File -> import -> Existing projects into workspace:
Click next -> select archive file -> browse and select the OSGiEAPattern.zip which you can download from https://sourceforge.net/project/showfiles.php?group_id=228168&package_id=301845
Deselect galang.research.rap.hello and click finish
Select Run configurations -> select OSGi -> select new –> deselect workspace and target platform -> tick galang.research.esb -> add required bundles, you should now have 13 bundles selected
Click Run then double click plugin.xml within galang.research.rcp.hello -> click overview
click Launch eclipse application and type in your name and click “Call web service”
Running the Rich Web Application
Ensure that you have installed the Rich Ajax Platform.
http://www.eclipse.org/rap/gettingstarted.php
Start eclipse and a new workspace.
Click window -> prefererences -> Plug in development -> target platform -> tick group plug-ins by location, Select or ensure that the target platform location is the pointing to the rich ajax platform plugins which is located at [ECLIPSE_HOME]/ configuration/org.eclipse.rap.target-1.1.1/eclipse
Click File -> import -> Existing projects into workspace:
Click next -> select archive file -> browse and select the workspaces.zip which you can downloaded from
https://sourceforge.net/project/showfiles.php?group_id=228168&package_id=301845
Download OSGiEAPattern.zip
Deselect galang.research.rcp.hello and click finish
Right click galang.research.rap.hello.launch
type in your name click Call web service
If you have any questions or want to work with me to implement a strategy for this pattern based on your java technology stack feel free to drop me a line (glenn.galang@gmail.com).
Related Articles:
OSGi
http://ggalangblog.blogspot.com/2008/11/ggblog-light-weight-reporting-server-on.html
RAP
http://ggalangblog.blogspot.com/2008/11/ggblog-chat-on-rap.html
RCP
http://ggalangblog.blogspot.com/2008/11/ggblog-dynamic-jface-xml-tableviewer.html
Taken From: http://ggalangblog.blogspot.com/
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Brian Shannon replied on Wed, 2008/12/10 - 2:43pm
I'm having trouble putting together how this solves the problem. The problem is that there are components that have to be changed for each deployment environment (I get that part and have experienced that problem myself). But I assume that this 'logic' for each deployment environment has to either exist somewhere (in the OSGi layer?) or be removed via altering the deployment environments to accept a more generic 'bundle' being distributed from the OSGi layer.
So, where do the details of each permutation of environments get take care of? Where's the 'magic' happening? :)
Glenn Galang replied on Wed, 2008/12/10 - 6:02pm
in response to:
Brian Shannon
"'logic' for each deployment environment has to either exist somewhere (in the OSGi layer?)"
This is right, your still going to have code that is specific to a deployment environment, its just OSGi gives you a neat way to break it apart from the code that is re-usable and not specific to an environment.
I've put a small example of this in my code where the RAP/RCP specific code is seperated into environment specific plugin and the webservice consumer and service layer are re-usable.
Brian Shannon replied on Wed, 2008/12/10 - 6:39pm
in response to:
Glenn Galang
Glenn Galang replied on Wed, 2008/12/10 - 8:46pm
in response to:
Brian Shannon
"So, are you saying that OSGi gives you a way to reuse the code that is common across similar environments,"
Yes this is what I'm saying.
"but I'm still going to have to have custom code in those specific environments for the Database differences. Is that right?"
I'd definately try to break this, environment specific database code, out into its own module. I'm sure there are very valid reasons for your code to be database specific. I guess the ponit is, try to decouple it from the rest of your code. This isn't really a new concept but OSGi helps you structure these modules/bundles in a standard way.