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

C8: Enterprise Integration Patterns in Sonic™ ESB

Stefano PicozziSolutions Architect

© 2008 Progress Software Corporation2

Agenda

Enterprise Integration Patterns Sonic ESB “built in” patterns Using patterns in Sonic workbench

Enterprise Integration Patterns in Sonic ESB


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


Benefits

Accelerates the development process Tested & proven approaches Familiar to developers Provides a lexicon, facilitates communication Basis for standards and documentation


Finding Patterns


60+ Patterns

600+ Pages

Icon language

One potential source

http://www.enterpriseintegrationpatterns.com/


Agenda




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?”

(http://integrationpatterns.com/MessageBus.html)


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.”


Control Bus pattern

“How can we effectively administer a messaging system that is distributed across multiple platforms and a wide geographic area?”

(http://integrationpatterns.com/ControlBus.html)


“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


Guaranteed Delivery pattern

“How can the sender make sure that a message will be delivered, even if the messaging system fails?”

(http://integrationpatterns.com/MessageBus.html)


Guaranteed Delivery pattern

“Use Guaranteed Delivery to make messages persistent so that they are not lost even if the messaging system crashes.”


Agenda




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.”

(http://integrationpatterns.com/ContentBasedRouter.html)


CBR pattern

Incoming message routed to exactly one destination based on the content of the message


CBR pattern implementation

Standard ESB Content Based Routing service• xcbr rules file

– Routed to first rule that matches


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.”

(http://integrationpatterns.com/RecipientList.html)


Recipient List pattern

Incoming message routed to one or more destinations based on the content of the message


Recipient List pattern implementation


– Routed to all rules that match


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.” (http://integrationpatterns.com/Detour.html)


Detour pattern

Incoming message routed to particular destination, but might have to go through some extra steps before it is routed to that destination


Detour pattern implementation


– Routed to first rule that matches– Default Destination is “pass through” branch


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.” (http://integrationpatterns.com/WireTap.html)


Wire tap pattern

Send a copy of an incoming message to another process without changing the original message or its destination


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


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.”

(http://integrationpatterns.com/Filter.html)


Message Filter pattern

Incoming message should either be routed to its destination or be discarded


Message Filter pattern implementation

Standard ESB Content Based Routing service• Delete decision branch

• xcbr rules file– Rule to route to destination– Default destination NULL


Transformation service Database service PSDN

Other default services to build patterns


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


Relevant Exchange Sessions

C3: Introduction to the Progress SOA Portfolio

C4: Common Applications of Sonic ESB


Questions?


Thank You

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

Documents

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