Raw minutes from today's call

[Graham Charters <CHARTERS@uk.ibm.com>]

Mark Combellack: - Roll Call
http://www.oasis-open.org/committees/membership.php?wg_abbrev=sca-j
- Appointment of scribe. List attached below
- Agenda bashing
- Approval of minutes for 27th March 2009
http://www.oasis-open.org/committees/download.php/31863/SCA%20Java%20Minutes%202009-03-27.doc


0. Administration 
- Issue Status: Open: 17


1. Review action items:

Action Items that I believe are done:

Action Items that I believe are still to be done:
2008-11-11-22: Mark to draw up some wording for Direction 1 (as discussed
at the November F2F) for JAVA-62
2008-11-11-23: Mark (and others prepared to help) to investigate the WorkManager
JEE spec and determine its applicability to SCA for JAVA-62
2009-02-23-06: Simon to write proposal for Java 131
2009-03-20-02: Simon to raise an issue about inconsistent normative statements
with respect to XML/JAXB mapping in section 10


2. List A Issues - Must be resolved before Public Review

None


3. Blocked List A Issues - Must be resolved before Public Review waiting
for updates/proposals

None


4. List B Issues - Nice to resolve before Public Review

a. JAVA-98: Can annotations be inherited
http://www.osoa.org/jira/browse/JAVA-98
Original Outline Proposal: http://lists.oasis-open.org/archives/sca-j/200902/msg00192.html
Alternative Proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00059.html
Updated proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00150.html
Summary email: http://lists.oasis-open.org/archives/sca-j/200903/msg00211.html


5. Blocked List B Issues - Nice to resolve before Public Review waiting
for updates/proposals

None

6. New Issues (Requires 2/3s of Voting members to open)

None


7. List C "10 Minute" Issues

a. JAVA-1: Accessing SCA Services from non-SCA component code
http://www.osoa.org/jira/browse/JAVA-1
Discussion: http://lists.oasis-open.org/archives/sca-j/200903/msg00160.html
Updated Proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00160.html
Updated Proposal (PDF): http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31769/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%203.pdf

b. JAVA-144: Possible confusion over whether @Service can specify both
a class and an interface
http://www.osoa.org/jira/browse/JAVA-144
Proposal in Jira

c. JAVA-148: Java CAA missing full definition of annotations applying to
Java Interfaces
http://www.osoa.org/jira/browse/JAVA-148
Proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00175.html

d. JAVA-152: Java C&I should have had corresponding changes in JAVA-134
http://www.osoa.org/jira/browse/JAVA-152
Proposal in Jira

e. JAVA-153: Java CI should have corresponding changes in JAVA-125
http://www.osoa.org/jira/browse/JAVA-153
Proposal in Jira


8. Other List C Issues

a. JAVA-139: Default value for SCA property is not supported for java implementations
http://www.osoa.org/jira/browse/JAVA-139
Outline of proposal in Jira

b. JAVA-127: Long running request/response operations
http://www.osoa.org/jira/browse/JAVA-127
Proposal: http://lists.oasis-open.org/archives/sca-j/200812/msg00089.html

c. JAVA-143: Guidelines for dealing with cyclic references refers to an
impossible situation
http://www.osoa.org/jira/browse/JAVA-143
Proposal in Jira


9. AOB


---------------------------------------------------------------
Rotating scribe list:

