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
