Stefano:
Here is a mixed response to your email.
I'm attempting to bridge real requirements relative to what we have in the framework today, explain why there is a significant semantic gulf in solutions within Avalon, present the rationale as to why and how solutions play into this - and throw into this are problem statement, actual requirements, and forward looking objectives.
Be warned - it's one of my longer emails.
;-)
Stefano Mazzocchi wrote:
I would much rather start the discussion from scenarios of use and from the functionality required by all the framework user.
For example, during the cocoon block discussion over at cocoon-dev I'm sure that the perception of the architecture of a container changed a little (at least, Stephen said that he had to think more about the functional needs that cocoon blocks required)
I think you are RIGHT with respect to a step back - some level of overview is missing in the last round of discussions. What's missing is the correlation of all of this with the respect to the original base - I least I think it is worth going over the ground between the Avalon framework as it is today, the issues and problems, and how the current discussions address them. There are a lot of new people lurking around and to really leverage these people an introduction/update is needed.
The Avalon framework as it stands today does not define the complete component contract.
What is does do is define the interfaces and artifacts used in the interaction of a container with a component. It says very little about the way a component communicates its operational criteria to a container. In fact, communication from component to container is limited to a few marker interfaces. The solution to this has been the evolution of two different approaches:
Framework default - programmatic resolution
ECM - dynamic resolution
Phoenix - static resolution
The end result of this is the following implicit meta-model evolution:
Avalon Framework
Meta-Model
^
|
------------------
| |
ECM Phoenix
Meta-Model Meta-Model
Both of the branches overload framework specifications in order to resolve problems.
The solution to this is to (a) recognize the different semantic of the respective models, and (b) establish a comon mechanisms for communicating this to a container. Both the ECM and Phoenix strains introduced mechanisms to achieve this. The ECM approach is through a roles file which is basically a configuration instance that holds a conceptual model, combined with dynamic dependency resolution (which makes assembly a lot easier but also position validation as a run-and-see-what-happens). In contract, the Phoenix model came up with the Block descriptors which enabled assembly and system validation in advance of deployment.
What come out of this is that there at least two fundamental things missing in the Avalon Framework as it is today.
* complete communication of component operation requirements
to its hosting container
* of which the concept of an assembly strategy (static or dynamic)
is one of several computational aspects
Consider the following picture:
|-------------| |------------|
| container |<------------------------> | component |
| | component | class |
|-------------| introspection |------------|
(returns boolean values
- is X instance of Y)
Options available according to the framework are limited to introspection. Does the component implement interface Initializable, Does the component implement interface SingleTreaded, etc. Based on this introspection based assessment it is possible build and deploy a minimal component. There is no information about context (which means that context is 100% container dependent based on current spec), it provides not information about service dependencies (which means that Serviceable and Composable interfaces are 100% container dependent based on current spec).
So what does this mean - it means that the Avalon Framework spec is basically only any good if you use it within the context of (a) an existing container, or (b) your own programmatic management of component which is in effect code acting in the role of a container.
Let's take a leap forward - the meta stuff - its only about the problem of communicating deployment criteria from a component to a container.
Consider the following:
|-------------| |------------|
| container |<-------------------> | component |
| | component | class |
|-------------| type defintion |------------|
(returns complete
type model with lifecycle,
lifestyle, assembly strategy,
etc., packaged in object model)
What we have here is a scenario where a developer can include information about a component with the component class that is sufficient for a generic container to say - YES or NO on deployment. The container can look at information concerning deployment constraints such as lifestyle - instead of doing introspection on interfaces, we lookup an attribute in the model named avalon:lifestyle - and if the value if "per-thread" then we known how to handle lifestyle - but that's not the kicker - the kicker comes in when we look at things like service dependencies, context criteria, assembly strategy, etc. These aspects of a component can be declared so that any container that understands the components meta model can make an assessment of its ability to deploy that component. This has some very important implications:
(a) assessment can fail with a constructive and detailed explanation
(b) the information provided by a component can be container neutral
(c) containers can optimize solutions in advance (pre-loading components, etc.)
Don't get me wrong: I'm pretty damn sure that you guys have most of the solutions at hand at this point, but I would like to start from "problems" and then drawing solutions, rather than refactoring different solutions and futher abstract them.
The problems are:
1. the current Avalon Framework contracts are insufficient for anything more than container specific solutions 2. due to an insufficiency in the current spec with respect to retrieval of information from a component concerning its operation requirements
I'm not saying it's a bad thing, it's just that I fear that not many people, even on this list, are able to follow the discussion of refactoring between the various containers.
I remember first getting involved in Avalon and wondering if I would ever get to grips with the framework as it is. This whole discussion is going a big step beyond - so it's easy to loose track. But actually, it's not so dramatic.
Consider the following:
* ECM style solution to framework deficiencies - the dynamic
resoltion strategy and represented by Fotress and ECM.
MyService service = (MyService) manager.lookup( "org.somewhere.MyComponent" );
This implementation of a component or service manager
"assumes" that the argument to lookup is an interface name
with possible extra sugar. The implementation understands
the syntax and semantics and handles resolution of a solution
based on runtime availability of components in the classloader
together with application context supplied in a roles file.
* Phoenix style solutions to framework deficiencies - the declarative
resolution strategy and represented by Phoenix and Merlin
MyService service = (MyService) manager.lookup( "vault" );
This implementation of a component or service manager knows
what "vault" translates to in terms of a service interface and
knows what components to supply to service that interface. This
implementation assumes that all of this information about role
to service mapping, service to component provision, etc. is
taken care of within an internal framework based a bunch of
pre-declared assembly information (either static or derived).
These are two well defined strategies from service resolution and yet even today, we do no have a standard framework approach for a component to declare - "hey, I want to be deployed using strategy X".
Real life scenarios will make a better way to understand the reason behind an architectural choice. Something that I personally found very hard to get when the Avalon 5 discussions took place.
Here is a real life scenario. I write a new component.
public class HelloWorld implements Initializable
{
public void initialize()
{
System.out.println( "hello" );
}
}
This component would probably run in Tweety (the edu. container), will run in Merlin, will not run in Phoenix, and will probably run in Fortress. If we add some javadoc adornments and expand the application level assembly directives it will run in Phoenix. If we add some xinfo files in Merlin is becomes usable as supporting service. Problem is that (a) the definition of an Avalon component is insufficiently defined, and (b) the mechanisms across containers make some very divergent semantic assumptions and present different models in terms of how component to container communication is handled. This means big problems in portability, more overheads for the component developer and extra work for container developers attempting to resolve other container assumptions.
In another thread, Paul Hammant and Peter Goldstein were discussing issues
over how to add more robust semantic contracts to the Frameworks. More work
to do, but acceptable points of convergence appeared to be in the offering.
I'm pretty sure that everybody on this list is tired of fighting and cares about Avalon enough to set aside personal issues and work toward a common goal.
Do you believe that these represent a reasonable set of enumerable points
around which the community can agree, pick the easiest ones to start (you
have to start somewhere, might as well start with what you can do easily so
that community behavior begins to build), and go from there?
Yes, why not. But I'm afraid that only a very few will be able to participate.
For example:
> * Type management [the fork problem must be fixed]
that might be perfectly clear to many here, but I don't have any clue about what that means. And this mean that I can't contribute my vision. And no, I don't think this is intentional, it's just that I (and others here) have missed many architectural discussions.
I am concerned about this as well.
There are a couple of things here - (1) the fork isn't a problem - yes - there are a couple of packages - there are pro and cons about those respective packages - at the end of the day I see a third package emerging based on the clazz package, (2) the meta level stuff in mechanics - data-structures, its not important - what is important is how that information is managed and that's where things like type managers and other Xxxx Manager come into play. Meta is an implementation mechanisms through which we communicate information about a component - it is nothing more, nothing less. The fun is in managing this stuff.
This doesn't mean that you guys have to slow down the process because of me or others that missed a few episodes. Not at all.
Put away any fears that you may have - things are moving forward!
But I think it might be more productive, for everybody, to take a step back and restart from the solutions we want to provide to existing needs and problems. At least to avoid the accademic effect that might be coming out of those very deep and abstract architectural refactoring discussions.
Hope you see my point here.
The point is understood and recognized.
I hope that this email provides some of the context and rationale around this subject. There is another important aspect - if we go back to the Merlin implementation .. after getting things in place and demonstrating deployment of James and some work that Berin was doing, Berin starting digging into Merlin. Initial reactions were positive and within a few days (maybe hours) Berin managed to nail in on the less-than-perfect parts of Merlin - namely the core-core of the implementation. While the Merlin implementation has identified and resolved a much a management aspects, the internal structure of type, profiles and appliance management are difficult to work with - because its complex. This in tern makes it difficult for others to get engaged because Merlin today requires that you grasp a lot stuff. The refactoring work going on is primarily targeting this aspect - facilitating separation of concerns such that we can reach a object model that is easier to understand - where other committers can engage with more confidence. That's part of the process of ensuing that obstacles to community participation are eliminated.
Functional NeedsIf so, how do you propose that the Avalon community begin to formalize its
roadmap, and use it to marshall its resources?
I would love to see each one of us writing an email where he/she explains the functional needs and the expectation out of Avalon and an Avalon container and the plans to use it.
----------------
A component model that enables:
- complete consistency in development approach
- supports and enhances the notions IOC and SOC
- enables consistency across a broad spectrum of development
projects (within and external to Avalon)
A container model that ensures:
- drop dead simple deployment (standalone or embedded)
- automated assembly
- extendable/customizable at every level
- pre-deployment validation
- distributed service composition and runtime management
- pluggable enhancements
- block packaging
- a bunch of stuff in meta-driven policy management that I'm
saving up for a little later
Plans for Use
-------------
OSM internal work used an extended Merlin container. These extensions deal with distributed service management - in particular the ability to deploy and publish a service in one location and the ability for a container in another location to bind this service as a dependency provider. We need solutions that ensure that deployment of a something like a catalina component can be reduced down to nothing more than a few lines of configuration (we are currently running at about 18 lines - but the target is 6-8). We are working on user-centric business model that layers above all of this and provides a view of distributed containers and services as task owned by users, held in workspaces, connected to processes, accessed by members of a digital communities, controlled by community and process policies (express as meta-policy). See http://www.osm.net/doc for more details.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
