ABBI's First Data Holder Connection to IHE XDS via OHT

I started my ABBI Prototype yesterday by refreshing my development environment.  The next step was to ensure that I could connect my application to a Web Service that would provide data I could start playing with to develop the service.  I spent several hours last night trying to get it to work and went to bed having not succeeded.  Today, I finally got it to work.

The architecture for my prototype is based on the IHE Documents for Mobile Health profile.  It will respond to RESTful queries by reformatting them into XDS/XCA queries to an Initiating Gateway, and return responses that reformat the ebXML gunge response into an Atom feed that is much more useful for developers.  So, my first step was to connect my application to the NIST XDS Test Facility on the intertubes.

I've used this in the past, but it's been a while.  Refamiliarization took a little bit of time.  When connecting to the NIST Test facility as an XD* Client, the first thing you need to create is a patient identifier.  It took me a bit to find this page where I could do that.  That page also points you to testing tools that allow you to perform queries on that identifier, submit test data, and a bunch of other goodies.  It's great that I don't have to create a full blown XCA Server just to test my prototype.

Having now created a patient, and given them a document, my next step was to ensure that I could create an application that would be able to do the same.  As I mentioned previously, I'm using the Open Health Tools IHE Profiles project to do that.  This is where I got stuck last night.  I'm apparently an odd-ball, in that I like to write POJO's to do the work, rather than adding a bunch of other stuff.  I suppose I could have used the Bridge to make life easy, but that requires I configure another service, and I'm always swapping Tomcat in and out depending on what I'm up to right now.  It's not like I have extra computers devoted to my build/deployment environment.  It's all running on my laptop.

The challenge I learned later has to do with the way that Axis2 works.  It needs to be configured with an XML file that you have to tell it where to find.  That doesn't come with the ihetools project of OHT.  You have to pull it from another project.  It also likes to be in charge of class loading.  This is in part because you need to be able to maintain several versions of a handler in memory at the same time to deal with different possible cases where messages can be handled in various ways, with multiple services running at the same time, et cetera, and so on.  So, rather than putting certain things in my classpath, like I'd expect (or in WEB-INF\lib), I had to do things differently.  Axis 2 is cool.  But it's also enterprise class software, and quite honestly, for a client application, is probably overkill.

Somewhere along the line, I decided to replace the Axis jar that shipped with OHT with the original jar files that come from the Apache Axis project.

It took me quite a while to figure out how to make things run, but eventually, I figured out the right command line switches, and everything worked.  Today, I was able to verify that I could connect to the NIST Test Registry and get metadata about my test patient's documents in a simple POJO with a main() method.  The next step was to make sure that my Web Application, which would be serving up the ABBI API could do the same.  It turns out that starting Tomcat with the same JVM switches solves the problem.  It's NOT the right way to do it, but it works.  I can dink with classpaths and server.xml files later.

My first test isn't connecting to the NIST Registry securely.  To do that, I need a certificate.  I think I have one from last year that still works, and I'll be getting a new one for the connectathon this year.  For now, I know what needs to happen, and how to secure that link.

My next steps are to figure out how I want to set up the prototype to show off what it can do.  Now that I know I can get to the data, generating queries from RESTful API and transforming results into atom are just a simple matter of writing code.

  -- Keith

---

If you are an OHT User, these notes might be helpful to you if you just want to write simple Java command line applications to access an XDS Registry.

1. Download the IHETools ZIP File from OHT
2. Unzip it and copy the resulting JARs to location1.
3. Rename  location1/org.apache.axis2_1.4.1.jar to location1/org.apache.axis2_1.4.1.bak
4. Grab Axis2 from Apache's web site (I used V1.4.1) and unzip it to location2.
5. Download axis2.xml from here and put it in location3.
6. Copy location2/repository/modules/addressing-1.41.mar to location1/addressing-1.41.jar
7. When you run your Java application, add these parameters:
1. -Djava.ext.dirs=location2/lib 
2. -Daxis2.repo=location2/repository
3. -Daxis2.xml=location3/axis2.xml
4. CLASSPATH=location1

These do several things:

1.  Makes Java happy about where to find and how to load certain Axis classes.

2.  Makes Axis Happy.

3.  Configures Axis to generate SOAP Headers.

4.  It makes it possible for your application to find the addressing module which is needed to generate those SOAP headers.