Architecture

Variants of SEDA

17th April 2016 Architecture, EDA, JMS, Uncategorised No comments

SEDA (Staged Event Driven Architecture) was described in Ph.D. thesis of Matt Welsh. I recently read his blog post that describes various ways SEDA was perceived and implemented . One thing that comes to my mind after reading this is that SEDA as a tool has been used in more or less correct ways, as many other patterns and architecture models.

Because SEDA is a design model and architecture pattern, one that can be used with other models like SOA. In fact some ESB’a use SEDA as a processing model, like Mule ESB or ServiceMix. SEDA is one of a few processing models in ServiceMix. But SEDA can be used elsewhere, like with Oracle Service Bus. And in more that one way:

  1. SEDA using messaging – here we would add a queue before service that consumes event messages possibly using SOAP/JMS binding. We can that add additional stages for events processed by this first service.
  2. Throttling capabilities of OSB – here we do not have a real thread pool but using WebLogic’s Work Managers we achieve similar goal, threads will be taken from WebLogic thread pool. This processing model will work with every routing action

I also used a variant of the first model, where services were exposed as SOAP/HTTP services and they published a messages on a queue and then send reply that message has been queued. This way we can still used SOAP/HTTP messages, not forcing other systems to use messaging – either JMS, AMQP, STOMP or some other.

When done right SEDA will improve system’s scalability an extensibility. Scalability is higher because if a peak of messages happens than it will be queued up to the limit of storage quota. Messages that can’t be processed when arriving at a queue will wait for their turn. With addition of reliable messaging like JMS persistent delivery with exactly-once guarantee we can have scalable and reliable message processing mechanism. Adding additional queues depends on requirements of specif domain or application. It may be viable to add queues not only because of scalability but also from extensibility point of view. We would use topics here of publish event to multiple queues but the main point is that it would me possible and quite easy to add additional event consumer in this model.

SEDA may be also good for asynchronous request processing with long processing times with addition of NIO2 and Servlet 3.x asynchronous processing model. In this case we would accept request at some endpoint like Spring controller method and then invoke asynchronous method to do backend processing. HTTP could process another request for another potentially synchronous endpoint. Backend processing service would process incoming requests and invoke completion handlers as it finishes (using Spring infrastructure).  Here we would have at least two queues – HTTP thread queue and backend processing service queue. Both could be managed and adjusted to add higher scalability.

When considering SEDA it is important co remember that request processing will be lower that with processing with one thread and no queues on the way. This is quite obvious, as dispatching, consuming, confirming event message has it’s performance impact. SEDA can also impact system’s maintainability as event messages may get stuck in some queues or get redirected to dead letter queues and this must be monitored. Fortunately it is not a big problems, especially on OSB (we can use alerts) .

SEDA can be used incorrectly, just like EDA, CEP or SOA.  Once again architecture design is probably the most important thing in system’s development.

Have a nice day !

EDA in Java EE 7

3rd April 2016 EDA, Java EE, JMS, Software development 1 comment

Building EDA in Java EE 7 or Spring is easy. Let’s create a simple EDA routing example using JMS 2.0, EJB 3.2 and CDI 2.0. We will focus on messaging part, so we will not use anything fancy to route messages. We will publish messages to a single queue – the event channel. Messages will be received by EDA component which will route them according to header. Message will be published to appropriate event queue based on header value and will be received by appropriate component that will monitor those queues. Example will use queues but it can be easily modified to use topics.

A few important things:

  • What is important is to keep the architecture clean an event generator must not know anything about event consumers. Event instance should be created using an EventBuilder or some other helper class so that event source passes required information and does not know anything about details of EDA event construction.
  • Event consumer that does business processing must get business information from event and trigger processing. Do not implement business code in event consumer nor propagate EDA related details down to domain services layer.
  • It is important to do routing based on header if possible, as it is more lightweight.
  • Use appropriate session mode (transacted or no, with required AcknowledgementMode)
  • Remember that messages can and will arrive out of order
  • Use one or a few Dead Letter Queues, sent messages that failed to be processed a few time to related DLQ. Example code does not do this

EDA - simple routing

 

Publishing message using EJB is super easy:

Important parts are discussed below.

Creating JMSContext that manages JMS Session and ConnectionFactory for us. This must NOT be created in session transacted mode in order for it to join JTA transaction. There are cases where we want to manage transactions our selves or send message whether or not other parts of request processing failed. In those cases we could use separate transaction (e.g. by setting TransactioAttribute to REQUIRES_NEW  in CMT model or JTA 1.2 Transactional annotation) or we could create a transacted session and commit local JMS transaction in publisher code. In most cases we want to publish events as part of some other processing in transaction, so we must join existing JTA transaction.

Thanks to AUTO_ACKNOWLEDGE mode session will not be transacted and will join existing JTA transaction. We can use this to span XA transactions if it would be required.

Creating message and setting routing header:

and finally sending message:

Event can be send fully asynchronously in Java EE. In code example above client code will block until JMS provider acknowledges message. Starting from Java EE 7 we can send message and continue processing.

Publishing a message from a CDI Bean is similar, notable detail is the use of @Transactional, a JTA 1.2 annotation that allows CDI beans to work in transaction context (but not in case of life cycle methods – here EJBs still have to be used).

Messages will be received by Message Driven Bean. One of the strengths of using MDB component is that messages are delivered asynchronously with possibility to scale MDB resource share (thread pool, component instance pool). EJB container take care of other thing that we must think of when using CDI bean like transaction management and related message acknowledgement. A lot of configuration can be done declaratively using @AnnotationConfigProperties. But I don’t intend to compare CDI with EJB here, so let’s see the code:

