- jsdl-wg - lists.ogf.org

Port and xRSL
by Michael Grønager 29 Nov '04

29 Nov '04

Hi, I searched the archive of the list for Port and for xRSL, and found nothing, though I want to throw in my two cents: 1. Port In the Network section of a WSDL file I didn't found any way to request specific ports to be opened for incoming/outgoing/tcp/udp connections and if net is NAT'ed etc. I have quite often submitted jobs with need for specific ports and it would hence be nice to be able to specify this in stead of having the job fail. 2. xRSL As JSDL is based on Condor, RSL and others I just wanted to point to NorduGrids xRSL. It is (eXtended RSL) to it is mostly covered by RSL, however, there is some additions that I think could be usefull for JSDL: * runtimeEnvironment: Specifies specific software requirements on the cluster (like Gaussian, ATLAS and others.) It could though be added as an extention to JSDL. * nodeAccess: inbound|outbound essentially a light version of the Port sepecified above. Cheers, Michael Michael Grønager, PhD Research and Developement, VR-C UNI-C DTU Build. 304 DK2800 Lyngby DENMARK Phone: +45 35878889 Direct: +45 24248207 Fax: +45 35878990 Email: mpg(a)uni-c.dk

3 3

Re: [jsdl-wg] Port and xRSL
by Michael Grønager 29 Nov '04

29 Nov '04

Donal, Thanks for your answer - I have inlined some comment below. > > 1. Port > > This would be fine as an extension in the Resources section, though the > semantics would have to be that the job requires the given ports to be > open (in general, you'd want to be able to also specify where it is open > with respect to.) Agree - and it would be fine if it were just an extension. However, I saw that one of the JSDL job types are WebService and here some kind of communication to the outside world is definately needed (even though a completely open net probably isn't). That is to say that having a WS job type calls for a port specification as well (or am I misinterpreting the WS job type?). > > (FWIW, in my jobs the requirement to have a particular port or > port-range open is a bug, but then I structure my things differently and > I'm also working in quite a different environment to you apparently. > Just because I don't need it doesn't mean that it isn't valuable. But it > does fit nicely as an extension.) My area of interest is mainly interactive use of the grid and hence I would need some kind of network connedtion open to be able to steer a calculation. > > These things are either covered by the existing ApplicationName element > (Gaussian is one of our use-cases) or by other extensions within either > the Application or the Resources element (depending on the exact nature > of the kind of requirement). I'd like to emphasize that the Application > element as it stands is (when you take advantage of it fully) a lot > richer than many current job running systems support. Here I rest my case ;-) I overlooked or misinterpreted the meaning of that element. > > > * nodeAccess: inbound|outbound essentially a light version of the Port > > sepecified above. > > Then it's either covered by what I said above :^) or you'll need to > provide a bit more explanation (e.g. a URL where I can look up what > those terms really mean). Agree - It was mainly mentioned as an example of a job des. lang that have some kind of network awareness thought into the spec. though way to minimal in my opinion. Btw. the spec is : http://www.nordugrid.org/documents/xrsl.pdf FYI: Nordugrid is with its 5000 CPUs one of the largest production grids in the world. Lately it was used to produce more than one third of the Atlas datachallange II (together with LCG and Grid3). > > I hope this message doesn't come across as combative; it's not meant to. > I'm just trying as hard as possible to describe things in terms of what > is already there to minimize the amount of work we need to do. :^) No offend taken ;-) I just read your fine work and just had to add to it some of my darlings. Btw: do you keep a repository of extentions and if so where? I would like to see how they are laied out so I (at least as a start) can make my "Port" extension into such. Cheers, Michael > > Donal. > >

1 0

[jsdl-wg | Request Meeting Topic - 1150] Extension Name and Version tag
by Sourceforge Tracker Monitor 29 Nov '04

29 Nov '04

