PHINMS: Application Integration Raja Kailar, Ph.D. The findings and conclusions in this presentation...
-
Upload
amia-sharp -
Category
Documents
-
view
220 -
download
4
Transcript of PHINMS: Application Integration Raja Kailar, Ph.D. The findings and conclusions in this presentation...
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?