I wasn't able to get the demo to ncphi.phgrid.net yet.

While the demo is set up and running on our internal servers... and we have a way to get into the internal servers for the Phin conference, and while I was able to get the databases and ogsadai bits installed on Dallas (I think) and NCPHI (I know)... I will not be able to get jboss on NCPHI and the demo available for public consumption.

I faced a lot of hurdles that delayed me, including limited server access due to higher priority testing and a 4:00 PM brownout/surge that killed all of our virtual machines. I was tooting along despite that when at 5:30, I discovered that dallas wasn't accessible on port 8443. That is the port OGSA-DAI operates on, and without it I won't be able to see one of the databases needed for the demo.. as a RODSAdai demo isn't that impressive with only one server.

I also tried getting JBoss installed on the NCPHI node, only to find that there were lots of errors generated on startup and a realization that port 8080 is blocked coming in.

Thus, we are facing a big case of interrupted ports, and no-one is in the building who can un-interrupt them.

At least the internal demo is working, and very neat I think.

Remaining SRGM Test Cases

The latest version of SRGM_POC test case document is on the wiki right now with test case 4G to be revisited with either a little more elaboration or a change of approach. I am currently working with Vaughn Mcmullin on that. Apart from that, the case 4J ) Evaluate user interface projects for RFT management and operation (including, but not limited to, job starting/stopping/resuming, route management) ( Req. No 16) is what I am looking into. Early in our work we came across vbrowser which covered a lot of ground, in terms of functionality, as one of the possible UI's. So before we move further in this area, upon Brian's recommendation, I am posting a couple of features that we would want to zero in on while evaluating various UI's
1) Support for manual/interactive as well as automatic transfers. Although, as discussed ,automatic transfers could be more of an added feature rather than a basic requirement.
2) Ability to see the status of jobs going on at any particular time by being able to provide a way to query the persistent storage.
3) Capability to stop the jobs manually in the middle of a transfer, which could remove parts of payload already transferred.
4) As we know,Vbrowser is applet based so making a decision whether we would like to have a web based UI for our purpose.
5) Raj(from Globus) mentioned in one of the calls that they do have a UI implementation also so I will be following up with him whether their implementation covers some of these already.

I also found another UI implementation for GridFTP of WISENT, which is an eclipse based, cross-platform, open-source GridFTP client which allows to transfer, view progress and delete files. Although it would be interesting if they provide support for RFT. Please feel free to check out the url (a flash presentation of the application)
http://bi.offis.de/gridftp/screens/gridftp.htm
Please feel free to add what you would think, could be a feature of the UI for GridFTP.

VBrowser

Communicated through email with Piter T. de Boer from the Informatics Instituut at the University of Amsterdam. We plan to discuss our use of VBrowser as an application and as a plugin development framework after the PHIN Conference next week.

Piter is our first contact with the team developing VBrowswer

caGrid: DCQL Federated Query Processor News

One thing that Ron just learned regarding DCQL is that the Federated Query Processor (FQP) in caGrid will not support delegation until caGrid1.3 which should be out early 2009. So, currently one can do a federated query with authentication (https only), but authorization does not work.

For instance when we tried this at Utah our data grid services rejected the query from the FQP because the query came in under user workflow and workflow is not authorized.

More successful testing of secure grid services!

Ron Price, with the University of Utah CoE, sent over a new demo project this morning to test out the secure invocation of his grid services.

Utah is using cagrid's gridgrouper to manage security configuration (phirg uses manual maintenance of certs at each node), so I created a userid with cagrid (https://cagrid-portal.nci.nih.gov/web/guest/register) and Ron added my cagrid user the PH Grid group.

Ron made it pretty easy to test by providing an Eclipse project export and the required certificates to authenticate with cagrid's Dorian services.

I copied the certificates to the ~.globus folder on my workstation, specified my cagrid provided userid and password, and ran the service from inside Eclipse. Pretty straightforward

When I tried with an invalid password I get an exception thrown back from Dorian (gov.nih.nci.cagrid.authentication.stubs.types.InvalidCredentialFault).

So we tested securely invoking a Utah phGrid service over SSL using the cagrid authentication management from the NCPHI Research Lab grid.

Next steps will be to test out invoking the service using phirg specific credentials.

Demodemodemo

Greetings all.

I was out last week, and this week I was putting my nose to the grindstone... and I got some pretty neat things done with the RODSAdai demo.

