Re: Implementation Policies
Folks, Perhaps this calls for something more general which will support other use cases. How about some form of management interfaces which will allow an application to get information about entities inside the runtime in a controlled fashion? So the idea would be to get some contribution(s) running in the SCA runtime and then have a client application issue queries about what is actually running, which would include information such as Venkat requires to check the intents and policySets applying to some componenet? I realize that this is no trivial capability to add to the system, but it will satisfy a number of goals in the longer run. Yours, Mike. Venkata Krishnan wrote: Hi Simon, What I need is a hook into the runtime startup and more specifically after the build phase so that I can analyse the built composite to see if it has the correctly computed intents and policysets. Is that something we can do in the node-runtime? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation Policies
I took Venkat's post as expressing a need for some kind of validation that would be performed before the composite is allowed to be used by the runtime. This seems to preclude a solution based on management interfaces, as these would presumably not come into play until the composite is actually running. Managemant interfaces would be good for other reasons, but it's not clear to me that they can be used for this purpose. Simon Mike Edwards wrote: Folks, Perhaps this calls for something more general which will support other use cases. How about some form of management interfaces which will allow an application to get information about entities inside the runtime in a controlled fashion? So the idea would be to get some contribution(s) running in the SCA runtime and then have a client application issue queries about what is actually running, which would include information such as Venkat requires to check the intents and policySets applying to some componenet? I realize that this is no trivial capability to add to the system, but it will satisfy a number of goals in the longer run. Yours, Mike. Venkata Krishnan wrote: Hi Simon, What I need is a hook into the runtime startup and more specifically after the build phase so that I can analyse the built composite to see if it has the correctly computed intents and policysets. Is that something we can do in the node-runtime? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation Policies
Hi, I've made some additions to the policy annotations processing. I have posted the rules of interpretation on another thread. I've also now added the code to pick up policies specified in the componentType. Ideally I would have liked to have a testcase to verify this and it seems like I'd have to do a bit more than a unit test since I must rope in the implementation.java extension modules for the testing. I could not find much success in getting around with a iTest too. Here is what I wished to do... - load the composite, read it up with - resolve the composite and all of its constituents - build the composite - test if the composite's Java implementation component has correnctly computed policies. Trying to do this the unit test way brings in cyclic dependencies and with the iTest there seems to the trouble of 'almost' rewriting the host-embeded runtime. So I just resorted to debugging for verification. Any suggestions on how I could pull this off with a test case ? Should be embed event-listener-callback along the processing so that interested listeners are called to take their actions after each phase like th read phase, resolve phase, build phase and so on. Makes sense ? Thanks - Venkat On Dec 15, 2007 9:20 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks for looking up :). Yes, I don't think I have picked up policies specified for an implementation in the ComponentType. I suppose the componenType will include the ones that have been specified using annotations. I will give this a check. Thanks - Venkat On Dec 15, 2007 2:19 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Sorry, I should have said 'resolution phase'. Its all done in the CompositeProcessor.resolve method. Looks good. Unless I missed it, I think you're missing code to add to the component policies the policies coming from a shared implementation, for example policies specified as annotations in a Java implementation class. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation Policies
Hi Venkat Why do you say you had to almost rewrite the host-embeded runtime to make a itest work in this scenario? Is the something we can do with the node runtime to help you out here? Simon On Dec 23, 2007 4:45 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I've made some additions to the policy annotations processing. I have posted the rules of interpretation on another thread. I've also now added the code to pick up policies specified in the componentType. Ideally I would have liked to have a testcase to verify this and it seems like I'd have to do a bit more than a unit test since I must rope in the implementation.java extension modules for the testing. I could not find much success in getting around with a iTest too. Here is what I wished to do... - load the composite, read it up with - resolve the composite and all of its constituents - build the composite - test if the composite's Java implementation component has correnctly computed policies. Trying to do this the unit test way brings in cyclic dependencies and with the iTest there seems to the trouble of 'almost' rewriting the host-embeded runtime. So I just resorted to debugging for verification. Any suggestions on how I could pull this off with a test case ? Should be embed event-listener-callback along the processing so that interested listeners are called to take their actions after each phase like th read phase, resolve phase, build phase and so on. Makes sense ? Thanks - Venkat On Dec 15, 2007 9:20 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks for looking up :). Yes, I don't think I have picked up policies specified for an implementation in the ComponentType. I suppose the componenType will include the ones that have been specified using annotations. I will give this a check. Thanks - Venkat On Dec 15, 2007 2:19 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Sorry, I should have said 'resolution phase'. Its all done in the CompositeProcessor.resolve method. Looks good. Unless I missed it, I think you're missing code to add to the component policies the policies coming from a shared implementation, for example policies specified as annotations in a Java implementation class. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation Policies
Hi Simon, What I need is a hook into the runtime startup and more specifically after the build phase so that I can analyse the built composite to see if it has the correctly computed intents and policysets. Is that something we can do in the node-runtime? Thanks - Venkat On Dec 23, 2007 10:58 PM, Simon Laws [EMAIL PROTECTED] wrote: Hi Venkat Why do you say you had to almost rewrite the host-embeded runtime to make a itest work in this scenario? Is the something we can do with the node runtime to help you out here? Simon On Dec 23, 2007 4:45 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I've made some additions to the policy annotations processing. I have posted the rules of interpretation on another thread. I've also now added the code to pick up policies specified in the componentType. Ideally I would have liked to have a testcase to verify this and it seems like I'd have to do a bit more than a unit test since I must rope in the implementation.java extension modules for the testing. I could not find much success in getting around with a iTest too. Here is what I wished to do... - load the composite, read it up with - resolve the composite and all of its constituents - build the composite - test if the composite's Java implementation component has correnctly computed policies. Trying to do this the unit test way brings in cyclic dependencies and with the iTest there seems to the trouble of 'almost' rewriting the host-embeded runtime. So I just resorted to debugging for verification. Any suggestions on how I could pull this off with a test case ? Should be embed event-listener-callback along the processing so that interested listeners are called to take their actions after each phase like th read phase, resolve phase, build phase and so on. Makes sense ? Thanks - Venkat On Dec 15, 2007 9:20 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks for looking up :). Yes, I don't think I have picked up policies specified for an implementation in the ComponentType. I suppose the componenType will include the ones that have been specified using annotations. I will give this a check. Thanks - Venkat On Dec 15, 2007 2:19 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Sorry, I should have said 'resolution phase'. Its all done in the CompositeProcessor.resolve method. Looks good. Unless I missed it, I think you're missing code to add to the component policies the policies coming from a shared implementation, for example policies specified as annotations in a Java implementation class. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation Policies
Thanks for looking up :). Yes, I don't think I have picked up policies specified for an implementation in the ComponentType. I suppose the componenType will include the ones that have been specified using annotations. I will give this a check. Thanks - Venkat On Dec 15, 2007 2:19 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Sorry, I should have said 'resolution phase'. Its all done in the CompositeProcessor.resolve method. Looks good. Unless I missed it, I think you're missing code to add to the component policies the policies coming from a shared implementation, for example policies specified as annotations in a Java implementation class. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation Policies
Venkata Krishnan wrote: Hi, I've tried another way out of this and it works... here is a jist of what I've done... - During the composite loading phase itself aggregate the policies into the child elements. This makes the component free to take over the implementation policies since it has already given away the policies that the child element should inherit. - Just before an Implementation is resolved, validate the policies that have been specified on the implementation. Upto the resolution point every component has its own implementation model instance. Its only after resolution that they might end up sharing an existing instance. So at this point the validity of policies specified on the implementation is checked and then copied over to the component. Can you point me to the class/method where you're doing that? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation Policies
Hi, Sorry, I should have said 'resolution phase'. Its all done in the CompositeProcessor.resolve method. Thanks - Venkat On Dec 13, 2007 6:06 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, I've tried another way out of this and it works... here is a jist of what I've done... - During the composite loading phase itself aggregate the policies into the child elements. This makes the component free to take over the implementation policies since it has already given away the policies that the child element should inherit. - Just before an Implementation is resolved, validate the policies that have been specified on the implementation. Upto the resolution point every component has its own implementation model instance. Its only after resolution that they might end up sharing an existing instance. So at this point the validity of policies specified on the implementation is checked and then copied over to the component. Can you point me to the class/method where you're doing that? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation Policies
Hi, I have put in a few more changes to get the support for policies on operations going without the hack that I had previously introduced to the ComponentImpl.getImplementation and setImplementation. I am continuing to use OperationsConfigurator and ConfiguredOperation interfaces as am yet to convince myself about holding 'operation' instances within 'Intent' instances ;-). Thanks - Venkat On Dec 8, 2007 11:39 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I've tried another way out of this and it works... here is a jist of what I've done... - During the composite loading phase itself aggregate the policies into the child elements. This makes the component free to take over the implementation policies since it has already given away the policies that the child element should inherit. - Just before an Implementation is resolved, validate the policies that have been specified on the implementation. Upto the resolution point every component has its own implementation model instance. Its only after resolution that they might end up sharing an existing instance. So at this point the validity of policies specified on the implementation is checked and then copied over to the component. - From then on wherever implemenation policies are to be computed the component's policies are used (since that is where we have now stored the implementation's policies) I've now got rid of the hacks and also cleaned up the policy computing code out of the CompositeWireBuilder. I am right now resolving some conflicts after an update I did just now... I shall check in this after that. Next I shall iron out the hack around support for policies in operations and then get back to the secure-bigbank scenario to move that further. Thanks - Venkat On Dec 6, 2007 3:20 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, First, thanks for the help. I am not so comfortable with having inside an intent or a policyset, a pointer to an assembly model artifact. I somehow see a one way dependency that goes from the assembly model to the policy model i.e. an assembly model artifact must know the policies attached to it, but a policy (intent or policyset) doesn't quite need to know where it is attached. The fact that a policy intent 'constrains' or a policyset 'appliesTo' a particular 'class' of assembly model artifacts is a different thing. I am trying another work around for this. Will let you folks know of it once I am sure it works for me locally and get your views. Thanks - Venkat On Dec 6, 2007 2:36 PM, Simon Laws [EMAIL PROTECTED] wrote: On Dec 5, 2007 11:04 PM, Raymond Feng [EMAIL PROTECTED] wrote: Would it help if the Intent/PolicySet has a pointer to the its attachpoint (i.e., where the intent/policy is declared)? Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, December 05, 2007 1:40 AM Subject: Implementation Policies Hi, To set the context its about specification of policies on implementation elements in a composite. Since we have implementation model instances being reused we have trouble with capturing what policies were set on an implementation under a specific Component. I have this going in the trunk but with a bit of a hack in ComponentImpl.getImplementation. Now am looking at cleaning that a bit and exploring options. One of the alternatives suggested earlier is to have the implementation policies stored in the component itself. But the problem is Component themselves can have policies specified over them which will have be inherited by the service, implementation and reference child elements within. One way of getting around this is to add up the component's policies to the services and references child elements right at the time of reading from the scdl. Then when the implementation child element is loaded we read its policies and store it into the component. This seems a good way out but bites during the build phase as follows :- - One of the things we do in the build phase is validating if policysets specified on an implementation element i.e. checking to see if a specified policyset does apply to the implementation type in question. The specs says that its ok if this validation fails for policysets that have been inherited (say from the composite or the component), but if this validation fails for a policyset directly specified for the element then its an error in defining the composite and it must be flagged. *
Re: Implementation Policies
Hi, I've tried another way out of this and it works... here is a jist of what I've done... - During the composite loading phase itself aggregate the policies into the child elements. This makes the component free to take over the implementation policies since it has already given away the policies that the child element should inherit. - Just before an Implementation is resolved, validate the policies that have been specified on the implementation. Upto the resolution point every component has its own implementation model instance. Its only after resolution that they might end up sharing an existing instance. So at this point the validity of policies specified on the implementation is checked and then copied over to the component. - From then on wherever implemenation policies are to be computed the component's policies are used (since that is where we have now stored the implementation's policies) I've now got rid of the hacks and also cleaned up the policy computing code out of the CompositeWireBuilder. I am right now resolving some conflicts after an update I did just now... I shall check in this after that. Next I shall iron out the hack around support for policies in operations and then get back to the secure-bigbank scenario to move that further. Thanks - Venkat On Dec 6, 2007 3:20 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, First, thanks for the help. I am not so comfortable with having inside an intent or a policyset, a pointer to an assembly model artifact. I somehow see a one way dependency that goes from the assembly model to the policy model i.e. an assembly model artifact must know the policies attached to it, but a policy (intent or policyset) doesn't quite need to know where it is attached. The fact that a policy intent 'constrains' or a policyset 'appliesTo' a particular 'class' of assembly model artifacts is a different thing. I am trying another work around for this. Will let you folks know of it once I am sure it works for me locally and get your views. Thanks - Venkat On Dec 6, 2007 2:36 PM, Simon Laws [EMAIL PROTECTED] wrote: On Dec 5, 2007 11:04 PM, Raymond Feng [EMAIL PROTECTED] wrote: Would it help if the Intent/PolicySet has a pointer to the its attachpoint (i.e., where the intent/policy is declared)? Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, December 05, 2007 1:40 AM Subject: Implementation Policies Hi, To set the context its about specification of policies on implementation elements in a composite. Since we have implementation model instances being reused we have trouble with capturing what policies were set on an implementation under a specific Component. I have this going in the trunk but with a bit of a hack in ComponentImpl.getImplementation. Now am looking at cleaning that a bit and exploring options. One of the alternatives suggested earlier is to have the implementation policies stored in the component itself. But the problem is Component themselves can have policies specified over them which will have be inherited by the service, implementation and reference child elements within. One way of getting around this is to add up the component's policies to the services and references child elements right at the time of reading from the scdl. Then when the implementation child element is loaded we read its policies and store it into the component. This seems a good way out but bites during the build phase as follows :- - One of the things we do in the build phase is validating if policysets specified on an implementation element i.e. checking to see if a specified policyset does apply to the implementation type in question. The specs says that its ok if this validation fails for policysets that have been inherited (say from the composite or the component), but if this validation fails for a policyset directly specified for the element then its an error in defining the composite and it must be flagged. * 551 When computing the policySets that apply to a particular element, the @appliesTo attribute 552 of each relevant policySet is checked against the element. If the policySet is attached 553 directly to the element and does not apply to that element an error is raised. If a policySet 554 that is attached to an ancestor element does not apply to the element in question, it is simply 555 discarded.
Re: Implementation Policies
On Dec 5, 2007 11:04 PM, Raymond Feng [EMAIL PROTECTED] wrote: Would it help if the Intent/PolicySet has a pointer to the its attachpoint (i.e., where the intent/policy is declared)? Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, December 05, 2007 1:40 AM Subject: Implementation Policies Hi, To set the context its about specification of policies on implementation elements in a composite. Since we have implementation model instances being reused we have trouble with capturing what policies were set on an implementation under a specific Component. I have this going in the trunk but with a bit of a hack in ComponentImpl.getImplementation. Now am looking at cleaning that a bit and exploring options. One of the alternatives suggested earlier is to have the implementation policies stored in the component itself. But the problem is Component themselves can have policies specified over them which will have be inherited by the service, implementation and reference child elements within. One way of getting around this is to add up the component's policies to the services and references child elements right at the time of reading from the scdl. Then when the implementation child element is loaded we read its policies and store it into the component. This seems a good way out but bites during the build phase as follows :- - One of the things we do in the build phase is validating if policysets specified on an implementation element i.e. checking to see if a specified policyset does apply to the implementation type in question. The specs says that its ok if this validation fails for policysets that have been inherited (say from the composite or the component), but if this validation fails for a policyset directly specified for the element then its an error in defining the composite and it must be flagged. * 551 When computing the policySets that apply to a particular element, the @appliesTo attribute 552 of each relevant policySet is checked against the element. If the policySet is attached 553 directly to the element and does not apply to that element an error is raised. If a policySet 554 that is attached to an ancestor element does not apply to the element in question, it is simply 555 discarded. - * So if we are going to store in the component model, the policysets specified on its implementation then during validation its not possible to figure out if the policyset came thro inheriting the component's policyset or from direct definition. Is there a way out of this ? Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Or have a pointer from each attachpoint to their policy and also a pointer from the component which aggregates them. A similar thing happens in contributions and the domain where composites are both contributed composites and deployable composite. Simon
Re: Implementation Policies
Hi, First, thanks for the help. I am not so comfortable with having inside an intent or a policyset, a pointer to an assembly model artifact. I somehow see a one way dependency that goes from the assembly model to the policy model i.e. an assembly model artifact must know the policies attached to it, but a policy (intent or policyset) doesn't quite need to know where it is attached. The fact that a policy intent 'constrains' or a policyset 'appliesTo' a particular 'class' of assembly model artifacts is a different thing. I am trying another work around for this. Will let you folks know of it once I am sure it works for me locally and get your views. Thanks - Venkat On Dec 6, 2007 2:36 PM, Simon Laws [EMAIL PROTECTED] wrote: On Dec 5, 2007 11:04 PM, Raymond Feng [EMAIL PROTECTED] wrote: Would it help if the Intent/PolicySet has a pointer to the its attachpoint (i.e., where the intent/policy is declared)? Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, December 05, 2007 1:40 AM Subject: Implementation Policies Hi, To set the context its about specification of policies on implementation elements in a composite. Since we have implementation model instances being reused we have trouble with capturing what policies were set on an implementation under a specific Component. I have this going in the trunk but with a bit of a hack in ComponentImpl.getImplementation. Now am looking at cleaning that a bit and exploring options. One of the alternatives suggested earlier is to have the implementation policies stored in the component itself. But the problem is Component themselves can have policies specified over them which will have be inherited by the service, implementation and reference child elements within. One way of getting around this is to add up the component's policies to the services and references child elements right at the time of reading from the scdl. Then when the implementation child element is loaded we read its policies and store it into the component. This seems a good way out but bites during the build phase as follows :- - One of the things we do in the build phase is validating if policysets specified on an implementation element i.e. checking to see if a specified policyset does apply to the implementation type in question. The specs says that its ok if this validation fails for policysets that have been inherited (say from the composite or the component), but if this validation fails for a policyset directly specified for the element then its an error in defining the composite and it must be flagged. * 551 When computing the policySets that apply to a particular element, the @appliesTo attribute 552 of each relevant policySet is checked against the element. If the policySet is attached 553 directly to the element and does not apply to that element an error is raised. If a policySet 554 that is attached to an ancestor element does not apply to the element in question, it is simply 555 discarded. - * So if we are going to store in the component model, the policysets specified on its implementation then during validation its not possible to figure out if the policyset came thro inheriting the component's policyset or from direct definition. Is there a way out of this ? Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Or have a pointer from each attachpoint to their policy and also a pointer from the component which aggregates them. A similar thing happens in contributions and the domain where composites are both contributed composites and deployable composite. Simon
Re: Implementation Policies
Would it help if the Intent/PolicySet has a pointer to the its attachpoint (i.e., where the intent/policy is declared)? Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, December 05, 2007 1:40 AM Subject: Implementation Policies Hi, To set the context its about specification of policies on implementation elements in a composite. Since we have implementation model instances being reused we have trouble with capturing what policies were set on an implementation under a specific Component. I have this going in the trunk but with a bit of a hack in ComponentImpl.getImplementation. Now am looking at cleaning that a bit and exploring options. One of the alternatives suggested earlier is to have the implementation policies stored in the component itself. But the problem is Component themselves can have policies specified over them which will have be inherited by the service, implementation and reference child elements within. One way of getting around this is to add up the component's policies to the services and references child elements right at the time of reading from the scdl. Then when the implementation child element is loaded we read its policies and store it into the component. This seems a good way out but bites during the build phase as follows :- - One of the things we do in the build phase is validating if policysets specified on an implementation element i.e. checking to see if a specified policyset does apply to the implementation type in question. The specs says that its ok if this validation fails for policysets that have been inherited (say from the composite or the component), but if this validation fails for a policyset directly specified for the element then its an error in defining the composite and it must be flagged. * 551 When computing the policySets that apply to a particular element, the @appliesTo attribute 552 of each relevant policySet is checked against the element. If the policySet is attached 553 directly to the element and does not apply to that element an error is raised. If a policySet 554 that is attached to an ancestor element does not apply to the element in question, it is simply 555 discarded. - * So if we are going to store in the component model, the policysets specified on its implementation then during validation its not possible to figure out if the policyset came thro inheriting the component's policyset or from direct definition. Is there a way out of this ? Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
