Open Source Reverse Ajax Library: event-driven web development

This series of articles shows you how to use reverse Ajax http://www.aliyun.com/zixun/aggregation/7332.html "> Technology to develop event-driven WEB programs." The 1th part describes reverse Ajax, polling, streaming, Comet, and long polling. Part 2nd describes how to use WebSocket and discusses the limitations of WEB servers that use Comet and WebSocket. The 3rd part explores some of the difficulties you may encounter in implementing your own Comet or WebSocket communication system when you need to support multiple servers or provide a stand-alone WEB application that users can deploy on their own servers. The 3rd part also discusses the Socket.io. Part 4 introduces atmosphere and cometd, which are the most famous open source reverse Ajax libraries for Java servers.

Previously, you learned how to create components from events. In the last installment of this series, the event-driven development principles are applied and an example of an event-driven Web application is built.

For

Ideally, if you want to make the most of this article, you should know about JavaScript and Java. To run the examples in this article, you will need to use the latest version of Maven and JDK.

Terms

You may be familiar with event-driven architecture (EDA), Eventbus systems, messaging systems, complex event handling (CEP), and channels. These terms and concepts have existed for many years. As technology matures, you may hear more about them. These concepts are briefly explained in this section.

What happens in the

event system. Events usually have properties such as Date (timestamp), source or location (the component we clicked), and some event description data. Depending on the system, events can also have other properties.


Event-handling Architecture (EDA) is also known as event-based programming, an architectural design pattern in which applications contain components that communicate and perform operations by sending and receiving events. The Java Swing graphical user interface (GUI) is an example of an EDA. Each Swing component can perform actions such as listening events, reacting, sending other events, and so on. EDA consists of several components: event generators, event consumers, events, and processing software. Event Creator: This component is used to emit events. In the example in this article, a form Submit button is an event builder. Event Consumer: This component is used to listen for specific events. For example, in the form submission example, the browser listens to the Click events on the form submission button to send form data to the server. Event-handling software: This is the system kernel where event creator publishing events and event consumers register themselves to receive events. Depending on the software, the process can be simple (simply forwarding the generated events to the consumer), or it can be complex (such as CEP). When using CEP, the software supports a variety of processing methods, such as event aggregation, filtering, and transformation.

Esper is such a software. Event-handling software can be not only an application that runs independently, but an integrated library in an application.

Messaging System an event-driven application in which event generators publish messages to channels, and event consumers subscribe to channels. There is no link between the event creator and the consumer, completely independent. In this event-driven application, the term message is usually used, not the event.

A method of classifying events in a
channel messaging system. The channel represents the destination where the event creator expects the event to be sent. For example, in a chat room application, the channel may be/chatapplication/chatrooms/asdrt678. This channel will identify a chat room where event generators can send messages, and the graphics component can subscribe to the chat room to display the newly arrived message.

Some messaging systems provide two channels: queues and topics.

Queues: When a message is sent to a queue, only one event consumer can receive and process it. Other users cannot see it. Queues can be persistent to guarantee message delivery. The best example of a queue might be a mail request. When the user registers, the WEB application publishes a message to the queue/myapp/mail/user-registration. Several mail applications may subscribe to the queue. Even if not, the message will not be lost. Topic: When a message is delivered to a topic, each Subscriber receives the relevant message. Topics are usually not persistent. One of the topics for monitoring software is/event/system/cpu/usage, where one generator periodically sends CPU usage. On the other hand, there may be many subscribers, or there may be no subscribers at all, depending primarily on the interest of the Subscriber. The Publish/Subscribe event-driven solution implements the Publish/Subscribe mode. Event generators publish events in the processing software, and event consumers receive events through subscriptions. The way in which event consumers subscribe depends on the software. In a messaging application, an event consumer can subscribe to a channel (for example, you can also apply a filter rule on an event type). When using CEP (such as Esper), you can use a SQL class request to implement subscriptions to define events of interest to you.

Why use event-driven solutions?

In a traditional communication scenario, if system A requires information from System B, it sends a request to system B. System B will process the request, and system A will wait for the response. When processing is complete, the response is sent back to system A. In synchronous communication mode, resource usage is less efficient because it wastes processing time waiting for a response.

In asynchronous mode, System A subscribes to the information it wants to obtain from system B. System A can then send a notification to system B, or it can return information immediately, while system a can handle other transactions. This step is optional. In an event-driven application, you typically do not have to request other systems to send events because you do not know what these events are. After system B publishes the response, System A receives the response immediately.

One benefit of the event-driven architecture is that it allows for better scalability. Scalability is the ability of a system to achieve a goal while adapting to changes in demand, volume, and intensity. By eliminating pause time, the event-driven architecture has better performance and higher processing ratios.

Another benefit is application development and maintenance. When using event-driven solutions, each application component can remove coupling and be completely independent.

Due to reduced communication latency, event-driven solutions can respond within a shorter period of time.