1 / 31

Service Component Architecture (SCA) Policy TC

Service Component Architecture (SCA) Policy TC. …. Face to Face Agenda – Jan 24,25 2008. F2F Agenda - Major Topics. Should we put compliance testing on the agenda ???. Compliance Language Compliance Testing Technical Items Issue 15/23/28 – External Attachment

creola
Download Presentation

Service Component Architecture (SCA) Policy TC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related