OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [NEW ISSUE] Need a clear way to distinguish Implementation Intents fromInteraction Intents



Raiser:                Mike Edwards

Target:                Policy framework specification - CD-01 of  27th January

Description:

The current specification describes the concepts of Interaction intents and Implementation intents.

Interaction intents are intended to influence policy which affects services, references and the wiring
between them.  In particular, such policies are expdected to influence the wire matching between the
two ends of a wire and also to affect the bytes that are sent between the reference and the service.

Implementation intents are intended to influence policy that relates to implementations and to the
containers that hold the implementations.

The basic implicit assumption of the current specification is that the @constrains attribute of the intent definition,
which defines which element(s) of the SCDL are targetted by the intent, define whether an intent is an interaction
intent or an implementation intent.  It is assumed that an interaction intent constrains a <binding/> element,
while an implementation intent constrains an <implementation/> element.

However, when creating some kinds of intent, it has been discovered that some types of implementation
intent need to target <binding/> elements, since they seek to influence the way that the binding implementation
operates, rather than the operation of the container for the implementation type.  These intents thus seek to
constrain <binding/> elements, but are not interaction intents and are not intended to influence wire matching
or the bytes that flow on the wire.

This issue calls for a new mechanism to distinguish interaction intents from implementation intents, which allow
for explicit marking of an intent as being of one type or the other and also for the design to permit an intent to
constrain an element indepdently of whether it is an implementation intent or an interaction intent.

Proposal:

a) Add a new attribute to an intent declaration, @intentType

- this has one of two values "interaction" or "implementation"

- "interaction" is the default (and so can be omitted for the more common case of interaction intents)

- for a qualified intent, the qualified form of the intent inherits the @intentType of the unqualified form
- it is an error if the qualified form of the intent uses an @intentType

b) Changes to the text of the spec:

1. Modify the attribute schema for the <intent/> element

change line 196 to:

constrains="listOfQNames" requires="listOfQNames"? intentType="string"? >

add, following line 1872:

<attribute name="intentType" type="string" use="optional" default="interaction"/>

add, following line 221:


replace lines 259 - 262 with the following:

Further, the @constrains attribute and the @intentType attribute of a qualified intent are unnecessary because
qualified intents inherit the @constrains and the @intentType attributes from the qualifiable intent.
A qualified intent MUST NOT specify @constrains or @intentType in its definition.
The following are definitions of the transport and message qualifiers of the confidentiality intent.


add, following line 274:

3.1 Interaction Intents and Implementation Intents

Interaction intents and implementation intents are distinguished by the value of the @intentType attribute in the
intent definition.

An interaction intent is an intent designed to influence policy which applies to a service, a reference and the wires
that connect them.  The interaction intent is intended to affect the wire matching between the two ends of the wire
and/or the set of bytes that flow between the reference and the service when a service invocation takes place.

Interaction intents typically apply to <binding/> elements.

An implementation intent is an intent designed to influence policy which applies to an implementation artifact or to
the relationship of that artifact to the runtime code which is used to execute the artifact.  Implementation intents
do not affect wire matching between references and services, nor do they affect the bytes that flow
between a reference and a service.

Implementation elements often apply to <implementation/> elements, but they may also apply to <binding/>
elements, where the desire is to influence the activity of the binding implementation code and how it interacts
with the remainder of the runtime code for the implementation.


add following line 1237:

Some implementation intents are targeted at <binding/> elements rather than at <implementation/> elements.
This occurs in cases where there is a need to influence the operation of the binding implementation code
rather than the code directly related to the implementation itself.  Implementation elements of this kind will
have a @constrains attribute pointing to a binding element, with a @intentType of "implementation".



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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]