Timothy Bennett wrote:
Time to start a new project, which mean technology evaluation time! Oh goody!
:-)
Last project, I quite successfully used Avalon and Phoenix 4.0.4 as the framework for my server application. Very pleased, and it certainly exceeded all my expectations. Actually, as using new technologies go, it was rather painless.
But now the next project looms (no pun intended), and I need to decide if I'm going to continue to use Phoenix/Loom, or if I'm going to use Merlin. I've downloaded the Merlin binaries and went through all the tutorials and read through some of the basics. My hat off to Steve and his crew.
Thanks!
However, I've got this slab of Phoenix components, blocks and applications
that I wrote and assembled for the last project. Of course, I want (and
need) to re-use a number of these entities. One thing I haven't seen in all
the marvelous Merlin documentation is some kind of
Phoenix-migration-porting-reusing-guide type of document.
Earlier this week I was going over exactly the same subject - looking at what migration means and what are the differences in approaches between Merlin and Phoenix. A large part of that discussion focussed on (a) what you don't need to do bacause Merlin will take care of it for you, and (b) what you do need to do if you want to make you solution useful to others.
1. configurations
When you define the configuration for a suite of components, a large part of you configuration information never changes. Take a look at the James mail server configuration as an example:
Phoenix: configuration.xml = 40k
Merlin: config.xml = 2kThe diffference between these two reflects the seperation of user oriented configuration info from system and/or developer contric configuration info. Under the Merlin works, you have several options concerning the packaging of configuation information so that it doesn't get in the way. One mechanisms is the bundling of a static configuration with a component class using a <classname>.xconfig resource. It looks like the following:
From <classname>.xconfig
<configuration>
<!--
any configuration info you conssider to be a workable
static default value
-->
<configuration>Given a defauot configuration, in many cases you deployment confiugration becomes a lot simpler. However, there is still information we want to change when we deploy the component (e.g. file based persistence verus database persistence). This sort of thing can be declared when you describe a deployment scenatio.
From block.xml
<container name="demo">
<component name="example" class="MyLegacyComponent">
<configuration>
<!-- anything extra we want to add or override -->
</configuration>
</component>
</container>
However, there remains configuration info that we don't want to include in a deployment profile. This is stuff like account names, passwords, etc. This infomation is included in the config.xml that is supplied to Melrin on the command line. A config.xml looks like the following:
<targets>
<target path="/demo/example">
<configuration>
<username>fred</username>
<password>secret</password>
</configuration>
</target>
</targets>Merlin also provides a few other handy feature for packaging deployment
profiles, but that's not critical. The important thing here is to think
about the type of infomation your holding in a configuration - and then
ask youself the question .. "is this information something that I should
package with the component, or as part of a deployment solution, or as part
of a usage scenario?".
Once you go through this process, you will typically discover that 50% of
your components can be declared using static defaults. This means that
you don't need to declare them in a deployment descriptor (block.xml)
beacause Merlin will locate then automatically. That lets you concentrate
on those components that need extra attention.
2. assembly
The approach in Phoenix is to declare componets in an assembly.xml file which basically represents the wiring diagram. It tells Phoneix how to wire together components providing services with component consuming services.
In Merlin the assuption is that Merlin will take care of this for you. You simply need to declare what you want to deploy and Merlin will
figure out a deployment plan.
Consider the following:
<container name="demo">
<component name="example" class="MyPhoenixComponent"/>
</container>Merlin will assess the target component in terms of its complete dependencies (deployment and runtime) and build up a end-to-solution that covers all of the component requirements. This may involve the establishment of hundreds of other component in orer to achieve that objective. The primary function of the content included in a block.xml file it to provide guidance to Merlin in the delivery of that objective.
The important point here is that the information you provide to Merlin is the additional information needed to influence Merlin decisions. If your paranoid, you can take total control over the deployment solution - or if your like me, you make Merlin work for a living.
I've got a basic
idea of the merlin container, and how to create new components for the
container, but I don't have a clear idea how to re-use my Phoenix blocks
even though there is much press touting that merlin supports re-use of the
Phoenix-style blocks.
If there is an existing <classname>.xinfo resource generated using the phoenix blockinfo descriptors, then merlin will read it in a create an internal component type representation. You don't need to do anything more than request deployment in a block.xml. In other words - you can take your binary phoneix components and run them without modification inside Merlin. There are a couple of restrictions (BlockContext and BlockListerner).
Any tips, help, suggestions from some of you (by now) Merlin-gurus would be most appreciated.
1. are you using BlockContext and/or BlockListener?
2. can you update to eliminate these dependencies?
3. if not then you need some more info
4. if yes - then throw together a container descriptor, include the resources you need in the classloader classpath, execute it, see what happens, post more questions
As we go ahead I'll try and capture some of the notes in a Phoenix Migration Strategy page.
Stephen.
Timothy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
