sca-policy message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-policy] [ISSUE 15] External attachment - Alternative Proposal
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Policy" <sca-policy@lists.oasis-open.org>
- Date: Mon, 7 Jul 2008 12:49:24 +0100
Ashok,
I'm glad to see that you are sympathetic
to the proposal over all ;-)
That is one good step forwards.
Let me try to deal with the usecase
you raise - first let me check that I understand it properly, then
I'll show how my proposal would deal
with it.
---------------------------------------------------------
Usecase:
Company has a set of corporate policies
that must be used for all communications between components
in their applications. These policies
happen to include the use of certain types of encryption, message
signing, reliable (once and once only)
messaging (and so on). These are to be used in all cases, whether
or not any of the components are explicitly
marked to require these features.
Let us make one further assumption -
that IF the company allows the use of more than one transport, then
these policies are "interpreted"
for each of the transports used. ie, if the company uses Web services
and also uses JMS (say over MQSeries...),
then the detailed low-level policies are separately defined
for each transport, since the details
are likely to differ.
Edwards' Issue 15 Proposal approach:
For each transport (hence my extra assumption
above):
- Define a single overall policySet
(say "Corporate_Policy_1"), which either contains all the necessary
policies
or it contains references to other more
granular policySets that deal with particular areas of policies.
- Where this overall policySet actually
provides one or more Intents such as confidentiality, it is worth saying
so on this policySet, to avoid getting
errors where some component is marked as requiring one or more of these
intents (note that any unsatisfied intents
will be flagged as an error)
- Set the "appliesTo" attribute
of "Corporate_Policy_1" so that it applies to bindings of the
relevant type, such as
Web services (//binding,ws)
- Set up the "attachTo" attribute
of "Corporate_Policy_1" to attach it to ALL relevant places -
such as "all components"
(//component) or "all services
and all references" (//service, etc)
When Corporate_Policy_1 is deployed
into the Domain, it will thus get applied to all services & refererences
of all
components using the relevant binding(s).
To ensure that Corporate_Policy_1 gets used over any other policySets
that might get attached, give it the
highest priority in the Domain. If something less dictatorial is
required, play with
the priority setting so that other policySets
can get a look-in in the right circumstances...
---------------------------------------------------------
I think that this provides what your
use case is looking for. If not, then I've misunderstood the use
case or I've
failed to understand my own proposal
- either is a possibility ;-)
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
ashok malhotra <ashok.malhotra@oracle.com>
03/07/2008 00:43
Please respond to
ashok.malhotra@oracle.com |
|
To
| Mike Edwards/UK/IBM@IBMGB
|
cc
| OASIS Policy <sca-policy@lists.oasis-open.org>
|
Subject
| Re: [sca-policy] [ISSUE 15] External
attachment - Alternative Proposal |
|
Hi Mike:
I'm sympathetic to this proposal but I want to make sure I understand it
completely.
If I have an intent attached to a SCDL element, that intent must be
satisfied either by a policy in a policySet
that is directly attached to the SCDL element or a policySet using the
external attachment mechanism.
If this is correct, it does not address the usecase where I have a set
of corporate policies that specify how
encryption, authentication etc. must be done but do not need to be
mentioned explicitly. They are pulled
in at deployment time to address appropriate intents and can be changed
independently of the SCDL.
I think this is a significant usecase.
All the best, Ashok
Mike Edwards wrote:
>
> Folks,
>
> Here is the alternative proposal for Issue 15 that we have been
> working on:
>
>
>
> 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/
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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]