[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
Does anyone else think that having two defaults (default quallifiers AND
defaults in intent maps) is overly complex? I think the problems are more
fundamental.
I have a different perspective on (1) and (2) from Michael Rowley's email
below,
1) Any binding should be able to provide an intent without the need to add
a policySet. I see no reason why binding.sca is special in this regard.
2) @mayProvides on bindingType should be used solely to determine if a
binding can be attached to a service or reference based on what the service
or reference @requires. It has no bearing on policySet assignment to the
service or reference.
3) I think we should decide if we really want to keep intentMaps in the
model before we go down these complex cases. Perhaps we've overly
complicated the policySet model with intentMaps. For example (WS-Policy),
can we reuse more of the WS-Policy FW feature functions (optional,
exactlyOne, etc) without needing to put more FW on top of it.
I do realize the implications of what I've written. When the design starts
to get complex we should step back and examine the landscape from above the
trees. Feels like we're patching patches.
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
Mike Edwards
<mike_edwards@uk.
ibm.com> To
"OASIS Policy"
11/27/2007 04:27 <sca-policy@lists.oasis-open.org>
AM cc
Subject
RE: [sca-policy] ISSUE POLICY-18 :
Should qualifiable intents have a
default qualifier
Michael,
" In my opinion, my original words were easier to understand. Does that
description miss something?"
YES, it misses the cases where there are two or more qualified intents
"competing" with each other
to select out policy sets. Two different intents potentially make
different selections. How to resolve
such a conflict? Even my words leave it vague as to which one "wins" - it
just says that choosing in
favour of one can't mess up the resolution of the other one.
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>
To
27/11/2007 07:44 Mike Edwards/UK/IBM@IBMGB, "OASIS
Policy"
<sca-policy@lists.oasis-open.org>
cc
Subject
RE: [sca-policy] ISSUE POLICY-18 :
Should qualifiable intents have a
default qualifier
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>
To
20/11/2007 21:48 <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
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]