You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2008/03/04 14:44:16 UTC
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?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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:service[@name='SomeName']"
> >
> <ConnectionsConf>
> <NoOfConnections> 100 </NoOfConnections>
> <TimeOut>300000</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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Is it possible to define a customizable value for an intent or
policy?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Is it possible to define a customizable value for an intent or policy?
Posted by ant elder <an...@gmail.com>.
On Tue, Mar 11, 2008 at 1:01 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> ant elder wrote:
> > On Fri, Mar 7, 2008 at 12:01 AM, Jean-Sebastien Delfino <
> > jsdelfino@apache.org> wrote:
> >
> >> ant elder wrote:
> >>> On Wed, Mar 5, 2008 at 9:46 AM, ant elder <an...@gmail.com> wrote:
> >>>
> >>>> On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino <
> >>>> jsdelfino@apache.org> 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:service[@name='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
Re: Is it possible to define a customizable value for an intent or
policy?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Fri, Mar 7, 2008 at 12:01 AM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> ant elder wrote:
>>> On Wed, Mar 5, 2008 at 9:46 AM, ant elder <an...@gmail.com> wrote:
>>>
>>>> On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino <
>>>> jsdelfino@apache.org> 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:service[@name='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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Is it possible to define a customizable value for an intent or policy?
Posted by ant elder <an...@gmail.com>.
On Fri, Mar 7, 2008 at 12:01 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> ant elder wrote:
> > On Wed, Mar 5, 2008 at 9:46 AM, ant elder <an...@gmail.com> wrote:
> >
> >>
> >> On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino <
> >> jsdelfino@apache.org> 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:service[@name='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
Re: Is it possible to define a customizable value for an intent or
policy?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Wed, Mar 5, 2008 at 9:46 AM, ant elder <an...@gmail.com> wrote:
>
>>
>> On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org> 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:service[@name='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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Is it possible to define a customizable value for an intent or policy?
Posted by ant elder <an...@gmail.com>.
On Wed, Mar 5, 2008 at 9:46 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> 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. 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="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:service[@name='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?
...ant
Re: Is it possible to define a customizable value for an intent or policy?
Posted by ant elder <an...@gmail.com>.
On Tue, Mar 4, 2008 at 6:19 PM, Jean-Sebastien Delfino <js...@apache.org>
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
Re: Is it possible to define a customizable value for an intent or
policy?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Is it possible to define a customizable value for an intent or policy?
Posted by ant elder <an...@apache.org>.
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?
...ant
On Tue, Mar 4, 2008 at 5:37 PM, Venkata Krishnan <fo...@gmail.com>
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:service[@name='SomeName']"
> >
> <ConnectionsConf>
> <NoOfConnections> 100 </NoOfConnections>
> <TimeOut>300000</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 <an...@gmail.com> wrote:
>
> > On Tue, Mar 4, 2008 at 4:34 PM, Jean-Sebastien Delfino <
> > jsdelfino@apache.org>
> > 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-dev&m=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: Transaction Handling
Posted by Sandeep Raman <sa...@tcs.com>.
Hi,
Where can i get the intent for the same, using which i can get started on
it.
I guess something should be available
Regards
Sandeep
"Raymond Feng" <en...@gmail.com> wrote on 03/21/2008 09:06:17 PM:
> Hi,
>
> The transaction policy hasn't been fully implemented yet. The seed code
in
> policy-transaction module. You can try to add it to your dependency to
see
> if it removes the warnings.
>
> Any contribution in the transaction area are welcome.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Sandeep Raman" <sa...@tcs.com>
> Sent: Friday, March 21, 2008 5:18 AM
> To: <tu...@ws.apache.org>
> Subject: Transaction Handling
>
> > I get the following error in console on using requires = "transaction"
on
> > a component
> >
> > Mar 21, 2008 5:45:29 PM
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> > problem
> > WARNING: Theres been an exception related to policies...
> > org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy
> > Intent '{http://www.osoa.org/xmlns/sca/1.0}transaction' is not defined
in
> > this domain
> > Mar 21, 2008 5:45:29 PM
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> > problem
> > WARNING: Theres been an exception related to policies...
> > org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy
> > Intent '{http://www.osoa.org/xmlns/sca/1.0}transaction' is not defined
in
> > this domain
> > Mar 21, 2008 5:45:29 PM
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> > problem
> > WARNING: Theres been an exception related to policies...
> > org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy
> > Intent '{http://www.osoa.org/xmlns/sca/1.0}transaction' is not defined
in
> > this domain
> > Mar 21, 2008 5:45:31 PM org.apache.geronimo.kernel.log.GeronimoLog
info
> > INFO: Module validation failed: The system is attempting to engage a
> > module that is not available: rampart
> > Mar 21, 2008 5:45:32 PM org.apache.geronimo.kernel.log.GeronimoLog
warn
> > WARNING: No JMS connection factories are defined.Will not listen for
any
> > JMS messages
> > Mar 21, 2008 5:45:32 PM org.apache.geronimo.kernel.log.GeronimoLog
warn
> > WARNING: No JMS connection factories are defined.Will not listen for
any
> > JMS messages
> > Mar 21, 2008 5:45:32 PM org.apache.tuscany.sca.http.jetty.JettyServer
> > addServletMapping
> > INFO: Added Servlet mapping: http://01hw113905:8080/ComposerService
> >
> > I guess i am missing the intent for transaction here.
> > Where can i find that.
> >
> > Regards
> > Sandeep.
> > =====-----=====-----=====
> > Notice: The information contained in this e-mail
> > message and/or attachments to it may contain
> > confidential or privileged information. If you are
> > not the intended recipient, any dissemination, use,
> > review, distribution, printing or copying of the
> > information contained in this e-mail message
> > and/or attachments to it are strictly prohibited. If
> > you have received this communication in error,
> > please notify us by reply e-mail or telephone and
> > immediately and permanently delete the message
> > and any attachments. Thank you
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> ForwardSourceID:NT00009392
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
Re: Transaction Handling
Posted by Raymond Feng <en...@gmail.com>.
Hi,
The transaction policy hasn't been fully implemented yet. The seed code in
policy-transaction module. You can try to add it to your dependency to see
if it removes the warnings.
Any contribution in the transaction area are welcome.
Thanks,
Raymond
--------------------------------------------------
From: "Sandeep Raman" <sa...@tcs.com>
Sent: Friday, March 21, 2008 5:18 AM
To: <tu...@ws.apache.org>
Subject: Transaction Handling
> I get the following error in console on using requires = "transaction" on
> a component
>
> Mar 21, 2008 5:45:29 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> problem
> WARNING: Theres been an exception related to policies...
> org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy
> Intent '{http://www.osoa.org/xmlns/sca/1.0}transaction' is not defined in
> this domain
> Mar 21, 2008 5:45:29 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> problem
> WARNING: Theres been an exception related to policies...
> org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy
> Intent '{http://www.osoa.org/xmlns/sca/1.0}transaction' is not defined in
> this domain
> Mar 21, 2008 5:45:29 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> problem
> WARNING: Theres been an exception related to policies...
> org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy
> Intent '{http://www.osoa.org/xmlns/sca/1.0}transaction' is not defined in
> this domain
> Mar 21, 2008 5:45:31 PM org.apache.geronimo.kernel.log.GeronimoLog info
> INFO: Module validation failed: The system is attempting to engage a
> module that is not available: rampart
> Mar 21, 2008 5:45:32 PM org.apache.geronimo.kernel.log.GeronimoLog warn
> WARNING: No JMS connection factories are defined.Will not listen for any
> JMS messages
> Mar 21, 2008 5:45:32 PM org.apache.geronimo.kernel.log.GeronimoLog warn
> WARNING: No JMS connection factories are defined.Will not listen for any
> JMS messages
> Mar 21, 2008 5:45:32 PM org.apache.tuscany.sca.http.jetty.JettyServer
> addServletMapping
> INFO: Added Servlet mapping: http://01hw113905:8080/ComposerService
>
> I guess i am missing the intent for transaction here.
> Where can i find that.
>
> Regards
> Sandeep.
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Transaction Handling
Posted by Sandeep Raman <sa...@tcs.com>.
I get the following error in console on using requires = "transaction" on
a component
Mar 21, 2008 5:45:29 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: Theres been an exception related to policies...
org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy
Intent '{http://www.osoa.org/xmlns/sca/1.0}transaction' is not defined in
this domain
Mar 21, 2008 5:45:29 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: Theres been an exception related to policies...
org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy
Intent '{http://www.osoa.org/xmlns/sca/1.0}transaction' is not defined in
this domain
Mar 21, 2008 5:45:29 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: Theres been an exception related to policies...
org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy
Intent '{http://www.osoa.org/xmlns/sca/1.0}transaction' is not defined in
this domain
Mar 21, 2008 5:45:31 PM org.apache.geronimo.kernel.log.GeronimoLog info
INFO: Module validation failed: The system is attempting to engage a
module that is not available: rampart
Mar 21, 2008 5:45:32 PM org.apache.geronimo.kernel.log.GeronimoLog warn
WARNING: No JMS connection factories are defined.Will not listen for any
JMS messages
Mar 21, 2008 5:45:32 PM org.apache.geronimo.kernel.log.GeronimoLog warn
WARNING: No JMS connection factories are defined.Will not listen for any
JMS messages
Mar 21, 2008 5:45:32 PM org.apache.tuscany.sca.http.jetty.JettyServer
addServletMapping
INFO: Added Servlet mapping: http://01hw113905:8080/ComposerService
I guess i am missing the intent for transaction here.
Where can i find that.
Regards
Sandeep.
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
Re: Running component service on a running port.
Posted by Raymond Feng <en...@gmail.com>.
When you deploy the SCA composite with services configured with web service
binding, please make sure tuscany-host-webapp-*.jar (but not
tuscany-host-jetty-*.jar) is packaged in the WEB-INF/lib folder.
Thanks,
Raymond
--------------------------------------------------
From: "Sandeep Raman" <sa...@tcs.com>
Sent: Tuesday, March 04, 2008 8:21 PM
To: <tu...@ws.apache.org>
Subject: Running component service on a running port.
> Hi,
>
> I want a component service run on an already running servlet container.
>
> I have done the following:
>
> 1) Have created two web services and exposed them on port 8080 in tomcat
> 2) I create then a composite of the two services and create then a service
> of the composite as follows:
>
> <component name="TwoWSService">
> <implementation.java class="eai.Compose" />
> <service name="Compose" requires = "integrity">
> <binding.ws uri="http://localhost:8080/TwoWSService" />
> </service>
> </component>
>
> 3) Now if i try to run this composite , the tuscany prepares to start its
> jettyserver and there is a conflict as the port is already in use. Now i
> dont want to start it on a new port.
>
> 4) The only option as per the samples is to create a webapp with an
> initial page (JSP/HTML) and go to the context path after deploying. The
> JSP does open , but in my case i will require the wsdl to open as soon as
> i touch the URL:
> http://localhost:8080/TwoWSService?wsdl
>
> How can it be done this way. Can you guide me.
>
> Regards
> Sandeep Raman.
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Running component service on a running port.
Posted by Sandeep Raman <sa...@tcs.com>.
Hi,
I want a component service run on an already running servlet container.
I have done the following:
1) Have created two web services and exposed them on port 8080 in tomcat
2) I create then a composite of the two services and create then a service
of the composite as follows:
<component name="TwoWSService">
<implementation.java class="eai.Compose" />
<service name="Compose" requires = "integrity">
<binding.ws uri="http://localhost:8080/TwoWSService" />
</service>
</component>
3) Now if i try to run this composite , the tuscany prepares to start its
jettyserver and there is a conflict as the port is already in use. Now i
dont want to start it on a new port.
4) The only option as per the samples is to create a webapp with an
initial page (JSP/HTML) and go to the context path after deploying. The
JSP does open , but in my case i will require the wsdl to open as soon as
i touch the URL:
http://localhost:8080/TwoWSService?wsdl
How can it be done this way. Can you guide me.
Regards
Sandeep Raman.
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
Certificate Handling - Policy
Posted by Sandeep Raman <sa...@tcs.com>.
Hi Venkat,
I am unable to find any tuscany sample which deals with certificates for
Policy.
I create a component service as follows:
<component name="TwoWSService">
<implementation.java class="helloworld.Compose" />
<service name="Compose" requires = "integrity">
<binding.ws uri="http://localhost:8085/TwoWSService" />
</service>
</component>
I send a soap request with an header information pertaining to the x509
certificate key, but it doesnt seem to be reading it. I am unable to find
if anything is missing in the intents or the composite.
For the @requires , i have in definitions.xml as follows, is any change
required in the below:
<sca:policySet name="hw:wsSecurityPolicyForIntegrity"
provides="integrity"
appliesTo="sca:binding.ws">
<wsp:Policy wsu:Id="SignOnly"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:AsymmetricBinding
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:TripleDesRsa15/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:Wss10
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
</wsp:Policy>
</sp:Wss10>
<sp:SignedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body/>
</sp:SignedParts>
<ramp:RampartConfig
xmlns:ramp="http://ws.apache.org/rampart/policy">
<ramp:user>apache</ramp:user>
<ramp:encryptionUser>apache</ramp:encryptionUser>
<ramp:passwordCallbackClass>helloworld.ServerPWCBHandler</ramp:passwordCallbackClass>
<ramp:signatureCrypto>
<ramp:crypto
provider="org.apache.ws.security.components.crypto.Merlin">
<ramp:property
name="org.apache.ws.security.crypto.merlin.keystore.type">JKS</ramp:property>
<ramp:property
name="org.apache.ws.security.crypto.merlin.file">helloworldKeys.jks</ramp:property>
<ramp:property
name="org.apache.ws.security.crypto.merlin.keystore.password">apache</ramp:property>
</ramp:crypto>
</ramp:signatureCrypto>
</ramp:RampartConfig>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</sca:policySet>
Regards
Sandeep Raman.
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
Re: Is it possible to define a customizable value for an intent or policy?
Posted by Venkata Krishnan <fo...@gmail.com>.
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:service[@name='SomeName']"
>
<ConnectionsConf>
<NoOfConnections> 100 </NoOfConnections>
<TimeOut>300000</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 <an...@gmail.com> wrote:
> On Tue, Mar 4, 2008 at 4:34 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org>
> 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-dev&m=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?
Posted by ant elder <an...@gmail.com>.
On Tue, Mar 4, 2008 at 4:34 PM, Jean-Sebastien Delfino <js...@apache.org>
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-dev&m=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?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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-dev&m=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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org