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

[Paul Harrison]

On 2009-11 -06, at 22:51, Petr Skoda wrote:

>
> 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 ).

I agree that it would be good to prolong the RFC period somewhat - it  
is a problem with the the IVOA procedure that typically it is only  
late in the RFC stage that people who are not the authors of a  
standard begin to try to implement the standard - it is only at this  
stage that certain issues emerge - perhaps so "obvious" to the authors  
that they did not include it in the document, perhaps something that  
the authors had not considered - in either case there does need to be  
time for reflection.

>
> 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.


I will check and fix these - though I might need to put the corrected  
service at a different location, as this is a production server. |t  
shows that we need to get a verification service in place asap.

Cheers,
	Paul.