[NEW ISSUE] Provide a better mechanism of attaching Intents and Policy Setsto Operations and Messages

[Mike Edwards <mike_edwards@uk.ibm.com>]

Raiser:        
               Mike
Edwards

Target:        
               Policy
Framework specification, CD-01

Description:

Sections 4.4 (line 826) and 4.5 (line
838) deal with attaching intents and policy sets at the operation level
to services, references and bindings.

Section 5.2 (line 1253) deals with attaching
intents and policy sets at the operation level to implementations.

The current functionality described
there suffers from flaws:

o There is a lot of mechanics reproducing
the structure of an interface in order to allow for the required attachment.
 This is complex and
is hard to understand given the large number of locations to which it can
apply.

o It does not support the attachment
of intents / policy sets to an individual message, only to complete operations.
 There is a desire from
some users to enable some policies to
be applied only to particular messages, since the overhead of complex policies
(eg signing and
encryption) may be such that the performance
implications force its use only where absolutely necessary.

This issue requests that a simpler and
more capable set of mechanisms is provided for this functionality

Proposal:

This proposal is based on the concept
of attaching Intents and/or PolicySets directly to interface artifacts,
rather than attaching them to
artifacts in the SCDL as in the current
design.

The basic idea is that interface artifacts
such as WSDL documents and Java interfaces already fully describe the interface,
with its
operations and messages.  If operation-level
or messge-level intents/policies need to be applied, then this done using
annotations in
the interface artifacts, applying those
annotations directly to the operation or message declarations.

When interfaces are used that contain
operation and/or message level intents or policy sets, the policy selection
process is driven
at the operation and/or message level,
to compute the actual policies to apply for those operations or messages,
separately from 
the intents and policy sets that apply
to the interface as a whole.  This requires that the runtime processing
a service or a reference
must inspect the interface artifact
to discover any annotations applied at the operation or message level.
 It is also necessary when
checking for wire compatibility between
a reference and a service, to check right down to operation and message
level and ensure
that any policies which apply at these
levels also match,

*** Note that this will require some
changes to the Assembly specification, which are listed in this proposal
but which will have to
be raised as an issue with the Assembly
TC ***

For the Policy framework specification:

Remove section 4.4, section 4.5, section
5.2.

Add a new section at line 826, as follows:

4.4 Operation and Message Level Intents
and Policy Sets 

It is possible to specify intents and/or
policy sets for individual operations within an interface used by a service
or by a reference.
It is also possible to specify intents
and/or policy sets to individual messages used by one or more operations
within an interface
used by a service or by a reference.

Operation or message level intents and
policy sets can select different policies for those operations or for those
messages than 
the policies that apply to the interface
as a whole.  They can customise the policies that apply to the operation
or to the message 
concerned.  As an example, a special
encryption policy can be applied to a particular message, where that message
has a special
sensitivity and where applying that
policy to the whole interface would be wasteful of resources (perhaps the
encryption technique 
is very strong but has major performance
impact, for example).

For WSDL interface documents, intents
are specified on <operation/>, <input/> and <output/>
elements using the @requires
attribute (see Assembly specification,
section 8.4) <suggest a hyperlink at this point>

For WSDL interface documents, policy
sets are specified on <operation/> , <input/> and <output/>
elements using the @policysets
attribute (see Assembly specification,
section 8.4) <suggest a hyperlink at this point>

For Java interfaces, intents are applied
using the @Requires annotation while policy sets are applied using the
@PolicySets
annotation.  For details, see the
Java Common Annotations and APIs specification.

For other interface definition types,
please see the specification which describes that interface definition
type.


Replace section 4.10, line 1095 with
the following:

2.        Add
intents found in any related interface definition.  If the interface
contains any intents or any policy sets which are attached
at the operation level or at the message
level, all of the steps following this one must be executed repeatedly,
for each operation or
message so marked, with the resulting
set of policies being attached to that operation or message only.  Any
operations or messages
that are not marked use the policies
which apply to the interface as a whole.


For the Assembly specification:

Modify section 8.4, lines 2374 - 2377:

The @requires attribute can be applied to WSDL Port Type elements (WSDL 1.1) and to WSDL Interface elements (WSDL 2.0), and to any child operation elements and to any input or output elements which are children of an operation element..  The attribute contains one or more intent names, as defined by the Policy Framework specification [10].

Add to section 8.4 after line 2399:

SCA defines a global attribute in the SCA namespace which provides a mechanism to attach policy sets - @policySets.  The definition of this attribute is as follows:

    <attribute name="policySets" type="sca:listOfQNames"/>

 
The @policysets attribute can be applied to WSDL Port Type elements, and any child operation elements and to any input or output elements which are children of an operation element (WSDL 1.1) and to WSDL Interface elements (WSDL 2.0), and to any child operation elements and to any input or output elements which are children of an operation element.

The attribute contains one or more policy set names, as defined by the Policy Framework specification [10].

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.        
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU