Introduction to SOA EDA Event-driven architecture (Event-driven Architecture,eda)

Introduction to Event-driven architecture (Event-driven Architecture,eda)

There are two ways to understand EDA:

1. EDA is an architectural pattern that focuses on generation/consumption-based asynchronous communication. This is mainly compared to traditional thread-based synchronization systems.
2. EDA is a kind of architecture mode which takes event as the core, provides the mechanism of generating, routing and consuming the result callback.

To put it simply, service-oriented architecture (service-oriented Architecture, SOA) is an IT architecture strategy based on service-oriented concepts. Since its inception in 2002, SOA has gradually become the industry standard and has been widely used.

SOA! = Web Service

Because SOA is often compared to Web Service, there is always a misunderstanding that the two are equal, but it is not. Although there are many associations between the two, they are two distinct concepts, or different angles of consideration. While the initial popularity of SOA is inseparable from the contribution of Web service, SOA is now beyond the scope of Web service and becomes an independent design concept.

Limitations of SOA

SOA is primarily from the point of view of system deconstruction, which focuses on decomposing the entire application into a series of independent services and specifying standards and infrastructures to make these services easy to reuse and easily used by applications on various platforms. However, there are some problems in serving the actual business, because SOA is more concerned with static information, so it is not well matched to dynamic business. SOA, for example, is not a good answer to some of the following questions:

For example, in a securities company, there is a very good trading system, back-Office system, accounting system and position management system, when a customer orders on the exchange after the implementation of all these systems should be notified, and to make appropriate processing. This actually contains several questions: who is responsible for triggering such an event, and how are the systems notified? How to ensure the consistency of each system action? The SOA architecture is not a good solution to these problems because of its focus, and these problems are often a feature that is very much needed by the real system. Therefore, the integration of EDA and SOA has aroused people's attention.

By introducing an event-oriented mechanism, the system has the ability to perceive and respond quickly to business events. In fact, whether SOA or EDA is not a new technology, but in some old concepts to add some new elements.

What is an event?

The event is a significant change in state, such as the customer's next orders as mentioned above. From sources, events can be divided into system internal events and external events. From the type, it can be divided into business events and system events.

In fact, you can easily see the shadow of previous technologies (such as CORBA or DCOM) from SOA or EDA. Any system can simplify adding channels to components/services (channel, resolving communication problems), and if SOA focuses on components and services, then EDA pays more attention to channels.

Back to top of page

Event-driven SOA

We generally call the integration of SOA and EDA an event-driven service-oriented architecture (Event-driven SOA), which can be understood as a derivative of SOA. The interaction between SOA and EDA is mainly reflected in the following aspects:

Bringing event-handling capabilities to SOA

The generation of an event can trigger the invocation of one or more services, so that these static functions are dynamically concatenated together.

The service itself can also generate events

A service can generate an event based on its own needs, in addition to a specific function.

Someone has made an image of the relationship between EDA and SOA and the human body, and if SOA is likened to hands and feet, EDA is like human eyes and ears. When the eye discovers a lion is running toward you, a message is sent to the brain, and the brain sends instructions to your hands and feet: run quickly.

Back to top of page

Event-driven features of the SOA architecture

Of course, any architecture pattern has its own scenario, and Event-driven SOA is no exception.

first , it applies to an asynchronous environment. If your system requires a higher level of real-time, do not use the schema.

Second , if your system needs to face complex heterogeneous environments-cross-platform/cross-language, the service-oriented architecture can handle it well.

Thirdly , it can improve the adaptability and efficiency of the IT system to improve the return on investment (ROI) by decomposing the system function into the appropriate granularity and high reusability service.

fourth , after the ability to introduce event processing, each service is driven by a different event, so that when an event occurs, the different services of the system can be triggered automatically. This is ideal for systems with higher automation requirements.

Fifth , unlike a process-oriented system in which clients must poll for change requests (via API calls), the event-driven architecture allows systems and components to respond in real-time and dynamically when an event occurs. The event-driven architecture compensates for the lack of SOA by introducing long-running processing capabilities. This is particularly important for the financial system, such as when a stock is traded from a customer order to a final delivery that goes through a few days of life cycle.

finally , Event-driven SOA makes it easy to increase the consumer and producer of events, which makes it easy to increase system throughput, and the flexibility of the system is very good for systems that continue to grow in volume. In this regard, there is an EDA variant SEDA (staged Event-driven Architecture) to the extreme of this aspect of the design, detailed introduction please refer to the text after reference.

Back to top of page

Application of Event-driven SOA in financial system

