RE: RE: [sca-policy] NEW ISSUE: How to configure policySets

["Joshi, Kaanu" <Kaanu.Joshi@patni.com>]

Done.

The URL for this issue in the SCA POLICY JIRA is: http://www.osoa.org/jira/browse/POLICY-46.

Regards,
Kaanu Joshi

-----Original Message-----
From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
Sent: Wednesday, January 30, 2008 9:35 AM
To: ashok.malhotra@oracle.com; OASIS Policy
Subject: RE: [sca-policy] NEW ISSUE: How to configure policySets


[Can we have an issue number assigned asap, please]

Some comments inline ...

> -----Original Message-----
> From: ashok malhotra [mailto:ashok.malhotra@oracle.com]
> Sent: Tuesday, Jan 29, 2008 6:29 AM
> To: OASIS Policy
> Subject: [sca-policy] NEW ISSUE: How to configure policySets
>
> TARGET:  SCA Policy Framework
>
> DESCRIPTION :
>
> The current SCA Policy Framework supports the specification of intents
> and policySets on SCDL elements using attributes.
> For example:
>
> <service> or <reference>
>
> <binding name = "xs:string"
>
> policySet="xs:QName"? requires="="listOfQNames"? />
>
> </service> or </reference>
>
>
> There are a couple of problems with this approach.
>
>
> 1. Attributes are not extensible.  If the intents and policySets were
> specified as child elements, this would  permit extensibility.  In the
> f2f meeting last week the argument was made that some extensibility
> was required to allow runtime extension of policies with information
> like the location of the key store  or the type  of certificate
> required.

I am guessing that you want to support binding configuration by allowing extensibility of policySets but not standardize the configuration model itself. Am I right?


>
>
> 2. If the 'requires' attribute is  used in conjunction with a
> policySet attribute it's not clear what the semantics are.
> At one time the intents in the 'requires'  list  were used to
> configure the  policySets  but that  meaning seems  to have been lost.

I think we would still want to keep the intents mechanism such that the developers can express abstract requirements and deployers can validate any selected bindings for the concerned wire, right?

>
>
> PROPOSAL:
>
> For the  reasons cited above,  I suggest that policySets and intents
> be associated with SCDL elements using child elements.
> For example:
>
> <service> or <reference>
>
> <binding name = "xs:string"
>
> <policySet name="xs:QName" select="xs:string"*> *
>      <requires name ="xs:QName"/> *
>
> </service> or </reference>

I understand why we might want to have policySet as an element. I am not sure why we would want to make 'requires' as an element (vs. an attribute)?

-- Sanjay

>
>
> Each "policySet" element would name a single policySet.  The "select"
> attribute could contain a list of xs:strings which would name
> qualified intents and customize the use of the policySet by selecting
> specific options from the intentMaps within the policySet.
>
> For symmetry,  the "requires" element also names a single intent but
> this is not necessary.  It could be changed to take a list of intent
> names as long as there was no need to customize the intents.
>
> --
> All the best, Ashok
>
> ---------------------------------------------------------------------
> 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_workgr
> oups.php
>
>

---------------------------------------------------------------------
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


http://www.patni.com
World-Wide Partnerships. World-Class Solutions.
_____________________________________________________________________

This e-mail message may contain proprietary, confidential or legally
privileged information for the sole use of the person or entity to
whom this message was originally addressed. Any review, e-transmission
dissemination or other use of or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you have received this e-mail in error
kindly delete  this e-mail from your records. If it appears that this
mail has been forwarded to you without proper authority, please notify
us immediately at netadmin@patni.com and delete this mail. 
_____________________________________________________________________