[news.eclipse.technology.ohf] Re: OHF Bridge 0.3.0 problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]

[news.eclipse.technology.ohf] Re: OHF Bridge 0.3.0 problems

From: Matthew Davis <mattadav@xxxxxxxxxx>
Date: Wed, 26 Mar 2008 14:41:35 -0700
Newsgroups: eclipse.technology.ohf
Organization: EclipseCorner
User-agent: Thunderbird 2.0.0.12 (Windows/20080213)

Robert,

I'll try and cover the questions that Sarah didn't get to.

First let me give a quick note. The OHF Bridge is *NOT* "an IHE interface". It's not designed to be interfaced by an IHE actor. (including the xdstest2 tool). Its purpose is strictly to enable non-Java implementations to use the OHF components for IHE support. The Bridge uses what amounts to be a proprietary / custom interface to simplify this support. It does not implement any of the Web services specified in the IHE Technical Framework nor should anyone try to point an IHE actor at it. Its existence is a simplification layer on top of the existing OHF plugins.

> 2. If I use the bridge.war in Tomcat, and I want to utilize that
> bridge to point to my backend WS, I need to implement all the WSDL
> that the bridge exposes, correct?

Correct. As stated above, the Bridge WSDL does not specify an IHE interface. It is a custom interface designed to simplify / enable use of the OHF components by non-Java applications. When you generate client stubs from the Bridge WSDL, do they do not represent any IHE constructs. It's a relatively simple, custom API that transforms calls to the Bridge into the appropriate calls to the OHF PIX, PDQ, XDS, and ATNA plugins.

Here's a code snippet from the Bridge that will XDS stored query for documents by a patient id. Note that I am calling the Bridge API directly in Java here (as a POJO) but in reality this would be called using a Web service proxy.

PatientIdType idType = new PatientIdType("cc7b3bf3bd964e0"); idType.getAssigningAuthorityType().setUniversalId("1.3.6.1.4.1.21367.2005.3.7"); idType.getAssigningAuthorityType().setUniversalIdType("ISO");

// set up query preferences DocumentQueryPreferencesType queryPreferences = new DocumentQueryPreferencesType(); queryPreferences.setReturnReferencesOnly(false); queryPreferences.setStoredQuery(true);

SessionContext sessionContext = new SessionContext();
sessionContext.setRhioName("rhio name");
sessionContext.setInitiatingUser("tester");

OHFBridge bridge = new OHFBridge(); QueryDocumentsResponseType response = bridge.QueryDocumentsByPatientId(sessionContext, idType, queryPreferences);

