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: Tue, 22 Jul 2008 13:35:08 +0100
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
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]