Is this an application which I see before me?

This post has been triggered by two interesting posts on the topic of what it is to be an application in an OSGi environment. This is something I felt I just had to get stuck in with as its exactly what we've been working on in the Newton project.

The way we've tackled this is very similar to the approach suggested by Mirko, except instead of using Spring-DM as the top level element in the model we've picked SCA.

SCA is a relatively new specification but it gives a vendor neutral way of describing the service dependencies and architecture of an application running in an enterprise environment.

The basic pattern is that a component which has a certain implementation (java, spring, bpel, c, etc) is able to publish a number of services (over a range of protocols - in-memory, RMI, WS, JMS, etc) and consume services from other components via references. The combined unit which is the component, it's services and it's references are then packaged in an entity called a composite.

In Newton we associate a composite with a top level (or root) bundle. This bundle then provides the class space for the composite to instantiate it's implementation, services and references. Importantly the bundle does not have to contain all of the classes that it needs to function but can use OSGi tools such as Import-Package to achieve modularity at the deployment level.

When an SCA composite is installed in a Newton runtime we go through a series of steps:

1. Resolve the root bundle that supplies the class space for the composite. If this is not the first time the root bundle has been resolved we increment an internal counter
   
2. Resolve and optionally download the bundle dependencies required to satisfy the root bundle against a runtime repository (this includes ensuring that we reuse existing bundles within the runtime - if they were installed for other composites)
3. Build a runtime model around the SCA document that controls the lifecycle of the component as references come and go
4. Finally when all required references are satisfied (a dynamic process) we publish the services to be consumed by other components in the enterprise.

When an SCA composite is uninstalled we go through the reverse process:

1. Unpublish the services and release any references.
2. Shut down the implementation and discard our runtime model.
   
3. The bundle root counter is decremented, if the bundle root counter reaches zero then it is no longer required in the runtime and is marked as garbage.
   
4. Finally garbage collect all bundles that are no longer in use, so clearing down the environment.

This pattern then forms the building blocks of our distributed provisioning framework that is able to deploy instances of SCA composites across what we term a "fabric" of newton runtime instances.

To achieve this we group composites together into an entity known as a System. A system is a group of composites which each specify a particular replication strategy and a set of contract requirements. A replication strategy is a dynamic pattern used by Newton to decide how many instances of a Composite should be installed at any given instant. A contract is a pattern used to restrict where a composite should be installed, i.e. a contract may specify a filter such as (&(machine.cpu.count>1)(machine.memory>1G)) i.e. only install on dual cpu or greater machines with more than 1GB of memory available.

So in the Newton world an application is actually a very dynamic entity. It is built from OSGi bundles and wired together on the fly. But it never the less has rules which are defined via a model (expressed in SCA plus our system extensions) which specify:

• how implementations and interfaces are connected
  
• how remote services should interact via bindings
• how they should scale
• where they should install

Hope that's been of interest,

Laters,

A New Hope

A long time ago in a galaxy far far away...

A group of rebels formed the OSGi Alliance, an alliance against the empire (or at least monolithic code empires). The alliance was created to champion an ideal (in CS terms a specification) which described a standardised way for modules of Java code in a single virtual machine to interoperate without requiring the JVM to be restarted.

The specification was simple to understand and many were drawn to it due to the elegance of its implementation. In time many who chose this new life found that despite the simplicity of the specification championed by the JEDi alliance they could nevertheless wield wondrous powers not seen before in the Java world.

Inevitably these powers drew the attention of those still living within the empire. Initially some sought to discredit the Jedi powers, either through misunderstanding or fear. But soon others became envious and wanted these powers for themselves.

Some within the empire chose to take the difficult road and started to convert their legacy methodologies to meet the requirements of the Jedi ideal. But others saw a different path, instead of converting their methodologies to conform to the Jedi ideals they decided to convert the Jedi ideals to fit their own methodologies.

Those in the Jedi council found themselves torn between the short term promises of wealth offered by the empire or sticking to their ideals and holding out for the long term riches of a truely flexible Java virtual machine architecture.

It is at this point in the story that we find our selves. Peter Kriens (Obi Wan?) has recently blogged about the choices facing the Jedi alliance and argues for the purist ideals to be upheld.

Myself I find myself acting as a trader (or possibly a smuggler - gonna argue for Han but you make your own judgements...) between these two worlds.

As a developer and architect of Infiniflow I have been directly involved with building a distributed computing infrastructure that seeks to embrace ways of the Force as championed by the Jedi alliance for a single JVM but across the enterprise.

Our driving goal that led us as a company to the Jedi way of life was acceptance within our architecture that things change, or to put it another way: there is no one rigid model of the enterprise but rather a series of iterations which encapsulate the functions required to service the current business requirements.

Whether you believe a word of this, having walked the boundary between the Jedi world and that of the Empire I am acutely aware of the problems associated with integrating tools built by these two communities.

My own gut feeling is that the Jedi should stick to their ideals and treat integration with the Empire as an edge case - i.e. certainly build up specifications but treat them as boundary conditions vs compromising the core ideals. In this way legacy methodologies can be incorporated but in such a way as to highlight the fact that it is just a stepping stone towards a new ideal.

When it is impossible to integrate a legacy pattern I'd argue that this is a point when we have to admit that Gödel was right - it is not always possible to please all of the people all of the time (I paraphrase but you get the point). You can always delegate legacy cases to a separate jvm and communicate remotely to the old world.

If the Jedi council compromise their core ideals for ill conceived or temporary solutions they risk sending out a mixed and confusing message to those who are new to this technology.

Padawan learning the ways of the Force for the first time are unlikely to appreciate the subtle differences between such abstract concepts as import-package and require-bundle. They will of course go for which ever is the simplest pattern to achieve their short term goals but this could well be at the expense of logical coherency within the OSGi specification.

Once stepping onto the path to the dark side it is very difficult to turn back and ultimately leads to ruin. (Or cool lightning powers - you decide)

I have to give credit to the fantastic blog posts of Hal Hildebrand for the Star Wars theme to this blog entry, whether this will become a common theme for my own posts I'm unsure but it was certainly fun to write.

Laters,