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