You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@osm.net> on 2002/05/15 02:01:33 UTC
Re: [Newbie question] Confused (with correction)
Fredrik Hultin wrote:
>Hi,
>I have tried to figure how the different efforts under the Avalon
>umbrella are intended. But I am still not clear on why Phoenix doesn't
>use Excalibur's component manager or where Fortress fits into the
>picture.
>
Taking a step back for a moment - here is a short description of the
five main areas within Avalon:
1. The Avalon framework - basically a set of building blocks for the
construction of component based solutions. Within the framework you have
a set well-developed concepts that share a central notion of an object
lifecycle within the context of a development approached referred to as
Inversion of Control (IOC). Following IOC patters results in separation
the managing container from the component. In practice, the container is
an implementation issue - but the components, their lifecycle and the
contracts they support are formally declared. That's why we see the
component details in framework and no formal definition of a container.
2. Excalibur is a collection of all sorts of things that leverage the
notions of IOC. Many of the packages in Excalibur use the framework as a
construction toolkit. I tend to dip into Excalibur from time to time -
support for internationalization - some where to put framework
extensions - ideas concerning component management and containers, etc.
There are at least three different contains within Excalibur - the
original ECM (which reflects early work relative to the framework
abstractions) - Fortress (from my observation is something like
"son-of-Excalibur" - still evolving, but I believe a step forward in
thinking about formalizing utilities supporting creation od containers).
There is Merlin which is a container that is more like a stripped-down
Phoenix with tweaks and go-fast additions like support for
ServiceManager, Serviceable, ServiceSelector.
3. Phoenix - this is a real serious container - basically a container
for running applications (as compared to Merlin, which is much more a
container for running components). Phoenix provides a lot more
functionality in respect to deployment flexibility - targeted towards
the deployment manager (as opposed to Merlin's focus towards a developer).
4. LogKit - a logging implementation that respects IOC patterns
5. Applications - a bunch of very different application projects that
are capable of execution as packaged applications within the context of
the Phoenix platform
>
>Is the component manager deprecated and has Fortress taken over? Why
>then doesn't Phoenix use Fortress?
>
Keep in mind that ComponentManager and Fortess are really two different
things. ComponentManager is simply a utility used in one of several
phases in the management of component. It is not a manager of a
component - instead it is a utility through which a component can access
the components it is dependent on. Recently the Avlon framework has been
updated in include ServiceManager as a replacement with the intention of
deprecating ComponentManager in the next release. ServiceManager and
ComponentManager are identical except that ServiceManager removes the
restriction of the Component marker interface (and therefore enables a
much broader scope of applications that can leverage the Avalon
framework and component model).
Fortress on the other-hand reflects a lot of the discussions that were
going on at the time of the introduction of ServiceManager and is
addressing the notion of a container. I would not class Fortess as
signed, sealed and delivered - but it is interesting content. Keep in
mind the point I mentioned above - containers are an implementation
concern - the components are an interface and formal semantics concern -
so don't worry too much about which container is being used where -
because in an IOC world, components don't need to know about their
containers. As for Phoenix/Fortress - in my mind these are two different
container approaches that are addressing two different scales of
component management. In addition, Phoenix is strong, reliable, and
validated - Fortress is still in hanger.
>
>What is the intent for the future? What projects will survive and which
>will die in the near future?
>
We are seeing subtle and progressive elimination of marker interfaces -
for example, the replacement of Composable/ComponentManager with the
Serviceable/ServiceManager. This trend is also going on at the Phoenix
level where with luck we should soon be free of the Block marker
interface. In parallel, withdrawal of marker interfaces introduces
stronger dependencies on meta-information and I except we will see
development in that erea both in terms of tools supporting automatic
meta-info generation, and a convergence of approaches to component
related meta-management as various containers expose and validate best
practices in this area. In terms of what will die - I would recommend to
avoid using the ComponentManager, and instead focus on tools and
utilities that leverage ServiceManager (but that statement is bound to
be controversial because lots of people are using ECM which has strong
Component/ComponentManager ties and ECM has not been upgraded to support
the Serviceable/ServiceManger). Over on the Jakarta Avalon Apps group,
the Database, FTP server, HSQL, HTTP proxy, Overlord, Xcommand and the
Enterprise suite (ORB, Interoperable Naming Service, Persistent State
Service, Time Service ) are all component based applications with
suppport for Serviceable/ServiceManager semantics. Also, Phoenix offers
full support for the new Servicable/ServiceManager.
In addition to above, ECM has to deal with legacy issues concerning the
usage of the LogKit interface (as distinct from the abstract framework
Logger package) - which appears to be restricting its development to
some degree. My guess is that as Fortress matures will see more dialog
on this area - and in particular, discussion of ECM management and
evolution with respect to Fortress and the evolution of the framework.
Bottom line - the container isn't the issue - the critical aspects are
down in the framework. When emerges from Excalibur in the container area
are just different approaches to similar problems they tend to reflect
different priorities. And finally, rolling your own container is also
totally valid - in fact in our internal applications we have several
"custom" containers that deal with families of components - and cases
where you just want to do something simply and directly. At the end of
the day our applications leverage custom containers (typically at a low
level), Merlin at the component level and Phoenix at the application level.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Documentation (was ... confused (with correction))
Posted by Leo Simons <le...@apache.org>.
> I will do what I can! I'm not an expert in CVS, but I have used it. Most
> of what I've done has been through a UI (JCvs for example), although I'm
> not afraid of a command line :-)
I used WinCVS for about a year...was never a prob ;)
> The areas I'm not familiar with are branches, tags, and those kinds of
> things. I can certainly checkout, update, etc. though.
metoo...we use 'em sporadically.
> I've wanted to dig into the xdocs stuff for a while so this would be a
> good start for me. I'll grab the latest and start from there. Any
> particular area you want targeted? Avalon framework, Excalibur, etc?
> Stephen (prefer Steve?) mentioned the .../notes/comments stuff, so I
> could easily start there.
Mostly the "overview" part, and I would also like to see some "hands-on"
stuff (ie "Avalon by Example" material).
> Another question... how would you all like to 'view' this? Just send
> patches or whatever, or would you like me to generate the docs/site on
> my local machine and let you all preview it before sending it in?
Nah...if you think it looks okay I'll trust you and just patch. No
objections against previews tho'.
I'd prefer if you put the patches into bugzilla. That's what it's for,
innit?
cheers!
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Documentation
Posted by Stephen McConnell <mc...@osm.net>.
Robert wrote:
>I will do what I can! I'm not an expert in CVS, but I have used it. Most
>of what I've done has been through a UI (JCvs for example), although I'm
>not afraid of a command line :-)
>
>The areas I'm not familiar with are branches, tags, and those kinds of
>things. I can certainly checkout, update, etc. though.
>
>I've wanted to dig into the xdocs stuff for a while so this would be a
>good start for me. I'll grab the latest and start from there. Any
>particular area you want targeted? Avalon framework, Excalibur, etc?
>Stephen (prefer Steve?) mentioned the .../notes/comments stuff, so I
>could easily start there.
>
Here are initial comments on the Project Home Page
http://jakarta.apache.org/avalon/index.html
"What is it?" - this needs to be much more specific - it should
present something like a bulleted into to the subprojects - should
not say anything about what it does not do - should not be phrased
in negatives.
"Project Goals" - needs to be presented in a more aggressive fashion,
e.g. The Avalon goal is to delivering software engineering solutions.
"Sub-Projects" - this section needs to more concrete content - e.g.
the framework description should say that it is a set of interfaces
and implementations supporting the creation and managemnt of
components - excalibur should be rewritten to be better describe
that fact that there is a lot of "above-the-framework" and IOC based
mini-projects covering .... LogKit should updated to say that it an
IOC based logging framework (as opposed to the logging framework used
by Avalon). Cornerstone should be included in Appplications and
Applications could be expended with a table with very short
descriptions of each project.
Cheers, Steve.
>
>Another question... how would you all like to 'view' this? Just send
>patches or whatever, or would you like me to generate the docs/site on
>my local machine and let you all preview it before sending it in? I have
>a cable modem and my IP hasn't changed in over 6 months so I certainly
>don't mind doing so. I use my machine for demos for my company all the
>time anyway so it is always up. Just a thought.
>
>
I have no problem receiving directly small or large attachements.
Response time on answers my be sporadic as I will be in and out of the
office a lot over the next 7-10 days.
Cheers, Steve.
>- Robert
>
>-----Original Message-----
>From: Leo Simons [mailto:leosimons@apache.org]
>Sent: Wednesday, May 15, 2002 1:49 PM
>To: Avalon Developers List
>Subject: RE: [Newbie question] Confused (with correction)
>
>Robert,
>
>that would be great! We really need a few extra hands working on the
>docs...
>
>You know CVS? You'll need to, really.
>
>The XML format we use is defined in DTDs in
>
>jakarta-avalon/src/xdocs/dtd
>
>where the relevant one is document-v10.dtd. It is a lot easier to just
>look at the xml files in
>
>jakarta-avalon/src/xdocs
>
>though, and do your work by copy-pasting at first.
>
>To create a new page, you also need to add an entry to the book.xml
>file, which defines the menu on the left. Should be easy to figure out
>from the example alone (there's a dtd for it too, if you want one).
>
>I'm working on reorganising text we currently have so that the
>information in there is easier to find (I'm done for framework and
>phoenix). If you supply patches actually improving that information, we
>all will be very happy =)
>
>Oh, address for patches is this list.
>
>The info is in the heads of the committers here, as well as scattered
>across the website and in the mailing list archive. Getting it out of
>there and into something useful is the hard part ;)
>
>The easiest way to be productive would be to figure out what information
>you personally miss on the website, dig into all available sources to
>find that information, and if it is not there or too difficult to find,
>to ask on the mailing list.
>
>For starters, it'd be nice if this little bit of info went online for
>the next time someone has the same thought :)
>
>Lastly, don't worry too much about stepping on someone's toes as far as
>the docs are concerned...we've got though skin (wrt writing skills, at
>least)
>
>- Leo
>
>On Wed, 2002-05-15 at 19:39, Robert wrote:
>
>
>>I wouldn't mind helping out here if I can(?). If I had the right info
>>
>>
>to
>
>
>>add and the format, I would be happy to help with the docs/website
>>unless someone else has already volunteered with that. Maybe I can
>>
>>
>bring
>
>
>>that use perspective on it...
>>
>>Just a thought
>>
>>- Robert
>>
>>
>
>
>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Documentation (was ... confused (with correction))
Posted by Robert <rm...@bull-enterprises.com>.
I will do what I can! I'm not an expert in CVS, but I have used it. Most
of what I've done has been through a UI (JCvs for example), although I'm
not afraid of a command line :-)
The areas I'm not familiar with are branches, tags, and those kinds of
things. I can certainly checkout, update, etc. though.
I've wanted to dig into the xdocs stuff for a while so this would be a
good start for me. I'll grab the latest and start from there. Any
particular area you want targeted? Avalon framework, Excalibur, etc?
Stephen (prefer Steve?) mentioned the .../notes/comments stuff, so I
could easily start there.
Another question... how would you all like to 'view' this? Just send
patches or whatever, or would you like me to generate the docs/site on
my local machine and let you all preview it before sending it in? I have
a cable modem and my IP hasn't changed in over 6 months so I certainly
don't mind doing so. I use my machine for demos for my company all the
time anyway so it is always up. Just a thought.
- Robert
-----Original Message-----
From: Leo Simons [mailto:leosimons@apache.org]
Sent: Wednesday, May 15, 2002 1:49 PM
To: Avalon Developers List
Subject: RE: [Newbie question] Confused (with correction)
Robert,
that would be great! We really need a few extra hands working on the
docs...
You know CVS? You'll need to, really.
The XML format we use is defined in DTDs in
jakarta-avalon/src/xdocs/dtd
where the relevant one is document-v10.dtd. It is a lot easier to just
look at the xml files in
jakarta-avalon/src/xdocs
though, and do your work by copy-pasting at first.
To create a new page, you also need to add an entry to the book.xml
file, which defines the menu on the left. Should be easy to figure out
from the example alone (there's a dtd for it too, if you want one).
I'm working on reorganising text we currently have so that the
information in there is easier to find (I'm done for framework and
phoenix). If you supply patches actually improving that information, we
all will be very happy =)
Oh, address for patches is this list.
The info is in the heads of the committers here, as well as scattered
across the website and in the mailing list archive. Getting it out of
there and into something useful is the hard part ;)
The easiest way to be productive would be to figure out what information
you personally miss on the website, dig into all available sources to
find that information, and if it is not there or too difficult to find,
to ask on the mailing list.
For starters, it'd be nice if this little bit of info went online for
the next time someone has the same thought :)
Lastly, don't worry too much about stepping on someone's toes as far as
the docs are concerned...we've got though skin (wrt writing skills, at
least)
- Leo
On Wed, 2002-05-15 at 19:39, Robert wrote:
> I wouldn't mind helping out here if I can(?). If I had the right info
to
> add and the format, I would be happy to help with the docs/website
> unless someone else has already volunteered with that. Maybe I can
bring
> that use perspective on it...
>
> Just a thought
>
> - Robert
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Newbie question] Confused (with correction)
Posted by Leo Simons <le...@apache.org>.
Robert,
that would be great! We really need a few extra hands working on the
docs...
You know CVS? You'll need to, really.
The XML format we use is defined in DTDs in
jakarta-avalon/src/xdocs/dtd
where the relevant one is document-v10.dtd. It is a lot easier to just
look at the xml files in
jakarta-avalon/src/xdocs
though, and do your work by copy-pasting at first.
To create a new page, you also need to add an entry to the book.xml
file, which defines the menu on the left. Should be easy to figure out
from the example alone (there's a dtd for it too, if you want one).
I'm working on reorganising text we currently have so that the
information in there is easier to find (I'm done for framework and
phoenix). If you supply patches actually improving that information, we
all will be very happy =)
Oh, address for patches is this list.
The info is in the heads of the committers here, as well as scattered
across the website and in the mailing list archive. Getting it out of
there and into something useful is the hard part ;)
The easiest way to be productive would be to figure out what information
you personally miss on the website, dig into all available sources to
find that information, and if it is not there or too difficult to find,
to ask on the mailing list.
For starters, it'd be nice if this little bit of info went online for
the next time someone has the same thought :)
Lastly, don't worry too much about stepping on someone's toes as far as
the docs are concerned...we've got though skin (wrt writing skills, at
least)
- Leo
On Wed, 2002-05-15 at 19:39, Robert wrote:
> I wouldn't mind helping out here if I can(?). If I had the right info to
> add and the format, I would be happy to help with the docs/website
> unless someone else has already volunteered with that. Maybe I can bring
> that use perspective on it...
>
> Just a thought
>
> - Robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Newbie question] Confused (with correction)
Posted by Stephen McConnell <mc...@osm.net>.
Robert wrote:
>I wouldn't mind helping out here if I can(?).
>
Superb - yes!!
>If I had the right info to add and the format, I would be
>happy to help with the docs/website unless someone else has
>already volunteered with that. Maybe I can bring
>that use perspective on it...
>
This sonds like a venture in the making !!
* Leo has already put some new content together and knows
the doc system
* I'll start pulling together notes and recommendations and
get it to the list.
* if you can do some development in on the content Leo has
already based on outlines/notes/comments ... that would
be great (read this as a big understatement)
Cheers, Steve.
>
>
>Just a thought
>
>- Robert
>
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@osm.net]
>Sent: Wednesday, May 15, 2002 12:39 PM
>To: Avalon Developers List
>Subject: Re: [Newbie question] Confused (with correction)
>
>
>
>Robert wrote:
>
>
>>I must say Stephen, this is the best description and comparison I've
>>ever seen on the various projects/apps. This should go on the website!
>>
>>
>
>I've been reading over the intro package for the Avalon website and
>something struck me ... it doesn't actually say right up front what
>Avalon is/does. When I wrote the info you referenced - I had Leo in
>mind as a potential 'target' and an underlying 'agenda' to instigate
>some more direct messages on the web-site. However - this is also a
>terrible time for me to try to do anything too serious - just way - way
>- way to busy on admin/business/finance stuff. In an ideal world I
>would like to kick around a bunch of things concerning the web-site but
>it really difficult just at the moment - about all I can offer is
>critique - and I'm not happy about doing that without a corresponding
>contribution of something useful. If someone has cycles available I can
>
>push out issues we need to deal with - I can provide good pointers to
>what needs to chage (positives instead of negatives / make the techo
>stuff move to background / focus on the value proposition / define the
>targets / define the products / define the services / clarify the Avalon
>
>brand / enforce the brand / etc ).
>
>Cheers, Steve.
>
>
>>- Robert
>>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>Sent: Tuesday, May 14, 2002 7:02 PM
>>To: Avalon Developers List
>>Subject: Re: [Newbie question] Confused (with correction)
>>
>>
>>Fredrik Hultin wrote:
>>
>>
>>>Hi,
>>>I have tried to figure how the different efforts under the Avalon
>>>umbrella are intended. But I am still not clear on why Phoenix
>>>
>doesn't
>
>>>use Excalibur's component manager or where Fortress fits into the
>>>picture.
>>>
>>>
>>Taking a step back for a moment - here is a short description of the
>>five main areas within Avalon:
>>
>>1. The Avalon framework - basically a set of building blocks for the
>>construction of component based solutions. Within the framework you
>>
>have
>
>>a set well-developed concepts that share a central notion of an object
>>lifecycle within the context of a development approached referred to as
>>Inversion of Control (IOC). Following IOC patters results in separation
>>the managing container from the component. In practice, the container
>>
>is
>
>>an implementation issue - but the components, their lifecycle and the
>>contracts they support are formally declared. That's why we see the
>>component details in framework and no formal definition of a container.
>>
>>2. Excalibur is a collection of all sorts of things that leverage the
>>notions of IOC. Many of the packages in Excalibur use the framework as
>>
>a
>
>>construction toolkit. I tend to dip into Excalibur from time to time -
>>support for internationalization - some where to put framework
>>extensions - ideas concerning component management and containers, etc.
>>There are at least three different contains within Excalibur - the
>>original ECM (which reflects early work relative to the framework
>>abstractions) - Fortress (from my observation is something like
>>"son-of-Excalibur" - still evolving, but I believe a step forward in
>>thinking about formalizing utilities supporting creation od
>>
>containers).
>
>>There is Merlin which is a container that is more like a stripped-down
>>Phoenix with tweaks and go-fast additions like support for
>>ServiceManager, Serviceable, ServiceSelector.
>>
>>3. Phoenix - this is a real serious container - basically a container
>>for running applications (as compared to Merlin, which is much more a
>>container for running components). Phoenix provides a lot more
>>functionality in respect to deployment flexibility - targeted towards
>>the deployment manager (as opposed to Merlin's focus towards a
>>developer).
>>
>>4. LogKit - a logging implementation that respects IOC patterns
>>
>>5. Applications - a bunch of very different application projects that
>>are capable of execution as packaged applications within the context of
>>the Phoenix platform
>>
>>
>>>Is the component manager deprecated and has Fortress taken over? Why
>>>then doesn't Phoenix use Fortress?
>>>
>>>
>>Keep in mind that ComponentManager and Fortess are really two different
>>things. ComponentManager is simply a utility used in one of several
>>phases in the management of component. It is not a manager of a
>>component - instead it is a utility through which a component can
>>
>access
>
>>the components it is dependent on. Recently the Avlon framework has
>>
>been
>
>>updated in include ServiceManager as a replacement with the intention
>>
>of
>
>>deprecating ComponentManager in the next release. ServiceManager and
>>ComponentManager are identical except that ServiceManager removes the
>>restriction of the Component marker interface (and therefore enables a
>>much broader scope of applications that can leverage the Avalon
>>framework and component model).
>>
>>Fortress on the other-hand reflects a lot of the discussions that were
>>going on at the time of the introduction of ServiceManager and is
>>addressing the notion of a container. I would not class Fortess as
>>signed, sealed and delivered - but it is interesting content. Keep in
>>mind the point I mentioned above - containers are an implementation
>>concern - the components are an interface and formal semantics concern
>>
>-
>
>>so don't worry too much about which container is being used where -
>>because in an IOC world, components don't need to know about their
>>containers. As for Phoenix/Fortress - in my mind these are two
>>
>different
>
>>container approaches that are addressing two different scales of
>>component management. In addition, Phoenix is strong, reliable, and
>>validated - Fortress is still in hanger.
>>
>>
>>>What is the intent for the future? What projects will survive and
>>>
>>which
>>
>>>will die in the near future?
>>>
>>>
>>We are seeing subtle and progressive elimination of marker interfaces -
>>for example, the replacement of Composable/ComponentManager with the
>>Serviceable/ServiceManager. This trend is also going on at the Phoenix
>>level where with luck we should soon be free of the Block marker
>>interface. In parallel, withdrawal of marker interfaces introduces
>>stronger dependencies on meta-information and I except we will see
>>development in that erea both in terms of tools supporting automatic
>>meta-info generation, and a convergence of approaches to component
>>related meta-management as various containers expose and validate best
>>practices in this area. In terms of what will die - I would recommend
>>
>to
>
>>avoid using the ComponentManager, and instead focus on tools and
>>utilities that leverage ServiceManager (but that statement is bound to
>>be controversial because lots of people are using ECM which has strong
>>Component/ComponentManager ties and ECM has not been upgraded to
>>
>support
>
>>the Serviceable/ServiceManger). Over on the Jakarta Avalon Apps group,
>>the Database, FTP server, HSQL, HTTP proxy, Overlord, Xcommand and the
>>Enterprise suite (ORB, Interoperable Naming Service, Persistent State
>>Service, Time Service ) are all component based applications with
>>suppport for Serviceable/ServiceManager semantics. Also, Phoenix offers
>>full support for the new Servicable/ServiceManager.
>>
>>In addition to above, ECM has to deal with legacy issues concerning the
>>usage of the LogKit interface (as distinct from the abstract framework
>>Logger package) - which appears to be restricting its development to
>>some degree. My guess is that as Fortress matures will see more dialog
>>on this area - and in particular, discussion of ECM management and
>>evolution with respect to Fortress and the evolution of the framework.
>>
>>Bottom line - the container isn't the issue - the critical aspects are
>>down in the framework. When emerges from Excalibur in the container
>>
>area
>
>>are just different approaches to similar problems they tend to reflect
>>different priorities. And finally, rolling your own container is also
>>totally valid - in fact in our internal applications we have several
>>"custom" containers that deal with families of components - and cases
>>where you just want to do something simply and directly. At the end of
>>the day our applications leverage custom containers (typically at a low
>>level), Merlin at the component level and Phoenix at the application
>>level.
>>
>>Cheers, Steve.
>>
>>
>>
>>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Newbie question] Confused (with correction)
Posted by Robert <rm...@bull-enterprises.com>.
I wouldn't mind helping out here if I can(?). If I had the right info to
add and the format, I would be happy to help with the docs/website
unless someone else has already volunteered with that. Maybe I can bring
that use perspective on it...
Just a thought
- Robert
-----Original Message-----
From: Stephen McConnell [mailto:mcconnell@osm.net]
Sent: Wednesday, May 15, 2002 12:39 PM
To: Avalon Developers List
Subject: Re: [Newbie question] Confused (with correction)
Robert wrote:
>I must say Stephen, this is the best description and comparison I've
>ever seen on the various projects/apps. This should go on the website!
>
I've been reading over the intro package for the Avalon website and
something struck me ... it doesn't actually say right up front what
Avalon is/does. When I wrote the info you referenced - I had Leo in
mind as a potential 'target' and an underlying 'agenda' to instigate
some more direct messages on the web-site. However - this is also a
terrible time for me to try to do anything too serious - just way - way
- way to busy on admin/business/finance stuff. In an ideal world I
would like to kick around a bunch of things concerning the web-site but
it really difficult just at the moment - about all I can offer is
critique - and I'm not happy about doing that without a corresponding
contribution of something useful. If someone has cycles available I can
push out issues we need to deal with - I can provide good pointers to
what needs to chage (positives instead of negatives / make the techo
stuff move to background / focus on the value proposition / define the
targets / define the products / define the services / clarify the Avalon
brand / enforce the brand / etc ).
Cheers, Steve.
>
>- Robert
>
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@osm.net]
>Sent: Tuesday, May 14, 2002 7:02 PM
>To: Avalon Developers List
>Subject: Re: [Newbie question] Confused (with correction)
>
>
>Fredrik Hultin wrote:
>
> >Hi,
> >I have tried to figure how the different efforts under the Avalon
> >umbrella are intended. But I am still not clear on why Phoenix
doesn't
> >use Excalibur's component manager or where Fortress fits into the
> >picture.
> >
>
>Taking a step back for a moment - here is a short description of the
>five main areas within Avalon:
>
>1. The Avalon framework - basically a set of building blocks for the
>construction of component based solutions. Within the framework you
have
>a set well-developed concepts that share a central notion of an object
>lifecycle within the context of a development approached referred to as
>Inversion of Control (IOC). Following IOC patters results in separation
>the managing container from the component. In practice, the container
is
>an implementation issue - but the components, their lifecycle and the
>contracts they support are formally declared. That's why we see the
>component details in framework and no formal definition of a container.
>
>2. Excalibur is a collection of all sorts of things that leverage the
>notions of IOC. Many of the packages in Excalibur use the framework as
a
>construction toolkit. I tend to dip into Excalibur from time to time -
>support for internationalization - some where to put framework
>extensions - ideas concerning component management and containers, etc.
>There are at least three different contains within Excalibur - the
>original ECM (which reflects early work relative to the framework
>abstractions) - Fortress (from my observation is something like
>"son-of-Excalibur" - still evolving, but I believe a step forward in
>thinking about formalizing utilities supporting creation od
containers).
>
>There is Merlin which is a container that is more like a stripped-down
>Phoenix with tweaks and go-fast additions like support for
>ServiceManager, Serviceable, ServiceSelector.
>
>3. Phoenix - this is a real serious container - basically a container
>for running applications (as compared to Merlin, which is much more a
>container for running components). Phoenix provides a lot more
>functionality in respect to deployment flexibility - targeted towards
>the deployment manager (as opposed to Merlin's focus towards a
>developer).
>
>4. LogKit - a logging implementation that respects IOC patterns
>
>5. Applications - a bunch of very different application projects that
>are capable of execution as packaged applications within the context of
>the Phoenix platform
>
> >
> >Is the component manager deprecated and has Fortress taken over? Why
> >then doesn't Phoenix use Fortress?
> >
>
>Keep in mind that ComponentManager and Fortess are really two different
>things. ComponentManager is simply a utility used in one of several
>phases in the management of component. It is not a manager of a
>component - instead it is a utility through which a component can
access
>the components it is dependent on. Recently the Avlon framework has
been
>updated in include ServiceManager as a replacement with the intention
of
>deprecating ComponentManager in the next release. ServiceManager and
>ComponentManager are identical except that ServiceManager removes the
>restriction of the Component marker interface (and therefore enables a
>much broader scope of applications that can leverage the Avalon
>framework and component model).
>
>Fortress on the other-hand reflects a lot of the discussions that were
>going on at the time of the introduction of ServiceManager and is
>addressing the notion of a container. I would not class Fortess as
>signed, sealed and delivered - but it is interesting content. Keep in
>mind the point I mentioned above - containers are an implementation
>concern - the components are an interface and formal semantics concern
-
>so don't worry too much about which container is being used where -
>because in an IOC world, components don't need to know about their
>containers. As for Phoenix/Fortress - in my mind these are two
different
>container approaches that are addressing two different scales of
>component management. In addition, Phoenix is strong, reliable, and
>validated - Fortress is still in hanger.
>
> >
> >What is the intent for the future? What projects will survive and
>which
> >will die in the near future?
> >
>
>We are seeing subtle and progressive elimination of marker interfaces -
>for example, the replacement of Composable/ComponentManager with the
>Serviceable/ServiceManager. This trend is also going on at the Phoenix
>level where with luck we should soon be free of the Block marker
>interface. In parallel, withdrawal of marker interfaces introduces
>stronger dependencies on meta-information and I except we will see
>development in that erea both in terms of tools supporting automatic
>meta-info generation, and a convergence of approaches to component
>related meta-management as various containers expose and validate best
>practices in this area. In terms of what will die - I would recommend
to
>avoid using the ComponentManager, and instead focus on tools and
>utilities that leverage ServiceManager (but that statement is bound to
>be controversial because lots of people are using ECM which has strong
>Component/ComponentManager ties and ECM has not been upgraded to
support
>the Serviceable/ServiceManger). Over on the Jakarta Avalon Apps group,
>the Database, FTP server, HSQL, HTTP proxy, Overlord, Xcommand and the
>Enterprise suite (ORB, Interoperable Naming Service, Persistent State
>Service, Time Service ) are all component based applications with
>suppport for Serviceable/ServiceManager semantics. Also, Phoenix offers
>full support for the new Servicable/ServiceManager.
>
>In addition to above, ECM has to deal with legacy issues concerning the
>usage of the LogKit interface (as distinct from the abstract framework
>Logger package) - which appears to be restricting its development to
>some degree. My guess is that as Fortress matures will see more dialog
>on this area - and in particular, discussion of ECM management and
>evolution with respect to Fortress and the evolution of the framework.
>
>Bottom line - the container isn't the issue - the critical aspects are
>down in the framework. When emerges from Excalibur in the container
area
>are just different approaches to similar problems they tend to reflect
>different priorities. And finally, rolling your own container is also
>totally valid - in fact in our internal applications we have several
>"custom" containers that deal with families of components - and cases
>where you just want to do something simply and directly. At the end of
>the day our applications leverage custom containers (typically at a low
>level), Merlin at the component level and Phoenix at the application
>level.
>
>Cheers, Steve.
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Newbie question] Confused (with correction)
Posted by Stephen McConnell <mc...@osm.net>.
Robert wrote:
>I must say Stephen, this is the best description and comparison I've
>ever seen on the various projects/apps. This should go on the website!
>
I've been reading over the intro package for the Avalon website and
something struck me ... it doesn't actually say right up front what
Avalon is/does. When I wrote the info you referenced - I had Leo in
mind as a potential 'target' and an underlying 'agenda' to instigate
some more direct messages on the web-site. However - this is also a
terrible time for me to try to do anything too serious - just way - way
- way to busy on admin/business/finance stuff. In an ideal world I
would like to kick around a bunch of things concerning the web-site but
it really difficult just at the moment - about all I can offer is
critique - and I'm not happy about doing that without a corresponding
contribution of something useful. If someone has cycles available I can
push out issues we need to deal with - I can provide good pointers to
what needs to chage (positives instead of negatives / make the techo
stuff move to background / focus on the value proposition / define the
targets / define the products / define the services / clarify the Avalon
brand / enforce the brand / etc ).
Cheers, Steve.
>
>- Robert
>
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@osm.net]
>Sent: Tuesday, May 14, 2002 7:02 PM
>To: Avalon Developers List
>Subject: Re: [Newbie question] Confused (with correction)
>
>
>Fredrik Hultin wrote:
>
> >Hi,
> >I have tried to figure how the different efforts under the Avalon
> >umbrella are intended. But I am still not clear on why Phoenix doesn't
> >use Excalibur's component manager or where Fortress fits into the
> >picture.
> >
>
>Taking a step back for a moment - here is a short description of the
>five main areas within Avalon:
>
>1. The Avalon framework - basically a set of building blocks for the
>construction of component based solutions. Within the framework you have
>a set well-developed concepts that share a central notion of an object
>lifecycle within the context of a development approached referred to as
>Inversion of Control (IOC). Following IOC patters results in separation
>the managing container from the component. In practice, the container is
>an implementation issue - but the components, their lifecycle and the
>contracts they support are formally declared. That's why we see the
>component details in framework and no formal definition of a container.
>
>2. Excalibur is a collection of all sorts of things that leverage the
>notions of IOC. Many of the packages in Excalibur use the framework as a
>construction toolkit. I tend to dip into Excalibur from time to time -
>support for internationalization - some where to put framework
>extensions - ideas concerning component management and containers, etc.
>There are at least three different contains within Excalibur - the
>original ECM (which reflects early work relative to the framework
>abstractions) - Fortress (from my observation is something like
>"son-of-Excalibur" - still evolving, but I believe a step forward in
>thinking about formalizing utilities supporting creation od containers).
>
>There is Merlin which is a container that is more like a stripped-down
>Phoenix with tweaks and go-fast additions like support for
>ServiceManager, Serviceable, ServiceSelector.
>
>3. Phoenix - this is a real serious container - basically a container
>for running applications (as compared to Merlin, which is much more a
>container for running components). Phoenix provides a lot more
>functionality in respect to deployment flexibility - targeted towards
>the deployment manager (as opposed to Merlin's focus towards a
>developer).
>
>4. LogKit - a logging implementation that respects IOC patterns
>
>5. Applications - a bunch of very different application projects that
>are capable of execution as packaged applications within the context of
>the Phoenix platform
>
> >
> >Is the component manager deprecated and has Fortress taken over? Why
> >then doesn't Phoenix use Fortress?
> >
>
>Keep in mind that ComponentManager and Fortess are really two different
>things. ComponentManager is simply a utility used in one of several
>phases in the management of component. It is not a manager of a
>component - instead it is a utility through which a component can access
>the components it is dependent on. Recently the Avlon framework has been
>updated in include ServiceManager as a replacement with the intention of
>deprecating ComponentManager in the next release. ServiceManager and
>ComponentManager are identical except that ServiceManager removes the
>restriction of the Component marker interface (and therefore enables a
>much broader scope of applications that can leverage the Avalon
>framework and component model).
>
>Fortress on the other-hand reflects a lot of the discussions that were
>going on at the time of the introduction of ServiceManager and is
>addressing the notion of a container. I would not class Fortess as
>signed, sealed and delivered - but it is interesting content. Keep in
>mind the point I mentioned above - containers are an implementation
>concern - the components are an interface and formal semantics concern -
>so don't worry too much about which container is being used where -
>because in an IOC world, components don't need to know about their
>containers. As for Phoenix/Fortress - in my mind these are two different
>container approaches that are addressing two different scales of
>component management. In addition, Phoenix is strong, reliable, and
>validated - Fortress is still in hanger.
>
> >
> >What is the intent for the future? What projects will survive and
>which
> >will die in the near future?
> >
>
>We are seeing subtle and progressive elimination of marker interfaces -
>for example, the replacement of Composable/ComponentManager with the
>Serviceable/ServiceManager. This trend is also going on at the Phoenix
>level where with luck we should soon be free of the Block marker
>interface. In parallel, withdrawal of marker interfaces introduces
>stronger dependencies on meta-information and I except we will see
>development in that erea both in terms of tools supporting automatic
>meta-info generation, and a convergence of approaches to component
>related meta-management as various containers expose and validate best
>practices in this area. In terms of what will die - I would recommend to
>avoid using the ComponentManager, and instead focus on tools and
>utilities that leverage ServiceManager (but that statement is bound to
>be controversial because lots of people are using ECM which has strong
>Component/ComponentManager ties and ECM has not been upgraded to support
>the Serviceable/ServiceManger). Over on the Jakarta Avalon Apps group,
>the Database, FTP server, HSQL, HTTP proxy, Overlord, Xcommand and the
>Enterprise suite (ORB, Interoperable Naming Service, Persistent State
>Service, Time Service ) are all component based applications with
>suppport for Serviceable/ServiceManager semantics. Also, Phoenix offers
>full support for the new Servicable/ServiceManager.
>
>In addition to above, ECM has to deal with legacy issues concerning the
>usage of the LogKit interface (as distinct from the abstract framework
>Logger package) - which appears to be restricting its development to
>some degree. My guess is that as Fortress matures will see more dialog
>on this area - and in particular, discussion of ECM management and
>evolution with respect to Fortress and the evolution of the framework.
>
>Bottom line - the container isn't the issue - the critical aspects are
>down in the framework. When emerges from Excalibur in the container area
>are just different approaches to similar problems they tend to reflect
>different priorities. And finally, rolling your own container is also
>totally valid - in fact in our internal applications we have several
>"custom" containers that deal with families of components - and cases
>where you just want to do something simply and directly. At the end of
>the day our applications leverage custom containers (typically at a low
>level), Merlin at the component level and Phoenix at the application
>level.
>
>Cheers, Steve.
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Newbie question] Confused (with correction)
Posted by Robert <rm...@bull-enterprises.com>.
I must say Stephen, this is the best description and comparison I've
ever seen on the various projects/apps. This should go on the website!
- Robert
-----Original Message-----
From: Stephen McConnell [mailto:mcconnell@osm.net]
Sent: Tuesday, May 14, 2002 7:02 PM
To: Avalon Developers List
Subject: Re: [Newbie question] Confused (with correction)
Fredrik Hultin wrote:
>Hi,
>I have tried to figure how the different efforts under the Avalon
>umbrella are intended. But I am still not clear on why Phoenix doesn't
>use Excalibur's component manager or where Fortress fits into the
>picture.
>
Taking a step back for a moment - here is a short description of the
five main areas within Avalon:
1. The Avalon framework - basically a set of building blocks for the
construction of component based solutions. Within the framework you have
a set well-developed concepts that share a central notion of an object
lifecycle within the context of a development approached referred to as
Inversion of Control (IOC). Following IOC patters results in separation
the managing container from the component. In practice, the container is
an implementation issue - but the components, their lifecycle and the
contracts they support are formally declared. That's why we see the
component details in framework and no formal definition of a container.
2. Excalibur is a collection of all sorts of things that leverage the
notions of IOC. Many of the packages in Excalibur use the framework as a
construction toolkit. I tend to dip into Excalibur from time to time -
support for internationalization - some where to put framework
extensions - ideas concerning component management and containers, etc.
There are at least three different contains within Excalibur - the
original ECM (which reflects early work relative to the framework
abstractions) - Fortress (from my observation is something like
"son-of-Excalibur" - still evolving, but I believe a step forward in
thinking about formalizing utilities supporting creation od containers).
There is Merlin which is a container that is more like a stripped-down
Phoenix with tweaks and go-fast additions like support for
ServiceManager, Serviceable, ServiceSelector.
3. Phoenix - this is a real serious container - basically a container
for running applications (as compared to Merlin, which is much more a
container for running components). Phoenix provides a lot more
functionality in respect to deployment flexibility - targeted towards
the deployment manager (as opposed to Merlin's focus towards a
developer).
4. LogKit - a logging implementation that respects IOC patterns
5. Applications - a bunch of very different application projects that
are capable of execution as packaged applications within the context of
the Phoenix platform
>
>Is the component manager deprecated and has Fortress taken over? Why
>then doesn't Phoenix use Fortress?
>
Keep in mind that ComponentManager and Fortess are really two different
things. ComponentManager is simply a utility used in one of several
phases in the management of component. It is not a manager of a
component - instead it is a utility through which a component can access
the components it is dependent on. Recently the Avlon framework has been
updated in include ServiceManager as a replacement with the intention of
deprecating ComponentManager in the next release. ServiceManager and
ComponentManager are identical except that ServiceManager removes the
restriction of the Component marker interface (and therefore enables a
much broader scope of applications that can leverage the Avalon
framework and component model).
Fortress on the other-hand reflects a lot of the discussions that were
going on at the time of the introduction of ServiceManager and is
addressing the notion of a container. I would not class Fortess as
signed, sealed and delivered - but it is interesting content. Keep in
mind the point I mentioned above - containers are an implementation
concern - the components are an interface and formal semantics concern -
so don't worry too much about which container is being used where -
because in an IOC world, components don't need to know about their
containers. As for Phoenix/Fortress - in my mind these are two different
container approaches that are addressing two different scales of
component management. In addition, Phoenix is strong, reliable, and
validated - Fortress is still in hanger.
>
>What is the intent for the future? What projects will survive and
which
>will die in the near future?
>
We are seeing subtle and progressive elimination of marker interfaces -
for example, the replacement of Composable/ComponentManager with the
Serviceable/ServiceManager. This trend is also going on at the Phoenix
level where with luck we should soon be free of the Block marker
interface. In parallel, withdrawal of marker interfaces introduces
stronger dependencies on meta-information and I except we will see
development in that erea both in terms of tools supporting automatic
meta-info generation, and a convergence of approaches to component
related meta-management as various containers expose and validate best
practices in this area. In terms of what will die - I would recommend to
avoid using the ComponentManager, and instead focus on tools and
utilities that leverage ServiceManager (but that statement is bound to
be controversial because lots of people are using ECM which has strong
Component/ComponentManager ties and ECM has not been upgraded to support
the Serviceable/ServiceManger). Over on the Jakarta Avalon Apps group,
the Database, FTP server, HSQL, HTTP proxy, Overlord, Xcommand and the
Enterprise suite (ORB, Interoperable Naming Service, Persistent State
Service, Time Service ) are all component based applications with
suppport for Serviceable/ServiceManager semantics. Also, Phoenix offers
full support for the new Servicable/ServiceManager.
In addition to above, ECM has to deal with legacy issues concerning the
usage of the LogKit interface (as distinct from the abstract framework
Logger package) - which appears to be restricting its development to
some degree. My guess is that as Fortress matures will see more dialog
on this area - and in particular, discussion of ECM management and
evolution with respect to Fortress and the evolution of the framework.
Bottom line - the container isn't the issue - the critical aspects are
down in the framework. When emerges from Excalibur in the container area
are just different approaches to similar problems they tend to reflect
different priorities. And finally, rolling your own container is also
totally valid - in fact in our internal applications we have several
"custom" containers that deal with families of components - and cases
where you just want to do something simply and directly. At the end of
the day our applications leverage custom containers (typically at a low
level), Merlin at the component level and Phoenix at the application
level.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>