More information on Tuscany policy sets

[Dan Becker <da...@gmail.com>]

Where can I get more information on policy sets in Tuscany? I am quite 
new to this concept, so I would appreciate more introductory information 
such as why are they there, what are they used for, how SCA applications 
use them?

I do see the implementation in the code base, but I am looking for more 
of a beginner explanation.
-- 
Thanks, Dan Becker

Re: More information on Tuscany policy sets

[Dan Becker <da...@gmail.com>]

Simon Laws wrote:
> On Fri, Aug 8, 2008 at 4:46 AM, Ramkumar R <ra...@gmail.com> wrote:
> 
>> Hi Dan,
>> Here I like to present what I understand about the policy sets.
>> ... 
>> Hope this helps.
>>
> 
> Hope this helps
> 
> Simon
> 
> [1]
> http://www.osoa.org/download/attachments/35/SCA_Policy_Framework_V100.pdf?version=1
> [2]
> http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
> 

Thanks Ram and Simon. Those are excellent introductions to the topic. I 
also appreciate the pointers to the specs.

It seems like this area is ripe for technical articles and tutorials!

-- 
Thanks, Dan Becker

Re: More information on Tuscany policy sets

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

On Fri, Aug 8, 2008 at 4:46 AM, Ramkumar R <ra...@gmail.com> wrote:

> Hi Dan,
> Here I like to present what I understand about the policy sets.
>
> Before we jump into policies, we need to understand what are non-functional
> properties in SOA as shown in the paragraph below:
>
> In Service Oriented Architecture, the non-functional properties of services
> and their connections, such as security and fault tolerance, should be
> defined separately from their functional properties (i.e., business logic)
> because different applications use services and connections in different
> non-functional contexts. For example, an application may unicast messages to
> a service, and another may manycast messages to multiple replicas of the
> service to improve fault tolerance. The separation between functional and
> non-functional properties improves the reusability of services and
> connections. It also enables the two different properties to evolve
> independently, and improves the ease of understanding application
> architectures. This contributes to higher maintainability of applications.
>
> Now lets see what are Policies in Tuscany:
>
> Policy is mainly used to impose non-functional properties like security,
> logging, authentication etc.,  that can be applied to service components or
> to the interactions between service components represented by services and
> references. An example of a policy is that messages exchanged between a
> service client and a service provider be encrypted, so that the exchange is
> confidential and cannot be read by someone who intercepts the conversation.
>
> In SCA, services and references can have policies applied to them that
> affect the form of the interaction that takes place at runtime. These are
> called interaction policies.
> Service components can also have other policies applied to them which
> affect how the components themselves behave within their runtime container.
> These are called implementation policies.
>
> In SCA, policies are held in policySets, which may contain one or many
> policies, expressed in some concrete form. Each policySet targets a specific
> binding type or a specific implementation type.
>
> In Tusany, all the policy related definitions can be defined in
> definitions.xml file. To know more about Intents and PolicySets, please
> refer the SCA Policy Framework Specs.
>
> Hope this helps.
>
>
> On Thu, Aug 7, 2008 at 11:32 PM, Dan Becker <da...@gmail.com>wrote:
>
>>
>> Where can I get more information on policy sets in Tuscany? I am quite new
>> to this concept, so I would appreciate more introductory information such as
>> why are they there, what are they used for, how SCA applications use them?
>>
>> I do see the implementation in the code base, but I am looking for more of
>> a beginner explanation.
>> --
>> Thanks, Dan Becker
>>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>

Nice write up Ram. We should also say that the policy framework that we
implement in Tuscany follows the SCA policy framework specification [1] and
extension specific policy detail contained in the other SCA specifications
[2].

I would just add to Ram's comments that SCA separates the process of
describing non-functional behaviour into 2 parts. Intents and policy sets.

Intents allow the composite application designer to describe what is
required in an abstract way, for example, Authentication, confidentiality
etc. without getting into the details of how that might be achieved.

Policy sets allow the deployer desbribe how the intents will actually be
achieved. So the policy set that "applies to" the authentication intent may
configure our Axis2 based web services binding to use web services security
techniques to ensure that incoming messages contain a username token which
is then authenticated.

It is true that you can attach policy sets directly to artifacts in the
composite file so there is some flexibiity to be very specific about how you
want a composite application to behave.

Hope this helps

Simon

[1]
http://www.osoa.org/download/attachments/35/SCA_Policy_Framework_V100.pdf?version=1
[2]
http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications

Re: More information on Tuscany policy sets

[Ramkumar R <ra...@gmail.com>]

Hi Dan,
Here I like to present what I understand about the policy sets.

Before we jump into policies, we need to understand what are non-functional
properties in SOA as shown in the paragraph below:

In Service Oriented Architecture, the non-functional properties of services
and their connections, such as security and fault tolerance, should be
defined separately from their functional properties (i.e., business logic)
because different applications use services and connections in different
non-functional contexts. For example, an application may unicast messages to
a service, and another may manycast messages to multiple replicas of the
service to improve fault tolerance. The separation between functional and
non-functional properties improves the reusability of services and
connections. It also enables the two different properties to evolve
independently, and improves the ease of understanding application
architectures. This contributes to higher maintainability of applications.

Now lets see what are Policies in Tuscany:

Policy is mainly used to impose non-functional properties like security,
logging, authentication etc.,  that can be applied to service components or
to the interactions between service components represented by services and
references. An example of a policy is that messages exchanged between a
service client and a service provider be encrypted, so that the exchange is
confidential and cannot be read by someone who intercepts the conversation.

In SCA, services and references can have policies applied to them that
affect the form of the interaction that takes place at runtime. These are
called interaction policies.
Service components can also have other policies applied to them which affect
how the components themselves behave within their runtime container. These
are called implementation policies.

In SCA, policies are held in policySets, which may contain one or many
policies, expressed in some concrete form. Each policySet targets a specific
binding type or a specific implementation type.

In Tusany, all the policy related definitions can be defined in
definitions.xml file. To know more about Intents and PolicySets, please
refer the SCA Policy Framework Specs.

Hope this helps.

On Thu, Aug 7, 2008 at 11:32 PM, Dan Becker <da...@gmail.com> wrote:

>
> Where can I get more information on policy sets in Tuscany? I am quite new
> to this concept, so I would appreciate more introductory information such as
> why are they there, what are they used for, how SCA applications use them?
>
> I do see the implementation in the code base, but I am looking for more of
> a beginner explanation.
> --
> Thanks, Dan Becker
>


-- 
Thanks & Regards,
Ramkumar Ramalingam