1 / 34

Enterprise Integration

Enterprise Integration. Erik Doernenburg ThoughtWorks, Inc. edoernen@thoughtworks.com. Agenda. Challenges in enterprise application development Design patterns Enterprise Integration patterns Interop technologies Conclusion & Resources. The challenge.

Antony
Download Presentation

Enterprise Integration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Enterprise Integration Erik Doernenburg ThoughtWorks, Inc. edoernen@thoughtworks.com

  2. Agenda • Challenges in enterprise application development • Design patterns • Enterprise Integration patterns • Interop technologies • Conclusion & Resources

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

  4. Finance Operator Application • 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 New System fax/telex web app email mail document recognition Existing Systems ref. data ERP

  5. Front-end uses Office 2003 code-behind technology communicates with server using WebSphere MQ queues Message format defined with XSD schema Application uses existing services accesses analytics library with COM bridge accesses stored deals through deal manager service accesses service bus through messaging abstraction library Portfolio Management Tool New application Excel front-end application logic technology adaptor Existing Existing Existing analytics library deal manager messaging library

  6. Design Patterns

  7. Why design patterns? • Code reuse remains difficult but… • Knowledge reuse can be very valuable • Patterns encapsulate knowledge of successful designs

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

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

  10. Enterprise Integration Patterns • Gregor Hohpe defined a visual pattern language describing message-based enterprise integration solutions • Pattern language comprises 65 patterns in 6 categories MessageRouting MessageConstruction MessageTransformation Endpoint Endpoint Message Router Translator Channel Application Application A B MessagingChannels MessagingEndpoints SystemManagement Monitoring

  11. Pattern: Request-Response • Service Consumer and Provider (similar to RPC) • Channels are unidirectional • Two asynchronous point-to-point channels • Separate request and response messages Consumer Provider Request Request Channel Reply Channel Response

  12. Multiple consumers • 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) Provider Requests Requests Consumer 1 Request Channel ? Reply Channel 1 Reply Channel 2 Responses Consumer 2

  13. Pattern: Return Address • Consumer specifies Return Address (the reply channel) in the request message • Service provider sends response message to specified channel Reply Channel 1 Reply Channel 2 Provider Consumer 1 Request Channel Reply Channel 1 Responses Reply Channel 2 Consumer 2

  14. Load-balanced service providers • 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? Provider 1 Consumer Request Channel Provider 2 Reply Channel

  15. 1 1 1 1 2 2 2 2 Pattern: 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 Provider 1 Consumer Message Identifier 1 2 Request Channel Provider 2 2 1 Correlation Identifier Reply Channel

  16. Multiple specialised providers • 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 Widget Inv. Order Messages Order Entry ? Gadget Inv.

  17. Pattern: Content-Based Router • 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 Widget Inv. Order Messages Order Entry Gadget Inv. Content Based Router

  18. Composite messages • How can we process a message that contains multiple elements? OrderMessage Widget Inv. Order Entry ? Gadget Inv.

  19. Pattern: Splitter & Router • 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 OrderItem 1 OrderMessage OrderItems Widget Inv. Order Entry Gadget Inv. Splitter Router OrderItem 2

  20. Producing a single response • How to combine the results of individual but related messages? • Messages can be out-of-order, delayed • Multiple conversations can be intermixed OrderItem 1 Response 1 Confirmed Order Widget Inv. Billing ? Gadget Inv. OrderItem 2 Response 2

  21. Pattern: Aggregator • 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) OrderItem 1 Response 1 Confirmed Order Widget Inv. Billing Gadget Inv. Aggregator OrderItem 2 Response 2

  22. Communicating with multiple parties • How to send a message to a dynamic set of recipients? • And return a single response message? Quotes Vendor A Vendor B Request For Quote ? Vendor C Best Quote Aggregator

  23. Pattern: Scatter-Gather • 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 Pub-Sub channel Quotes Vendor A Vendor B Request For Quote Vendor C Best Quote Aggregator

  24. Complex composition • 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 Pub-Sub channel Quotes Vendor A Vendor B Quote request for each item Splitter Vendor C Best Quote for each item Aggregator Aggregator

  25. Interop technologies

  26. Major interop technologies • Resource based • RPC style / distributed objects • Message based / document-oriented DB files RMI-IIOP (CORBA) Remoting (DCOM) WS in-process bridge WS WS-* MOM

  27. durable message point-to-point transient messages server lifetime-management clustering routable Interop technology characteristics platform neutral J2EE server .NET server in-proc DB/files MOM WS-* WS RMI-IIOP (CORBA) Remoting (DCOM) bridge MOM WS-* WS

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

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

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

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

  32. Enterprise Solution Patterns using Microsoft .NETMicrosoft Patterns & Practices 2003 Integration Patterns Microsoft Patterns & Practices 2004 Enterprise Integration Patterns Gregor Hohpe, Bobby WoolfAddison-Wesley, 2004 Patterns of Enterprise Application ArchitectureMartin Fowler Addison-Wesley, 2003 Enterprise SOA Dirk Krafzig, Karl Banke, Dirk Slama Prentice Hall, 2004 Recommended books

More Related