Automatically provision services during application deployment:
Provision all the required dependent services during deployment of a Java EE application. The application could come up with full/partial/no cloud meta-data.
The Orchestrator would use the IaaS APIs to provision and manage the lifecycle of a Provisioned Service. The Orchestrator must be Service VM Host/Guest OS agnostic. In other words, the Orchestrator must not have any additional dependencies/restrictions on Host/Guest OS of a Service VM Image as we expect the IaaS API and implementation to handle these.
The following must be considered as part of Service Provisioning
- Service Provider Matching (Template matching rules): Using the service meta-data bundled with or discovered from the application, the Orchestrator must match the service requirements of the application to a Service Template. This template would then be used to provision and realize the Service. These matching rules are still a work in progress. One simple rule that has been identified is: If the application requires a RDBMS service and the service definition is not specified in the cloud meta-data or the service definition does not explicit point to a particular Service Provider(say MySQL), then by default the Orchestrator will select a "default" template (e.g: Derby service template).
- Atomic provisioning: Provisioning of the dependent services of an application must be atomic (ALL or NONE).
- Failure handling: If a subset of dependent services cannot be provisioned, the deployment must fail and the state of the system must roll-back to the state prior to the current deployment. [Atomic deployment]
- Ambiguity during provider matching When multiple plugins can handle particular service requirement and a particular service provider can not be matched then deployment must fail.
- Automatically provisioning services for vanilla Java EE archives