[ccrouch]

So a runtime update from the perspective of achieving the semantic of having the service running with that change in effect may require logic in addition to just setting the property. This is also related to the transaction/bulk update issue. Generally you don't want a service immeadiately reacting to a single property update. A service also does not in general know how to correctly deal with cycling to apply updates. For example, if the detached invoker listening port is changed from 4444 to 14444 and all active requests should succeed, some aspect(s) is going to have to handle this. This is really a service dependency issue.

So how much of the handling of these runtime changes falls onto the Profile Service?

I could imagine the Profile Service/MC dealing with restarting a changed Bean and then updating all the other Beans that hold a reference to it (and presumably restarting those too since they had changed? etc etc)

When it comes to things like Beans listening on ports then as you say some additional component/"aspect" is going to be needed. This is presumably outside of the scope of the Profile Service?

[ccrouch]

A problem related to this dependency issue is that the dependency is all the defines that the 4444 port has anything to do with the ejb container. The 4444 invoker can be used by services other than the ejb container as well. I don't know how to deal with this arbitrary wiring of services together from the perspective of an admin console tool. To start with we will just provide the service to console mappings, but at some point the ejb container console should be a composition of portlets generated based on metadata exposed by profile service based on the wiring of the service dependencies. This also has to work when the server is not even running.

At some scope I think there needs to be another level of abstraction introduced on top of Beans. (I'd like it to be Service, because I don't understand what the current definition of Service actually adds: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelDefinitions).

An abstraction is required for exactly the reasons you outline. In order to change the port my "EJB Container Service" is listening on, the user shouldn't have to know that they have to mess with Detached Invoker beans. This "EJB Container Service" should take care of hiding the implementation details away from an admin tool. It would have to know that instead of just changing the port its Detached Invoker is listening on, which will impact other services which use the invoker, it will have to create a new Detached Invoker instance listening on the new port.

The next question is where this additional abstraction should live? If it doesn't come bundled with the Beans themselves then every management solution will need to implement this abstraction for themselves. Therefore I think it makes sense for the abstraction to be written once and then reused accross "admin tools".

[adrian.brock]

Guys, before we start playing humtpy again,
please read the other threads on this subject.

You are mixing implementation details with contract. Again!

[adrian.brock]

To reiterate, the profile service is just a (possibly versioned) list of
deployments.
How it is implemented is upto the "user":
* Simple static list
* Directories ala JBoss4
* IDE based
* More complicated versioning over a database
* Something else
but management tools should deal with one contract.

If the management tools attempts versioning where it is not supported
it won't get it.
* Give me a list of versions - answer only the current version
* Rollback to last version - operation not supported
Similary for transacted deployments.

All this talk about ports, etc. is rubbish. A port is a piece of policy
that is (only technically) a part of the profile because it is defined in a deployment.

[adrian.brock]

Like I said before. If the management tool wants to define the versioning
then it should implement the profile service. Or at least that part of it.

[starksm64]

So we need to start hashing out the profile service api and the additional managment api abstractions. The topic is the profile service api, but the point was starting with this to get to the definition of a management abstraction to stop the propagation of incomplete management consoles.

[acoliver]

Can someone who understands the details draft this up on the Wiki as a unified proposal and then the discussion can center around it? I've seen many threads go by, half of which I sort of understood. Most really seem to go too far too fast rather than KISS and grow. I can doco something but my thoughts are a magnitude simpler and single-minded. I'd like to see this with a JB4 focus at first rather than a JB5 (easier to grow forward rather than backward). I also think we can drop JB3 because whether you realize it now or not, JB3 will be EOL by the time we had this ready for JB3.

[adrian.brock]

The problem is that nobody knows the details.
Somebody has got to sit down and work it out.

We have the high level requirements (AFAIK).

Besides what I said above:

I just want to have the basic infrastructure that can be
used as a facade to implement JSR77/88 (in an aspectized way
such that developers don't have to think too hard about
how their modifications affect it)
with plugins for value added behaviour.

The details are in how to define those plugins
and write the aspects that enable a model for JSR77/88 exposure.

I'd expect our management tools to bypass the facade and use the "better"
profile service directly.

thirdparty -> jsr88 -> profile service -> plugins -> deployers
us -> profile service -> plugins -> deployers

[acoliver]

Here is my "hacky" approach

MainDeployerEx

keeps a list of deployed URLs

SARDeployerEx
calls setConfigUrl(String) on every MBean deployed

AOP
MBean class files add setConfigUrl
Add interceptor to attributes with @save

