phi-ESB

Technical White Paper

Version 1.0 November, 2009

Page 2 of 21

ABSTRACT ................................................................................................................................ 3

INTRODUCTION ......................................................................................................................... 3

TYPICAL SCENARIO ................................................................................................................. 3

OVERVIEW ................................................................................................................................. 7

TECHNICAL OUTLOOK ........................................................................................................... 10

Purpose ................................................................................................................................ 10

Who Should Use the Product? .............................................................................................. 13

Used Technology .................................................................................................................. 13

JBoss ESB ............................................................................................................................ 15

Process Designer .................................................................................................................. 17

Rule Designer ....................................................................................................................... 18

Data Mapper ......................................................................................................................... 19

BENEFITS ................................................................................................................................ 21

Page 3 of 21

ABSTRACT

This document is the technical white paper for phi-ESB. The purpose of this document is to present phi-ESB to readers not familiar with it and to provide

a basic understanding of its concepts, architectural elements and features. The paper does not

aim to explain phi-ESB in detail, but to introduce it and to provide a general idea of how it can be helpful to the reader.

The INTRODUCTION is intended for readers coming across phi-ESB for the first time, listing its

main definitions.

The TYPICAL SCENARIO section covers a typical situation of our daily round in which the

product may be helpful. It describes tasks encountered by healthcare staff, problems that may occur and our product’s problem-solving approach.

The OVERVIEW section is intended for readers encountering phi-ESB for the first time. It

provides a general description of the main components.

This brief introduction is followed by the TECHNICAL OVERVIEW, which contains details of the

product’s concepts. There is also an introduction for the suggested readers and users. The product’s structure and the technology used are described in this section.

At the end of the paper, the reader will find the product’s BENEFITS. This section explains specific features that distinguish it from other solutions.

INTRODUCTION

phi-ESB is the integration middleware based on JBoss ESB with Healthcare customization.

phi-ESB was developed after the lesson learned by the previous Clinical Integration Server (CIS) developed in house and used in the last 5 years. The main goals are:

1. Availability, reliability and performance

2. Integration procedure monitoring and quick refactoring 3. Integration protocol standardization 4. Integration with phi-Technology

phi-ESB is a process-driven integration middleware and this makes business logic and application

monitoring easier; this means that it’s also easy to understand where the integration-business-

process generates an error.

TYPICAL SCENARIO

The typical scenario is shown in the following figures:

Page 4 of 21

An example of common daily duties related to information exchange among different healthcare

systems, and how phi-ESB can address the solutions of the integration problem, can be

summarized with this simple scenario: A LEGACY SYSTEM(LS) sends data to phi via phi-ESB. phi will store data in the phi-RIM DB and make it available by using a phi-Solution.

1. LS produce HL7 v2.4 files related to Patient Demographics (ADT) and Laboratory Results(ORU)

2. Message is stored in the FS where the phi-ESB is LISTENING and when a new Message arrives a PROCESS will be triggered by the ESB. The main STEPS of the process are:

a) Check the message a) If the message is WRONG a PROCESS will be suspended b) If the message is CORRECT the V2.4 will be transformed in V3 and

will be sent to PHI via WS 3. PHI will transform the MESSAGE in one or more HL7 v3 RIM OBJECTS and STORE it

in the DB. phi-Solution will show the data and then make the update possible.

The integration-business-process with phi-ESB can be DESIGNED:

Page 5 of 21

and the process running state can be monitored:

and the MESSAGES stored and then checked or changed if an error arises:

Page 6 of 21

at the end the imported data are visible in a web-page thanks to phi-RIM DB:

Page 7 of 21

The phi-ESB approach allows to keep under control the integration process flow from the

analysis phase to the running phase with high level “tools” and “console/user interface”.

OVERVIEW

In general terms, phi-ESB is created to assist technician involved in integration project among

healthcare institutions such as hospitals.

phi-ESB is developed using JBoss ESB that is a framework service oriented that supports:

1. Exposure of system functionalities using standard technology like: JDBC, JCA, JMS, JMX, WSDL, UDDI, SOAP, JAX-RPC, JAXM, SSAJ, XQuery, XPath, MLLP, etc;

2. Distributed architecture and this mean high throughput.

