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



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








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