TAP Implementation Issues: Final Comment: TAP and UWS, sync and async

[Petr Skoda]

Hello all !

I have been following the discussion about the UWS for several weeks.
In fact RESTFull UWS is the core of our application called VO-KOREL, which 
I will show  during the GWS cloud session.

As you may remember since last interop we started with some php 
application using GET and question marks for controlling. Now it is in 
RESTFull way and we tried to follow the UWS 1.0 although some issues are 
very specific and maybe not following standard closely.

We wanted to do things in a user friendly manner so there issues like http 
refresh needed on page with jobs and some direct creating of job and run 
in one step (which in fact uses two step - create job and put in queue. 
It runs automatically if it is possible) Its a some ballance between how 
it should behave for user and what is logical  for server interaction.

> UWS becomes a service definition, not  an access protocol.

So this is exactly our case - we are providing some service using specific 
parameters and giving specific results (we have to provide number of 
outputs like ...jobs/job_number/results/filename. We have even embedded 
picture on page results.) The core is just computation -  no VO DAL 
protocol is used. In the future the another service will use DAL to get 
spectra and produce KOREl specific parameter file - thus a 
"scientific cloud" .


> If I think of things this way, then I can implement UWS completely 
> independently of the underlying application. Indeed the binding to the 
> underlying application could be dynamic: I can provide a UWS layer over any 
> number of distinct synchronous applications.

In our case all jobs are asynchronous as it runs computing job and even 
if it returns quickly we have to put it in the queue and run if the 
certain conditions (memory, number of jobs, processor load ..) are 
fulfiled.

It is in fact layer over the basic number crunching program (Fourier 
disentangling) which allows to run several of them by different users, 
rerun the jobs (with different parameters) aborting, deleting etc ... The 
POST for changing state (and run it using PHASE=RUN) seems to be very 
logical and flexible

I would, however suggest to prolong the RFC period  for UWS as some issues 
of UWS 1.0 should be still discussed in more detail (e.g. the results 
list, error responses in critical states etc ... the estimate of runtime, 
date when the job is killed etc ).

As the good understanding of UWS is probably crucial for further work of 
VO I would suggest its authors to concentrate on it during the grid 
sessions and allow some discussion about their intentions (e.g. the quote, 
descruction, executionduration) as the example on astrogrid sets these in 
a strange way - its a question of their real necessity.


BTW

I have chacked the reference UWS at astrogrid.jb.man.ac.uk:8080 and it 
seems not strictly follow UWS1.0 - e.g. the quote does not work, 
parameters show the same as whole job description - that means 
jobs/id/parameters is the same as /jobs/id,

then bugs with end slash:

the root/jobs/ returns error not jobs list
   root/jobs returns correctly

however root/jobs/id and root/jobs/id/ gives the same job detail

These are subtle details however - probably small bugs.

Petr Skoda

*************************************************************************
*  Petr Skoda                         Phone : +420-323-649201, ext. 361 *
*  Stellar Department                         +420-323-620361           *
*  Astronomical Institute AS CR       Fax   : +420-323-620250           *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Czech Republic                                                       *
*************************************************************************