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.
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 :-)
"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.
"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
"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
"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?"
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>