Enterprise Integration Erik Doernenburg ThoughtWorks, Inc. [email protected] EMEA 2 Agenda Challenges in enterprise application development Design patterns Enterprise Integration patterns Interop technologies Conclusion & Resources EMEA 3 © Copyright ThoughtWorks, Inc.® 2005 The challenge Enterprises depend on a growing number of IT systems The systems must provide an integrated solution for the enterprise The systems must interoperate with each other Architectural trends and “waves” of technologies Changing business needs and requirements EMEA 4 © Copyright ThoughtWorks, Inc.® 2005 Finance Operator Application fax/telex app web email mail New System Existing Systems document recognition ERP ref. data Workflow items are stored on Tibco RV/CM queue Tibco Integration Manager organises workflow handles imports from document recognition handles interaction with existing ERP systems Reference data imported using linked servers EMEA 5 © Copyright ThoughtWorks, Inc.® 2005 Portfolio Management Tool Front-end uses Office 2003 code-behind technology communicates with server using WebSphere MQ queues New application Excel front-end application logic Message format defined with XSD schema technology adaptor analytics library Existing deal manager Existing messaging library Existing Application uses existing services accesses analytics library with COM bridge accesses stored deals through deal manager service accesses service bus through messaging abstraction library EMEA 6 © Copyright ThoughtWorks, Inc.® 2005 Design Patterns EMEA 7 Why design patterns? Code reuse remains difficult but… Knowledge reuse can be very valuable Patterns encapsulate knowledge of successful designs EMEA 8 © Copyright ThoughtWorks, Inc.® 2005 Using technology successfully Syntax Basic language mechanism A necessity but not a guarantee Constructs Classes, Interfaces, Inheritance, Polymorphism, etc. Helpful but not sufficient for good design Principles Separation of concerns, Dependency Injection, etc. Steer us towards a better solution Patterns Model-View-Controller, Observer, Decorator Concrete design guidance EMEA 9 © Copyright ThoughtWorks, Inc.® 2005 Patterns “Mind sized” chunk of information (Ward Cunningham) Shows a good solution to a common problem within a specific context Observed from actual experience Has a distinct name Not copy-paste ThoughtWorks collaborates with Microsoft to document design patterns for the .NET platform EMEA 10 © Copyright ThoughtWorks, Inc.® 2005 Enterprise Integration Patterns Message Routing Message Construction Endpoint Application A Messaging Endpoints Message Channel Messaging Channels Message Transformation Router Translator Endpoint Application B Monitoring System Management Gregor Hohpe defined a visual pattern language describing message-based enterprise integration solutions Pattern language comprises 65 patterns in 6 categories EMEA 12 © Copyright ThoughtWorks, Inc.® 2005 Pattern: Request-Response Consumer Request Provider Request Channel Reply Channel Response Service Consumer and Provider (similar to RPC) Channels are unidirectional Two asynchronous point-to-point channels Separate request and response messages EMEA 14 © Copyright ThoughtWorks, Inc.® 2005 Multiple consumers Consumer 1 Requests Requests Provider Request Channel Reply Channel 1 ? Reply Channel 2 Responses Consumer 2 Each consumer has its own reply queue But how does the provider send the response? Could send to all consumers (very inefficient) Hard code (violates principle of context-free service) EMEA 15 © Copyright ThoughtWorks, Inc.® 2005 Pattern: Return Address Consumer 1 Reply Channel 1 Reply Channel 2 Provider Request Channel Reply Channel 1 Reply Channel 2 Responses Consumer 2 Consumer specifies Return Address (the reply channel) in the request message Service provider sends response message to specified channel EMEA 16 © Copyright ThoughtWorks, Inc.® 2005 Load-balanced service providers Provider 1 Consumer Request Channel Provider 2 Reply Channel Request message can be handled by multiple providers Point-to-point channel supports competing services Only one service receives each request message But what if the response messages are out of order? EMEA 17 © Copyright ThoughtWorks, Inc.® 2005 Pattern: Correlation Identifier Consumer 1 2 2 1 1 2 Message Identifier Request Channel Provider 1 1 2 Provider 2 2 1 Reply Channel 2 1 Correlation Identifier Consumer assigns a unique identifier to each message Identifier can be an arbitrary ID, a GUID, a business key Provider copies the ID to the response message Consumer can match request and response EMEA 18 © Copyright ThoughtWorks, Inc.® 2005 Multiple specialised providers Order Messages Order Entry Widget Inv. ? Gadget Inv. Each provider can only handle a specific type of message Route the request to the "appropriate" provider. But how? Do not want to burden sender with decision Letting providers "pick out" messages requires coordination EMEA 20 © Copyright ThoughtWorks, Inc.® 2005 Pattern: Content-Based Router Order Messages Widget Inv. Order Entry Content Based Router Gadget Inv. Insert a content-based router Routers forward incoming messages to different channels Message content not changed Mostly stateless, but can be stateful, e.g. de-duper EMEA 21 © Copyright ThoughtWorks, Inc.® 2005 Composite messages Order Message Order Entry Widget Inv. ? Gadget Inv. How can we process a message that contains multiple elements? EMEA 22 © Copyright ThoughtWorks, Inc.® 2005 Pattern: Splitter & Router Order Message Order Item 1 Order Items Widget Inv. Order Entry Splitter Gadget Inv. Router Order Item 2 Use a splitter to break out the composite message into a series of individual messages Then use a router to route the individual messages as before Note that two patterns are composed EMEA 23 © Copyright ThoughtWorks, Inc.® 2005 Producing a single response Order Item 1 Response 1 Confirmed Order Widget Inv. ? Billing Gadget Inv. Order Item 2 Response 2 How to combine the results of individual but related messages? Messages can be out-of-order, delayed Multiple conversations can be intermixed EMEA 24 © Copyright ThoughtWorks, Inc.® 2005 Pattern: Aggregator Order Item 1 Response 1 Confirmed Order Widget Inv. Billing Gadget Inv. Order Item 2 Aggregator Response 2 Use a stateful filter, an Aggregator Collects and stores messages until a complete set has been received (completeness condition) Publishes a single message created from the individual messages (aggregation algorithm) EMEA 25 © Copyright ThoughtWorks, Inc.® 2005 Communicating with multiple parties Vendor A Quotes Vendor B Request For Quote Best Quote ? Vendor C Aggregator How to send a message to a dynamic set of recipients? And return a single response message? EMEA 26 © Copyright ThoughtWorks, Inc.® 2005 Pattern: Scatter-Gather Pub-Sub channel Vendor A Quotes Vendor B Request For Quote Best Quote Vendor C Aggregator Send message to a pub-sub channel Interested recipients subscribe to a "topic" Aggregator collects individual response messages may not wait for all quotes, only returns one quote EMEA 27 © Copyright ThoughtWorks, Inc.® 2005 Complex composition Pub-Sub channel Vendor A Quotes Vendor B Splitter Aggregator Quote request for each item Best Quote for each item Vendor C Aggregator Receive an order message Use splitter to create one message per item Send to scatter/gather which returns "best quote" message Aggregate to create quoted order message EMEA 28 © Copyright ThoughtWorks, Inc.® 2005 Interop technologies EMEA 29 Major interop technologies Resource based DB files RPC style / distributed objects RMI-IIOP (CORBA) Remoting (DCOM) in-process bridge WS Message based / document-oriented MOM WS WS-* EMEA 30 © Copyright ThoughtWorks, Inc.® 2005 Interop technology characteristics platform neutral DB/files MOM WS-* WS J2EE server .NET server in-proc RMI-IIOP (CORBA) Remoting (DCOM) bridge point-to-point routable transient messages durable message clustering server lifetimemanagement EMEA 31 © Copyright ThoughtWorks, Inc.® 2005 Messaging Channels are separate from applications Removes location dependencies Channels are asynchronous & reliable Removes temporal dependencies Data is exchanged in self-contained messages Removes data format dependencies Loosely coupled integration enables independent variation EMEA 32 © Copyright ThoughtWorks, Inc.® 2005 Why Web Services? Web services provide all benefits of messaging solution loose-coupling service oriented reliable communication Why web services? composable protocol vendor neutral suitable for access through Internet EMEA 33 © Copyright ThoughtWorks, Inc.® 2005 Web Services development Web Services are expected to become the default Messaging solution in the future WS-* standards are evolving rapidly, most important WS-Security WS-Policy WS-Addressing WS-I defines profiles, sample applications and testing tools Profiles are guidelines for using WS specifications Use Basic profile 1.1 to build interoperable solutions Further research on WS is being carried out EMEA 34 © Copyright ThoughtWorks, Inc.® 2005 Conclusion Enterprise systems are becoming more complex We have patterns to help us with the design We have technologies to implement our designs Building for interoperability and integration is key EMEA 36 © Copyright ThoughtWorks, Inc.® 2005 Recommended books Enterprise Integration Patterns Gregor Hohpe, Bobby Woolf Addison-Wesley, 2004 Integration Patterns Microsoft Patterns & Practices 2004 Patterns of Enterprise Application Architecture Martin Fowler Addison-Wesley, 2003 Enterprise Solution Patterns using Microsoft .NET Microsoft Patterns & Practices 2003 Enterprise SOA Dirk Krafzig, Karl Banke, Dirk Slama Prentice Hall, 2004 EMEA 37 © Copyright ThoughtWorks, Inc.® 2005 Please complete your session feedback form THANK YOU
© Copyright 2024