EAI Patterns with Actor Model: Dynamic Router

You may have become a bit bored with the previously discussed routing patterns, Splitter and Content-Based Router. It’s not that they aren’t necessary or useful. They absolutely are. But they are also sort of simple and much like each other, with only slight differences in the way they route messages. Sure, in an actual project we would always face additional challenges with the implementations. Still, it’s nice to move on to the more advanced Dynamic Router.

With this router there are several moving parts, and anything that’s dynamic is always more fun to code and discuss. Besides, it uses rules, and rules have a sort of intrigue about them. The rules aren’t that complex, but it’s an improvement over those observed in Splitter and Content-Based Router.

To receive messages from a Dynamic Router an Actor must register interest in a given message. With the most basic of registration processes an Actor would tell a Dynamic Router that it is interested in a specific type of message. Or there could be more elaborate rules that require the Dynamic Router to perform a multi-level look up to resolve the Actor to receive a given message.

. . .

The full text is now available as part of my book Reactive Enterprise with Actor Model on Safari Books Online.

EAI Patterns with Actor Model: Content-Based Router

As noted in my discussion on Splitter, a Content-Based Router has a different motivation. While both of these router types are designed to route a message based on message content, the Content-Based Router doesn’t break up the composite parts of one message into multiple messages as does a Splitter. Rather, it routes the whole message based on some message content analysis.

The example used by the Enterprise Integration Patterns is an Order System that must route each Order to the Inventory System to check on Order Item availability. This assumes that a given Order has only those Order Items that are kept by one of two or more Inventory Systems. If, on the other hand, a single Order can have multiple Order Items each potentially kept by a different Inventory System, you’d need to use a Splitter to check on availability.

. . .

The full text is now available as part of my book Reactive Enterprise with Actor Model on Safari Books Online.

EAI Patterns with Actor Model: Splitter

There are various ways to route messages, including Content-Based Router, Dynamic Router, Recipient List, Splitter, Aggregator, Scatter-Gather, Routing Slip, and Process Manager. In time we will take a look at each of these. For now let’s discuss Splitter.

Use Splitter when a large composite message must be separated into its individual parts and sent as smaller messages. The Splitter might be considered similar to the Content-Based Router because it is the part content of the message that determines how parts are routed. However, Content-Based Router is primarily concerned with routing the whole message to a specific subsystem based on the overarching message type. On the other hand, with Splitter we are more concerned with routing individual parts of a single composite message to separate subsystems.

Here’s an example of splitting an OrderPlaced message into separate Type[?]ItemOrdered messages:

. . .

The full text is now available as part of my book Reactive Enterprise with Actor Model on Safari Books Online.

EAI Patterns with Actor Model: Content Filter

With Envelope Wrapper we already dealt with the situation where an external message is incompatible with our local Actor System. We used to Envelope to both adapt the external message to one locally acceptable, and we also designed the Envelope to reply to the originating external system. This made dealing with the external messaging system, and the message itself, seamless. Further, we used a Content Enricher to augment our local message with more information needed by an external system before the message is sent to it.

There are times, however, when a message could contain too much information, or for other reasons be difficult to consume. Consider some cases:

  • Data may be easily obtained from a database when local application-specific queries are employed. Yet, the rich amount of data may be too sensitive to send to outside systems.
  • The local application data that is queried may also be too large to be practical to send over the network, and most of it may not be necessary for most consumers, even local Actors.
  • Not only the amount of data, but also its structure, may be too complex for it to be practical to consume by some local Actors or remote systems.

For these situations, use a Content Filter. It might be enough to use a single Filter to reduce the size and complexity of the information passed in a given message. On the other hand, it may be necessary to design a Splitter to break one large data structure into several smaller message types.

. . .

The full text is now available as part of my book Reactive Enterprise with Actor Model on Safari Books Online.

EAI Patterns with Actor Model: Content Enricher

With the Envelope Wrapper an incompatible message from an external system is made compatible with our Actor System. Yet, the opposite situation may be true; a message that the local Actor System needs to send is not compatible with an external system because the external system needs more content than the local system stores. What is more, the external system cannot or should not retrieve the extra information it requires. This situation can be resolved by using a Content Enricher.

The basic solution put forth by [Hohpe & Woolf] uses another component—in our case, an Actor—to enrich the content of the message before it is sent on to the external system, such that the message will contain all the content needed by that system once it is delivered.

. . .

The full text is now available as part of my book Reactive Enterprise with Actor Model on Safari Books Online.

EAI Patterns with Actor Model: Envelope Wrapper

We’ve discussed a few different ways to use Return Address with the Actor Model, which allows a message-receiving Actor to reply to an Actor other than the direct sender or forwarder of the message. Sometimes, however, it might work out for the best if your messages themselves support the means to dispatch to a reply-to Actor. This can be accomplished if a message has an Envelope Wrapper.

Often times an Envelope Wrapper is used when there are multiple transport layers, or when a message must be tunneled through to a network other than the one on which it originated. Generally speaking, a message that is produced by an Actor System such as Akka will not need an Envelope for those reasons, or the Actor System itself may provide the needed transport-specific Envelope. Yet, there may be other reasons for Actors in a given Actor System to use an Envelope.

. . .

The full text is now available as part of my book Reactive Enterprise with Actor Model on Safari Books Online.

EAI Patterns with Actor Model: Return Address

Since you understand how to implement a Request-Reply using Actor Model, what if you want your Request receiver to Reply to an Actor at an Address other than the direct message sender? Well, that’s the idea behind the Return Address pattern, and one that we can implement in a few different ways.

It’s interesting that the Actor Model actually uses Addresses to identify how to send messages to Actors. You see, each Actor has an Address, and in order to send a given Actor a message you must know its Address. One Actor can know the Address of another Actor by a few different means:

  • An Actor creates another Actor, and thus knows the Address of the Actors it has created
  • An Actor receives a message that has the Address of one or more other Actors that it will send messages to
  • In some cases an Actor may be able to look up the Address of another Actor by name, but this may create an unseemly binding to the definition and implementation of a given Actor

Anyway, the Return Address EAI Pattern name fits really well with the fundamental ideas behind Actor Model.

. . .

The full text is now available as part of my book Reactive Enterprise with Actor Model on Safari Books Online.

EAI Patterns with Actor Model: Request-Reply

This is the first in a series of simple posts about using Actor Model to implement the EAI Patterns. The patterns are from the book Enterprise Integration Patterns, by Gregor Hohpe and Bobby Woolf. Information about the book and the patterns are found at the previously referenced link.

When I say Actor Model I am not discussing the general use of messaging, as in Pub-Sub or Queues, or a SOAP request for that matter. Of course ultimately you can use the Actor Model in that way, and you can find enough similarities to prove that using those approaches to service design and implementation qualifies them as Actor Model. In fact, even Carl Hewitt explains that you can model email systems and Web service endpoints as Actor systems.

On the other hand, some toolkits bring you much closer to the use of Actor Model as originally specified by Carl Hewitt and his team. This is the use of Actor Model that I am emphasizing, and the specific toolkits I am using are those that support Actor Model in that way. So I will be talking about Akka and my own Actor Model toolkit. Actors as supported by such an Actor Model toolkit will have the following basic characteristics:

  • Communication via Direct Asynchronous Messaging
  • Lock Free Concurrency
  • Share Nothing
  • Futures/Promises
  • Supervision
  • Parallelism (yes, even the potential for Parallelism)

This post is about Request-Reply. It’s quite simple and straightforward to implement using Actor Model.

. . .

The full text is now available as part of my book Reactive Enterprise with Actor Model on Safari Books Online.