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.

Comments

  1. Tristan Slominski says:

    This is a very interesting series of posts. I find it valuable to compare the EAI patterns you’re elaborating using actors with some pure actor patterns described by Dale Schumacher (http://apice.unibo.it/xwiki/bin/download/AGERE2012/AcceptedPapers/ageresplash2012submission3.pdf). The combination of both provides quite an actor toolbox.

    • Great, thanks for the reference. The thrust behind my posts is the matter migrating to Actor Model with familiarity. There are many, many enterprise architects and developers familiar with Enterprise Integration Patterns. They will be caught off guard if they don’t understand that the use of Actor Model with its lock-free concurrency may soon (maybe years, but soon) be one of the few practical ways to get the performance and scale needed by the next generation of applications and systems. And what better way to learn the Actor Model than with Scala and Akka? I believe it’s the direction that Java developers will need to go, and possibly the direction of choice even by C# developers looking for lock-free concurrency.

      There are efforts already in progress to teach the patterns specific to Actor Model. I want to drag the enterprise to Scala and Akka, but without a lot of kicking and screaming 🙂