Thoughts/Questions about interfacing other computers with VistA

[Kevin Toppenberg]

Hey All,

I am having problems working on a VA project that will interface VistA to a Java process. 

The VistA will be standard VA setup, meaning Cache' on Windows, and the Java process will be on a separate box.  I'm not sure whether the host OS for the Java box will be Linux or Windows.  The Java process will take data from Mumps (in an XML flat file), run analysis on it, and then return results in XML format.

To have the two process talk to each other, I have been planning on using a common host file system and then passing messages in the form of files stored in predefined locations.  However, as per this thread:  https://groups.google.com/forum/?fromgroups#!topic/Hardhats/z2gUU3ikZiE I am having permission issues whereby the server mumps code can't access the shared network drive.  And even if I can fiddle with permissions on my development environment, I worry how this issue will play out when implemented in a VA setting.  I.e. will I be able to get the permissions altered by IT/IRM departments?

So this has got me wondering if my approach of using the file system as a messaging channel is a "proper" way for computers to communicate.  And if not, what would be a better way?  These are the ways I can think for the computers to talk to each other:

1. A TCP/IP connection
2. HL-7 messaging
3. E-mail messaging
4. Some sort of formal Windows RPC technology.
5. Common file system, with permission issues worked out.
6. Some sort of Web technology interface
7. Something else I haven't thought of...

Here are my thoughts on these approaches:

1. A TCP/IP connection

This seems the most direct approach.  I know that GT.M has Linux pipe technology that could establish the connection on the mumps side.  I assume that Cache' would have something equivalent?  On the Java side, I would have to create a TCP/IP listener.  I have never done this, but assume there would be some sample code on the internet.  Would I have to worry about security / authentication of incoming signals?  Or would it be like the RPC listener from mumps -- i.e. the network administrators job to ensure that the port is not exposed to the internet etc?

2. HL-7 messaging

If I did this, then the mumps side would already be set up.  But on the Java side, I would have to somehow implement an HL-7 listener, and that seems to me to be a difficult solution for a relatively simple goal.

3. E-mail messaging

Again, mailman should be able to send out messages.  But I don't know how this would be handled on the Java end.  And e-mail is typically assumed to be a low-priority technology.  I.e. who cares how fast email messages are delivered.  So I don't see this as a great option.

4. Some sort of formal Windows RPC technology.

Here is a link that discusses this http://msdn.microsoft.com/en-us/library/windows/desktop/aa373935%28v=vs.85%29.aspx.  I think this would be for programs running in the windows environment, i.e. an API call.  Even if my mumps code is running in Cache' on Windows, I don't think I would have access to such an API.  So I don't see that this would help.

5. Common file system, with permission issues worked out.

I think the issue is that the VistA server process on Cache', when it runs has to be logged in with credentials.  And based on those credentials, it may or not have permissions to access a network resource.  I assume that IT would be able to adjust such permissions, but I don't know how VA policy will apply to this.  Would they be willing to do this?  And for that matter, will I have to get IT permission for communication between two computers regardless of how the channel is set up?

6. Something else I haven't thought of...

Anyway, I am curious to input as to whether one of these methods is a better way than another?  I am a bit discouraged to hit this unexpected snag, and am looking for a straight-forward solution.  All I have to do is pass some text files back and forth and I hate to have to implement entire communication technologies just to do this simple task.

Thanks

Kevin

[Bhaskar, K.S]

Kevin --

A TCP connection seems the best fit for your application.  It's universal.  It guarantees delivery with serialization.  Most systems support it (incidentally, you would use a GT.M SOCKET device, not a PIPE device).  It's the network administrator's job to administer it, and you can encrypt it completely outside the application using standard tools like stunnel, ssh tunneling, VPN, or router (within the LAN of a VA hospital, there may not be a concern about encryption, though).  You could of course layer a protocol on top of TCP like http, but that would be (in my opinion) overkill/overhead.

Which side initiates the connection?  The VistA side or the Java side?

Regards
-- Bhaskar

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[Chris]

Interesting problem. What VA project?

Build a Cache/Java projection? Bind your M code to Java; pass whatever you want between M and Java; example  http://typewith.me/p/projection

[Kevin Toppenberg]

Bhaskar,

Thanks for the reply.  I started to stand on my head trying to figure out how to make a DEVICE file entry that would properly interact with the underlying mumps functionality (GT.M or Cache') to send out TCP/IP.   But then, happy suprise, I found these links:

CALL^%ZISTCP --> hardhats.org/kernel/html/call^zistcp.shtml
CLOSE^%ZISTCP --> http://hardhats.org/kernel/html/close%5Ezistcp.shtml

So it looks like mumps TCP out in the VA is all ready to go.

Now I just need to get a Java TCP listener going.

(more below)

On Friday, June 1, 2012 9:48:41 AM UTC-4, K.S. Bhaskar wrote:

Kevin --

A TCP connection seems the best fit for your application.  It's universal.  It guarantees delivery with serialization.  Most systems support it (incidentally, you would use a GT.M SOCKET device, not a PIPE device).  It's the network administrator's job to administer it, and you can encrypt it completely outside the application using standard tools like stunnel, ssh tunneling, VPN, or router (within the LAN of a VA hospital, there may not be a concern about encryption, though).  You could of course layer a protocol on top of TCP like http, but that would be (in my opinion) overkill/overhead.

This seems good advice.

 

Which side initiates the connection?  The VistA side or the Java side?

mumps VistA side will initiate the connection.
 

Regards
-- Bhaskar

Thanks,
Kevin
 

On 06/01/2012 08:32 AM, Kevin Toppenberg wrote:

Hey All,

I am having problems working on a VA project that will interface VistA to a Java process. 

...

 

[Kevin Toppenberg]

Chris,
...

>Build a Cache/Java projection? Bind your M code to Java; pass whatever you want between M and Java; example  http://typewith.me/p/projection

I couldn't get this URL to respond.  It goes to "Etherpad Lite" site, but then hangs with a "loading" message.  I did, however, find this document:
http://www.odbms.org/download%5CUsing%20Java%20With%20Cach%C3%A9.pdf
that shows how to tightly integrate Cache' and Java.

I have a couple of questions:
1. This seems to make use of the extended features of Cache'.  And as much as I admire and envy them, I thought that the VA didn't want to get into Vendor Lock, and thus developers are only supposed to use standard mumps functionality.  I.e. no "Z" commands etc. 

This examples in the links that I supplied seem to be about a JAVA process calling INTO cache'.  I actually need to do the opposite: call out to JAVA from mumps.

As per my other post, I just found that Kernel has TCP/IP routines for IO already written, so I just now need to get the java to be a TCP/IP listener.

Thanks,
Kevin

...

[Chris]

http://pastebin.com/kMv3JY3d - re-paste

When I read "The Java process will take data from Mumps (in an XML flat file), run analysis on it, and then return results in XML format." - I took it literally.

If it were me; I'd use some sort of very simple M event handler to signal Java to read X and write Y. I don't envision writing a M socket client and Java socket server as trivial and will introduce complexity; VA workstations have a wonderful thing called a firewall that should be taken into consideration. 

Cache can call Java; that does introduce complexity that not many know about. Again; simple M event handler would suffice followed by "the Java process will take data from Mumps."

So to answer your question about VA and vendor lock... yes that is true; no vendor lock is the stance I hear as well. However actions speak louder than words and what can I say? VA does depend on Cache Objects for a couple of nationally used applications.

Do what is best and easiest for you to get the job done; I'm just shining light down other paths. Ciao.

[Kevin Toppenberg]

Chris,

I appreciate the light you have shed. 
Thanks!

Kevin