Difference between revisions of "How does VistA work"

From VistApedia
Jump to: navigation, search
Line 1: Line 1:
 +
* [[CPRS]] is a client program that runs on a user's own computer.
 +
* CPRS uses a software module called the RPC Client to connect to the main VistA server.
 +
* The VistA server can be running on a standalone computer anywhere on the network, or within a virtual machine on the user's own computer (or even on another computer in the network). The RPC client will use standard networking protocols to connect to the server (wherever it is located).
 +
* A software module that is part of the VistA server (called the RPC Broker) "listens" on the network for connection attempts from RPC Clients scattered around the network. It often "listens" on port 9260.
 +
* The RPC Broker acts as an interface (or "proxy") between the main MUMPS database of the VistA server and the RPC Client (portion of CPRS) to handle queries and respond to those requests for information from the database that are generated by CPRS. Each instance of an RPC client-RPC Broker connection is maintained as an independent session. If multiple users are accessing the database at once, there will be multiple sessions established.
  
−
* [[CPRS]] runs on a person's own computer.
+
* Example:
−
* CPRS uses a part of a person's own computer called the [[RPC Client]].
+
:* CPRS might generate a request: "I am this person, authorize me."
−
* The RPC Client uses the computer's network software and hardware to establish a link to some bigger computer running the VistA server.  The part of the VistA server that the RPC Client connects to is called the RPC Broker.
+
:* The RPC proxy (RPC Broker) then uses the access code and verify code which was sent with the request (by the RPC client), and tries to authorize that person's CPRS session with the MUMPS database.   
−
* The RPC Broker sets up a part of the VistA server to handle any questions and answers that are needed by the person's CPRS session. This could be called the user's RPC proxy.
+
::* If it succeeds, a "success" message is returned by the RPC Broker to the RPC Client, then other requests will be allowed to be forwarded through the session's proxy connection. (This is known as a "handshake" in networking terms.) Further requests for information from the database are then allowed from the CPRS RPC client (such as patient information, lab information, etc.). They are passed over the network to the RPC Broker, which interfaces with the MUMPS modules on the VistA server to look for the data and then send it back through the established connection.
−
* CPRS uses the RPC client on the person's PC to send requests to the RPC proxy on the VistA server. The proxy forwards questions to VistA and VistA replies with answers. 
+
::* If the handshake does not succeed, then the proxy waits for a proper authorized user.
−
:* An example request might be "I am this person, authorize me."
+
:*
−
:* The RPC proxy then uses the access code and verify code which was sent with the request, and tries to authorize that person's CPRS.   
+
* Eventually, the person using CPRS finishes with their work. If the RPC proxy on the VistA server doesn't get any requests for a while, it "times out" and drops the connection. (In computer jargon, the amount of time it waits is known as the "time to live", or TTL).
−
:* If it succeeds, then other requests can be answered through the proxy.
+
 
−
:* If it does not succeed, then the proxy waits for a proper authorized user.
+
== Developments in VistA interfaces ==
−
* Eventually, the person using CPRS finishes with their work, and the RPC proxy on the VistA server doesn't get any requests for a while. The VistA server then removes the proxy and the connection is broken.
+
 
 +
=== Web browser based clients ===
 +
There are alternatives to using the RPC Client (or CPRS) <--> RPC Broker conduit as a method to "mine" data from the MUMPS database.
 +
 
 +
This is a time honored method that has been very reliable and stable for the VA for many years. However, the Internet and World Wide Web developed some time after VistA (and its predecessor, DHCP) were already in use.
 +
 
 +
Newer communications interfaces have been developed that allow "packet"-based queries for information from databases. They do not require that a communications session remain open for a specified "time to live" (TTL). The request for information from the database is made and the information found (from the database), returned to the requesting client, and the connection closed. it does not remain open for a predetermined "time to live."
 +
 
 +
This allows more users simultaneous access to the database without stressing network bandwidth as much, and this type of communications is what makes the World Wide Web able to handle so much traffic.
 +
 
 +
