- ogsa-bes-wg - lists.ogf.org

Dec 8th Meeting
by Darren Pulsipher 07 Dec '05

07 Dec '05

When: Thursday, Dec 8, 2005 7:00 AM (MST) 12:00 GMT Scheduled to Occur: Once Duration: 1:00 Darren Pulsipher has invited you to attend a Live Meeting. https://www.livemeeting.com/cc/xangoit/join?id=B4GTR3&role=attend Subject: BES Meeting Meeting URL: https://www.livemeeting.com/cc/xangoit/join Meeting ID: B4GTR3 Role: Attendee Audio Conferencing (Toll): +1 (770) 765-9436 Audio Conferencing (Toll-free): +1 (866) 765-2460 Participant Code: 8018168214 FIRST TIME USERS: Install the Windows-based Meeting Console before your meeting: http://r.office.microsoft.com/r/rlidLiveMeeting?p1=7&p2=en_US&p3=LMInfo& p4=DownloadWindowsConsole This Live Meeting invitation is a personal invitation; it should not be forwarded. For assistance, please visit Live Meeting Help and Support: http://r.office.microsoft.com/r/rlidLiveMeeting?p1=7&p2=en_US&p3=LMInfo& p4=support

2 1

EPR as activity identifier
by William Lee 05 Dec '05

05 Dec '05

Hi all, I have hit on a couple of issues raised during my implementation effort regarding the use of EPR in BES. I will try to write down my interpretation here so the group can correct me. Issue 1: What the type of the service addressed by the EPR returned from a CreateActivityFromJSDL request? [Section 5] suggests the type of the service is out of the scope of BES. However, it hasn't addressed the fact that an activity might not even have a service representing it. If I implement this hypothetical BES service, what should I put in the <wsa:Address/> element? Issue 2: Should a <bes:activity-identifier/> (currently an EPR) be totally opaque to users other than the issuer (the BES service)? If the client does not understand how or even wish to interact with the service referenced by the EPR, the <bes:activity-identifier/> is completely opaque because they are simply copied into the bodies of GetActivityStatus, RequestActivityStateChanges and GetActivityJSDLDocuments. There's no need for the content to be introspected. If the client wishes to interact with the service referenced by the EPR (and know the type of course), the <bes:activity-identifier/> will serve as both the address and the identifier (a <wsa:ReferenceProperties/>?) to the activity. I can only interact with the activity through the service (e.g. POSIXControlService) addressed by that EPR. Even though there might be a third service (at a different <wsa:Address/> and different type [MonitoringService]) that can interact with my activity. I can't just replace the <wsa:Address> with the new one and stick in the original <wsa:ReferenceProperties/> because it's supposed to be opaque. How should I perform this resolution? My point is (if my interpretation is correct) is it a good idea to use a service address to identify an activity? If we are not specifying the type of the service referenced by the EPR, is there any value in using an EPR (instead of ... an IRI)? William --- William Lee @ London e-Science Centre, Imperial College London -- --- Software Coordinator --- A: Room 380, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl(a)doc.ic.ac.uk | william(a)imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024 --- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni -----------------------------------------

2 1

Meeting Minutes (WS-Name issue discussed)
by Darren Pulsipher 01 Dec '05

01 Dec '05

Dec 1, 2005 Agenda Mark's changes MUST vs SHOULD WS-Names Attendees Darren Andrew Mark William Lee Steve McGough Michel State Net changes for Staging - Run the state net of the staging actions in parallel with the activity statenet not as a composite state of Stage In and Stage Out. The examples and changes are in the document that Mark sent out. State Net Exceptions - Add an "any" to the status element of the activity status type. For the exception state should have a reason why. See Mark's Document. Notification - We need to add SHOULD implement a notification rendering and if it does then it MUST have specific elements and raise the notification at specific triggers. See Mark's Document. WS-Name issue (Properties/Meta-Data) - MUST be a EPR with meta-data that describes queue names to determine WS-Name or EPR or what ever is coming later. SHOULD be an WS-Name. Make sure that the meta-data is only on the container attribute. And as such all Activities are referenced by EPR or WS-Name not a mix of the two. - Change IsAcceptingActivities should be changed to meta-data on the container. There needs to be a last call out on the EPR/WS-Name isssue.

1 0

BES WSDL
by William Lee 30 Nov '05

30 Nov '05

