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 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. 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.
Marvin.
From:
Sent: Monday, June 05, 2006 5:20
PM
To: Marvin Theimer
Cc: ogsa-bes-wg@ggf.org;
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:
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).