The most important feature of phi-ESB is that the developer is supported by some TOOLS that help during DATA MAPPING and INTEGRATION-PROCESS analysis phase:

• DATA MAPPER: Healthcare IT systems have a variety of data models, and communicate in a range of message formats, standard and non-standard. The purpose of these tools is to build reliable, testable interfaces between these systems and message formats - so that applications can exchange data with high confidence that their information content will not be lost or altered. The core technique supported by the tools is Semantic Mapping. Semantic mappings are mappings of physical data structures onto a UML class model.

Page 8 of 21

• INTEGRATION BUSINESS PROCESS DESIGNER is helpful to visual define the

services orchestration involved in a detailed integration event

Page 9 of 21

• BUSINESS RULE DESIGNER useful to write BUSINESS RULES that are used in the

process to route the message or to better manage the error

• BUSINESS RULE WEB CONSOLE useful to change the business rule in the Run-time

environment and hot-deploy it

Page 10 of 21

phi-ESB tools are intended to assist you with developing easy-to-use, intuitive, reusable integration process and components for your daily handling of information.

Last but not least, another important functionality of phi-ESB is its INTEGRATION-BUSINESS-PROCESS monitoring CONSOLE that helps to keep under control and trace the process and its data.

TECHNICAL OUTLOOK

Purpose The INTEGRATION LOGIC is based on the BUS access point, this means high modularity and scalability. This characteristic is implemented in the phi-ESB with the adoption of a Model-Driven

Architecture (MDA) combined with a Service-Oriented Architecture (SOA), based entirely on HL7

V3 RIM as common information reference model.

One of the goal of the phi-ESB MDA is to give the “plug and play” (the optimum!) capability to

the integration middleware:

Page 11 of 21

Using the common messaging model, the integration effort required by an approach like this

Page 12 of 21

where a specialized adaptor is required for each receiver when a new service is added to the BUS and needs to talk with the others service, can be simplified by using the following approach:

when a new service is added to the BUS you just need a semantic mapping with the common

model to make the new data available to all services.

This approach is implemented using a set of VISUAL tools to make the analysis/design phase easier:

• Data mapper designer

• Integration-Business-Process designer

• ESB service designer

• Rule designer

• Deployment tool

Page 13 of 21

The phi-ESB high level architecture overview can be represented by the following figure

where the PROCESS ENGINE is the core of the system and it orchestrates all services and data.

This is possible thanks to JBoss ESB that also makes available the connection with others system

(ESB SERVICES) throughout the BUS and the monitoring thanks to the console (ESB UI -

CONSOLE). phi-ESB adds the UI ERP and phi-DB both based on HL7 V3 RIM and this makes

possible to build high level UI developed as web-application to show the DATA that passes

through the MIDDLEWARE.

Who Should Use the Product? The product is designed for software developers that has a background knowledge of JBoss ESB,

JBPM, Drools, Data format and HL7 V3 Model.

Used Technology phi-ESB’s architecture as was written in the previous paragraph implement the Service Oriented Architecture (SOA) that can be represented as follows:

Page 14 of 21

The SOA paradigm allows the integration of systems and existing applications within an architecture flexible that it can easily meet the needs for changes. This allows you to create a "non-invasive" interoperability i.e. a distributed system with "weak coupling" in which applications that belong to different systems for technology and organization can work together. The isolation between services allows a significant reduction in maintenance costs and evolution of system, while the standardization of the interfaces has the effect of standardizing information as well, with significant improvement in management processes. Low dependence between different services also offers the possibility to follow plans deployment incrementally, allowing the implementation of sustainable development plans and fully adaptable to own needs. The SOA paradigm can support :

• a service-oriented communication where an application sends data to a specific service available on the BUS

• a publish-subscribe communication where an application/service publishes a message to inform all the subscribers

The publish-subscribe communication is supported by an Event Driven Architecture (EDA) which is a software architecture that enables systems to manage events of various kind in relation to the applied field. The objects of the application domain are found each time in a very specific state: the change of this state generates an event that can trigger one or more actions in the application field. EDA is complementary to SOA architecture, where services react to events in the application area (for example the change of marital status in a common generates an event that makes the request for a service of "updating of data security" in another application domain). SOA grants significant improvements in the alignment of IT with the operational requirements of

Page 15 of 21

