CONNECT: Release 3.0 Webinar June 29th, 2010. CONNECT Architecture Overview Les Westberg 2.
-
Upload
ami-baldwin -
Category
Documents
-
view
218 -
download
0
Transcript of 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