RODSAdai, PoiConDai, and NPDS-ws

Today I started off by having a productive discussion with the folks who helped me with RODSAdai: Dr. Jeremy Espino from Pitt (who brings the RODS) and Mario Antonioletti and Alastair Grant from University of Edinburgh (who bring the OGSA-DAI).

We discussed future developments, concerns about security, scalability, and automating installation and configuration as much as possible. We also talked about our availability being reduced for the next phases... But mainly we talked about the fact that one of the things that got lost in the making of RODSAdai 1.0 was a quick and descriptive design document that explained what we were all trying to do and how. Something so that Alastair, Mario, or Jeremy would be able to go "oh, well to connect it that way you should try configuring it like this..." Furthermore it is much more likely that the whole Axis/Globus conflict would have been found earlier and mitigated sooner since Alastair was already familiar with that particular limitation. Thus, the first step for the next phase of RODSAdai is to take the ideal-state and current-state diagrams of RODSAdai that I made, and more information about what they mean, how they currently work, and how I hope to get them working to focus advice and let anyone search for red flags.

But I won't be able to do that until Thursday of next week, because right now I am in demodemodemo mode to get PoiConDai in some form of pretty graphical display so we can show that yes, we are pulling Poison Center call data into the CDC.

This was greatly moved forward this morning with the help of Dr. Espino, namely because he already wrote code that used AXIS to consume the NPDS webservice a couple of weeks ago and had already incorporated all of the JAXB libraries needed for parsing the "any" response returned by the web service. The codebase is called npds-ws-client, and I am going to use it because it is pretty and is along the lines of what I was going to do, only with the properties file and return serializing I was planning on doing already implemented (and thank goodness for it).

Let me pause here to say how much I love maven again. It has extensions for generating axis stubs and jaxb code, so all you need to do is have the WSDLs handy and you don't have to worry about constantly regenerating the parsing bits and movig them about manually. How cool is that!?

Meanwhile, my next step is to incorporate a few of those unit tests I posted about earlier, and then set up a web-client front end that I am going to call PoiConDai web for showing the data in an ever-snazzier JSP. I think I am going to get something really nifty ready by Tuesday Evening.

I can access the PoiConDai WSDL... but it's returning "any"

So, I spent most of today putting together a little program to test the webservice.

I have gotten to the point where I can get the webservice to respond... and it seems to not be throwing any errors...

But there is a problem.

The return type of the webservice is marked as "any"

As opposed to laying out the return type and defining the structure of the object (which really should be the point of any webservice)... the WSDL defines the "any" type, therefore axis makes no attempts to seriealize or deserialize the object being returned, and I am pretty much going to have to go into the big bucket of XML parsing to deserialize all the data myself.

I might be able to patch the structure back into a local WSDL and regenerate the classes...now that I can read what the format is... and get AXIS to do it for me, but we'll see.

Maybe introduce has better metadata introspection, but I doubt it. Either way... it's a whole bunch of annoying extra work.