MDB implements MessageListener to clearly state it is a JMS MDB, as MDBs can also connect to other resource manager types. onMessage method will be invoked to process each message and each message will be processed separately, even though messages will be fetched in batches from JMS Provider. Default acknowledgment mode for MDB component is AUTO_ACKNOWLEDGE with DUPS_OK_ACKNOWLEDGE allowed to be set.

SimpleRoutingEventMessageBroker can be source of other events. How you process events is system specific. In some cases simple XML or JSON routing specifications will be sufficient, in other cases Business Rules engine will help go trigger events. CEP (Complex Event Processing) is different league.

As comment states in code above MDB component that gets messages from event channel should not take care of message processing or routing. Message processing should be executed in dedicated component so that we can use different routing strategies and component will be easier to maintain. Testing routing code separately of JMS can also be a plus – although we can test it with JMS this test will be slower than regular JUnit tests.

Event consumer implementation is similar to SimpleRoutingEventMessageBroker MDB:

Message consumer CDI component is another story – see code below:

We must receive messages manually and we can and should give a timeout for receive operation. This component is transactional also, but it must be called by some other component in order to receive messages.

We can test code above using Arquillian. In case of both publishers we will test if message is not send if an exception is thrown.

Second test is similar, so if you’re interested to check github.

In come cases it may make more sense to use lightweight integration framework like Spring Integration or Apache Camel to create internal EDA component. Most efficient tool should be used to do the job.

Have a nice day !

Is Reactive similar to Event Driven Architecture ?

21st March 2016 Architecture, Reactive, Software development No comments

Reactive is getting more and more popular. I decided to check it out, started to do some research. A thought came into my mind – is Reactive related to EDA ? If you check Reactive Manifesto then quick answer would be yes, it is. But it is more complicated than than.

What is Reactive Programming ? According to the manifesto it is a way of building systems so that they have certain characteristics:

  • responsiveness – they respond in timely manner
  • resilience – they are fault tolerant and highly available
  • elastic – I must cite Manifesto here 🙂 “The system stays responsive under varying workload.” You’ll see why
  • message driven – reactive systems use asynchronous messages to propagate information and achieve loose coupling

Some points in the manifesto are more detailed, some less – but it is a manifesto, not a tech spec. So don’t expect too much. Manifesto tells about an approach to design and development of systems though. But it is not an architecture, nor a design pattern. Maybe this Manifesto level of detail is the reason that most of the articles or presentations I came across was about Reactive approach to programming and did not touch architecture design.

Important fact about Reactive Manifesto is that it sets goals but only gives some advice in case of resilience and message orientation. I can’t help to thing about it as a… Manifesto… 🙂 I’ll get back to Reactive in a minute.

EDA (Event Driven Architecture) is well known, proven architecture used to decouple system’s modules, provide better scalability. EDA architecture is achieved when components communicate using events that are carried in messages. Important factor is that event generator, that is component that emits event, does not know anything about consumers. EDA is extremely loosely coupled.

Most common way to propagate events is to use messaging system, but EDA can be done in various ways depending on the system being developed:

  • Single instance (JVM in case of Java) processing can be implemented using CDI events, simple observer pattern implementation, asynchronous invocations.
  • Event processing with several application instances – here we would probably use some messaging technology (MOM), but we are not limited to this:
    • remote method invocations would also do
    • one-way soap web services would do
    • restful web services with asynchronous invocations

Using messaging technology like JMS (HornetQ, ActiveMQ, SonicMQ among others) or AMQP (RabbitMQ, Apache Qpid) will give us a few important benefits:

  • Reliability: both JMS and AMQP provide a few message production and consumption modes. JMS provides persistent and non-persistent delivery, durable subscriptions (subscribers will receive messages even if the weren’t listening at the time of publication), a few ackowledgement modes (allowing or not duplicate messages, exactly once guarantee is available with JTA transacted session and XA may be required).
  • Great scalability: messages can be queued and processed without being overwhelmed even in case of peak of messages a few time greater than normal processing. Message processing components can be scaled independently from other – e.g. number of threads for a given MDB component can be increased, allowing events to be consumed faster.
  • Fault tolerance: both JMS and AMQP can survive message broker crashes

EDA can have one of a few implementation types:

  • simple event processing – like in case of observer pattern implementation, some event is generated by event generator and consumed by observers
  • streaming event processing – here events are routed and processed and can be the source of other events
  • complex event processing – in this case not only current event is analyzed but also past events are taken into analysis scope, with some sophisticated event stream queries (like in Oracle CEP).

So as we can see EDA can be:

  • resilient – if done using appropriate tools that will guranteee delivery, fault tollerance, high availability
  • elastic – this is why I wanted to cite manifesto. If you do EDA using messaging system than you get elasticity. System can and will cope with peaks in events, the messages will get queued possibly spread across cluster of messagign system’s nodes. Even more – using SEDA architecture we can throtle and dynamically control throughput
  • using messaging – we can use messaging and most of the time we do
  • responsive – due to asynchronous nature of EDA system will be responsive. It will require a different style of programming though.

As you can see there are similarities between EDA and Reactive. But as I mentioned before most of the time Reactive is about how to implement details of code and does not touch architecture level. On the other hand EDA is all about architecture – it tells about components and way to connect them so they can interact.

Reactive is more about how to structure your code, get rid of some flow statements, replace pull / imperative style with push streams. Like Introduction to Reactive Programming says Reactive programming is programming with asynchronous data streams. Another nice introduction is Jonathan Worthington presentation. We must differentiate between Reactive Programming and Reactive approach to architecture.  The second one is less common.

This lets me think that EDA can be Reactive and most of the time Reactive is just more about coding your solution using streams, observables or promises.

And btw. doing EDA in simple or streaming strategy is extremely easy in Java 😉

Have a nice day !