vista soa services vista service assembler (vsa) conceptual and technical overview

VistA SOA ServicesVistA Service Assembler (VSA)

Conceptual and Technical Overview

VSA Development TeamApril 2014

VistA SOA Services 2

The VSA “Narrow Focus”

“How is VistA supposed to integrate with external systems / applications in the Service Oriented Architecture (SOA) environment?”


Common Legacy SOA Interpretations

– 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

VistA

HealtheVet VistANotes Service

Rx Service

Ordering Service CP&E

ServiceConsumers

Atomization / Re-Hosting

Encapsulation / Encasement

MDWS/VIA

Consumers

VistANotes

RxOrdering

CP&E


VSA precepts

VistA Service Assembler (VSA) is not an “adaptor”. It positions VistA as a direct provider of SOA web services. This is a paradigm shift in VistA system integration approach

VSA is not a collection of ‘services’, it is a set of utilities that facilitate the structured creation of VistA-based, SOA compatible services

With minimal technical orientation, VSA facilitates the automated creation of VistA based web services to support system integration and the implementation of SOA in the VA


VSA Objectives and OutcomesTechnical—• Position VistA as a direct provider of SOA services

– Maintain/enhance existing security, auditing and role based access– Ensure implementation of the ‘user identity communication’ design pattern,

generalizable for all VistA connectivity middleware solutions– Maintain VistA data integrity and VistA application-based provision/interpretation of data – Ensure SOA architectural principles (e.g. authoritative services, non-redundancy, loose

coupling)– Standardize VistA SOA service design to support improved maintainability and

sustainability

Organizational—• Facilitate effective and reliable VistA SOA development

– Simplify organizational orientation related to development that involves both legacy VistA and OO environments

– Facilitate VistA SOA service development efficiency through automation– Enable community development participation and VSA product utilization (e.g. ‘open

source’)


Major Elements of the VSA Solution

• VistA SOA service infrastructure– VistA Service Assembler Wizard– Service descriptors database– Federating platform and federating logic– M environment components for ‘service’ execution

• Definition of Policy and Process– VSA infrastructure distribution– VistA SOA service distribution

• External component integration and implementation**– VistA SOA ‘reference implementation’ services– VSA “Pre/Post” action logic components**Collaboration with/contribution by external groups

Enterprise Service Bus (ESB)

Registry and Repository(Websphere Registry and

Repository)

Core ESB(Websphere Message

Broker)

VistA

VistA SOA Federating Services Platform - Regional

(Java)MUMPS Hosting Platform (Intersystems Caché or Open Source

Platform (ie. Graystone))

VistA Service Assembler (VSA) High Level

7

VistA Service Assembler Wizard

VistA SOA Service Registry Entries

VistA SOA Service Proxies

ConsumersConsuming Applications

‘Open Source’ connectivity

VA integration approach

VistA Service Assembler SOA Service Descriptors (generated by the Assembler

Wizard)6

6a

1 A M Developer or System Integrator identifies existing or new M routine(s) to be called by a new or existing VistA SOA Service.

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.

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.

5 Organizations using VSA as an ‘open source’ solution can engage VSA services directly if SOA infrastructure (e.g. ESB) is not implemented.

VA integration approach – ESB is deployed to production

Registry entries and service proxies created for the VistA SOA Services.

6a

6b 66a

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.

6b

M Hosting Platforms (Intersystems Caché or open source platform (ie. GT.M), 130+ instances in

production in VA)

M Code and Data

All Other Packages

Routines

Site Specific VistA M Routine Calling Service

(VMRCS)

13

2

VSA Package

Site Specific VistA M Routine Calling

Adapter (VMRCA)VistA SOA Services(generated by the Assembler Wizard)

VistA SOA Services(generated by the Assembler Wizard)

4

5

Private Interface

Cons

umin

g Ap

plic

ation

s

VSA core logic

“Pre”logic

“Post”logic

“Pre”logic

“Post”logic

ESB /

eMI

VistAs&

RPCs

SOA Services Environment VistA M Environment

VSA “Pre/Post” Logic (Future Implementation)

5.1.3.

2.4.

6.7.8.

9.10.


Solution Attributes• Cost Effective

– 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 Service Assembler 10

Current Status• VSA ‘proof of concept’ delivered December 2014• VSA ‘design time’/’run time’ components are operational,

development underway to complete “essential” functionality features and prototype deployment

• Major dependencies include ESB/eMI implementation, ‘user identity’ design pattern (incl. ‘user provisioning’), multiple “user” types, ‘consuming application’ authentication, service consumption governance, etc.

• VSA Phase II (Feb. – January 2015)—• Increment 1 – Development focused, initial implementation• Increment 2 – Implementation focused, remaining development

