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:  

From:
Yang Lei <>

To:
David Booz <>

Cc:


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: 

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



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:

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

To:

"OASIS Java" <>

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:  

From: 
David Booz <>

To: 
 

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:

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

To: 

 

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:  

From: 
Yang Lei <>

To: 
 

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: 

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