Raj Saini wrote:
Hi,
Merlin2 provides pluggable lifestyle extensions. Components can declare a dependency on a lifecycle extension provide. Components can also be provider of lifecycle extension service.
Correct.
The Eclipse IDE (www.eclipse.org) provides the same kind of mechanism where the plugs can declare hook to extension points of other plugs or they can also declare their own extensions. The Merlin2 extension architecture seems similar to the Eclipse extension architecture. In Eclipse IDE it is possible to extend the IDE functionality by writing the plugins.
What is the purpose of the extension architecture in Merlin2?
There ate two ways of interpriting the question - and two distinct answers.
1. What is the purpose of the *component* Extension
architecture in Merlin 2
The purpose is to provide a higher level of flexibility
to component users by eliminating the restriction to
Avalon only lifecycle stages. In effect, different component
models can be handled by the Merlin system - although it is
safe to say that the Avalon model is the core and central
model supported.
2. What is the purpose of the *extendable* architecture of
Merlin 2
Merlin 2 design was initiated on the principal that diffenent
functional elements should be replaceble by components. This
requires at least a bootstrap component deployment framework
so that extensions logic to establish Merlin can be loader
without compromising the support for the core Avalon
component model. This is why a extension facility in Merlin
can have things like depedencies and so on - because the
bootstrap assemably, lifecycle and lifestyle facilities
enable the establishment of extensions that may end up
replacing themselves.
Is it possible to write a core application and extend the functionality by writing pluggable blocks? I am impressed by the Eclipse plugin architecture. Eclipse allows tool venders to write tools and plug them to the base IDE. Does Merlin2 extension architecture server the same purpose for server application
Its a quaestion of granularity.
The "Lifecycle Extension" model only serves to suppliment the deployment and access stages that a component passes through. This is more a concern of the lifecycle model adn less to do blocks.
Componet service management (ability to declare dependecies) and system assembly is much closer to the notion of server extension that I think your getting at.
Finally, the approach and policies applied to component management within Merlin are largely diriven my replaceable components. In that resspect the configuration of merlin containers allows a very high degree of freedom in terms of the component management and containment logic. For example, I can have a container hierachy in which different containters in the hierachy are using different approaches to componet deployment and service access. However, you won't find much document on this area as it is still not quitre settled. There is a little more seperation to be done on the service access policy and handling of custom service access handlers.
Extending the server application by writing self-contained plugs (or components) would be a nice feature. Though Phoenix offers this facility but it is on server level. In my opinion a server developer need deployable components (or plugs) for the server instead of many deployable servers application in a single kernel.
Agreed - I've been thinking recently about a block architecture which is basically a container hierachy packaged into a deploiyment unit. There blocks could be referenced by a container relative to the services exported by the block. Much of the structure for this is already in place within Merlin 2, but more thinking is still required on some aspects concerning the semantics of interaction between container and block.
Hope that helps and gives you an idea where thinking is on this at this time.
Cheers, Steve.
Thanks,
Raj Saini
--
To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
