1 2 3 4 5 Previous Next 72 Replies Latest reply: Apr 20, 2006 4:18 AM by Scott Stark Go to original post RSS
  • 30. Re: Need to get going on a ProfileService api
    Adrian Brock Master

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

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

    1) This shows bad design in our EJB container
    2) Would you seriously expect a user to know how to construct
    an 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 the
    changing 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 need
    to know this, nor are they interested in most cases.
    In fact, there are currently 4 services that make up a datasource
    and that doesn't include the jdbc driver deployment or the rar(s).

  • 31. Re: Need to get going on a ProfileService api
    Adrian Brock Master

    The big deal for me is how you tie back the services to the
    deployment.

    e.g. a management tool deploys an ejb to a cluster,
    the jsr77 stats for each node should be available when it is in the
    active state.

    Also when I talk about the management tool, I am talking about
    a model.

    The "GUI" could be the command line, a struts web app, an eclipse
    plugin, etc. It just renders the model and provides "wizards/templates"
    on top of it.

    Although, my own personnel view is that "templates" or any form
    scripting that looses the meaning of what is being expressed
    is a failure of the underlying model.

  • 32. Re: Need to get going on a ProfileService api
    Scott Stark Master

     

    "charles.crouch@jboss.com" wrote:
    Here is a start. Is this the sort of thing you want?

    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.

  • 33. Re: Need to get going on a ProfileService api
    Charles Crouch Expert

     

    "adrian@jboss.org" wrote:

    The management tools should be dealing with deployments
    and 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.

    "adrian@jboss.org" wrote:

    Services are too fine grained and implementation detail
    specific.

    Ok, then maybe this is just a problem with the definition I used of a Service. So I'd say a "DataSource" is a Service, but a "Managed Connection Pool" is not, its too low level.

    "adrian@jboss.org" wrote:

    I want to remove the implementation detail from the
    user's view (except for debugging or super user purposes).

    +1. So for a DataSource I would say that Blocking Timeout is something the user should be able to read/edit, but the name of the required MBeans for the connection pool/factory is not.



  • 34. Re: Need to get going on a ProfileService api
    Charles Crouch Expert

     

    "adrian@jboss.org" wrote:

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

    I guess you could, but as you point out it would be an in-ordinate amount of work due to the lack of support for the requirements (e.g. persistence, off-line access) within the current app server.

    "adrian@jboss.org" wrote:

    2) Would you seriously expect a user to know how to construct
    an 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.

    "adrian@jboss.org" wrote:

    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 need
    to know this, nor are they interested in most cases.

    I agree 100%.


  • 35. Re: Need to get going on a ProfileService api
    Charles Crouch Expert

     

    "scott.stark@jboss.org" wrote:

    I was looking for what abstractions exist today in JON.


    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.


  • 36. Re: Need to get going on a ProfileService api
    Scott Stark Master

    Here is a first pass at an abstraction:
    http://wiki.jboss.org/wiki/Wiki.jsp?page=ProfileServiceClasses

    To flesh it out more I want to prototype an implementation that replaces the existing filesystem based profiles with no persistence of updates.

  • 37. Re: Need to get going on a ProfileService api
    Adrian Brock Master

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

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

    It is also missing the CRUD operations and a notion of what can
    be 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 the
    config and say does it make sense before distribution,
    e.g. missing dependencies)
    * the versioning api for when it is supported

    Others?

  • 38. Re: Need to get going on a ProfileService api
    Scott Stark Master

    I'll keep this in mind as I flesh out the file system based prototype.

  • 39. Re: Need to get going on a ProfileService api
    Adrian Brock Master

     

    "adrian@jboss.org" wrote:
    This needs to include something like the
    OpenMBean api with metadata for valid values, etc.


    Another option would be use something like the schema
    facets and properties.
    http://www.w3.org/TR/xmlschema-2/#rf-facets

  • 40. Re: Need to get going on a ProfileService api
    Charles Crouch Expert

    So I've taken the use cases that I created above, and "translated" them so hopefully they are using the correct nomenclature. I've pointed out the various ones which can and cannot be implemented using the API Scott has drawn out. http://wiki.jboss.org/wiki/Wiki.jsp?page=ProfileServiceClasses

    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 values
    Deployment 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?

    Thanks

  • 41. Re: Need to get going on a ProfileService api
    Scott Stark Master

     

    "charles.crouch@jboss.com" wrote:

    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()

    Right.

    "charles.crouch@jboss.com" wrote:

    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.

    "charles.crouch@jboss.com" wrote:

    U2) List the Properties of a Deployment and their current values
    Deployment 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.

    "charles.crouch@jboss.com" wrote:

    DeploymentBean myBean = dBeans[0];
    Map<Property, Object> properties = myBean.getPropertValues();
    * When should a user (i.e. admin tool) call myBean.getPolicies()?

    When it nees to read/write the bean attributes. This does relate to the previous question. You have to know something about the beans to work with them.

    "charles.crouch@jboss.com" wrote:

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

    Yes.

    "charles.crouch@jboss.com" wrote:

    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

    Yes, I'll synch up with jsr88/kernel notions to add this.

    "charles.crouch@jboss.com" wrote:

    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)?

    "charles.crouch@jboss.com" wrote:

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

    Arbitrary attributes/configuration data for externalizing the behavior of the Profile and Policy implementations.

    I'll do another iteration of the api tonight before going on with the prototype since there is enough feedback for that.


  • 42. Re: Need to get going on a ProfileService api
    Scott Stark Master

    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.

  • 43. Re: Need to get going on a ProfileService api
    Scott Stark Master

    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.

  • 44. Re: Need to get going on a ProfileService api
    Scott Stark Master

    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.