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
