Trabajo Con Eventos En Jwebsocket

Events 10

Event model in a WebSocket network

“Event model” is about “server-side programming fully based on events”, more specifically a server-side environment guided by the observer pattern, in this chapter we will be talking about subjects, listeners and events.

"In computer programming, event-driven programming or event-based programming is a programming paradigm in which the flow ofthe program is determined by events—i.e., sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads. Event-driven programming can also be defined as an application architecture technique in which the application has a main loop which is clearly divided down to two sections: the first is event selection (or event detection), and the second is eventhandling..."[1]

Event-driven programming is highly used in building graphical user interfaces, we are all familiarized with the OnEnter event, OnMouseMove, OnKeyPress, etc... The Observer Pattern has been tested over years on desktop and web applications and now, everybody knows about its benefits.
jWebSocket is a framework to build applications following the client/server architecture. Different tothe common MVC web frameworks, with jWebSocket the client requires to be constructed separately by using JavaScript or other language, offering to our clients the desktop-like appearance.

After this brief introduction, let's see the “Event model” intention:
“Offers support for a client or server side (bi-directional) event notification as transparent as possible, simulating that we still in thesame side (client or server). In fact it removes the MVC design by other more flexible and faster: just one observable components environment for both sides.”

How it works?
The Event model in jWebSocket is handled by the EventsPlugIn, that is in fact a TokenPlugIn with a totally different behavior. When the EventsPlugIn receive a token, a new C2SEvent is generated according to the token type,for example a token with type “auth.logon” is mapped to “Logon” event class, wrapping the token in a new Logon event object, after that, the filter chain is executed by first time, next interested listeners are notified of the Logon event, once the listeners has been finished the filter chain is executed by second time and the events work-flow finish.

Illustration 1: Events work-flow

The maindifferences with the current jWebSocket token level environment are:
Based on an event-driven model by using the observable pattern.
The filters are focused on support aspects related to events notifications, are executed in chain before and after every C2S event notification.
Plug-ins offer support to related events in the server side, using different method signatures and not only the“processToken” method.
Example:
public void processEvent(Logon aEvent, C2SResponseEvent aResponseEvent);
public void processEvent(Logoff aEvent, C2SResponseEvent aResponseEvent);
New client layer (JavaScript only already) for integration with the server-side.
Spring framework[2] integration.

Observable/Observer Pattern

The Observable pattern defines one-to-manydependency between objects, so when the object changes its state, all its listeners are notified automatically. Solve the need to maintain consistency between related objects without making classes tightly coupled. Generally guarantee clean implementations, high flexibility and less dependency between objects.
The principal disadvantage is the memory and processor consumption in systems with a lotof listeners.

The Observer Pattern implementation in the EventsPlugIn is done using a FastMap, so the access to the listeners is very quick. Consider every listener loaded in memory and ready to use in terms of “time needed to get a response” versus the classic way for RPC calls where the classes must be loaded, instances created, many other checks needed to execute the targeted method,...