• Collaboration with ConnectedHealth effort• Implementation of actual business use cases related to VPS Kiosk, etc.• Non-production/”production ready” implementation of VSA ‘run time’ capabilities

targeted NLT summer 2014

Navigate to a directory location and select or create a Service Descriptor file.

Service Descriptor File<?xml version="1.0" encoding="UTF-8" standalone="yes"?><serviceDescriptor xmlns="http://vsa.med.va.gov/schema/service-descriptor-0.0.1"> <serviceName>ZzMkoMyService</serviceName> <serviceType>soap</serviceType> <version>1.0.1</version> <serviceNamespace>http://gov.va.med.zzmko</serviceNamespace> <javaPackage>zzmko.med.va.gov</javaPackage> <operation> <name>tiuLongListClinprocTitles</name> <rpcName>TIU LONG LIST CLINPROC TITLES</rpcName> <responseType>json</responseType> <parameter> <name>from</name> <type>string</type> </parameter> <parameter> <name>dir</name> <type>string</type> </parameter> </operation></serviceDescriptor>

Testing the Deployed Service

Test Results

Example of a RESTful service invoking the same RPC


Questions / Comments


Backup Slides

Paradigm Shift:VistA as an SOA Service Provider


EncasedVistA is encased as a system to isolate and then replace in the future

Adapter Integration‘Consumer applications’ are integrated with adapters that encase VistA

Fine GrainedChattiness due to business logic in adaptors, fine grained VistA methods

Built from ‘scratch’SOA services, environment and governance built “from the ground up”

Rip and ReplaceLegacy VistA is encased with adaptors as a monolithic system, then replaced

LeveragedVistA packages are leveraged and extended as building blocks for legitimate SOA services

Service Integration‘Consumer applications’ are integrated with SOA services exposed by ‘provider applications’

Coarse GrainedAll business logic positioned in VistA applications to produce coarse grained service logic modules

Built from existing componentsExisting VistA methods and data used to build SOA services, reducing development, testing, etc.

Plug and PlayVistA applications expose SOA services, allowing application-by-application replacement


VistA SOA Services Runtime ViewEnterprise Service Bus (ESB)

Registry and Repository(Websphere Registry and

Repository)

Core ESB(Websphere Message Broker)

Progress Notes ServiceRegistry Entry

Progress Notes Service Proxy

ConsumersConsuming Applications

Outpatient Meds ServiceRegistry Entry

Allergies ServiceRegistry Entry

Outpatient Meds Service Proxy

Allergies ServiceProxy

VistA

VistA SOA Federating Services Platform -

Regional(Java)

Progress Notes Service

Outpatient Meds Service

Allergies Service

Site 1

M Code and DataM Routines for Progress Notes

VMRCS

VMRCA

M Routines for Outpatient Meds

M Routines for Allergies

Site N

M Code and DataM Routines for Progress Notes

VMRCS

VMRCA

M Routines for Outpatient Meds

M Routines for Allergies

VSA National Production Deployment Configuration

VistA Service Assembler

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. 22

WSRR = WebSphere Registry and RepositoryWMB = WebSphere Message BrokerESB = Enterprise Service BusSOA = Service Oriented ArchitectureVMRCA = Site Specific Generic Mumps Routine Calling AdapterVMRCS = Site Specific Generic Mumps Routine Calling Service

Region 1 RDC

VistA

WSRR


WMBVistA SOA Service

Proxies

2

VistA SOA Federating Services Platform

VistA SOA ServicesVistA SOA Services

Site 1 to M

M Code and DataM Routines

VMRCS

VMRCA

Region 2 RDC

VistA

WSRR



Proxies

2



Site M+1 to N


VMRCS

VMRCA

Region 3 RDC

VistA

WSRR



Proxies

2



Site N+1 to O


VMRCS

VMRCA

Region 4 RDC

VistA

WSRR



Proxies

2



Site O+1 to P


VMRCS

VMRCA

1 1 1


VSA Security Integration

Enterprise Service Bus (ESB)

Registry and Repository

(Websphere Registry and Repository)

Core ESB(Websphere Message

Broker)


VistA SOA Service Proxies

Consuming Applications

VistA


VistA SOA Services

Site 1-N

M Code and Data

VMRCS

VMRCA

M Routines Supporting VistA SOA Services

https

httpshttps

https

Ensures user authentication and audit logging.

Authorization is handled by application M routines.

In process communication


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.

VSA Deployment and RolloutSystem 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

Standard VA M patch release process via KIDS 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.


VistA Service Assembler

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

ANSI Standard MUMPS hosted on Caché

ANSI Standard MUMPS hosted on Caché or GT.M

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

26

vista soa services vista service assembler (vsa) conceptual and technical overview

Documents

vista soa servicesresponding

implementation of soa

soa compliance

legacy vista

vista soa proposal notes

soa compatible services

soa architectural principles

automated creation of