A short paper on EDA

A short paper on EDA
11:10:57
Alexander Alves is a software engineer of BEA WebLogic Integration Team. Alex has been involved in the enterprise integration field for more than 10 years and has used technologies such as CORBA, J2EE, and Web services.

The event-driven infrastructure is an infrastructure style that consists of decoupled applications that exchange events for interaction. These applications are called event-driven applications. The event-driven application can act as the event transmitter, as well as the event responder and processor.
Event-driven infrastructure is very important because the real world is event-driven. The financial world is an example in which traders' applications respond to events (or exchanges) in the financial exchange market. The event-driven architecture should be modeled by the event-driven infrastructure.
An event-driven application is a sense-and-respond application, that is, the application responds to the event and processes the event.
An event is a meaningful state change for an observer. Generally, an event occurs in the form of a protocol message. Events can be simple or complex. Simple events do not contain meaningful member events. Complex events include meaningful member events, which are also very important. An example of a simple event is a stock auction event and a stock sale event. A complex event is a stock transaction event, which includes both a spot price event and a sale event.
Events can be transmitted through different media, two of which are channels and streams. The channel is a non-active virtual pipeline. That is to say, the producer component is responsible for inserting data into one end of the pipeline, while the other consumer component is responsible for removing data from the other end of the pipeline. As long as the data is not removed from the component, it will be stored in the channel. Of course, the channel can be restricted. In this case, it can stop accepting new data or clear existing data (as long as it thinks appropriate ). Examples of the channel include the JMS queue and topic. On the contrary, streams are active virtual pipelines, that is, they support continuous data streams. If the producer component does not directly listen to a stream, it may miss some data. Because the Stream does not need to store data, the stream can support high-volume streaming data flowing through them. An example of a stream is air TV broadcast.
If you have received events, the next task of the event-driven application is to process these events. Event processing is defined as a computing stage for consuming and Generating Events at will. Currently, as Roy Schulte specifies, there are four ways to classify event processing:
Event transfer: events are processed only between components, so there is almost no processing operation, and generally only simple events are processed. The event transfer application is asynchronous, phased, and triggered by the arrival of an event from a single event stream or channel. Sometimes they are referenced as message-driven applications or document-driven applications. Examples include simple pub-sub applications.
Event coordination (or proxy): Events are filtered, transmitted (such as content-based), and converted (such as reinforcement ). Event Coordinator is stateless and can be used to process simple events and complex events. However, they do not combine their own new complex events, that is, event Coordinator cannot combine simple events (that is, aggregation) as complex events, mainly because they cannot be maintained. Generally, only one event stream or channel can be input, but multiple event streams or channels can be output. This example includes an integrated proxy.
Complex Event Processing (CEP): Events are processed by matching with complex patterns and complex relationships (such as causal relationships, time selection, interrelationships, and integration. CEP applications are stateful; simple events and complex events are received from several event streams, while new complex events may be integrated. CEP applications must be able to handle high-volume events, so they generally only use streams.
Non-linear complex BPM: Event-based business processes that model non-linear complex workflows. Business processes can handle unexpected situations, including complex patterns and complex event relationships.
Event stream processing (ESP) is a separate event processing on the stream, opposite to the channel. Therefore, CEP is always part of ESP; however, esp includes other event processing types (such as event transfer and event coordination) when these are executed on the stream rather than on the channel.
An event-driven application can act as the event source, event receipt, or both. The event source generates an event for receiving the event. Note that there is no need to create events for the event source, and event receipt is not required by the event consumer. In addition, the event source and event receipt are completely isolated from each other:
The event source does not have to transmit control to the event for receiving. This is when the service consumer delegates the work to the provider;
Event receiving does not provide services for event sources. This is when the consumer initializes and consumes work from the provider;
You can add and remove event sources and receive events as needed without affecting other event sources and events.
How can we compare EDA and SOA? This depends on the loose nature of the definition term SOA. If SOA is defined as an infrastructure that promotes reuse of modules and distributed components, Eda is a type of SOA. If SOA is defined as the infrastructure where the module provides services for the consumer module, Eda is not an SOA.
The concepts described above are based on the work of Roy Schulte, Mani Chandy, David luckham, and others.
Next, let's focus on some real-time concepts.
Real-time is a system capability that ensures code execution in a timely and foreseeable manner. In other words, if a developer specifies that an object must be executed within the next 100 milliseconds (or completed within the next 100 minutes ), the real-time infrastructure ensures that this object is executed within this constraint time.
The event-driven infrastructure is suitable for real-time technology. Event-driven applications are usually implemented using an asynchronous mechanism. Such non-synchronization improves resource utilization and ensures the real-time service quality.
Objects with time constraints are named as scheduling objects. The system uses a specific standard (for example, the number of missed deadlines) to measure the degree of conformity of time constraints. The scheduler schedules the execution of standard schedulable objects to maximize. The scheduler uses different algorithms or policies to achieve this. One of the policies is Rate Monotonic analyze (RMA ). RMA depends on the thread priority, uses it as a scheduling parameter, and determines that the highest priority should be associated with the shortest task.
Let's reconsider CEP. CEP allows you to specify time constraints during event processing. For example, you can specify that an event occurs within 100 milliseconds of another event. Therefore, CEP rules (such as queries) are essentially some types of schedulable objects. Therefore, the CEP proxy must be a real-time proxy.
In a very loose form, CEP can be further characterized by two features, that is, ensure the function and action function. The former determines whether an event triggers a response, and the latter specifies the response that will be used if this guarantee is met.
Consider a system that supports CEP proxy. The proxy's action function is coded in Java. This means that the system must support the development and deployment of Java applications. Therefore, in this relationship, the Java application server or the Real-Time Java application server (as mentioned above) you must get some extension.
More specifically, the CEP Java action function does not require all the functions of the application server. For example, some transaction services, persistent storage, and secure container services may not be required. What is needed is the app server with the minimum required features. This minimum requirement can also be applied to real-time functions. We do not need to allow a complete real-time feature set for all types of application development, but need a real-time feature set with the lowest requirements to support CEP proxy.
Systems that support CEP also support other event processing types, such as event transfer and event coordination. Therefore, the lightweight Real-Time Java application server that can host CEP proxy is a good comprehensive solution for obtaining EDA.

This article is transferred from
Http://dev2dev.bea.com.cn/blog/alexandrealves/200702/06_351.html