E-Commerce Architecture and Network visualization

CONNECT 2.1 Release

July 28, 2009

Introduction

• 

2.1 Architecture Overview- Les Westberg

• 

Enterprise Services Components (ESC):

–  Policy Engine (OpenSSO/Jericho) – Les Westberg

–  Mural MPI- Kieran Dunne

–  NIST Document Repository- Clark Shaw

CONNECT:

Architecture Overview

CONNECT Architecture

Message from NHIN

CONNECT Architecture

Message to NHIN

Orchestrated vs. Pass Through Mode

Internal NHIN Message Orchestrator

Enterprise Service Components

•  Master patient index (MPI)

–  Sun MURAL/MDM, Stable release dated 4/24/2009

•  Document registry/repository

–  NIST XDS Repository v. 2

–  Object, Metadata and Artifacts Registry (OMAR) v. 2.1, final 1

•  Policy engine

–  OpenSSO, Express Build 7 dated 4/10/2009

–  Jericho

•  Audit repository

CONNECT Development Environment

Version 2.1

Item Version

Java JRE/JDK 1.6 Update 13, Build 3

GlassFishESB GlassFishESB V2.1

NetBeans GlassFishESB V2.1

Metro 1.4

MySQL 5.0

Movement away from BPEL/ESB

Perceived

ESB

benefits not realized

–  Primarily used SOAP binding (others not used/needed)

–  GlassFishESB – features of individual components not fully implemented

–  NMR

•  Not dynamically configurable

•  Had to place all services into single large composite application

•  Does not work when crossing machine boundaries

Perceived

BPEL

benefits not realized

–  Development of moderate to complex logic in BPEL is cumbersome

–  Graphical view for complex BPEL code is unusable

–  Performance was unacceptable when making BPEL changes

Movement away from BPEL/ESB

(cont.)

Additional Issues with ESB and BPEL

Integrated GlassFishESB

•  Combined stack tied NHIN CONNECT to a particular vendor

•  Upgrades to newer versions is very time-consuming

•  Integrated solution is based on older individual components

•  Bug fixes are done on new versions of the individual components and these are not available in the integrated solution

•  Resolution of issues are difficult because they span multiple vendor development teams

•  Memory consumption has become a big issue

•  Run-time performance on CONNECT 2.0 degraded because of the necessity of handling “replaceable components”

Adoption of Component

Proxy Approach

•  Move toward Java/Enterprise Java Bean (EJB) solution •  Using Spring Framework

•  Replaceable components have both java and web service implementations

–  Configuration selection done at run-time

–  Contains a no-op implementation as well

•  Enables portability to other tools/platforms

•  Migration of current BPEL/ESB to component proxy will be done over time

Enterprise Services Components (ESC):

Policy Engine (OpenSSO/Jericho)

• 

Review release 2.0 policy engine

• 

Review highlights of release 2.1

policy engine

• 

Discuss release 2.1 design

• 

Discuss installation

Policy Engine Under Release 2.0

(Review)

• 

Interim policy engine

• 

Rules were coded within BPEL

• 

Used XACML requests

– 

eXtensible Access Control

Markup Language

• 

Primarily based on patient opt-in/

opt-out settings

Policy Engine – Release 2.1

•  Replaces 2.0 interim policy engine

•  Support for OpenSSO and Jericho

•  Implement XACML structure

–  Policy Enforcement Point (PEP)

–  Policy Information Point (PIP)

–  Policy Decision Point (PDP)

•  XSPA (Cross-Enterprise Security and Privacy

Authorization)

–  Adapter side only

•  Changed structure of CPP

–  Follows Basic Patient Privacy Consents (IHE - BPPC)

•  GUI Authentication added

–  Uses OpenSSO

Policy Engine – Release 2.1

Where does

OpenSSO and

Jericho fit into

the CONNECT

Architecture?

Policy Enforcement Point (PEP)

• 

Orchestrates policy engine call

• 

Retrieves patient consent using PIP

• 

Transforms gateway XACML to XSPA XACML

• 

Sends XSPA XACML to PDP

• 

Receives response from PDP

• 

Returns response to gateway

XACML Request Format

• 

Gateway

–  No change from release 2.0

–  Format does not follow XSPA

• 

Adapter

–  PEP transforms gateway XACML to XSPA format

–  PEP uses PIP to retrieve patient consent information

–  PEP uses OpenSSO client to call PDP

Policy Information Point (PIP)

• 

Responsible for retrieving needed resource data

• 

Manages storage/retrieval of patient consent data

• 

Patient consent is stored in document repository

• 

Patient consent stored as a CDA document following IHE

BPPC specifications

• 

When stored, sends HIEM notification if a subscription is in

place

