Design of MC for Bean configuration

[ccrouch]

Could someone point me to any discussion/documentation on the design of the Repository Service (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelCore) or POJO configuration (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelConfiguration). What I'm looking for is information on how the Microcontainer is going to address the following:


a) Once a bean is "installed" (http://docs.jboss.org/nightly/microkernel/docs/gettingstarted/en/html/basics.html#d0e268) in the Microcontainer, what will be the effect of updates to the bean deployment descriptor?

b) What, if any, Microcontainer apis will allow for the state of bean instances, e.g. their properties, to be manipulated programmatically?

c) If properties can be manipulated programmatically, how will the new values be persisted to survive across Microcontainer restarts?

d) If programmatic changes are possible, will the new persistent state be reflected somehow in the original bean deployment descriptor? If not, then what will be the semantics the Microcontainer will use for reading the bean deployment descriptor and a beans persistent state.

Thanks very much

[starksm64]

There was a big thread "Moving to thread local enc/metadatageneralization" touching on the repository so I would look at that. See the jboss-development list archives.

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

a) is really an ambiguous question because its an implementation detail of the deployer processing the descriptor. It could be the same as today where a redeployment occurs, it could "know" that changes only affected attributes and update the metdata or try to pass these to the beans management interface, etc. In short, this behavior is not a fixed design element at this point.

b) See some of the class diagrams out here under (Class Diagrams for Evolving JBoss5):
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernel
Also from this page, one of the main design issues is to have a POJO based model at the lowest level, so fundamentally xml is irrelevant. Its just one supported configuration mechanism.

c+d) At the lowest level this notion does not exist. It comes into play at the level of the metadata repository + that aspects associated with the path being used to update the state (jmx, some other management interface). In general the notion of the repository is that the bean metadata can be obtained from a collection of sources at different levels from class annotations, deployment descriptors, serve defaults, admin defaults, etc.

Because there is no hard coupling between a bean and its management interface (as is the case with the jmx based mc), this question can't be answered. There will be support for using jmx as the management view of course.

Your first big disconnect between the way things are done today(jboss4) vs how jboss5/Microcontainer will behave is that the bundled deployment descriptors should not be viewed as something that is manipulated by the admin/management layer. This should be introducing overrides/defaults at a layer above the application deployment level.

[ccrouch]

Thank you for the direction, I reviewed the dev-list thread and the new class diagrams. I had a couple more questions...

"This should be introducing overrides/defaults at a layer above the application deployment level."

What do you mean by 'layer' here? How does this relate to "scope" in http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelMetaData? i.e. the "THREAD, REQUEST, SESSION, DEPLOYMENT, APPLICATION, SERVER, CLUSTER, DOMAIN" levels you mention here http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3910490#3910490.

What's the relationship between the metadata repository and the bean itself? How do the two interact across the beans lifecycle? Will you be able to update a beans metadata by using the metadata repository directly or only through the beans "management interface"?

"It comes into play at the level of the metadata repository + that aspects associated with the path being used to update the state (jmx, some other management interface)."

Are you saying that the interface used to update a beans metadata could determine whether or not the change is permanent?

Are there plans to document use cases/sequence diagrams at the 'Microcontainer' level or at the 'AppServer atop the MC' level?


Thanks

[starksm64]

What do you mean by 'layer' here? How does this relate to "scope" in http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelMetaData? i.e. the "THREAD, REQUEST, SESSION, DEPLOYMENT, APPLICATION, SERVER, CLUSTER, DOMAIN" levels you mention here http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3910490#3910490.

The layer I am talking about is related to the scope only in that the management layer sources metadata at certain layers. The scope just defines an ordering of metadata that will allow a runtime consumer to choose between various priorities of metadata. The management layer would be a source of metadata at the deployment and higher levels since its not typically a runtime notion. However, you could have a management console that introduced runtime changes that should not be persisted that did in fact populate say the session level metadata.

By layer I mean a management aspect that layers on top of the bean deployments which introduces the management concern. Unlike the current jboss4 jmx based kernel, management via an aspect like jmx is not a fundamental notion. Some configuration layer would have to introduce this concern to some subset or all of the beans. Certainly the jboss5 configuration of the mc will introduce a management aspect, including legacy adaptors that allow the jmx mbeans to integrate.

What's the relationship between the metadata repository and the bean itself? How do the two interact across the beans lifecycle? Will you be able to update a beans metadata by using the metadata repository directly or only through the beans "management interface"?

It really depends on how the deployers/aspects associated with the bean make use of the repository.

"It comes into play at the level of the metadata repository + that aspects associated with the path being used to update the state (jmx, some other management interface)."

Are you saying that the interface used to update a beans metadata could determine whether or not the change is permanent?

Are there plans to document use cases/sequence diagrams at the 'Microcontainer' level or at the 'AppServer atop the MC' level?

Yes, just as today with the jmx management api, persistence is a configuration detail. As we move into the creation of the management aspects, interaction with the persistent state of the metadata repository and profile service will have to be considered.

I do plan on documenting the key usecases and interactions as the mc gets built out.

[adrian.brock]

What's the relationship between the metadata repository and the bean itself? How do the two interact across the beans lifecycle? Will you be able to update a beans metadata by using the metadata repository directly or only through the beans "management interface"?

Initial comment:

You are also assuming one QOI (quality of implementation).
The whole point of the abstraction is that people can pick/choose and plugin what
happens and what is enabled (e.g. maybe deliberately disabling some
features to provide a stable "lock down").

Back to your questions:

Most of these are a function of the metadata itself.

The metadata exists independently of the object.
That is a key feature of the new MC.

Metadata/management and real instance
* You can have a JMX MBean for a bean that is "on-demand" and click "start" on the
MBean to actually construct the real service.
* You can "suspend" a service (including removing the classloader) while keeping
the MBean/metadata in place.
* You can have metadata that is crosscutting or overriding lots of services,
e.g. a server level "default datasource"

Lifecycle
* Whether the metadata change leads to a recycling of the lifecycle depends upon
the policy of the metadata.
e.g. changing the transaction timeout of an ejb method does not require a redeploy
it just takes affect at the next invocation
e.g. undeploying the ejb's datasource does lead to a temporary removal
(or at least suspension of service either through valve or cluster failover) of the EJB.
* It also depends upon whether the metadata is co-deployed, e.g. that is typically
true for ejbs and webapps.

Profile/Deployment/Repository(metadata)/Management Console
* A profile holds the collection of deployments and their top level attributes
* The deployment holds the raw information
* The metadata repository and mangement console is a runtime notion that can
act upon the profile/deployment/repository/object
* Support for cross updates between the different layers are QOI

e.g.
* If the profile service is static/locked down, changes to it or deployments
won't affect live data until you restart the server
* If the repository/bean's management decorator have support for persistence
(and the option is configured) that will be able to "marshall" back changes into the
deployments/profile

It would also be possible to have a QOI where changes are propogated
across a cluster or federation of servers from a single console.

How much of this is initially available in the open source product is unknown.

Clearly the JBoss Network is well ahead in feature set and it will be able
to provide better QOI than what we can do for JBoss5.

If somebody doesn't want to use the JBoss Network,
then they can "write their own" profile service or
management decorator (hopefully contributing back new features to the open
source community).