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. 

· 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

· CancelActivity(EPR)

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

· ‘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.

· 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.