A new artifact has been added: 1150 Submitted by: Stephen McGough Submitted date: 2004-11-29 17:29:50 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=688&aid=1150&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=688&aid=1150&group_id…) Summary: Extension Name and Version tag Project: JSDL-WG Tracker: Request Meeting Topic Artifact ID: 1150 Category: Next call Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2004-11-29 17:29:50 Submitted By: Stephen McGough Submit Date: 2004-11-29 17:29:50 Assigned To: Stephen McGough File(s): <None> Description: We have talked about people being able to generate their own extension set to JSDL. It would be useful to allow a document not only to be taged with the JSDL version that it is written in but also the names of the extension sets that have been used and the version of those extension sets. Discuss View the Request Meeting Topic : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=122&atid… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=122&atid…)

1 0

JSDL Meeting
by Darren Pulsipher 29 Nov '04

29 Nov '04

When: Tuesday, November 30, 2004 07:00-08:00 (GMT-07:00) Mountain Time (US & Canada). Where: On Line *~*~*~*~*~*~*~*~*~* You have been invited to a Microsoft Office Live Meeting. At the time of the meeting, click on the following link to attend: http://www.placeware.com/rm/cadence/attend?id=JSDL1130&pw=594904 Meeting Title: JSDL Meeting Audio Information: x3000 Passcode 6447 If you cannot click the meeting link above, or it does not work, please do the following: Browse to: http://www.placeware.com/rm/cadence/attend Type your name Type the Meeting ID as: JSDL1130 Type the Password as: 594904 _________________________ The dial in numbers for the different countries Belgium - 0800-7053 Bezeq - 1-800-940-1786 France - 0800-903109 Germany - 0800-1815765 Hong Kong - 800-968932 Italy - 800874509 Japan - 00531123656 Korea-Tele - 00798-14-800-0512 Netherlands - 0800-0225447 Singapore - 800-1200766 Sweden - 020-7905043 Taiwan - 00801-13-8546 UK - 0800961294 US - 800-933-3594 ______________________________________________________________________________ Darren Pulsipher has invited you to a MeetingPlace e-Conference (Mtg ID 6447) on NOV, 30 2004 at 7:00 AM America/Denver. If provided, use the following password: Call 1 408 894 3000. Enter Mtg ID 6447 when prompted. For more information about this MeetingPlace e-Conference, contact: Darren Pulsipher, 408-895-4537 _______________________________________________________________________________

1 0

Tuesday Meeting Nov. 30
by Darren Pulsipher 29 Nov '04

29 Nov '04

Time: 1400 GMT, 0900 EST, 2300 Tokyo. You have been invited to a Microsoft Office Live Meeting. At the time of the meeting, click on the following link to attend: http://www.placeware.com/rm/cadence/attend?id=JSDL1130&pw=594904 Meeting Title: JSDL Meeting Audio Information: x3000 Passcode 6447 If you cannot click the meeting link above, or it does not work, please do the following: Browse to: http://www.placeware.com/rm/cadence/attend Type your name Type the Meeting ID as: JSDL1130 Type the Password as: 594904 _________________________ The dial in numbers for the different countries Belgium - 0800-7053 Bezeq - 1-800-940-1786 France - 0800-903109 Germany - 0800-1815765 Hong Kong - 800-968932 Italy - 800874509 Japan - 00531123656 Korea-Tele - 00798-14-800-0512 Netherlands - 0800-0225447 Singapore - 800-1200766 Sweden - 020-7905043 Taiwan - 00801-13-8546 UK - 0800961294 US - 800-933-3594

1 0

Revised and updated jsdl xsd schema - with schema this time!
by A Stephen McGough 26 Nov '04

26 Nov '04