various application domains, but to achieve this goal one needs an infrastructure to connect IT resources regardless of location with technology with which they are deployed. So, in order to gain maximum flexibility, the infrastructure must be able to "reassemble" easily services "hot" while ensuring the reliability, security and robustness of the system. The JBoss ESB embedded in the JBoss SOA Platform makes this possible.

JBoss ESB The main components in the JBoss ESB are shown in the following figure:

Mediation of the transport model, protocol and interaction Guarantees the simple integration of services representing different technologies without changing the underlying applications or introducing interdependencies specified programmatically. Interaction models include synchronous and asynchronous call, publish / subscribe and point-to-point strategy, routing intelligent and orchestration with processes and transactional capabilities (stateful orchestration) through languages such as BPEL and jPDL.. Protocol Adapters Supports communication across a wide range of protocols and formats: SOAP, WS-*, (S) FTP, HTTP (s), TCP, file system, CSV, SMTP, JDBC, JMS, HL7 (v3 and v2), DICOM, FIXML ...

Page 16 of 21

Intelligent routing Routing configured according to subject, content and route messages to services. Guarantees interaction between the highly scalable services without bottlenecks in terms of performance or individual point of failure. Transformation, division, aggregation and enrichment of the XML message To quickly reconcile the incompatibilities between data formats used by services that interoperate. To merge data from different sources in a flexible way and extend the functionality of the services without any impact on running services. Service model event-driven The event-driven architecture organize the interactions between services, reducing the dependencies between integrated services. It simplifies the configuration of new relations between the services and supports distributed processing and high throughput of events. Reliable transmission of messages Transmits reliable (guaranteed) data to the destinations specified by the configured quality of service (such as once-and-only-once) and avoids the need to manage the data retransmission services when destination service is not available Transaction Manager Ensures high availability and transactional fault tolerance. Totally transparent to services, in-progress transactions continues without delays caused by recovery processes or rollback. The System doesn’t require RAID, OS clustering software or third-party HA frameworks in the messaging layer. Fast-mode Forward eliminates bottlenecks created by the messaging layer disk writes, offering a throughput which is significantly greater than the one assured by other messaging systems. Clustering Ensures system availability, improves performances by scaling the number of operations per unit time (throughput services) and ensures consistent response times through load balancing on the clustered servers. Allows you to change the implementation to support large amount of messages, users or applications. Modular security infrastructure Provides encryption, authentication, authorization and complete and modular ESB, with the flexibility needed to use existing corporate security policies. Support for cryptography is integrated. Web Services Advanced Web services endpoint connectivity. Integration of web service-enabled application is reliable, scalable and secure.

Page 17 of 21

J2EE and .NET applications connectivity Exposes the business logic for J2EE and .NET as a first-class service on ESB. Simplifies connectivity between the application server and the ESB. Centralized configuration and monitoring JMX-based framework used to manage system infrastructure and ESB services. Supports management of large deployments from a single console. Interaction of services from the configuration wizard The configurable control of interactions between services allows to update flow of data and processes without having to rewrite code or stopping the running services. It guarantees the flexibility to adapt SOA to business changing needs. Dynamic and distributed implementation Supports implementation and configuration of distributed services. Offers the ability to scale, reconfigure and deploy new services without disturbing other services or activities. Gradual implementation Supports the implementation and migration of ESB services and processes from development environment to testing or deployment environment. Performs impact analysis and dependency of the changes before the migration. Solves the problems of managing the upgrade of services and processes to SOA implementations scale. Centralized monitoring and recording Ability to monitor and diagnose the behavior of complex and distributed systems through centralized monitoring and recording of services, errors, process status, etc..

Process Designer This tool provides a jBPM (JBoss Business Process Management) designer-based for defining workflows of any kind and WS orchestration files. These files are then parsed and executed by

the iBPM Process Engine.

jBPM is licensed by the Apache Software Foundation under the open source licence, making it

free to download, use, embed and distribute.

Processes are organised in tasks and sub-processes. Sub-processes are used to simplify the graphical view, grouping atomic simple sub-processes together with tasks in more generic

processes, using both top-down and bottom-up approaches.

Process Designer has its own property view which is independent from the rest of the Eclipse Framework. This is where all specific Process Designer functions are stored.

Page 18 of 21

A task can be linked either to services, to user interfaces or reports (and documents), in order to

