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.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.
Maybe you can ask them for more info?
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.
I can see that :)
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.
Mike, Dave, anybody working on the policy spec, could you please jump in
with your thoughts? Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
