Howdy, I have been thinking about this for a while (actually I have been
think about something like this for years, but never really had the resource
to be anything together).
I am thinking that it would be incredibly cool (and usable) to package up
services into deployable jar files (perhaps .sar or something). These files
would have a descriptor that could tell which service classes are available
and provide some extra metadata, like the name of the configuration they
should use.
On the server side, there is a Service Deployer (and probably a
Service Manager, though that might be the JMX Agent) as well as a Service
Configuration Manager.
The service deployer and service manager would be collectively responsible
for "discovering" services to install. Once the service classes have been
loader (probably in there one class loader, perhaps with some extra loaders
for dependency libraries too), the manager will ask the configuration service
for the services configuration.
Services would be JMX MBeans. They could be wrapped in dynamic mbeans, so
services do not have to worry about the JMX bits. Blah, blah, blah.
Services could received events if there configuration changes (ala the
configuration service), and optional reload if they can.
* * *
I could go on drooling over this in more detail, but how about some
explanation for why I think this would be a positive move for JBoss.
First it would make it trivial to integrate thirdparty components, such as
Tomcat or Jetty. Users would install the base JBoss server, then download
the optional services which they desire, then simply tell the configuration
service about the new component and drop a file into the deployment directory.
All of the above components (deployer, manager & config) would be pluggable
themselves for maximum extensively. I would imaging that the first
configuration service would work off of files (probably a standard .xml file
for defining properties and such for a service (or services) and a method to
include other urls (such as jetty.xml or log4j.xml).
So in the simplest configuration a user could drop a file into the conf
directory (say log4j.xml) and a file into the deploy directory (say
log4j.sar). The deployer would be watching for file, find a new file, read
the deployment descriptor, tell the manager to install it, the manager would
then ask the config service for the "log4j" configuration, which would
return an InputStream (or perhaps an abstraction of the basic properties and
url access) and ask the service to configure itself.
If the user wanted to change something, they could just edit the log4j.xml
file, which would cause the config service to send an event to the manager
(and it to the service) that its configuration has changed. If the service
could handle a reconfig it would request the latest config from the manager
(and it from the config service).
In this case the manger would be the go between from the service and the
config manager (as well as the deployer and possibility an extra library
manager).
* * *
At this point the JBoss server could be divided up into smaller modules (at
a CVS and deployment level), leaving only the most basic components in the
core server. We could then organize the CVS depot like the NetBeans project,
where each chunk of functionality is packaged up and installed separately.
Everything (except perhaps access to temp, log and data files) would be
referenced by URL's, files could be abstracted to FileSystems (perhaps by
the openapi's from NetBeans... but I am getting ahead of myself.
So the main JBoss configuration file might look something like this:
<?xml version="1.0"?>
<!DOCTYPE ....>
<server>
<!-- define the local file systems that we have access to -->
<filesystems>
<!-- where temp files will go -->
<filesystem name="temp" type="org.jboss...LocalFileSystem"/>
<!-- where log files will go-->
<filesystem name="log" type="org.jboss...LocalFileSystem"/>
<!-- shared files, like jbossmq state and other fluff go here -->
<filesystem name="shared" type="org.jboss...LocalFileSystem"/>
</filesystems>
<!-- define some properties -->
<properties>
<property name="some.property" value="some value"/>
<property name="some.local.file" value="/foo/bar" format="path"/>
</properties>
<!-- setup core services -->
<services>
<deployer type="org.jboss...ServiceDeployerImpl"/>
<manager type="org.jboss...ServiceManagerImpl"/>
<configuration type="org.jboss...FileServiceConfigurationManager"/>
</services>
</server>
* * *
This is overly simplified, but basically shows some of what I am thinking.
The first bits about filesystems could really be the topic for another
email.
A service archive deployement descriptor might look like this:
<?xml version="1.0"?>
<!DOCTYPE ....>
<services>
<service>
<service-name>TransactionManager</service-name>
<service-class>
org.jboss.tm.TransactionManagerImpl
</service-class>
<service-configuration>
default/TransactionManager
</service-configuration>
<!-- more information about dependent services and libraries -->
</service>
<!-- ... more services -->
</services>
* * *
This is what I came up with last night when I could not sleep due to these
really annoying (and very loud birds outside). I apologize if this is a
bit scattered, I have lots of ideas floating around in my head about this one
and it is hard to get them into words.
Any ways, comments on this are appreciated. I am not really sure how
something like this might fit into the schedule, but I am convinced that it
would be a positive move for JBoss. I am also not sure what parts of the
above are currently handled by JMX or overlap with what Marc is working on.
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