Web browsers (Firefox, Internet Explorer, Safari) are the ubiquitous clients that generate these packet-based requests.
 +
 
 +
Using [[EWD]], new interfaces for VistA that will respond to this type of request are being developed. Requests for database information from a web browsers will be sent to EWD, which will itself establish a connection to the RPC Broker. The RPC Broker will again query the MUMPS database, retrieve the requested information, send it to EWD which will then return the packet-based information to the web browser acting as a client.
 +
 
 +
This method of communication is actively in development at team VistA. Look for updates and improvements in the VistA Community Meetings and in the Google HardHats group.

Revision as of 19:10, 31 January 2010

  • CPRS is a client program that runs on a user's own computer.
  • CPRS uses a software module called the RPC Client to connect to the main VistA server.
  • The VistA server can be running on a standalone computer anywhere on the network, or within a virtual machine on the user's own computer (or even on another computer in the network). The RPC client will use standard networking protocols to connect to the server (wherever it is located).
  • A software module that is part of the VistA server (called the RPC Broker) "listens" on the network for connection attempts from RPC Clients scattered around the network. It often "listens" on port 9260.
  • The RPC Broker acts as an interface (or "proxy") between the main MUMPS database of the VistA server and the RPC Client (portion of CPRS) to handle queries and respond to those requests for information from the database that are generated by CPRS. Each instance of an RPC client-RPC Broker connection is maintained as an independent session. If multiple users are accessing the database at once, there will be multiple sessions established.
  • Example:
  • CPRS might generate a request: "I am this person, authorize me."
  • The RPC proxy (RPC Broker) then uses the access code and verify code which was sent with the request (by the RPC client), and tries to authorize that person's CPRS session with the MUMPS database.
  • If it succeeds, a "success" message is returned by the RPC Broker to the RPC Client, then other requests will be allowed to be forwarded through the session's proxy connection. (This is known as a "handshake" in networking terms.) Further requests for information from the database are then allowed from the CPRS RPC client (such as patient information, lab information, etc.). They are passed over the network to the RPC Broker, which interfaces with the MUMPS modules on the VistA server to look for the data and then send it back through the established connection.
  • If the handshake does not succeed, then the proxy waits for a proper authorized user.
  • Eventually, the person using CPRS finishes with their work. If the RPC proxy on the VistA server doesn't get any requests for a while, it "times out" and drops the connection. (In computer jargon, the amount of time it waits is known as the "time to live", or TTL).

Developments in VistA interfaces

Web browser based clients

There are alternatives to using the RPC Client (or CPRS) <--> RPC Broker conduit as a method to "mine" data from the MUMPS database.

This is a time honored method that has been very reliable and stable for the VA for many years. However, the Internet and World Wide Web developed some time after VistA (and its predecessor, DHCP) were already in use.

Newer communications interfaces have been developed that allow "packet"-based queries for information from databases. They do not require that a communications session remain open for a specified "time to live" (TTL). The request for information from the database is made and the information found (from the database), returned to the requesting client, and the connection closed. it does not remain open for a predetermined "time to live."

This allows more users simultaneous access to the database without stressing network bandwidth as much, and this type of communications is what makes the World Wide Web able to handle so much traffic.

Web browsers (Firefox, Internet Explorer, Safari) are the ubiquitous clients that generate these packet-based requests.

Using EWD, new interfaces for VistA that will respond to this type of request are being developed. Requests for database information from a web browsers will be sent to EWD, which will itself establish a connection to the RPC Broker. The RPC Broker will again query the MUMPS database, retrieve the requested information, send it to EWD which will then return the packet-based information to the web browser acting as a client.

This method of communication is actively in development at team VistA. Look for updates and improvements in the VistA Community Meetings and in the Google HardHats group.

Retrieved from "https://vistapedia.com/index.php?title=How_does_VistA_work&oldid=6420"