connect: release 3.0 webinar june 29th, 2010. connect architecture overview les westberg 2

CONNECT:Release 3.0 Webinar

June 29th, 2010

CONNECT Architecture Overview

Les Westberg

2

CONNECT ArchitectureMessage from NHIN

3

CONNECT ArchitectureMessage to NHIN

4

CONNECT Development Environment

Version 3.0

Item Version

Java JRE/JDK 1.6 Update 16 (32-bit version)

GlassFish 2.1.1

NetBeans 6.7.1

Metro 1.5

MySQL 5.1.41

SoapUI 3.0.1

5

Major Changes in 3.0

Soap Version 1.2 Upgrade

Deferred Messaging Support

• Patient Discovery

• Document Submission

Redaction Engine

Database Independence

LiFT Support

Administrative Distribution Service Design

CONNECT Direct

IDE Neutral Build Scripts

OCSP Support

Secured & Unsecured Interfaces

6

Soap Version 1.2 Upgrade

Sai Valluripalli

7

Soap Version 1.2 Upgrade

• CONNECT release 3.0 now has all Web services upgraded to soap 1.2 version.

• Before 3.0, the Gateway used SOAP 1.2 to communicate between gateways, but most if not all of the internal web service interfaces used SOAP 1.1.

• All internal interfaces including Entity and Adapter are now SOAP 1.2.  

• This may break compatibility with adapter interfaces that have been created before CONNECT 3.0 release. Those adapter interfaces that have been created for use with CONNECT will need to be changed to use SOAP 1.2 under CONNECT 3.0.  

8

Support of the Updated NHIN Specifications

Deferred Messaging

Jon Hoppesch/ Les Westberg

9

Deferred Messaging Services

• Asynchronous messaging using two two-way services

• Request/Response on separate HTTP sockets

• Allows for long-latencies between request/response

– Hours/days/weeks/months

• Both request/response have application ACK

– Ensures that the message was received

– Important for long latencies

• Makes use of WS-Addressing– Support for “ReplyTo” value of: http://www.w3.org/2005/08/addressing/anonymous

– MessageId to track message through CONNECT services

• New web services on initiating/responding gateway per service

• Designed in conjunction with NHIN Spec Factory

10

Deferred Messaging Services Diagram

11

Deferred Messaging

NHIN Specification:

Messaging Platform, Patient Discovery, and Document

Submission specifications are currently being updated

by the NHIN Spec Factory to support Deferred

Messaging

• Messaging Platform Specification version 2.0.0.5 (5/10/2010)

• Patient Discovery Specification version 1.0.0.5 (5/10/2010)

• Document Submission Specification version 1.1.0.6 (5/13/2010)

12

Responding GW

Responding GW

InitiatingGW

InitiatingGW

PD Request

PD Request

PD Request

App Ack App Ack App Ack

ADAPTER

Patient Discovery

Request I/F

Patient Discovery

Request I/F

Patient Discovery Error I/F

Patient Discovery Error I/F

Patient Discovery Queue I/F

Patient Discovery Queue I/F

Deferred Patient Discovery: Request Transaction

13

• New Patient Discovery Service added to support Deferred Request

– Includes new Entity, Nhin, and Adapter Service WSDL Interfaces

• Additional Adapter Interfaces were created in order to support Deferred Messaging

– Error Interface allows the Adapter to decide what is the appropriate action when an error occurs and when to send back that response

– Queue Interface allows the Adapter to decide when a request is processed, but still take advantage of the Gateway’s capabilities

• Patient Discovery Request Interface on the Adapter is for pass-through mode

PD Response

PD Response

PD Response

App Ack App Ack

App AckResponding

GWResponding

GWInitiating

GWInitiating

GW Adapter

Patient Discovery

Request I/F

Patient Discovery

Request I/F

Patient Discovery Queue I/F

Patient Discovery Queue I/F

PD Request

App Ack

Deferred Patient Discovery: Response Transaction

14

• New Patient Discovery Service added to support Deferred Request

– Includes new Entity, Nhin, and Adapter Service WSDL Interfaces

• Additional Adapter Interfaces were created in order to support Deferred Messaging

