Hi;

 

A couple more questions:

·        Although sec. 8 says that the interface for controlling/managing an existent activity is out-of-scope, it clearly overlaps with the BES interface (in particular, the query and cancel operations).  Given this overlap I’m wondering how much of the activity’s WSDL interface will effectively be redundant with the BES interface.  Moreover, services wanting to support array operations on activities will effectively need to support the full activity WSDL in any case since otherwise it will be impossible to achieve the desired batching for those operations.  

I strongly object to the idea of having generic array operations in an activity interface in addition to the BES interface.They're not needed if the BES interface already has them. I think there should be a strong separation between the "factory" or "activity manager" interface and the activities themselves which will have resources for each individually-owned activity.

·        This leads me to wonder whether a separate WSDL for activity interaction is really appropriate since it will require that the two specifications be kept continuously synchronized and one will effectively be a strict subset of the other.

I think there are enough differences between the two interfaces that a separate WSDL is warranted if not required. If the activity interface is a subset of the BES interface, then I think the design is flawed. Operations and properties that operate on/expose data for one and only one activity should only be in the activity interface. Array operations and compute resource data properties should only be in the BES interface. An implementation of the BES interface will potentially support multiple resources corresponding to the various LocalResourceManagerType values (not necessarily a one-to-one relationship).