Hi all, I've had a quick look at the BES WSDL. Here are my comments and modifications (attached). 1) Typos that cause missing referenced elements (see inline mod in the attached word doc.) 2) JSDL namespace has been updated according to the JSDL v1.0 spec. 3) The BES schema references the jsdl:JobDefinitionType complexType (it's actually been renamed to jsdl:JobDefinition_Type in the v1.0 spec), should we use the JSDL defined element "jsdl:JobDefinition" instead of creating our own. This makes life easier for user who's used to write JSDL document. <xsd:element ref="jsdl:JobDefinition" minOccurs="1" maxOccurs="1"/> 4) How are we going to cope with different renderings? The current WSDL contains a lot of WS-RF artifacts. Here's a cleanup WSDL with the WS-RF related artifacts commented out. http://www.doc.ic.ac.uk/~wwhl/bes/wsdl/basic-execution-service9.wsdl You can use the following tool to visualise it. http://www.mindreef.net/tide/scopeit/start.do William --- William Lee @ London e-Science Centre, Imperial College London -- --- Software Coordinator --- A: Room 380, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl(a)doc.ic.ac.uk | william(a)imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024 --- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni -----------------------------------------

1 0

BES Meeting
by Darren Pulsipher 30 Nov '05

30 Nov '05

When: Thursday, Dec 1, 2005 7:00 AM (MST) Scheduled to Occur: Once Duration: 1:00 Darren Pulsipher has invited you to attend a Live Meeting. https://www.livemeeting.com/cc/xangoit/join?id=QG4M2D&role=attend Subject: BES Meeting Meeting URL: https://www.livemeeting.com/cc/xangoit/join Meeting ID: QG4M2D Role: Attendee Audio Conferencing (Toll): +1 (770) 765-9436 Audio Conferencing (Toll-free): +1 (866) 765-2460 Participant Code: 8018168214 FIRST TIME USERS: Install the Windows-based Meeting Console before your meeting: http://r.office.microsoft.com/r/rlidLiveMeeting?p1=7&p2=en_US&p3=LMInfo&p4=… This Live Meeting invitation is a personal invitation; it should not be forwarded. For assistance, please visit Live Meeting Help and Support: http://r.office.microsoft.com/r/rlidLiveMeeting?p1=7&p2=en_US&p3=LMInfo&p4=…

1 0

BES Meeting
by Darren Pulsipher 30 Nov '05

30 Nov '05

When: Thursday, Dec 1, 2005 7:00 AM (MST) Where: On Line *~*~*~*~*~*~*~*~*~* -+-----+-----+-----+-----+-----+-----+-----+-----+- Darren Pulsipher has invited you to attend a Live Meeting. https://www.livemeeting.com/cc/xangoit/join?id=QG4M2D&role=attend Subject: BES Meeting Meeting URL: https://www.livemeeting.com/cc/xangoit/join Meeting ID: QG4M2D Role: Attendee Audio Conferencing (Toll): +1 (770) 765-9436 Audio Conferencing (Toll-free): +1 (866) 765-2460 Participant Code: 8018168214 FIRST TIME USERS: Install the Windows-based Meeting Console before your meeting: http://r.office.microsoft.com/r/rlidLiveMeeting?p1=7&p2=en_US&p3=LMInfo&p4=… This Live Meeting invitation is a personal invitation; it should not be forwarded. For assistance, please visit Live Meeting Help and Support: http://r.office.microsoft.com/r/rlidLiveMeeting?p1=7&p2=en_US&p3=LMInfo&p4=…

1 0

RE: naming issues resolution process discussion (Re: [ogsa-wg] Proposed agenda for Nov. 16 call)
by Ian Foster 17 Nov '05

17 Nov '05