All, I've attached the latest and updated schema. There are two major changes. 1) Trivial - uses the latest Regular Expression for range values. 2) Big change: removal of jsdl:any and replacement with xsd:any##other. This is due to some big problems with the jsdl:any type. I'm going to put a summary below: a) It was noticed that the requirement for jsdl:any to always have an id tag was inconsistent with the rest of the document. We have stated for the rest of the document that an id tag was only needed when the multiplicity of an element (in the schema) is greater than 1. Thus forcing all extensions to the schema to have an id is incorrect. b) The definition that was there for jsdl:any did not match how I and (I think) most others expected it to work. Here is how I expected it to work: ... <jsdl:Resource> <jsdl:CPUTime operator="lessThanEqualTo">1000</jsdl:CPUTime> <globus:two_phase id="globusExtend">1</globus:two_phase> </jsdl:Resource> ... While in fact the document would need to look like the following: ... <jsdl:Resource> <jsdl:CPUTime operator="lessThanEqualTo">1000</jsdl:CPUTime> <jsdl:any id="globusExtend"> <globus:two_phase>1</globus:two_phase> </jsdl:any> </jsdl:Resource> ... This reduces the elegance of the document and makes it much harder to write. Michel, Nathalie, Willam, Donal and I have had a look at alternatives including using substitution groups and extending jsdl elements and all have some form of drawback which is either as bad if not worse than the fact we can't force people to use an id tag in their elements. As it has now been noticed that id tags don't always need to be there it seems much better to stick with the xsd:any##other tag in the schema and place into the spec document instructions on how extensions should be done and where id attributes should be placed. If someone could put the schema up on GridForge that would be great. Andreas - could you update the pseudo-schema in the document to use xsd:any##other rather than jsdl:any and we'll need to write the section in the spec to describe how to do extensions. steve.. PS if any XML guru knows how to achieve these rules in a schema please let us know. -- ------------------------------------------------------------------------ Dr A. Stephen McGough ------------------------------------------------------------------------ Research Associate, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8310 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------

2 1

[jsdl-wg | Request Meeting Topic - 1148] JSDL XML namespace
by Sourceforge Tracker Monitor 25 Nov '04

25 Nov '04

A new artifact has been added: 1148 Submitted by: William Lee Submitted date: 2004-11-25 15:19:25 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=688&aid=1148&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=688&aid=1148&group_id…) Summary: JSDL XML namespace Project: JSDL-WG Tracker: Request Meeting Topic Artifact ID: 1148 Category: Next call Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2004-11-25 15:19:25 Submitted By: William Lee Submit Date: 2004-11-25 15:19:25 Assigned To: &lt;None&gt; File(s): <None> Description: The current schema uses the namespace "http://www.gridforum.org/JSDL&quot (http://www.gridforum.org/JSDL&quot) Do we need to document that in the spec? If so, should we make http://www.gridforum.org/JSDL (http://www.gridforum.org/JSDL) final. View the Request Meeting Topic : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=122&atid… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=122&atid…)

1 0

RE: [jsdl-wg] application abstraction in JSDL (fwd)
by Lukichev, Alexander S 25 Nov '04

25 Nov '04

