On the whole, resource configuration metadata looks great. I agree upon the consensus of the group so far. This would primarily address configuration bootstrapping required for application deployment in both cloud/non-cloud environments.
(Comments inline)
----- Original Message -----
From: Adam Bien
To: jsr342-experts_at_javaee-spec.java.net
Sent: Thursday, September 08, 2011 4:44 PM
Subject: [jsr342-experts] Re: resource configuration
Hi Linda,
I like the ideas. Some remarks:
"Open Issue: What happens upon failure to satisfy the requested resources? Does the application fail to deploy or is there run-time failure?"
The app should fail as fast as possible => deploy failure.
Deployment failure
Open Issue: Should any of the following attributes be standardized, or should they be left as properties? :
They should be standardized with default values. I would extract the defaults from Resin, WLS, JBoss, WAS, GF and compare them. Or just use GF and ask for feedback :-)
The standard set of properties included for all the resources look fine.
"A number of the examples (e.g., Example 4) illustrate the creation of objects upon deployment. Should this creation be limited to cloud environments? For example, should we key it off a cloud.xml descriptor?"
Object creation should be NOT limited to clouds. It is very usable in Continuous Integration / Deployment scenarios: I re-create and re-configure the application server on each build from a common schema usually using bash-scripts or proprietary APIs. An automatic resource creation would significantly simplify all CI / Continuous Deployment setups.
This behavior should not be specific to cloud. I completely agree with Adam, as it eases the painful step of configuration management for Dev/Stage & Deployment environments. Even if the platform doesn't support stage specific configuration, having the ability to bundle configuration is a big win.
"What format should the specification of an application’s resource configuration dependencies take, particularly when the application is intended for multitenant use? For example, should they be externalized in a separate services.xml file? Should we support annotations as well, with XML overriding?"
1. Conventions
2. Java Classes / Annotations [see my follow email]
3. XML
Definitely XML, either services.xml or the existing application.xml. Having annotation support would definitely serve as easy replacement for developer friendly use cases like POJO based resource configuration (used by c3po style datasources with setXXX methods).
"Should such a descriptor also include the specification of QoS information as well as service dependencies? If so, what additional QoS metadata should we stan- dardize on (e.g., scaling information such as minimum and maximum number of server instances)?"
IMHO: it should. I would start with minimal set of attributes. Minimum and maximum number of server instance is a good start. We should look at EC2 or rightscale to get some ideas.
I would at least also standardize:
- max number of concurrent HTTP requests
- max number of concurrent TX
I don't think we should standardize QoS metadata. Having additional properties should serve as an extension mechanism for such configuration.
"Semantics of JNDI global names. We have been assuming that the JNDI namespace is per tenant. If application server instances are shared by different tenants, it is not intended that these resources are shared by those tenants by default. However, there are some resources (e.g., databases) that might poten- tially be shared by tenants. What means should we use to indicate sharing of resources?"
Resource configuration definition should be application specific and should not encourage creating shared resources.
java:global should be tenant-specific
(a) I do not intend to run into other tenant's namespace
(b) Application doesn't need to be coded/configured for multi-tenancy
Is java:global intended to be also tenant-specific? I would keep that global. We could introduce a java:tenant as a global-tenant-specific replacement for java:global.
thanks!,
adam
On 27.07.2011, at 00:42, Linda DeMichiel wrote:
One of our goals in this release is to provide improvements in
resource configuration and resource "definition". The intention here
is both to enable the deployment process to be further automated in
PaaS environments and to facilitate ease-of-use.
Resource definitions (for example, the DataSource definition
introduced in Java EE 6), allow an application to be deployed into the
cloud with more minimal administrative configuration, and can also
serve as "templates" for modifications and/or extensions to meet the
deployment requirements of additional tenants.
The attached document is intended as a proposal for the first step in
this process, and addresses standardization for the configuration of
application-scoped resources that are required to be provided as
part of the platform.
We would appreciate if you would review this document in detail and
post your feedback. There are a number of issues flagged in the text,
including open issues that impact on the next steps that we would
pursue in extending such configuration support to multiple tenants.
thanks,
-Linda
<ResourceConfiguration.pdf>