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

[Mike Edwards <mike_edwards@uk.ibm.com>]

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


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

[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