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

[Yang Lei <yanglei@us.ibm.com>]

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

David 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

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

Mike 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:

• some of the annotations can apply onto the methods level, while component type definition does not have operational level any more.
• if we did generate the information into component type, we also need to generate the policysets to apply the policy...

<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

sca-javacaa-1.1-spec-cd02+Issue27.pdf

sca-javacaa-1.1-spec-cd02+issue27.doc