Enterprise Integration Patterns

1 Enterprise Integration PatternsAsynchronous Messaging Architecturesin PracticeTest MessageSplitterEnricherTranslatorAggrega torGregor Hohpe2 Copyright 2003 Gregor HohpeEnterprise Integration PatternsIntegration Challenges Users want to execute business functions that span multiple applications Requires disparate applications to be connected to a common Integration solution However: Networks are slow Networks are unreliable No two applications are alike Change is InevitableIsolated SystemsUnified Access3 Copyright 2003 Gregor HohpeEnterprise Integration PatternsMessage-Oriented MiddlewareMessage-oriented architectures provide loose couplingand reliabilitySystemASystemASystemBSystemBC hannelMessage Remove location dependencies Remove temporal dependencies Remove data format dependencies Channels are separate from applications Channels are asynchronous & reliable Data is exchanged in self-contained

2 Messages4 Copyright 2003 Gregor HohpeEnterprise Integration PatternsThinking AsynchronouslyOrder MgmtShippingOrder MgmtShippingInventoryInventoryWeb SiteWeb SiteNew OrderNew OrderConfirmNew OrderConfirmIdleNew OrderConfirmConfirmSynchronousAsynchrono us5 Copyright 2003 Gregor HohpeEnterprise Integration PatternsMany Products & Implementations Message-oriented middleware (MOM) IBM WebSphere MQ Microsoft MSMQ Java Message Service (JMS) Implementations EAI Suites TIBCO, WebMethods, SeeBeyond, Vitria, .. Asynchronous Web services WS-ReliableMessaging, ebMS Sun s Java API for XML Messaging (JAXM) Microsoft s Web Services Extensions (WSE)HOTHOTThe Underlying Design Principles Are the Same!

3 6 Copyright 2003 Gregor HohpeEnterprise Integration PatternsCatalog of 65 PatternsMessageConstructionMessagingChan nelsApplicationAApplicationBMessageChann elRouterTranslatorEndpointEndpointMonito ringMessagingEndpointsMessageRoutingMess ageTransformationSystemsManagementComman d MessageRPC MessageQuery MessageDocument MessageEvent MessageReply MessageReturn AddressCorrelation IdentifierMessage SequenceMessage ExpirationCanonical Data ModelFormat IndicatorPoint-to-Point ChannelPublish-Subcr. ChannelDurable SubscriberDatatype ChannelInvalid Message ChannelDead Letter ChannelGuaranteed MessagingChannel AdapterContent-Based RouterMessage FilterRecipient ListSplitterAggregatorResequencerDistrib ution w.

4 Aggr. TableProcessManagerData EnricherContent FilterCheck LuggageControl BusMessage HeaderEnvelope WrapperMessage HistoryMessage StoreChannel PurgerTest MessageMessaging AdapterPolling ConsumerEvent-Driven ConsumerTransactional ClientCompeting ConsumersMessage DispatcherMessage SelectorIdempotent ReceiverMessaging Mapper1. Request-ReplyExample2. Order ManagementExample3. Bonus7 Copyright 2003 Gregor HohpeEnterprise Integration PatternsPattern: Request-ReplyConsumerProviderRequest Service Provider and Consumer (similar to RPC) Channels are unidirectional Two asynchronous Point-To-Point Channels Separate request and reply messagesRequest ChannelReply ChannelReply8 Copyright 2003 Gregor HohpeEnterprise Integration PatternsMultiple Consumers ProviderRequestsRequestsRequest ChannelConsumer1 Consumer1?

5 ?Reply Channel 1 Consumer2 Consumer2 Reply Channel 2 Replies Each consumer has its own reply queue How does the provider know where to send the reply? Could send to all consumers very inefficient Hard code violates principle of context-free service9 Copyright 2003 Gregor HohpeEnterprise Integration PatternsPattern: Return AddressConsumer1 Consumer1 RepliesConsumer2 Consumer2 Request ChannelReply Channel 1 Reply Channel 2 Consumer specifies Return Address(reply channel) in the request message Service provider sends reply message to specified channelReplyChannel 1 ReplyChannel 2 Provider10 Copyright 2003 Gregor HohpeEnterprise Integration PatternsMultiple Service ProvidersProvider 1 Provider 1 ConsumerConsumerProvider 2 Provider 2 Request ChannelReply Channel Request message can be consumed by more than one service provider Point-to-PointChannelsupports Competing Consumers.

