[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

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