Interceptor:
When a property is updated, Main deployer is notified to ignore deployment, JAXB is used on the descriptor, the attribute is added or changed, Main deployer is notified to allow further deployments.

Me thinks that would take care of unwrapped MBean deployments. Proper VFS and JARUpdaterThingyMBean could handle wrapped deployments. If we wanted that to go into a repository with pluggable backend, that shouldn't be really hard to implement.

All the developer does is mark his attributes with @save or presumably could add something similar to XMBean descriptor for non-jdk5.

[starksm64]

I would like to see the current JBossON abstraction in the form of a psuedo api before trying to draft a profile service through management api.

[ccrouch]

Ok. I can help with that.

Lets get the stupid question out of the way: you would like to see the "JBossON abstraction" of what exactly?

Thanks

[starksm64]

Basically I want to see the abstraction that isolates/encapsulates the implementation details leaking into this thread that are annoying Adrian. Maybe you need to make abstractions up to achieve this. I just want a better starting point for the management api that considers both simple implementations such as the current filesystem as well as what JBossON wants/has.

[ccrouch]

Here is a start. Is this the sort of thing you want? In my mind the most important pieces here are the definitions, use cases and cross-cutting requirements. The API should allow a mgmt console to implement the requirements listed below. The API below is obviously very simple but hopefully will be a starting point for discussion, the key thing is ensuring that whatever we work towards still meets the requirements.
At the moment the API and requ's deal with the single server level, so the next extension would be for me to update it to include concepts of Domain, i.e. multiple Servers and also adding requirments related to versioning and Service dependencies. I can flesh this out but I want to know if this is inline with what you were thinking.

Cheers
Charles



Definitions:
Server:- single instance of the MC
Service:- concept that is at a higher level than Beans, represents things users of the System care about, e.g. Web App, Enterprise App, DataSource, EJB Container, JBoss Messaging, JMS Queue.


Use Cases:
An administrator uses a Management Tool to:-

U1) List the Services which are deployed in the Server
a) List the types of Services which are deployed in the Server
b) List all the Services of a particular type which are deployed in the Server
U2) List the Properties of a Service and their current values
U3) Update a Property of a Service.
U4) See the current state of a Service
U5) Add Services to the System
U6) Remove Services from the System
U7) Stop Services which are currently running in the Server
U8) Start Services which are current deployed in the Server but are stopped



Cross-cutting requirements:
C1) Changes to Services should be persistent across Server restarts.
C2) Virtually all operations should work whether the Server is running or not. Obviously trying to start a Service will fail if the Server is not running, but updates to properties, should work fine and be picked up when the Server starts up again.
C3) Handle concurrent access, e.g. if you call getServices() with the intention of updating a Service, then somebody else calls update(Service) before you do, then your call should fail with an appropriate exception.
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".


Possible API and corresponding requirement #:
U1) List MgmtAPI.getServices()
a) List MgmtAPI.getServiceTypes()
b) List MgmtAPI.getServices(ServiceType)

U2) List Service.getProperties()
String Property.getName()
Object Property.getValue()
Map Property.getMetaInfo()

U3) Property = new Property(String name, Object value)
Service.setProperty(Property)
MgmtAPI.update(Service)

U4) ServiceState Service.getState()

U5) ServiceState MgmtAPI.add(Service)

U6) ServiceState MgmtAPI.remove(Service)

U7) ServiceState MgmtAPI.stop(Service)

U8) ServiceState MgmtAPI.start(Service)

C4) tx = MgmtAPI.beginTransaction();
MgmtAPI.add(Service)
MgmtAPI.update(Service)
MgmtAPI.start(Service)
tx.commit()

[acoliver]

Looks just like existing service controller in 4.x

[adrian.brock]

Here is a start. Is this the sort of thing you want?

This is entirely the wrong approach.
The management tools should be dealing with deployments
and policy, not services.

Services are too fine grained and implementation detail
specific. I want to remove the implementation detail from the
user's view (except for debugging or super user purposes).

Use Cases:
An administrator uses a Management Tool to:-

U1) List the Services which are deployed in the Server
a) List the types of Services which are deployed in the Server
b) List all the Services of a particular type which are deployed in the Server
U2) List the Properties of a Service and their current values
U3) Update a Property of a Service.
U4) See the current state of a Service
U5) Add Services to the System
U6) Remove Services from the System
U7) Stop Services which are currently running in the Server
U8) Start Services which are current deployed in the Server but are stopped

These are all covered by jsr77/jsr88/jmx.
But these abstractions are not good.
Can you tell me which one you use for each use case?
I know, but I can guarantee most users don't.

etc.