Like Andy says, you could implement your api on top of theMainDeployer/ServiceController/JMX remoting.

It doesn't help you much, since the only current way to deploy/change anEJB is to give it the jar file.

1) This shows bad design in our EJB container2) Would you seriously expect a user to know how to constructan EJB container programmatically (from the component services),even if that were an option?3) How do you keep the management tool up-to-date with thechanging implementation of the hypothesised EJB container?

No. The correct solution is to define the policy of the EJB,whether it is the ejb-jar/jboss.xml or the annotations.

The same should be true for our services.i.e. I want a DataSource and here is the connection-url, etc.not here is the managed connection factory with all the properties,here is the managed connection pool with all its properties, etc.Underneath, that is what happens, but the user doesn't needto know this, nor are they interested in most cases.In fact, there are currently 4 services that make up a datasourceand that doesn't include the jdbc driver deployment or the rar(s).

I was looking for what abstractions exist today in JON. I'll work on an abstraction in between the current directory based profile and jmx services as a starting point for a profile service/profile api to argue where the line between abstraction and implemention should be.

The management tools should be dealing with deploymentsand policy, not services.

Ok, let me clarify what I was talking about and see if that jives with your understanding. I was meaning to imply a Service is a *representation* of some granular component the user cares about. So when you call addService(Service) the app server is still going to need to know how to take the *representation* and create/deploy the functional implementation, e.g. the breakdown of a DataSource into its constituent mbeans. I guess I should also say that I think representation is very different from *definition*, it contains a lot less information. To help me compare this to policies can you add a definition of Policy to here http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelDefinitions.

2) Would you seriously expect a user to know how to constructan EJB container programmatically (from the component services),even if that were an option?

No. That wasn't what I was driving towards. You are right that full CRUD on "Container Services" (e.g. such as the EJB Container, JBoss Messaging) makes less sense, but if there was some attribute of the EJB Container which the user could want to change and would meaningfully impact how the container functions, then that should be exposed *without* also exposing unnecessary implementation details surrounding the "how" of the EJB container.

The same should be true for our services.i.e. I want a DataSource and here is the connection-url, etc.not here is the managed connection factory with all the properties,here is the managed connection pool with all its properties, etc.Underneath, that is what happens, but the user doesn't needto know this, nor are they interested in most cases.

So lets start with using the DataSource as an example. JON represents this as a "Service" within the Platform/Server/Service resource hierarchy which JON defines. Interesting things about JBoss related Services are: -They have properties which we monitor (i.e. collect values of over time). A property is just an attribute on some MBean which we associate with the service. We only collect availability for DataSources, which just corresponds to checking the existence of a particular MBean attribute. -They have configuration properties, e.g. name of the DataSource, location of the -ds.xml where applicable. This is essentially meta information JBoss ON uses for monitoring or controlling the service -They have operations which we call. An operation is just method on an MBean which we associate with the service.

In terms of administration (Create/Read/Update/Delete) we have a separate abstraction, which defines the interesting properties of a DataSource and has code which maps those properties to the underlying -ds.xml file.

In the future we're looking to move to a single model that doesn't require us to have a separate administration abstraction.

The classes you have drawn out obviously have some overlap withthe new VFD (virtual deployment framework).

I think we'll need to provide a better api than key/value pair forthe policy properties. This needs to include something like theOpenMBean api with metadata for valid values, etc.

It is also missing the CRUD operations and a notion of what canbe created. e.g. I want to create a datasource where is the "template"coming from?

Finally, it lacks:* the lifecycle api like the JSR88 notion of distribute and activate(a notion of validate would also be useful, so a user can play with theconfig and say does it make sense before distribution,e.g. missing dependencies)* the versioning api for when it is supported

Scott, can you look at my usage of the API below and see if it is consistent with what you are thinking? I've also included some questions that arose while I was putting this together.

U1) List the Deployments which are deployed in the Server* How to get the name of the Profile which the Server is currently using, e.g. "default"?Profile profile = ProfileService.getProfile("default")Deployment[] deployments = profile.getDeployments()

U1a) List the types of Deployments which are deployed in the Server* Need a concept of Deployment type. So one can tell what "sort" of things you have deployed.

U1b) List all the Deployments of a particular type which are deployed in the Server* Need a concept of Deployment type, e.g. show me the DataSources I have deployed

U2) List the Properties of a Deployment and their current valuesDeployment deployment = deployments[0];DeploymentBeans[] dBeans = deployment.getBeans();* What do each of the DeploymentBeans actually represent? How are you meant to tell which DeploymentBean to use?DeploymentBean myBean = dBeans[0];Map<Property, Object> properties = myBean.getPropertValues();* When should a user (i.e. admin tool) call myBean.getPolicies()?

