This is interesting... and i'am doing things in this direction :-) Ok, i've not been
thinking as far as you have done, how this would handle JBoss modules, but more on how
our own application could be extended with new services in an easy way.
I'm having this running today but on another EJB server. A new service is packed in a
jar file with a properties file describing it. The jar file is dropped into a services
directory. There is a scanner scanning this directory for new, updated or deleted
services. A client of our application can query an EJB compoent for which extra
services that are available, pick one service and get a UI object dynamically
downloaded. This UI object may then proceed on the client and communicate with the
user and with the service on the server. This is really a hit to demonstrate for our
customers, just drop a jar file on the server and the client will have a complete new
UI to work with :-)
This am i now converting to use the JMX architecture where the services are MBeans.
Hope to have it running (in my rather simple version :-) next week.
/Lennart
----- Original Message -----
From: Jason Dillon <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 20, 2001 11:15 PM
Subject: [JBoss-dev] Deployable service archives & new configuration system
> 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
