-
Notifications
You must be signed in to change notification settings - Fork 7
Provisioner Service
The Provisioner is a service that allows a client to specify 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.
- Provisioner - Provisions the system with a set of Resources to satisfy a given set of client Requirements
- Environment - The Environment holds the runtime state of currently installed Resources with their associated Capabilities and Requirements
- Resolver - The Resolver is a stateless services that can find a consistent wiring solution for a given set of Capabilities/Requirements
- Repository - 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.
- Resource - 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)
- Capability - A Capability is an abstract concept of capability that a Resource can provide.
- Requirement - 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.
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 returns 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 unsatisfied 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.
The Repository contains a set of portable metadata definitions. Key aspects of these resource definitions are
- The unique resource identity
- A set of optional first order resource dependencies
- Additional metadata that drive resource processing (i.e. shared or not shared)
The generic data model of resources with associated capabilities/requirements allows for arbitrary dependency definitions. (e.g. on specific runtime services)
Any artefact that gets deployed/provisioned to a given target container must of course be supported by that target container.
Tomcat supports ordinary jars in the shared lib location. Unshared resources must be WARs.
Multiple versions of resources with the same symbolic name are not supported in the shared lib location.
An OSGi framework supports OSGi bundles. There is no distinction between shared and unshared. Resource dependencies based on identity work in the context of Gravia provisioning. They are no guarantee that the deployed/provisioned bundles will actually wire in the way as defined by Gravia. OSGi metadata must be valid and resolvable in the runtime.
Multiple versions of resources with the same symbolic are supported.
WildFly supports ordinary jars in the shared lib location. Unshared resources can be deployed/provisioned in a variety of formats.
Multiple versions of resources with the same symbolic are supported both in the shared and unshared location.