From: Mike
Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Thursday, November 22, 2007
9:00 AM
To: OASIS Policy
Subject: RE: [sca-policy] ISSUE
POLICY-18 : Should qualifiable intents have a default qualifier
Michael,
I
think there is a need to think through the meaning before worrying about the
words.
There
is a problem in getting a clean selection of policyset(s) in the case where
there are two or more
qualified
intents in the mix being used to select out the policysets.
The
use cases 1) and 2) below are clear. The default qualifier in the intent
definition acts as a tie breaker
for
otherwise ambiguous cases. So an intent intentA is treated as if it
were written "intentA.defaultQ" for
usecases
1) and 2) and is interpreted accordingly.
Case
3) is less clear to me.
Here
let's assume that @requires="intentA" is specified for some element.
This
will pick out policySets which have @provides="intentA" and in this
case, the default qualifier in the intent
definition
is not used at all (right?).
Right.
If the policySet(s) have their
own internal default, that gets used.
However,
for policySets which @provides="intentA.someQ", the idea is that the
default qualifier in the intent
definition
is used to select out ONLY those policySets which have
@provides="intentA.defaultQ" (right?)
It
is as if @requires="intentA" is interpreted as if
@requires="intentA.defaultQ".
Only in
cases where it is used to disambiguate between two different policySets, one
that provides “intentA.defaultQ” and the other that provides “intentA.someOtherQ”.
It is only used as a tie breaker. Here was my proposed rule: “If
there are multiple matching policy sets whose @provides lists are identical
except that each provides a different qualifier for the same qualifiable
intent, then only the policy set that provides the qualifier that was defined
as the default qualifier will be used. “
This leads to entertainment if there are multiple
qualified intents: @requires="intentA intentB"
This
is now interpreted as if @requires="intentA.defaultQ
intentB.defaultQB". The result of this is potentially
to
fail to select any policySet at all.
Not
quite, as noted above.
A policySet with @provides="intentA intentB"
will be selected OK.
But
a policySet with (say) @provides="intentA.someQ intentB" will now
fail selection as it does not provide
intentA.defaultQ.
If this is the only policySet providing intentB, the whole process will
fail, if I understand the
proposal
below. If it is supposed to work, then the wording below simply doesn't
say enough about the
selection
process.
What
was the intention here?
No, that
isn’t how it works. The default was only supposed to be used as a
tie-breaker, when more than one policySet would qualify.
If the default qualifier is really a "tie
breaker", then it should not be used until the point where the (original)
process
has (potentially multiple) sets of policySets that satisfy all the stated
intents. These can be
potentially
winnowed using the default qualifiers, but there may be conflict between the
default qualifiers
for
different intents and there must be some conflict resolution process.
"Remove
from the set of policySets each of those policySets which provide qualified
intents for the
unqualified
intents in the set of intents where the provided qualified intent does
not match the default qualifier for
the
intent, IF the removal of that policySet does NOT cause some (other) intent in
the set of intents to become
unsatisfied
by the remaining group of policySets"
UGH
!
Indeed
it is tricky to get the right words. In my opinion, my original words
were easier to understand. Does that description miss something?
Reminder
(so you don’t have to scroll up): “If
there are multiple matching policy sets whose @provides lists are identical
except that each provides a different qualifier for the same qualifiable
intent, then only the policy set that provides the qualifier that was defined
as the default qualifier will be used. “
Michael
Or is my brain just too small to handle this stuff.
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
"Michael
Rowley" <mrowley@bea.com>
20/11/2007 21:48
|
To
|
<sca-policy@lists.oasis-open.org>
|
cc
|
|
Subject
|
RE: [sca-policy] ISSUE POLICY-18 : Should
qualifiable intents have a default qualifier
|
|
We
discussed a potential solution to this issue on yesterday's policy TC.
Here is a proposal that I believe fits with the discussion that we had
(and fulfills the action item I took on the call).
First,
it is worth noting the situations where the current approach of having a
default qualifier in an intent map, doesn't work:
1)
Policy sets aren't used because binding.sca is being used, and that binding
uses intents directly, rather than using policy sets.
2)
If a binding specifies a qualifiable intent in its list of @mayProvide intents,
then no policy sets or intent maps will be used.
3)
When policy sets for qualified intents are specified separately, rather than
being part of a single intent map, then there is no place to put a default
qualifier. This approach is valuable for qualifiable intents that may
gain additional qualifiers over time.
To
handle these situations, a intent definition will get a new attribute called
@defaultQualifier. The value of the attribute is the name of a qualifier
(so the full quaified intent would be "<qualifiable intent
name>.<qualifier name>").
This
default has lower priority than defaults that might be found in intent maps.
So, if some construct which includes intent "a" in its
@requires list matches against a policySet that includes "a" in its
@provides list, then that policy set will be used, irrespective of any default
qualifier listed in the intent definition for "a". If
"a" is qualifiable, then the policy set that provides it will most
likely include an intent map, although that isn’t strictly necessary.
The
policy set matching algorithm in section 4.10 will need to be modified.
Step E currently reads:
E.
Choose the smallest collection of additional policySets that match all
remaining required intents.
This
will need the following addition:
If
there are multiple matching policy sets whose @provides lists are identical
except that each provides a different qualifier for the same qualifiable
intent, then only the policy set that provides the qualifier that was defined
as the default qualifier will be used.
I
know that the above text is quite complicated, so I hope someone will suggest
how it can be made simpler.
I
think we also need to address intents offered by the @mayProvide list for
bindings. I think the rule should be something like the following:
If
a binding lists a qualifiable intent in its @mayProvide list, then the binding
is assumed to support any of the qualifiers for that intent (i.e. the binding
will do the right thing if the qualified intent is required). If only the
qualifiable form of the intent is required, then the behavior is the same as if
the qualified intent that corresponds to the default qualifier had been
required.
Michael
-----Original
Message-----
From: Joshi, Kaanu [mailto:Kaanu.Joshi@patni.com]
Sent: Friday, October 19, 2007 1:06 PM
To: OASIS Policy
Subject: [sca-policy] ISSUE POLICY-18 : Should qualifiable intents have a
default qualifier
Hi
folks,
The
link for this issue in the SCA Policy TC JIRA:
http://www.osoa.org/jira/browse/POLICY-18
Regards,
Kaanu
Joshi
________________________________________
From:
ashok malhotra [ashok.malhotra@oracle.com]
Sent:
Thursday, October 18, 2007 9:29 PM
To:
OASIS Policy
Subject:
[sca-policy] NEW ISSUE: Should qualifiable intens have a default qualifier
TARGET:
SCA Policy Framework
DESCRIPTION
: The transaction proposal needs to capture default
qualified
intent behavior
outside
of a policySet.
PROPOSAL:
PROVENANCE:
SCA-182 by booz on 2006-10-23 08:49:45
--
All
the best, Ashok
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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