OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type -proposal comments



Yang Lei,

We have a problem here in that our annotations in SCA cover both those related to JSR 250 and ALSO those related to JSR 181.

These two conflict.  JSR 250 indicates that interface-attached annotations "don't count".  JSR 181 annotations on interfaces most certainly
do count.

I'm wondering whether we should do as Dave originally proposed.  That for implementation annotations, they can be attached to the
implementation and NOT be reflected in the component type, but only get read by the runtime container.  The trouble with this approach is
that it isn't clear how implementation intents attached to the using  <component/> relate to those in the implementation.  These can clearly
conflict (in principle) which means that logically they are attached to the componentType of the implementation.  So JSR 250 rules could
apply to the implementation intents, but I'm not sure how to describe the relation of annotations on the implementation to equivalent
intents on the <component/>.

For interaction annotations, I think it is easy to argue that they must apply to the interface - they are part of the contract between client and
service provider.  JSR 250 rules cannot apply in this case.


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com



From: Yang Lei <yanglei@us.ibm.com>
To: David Booz <booz@us.ibm.com>
Cc: sca-j@lists.oasis-open.org
Date: 26/01/2009 19:23
Subject: Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type - proposal comments





I have a couple of questions if we will require interface annotations for these implementation policy:

1. JSR 250 2.1 "2.1General Guidelines for Inheritance of Annotations"
states that

3. The interfaces implemented by a class never contribute annotations to the class itself or any of its members.


SCAJ 10.3.1
Inheritance And Annotation
states that

The inheritance rules for annotations are consistent with the common annotation specification, JSR 250.



If we do introduce inheritance rules that is different from JSR250, what our inheritance rule is , e.g. do we allow coexistence of both annotation on interface and class, do they have to be the same? If it is not, who takes precedents

2. From semantic perspective, this interface annotation worries me, what happens if different implementation of the same interfaces needs to have different implementation policy? Does it mean developer needs to achieve it through new interface?


Due to the above issue, I would prefer the <operation/> approach than the interface annotation to make things simple. Then the only remaining issue needs to be resolved is : do we need to describe the naming convention for the generated PolicySet when the annotation having parameters , e.g. @RunAs, @RolesAllowed. Or we say it is vendor specific.

Here is the latest proposal on ISSUE 27 , changed on top of cd02.

(See attached file: sca-javacaa-1.1-spec-cd02+Issue27.pdf)(See attached file: sca-javacaa-1.1-spec-cd02+issue27.doc)



Please let me know if you have problem reviewing it. I did save the word version after turning on the "Review Pane", I can see most of the changes are mine except some "Formatted Bullets and Numbering" from Mike due to certain sections are added.


Thank you.

Regards,

Yang Lei

WebSphere SCA Feature Pack Development -- SCA Architect
Phone: (919) 543 8887 T/L 441-8887
e-mail: yanglei@us.ibm.com

SCA Feature Pack:
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
RTP Technical Vitality:
http://swgcomm.bluehost.ibm.com/siteFiles/labs.html?location=SEUS&type=cluster
WebSphere Lab Advocate for Royal Bank of Scotland


Inactive hide details for David Booz/Poughkeepsie/IBM@IBMUSDavid Booz/Poughkeepsie/IBM@IBMUS

David Booz/Poughkeepsie/IBM@IBMUS

01/25/2009 05:10 PM



To

sca-j@lists.oasis-open.org

cc

Subject

Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type - proposal comments




I'm ok with the idea of "encouraging" interface annotation. With the external attachment mechanism, it should also be possible to avoid modification of the interface (at least for WSDL anyway) if necessary.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Inactive hide details for Mike Edwards ---01/23/2009 06:20:02 AM---Dave, 1)  What I am suggesting is that IF a developer wants Mike Edwards ---01/23/2009 06:20:02 AM---Dave, 1) What I am suggesting is that IF a developer wants to have Policy

From:

Mike Edwards <mike_edwards@uk.ibm.com>

To:

"OASIS Java" <sca-j@lists.oasis-open.org>

Date:

01/23/2009 06:20 AM

Subject:

Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type - proposal comments






Dave,


1) What I am suggesting is that IF a developer wants to have Policy annotations on a method or on a parameter in the method, then the way

they have to do this is to take the interface file for the service or reference and place the annotations into that file. If they can't change that

file, then tough, they can't have the policy annotations on the method or parameter.


Once the Policy metadata is placed onto the interface artifact like this, then it CAN be part of the ComponentType, since the ComponentType

does directly reference the interface artifact. I am sure that we will have to look into the mapping of Policy annotations from Java interfaces

to WSDL interfaces when we do this, but I hope that this is a "simple" extension of the JAX-WS mapping rules.


