Hi Reza,
Thanks for the feedback. Some comments and questions from me below....
On 7/27/2011 3:29 PM, Reza Rahman wrote:
> Linda,
>
> Looks good overall.
>
> A few questions:
> * Should more configuration defaults be standardized? Some of what is now required could simply be defaulted. It could
> be problematic if some of the values defaulted to "null" instead of an empty string.
That is a question that we would really like feedback from you and the other experts on.
What other defaults do you think should be standardized on?
I'm not following your comment about null vs empty string though. Could you explain further?
> * Should we standardize some default resources that an application server must provide?
Java EE currently standardizes on database, JMS, and mail as resources that must be provided.
> * Since JMS pluggability is not well defined, how portable is the proposed JMS resource configuration really?
We believe that JCA covers the issue of JMS pluggability. An application could potentially
bundle a JMS resource adapter and reference it in the configuration information instead of
relying on the default JMS implementation bundled with the appserver.
> * The names <jms-resource>, <jms-admin-object> and <mail-resource> seem overly abstract/ivory-tower-ish. Is there a
> reason for that - it might confuse the average joe developer? Why not simply use <jms-connection-factory>,
> <jms-destination> and <mail-session>?
>
Sure! I needed a strawman element name to convey the semantic intent, but we are very open
to suggestions for better names. We wanted first of all to get feedback on the form in which
this configuration metadata should be specified. Do your suggestions mean that you otherwise
agree with the form in the proposal?
> Comments on your notes:
> * What happens upon failure to satisfy the requested resources? Does the application fail to deploy or is there run-time
> failure?
> - There should be a deployment failure - basically the "fail fast" principle.
> * Should any of the following attributes be standardized, or should they be left as properties?
> - They should be standardized.
All of them? Or which ones? Are there any others?
> * Do we need any way to distinguish XA from non-XA if transactional?
> - I don't think we do. If so, it should be a separate attribute.
> * Should this creation be limited to cloud environments?
> - No.
> * What format should the specification of an application’s resource configuration dependencies take, particularly when
> the application is intended for multi-tenant Resource Configuration July 26, 2011 3:20 pm 11 use?
> - Not sure I understand?
Do you like the XML illustrated in the strawman? It could plausibly be expanded with elements
or attributes that would indicate which information could / should / or must not be modified
when the application is deployed for another tenant. Alternatively, what would you suggest?
> * What means should we use to indicate sharing of resources?
> * We will need a means to specify which attributes of the resource definition must be modified by a tenant, which
> attributes of the resource definition must not be
> modified when the application is deployed for a tenant, and which attributes of the resource definition may be modified
> by a tenant.
> - Probably just more attributes? Difficult to tell without actually seeing the rest of the multi-tenancy features.
>
> Hope it helps.
>
Yes -- thank you!
regards,
-Linda
> Cheers,
> Reza
>
>
> On 7/26/2011 6:42 PM, 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
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG -www.avg.com
>> Version: 10.0.1390 / Virus Database: 1518/3789 - Release Date: 07/26/11
>
>