1. ESS Architecture Workgroup August 2013
 VistA SOA Services VistA Service Assembler (VSA) Conceptual and Technical Overview
ESS Architecture Workgroup
August 2013

2. VA Healthcare SOA
“One of the major focuses of VA system integration is the healthcare domain.”
“The majority of VA healthcare computing involves VistA and applications integrated with VistA.” 
The VA healthcare SOA challenge—
Efficiently expose existing VistA methods and data
Decouple consuming systems from the implementation details of VistA
Solve the “organizational gap” of coding multiple technologies
VistA SOA Services

3. Common Legacy SOA Interpretations
VistA
Encapsulation / Encasement
HealtheVet VistA
Notes Service
Rx Service
Ordering Service
CP&E Service
Consumers
Perpetuates shortcomings and dependencies on legacy systems
Inhibits individual application replacement
Granular logic, “chatty” communications through middleware layer
Atomization / Re-Hosting
Major retooling and investment
Subjective interpretation
Inability to anticipate future consumers
Tendency to build too much, to build too little
MDWS/VIA
Consumers
VistA
Notes Rx
Ordering
CP&E
VistA SOA Services

4. Providing a Better Way: VistA as an SOA service provider
Leverage proven assets
Existing application methods, data, application integration methods and governance
‘Provider application’ SME and technical knowledge and documentation
Improve management of the IT solution (development and sustainment)
VistA applications and services become
Economically extensible, maintainable and individually replaceable
VSA generated VistA SOA services are fully compliant with SOA architecture and compatible with VA SOA infrastructure
VistA SOA Services

5. VistA SOA Service Formats
Legacy VistA SOA compatible service designs
HL7 messaging
Mature VA implementation
Data model driven
Web Services
Offer various efficiencies
Suitable for certain integrations
“Composable” as coarse grained functionality
VSA is focused on the creation of VistA based web services to support the implementation of SOA
VistA SOA Services

6. The VistA Service Assembler (VSA) Solution
Provides both a technical and organizational solution
Technical solution
Legacy VistA integration compatibility
Technical abstraction across disparate technical environments
SOA implementation integration and compliance
Leveraging of existing VistA “service assets”
Organizational solution
A solution that crosses technical boundaries
Accommodates staff skill set / technical orientation limitations
Provides standardized SOA implementation direction
Reduces investment, improves ‘time to market’
Minimizes organizational impact related to SOA implementation
VistA SOA Services

7. Paradigm Shift: VistA as an SOA Service Provider
Encased
VistA is encased as a system to isolate and then replace in the future
Leveraged
VistA packages are leveraged and extended as building blocks for legitimate SOA services
Adapter Integration
‘Consumer applications’ are integrated with adapters that encase VistA
Service Integration
‘Consumer applications’ are integrated with SOA services exposed by ‘provider applications’
Rip and Replace
Legacy VistA is encased with adaptors as a monolithic system, then replaced
Plug and Play
VistA applications expose SOA services, allowing application-by-application replacement
Fine Grained
Chattiness due to business logic in adaptors, fine grained VistA methods
Coarse Grained
All business logic positioned in VistA applications to produce coarse grained service logic modules
Built from ‘scratch’
SOA services, environment and governance built “from the ground up”
Built from existing components
Existing VistA methods and data used to build SOA services, reducing development, testing, etc.
VistA SOA Services

8. Major Elements of the Solution
VistA SOA service infrastructure
VistA Service Assembler Wizard
Service descriptors database
M environment components for ‘service’ execution
Federating platform and federating logic
VistA SOA ‘reference implementation’ services
Per ‘service needs’ of VA stakeholder initiatives
Definition of Policy and Process
VSA infrastructure distribution
VistA SOA service distribution
Responding to the need
Efficiency
Accomplishing compliance
Full SOA compliance and integration without requiring re-work to existing VistA SOA services
Building the service initially is not rework in the end. It can be published on the ESB when the ESB is available.
VistA SOA Services