I cleaned it up, so it has a simple look with only intuitive controls.
I managed to get a server-merge in the demo app, thus allowing for data to be spread across different servers and aggregated when multiple servers are selected.
I managed to get some geocaching set up so that the page loaded a lot faster after the initial runs.

I owe many thanks to Brian for being a great sounding board. He was the one that turned major redesigns in my head into minor UI tweaks.

Distributed Query Diagram

Some important stakeholders had some questions about how the distributed query built for the RODSA-DAI demo works so Tom and I came up with some diagrams that should help to more clearly describe.

The demo is basically showing how you can run a distributed query on multiple nodes to perform an aggregate count analysis (by syndrome) and then return the results to a coordinator node that combines the aggregated results into a single collection and display it in an application (such as Google Maps).

Also we're currently only querying by syndrome and returning counts, you could easily add multiple dimensions on the criteria and the results (age, gender, date range, region, etc. etc.). Link to wiki entry with images and visio diagram.

In case you wonder why the blog is a bit quiet lately, it is because we're all preparing for the PHIN Conference's grid related presentations and demos.

SRGM Progress

Here's the update on SRGM test cases. With the combined efforts in the past couple of weeks we have been able to cover a lot of ground on these test cases. The ones which are still left are :
1) Transfer HL7 file from partner node (node B) to CDC lab node (node A) using PHINMS issued digital certificates.
2) Evaluate user interface projects for RFT management and operation (including, but not limited to, job starting/stopping/resuming, route management).
and the ones which are knocked off the list are :
1) Evaluate reliable GRIDftp and WS-RM against OCISO guidelines and requirements
2) Evaluate reliable GRIDftp and WS-RM against NIST guidelines and requirements (specifically, but not limited to, the FIPS 140-2 Cryptographic Module Validation Program; FIPS 200 Minimum Security Requirements for Federal Information and Information Systems).
3) Configure lab node and partner node to use PHINMS digital certificate.
4) Transfer HL7 file from partner node B to partner node C using stored at CDC lab node (node A).
5) Test ability of Globus components to integrate into existing PHINMS infrastructure (transfer of program payloads through both PHINMS and Globus).
6) Evaluate capabilities for unattended retries/delivery of payload file.
7) Evaluate capabilities for end to end payload level encryption (Done thanks to efforts of Vaughn Mcmullin, the document still needs to be updated with teminal snapshots)
8) Evaluate capabilities for guaranteed once and only once delivery of file and the robustness of its duplicate file detection
9) Evaluate capabilities for large payload (> 100 MB) reliable delivery.
10) Evaluate capabilities for file payload encryption for strength and validity.
11) Evaluate capabilities for reliable data exchange for once-and-only-once transport of payload data.
12) Evaluate reliable GRIDftp for reliable messaging for reliability due to node availability

So all in all of the 14 cases we have finished 12, 2 more to go, the completion of which we will be on working on next week.

PH case reporting scenario development project

An update on a project started a couple of months back for developing a PH case reporting scenario

The purpose of this activity:
To better understand the epidemiologists' workflow so we can align the PHI research grid activities to public health practice as well as AHIC case reporting use case.

Work done so far:

• Abstracted public health related information transaction steps from the AHIC public health case reporting use case
• An epidemiologist mapped the AHIC use case to a scenario in her daily activities
• The PHI research grid project team mapped the draft scenario activities to the PHI research grid activities (i.e., current Proof of Concept (PoC) projects and planned PoCs)

Plans:

• Select 3 - 4 consecutive steps from the use case scenario to work in more detail, i.e. describe in terms of who, what, when, etc (described in the scenario draft).
• Develop context flow diagrams and task flow diagrams for the 3-4 selected steps
• The PHI grid developers' team will use the above mentioned diagrams to better align the technical use cases
• The PHI grid project design team will use the above diagrams (and the full scenario) to plan further proof of concept projects

Ref material:

• AHIC case reporting http://www.hhs.gov/healthit/usecases/phcr.html
• Draft public health scenario (available on the PHI Grid wiki)

Comments and suggstions will be greatly appreciated!

Axis problem has functioning workaround

To address the axis mismatch problem (described here), we developed a separate RODSAdai download servlet that can be called by the RODS application to return either a TimeSeries or SpatialSeries object serialized over HTTP.

Jeremy has tested this in his Pittsburgh environment and it is working.

Mario also mentioned a tool called Jar Jar Links (http://code.google.com/p/jarjar/) that may be able to help. We'll investigate this once the time is found.

So good news is that we're no longer blocking on the custom Axis 1.2RC2 that Globus uses.