RE: [sca-policy] Few questions related to external attachments

[David Booz <booz@us.ibm.com>]

As I understand the IPA vs EPA proposal from Anish and yourself, inlining and direct attachment to a component are essentially the same thing, where direct attachment to a component is a form of inlining. That is, the following is a policySet attached to a component. I believe your IPA v EPA proposal calls this inlining.

<component>
<implementation.java class="foo" policySet="xs:implPolicy">
</implementation.java>
</component>

Unlike interaction policy, we've found implementation policy very difficult to represent via intents. This is the fundamental observation behind my concern. I can live with interaction policy attached exclusively via EPA mechanism because we have intents that can still capture policy requirements in the "application". For implementation policy, there is not existing viable mechanism to capturing abstract implementation policy. Authorization is a good example. Back in OSOA, we tried, desperately at times, to construct an intent model that could represent authorization policy, but were unable to do it. What we ended up with was inventing a policy language that would live inside policySets. Authorization policy is very tied to the combination of the component (the context it is defined within) and it's interface, thus it's a natural fit for direct attachment. The Java spec then went and built Java annotations for the policy language, pushing the "attachment" into the impl itself.



Dave Booz
STSM, BPM and SCA 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
"Patil, Sanjay" <sanjay.patil@sap.com>

"Patil, Sanjay" <sanjay.patil@sap.com>

09/15/2008 01:28 PM

To	David Booz/Poughkeepsie/IBM@IBMUS, "Anish Karmarkar" <Anish.Karmarkar@oracle.com>
cc	"OASIS Policy" <sca-policy@lists.oasis-open.org>
Subject	RE: [sca-policy] Few questions related to external attachments

Hi Dave,

Could you please elaborate further upon your answer to Anish's question 3). In particular, can you please provide some example scenarios for inlining implementation policies in the composites. Also, what do you mean when you say 'attached to components'? Is this case different from inlining policies in a composite?

Thanks,
Sanjay

---

From: David Booz [mailto:booz@us.ibm.com] 
Sent: Monday, Sep 15, 2008 7:42 AM
To: Anish Karmarkar
Cc: OASIS Policy
Subject: Re: [sca-policy] Few questions related to external attachments

Answering 3) I meant inlined in composites, attached to components AND inlined in component implementations (componentTypes).

You didn't address 1 and 2 to me, but while I'm here:
1) In the case of bindings we have said that
bindings on internal wires stay the same regardless of promotion. Is
that applicable to policies as well? YES

2) If the composite has a security policy, does it override the transaction policy? NO


Dave Booz
STSM, BPM and SCA 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
Anish Karmarkar <Anish.Karmarkar@oracle.com>

Anish Karmarkar <Anish.Karmarkar@oracle.com>

09/15/2008 10:13 AM

To	OASIS Policy <sca-policy@lists.oasis-open.org>
cc
Subject	[sca-policy] Few questions related to external attachments

Sanjay, Ashok and I had some discussion related to external attachments
as they apply to policy. Few questions came out of that discussion that
I would like to bring up here:

1) For the cases where inlined polices are specified in a composite, do
policies specified on an internal wire (of a hierarchical composite) get
overridden by policies specified on promoted service/reference, as they
apply to that internal wire? In the case of bindings we have said that
bindings on internal wires stay the same regardless of promotion. Is
that applicable to policies as well?

2) How does inlined component policy override of policies in component
type work when the polices are for different domains?
For example, a component type may have a transaction policy. If the
composite has a security policy, does it override the transaction policy?

3) For Dave: I understand that you mentioned on one of the calls (for
which I was not present) that implementation policies would be required
to be inlined. Are such policies confined only to component type
(because they are closely associated with the code) or are they included
in composites as well.

Thanks.

-Anish
--

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php