[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Feb 05 F2F minutes
_________________________________________________________________ Martin Chapman Consulting Member of Technical Staff Oracle P: +353 87 687 6654 e: martin.chapman@oracle.com
OASIS WS-CAF Technical Committee Face-to-Face meeting
9-10 February 2005
Welcome and introductions:
---------------------------------------
The meeting was hosted by Arjuna and Codeworks in Newcastle in the North East of England.
Roll Call:
-------------
Mark Little & Kevin Connor (Arjuna), Tony Fletcher (Choreology), Eric Newcomer (IONA), Martin Chapman & Greg Pavlik (Oracle), Doug Bunting (SUN)
It was agreed to make Kevin a full member of the TC as he has attended meetings and the interop, although he would only have met the specific defined criteria at the end of this meeting.
Initially the situation was thought to be that we had seven members present out of fourteen total voting members so the meeting was not quite quorate and needed people to dial in. Subsequent investigation discovered that Jeff Mischkinsky should not be a member having been warned and not then having attended meetings and so there are thirteen members of the TC, and so the meeting was deemed to be quorate. Jeff was susequently informed of this decision and did not dispute it.
Appointment of scribes:
----------------------------------
Tony agreed to scribe for a Wednesday morning, Kevin for the afternoon, Martin for Thursday morning and Doug for Thursday afternoon.
Agenda review and additions:
-----------------------------------------
Tony suggested taking Context issues earlier than Thursday afternoon. Agreed to move up to Wednesday morning.
Approval of outstanding minutes:
----------------------------------------------
Approval of outstanding minutes for 31 January 2005. Mark motioned and Greg seconded, and the minutes for 31 January 2005 were accepted with no objection.
Review of Actions:
--------------------------
There were no new Actions from the 31 January 2005 meeting.
General and context issues:
---------------------------------------
General:
Issue 124 Shall we include in the WSDL a binding for synchronous interaction style?
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=124
Martin : leave as is for the moment and wait for WSDL 2. WSDL 1.1 has portTypes and ports and in and out messages. Current 1.1 defined bindings (though these are not normative ) say in and out are on the same connection for HTTP and silent on the topic for other bindings. This is not reliable if there is a long time between the request and response. Do not want to invent addressing mechanisms to achieve good reliable performance. Mark motioned and Kevin seconded to close this issue with no action.
It was noted that one can add one's own WSDL to any of the CAF specifications.
The motion was agreed without objection.
Action: Martin / Mark to write up a response to this issue.
Action: Martin / Mark to raise another issue for the primer on the use of WSDL.
Issue 128 Some elements in the schemas are unnecessarily extended
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=128
Mark motioned and Doug seconded to close this issue with no change, but with a request for Simeon to come back with individual, specific examples.
Issue 143 OASIS namespace
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=143
Change namespace for the context CD. Yes, but need to observe the new OASIS TAB guidelines and the namespace has already been changed in the context CD.
Mark motioned and Greg seconded to close this issue with no action as it is an old issue. This was agreed without objection.
Issue 224 Mandate WSDL and SOAP?
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=224
Related to conformance. Mark motioned to say that if an implementation supports context / one ways then it must do according to the specification. Kevin seconded (i.e. optional to implement, but specification is normative if you do implement). Amendment from Doug: a conformant implementation must implement one ways according to the specification. Tony suggested putting conformance for the CAF stack in the highest level referencing specification in the CAF family. Eric said no as will not always have a referencing specification.
Greg: there are different conformance points in the specification. For instance may just comply with the context structure only, or with the structure and by the reference mechanism. Greg suggested a functional unit approach. Martin agreed with Tony that high-level specifications can/should add conformance statements for what they used, but also felt each should be usable stand-alone as Eric said. Doug suggested having a consistent statement on WSDL in all the CAF specifications.
Tony said that he supported what Greg said as well as what he had expressed.
Motion: if you use the facility then must do according to WSDL and text in the specification.
Agreed unanimously.
It was agreed that people can and should review the resulting text in WS-Context and raise new specific issues if necessary.
Issue 225 Addressing scheme
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=225
Use WS-Addressing rather than the open content model?
Martin reported that WS-Addressing has been changed at the last face-to-face and there is no specification to reflect this yet. Also should allow just use of URLs. No solid text to consider. Leave issue open and revisit once WS-Addressing is at Candidate Recommendation or later.
Tony motioned and Mark seconded to leave open and revisit once WS-Addressing is at CR stage.
Context Issue:
Issue 209 unknown-context-fault/context-identifier
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=209
Why is unknown-context-fault / context-identifier an anyURI, and not contextIdentifierType. One reason is contextIdentifierType is basically an anyURI though it does have wsu:id added.
Tony motioned and Martin seconded that we agree to change to contextIdentifierType. Agreed unanimously
Issue 214 Correlation ID in AssertionType should be removed
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=214
Correlation is now deferred to the addressing scheme and therefore we do not need this parameter any more. Also need to add text to context to describe this parameter and its use, if we retain. See note and figure 4 in WS-Context. Doug suggested making the note mention correlation and removing the word 'handled' plus removing the parameter. Doug proposed this and Mark seconded and it was passed unanimously.
Issue 218 Remove AssertionType and AssertionWithProtocolURIType
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=218
Tony motioned that we remove assertionWithProtocolType and all its contents.
Doug said that we do need to add text to WS-Context on how messages and contexts are extended.
Action: editors to add text on extensibility to WS-Context (and WS-CF as well?).
Tony motioned and Mark seconded to remove assertionWithProtocolType, amend the text as Doug suggested, and to add the note on extensibility. Agreed unanimously
Action: Doug to raise an issue on adding attribute extensibility, or adding in must understand attribute.
Issue 219 Remove wsu import and use XML Id instead - or justify
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=219
It was explained that wsu:Id is given special meaning in WS-Security and tools will look for wsu: namespace. WS-Context section 6 paragraph 3 does mention wsu:Id explicitly.
Mark proposed and Greg seconded to close this issue with no action and this was agreed.
Action: Tony to look up to use of wsu:Id in WS-Security to check that we have taken the correct action here.
Issue 220 Describe mandatory services first, as a general principle.
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=220
Major editorial.
It was pointed out that in fact both services are optional and the feeling is that the current order reads better than it would be if we were to change the order around.
Mark motioned and Greg seconded that we close this issue with editorial change and this was agreed.
Remove the optional statement in section 4, first paragraph, as this implies that this service is optional and the lack of such a statement against the other service implies that it might not be optional. The conformance section makes both optional.
Action: editors to adjust the text of section 4 for issue 220 http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=220
Issue 221 Parameters and Context on BEGIN and BEGUN?
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=221
It is stated in 5.2 that context may be present - does not say how, but implies in header if using SOAP. This would be spelt out in the binding.
Add a table that states which messages must have a context with them and which ones may optionally have a context with them.
Doug pointed out that it was his understanding that there could be several contexts with BEGIN and the service picks the one that corresponds to the type in BEGIN and builds a new context for BEGUN with the selected one. This raises an issue of should BEGUN echo all the other BEGIN contexts?
There is a related issue as to why 'get' and 'set' have context explicitly embedded in the message.
Current text does not say a context within a context has to be of same type. It was agreed to log a new issue on multiple contexts on one message, and also to log another new issue as to why 'get' and 'set' have embedded contexts.
State when a context is required and when optional on each operation and clean up the text on types of contexts.
Tony motioned and Mark seconded this proposal and it was passed unanimously.
Issue 222 Reference to the schema from the text
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=222
Martin motioned that the final version of each of the specifications include schema and WSDL as well as a reference to external versions of both the schema and WSDL, and include a statement in the specification that the schema and WSDL in the specification take precedence. This was seconded by Tony.
Doug agreed that there should be an accurate reference to the schema and WSDL external documents and also with the inclusion of a non normative Appendix, but disagreed with making the machine readable material in a non machine readable specification take precedence over a form that was directly machine readable.
He amended the motion to make the precedence lie with the referenced schema and WSDL files. Also need to make the statement that the fragments in the specification do not take precedence over referenced schema and WSDL.
Greg said that next time we should add an info set version.
Action: Greg to provide information / a proposal on adding an info set version of the schema.
It was agreed to make a precedence statement and have a clear reference to the specific WSDL and schema files and add an informative Appendix into specification with the WSDL and schema. It was also noted that the specification text takes precedence over the WSDL and schema files.
This motion was agreed unanimously
Issue 223 Consistency of specification approach
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=223
Accepted as an editorial to use a consistent style.
Action: editors to make make wsdl operation style consistent http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=223
Action: Tony to ask Peter to update his table on wsdl operations and resubmit (actually Tony will take on this task himself.).
Need to triage the list of issues submitted by Anish (Arjuna) and put them into Bugzilla, and then triage and address those that are substantive on the calls.
Action: editors to take a first pass and enter the resulting issues from Anish into Bugzilla.
WS-Coordination Framework:
------------------------------------------
Mark
Overview 5th February draft, mostly editorial clarifications of 0.2
Martin: We need a better way of tracking resolved issues
Mark: This is currently done by marking the issue as 'closed later' and then 'closed resolved' on resolution.
Martin: Any general comments on the specification?
Tony: General comments are in the contribution we have made.
Greg: There are comments in the specification requiring clarification
Triage/prioritization
Martin proposes to spend 30 secs on each one (73 bugs) to decide it if it is editorial/not an issue/technical issue.
Issue 144: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=144 - drop example
no longer relevant
closed, no action
Issue 145: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=145 - Roles and Responsibilities
no longer relevant
closed, no action
Issue 146: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=146 - Text clarification for coordination demarcation
no longer relevant
closed, no action
Issue 147: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=147 - WS-CF tied to WS-Context
no longer relevant
closed, no action
Issue 148: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=148 - WS-CF activity versus WS-Context activity
no longer relevant
closed, no action
Issue 149: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=149 -Text clarification for context propagation
no longer relevant
closed, no action
Issue 150: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=150 - Coordinator versus Coordination Service
no longer relevant
closed, no action
Issue 151: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=151 - Text related to ALS needs removing or modifying
no longer relevant
closed, no action
Issue 152: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=152 - Optional ALS text and diagram
no longer relevant
closed, no action
Issue 153: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=153 - Protocol configuration and negotiation section
no longer relevant
closed, no action
Issue 154: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=154 - Relationship to WSDL section
closed, resolved
Motined by Mark
Issue 155: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=155 - Coordination and activities section
closed, resolved
Motioned by Mark
Issue 156: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=156 - WS-CF components section
no longer relevant
closed, no action
Issue 157: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=157 - References to endpoints in messages
closed, resolved
Motioned by Mark
Issue 158: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=158 - Truncate interposition text
closed, resolved
Motioned by Mark
Issue 159: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=159 - Spec is more than “outline”
no longer relevant
closed, no action
Issue 160: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=160 - Multiple use of word “activity”
no longer relevant
closed, no action
Issue 161: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=161 - What is a Participant
no longer relevant
closed, no action
Issue 162: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=162 - Use of term “implementation of a Coordination Service”
ACTION: assigned to editorial to implement the suggestion
Issue 163: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=163 - WS-CF without Coordinator and Participant
no longer relevant
closed, no action
Issue 164: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=164 - Figure 1 problems
no longer relevant
closed, no action
Issue 165: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=165 - Protocol requirements
Not in the specification but is the four body diagram useful? (Mark, Martin)
MOTION: Mark – Tony shows the four body diagram, associated text and how it relates to CF.
SECONDED: Martin.
Issue 166: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=166 - Implementation of what ?
no longer relevant
closed, no action
Issue 167: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=167 - Coordinator, participant purpose and model
no longer relevant
closed, no action
Issue 168: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=168 - Activity hierarchy
Martin: context can have a partial hierarchy but not a graph. Do we insist on full tree? Need discussion. Accepted as an issue.
Issue 169: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=169 - Changing the coordinator
Martin: is it related to recovery?
Mark: just participant
Tony: our proposal allows the registrar to move as well as the coordinator.
Leave as an issue.
Issue 170: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=170 - URI for protocols and coordinator implementations
no longer relevant
closed, no action
Issue 171: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=171 - Invokes operation X on service Y
Action: assigned to editorial to remove
Issue 172: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=172 - Role names
no longer relevant
closed, no action
Issue 173: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=173 - Request/response or one-ways
no longer relevant
closed, no action
Issue 174: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=174 - Coordinator and ALS
no longer relevant
closed, no action
Issue 175: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=175 - Implementation and service
closed, duplicate of another open issue 162
Issue 176: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=176 - Coordination Service broadcasts ?
no longer relevant
closed, no action
Issue 177: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=177 - Participant service and CTX service
no longer relevant
closed, no action
Issue 178: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=178 - Service-to-coordinator, Client-to-coordinator messages fully contextualized ?
ACTION: assigned to editorial to clarify which operations require a context and whether it is a full context or just a context identifier.
Issue 179: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=179 - “call-back address” is ServiceCoordinator
no longer relevant
closed, no action
Issue 180: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=180 - ServiceCoordinator entities
no longer relevant
closed, no action
Issue 181: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=181 - Allow late enrollment
still an issue
Issue 182: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=182 - What defines beginning of completion
No complete in CF, need to rely on context
still an issue, needs discussion
Issue 183: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=183 - Multiple registration
closed, resolved
Up to referencing specification
Issue 184: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=184 - Fault for disallowed removeParticipant
ACTION: editorial. change the text so that the rules regarding the raising of the wrongState fault is the responsibility of the referencing specification.
Issue 185: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=185 - getParentCoordinator not needed
closed, no action
Issue 186: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=186 - How are qualifiers “registered with a coordinator service”
Mark: weren't qualifiers removed in Dublin?
Greg: Decided in Dublin that this was an overlap in policy.
ACTION: assigned to editorial – need to cleanup documentation
Issue 187: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=187 - Wsdl, request/reply, fields
ACTION: assigned to editorial – keep the same style for operational description
Issue 188: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=188 - How is ClientCoordinator endpoint known
closed, no action
Latest names can be reviewed and any issues raised.
Issue 189: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=189 - coordinator/ActivityCoordinator, enlisted participant/registered Participant
no longer relevant
closed, no action
Issue 190: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=190 - Context with no Activity ?
If it is an invalid activity then this should be pushed down to context, if it is an invalid coordinator it shouldn't be.
This is still an issue.
Issue 191: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=191 - Type of status
ACTION: assigned to editorial to check that the terminology is consistent.
Issue 192: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=192 - Coordinator-reference
Tony: reason is that there is no updated schema.
Leave open as a reminder to check when the updated schema has been generated.
Issue 193: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=193 - Mysteries in example context
Example is no longer present.
closed, no action
Issue 194: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=194 - “coordination domain”
no longer relevant
closed, no action
Issue 195: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=195 - Interposition
Still an issue, no disagreements.
Issue 196: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=196 - Recovery
We have new text and any potential issues can be raised against that.
closed, no action.
Issue 197: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=197 - Port for RecoveryCoordinator
no longer relevant
closed, no action
Issue 198: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=198 - Recovery of coordinators
closed, duplicate of 169
Issue 199: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=199 - Fault when recovery temporarily not allowed
Still an issue.
Issue 200: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=200 - getStatus
Examine new WSDL and raise any issues.
closed, no action.
Issue 201: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=201 - Beginning and ending of coordinated activity
Martin: Should we be more explicit concerning the relationship to WS-Context?
ACTION: assign to editorial – draft text expanding/clarifying the relationship with WS-Context.
Issue 202: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=202 - WS-CF components diagram
ACTION: Tony to check to see if the figure still exists.
Issue 203: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=203 - Definition of coordination service
no longer relevant
closed, no action
Issue 204: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=204 - Web service provider – “participant api”
no longer relevant
closed, no action
Issue 205: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=205 - Example doesn’t use ws-cf facilities
no longer relevant.
examples should be placed in a primer.
closed, no action.
Issue 206: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=206 - Extension fields in wrong place
Check again when the new schema is produced.
closed, no action.
Issue 207: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=207 - Justification and tutorial inappropriate
no longer relevant
closed, no action.
Issue 208: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=208 - Conformance to this Coordination Framework specification
Martin: we need a conformance statement.
Still an issue.
Issue 210: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=210 - namespace
closed, already resolved.
Issue 211: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=211 - Clarification in error propagation text
Issue with Greg.
Issue 212: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=212 - atomic registration of participant
closed, resolved
Issue 213: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=213 - Participant list in the context?
This was removed from Context and it needs to be incorprated into CF.
Issue 215: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=215 - Add diagrams showing the CAF architecture
Martin: Make sure we are consistent across all of our specifications. All WSDLs have a consistent style.
ACTION: assigned to editorial
Issue 216: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=216 - Add tables giving message parameters and types
ACTION: assigned to editorial. Tony offered to give editorial assistence.
Issue 217: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=217 - Add message sequencing specification
Still an issue.
ACTION: editors to come up with a concrete template for each WSDL and then apply.
Issue 226: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=226 - Relevance of client-to-coordinator interactions
Still an issue.
Issue 227: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=227 - What is currently known as Coordination Framework should be about Link formation, migation and termination
Still an issue.
Triage finished, discussion of issues.
Issue 168: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=168 - Activity hierarchy
Greg: Conceptually there can be hierarchies but there is no requirement for it to be included in the context.
Tony: referencing spec should be able to mandate strict hierarchy but should not be forced to.
Mark: This can be handled by interposition, do we need to say any more in the spec?
Tony: We would want the facility to implement arbitrary graphs and not be restricted to a hierarchy.
Mark: Could have two contexts specified in a header for cycles.
Greg: Should we be able to describe arbitrary graphs? Directed graphs? Undirected graphs? All graph theory?
Greg: The relationships currently supported are parent/child from Context and peer/sibling from Coordination
Current implementation allows for a directed, cyclic graph using different contexts.
Martin: core does not talk about parent/child.
We could include a statement saying that an activity group could join another activity group.
Include discussion of proposal from 227
(http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=227)
to determine whether it is relevant to 168.
Tony: The basic idea is to make CF simple, upon which you can build other things.
Registrar who can register things. The registering agent is acting on behalf of the registrand.
The registrar acts on behalf of the registration.
The proposal has a slightly different configuration for redirecting the link.
The current implementation will support redirection from the participant's perspective but not the coordinators.
Mark: perhaps the only difference is with the recovery of coordinators and we already have an issue for this.
The proposal from 227 is the same as the current architecture but using differing terminology.
There seem to be two distinct issues, coordinator recovery and whether the remove can happen either side.
New issues raised from first part of 227 proposal
- terminology (http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=228)
- update of EPRs on interfaces (recovery) (http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=229)
- Is there a restriction on where remove participant comes from? (http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=230)
The mapping between the current specification and the propoosal from 227 is as follows:-
Participant Service maps to Registrand
Registering Service maps to registering agent
Registration Service maps to registrar
Coordination Service maps to registration.
WS-ContextTree (second part of proposal from 227)
New issue raised
- Martin: We do need to log a more precise issue and say 'what should the registration context look like to support all this functionality? (section 4.2.2)' (http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=231)
Martin: The issues and problems seem to be the same as the current architecture once the issues are addressed.
Tony agrees that these four issues cover the proposal from Choreology.
Tony: referencing specs may want to limit the types of graphs that are built.
Greg: just a protocol restriction
MOTION: Mark - to close 227 depending on resolution of 228, 229, 230, 231
passed no objection.
Thursday morning (Martin taking notes):
Progress through non editorial issues.
Will have telecon meeting on Monday and will process Anish's Context issues.
Issue 168: Activity hierarchy
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=168
Should there be any restrictions on graph building in the CF spec?
Agreed that these are referencing spec issues but we need a fault at the context level
Motion by Mark: reassign the issue to ws-context and add a fault to indicate that the structure of the
context is invalid because of ref spec structuring restrictions.
Eric 2nd
No objections.
Issue 169: Changing the coordinator
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=169
Motion by Martin: close no action as issue 229 supersedes this
Mark 2nd
No objections
Issue 181: Allow late enrolment
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=181
Motion by Mark: make the raising of the Wrongstate fault optional for the when a participant is added during completion i.e. up to referencing spec to allow or disallow
Tony 2nd
No objection
Issue 182: What defines beginning of completion
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=182
Related to issue 201 where we have to expand on relationship to ws-context.
Motion by Mark make 182 dependant on 201.
Dong 2nd
No objections
Issue 184: Fault for disallowed removeParticipant
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=184
Motion by Mark: make the raising of the Wrongstate fault optional for the when a participant is removed during completion i.e. up to referencing spec to allow or disallow
Kevin 2nd
No objections
Issue 190: Context with no Activity ?
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=190
Motion by mark: Make issue dependant on issue 232
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=232
Doug 2nd
No objections
Issue 195: Interposition
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=195
interposition section 4.5
Motion by Martin: Editorial to clarify text to say that cf allows the building of graphs and trees by adding participants that are themselves coordinators - called interposition. the allowable form of the graph (tree etc) is dictated by the ref spec.
Tony 2nd.
No objections
Issue 199: Fault when recovery temporarily not allowed
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=199
Issue relates to use of Wrongstate on recover
Motion by Tony: Define the syntax and semantics of transient faults. Review each operation of both ws-context and ws-cf and add transient fault message where agreed.
Mark 2nd:
Action: editors to make a proposal
discussion: do we have our fault/error architecture correct?
Why respond with a fault, the server could just not reply or reply when the transient fault is
over (even with a perm fault)
No objections.
Issue 208: Conformance to this Coordination Framework specification
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=208
leave open and address when the spec is more stable.
Issue 211: Clarification in error propagation text
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=211
Proposal from Mark on using soap faults
http://www.oasis-open.org/apps/org/workgroup/ws-caf/email/archives/200502/msg00000.html
Follow up from Peter: http://www.oasis-open.org/apps/org/workgroup/ws-caf/email/archives/200502/msg00015.html
this issue depends on 225 so added dependency.
Martin suggested we look at WS-RF Basefaults. Doug proposes action on group members to review ws-basefaults.
ACTION: Group members review ws-basefaults
spec http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-BaseFaults-1.2-draft-03.pdf
ACTION: chairs put discussion of ws-rf basefaults on 28th feb agenda.
Issue 213: Participant list in the context?
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=213
also comment from Greg in the 0.2 cf draft:
"Should we, as a second bullet item, consider formally defining
the list of participants in an activity group? This would be
useful for peer discovery of participants, particularly when
network access to the Registration service is
unavailable."
motion by Mark: add to the ws-cf registration context an optional list of participant endpoint references to hold participants in the activity group.
Martin 2nd
Discussion: what is the use case for this? participants may want to send messages to other participants.
are there any use cases for non tx systems? yes if there are decentralized protocols that don’t
require going through the coordinator.
how do we keep the list up to date? this is a cache/coherency issues which is not specific to this issue.
Tony objected
Vote: yes-3, no-0, abs-2
Motion carries
Issue 226: Relevance of client-to-coordinator interactions
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=226
Motion by Martin: to remove coordinate operation
2nd by mark
Friendly amendment by mark to remove all the client-to-coordinator wsdl and related sub section
Note there is a separate issue about getting list of participants from a registrations service
(issue 233: http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=233)
No objections.
Issue 228: WS-CF terminology
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=228
come back to.
Issue 229: Registration Service recovery and failure
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=229
come back to
Issue 230: removeParticipant restriction
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=230
Thursday afternoon (Doug taking notes):
continue with issue 230:
Martin proposes adding message (notification) from registration service to
registering service saying "you have been removed".
Mark makes motion: Text around participantRemoved message makes it clear
that it MAY be sent from registration service to the registering service
without having previously received a removeParticipant message.
Kevin seconds
That is, we will reuse same message as a response. Effectively make
removeParticipant optional for completion of this [IN] / OUT.
Discussion: Looking for parallel request and response going in the other
direction rather than (confusing) optional request message. These new
messages (logical in / out) would have new names.
Martin would like to amend motion to create new message
(participantHasBeenRemoved) sent from registration service to registering
service instead.
Tony seconds
on amendment, vote is 2 / 2 / 2 - defeated (notation is for / against /
abstain)
on original motion, passed without objection
Issue 231: Format of registration service
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=231
Structure allows parent / child relationships but does not mandate them.
Question is about context extended for registration service (not its WSDL).
Mark makes motion: Close no action
Martin seconds
Discussion: Note that schema does not reflect current specification text.
Passed without objection
Issue 232: Do we keep coordinate
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=232
Martin believes we have already removed client-to-coordinator (when we
closed 226).
Issue is not relevant any longer: duplicate.
Issue 233: Get list of participants from registration service
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=233
Martin makes motion: Add operation on registration service
(getParticipants) which returns (participantList) current list of
participants in the activity.
Mark seconds
Discussion question: Is this open to anyone or only those already in the
group? Return is decided based upon the context send in the header.
Passed without objection
Only remaining WS-CoordinationFramework issues 228 and 229
Issue 228: WS-CF terminology
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=228
Mark makes motion: Adopt current editors draft as next working draft.
Martin seconds
Discussion: This draft is incomplete (does not have WSDL or schema and is
internally inconsistent). Does provide a baseline for future work and
issue resolutions. This would be first draft since the input WS-CF
document the group has accepted.
Vote is 5 / 1 / 0 - passed
Mark makes motion: Close this issue, no action
Martin seconds
Discussion: Tony uncomfortable with coordinator service and participant
service. Would prefer more neutral terms for these. Nothing stops him
coming back with a specific proposal for new names.
Vote is 5 / 1 / 0 - passed
Issue 229: Registration Service recovery and failure
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=229
Discussion: Tony would prefer additional operations which allow redirection
of further messages intended for each service. A single interface at each
service; nothing new at that level to support redirection. Recovery
Coordinator would use these messages to take over for Registration Service.
Current approach uses a separate interface (Recovery service) for the
"ChangeMe" portion of the Registration service life cycle.
Doug makes motion: Remove Recovery Coordinator and all mentions of it from
the specification. In doing so, consolidate its current interface with
that of the Registration Service.
Martin seconds
Discussion: Doug notes that Participant recovery becomes a specific use
case for the (more general) redirection operations on the Registration
Service. Eric does not think this breaks anything but may not fix anything
either.
Passed without objection
Above motion resolved opposite of the original issue, covers failure of a
participant.
Tony makes motion: Add Registering Service operations to support changing
the Registration Service EPRs. The specification should contain no
requirement for the Registration Service to invoke these operations.
Martin seconds
Discussion: This new set of operations would support recovery of the
Registration Service after its failure as one use case.
Mark makes amendment adding second sentence shown above. Passed without
objection.
Motion passed without objection
Issue 235: Inaccurate text between Figures 1 and 2
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=235
Discussion: These figures are duplicated from WS-Context specification.
Move to be a Context issue instead.
Left with only a few Context issues that have not yet been discussed. All
were submitted during this meeting.
CODEWORKS presentation on their efforts in the U.K. NE region.
---------------------
The WS-CAF TC formally thanks CODEWORKS for all of their support for this
event.
Future plans and logistics for them, document schedule
------------------------------------------------------------------------------
Plan for next 2f2:
New Orleans on 28 & 29 April, after 27 April for OASIS Symposium itself.
Need to talk about demonstration plans. Finish up Context (by reference)
demonstration and add Coordination demonstration. Also need to cover
changes to addressing scheme.
ACTION: Chairs to put implementation subgroup re-invigoration on agenda for
Monday's meeting.
Document schedule:
ACTION: Editors to create WSDL and schema consistent with next draft.
Discussion: Aim for consistent draft(s) as input to next f2f, possibly
ready to be a Committee Draft at end of that meeting.
working back: next draft available 11 March
f2f draft on 15 April
question: What is due on 11 March? WS-CF specification, schema and WSDL
Good to have revision of WS-Context for 15 April but interim copy may be
staggered from WS-CF delivery. Pending editors decisions and ability to
deliver one or the other early, use same schedule for WS-Context.
ACTION: Eric to organize editors call to decide how to meet this schedule.
Meeting schedule:
Concalls continue on as they have been, starting next Monday.
ACTION: Doug to check about f2f meeting 30 June / 1 July or following week
(immediately following JavaOne)
Should be talking about transactions by this time.
Document progression:
Doug suggests we do not wait to submit all of the specifications in a
bundle. Some agreement we push specifications to OASIS Standard status
individually. May need a context-specific primer to make this useful.
Certainly need further interoperability testing and demonstration work.
Therefore, Mark suggested we begin work on Context Primer document after
April f2f meeting -- for June meeting.
Context Primer schedule:
draft available 18 May
final WD due prior to June meeting
overall Context goal: done and dusted in New Orleans, complete with primer
and further testing soon after, ready for OASIS Standard submission in June
overall CF goal: new draft in New Orleans, public review between April and
June; June meeting for Context primer & submission, CF issues and beginning
work on WS-TXM
need to define another point at which editors start working on WS-TXM
Idea of BOF at JavaOne to demonstrate WS-Context:
ACTION: Doug to check if deadline has passed or is somehow flexible.
ACTION: Martin to create spreadsheet helping us to visualize
getting to these dates.
WS-CAF officially thanks Arjuna for working with CODEWORKS to get this
meeting going.
Meeting adjourned.
Summary of Actions
----------------------------
Action: Martin / Mark to write up a response to this issue.
Action: Martin / Mark to raise another issue for the primer on the use of WSDL.
Action: editors to add text on extensibility to WS-Context (and WS-CF as well?).
Action: Doug to raise an issue on adding attribute extensibility, or adding in must understand attribute.
Action: Tony to look up to use of wsu:Id in WS-Security to check that we have taken the correct action here.
Action: editors to adjust the text of section 4 for issue 220 http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=220
Action: Greg to provide information / a proposal on adding an info set version of the schema.
Action: editors to make wsdl operation style consistent http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=223
Action: Tony to ask Peter to update his table on wsdl operations and resubmit (actually Tony will take on this task himself.) Issue 223.
Action: editors to take a first pass and enter the resulting issues from Anish into Bugzilla.
ACTION: assigned to editorial to implement the suggestion
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=162
Action: assigned to editorial to remove
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=171
ACTION: assigned to editorial to clarify which operations require a context and whether it is a full context or just a context identifier.
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=178
ACTION: editorial. change the text so that the rules regarding the raising of the wrongState fault is the responsibility of the referencing specification.
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=184
ACTION: assigned to editorial – need to cleanup documentation
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=186
ACTION: assigned to editorial – keep the same style for operational description.
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=187
ACTION: assigned to editorial to check that the terminology is consistent.
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=191
ACTION: assign to editorial – draft text expanding/clarifying the relationship with WS-Context.
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=201
ACTION: Tony to check to see if the figure still exists.
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=202
ACTION: editors, add architectural diagrams
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=215
ACTION: editors, Add tables giving message parameters and types
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=216
ACTION: editors to come up with a concrete template for each WSDL and then apply.
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=217
Action: editors, make a proposal to Define the syntax and semantics of transient faults and which operations need them
http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=199
ACTION: Group members review ws-basefaults
http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-BaseFaults-1.2-draft-03.pdf
ACTION: chairs put discussion of ws-rf basefaults on 28th feb agenda.
ACTION: Chairs to put implementation subgroup re-invigoration on agenda for
Monday's meeting (14 feb).
ACTION: Editors to create WSDL and schema consistent with next draft (both context and cf.) due 11 March.
ACTION: Eric to organize editors call to decide how to meet the schedule.
ACTION: Doug to check about f2f meeting 30 June / 1 July or following week (immediately following JavaOne)
ACTION: Doug to check if deadline has passed for javaone or is somehow flexible.
ACTION: Martin to create spreadsheet helping us to visualize
schedule dates.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]