[nvo-techwg] Re: Logging suggestion

[KevinBenson]

Yes I forgot to ask about that question as well.  I know it is implicit, 
but I actually think it might be nice if you did extend the registry 
(the Service type).  To point at your Support Interface endpoints.
Reason being.
a.)  All our support services are not mandatory.  How is a client/app 
going to know what services are supported or did I miss something in the 
doc on that.  I Don't fancy making them interrorgate the wsdl or 
trial&error such as call the interface method and see if it works.  I 
would suggest possibly extending the registry so there is an 
"enumeration" of what support services you support.
b.) Lets say you have more than 1 endpoint per service.  You can have as 
many Interface and accessURL as you want.  Good example is Registry may 
have 2 web services one for Query and one for Harvesting.  This means 
the web logger service may be very similiar.  Probably heartbeat service 
may be the same.  And the getRegistration might be the same.

cheers,
Kevin



Alex Szalay wrote:

>I was just about to send a note in the same spirit as
>Guy's note. I fully agree.
>
>Cheers, Alex
>
>-----Original Message-----
>From: techwg-bounces at us-vo.org [mailto:techwg-bounces at us-vo.org] On Behalf
>Of Guy Rixon
>Sent: Thursday, December 08, 2005 7:22 AM
>To: grid at ivoa.net
>Cc: techwg at us-vo.org
>Subject: [nvo-techwg] Re: Logging suggestion
>
>It sounds reasonable to concentrate the log-harvesting interface in a
>special
>service for a group of services. However, if we do so, we then need a way of
>recording the log-harvesting endpoint in the resource document for each
>service.
>
>It's implicit in the current support-interfaces spec that the extra
>interfaces
>are extra operations on the main endpoint of a service. Therefore, they
>don't
>need to be separately registered since their access URLs are obvious. This
>arrangement isn't necessary and we can change it if we wish; but we should
>be
>clear about this.
>
>On Thu, 8 Dec 2005, Paul Harrison wrote:
>
>  
>
>>I think that I agree with Doug and Kevin on this - imposing a
>>requirement for a logging interface on *every* service is a significant
>>barrier to implementation, as this sort of interface does not fit easily
>>with existing low level logging libraries, so some sort of adapter layer
>>would have to be written in every service to gather and send the
>>requested information.
>>
>>Having a localised logging service that was able to accept log
>>information in a number of ways that recognised the facilities of
>>existing log libraries - e.g. in java log4j has serveral methods
>>available for remote logging, that are not necessarily web services. The
>>implementer of a web service could chose the easiest way to send the log
>>information to the localised log collecting/storing server - and I think
>>that push is more appropriate.
>>
>>In this way there could be a small number of implementations of the log
>>collecting server, which could then potentially do more complex actions
>>such as periodically storing gathered logs in a vostore.
>>
>>
>>Doug Tody wrote:
>>    
>>
>>>Hi Ani -
>>>
>>>On Wed, 7 Dec 2005, Ani Thakar wrote:
>>>
>>>      
>>>
>>>>There are two different logging services that we are talking about
>>>>        
>>>>
>here,
>  
>
>>>>I think:
>>>>
>>>>    - site logging
>>>>    - VO logging
>>>>
>>>>The first is the logging service at a given site that may or may not
>>>>provide a query interface for users to view the logged data.  This logs
>>>>all the services at a given site (e.g. STScI).
>>>>
>>>>The second is the VO-wide log harvesting that collects the logs from
>>>>        
>>>>
>all
>  
>
>>>>the VO services in a VO domain (e.g. NVO).
>>>>
>>>>Which one do you mean by "centralized logging service"?
>>>>        
>>>>
>>>The suggestion was that the VO logging interface and functionality not
>>>be provided by individual services, but by some centralized site logging
>>>service (specific to VO, not httpd logging or some such)) which the
>>>domain-wide VO log harvestor can access.
>>>
>>>
>>>      
>>>
>>>>The logging interface in the support interfaces draft only deals with
>>>>the minimum that any site or service needs to do to get its log data
>>>>harvested to the VO logging VOStore.
>>>>
>>>>It's fine if each site has a central logging service that has a log
>>>>harvesting interface hanging off it that the VO log harvester can use
>>>>        
>>>>
>to
>  
>
>>>>retrieve log data from it periodically.  Each individual service does
>>>>not need to support a log harvesting interface.
>>>>        
>>>>
>>>This is what was meant by a "centralized logging service" for a site.
>>>
>>>
>>>I still think it would be good if low level infrastructure capabilities
>>>like
>>>service registration, logging, heartbeat, etc., could function
>>>independently
>>>of complex high level data management functionality such as VOStore.
>>>
>>>    - Doug
>>>
>>>      
>>>
>>--
>>Paul Harrison
>>ESO Garching
>>www.eso.org
>>
>>    
>>
>
>Guy Rixon 				        gtr at ast.cam.ac.uk
>Institute of Astronomy   	                Tel: +44-1223-337542
>Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523
>
>
>  
>