Actual needs of the financial system

In today's society, the market is unpredictable, business opportunities are fleeting, enterprises need to have a strong flexibility and resilience, especially in the financial industry, especially in China, a financial industry in a fast-growing market. Companies require IT systems to respond quickly to business needs, or they lose their first advantage. This is somewhat similar to modern warfare conditions, where countries demand rapid response capabilities, which are reflected in the ability of the IT department to rapidly respond to business needs by rapidly developing or reusing/consolidating existing resources. Also, the financial industry is becoming more and more complex, involving a very large number of third-party systems or legacy systems, which requires IT systems to have strong integration capabilities and adaptability to heterogeneous environments. Finally, due to the rapid development of the financial industry, the specific financial business will be in the initial development of a fast expansion period, the volume of business and business type will increase sharply, which also requires IT systems have a good scalability.

Comparing the features of the Event-driven SOA mentioned earlier, we can intuitively find that the architecture can well meet the real needs of the financial system. Of course, the financial system is also all-encompassing, with different characteristics, which may be more emphasis on the financial industry trading system.

Why choose Event-driven soa--Applicability Discussion

In addition to these big factors mentioned above, we can also go deep into the specific system, from a number of micro-level to consider whether Event-driven SOA can still meet our requirements. It is a schematic diagram of a securities company stock trading System:

Figure 1. Summary of stock trading system of securities companies

As we can see, the whole application is divided into many subsystems, and there is a great deal of information interaction between the subsystems. And most of the application input needs to go through a long life cycle, such as a customer order entered into the system, will experience the foreground system (Front office), the Middle Office system (middle) and back office And many service components are included within each system. In addition to the system-level span, this life cycle is also reflected in the length of time. Furthermore, all financial systems today pursue the capabilities of STP (straight Through processing), advocating for as little human intervention as possible, so that all service components need to have self-triggering capabilities.

Back to top of page

Event-driven SOA Architecture Design

Architects are actually proposing and answering a series of questions when they start each architectural design, answering the questions and architecting the design. For example, we will always ask: Who is the end user of the system, how they will use the system, and what their core demands are. Of course, not all problems can have a satisfactory answer, more often is a process of trade-offs. For example, the key indicators of the system is difficult to meet all of a sudden, we need to combine specific business needs and human resources and time of the specific circumstances to make a choice. The following table lists some of the issues that I think are critical when I do the Event-driven SOA architecture design (based on the principles of General architecture design) and see if you share the same feeling.

Table I: Several key considerations in Event-driven SOA architecture design

Field	Key Considerations
Design principles	Business-First
	Adhere to the principle of simple application
	What are the key indicators of the system? Interoperability is the most important
Design Evolution	Functional decomposition, service definition, event definition and classification
	Choice of infrastructure
	The way of realizing EDA
Best practices	How to reuse existing base components

Let me discuss some of the specific points below:

Business-First

Any technical or architectural ideas are driven by specific business requirements, such as the emergence of SOA as a result of people breaking the silo application (application silos) and the pursuit of functional reuse of the strong demand, and the advent of EDA also catered to the business process, automation trends. Therefore, any architectural design should be subject to the specific needs of their own business, there is no best architecture design, only the most appropriate.

In SOA practice, the principle of business first is emphasized, because we must first make the reorganization of the business process, then the service of IT system. The problem of the business process itself still needs to be solved from the business itself, and the good technology can not solve the problem of the business. Imagine a good service-oriented IT system if fighting each other, lack of collaboration and communication between the various departments of an enterprise?

In addition to the efforts of the business unit, IT departments must ensure that the specific needs of the business unit are understood before making any architectural design decisions. So it is important to collaborate and communicate between the IT and the business units in the early stages of the project.

It is easy to have a misunderstanding here, especially for those experienced architects. They often have a wealth of IT experience and business knowledge, and they think they have a good understanding of the needs of the business, and sometimes they can direct the business to improve. In this conceited mood, they feel they can first develop the so-called advanced IT Systems, and then to promote, they think users will gladly accept these systems, because they represent advanced ideas, but often backfired. Let's not go into what is right or wrong, back 10,000 steps, a not fully listen to the user's opinion, no user participation system can be so easy to get the user's approval? Even if you are right.

Connectivity

In the implementation of Event-driven SOA, there are several key indicators: classification and creation of services, definition and management of events, interconnection of services, understanding of business processes, and IT implementation. Which indicator should we pay more attention to? Because it is often difficult for us to take all the indicators into account. Personally, the most important thing is that the interconnection of services. Of course, the interconnection is not so simple, not just to establish a channel of communication can be, it includes the following aspects of the content:

