avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Crafter <craft...@fztig938.bank.dresdner.net>
Subject Merger of Merlin/Fortress - first steps ?
Date Tue, 06 Aug 2002 16:52:48 GMT
Hi All,

	Hope all is well.
	We've been talking a lot recently about the potential merger of
	Fortress and Merlin into one effort to come up with a rock-solid
	replacement for ECM.
	Everyone seems to think this would be a worthwhile goal, so lets
	start to look at the issues involed.
	What would be great, is if we could all brainstorm a little and
	put together a list of the potential issues we (may?) have with
	merging the 2 efforts, so we can then discuss them and work out
	the solutions that will give us a path forwards.
	Here's what I see to be on the list so far, it's probably far from
	complete, but something we can start to work from.
	(BTW - I'm still a Merlin novice, so for the Merlin guru's if I
	make a mistake or mistype something feel free to correct me)
	o use of .xinfo/.xprofile/.xconfig vs role manager/.xconf
	Merlin's use of configuration files differs from the ECM/Fortress
	model. Each component has an associated .xinfo file specifying
	meta information, and a .xconfig file specifying default
	configuration values. A .xprofile file specifies instances of the
	specified component which are available for use (all of this can
	also be specified in Merlin's higher level kernel.xml file too).
	All of this is packaged up in a jar, which Merlin can search
	through automatically at startup for example to locate and expose
	ECM/Fortress uses the RoleManager approach, which allows you to
	specify a shorthand name for a role (as opposed to a particular
	roles complete class name). This shorthand can then be used in the
	.xconf configuration file which specifies config data for all
	components that ECM/Fortress instance is managing. 
	What to do ?
	I think Merlin's approach is really nice. The meta info specified
	in the .xinfo files allows features like service dependencies,
	versioning, etc, to be implemented which role manager can't yet do
	without changes.
	It also implicitly fixes other issues previously brought up on the
	list like the separation of configuration files, default settings, etc.
	The combination of Merlin's .x* files also lets us have the
	ability to take jar's and expose services for clients automatically
	(and perhaps in the future load/reload them dynamically).
	I would advocate the adoption of Merlin's model, with the
	development of a transition tool that could generate the required bits
	for the .roles world, either dynamically or statically at build
	time - or the development of an ECM style compatibility layer for
	Merlin that would allow the use of the .roles/.xconf files. Thoughts ?
	o ComponentSelector
	ECM/Fortress return ComponentSelectors for lookups that end in
	role name + selector. From my current understanding Merlin doesn't
	do this (?). I remember Stephen proposed a solution for this in a
	previous email which is quoted verbatim below:
>>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.

	o Fortress style ComponentHandlers
	Fortress allows the developer to specify the usage of a particular
	component, ie. whether it should be pooled, reused in all threads,
	or created and destroyed per lookup/release.
	Merlin currently assumes thread safe singleton components only.
	Stephen told me offline that this one is on his current TODO list
	- any further info there Stephen ? will it be similar to the
	Fortress approach ? ie. can the developer specify how a particular
	component can be handled ?
	o Lifecycle Extensions
	Implementation of the features discussed in Berin's email:

	o Merlin logging management
	Stephen mentioned to me that Merlin's logging management is
	different than both Phoenix and ECM/Fortress. He mentioned to me
	the possibility of supporting the ECM style configuration, I guess
	we need to cover this one in a bit more detail.
	And... there are probably others..
	Also to discuss is the process of *how* we should merge the efforts
	together. Ideas ?
	Ok, well hopefully thats a start. Feel free to add any thoughts/issues
	or comments to the above list, and we can work out solutions for them
	all. Hopefully that will give us a path forward, combined our
	'how' plan, to create our kick ass ECM successor. :)
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&

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

View raw message