PHINMS: Application Integration

Raja Kailar, Ph.D.

The findings and conclusions in this presentation are those of the author and do not necessarily represent the views of the Centers for Disease Control and Prevention/the Agency for Toxic Substances and Disease Registry.

Overview PHINMS – brief overview and history

Application Integration View

Summary

What is PHINMS?(Business Perspective)

Secure, reliable message transport Used by PH agencies to send data to CDC Applications using PHINMS include: BioSense, ELR,

LRN, NBS, HCN, NHSN Some states using PHINMS internally: NYS, NYC,

MN, OK, CA 4-year old product deemed “mission critical” by CDC

PHINMS Usage

7734

88,859

189,374

2003 2004 2005

Increase in PHINMS Messages

~800,000

2006 (est.)

40

2004 2005

Increase in PHINMS Senders

~360

2006 (est.)

87

What is PHINMS?(Technical Perspective)

CDC’s implementation of the ebXML 2.0 messaging standards

Runs on Windows, Linux, Solaris (platform independent)

Can be used by any application that can write and read database tables (language independent)

PHIN - Operational Environment

PHIN Node (State)

Data

PHIN Node (CDC)

Data

PHIN Node (Lab)

Data

PHINMS – Typical Message Flow

StatePublic Key (Encrypt)

Lab State

Proxy Server

PHINMSReceiver

Internet

DBQ

DBQ

PHINMSSender

Firewall Firewall

StatePrivate Key(Decrypt)

HL7

HL7

DMZ

Application Integration View

Overview Provide guidelines for business and technical

decisions on messaging

Analyze application interfacing considerations

Explore ways to leverage messaging infrastructure to satisfy new data sharing needs

Data Sharing Models

Applications,Data

User

User

User

User

User

User

User

Centralized Applications/Data Sharing

Model Pros Cons

Centralized

Repository

Accuracy (real time updates) Scalability

Single point of failure

Security

Distributed

Repositories with

Query/Response

Accuracy

Autonomy (data ownership)

Privacy

Application level tight coupling

Reliability

Distributed Repositories with Messaging

Application level loose coupling

Autonomy, Privacy

Data latency

LocalApplications,

Data

UserUserLocalUser

Local Applications and Data,Data Sharing via Query / Response

LocalApplications,

Data

UserUserLocalUser

Query

Response

LocalApplications,

Data

UserUserLocalUser

Regional Application,

DataRepository

LocalApplications,

Data

UserUserLocalUser

Messaging

Messaging

Local Applications and Data,Data Sharing through Messaging

UserUserRegionalUser

National Application,

DataRepository

Messaging

Regional Application,

DataRepository

Messaging

UserUserFederalUser

To Message Or Not To Message?

When to message? Periodic, un-attended data exchange Data latency acceptable

When not to message? Data latency not acceptable (synchronization

needed) Manual confirmation is necessary

What Are Your Messaging Requirements? Is there a need for automated B2B data sharing?

Is sensitive data being shared via the Internet?

Is guaranteed delivery of messages important?

Do you have a mix of small / large agencies (some with only “outbound” connections to Internet)?

Is PHINMS the Right Tool For You?Requirement: Secure, Reliable Messaging over Internet

Option Pros ConsBuild Full control over product, direction,

intellectual property1) Expensive and time consuming

2) Custom implementations may

not interoperate

3) Product maintenance and support burden

Buy 1) Quick return on investment

2) No product support burden

1) Cost

2) No control over product life cycle/direction

3) Proprietary implementations may not interoperate with other products

Use freeware (e.g., PHINMS)

1) Low investment, high returns

2) No product support burden

3) Proven solution

Reduced control over product life cycle/direction

PHINMS - Application Interfaces

PHINMSSENDER

PHINMSRECEIVER

DatabaseQueue

FilesystemFolders (new)

File descriptors

DatabaseQueue

ebXML 2.0

ebXML 2.0

ebXML2.0JMS

Queue

Servlet

PHINMS - Application Interfaces

