default policy behaviour

[Simon Laws <si...@googlemail.com>]

In most cases policy based behaviour is only enabled when explicit
policy is attached to the assembly model (there are exceptions to this
of course when the policy is provided by default, by a binding for
example).. The specs leave default behaviour up to the runtime, for
example,

1654 9.2 Common Transaction Patterns
1655 In the absence of any transaction policies there is no explicit
transactional behavior defined for the SCA
1656 service component or the interactions in which it is involved and
the transactional behavior is
1657 environment-specific. An SCA runtime provider can choose to
define an out of band default transactional
1658 behavior that applies in the absence of any transaction policies.

I'd like to see a pluggable way to specify default policy behviour in
Tuscany if that's what you need to do.  Is there already a way to do
this?

If not I think the ideal candidate for this is the policy builder but
we'd need to adjust to have all policy builders called for all
endpoints, endpoint references and implementation. At the moment they
only get called if there is a policy set of the builders policy type
present. Maybe we we could add extra methods to the SPI to deal with
the default case, i.e. the case where the particular policy type isn't
present. The build can then decide it it needs to add a policy set.

The other alternative is to rely on the existing wire processor SPI.
This could work if we were desperate but it requires too much
knowledge of the runtime just to add default interceptors.

Thoughts?

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: default policy behaviour

[Simon Laws <si...@googlemail.com>]

I hadn't realized that 1) was our default behaviour. Interesting. This
may be good enough but I'm concerned about matching. If we don't
include default policy configuration in the model then the matching
algorithm may not work correctly. For example,

Reference
   explicit policyA
Service
   Binding.xyz
       default policyA

Unless we can determine that the default policy is applied the
matching falls down. I'm not completely sure that this is a valid
scenario yet and need to think harder about it. I suppose I'm
considering Luciano's question about what the affects of adding
defaults to the model from the opposite direction, i.e. what are the
effect if we don't.

Simon

Re: default policy behaviour

[Luciano Resende <lu...@gmail.com>]

On Thu, Jan 21, 2010 at 2:46 PM, Raymond Feng <en...@gmail.com> wrote:
> We have two options here:
>
> 1) Call all types of PolicyBuilder to populate the default values into the
> model
> 2) Call all types of PolicyProviderFactory to give them the opportunity to
> enforce the default behavior (The current code supports this flavor).
>
> Option 1 is interesting to explore. If it happens, the builders will add the
> default values to the in-memory assembly model when the intents/policySets
> are absent in the SCDL. PolicyProviderFactory can then be registered by the
> policy types. Tuscany runtime will look them up from the
> ProviderFactoryExtensionPoint by the type and call them to configure the
> invocation chain.
>

What are the side effects of using option1 and then using the in
memory model to write the composite, will we start to get very
different composites being produced ? Would this have effects on
tooling runtimes that have this as a common pattern for
reading/writting composites to files ?


-- 
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: default policy behaviour

[Raymond Feng <en...@gmail.com>]

We have two options here:

1) Call all types of PolicyBuilder to populate the default values into the 
model
2) Call all types of PolicyProviderFactory to give them the opportunity to 
enforce the default behavior (The current code supports this flavor).

Option 1 is interesting to explore. If it happens, the builders will add the 
default values to the in-memory assembly model when the intents/policySets 
are absent in the SCDL. PolicyProviderFactory can then be registered by the 
policy types. Tuscany runtime will look them up from the 
ProviderFactoryExtensionPoint by the type and call them to configure the 
invocation chain.

Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Thursday, January 21, 2010 2:10 PM
To: "tuscany-dev" <de...@tuscany.apache.org>
Subject: default policy behaviour

> In most cases policy based behaviour is only enabled when explicit
> policy is attached to the assembly model (there are exceptions to this
> of course when the policy is provided by default, by a binding for
> example).. The specs leave default behaviour up to the runtime, for
> example,
>
> 1654 9.2 Common Transaction Patterns
> 1655 In the absence of any transaction policies there is no explicit
> transactional behavior defined for the SCA
> 1656 service component or the interactions in which it is involved and
> the transactional behavior is
> 1657 environment-specific. An SCA runtime provider can choose to
> define an out of band default transactional
> 1658 behavior that applies in the absence of any transaction policies.
>
> I'd like to see a pluggable way to specify default policy behviour in
> Tuscany if that's what you need to do.  Is there already a way to do
> this?
>
> If not I think the ideal candidate for this is the policy builder but
> we'd need to adjust to have all policy builders called for all
> endpoints, endpoint references and implementation. At the moment they
> only get called if there is a policy set of the builders policy type
> present. Maybe we we could add extra methods to the SPI to deal with
> the default case, i.e. the case where the particular policy type isn't
> present. The build can then decide it it needs to add a policy set.
>
> The other alternative is to rely on the existing wire processor SPI.
> This could work if we were desperate but it requires too much
> knowledge of the runtime just to add default interceptors.
>
> Thoughts?
>
> Simon
>
> -- 
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com