orchestrate not only the business logic but also GUI navigation.

Rule Designer Rule Designer is a tool based on JBoss Rules, licensed by the Apache Software Foundation under

the open source licence which makes it free to download, use, embed and distribute.

Rule engines simplify applications by decoupling business policy or rules logic from processes and

infrastructures. This modularity makes it possible for business analysts, rules developers and auditors to develop, deploy, modify and manage rules related to business processes with much

greater ease and speed.

Rule Designer is a great way to collect complex decision-making logic, and deal with data sets

that would be too large for humans to use effectively. The JBoss rule engine can make decisions

based on hundreds of thousands of facts, quickly, reliably and repeatedly.

Rule engines makes knowledge-transfer to centralised pools easier, and provides a powerful tool

to convert work experience of key decision-makers, managers, executives and specialists in an

easily administrable and reusable decision system. Once your business rules are separated from other logic, they can be reused more easily across

many applications and in service-oriented architecture environments.

The tool provides a graphic editor not only in Designer but also in the form of a Web application

called BRMS.

Page 19 of 21

,

Data Mapper The core technique supported by the tools is Semantic Mapping. Semantic mappings are mappings of physical data structures onto a UML class model.

Semantic mappings between an XML message format (or relational data model) and a class

model define precisely and completely how any instance of the XML or database conveys

information in an instance of the class model. Having semantic mappings from several different

XML languages onto the same class model is the soundest possible basis to ensure

interoperability between those languages – because it defines what they all mean, in terms of the common class model. The tools support four main activities:

1. Defining and validating Semantic Mappings 2. Automatic generation of translation software from the mappings 3. Testing of translations for semantic and structural correctness 4. Model-based application development

Making and Validating Mappings The tools include a Mapper Editor which can be used to define mappings between any physical data structure and any UML class model. By mapping HL7 V2 onto some class model, and mapping other structures onto the same class model, the mappings can then be used to auto-generate interfaces from HL7 V2 to other data formats. By mapping data structures onto an HL7 V3 RMIM class model, the mappings can auto-generate interfaces between any data format and HL7 V3.

Page 20 of 21

Combining these, by mapping HL7 V2 messages onto HL7 V3 RMIM class models, the tools can auto-generate V2-V3 transformations in either direction. The screenshot below shows a set of V2-V3 mappings:

Generating Translation Software Auto-generated translations are intrinsically more reliable than hand-coded translations; for instance, they carry a strong guarantee of round-trip consistency. The translations can be deployed in one of two ways:

• By a run-time Java translator, driven by mappings and derived ‘write procedure’ files • As generated XSLT

Testing Translations The tools have extensive facilities for automated testing of the generated translations. Given a set of message instances and mappings in different XML languages (such as V2.XML and V3), the tools will automatically make all possible sequences of translations between the languages, test the results for semantic and structural correctness, and display the output of the tests. The summary of a V2-V3 translation test is shown below:

Page 21 of 21

The code ‘A’ stands for V3, and ‘B’ stands for V2. Therefore the row ‘BAB’ describes the round-trip translation V2 => V3 => V2; the score 100% means that all items of semantic information in the input V2 instance survived unchanged in the final result. The round–trip ‘BB’ is not trivial; V2 is transformed in to the class model form, and out again to V2 form. Application Development The tools are built on the Eclipse Modelling Framework (EMF); so they can, for instance, convert any XML message instance, through its mappings, to an instance of EMF Ecore; or go in the reverse direction. This allows the use of many EMF-based tools and facilities for development in a Model-Driven Architecture (MDA) framework.

BENEFITS

phi-ESB provides useful tools for creating reusable integration components. Reusability means

that there is no need to re-think the same solutions many times by many users and this improve

the time-to-market.

The user-friendly interface allows developers to create and deploy self-designed, and thus self-

explanatory, reusable applications for handling data. The strong process orientation approach shortens distances between development and

organisational requirements.

The modelling driven architecture and data mapper tool with test and code generation capability

improve the reliability of the integration project reducing time in developing interface and

building test.

At the end we can list the phi-ESB advantages:

• reduce the efforts involved in adaptors development, this speeds up the time-to-market

• improve the components reuse

• improve the test capability reducing the risk factors

• reduce maintenance costs

• ensure the longest possible lifetime