[ogsa-bes-wg] RE: Questions and potential changes to BES, as seen from HPC Profile point-of-view

[Peter Lane]

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 at mcs.anl.gov]
> Sent: Monday, June 05, 2006 5:20 PM
> To: Marvin Theimer
> Cc: ogsa-bes-wg at 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060610/aaaa795d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2782 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060610/aaaa795d/attachment.bin