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 defn?
• disadvantage is that its 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/_at_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
Issue 22
Dave doesnt understand the requirement

• 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 _at_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