Building event-driven frameworks with Apache Geronimo and JMS

Defining event types with Java reflection

Responding to real-time changes and events occurs as an important requirement for the enterprise framework. This article describes the techniques and mechanisms used in the Apache Geronimo framework that enable applications and services to respond effectively to real-time stimuli and then send and receive events across the architecture virtual layer.

Developers are having trouble designing and building dynamic workflows and integration systems using traditional sequential processing methods, so there is an urgent need for more appropriate, event-aware technologies and tools. SOA and event-driven programming can solve this complex problem.

SOA gives a loosely coupled development model and runtime environment. It enables service providers and service consumers to build interactive models using dynamic component interactions that take advantage of the development model's flexibility and power. Event-driven interaction models respond more promptly to dynamic events than traditional synchronization mechanisms, in part because event-driven programming in SOA leverages many of the same characteristics that distributed systems themselves require, including specialization, modularity, and adaptability.

Event-Driven schemas

In the 2003, Gartner Group introduced event-driven architecture (EDA) as a way to build systems, services, and applications in which events were routed between loosely coupled event receivers. Event-driven systems consist of event producers and event receivers. Event producers can publish events to the event channel, which can distribute the event to the recipient of the subscription event. As with producer publishing events, the event channel forwards events to the recipient. If no recipients are available, the event channel stores the event and forwards it to the recipient that is available later. This process is called storage and forwarding.

EDA uses the concept of passing messages as a means of interacting between two or more entities. Initiates an interaction by triggering signals and messages that correspond to certain business domain events. When each given event occurs, all subscribers to the event are notified. The subscriber can then take action on the event.

EDA benefits from the following attributes:

Non-coupling associations: Event Publishers and event subscribers do not need to know each other's existence beforehand.

Many-to-many Interaction: One or more events affect one or more subscribers.

event-based Control Process: The application process is natural when the application responds to events that occur.

Asynchronous messaging: Business logic can occur concurrently with the event.

By building applications and systems around EDA, you can build them in a more responsive way because, by design, event-driven systems are more adaptable to unpredictable and constantly changing environments.

The benefits of event-driven design and development

Event-driven programming has many advantages. For example, this type of programming can:

Reduce the complexity of developing and maintaining distributed systems.

Makes it easier and less costly to assemble and configure applications and services.

Facilitates the reuse of source code and components, reducing bugs and facilitating agile development and deployment.

In the short term, event-driven design and development allow for faster, easier customization. In the long run, the system state is more precise.

Integration of EDA and SOA

Unlike a sequential or procedural system in which a client must poll for a change request, EDA allows the system and components to respond dynamically in real time when an event occurs. EDA makes up for the lack of SOA by introducing long running processing capabilities. Because event consumers receive events when events occur and they invoke loosely coupled services to provide more timely and accurate data to customers, they are beneficial to the business.

Within EDA, you can transfer events across various segments of the SOA, including the physical layer and the virtual layer of the architecture, so that the system can respond effectively. Figure 1 illustrates the events propagated across the hierarchy stack.

Figure 1. Spread across the virtual layer