[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
I'll try to do this inline <dab> </dab>
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/28/2007 04:39 <sca-policy@lists.oasis-open.org>
AM cc
Subject
RE: [sca-policy] ISSUE POLICY-18 :
Should qualifiable intents have a
default qualifier
Dave,
Comments inline.
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
David Booz <booz@us.ibm.com> wrote on 27/11/2007 22:24:35:
> 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.
>
It is good to worry about complexity - I'm with you there.
But what are the "more fundamental" problems?
<dab> you commented on them below :-) </dab>
> 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.
>
But the question for the binding.sca is how does it handle the case where
it>
supports a qualified intent, but the service or reference only specifies
the unqualified form? Which of the qualified forms does it use?
<dab> The answer should be the same as for any other binding. </dab>
I suppose that this could be part of some "configuration" of binding.sca,
but
we have no place for this today.
<dab> Sure we do, we have bindingType and policySet. Binding.sca should be
no different
in this respect than any other binding. </dab>
> 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.
>
Well, it has the bearing that IF the bindingType satisfies the intent, then
there is no need to search for a policySet to apply to the binding.
<dab> I think we need to seperate those two semantics. I think it should
be possible for
a binding to indicate what it is configurable to do, not just what it does
by default. I'm
simply saying that I think we should (re)consider how this works. I don't
find this
justification in Michael R's proposal to be compelling WRT adding a second
defaulting mechanism. </dab>
> 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.
Well, to be fair, going way back when Chris Sharp was involved with this
effort, we did make some big efforts to use WS-Policy and WS-Policy
attachment
without extensions.
The basic problem is that IF you have some domain of policy, say such as
confidentiality (encryption), there is no obvious way within WS-Policy to
link
some intent name (typically a qualifier) to a particular policy within a
policy file.
That was why intent maps were created.
<dab> Yes, I know. I was there. Maybe we need to try harder or think about
the problem
differently. I'm not making proposals yet, just observations. If no one
else agrees then
I'm not going to waste my time on a proposal. </dab>
The idea of intents in the first place is to provide some simple high level
means that a developer or an assembler can indicate requirements. There is
a
deliberate separation from low level policies since the low level policies
may change from installation to installation and may change with a change
of
bindings (say). Without the indirection provided by intents, this can't be
done.
Once you have indirection, there has to be some form of mechanics to
resolve
the indirection. Intent maps are the way in which this is done currently.
There may be other possible approaches, but without some mechanism, the
whole
idea of intents will not work.
<dab> I wasn't trying to throw out intents or the valuable indirection they
provide. </dab>
Optional, exactly one, etc don't provide indirection. Indeed, I don't
think
there is anything within WS-Policy that would provide this sort of
capability.
<dab> I think you've confused two aspects of the FW. IntentMaps don't give
you indirection,
policySets do. All that intentMaps give you is a selection capabilty
within the policy.
WS-Policy also have selection capability. As part of providing a selection
capability,
intentMaps necessarily introduce a defaulting mechanism, _ but_ is that
the right place
for the defaulting mechanism? All that I'm observing is that we have two
competing ways
of specifying qualified intent defaults. You can't have two defaults.
Defaults should always
have a cardinality of one. The fact that (with this proposal) we have two
defaults raises a
red flag that the architecture is wrong. There are also other problems
with intentMaps
as described in other open issues. I'm looking at this from a holistic
perspective. </dab>
Unless someone thinks that WS-PolicyAttachment could be bent to suit our
needs.
I have now reached the start of a new path that leads I know not where -
but
there are lots of thorn bushes along the way. I'll need some encouragement
before stepping further down there.
>
> 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.
Hmm.>
>
>
> 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
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]