Adeola Odunlami - 2010-02-04

Topic: All Enterprise Service Components (plugins) on one machine

Posted: August 11, 2009 00:26 by Anonymous User

With reference to CONNECT, my understanding is that it is advisable to plan on deploying the Gateway and Adapter components to different machines.

As of now, if one where to embark on deploying the Enterprise Service Components of
HIEOS as the Document Reg/Rep, Mural as the MDM, and OpenSSO as the Policy Engine - all residing on the same machine as the CONNECT Adapter - then one see some potential conflicts.

For instance:

Web Stack of Axis2 used by HIEOS versus Metro 1.4 used by CONNECT.

A conflict in Metro version between 1.1 used by Mural and 1.4 used by CONNECT
(Ref: http://www.connectopensource.org/pages/viewpage.action?pageId=18513926&focusedCommentId=185141411.4)

…

My question of relevance here: should I (can I) plan on a single machine for all the Adapter Enterprise Service Components (including HIEOS) to use Metro 1.4?

Thank you for your time.

Jim

Posted: August 11, 2009 15:56 by Anonymous User

Jim,

A few thoughts below:

1) We have not seen an issue between running Metro and Axis2 in the same virtual machine in GlassFish. The only issue we have seen is that HIEOS supports SOAP 1.2 which is an IHE requirement whereas NHIN Connect still has some SOAP 1.1. Also, we have seen an issue regarding MTOM support from the NHIN Connect side. We are working closely with the NHIN CONNECT team to resolve. However, we have HIEOS working with NHIN Connect in our test environment.
2) We are now looking into what it would take to remove Axis2 from HIEOS and replace with Metro. We hope to have that support in place soon.
3) From a development perspective, you should be able to run all of the mentioned components within the same Glassfish domain or separate domains on the same machine.
4) From a production perspective, depending on your scalability requirements, it is likely a better approach to run the Enterprise Service Components on separate hosts. In fact, with XDS.b, the XDS.b Repository web service may be deployed on multiple hosts closer to your EHR systems. The Record Locator Service (XDS.b Registry) web service could be housed on a separate host - either co-located with the NHIN Adaptor or on a separate box.

Hope this helps - Bernie

Posted: August 13, 2009 00:11 by Anonymous User

Bernie:

This does help to put a frame around the picture.

While production deployment will most likely use multiple hosts along the lines of your point 4) for both scalability and maintainability issues, for right now we are in development mode, so it makes more sense to be able to run all under one development environment, hence the question.

Do you have any sort of project plan for the future of HIEOS? I know that this puppy just got off the ground, but I would be interested in knowing what your plans for the future are.

Jim

Posted: August 16, 2009 06:47 by Anonymous User

Currently, we are working on additional performance enhancements and evaluating the possibility of migrating to the Metro WS stack. We are also evaluating recent IHE specification changes. Do you have specific items that you would like to see addressed by HIEOS?

Posted: August 17, 2009 11:40 by Anonymous User

Hi Bernie,

RE: Do you have specific items that you would like to see addressed by HIEOS?

Yes, but you have answered some of those items, already.

As you know, IHE has always been on a fast track, mostly driven by the results of their Connectathons, so my question here was if HIEOS was going to be an on-going process that kept pace with IHE?

You have answered with: "We are also evaluating recent IHE specification changes."

The question that prompted my original post was if HIEOS could/would eventually use the same Web Services stack as that used by CONNECT?

You have answered with: "Currently, we are working on additional performance enhancements and evaluating the possibility of migrating to the Metro WS stack."

Until such time that HIEOS uses the same Web Services stack as that used by CONNECT, we are considering using different administrative domains in our GlassFish development environment for each of CONNECT's Enterprise Service Components.

Something along the lines of:

C:\GlassFishESBv21\glassfish\domains\domain1\
C:\GlassFishESBv21\glassfish\domains\HIEOS\
C:\GlassFishESBv21\glassfish\domains\Mural\
C:\GlassFishESBv21\glassfish\domains\OpenSSO\

Would this be at all advisable?

Are there any pro/con issues that we should be aware of, if we were to take this approach?

Finally, there is the issue of the repository implementation.

A relational database solution for the repository side of the regrep equation is, in my opinion, a-square-peg-in-a-round-hole solution.

A native XML database to support the reams of privacy, policy, and security documents, all of which is XML, seems the better tool for the job.

