sca-policy message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sca-policy] ISSUE POLICY-18 : Should qualifiable intents have adefault qualifier
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Policy" <sca-policy@lists.oasis-open.org>
- Date: Thu, 22 Nov 2007 13:59:36 +0000
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?).
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".
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.
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?
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 !
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]