Some use cases and questions

[acoliver]

Hi,

Portions of this are offtopic, but it will be hard to get a non-disjointed answer without the background. I'm about to go on a journey to try and make JBMS a bit more manageable but I want to make sure I'm not duplicating work. I would like to:

0. Have a decent admin GUI (competitive with existing mail offerings)
1. allow hot deployment of services
2. allow changes to service configuration w/o redeploying said service yet have those available at restart
3. allow decoupling of metadata and persistence of metadata to repositories (such as ldap, file based, database, windows registry, whatever)... It should still be able to read/write to a hand-editable config file (decoupled from instance descriptor)

JBMS has these types of data essentially:

1. Declarative instance information (name, existence)
aka "mbean name="
2. Declarative structural information (operations/attributes)
aka has an attribute called, has an operation called
3. simple instance attribute settings (strings, ints, etc)
aka jboss-service.xml style attribute settings
4. simple dependency declarations (static to class, name)
i.e. ALWAYS depends on transaction service
5. complex dependency declarations (dynamic to instance, proxies)
for example my "server" has an injected proxy to the "protocol" which it exposes. I may have N instances of SERVER and N instance of PROTOCOL but each SERVER depends/exposes ONE protocol. (The server answers the port and passes off to the protocol)

I know:
1. There is an attribute persistence service pre-existing. Is it usable for this purpose?
2. About the deployment-service

My thoughts:
1. expose all existing MBeans as "service" beans
2. mark up case #5 attributes with @injectConfig and provide a generic aspect which retreives from a persistence service
3. create a custom deployer which reads the dependency tree from the persistence service, finds holes and deploys in the correct order (this is a duplication of the ServiceController, is it possible to push the data to the service controller?)
4. create a configuration persistence service
5. create a wrapper for MBeanServer which sets attributes, creates instance, etc and also sends the info to the configuration service.
6. create a scanner which scans the decoupled config file and applies changes but does not restart/redeploy the service.

Expectations:
1. I'll be able to change attributes at runtime, have them persisted and set. They will not be lost after restart. They will be set before "start" and set once.
2. i'll be able to dynamically create instance and their dependencies with data

probably:
server/default/deploy/bla-service.xml

<mbean name="jboss.jbms:service=Server,protocol=SMTP">
</mbean>

<mbean name="jboss.jbms:service=Protocol,protocol=SMTP">
</mbean>

server/default/conf/jbms.xml (or ldap or whatever)

<service name="jboss.jbms:service=Server,protocol=SMTP">
 <!-- proxy implied by @ tag -->
 <attribute name="protocol">jboss.jbms:service=Protocol,protocol=SMTP</attribute>
 <attribute name="port">25</attribute>
</service>

<service name="jboss.jbms:service=Protocol,protocol=SMTP">
...
</service>

Does the microcontainer buy me anything here? What are the mismatches?

[acoliver]

(oh and note i have read the documentation in the READ THIS FIRST as well as what was linked from development forum, I just used what I was more familar with for examples)

[starksm64]

So I see this as a heavy overlap in that all of the functionality you describe will exist in the microcontainer as used by jboss5. The reply I gave to Charles on "Design of MC for Bean configuration" (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73288) also overlaps here.

Also, have you navigated to the kernel design wiki page?
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernel

The current disconnects are just in terms completeness with respect to the level of usage you are starting at. For example:

1. hotdeployment is an interaction of bean (monitor + deployer) similar to what we have today. Only a deployer notion exists currently.

2. this is possible, but the term "service configuration" is an overloaded term thinking of the existing jboss-service.xml mbean service in that the configuration are the attribute associated with the mbean declaration, and changing this in jboss4 involves redeployment of the service. Decoupling declaration of a service from its configuration metadata is fundamental notion in the mc. The configuration for services/beans that should be installed to the mc is the profile service in the kernel design related pages (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelConfiguration).

3. Yes, this is an aspect of the metadata repository that I'm currently working on. This does not exist at all implementation wise, but is what I'm currently working on. The metadata repository is a store of pojo metadata with a hierarchical namespace. The hierarchical structure defines the level at which the metadata is introduced/loaded: THREAD, REQUEST, SESSION, DEPLOYMENT, APPLICATION, SERVER, CLUSTER, DOMAIN

The are two elements to your usecase:
a. repository loaders: how data from a given level is loaded.
b. a management aspect that ties together that runtime modification of data at a given level needs to be written to a particular store.

All of what you are talking about intersects with the mc notions.