This seems especially important when one begins to also factor in SOA governance, policy and lifecycle management, to say nothing of medical-specific ontologies.

Using XQuery to pull such information out would be a no-brainer, whereas doing the same with a relational database seems like something would hurt…a lot.

So, the question here would be if using a native XML database for the repository would be on the radar for HIEOS?

Footnote:
I have noted that in OMAR freebXML for ebXML 3.x, all Repository Managers (e.g., FileSystemRepositoryManager, HibernateRepositoryManager) extend the AbstractRepositoryManager, which in turn implements the RepositoryManager interface. This suggests that coding for a native XML database would be no more complicated than creating a new class that extended AbstractRepositoryManager. What would be your thoughts on this?

Thanks for your time, Bernie. Any insight you can provide is sincerely appreciated.

Jim

Posted: August 17, 2009 14:52 by Bernie Thuman

Jim - embedded answers below (marked )….

Hi Bernie,

RE: Do you have specific items that you would like to see addressed by HIEOS?

Yes, but you have answered some of those items, already.

As you know, IHE has always been on a fast track, mostly driven by the results of their Connectathons, so my question here was if HIEOS was going to be an on-going process that kept pace with IHE?

You have answered with: "We are also evaluating recent IHE specification changes."

: We will keep pace with the IHE process. The HIEOS code base (now enhanced) successfully passed the last North America IHE Connectathon in Feb 2009.

The question that prompted my original post was if HIEOS could/would eventually use the same Web Services stack as that used by CONNECT?

You have answered with: "Currently, we are working on additional performance enhancements and evaluating the possibility of migrating to the Metro WS stack."

: No response change here.

Until such time that HIEOS uses the same Web Services stack as that used by CONNECT, we are considering using different administrative domains in our GlassFish development environment for each of CONNECT's Enterprise Service Components.

Something along the lines of:

C:\GlassFishESBv21\glassfish\domains\domain1\
C:\GlassFishESBv21\glassfish\domains\HIEOS\
C:\GlassFishESBv21\glassfish\domains\Mural\
C:\GlassFishESBv21\glassfish\domains\OpenSSO\

Would this be at all advisable?

: This should technically work.

Are there any pro/con issues that we should be aware of, if we were to take this approach?

: Memory consumption and different port requirements.

Finally, there is the issue of the repository implementation.

A relational database solution for the repository side of the regrep equation is, in my opinion, a-square-peg-in-a-round-hole solution.

A native XML database to support the reams of privacy, policy, and security documents, all of which is XML, seems the better tool for the job.

This seems especially important when one begins to also factor in SOA governance, policy and lifecycle management, to say nothing of medical-specific ontologies.

Using XQuery to pull such information out would be a no-brainer, whereas doing the same with a relational database seems like something would hurt…a lot.

So, the question here would be if using a native XML database for the repository would be on the radar for HIEOS?

: Currently, we do not plan to change the HIEOS base repository implementation. However, HIEOS already supports a means to vary the XDS.b Repository underlying storage implementation. You simply need to extend the com.vangent.hieos.services.xds.repository.storage.XDSRepositoryStorage class . Implementations of this class are loaded at run-time and can be configured in the HIEOS xconfig.xml configuration file by changing the RepoStorageClassImpl property to point to your implementation. Today, HIEOS is configured to use the XDSRepositoryStorageSQL implementation that you mention. Also, I should point out that an XDS repository can store any kind of data (e.g. PDF, DICOM image, TXT) - not just XML.

Footnote:
I have noted that in OMAR freebXML for ebXML 3.x, all Repository Managers (e.g., FileSystemRepositoryManager, HibernateRepositoryManager) extend the AbstractRepositoryManager, which in turn implements the RepositoryManager interface. This suggests that coding for a native XML database would be no more complicated than creating a new class that extended AbstractRepositoryManager. What would be your thoughts on this?

: HIEOS XDS.b Registry is a layer above OMAR (optimized for XDS.b I should add - a bit more to do here). An XDS.b Registry has no knowledge (or dependency) on a repository - it only stores repository ids (as per IHE). HIEOS XDS.b Repository is a completely different entity and communicates to an XDS.b Registry during "Provide & Register" web service transactions. In this case, the Repository has no knowledge of the Registry implementation. We will keep these concepts separated in HIEOS - i.e., we will not leverage OMAR for Repository storage.

Posted: August 17, 2009 18:08 by Anonymous User

Thanks, Bernie!

This is most helpful, indeed.

Jim