addParticipants update

[Mark Little <mark.little@arjuna.com>]

During the last round of discussions on registration optimizations, 
Alastair raised the topic of registering multiple participants at the 
same time via an as yet to be named operation on the registration 
service. Last week I added that issue to bugzilla 
(http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=279); I hope it 
reflects everyone's understanding of the problem as discussed at the 
teleconference.

With that in mind, it seems that we're after a new operation 
(wscf:addParticipants?) [Note, since AddParticipants is now the element 
name for the header block optimization we agreed a couple of weeks ago, 
I'd recommend not using that name, but I'll use it for now.] This 
operation would take a list of participant service references and have 
to return a list of endpoint references for the participants to use 
subsequently (presumably within a wscf:participantsAdded message).

Now the wrinkle in this scenario is whether additions have to be atomic, 
i.e., if a list of participants is sent, do they all have to be 
registered, or are partial failures allowed? This could be an optional 
flag at registration time (wscf:atomic?) but having atomic registration 
does complicate things a lot. It also goes beyond simply providing an 
optimization to multiple individual registration attempts. My temptation 
would be to fail the entire operation on the first participant 
registration failure and return the list of successful registrations 
along with an indication of which one failed.

Do we want to add a wscf:removeParticipants operation?

Mark.

-- 
Mark Little
Chief Architect
Arjuna Technologies Ltd
www.arjuna.com