Category Archives: Architecture

How you can Increase Agility and Expandability with Event Driven Architecture (EDA)

From ordering your favorite kind of pizza or a taxi to manufacturing and financial processes, everything is event driven today. People expect to do everything immediately, get instant feedback on the status of their request, and interact in real-time with anybody involved in the process.

John Mathon, the former vice president of enterprise evangelism at WSO2, wrote a white paper which explores how you can keep pace with these demands by implementing event driven architecture (EDA) in your enterprise.

EDA is essentially a messaging system that notifies interested parties of events that occur in order for them to benefit from it. The publish/subscribe model was implemented in the earliest real-time event-driven systems. Anonymity, discoverability and guaranteed delivery were a few of the characteristics that made it popular.

But this simple model deemed insufficient for the demanding and varied needs of subscribers, notes Mathon. Here came the rise of the enterprise service bus (ESB), which standardized enterprise integration patterns, the business process server (BPS) which allowed messages to trigger business processes that dealt with events and business activity monitor, now named data analytics server (DAS), to monitor the health of enterprises through statistics.

These tools became standard components in an EDA and are useful even today, which is why IoT is reusing pub/subs all over again.

Screen Shot 2016-04-26 at 3

The easiest, fastest and most efficient way of implementing EDA in your enterprise is to incorporate already existing event-driven technologies. You may think writing dedicated software would be more cost efficient and cater more to your specific needs, but in the long run the cost of maintenance would be over a dozen times more than the initial cost of development.

Existing tools are designed to increase performance and reliability of your system. It’s also easy for non-programmers to use because of features such as drag-and-drop components. They can handle large loads and are robust, secure and resilient to failure.

You can choose a specific tool for a specific problem. For example, long-running processes use BPS and short-running ones use message broker (MB). Also, when the tools are combined together it can provide additional power by working together to achieve one goal.

The problem with combining tools is that they can each be large monolithic entities that require significant communication bandwidth and can cause increased load on servers. WSO2 solves this problem because all the tools you require are built as light-weight components with the same base framework making it possible to combine them in the same Java runtime.

When implementing an EDA you need to keep in mind the message flow rates and the characteristic of the message flows. Make sure not to create extremely large messages or do a lot of computation during processing. You also need to consider whether you will be designing for microservices; your architecture design depends on this. API management is another key factor that you need to keep in mind. And lastly, you need to know which tool to use for which job.

WSO2 offers a full suite of open source components for EDA to implement highly scalable and reliable enterprise grade solutions. This includes a complete middleware stack, which includes the WSO2 integration, analytics, security and API management platforms.

For more details download John’s whitepaper here.

Event-Driven Architecture and the Internet of Things

It’s common knowledge now that the Internet of Things is projected to be a multi-trillion dollar market with billions of devices expected to be sold in a few years. It’s happening already. What’s driving IoT is a combination of low-cost hardware and lower power communications, thus enabling virtually everything to become connected cheaply. Even Facebook talked about it in their recent F8 conference (photo by Maurizio Pesce). 

16748634049_d7aea3646d_k

And why wouldn’t they? A vast array of devices that make our lives easier and smarter are flooding the market ranging from fuel-efficient thermostats, security systems, drones, and robots, among others. The industrial market for connected control and monitoring has existed and will expand in automated factories, logistics automation, and building automation. However, efficiencies are being found with new areas. For instance, connected tools for the construction site enable construction companies to better manage construction processes. We are also seeing increased intelligence from what can be referred to as the network effect – the excess value created by the combination of devices all being on a network.

What’s remarkable is that all IoT protocols share one common characteristic, i.e. they are all designed around publish/subscribe. The benefit of publish/subscribe event driven computing is simplicity and efficiency.

Devices or endpoints can be dynamic, and added or lost with little impact to the system. New devices can be discovered and rules applied to add them to the network and establish their functionality. All IoT standards support some form of discovery mechanism so that new devices can be added as near seamlessly as possible. Over the air a message can be delivered once to many listeners simultaneously without any extra effort by the publisher.

Addressing The Challenges

All of this efficiency and flexibility sounds too good to be true? You guessed right. The greatest challenge with this is security and privacy. While most protocols support encryption of messages, there are serious issues with security and privacy with today’s protocols. There are many IoT protocols and the diversity indicates a lot of devices will not be secure and it is likely that different protocols will have different vulnerabilities. Authentication of devices is not generally performed, so various attacks based on impersonation are possible.

Most devices and protocols don’t automate software updating and complicated action is needed sometimes to update software on devices. This can lead to vulnerabilities persisting for long periods. However, eventually, these issues will be worked out and devices will automatically download authenticated updates. The packets will be encrypted to prevent eavesdropping and it will be harder to hack IoT device security, albeit this could take years. Enterprise versions of devices will undoubtedly flourish, thereby supporting better security as this will be a requirement for enterprise adoption.

Publish/subscribe generates a lot of excitement due to the agility it gives people to leverage information easily, thus enabling faster innovation and more network effect. Point-to-point technologies lead to brittle architectures that are burdensome to add or change functionality.

WSO2 has staked out a significant amount of mindshare and software to support IoT technologies. WSO2 helps companies with its lean, open-source componentized event driven messaging and mediation technology that can go into devices and sensors for communication between devices and services on hubs, in the cloud or elsewhere; big data components for streaming, storing and analyzing data from devices; process automation and device management for IoT and application management software for IoT applications and devices. WSO2 can help large and small firms deploying or building IoT devices to bring products to market sooner and make their devices or applications smarter, easier, and cheaper to manage.

To learn more about event-driven architecture refer to our white paper – Event-Driven Architecture: The Path to Increased Agility and High Expandability

Want to know more about using analytics to architect solutions? Read  IoT Analytics: Using Big Data to Architect IoT Solutions

 

Enabling Microservice Architecture with Middleware

Microservices is rapidly gaining popularity among today’s enterprise architects to ensure continuous, agile delivery and flexible deployments. However many mistake microservice architecture (MSA) to be a completely new architectural pattern. What most don’t understand is that it’s an evolution of Service Oriented Architecture (SOA). It has an iterative architectural approach and development methodology for complex, service-oriented applications.

microservices

Asanka Abeysinghe, the vice president of solutions architecture at WSO2, recently wrote a white paper, which explores how you can efficiently implement MSA in a service-oriented system.

Here are some insights from the white paper.

When implementing MSA you need to create sets of services for each business unit in order to build applications that benefit their specific users. When doing so you need to consider the scope of the service rather than the actual size. You need to solve rapidly changing business requirements by decentralizing governance and your infrastructure should be automated in such a way that allows you to quickly spin up new instances based on runtime features. These are just a few of the many features of MSA, some of which are shared by SOA.

MSA combines the best practices of SOA and links them with modern application delivery and tooling (Docker and Kubernetes) and technology to carry out automation (Puppet and Chef).

In MSA you need to give importance to how you scope out a service rather than the size. The inner architecture of an MSA addresses the implementation architecture of the microservices, themselves. But to enable flexible and scalable development and deployment of microservices, you first need to focus on its outer architecture, which addresses its platform capabilities.

Enterprise middleware plays a key role in both the inner and outer architecture of MSA. Your middleware needs to have high performance functionality and support various service standards. It has to be lean and use minimum resources in your infrastructure as well as be DevOps-friendly. It should allow your system to be highly scalable and available by having an iterative architecture and being pluggable. It should also include a comprehensive data analytics solutions to ensure design for failure.

This may seem like a multitude of functionality and requirements that are just impossible to meet. But with WSO2’s complete middleware stack, which includes the WSO2 Microservices Framework for Java and WSO2 integration, API management, security and analytics platforms, you can easily build an efficient MSA for your enterprise.

MSA is no doubt the way forward. But you need to incorporate its useful features into your existing architecture without losing applications and key SOA principles that are already there. By using the correct middleware capabilities, enterprises can fully leverage the advantages provided by an MSA to enable ease of implementation and speed of time to market.

For more details download Asanka’s whitepaper here.

Everything you need to know about architecture patterns: a quick reference for Solution Architects  

The success of a solutions architect depends on the approach taken from the beginning. The role can be challenging with the need to carefully balance the organization’s business as well as technical requirements. That’s why we had a dedicated track on architecture patterns at WSO2Con Asia 2016 held earlier this year  in Colombo, Sri Lanka, to help SAs understand today’s best practices and how they can deliver value more quickly. If you missed out, here’s a recap of the patterns we discussed with the link to recordings of each talk.

Iterative Architecture: Your Path to On-Time Delivery

Agility is key for enterprises to optimize business functions, introduce new business capabilities, and explore new markets. Thus, enterprise software systems should support both evolutionary as well as revolutionary changes that will impact core business functions.

Screen Shot 2016-04-25 at 12

WSO2’s VP – Solutions Architecture, Asanka Abeysinghe, discussed the advantages of adopting an iterative approach when introducing architectural changes to support business and technical requirements. He demonstrates this with real-world examples of successful implementation of architectures in iterations. 

Breaking Down Silos with Service Oriented Architecture

Service-oriented architecture (SOA) has outrun the notion of systems silos with its use of standard protocols and specifications at integration points, which allows systems to communicate with each other in a much more flexible manner. Nadeesha Gamage, associate lead – solutions engineering at WSO2, explained the drawbacks of having a siloed architecture and how they can be avoided by moving to SOA, thereby enabling greater agility. He discussed how SOA can be broken down further to a finer-grained microservice architecture and, as a result, how an enterprise can benefit using the WSO2 suite of products. 

Event Driven Architecture: Managing Business Dynamics for Adaptive Enterprise

SOA implements a synchronous request-response model to connect remote processes in distributed system; it creates an inherent rigidity and additional dependencies when applied in modelling business processes and workflows. In contrast, event driven architecture (EDA) is based on an asynchronous message-driven communication model to propagate information throughout an enterprise, thus supporting a more natural alignment with an enterprise’s operational model and processes/workflows. In this session, Solutions Architect at WSO2, Dassana Wijesekera, analyzes key business challenges that encourage the use of EDA and discusses a pragmatic approach of designing and implementing an EDA using the WSO2 integration framework.

Moulding Your Enterprise with Resource-Oriented Architecture

An enterprise environment is typically heterogeneous, often spanning across organizational boundaries. Building such systems require tools that promote intrinsic interoperability and provide ease of integrating over boundaries. It also needs to use technology that promotes simplicity and is easy to handle. Resource-oriented architecture (ROA) supports this by focusing on entities and interactions for effective enterprise integration. Shiroshika Kulatilake, solutions architect at WSO2, explained the idea behind having a ROA in your organization, both externally and internally and also talked about how WSO2 technology can help you built your enterprise system in a resource oriented manner. 

Building Web Apps Using Web-Oriented Architecture

Web-oriented architecture (WOA) or SOA + WWW + REST  takes you several steps further by filling the blanks of SOA and helping you build an end-to-end complete web application. In addition to APIs, WOA identifies user interfaces and application states as first-class components of an architecture. Most of what we build today is actually WOA, though the abbreviation might not be that popular.

Screen Shot 2016-04-25 at 2

Lead Solutions Engineer at WSO2, Dakshitha Ratnayake, discussed the changes to WOA over the years, today’s trends, and how you can leverage WOA to build web apps. 

Reinforcing Your Enterprise With Security Architectures

WSO2’s VP – Engineering, Selvaratnam Uthaiyashankar presented an informative session on

leveraging the extensive feature set and extensible nature of the WSO2 platform to provide a robust security architecture for your enterprise. He also explained some of WSO2’s experiences with customers in building a security architecture and thereby extracting commonly used security architecture patterns.

Understanding Microservice Architecture

Today many organizations are leveraging microservice architecture (MSA), which is becoming increasingly popular because of its many potential advantages. MSA itself is divided into two areas – inner and outer architectures –  which require separate attention. Moreover, MSA requires a certain level of developer and devops experience too. Sagara Gunathunge, architect at WSO2, presented an awareness session about MSA and also discussed WSO2’s strategic initiatives in both the platform level and WSO2 MSF4J framework level. 

Deployment Patterns and Capacity Planning

Identifying the right deployment architecture is key when providing smooth operation of a production system. In the next step, it’s crucial to determine the size of the deployment by understanding the number of servers/VMs/containers necessary to support the minimum, average and possible maximum load that the system is expected to handle. Solutions Engineer at WSO, Chathura Kulasinghe, in this talk focused on how you could take a fact based approach to determine the size of your deployment. 

Pattern-Driven Enterprise Architecture: Applying Patterns in Your Architecture

It’s no secret that architectural patterns help you build beautiful enterprise architecture. High-level patterns such as SOA, ROA, EDA, MSA and WOA provide many best practices for enterprise architects who are looking to evolve their existing enterprise architecture or for those creating newer enterprise architecture strategies. Mifan Careem, director – solutions architecture at WSO2, analyzed the good, the bad and the ugly (if any) of the various architectural patterns in his talk. He discussed practical examples of the patterns in practice and also went on to build a solution architecture from scratch using WSO2 components with the help of patterns. 

Still interested in meeting the experts and discussing these topics and more? Sign up now for WSO2Con EU, which will be held in London from June 7 to 9. Be sure to grab the early bird offer before May 8.

 

Orchestration and Choreography – When To Use An ESB vs a Workflow Engine

Service chaining and workflows, commonly referred to as orchestrations, are common integration scenarios in enterprise systems development. There are two distinct type of orchestrations we deal with when realizing these systems:

  1. Short-running stateless orchestrations
    Service chaining messaging patterns that are more synchronous in nature and deals with transient data/sessions.
  2. Long-running stateful orchestrations
    Service chaining messaging patterns that are asynchronous in nature. These workflows take human input and approvals and are configured to run for longer durations with more persistent sessions.

If we look at these two types a bit closely the short-running ones are more straightforward; it mainly follows a request/response pattern, talks to multiple service endpoints, derives a response from one service call and composes the message to be sent to another service call. Enterprise integration patterns, such as message splitting, transformation, cloning and aggregation, are key building blocks in such orchestrations. The enterprise service bus (ESB) pattern fits this description quite well.

Screen Shot 2016-03-29 at 12

However, the long-running ones are more complex in nature and often involve human approval activities, work delegation, and assignments. A typical example for such a use case is a loan approval workflow; when a banking customer applies for a loan, the request triggers multiple services (1) credit approval service – this means connecting to multiple credit bureaus and valuing the customer’s credit worthiness, (2) evaluating the loan type (personal/home/vehicle, etc.), (3) finally, human approval (bank manager’s or loan department’s approval).

If you look closely, this particular workflow has different types of system interactions from a technical point of view. Not all interactions are long-running, yet the end-to-end scenario is so. The traditional architectural belief for such an end-to-end scenario is to model it with BPEL or BPMN (with a workflow/BPM tool), resulting in a complex model with human tasks and external links.
The common characteristic of this use case is that it is asynchronous in nature. The loan applicant will not get a response instantaneously; other parts, such as calling a credit bureau and getting the credit rating, is a synchronous stateless service call. Manager approval is a human interaction. Hence you do not have to follow the traditional path and build the entire workflow with the BPM tool. What you can follow is a hybrid model where you model the synchronous short-running stateless interactions with an ESB and long-running human interaction with a BPM tool. The proposed solution is depicted in the following architecture diagram.

Screen Shot 2016-03-29 at 12

The corresponding sequence of interactions has been illustrated in the following diagram.

Screen Shot 2016-03-29 at 12

SOA patterns and an enterprise middleware platform – a winning combination!

Service-oriented architecture (SOA) patterns provide structure and clarity, enabling architects to establish their SOA efforts across the enterprise. Moreover, these SOA patterns also help to link SOA and business requirements in an effective and efficient way.

Since service orientation has past roots in distributed computing, some of these patterns share similar attributes with distributed computing patterns and concepts. SOA design patterns also inherit concepts from other areas, such as object orientation patterns, enterprise architecture integration patterns, enterprise integration patterns, and software architecture patterns.

SOA design patterns capture the essence of past best practices, solution design principles, and general guidelines to build efficient SOA systems. Even though some of the implementation approaches of SOA keep changing (e.g. the introduction of rapid application development, the importance of devops principles in SOA and gradual movement from a top down approach to a bottom up approach etc.), these principles and design patterns make a lot of sense when building small to large, simple to complex distributed and service oriented systems.

The WSO2 Middleware Platform provides a set of loosely coupled, lean, open source capabilities that can be mixed and matched to build an end-to-end SOA solution. This platform approach means architects have the power of a range of orthogonal tools that support open standards to build their solution – the open standards based integration between the components is a strong arsenal when building solutions since architects can now bring in any preferred standard compliant component to achieve certain functionality, in line with an organization’s enterprise architecture principles.

The WSO2 team presented a series of SOA patterns, aptly categorised as the ‘SOA Patterns Webinar Series’ in 2014. Each webinar in this series covered the definition and explanation of the said pattern, along with real world use cases, solution architecture principles, and examples on how the pattern could be achieved using the WSO2 middleware platform and its suite of products. This is just the tip of the iceberg though – WSO2’s orthogonal toolset means implementation of patterns are just a download away.

SOA Pattern: File Gateway

http://wso2.com/library/webinars/2014/09/soa-pattern-file-gateway/

Presented by Mifan Careem and Jason Catlin, this pattern looks at how a File Gateway pattern can be used to interact with real time and batch processing systems, by providing an intermediate file processing service between batch files and services. This webinar also looks at related patterns such as service loose coupling, data format transformation, service abstraction and technology and operational challenges in implementing this.

SOA Pattern: Policy Centralisation

http://wso2.com/library/webinars/2014/10/soa-pattern-policy-centralization/

Suresh Attanayake and Umesha Gunasinghe look at the importance of managing organizatinal policies centrally to overcome redundancy issues and inconsistencies and how a Policy Centralization pattern can help overcome this. This webinar looks at how the WSO2 Platform, focusing on the WSO2 Identity Server, can be used to implement such a pattern.

SOA Pattern: Legacy Wrappers

http://wso2.com/library/webinars/2014/10/soa-pattern-legacy-wrapper/

Chintana Wilamuna and Nadeesha Gamage explore the well known Legacy Wrapper pattern, as a solution to an enterprise which has large amounts of customised legacy code that cannot be easily modified nor replaced. In this webinar, they also look at common and popular tools from the WSO2 toolset for providing a legacy wrapper, including the WSO2 Enterprise Service Bus and the WSO2 Data Services Server.

SOA Pattern: Asynchronous Queuing

http://wso2.com/library/webinars/2014/10/soa-pattern-asynchronous-queuing/

As business ecosystems become more critical, real time and complex, users expect inter-system messages to be processed in less than a second, regardless of the complexity and distance between ecosystems. Senaka Fernando and Lakmal Kodithuwakku look at the Asynchronous Queuing pattern as a solution to this. In this webinar, the team also focuses on the pros and cons of such a pattern as well as the implementation details using the WSO2 platform.

SOA Pattern: Event driven messaging

http://wso2.com/library/webinars/2014/09/soa-pattern-event-driven-messaging/

In a connected business context, systems need to work efficiently with each other, responding to internal and environmental changes real time. An event-driven architecture for messaging provides a solution to this by allowing the external entities to establish communication channels to the main entity as subscribers for its events. Dakshita Ratnayake and Chathura Kulasinghe look at the Event Driven Messaging pattern in detail, along with a demo of the same in this webinar.

SOA Pattern: Compensating Service Transaction

http://wso2.com/library/webinars/2014/09/soa-pattern-compensating-service-transaction/

In this webinar, Nuwan Bandara and Nipun Suwandaratna look at different strategies of compensating transactions and how they can be used to recover systems to the original abstract states to guarantee system integrity. They discuss a solutions approach to achieve business integrity across stateful and stateless transactional workflows and how the WSO2 platform can be used effectively to achieve this.

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.

online-sales

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. A typical enrollment system for consumers would include at least the components depicted in Figure 1.

A typical enrollment system for consumers-01-01

Figure 1

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.

Figures 2 illustrates a view of WSO2’s connected health reference architecture.

WSO2’s connected health reference architecture-01

Figure 2

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.

The Use of Event-Driven Architecture in Trading Floors-figure-01-01-01-01

Figure 1 (Source: Cisco)

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.

The Use of Event-Driven Architecture in Trading Floors-Figure-02

Figure 2

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.

A sample online taxi service potential architecture is depicted in the figure below. case-study-Ufer-Taxis

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.