U3) Update a Property of a Deployment.mybean.setPropertyValue(name, value)

U4) See the current state of a Deployment* As Adrian pointed out, no lifecycle is exposed by the API

U5) Add Deployments to the System* As Adrian pointed out, no way to add deployments

U6) Remove Deployments from the System* As Adrian pointed out, no way to remove deployments

U7) Stop Deployments which are currently running in the Server* As Adrian pointed out, no lifecycle is exposed by the API

U8) Start Deployments which are current deployed in the Server but are stopped* As Adrian pointed out, no lifecycle is exposed by the API

C4) When making multiple calls to update the Server we should support basic transaction semantics, e.g. when making two updates, if the second fails the first one should be "rolled back".* No support in the API for transactions, e.g. tx = ProfileService.beginTransaction(); tx.commit()

General Questions* What is Profile.getConfig() meant to return?* What is Policy.getConfig() meant to return?

U1) List the Deployments which are deployed in the Server* How to get the name of the Profile which the Server is currently using, e.g. "default"?Profile profile = ProfileService.getProfile("default")Deployment[] deployments = profile.getDeployments()

U1a) List the types of Deployments which are deployed in the Server* Need a concept of Deployment type. So one can tell what "sort" of things you have deployed.

U1b) List all the Deployments of a particular type which are deployed in the Server* Need a concept of Deployment type, e.g. show me the DataSources I have deployed

The notion of deployment type would be one of the attributes in the Deployment. I'm going to do another iteration of the spi that maps better to the JSR88 javax.enterprise.deploy.spi.DeploymentManager and clarify that.

U2) List the Properties of a Deployment and their current valuesDeployment deployment = deployments[0];DeploymentBeans[] dBeans = deployment.getBeans();* What do each of the DeploymentBeans actually represent? How are you meant to tell which DeploymentBean to use?

A DeploymentBean is some metadata for an MC bean that needs to exist for the deployment. In terms of knowing what to deal with, there has to be some convention for scanning for metadata that you understand. One example might be a portal based implementation of a console that looked for view metadata and only redendered those beans with this.

U4) See the current state of a Deployment* As Adrian pointed out, no lifecycle is exposed by the APIU5) Add Deployments to the System* As Adrian pointed out, no way to add deploymentsU6) Remove Deployments from the System* As Adrian pointed out, no way to remove deploymentsU7) Stop Deployments which are currently running in the Server* As Adrian pointed out, no lifecycle is exposed by the APIU8) Start Deployments which are current deployed in the Server but are stopped* As Adrian pointed out, no lifecycle is exposed by the API

C4) When making multiple calls to update the Server we should support basic transaction semantics, e.g. when making two updates, if the second fails the first one should be "rolled back".* No support in the API for transactions, e.g. tx = ProfileService.beginTransaction(); tx.commit()

Its not clear that this should be a manifest api in the ProfileService. Why wouldn't this be an implementation detail that picks up the transaction aspect when running in a context with a transaction (and ejb3 embedded implementation of the ProfileService)?

Reviewing the jsr88 deployment manager api again, the reason why there are no lifecycle on the Deployment objects is that these are not representations of active server deployments. A Deployment represents the metadata needed to create/reference an actual deployment on a server. This is more like the jsr88 javax.enterprise.deploy.spi.DeploymentConfiguration (see http://wiki.jboss.org/wiki/Wiki.jsp?page=JSR88DeploymentManagerClasses).

Any runtime interaction with a server(s) in terms of modifying a profile would essentially need a javax.enterprise.deploy.spi.DeploymentManager to be able to specify which server(s) were being targeted.

Similarly, a Policy associated with a Deployment may not be meaningful to write to except when active in a server. A Policy is about wiring the Deployment bean values to container "beans".

I'm going to expand the ProfileService to support profile creation and deployment templates and then come back to the running deployment notions.

I added Policy/Deployment editing, changed the Property to a PropertyInfo modelled along the lines of the OpenMBeanParameterInfo, and added a simple DeploymentTemplate notion for building a Deployment from a set of PropertyInfo values.

It still seems that the runtime manipulation of server deployments needs to be correlate to the jsr88 deployment manager and integrate with the server(s) profiles.

Regarding the jmx OpenType/OpenMBean style of properties, I can see this is better than opaque types, but it really does not solve the problem of mapping a deployment bean's metadata to a meaningful view. Its probably an intractable problem from just the bean metadata level, so it seems like we need a notion of a logical management view in between the profile service api and the management tools so that if I rewrite the jmx console using portlets, I don't need an intimate knowledge of the deployment beans to create simple portlets. A management view java bean that aggregates one or more deployment metadata beans would do the trick.