Policy Decision Point (PDP)

• 

Receives XACML XSPA-based request

• 

XACML request contains needed resource information

• 

Applies rules to the XACML request

PDP: OpenSSO

Policy rules implemented in a

request handler

–  Java based

–  OpenSSO currently does not

support XACML Policy Rules XML

•  Sun expects support for this to be released later this year

–  Changing policy rules requires modifying and re-deploying the request handler

PDP: Jericho

• 

Jericho provides binary install

• 

Rules created in XACML XML

format

• 

Change rules by altering

XACML XML file

Patient Consent Management

Policy Engine

Processing Message From NHIN

Sequence Diagram

OpenSSO Installation

• 

OpenSSO Installation, Deployment, and

Configuration is pretty straightforward

–  Specific instructions are given in the OpenSSO Installation Guide

• 

A couple of “gotchas”

–  Be careful when setting up federations, some of the names are very similar and it’s easy to mistype something.

–  After you deploy OpenSSO and complete the configuration you will need to restart Glassfish.

Jericho Installation

•  Jericho Installation, Deployment, and Configuration is pretty straightforward

–  Specific instructions are given in the Jericho Installation Guide

•  Only oddity

–  If you get a message saying “A ConnectOpenSSOPepEntity

already exists” this is because it was installed during the OpenSSO installation portion.

•  You can ignore this error.

•  Gateway.properties

Enterprise Services Components (ESC):

Mural MPI

Mural MPI Agenda

• 

Review Installation – General Setup

• 

Review Installation – Configuration

• 

Discuss Adapter Creation

• 

Discuss General Challenges with

Mural Integration

Mural MPI

Where does

Mural MPI fit

into the

CONNECT

Architecture?

Installation Notes

Setup

1.  Followed the steps outlined in Tom Barrett’s tutorial

–  Exploring Sun MDM Suite: Open ESB and Mural Technology (V 1.0)

–  http://wikis.sun.com/display/OpenESBTutor/Tom+Barrett's+Open+ESB

+and+Mural+Tutorials

2.  Downloaded Mural plug-in for Netbeans.

3.  Created new project of type MDM / Master Index

4.  Ran wizard.

5.  Created ‘Person’ data model, used all of the fields available.

Installation Notes

Configuration

Configured MySQL database

–  Created User

–  Created Schema

–  Executed Mural generated SQL scripts.

–  MySQL installed on Mural box

Configured Glassfish

–  Created 2 JDBC Connection Pools

–  Created 2 JDBC Resources

–  Created MIDM user

–  Granted necessary privileges to MIDM user.

Adapter Creation

• 

Implemented in MuralMpiEJB (Available with Connect 2.1

Source Code download)

–  Consumes Mural generated web services

–  Services AdapterComponentMPI.wsdl

• 

Deployed MuralMPIEJB to Connect Gateway

• 

InternalConnectionInfo.xml

Mural Integration Challenges

General Issues

• 

Mural versioning issues

–  The Mural product is not versioned, and previous versions are not available for download from the SUN website.

–  Based on Multiple Open Source tools. Tools were not on the same upgrade paths.

• 

Mural Glassfish Configuration

–  Encountered a few “gotchas”. Issues were identified in multiple locations. Did not find a single installation guide.

•  Glassfish requires 2 JDBC Connection pools and 2 JDBC Resources

Mural Integration Challenges

Tool Incompatibilities

• 

Metro 1.4 incompatibilities

–  Metro 1.4 upgrades ws-gen from 2.1.3 to 2.1.5.

–  In 2.1.3 the public methods in EJB end-points, if not annotated by @WebMethod were not included in WSGEN process. However, starting 2.1.5 and above you need to specifically exclude public methods with the annotation: @WebMethod(exclude=true)

–  Modified source code produced by Mural wizard.

• 

Connect Gateway 2.1 Incompatibility

–  Current version of Mural is incompatible with Connect 2.1.

–  Incompatibility comes from updated third party jars.

Enterprise Services Components (ESC):

NIST XDS Document Repository

and Registry

NIST Document Repository Agenda

Introduction of the NIST Document

Registry and Repository

What is it and why do we care?

Review of important NIST and CONNECT

properties files

Installation “Gotcha’s” and other

common problems

Upcoming Document Registry &

Repository Features

NIST XDS Document Registry &

Repository Introduction

What is the NIST XDS Registry and Repository Software?

–  A “library” of digital content implemented by the National Institute of

Standards and Technology (NIST) to adhere to the IHE XDS specification.

–  XDS: Cross Enterprise Document Sharing – an IHE specification outlining

the common rules to follow when sharing documents between organizations/enterprises.

–  Document Registry: can be thought of as the library card catalog that

