VSA Integration with Apache

1. VSA Integration with Apache VistA SOA Update Edward Ost 5/20/2014

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. Consuming Applications Consumers VA SOA Runtime View Site N Site 1 E$B not in Community Enterprise Service Bus (ESB) VistA M Code and Data M Code and Data Registry and Repository (Websphere Registry and Repository) M Routines for Progress Notes M Routines for Progress Notes M Routines for Outpatient Meds M Routines for Outpatient Meds VistA SOA Federating Services Platform - Regional (Java) Progress Notes Service Registry Entry M Routines for Allergies M Routines for Allergies VMRCA VMRCA Outpatient Meds Service Registry Entry Progress Notes Service VMRCS VMRCS Allergies Service Registry Entry Outpatient Meds Service Core ESB (Websphere Message Broker) Allergies Service Progress Notes Service Proxy Outpatient Meds Service Proxy No RPC Support for Existing Clients Cache WS-* in M Allergies Service Proxy VistA SOA ServicesVistA Service Assembler (VSA)Conceptual and Technical Overview VSA Development Team April 2014 VistA Service Assembler

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

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 Encapsulation / Encasement • Major retooling and investment • Subjective interpretation • Inability to anticipate future consumers • Tendency to build too much, to build too little • Perpetuates shortcomings and dependencies on legacy systems • Inhibits individual application replacement • Granular logic, “chatty” communications exacerbated by the middleware layer Atomization / Re-Hosting MDWS/VIA VistA Notes Consumers Rx Ordering CP&E HealtheVet VistA VistA Rx Service Notes Service VistA SOA ServicesVistA Service Assembler (VSA)Conceptual and Technical Overview VSA Development Team April 2014 Consumers Ordering Service CP&E Service VistA SOA Services

17. Architecture Risk Management

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 VistAM 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