OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[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]