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

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

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

4. Interaction v. Implementation n What is the relationship between implementation intents and interaction intents, ala the transaction specification. l Does a client ever need to be aware of an implementation intent? n Assert NO for now l 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. l Do we need a new concept for implementation policy (other than intent)? n 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 n 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 n 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 n The URL for the location of the ws- policy.xsd is incorrect. l http://www.osoa.org/jira/browse/POLICY-37

7. Issues with a Proposal that need discussion

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

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

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

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

12. Issue 24 n 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. l http://www.osoa.org/jira/browse/POLICY-24

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

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

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

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

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

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

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

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

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

22. Issue 21 n 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. Issue 22 n Portmanteau intents: l http://www.osoa.org/jira/browse/POLICY-22 Dave doesn’t understand the requirement

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

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

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

27. Issue 32 n Security intent which allows a client to authenticate a server l 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. l See Policy 33

28. Issue 33 n Need the ability to express capabilities l 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. l See Policy 32

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

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

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