(note that calling bridge.QueryDocumentsByPatientId would call your Web service proxy in an instance where you're using the Bridge as a Web service)

This code snippet would call the OHF Bridge. The Bridge would use the information provided (such as the RHIO name) to setup the OHF XDS Consumer and invoke a stored query. The XDS Consumer creates the ebXML request, sends to the registry, and parses the response. The Bridge decodes the response and returns a list of metadata.


> 3. Suppose I have the bridge.war in question 2, is there a tag so that
> I can pull all the source from CVS and build it myself, or must I
> always pull trunk (buggy at best)?

The code that was tested at Connectathon by several vendors is tagged "OHE_IHE_POST_2008NACTHON".

> 4. If I decide to write my own code to hanlde consider writing code
> like the Sample Code in http://wiki.eclipse.org/OHF_Using_XDS.b but
> not using OHF, is it likely to be a large effort compared to using
> OHF?  (I am not referring to the Bridge here).

We've been working on our implementation for over 2 years now :) The amount of work / time needed will vary based on prerequisite understanding of the IHE Technical Framework for XDS, PIX, PDQ, and ATNA. This includes knowing ebXML 2.1/3.0 and HL7 v2.x. Plenty of people write their own, although OHF use has continued to increase.

> 5. If I want to fully understand the best way to test (Mesa test?) XDS
> and OHF with or without the Bridge, what is the total set of packages
> I should pull from CVS?

Will clarify Sarah's response here. To build OHF from source, you will need all of the org.eclipse.ohf.ihe.* projects from CVS (minus a few that are no longer used). Additionally, you will need the org.eclipse.ohf.hl7v2.core and org.eclipse.ohf.utilities project. Most of the non-org.eclipse.ohf.* projects will also be needed. I have attached an Eclipse team project set here that lists all of the dependencies.

Again I hope this helps.

-Matt

Sarah Knoop wrote:

Hi Robert,
I'll take a stab at some of your questions below and leave the rest for Matt. As noted - we were out of the country and were slow to respond to your posts. Thank you for posting to the newsgroup ... we do our best to keep up with you guys ... now that we are more popular (a good thing) :-). It's also great to see our community stepping up to answer questions too - THANKS JESSE!

I agree with your point about the xdstest2 tool. I was, too, horribly confused about it's use the first time I did MESA tests. I too spent a lot of time trying to get them to work with the client side of XDS - to no avail. There is an intitiative in IHE to come up with a more consolidated set of testing tools. This group met at HIMSS - which I regret not being able to make it too. This group does know about OHF and as the year progresses we hope to interact more with them.

Now for your questions - 1/5. We have 'MESA' JUNIT tests for the bridge and each of the underlying IHE actor plugins. These can be found in <plugin>/src_test/org.eclipse.ohf.ihe.<profile>.<actor>.test.mesa. The underlying plugins use a TestConfiguration.java file as well as some supporting files to run. These are documented in the javadoc. We have MESA tests for the Bridge as well - org.eclipse.ohf.bridge.ws/src_tests/org.eclipse.ohf.bridge.ws.tests.mesa

6. we have a light weight php application that can sit ontop of the bridge - org.eclipse.ohf.bridge.client
Regards,
- Sarah
Robert Alkire wrote:
Thanks for all your feedback, I slowly came around to the conclusion that xdstest2 tool was not really intended to work directly in that fashion. I don't really understand why not though. The bridge API is exactly what that tool should be talking to IMHO. Each of the tests is doing basic XDS operations that are supportable through the bridge, regardless of the destination that implements the WS calls. Perhaps someone can spend the time to interface the two of them together with a layer, alas I don't have that time...

" For example, if you want to query for and retrieve a document using XDS, you can do so with the OHF Bridge API. Likewise if you want to submit a document to an XDS repository, you could use OHF to create the transaction and send it to the repository."

Could you point to a good source (even unit tests) that serve as examples of how to utilize OHF to do exactly these things. I only wanted to use the testing tool to drive OHF attempting to avoid coding. Assuming I had a handler of the WS on the back end I can alter the RHIO configuration to point to my implementations rather than NIST rather easily. That is the whole point of the Bridge. Just starting to attempt to use it some things aren't very clear to me yet. 1. How did OHF Bridge show passing MESA tests? (where is the code that drove those tests)

2. If I use the bridge.war in Tomcat, and I want to utilize that bridge to point to my backend WS, I need to implement all the WSDL that the bridge exposes, correct?

3. Suppose I have the bridge.war in question 2, is there a tag so that I can pull all the source from CVS and build it myself, or must I always pull trunk (buggy at best)?

4. If I decide to write my own code to hanlde consider writing code like the Sample Code in http://wiki.eclipse.org/OHF_Using_XDS.b but not using OHF, is it likely to be a large effort compared to using OHF? (I am not referring to the Bridge here).

5. If I want to fully understand the best way to test (Mesa test?) XDS and OHF with or without the Bridge, what is the total set of packages I should pull from CVS? And what are all the dependencies? I've sent for example http://wiki.eclipse.org/images/2/26/OHF_XDS_Document_Consumer.pdf; I am referring to a more comprehensive OHF with the Bridge and all dependencies to enable me to run the gammit of XDS Mesa tests.

6. Is there any UI tools that will make this work easier, such as one that lists XDS documents retrived from a query that can then be pulled from the repository?
Thanks...
"Matthew Davis" <mattadav@xxxxxxxxxx> wrote in message news:fsbv4d$6d6$1@xxxxxxxxxxxxxxxxxxxx
Hi Robert,
First - I'm very sorry about the delay in getting back to you. Sarah and I were traveling internationally last week and it appears her original email did not get through to you. However, I hope I can be of help now. Also, I'm sorry I did not get to your newsgroup posts until now.
1.
[DEBUG][13:15:40][.builder.RhioConfigManagerImpl] Got rhio config
file from
C:\Apache\Tomcat 6.0\conf\rhioConfig.xml
[DEBUG][13:15:40][.builder.RhioConfigManagerImpl] loading EMF from
C:\Apache\Tomcat 6.0\conf\rhioConfig.xml
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'mllp'
not found. (http://config.common.ihe.ohf.eclipse.org, 64, 15)
You are absolutely correct. We did make a major change in refactoring the RHIO Configuration API and the installation package did not get fully updated - that is, the rhioConfig.xml shipped in org.eclipse.ohf.bridge.install did not get updated to reflect the new updates. I will make that fix and update this afternoon.
2.
On 11710 changed endpoint to
http://localhost:8080/bridge/services/ohf-bridge and now get the
following:
ov.nist.registry.xdstest2.StepContext
  step_id : submit
ov.nist.registry.xdstest2.PlanContext
  RegistryEndpoint : http://localhost:8080/bridge/services/ohf-bridge
  transaction : gov.nist.registry.xdstest2.SimpleTransaction@1b383e9
Fatal Error: Exception thrown:
gov.nist.registry.common2.exception.XdsInternalException
xisFault thrown: No such operation 'hello'
rg.apache.axis2.AxisFault: No such operation 'hello'
ov.nist.registry.common2.exception.XdsInternalException: AxisFault
thrown:
No such operation 'hello'
rg.apache.axis2.AxisFault: No such operation 'hello'
I believe test 11710 is the configuration only test and should be invoked using the xdstest2 tool against the NIST registry - it's simply so Bill's system can identify the vendor that is testing from a set of IP addresses for correlation with MESA. OHF or the Bridge should not be used in this test.
3.
<TestResults
status="Fail"><Xdstest2_version>1.9</Xdstest2_version><Xdstest2_args>--actorconfig
C:\xdstest2tool\actors.xml --testmgmt C:\xdstest2tool\mgmt
</Xdstest2_args><Test>11733/submit</Test><RegistryEndpoint>http://localhost:8080/bridge/services</RegistryEndpoint><TestStep

id="submit"><ExpectedStatus>Success</ExpectedStatus><RegisterTransaction><Xdsa

/><MetadataFile>./single_doc.xml</MetadataFile><RegistryEndpoint>http://localhost:8080/bridge/services</RegistryEndpoint><AssignedPatientId><Assign

It looks like you're trying to run 11733 here - which is a Document Registry MESA test. It uses xdstest2 to test the syntax/construction of the document registry, so the test should target the Web service endpoint of a registry directly and not the OHF Bridge. As Jesse mentioned before, the Bridge isn't a document registry or a server-side IHE actor, it's an implementation of client-side IHE actors.
4.
For test 11746: org.eclipse.ohf.bridge.install_0.3.0.v20080313073042.zip contains the Eclipse Equinox/OSGi server-side Servlet (WAR file) but received this error: Mar 25, 2008 12:43:21 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet equinoxbridgeservlet threw > exception java.lang.RuntimeException: No support for attachments
...
<FatalError>Exception thrown by xdstest2: Exception thrown:
java.lang.Exception
Reply is not SOAP Envelope
Not 100% sure what's going on here, but it appears that you maybe tried to run test 11746 (document source) from xdstest2 against the Bridge? This should be targeted at a document repository's endpoint, not the Bridge.

I hope I caught all the questions from the previous posts here. Again please remember that the Bridge is not a server-side/infrastructure actor, it is simply an aggregation of the OHF IHE client-side actors (PIX Source, PIX Consumer, PDQ Consumer, XDSa/b Source, XDSa/b Consumer, ATNA) into a single interface that is accessible via a Web service. The RHIO Configuration acts as a simplification mechanism on top of that. For example, if you want to query for and retrieve a document using XDS, you can do so with the OHF Bridge API. Likewise if you want to submit a document to an XDS repository, you could use OHF to create the transaction and send it to the repository. OHF also can be used to perform PIX and PDQ queries as well as submitting new patient info using PIX Source.

-Matt

<?xml version="1.0" encoding="UTF-8"?>
<psf version="2.0">
<provider id="org.eclipse.team.cvs.core.cvsnature">
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.apache.axis2,org.apache.axis2"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.apache.batik,org.apache.batik"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.apache.commons,org.apache.commons"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.apache.commons.codec,org.apache.commons.codec"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.apache.commons.lang,org.apache.commons.lang"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.apache.log4j,org.apache.log4j"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.apache.xerces,org.apache.xerces"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.bridge,org.eclipse.ohf.bridge"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.bridge.client,org.eclipse.ohf.bridge.client"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.bridge.ihe,org.eclipse.ohf.bridge.ihe"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.bridge.ihe.pixpdq,org.eclipse.ohf.bridge.ihe.pixpdq"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.bridge.install,org.eclipse.ohf.bridge.install"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.bridge.ws,org.eclipse.ohf.bridge.ws"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.hl7v2.core,org.eclipse.ohf.hl7v2.core"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.hl7v2.ui,org.eclipse.ohf.hl7v2.ui"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.atna.agent,org.eclipse.ohf.ihe.atna.agent"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.atna.audit,org.eclipse.ohf.ihe.atna.audit"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.atna.transport,org.eclipse.ohf.ihe.atna.transport"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.common.atna,org.eclipse.ohf.ihe.common.atna"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.common.cdar2,org.eclipse.ohf.ihe.common.cdar2"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.common.config,org.eclipse.ohf.ihe.common.config"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.common.ebXML._2._1,org.eclipse.ohf.ihe.common.ebXML._2._1"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.common.ebXML._3._0,org.eclipse.ohf.ihe.common.ebXML._3._0"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.common.hl7v2,org.eclipse.ohf.ihe.common.hl7v2"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.common.hl7v2.client,org.eclipse.ohf.ihe.common.hl7v2.client"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.common.mllp,org.eclipse.ohf.ihe.common.mllp"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.common.ws.axis2,org.eclipse.ohf.ihe.common.ws.axis2"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.pdq.consumer,org.eclipse.ohf.ihe.pdq.consumer"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.pix.consumer,org.eclipse.ohf.ihe.pix.consumer"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.pix.source,org.eclipse.ohf.ihe.pix.source"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.xds,org.eclipse.ohf.ihe.xds"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.xds.consumer,org.eclipse.ohf.ihe.xds.consumer"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.xds.metadata,org.eclipse.ohf.ihe.xds.metadata"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.xds.metadata.extract,org.eclipse.ohf.ihe.xds.metadata.extract"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.xds.metadata.extract.cdar2,org.eclipse.ohf.ihe.xds.metadata.extract.cdar2"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.xds.metadata.transform,org.eclipse.ohf.ihe.xds.metadata.transform"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.xds.soap,org.eclipse.ohf.ihe.xds.soap"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.ihe.xds.source,org.eclipse.ohf.ihe.xds.source"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.eclipse.ohf.utilities,org.eclipse.ohf.utilities"/>
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ohf/plugins/org.xmlpull.v1,org.xmlpull.v1"/>
</provider>
</psf>

References:
- [news.eclipse.technology.ohf] OHF Bridge 0.3.0 problems
  - From: Robert Alkire
- [news.eclipse.technology.ohf] Re: OHF Bridge 0.3.0 problems
  - From: Jesse Pangburn
- [news.eclipse.technology.ohf] Re: OHF Bridge 0.3.0 problems
  - From: Robert Alkire
- [news.eclipse.technology.ohf] Re: OHF Bridge 0.3.0 problems
  - From: Robert Alkire
- [news.eclipse.technology.ohf] Re: OHF Bridge 0.3.0 problems
  - From: Matthew Davis
- [news.eclipse.technology.ohf] Re: OHF Bridge 0.3.0 problems
  - From: Robert Alkire
- [news.eclipse.technology.ohf] Re: OHF Bridge 0.3.0 problems
  - From: Sarah Knoop

Prev by Date: [news.eclipse.technology.ohf] Re: XCA on the bridge
Next by Date: [news.eclipse.technology.ohf] Bridge PIX feed conflict with PIX Manager and Registry
Previous by thread: [news.eclipse.technology.ohf] Re: OHF Bridge 0.3.0 problems
Next by thread: [news.eclipse.technology.ohf] Mesa testing and OHF
Index(es):
- Date
- Thread