9. Solution Attributes Cost Effective Addresses SOA objectives
Able to rapidly expose broad VistA functionality as ‘services’
Rapid development and incremental approach
Minimal retooling of VistA applications or retraining developers
Low impact organizationally
Addresses SOA objectives
Security and system performance
Semantic and syntactic compatibility
Reusability and non-redundancy
System maintainability, sustainability and replaceability
Provides value before full SOA infrastructure is in place
Complete integration and compliance with SOA architecture
Enables major consumers (e.g. mobile computing)
Alleviates ‘vendor dependence’ concerns while exponentially expanding VistA extensibility and ‘open source’ product development opportunities
VistA SOA Services

10. VistA Service Assembler (VSA) High Level1
A M Developer or System Integrator identifies existing or new M routine(s) to be called by a new or existing VistA SOA Service.
VistA SOA Federating Services Platform - Regional
(Java)
M Hosting Platforms
(Intersystems Caché or open source platform (ie. GT.M), 130+ instances in production in VA)
MUMPS Hosting Platform
(Intersystems Caché or Open Source Platform (ie. Graystone)) 2
The M Developer or System Integrator executes the Assembler Wizard providing required information such as operation names, mumps routines to be called, and parameter mappings. 2
VistA Service Assembler Wizard
M Code and Data
All Other Packages
Routines 3
A VistA SOA Service descriptor is generated and stored in the VistA SOA Federating Service Platform. 4
A new VistA SOA Service is auto-generated and published. 3
Consuming Applications can interface with the new VistA SOA Service directly (NEAR TERM ONLY).
VistA Service Assembler SOA Service Descriptors (generated by the Assembler Wizard) 1 5
VSA Package
Enterprise Service Bus (ESB) 6
Site Specific VistA M Routine Calling Adapter (VMRCA) 4
VistA SOA Services
(generated by the Assembler Wizard)
Registry and Repository
(Websphere Registry and Repository)
Core ESB
(Websphere Message Broker)
VistA SOA Services
(generated by the Assembler Wizard)
VistA is extended to include the VistA SOA Federating Service Platform in addition to all of the M Hosting Platforms.
VistA SOA Federating Platform can serve a single site (open source community focus)
The VistA Service Assembler Wizard is deployed to the VistA SOA Federating Service platform. This platform is envisioned to be the Java based Spring Framework deployed on WebLogic in the VA or on any other Java container such as Tomcat or JBoss in open source based organizations.
The term “M Hosting Platform” has been used to indicate a platform into which the M computing system is deployed. In the VA, this is currently Intersystems Caché. In other open source based computing systems this may be GT.M, commonly referred to as “Greystone.”
The Site Specific VistA M Routine Calling Service (VMRCS) is implemented once and deployed to each M Hosting Platform. VMRCS is implemented in Caché Server Pages (CSP) and Caché Objects technology in Intersystems Caché, and is implemented by GT.M specific technologies in GT.M (how GT.M works needs to be researched). This is the only component of the framework that is vendor technology specific. The VMRCS is a private service and can only be used by the auto-generated VistA SOA services. This is enforced with two way SSL. VMRCS provides web service integration with SOAP/REST protocols over two way SSL and delegates the rest of the work to the Site Specific VistA M Routine Calling Adapter (VMRCA).
VMRCS is a private service. SSL certificates are only authorized for the VistA SOA Services. No other consuming system is allowed access to the VMRCS.
The VMRCA authenticates to Kernel, sets up and executes M routines, transforms the request from VMRCS to M routine compatible syntax, and transforms the M routine response payload to VMRCS compatible syntax.
The provider application is responsible for the M routines and the VistA SOA Services that use them.
“Service Assembly in a Day” is enabled by the VistA Service Assembler Wizard.
The M developer or System Integrator runs the Assembler Wizard in a design and development environment which can be implemented via a replicatable virtual machine.
The VistA SOA Services generated at design time are deployed to the VistA SOA Federating Service Platform deployed to each region. Each VistA SOA Service is packaged as a separate WAR VSA common libraries configured by the Assembly Wizard. These deployment artifacts are version controlled by the provider application, and deployed through the provider application’s deployment processes.
A new version of a VistA SOA Service results in a newly versioned WAR. The new version can be deployed side-by-side with a previous version of the service as governed by the provider application.
The VistA SOA Service Proxies are created on the ESB. As the VSA system matures, configuration of these proxies may become automatable.
The VistA SOA Service Registry Entries are created on the ESB. As the VSA system matures, configuration of these proxies may become automatable. 6a 6a
Site Specific VistA M Routine Calling Service (VMRCS)
VistA SOA Service Registry Entries
VistA SOA Service Proxies
Private Interface
To-be Integration 6b 5 6
TO BE – The ESB is deployed to production
Registry entries and service proxies created for the VistA SOA Services.
Consumers
Consuming Applications
Near Term Integration 6a 6b
The Consuming Applications integrate with the VistA SOA Service proxies published on the ESB and the direct connection to the VistA SOA Services published on VistA are retired.

