ogsa-bes-wg

Download

ogsa-bes-wg@lists.ogf.org

December 2005

7 participants
12 discussions

EPR as activity identifier
by William Lee 05 Dec '05

05 Dec '05

Hi all, I have hit on a couple of issues raised during my implementation effort regarding the use of EPR in BES. I will try to write down my interpretation here so the group can correct me. Issue 1: What the type of the service addressed by the EPR returned from a CreateActivityFromJSDL request? [Section 5] suggests the type of the service is out of the scope of BES. However, it hasn't addressed the fact that an activity might not even have a service representing it. If I implement this hypothetical BES service, what should I put in the <wsa:Address/> element? Issue 2: Should a <bes:activity-identifier/> (currently an EPR) be totally opaque to users other than the issuer (the BES service)? If the client does not understand how or even wish to interact with the service referenced by the EPR, the <bes:activity-identifier/> is completely opaque because they are simply copied into the bodies of GetActivityStatus, RequestActivityStateChanges and GetActivityJSDLDocuments. There's no need for the content to be introspected. If the client wishes to interact with the service referenced by the EPR (and know the type of course), the <bes:activity-identifier/> will serve as both the address and the identifier (a <wsa:ReferenceProperties/>?) to the activity. I can only interact with the activity through the service (e.g. POSIXControlService) addressed by that EPR. Even though there might be a third service (at a different <wsa:Address/> and different type [MonitoringService]) that can interact with my activity. I can't just replace the <wsa:Address> with the new one and stick in the original <wsa:ReferenceProperties/> because it's supposed to be opaque. How should I perform this resolution? My point is (if my interpretation is correct) is it a good idea to use a service address to identify an activity? If we are not specifying the type of the service referenced by the EPR, is there any value in using an EPR (instead of ... an IRI)? William --- William Lee @ London e-Science Centre, Imperial College London -- --- Software Coordinator --- A: Room 380, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl(a)doc.ic.ac.uk | william(a)imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024 --- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni -----------------------------------------

2 1

Meeting Minutes (WS-Name issue discussed)
by Darren Pulsipher 01 Dec '05

01 Dec '05

Dec 1, 2005 Agenda Mark's changes MUST vs SHOULD WS-Names Attendees Darren Andrew Mark William Lee Steve McGough Michel State Net changes for Staging - Run the state net of the staging actions in parallel with the activity statenet not as a composite state of Stage In and Stage Out. The examples and changes are in the document that Mark sent out. State Net Exceptions - Add an "any" to the status element of the activity status type. For the exception state should have a reason why. See Mark's Document. Notification - We need to add SHOULD implement a notification rendering and if it does then it MUST have specific elements and raise the notification at specific triggers. See Mark's Document. WS-Name issue (Properties/Meta-Data) - MUST be a EPR with meta-data that describes queue names to determine WS-Name or EPR or what ever is coming later. SHOULD be an WS-Name. Make sure that the meta-data is only on the container attribute. And as such all Activities are referenced by EPR or WS-Name not a mix of the two. - Change IsAcceptingActivities should be changed to meta-data on the container. There needs to be a last call out on the EPR/WS-Name isssue.

1 0