[ogsa-wg] RE: Modeling State: Technical Questions

Tue Apr 5 08:11:58 CDT 2005

Dear Ian,

My apologies... I should have made it clear that I was referring to the
beginning of today's thread when the issue of how to address multiple
jobs was discussed.

Regards,

--
Savas Parastatidis
http://savas.parastatidis.name

________________________________

From: Ian Foster [mailto:foster at mcs.anl.gov] 
Sent: Tuesday, April 05, 2005 2:08 PM
To: Savas Parastatidis; Mark McKeown; Karl Czajkowski
Cc: Dennis Gannon; Samuel Meder; ogsa-wg; dave.pearson at oracle.com;
savas.parastatidis at ncl.ac.uk; gray at microsoft.com;
humphrey at cs.virginia.edu; grimshaw at virginia.edu; aherbert at microsoft.com;
gcf at indiana.edu; mark.linesch at hp.com; Frank Siebenlist; Tony Hey; Dave
Berry
Subject: RE: [ogsa-wg] RE: Modeling State: Technical Questions

Savas:

I think your email misses the point of the current discussion.

Of course, as you point out, if I have a handle of some sort for a job
(a WS-Addressing EPR, as in WSRF/WS-Transfer, or a job-id, as you
advocate below), then I can include several of these in a request to the
job factory asking for some operation to be performed on them all. I
don't believe that anyone's debating that. But that's not the topic of
the recent thread.

What Mark and Karl are discussing is how you would express more abstract
requests such as "kill all jobs that have consumed more than one hour's
CPU time." This is a question of query languages, I presume, not
modeling of job ids.

Ian.

At 01:10 PM 4/5/2005 +0100, Savas Parastatidis wrote:

Dear all,

I think something needs to be clarified with regards to handling
multiple jobs with one message. The beauty of document-oriented
interactions is that you can do things like...

<job-details-request>
  <job-id>urn:ogsa:job:guid:bla-bla-bla-001</job-id>
  <job-id>urn:ogsa:job:guid:bla-bla-bla-010</job-id>
  <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id>
  <job-id>urn:ogsa:job:guid:bla-bla-bla-029</job-id>
</job-details-request>

Or

<job-suspend-request>
  <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id>
  <job-id>urn:ogsa:job:guid:bla-bla-bla-005</job-id>
  <job-id>urn:ogsa:job:guid:bla-bla-bla-008</job-id>
</job-suspend-request>

The schema for the above document can allow anything from 0 to N number
of <job-id> elements.

What WS-RF and WS-Transfer and REST are doing is require that each
message be directed to only one resource. As a result, when it comes to
defining groups of resources, additional resources (representing
collections) have to be created. Populating and managing the collections
require additional messages.

The WS-RF/Ws-Transfer/REST model is a special case of the
document-oriented model I described above...

<!-- just one resource all the time -->
<job-suspend-request>
  <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id>
</job-suspend-request>

In the WS-RF/WS-Transfer case the job ID will have to be part of the
wsa:To (wsa -> WS-Addressing) header. In REST, it is the URI on which
the operations are called (if we are using HTTP and the HTTP verbs, then
the URI usually has the 'http' prefix).

An example, of a WS-Addresing EPR...

<my:MyEndpointReference> 
  <wsa:Address> urn:ogsa:job:guid:bla-bla-bla-002</wsa:Address>
</my:MyEndpointReference>

Please note that the address doesn't have to carry transport/transfer
specific semantics (i.e. it doesn't have to be an 'http' URI). The above
would require a registry look up if that's necessary or perhaps a P2P
network that will know how to direct the message to its destination
based only on the above information. The sender of the message may never
actually see the transport-specific address of the receiving service.

This means that a SOAP msg like the one bellow will have to be sent...

<soap:Envelope>
  <soap:Header>
    <wsa:To>urn:ogsa:job:guid:bla-bla-bla-002</wsa:To>
  </soap:Header>
  <soap:Body>
    <job:job-suspend-request />
  </soap:Body>
</soap:Envelope>

Well... it turns out that this can by the special case of a message that
looks like this...

<soap:Envelope>
  <soap:Header>
    <wsa:To>urn:ogsa:job:service:Newcastle-Job-Service</wsa:To>
    <!-- again... a registry lookup although
         http://ncl.ac.uk/job-service could have also been used -->
  </soap:Header>
  <soap:Body>
    <job:job-suspend-request>
     <job:job-id>urn:ogsa:job:guid:bla-bla-bla-002</job:job-id>
     <job:job-id>urn:ogsa:job:guid:bla-bla-bla-003</job:job-id>
     <job:job-id>urn:ogsa:job:guid:bla-bla-bla-004</job:job-id>
    </job:job-suspend-request>
  </soap:Body>
</soap:Envelope>

What WS-RF and WS-Transfer seem to be doing is to expose to the wire the
programming abstraction that most of us are used to (i.e. calling
methods on an object). As a result, systems based on a special case are
designed rather than the more general case. It's been our argument all
along that this may not be the most efficient way of designing systems
in general (perhaps in certain application domains the WS-RF/WS-Transfer
approach may be appropriate) but I am prepared to be corrected on this
:-)

Best regards,
--
Savas Parastatidis
http://savas.parastatidis.name <http://savas.parastatidis.name/> 

_______________________________________________________________
Ian Foster                    www.mcs.anl.gov/~foster
Math & Computer Science Div.  Dept of Computer Science
Argonne National Laboratory   The University of Chicago    
Argonne, IL 60439, U.S.A.     Chicago, IL 60637, U.S.A.
Tel: 630 252 4619             Fax: 630 252 1997
        Globus Alliance, www.globus.org <http://www.globus.org/> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20050405/ee7fc301/attachment.htm 