VistA Evolution VistA API Exposure 1.0
The discussion covered the material submitted by VA to the OSEHRA Technical Journal - http://code.osehra.org/journal/browse/publication/94#
In particular, the discussion centered around the architecture diagram (see figure below) - Figure 2 VistA API Exposure High Level Component Architecture on page 15 of the Software Design Document - http://www.osehra.org/sites/default/files/vista_api_exposure_software_design_document_0.4.doc
Highlights of the discussion:
- The VistA API Exposure 1.0 web servics are derived from low level read-only M-APIs from FileMan, Kernel, and MailMan packages. The M-APIs are also RPCs that are accessible via VistALink from the web application server.
- The web services are hosted on a J2SE application server configured with the CAIP (Cross-Application Integration Protocol) framework component. The CAIP component currently runs on the proprietary Oracle Weblogic platform.
- The SOA ESB framework is the Harris IBM Websphere ESB located at the regional data center. The VistA API web services, which are listed in the ESB Service Registry Repository, are invoked by the the ESB framework as part of calls initiated by the web application clients.
- Instead of the typical RPC used by MDWS or CPRS client which contain built-in M based business logic, the use of the low level FileMan and Kernel APIs imply bypassing the built-in M business logic. The assumption is that ESB will need to add business logic to normalize the data for use by client such as the Joint Legacy Viewer (derived from the JANUS UX framework).
- This approach is quite different from the VistA Service Assembler (VSA) architecture proposed by Keith Cox's group. Where does VSA stands in the VA VistA Evolution roadmap?
Please note on your calendar: April 29th - Keith Cox will brief the Architecture Work Group on update to the VistA Service Assembler.