C8: Enterprise Integration Patterns in Sonic ™ ESB Stefano Picozzi Solutions Architect

© 2008 Progress Software Corporation 2 Agenda  Enterprise Integration Patterns  Sonic ESB “built in” patterns  Using patterns in Sonic workbench Enterprise Integration Patterns in Sonic ESB

© 2008 Progress Software Corporation 3 What are Design Patterns?  Repeatable solution to a software design problem  Design “template”  Relationships & interactions between classes and/or objects  Situation dependent, must be adapted  Not all patterns are “design” patterns Architectural pattern Code pattern

© 2008 Progress Software Corporation 4 Benefits  Accelerates the development process  Tested & proven approaches  Familiar to developers  Provides a lexicon, facilitates communication  Basis for standards and documentation

© 2008 Progress Software Corporation 5 Finding Patterns

© 2008 Progress Software Corporation 6  60+ Patterns  600+ Pages  Icon language One potential source

© 2008 Progress Software Corporation 7 Agenda  Enterprise Integration Patterns  Sonic ESB “built in” patterns  Using patterns in Sonic workbench Enterprise Integration Patterns in Sonic ESB

© 2008 Progress Software Corporation 8 Message Bus pattern “What is an architecture that enables separate applications to work together, but in a decoupled fashion such that applications can be easily added or removed without affecting the others?” (

© 2008 Progress Software Corporation 9 Message Bus pattern “An enterprise contains several existing systems that must be able to share data and operate in a unified manner in response to a set of common business requests.”

© 2008 Progress Software Corporation 10 Control Bus pattern “How can we effectively administer a messaging system that is distributed across multiple platforms and a wide geographic area?” (

© 2008 Progress Software Corporation 11 “Use a Control Bus to manage an enterprise integration system. The Control Bus uses the same messaging mechanism used by the application data, but uses separate channels to transmit data that is relevant to the management of components involved in the message flow.” Control Bus pattern

© 2008 Progress Software Corporation 12 Guaranteed Delivery pattern “How can the sender make sure that a message will be delivered, even if the messaging system fails?” (

© 2008 Progress Software Corporation 13 Guaranteed Delivery pattern “Use Guaranteed Delivery to make messages persistent so that they are not lost even if the messaging system crashes.”

© 2008 Progress Software Corporation 14 Agenda  Enterprise Integration Patterns  Sonic ESB “built in” patterns  Using patterns in Sonic workbench Enterprise Integration Patterns in Sonic ESB

© 2008 Progress Software Corporation 15 CBR pattern “The Content-Based Router examines the message content and routes the message onto a different channel based on data contained in the message. The routing can be based on a number of criteria such as existence of fields, specific field values etc.” ( Router.html) Router.html

© 2008 Progress Software Corporation 16 CBR pattern  Incoming message routed to exactly one destination based on the content of the message

© 2008 Progress Software Corporation 17 CBR pattern implementation  Standard ESB Content Based Routing service xcbr rules file –Routed to first rule that matches

© 2008 Progress Software Corporation 18 Recipient List pattern “The logic embedded in a Recipient List can be pictured as two separate parts even though the implementation is often coupled together. The first part computes a list of recipients. The second part simply traverses the list and sends a copy of the received message to each recipient.” (

© 2008 Progress Software Corporation 19 Recipient List pattern  Incoming message routed to one or more destinations based on the content of the message

© 2008 Progress Software Corporation 20 Recipient List pattern implementation  Standard ESB Content Based Routing service xcbr rules file –Routed to all rules that match

© 2008 Progress Software Corporation 21 Detour pattern “The Detour uses a simple context-based router with two output channels. One output channel passes the unmodified message to the original destination. When instructed by the Control Bus, the Detour routes messages to a different channel. This channel sends the message to additional components that can inspect and/or modify the message. Ultimately, these components route the message to the same destination.” ( Bushttp://integrationpatterns.com/Detour.html

© 2008 Progress Software Corporation 22 Detour pattern  Incoming message routed to particular destination, but might have to go through some extra steps before it is routed to that destination

© 2008 Progress Software Corporation 23 Detour pattern implementation  Standard ESB Content Based Routing service xcbr rules file –Routed to first rule that matches –Default Destination is “pass through” branch

© 2008 Progress Software Corporation 24 Wire tap pattern “The Wire Tap is a fixed Recipient List with two output channels. It consumes messages off the input channel and publishes the unmodified message to both output channels. To insert the Wire Tap into a channel, you need to create an additional channel and change the destination receiver to consume of the second channel. Because the analysis logic is located inside a second component, we can insert a generic Wire Tap into any channel without any danger of modifying the primary channel behavior. This improves reuse and reduces the risk of instrumenting an existing solution.” ( Listhttp://integrationpatterns.com/WireTap.html

© 2008 Progress Software Corporation 25 Wire tap pattern  Send a copy of an incoming message to another process without changing the original message or its destination

© 2008 Progress Software Corporation 26 Wire tap pattern implementation  Standard ESB Content Based Routing service Delete decision branch xcbr rules file –Routed to all rules that match –Always route to DEFAULT –Conditionally route to wiretap destination

© 2008 Progress Software Corporation 27 Message Filter pattern “The Message Filter has only a single output channel. If the message content matches the criteria specified by the Message Filter, the message is routed to the output channel. If the message content does not match the criteria, the message is discarded.” (

© 2008 Progress Software Corporation 28 Message Filter pattern  Incoming message should either be routed to its destination or be discarded

© 2008 Progress Software Corporation 29 Message Filter pattern implementation  Standard ESB Content Based Routing service Delete decision branch xcbr rules file –Rule to route to destination –Default destination NULL

© 2008 Progress Software Corporation 30  Transformation service  Database service  PSDN Other default services to build patterns

© 2008 Progress Software Corporation 31 Other Integration Patterns Routing Pipes and Filters/Routing Slip Content Based Router Splitter Transformation Canonical Data Model Envelope Wrapper Content Enricher Interaction Models Produce Fire and Forget Request-Reply Async Request-Reply Bulk Read Operate/Aggregate/Correlate Cache Claim Check Process Manager System Interaction Adapter Emitter Bridges Messaging Application Server (SSB or Servlet) Interaction Models Consume Event Driven Consumer Selective Consumer Polling Consumer Replier Bulk Load System Interaction Adapter Requestor/Sender Bridges Messaging Application Server (MDB) Resequencer Gather

© 2008 Progress Software Corporation 32 Relevant Exchange Sessions  C3: Introduction to the Progress SOA Portfolio  C4: Common Applications of Sonic ESB

© 2008 Progress Software Corporation 33 Questions ?

© 2008 Progress Software Corporation 34 Thank You

© 2008 Progress Software Corporation 35