The Provisioner is a service that allows a client to specifiy a set of abstract requirements to be satisfied by the runtime. It has the complete view of Capabilities installed in the runtime plus the possible set of installable Resources from the Repository. It uses the Resolver to determine whether/which additional Resources need to be installed in the Environment to provide the requested functionality.
Provisions the system with a set of Resources to satisfy a given set of client Requirements
The Environment holds the runtime state of currently installed Resources with their associated Capabilities and Requirements
The Resolver is a stateless services that can find a consistent wiring solution for a given set of Capabilities/Requirements
The Repository holds the complete set of installable Resources with their associated Capabilities and Requirements. A Repository can delegate to other Repositories to find suitable Resources.
A Resource is an entity with associated Capabilities and Requirements. A Resource can be abstract to model a complex set of Capabilities/Requirements or congrete (i.e. a deployable artefact)
A Capability is an abstract concept of capability that a Resource can provide.
A Requirement is an abstract concept of requirement that a Resource has in order to resolve/work in the Environment. The Resolver can only resolve a Resource when every non-optional Requirement can be wired to a respective Capability in the Runtime.
Reuse of existing API
The OSGi R5 Core/Enterprise Specification already provides a number of APIs that can be reused by the Provisioner service. These enties are sufficiently abstract that they can be used independent of OSGi
In AS8 we already work with these abstract concepts to provide OSGi support. We have standalone Resolver and Repository services that work with Resources and their associated Capabilities/Requirements. During OSGi Bundle deployment we construct resource metadata from the OSGi Manifest. The Resolver uses this metadata to find a consistent wiring solution at resolve time. We use the wiring result to setup Module dependencies through the jboss-modules API. Every Bundle becomes a Module and once the associated Classloader and dependency wiring is esablished it should make no difference whether a deployment came in as OSGi Bundle or some other deployment type. Any Module (i.e. non OSGi) can define its associated Capabilities and be registered with the Environment. Modules known to the Environment have an OSGi Bundle view and can participate in future resolve operations. They can also use the OSGi Service Registry and participate in dynamic OSGi service handling. Integrating at the lowest possible level (i.e. Modules) allows us to invoke AS8 middleware services from OSGi and OSGi services from JavaEE deployments.
The Provisioner would first try to resolve the given set of Requirements against the Capabilities that already exist in the runtime Environment. If successful the Provisioner has nothing to do and return immediately. For the subset of Requirements that cannot get resolved in the Environment the Provisioner would contact the Repository to find the set of Resources that need to be installed in order to resolve the complete set of Requirements. If there are Requirements left that cannot get satisfied the Provisioner returns with a failure description that names the set of unsatisfieable Requirements. This completes the phase of impact analysis during which the Environment did not get modified. Only if the Provisioner found a set of installable Resources that provide the wanted Capabilities, it provisions these Resources and returns success with a description of installed Resources.
Any type of deployment could somehow define a set of abstract Requirements. The Repository specification already defines an XML schema to describe Repository metadata. I suggest to reuse that schema and the parsers we already have to define the set of Requirements that are input to the Provisioner service. Specifically, a deployment could contain an XML descriptor that defines additional requirements for that deployment. The deployment may or may not contain congrete Resources that are provisioned as well. Additionally, I suggest to define a propriatary manifest header that names the Requirements that are input to the Provisioner service. The syntax for this manifest header value is already defined by the R5 Core spec.
Feature deployment through Management
There should be a managment operation that allows an invocation on the Provisioner service with a set of abstract Requirements.
Entry points in Jira