perfsonar development work

[Michael Michalis <>]

Nicolas Simar wrote:
> Loukik Kudarimoti wrote:
> > Verena Venus wrote:
> >
> > > Hi Loukik,
> > >
> > > Am Monday 09 July 2007 13:16 schrieb Loukik Kudarimoti:
> > >
> > > [...]
> > >
> > > > I think its very beneficial to have this functionality and is very 
> > > easy
> > >
> > > > to implement it (It shouldn't take more than a couple of hours). 
> > > But I
> > >
> > > > would say that its up to you guys. All services in perfsonar 2.0 
> > > (except
> > >
> > > > bwctl mp) support this functionality.
> > >
> > > >
> > >
> > > In fact we do support this feature in the 0.2.1 release of our service.
> > Ok, we weren't aware of your new micro-release. Can you drop an email 
> > to release management whenever you produce a new micro-release?
> >
> > > > As far as a "definition of what is a proper perfSONAR service" is
> > >
> > > > concerned, we don't have any such document yet.
> > >
> > > > Nicolas, Szymon, any thoughts?
> > >
> > > >
> > >
> > > I'd like to bring up the idea of a perfSONAR validator (again), 
> > > which should be easy to accomplish, now that we have the SOAP UI 
> > > test projects for the services. Just extract what all these test 
> > > files have in common, and you have testing script for common 
> > > perfsonar services. This could also be the starting point for 
> > > defining what a "proper" perfSONAR service is.
> > >
> > > And obviously, we have a need for such a thing (see Mark and Matthias).
> >
> > I take your point on the need for such a validtor. However, I think 
> > such a validator would still need a documented definition of what 
> > exactly does it need to validate (i.e., what features should it be 
> > checking for). I think we need an initial list (like echo 
> > functionality, ls registration, result codes, doc/lit style, logging, 
> > wsdl, etc)
>
> That sounds like a reasonable starting point at those functionalities 
> are used by multiple services.
>
> Loukik and Michalis, have you got an idea on how we could proceed? Can 
> we re-used some existing part of the functional tests?
Some parts like echo requests are common between services so already 
made functional tests can be used. LS registration so far was tested 
manually Result codes are also  kind of unique for each service. Doc/lit 
style  can be checked  indirectly when checking for the echo request ( a 
service not using doc/lit will return a soap fault).  Logging is not 
currently directly checked and wsdl files produced at least for the java 
services are too general to check.

If we are to have a perfSONAR service validator we must first put down a 
list of the features and characteristics a perfSONAR service should 
have. If the list is something like the above then i suggest that we 
develop a set of tests around the echo request along with tests 
verifying the LS registration(I'm not sure how to test logging).

So I propose a pre-testing stage  where the service is checked whether 
it fits in perfSONAR minimum specifications and  requirements and if so 
then proceed to further testing.

This set of tests can be build around the echo request. Using the echo 
request we can determine if the service actually uses doc/lit style, if 
it can respond with a result code and not a soap fault and of course the 
echo request functionality. We must also develop an automated way to see 
if a service has the ability to register to the LS(A query to a certain 
LS after deployment and after undeployment may do the trick). And we 
also need to see if further tests need to be developed for any other 
requirements.

#OFF TOPIC#
Its quite interesting because I'm currently investigating a tool brought 
under my attention by Andreas. Its actually a tool used for deploying 
web services with a build in testing mechanism which may came handy to 
us. 
http://smartfrog.org/presentations/distributed_testing_with_smartfrog_slides.pdf  

#OFF TOPIC#

-Michalis
> Cheers,
> Nicolas
>
> > Loukik.
> >
> > > Kind regards,
> > >
> > > Verena
> > >
> > > --
> > >
> > > Verena Venus - DFN Labor
> > >
> > > Regionales Rechenzentrum Universitaet Erlangen-Nuernberg
> > >
> > > Martensstrasse 1, D-91058 Erlangen