Sending Side - Interfacing StepsSending

Interface

Usage

Database Queue

Create Database Record in transport-queue with Payload and Meta-data

File Descriptors

1) Drop file in “outgoing” directory

2) Create file descriptor

File-system Folder (new)

1) Create “Folder-Map” (map folder to addressing information)

2) Drop file to folder, and transport uses the properties in the Folder map to send file

Sending Interface Considerations

Sending

Interface Option

Pros Cons

Database Queue (preferred)

1) Ease of maintenance

2) Queue Viewer (Console)

1) Dependency on DBMS

2) Requires ODBC/JDBC programming

File descriptors 1) DBMS not needed

2) Simpler programming

1) Harder to manage

File-system folders

(new)

1) DBMS not needed

2) No added programming

1) Queue management more complex

2) Higher disk space use

Receiving Interface Options

PHINMS

(Node A)

PHINMS

(Node B)

Message

Acknowledge

DataMessag

e

Asynchronous Processing Level Response

ReceivingApplication

Response

Response

Acknowledge

(optional)

QUEUE

Sending

Appn.

Send

Poll(optional)

PHINMS

(Node A)

PHINMS

(Node B)

Message

Acknowledge +Servlet Response

ReceivingServlet

Message

Servlet Response

Synchronous Processing Level Response

SendingAppn.

QUEUE

Send

Poll

Receiving Interface Considerations

Receiving

Mode

Pros Cons

Synchronous

(e.g., Servlet)

Processing level response on same connection (no delays)

Not reliable (timeouts)

Harder to trouble-shoot / maintain

Asynchronous

(e.g., DBMS or JMS Queue)

Reliable, Scalable,

Easier to trouble-shoot/maintain

No processing level response

PHINMS - Messaging Models

Model Pros Cons Sending Application Interface

Gateway 1) Single security model

2) Simple deployment

3) More dynamic collaborations

1) Scalability

2) Single point of failure

3) Asynchronous only

1) Address information of Gateway and Recipient

2) Encryption with Recipient key (not gateway key)

Peer-to-Peer 1) Scalable

2) Private

3) More reliable

4) Synchronous and Asynchronous models

1) Complexity

2) Many security models, infrastructures

3) Static collaborations

Address/encryption information of Peer node

Messaging Gateway

(Route-not-Read)

Peer-to-Peer

(Direct-Send)

Leveraging Existing PHINMS For New Data Sharing

PHINMS(Node A)

SendingApplication A

PHINMS(Node B)

ReceivingApplication B

Q Q

Existing Infrastructure

PHINMS(Node A)

SendingApplication A

PHINMS(Node B)

ReceivingApplication B

Q Q

Leveraging Infrastructure to Send/Receive New

Types of Application Data To/From Same Partners

SendingApplication C

ReceivingApplication D

Q

PHINMS(Node A)

SendingApplication A

PHINMS(Node B)

ReceivingApplication B

Q Q

Leveraging Infrastructure to Send/Receive To/From

new Partners

PHINMS(Node D)

ReceivingApplication D

Q

PHINMS(Node P)

SendingApplication C

Q

PHINMS - Scaling Considerations

Route specificThread

PHINMS Sender

Application Q

Sender Scaling UsingMulti-Threading

Send

Write

PHINMS Sender A

Application

Q

Sender Scaling UsingMultiple Senders

Send

PHINMS Sender BQ

Send

Split

Party-ID1

Party-ID2

App-ServerThreads

PHINMS Receiver

ApplicationQ

Receiver Scaling Using Application Server

Multi-Threading

Receive

Read

PHINMS Receiver A

Receiver Scaling UsingMultiple Instances of

Receiver

PHINMS Receiver B

Party-ID1

Party-ID1

LoadBalancer

Summary Data sharing needs determine suitability of

messaging, architecture and tools PHINMS is a “pluggable” component that enables

secure/reliable data sharing Many public health organizations have PHINMS Can leverage infrastructure for new data sharing As usage goes up, need to scale up your

infrastructure

Questions?