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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Policy" <sca-policy@lists.oasis-open.org>
- Date: Mon, 28 Jan 2008 15:03:01 +0000
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:
- @intentType attribute (optional) defines
whether the intent is an interaction intent or an implementation intent.
A value of "interaction", which is the default value, indicates
that the intent is an interaction intent. A value of
"implementation" indicates that the intent is an implementation
intent.
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]