[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: caf Minutes 11 feb 05
I will collate all of the notes together into formal minutes early next week. Martin.
Thursday morning (Martin taking notes): Progress through non editorial issues. Will have telecon meeting on Monday and will process Anish's 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 <lunch /> 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 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 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 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 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 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 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. <break /> 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. <break /> agenda: 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. Note: Kevin will not necessarily take leadership role in the SC. 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 detailed Pert chart helping us to visualize getting to these dates. Revised slightly: This is an informal action and may actually use a spreadsheet. WS-CAF officially thanks Arjuna for working with CODEWORKS to get this meeting going. Meeting adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]