11. VistA Service Assembler (VSA) High Level Component Descriptions
VSA Component
Description
VistA Service Assembler Wizard
Java web application - auto generates VistA SOA Services
VistA SOA Federating Services Platform
Java application server such as Tomcat or WebLogic, to which VistA SOA Services are deployed
M Hosting Platform
A runtime system supporting ANSI standard M such as Intersytems Caché or GT.M
VistA SOA Service
An SOA compliant service generated by the VistA Service Assembler Wizard with federating capabilities. Implemented in the Java Spring Framework.
VistA Service Assembler SOA Service Descriptors
Meta data XML document created by the VistA Service Assembler Wizard used to auto generate VistA SOA Services
Site Specific VistA M Routine Calling Service (VMRCS)
A REST/SOAP web service deployed to each site that delegates requests to run M routines to VMRCA. Implemented in vendor specific technologies..
Site Specific VistA M Routine Calling Adapter (VMRCA)
VSA M routines that handle M routine calling
VistA SOA Service Registry Entry
Entry in the Registry and Repository used to govern a specific VistA SOA Service
VistA SOA Service Proxy
Proxy on the ESB used to abstract the service endpoint.
VistA Service Assembler

12. VistA Service Assembler Wizard
Web application accessible via browser
Define Service name
Define Operations
Federation
Site lookup is selectable
Used in design and development sandbox
VistA SOA Service operation payload transformations include XML, JSON transforms
This list is a starting point
Other things to set in the wizard may include a selection of an aggregation strategy, caching strategy, runtime data cleansing strategy, deduplication/deconfliction strategy, partial data handling strategy, terminology mapping integration strategy (runtime terminology resolution and may include something with design time), multi-threading strategy, regional federating service location strategy, exception handling strategy and security integration strategy.
The VistA Service Assembler Wizard is implemented as a web application on open source Java based web technologies. It is deployed to the design time environment/sandboxes.
Define Operations
Name
Parameters and transformations
Response and transformation
MUMPS routine to call
Federation
Configurable for a single site
Federates all available sites
Federates a subset of sites (VISN specific)
Site lookup is selectable
MVI
Other open source defined site lookup
Fixed site identifier list
VistA SOA Service operation parameter or response transformation types include
XML to/from ‘^’ delimited string or array
JSON to/from ‘^’ delimited string or array
Custom binary to/from ‘^’ delimited string or array
Atomic type conversions include
GMT to/from Fileman date time
XSD atomic types to/from Fileman types such as string, integer, etc.
VistA Service Assembler

