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?
> 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="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).
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].
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.
Thoughts? Could the people also involved in the OASIS policy and/or
binding spec groups jump in with their views on this?
[1] http://www.osoa.org/jira/browse/BINDINGS-5
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