Andrew: I'm not ignoring you: either I hadn't heard you express the use cases below (I haven't been on all the calls) or I hadn't internalized you doing so. I appreciate you taking the time to write them down: this information is very helpful. Three comments on the use cases: 1) These use cases, like Chris Smith's, do not imply a need for names that are "globally unique in time and space." The only requirement is that names be unique with respect to the scope of the activities that the user wants to monitor or track. This might seem a minor point, but I think it's an important one: as Chris pointed out, a sensible key to use as a name in #1 could be, in some circumstances, e.g. the LSF jobid. That choice of key is prohibited by the current WS-Name definition. 2) In use case #1, I think you assume that a notification has the form "job with epr E has status S." Certainly, if that was the case, then you'd face the problem of determining which job that EPR referred to, something that you can't do without the ability to compare EPRs. But in WS-Notification, at least, when a client subscribes to notifications it can supply, as the callback address, an EPR to a unique WS-Resource. So the notification delivers the message "status S" to the subscription for job with epr E. Thus, there is no need to include a key in the EPR for the purpose of disambiguation. 3) Use case #2 makes sense to me. I could also do this without an AbstractName, by passing around an XML structure containing an application-specific key and the EPR--or, more likely, embedding the EPR in a larger application-specific structure that I have created for other purposes. But clearly an AbstractName could usefully be applied here. Ian. At 12:03 PM 11/16/2005 -0500, Andrew Grimshaw wrote: >Ian, > >I did give a scenario you just chose to ignore it. Here are two: > >1) As a client of BES I want to be able to keep track of the activities I >start. Suppose I have one hundred going. I want to build a data structure >that keys off of the activity. Id like the handle I get back from the BES >container (which is basically acting like a factory) to have a keyin it I >can use so that when I get notifications about the activity, or some other >services wants to talk about the activity I have some way to associate and >search for the activity information I am keeping. > >2) Using the WS-name (specifically the abstract name) to correlate >information flows about an activity. (This is the example I have used >several times.) > > > >The requirement in both cases is to be able to identify when two EPRs >refer to the same activity. > > > >Andrew > > > >---------- >From: Ian Foster [mailto:foster@mcs.anl.gov] >Sent: Wednesday, November 16, 2005 9:33 AM >To: Hiro Kishimoto; Andrew Grimshaw; Tom Maguire; Frank Siebenlist; Smith >Chris; Mark Morgan >Cc: Savva Andreas >Subject: Re: naming issues resolution process discussion (Re: [ogsa-wg] >Proposed agenda for Nov. 16 call) > > > >Hiro: > >Ahead of the call, I'd like to raise the question again of what >application requirements motivate the use of WS-Names in BES. I asked this >on the last call, and my question wasn't answered. I asked the question >again via email, and Chris replied with what turned out to be a >requirement for something different than WS-Names. I think it would be >really helpful to have a list of requirements as a basis for discussion. > >Ian.

1 0

Next telecon
by Andrew Grimshaw 17 Nov '05

17 Nov '05

All, Many people are at SC this week and cannot make the telecon. As next Thursday is Thanksgiving here in the US (one of the top two holidays) I propose that we skip next weeks telecon as well, and schedule our next telecom for Thursday, December 1, at the usual time. The primary issue on the table is the use of WS-Names in BES. There is a proposal under discussion in the OGSA-WG to prohibit mandatory use of WS-Names in ANY OGSA specification. That would impact BES in that the current specification requires the use of WS-Names as return types and parameters to many of the operations. This has generated a proposal (during discussions) that if WS-Names cannot be mandated, that BES revert to the original draft use of AbstractNames (i.e. strings) as the parameters and return values of the functions. Another issue that needs discussion is some changes to the document itself. As Mark Morgan has begun implementing a prototype of the draft specification several under-specified, or incompletely specified issues have come up. In separate email he discussed some of those. We will need to take actions (yea/nea) on some of his choices. Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

2 1

Re: [ogsa-wg] Abstract names in BES
by Christopher Smith 11 Nov '05

11 Nov '05

> > I'm concerned that the following two notions may be inconsistent: > > a) WS-Names should be globally unique (Andrew) > > b) The WS-Name can be used to pass a LSF jobid (Chris) > > Or is Chris proposing that LSF be changed to generate its jobids with > whatever scheme WS-Naming proposes to ensure global uniqueness? (If it > doesn't, then I don't think that Chris can guarantee that the names that > LSF generates and the names that someone else generates will not collide.) > For me, these names are all about context. Within an LSF environment (including an LSF multicluster environment), the LSF jobid is sufficient, and generating another globally unique identifier doesn't really add much value. If I'm in a context where I'm dealing with multiple systems that will be providing me EPRs for interacting with "jobs", then I'll need a higher level software layer to shield me from the lower level details, and here globally unique (well ... at least contextual globally unique) identifiers are required, and add more value. So let's circle back on this discussion for a moment. You asked for some use cases for the use of abstract names, and I provided one (perhaps you don't agree with my usage of abstract names, but that's this side discussion). This use case is one that we see all the time. Imagine an application "workbench" (e.g. something like Fluent or Sybyl), that exports a special BES service to run and manage domain specific jobs through its own "gateway" to LSF. Imagine then, if you will, a higher level job "viewer" interface that then produces another EPR for watching jobs (maybe so I can aggregate my job views from multiple workbenches). A job submitted through the workbench is viewable through the viewer, but they have different EPRs. The LSF jobid in this case is the abstract name that let's me know they are the same thing. And this jobid is as unique as it needs to be within this context. If I embed this identity information in the EPR, then how do the two gateways share this information? How can they if they are hosted at different SOAP endpoints? -- Chris