• Regardless of the way the communication is, it is best to automate

There are many ways to implement communication: synchronous calls, asynchronous messages, sockets, and even files, whichever is best for automation. Intervention by any worker is prone to errors and delays.

• Communication between the two sides need to define a clear interface, there is a common anomaly response mechanism

Especially when the two sides of the communication are done by different development teams, it is important to define the interface clearly at the beginning and follow the development process closely, while maintaining real-time communication. One of the things that needs to be emphasized here is the unusual coping mechanism that allows both parties to fully understand the anomalies and the measures that may be faced.

• Sharing of underlying data

In the financial system, a large amount of basic data is used (commonly referred to as Reference-data), which is used in every system. However, the fact is often not the case, often the system fighting each other, do not use different data sources, resulting in the communication process of recognition ambiguity.

To do these, technically not difficult, more important is the collaboration between projects and strong executive leadership team.

Combined with practical examples, such as the United States Armed Services joint combat system, its core is its "Data Link" system, which enables the Battlefield command center, combat forces and weapons platform to exchange data in real-time, to achieve the purpose of precise collaboration. We can feel the power of this efficient and seamless collaboration from the following description:

"In the Gulf War 7 years later, the primary" data link "has been marked by the battlefield. As an example, we can see the role of "Data link" in the operation of American interceptor missile. Iraqi's "Scud" missile launched, 12 seconds later, the U.S. Defense Support Program (DSP) in the Pacific Ocean missile warning satellite found "scud", and quickly measured its orbit and predetermined landing area, The alarm information and related data were quickly transmitted to a data center in the U.S. Space Command in Australia, and the supercomputer of the datacenter was given an emergency response to the data, which was then effectively intercepted by the "Scud" missiles, which the space command then transmitted via satellite to the "patriot" in Saudi Arabia. Air Defense Missile Command Center. The Air Defense Missile Command center immediately loaded the data into "patriot" missiles and fired, the whole process only takes about 3 minutes, and "Scud" at least 4 to 5 minutes to fly to reach the target of the sky, this is to intercept missiles created conditions. ...”

Design Considerations

With these design principles in mind, we need to consider the implementation path of the entire architecture step by step. The first thing to face is the choice of some infrastructure.

• Choice of infrastructure

Here we need to answer a series of questions: own development or purchase? Open source or commercial? What is the base platform for Web Service selection? What messaging middleware (message oriented middleware, MOM) is selected? Do you adopt an enterprise service bus, an ESB?

One of the most discussed is whether and how the ESB is used. As a personal point of view, an ESB is valuable only if the system really needs the functionality of the ESB. Don Rippert, chief technology officer of Accenture, mentioned in an early interview that the full potential of SOA would require roughly the following 4 steps:

• Get started with SOA architecture, using standard methods such as XML to use application interfaces
• Capture some business processes and turn them into WEB services
• Introduction and full use of enterprise service bus
• Integrate business Process Execution language (execution Language, BPEL) with business process modeling tools and BPEL to create different application behaviors without modifying software

Why put the use of an ESB in the third step, we need to start with the definition of an ESB to understand what the ESB actually brings to us. An ESB should be understood as a pattern rather than a product, and it should have at least these features:

• Virtualization of services that support and manage the interaction of services between virtualized communication parties. It means that the service needs only to focus on its own functionality, without having to worry about which service calls it and which service it needs to invoke.
• Transformation, packaging, and bridging of services
• Message delivery, filtering, and routing
• Service Preparation (Orchestration)

Do you remember an example of the analogy between Eda/soa and the human body before? If you follow this idea, the ESB can be seen as the human central nervous system. It accepts the message that the "lion comes" from the eye, and the whole process becomes a coordinated movement, and the hands and feet begin to move.

As you can see from the above definition, the ESB is more concerned with the application process information, stripping out the business process and handing it over to the ESB for unified management. Therefore, there is a very simple criterion to determine whether an enterprise service bus is required: it is to see if your application itself has a complex business process, and it is possible that these processes will change frequently. According to this standard, I think a lot of applications at the beginning are not complex to need to immediately adopt enterprise service bus, such as a stock management system, its business process relatively simple fixed, there is no need to introduce the Enterprise service bus such a heavyweight solution.

Of course, the idea of decomposing process information in an ESB can be borrowed, but we can do it in a simpler way.

• The way of realizing EDA

In EDA, the event processing model can be divided into the following three types according to the simple degree of the event:

