Logging question/suggestion

[Doug Tody]

Unfortunately we did not have a chance to discuss this general issue
of a "logging enabled service" at the interop, although it came
up briefly in the closing plenary.  This was discussed extensively
within US-NVO several months ago and we reached the conclusion that
a separate logging service is what is really required.

It does not make a whole lot of sense for every service instance to
have to be able to keep a log of all accesses and be able to report
this information, or periodically upload it, to some remote client.
Instead a service instance, when it is invoked, should generate
logging messages which are sent to a separate logging service at
the site.  This logging service can record the information in a
DBMS, file, or whatever, and support standard methods for querying
log information or uploading it as desired.  The scope would be ALL
service instances at the site.  This approach would greatly simplify
the logging requirements we place on service instances while allowing
a more sophisticated logging capability.

It follows that if service instances have limited logging capabilities,
one cannot use a logging interface to implement asynchronous activities
at the service level.  Rather, what one has at the level of a service
is the ability to generate messages when events occur during execution,
which can go to the client or clients or to a logging service.
In the case of a long-running service the service should also be able
to respond to polling requests for status.  Possibly this can all be
done with a simple HTTP interface which passes SOAP-encoded events,
e.g., polling for status could be just another GET or SOAP operation
the service supports (both returning the same SOAP-encoded response),
and asynchronous messaging is easy if the client merely keeps an HTTP
connection open during execution.  SMTP message delivery is also possible
but HTTP is probably more appropriate for most services.  - Doug



On Thu, 25 May 2006, KevinBenson wrote:

> On the last day of the IVOA meeting me and Guy Rixon were chatting about the 
> Logging and namely how it will need to do e-mail and how users will check 
> e-mails to see when it is complete or if an error occurred.  And if your a 
> machine client you will need to monitor e-mail and/or VOSpace to see when 
> things are complete or error to do things more automated.  Also possibility 
> of e-mail systems being down even though rare could be a small/minor problem.
>
> A suggestion was made; how about implement the UWS pattern with Logging. 
> What do others think about it?
> It would mean that clients could do polling to see if a job is complete or 
> error happened, and possibly resume jobs if there was a problem.  It might 
> seem a little heavy weight, but since we agreed we need security, vospace, 
> handle long running queries, and a requestid which matches the resource 
> identifier it would seem UWS idea might be a good fit.  Plus it is quite 
> likely that libraries to handle UWS will incorporate the security and 
> vospace.
>
> cheers,
> Kevin
>