2 1

FW: BOUNCE ogsa-bes-wg@ggf.org: Non-member submission from [itf@mcs.anl.gov]
by Darren Pulsipher 10 Nov '05

10 Nov '05

-----Original Message----- From: owner-ogsa-bes-wg(a)ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] Sent: Thursday, November 10, 2005 2:47 PM To: owner-ogsa-bes-wg(a)ggf.org Subject: BOUNCE ogsa-bes-wg(a)ggf.org: Non-member submission from [itf(a)mcs.anl.gov] >From owner-grdfm-ogsa-bes-wg(a)mailbouncer.mcs.anl.gov Thu Nov 10 15:47:13 2005 Return-Path: <owner-grdfm-ogsa-bes-wg(a)mailbouncer.mcs.anl.gov> X-Original-To: grdfm-ogsa-bes-wg(a)mailbouncer.mcs.anl.gov Delivered-To: grdfm-ogsa-bes-wg(a)mailbouncer.mcs.anl.gov Received: from localhost (localhost [127.0.0.1]) by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 83F5112C96; Thu, 10 Nov 2005 15:47:13 -0600 (CST) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 1592112C94; Thu, 10 Nov 2005 15:47:12 -0600 (CST) Received: from www-unix.mcs.anl.gov (gust.mcs.anl.gov [140.221.9.215]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id jAALkqQ14270; Thu, 10 Nov 2005 15:46:52 -0600 Received: from 208.54.72.239 (SquirrelMail authenticated user itf) by www-unix.mcs.anl.gov with HTTP; Thu, 10 Nov 2005 15:46:52 -0600 (CST) Message-ID: <1472.208.54.72.239.1131659212.squirrel(a)www-unix.mcs.anl.gov> In-Reply-To: <43739301.7080507(a)mcs.anl.gov> References: <20051110143143.H67244-100000(a)nessie.mcc.ac.uk> <43739301.7080507(a)mcs.anl.gov> Date: Thu, 10 Nov 2005 15:46:52 -0600 (CST) Subject: Re: [ogsa-naming-wg] Re: [ogsa-wg] Abstract names in BES From: itf(a)mcs.anl.gov To: "Frank Siebenlist" <franks(a)mcs.anl.gov> Cc: "Mark McKeown" <zzalsmm3(a)nessie.mcc.ac.uk>, "Donal K. Fellows" <donal.k.fellows(a)manchester.ac.uk>, ogsa-wg(a)ggf.org, ogsa-naming-wg(a)ggf.org, ogsa-bes-wg(a)ggf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov X-Spam-Status: No, hits=-0.8 tagged_above=-1.0 required=5.0 tests=AWL, BAYES_00, NO_REAL_NAME X-Spam-Level: I'm concerned that the following two notions may be inconsistent: a) WS-Names should be globally unique (Andrew) b) The WS-Name can be used to pass a LSF jobid (Chris) Or is Chris proposing that LSF be changed to generate its jobids with whatever scheme WS-Naming proposes to ensure global uniqueness? (If it doesn't, then I don't think that Chris can guarantee that the names that LSF generates and the names that someone else generates will not collide.) Ian. > Mark McKeown wrote: >> Hi Donal, >> >> >>>> Regarding Chris's desire to be able to pass the LSF jobid >>>> back to the client somehow - it could be included in the EPR's >>>> Metdata, possibly RDF could be used to mark up the Metadata >>>> to indicate that it is a LSF jobid. In this way the Address >>>> IRI can be kept opaque. >>>> >>> That would seem to me to be needless disambiguation. Surely it is just >>> up to the service that mints the abstract name to understand it; there >>> is no inherent need for it to explain what that means to anyone else. >>> >> >> I am not sure I understand your comment - you don't seem to >> be disagreeing with me... >> >> Frank wants to use the EPR's wsa:Address IRI as an AbstractName, >> Chris wants to send a LSF jobid to the client and the W3C >> recommends that IRIs should be opaque. One way to include >> the LSF jobid in the EPR is to embed it into the wsa:Address >> IRI, this might help make it unique and the client could extract >> it from the IRI - however the W3C recommends that IRIs >> should be opaque. >> > > Well, I also believe that it's better to keep the IRIs opaque and was > suggesting to use the complete IRI itself as an alternative jobId. > > Whether that could work depends on the use cases we have to consider... > > -Frank. > > -- > Frank Siebenlist franks(a)mcs.anl.gov > The Globus Alliance - Argonne National Laboratory > >

1 0