• Simple event handling (processing)
• Stream event Processing (stream events processing)
• Complex incident handling (Complex event processing, CEP)

In a mature event-driven architecture, these three kinds of things tend to be mixed together. Currently, many companies have launched products that support CEP functionality. But in the actual application process, we still need to uphold the principle of simple into the complex. To solve problems with simple event handling, there is no need to use complex.

The simplest and most intuitive way to implement an event-driven architecture is to use messages. In the JMS architecture, it is easy to implement some of the underlying elements of event-driven: The producer, the consumer, and the channel of the event. For interaction between message publishers, Subscribers, and message channels and topics in publish/subscribe mode.

Figure 2. Interaction between a publisher, multiple subscribers, an event channel, and a topic

(Image from Http://www.ibm.com/developerworks/cn/opensource/os-ag-eventdriven/index.html)

In a strict sense, events and messages are different concepts. Messages represent short messages that are not directly interactive, and events often represent significant changes in state. You can think of an event as a subclass of a message, because the latter also includes messages that contain data. Also, in real-world applications, the content of events and data is often included in a message. For example, when the system receives a customer's order, it publishes a message that includes both the event (new customer order) and the specific data for the new order.

Basic components

After defining the architecture of the system, we need to start to implement it. After so many years of practice, people have also summed up some basic components that are essential to the event-driven service-oriented architecture, or often used.

• WEB Services Infrastructure (XML,SOAP,WSDL,UDDI and quality of services)
• Enterprise Service Bus (for complex applications)
• Message middleware
• Monitoring System
• Discussion of exception handling
• Configuration and Rules Engine

The first to second is the most discussed and the third one is often mentioned. Message middleware (message-oriented middleware,mom) must be secure, reliable, and fast as a basis for message operation. There are many very mature products on the market, such as WebSphere Mq,apache ActiveMQ and so on. There are also specialty products for specific industries, such as the WebSphere MQ low Latency Messaging, a specialized middleware for the financial industry to meet high-throughput, low-latency business needs.

Not many of the other three discussions, but these are critical to our application. I will introduce them in the following articles.

Figure 3. Collaboration between individual subsystems and the underlying components

Back to top of page

Conclusion

It is very simple to adopt a concept, and what we really need to do is to actually use the good ideas behind these concepts in the context of the actual needs of our projects. The use of these wisdom crystallization to solve the problems faced, this requires you to think more from the reality of the problem. Too often, too many concepts will only confuse you, and what we really need to remember is not these nouns, but the ideas behind them-things that have been passed on in the software architecture.

Resources

Learn

• SOA Quick Guide 1 2 3:IBM series of tutorials that describe the experience of SOA project implementation
  
  
• "Service-oriented World" Cheat Sheet by Patricia seybold Group (Brenda m. Michelson June 2, 2005): A good introductory SOA article that describes the SOA phase Key concepts and technologies.
  
  
• EDA and SOA: comparing EDA with SOA
  
  
• What really is SOA. A comparison with Cloud Computing, Web 2.0, SaaS, WOA, Web Services, PaaS and others: understand the nature of SOA by comparing SOA with other technologies.
  
  
• The concept of Seda:an Architecture for highly Concurrent Server Applicationsseda was first proposed by Matt Welsh in his doctoral dissertation. To learn more about SEDA, you can study Mule, whose architecture is based on SEDA.
  
  
• Event-driven soa:a Better to Soa:tibco the article on Event-driven SOA, you can learn some concepts.
  
  
• Why ESBs is made for Event-driven Architecture: Emphasize the central position of the ESB in the event-driven architecture.
  
  
• Build an event-driven framework using Apache Geronimo and JMS (J. Jeffrey Hanson, September 28, 2006).
  
  
• IBM developerWorks China WebSphere Zone: Technical information and materials for developers who use WebSphere products. Product downloads, how-to information, support resources, and a free technical library are available, including more than 2000 technical articles, tutorials, best practices, IBM Redbook, and online product manuals.
  
  

Access to products and technologies

• Most popular WebSphere trial software download: Download a free trial version of the key WebSphere product.
  
  
• IBM developerWorks software Download Resource Center: IBM deveperworks the latest software downloads.
  
  
• IBM developerWorks Toolkit: Download the latest product kit for critical WebSphere.
  
  

Discuss

• My DeveloperWorks BPM Group: Learn about the latest technical resources for business process management solutions with BPM groups set up for developers.
  
  
• My DeveloperWorks Chinese Community

Introduction to SOA EDA Event-driven architecture (Event-driven Architecture,eda)