Hi;

 

My initial email had the intended effect of generating some good discussion.  This email is an attempt on my part to try to distill what I took out of those discussions.  Feedback, corrections, and extensions are welcomed.

 

The main topics that seemed to generate significant controversy were the following:

·        The relationship of the BES “array” operations for interacting with multiple activities in a batch manner versus the (system management) interface that should be offered via the EPRs corresponding to individual activities. 

I still don't understand what you're getting at here. I don't see this as the two interfaces are mutually exclusive. I just don't see any point of having identical operations for both the BES/activity factory service and the activity service. If the factory and activity service were the same, then fine. If they are two distinct services then tailor the interfaces. You mentioned "keeping them in sync". I still don't understand your concern here. What is it that frightens you about the BES group being able to keep the two (which are intimately related) in sync?

·        How BES should describe the available resources its associated execution container has – especially when that container might be a compute cluster or the BES service might be a meta-scheduler fronting multiple backend BES services.  Most of this controversy was really around the details of the JSDL specification and how to use it rather than around BES proper.

 

The rest of my suggestions did not seem to draw much fire (or maybe I’m just blanking it from my mind J).  

 

Given that, I would like to propose the following second draft of my proposal for how to change BES in order to support the HPC profile work:

·        Operations:

·        CreateActivity(jsdlDoc) à EPR

·        GetActivity(EPR) à activityState

·        GetActivityDescription(EPR) à JSDL doc

I would rather see a generic property getter method instead that takes an array of EPRs. This would model better w.r.t. WSRF's getResourceProperty, etc... methods and avoid the precedent of providing individual operations for each property.

·        CancelActivity(EPR)

·        For non-WSRF versions: QueryResources() à schedulerResourcesInfoset

It worries me that this is a non-WSRF-only operation. We should try very hard to avoid branching the spec for two different resource models. If we can't avoid it then there needs to be two separate specs IMHO. What do the WSRF services do with this?

·        ‘schedulerResourcesInfoset’ is essentially the union of the RPs that would be exported in a WSRF-based version for describing the resources that are available for use at this BES service.  Note that a BES service might also want to expose other kinds of information that would not be returned from this operation – this operation is there so that clients can determine whether or not a BES service could potentially meet their needs and is necessary for meta-scheduling scenarios.

I don't really understand what you're trying to accomplish here. You say it's a non-WSRF operation and yet this description says it's an aggregation of the WSRF RPs. Then you add that it might return other stuff as well. This seems like a "give me the serialized resource object" operation. My feeling is that if the necessary information were exposed correctly you wouldn't need this operation.

·        One might argue that one could use WS-Transfer for this operation.  However, since a BES service might want to export other kinds of information, this would require an extra level of indirection so that the BES service could expose which EPRs to use for retrieving which kinds of information.

·        Information model for describing available resources:

·        Define an infoset that can describe such resources.  The top-level element indicates which description standard is being employed by the infoset.  

·        Define one such description standard to be an array of JSDL descriptions for things like compute clusters.  Other, richer, description standards can be defined later.

·        Additional topics/summary:

·        Simple state diagram and no notion of array operations, data staging, suspension, or notifications in base BES case.

·        Extensions defined as separate profiles for array operations, data staging, suspension, and notifications.

·        Defer the topic of how the interface for (extension) array operations should relate to the interface supplied for querying/canceling individual activities.

·        RequestActivityStateChange replaced by operations specifying desired actions rather than states.  Base case supports activity cancellation; extensions can define additional operations (e.g. SuspendActivity).

·        Information model: small base set plus extensions model (which ones to include in the base set TBD)

·        All system management functions moved out to a separate interface.

·        Provenance log: (eventually) define an extension for a GetActivityProvenance operation.