1 Reply Latest reply on Feb 8, 2005 1:16 PM by Scott Stark


    Dimitris Andreadis Master

      (moving this here, the quoted stuff is from Sacha)

      but do we agree that for all services that is deployable through
      your system, you have a corresponding MBean that can be used to
      perform such action? Is this MBean JSR-77 related (it should IMHO).

      There is no "proxy/management mbean" for each deployment now, all operations (upload, create, deploy, undeploy, remove) go through the deployment service.

      This is probably a good idea, i.e. keep DeploymentService as a factory and create wrapping proxies for all top-level deployments. Or infact, integrate somehow with the existing management mbeans and enhance their API to add methods like undeploy or remove. I'll need to think about it...

      Furthermore, can the deployment process be synchronous (not
      Asynchronous like the default deployment mode) and report any issue?
      That is something that is currently missing: you cannot report an
      error to a client that has launched a deployment operation. This will
      be increasingly difficult in the future as we moving towards
      clustering deployment and maybe should we directly move to some kind
      of "transactional" or "two-steps" deployment where you can first ask
      the deployer to "prepare" a deployment (check as much as it can that
      the deployment should be ok i.e. that required dependencies,
      resources, etc. are available) and then "commit" (i.e. effectively
      deploy the service/app). Hence, in a clustered environment, we could
      first ask all nodes if a "prepare" is fine and then issue a commit. We
      might not want to go to full TX semantic but even a weak clustered
      semantic would be better than a simply asynchronous try-and-forget
      semantic ;)

      The implemented API was the simplest possible to do at this stage, in the sense that we re-use the DeploymentScanner. We can emualate short of synchronous behaviour by waiting on the main deployer. If we want to be really synchronous we'll have to re-implement the Scanner functionality and somehow isolate the DeploymentService deployments from the ./deploy dir...

      So the question really is, given a new deployment in directory ./undeploy, how we deploy this? Either we give it to the scanner by moving this to ./deploy, (or ./farm, or ./hasingleton...), or we give it directly to the MainDeployer, but then we have to solve the problem how we treat a server start-up. (essentially we'll have to duplicate what the scanner does...)

      In any case, my initial intention was to solve the problem of having a deployment "factory", since a deployment in jboss is basically any type of package (.sar, .rar, .xml, .war, .etc). rather than just MBeans.

      If you have any ideas let me know!

        • 1. Re: DeploymentService
          Scott Stark Master

          The intersection with the management apis is really more along the lines of j2ee 1.1 management api(JSR-88) which has this very deep discussion of how it relates to JSR-77:

          1.2.1 Relationship to the J2EE Management Specification (JSR-77)

          Deployment is an integral part of platform management. It depends on
          management functionality to start deployed applications, stop deployed
          applications, report the status of applications, and the like. We determined, however, that J2EE platform deployment and management should be addressed in separate JSRs, because of the ways in which these two topics need to be addressed. J2EE platform management needs to be defined as a metadata model and not as an API in order to best address the issues of interoperability with different management systems and protocols. Deployment, on the other hand is best addressed as an API. It is expected that the Platform Product Provider will integrate the Deployment API with its management model implementation. This specification describes its interactions with the J2EE Platform Management Model.

          1.2.2 Replacing a J2EE Application

          We recognize that over time applications evolve and need updates of various types. The J2EE specification does not currently address this issue, nor does it prohibit the Platform Product Providers from doing so.

          We believe that this API provides a sufficient infrastructure to enable Platform Product Providers to continue providing application update solutions that are appropriate for their implementations. In addition this specification defines a very basic type of application redeployment. A redeploy method is provided. It is an optional feature for the Platform Product Provider to implement.


          4.6 DeploymentManager and the J2EE Management
          Specification (JSR 77)

          The J2EE Management Specification defines a model for platform
          management. Deployment is an integral part of J2EE platform management. Deployment depends on management functionality to start installed applications, stop running applications, and report the status of applications. This section describes the recommended mappings of the DeploymentManager functionality to the management model.

          4.6.1 Listing Deployed Modules

          The management model provides access to all managed objects on the J2EE platform through the J2EE Management EJB component (MEJB). The MEJB is registered in the Java Naming and Directory Interface ? (JNDI) service. The DeploymentManager may use the MEJB to acquire the list of deployed modules on the platform. See chapter 7, "J2EE Management EJB" in the Java 2 Enterprise Edition Management Specification.

          4.6.2 Module Start and Stop

          The management model provides a facility for state management of managed objects. This is an optional feature. The state management facility allows applications to start and stop deployed modules. The DeploymentManager may use this facility to start and stop modules that support state management. See chapter 5, "State Management" in the Java 2 Enterprise Edition Management Specification.

          7.3 Target and the J2EE Management Specification (JSR 77)

          There is no managed object in the management model that translates directly to a Target object. There is a J2EEServer object. This represents a single J2EE server. A Target can represent a single server, but it can also represent a collection of servers. It is left to the J2EE Product Provider to provide a translation of Target object to J2EEServer objects for their product. See section 3.3, "J2EEServer extends J2EEManagedObject" in the Java 2 Enterprise Edition Management Specification.