Andrew Grimshaw wrote: [...]
MUST support RNS:list
RNS:list MUST return a predefined set of <name, EPR> pairs that contain
the
job information people want, e.g., session_directory, status
I would prefer to have that information profiled directly into EPR of
activity.
That would save a need to call at least one more operation for every
initiated Activity.
[Andrew Grimshaw] I'm not sure what you mean. Do you mean into the metadata portion of the EPR? I think this may be difficult. Status information for example changes? The contents of the session_directory may change. Or do you have something else in mind?
The GES must support client-initiated transfer of the input data. This means that the user creates an activity in "pending" state. The GES returns an activity identifier, plus additional information (e.g., a URI) pointing to a location when the user can upload input data needed by the activity, using a supported protocol (scp/gridftp/whatever). At this point the user can start the activity. Thus, in the "strawman" we defined the CreateActivity operation to return a structure to avoid another call to the service to get the URI of the data staging area. This was considered as an implementation detail, which I certainly agree. On the other hand, would we have written something like "the GES must be efficient and avoid redundant interactions", that requirement would have been too generic and completely unverifiable, and again I would agree. I can not find any succint way of describing such a requirement, suggestions are welcome. Anyway, this specific problem would be easy to "fix" (by another profile), as the BES CreateActivity operation returns an ActivityDocument datatype, which contains an extension point. I also see that so far the discussion focused on adding features, but it would be equally important to get rid of stuff which is no longer needed. For example, the BES GetFactoryAttributesDocument as defined in BES makes little sense if we switch to a GLUE-based information model. From the discussion on wednesday I understand that it is not possible to deprecate operations; for GetFactoryAttributesDocument it is not possible to have it return an empty structure, because the normative BES specification says that the GetFactoryAttributesDocument operation returns a FactoryResourceAttributesDocument element, which must contain at least the following: - IsAcceptingNewActivities - TotalNumberOfActivities - TotalNumberOfContainedResources - NamingProfile - LocalResourceManagerType I did not check the other profiles/specifications, but I think that there could be other situations in which there are features not needed nor requested by GES which must be implemented anyway. So, while it would be possible to extend FactoryResourceAttributesDocument to include an XML rendering of some GLUE information, the same structure would still contain at least the abovementioned legacy stuff. Is there any way this can be avoided? Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233