Home » Eclipse Projects » Equinox » Avalon
| Avalon [message #10404] |
Sat, 08 March 2003 09:53  |
Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
I contacted Leo Simons from Avalon and got a reply from him. Leo does
not have time to read the whole thread but this was his reaction. He
asked Steve to react, he informed me he joined the newsgroup so I expect
his reaction as well:
Leo Simons wrote:
It does sound like avalon can be of use, as we do useful stuff in the
domains of component and dependency management and have a solid services
model. While avalon is not specifically about "plugins", there are
interesting albeit alpha developments
(http://avalon.apache.org/sandbox/) dealing with dynamic service
discovery and resolution.
I'm CCing Stephen Mcconnell who is most active in that area of avalon
right now; he might have a good idea or two :D
Nevertheless, I'll try and provide you with some starting points based
on limited knowledge of eclipse. Feel free to FWd or CC anywhere that
makes sense.
From limited knowledge it sounds like the dependency management
features needed for the eclipse plugin architecture are better
implemented by OSGi compared to current avalon containers, as the
dependency management of avalon shines best on a level a little more
fine-grained than what I understand the OSGi setup to be, and you don't
need really fine dep. management for plugins. That said, there are
interesting non-released developments in avalon which /do/ tackle this
stuff in quite interesting ways.
How avalon might fit in...hmm. Avalon-framework is a rigid specification
for a component lifecycle which is easily adapted or modded to support
another lifecycle (I've experimented with mapping the OSGi lifecycle
onto an avalonized component and vice versa, and it is perfectly
doable). It should be perfectly doable and smart to base a plugin
lifecycle contract around avalon-framework, but my guess is eclipse
already has a plugin lifecycle definition, so I'm not sure if this is
what you're looking for.
Avalon-Phoenix can basically be seen as a server-oriented COP platform
(ie it is a generic AppServer) which I think is more selective in the
"plugin patterns" it supports compared to eclipse. It starts off with
providing the container side support for avalon-framework and then adds
additional features and constraints, like exposing its kernel via JMX.
While it might be possible to "embed" phoenix into the eclipse platform
or to refactor the eclipse platform to be layered on top of phoenix, I
am guessing the implications and influence that would result in would
mean a huge codebase shift, so I'm not sure if its a viable option.
Also phoenix is not very dynamic in nature: AFAIK, it is mostly in use
as an appserver for long-running enterprise-grade server applications,
ie the likely use case is to run a mail/web/EJB/ORB/etc service on top
of it.
Avalon-Fortress and Avalon-Merlin (nonstable code at the moment) are
more "lightweight" more "dynamic" "versions" of phoenix, more suitable
for embedding inside an existing platform, though somewhat less
suitable for use as the base of the system (ie if eclipse
platform were to "embed" an avalon container in its internals for
support of the plugin architecture, it would have a hard time embedding
phoenix and a good time embedding fortress or merlin).
Of the two, merlin provides by far the more features, accompanied by
more semantic rigidness, requirements and concepts to grasp and adopt.
It should be feasible to implement a plugin manager as a merlin
"appliance" (http://avalon.apache.org/sandbox/assembly/appliance.html),
which would enable the dynamic management features of merlin to kick in
for handling plugin (de)activation. Steve, maybe you could give an
overview of how such a thing might look in the real world?
cheers!
- Leo Simons
|
|
|
| Re: Avalon [message #10507 is a reply to message #10404] |
Sat, 08 March 2003 12:23  |
| Eclipse User |
|
|
|
Originally posted by: mcconnell.apache.org
Peter:
As Leo noted - I've been working on a lot of content dealing with
service management as part of the Avalon Project over on Apache. This
work is represented by a number of projects - the following is a quick
summary:
The Assembly Package
--------------------
assembly
assembly-spi
meta
The assembly package is all about the management of the
the deployment of services provided by a component. The
package provides support for the declaration of meta
information describing component dependencies, and
deployment templates.
Components in the framework my have dependencies on services
provided by other components, which in turn may have
dependencies of their own. In addition, components can
declare (as part of their meta-info) particular lifecycle
stages (such as initiation or configuration) and the type
of stage provider it needs to handle that stage. So in
effect, components can be deployed with classic runtime
dependencies together with deployment dependencies (because
deployment stage providers are themselves components).
Assembly services include ordered deployment and
decommissioning, a range of "lifestyle" handlers (things
like thread-safe, per-thread, singleton, transient, or
custom policies). The package includes facilities for:
classloader management and cascading repositories for
types, templates, service definitions and appliance
instances (appliance is simply an instantiation of a
particular component deployment scenario).
The Merlin Project
------------------
merlin
merlin-spi
merlin-jndi
merlin-bootstrap
The Merlin Project is a service management system based
on the Assembly framework. If focus is to provide support
for the encapsulation of a set of components and services
within functional blocks. Blocks enable the separation of
components as an implementation solutions, from services
established by the component implementation.
The containment model supports hierarchical component
structuring within an implementation and will enable
publication of these composite component models as a classic
component (which in turn may be used as a provider of
services to other components).
Looking at this from the point of view of a plug-in deployment - I
don't see any immediate issues. If plug-ins are components (which
is minimally a null-constructor + meta-data in XML) then either the
Assembly and/or Merlin packages will provide a solution. The assembly
package does not get into management of collections or scoped
components, instead - these notions have been separated out into the
Merlin platform. Assembly focussed on the management of component
deployment (including assembly, instantiation, activation,
decommissioning and termination) whereas Merlin focussed on composite
component assembly, service encapsulation and service distribution.
Something to keep in mind is that the Meta/Assembly/Merlin suite is
in active development. It is being used in production applications -
however, I would note that current users are willing to tolerate
API changes - and also somewhat significant is that all current users
are dealing with complex dependency chain scenarios.
Components aleary in place in Avalon that are based on the Meta package
meta info and meta data models include:
* ORB (CORBA 2.4) - opensource and coming to Apache
* PSDL & PSS (OMG Persistence Spec) - compiler and runtime
* INS (OMG Interoperable Naming Service)
* Time (OMG Time Service)
* Corbaloc (remote service access protocol)
Just a note - INS and Time are distributed services that will can be
included in the Merlin block composition model. The principal is
that a block can encapsulate implementation details and remote services
highly scalable distributed service solutions (i.e. plug-in X does not
need to be local).
There are a bunch of other related projects I'm involved with that
leverage Meta/Assembly and Merlin. Documentation is available at the
at the following URL:
http://www.osm.net/products/avalon/enterprise/index.html
As Pete mentioned - I'm now subscribed (but haven't read all of the past
month just yet). But I can answer questions, etc.
Cheers, Steve.
pkriens wrote:
> I contacted Leo Simons from Avalon and got a reply from him. Leo does
> not have time to read the whole thread but this was his reaction. He
> asked Steve to react, he informed me he joined the newsgroup so I expect
> his reaction as well:
>
> Leo Simons wrote:
> It does sound like avalon can be of use, as we do useful stuff in the
> domains of component and dependency management and have a solid services
> model. While avalon is not specifically about "plugins", there are
> interesting albeit alpha developments
> (http://avalon.apache.org/sandbox/) dealing with dynamic service
> discovery and resolution.
> I'm CCing Stephen Mcconnell who is most active in that area of avalon
> right now; he might have a good idea or two :D
>
> Nevertheless, I'll try and provide you with some starting points based
> on limited knowledge of eclipse. Feel free to FWd or CC anywhere that
> makes sense.
>
> From limited knowledge it sounds like the dependency management
> features needed for the eclipse plugin architecture are better
> implemented by OSGi compared to current avalon containers, as the
> dependency management of avalon shines best on a level a little more
> fine-grained than what I understand the OSGi setup to be, and you don't
> need really fine dep. management for plugins. That said, there are
> interesting non-released developments in avalon which /do/ tackle this
> stuff in quite interesting ways.
>
> How avalon might fit in...hmm. Avalon-framework is a rigid specification
> for a component lifecycle which is easily adapted or modded to support
> another lifecycle (I've experimented with mapping the OSGi lifecycle
> onto an avalonized component and vice versa, and it is perfectly
> doable). It should be perfectly doable and smart to base a plugin
> lifecycle contract around avalon-framework, but my guess is eclipse
> already has a plugin lifecycle definition, so I'm not sure if this is
> what you're looking for.
>
> Avalon-Phoenix can basically be seen as a server-oriented COP platform
> (ie it is a generic AppServer) which I think is more selective in the
> "plugin patterns" it supports compared to eclipse. It starts off with
> providing the container side support for avalon-framework and then adds
> additional features and constraints, like exposing its kernel via JMX.
> While it might be possible to "embed" phoenix into the eclipse platform
> or to refactor the eclipse platform to be layered on top of phoenix, I
> am guessing the implications and influence that would result in would
> mean a huge codebase shift, so I'm not sure if its a viable option.
> Also phoenix is not very dynamic in nature: AFAIK, it is mostly in use
> as an appserver for long-running enterprise-grade server applications,
> ie the likely use case is to run a mail/web/EJB/ORB/etc service on top
> of it.
>
> Avalon-Fortress and Avalon-Merlin (nonstable code at the moment) are
> more "lightweight" more "dynamic" "versions" of phoenix, more suitable
> for embedding inside an existing platform, though somewhat less
> suitable for use as the base of the system (ie if eclipse
> platform were to "embed" an avalon container in its internals for
> support of the plugin architecture, it would have a hard time embedding
> phoenix and a good time embedding fortress or merlin).
>
> Of the two, merlin provides by far the more features, accompanied by
> more semantic rigidness, requirements and concepts to grasp and adopt.
> It should be feasible to implement a plugin manager as a merlin
> "appliance" (http://avalon.apache.org/sandbox/assembly/appliance.html),
> which would enable the dynamic management features of merlin to kick in
> for handling plugin (de)activation. Steve, maybe you could give an
> overview of how such a thing might look in the real world?
>
> cheers!
>
> - Leo Simons
>
>
>
|
|
|
Goto Forum:
Current Time: Sun May 04 00:05:56 EDT 2025
Powered by FUDForum. Page generated in 0.02457 seconds |
Home