1. Service Component Architecture Policy TC Issue 33 Capabilities

2. Introducing “Capabilities” into the Policy FW n Introduction - Examples of the problem n Part 1 - Capabilities for runtime implementations l Two alternatives are presented (part1a and part1b) n Part 2 – Capabilities for service instances

3. Introducing “Capabilities” into the Policy FW n Optional policy configuration - examples l Runtime implementation n Java component container does not have access to a transaction manager, and therefore ALL component instances hosted by the container cannot exploit transaction policy. n Web service binding implementation does not have the ability to participate in a reliable message exchange. l Service instances (i.e. configured services) n Service will participate in a transaction if sent by the client, but does NOT require the client to send a transaction context. n Service will participate in a reliable message exchange if the client so desires, but does NOT require the client to use any reliable messaging mechanism.

4. Capabilities for Runtime Implementations – Part 1 n Enables design time validation of policy n How to express a constraint that reflects policy which CANNOT be supported/configured by the runtime? l Bindings and implementations are the ultimate targets of policy configuration l SCA has the and definitions which represent the types of bindings and component implementations available in any given runtime n SCA vendors will provide runtimes for each bindingType and implementationType that they support n Today, these definitions can only declare policy that: 1.will always be enabled (@alwaysProvides), or 2.can be enabled BUT is not configurable via policy set or binding specific configuration (@mayProvides)

5. Capabilities for Runtime Implementations Proposal (part1a) – Preferred Apporach n What’s missing is how to declare that a particular policy is not supportable by the runtime @neverProvides – QNames of policy intents Intents in the list are not supported by the binding implementation. Using section 4.12 step A definition of ‘required intent set’; It is an error if an intent that is in the ‘required intent set’ is also listed in the @neverProvides of a related bindingType(s). @neverProvides intents should be treated as mutually exclusive WRT inherited intents so that inherited intents can be ignored if they cannot be supported by child elements.

6. Capabilities for Runtime Implementations Proposal (part1b) - alternative n The corollary would be to provide a feature where the “known to be supported” policy is declared, any policy not listed is by definition unsupported. @provides – QNames of policy intents Only intents in the list are supported by the binding runtime. All other intents are implicitly not supported. It is an error to have intents in @alwaysProvides or @mayProvides that are not specified in @provides.

7. Capabilities for Runtime Implementations - sample comp1 can be detected as in error at design time. comp2 contains no detectable errors.

8. Capabilities for Service Instances – Part 2 n Enables service design time expression of optional policy n How to express the desire for an optional policy? l SCA services can require that specific policy is enabled (@requires) n All clients (references) end up being forced to comply to the service’s requirements, even if they don’t really need to. l Policy compatibility is defined as the intersection of consumer and provider policy l But, there is no way to express what policy alternatives are provided by a policySet Cheap solution: Create as many services as are needed to express all the desired policy alternatives

9. Capabilities for Service Instances n What’s missing is how to declare that a particular policy is optionally available for use @optionallyProvides – QNames of policy intents Any listed intent is represented by concrete policy in at least one of the policy alternatives in the policySet. @options – QNames of policy intents. For service only. Any listed intent is satisfied by a policySet that @optionallyProvides the same intent.

10. Capabilities for Service Instances - sample <policySet name="exa1" provides="sca:integrity" optionallyProvides="sca:atLeastOnce" appliesTo="binding.ws"> During deployment of comp1, exa1 is attached by the FW as usual When comp2 is deployed, a policySet which satisfies ref1 can be attached. At runtime, the policy intersection will result in picking the second alternative.