Marco Tedone wrote:
Basically what makes sense is one set of docs the describe the usage of the template. This should be seperate from the template itself. The usage docs would then go through the steps - download, customize, populate, build, etc.
If you don't mind I would write a documentation for the following:
1) Download and install the template 2) Create a copy of the template (The HelloWorld example) 3) Set up the HelloWorld example 4) Create an HelloWorld client that uses the HelloWorld service
I succesfully created a component which uses the HelloWorld Service now. However, I've got some questions:
1) Would it be possible to using a naming service to register services/components? If so, it would be nice to have a feature like the following: when registering a service, all the components would be registered automatically.
One needs to seperate thinking in terms of component from thinking in terms of container. Following IOC patterns if a component wants a registry of services then it declares that it needs a registry service. The container is reponsible for making sure that the needs of the component are fulfilled. If we look at the same problem from the point of view of the container - it clearly needs a registry of services - and in fact deep inside the merlin internals you find lots of registries (service registries, type registries, appliance registies, etc.). But the important thing is that a component (or component developer) does not need to know how merlin achives the establishment of services. In fact - it rather important that they don't because merlin will continually evolve to handle new mechanisms for service discovery and delivery.
It's worthwhile thinking of merlin (as it is today) as a client application within a distributed network. Imagine a merlin-backoffice - a system located remotely that does much more than repositories like ibiblio - instead, think of merlin-backoffice as an intelligent service brokerage engine serving thousands of merlin client kernels based on in incoming service requests and delivering based on quality, proximity, availability and security criteria.
2) I executed maven merlin:simulate under /impl and all the components have been executed. I'm sure this is not the only way components can be ran in Merlin, otherwise it would be too limitative. Users may want just to run a component rather that all of them (sequencially?). How could this feature be enabled?
The merlin:simulate and merlin:deploy goals are simply facilities than enable validation at different stages in a development lifecycle. The merlin:simulate goal can be applied after a compile and lets you confirm that the components are deployable relative to the content in the target/classes directory. The merlin:deploy goal lets you validate that a jar file with an embedded block descriptor is actually executable. Normal deployment is undertaken in either the cli handler or in a dedicated embeddor (e.g. web app, enterprise app, or whatever). All of these example can be manipulated as if your were running from the merlin command line - i.e. through diligent use of merlin.properties you achieve lots of stuff. And if that's not sufficient - you can take the next jump and crete your own embeddor in which case you get access to everything.
3) I can guess that when executed, Merlin registers services somewhere and make them available to other components. Doesn't this seem very similar to a distributed application? If so, how much would it cost in term of time and resources to make the Merlin kernel a RMI application?
Next to nothing (in fact its already available via an extension). But that's not the prime issue. Like Niclas said - its about management
of service availability.
4) It would be nice to have Merlin running (even if without services) and
listening for deployments. In few words it would be nice to have some hot
deployment services (like JBoss and Tomcat) and having Merlin as a
container.
What you describing has a number of prerequisites. Firstly, hot service deployment implies that the meta model the is used to manage the defintion of classloaders becomes an active istance. This requires full support for willcard patterns in the classloader meta data, active directory and remote repository monitoring in the metamodel, event propergation to the deployment system, reactive redeployment in the activation system, etc.
I.e. doing it right is non-trivial.
I'm sure there is a way to run Merlin without services, just for the pleasure to see the container running, but I don't know how. What I would avoid, is to be constrained to run several instances of Merlin for different applications. It would be nice to have one instance that deploys all the services.
As things stand if there are no blocks to deploy merlin will terminate. This is simply because the root block is not running under a dedicated thread. That would be realtively easy to change. However, the objective also implies that you have a management interface (web, command-line, whatever) through which you can add and remove content at will. You can think of this sort of functionality as a facility that can be plugged into merlin. The ability to plug in different container side sub-systems, listeners, and extensions of different sorts. But before completing the facility management there are still a couple of steps remaining concerning the block and appliance implementation (in particual a deployment listener).
Cheers, Stephen.
Marco
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
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]
