[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] ISSUE 27 - Security Annotations in generated ComponentType - proposal comments
Mike,
There seem to be some changes in Yang's proposal that don't relate
directly to the issue as described in JIRA (e.g., moving the
definitions for @Authentication, @Confidentiality, @Integrity,
@PolicySets, @Qualifier, @Requires from chapter 10 to chapter 8).
Up till now I hadn't seen this as a problem because when Mike R
raised issue 27 originally, he described it a placeholder for
various problems with chapter 10.
If we are going to separate the issues as you suggest, and use
issue 27 only to address what is specifically mentioned in the JIRA,
then I think the only changes in Yang's document that should be
accepted for issue 27 would be those in sections 8.25, 10.6.2 and
10.6.2.1. This would mean that only my review comment number 18
would be relevant to this issue.
If we are going to go beyond the issue 27 JIRA description by using
it to move the other material from chapter 10 to chapter 8, I think
we also need to consider my comments numbers 1, 2, 3 and 4.
Either approach is fine with me, as long as we are consistent.
Simon
Mike Edwards wrote:
>
> Folks,
>
> Most but not all of the comments below don't relate to the changes
> proposed for Issue 27, but are problems
> related to the pre-existing material in the Java CAA spec (CD02). They
> are valid points but I don't think it helps
> to lump them in with comment about the specifics of Issue 27. I'd
> prefer a separate issue to deal with problems
> relating to the CD02 Java CAA spec and its handling of the Policy
> annotations for Java.
>
> If anyone disagrees with me, shout load - and soon - otherwise I'll
> raise the new issue and build a proposal to
> fix the problems.
>
>
> 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: Simon Nash <oasis@cjnash.com>
> To: sca-j@lists.oasis-open.org
> Date: 30/01/2009 19:41
> Subject: Re: [sca-j] ISSUE 27 - Security Annotations in generated
> Component Type - proposal comments
>
>
> ------------------------------------------------------------------------
>
>
>
> I reviewed this document and I have the following comments:
>
> 1. The definition of @Intent is missing from chapter 8.
>
> 2. Section 8.2 should not define the Constants interface and
> the SCA_PREFIX constant. These should be defined in a
> separate section.
>
> 3. In section 8.19, the description of @Qualifier is hard to
> understand. It says "The @Qualifier annotation can be applied
> to an attribute as an @Intent annotation to indicate the
> attribute provides qualifiers for the intent." A clearer
> description would be "The @Qualifier annotation can be
> applied to an attribute of an intent annotation definition
> to indicate the attribute provides qualifiers for the intent.
> The annotation definition containing the @Qualifier annotation
> MUST be annotated with @Intent."
>
> 4. The forward references from chapter 8 to chapter 10 make it
> hard to understand the chapter 8 descriptions of these annotations
> without reading chapter 10 first. Could we move chapter 10 to
> a new position between chapters 6 and 7?
>
> 5. In section 10.1, the example classes should not be declared
> in the package org.oasisopen.sca.annotations. Instead, they
> should import the @Requires and @Reference annotation
> definitions from that package.
>
> 6. The formal syntax for the @Requires annotation is specified as
> @Requires( “qualifiedIntent” | {“qualifiedIntent” [,
> “qualifiedIntent”]}
> which would only allow up to two intent strings to be specified.
> I believe this should say
> @Requires( “qualifiedIntent” | {“qualifiedIntent” [,
> “qualifiedIntent”]...}
>
> 7. The formal syntax for qualifiedIntent also seems more
> restrictive than it should be. It is given as
> qualifiedIntent ::= QName | QName.qualifier |
> QName.qualifier1.qualifier2
> which would only allow up to two levels of qualification.
> I believe this should say
> qualifiedIntent ::= QName[.qualifier]...
>
> 8. Similar to comment 6 above, the definition of qualifiers in
> section 10.2 should be
> qualifiers ::= ”qualifier” | {“qualifier” [, “qualifier”]... }
>
> 9. In section 10.2, the definition of qualifier is
> qualifier ::= NCName | NCName/qualifier
> which uses "/" as a separator. This is inconsistent with
> section 10.1, which used "." as a separator.
>
> 10. In section 10.2.1, the last sentence of the second paragraph
> is misleading. It says "These String constants are then
> available for use with the @Requires annotation and it should
> also be possible to use one or more of them as parameters to
> the @Intent annotation." In fact they cannot be used as
> parameters to the @Intent annotation, but they are available
> for use as parameters to the specific intent annotation that
> defines them.
>
> 11. Section 10.3 says that intent annotations can be used on a class,
> an interface, a method or a field. However, the definitions in
> chapter 8 say that these annotations can also be used on a parameter.
> The bulleted list in section 10.3 should include a bullet for
> "constructor parameter".
>
> 12. In section 10.3, the second last paragraph says that "If an
> annotation is specified at both the class/interface level and
> the method or field level, then the method or field level
> annotation completely overrides the class level annotation of
> the same type." In this, the word "type" is not very precise.
> It would be clearer to say "... the same base intent name."
> using the precise terminology of section 10.1.
>
> 13. There are a number of problems with Example 2b in section 10.3.1.
> a. The <service> definitions for HelloService and HelloChildService
> should be inside the <component> definitions for
> HelloServiceComponent and HelloChildServiceComponent, not
> free-floating inside the <composite> definition.
> b. The <operation> definitions should not be within <component>
> defintions. I believe the intention may have been to put them
> within <service> definitions.
> c. <operation> elements within <service> definitions were
> recently removed from the Assembly spec because of a decision
> by the Policy TC.
> d. The contents of the <operation> definitions don't seem
> consistent. For the operations in HelloService, the <operation>
> elements provide fully explicit definitions of the intents that
> apply to the operations. However, for the operations in
> HelloChildService, some of the <operation> elements only provide
> partial definitions of the intents that apply. Specifically,
> "hello" specifies "confidentiality/transport" but does not
> specify "authentication" and "integrity/transport".
> "helloWorld" specifies "authentication" but does not
> specify "integrity/transport" or "confidentiality/message"
>
> 14. Section 10.4 refers to a component type document associated
> with a Java class. We no longer have component type documents
> for <implementation.java>. Should this reference be removed?
>
> 15. Section 10.4. The general rule for intents is not that they
> represent fundamental requirements of an implementation, but
> that they represents restrictions that can't be relaxed. So
> an intent specified by an implementation could be overriden by
> some other intent that is more restrictive, but not by some
> other intent that is less restrictive.
>
> 16. Section 10.5 says that @PolicySets can be used on a class,
> an interface, a method or a field. However, section 8.17 says
> that this annotation can also be used on a parameter. The
> bulleted list in section 10.5 should include a bullet for
> "constructor parameter".
>
> 17. In the example in section 10.6.1, the Java interface declarations
> use dot-qualified names, which isn't correct Java syntax. Also,
> these names use a "service." prefix which should be changed to
> "services." so that it is consistent with the code following
> these delarations.
>
> 18. In section 10.6.2, the PermitAll and DenyAll bullets have some
> added text that is bulleted but shouldn't be.
>
> 19. In section 10.6.2.1, should the fromUSDollarToCurrency method
> be declared in the AccountService interface? It currently
> only appears in the implementation class.
>
> Simon
>
> Yang Lei wrote:
> > 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
> <http://swgcomm.bluehost.ibm.com/siteFiles/labs.html?location=SEUS&type=cluster>
>
> >
> <http://swgcomm.bluehost.ibm.com/siteFiles/labs.html?location=SEUS&type=cluster
> <http://swgcomm.bluehost.ibm.com/siteFiles/labs.html?location=SEUS&type=cluster>>
> > WebSphere Lab Advocate for Royal Bank of Scotland
> >
> >
> > Inactive hide details for David Booz/Poughkeepsie/IBM@IBMUSDavid
> > 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
> >
> > Inactive hide details for Mike Edwards ---01/23/2009 06:20:02 AM---Dave,
> > 1) What I am suggesting is that IF a developer wants 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
> >
> > 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:
> >
> > # 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_
>
> >
> <http://swgcomm.bluehost.ibm.com/siteFiles/labs.html?location=SEUS&type=cluster
> <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/
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
> ---------------------------------------------------------------------
> 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/
>
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]