maintains descriptive information (metadata) on the content in one or more repositories/libraries. The main purpose of the registry is to enable rapid location of digital content for potential retrieval regardless of where the content is actually stored.

NIST XDS Registry & Repository

Introduction

Why do we care?

–  Document sharing is at the heart of NHIN

•  Asking for and retrieving pertinent patient data/documents can be key to patient care.

•  Asking for and retrieving patient documents in the same standard way saves time and money thus improving patient care.

–  NHIN has chosen to follow the IHE XDS specification

–  The NIST XDS registry and repository software follows the IHE XDS standard out of the box.

•  NIST provides the XDS compliant testing tools used in the international IHE connect-a-thons to which their registry and repository software adheres to and provides a measurement/comparison base for.

–  The NIST XDS registry and repository software offers a better solution for an enterprise level implementation than does the “light” repository in CONNECT.

NIST XDS Registry & Repository

Introduction

Where does

NIST fit into the

CONNECT

Architecture?

NIST XDS Registry & Repository

Introduction

The NIST Registry & Repository requires no adapter code

modifications because it adheres to the same repository interfaces as the CONNECT light-weight repository without customization.

Most plug-in integrations will require some custom adapter “glue code” to bridge the CONNECT adapter component interfaces to that plug-in’s native interface. The NIST software does not.

NIST XDS Registry & Repository

Introduction

Why a “registry” and “repository” and not just a simple

database?

–  “A registry plays a role in B2B applications that is similar to that played by databases in enterprise applications; it provides a way for

applications to store relatively static information reliably and to enable sharing of such information.” (JavaTM 2 API for XML Registries

(JAXR) Proposed Final Draft: 4/10/2002 Version 1.0)

–  Document registries and repositories are designed to:

•  Manage a lot of digital content

•  Manage a lot of detailed, standardized, structured metadata

Review of important NIST and

CONNECT properties files

• 

NIST

–  Codes.xml

•  Contains the assigning authority used by NIST’s validation services

–  Found in the “AssigningAuthority” XML element

–  E.g.: <AssigningAuthority id="&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"/>

•  Contains the metadata codes (e.g. document classCode,

healthcareFacilityTypeCode, etc.) used by NIST’s validation services

–  E.g.:

<CodeType name="classCode" classScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"> <Code code="XNHIN-CONSENT" display="XNHIN Consent CPP doc"

Review of important NIST and

CONNECT properties files

• 

NIST (cont’d)

–  Xds.properties

•  Contains the repository unique id (i.e. repository_unique_id property)

•  Contains the physical location of the folder where documents are stored (i.e. repository_base_dir property)

•  Contains the “validate_patient_id” property. This property, when set to “false” will not use the NIST patient validation component used during IHE connect-a-thon events.

Review of important NIST and

CONNECT properties files

CONNECT

–  adapter.properties

•  Contains the assigningAuthorityId property that should match the assigning authority value in the NIST codes.xml file.

–  XDSUniqueIds.properties

•  Contains the “documentuniqueid” and “submissionsetuniqueid” properties which are used in the AdapterComponentPIP class to ensure document and submisstion set id values are unique.

Installation “Gotchas” and Other

Common Problems

•  Use a good zip utility

–  Do not use the WinZip utility when unzipping any of the NIST software. This utility was modifying the java class file names causing errors during use (i.e. class not found exceptions in the tomcat1 log file).

•  Execute every postgres utility command (e.g. createuser)

–  Pay close attention to the postgres utility commands (e.g. createuser, createdb). There are a lot of these commands and missing one or entering a wrong password will trip you up later.

•  Change the CATALINA_HOME environment variable prior to starting or stopping the NIST servers

Installation “Gotchas” and Other

Common Problems

• 

Be sure to copy the xalan.jar file

–  This file should be copied to the tomcat2\webapps\ebxmlrr\WEB-INF\lib directory. Failure to do so will cause errors in the tomcat2 log file.

• 

Check your CONNECT-NIST configurations

–  The NIST assigning authority must match the CONNECT gateway’s assigning authority. The CONNECT software ships with a value of “1.1”.

–  The NIST repository unique id must match the one identified for CONNECT. The CONNECT software ships with a value of “1”.

–  Remember to change the endpoint reference of the

“adapterxdsbdocrepository” and “adapterxdsbdocregistry” service entries in the internalConnectionInfo.xml file.

Installation “Gotchas” and Other

Common Problems

• 

Use the HL7 ISO patient id format

–  This format includes a patient’s assigning authority.

•  e.g. : 289fb07d8a6f441^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO

• 

Document storage for non-consent documents

–  Use OID values for document unique ids and submission set unique ids (e.g. 2.1.3.33883.1)

