Rob Evans (robevans) wrote:
Folks,
More newbie questions.
1) How do I deploy and run multiple Merlin components in a single Merlin instance.
For example, I have 3 components that perform some sort of JMS messaging function and 1 component that provides a JMS connection service to the 3 messaging components. I want the 4 components running in a single VM. At the moment all I know how to do is run: merlin -execute some.package.jar
<container name="test">
<classloader>
<classloader stuff -->
</classloader><component name="c-one" type="MyFrirstComponent"/> <component name="c-one" type="MySecondComponent"/> <component name="c-one" type="MyThirdComponent"/>
</container>
And Merlin will take care of the wiring up of these components automatically for you. In fact you don't necessarily need to declare all of your components - bacause if there is a solution that is required and you havn't declared it - Merlin goes hunting for a solution and if if finds something - it wires it in. If finds mutliple solutions if selects the base candiate, if you want to override the candidate selecion - you can.
2) Is there a way to configure Merlin so that it will load components on
the fly?
For example, I'd like to be able to deploy a *new* component into a
running instance of Merlin.
Yes it is possible - but not via configuration directives. You need to get famility with the Block API and composition meta-model. Take a look at the kernel/unit abstract test case for some code that is dynamically establishing a container on-the-fly and accessing this during runtime. My keep in mind that this code will be changing as we impriove the kernel bootstrapping over the comming two weeks.
3) What's the target for having a stable version of Merlin ready for
production usage
I've been using Merlin in production scenarios for over a year.
and what features will be in that release?
Primarily the features over an above today will be:
(a) very clean embedding (b) smart repository management (c) plugable features (i.e. stable core - evolving freatures)
I know it's
hard/impossible for an opensource project to commit to release dates
but I need to have some indication of merlin's production readiness.
This is more of a question of knowing what is changing and what isn't. For example - the dynamic deployment stuff will change - but not significantly - I'm confident that there are enhancements we can make and that we should not be locking down these (container-side) interfaces just yet. Personally - I would suggest you work against a particular endorced stable realease (e.g. 3.0 or hang in there for new release before the end of the year).
We are willing to take a little risk but...
"A problem is a risk who's time has come" - Adrian Cowdrow (quote from sometime in the late 1990s).
If you make an analysis of the problem space the really big issue is the brick wall of complex systems - you scale up and *bang* - you just cannot go further because it all gets too difficult. Having been there on several occasions - the work on Merlin is directly influenced by and addresses this paramount issue. As such, Merlin development to-date is very much about the deliver a platform the breaks through the wall. That "opportunity" is massively more important that transient risks.
However, to understand this properly you need to consider what those transient risks are. Those include (a) functional evolution schedule - i.e. what you can expect within a specific time frame, (b) strategic backup, and (c) future potential.
Following Adrian's philosophy:
(a) functional evolution schedule - low risk - not really an issue - we are seeing a variety of initiatives from different domain areas concerning extension of merlin into web-apps, repository handling, dev-tools, enterprise apps, process management, rules management, etc. - this simply means that there is an evolution process ongoing that is somewhat independent of the core
(b) strategic backup - medium risk - there are a number of individuals that I could name today (excluding myself) who could give you good support on a project if you need it - and independently of that you have a code base that is in code shape to handle independently of external support
(c) future potential - this is largely a question of the direction that Avalon as a community takes - one option is the simple J2EE solution .... but for my money that totally sucks - instead - the direction I'm looking at is the solution above and beyond J2EE - a solid next generation step - but that has its own challenges - today my guess is that is slightly under medium risk - but volatile territory all the same
So back indicators.
The risk of hitting a wall is a risk that my experience is something very expensive (and much moe significant than any of the transient risk outline above). You have team of a 12-50 people all working away and at some point you discover a physical/physiological limit - a system that will not scale - yes you can put effort into it and move the wall a bit - but the effort is very expensive. What you end up doing is either a "take-two" or adapt to the reality relative to the schedule. I.e. its a rare opportunity to be able to take a step back - ask yourself what the real issues are - and discover that the ground you were standing on is not looking as solid as it did a few weeks ago. Problem is that these sort of issues can take 12-18 months to resolve not to mention cooncurrent re-engineering cycles. On the other-side of the coin - this is open source - and that means that when you balance up "doing it right" versus "doing it on time" - "doing it right" wins - because on time is basically the about of time it takes to do it right.
That's the brilliance and epitome of open-source all in one.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/ | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
