Hello all,
Although I am now a little familiar with the Avalon framework, containers and (only some) component implementations, I am a long way from being able to clearly comprehend the configuration and assembly aspects of building an application with the requirements below to the various reusable components that currently exist as part of the Avalon project.
I am hoping someone will be able to assist me in proposing a deployment configuration for running one or more processing components (of the same type but different implementation) in a consistent manner both locally (on a linux server) and remotely (on windows workstations) that will allow a consistent view of configuration, logging and management of the components. I am interested in using the Merlin container and as many existing components as possible in the resulting application.
Let me try to explain the general requirements... (I apologize if my terminology lacks consistency, but I will try to keep it clear and consistent...)
1. The application should connect to a bus
a. I assume that one messaging component will be responsible to connect to the bus and register for the necessary subjects using a component configuration
In this context - presumably the subject are typed events? Is that correct?
b. The messaging component could connect over the same network or over the internet through proxy and firewall infrastructure
c. The bus is a mom (imagine jms) that will deliver messages to the messaging component for dispatching to one of the processing components
OK - in this scenario the messaging component is both component and potentially a container. It is a component relative to the mom and it is a container in that it is handling a "potential container" in that is is resolving solutions. The "resolving solutions" term is important here - in that we are either talking about a component with a dependency ono a service registry, or, we are talking about a component that is a service registry (a.k.a. container).
d. The selection of the specific processing component will be based upon the criteria contained in the received message
e. It should be possible to locate the specific component implementation (I assume using a component selector) using this criteria
At this point i time try to forget about Selectors (as per framework spec). Instead think about the problem in terms of features or criteria and the service needed to provide the appropriate handler. I.e. using the criteria the component would turn around a use a finder/registry/broker (lets stick with registry for the moment) to locate a service provider. The second aspects concerns the implementation of that registry .. how does it resolve services to handle requests? There are a bunch of solutions here but the right solution depends somewhat on the application context and granularity.
2. Each processing component should have an independent configuration
No problems here.
a. Although each of the processing components are of the same type, they should be able to be configured independent of each other prior to registering with the component manager
Again - this is OK. What you are describing is a deployment solution where a particular solution may or may not be a particular type of component - what matters is the solution, not the implementation. This corresponds directly with the notion of <component> in a block definition.
The key thing that you will be looking at is component selection semantics - i.e. the ability to adapt incoming criteria to solution selection.
b. Each processing component may have it's own classpath
Technically in Merlin components share a classloader defined within the scope of the enclosing container. Operationally this means you would need to nest components inside a container and ensure that the container publishes the service definition. The container will then appear as a component (with its own classloader). But we may need to do some enhancements with respect to service profile exposed by the container to be able to support good selection semantics.
c. Each component should have its own logging configuration
Can you qualify what you mean my "logging configuration". If you mean that a component should have the ability to declare multiple channels, the assignment of different targets and priorities on these channels - then yes - no problem.
3. Components should be manageable
a. It should be possible to remotely (preferably via the bus) rebuild(?) (dispose, create, configure, initialize) processing components independent from each other
This is all related to the facilities stuff currently under development. The facility would listen for management requests and then through access to the meta-model, locate the target component and manipulate its runtime and model state. I.e. the tools are there that make this possible but we are talking about 3.3 which may be an issue you should be aware of.
b. For testing and debugging it would be ideal to be able to create a new classloader when rebuilding each component
In principal - yes. Have not tried this myself but the model allows removal of component and container models followed by the addition of new models. There is also model replication that will help in putting this together.
c. For testing and debugging it would be ideal to be able to check for library updates on a central repository server for library updates prior to creating the classloader (currently we use a JNLP solution)
What is the sort of condition your thinking of? Something like "get latests released component version" or "Get latest for solution for this dependency?".
d. It should be able to query a management interface of each of the processing components via the bus
In th longer term this should arrive via a JMX facility. If your in a real hurry you will need to roll-your-own.
Cheers, Steve.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
