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



Rich,

Good questions.

This is my simplistic view of the lifecycle of an SCA artifact as it relates to Policy.

I think that this is true whether the artifact is a SCDL file (a composite) or some implementation artifact like a Java class.

Developer writes the implementation artifact.
- may attach intents to things like services & references
- but only required for cases where the intent is an absolute requirement (eg MUST encrypt these messages)

Assembler builds composite, creating component(s) that use the implementation(s)
- may attach intents to services & references of composite and/or of components within the composite
- only required for cases where the intent is an absolute requirement...

Policy Expert creates one or more PolicySets
- Each PolicySet can claim to satisfy one or more intents (eg "confidentiality")

Deployer deploys the composite to the Domain
- deployer (logically) controls the contribution of PolicySets to the domain
- deployer decides on the attach points for particular PolicySets


Deployer specifies the attach points for the PolicySets in ONE of 2 ways (after Issue 15 is resolved  ;-) ):

1) Use the @PolicySets attribute of <service/> and <reference/> to directly attach PolicySets, either by modifying
the composite(s) being contributed, or through configuration of elements within deployment Composite(s).

2) Use @attachTo attribute of PolicySets or of PolicyAttachment elements to identify places to attach specific
policies

Method 1) is "slow & sure" - takes a lot of work, but it is absolutely clear what is attached to which places

Method 2) is quicker and more general - but takes work to create approriate attachment statements:

eg //service/binding.ws   - means "attach to all services with a WS binding"
eg //service/binding.ws/IntentRefs("confidentiality")  - means "attach to all services with a WS Binding with the intent
"confidentiality" applied"


The "final check" done by the SCA runtime is that for all elements deployed to the domain (ie services, references),
the actual PolicySets attached to them do satisfy all the stated intents.



I hope that this helps...

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



"Rich.Levinson" <rich.levinson@oracle.com>

21/07/2008 17:23

To
OASIS Policy <sca-policy@lists.oasis-open.org>
cc
Subject
Re: [sca-policy] [ISSUE 15] External attachment - Alternative Proposal





To Mike, Ashok, et al,

I have been trying to follow the discussion on issue 15. I understand
that  there is something important here that must be decided
and I am trying to get a clear picture of what that is, but have
been having some difficulty which I will try to explain (possibly
others are in same boat, and maybe my dilemma and its
explanation will help get the issue more clear all around):

I think what would be very useful is to show the life cycle of
a scdl file from its creation thru the intents being applied thru
the intents being resolved and explaining what is going on
at each phase wrt this issue.

It doesn't have to be a complex example, maybe something
simple like adding confidentiality and integrity to the external
Reference to the StockQuote service in the composite from
the SCA-Assembly ppt presentation:

http://www.oasis-open.org/committees/download.php/26768/SCA_Plenary_SCA_Assembly.ppt

   <reference name=“StockQuoteService" promote="AccountServiceComponent/StockQuoteService">
       <interface.java interface="services.stockquote.StockQuoteService"/>
       <binding.ws port=
"http://example.org/StockQuoteService#
         wsdl.endpoint(StockQuoteService/StockQuoteServiceSOAP)"
/>
   </reference>

One could quick describe how this scdl file came into existence - ex
someone created it using a sca-friendly xml tool.
(One might optionally say that pieces of the file could automatically
be generated by another tool that reads the .war file for example,
then selectively included in this composite)

Then one could say let's apply confidentiality and integrity to this
reference and insert the appropriate intents.

At this point I think we come to issue 15.

What I would like to see here is the state of affairs when it is time
to apply the concrete policies. Presumably the service has been
at least partially deployed and maybe someone is sitting at a
tool that says that it is time to apply policies to match these
intents.

Presumably one would have a list handy of possible policies,
possibly selected by their "provides" capabilities.

At this point it sounds, as I understand it, that issue 15 is
relevant. i.e. there are different scenarios that could happen
here when the concrete policy replaces the intent.

Let me know if this sounds like a useful course to pursue further.

   Thanks,
   Rich





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















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]