1. VSA Integration with Apache
VistA SOA Update
Edward Ost
11/14/2018

2. Purpose Identify differences between VA and Community use of VSA
Understand lifecycle impacts of VSA on OSEHRA Platform
Align and leverage with VSA

3. Agenda Quick Overview of Apache Camel
Applying Apache Camel for VSA Architecture
Camel-RPC connector for VistA
Using Spring Dynamic Proxies with Camel
Next Steps

4. Principles Apply separation of concerns to technology stack
Open Standards – interoperability
Open Architecture – pluggable solution stack
Open Business Model – robust supply chain
Promote rapid evolution by minimizing client impact
Managed variation across VA and Community

5. What Stays the Same Same emphasis on VistA as provider of Services
Same emphasis on coarse grained Managed Services
Same emphasis on VSA as tooling to facilitate Managed Services compliant with Governance
Same external interoperable transport
VSA provides a Vista Platform Service Development Kit (SDK) to embed Governance into Development

6. Enterprise Service Bus (ESB) Registry and Repository
VA SOA Runtime View
E$B not in Community
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)
Allergies Service
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
Progress Notes Service Proxy
Outpatient Meds Service Proxy
No RPC Support for Existing Clients
Cache
WS-* in M
Allergies Service
Proxy
VistA SOA Services VistA Service Assembler (VSA) Conceptual and Technical Overview
VSA Development Team April 2014
VistA Service Assembler

7. VistA Service Backplane
OSEHRA VistA Platform
VistA
Platform
Site 1
M Code and Data
M Routines for Progress Notes
VMRCS
VMRCA
M Routines for Outpatient Meds
M Routines for Allergies
Optional
VistA SOA Federating Services Platform - Regional
(Java)
Enterprise Infrastructure
VistA Service Backplane
Managed Application
Progress Notes Service
Hybrid Environment
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
Legacy App
(managed)
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
RPC
Support and Migration of Existing Clients
RPC
(logical VMRCS layer)
VistA Service Assembler

8. Client Requirements Many existing RPC Clients
Impacts on Clients slows rollout
Low risk migration path
Manage a hybrid client environment

9. Service Backplane Integration
No ESB in OSEHRA Community deployments
Responsibilities of ESB can be delegated / integrated VistA Federated Service Platform
Service backplane should integrate with existing community infrastructure
Lightweight, open source solution

10. Differences – Operations
Legacy Client Support
Manage Legacy Clients
Zero-touch Deployment
Site N
M Code and Data
M Routines for Progress Notes
M Routines for Outpatient Meds
M Routines for Allergies
VistA Service Backplane
Legacy App
(managed)

11. Differences – Technical
VSA
Compose low level RPC into high level Managed Services
VMRCS
Implemented in process in M
Logical layer to compose internal services
Manage connection and session state
Enforce RBAC
Less IPC and marshalling overhead
RPC rather than SOAP for intra-Platform communication

12. Differences – Supply Chain
No WS-* implementation in M
Multiple OSS vendors for integration
No required custom built integration
Leverage existing RPC bindings

13. What Stays the Same
VistA trusts the identity communicated by the Service Backplane via secure transport
Service Backplane has pluggable Identity consistent with Enterprise Infrastructure (e.g. VA ESB)
Responsibility for coarse grained enforcement of Access Control is in the Service Backplane
Privacy and other concerns may require propagation of identity and access control policies to VistA

14. OSS Supply Chain Don’t forget the maintenance tail!
Good software is software you don’t need to maintain
Leverage the Apache OSS community for technology
KPI : [lines of business code] / [lines of tech code]
Don’t build applications, build components

15. Technical Challenges RPC currently has 32k payload limit
Need to build an appropriate Connection model for the Service Backplane to VRCS
Need to capture the Identity and Access Control mechanisms and points of enforcement

16. 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 exacerbated by the 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 VistA Service Assembler (VSA) Conceptual and Technical Overview
VSA Development Team April 2014
VistA SOA Services

17. Architecture Risk Management
Mitigation Strategy
Perpetuates shortcomings and dependencies on legacy systems
VSA extends governance to design phase, OSS allows client refactoring
Inhibits individual application replacement
Composition layer in VistA enables incremental refactoring
Granular logic, “chatty” communications exacerbated by the middleware layer
Coarse grained services composed directly in VistA
Major retooling and investment
Non-invasive, zero-touch deloyment
Subjective interpretation
Common policies expressed declaratively in VSA at design time, and enforced at runtime by VistA Service Backplane
Inability to anticipate future consumers
Layered composition of fine grained VistA services provides flexibility, EIP in Service Backplane allow choreography
Tendency to build too much, to build too little
Build a little, test a little, deploy incrementally, rapid feedback; service maturity cycle

18. Summary VistA Federated Service Platform Accelerate Adoption
Minimize impact on existing clients
Supporting existing RPC clients
Manage existing clients within new framework
Support Community operations without ESB
No dependency on Cache
No need to build and maintain WS-* in M
Option for EWD
Separation of Concerns focuses VistA M stack on data and domain logic rather than tech stack.

19. Next Steps
Demo VistA integration with Medical Devices using VistA Service Backplane
Pluggable Camel transport for VSA
Apache Camel Proxy to WS
Apache Camel Proxy to RPC