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? > > > 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="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.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? > > > > 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. > > IMHO we should avoid to create more confusion with two ways to configure > the same thing (a binding attribute plus a policy) in Tuscany and I > think that the policy approach is better. > I've not made up my mind yet. > > Thoughts? Could the people also involved in the OASIS policy and/or > binding spec groups jump in with their views on this? > > That would be really useful. ...ant
