GlassFish - World's first Java EE 7 Application Server


GlassFish 3.2 Service Orchestration Technical Requirements

Feature Overview

Id
Priority
Name
Description Dependencies
0 P1 Feature Overview Single-click application provisioning and deployment of a PaaS application through service dependency discovery, service provisioning and service association. All the technical requirements listed below are an expansion of this single feature  

Service Definition and Metadata

Id
Priority
Name
Description Dependencies
1.1 P1 Support association to different types of Services The Orchestrator must support binding of an application to the following types of Services:
  • External services(these are not provisioned by the orchestrator, but created and managed by an external user. Their lifecycle is not tied to an application and is not managed by the orchestrator. This is useful in scenarios where a user has existing DB/MoM investments and they want to reuse their existing setup for their application.)
  • Global/shared services (Services that are created by a DAS administrator that are provisioned and managed by the orchestrator. These services can be shared by multiple applications in the domain and the service lifecycle is not tied to a single application. This type of service is useful, for example, when multiple applications in a domain want to share the same database.)
  • application-scoped services (These are services that are automatically provisioned by the orchestrator during PaaS-style deployment of the application, and their life-cycle is tied to the application's lifecycle.)
  
1.2.a P1 Service Meta-data
Define a mechanism to specify deployment-time cloud meta-data (cloud.xml or any other appropriate name as we decide) that includes service definitions and service references of an application. The service reference could be a reference to an application-scoped service or global/shared service or external service (see requirement #1.1)  
1.2.b P1 Vendor specific Service Meta-data
Define glassfish-cloud.xml schema for glassfish specific defaults and extensions for cloud-meta-data. This could also be used by the Orchestrator to map generic service meta-data specified in cloud.xml to a Service Template in an IMS template catalog.  

Service Provisioning

Id
Priority
Name
Description Dependencies
2.1 P2 Extensible Service provisioning and association The Orchestrator component runs in DAS, and is responsible for reading Service Metadata, provisioning of Services and association of Provisioned Services to the application. The orchestrator must not assume a fixed set of ServiceTypes and a limited set of Service Providers per ServiceType. A plugin architecture (Service Provider) must allow extending the orchestrator to support provisioning and association of new ServiceTypes and Service Providers for a ServiceType.  
2.2 P2 Service Provider Pluggability Define SPIs to be able to add/remove the Plugins into the Orchestrator. The SPI will also define contracts for service life-cycle related activities viz., create, start, stop, destroy.

For this release, these SPIs will be private to GlassFish. 		The various Service integration teams would deliver the plugins. For instance, the MQ integration team delivers the OpenMQ plugin, the JDBC team delivers the JavaDB and MySQL plugins and the LB team delivers the various load balancer plugins.
2.3 P1 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.
2.4 P1 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). 		 
2.5.a
P1 Atomic provisioning 
Provisioning of the dependent services of an application must be atomic (ALL or NONE).
 
2.5.b P1 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]  
2.5.c
P1 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.  
2.6.a P1 Automatically provisioning services for vanilla Java EE archives
Provision all the required services during the deployment of a vanilla Java EE archive that is cloud unaware (i.e., doesn't contain any cloud meta-data).
Requirements 2.5.a, 2.5.b, 2.5.c are related to this.
 
2.6.b
P1 State restrictions(if any) for PaaS application deployments For example, if there is a physical JNDI name based resource lookup without explicit service reference in the cloud meta-data, then the orchestrator may not be able to perform service provisioning for such physical resource references.
Also, in some cases Orchestrator might not be able to discover/provision all the services required for the application to run. In these cases, the deployment of such archive will fail.
 

Service Association

Id
Priority
Name
Description Dependencies
3.1
P1 Service Association/Binding Automatically perform necessary actions(create the necessary pools/resources etc) in the application server to bind an application to the services provisioned for the application  

PaaS Deployment scenarios

Id
Priority
Name
Description Dependencies
4.1 P1 Supported list of ServiceTypes and Service Providers List of services/plugins supported for this release are RDBMS(JavaDB, MySQL), HTTPLoadBalancer (potentially 3 plugins: Native LB, Java LB, Apache mod_jk - exact set of supported LB configurations is TBD), JMS(OpenMQ).
 
4.2
P2 Deployment plan
Allow a user to specify the cloud meta-data external to the application, via deployment plan Deployment module must not ignore the cloud meta-data specified via deployment plan
4.3
P1
Automatic Service Decommissioning Automatically decommission all the application-scoped provisioned services of an application during application undeployment.  
4.4
P1 Pause/Stop Provisioned Services Pause/Stop all the application-scoped provisioned services when an application is disabled. Similarly, start all the provisioned services when the application is enabled. The Orchestrator will invoke the Plugin to pause/stop the service. So it is the Plugin's responsibility to stop the service.  
4.5
P1 Provisioning during redeployment Support redeployment of the application.
Possibly with a "--retain" redeployment option to re-use the previously provisioned services instead of re-provisioning again. 		 
4.6
P3
Support application versioning Only one version of the application will be active at a time. Each version of the application will have its own provisioned service(s) scoped to that particular version of the application. When a particular version of the application is disabled, all its associated application-scoped services are stopped.  
4.7
P1 Service decommissioning during domain deletion Decommission all the provisioned services (application scoped and global/shared) during domain deletion.
Should we also decommission shared services as they are used only within the domain ?
The Orchestrator will invoke all the related plugins to decommission the services. 		Admin infrastructure - delete-domain callback to the Orchestrator
4.8 P1 Track provisioned services Orchestrator must keep track of all the services provisioned via the Orchestrator.  

Management/Administration interfaces

Id
Priority
Name
Description Dependencies
5.1 P1
Admin command interception for managed services/resources All the administration operations/commands on a managed entity(such as a cluster provisioned by the orchestrator) must be intercepted by the Orchestrator. The orchestrator will decide whether to allow or disallow these operations. (For example, orchestrator might not allow 'asadmin stop-cluster' on a managed cluster). Moreover, orchestrator might need to perform some additional tasks (eg: for book-keeping purposes) during the command execution on a managed object. Admin Infrastructure must wrap all the commands on the managed object to go to Orchestrator first.
5.2
P1
Additional asadmin commands Implement admin commands for create/delete/list global services in a domain. The command implementation will internally invoke the plugin to do the needful. Plugin might internally use IaaS APIs, various existing glassfish commands to perform the task. Implement admin command to import/provision an external service into a domain.  
5.3.a P1 CLI/GUI to show all provisioned/shared services for a particular deployed application Orchestrator, with the help of plugins can determine implicit service requirements or use default service requirements or use shared services in order to satisfy an application's various service requirements. There needs to be an administrative interface (eg: CLI) to show the list of all services used by a particular application. eg: The State of the service(started/stopped/stopping/starting) can also be shown. In case of partial undeployments, some services might be in deleted state.  
5.3.b   CLI/GUI to show the list of managed applications that share a particular service A CLI command to list all applications that use or is bound to a global/shared service or an external service.  
5.4 P2 Logging Orchestrator actions to aid troubleshooting
Since a PaaS-style deployment would entail a lot of Orchestrator operations (such as Template Matching, Service Provisioning, Service Assocation), it is imperative that the Orchestrator logs all its actions to enable offline troubleshooting. 		 
5.5
P3 Monitoring probes Expose monitoring probes for various Orchestrator functionalities 
 
5.6
P3 Health check - service Ability to perform a health-check on a particular Service (eg: ping)  
5.7
P1 GUI (admin console) requirements
  We expect GUI team to come up with GUI requirements. For example, a GUI option for PaaS style deployments, creating and registering Service Templates are suggested requirements on the admin console.

Domains Manager and Template requirements

Id
Priority
Name
Description Dependencies
6.2
P1 Pre-built Service Templates GlassFish 3.2 would come with standard pre-built templates for the supported service providers (see requirement #4.1). The orchestrator matches the service requirements of an application to a service template(either pre-built or user-provided) through its cloud metadata(see requirement #2.3). The orchestrator/service plugin must not assume that the pre-built service template is the only template that could be provisioned. In other words, the orchestrator/plugin must support user-defined service templates. The team that would build these pre-built templates is TBD.

Non Requirements/Out-Of-Scope

Id Name Description
1 Orchestrator has no active role in Domains Manager/clustered-instance/standalone-instance Domains Manager will invoke the appropriate remote command on each domain to configure the external service.
So, Orchestrator functionality is available only in the DAS.
2 Advanced redeployment scenarios
Update and Upgrade of Service References
3 Lazy initialization of Provisioned Services Shared/Global Provisioned Services could be lazily started when the first application using it is deployed. Similarly when the last application using a Shared provisioned Service is undeployed/disabled, the Service could be paused/shutdown to conserve resources. This is currently not planned for this release.
4 Extensible Service Provider mechanism Making the Service Provider SPI public, to allow third party services to be plugged into the Orchestrator is not planned for this release.
5 Elastic scaling of Services The current elasticity requirements center around GF cluster scaling (EL-2.0.6 in the Elasticity Requirements page) and so there is no auto-scaling of the provisioned service planned in this release.
6 Allow a Provisioned Service's lifecycle to be managed by a PaaS System Adminstrator Allow a PaaS sysadmin to start/stop a Service that has been provisioned by the Orchestrator is not supported in this release.
7 Support mapping to external PaaS Service Offerings (for instance Amazon RDS)  
8 Support for other ServiceTypes (Mail, Queueing, NoSQL)  
9 Advanced Service Matching Heuristics  
10 No support for Orchestrator in Ad-hoc clusters Ad-hoc clusters (aka head-less c lusters) are primarily aimed at the Amazon Elastic BeanStalk scenario and in that case Services are provisioned and associated either by the Elastic BeanStack infrastructure or our HostManager SPI implementation and so there is no support planned for Orchestrator in Ad-hoc clusters.
11 Stacks/Assemblies of Services Support for an assembly/stacks of Services to be managed/provisioned as a whole (SteamCannon and Nuviaq refers to this as Platform) is beyond the scope of this release.
12 External services at the domain manager level Allow definition of external services at domains manager level (across domains). Not doing this as Domains Manager is not planned to part of GlassFish 3.2.

References: