Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>Berin Loritsch wrote:
>>
>>
>>>BTW, What is your feeling on lifecycle extension? Is it
>>>
>>>
>>something that
>>
>>
>>>we can propose for ContainerKit
>>>
>>>
>>>
>>I'll have to dig before given you an opinion.
>>
>>
>
>Cool. I would say check out the docs online, but it seems I
>have to add a link for the missing page....
>
>The xdocs do have the latest. I'll see what I can do to get
>the new page published ASAP.
>
>
>
>>>and make it easier for all containers
>>>to support it? Stephen, what is your feeling on it?
>>>
>>>
>>>
>>I would like explore a Merlin/Fortress merger. Merlin content on the
>>Kernel/Container/Meta-Data layers, Fortress content on the handlers,
>>lifecycle extensions and probably more that I'm not up to speed with
>>yet. There's stuff in-between that would need discussion
>>simply to get
>>a better picture of where the boundaries and relationships are.
>>
>>Thoughts ?
>>
>>
>
>I agree. Hmmm. Merlin's Fortress....
>
:-)
>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.
>* Merlin has the better metadata model. Fortress accomplishes the same
> thing from the RoleManager--however it is more limited.
>
>* 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.
>
>
>* 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.
>
>* Fortress has initial experimental support for integration with the
>Excalibur instrumentation packages. I don't know about Merlin.
>
Nothing in Merlin concerning instrumentation - priority is to get the
core kernel/container model as rugged as possible before addressing
extensions. But this is definately an interesting area.
>
>* 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.
>
>Please excuse my ignorance of Merlin.
>
And mine on RoleManager (still havn't figured that one out) :-)
Cheers, Steve.
>>Just for reference, I've updated a lot of the documentation
>>on Merlin so
>>getting a better idea of how Merlin is doing its stuff should
>>be easier.
>>
>>
>>
> http://home.osm.net/doc/merlin
>
>Cheers, Steve.
>
>
>
>>--
>>To unsubscribe, e-mail:
>>
>>
><mailto:[EMAIL PROTECTED]>
>
>
>>For additional commands, e-mail:
>><mailto:[EMAIL PROTECTED]>
>>
>>
>>
>>
>>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