Donal, >Ali Anjomshoaa wrote: >> Fwding bounced mail... > >(Alexander, if you're going to be writing much about this, please join >the mailing list; it simplifies things greatly.) Sorry. I've subscribed now. > >"Lukichev, Alexander S" <alexander.s.lukichev(a)intel.com> >> Our team is currently develops an application that will use >> JSDL documents as input to invoke jobs in a distributed system. >> I'd like to comment if possible some aspects of the latest JSDL >> schema. > >When you say "latest schema", is this pre- or post- the recent >work done >at the face-to-face meeting? It is my impression that many of these >issues you raise were actually addressed there... :^) FYI, you should >refer to the document at >https://forge.gridforum.org/docman2/ViewCategory.php?group_id=1 >22&category_id=868 >which I believe is the most recent version of the spec. Well, I refer this one. >> Currently to describe the job to run you can specify: >> a) executable name >> b) arguments >> c) environment variables >> >> This could be not enough configurable because executables can >> reside at different places on the different systems, arguments >> can be passed in different ways to close applications on >> different systems, etc. Thus JSDL contains pretty enough >> information for locating the suitable server, the located server >> could fail to run the requested application because of lack of >> configuration information. > >Actually, there is no need to specify the executable name at all. An >alternative (that we would encourage people to use where possible) is >the "application name", and that provides the necessary abstraction. That's right. > We also support an extensible set of application "types" which will allow >for a much more sophisticated range of behaviour. The schema limits the possible values to several _types_ of applications like scripts, java classes, sql queries, etc. But how e.g. fortran compilation could be specified? Imagine that you don't know the details about the location of the fortran compiler and the compiler vendor. >> We can look at the UNICORE experience and try to configure >> the particular applications using the following entities: >> >> a) fields (i.e. partucular file names, argument values, >> e.g. "source=a.c", "size=1234") > >I see this as being a different interpretation on the Argument element >(which would require using a non-JSDL type for now, though this will >make for a powerful thing to do once we've got JSDL 1.0 out of >the door.) OK, so non-JSDL Argument could be a solution. > >> b) options (i.e. names for common modes of application >> work; though setting this mode could differ from >> system to system, e.g. "debug=on" results in passing >> "-g" to some compilers) >> c) contexts (modes for application invocations, e.g. >> "profiliration") > >Thess would be probably done with extension elements in the Application >element (unless of course they are more like Resources, when they'd go >somewhere else). Anyone else want to comment? > >> d) variations (variations of expected results, e.g. >> "overwrite" for file operations) > >I don't currently see how the current DataStaging element's >CreationFlag >and DeleteOnTermination sub-elements are insufficient. Please explain >further. Well, file operations can include "copy folder" or "untar file" and can be expressed as applications. So such variations can exist. > >> It would be nice if some kind of such specification (probably with >> another entities but with the idea of abstraction of application) is >> described in the JSDL spec. > >I believe it is. Aside from the very standard kinds of execution scheme >(like "run this executable") we also have some more sophisticated ideas >like mechanisms for invokation of Java programs, running of SQL queries >or even invokation of webservices. However, one of the things we still >need to do is to fill out the (non-normative?) specification of how >these things will be done. > >Hope this helps. Thanks. Alexander > >Donal. >

3 3

Revised and updated jsdl xsd schema
by A Stephen McGough 25 Nov '04

25 Nov '04

All, I've attached the latest and updated schema. There are two major changes. 1) Trivial - uses the latest Regular Expression for range values. 2) Big change: removal of jsdl:any and replacement with xsd:any##other. This is due to some big problems with the jsdl:any type. I'm going to put a summary below: a) It was noticed that the requirement for jsdl:any to always have an id tag was inconsistent with the rest of the document. We have stated for the rest of the document that an id tag was only needed when the multiplicity of an element (in the schema) is greater than 1. Thus forcing all extensions to the schema to have an id is incorrect. b) The definition that was there for jsdl:any did not match how I and (I think) most others expected it to work. Here is how I expected it to work: ... <jsdl:Resource> <jsdl:CPUTime operator="lessThanEqualTo">1000</jsdl:CPUTime> <globus:two_phase id="globusExtend">1</globus:two_phase> </jsdl:Resource> ... While in fact the document would need to look like the following: ... <jsdl:Resource> <jsdl:CPUTime operator="lessThanEqualTo">1000</jsdl:CPUTime> <jsdl:any id="globusExtend"> <globus:two_phase>1</globus:two_phase> </jsdl:any> </jsdl:Resource> ... This reduces the elegance of the document and makes it much harder to write. Michel, Nathalie, Willam, Donal and I have had a look at alternatives including using substitution groups and extending jsdl elements and all have some form of drawback which is either as bad if not worse than the fact we can't force people to use an id tag in their elements. As it has now been noticed that id tags don't always need to be there it seems much better to stick with the xsd:any##other tag in the schema and place into the spec document instructions on how extensions should be done and where id attributes should be placed. If someone could put the schema up on GridForge that would be great. Andreas - could you update the pseudo-schema in the document to use xsd:any##other rather than jsdl:any and we'll need to write the section in the spec to describe how to do extensions. steve.. PS if any XML guru knows how to achieve these rules in a schema please let us know. -- ------------------------------------------------------------------------ Dr A. Stephen McGough ------------------------------------------------------------------------ Research Associate, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8310 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------

1 0

FW: BOUNCE jsdl-wg@ggf.org: Non-member submission from ["Lukichev, Alexander S" <alexander.s.lukichev@intel.com>]
by Darren Pulsipher 25 Nov '04

25 Nov '04

