Hi,
Please find the link to the JIRA system: http://www.osoa.org/jira/browse/POLICY-44
Regards,
Kaanu Joshi
From: Mike Edwards
[mailto:mike_edwards@uk.ibm.com]
Sent: Monday, January 28, 2008
8:33 PM
To: OASIS Policy
Subject: [sca-policy] [NEW ISSUE]
Need a clear way to distinguish Implementation Intents from Interaction 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:
- @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