Experiment DeploymentService in 3.2.7RC1

[dimitris]

It basically allows you to generate deployment descriptors
(using velocity templates) and move them in and out of ./deploy.

Read more at:
http://www.jboss.org/wiki/Wiki.jsp?page=DeploymentService

Comments/suggestions are welcome

[dimitris]

I've documented in detail how you can extend the DeploymentService with new velocity templates:

http://www.jboss.org/wiki/Wiki.jsp?page=WritingDeploymentTemplates

The service dependencies are velocity.jar & commons-collections.jar which are included with the deployment-service.sar archive.

Comments and suggestions are welcome

[starksm64]

Ok, I have gone through the example and wiki docs and this looks interesting. My immeadiate thought is that we should look at how this can be used as the basis for a jboss installation tool which would allow one to take a raw templatized jboss installation and browse the available services to select which services to install as well as configure those services.

In that regard some features to be addressed given that an initial implementation would simply allow selection of services are:

Categories of services, grouping of services into functional groups for easier selection of services. For example, ejb, jms, web, webservices, clustering, jndi, jca, etc. Selection of the group should be possible.
There needs to be a notion of which jars are needed for a service. Instead of having to duplicate the jars for each service template, there should be a notion of library sets that could be referenced by the template. Jars in a library set would go into the server lib directory while jars local to the template would go into either the service sar
There needs to be a notion of functional dependencies such that selecting the group of jms services automatically selected, jndi, jca and a datasource if the default pm is the jdbc based one, jaas security config, etc.
A historic problem with the direct use of service jmx names as the mechanism for specifying dependencies makes dependency specification too fragile. We need a service alias notion that allows one to depend on the 'DefaultDS', 'WebContainer', without needing to know what the exact object name of the service is for example.

One complication that exists today is some service attribute values depend on the type of another service. For example, we have services like the jms jdbc based pm, and the ejb timer pm, that have attributes for DDL that depend on the type of datasource. This should be addressed by the generic persistence api, but the situation can arise for other attributes. For example, the webservice layer and http based invokers may depend on the web container virtual host, port, and ssl settings. The template macro layer needs integration with dependent service attributes via references like ${WebContainer}.port to configure such dependency based attributes.

[dimitris]

What always confuses me when discussing configuration/deployment issues, is that JBoss is so flexible that can be configured in many different ways:

You can have a single server with multiple configurations, many servers that form one or more clusters, netboot, etc.

I believe we need to establish a baseline proposed configuration to start discussing ideas over this. In particular, if there is going to be a higher-order management server, or management functions are spread across the cluster, or the management service itself is somekind of ha-singleton, and whether netboot should be put in the picture.

Otherwise, it is hard to imagine how a configuration will be produced and distributed.

I'll try to come up with more concrete examples.

[ccrouch]

Thinking about the DeploymentService and reviewing the documentation has lead me to the following conclusions:

1) The DeploymentService is a "good" fit for creating new, durable, services in JBoss.
2) The DeploymentService is an "ok" fit for updating services already created through the DeploymentService
3) The DeploymentService may not be a good fit for updating services not created through the DeploymentService, e.g. existing handcrafted -service.xml files

Reasons for these conclusion:

1) See http://www.jboss.org/wiki/Wiki.jsp?page=DeploymentService for a description of how the DeploymentService offers a flexible approach to building deployment modules: .sar's, .war's, -service.xml etc.

2) If I understand correctly the process of updating a module with the DeploymentService involves making the following calls:
a) undeployModuleAsynch(), passing in the module name to be updated
b) removeModule(), passing in the module name to be updated
b) createModule(), passing in the module name to be updated, template name and properties
c) deployModuleAsynch(), passing in the module name to be updated

Essentially an update via the DeploymentService is really a delete followed by a create. The corollary of this is that to update one property in a module all the others need to be provided as well. This is often not very difficult since most properties of modules are available through JMX, but sometimes, e.g. finding which driver is being used by a datasource, is more difficult. One option to alleviate this, which Dimitris has suggested, is to extend the DeploymentService by giving it a "memory" of the things which have been deployed through it.

3) To show why the DeploymentService may not always be a good fit for updating services it has not created let me give an example.
The "default" JBoss configuration contains a file "deploy/hsqldb-ds.xml". This contains two things: the definition of the DefaultDS datasource and an MBean for the actual hsqldb instance. If I write a DeploymentService template for creating generic -ds.xml's it will not contain any knowledge of this special hsqldb MBean. If I then used it to update DefaultDS my updated hsqldb-ds.xml would not include the MBean for the hsqldb instance and by leaving out that MBean the module would no longer work as expected.
This is an example of larger issue: given the fact that jboss-ds_1_0.dtd and jboss-ds_1_5.dtd allow arbitrary mbeans in a -ds.xml, we will never know precisely what a user will have put in their -ds.xml. Therefore the DeploymentService approach of updating (delete then create) may result in the loss of elements which it doesn't know about. This is obviously not an issue for modules the DeploymentService created since it knows the whole definition of what can exist in one of those modules.

The above should be taken as my observations and is not meant as a critique of the DeploymentService since it was never designed to support option 3 above. I have just been investigating how far the DeploymentSerice will stretch.

Thanks