EAI Patterns with Actor Model: Aggregator

The Recipient List example didn’t demonstrate how the PriceQuote replies are assimilated by the MountaineeringSuppliesOrderProcessor. To correlate PriceQuote replies to the original RequestForQuotation we need to use the unique rfqId that has been passed along with each message:

orderProcessor ! RequestForQuotation("123", ...)
...
recipient ! RequestPriceQuote(rfq.rfqId, ...)
...
sender ! PriceQuote(rpq.rfqId, ...)

The previous example from Recipient List is extended here to include an Aggregator, which tracks the fulfillment of all requested price quotes. First note the new message types:

case class PriceQuoteFulFilled(priceQuote: PriceQuote)

case class RequiredPriceQuotesForFulfillment(rfqId: String, quotesRequested: Int)

case class QuotationFulfillment(rfqId: String, quotesRequested: Int, priceQuotes: Seq[PriceQuote], requester: ActorRef)
. . .

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: Recipient List

We’ve looked at a few different kinds of Content-Based Routers, and Recipient List is yet another. A Recipient List is compared to the To: and Cc: fields in an email message, where you specify any number of intended recipients of the email message. Thus, a Recipient List may be predetermined depending on the kind of message being sent. Yet, it is also possible for a Recipient List to take on the characteristics of a Dynamic Router in that the recipients may be determined by some set of business rules.

The example provided here performs price quoting. When the MountaineeringSuppliesOrderProcessor receives a RequestForQuotation message, it calculates a Recipient List based on a set of business rules, which means it is a kind of Dynamic Router.

. . .

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: Routing Slip

Use a Routing Slip when a large business procedure logically does one thing but physically requires a series of processing steps. This achieves a service composition commonly recognized as SOA. In our Routing Slip process, each step is handled by an individual Actor. The process of this example is customer registration, as described by [Hohpe & Woolf], which includes the following steps:

  • Create a new customer
  • Record the customer’s contact information
  • Request a service plan for the customer
  • Run a credit check for the new customer

First let’s look at the top of RoutingSlip.scala and the Value Objects that comprise the data body of the registration 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: 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.