Ron Barack SAP AG (3)
Michael Beisiegel IBM (3)
Sanjay Patil SAP AG (3)
Jim Marino Individual (4)
Pradeep Simha TIBCO Software Inc. (5)
Vamsavardhana Chillakuru IBM (3)
Plamen Pavlov SAP AG (2)
Graham Charters IBM (1)
Meeraj Kunnumpurath Individual (3)
Mike Edwards IBM (8 )
Simon Nash Individual (6)
Martin Chapman Oracle Corporation (8 ) 
Bryan Aupperle IBM (9)
Anish Karmarkar Oracle Corporation (10)
Ashok Malhotra Oracle Corporation (9)
Yang Lei (6)
Mike Edwards: Some very superior Mozart
Graham Charters: Scribe: Graham Charters
Graham Charters: Agenda Bashing:
Graham Charters: No comments/amendments.
Graham Charters: Minutes Approval:
Graham Charters: No comments.  Approved
as posted.
Graham Charters: Review of Action Items:
Graham Charters: All action items ongoing.
Graham Charters: No List A issues.
Graham Charters: List B issues:
Graham Charters: Java-98 - can annotations
be inherited.
anonymous morphed into anish
Graham Charters: Simon presented the four questions
to be answered...
anish for example, what if @Confidentiality has
'description' attribute
Graham Charters: Simon N suggests SCA should
only process metadata it understands and ignore any additional information
(other meta-annotations).  Dave B does not agree and think this needs
constraining to forbid additional meta-annotations.
Graham Charters: Simon N describes how we might
merge @Requires with specific intents (e.g. @Confidentiality)
Graham Charters: Suggestion is the specific
intents win over @Requires.
Graham Charters: Two specific intents which
contradict (try to configure the same base intent) should be an error.
Graham Charters: Mike E does not see a need
for a priority between @Requires and specific intents.  @Requires
can have multiple definitions for the same intents, so we have general
rules for handling this.
Graham Charters: Mike E: @Requires and @Confidentiality
should just produce intent string which are merged according to existing
rules.
Graham Charters: The annotations which produce
them has no baring on the merging.
Graham Charters: Simon N: Mike's proposal means
we do not needs to restrict the specific annotations.  SCA should
just 'extract' the intent strings and ignore anything extra.
Graham Charters: Dave B is ok with this.  The
important thing is the intents are ultimately identified by qname.
Graham Charters: All seem to be in agreement
in this first point (point A).
Graham Charters: Anish: we need to decide if
we want specific annotations...
Graham Charters: Simon N: they seem simple
and are syntactic sugar.  Get round the limitation of only allowed
1 @Requires annotations.
Graham Charters: Anish: does not like specifying
two ways to do two things.  Also does not like the requirement that
the developer has to do the mental merge.  Also made other points...
Graham Charters: Anish: concerned that these
specific annotations are effectively new and need some thought.
Graham Charters: Mike E/Simon N: argue they've
been around for a while and people are using them.  Chances are people
are not combining them in the ways which are ambiguous.
Graham Charters: Mike E/Simon N: argue they've
been around for a while and people are using them.  Chances are people
are not combining them in the ways which are ambiguous.
Graham Charters: Simon N: most people will
not need to write @Requires, which is a good argument for keeping the specific,
for the common and simple cases.
Graham Charters: Motion: Anish moves that we
remove the specific annotations for intents.
Graham Charters: Ashok seconds.
Graham Charters: Mike and Simon object.
Graham Charters: Vote:
Graham Charters: Yes 3, No 8 - motion failed
anonymous morphed into Pradeep
Graham Charters: The specific annotations remain.
Graham Charters: Point B:
Mike Edwards: The CAA spec currently says this:
Mike Edwards: Where multiple intent annotations
(general or specific) are applied to the same Java element, they are additive
in effect.  An example of multiple policy annotations being used together
follows:
@Authentication
@Requires({CONFIDENTIALITY_MESSAGE, INTEGRITY_MESSAGE})
In this case, the effective intents are "authentication", "confidentiality.message"
and "integrity.message".
If an annotation is specified at both the class/interface level and the
method or field level, then the method or field level annotation completely
overrides the class level annotation of the same base intent name.
Graham Charters: Policy describes that higher
level policy is merged down into lower level.  Most qualified is taken
in preference to generic.  Also rules in how mutually exclusive conflicts
are throw away at the lower level.
Graham Charters: Simon N: what was written
down in the earlier proposal was that method would win over class, irrespective
of whether one was more specific.
Graham Charters: Mutually exclusive at the
same level in the hierarchy is an error.
Graham Charters: Anish: why can't we use the
same merging rules we used for point A?
Graham Charters: Anish: It seems the rules
are the same.  The process of merging is just putting them all in
the same bucket.  Whether they came from class level, methods level,
@Requires, @Confidentiality is irrelevant.
Graham Charters: Mike E: Yes, exception for
mutually exclusive intents.
Graham Charters: Mike E: Yes, except for mutually
exclusive intents.
Graham Charters: Clarification: The hierarchy
being discussed is the XML Assembly hierarchy.
Graham Charters: General agreement that we
should be consistent in how we merge (XML merge and Java merge).
anish: +1 to consistency
Graham Charters: Simon N: the consistency argument
is compelling.
Graham Charters: Simon N: working assumption
on Point B is we should follow what the Policy spec describes.
Graham Charters: Point B.5 (a new point between
B and C

 ).
 Are references within a class part of the hierarchy?  Mike E
thinks they're independent.
Graham Charters: Mike E: problems occur if
you have an intent on the service which you don't want on the reference.
 There's no mechanism to remove.
Graham Charters: Point C - proposal.  There
is no hierarchy where intents are specified on impl and interface.
Graham Charters: Mike E: we must honor what's
on the interfaces (it's the external contract), but we could further restrict.
Graham Charters: Bryan A: this needs clarification
in Policy.  Interface should never be overridden.
Graham Charters: Simon N: merge interface and
impl independently, then merge the two buckets.
Graham Charters: Anish: if I have an intent
on interface A, it applies to all methods in that interface.  If I
have interface B with an intent, it applies to all methods in B.  What
if I have a class which implements both.  Impls of interface A methods
inherit its intents, impls of interface B methods inherit its intents.
 Those methods in common inherit both.
Graham Charters: Mike E: concerned about impl
intents like managedTransaction.  It should apply to the whole implementation.
Graham Charters: Simon N: perhaps we shouldn't
be allowed to put impl intents in an interface.
Graham Charters: Simon N: we should fix this
problem with impl intents.  Anish's proposal works for interactions
intents.
Graham Charters: Simon N: working assumption
is we'll go with Anish's proposal.
Graham Charters: Simon N: start with interface.
 Compute effective intents using the usual interface rules.  If
there are additional intents on the Reference then they get combined with
the intent strings on every method (no hierarchy, just additive combination).
Graham Charters: Anish: how do intents on methods
apply to assembly...
Graham Charters: Point D: There is no way to
express intents on the methods of a service or reference in Assembly.
Graham Charters: Simon N: we need some way
to synthesize an interface and then in the virtual component type we have
the synthesized interface carrying these intents.  This could be done
using a sub-interface or class.
Graham Charters: Simon N: this is on the component
type so could be done at runtime internally.
Graham Charters: Anish: This is needed during
assembly.
Graham Charters: Simon N: should not have said
runtime.  It's a 'computed' interface.  Could just be a logical
definition that does not need to physically exist.
Graham Charters: Disconnect...Simon/Anish were
talking a cross-purposes.
Mark Combellack: We are practically out of
time
Mike Edwards: Time gentlemen please!!
Graham Charters: Discussion deferred to mailing
list or next call...
Graham Charters: AOB
Graham Charters: The End....


Regards,

Graham.



Graham Charters PhD CEng MBCS CITP
STSM, AIM Technical Lead OSGi Expert Groups, Master Inventor, UKI Technical
Staff Member
IBM United Kingdom Limited, MP 146, Hursley Park, Winchester, SO21 2JN,
UK
Tel:  (Ext) +44-1962-816527     (Int) 7-246527   (Fax)
+44-1962-818999
Internet: charters@uk.ibm.com

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU