Tag Archives: Event-Driven Architecture

Event-Driven Architecture for Online Shopping

Event-driven architecture (EDA) offers high agility and expandability to integrate with future applications while providing real-time analysis and monitoring as events occur, ensuring that today’s solutions will also meet long-term requirements.

WSO2 offers a full suite of open source components for both event-driven SOA architectures and Web services architectures to implement highly scalable reliable enterprise grade solutions. WSO2 is one of the only vendors that can deliver all components of the EDA and Web services  architectures. WSO2 is also open source and built to be enterprise grade throughout.

Another common use case of EDA is online shopping because it can vary considerably in complexity depending on the scale and ways in which goods can be sold or acquired, and the process of fulfillment. A typical example of an online retailer is presented in the diagram below.

In this architecture, consumers have a possibility to communicate through a mobile app or go to a website to purchase goods. 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, etc. 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, and kick off a back-order process if required, which may then trigger processes to inform the customer about delivery dates. Shipping may be notified in a warehouse to initiate a delivery.

In this architecture, we assume 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 big data can be analyzed. A CEP processor is included so real-time offers can be made to customers if analytics determine it would be beneficial. RDB is used with MB to log transactions and other mission critical data.

Event-Driven Architecture and the Healthcare Industry

Insurance companies, state health care systems, and HMOs need to manage the health of customers and provide medical decisions. There are 4 parts of such a system, which is often referred to as an MMIS system. The key components of an MMIS system are as follows:

  1. Provider – enrollment, management, credentials, services enrollment
  2. Consumer – enrollment, service application, healthcare management
  3. Transactions, billing, and service approvals
  4. Patient health data, big data, health analysis, and analytics

Each of these systems are integrated and each requires its own event-driven architecture (EDA). 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 privacy.

Let’s look at one particular type of healthcare transaction; the enrollment process for patients in an insurance service.

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 this numerous ways are provided for the applicant to submit the information.  As a best practice, this application uses an ESB to mediate and transform whatever application source is used. 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 patient’s 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 created 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. Hence, 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.

WSO2 offers a full suite of open source components for both EDA and Web services architectures to implement highly scalable and reliable enterprise grade solutions. It is typical to use both architectures in today’s enterprises. WSO2 is one of the only vendors that can deliver all components of both architectures. WSO2 is also open source and built to be enterprise grade throughout.

In the architecture described by the above diagram, health care organizations have integrated event driven capabilities. A Data Services Server helps collect raw information that can be processed by analytics tools for learning and detection of anomalous conditions. Healthcare privacy is a key requirement and the architecture above provides the security required.

The Use of Event-Driven Architecture in Trading Floors

One of the first use cases for publish/subscribe event driven computing was on a trading floor. If you consider the typical architecture of a trading floor, it comprises 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, a trader who focuses on the oil sector will subscribe to any information that’s relevant that will likely in the traders estimation have an impact on prices of oil securities. Each trader would have a different view on what affects oil securities or the type of trading they do; therefore, even though you may have 2,000 traders on your trading floor, it’s unlikely that two of them will be interested in the same set of information or how these are presented.

Building a trading floor using EDA architecture involves building a high-performance infrastructure consisting of a number of services that must be able to sustain data rates well in excess of 1,000 transactions/second. As explained in Figures 1 and 2, 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 (MB) is used for trades and things related to auditable entities. Topics are used to distribute market data. Systems are monitored using an 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.

WSO2 offers a full suite of open source components for both event-driven EDA and Web Services architectures to implement highly scalable and reliable enterprise grade solutions. It is typical to use both architectures in today’s enterprises. WSO2 is one of the only vendors that can deliver all components of both architectures.

WSO2 is also open source and built to be enterprise grade throughout.

In a high-frequency-trading application (HFT), specialized MBs are used to minimize latency to communicate to the stock exchanges directly. A bank of computers will pull 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.

Other applications are for macro analysis that usually involves complex ingestion of data from sources that aren’t readily available. A lot of effort is put into data cleansing and a columnar time-series database that understands the state of things as they were known (prior to being modified by data improvements). 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 where calculations involve running historical data through algorithms to determine if the calculations will produce a profit or are reliable.

Online Taxi Service – A Typical Use Case of EDA

Event-driven architectures (EDAs) are sometimes called messaging systems. A message is simply an event or vice versa, an event becomes a message. The concept of an event-driven system is that everything that could benefit is notified of these events simultaneously and as soon as possible. Thus, the earliest real-time event driven systems came up with the notion of publish/subscribe.

An online taxi service is a typical use case of EDA; it has several applications that all talk directly to an ESB hub in the cloud or an API management service that deliver messages in real time between interested parties.

As illustrated here, 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. There’s also an API store for external developers who want to integrate the Ufer service into their apps, making it easier to arrange pickups or drops from any location.

WSO2 offers a full suite of open source components for both event-driven SOA architectures and web services architectures to implement highly scalable reliable enterprise grade solutions. WSO2 is one of the only vendors that can deliver all components of the EDA and Web services  architectures. WSO2 is also open source and built to be enterprise grade throughout.