Bundle metadata, was: GBeans: Saving Changes

[Jeremy Boynes <jb...@apache.org>]

Aaron Mulder wrote:
> 
> 	Of the two, I like option 5 more -- and more than all the 
> UUID-based options.  I'm not sure the mutability needs to be reflected in 
> the configuration name, though -- couldn't we have non-name properties for 
> the version and mutability?  That way the start/stop command would be the 
> same and so on.  You would refer to a prerequisite by providing the name 
> and version range separately, and perhaps even indicating explicitly 
> whether you're willing to depend on a mutable version.  If you provide 
> nothing but the name, that implies "any version will do".
> 

<snip>Because I think this is a key issue and drives the rest</snip>

First a chunk of background to establish context, skip to "+++" for the 
proposal.

One of the problems we have is that the configuration management system 
is very naive - I kept the first version real simple to see how needs 
would drive it and, of course, its limitations are now coming back to 
bite us.

It works on the assumption that all the information about a bundle can 
be captured in its unique id. So no matter how many services a bundle 
offers, all a user of those services needs to know is the bundle's id 
and if it references that those services will be there.

This allows us to have a very basic system where dependencies get 
resolved based on ids alone. It got us this far but I think we're 
starting to hit the limitations.

One thing we talked about from the start was a "capability model" where 
bundles advertised distinct services (versioned) and dependencies 
between bundles were resolved using those rather than just the basic id.

So, for example, a web container could advertise "jetty", "jetty 5", 
"jetty 5.1.4", "servlet", "servlet 2.4" etc. An application that needed 
a web container could require "servlet 2.4" which would mean it could 
run in any instance no matter what implementation of "servlet 2.4" was 
present (e.g. either Jetty or Tomcat) or it could require "jetty 5.1.4" 
because perhaps it had specific classes that it was using. For example, 
a generic webapp may just need the "servlet" bits but one with a custom 
Valve would require a Tomcat based version.

The intention was to build up an ever richer set of services that could 
be provided and consumed. In the end you would end up with very rich 
bundle descriptions such as "I am a bundle that provides Acme Inc. Order 
Entry System V7.5.2 tuned for 100 concurrent users at 500ms reponse time 
and 40 operations per second on an Acme-4000 Linux system with a Harmony 
JVM, 4 4.2Ghz CPUs and 2GB RAM. I provide these web services (...) and 
EJBs (...). I need access to a Acme Inc. Order Entry Schema V7 via a 
JDBC 3.0 driver on a database tuned for 80 transactions per second and 
to the following JMS queues (...) capable of handling 20 messages per 
second." This captures not only the physical and logical requirements 
needed to run the application but also the environment characteristics 
that drive response time and throughput.

With this in place, there starts to be sufficient information for the 
configuration manager to start to make intelligent decisions about 
where/when to run application bundles in order to meet business level 
service agreement targets.

+++

The key to this whole thing is having sufficient metadata in place about 
the bundles, which ties back to your point at the start. I think it has 
become clear that we have progressed to the point where a simple unique 
id is insufficient and we need to start adding metadata. The first bits 
relate to temporal stability: adding in a version identifier and adding 
in an indicator that a bundle is temporally unstable (i.e. its a SNAPSHOT).

We should add to that metadata about the services that a bundle provides 
and consumes. I think that at a minimum that comprises a service id, 
version and stablilty flag the same as for bundles themselves.

If we do that first for codebase services (i.e. the classes that a 
bundle uses and provides) then we not only get a start on the metadata 
description side, we also fix the classloader issues that lead to 
monolithic bundles like o/a/g/Server.

--
Jeremy