> 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. > >* 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