13. VistA SOA Services Runtime View
Enterprise Service Bus (ESB)
VistA
Site 1
M Code and Data
M Routines for Progress Notes
VMRCS
VMRCA
M Routines for Outpatient Meds
M Routines for Allergies
Registry and Repository
(Websphere Registry and Repository)
VistA SOA Federating Services Platform - Regional
(Java)
Progress Notes Service
Registry Entry
Outpatient Meds Service
Registry Entry
Progress Notes Service
Allergies Service
Registry Entry
Consumers
Consuming Applications
Outpatient Meds Service
Site N
M Code and Data
M Routines for Progress Notes
VMRCS
VMRCA
M Routines for Outpatient Meds
M Routines for Allergies
Core ESB
(Websphere Message Broker)
Each service is deployed separately to the VistA SOA Federating Services Platform hosted in each regional data center. As a Java application server platform it is scalable using standard application server clustering strategies. Use of commodity servers may be used to reduce cost.
Providers of a new VistA SOA Service do not have to install new servers, but add their service to the VistA SOA Federating Service Platform. This platform is managed at the Regional level.
VMRCS is deployed to each site instance in a Cache database separate from the standard VistA Cache database
Allergies Service
Progress Notes Service Proxy
Outpatient Meds Service Proxy
Allergies Service
Proxy
VistA Service Assembler

14. VSA National Production Deployment Configuration
Region 1 RDC
VistA
WSRR
VistA SOA Service
Registry Entries
WMB
Proxies 2
VistA SOA Federating Services Platform
VistA SOA Services
Site 1 to M
M Code and Data
M Routines
VMRCS
VMRCA
Region 2 RDC
VistA
WSRR
VistA SOA Service
Registry Entries
WMB
Proxies 2
VistA SOA Federating Services Platform
VistA SOA Services
Site M+1 to N
M Code and Data
M Routines
VMRCS
VMRCA
Region 3 RDC
VistA
WSRR
VistA SOA Service
Registry Entries
WMB
Proxies 2
VistA SOA Federating Services Platform
VistA SOA Services
Site N+1 to O
M Code and Data
M Routines
VMRCS
VMRCA
Region 4 RDC
VistA
WSRR
VistA SOA Service
Registry Entries
WMB
Proxies 2
VistA SOA Federating Services Platform
VistA SOA Services
Site O+1 to P
M Code and Data
M Routines
VMRCS
VMRCA 1 1 1
iEHR is deploying WMB and WSRR to each region. Consuming systems connect there. WMB and the VistA SOA Federating Services Platform connect via high speed network internal to the regional data center for best performance.
Site instances are targeted to be fully migrated to their associated regional data center. Where site instances are still deployed to VAMC computer rooms or other data centers like the HAC for CP&E connectivity between VistA SOA Services deployed on the VistA SOA Federating Services Platform and the site instance is over the WAN.
For each call to a regionally deployed VistA SOA Service operation, that operation will function in a runtime hub and spoke call hierarchy to the other regions (see the process flow diagram in a later slide).
Need to verify that a Regional federated approach is better than calling individual VistA instances. Connections to every VistA from a given Region may be optimal.
One level of multi-threading for concurrent regional calls, and a second layer of multi-threading for concurrent calls to sites associated with the region.
WSRR = WebSphere Registry and Repository
WMB = WebSphere Message Broker
ESB = Enterprise Service Bus
SOA = Service Oriented Architecture
VMRCA = Site Specific Generic Mumps Routine Calling Adapter
VMRCS = Site Specific Generic Mumps Routine Calling Service 1
Federated VistA SOA Services communicate with each other to produce a national view of information. 2
Chatty communication within an RDC is optimized on high speed network.
VistA Service Assembler

