Enterprise Integration Zone is brought to you in partnership with:

Glenn has posted 7 posts at DZone. View Full User Profile

Single Source OSGi Enterprise Architecture Pattern

12.08.2008
| 13513 views |
  • submit to reddit

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:

  1. Equinox as the OSGi execution environment,
  2. Rich Ajax Platform as the rich web application
  3. Rich Client Platform as the rich desktop application,
  4. Apache CXF as the Web Service consumer
  5. 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/

Published at DZone with permission of its author, Glenn Galang.

(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

So, are you saying that OSGi gives you a way to reuse the code that is common across similar environments, but that the code that is there for very specific environments will still need to be there?  For example, I have two environments where they both are in a Windows Server 2003/Oracle 9i/Web Sphere configuration.  But in one environment I have Database Schema version 2.123 and in the other Database Schema version 2.234.  So, the OSGi layer will help me with the Windows Server 2003/Oracle 9i/WebSphere environment by distributing common code for that particular permutation, but I'm still going to have to have custom code in those specific environments for the Database differences.  Is that right?

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.

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.