perfsonar development work

[Jochen Reinwand <>]

Hi all,

On Wednesday 17 January 2007 19:53, Yee-Ting Li wrote:
> >> Perhaps we - all participants who use or provide perfSONAR
> >> services with
> >> PERL - could collaborate in some way to avoid having the same
> >> developments twice or three times (as now).
> >
> > That would, of course, be a wise course of action!
>
> Agreed; however, i think it would be important to stress that we work
> on the common components rather than creating an entirely new
> framework for everyone that does everything (as it's very difficult!).

Agreed!

> I like the list by Jochen, and i think it's a good start to identify
> the main areas. however, the way i see 'perfsonar' is that it is a
> web service which strictly speaks NMWG between clients and servers.

If I remember it correctly there was some discussion about what perfSONAR 
_really_ is. I can't remember if there was some sort of conclusion...

The term NMWG is normally related to the schemas, to the message format. But 
there is code from Internet2 (containing also web service part), that can 
(perhaps) be seen as "NMWG framework". So there is also the question: What is 
NMWG? 

On the other hand, there is some sort of perfSONAR extension to the NMWG 
schema. I'm not sure whether this has to be seen as some sort of "plugin" or 
it will become an integral part of NMWG. This would perhaps influence the 
structure of the Perl implementation.

> as you guys have already mentioned, it can be as simple as sticking a
> http listener that spits out nmwg. (soap or not)

The SOAP envelope around the NMWG message should be trivial to implement 
since 
perfSONAR does not use many features of SOAP...

> i'm sorry for the confusion; i don't think that porting the java
> 'perfsonar' api is a good idea; ie how the service handles the
> request once it has recieved a nmwg document (like using ibatis in
> java etc). there is way too much complexity in there for the average
> perl coder.
>
> what i specifically had in mind was to port only the java NMWG
> libraries over to perl. as the nmwg spec changes, it should be
> important that existing (perl) services can easily 'update' to the
> latest xml spec. this was the main intention of my original request.

I see! Now I got the point! You really may be right on this issue! I don't 
know the Java code, how big it is, or how complicated. If you think you can 
do it,  you should perhaps really try to do it.

Just one advice: Use XML::LibXML for handling XML! It should provide 
everything you are looking for, like namespace support. It should also be 
quite compatible with the Java APIs, since it is written for "normal" 
programming languages and not Perl ;-)

> the other benefit is that if we were to build an api to the nmwg
> libraries, it would also separate out the need to fix to a particular
> perl xml library.

That's, of course, an important point! It's definitively the preferred way! 
My 
idea of using DOM objects directly was more some sort of quick hack to get 
things working. Nevertheless, it might be useful to make the DOM objects 
somehow accessable, because DOM also has a standardised API and different 
implementations in Perl (like XML::DOM or XML::LibXML::DOM) should be 
compatible to some extend.

> so specifically; taking from Maciej's recent email, 
> to create a new nmwg doc; we simply:
>
>          my $message = Message->new();
>          $message->setId("anId");
>          $message->setType("LSRegisterRequest");
>
>          my $metadata = Metadata->new();
>          $metadata->setId("serviceLookupInfo");
>          $message->setMetadata($metadata);
>
>          my $subject = Subject->new();
>          $subject->setId("commonParameters");
>          $metadata->setSubject($subject);
>
>       (etc)

Of course you are right and this is an API like everyone wants to have it ;-)

> of course, we don't actually need to do anything like this for the
> server end (except for creating the <data/> elements);

Unfortunately you are not right here. Keep in mind: The services need to 
contact other services! Our BWCTL MP already does LS registration (what your 
code snippet is doing, but using a very dirty hack). It will have to contact 
a MA in the near future...

> but we would 
> need a SAX parser to form the incoming xml to the above objects.

Shouldn't this also be possible with a DOM parser? Wrapping around DOM 
objects 
is much easier, but not that powerful...
BTW: libxml has a SAX like interface, too.

> so 
> the real question is how to query for the metadata information so
> that the backend of the server can make the relevant sql/rrd/etc
> requests.

Normally XPath is the best choice for extracting data from XML...

greetings,
Jochen

-- 
Jochen Reinwand                                 Tel: +49 9131 852-8689
DFN Labor

Regionales Rechenzentrum Erlangen
Martensstrasse 1
91058 Erlangen
 
email: