Use cases of EDA Event Driven Architecture

Here is a general architectural toolset for building EDA:

 

One of the first use cases for publish / subscribe event driven computing was on a trading floor.   Let’s look at the typical architecture of a trading floor.

 

Use Case Trading Floors

 

A trading floor has information sources from a variety of providers.   These providers aggregate content from many sources and feed that information as a stream of subject oriented feeds.   For instance, if I am a trader who focuses on the oil sector I will subscribe to any information that I believe is relevant to what I think will affect the prices of oil securities.  Each trader has a different view of what affects oil securities or the type of trading they do so that even though you may have 2000 traders on your trading floor no two of them are interested in the same set of information nor do they want it presented in the same way.

 

Building a trading floor using EDA architecture involves building an extremely performant infrastructure consisting of a number of services that must be able to sustain data rates well in excess of 1000 transactions/second.    Ultra high reliability and transactional semantics are needed throughout.   Every process is provided in a cluster or set of clusters and usually an active/active method of fault tolerance is employed. Message broker is used for trades and things related to auditable entities.   Topics are used to distribute market data.   Systems are monitored using Activity Monitor and Metrics produced.   Data also needs to be reliably sent to Risk Analysis which computes credit limits and other limits the firm has for trading operations in real-time. Complex event processing is used to detect anomalous events, security events or even opportunities.

 

In a high-frequency-trading application (HFT) specialized message brokers are used that minimize latency to communicate to the Stock Exchanges Directly.  A bank of computers will be taking in market information directly from sources and high powered computers will calculate opportunities to trade.   Such trading happens in an automated way because the timing has to be at the millisecond level to take advantage of opportunities. Specialized hardware is also used.

 

Other applications are for macro analysis which involves usually complex ingestion of data from sources that aren’t readily available normally.  A lot of effort is put into data cleansing and a columnar time-series databases which understands the state of things as they were known, as they were modified by improvements in data.  These are called as-of data and involve having persistent all variations of data and modifications so the time-series can be recreated as was known at a certain time.  Apple uses such notions in its Time Machine technology.   Calculations involve running historical data through algorithms to determine if the calculations will produce a profit or are reliable.

 

Use Case Health Care

 

Insurance Companies, State Health Care Systems, HMO’s need to manage the health of customers, provide medical decisions.   There are 4 parts of such systems.  These are called MMIS systems sometimes.   The 4 components of an MMIS system are:

 

1. Provider – Enrollment, Management, Credentials, Services enrollment
2. Consumer – Enrollment, Services Application, Health Care Management
3. Transactions, Billing and Service approvals
4. Patient Health Data, Bigdata, Health Analysis and Analytics

Each of these systems are integrated and each requires its own EDA architecture.   Standards in the health industry include HL-7 for the message format and coding. Important standards to be supported in any system include HL-7, EHR standards, ICD coding standards and numerous other changing specifications.   Systems need to support strong privacy, authentication and security to protect individuals.

 

 Here is a view of the Connected Health vision:

 

Here is another view of the architecture:

 

A typical Enrollment system for consumers would include at least the following components:

 

When a patient requests to enroll in a medical insurance company or system they typically make an application in one form or another.  To facilitate numerous ways this application can be made a mediation ESB is best practice.   Mobile applications for instance can talk directly to the ESB.

Once an application has been received it needs to be reliably stored and a business process initiated to process the application.   Typically, the patients past data will have to be obtained from existing medical systems as well as history of transactions, payments, providers etc so that a profile can be made to determine if the application should be approved. 

Over time, new information coming into the system may undermine an applicant’s eligibility to participate in a certain plan.   So, the system has to continue to ingest data from various data sources including information on the applicants living address, medical conditions and behaviors.   A CEP engine can detect events that may trigger a business process to review an applicant’s status.

 

Use Case: Online Shopping 

Online shopping can vary considerably in complexity depending on the scale and ways in which goods can be sold or acquired, the process of fulfillment.    An example online seller is presented.

 

In this architecture consumers have a possibility to communicate through a mobile app or to go to a web site to buy things.   When they use a mobile app it can talk directly to the ESB.  When coming in through a web service it will typically initiate a process in an app server.

All information goes through the ESB so requests to search, look for more information, place orders, query the status of orders are all processed through the ESB and lead to initiation of business processes or directly querying the database and returning a result.

A business process will coordinate fulfillment, determine if there is inventory or where the inventory is, kick off a back-order process if required which may then kick off processes to inform the customer in delivery dates.  Shipping may be notified in a warehouse to initiate a delivery.

In this architecture we are assuming the suppliers have an API to interact with the selling merchant so they can inform the merchant of their delivery and to place orders.  Real-time inventory must be managed in the RDB and product information constantly ingested and updated. 

Activity monitoring is used to collect data on all activities throughout the system including the customer so that metrics and bigdata can be analyzed.   A CEP processor is included so real-time offers can be made to customers if analytics determines it would be beneficial.   RDB is used with Message broker to log transactions and other mission critical data.

 

Use Case: Online Taxi Service

 

Let us consider an online taxi service.  What is the architecture such a firm would need:

An on-line taxi service has several applications which all talk directly to a ESB hub in the cloud or an API management service.  A message broker is added for queueing and creating a publish subscribe framework in the backend infrastructure.  This allows a new pickup to alert several support services and tracking.   I also include an API Store for external developers who want to integrate Ufer service into their apps making it easier to arrange pickup or drop off from any event, bar or business that wants.

 

This EDA Series:

Event Driven Architecture – The Basics

Event Driven Architecture – Internet of Things – What do trading floors and home thermostats have in common?

Event Driven Architecture – Architectural Examples and Use Cases

Event Driven Architecture – Enterprise Concerns:  High Availability / Disaster Recovery / Fault Tolerance / Load Balancing / Transactional Semantics / Performance Design

Other Articles you may find interesting:

MicroServices – Martin Fowler, Netscape, Componentized Composable Platforms and SOA (Service Oriented Architecture)

Publish / Subscribe Event Driven Architecture in the age of Cloud, Mobile, Internet of Things(IoT), Social

ESB Performance Comparison

Enterprise Application Integration

Event Driven Architecture (EDA) Pattern

Understanding ESB Performance & Benchmarking

Understanding Enterprise Application Integration – The Benefits of ESB for EAI