-----Original Message----- From: owner-jsdl-wg(a)ggf.org [mailto:owner-jsdl-wg@ggf.org] Sent: Thursday, November 25, 2004 02:35 To: owner-jsdl-wg(a)ggf.org Subject: BOUNCE jsdl-wg(a)ggf.org: Non-member submission from ["Lukichev, Alexander S" <alexander.s.lukichev(a)intel.com>] >From owner-grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov Thu Nov 25 03:35:21 2004 Return-Path: <owner-grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov> X-Original-To: grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov Delivered-To: grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov Received: from localhost (localhost.localdomain [127.0.0.1]) by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id A916412BE4 for <grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov>; Thu, 25 Nov 2004 03:35:21 -0600 (CST) Received: from mailbouncer.mcs.anl.gov ([127.0.0.1]) by localhost (mailbouncer.mcs.anl.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31473-05 for <grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov>; Thu, 25 Nov 2004 03:35:20 -0600 (CST) X-Greylist: delayed 1205 seconds by postgrey-1.16 at mailbouncer.mcs.anl.gov; Thu, 25 Nov 2004 03:35:19 CST Received: from petasus.ims.intel.com (petasus.ims.intel.com [62.118.80.130]) by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 01CD912BE3 for <jsdl-wg(a)gridforum.org>; Thu, 25 Nov 2004 03:35:19 -0600 (CST) Received: from mssmsxvs01.ims.intel.com (mssmsxvs01.ims.intel.com [10.125.2.23]) by petasus.ims.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id iAP9Ix9w004344 for <jsdl-wg(a)gridforum.org>; Thu, 25 Nov 2004 09:19:00 GMT Received: from mssmsx331.ccr.corp.intel.com ([10.125.2.16]) by mssmsxvs01.ims.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004112512151116895 for <jsdl-wg(a)gridforum.org>; Thu, 25 Nov 2004 12:15:11 +0300 Received: from mssmsx403.ccr.corp.intel.com ([10.125.2.52]) by mssmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Nov 2004 12:15:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: application abstraction in JSDL Date: Thu, 25 Nov 2004 12:15:10 +0300 Message-ID: <6EDC9204B3704C4C8522539D5C1185E565095C(a)mssmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: application abstraction in JSDL Thread-Index: AcTSz0MQhfLvcUxLQAaSW8PGwRyBSA== From: "Lukichev, Alexander S" <alexander.s.lukichev(a)intel.com> To: <jsdl-wg(a)gridforum.org> Cc: "Ratering, Ralf" <ralf.ratering(a)intel.com>, "Kentemich, Thomas" <thomas.kentemich(a)intel.com>, "Petrov, Dmitry N" <dmitry.n.petrov(a)intel.com>, "Odintsov, Igor O" <igor.o.odintsov(a)intel.com> X-OriginalArrivalTime: 25 Nov 2004 09:15:11.0261 (UTC) FILETIME=[43E8CCD0:01C4D2CF] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov X-Spam-Status: No, hits=0.0 tagged_above=-1.0 required=5.0 tests= X-Spam-Level: Hi, Our team is currently develops an application that will use JSDL documents as input to invoke jobs in a distributed system. I'd like to comment if possible some aspects of the latest JSDL=20 schema. Currently to describe the job to run you can specify: a) executable name b) arguments c) environment variables This could be not enough configurable because executables can reside at different places on the different systems, arguments can be passed in different ways to close applications on=20 different systems, etc. Thus JSDL contains pretty enough=20 information for locating the suitable server, the located server=20 could fail to run the requested application because of lack of=20 configuration information. We can look at the UNICORE experience and try to configure the particular applications using the following entities: a) fields (i.e. partucular file names, argument values,=20 e.g. "source=3Da.c", "size=3D1234") b) options (i.e. names for common modes of application=20 work; though setting this mode could differ from=20 system to system, e.g. "debug=3Don" results in passing=20 "-g" to some compilers) c) contexts (modes for application invocations, e.g.=20 "profiliration") d) variations (variations of expected results, e.g.=20 "overwrite" for file operations) It would be nice if some kind of such specification (probably with another entities but with the idea of abstraction of application) is described in the JSDL spec. Thanks. Alexander

1 0