–  Submission Set Unique Id values are unique for each provide and register transaction including replace document set transactions.

–  The only way to update a document or its metadata is to use a replace document transaction.

–  Ensure document storage requests contain the XDS required metadata (e.g. classCode, healthcareFacilityTypeCode, practiceSettingCode, etc.).

Upcoming Document Registry

& Repository Features

Migration to the Vangent Registry and Repository

– 

Based on the NIST XDS Registry and Repository

– 

Allows for a MySQL database implementation

Health Information Event Messaging

(HIEM)

HIEM Agenda

Evolution of CONNECT

HIEM implementation

Discuss CONNECT 2.1 implementation

Opportunity for future enhancements

Evolution of CONNECT HIEM

Implementation

“CPP” specifications

–  Specified subscribing to documents

–  CONNECT created “concrete” implementation to handle document subscriptions

CDC Biosurviellence use-case

–  Specified subscribing to a particular “topic”

Issues with early implementation

Requires code mod for new “profiles”

–  Expensive to maintain

–  Long time-to-market

–  Violation of “Open Closed Principle”

Unable to handle dynamic “consumer reference” or “subscription reference”

–  WS-BaseNotification + WS-Addressing specify handling of dynamic “references”

–  Operational, but not spec compliant Light-weight subscription repository

CONNECT 2.1 Implementation

• 

Generalized implementation

–  Entity/adapter interface change

–  Configuration driven to allow adding new “profiles” without new code

–  Designed around “topic”

–  hiemTopicConfiguration.xml

• 

Dynamic handling of “reference”

–  Required moving out of BPEL to handle dynamic SOAP headers

–  Include dynamic consumer reference in “notify” header

Opportunity for Future Enhancements

• 

Performance enhancement on subscription

repository

–  Indexing concepts to find matching subscriptions quickly

• 

Support for other dialects

–  Provide ability to plug-in support for the other standard dialects

• 

Support for “fan-out” on patient correlations

WS Reliable Message/SOAP 1.2 Upgrade

WS Reliable Message/SOAP 1.2

Agenda

Introduction to R2.1

Messaging Enhancements

SOAP 1.2

WS-ReliableMessaging

Messaging Enhancement Introduction

What Changed?

–  All NHIN public interfaces were converted from SOAP 1.1 to SOAP 1.2

–  The HIEM Notify NHIN public interface was changed to use WS-ReliableMessaging

–  These changes were driven by the NHIN

–  No other WSDL Interfaces were changed. This includes the Entity,

SOAP 1.2

SOAP 1.2 Change Overview

–  SOAP 1.2 allows the NHIN messaging interface to be more current and opens the door for more features down the road

–  From the CONNECT Gateway perspective change was strictly NHIN driven

–  For most users change is an “under the hood” change.

•  Currently only affects NHIN communication

–  This change was really just a namespace change. All NHIN WSDLs had their soap namespace changed to:

http://schemas.xmlsoap.org/wsdl/soap12

SOAP 1.2

Property File Changes

–  Some of the NHIN WSDLs had SOAP 1.1 references in their Binding or Port names.

•  To avoid confusion these were changed to just “soap” references since there is only one version of SOAP being supported

–  This caused some changes to be necessary in the connectionEPR.properties file

Ex) subjectdiscovery.PortName=PIXConsumer_Port_Soap11 was changed to:

WS-ReliableMessaging

WS-RM Change Overview

–  HIEM Notify messages are currently the only “one-way” message defined at the NHIN Interface

–  Implementing WS-RM on this interface will guarantee that this message gets delivered

•  Does not require the CONNECT Gateway to manage this guaranteed delivery

•  Glassfish application server handles this for us

–  For most users change is an “under the hood” change.

WS-ReliableMessaging

WS-RM Policy Statement

This change was just an additional WS-Policy added to the NHINSubscription WSDL for the Notify message.

Ex) <wsp:Policy wsu:Id="Reliable_Messaging_Policy"> <wsp:ExactlyOne>

<wsp:All>

<wsrm:RMAssertion/> </wsp:All>

Upcoming CONNECT Events

Code-a-thon:

August 27, 2009

10AM – 4PM

Hubert H. Humphrey Building

200 Independence Avenue S.W., Conference Rm 800 Washington, D.C. 20201

Webinar:

October 27, 2009

•  UC: Security and Context Management Infra

•  ESC: Document Reg/Rep Enhancement

•  ESC: Enterprise Class MPI (2.2 Enhancement)

•  ESC: Fine-Grain Policy Engine

•  HIEM PROFILE: CDC GIPSEGW: Security Enhancement (Part 1)

Conclusion

Questions?

Thank you for your Participation. Please visit us online at:

http://www.connectopensource.org