OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



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]