Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>Berin Loritsch wrote:
>>
>>
>>
>>>Here is my understanding of the differences (I am sure there
>>>
>>>
>>is more):
>>
>>
>>>* Fortress uses MPool and Event so that we have asyncronous
>>>
>>>
>>management.
>>
>>
>>> Critical path is not bogged down with management functions, and
>>> pooling does not require the Pool interface.
>>>
>>>
>>>
>>This needs more discussion because I don't have a totally
>>clear picture yet of the assumptions your making about asyn
>>management. If you mean that in async mode your spinning of a
>>thread to handle the lifecycle processing - then in Merlin this
>>can be very easily suppported under merlin.model.ResourceDesignator
>>- in fact I don't see a requirement for non-asyn becuase Merlin
>>has already assigned a source resource and the target resource does
>>not need to be concerned about the source lifestyle and lifecycle
>>state. That's because the actual component is hidden behind an
>>interface which holds the component instantiation criteria and
>>service instantiation/management mechaism.
>>
>>
>
>
>Asyncronous management means that component instance management,
>initialization, and pool size management are all done by a finite
>number of background threads. In the event of integrating dynamic
>reloading of component JARs or configurations, those functions would
>also be executed within the thread pool.
>
>This approach effectively removes container overhead from the critical
>path as much as possible. The affect is quite noticeable. The
>micro-benchmark that compares ECM (all synchronous model) and Fortress
>has Fortress processing requests for components an average of 15 times
>faster than ECM. I don't have a comparison agains Merlin, although
>that would prove an interesting thing as well.
>
>
There is conceptual difference here about the role of the container in
Merlin and Fortress (I think). In Merlin the container handles the
assembly of the components resulting in the establishment of a set of
ResourceDesignator instances. ResourceDesignators are supplied to a
Component/ServiceManager in map, keyed by role name. When a client
invokes lookup the manager implementation invokes getInstance() on the
ResourceDesignator - in the case of threadsafe component - if the
instance has not been established, it uses a lifecycle helper, provider
and meta-data reference to build the instance (including the supply of a
compoent/service manager packaged with dependent ResorurceDesignators).
In effect, the container has nothing to do after initialization except
handle the components that have a activation-on-startup policy, and any
shutdown/disposal requests from its kernel. This appears to be
different in Fortress because the Fortress container plays an active
runtime role (by runtime I mean post start). My current thinking is
that the dynamic aspects of the Fortress Container should be positioned
within an ResoruceDesignator implemetation. If you take a look at the
source merlin.container.ProfileDesignator you will see that it basically
doesn't do much more than delegate requests of to the lifecycle helper -
the lifecycle helper then uses merlin.container.DefaultProvider to
resolve context, depedecies and so forth, using the meta-data model as
execution context. My feeling is that we can handle different "semantic"
appraches through variations on ResourceDesignator implementations.
>
>
>
>>>* Fortress provides a more direct conversion from ECM world due to
>>> the integration of the Component/Service Selector interface.
>>> Fortress takes advantage of the posted "best practices" which you
>>> don't agree with ;P and any role that ends with "Selector" gets
>>> the ***Selector returned. The migration path is so that
>>> components that do not expect a ****Selector path can still
>>> coexist by using the default implementation.
>>>
>>>
>>>
>>This is the area I see as the "main topic" on merging - and
>>its also the source of handreds of emails. Merlin is good a "systems
>>assembly" - and it does this using those <sclasname>..xinfo files.
>>From this information it builds up a graph that associates the
>>type/profile combinations between supply and consumption compoenents.
>>Before the start method is invoked, everyting in Merlin is ready -
>>you can request any service (started or not) and you will get back a
>>properly prepared service. However, you will never get back a
>>selector (selection is done at assembly time). In the Fortress case
>>this is hadled at runtime (i.e a combination of late service binding
>>and referral of selection to the client). How to merge these two
>>approaches? My opinion is that they are seperate concerns - imagine
>>the existence of a ServiceManager along side a ServiceLocator -
>>ServiceManager providing the assembly time services to the component
>>and ServiceLocator supplying the resolution of dynamic lookups.
>>
>>
>
>
>My thoughts on designing Fortress from the outset were to remove the
>necessity of the ***Selector. The problem is that components that
>use the Selector require all systems that use the component type to
>put it in a selector--even if there is only one configuration of it.
>Also, components that expect direct access to the component can't
>get it if a ***Selector exists. To solve those two problems, I
>introduced the concept of the _default_, and made the Selector a
>runtime choice. That way we can mix and match components that expect
>different component layouts without too many issues.
>
>I am sure there is a better way of doing this, but I want to provide
>a migration path for people who *used* to use ECM, and really make it
>the best alternative for Cocoon.
>
>
>
>
>>>* Fortress has the Handler classes and support for four different
>>> handler types--although I would like to see the pure factory
>>> (i.e. no reuse) handler to be deprecated and serious warnings to
>>> be posted if it is used.
>>> Any component that requires its use is poorly designed.
>>>
>>>
>>>
>>I think these handlers can be integrated behing the
>>ResourceDesignator interface. ResourceDesignator is like a service
>>proxy - the client uses a getInstance method to access a service
>>instance and an implemetation of ResourceDesignator has everything it
>>needs to instantiate the service. I.e. it encapsulates the lifestyle
>>and lifecyle mechanisms.
>>
>>
>
>I have a duopoly:
>
>ComponentFactory -- Handles Lifecycle of components
>ComponentHandler -- Handles Lifestyle of components
>
>If your ResourceDesignator combines the two, then we have to
>take a good look at what provides the best way to manage the
>components. I essentially took this design concept from ECM,
>but refined it a little.
>
>
>
>
>>>* Fortress has the initial experimental support for extendable
>>>lifecycles.
>>> It should be easy to integrate with Merlin, et. al.
>>>
>>>
>>>
>>The main issue here is the integration of the lifecycle extension
>>requirements into the meta data model and the imact on the
>>core model.
>>Still thinking here.
>>
>>
>
>The meta model will have to declare the LifecycleExtension handler
>class that it requires. Either that, or we have to make the
>Lifecycle Extensions code list the interfaces that it supports.
>
>I think it would be a mistake to declare in meta-info what we can
>easily determine from the class itself.
>
>
Agreed - I guess this is a question for Markus - can you eliminate the
necessity for the declaration in the code of the extension to an
extension manager? For example, in the Fortress example for the
extensions - there is a container that is explicity declaring the
extension to the manager. It would be designable for a lifecycle
handler to figure this out for itself based on interfaces implemented by
looking at the component class? If so, do you see any problems
integrating extension support into the merlin.container.LifecycleHelper
class?
>
>
>>>Please excuse my ignorance of Merlin.
>>>
>>>
>>>
>>And mine on RoleManager (still havn't figured that one out) :-)
>>
>>
>
>Ok. I will do my best to describe how it functions. Both
>Fortress and ECM have a base markup to describe components. The
>main difference between them is Fortress's addition of the
>"handler" attribute so that we determine from the configuration
>what ComponentHandler we use. The configuration for components
>looks like this:
>
><component role="org.apache.excalibur.datasource.DataSourceComponent"
> class="org.apache.excalibur.datasource.JdbcDataSource"
>
>handler="org.apache.excalibur.fortress.handler.ThreadsafeComponentHandle
>r"
> logger="datasource.jdbc"/>
>
I've been thinking off-and-on about the hadler declaration and the
handler types in Fortress. They tend to reflect lifestyle concerns but
at the same time they mix functional policy - let me explain - a
component may be pooled and thread-safe - it may be pooled and
non-thread safe. Other aspect such as lazy or immediate activation are
seperate from the issue of thread-safe - I guess I would like to see a
breakout of the different *lifestyle* and the different *deployment*
policies. I've tried to break out a table isolating the notions of
singeton, poolable, per-thead, pre-request, and mapping these against
thread-dafe and non-thread-safe components but I havn't arrived at a
clean seperation. Any thoughts on this ? I guess my hidden agenda here
is to eliminate the requirement for the declaration of the handler class
in preference to the declaration of lifestyle policy(ies).
>
>That's a lot of information for an administrator to have to wade through
>just to change some config value. Worse, if they screw with the "role",
>"class", or "handler" attributes the component won't work.
>
>With the absence of a formal component model, I provided a RoleManager
>to handle the hints that the container needs to fill in the blanks--and
>provide a nicer name that we can use in the configuration. We use a
>"shorthand" name to describe how we know what we are dealing with when
>we encounter an unexpected element.
>
>Associated with a shorthand name is the role/interface, a default
>implementation class, and the handler associated with the default class.
>That way, we can use the following markup to describe all the
>information recorded above:
>
><datasource logger="datasource.jdbc"/>
>
>If we want to override the "class" and/or "handler" attributes that are
>the defaults, then we still can do that.
>
>The Fortress version of the RoleManager allows us to convert the shorter
>configuration element to the larger one, and back again. I wanted to
>allow for a "self-healing" configuration file. I want to get to the
>point where we can store the configuration data that might change at
>runtime. Something like Axis would be the usecase that I am imagining
>for that. Axis provides a runtime interface to add new web services, and
>store it so that it is run the next time.
>
>However, we should consider RoleManager something that will go away
>in favor of a proper meta-info model. We just have to make the
>meta-info really easy to maintain.
>
Ok - this now makes sence - basically RoleManager is maintaining
meta-data in the form of easily assecible infromation in the form of
configuration framgments and enabling these fragments to be passed
around as needed. Merlin's apprach is to eliminate the configuration
but sucking in the the configuration once, and building a formal model
accessible using the merlin.model API.
On the subject of maintainability - the Merlin stuff is really easy to
use - PROVIDING - the meta-info is documentated in an .xinfo. It gets
even easier if you use .xprofile which is a static defintion of a set of
instantiation profiles. I would be really interested to get a better
picture of the service model used by Cocoon assuming formal dependecies
were declared in advance - which will really help in sorting out the
real needs for dynamic service lookup.
Cheers, Steve.
--
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]>
