perfsonar development work

[Maciej Glowiak <>]

Hi Michael,

Sorry, but I missed your mail before. We've already had the discussion 
in Zagreb on that, but I think most of your ideas will be implemented.

Michael Bischoff wrote:
> http://wiki.perfsonar.net/jra1-wiki/index.php/JRA1_Meeting_-_Zagreb#New_pS_base_and_web-services_improvements
>
> 'Comments will be welcomed.' Well, here you go:   ;-)
>
> Explore the use of flyweights, in nmwg java implementation(to lower memory 
> footprint esp with
> big requests.)

Now the implementation is lightweight, however there is a need to keep 
similar API for NMWG classes, so we introduced new classes, however 
based on on simple Element class. There won't be separate class for 
various namespace:element pairs. All object may be handled with just 
Element class, otherwise there are mappings such as:

-------------------------------------------------------------------------------------
<protocolMappings>

      <!-- default mapping -->
      <element name="*"
               mapping="org.perfsonar.base2.xml.Element"/>

      <!-- general mappings -->
      <element name="{http://ggf.org/ns/nmwg/base/2.0/}message";
               mapping="org.perfsonar.base2.xml.nmwg.Message"/>
      <element name="{http://ggf.org/ns/nmwg/base/2.0/}metadata";
               mapping="org.perfsonar.base2.xml.nmwg.Metadata"/>
      <element name="{http://ggf.org/ns/nmwg/base/2.0/}eventType";
               mapping="org.perfsonar.base2.xml.nmwg.EventType"/>
      <element name="{http://ggf.org/ns/nmwg/base/2.0/}data";
               mapping="org.perfsonar.base2.xml.nmwg.Data"/>
      <element name="{http://ggf.org/ns/nmwg/base/2.0/}subject";
               mapping="org.perfsonar.base2.xml.nmwg.Subject"/>
      <element name="{http://ggf.org/ns/nmwg/base/2.0/}parameters";
               mapping="org.perfsonar.base2.xml.nmwg.Parameters"/>
      <element name="{http://ggf.org/ns/nmwg/base/2.0/}parameter";
               mapping="org.perfsonar.base2.xml.nmwg.Parameter"/>

      <!-- LSQueryRequest mappings -->
      <element
name="{http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/xquery/1.0/}subject"; 

               mapping="org.perfsonar.base2.xml.nmwg.Subject"/>

      <!-- LSRegistrationRequest, LSControlRequest mappings -->
      <element
         name="{http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/}subject";
         mapping="org.perfsonar.base2.xml.nmwg.Subject"/>

</protocolMappings>
-------------------------------------------------------------------------------------


> Perhaps only load SAX_config_file once and keep mappings.
> (keep the MessageHandler around)

There will be one hierarchical XML configuration file that will be 
mapped into objects (use of digester). They will be static, so will be 
shared among all requests. However we're thinking about using dynamic 
configuration as well.

> Change life-cycle of ServiceEngine's (make them stateless beyond 
> initialisation(like servlets))
> - allows for one time initialisation
> - lowers amount of work that needs to be done per request (no need to 
> reflectively create and
> instance just keep it in memory. Allows us to remove checks)

It's done, I think. Configuration is read once and a request is just 
parsed and proper service engine is run. We left similar structure 
(RequestHandler -> MessageHandler -> ServiceEngine) to ease developers 
migration into new structure.


> Improve quality:
> Assert FindBugs results.

Do you mean http://findbugs.sourceforge.net/ ?
I haven't been using that so far.

> Identify dependencies and describe what they are used for/by and perhaps trim 
> them?
> Distributions of the base with dependencies is quite big. (Our war is 17 mb 
> which is a lot
> for something that doesn't feature pictures or other media)

I know. Most of dependencies will be trimmed. For now Axis, CIMOM and 
StAX are used. We removed all DOM, Xerces, and other unnecessary 
dependencies, however ps-base will probably contain some specific 
functionalities that requires some special jars. Anyway, we want to keep 
the new base lightweight.

> Run it through a profiler (might have already be done.)

For now we're working on a prototype. There are several goals:
- get rid of old NMWG classes (unmaintained)
- migrate to Axis2
- XML config
- simlify and rewrite old, weird code

I think when we have a prototype, we'll ask developers for evaluation 
and additional testing. Then there will be time for profiling and other 
improvements.

> Also as this has been a longer standing for others have a look at to replace 
> axis into
> somethign 'newer' Axis2 xfire etc. Although that's not a specific personal 
> wish.

By default Axis2 will be used. However we wanted to separate SOAP 
library from internal NMWG representation. So, after implementing the 
parser new base will be able to run with Axis1. XFire should work 
without modifications.

Maciej

ps. I'll send the presentation in some time as well.



--

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

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