– Queue interface is used by adapter to resume orchestration of the message when in orchestrated mode.

– Patient Discovery Response I/F is used to send a response when in pass-through mode

Deferred Patient Discovery: Use Cases

Man In The Loop• In certain situations a Patient Discovery Request cannot

be processed until a person approves the request

• Adapter ends up receiving all requests on one of the Adapter Interfaces and is responsible for initiating when a response is sent back

Batch Processing• In certain situations Patient Discovery requests might not

be processed by organizations as soon as they are received

• This allows for “batch” processing during off hours in order to maximize resources

15

Deferred Patient Discovery: Adapter Responsibilities

• Adapter software determines when a requestis processed

• Adapter software is responsible for setting the MessageID WS-Addressing field in the Patient Discovery Request Message

• Adapter software is responsible for setting the corresponding RelatesTo WS-Addressing field in the Patient Discovery Response Message

• Adapter software is responsible for keeping track of missing responses

16

Deferred Patient Discovery:Gateway Features

• Patient Discovery still has the ability to process

Patient Discovery Requests and Responses

– Decision of “when” to process these messages is up to the Adapter

– Message correlation capability to be able to process responses

– Decision is still up to the user on whether to have the Gateway handle

this service or to just pass-through messages to the adapter software.

• Gateway will ensure WS-Addressing fields are

maintained throughout the transaction

17

Deferred Document Submission:3.0 Changes

• Interim solution was provided in CONNECT Release 2.4

• Under release 3.0 this solution has been brought in line with the new draft NHIN specifications for deferred document submission

• Main differences between the two solutions

– ebXML Registry Response message is used for the application acknowledgement instead of CONNECT-defined acknowledgement

– WS-Addressing MessageID and RelatesTo fields are now used

18

More Information on WIKI

• Asynchronous messaging white papers/proposalshttp://developer.connectopensource.org/display/CONNECTWIKI/Asynchronous+Messaging

• Generic asynchronous designhttp://developer.connectopensource.org/display/CONNECTWIKI/Generic+Asynchronous+Communication

• Patient discovery service (added to original design)http://developer.connectopensource.org/display/CONNECTWIKI/Patient+Discovery+Service

• Document submission service (added to original design)http://developer.connectopensource.org/display/CONNECTWIKI/XDR+Service

19

Redaction Engine

Neil Webb

20

Redaction Engine

Usage– Redaction Engine added to the process for document query and document

retrieve

– Document query and document retrieve services call the redaction prior to returning results

– Removes documents from response messages based on patient preferences

– Currently only uses Document Type Code for filtering

– The redaction engine is a new component on the adapter service bus

Access– A Component Proxy is used to access the redaction engine

– Default implementation is “no-op” so the redaction engine is turned off by default

21

Database Independence

Ralph Saunders

22

Database Independence

• Hibernate Provides Database Independence– Handles differences between databases and different versions of the

same database through the use of Dialect Objects that are configured in Hibernates *.cfg.xml files.

• Reserved Words– Each database defines it’s own set of reserved words.

– Hibernate mapping files allow column and table names to be changed without having to change source code.

• Name Length Restrictions– MySQL allows a maximum of 64 characters on table and column names.

– Oracle allows a maximum of 30 characters on table and column names.

23

Database Independence

• Differences in Syntax

– SQL files for creating tables and

loading data need to be created for

each database.

• Blobs

– Blobs are implemented differently

by each database vendor.

– Hibernate provides good support

for Blobs, supporting both Java

Blob objects and Java byte arrays.

24

Large Image File Transfer (LiFT)

Vicky Vickers

25

Large Image File Transfer (LiFT)

26

Cool acronym! But what is it?• Used to move large files from one gateway to another out-of-band. 

• Initial implementation was donated by the community

• Code has been stewarded in by the CONNECT team

• LiFT is currently a CONNECT only implementation 

– CONNECT must be used for the initiating and responding sides

– LiFT capabilities must be enabled for both sides

• Plans to submit specifications to NHIN Spec Factory

• Currently tested on Windows Non-FIPS platform only

• Future work to be done in 3.1

Large Image File Transfer (LiFT)Deferred Document Submission

27

AdapterAdapter

