GridMedlee Progress

Making progress on GridMedlee testing. I have altered the initial client code to add security options. I have gotten it to the point to where I am receiving a error of Unknown CA. In speaking with my team members this issue should be resolvable by running the code from a controlled node rather than my local laptop. I am in the process of moving the code over to the controlled node and will (hopefully) get it running from there.

Along the way I picked up some knowledge with regard to the GlobusCredential class. When the Introduce framework created the test client for GridMedlee there were several versions of the GridMedleeClient method that were created, some included a parameter for a GlobusCredential object. Upon further investigation I found that the GlobusCredential class can be used to create secure credentials.

I will have another update later today after I get the GridMedlee client built on the controlled node.

Axis mismatch is hurting RODSAdai

Dr. Espino discovered a pretty serious bug with how we are planning on using Globus that is preventing the RODSAdai code from running within the same war as RODS.

It comes down to Globus 4.0.5 using a customized version of Apache Axis 1.2RC2 (modified to specifically support Globus services). RODS (like many modern Java applications) also uses Axis. RODS specifically uses version 1.4 of Axis. The version of Axis used by Globus conflicts with the version of Axis used by RODS and is causing the RODSAdai code to fail.

The idea of RODSAdai is that it is a jar that can be included in RODS (or other Java applications) that calls out to OGSA-DAI services on the Public Health Research Grid. So it is beneficial to have the RODSAdai code be as drop in and easy to use as possible.

Jeremy and I had a call with the OGSA-DAI folks (Alistair and Mario) where they basically helped us work out that this is a limitation of Globus, not necessarily of OGSA-DAI. Mario is taking this question to the Globus community to ask how they typically deal with this situation.

In the meantime, Jeremy and I came up with a hack that should work for demo purposes until we get a proper solution from the Globus folks. We're running separate wars for RODS and RODSAdai. This will allow RODS to use the Axis 1.4 jar and RODSAdai to use the Axis 1.2RC2 jar that Globus/OGSA-DAI requires. The hack is that the two wars need to communicate with a HTTP based IPC. Not beautiful, but we'll see if it works.

I added a new servlet to RODSAdai to support this and Jeremy will test it out in his environment later today. Updates will be posted here.

We also found out from OGSA-DAI that they are working on a version that will work with Globus 4.2. Which should come in handy as Dan begins our 4.2 transition testing and planning.

Different Databases

Today, I got the RODSAdai test data split across different databases. I still have a few things to work on before the next demo... and I am going to be on vacation next week so I spent a lot of today documenting steps and locations of things and fearing the fact that people would be looking at my "gotta get this working" code.

Otherwise, everyone seemed to like the demo's we did this morning. So that makes me happy... and I will still have a week to polish things up and help externalize the demo before the PHIN conference... and I feel good that I got the basis of tests I wanted working before I left.

See you in a week!

Testing, Testing and more testing

• I spent the day working with the GridMedLee services and I feel I have made a lot of progress. I modified the client code sent to me to invoke the GridMedLee service. Currently working through what appears to be a security issue with getting a status back from the GridMedLeeContext service. I have some ideas of a few things to do on my end to try to make sure my set up is functioning properly.
  

• I also went back and re-ran the client for the ZipCode service for Utah and I am getting the same message from their service that I am receiving with GridMedlee.

• I also installed WireShark locally to be able to actually view the contents of data being sent between the client and the server.

Stay tuned friends more to come as I delve deeper into Globus security.

We've got dots, and they are indicating levels.

After a lot of tinkering with the google maps API and a lot of things that theoretically should work but didn't... I managed to get dots showing up on a google map and color-code them based on the level of incidents indicated by the query. They also load a bit slowly because of how I had to encode the data series, but it works, and that is better than before. I also have lots of ideas of how to make things faster and prettier given time thanks to Alastair and Mario of Ogsa-Dai, who helped me kick around ideas.

Next steps are to bisect the databases and put them on different database servers... wire up such nifty bisections into the demo app, and if time allows, start integrating the results.

I am happy. I got dots.

Globus 4.2 & OGSA-DAI News

Learned the following through the grapevine:

OGSA-DAI will not be part of GT4.2, although it will be possible to download, install and configure it separately.

In short OGSA-DAI can be added as extensions to the core GT4.2 installation.

Globus thinks XQuery may bridge federated queries across an OGSA-DAI / DCQL (caGrid) federated query services.

Building Demos

I got some very cool news from Dr. Espino today, that he had gotten RODSAdai building and happy on his end, and will probably be able to integrate all the code within a week. Furthermore, he added much better logging code (log4j complete with properties files), some null checking, and some defaults. I have successfully updated everything and adjusted to fit my own environment.

On the demo end, I have discovered many things that will not work with google maps as I envisioned them. I was thinking of doing real-time geocoding of zip codes, but that would turn one javascript request to google into about 30, and there are already free databases of zipcode geospatial locations. Furthermore, I am not sure of the best way to just lay out all the data given google's finicky timeouts (thus, if your application takes a while to generate a KML file, you will need to generate the file and place it somewhere in an accessible spot and then tell google to find it there).

Considering I am not exactly working on an accessible node, I am beginning to think it might just be easier to use JSP loops to build an array and then place that array into one of googles marker manager objects. Perhaps there is a way to pass KML into a google map directly? I will probably tinker with this at home.

Preppin' for Demo's

So, today we had the initial big discussion of how we want to demonstrate the neat things that have been coded for the upcoming PHIN conference.

My first priority is to Dr. Espino to try and get RODSAdai working with RODS so he can show multiple data source RODS info pulls.

Otherwise, while I am not helping him, I have the following bits in my stable:

• RODSAdai through google maps
• Split data sources for to demonstrate different data in different places.
• Set up a check-box "one or many" database location selection.
• Enable a spatial series that can display through google maps and/or google earth.
• Server Location Admin Screen
• Have the ability to declare a new server/resource location and modify existing locations.

I'm looking forward to it. I have also reached out to the OGSA-DAI folks for help with the Google Maps portion of the demo since they already did it once with their demo.

SRGM Progress

I talked to Raj(at Globus) regarding providing more details regarding the RFT Flow diagram provided. I will be upgrading the version on the wiki as soon as I get it.

On the test cases, the PHINMS certificate has been installed on the nodes. So no a successful transfer will knock off another test case 4E : Transfer HL7 file from partner node (node B) to CDC lab node (node A) using PHINMS issued digital certificates (Req. No. 05 & 06).
The test case document on the wiki will be updated as soon as the test is finished.

Also as Brian, Dan,Vaughn and me talked, one of the enhancements mentioned was having the option to set flags for optional parameters regarding the file being transferred. One criteria which came up was having a flag to set for Time Sensitive Data(as in if the file does not reach within specified time frame, discard it). Globus folks agreed that it would be a good feature to have and they can include it in the next version. Also, please feel free to add if you think of some more enhancements and we can convey them to Globus folks further.

Local Globus Install Completed

I completed the local installation of Globus with a Simple CA (using section A.3 from the Globus 4 Programming book as a guide) on my laptop yesterday afternoon. This will allow me to deploy the Columbia medLee project locally for client coding and testing purposes. It took a couple of tries to get the Simple CA installation to function correctly with Globus.

Some of the lessons I learned when installing Globus:

1. Certificates -- always select root install for certificates (option r) rather than the local install (option l)
   
2. Manually copy the *.pem files from globus/etc directory to /etc/grid-certificates directory
3. Edit the system bash resource file to source both the VDT setup and Globus user env scripts so that the necessary environment variables are available after logging into the system