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="300000" />? Which seems simpler if allowed so > why > >>>>> is the > >>>>>> policySet approach better? > >>>>>> > >>>>> <binding.ws timeout="300000" 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 bindings and policySets, > policySets can be shared by multiple policy intents and bindings, it > should be possible to apply them to many elements in the whole domain > with a single xpath expression, also their application is governed by > different promotion and overriding rules. > > I think this boils down to which one is better: > > a) Write one policy rule definition to say 'use 10 connections for all > the ws bindings in such part of my domain'. > > b) Repeat a 'use 10 connections' attribute on all the ws bindings you > see in all the composites deployed in such part of the domain. > > c) Do a combination of (a) and (b) and describe what happens when there > are conflicts between the two, what is the best practice and when we > recommend people to use (a) or (b), and what to do when you've > unfortunately chosen to do (b) and then when you're tired of configuring > all your bindings one by one you decide to migrate to (a). > > IMHO (a) is the better choice. (c), by providing people with two options > to mess up their domain is the worse choice. > > > > > > >>> 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="300000" /> > >>> > >>> 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> > >>> <TimeOut>300000</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.xmldocument. > >> 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? > >>> > >> There is a fine line between binding configuration attributes and some > >> policies. My current rule of thumb is to think "policies" for qualities > >> of service that can apply to multiple bindings (timeouts, connection > >> pool sizing, reliability, security), and think "binding attributes" for > >> things that are really specific to a particular binding (or have > nothing > >> to do with quality of service). > >> > > > > That makes some sense but some things in the specs don't seem to follow > this > > - soap 1.1/1.2 as an intent, JMSDeliveryMode as a binding attribute. > > > > Some of the specs like the JMS binding spec are crossing that line. > >> That's an issue IMO, and actually one case at least has already been > >> identified as such by the OASIS SCA binding spec committee [1]. > >> > > > > Ok thats interesting...though no where in that email discussion or > meeting > > minutes does anyone suggest that its a mistake that the jms binding > supports > > the delivery mode attribute. > > Maybe you can ask them for more info? 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
