Eclipse Zone - Comments for "Is There a Place for OSGi in Enterprise Application Development? (Part 2)"

Aslam,Interesting

rn82497 — Tue, 08 Apr 2008 06:55:38 -0400

Aslam,

Interesting article.

Your observation about the danger of inadvertently increasing complexity through modularization is I believe quite valid; especially for operations if they are expected to manage complex runtime assemblies.

The Infiniflow Enterprise OSGi runtime (see www.paremus.com) explicitly avoids this issue via enforcing a model driven approach, using SCA (Service Component Architecture) to define the runtime structure; the structural elements then dynamically instantiated from the relevant OSGi artifacts; see also the open source project newton.codecauldron.org.

The result, an OSGi based dynamic composite systems which are simpler to manage than traditional counterparts; primarily because at every point in time the runtime assembly is uniquely defined by, and can only be changed via, it's corresponding SCA model.

For those interested - the associated open source project Newton may be found at newton.codecauldron.org, along with several Newton related community projects.

Regards

Richard

Just a quick clarification

aslamkhn — Mon, 07 Apr 2008 10:42:16 -0400

Just a quick clarification on DDD's bounded contexts and modules before I get shot down in flames :-) In DDD terms, bounded contexts are not modules! Bounded contexts are may be created around team structures, system boundaries and other demarcations. However, the one of the areas in strategic design is the creation of bounded contexts and after some refactoring to deeper models, conceptual contours around specific parts of your problem domain will emerge. Also, when you start distilling your core domain the sub-domains __may__ become candidates for modules. In my experience, strategic design techniques from the world DDD is an excellent mechanism for discovery of modules. Cheers, Aslam

Hi Andrew, Thanks for the

aslamkhn — Mon, 07 Apr 2008 10:34:40 -0400

Hi Andrew, Thanks for the kind words :-) The idea is to expose only the classes in packages in a bundle. The cleaner approach is to expose Java interfaces instead of classes so that other bundles that "import" the "exported" interfaces really don't need to know about implementation specifics. You cannot expose XML configurations (or other forms of configurations, i.e. non-Java classes) because it will never be "loaded" by the OSGi class loader. However, the classes in your bundle can access anything on the classpath specified for the bundle, even if it is tucked away from public access deep in your bundle. A workaround may be to setup some custom attributes in your bundle and then dig around the OSGi API to exploit this. This sounds like a hack and I am certain that a more elegant solution to expose XML configuration via a class may be cleaner. Cheers, Aslam

thanks for the 2nd article.

andrewm — Mon, 07 Apr 2008 06:36:38 -0400

thanks for the 2nd article. very helpful.

just a quick question -- does OSGi allow exporting and controlling of meta-data as well as packages etc? i.e. to export some xml config and keep some separate? Or is the idea that you put it into packages to control it?

Cheers,
Andrew