XCA Implementation

A while back I began working on a project where I had to develop an XCA service. For those of you who don.t know what XCA is, see this: Cross-Community Access (XCA). XCA is a supplement of the XDS.b standard, which is Cross-Enterprise Document Sharing (the .b. as opposed to .a. for the older version). Well, I find that there is plenty of specifications on XCA and XDS.b in PDF form, but they seem to focus on the format of data being sent over the wire, not really how to implement the service that communicates that format of data.

Initially, someone told me that I could just generate code out of the XSD and WSDL. This sounded great in theory and I had done that for working with CDA documents, but in this case when I tried to use XSD.exe to generate objects for the RIM.xsd schema it gave me a number of errors that elements were missing, so I gave up on that after reading articles on the internet where other people were having similar problems. One statement indicated .IHE is working on creating an XSD that is compatible with Microsoft.s XSD.exe tool, and will be out shortly.. Unfortunately, that post was made quite a while ago and I couldn.t find anything about a newer version from IHE.

So, instead I looked into using Microsoft.s implementation of XDS as an example to implement just my own little pieces. Their interfaces used a very odd approach of accepting (and responding with) raw System.ServiceModel.Channels.Message objects. In this case, I parsed and created raw XML and converted that raw XML into the Message object.

The main issue I had was with attachments. Sure, the WCF service I setup for the interface and implementation class could accept and read the message, but attachments couldn.t be returned in MTOM/XOP format, they could only be returned in MTOM as embedded base64 data. This was reasonable for the moment because the XCA supplement supported embedded attachments, it just meant that the project couldn.t support multi-part attachments.

Now, I am trying to use NIST.s XDS Test tool to test that the (new XDR and) XCA service works. I was able to get the XDR portion of the test to work, but ran into an issue with the XCA tests where it told me .Request was SIMPLE SOAP but response was MTOM.. So now, I.m questioning whether or no the approach from Microsoft was a good one or not (which I.m thinking was not).

So, I started taking another look at generating a service interface and code from the XSDs. After scouring for three hours and talking to several people I figured it out. The first thing I was missing was IHE’s XCA Implementation Notes. Originally, I got the XSDs from a zip archive I found somewhere. I have just continued to use those XSDs because every time I looked for the XSDs on IHE.s website, I came up with nothing. Well, I finally found IHE.s XSDs and a WSDL within the .XCA Implementation Notes., the section called .Missing Web Service protocol information. (the link called .SupportMaterial.).

However, still after calling “wsdl.exe RespondingGateway.wsdl”, I got errors indicating that elements were missing. Eventually I stumbled onto a post from Scott Hanselman called .XSD.exe is kicing my butt, man.redux. which had the answer. Simply put, XSD.exe and WSDL.exe doesn.t support <import> within the XSD, so you have to manually specify all of the relevant XSDs in the command line. After doing so, I was able to generate code AND an interface for my service. I.ll just have to refactor the class and interface names a bit and it.ll be reasonable for use. I just hope that this different approach fixes my problems with attachments and with the XDS Test tool.

To generate a full interface:

1) Download the files from ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr5-2007-2008/Technical_Cmte/SupportMaterial or from this archive I made.

2) From the Visual Studio 2008 Command Prompt (or whatever visual studio command prompt is appropriate for your version of VS) run:

wsdl /serverInterface RespondingGateway.wsdl query.xsd rim.xsd lcm.xsd rs.xsd XDS.b_DocumentRepository.xsd

Leave a Reply

Your email address will not be published. Required fields are marked *