15. VSA Deployment and Rollout
System Component
VA Deployment and Rollout Mechanism
No Issues Foreseen
Site Specific VistA M Routine Calling Adapter (VMRCA)
Standard VA M patch release process via KIDS 
VSA Site Specific Generic Mumps Routine Calling Service (VMRCS)
VMRCS is deployed in its own Caché database file at each site deployed to a region.
M routines from other packages
VistA Service Assembler Wizard and Service Descriptors
Deployed to development and not production. Service descriptors are versioned in source control.
VistA SOA Services
Each service is packaged as a WAR file. The service provider promotes a service through development, test and production environments.
Service Registry Entries and Proxies
ESB registry entry and proxy creation processes defined by operations are followed.
The VMRCA deployment includes a new mechanism implemented in M to determine if an why an M routine failed.
VistA Service Assembler

16. VSA Security Integration
VistA
Site 1-N
Enterprise Service Bus (ESB)
M Code and Data
Registry and Repository
(Websphere Registry and Repository)
M Routines Supporting VistA SOA Services
Ensures user authentication and audit logging.
Authorization is handled by application M routines.
https
VistA SOA Service Registry Entries
VistA SOA Federating Services Platform
Consuming Applications
Core ESB
(Websphere Message Broker)
https
VistA SOA Services
More detail needs to be fleshed out here.
Open source security solutions are being proposed by Mitre. This integration pattern may serve as a starting point.
Note that VMRCA deals with the Kernel authentication.
Communication between VMRCS and the VMRCA M routines are all in process communication within the Cache instance security boundary
https
VistA SOA Service Proxies
VMRCA
https
In process communication
VMRCS
VistA Service Assembler

17. VA/Open Source Integration
VA to Open Source Release
VistA SOA Service artifacts released to OSEHRA
M patches including VMRCA released to OSEHRA
VMRCS code released to OSEHRA
Open Source Integration into VA
Open Source VistA SOA Service artifacts validated and approved by VA
M patches are validated and approved by VA
OSEHRA governs name spacing
VistA SOA Services

18. VSA Technology Stack (VA vs. Open Source)
System Component
VA Technology Stack
Open Source Technology Stack
VA/Open Source Integration Issues?
VSA Site Specific Generic Mumps Routine Calling Adapter (VMRCA)
ANSI Standard MUMPS hosted on Caché
ANSI Standard MUMPS hosted on Caché or GT.M 
M routines from other packages
VistA SOA Services, VistA Service Assembler Wizard and Service Descriptors
Java/Spring Framework/Open Source Web Technologies deployed to WebLogic
Java/Spring Framework/Open Source Web Technologies deployed to Tomcat or JBoss
VSA Site Specific Generic Mumps Routine Calling Service (VMRCS)
Caché Server Pages (CSP) and Caché Objects hosted on Caché, CSP Gateway hosted on IIS
Enterprise Web Developer (EWD) hosted on Apache/IIS/CSP and Caché stack or on Node.js and GT.M stack
EWD is not TRM compliant
EWD is not proven within the VA
Minimal foot print for the implementation of VMRCS
VMRCS is designed to provide web service protocol integration and delegate M routine authentication, execution and payload transformation to VMRCA.
VistA Service Assembler

19. VistA Service Assembler
Summary
VSA solution is cost effective
VSA Wizard enables rapid assembly of existing VistA functionality as SOA compliant “services” by non-programmers
Provides a rapid development and incremental approach
VSA solution has low organizational impact
Crosses technical boundaries (i.e. MUMPS and Java)
Accommodates current staff skill set/technical orientation limitations
VSA solution has minimal vendor dependence
Expands VistA extensibility and ‘open source’ product development opportunities.
Enables open source technology integration (Java Spring Framework and GT.M). A minimal Caché dependent gateway implementation can be ported to EWD in support of the open source community. When EWD is deemed TRM compliant in the future that implementation can ported within the VA to EWD.
VistA Service Assembler

20. VistA Service Assembler
Current Status
High level architectural design artifacts have been created and reviewed by ASD architects and the VSA development team.
Initial development of VSA tooling (service generation wizard) is underway.
Roadmap and schedule for VSA releases is being developed.
VistA Service Assembler

21. Questions / Comments 
VistA SOA Services