[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]