Ole Bulbuk wrote:
>The nice thing about containers is: There are so many to choose ... ;-))
>
>I am developing a single server application that should run (about) 24h a
>day. So far (for the more prototype stage) I have used Phoenix for the whole
>application and inside of it the Excalibur Component Manager (because of the
>document "Developing with Apache Avalon"). But now I would like to make the
>real production quality implementation but I still don't know which
>component/service container to use. The application should be shipped during
>January next year. So the container should have release quality then.
>
>The choice seems to be:
>1. Phoenix: The new official release has just come out and it
> seems to support the new service stuff and the
> new unified? configuration but seems to be
> oversized for a single application because it is
> build to host many applications.
> Or is this a feature that doesn't cost any
> performance during runtime (due to overhead)?
>2. Tweety: Only for educational purposes and pre-alpha.
>3. Myrmidon: Pre-alpha and specially made for Ant2.
>4. Fortress: Pre-alpha and needs a container itself.
>5. Merlin: Pre-alpha and needs a container itself.
> Where is the difference to Fortress when the
> unification of interfaces and configuration has
> been successful????
>
The main differences between Fortress and Merlin are related to the
handling of component dependencies. In both ECM and Fortress when you
lookup a compoent in a manager, you get back an instance of a type
implementing the interface classname supplied to the lookup operation.
Neither ECM or Fortress manage depedencies that the supplying component
may have. In the case of Merlin, a lookup request will return a service
reference backed by a fully assembled component. For example, in Merlin
- component A can depedend on component B, C and D - D can depend on
component E and B, etc. Merlin will take care of the assembly for you.
In the case of Fortress and ECM - the component supplying a service
cannot have depedencies.
Other differences relate to the meta-info and meta-data models. In ECM
and Fortress there is something called a Role Manager which is basically
managing configuration fragments as a means to better control and
reference configuration information. In the case of Merlin,
configuration infromation about a type and profiles of a type are
managed as a formal meta API. There is inital work in Fortress to
support the meta model whereas Merlin's implementation of the meta model
is complete. Fortress support for RoleManager means that it is much
easier to migrate from ECM to Fortress and they both share the same
conceptual foundations.
Both Fortress and Merlin support a common lifecycle extension mechanism
(refer excalibur/container for details). Respective implementations
differ in that a Merlin extension handler can be a full component with
their own dependencies. This reflects the high priority taken in Merlin
to isolate the mechanics of component assembly from the container system.
In terms of realse schedules - there is work currently going on to
provide web based container navigation and container distribution. The
navigation functionality allows an adminstrator to see the entire meta
model of component types and profiles, navigate across containers,
navigate to service descriptions, and even lauch web applications based
on meta information declared within service descriptors. The
distribution work is focussed on the ability to inport and export
service references between containers running on different machines and
enable late binding of these services - ie. the ability to create a
distributed service solution that crosses multiple organizations - with
full support for late activation irrespective of where a component is
within the network. Both the navigation and distribution functions will
come into the CVS progressively - in the meantime, immediate focus is on
validating Merlin 2 against some large scale distributed appications.
This validation process will impact interfaces and implememtations (not
dramatically, but sufficient to keep Merlin as pre-release for a few
more months). When release occurs, Merlin will be much more that a
container - it will be a servcie management solution on which existing
on-line remotely accessible services can be dynamically incorporated
into your applications.
Cheers, Steve.
>6. Plexus: Pre-alpha, specially made for Turbine and needs a
> container itself.
>7. ECM: The Excalibur Component Manager seems to be
> outdated now and needs a container itself.
>
>So is it true that writing new containers has become such a popular sport
>that there is none left that can be used without feeling guilty in one way
>or the other??? ;-)))
>
>So in January 2003 I would like to ship a *stable and modern* single server
>application but which container should I choose???
>
>Any help/opinion is welcome,
>
>Ole
>
>
--
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]>
