Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] perfSONAR API

Subject: perfsonar development work

List archive

Re: [pS-dev] perfSONAR API


Chronological Thread 
  • From: Maciej Glowiak <>
  • To: Jochen Reinwand <>
  • Cc: "" <>,
  • Subject: Re: [pS-dev] perfSONAR API
  • Date: Tue, 10 Apr 2007 14:59:35 +0200
  • Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA CXBIWXMAAEU1AABFNQF8gVf5AAAAB3RJTUUH1QYQDjo6uEWvwgAAAM5JREFUGNNN0LFqAkEUheGj KRZsfATrvENgYyH4APabxwgWGUUQC99BsNDCInUq7VImbbDZ0kayxBXMuN7jvTuKVh//mZlmQKZ1 EhQ8GAVgZECspEBdWQHRjR70KlgFKkoUaCw3ijSYQ4n5HfBK4a4jDcdDQPol/80Sr9BxZOOL4Fmr Jq8VBx7eopaSPvWGOm67fqol3j1q0XNs7Nk2cs6MU6gPNzf+ZGKQX4Ek8H6rAnFZnXB2vJxJcv8g C2P+WzL4tD+Txc4KydrIkh+eAdo01QbjQ84vAAAAAElFTkSuQmCC
  • Organization: Poznan Supercomputing and Networking Center

Hi Jochen

Jochen Reinwand wrote:
Hello Maciej,

On Thursday 05 April 2007 15:39, Maciej Glowiak wrote:
I have similar impression how the client API should look like.

From the examples you gave I can see that what you have in Java and also what
you're planning to do is really exactly what I had in mind ;-)
I wonder what the problem was during the discussion in Utrecht...

Hmm, I think there were several discussions on that topic. One was Client API for LS. In general, people wanted:
1) definitely to have it
2) to have it quite generic (to be re-used in other services)
3) to have also API for other services - without discussing on what,
when and how. That were more or less fuzzy discussions.

There are NMWG classes for Message construction and Axis functionality
for SOAP. Unfortunately Axis uses DOM Document to store date, so our
NMWG "DOM representation" must be converted into DOM Document. That's
the performance issue to be resolved in the future.

Yes, DOM can cause performance problems... Seems like the Perl implementation of SOAP uses its own parsers. Perhaps they encountered similar problems by just using some DOM module. But we are also using DOM for our perfSONAR Perl implementation. So far the performance seems to be acceptable. The DOM implementation we're using is more or less the Perl interface to the standard Open Source C/C++ XML library libxml. This library seems to be quite fast and C/C++ always tends to be faster than Java ;-)

But, anyway, seems like there is no "disagreement" on API design itself. So we can most likely close this discussion.

Yes, but the topic will be coming back... :)

DOM itself is not a problem. The problem is with multiple conversions. Axis uses DOM Document. Our services use NMWG classes. So we need to convert twice to and from NMWG. We could get rid one of two:

a) NMWG classes and use just DOM Document
b) Axis and use HTTP+NMWG classes

We had quite long discussion on it but in fact we need both of them. Axis for security (we agreed not to remove Axis until we decide how to implement AA, perhaps using WS-Security). NMWG classes are useful for developing our services in Java. We don't care about all the syntax of NMWG, we just create objects.


I'm still thinking about using the Java extension of Perl to directly use the perfSONAR classes from within our Perl code...

That could be interesting to investigate.

Maciej

--

--------------------------------------------------------------------
| Maciej Glowiak Network Research and Development ||
|

Poznan Supercomputing and Networking Center ||
| (+48 61) 858 2024 -- skype_id: maciej_psnc GG: 4526858 ||
====================================================================



Archive powered by MHonArc 2.6.16.

Top of Page