On Jun 7, 2006, at 4:35 PM, Marvin Theimer wrote:
Hi;
I'm not advocating an array interface on individual activities. Rather I'm asking whether there is some way of avoiding having two interfaces be defined that need to be kept in sync. One possibility is to have a single interface that takes either no activityID as a parameter or an array of them. The former case represents interaction with a particular activity through its AED while the latter represents interaction with a BES services about multiple activities (i.e. one or more). I just don't see what you're gaining from this. This seems like a hack so that we can avoid the responsibility of defining and keeping an activity interface in sync with the BES spec. If we're worried about keeping two specs in sync, then perhaps we need to simply define the activity interface in the same spec. I don't think this will be a huge problem if the OGSA-BES WG does both specs, though. I not so sure that there will be substantive differences between the interface provided by BES and the one provided by each activity directly. In a high throughput compute cluster scenario -- which is a VERY common case -- users -- and not just sys admins -- will routinely want to query and manipulate multiple activities at the same time. That's fine, but don't munge the factory and activity interfaces together just because this is a common operating scenario. I'll concede that there will basically be a one-to-one mapping between activity operations and similar array operations on the factory, but I don't see anything wrong with this. For example, modern UIs show multiple activities and hence must query multiple ones. Notifications can substantially reduce this traffic, but there are still plenty of occasions where a user's client software will want to query multiple activities. As another example, users will routinely do things like cancel all the activities related to some larger workflow, such as a parameter sweep. So I would argue that the canonical interface to an execution subsystem should be sets of activities rather than individual activities. This point-of-view would imply that the interface on a single activity is really just a special case of the interface for dealing with sets of activities. Of course, the special case of interacting/querying a single activity is also a very common one. But I would argue that both scenarios need to be equally well supported. I'm in total agreement with the idea of supporting both. I just strongly disagree that we should merge the two just to gain some slight convenience of only having to deal with one interface.
Marvin.
From: Peter Lane [mailto:lane@mcs.anl.gov] Sent: Monday, June 05, 2006 5:20 PM To: Marvin Theimer Cc: ogsa-bes-wg@ggf.org; Ed Lassettre Subject: Re: [ogsa-bes-wg] RE: Questions and potential changes to BES, as seen from HPC Profile point-of-view
On Jun 5, 2006, at 5:52 PM, Marvin Theimer wrote:
Hi;
A couple more questions:
· 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).
Peter