Ian,

Apologies for the delayed reply... I think we all got distracted by the WS-Names debate... and having just looked at the draft specification today for the first time today in a month or so let me take a stab at providing an answer.

I would like to argue against your proposed operations on the grounds of fragility and scalability.

Recall that most of the BES discussion until recently was focused on the  'abstract' interface. There are now two renderings - a WSRF and a 'plain' WS.

At the moment the specification (and the renderings) do not mandate any particular registry function. I see no reason why WSRF based activities could not be federated through WS-ServiceGroups (though I'm not exactly sure how they work... I'm interpreting them as a 'sort of' registry view - apologies if this is incorrect) or the plain WS through a UDDI registry.

The respective clients would not need to maintain a list of the endpoints they where interested in (but could do so) as these could be obtained from the service group or by searching the registry. Having extracted a list of end points these could be applied to the running activities through the operations on their respective containers.

I suggest (as we have also suggested in earlier communications to BES-WG) that we should instead allow the user to specify a set of activities that are to be monitored or controlled in terms of their properties, not names. E.g., "activities that belong to me", "activities that involve executable Foo", "activities that have been running for over 2 hours."

So I don't see these operations ruled out by what we've done... but not explicitly defined. I'm not sure if these registry functions/capability need to be defined/declared within the service specification. Is this not a broader property of the deployed SOA - e.g. UDDI registry, MDS type federation or P2P structure?

Regards,

Steven
--
----------------------------------------------------------------
Dr Steven Newhouse                        Tel:+44 (0)2380 598789
Deputy Director, Open Middleware Infrastructure Institute (OMII)
Suite 6005, Faraday Building (B21), Highfield Campus,
Southampton University, Highfield, Southampton, SO17 1BJ,  UK