6 Only one service receives each request message Channel queues up pending requests11 Copyright 2003 Gregor HohpeEnterprise Integration PatternsMultiple Service ProvidersReply 1 Reply messages get out of sequence How to match request and reply messages? Only send one request at a time very inefficient Rely on natural order bad assumptionService 1(slow)Request 1 Service 2(fast)ConsumerRequest 2 Reply 212 Copyright 2003 Gregor HohpeEnterprise Integration PatternsPattern: Correlation IdentifierMessageIdentifier12 Provider 1 Provider 1 Provider 2 Provider 2 Request ChannelResponse Channel1212121212 CorrelationIdentifierCorrelateRequest & ReplyConsumer Equip each message with a unique identifier Message ID (simple, but has limitations) GUID (Globally Unique ID) Business key ( Order ID) Provider copies the ID to the reply message Consumer can match request and response13 Copyright 2003 Gregor HohpeEnterprise Integration PatternsPattern.

7 Pipes-And-FiltersPipe Connect individual processing steps (filters) with message channels (pipes) Pipes decouple sender and receiver Participants are unaware of intermediaries Compose Patterns into larger solutionsIncomingOrderAuthenticateAuthen ticateDecryptDecryptDe-DupDe-DupPipePipe PipeFilterFilterFilter Clean Order14 Copyright 2003 Gregor HohpeEnterprise Integration PatternsMultiple Specialized ProvidersOrderMessagesWidget Inv. Each provider can only handle specific type of message Route request to the appropriate provider based on the content of the request message Do not want to burden sender with decision (decoupling) Letting each consumer pick out desired messages requires distributed coordination15 Copyright 2003 Gregor HohpeEnterprise Integration PatternsPattern: Content-Based RouterOrderMessagesWidget Inv.

8 Insert a Content-Based Router Message routers forward incoming messages to different output channels Message content not changed Mostly stateless, but can be stateful( de-duper)OrderEntryOrderEntryContent-Bas edRouter16 Copyright 2003 Gregor HohpeEnterprise Integration PatternsComposite MessageOrderMessageWidget Inv. How can we process a message if it contains multiple elements, each of which may have to be processed in a different way? Treat each element independently Need to avoid missing or duplicate elements Make efficient use of network resourcesOrderEntryOrderEntry?

9 ?Gadget 2003 Gregor HohpeEnterprise Integration PatternsPattern: SplitterOrderMessageWidget Inv. Use a Splitter to break out the composite message into a series of individual messages, each containing data related to one 1 OrderItem 2??SplitterGadget 2003 Gregor HohpeEnterprise Integration PatternsComposite: Splitter & RouterOrderMessageOrderItem 1 Widget Inv. Use a Splitter to break out the composite message into a series of individual messages, each containing data related to one item. Then use a Content-Based Router to route the individual messages to the proper destinationOrderEntryOrderEntryOrderItem 1 OrderItem 2 SplitterGadget 219 Copyright 2003 Gregor HohpeEnterprise Integration PatternsProducing a Single ResponseWidget 1 OrderItem 2 Response 1 Response 2?

10 ?ConfirmedOrderBillingBilling How to combine the results of individual, but related messages so that they can be processed as a whole? Messages out of order Message delayed Which messages are related? Avoid separate channel for each system20 Copyright 2003 Gregor HohpeEnterprise Integration PatternsPattern: AggregatorOrderItem 1 Response 1 ConfirmedOrderWidget Inv. Use a statefulfilter, an Aggregator, to collect and store individual messages until a complete set of related messages has been received. Aggregator publishes a single message distilled from the individual messages.