Re: Is it possible to define a customizable value for an intent or policy?
ant elder wrote: I can look at the existing specs and copy what they do for things like the SOAP intent or the JMS binding use of policy. I understand it can be useful to apply policy to a composite from out side but i disagree with you comment that anything else would mess up the domain and in this case where the alternative copies what an existing spec does and makes the simple case vastly simpler I think it may be better to do that or provide both options. ...ant It doesn't look like we're reaching consensus on doing only one of the two options, maybe the consensus is to do both. If you really want to do the 'binding attribute' option (which BTW should be in the Tuscany namespace I think) why don't you implement it? I really want to see the 'policy set' option implemented, if you don't want to implement it I can spend the time to help implement it. Both can coexist and will give Tuscany users two options to choose from, and we'll see over time what option they prefer in which configuration and circumstances. Does that work? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to define a customizable value for an intent or policy?
On Tue, Mar 11, 2008 at 1:01 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Fri, Mar 7, 2008 at 12:01 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Wed, Mar 5, 2008 at 9:46 AM, ant elder [EMAIL PROTECTED] wrote: On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Ok thanks. The binding.ws element is also extensible so this axis2 config could be added as extra attributes or elements there couldn't it, eg binding.ws timeOut=30 /? Which seems simpler if allowed so why is the policySet approach better? binding.ws timeout=30 connections=10 will require you to go open your application jar and change the .composite provided by the application developer to adjust the timeout or number of connections. Policies allow you to configure and adjust qualities of service like timeouts, connection pools etc. without touching the logical composition. -- Jean-Sebastien Ok that makes sense. But how does this compare to say the JMS binding which does support configuring QOS related things (priority, time to live etc) via binding attributes? ...ant No replies yet so I'll expand a little in case i was misunderstood, I'm trying to get better understanding of this area as there's been little on the ML to date and I'd guess it may not be just me thats a bit unclear. One issue is that currently the samples we have just include the definitions.xml file within the contribution so the point about being able configure things externally isn't being demonstrated, maybe this is just a point in time thing as its being implemented in Tuscany. It's a point in time limitation of the sample (not the Tuscany implementation). I think we should improve the bigbank sample to place definitions.xml in a separate contribution. Venkat has been working on it recently so he may already be looking into that? But if its in another contribution then you still have to crack open the jar to alter it so is that so much better than being included within the contribution its applying to? The key word here is another contribution. This allows people with different roles (developer, assembler, administrator) to work on the artifacts that they are interested in in the different contributions that they work with and own. For example with the policy approach you'll be able to resize the connection pools for 100 Web services by making a change to the-admin's-contribution/definitions.xml, without touching at all the 30 application-contributions containing the Web services. BTW a contribution does not have to be a JAR, the domain administrator should be able to contribute a definitions.xml file by pointing to the directory that contain them. Another issue i have with the policySet using an appliesTo xpath for the service is that it's invisible when looking at a contribution, maybe if there was good tooling it would get highlighted in some graphical display but from just looking at the contribution its not obvious so i don't like it so much. If you don't like references to elements outside of your contribution then you'll have a more general issue with many other such references, to WSDLs, other composites, classes etc. which will often be in a different contribution as well. Maybe I'm just not getting what you meant here :) I don't mind explicit references to elements outside the contribution which is why the requestConnection on the jms binding seems more intuitive to me. IMO the ability to apply policySets to services without polluting the logical composition and the application contribution is a key feature. OASIS JIRA POLICY-15 for example introduces the concept of external policy attachements to provide support for that scheme. I think it's much better than referencing policySets directly from the composition artifacts as direct references to policySets will make a composition much more difficult to reuse (for example if you want to change the level of security or connection pool size in different deployments of the same composite). Perhaps you can raise the issues you have with policySets to the OASIS policy spec workgroup? I can see I may want to change the timeout on a reference externally to the contribution but it feels like I'd much more often want to change the actual target endpoint uri on the WS binding but we don't have a way to do that without opening the contribution. IMO endpoint URIs do not change so often, but with SCA wiring and promotion you can (and in most cases should, IMO) limit the configuration of endpoint URIs to domain-level deployment composites. When you do that, you're doing something very similar to what is done for policies in definitions.xml files (which are domain-wide definitions as well).
Re: Is it possible to define a customizable value for an intent or policy?
ant elder wrote: On Fri, Mar 7, 2008 at 12:01 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Wed, Mar 5, 2008 at 9:46 AM, ant elder [EMAIL PROTECTED] wrote: On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Ok thanks. The binding.ws element is also extensible so this axis2 config could be added as extra attributes or elements there couldn't it, eg binding.ws timeOut=30 /? Which seems simpler if allowed so why is the policySet approach better? binding.ws timeout=30 connections=10 will require you to go open your application jar and change the .composite provided by the application developer to adjust the timeout or number of connections. Policies allow you to configure and adjust qualities of service like timeouts, connection pools etc. without touching the logical composition. -- Jean-Sebastien Ok that makes sense. But how does this compare to say the JMS binding which does support configuring QOS related things (priority, time to live etc) via binding attributes? ...ant No replies yet so I'll expand a little in case i was misunderstood, I'm trying to get better understanding of this area as there's been little on the ML to date and I'd guess it may not be just me thats a bit unclear. One issue is that currently the samples we have just include the definitions.xml file within the contribution so the point about being able configure things externally isn't being demonstrated, maybe this is just a point in time thing as its being implemented in Tuscany. It's a point in time limitation of the sample (not the Tuscany implementation). I think we should improve the bigbank sample to place definitions.xml in a separate contribution. Venkat has been working on it recently so he may already be looking into that? But if its in another contribution then you still have to crack open the jar to alter it so is that so much better than being included within the contribution its applying to? The key word here is another contribution. This allows people with different roles (developer, assembler, administrator) to work on the artifacts that they are interested in in the different contributions that they work with and own. For example with the policy approach you'll be able to resize the connection pools for 100 Web services by making a change to the-admin's-contribution/definitions.xml, without touching at all the 30 application-contributions containing the Web services. BTW a contribution does not have to be a JAR, the domain administrator should be able to contribute a definitions.xml file by pointing to the directory that contain them. Another issue i have with the policySet using an appliesTo xpath for the service is that it's invisible when looking at a contribution, maybe if there was good tooling it would get highlighted in some graphical display but from just looking at the contribution its not obvious so i don't like it so much. If you don't like references to elements outside of your contribution then you'll have a more general issue with many other such references, to WSDLs, other composites, classes etc. which will often be in a different contribution as well. Maybe I'm just not getting what you meant here :) I don't mind explicit references to elements outside the contribution which is why the requestConnection on the jms binding seems more intuitive to me. IMO the ability to apply policySets to services without polluting the logical composition and the application contribution is a key feature. OASIS JIRA POLICY-15 for example introduces the concept of external policy attachements to provide support for that scheme. I think it's much better than referencing policySets directly from the composition artifacts as direct references to policySets will make a composition much more difficult to reuse (for example if you want to change the level of security or connection pool size in different deployments of the same composite). Perhaps you can raise the issues you have with policySets to the OASIS policy spec workgroup? I can see I may want to change the timeout on a reference externally to the contribution but it feels like I'd much more often want to change the actual target endpoint uri on the WS binding but we don't have a way to do that without opening the contribution. IMO endpoint URIs do not change so often, but with SCA wiring and promotion you can (and in most cases should, IMO) limit the configuration of endpoint URIs to domain-level deployment composites. When you do that, you're doing something very similar to what is done for policies in definitions.xml files (which are domain-wide definitions as well). Right, so then when you're doing that why not have the binding just support these extra attributes to avoid the complication of needing the policySet in a definstions.xml :-) There are significant differences between
Re: Is it possible to define a customizable value for an intent or policy?
On Wed, Mar 5, 2008 at 9:46 AM, ant elder [EMAIL PROTECTED] wrote: On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Ok thanks. The binding.ws element is also extensible so this axis2 config could be added as extra attributes or elements there couldn't it, eg binding.ws timeOut=30 /? Which seems simpler if allowed so why is the policySet approach better? binding.ws timeout=30 connections=10 will require you to go open your application jar and change the .composite provided by the application developer to adjust the timeout or number of connections. Policies allow you to configure and adjust qualities of service like timeouts, connection pools etc. without touching the logical composition. -- Jean-Sebastien Ok that makes sense. But how does this compare to say the JMS binding which does support configuring QOS related things (priority, time to live etc) via binding attributes? ...ant No replies yet so I'll expand a little in case i was misunderstood, I'm trying to get better understanding of this area as there's been little on the ML to date and I'd guess it may not be just me thats a bit unclear. One issue is that currently the samples we have just include the definitions.xml file within the contribution so the point about being able configure things externally isn't being demonstrated, maybe this is just a point in time thing as its being implemented in Tuscany. Another issue i have with the policySet using an appliesTo xpath for the service is that it's invisible when looking at a contribution, maybe if there was good tooling it would get highlighted in some graphical display but from just looking at the contribution its not obvious so i don't like it so much. I can see I may want to change the timeout on a reference externally to the contribution but it feels like I'd much more often want to change the actual target endpoint uri on the WS binding but we don't have a way to do that without opening the contribution. The SOAP version is defined in the spec as using intents so if that is a valid approach I'm not sure i understand why a timeout intent is not? Even when i can see it would be useful to be able configure aspects of a binding externally to a contribution it does seem like it makes it more complicated than necessary for simple use, eg this: binding.ws timeout=30 / is much much simpler than requiring a separate document containing: sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; sca:policySet name=tuscany:Axis2ConnectionsConfPolicySet provides= appliesTo=sca:binding.ws tuscany:alwaysAppliesTo=sca:[EMAIL PROTECTED]'SomeName'] ConnectionsConf TimeOut30/TimeOut /ConnectionsConf /sca:policySet /sca:definitions Part of whats causing this confusion is that the JMS binding seems to use policy in a different way to the WS binding. Instead of using intents or policySets for these type of parameters it does just define them as elements and attributes of the binding.jms, but then it also supports pointing to an external binding configuration that is in a definitions.xml document. For example: binding.jms requestConnection=foo / and a definitions.xml containing: definitions binding.jms name=foo ...(the various config attributes and elements)... / /definitions (though it has to be said the JMS spec only allows some of the config options to be specified in that external definitions file, and ones that you'd think should be there like timeToLive are not allowed!) So any comments from those who've made it this far through the email? Is some of this just due to timings of when specs were written or not yet finished? Would it be wrong to support extra attributes on the binding as well as the policySet approach to make the simple use easier? Or also the support the JMS binding approach and have binding.ws name an external binding config thats in an external definitions.xml so that its more obvious there's some external config going on when looking in a contribution? ...ant
Re: Is it possible to define a customizable value for an intent or policy?
ant elder wrote: On Wed, Mar 5, 2008 at 9:46 AM, ant elder [EMAIL PROTECTED] wrote: On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Ok thanks. The binding.ws element is also extensible so this axis2 config could be added as extra attributes or elements there couldn't it, eg binding.ws timeOut=30 /? Which seems simpler if allowed so why is the policySet approach better? binding.ws timeout=30 connections=10 will require you to go open your application jar and change the .composite provided by the application developer to adjust the timeout or number of connections. Policies allow you to configure and adjust qualities of service like timeouts, connection pools etc. without touching the logical composition. -- Jean-Sebastien Ok that makes sense. But how does this compare to say the JMS binding which does support configuring QOS related things (priority, time to live etc) via binding attributes? ...ant No replies yet so I'll expand a little in case i was misunderstood, I'm trying to get better understanding of this area as there's been little on the ML to date and I'd guess it may not be just me thats a bit unclear. One issue is that currently the samples we have just include the definitions.xml file within the contribution so the point about being able configure things externally isn't being demonstrated, maybe this is just a point in time thing as its being implemented in Tuscany. It's a point in time limitation of the sample (not the Tuscany implementation). I think we should improve the bigbank sample to place definitions.xml in a separate contribution. Venkat has been working on it recently so he may already be looking into that? Another issue i have with the policySet using an appliesTo xpath for the service is that it's invisible when looking at a contribution, maybe if there was good tooling it would get highlighted in some graphical display but from just looking at the contribution its not obvious so i don't like it so much. If you don't like references to elements outside of your contribution then you'll have a more general issue with many other such references, to WSDLs, other composites, classes etc. which will often be in a different contribution as well. Maybe I'm just not getting what you meant here :) I can see I may want to change the timeout on a reference externally to the contribution but it feels like I'd much more often want to change the actual target endpoint uri on the WS binding but we don't have a way to do that without opening the contribution. IMO endpoint URIs do not change so often, but with SCA wiring and promotion you can (and in most cases should, IMO) limit the configuration of endpoint URIs to domain-level deployment composites. When you do that, you're doing something very similar to what is done for policies in definitions.xml files (which are domain-wide definitions as well). The SOAP version is defined in the spec as using intents so if that is a valid approach I'm not sure i understand why a timeout intent is not? Even when i can see it would be useful to be able configure aspects of a binding externally to a contribution it does seem like it makes it more complicated than necessary for simple use, eg this: binding.ws timeout=30 / is much much simpler than requiring a separate document containing: sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; sca:policySet name=tuscany:Axis2ConnectionsConfPolicySet provides= appliesTo=sca:binding.ws tuscany:alwaysAppliesTo=sca:[EMAIL PROTECTED]'SomeName'] ConnectionsConf TimeOut30/TimeOut /ConnectionsConf /sca:policySet /sca:definitions Part of whats causing this confusion is that the JMS binding seems to use policy in a different way to the WS binding. Instead of using intents or policySets for these type of parameters it does just define them as elements and attributes of the binding.jms, but then it also supports pointing to an external binding configuration that is in a definitions.xml document. For example: binding.jms requestConnection=foo / and a definitions.xml containing: definitions binding.jms name=foo ...(the various config attributes and elements)... / /definitions (though it has to be said the JMS spec only allows some of the config options to be specified in that external definitions file, and ones that you'd think should be there like timeToLive are not allowed!) So any comments from those who've made it this far through the email? Is some of this just due to timings of when specs were written or not yet finished? Would it be wrong to support extra attributes on the binding as well as the policySet approach to make the simple use easier? Or also the support the
Re: Is it possible to define a customizable value for an intent or policy?
On Fri, Mar 7, 2008 at 12:01 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Wed, Mar 5, 2008 at 9:46 AM, ant elder [EMAIL PROTECTED] wrote: On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Ok thanks. The binding.ws element is also extensible so this axis2 config could be added as extra attributes or elements there couldn't it, eg binding.ws timeOut=30 /? Which seems simpler if allowed so why is the policySet approach better? binding.ws timeout=30 connections=10 will require you to go open your application jar and change the .composite provided by the application developer to adjust the timeout or number of connections. Policies allow you to configure and adjust qualities of service like timeouts, connection pools etc. without touching the logical composition. -- Jean-Sebastien Ok that makes sense. But how does this compare to say the JMS binding which does support configuring QOS related things (priority, time to live etc) via binding attributes? ...ant No replies yet so I'll expand a little in case i was misunderstood, I'm trying to get better understanding of this area as there's been little on the ML to date and I'd guess it may not be just me thats a bit unclear. One issue is that currently the samples we have just include the definitions.xml file within the contribution so the point about being able configure things externally isn't being demonstrated, maybe this is just a point in time thing as its being implemented in Tuscany. It's a point in time limitation of the sample (not the Tuscany implementation). I think we should improve the bigbank sample to place definitions.xml in a separate contribution. Venkat has been working on it recently so he may already be looking into that? But if its in another contribution then you still have to crack open the jar to alter it so is that so much better than being included within the contribution its applying to? Another issue i have with the policySet using an appliesTo xpath for the service is that it's invisible when looking at a contribution, maybe if there was good tooling it would get highlighted in some graphical display but from just looking at the contribution its not obvious so i don't like it so much. If you don't like references to elements outside of your contribution then you'll have a more general issue with many other such references, to WSDLs, other composites, classes etc. which will often be in a different contribution as well. Maybe I'm just not getting what you meant here :) I don't mind explicit references to elements outside the contribution which is why the requestConnection on the jms binding seems more intuitive to me. I can see I may want to change the timeout on a reference externally to the contribution but it feels like I'd much more often want to change the actual target endpoint uri on the WS binding but we don't have a way to do that without opening the contribution. IMO endpoint URIs do not change so often, but with SCA wiring and promotion you can (and in most cases should, IMO) limit the configuration of endpoint URIs to domain-level deployment composites. When you do that, you're doing something very similar to what is done for policies in definitions.xml files (which are domain-wide definitions as well). Right, so then when you're doing that why not have the binding just support these extra attributes to avoid the complication of needing the policySet in a definstions.xml :-) The SOAP version is defined in the spec as using intents so if that is a valid approach I'm not sure i understand why a timeout intent is not? Even when i can see it would be useful to be able configure aspects of a binding externally to a contribution it does seem like it makes it more complicated than necessary for simple use, eg this: binding.ws timeout=30 / is much much simpler than requiring a separate document containing: sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; sca:policySet name=tuscany:Axis2ConnectionsConfPolicySet provides= appliesTo=sca:binding.ws tuscany:alwaysAppliesTo=sca:[EMAIL PROTECTED]'SomeName'] ConnectionsConf TimeOut30/TimeOut /ConnectionsConf /sca:policySet /sca:definitions Part of whats causing this confusion is that the JMS binding seems to use policy in a different way to the WS binding. Instead of using intents or policySets for these type of parameters it does just define them as elements and attributes of the binding.jms, but then it also supports pointing to an external binding configuration
Re: Is it possible to define a customizable value for an intent or policy?
On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Ok thanks. The binding.ws element is also extensible so this axis2 config could be added as extra attributes or elements there couldn't it, eg binding.ws timeOut=30 /? Which seems simpler if allowed so why is the policySet approach better? binding.ws timeout=30 connections=10 will require you to go open your application jar and change the .composite provided by the application developer to adjust the timeout or number of connections. Policies allow you to configure and adjust qualities of service like timeouts, connection pools etc. without touching the logical composition. -- Jean-Sebastien Ok that makes sense. But how does this compare to say the JMS binding which does support configuring QOS related things (priority, time to live etc) via binding attributes? ...ant
Is it possible to define a customizable value for an intent or policy?
For a few things i've wondered about using intents to configure the behaviour of an extension but cant see how to code it without hard coding values. Using TUSCANY-1997 as an example is there some way of saying something like binding.ws requires=lotsOfConnections / and have that map to a user configurable value like 10? I can see how to use an intent named lotsOfConnections in a definitions.xml file but is there a way to map a value like 10 to that without just hard coding the mapping in the ws binding code? ...ant
Re: Is it possible to define a customizable value for an intent or policy?
ant elder wrote: For a few things i've wondered about using intents to configure the behaviour of an extension but cant see how to code it without hard coding values. Using TUSCANY-1997 as an example is there some way of saying something like binding.ws requires=lotsOfConnections / and have that map to a user configurable value like 10? I can see how to use an intent named lotsOfConnections in a definitions.xml file but is there a way to map a value like 10 to that without just hard coding the mapping in the ws binding code? Yes, the policy framework allows you to define in definitions.xml a policySet matching an intent, place in the policySet the desired configuration in a form understood by the binding code, then that configuration will be presented to your binding. For a scenario like configure lots of connections on a reference with binding.ws, there is a better way than using an intent (i.e. I don't think that defining an intent for something like lotsOfConnections is the proper usage of policies): - you can just define the policySet, without an intent - add the policySet explicitly to your composition - or, better, attach it to your composition externally as discussed on tuscany-dev [1], the OASIS SCA Policy group [2] and in JIRA TUSCANY-1997 [2]. [1] http://marc.info/?l=tuscany-devm=120346977514972 [2] http://www.osoa.org/jira/browse/POLICY-15 [3] http://issues.apache.org/jira/browse/TUSCANY-1997?focusedCommentId=12570553#action_12570553 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to define a customizable value for an intent or policy?
On Tue, Mar 4, 2008 at 4:34 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: For a few things i've wondered about using intents to configure the behaviour of an extension but cant see how to code it without hard coding values. Using TUSCANY-1997 as an example is there some way of saying something like binding.ws requires=lotsOfConnections / and have that map to a user configurable value like 10? I can see how to use an intent named lotsOfConnections in a definitions.xml file but is there a way to map a value like 10 to that without just hard coding the mapping in the ws binding code? Yes, the policy framework allows you to define in definitions.xml a policySet matching an intent, place in the policySet the desired configuration in a form understood by the binding code, then that configuration will be presented to your binding. For a scenario like configure lots of connections on a reference with binding.ws, there is a better way than using an intent (i.e. I don't think that defining an intent for something like lotsOfConnections is the proper usage of policies): - you can just define the policySet, without an intent - add the policySet explicitly to your composition - or, better, attach it to your composition externally as discussed on tuscany-dev [1], the OASIS SCA Policy group [2] and in JIRA TUSCANY-1997 [2]. [1] http://marc.info/?l=tuscany-devm=120346977514972 [2] http://www.osoa.org/jira/browse/POLICY-15 [3] http://issues.apache.org/jira/browse/TUSCANY-1997?focusedCommentId=12570553#action_12570553 -- Jean-Sebastien Could you show some XML snippets for how that would look? ...ant
Re: Is it possible to define a customizable value for an intent or policy?
Hi, I am just about going to check in what Sebastien is suggesting here. So you could define a PolicySet as follows : - sca:policySet name=tuscany:Axis2ConnectionsConfPolicySet provides= appliesTo=sca:binding.ws tuscany:alwaysAppliesTo=sca:[EMAIL PROTECTED]'SomeName'] ConnectionsConf NoOfConnections 100 /NoOfConnections TimeOut30/TimeOut /ConnectionsConf /sca:policySet Where the only thing you might have to define is that structure ConnetionsConf and the xml processing for it. Then you need to write your handler for this policyset and register it in the binding module's META-INF/services. Thats it. - Venkat On Tue, Mar 4, 2008 at 10:30 PM, ant elder [EMAIL PROTECTED] wrote: On Tue, Mar 4, 2008 at 4:34 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: For a few things i've wondered about using intents to configure the behaviour of an extension but cant see how to code it without hard coding values. Using TUSCANY-1997 as an example is there some way of saying something like binding.ws requires=lotsOfConnections / and have that map to a user configurable value like 10? I can see how to use an intent named lotsOfConnections in a definitions.xml file but is there a way to map a value like 10 to that without just hard coding the mapping in the ws binding code? Yes, the policy framework allows you to define in definitions.xml a policySet matching an intent, place in the policySet the desired configuration in a form understood by the binding code, then that configuration will be presented to your binding. For a scenario like configure lots of connections on a reference with binding.ws, there is a better way than using an intent (i.e. I don't think that defining an intent for something like lotsOfConnections is the proper usage of policies): - you can just define the policySet, without an intent - add the policySet explicitly to your composition - or, better, attach it to your composition externally as discussed on tuscany-dev [1], the OASIS SCA Policy group [2] and in JIRA TUSCANY-1997 [2]. [1] http://marc.info/?l=tuscany-devm=120346977514972 [2] http://www.osoa.org/jira/browse/POLICY-15 [3] http://issues.apache.org/jira/browse/TUSCANY-1997?focusedCommentId=12570553#action_12570553 -- Jean-Sebastien Could you show some XML snippets for how that would look? ...ant
Re: Is it possible to define a customizable value for an intent or policy?
Ok thanks. The binding.ws element is also extensible so this axis2 config could be added as extra attributes or elements there couldn't it, eg binding.ws timeOut=30 /? Which seems simpler if allowed so why is the policySet approach better? ...ant On Tue, Mar 4, 2008 at 5:37 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I am just about going to check in what Sebastien is suggesting here. So you could define a PolicySet as follows : - sca:policySet name=tuscany:Axis2ConnectionsConfPolicySet provides= appliesTo=sca:binding.ws tuscany:alwaysAppliesTo=sca:[EMAIL PROTECTED]'SomeName'] ConnectionsConf NoOfConnections 100 /NoOfConnections TimeOut30/TimeOut /ConnectionsConf /sca:policySet Where the only thing you might have to define is that structure ConnetionsConf and the xml processing for it. Then you need to write your handler for this policyset and register it in the binding module's META-INF/services. Thats it. - Venkat On Tue, Mar 4, 2008 at 10:30 PM, ant elder [EMAIL PROTECTED] wrote: On Tue, Mar 4, 2008 at 4:34 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: For a few things i've wondered about using intents to configure the behaviour of an extension but cant see how to code it without hard coding values. Using TUSCANY-1997 as an example is there some way of saying something like binding.ws requires=lotsOfConnections / and have that map to a user configurable value like 10? I can see how to use an intent named lotsOfConnections in a definitions.xml file but is there a way to map a value like 10 to that without just hard coding the mapping in the ws binding code? Yes, the policy framework allows you to define in definitions.xml a policySet matching an intent, place in the policySet the desired configuration in a form understood by the binding code, then that configuration will be presented to your binding. For a scenario like configure lots of connections on a reference with binding.ws, there is a better way than using an intent (i.e. I don't think that defining an intent for something like lotsOfConnections is the proper usage of policies): - you can just define the policySet, without an intent - add the policySet explicitly to your composition - or, better, attach it to your composition externally as discussed on tuscany-dev [1], the OASIS SCA Policy group [2] and in JIRA TUSCANY-1997 [2]. [1] http://marc.info/?l=tuscany-devm=120346977514972 [2] http://www.osoa.org/jira/browse/POLICY-15 [3] http://issues.apache.org/jira/browse/TUSCANY-1997?focusedCommentId=12570553#action_12570553 -- Jean-Sebastien Could you show some XML snippets for how that would look? ...ant
Re: Is it possible to define a customizable value for an intent or policy?
Venkata Krishnan wrote: Hi, I am just about going to check in what Sebastien is suggesting here. So you could define a PolicySet as follows : - sca:policySet name=tuscany:Axis2ConnectionsConfPolicySet provides= appliesTo=sca:binding.ws tuscany:alwaysAppliesTo=sca:[EMAIL PROTECTED]'SomeName'] ConnectionsConf NoOfConnections 100 /NoOfConnections TimeOut30/TimeOut /ConnectionsConf /sca:policySet Where the only thing you might have to define is that structure ConnetionsConf and the xml processing for it. Then you need to write your handler for this policyset and register it in the binding module's META-INF/services. Thats it. Yes that's exactly what I meant. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to define a customizable value for an intent or policy?
ant elder wrote: Ok thanks. The binding.ws element is also extensible so this axis2 config could be added as extra attributes or elements there couldn't it, eg binding.ws timeOut=30 /? Which seems simpler if allowed so why is the policySet approach better? binding.ws timeout=30 connections=10 will require you to go open your application jar and change the .composite provided by the application developer to adjust the timeout or number of connections. Policies allow you to configure and adjust qualities of service like timeouts, connection pools etc. without touching the logical composition. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
