On Wednesday, Mar 17, 2004, at 02:16 US/Pacific, Niclas Hedhman wrote:
On Wednesday 17 March 2004 17:34, Corey Jewett wrote:
Is there a replacement for ServiceManager/Serviceable that would allow me to resolve a service by ServiceDescriptor? Or perhaps some other mechanism entirely?
Stephen is pointing you to an example of a hook into Merlin's guts, which allow you to "listen in" or to modify the Model on the fly.
You don't write in detail what you are trying to achieve, but I assume that
the services are to be exposed to the external world.
The Finder strategy was close, but I would prefer to stick with release 3.2.5 as it seems to be stable?
Yes. The 3.2.5 version is stable. The 3.3 (CVS HEAD) is a moving target but even so a surprising number of people are staying in sync.
In 3.2.5 there is not a CompositionModel, not the the commission() and resolve() methods of DeploymentModel. Therefore I came to the conclusion that there is no mechanism for instantiating service instances, from the DeploymentModel, in Merlin 3.2.5.
The main difference between 3.2.5 and 3.3 are:
* A restructuring of the relationship between the
composition model and the activation model (or
more simply stated - between model and runtime). * Under 3.2.5 the assembly concepts are under
activation package whereas this has been moved up
to the model level in 3.3. End result is a much
cleaner separation of concerns. * Also a lot of work has been put into improving
naming and general cleanliness of the model. * Through model/runtime restructuring we have arrived
at a completely model-driven approach which has
opened up the potential for a really simple approach
to the customization of a containment context using
facilities (components accessing and manipulating
the model) * Implementation (partial at this time) of a per-
component permission scheme and permission profile
grant mechanism.Instead I'm investigating using a Lifecycle Extension to load service entries into a master list. All services are singletons, but I'm concerned that the instance will be lazy-loaded and thereby cause a catch-22 where the service can't be found because it wasn't instantiated.
Instantiation is not a prerequisite to discovery. In fact all that is needed is the definition of the respective component types. Providing the different component implementations publish meta-info then your in business.
It is acceptable to me that a service must know to declare itself as publishable. This strategy actually adds the potential for better control over what is published.
Under 3.2.5 and 3.3 you can resolve a component by referencing its address (partition + name). Under 3.2.5 this is possible in the block descriptor by declaring a dependency directive. Under 3.3 this can be handled programatically.
If that is the case,
you create the "Publishing Facility", which will receive a reference to the
Composition Model, via a Context entry, and it will then register itself as a
CompositionListener, for 'added' and 'removed' events.
The components should not need to know anything about that this mechanism is
in place.
The Composition package is a bit intimidating, but you will primarily be looking at ComponentModel, its superclass DeploymentModel and perhaps ContainmentModel.
As for different versions of the same service;
I assume you mean different versions of the same component.
You would need to ensure that they are in different <containers>, so that the
Classloading works properly, but other than that, it should be Ok.
If you need different versions of the same service, then you need to bring the
classloader hierarchy yet another level, and the resulting <container> will
NOT be able to expose both services (as classes will conflict in the higher
container.)
I somewhat don't see the purpose, but maybe you can explain your usecase.
I have a number of services that provide back-end data services. They all adhere to a basic request processor interface that won't change. The parameter for this interface is a org.dom4j.Element. All of my services are actually parameterized by an xml tree. We're building the system to scale so that there can be multiple service instances in different JVMs. The reasoning for versioning services is that older versions may be kept running to support other services, while newer services may require the new service. The backing classes for each service may conflict as you mentioned so I planned on putting each service in it's own container that is a sub-container of the core blocks.
This is not strictly necessary. You can declare the version of the the service the a particular component type publishes. As such you can multiple components in the same classloader implementing the same service interface by each component publishing a different version of that interface.
The core blocks would be publishers, db-pooling, etc. ASCII art:
+---------------------+ | Core Service Blocks | +---------------------+ | +---------------+----------------+ | | | +----------+ +----------+ +----------+ | svc A, 1 | | svc A, 2 | | svc A, B | +----------+ +----------+ +----------+
I have several questions that derive from this scenario.
1) Can a block (a publisher) in core access a component in one of the sub-containers.
You can direct component located in the core container can use a service declared in the same or higher classloader provided by a component implementation in a lower classloader. In 3.2.5 this is achieved through dependency directives, and as mentioned above - in 3.3. you can do this programatically as well.
2) Would the composition strategy still be relevant in this scenario?
You could take a couple of approaches:
(a) version the services declarations published by different
component implementations and setup dependencies that reference
version services(b) manually wire things together using dependency directives
3) Am I correct that core services may be used as components in each service?
Yep.
Cheers, Stephen.
p.s. intuition tells me this is more a 3.3 scenario then 3.2.5.
Thanks for your help, Corey
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | 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]
