Re: Validating PolicySet attachments in SCA Artifacts.
Hi Mike / Sebastien, I am reviving this discussion. As far as validation is concerned, the specs mentions about errors to be flagged if a policyset happens to be attached directly to an element to which it does not apply. I am perceiving this a having to 'validate' the SCDL - am I missing a view here ? To clarify a bit on the validation that exists presently, I do not attempt this validation against every element in the SCDL. I just do it for implementation and binding elements alone since they are the ones to which policies eventually apply. Virutally this come to simply verifying if intents and policysets directly attached to a binding or implementation element apply to the element in question and would like to flag errors if they don't apply. For all others that have been inherited from ancestors, I discard if they don't apply and aggregate it over the implementation or binding if they do apply. So there is still this bit of validation to be done and am yet to figure out a clean way to do this from the CompostieBuilder since at that point I don't have access to the SCDL fragments against which I should be running the xpath specified in 'appliesTo' Thoughts ? Thanks - Venkat On 8/20/07, Mike Edwards <[EMAIL PROTECTED]> wrote: > > Folks, > > Jean-Sebastien Delfino wrote: > > > > I would be surprised if impl="axis" was actually in the SCDL. Instead > > I'd imagine that impl="axis" would be a characteristic of a particular > > implementation of , not exposed to app developers but used > > by the policy framework to either select that axis-based implementation > > over another one when it sees that policy, or validate that the > > implementation in use in your runtime configuration can > > actually apply the requested policy. > > > > So basically, an SCDL-only based approach may not work, and I'd suggest > > to seek clarification from the SCA spec workgroup before going down that > > route. > > > > Nope, the spec intention is only to "validate" against the SCDL - > nothing else is involved. > > Really "validation" isn't what's going on here. Those @appliesTo > attributes are used to say what kind of element the PolicySet is > designed for. It is really simply a way of rejecting PolicySets not > designed for the element you're processing. > > The example involving @impl="axis" is actually a poor one. It assumes > that is extended with an attribute @impl, which then > has some range of values which reflect the available implementations of > binding.ws - "axis" being one of them. But this attribute would have > to be in the SCDL, for sure. > > What you do have to know is that when you are processing some element > that can have intents / policySets applied, then both those on the > element AND those in ancestor elements form a set which you have to scan > in order to pick out the right one(s). So, you look upwards from the > current place and pick out those that apply. XPath is used since not > only the element itself can control whether to use the PolicySet, but > also its attributes. > > The process is not so simple, I would certainly agree, but validation is > not the issue - it's a "simple" case of selection that is going on here. > > Now, if I can help with more specific points of the algorithm, I'm happy > to try to deal with them in other emails > > > Yours, Mike. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Validating PolicySet attachments in SCA Artifacts.
Folks, Jean-Sebastien Delfino wrote: I would be surprised if impl="axis" was actually in the SCDL. Instead I'd imagine that impl="axis" would be a characteristic of a particular implementation of , not exposed to app developers but used by the policy framework to either select that axis-based implementation over another one when it sees that policy, or validate that the implementation in use in your runtime configuration can actually apply the requested policy. So basically, an SCDL-only based approach may not work, and I'd suggest to seek clarification from the SCA spec workgroup before going down that route. Nope, the spec intention is only to "validate" against the SCDL - nothing else is involved. Really "validation" isn't what's going on here. Those @appliesTo attributes are used to say what kind of element the PolicySet is designed for. It is really simply a way of rejecting PolicySets not designed for the element you're processing. The example involving @impl="axis" is actually a poor one. It assumes that is extended with an attribute @impl, which then has some range of values which reflect the available implementations of binding.ws - "axis" being one of them. But this attribute would have to be in the SCDL, for sure. What you do have to know is that when you are processing some element that can have intents / policySets applied, then both those on the element AND those in ancestor elements form a set which you have to scan in order to pick out the right one(s). So, you look upwards from the current place and pick out those that apply. XPath is used since not only the element itself can control whether to use the PolicySet, but also its attributes. The process is not so simple, I would certainly agree, but validation is not the issue - it's a "simple" case of selection that is going on here. Now, if I can help with more specific points of the algorithm, I'm happy to try to deal with them in other emails Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating PolicySet attachments in SCA Artifacts.
Venkata Krishnan wrote: Hi Sebastien, Yes its quite bizzare and thats probably to do with how I am seeing a way out. Here it is... - A policyset has this 'appliesTo' attribute that is an xpath expression that should be evaluated against the scdl fragment which is parent element to a binding or implementation element. If the result of the evaluation includes the binding or implementation then the policyset is applicable to that binding or impl. - Having said that, its now a question of when this validation is to be done. Since we need a complete PolicySet information that will include the 'appliesTo' attribute as well, this is something that we have to do post-resolve which I think is the build phase. - Now during the build phase, we have the binding instance and from it we get the attached policyset (which is fully resolved) and from within that we get the appliesTo attribute. But what we don't have is the scdl fragment over which the xpath is to be evaluated i.e. the parent element of the binding which is a composite service / reference or a component service or reference So thats the problem is about get hold of this scdl fragment. OK I think I get it now :) If I understand correctly what you're suggesting: - We need to validate the Xpath expression in the PolicySet.appliesTo attribute, for example means that we'll have to check that it's only applied to Web Service bindings (in XML ). - This can only be done once all policy declarations have been combined / overriden / aggregated etc. in the assembly "build" phase. - You're thinking about evaluating the Xpath expression against the SCDL representing the binding and the polices applied to it, and that's why you're thinking about using the ArtifactProcessor write() methods to produce that SCDL, then parse it back and give it to XPath... If this is correct, then I have two comments: - It is not clear to me that the intent of the spec is to evaluate the XPath expression only against the SCDL. It says it, but it also seems to contradict that statement in one of the samples, with [EMAIL PROTECTED] I would be surprised if impl="axis" was actually in the SCDL. Instead I'd imagine that impl="axis" would be a characteristic of a particular implementation of , not exposed to app developers but used by the policy framework to either select that axis-based implementation over another one when it sees that policy, or validate that the implementation in use in your runtime configuration can actually apply the requested policy. So basically, an SCDL-only based approach may not work, and I'd suggest to seek clarification from the SCA spec workgroup before going down that route. - The other comment is that this kind of validation is great... in a tool, but I'm not sure that we need to perform all of it in the runtime, specially if it means, read XML + combine policies + write XML back + parse it back + Evaluate XPath on it... Do we really want to do all that at application startup time?? Maybe we could check with the Eclipse SOA Tooling Platform project what kind of Policy validation they're planning to do in the tooling? Hope this helps... Thanks - Venkat On 8/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Venkata Krishnan wrote: Hi, The PolicyFwk specs mentions that when checking out the applicability of a PolicySet over a binding or implementation, an xpath expression specified in the 'appliesTo' attribute of the PolicySet Defn, should be run against the parent element of the binding or implementation. Since this validation is done during the build phase, I am a bit lost of how I could get hold of the scdl fragment of the parent element of the binding or implementation. One option I have in mind for this, is to split up the 'write' method in the CompositeProcessor into smaller methods such as writeComponent or writeComponentService and so on. Then its a question of invoking one of these methods from the build phase. But the problems I see with this are : - - making the CompositeProcessor instance available to the CompositeConfigurationBuilderImpl which could probably be done during construction of CompositeConfigurationBuilderImpl - the services or referneces or components that we might have at the build phase may not quite reflect exactly what was in the scdl as there is quite a bit of reconciliations and normalizations that they undergo. But for the current context, it should not matter much. Thoughts ? Thanks - Venkat I'm trying to to understand the issue, but I must be missing something, could you please explain how "validating a PolicySet in the build phase" could lead to "refactoring assembly XML write methods". We're not writing anything when the runtime starts, so I'm a little lost... Thanks -- Jean-Sebastien --
Re: Validating PolicySet attachments in SCA Artifacts.
Hi Sebastien, Yes its quite bizzare and thats probably to do with how I am seeing a way out. Here it is... - A policyset has this 'appliesTo' attribute that is an xpath expression that should be evaluated against the scdl fragment which is parent element to a binding or implementation element. If the result of the evaluation includes the binding or implementation then the policyset is applicable to that binding or impl. - Having said that, its now a question of when this validation is to be done. Since we need a complete PolicySet information that will include the 'appliesTo' attribute as well, this is something that we have to do post-resolve which I think is the build phase. - Now during the build phase, we have the binding instance and from it we get the attached policyset (which is fully resolved) and from within that we get the appliesTo attribute. But what we don't have is the scdl fragment over which the xpath is to be evaluated i.e. the parent element of the binding which is a composite service / reference or a component service or reference So thats the problem is about get hold of this scdl fragment. Thanks - Venkat On 8/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Venkata Krishnan wrote: > > Hi, > > > > The PolicyFwk specs mentions that when checking out the applicability of > a > > PolicySet over a binding or implementation, an xpath expression > specified in > > the 'appliesTo' attribute of the PolicySet Defn, should be run against > the > > parent element of the binding or implementation. Since this validation > is > > done during the build phase, I am a bit lost of how I could get hold of > the > > scdl fragment of the parent element of the binding or implementation. > > > > One option I have in mind for this, is to split up the 'write' method in > the > > CompositeProcessor into smaller methods such as writeComponent or > > writeComponentService and so on. Then its a question of invoking one of > > these methods from the build phase. But the problems I see with this > are : > > - > > - making the CompositeProcessor instance available to the > > CompositeConfigurationBuilderImpl which could probably be done during > > construction of CompositeConfigurationBuilderImpl > > - the services or referneces or components that we might have at the > build > > phase may not quite reflect exactly what was in the scdl as there is > quite a > > bit of reconciliations and normalizations that they undergo. But for > the > > current context, it should not matter much. > > > > Thoughts ? > > > > Thanks > > > > - Venkat > > > > > > I'm trying to to understand the issue, but I must be missing something, > could you please explain how "validating a PolicySet in the build phase" > could lead to "refactoring assembly XML write methods". We're not > writing anything when the runtime starts, so I'm a little lost... > > Thanks > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Validating PolicySet attachments in SCA Artifacts.
Venkata Krishnan wrote: Hi, The PolicyFwk specs mentions that when checking out the applicability of a PolicySet over a binding or implementation, an xpath expression specified in the 'appliesTo' attribute of the PolicySet Defn, should be run against the parent element of the binding or implementation. Since this validation is done during the build phase, I am a bit lost of how I could get hold of the scdl fragment of the parent element of the binding or implementation. One option I have in mind for this, is to split up the 'write' method in the CompositeProcessor into smaller methods such as writeComponent or writeComponentService and so on. Then its a question of invoking one of these methods from the build phase. But the problems I see with this are : - - making the CompositeProcessor instance available to the CompositeConfigurationBuilderImpl which could probably be done during construction of CompositeConfigurationBuilderImpl - the services or referneces or components that we might have at the build phase may not quite reflect exactly what was in the scdl as there is quite a bit of reconciliations and normalizations that they undergo. But for the current context, it should not matter much. Thoughts ? Thanks - Venkat I'm trying to to understand the issue, but I must be missing something, could you please explain how "validating a PolicySet in the build phase" could lead to "refactoring assembly XML write methods". We're not writing anything when the runtime starts, so I'm a little lost... Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating PolicySet attachments in SCA Artifacts.
Hi, I just realized that passing CompositeProcessor to the Builder is not possible since that results in a circular dependency. Maybe we could consider moving the 'write' functions to an appropriate 'Util' class. Also, I might need the xpath evaluate method in the PropertyUtil class of the assembly module. This method is private now. I am intending it to relax this to make it visible within package. - Venkat On 8/17/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Hi, > > The PolicyFwk specs mentions that when checking out the applicability of a > PolicySet over a binding or implementation, an xpath expression specified in > the 'appliesTo' attribute of the PolicySet Defn, should be run against the > parent element of the binding or implementation. Since this validation is > done during the build phase, I am a bit lost of how I could get hold of the > scdl fragment of the parent element of the binding or implementation. > > One option I have in mind for this, is to split up the 'write' method in > the CompositeProcessor into smaller methods such as writeComponent or > writeComponentService and so on. Then its a question of invoking one of > these methods from the build phase. But the problems I see with this are : > - > - making the CompositeProcessor instance available to the > CompositeConfigurationBuilderImpl which could probably be done during > construction of CompositeConfigurationBuilderImpl > - the services or referneces or components that we might have at the build > phase may not quite reflect exactly what was in the scdl as there is quite a > bit of reconciliations and normalizations that they undergo. But for the > current context, it should not matter much. > > Thoughts ? > > Thanks > > - Venkat >
Validating PolicySet attachments in SCA Artifacts.
Hi, The PolicyFwk specs mentions that when checking out the applicability of a PolicySet over a binding or implementation, an xpath expression specified in the 'appliesTo' attribute of the PolicySet Defn, should be run against the parent element of the binding or implementation. Since this validation is done during the build phase, I am a bit lost of how I could get hold of the scdl fragment of the parent element of the binding or implementation. One option I have in mind for this, is to split up the 'write' method in the CompositeProcessor into smaller methods such as writeComponent or writeComponentService and so on. Then its a question of invoking one of these methods from the build phase. But the problems I see with this are : - - making the CompositeProcessor instance available to the CompositeConfigurationBuilderImpl which could probably be done during construction of CompositeConfigurationBuilderImpl - the services or referneces or components that we might have at the build phase may not quite reflect exactly what was in the scdl as there is quite a bit of reconciliations and normalizations that they undergo. But for the current context, it should not matter much. Thoughts ? Thanks - Venkat