Initiating GatewayInitiating Gateway

AdapterAdapter

File StoreFile

StoreFile

StoreFile

Store

Responding Gateway

Responding Gateway

5

1

4

3

2

7

6

1. Adapter sends Deferred Document Submission Request to the Entity Interface indicating the file URL.

2. Gateway retrieves the file to be transferred and makes it available on a File Server.

3. Deferred Document Submission Request is sent to targeted Gateway with the LiFT Payload.

4. Responding Gateway establishes a secure TCP\IP Socket connection and using the information in the LiFT payload requests the file transfer

5. After verifying the secured connection request, the file is transferred.

6. Retrieved file is written to the configured file store location

7. Gateway sends the Deferred Document Submission Request to the Adapter Interface indicating the URL of the retrieved file.

Large Image File Transfer (LiFT)

Need more information?

Visit the Design Document and Installation Guide

http://developer.connectopensource.org/display/CONNECTWIKI/Large+Image+File+Transfer+%28LiFT%29+Component

http://developer.connectopensource.org/display/NHINR30/Large+Image+File+Transfer+%28LiFT%29

28

Support of the Updated NHIN Specifications

Administrative Distribution Service

Kieran Dunne

29

Administrative Distribution

NHIN Specification

• Administrative Distribution v1.0 Dated: 10/26/2009

Underlying Specifications

• HITSP/T63 Emergency Message Distribution Element Transaction, Version 1.1

• OASIS Emergency Data Exchange Language (EDXL) Distribution Element (DE), Version 1.0

30

31

Administrative Distribution Service Design

Purpose of the Administrative Distribution Service

• Used to “push” one or more available documents or sets of discrete data

• A “document” refers to the form of data as it is transferred between NHIOs, not as it is stored in an NHIO

Service Highlights

• Data is non-patient centric

• One-way push mechanism. There is no response sent from the receiver

• Allows for multiple documents in a single distribution

• Allows for multiple targets

32

Administrative Distribution Service Design

Notes

• Design only.

• To be implemented in a future release.

Referencehttp://developer.connectopensource.org/display/

CONNECTWIKI/Administrative+Distribution+Service

Performance Testing

Jason Ray

33

Performance Testing

Create set of reusable performance test

• 3.0 Goal: “show how the performance of the gateway varies from build-to-build, providing a basis to recognize when software changes have a performance impact”

• Utilize soapui, ant

• Test are run automatically as part of CI process

• http://developer.connectopensource.org/display/CONNECTWIKI/Performance+Testing+Overview

34

Performance Testing (Results)

Release 3.0 Performance Summary    

Test Name Runs Avg

Entity Doc Query 10 1.7

Entity Doc Query 20 1.4

Entity Doc Query 50 1.4

Entity Doc Retrieve 1 8.5

Entity Doc Retrieve 10 1.3

Entity Doc Retrieve 20 1.3

Entity Doc Retrieve 50 1.3

Entity Patient Discovery 10 1.2

Entity Patient Discovery 20 1.3

Entity Patient Discovery 50 1.2

NHIN Doc Query (no results) 50 1.1

NHIN Doc Query (1 result) 50 1.1

NHIN Doc Query (3 results) 50 1.1

NHIN Doc Query (many results) 50 1.1

NHIN Doc Retrieve (1 document) 50 1.3

NHIN Doc Retrieve (1 document) 500 1.3

NHIN Doc Retrieve (1 document, 2 threads) 50 1.8

NHIN Doc Retrieve (1 document, 4 threads) 50 2.6

NHIN Doc Retrieve (sequential requests for multiple documents) 50 6.4

NHIN Doc Retrieve (single request for multiple documents) 50 1.9

NHIN Patient Discovery (no results) 50 0.9

NHIN Patient Discovery 50 1

35

Notes:‐ Run = # of iterations through the test case‐ Avg = Average time in seconds per transaction

http://developer.connectopensource.org/download/attachments/32768184/release+3.0+perf+summary.pdf

IDE Neutral Build Scripts

Srikanth Vadlamani

36

IDE Neutral Build Scripts

• IDE neutral build scripts replaced build scripts that had dependency on NetBeans IDE generated ant scripts

