Service Component Architecture (SCA) Policy TC

1. Service Component Architecture(SCA) Policy TC … Face to Face Agenda – Jan 24,25 2008

2. F2F Agenda - Major Topics Should we put compliance testing on the agenda ??? • Compliance Language • Compliance Testing • Technical Items • Issue 15/23/28 – External Attachment • Interaction intents vs. Implementation Intents • Issue 18 – Default qualifiers • Issue 24 – Structural form for qualified intents • Issue 11 – What is the difference between policy and binding configuration • Issue 29/31 – When is policy in effect? • Issue 32/33 – Expressing capabilities

3. Compliance Language We could wait and see how far Assembly TC progresses • Compliance targets proposal • Document style? • All normative, or marked normative sections • What is our approach for transforming the document itself? • Is it a separate piece of work to decide on optional aspects of the spec? • See Policy 35

4. Interaction v. Implementation • What is the relationship between implementation intents and interaction intents, ala the transaction specification. • Does a client ever need to be aware of an implementation intent? • Assert NO for now • Is an implementation intent more like an interaction intent or more like a binding configuration? Most seem to think it is more like the latter. • Do we need a new concept for implementation policy (other than intent)? • Similarities between interaction intents and the new concept: annotations in Java, specified/attached to composites which apply to all “elements” of a composite, express configuration • some people liked “container assertions” as a concept name • Differences – this new form is parameterizable • would we specify this config in an implementation-type def’n? • disadvantage is that it’s harder to universally define how to configure transactions for many implementation-types • new name has surfaced – “common configuration options” • common across implementation-types • much simpler than the current intent model, and most of the current policy FW spec would not apply to this new concept.

5. Easy Issues

6. Issue 37 • The URL for the location of the ws-policy.xsd is incorrect. • http://www.osoa.org/jira/browse/POLICY-37

7. Issues with a Proposal thatneed discussion

8. Issue 15 • Proposal for external attachment of intents and policySets • See also Policy 23 and Policy 28

9. Issue 23 • Need support for message level attachment of policy • Does the proposal of Policy 15 resolve this?

10. Issue 28 • Add the ability to attach policy directly to an SCA composite (SCDL) • See also Policy 15

11. Issue 18 • Should qualifiable intents have a default qualifier? • See email chain on this topic

12. Issue 24 • Qualifiers are defined for intents by defining a new intent with a dot qualified name, where the name following the dot is the qualifier. A more structurally obvious technique for defining qualifiers should be investigated. • http://www.osoa.org/jira/browse/POLICY-24

13. Issue 26 • Security implementation policy should be validate-able by schema • http://www.osoa.org/jira/browse/POLICY-26

14. Issue 39 • Need Support for Mutually exclusive intents • http://www.osoa.org/jira/browse/POLICY-39

15. Issue 27 • Operation level policy attachment is broken • http://www.osoa.org/jira/browse/POLICY-27 • See also Policy 15

16. Issue 42 • Infoset for policySet/@appliesTo • http://www.osoa.org/jira/browse/POLICY-42

17. Issue 43 • Use of intents from component types in policySet algorithm • http://www.osoa.org/jira/browse/POLICY-43

18. Issue 19 • We need a way to apply a policy pattern (or a group of policies) to a composition • IBM has a proposal

19. Issues that need Proposal(and possibly some discussion to get it started)

20. Issue 11 • Original problem: • Concern is how to differentiate conceptually between binding configuration and a policySet.

21. Issue 20 • Should intents have a default policySet?

22. Issue 21 • When the specification of a binding type indicates that an intent is always provided, does that intent have to be listed in the alwaysprovides element of a binding.type? What happens if it is not listed, as according to the spec it is always provided.

23. Dave doesn’t understand the requirement Issue 22 • Portmanteau intents: • http://www.osoa.org/jira/browse/POLICY-22

24. Issue 29 • Need more precision on when policies in a policySet are in effect • It is not clear whether policies in a policySet that are not referenced by the list of required intents are always applicable. • See Policy 31

25. Issue 31 • Is it possible to use only a piece of a more general policySet? • Are policies from a policySet in effect just because the containing policySet is attached to the SCA construct? • http://www.osoa.org/jira/browse/POLICY-31 • See Policy 29

26. Issue 30 • Is the policy (specified in intentMap) from multiple qualified intents in effect? • http://www.osoa.org/jira/browse/POLICY-30

27. Issue 32 • Security intent which allows a client to authenticate a server • SCA Policy should define an intent which enables a client to request that a server authenticate itself to the client, so that the client knows it can trust the server. • See Policy 33

28. Issue 33 • Need the ability to express capabilities • How does a service express capabilities that it can provide (like authentication) without requiring that the client reference also @require those same intents in order to create a valid wire. • See Policy 32

29. Issue 35 • Wiring from a reference with no binding to a service with a binding • http://www.osoa.org/jira/browse/POLICY-34 • See also Assembly-31

30. Issue 36 • Add intents for all existing WS-I profiles • http://www.osoa.org/jira/browse/POLICY-36

31. Issue 40 • Fix SCA Policy schema complex types for Qualifier and PolicySet • http://www.osoa.org/jira/browse/POLICY-40