Service Component Architecture (SCA) Policy TC

…

Face to Face Agenda – Jan 24,25 2008

F2F Agenda - Major Topics 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

Should we put compliance

testing on the agenda ???

Compliance Language

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

We could wait and see how far

Assembly TC progresses

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.

Easy Issues

Issue 37

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

Issues with a Proposal thatneed discussion

Issue 15

Proposal for external attachment of intents and policySets See also Policy 23 and Policy 28

Issue 23

Need support for message level attachment of policy Does the proposal of Policy 15 resolve this?

Issue 28

Add the ability to attach policy directly to an SCA composite (SCDL) See also Policy 15

Issue 18

Should qualifiable intents have a default qualifier? See email chain on this topic

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

Issue 26

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

Issue 39

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

Issue 27

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

Issue 42

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

Issue 43

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

Issue 19

We need a way to apply a policy pattern (or a group of policies) to a composition IBM has a proposal

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

Issue 11

Original problem: Concern is how to differentiate conceptually

between binding configuration and a policySet.

Issue 20

Should intents have a default policySet?

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.

Issue 22

Portmanteau intents: http://www.osoa.org/jira/browse/POLICY-22

Dave doesn’t understand the

requirement

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

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

Issue 30

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

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

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

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

Issue 36

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

Issue 40

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