• Apache Ivy used to manage dependencies.

• CONNECT can be build using command line or any IDE that supports Ant Builder

• Backward compatible - NetBeans IDE users use IDE features like debug and etc.

• New features: code coverage, check style, execution of SoapUI tests

• Support execution of SoapUI tests: ValidationTestSuite, RegressionTestSuite*, DevelopmentTestSuite*

http://developer.connectopensource.org/display/CONNECTWIKI/IDE+Neutral+Build+Scripts

* require soapUI Pro

37

Support for Online Certificate Status Profile

Sai Valluripalli

38

OCSP Support

• Each NHIN initiating and responding gateway MUST implement either Online Certificate Status Protocol (OCSP) based x.509 certificate revocation checking or use CRLs against an NHIN-governed CA to determine the revocation status of each certificate as per NHIN policy.

• OCSP can be enabled by modifying java.security file under $JAVA_HOME/jre/lib/security/ path. Edit this file and search for ocsp. ocsp.enable=true property will be commented by default. Uncomment this property and ocsp.responderURL=http://ocsp.example.net:80 property.

• Ocsp.responderURL property should have the ocsp service endpoint url. If the certificate already includes this URL in AIA (Authority Informaton Access) section then we don’t have to set this property.

• To get OCSP functionality working we need to first enable checkRevocation jvm-option. -Dcom.sun.net.ssl.checkRevocation=true.

39

Secure & Unsecured Interfaces

Neil Webb

40

Secured & Unsecured Interfaces

• Security needs– Different implementations have different security needs for Gateway/

Adapter messaging.

– Some need secured and some cannot or would prefer not to use secure messaging between the gateway and adapter.

• Structure– Component proxy used to reference secured or unsecured web service client.

– Patient Discovery completed as a pilot.

• Changes required– Move some web services (e.g. Move unsecured entity web service from

AdapterWeb to GatewayWeb).

– Create new component proxy implementations and rename others.

41

Support Items

Ralph Saunders and Visu Patlolla

42

Support Items

FIPS Compliance on Sparc Solaris with Glassfish

• FIPS (Federal Information Processing Standards) publication 140-2 defines the Security Requirements for Cryptographic Modules.

• Cryptographic modules used in CONNECT should be FIPS 140-2 compliant in order to meet Federal Government requirements.

• Network Security Services (NSS) libraries are used for implementing cryptography.

• NSS libraries are implemented in C and they are platform dependent.

• NSS libraries are integrated into Glassfish using SunPKCS security provider dynamically.

• Instructions to set up CONNECT in FIPS mode on Solaris is available at http://developer.connectopensource.org/display/CONNECTWIKI/Instructions+to+set+up+CONNECT+in+FIPS+mode+on+Sparc+Solaris+environment

43

FIPS Compliance on Linux with JBOSS

FIPS Compliance on Linux with JBOSS• NSS is used to implement FIPS compliance.

• NSS libraries are configured statically using SunPKCS security provider. SunPKCS provider should be defined in java.security file.

• SSL Provider should be updated to refer to SunPKCS provider in the java.security file.

• Instructions to set up CONNECT in FIPS mode on Linux/JBOSS is available at http://developer.connectopensource.org/display/CONNECTWIKI/FIPS+validation+on+JBoss

RedHat Linux Using JBOSS• Incorrect drivers will produce misleading error messages if Blobs are used

44

Overview of 3.1 Plans

Les Westberg

45

46

CONNECT 3.1 Planned FeaturesReleased on 9.15.10

Release 3.1 Priorities are subject to change at any time. Release 3.1 Priorities are subject to change at any time.

CONNECT 3.1 Change RequestsPending CRs

Release 3.1 Priorities are subject to change at any time. Release 3.1 Priorities are subject to change at any time.

Approval of a CR may impact priorities and deliverables for the release. Approval of a CR may impact priorities and deliverables for the release.

47

CONNECT Release 3.0

Release 3.0 is currently available for download

48

http://developer.connectopensource.org/display/NHINR30/Release+3.0+Home

Questions?

Thank you for joining.

Please Participate in a Short Survey!

http://www.surveymonkey.com/s/LTLLVF3

50