2) I have resisted the idea that features of the implementation which affect the overall Assembly do not appear in the ComponentType.

If you decide that some aspect of the implementation artifact, which do affect the Assembly layer, are transmitted through some other

means, then I think that the "other means" has to be known to the Assembly layer. Otherwise how can the Assembly layer make sense

of the implementation. It is NOT enough for the Java runtime to know these things, since the other components around the implementation

in question may not be Java. Consider the case where this implementation offers a service that is used by a BPEL process...


My proposal is to force the developer to attach the Policy annotations to the interface file in this case. If this is not acceptable, then maybe

we shall have to reconsider the removal of <operation/> elements - or else think of a new mechanism to represent method and parameter

level metadata.


Yours, Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From: David Booz <booz@us.ibm.com>
To: sca-j@lists.oasis-open.org
Date: 22/01/2009 15:59
Subject: Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type - proposal comments






On point two, since there is no way to reflect an annotation on a method in the CT (because there's no method element in the CT), are you suggesting that somehow the interface is modified? I don't understand how that works, esp. if the interface is an artifact that was provided by the developer.

I don't think it's true that annotations MUST show up in the CT. The Java C&I is perfectly within its rights to describe how these annotations are to be handled by the SCA Java runtime. It's certainly preferrable if these things were to be present, but I don't see it as required, and given that it's impossible to do so, we're stuck.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com


Inactive hide details for Mike Edwards ---01/22/2009 10:01:29 AM---Yang Lei, Thanks for producing this proposal.   In general iMike Edwards ---01/22/2009 10:01:29 AM---Yang Lei, Thanks for producing this proposal. In general it looks very good.

From:

Mike Edwards <mike_edwards@uk.ibm.com>

To:

sca-j@lists.oasis-open.org

Date:

01/22/2009 10:01 AM

Subject:

Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type - proposal comments







Yang Lei,


Thanks for producing this proposal. In general it looks very good.


Some comments inline as
<mje>...</mje>

Yours, Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From: Yang Lei <yanglei@us.ibm.com>
To: sca-j@lists.oasis-open.org
Date: 21/01/2009 22:16
Subject: [sca-j] ISSUE 27 - Security Annotations in generated Component Type - proposal







Here is the proposal for issue 27:
http://www.osoa.org/jira/browse/JAVA-27.

The highlights of the proposal:

1. Instead of defining SCA security implementation policy annotations, point to JSR 250 security annotations

<mje>

I'm OK with this proposal.


I think that there is a need to spell out the mapping of the annotations to the intents declared by the

Policy spec. It may seem obvious, but to be normative, you have to state it explicitly.


This should be in 10.6.2 I think.

</mje>


2. Not generating componentTypes for the above annotations, due to two major reasons:
<mje>
I don't agree with this. If they dont turn up in the componentType, then in effect they are useless - or else you are proposing

a second mechanism for transmitting information from the implementation to the using <component/>


Any annotations on method or class level MUST turn up in the component type.


Annotations below the method level MUST be placed on the interface class. The annotations then turn up in the componentType

as part of the interface declaration in the componentType.


I think that this approach works...

</mje>


3. Also added are the other annotations that is missing from section 8, related to 10.3 Application intent annotations:

@Authentication
@Confidentiality
@Integrity
@Intent
@PolicySets
@Qualifier
@Requires

All the changes are under 8.2, 8.5, 8.15, 8.19, 8.22, 8.25, 10.6.2, 10.6.2.1.

<mje>excellent</mje>


(See attached file: sca-javacaa-1.1-spec-cd01-rev4a-Issue27.doc)(See attached file: sca-javacaa-1.1-spec-cd01-rev4a-Issue27.pdf)



Thanks Dave for the review and comments earlier.

Regards,

Yang Lei

WebSphere SCA Feature Pack Development -- SCA Architect
Phone: (919) 543 8887 T/L 441-8887
e-mail: yanglei@us.ibm.com

SCA Feature Pack:
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
RTP Technical Vitality:
http://swgcomm.bluehost.ibm.com/siteFiles/labs.html?location=SEUS&type=cluster
WebSphere Lab Advocate for Royal Bank of Scotland
[attachment "sca-javacaa-1.1-spec-cd01-rev4a-Issue27.doc" deleted by Mike Edwards/UK/IBM]
[attachment "sca-javacaa-1.1-spec-cd01-rev4a-Issue27.pdf" deleted by Mike Edwards/UK/IBM] ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



[attachment "pic24523.gif" deleted by Mike Edwards/UK/IBM] [attachment "sca-javacaa-1.1-spec-cd02+Issue27.pdf" deleted by Mike Edwards/UK/IBM]
[attachment "sca-javacaa-1.1-spec-cd02+issue27.doc" deleted by Mike Edwards/UK/IBM] ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]