avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject Merlin's Fortress (was RE: Component Initialization)
Date Tue, 23 Jul 2002 13:26:34 GMT
> From: Stephen McConnell [mailto:mcconnell@osm.net] 
> 
> 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.


> >* 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.

> >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"/>

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.


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message