Pal gov.tutorial3.session11.integration.patterns
0 likes325 views
This document discusses integration patterns in service oriented architectures. It begins with an overview of SOA principles such as loose coupling, abstraction, and autonomy. Common integration challenges are then addressed through enterprise integration patterns which describe message-based solutions. Specific patterns are examined like request-response, content-based routing, and the aggregator. Web services are identified as a tool that can help address integration goals through standards-based interfaces. The document concludes with a discussion of SOA integration patterns organized into categories and provides examples of how patterns can solve problems related to centralized logic, service layer organization, and composition autonomy.
![Enterprise integration Patterns
Message Message Message
Construction Routing Transformation
Endpoint Endpoint
Message Router Translator
Channel
Application Application
A B
Messaging
Messaging Channels Monitoring System
Endpoints Management
• Gregor Hohpe [1] defined a visual pattern language
describing message-based enterprise integration solutions
• 6 categories of patterns contains around 65 patterns](https://image.slidesharecdn.com/palgov-tutorial3-session11-integration-patterns-120601120302-phpapp02/85/Pal-gov-tutorial3-session11-integration-patterns-14-320.jpg)
Pal gov.tutorial3.session11.integration.patterns
- 1. أكاديمية الحكومة اإللكترونية الفلسطينية The Palestinian eGovernment Academy www.egovacademy.ps Tutorial III: Process Integration and Service Oriented Architectures Session 11 Integration Patterns Prepared By Mohammed Melhem PalGov © 2011 1
- 2. About This tutorial is part of the PalGov project, funded by the TEMPUS IV program of the Commission of the European Communities, grant agreement 511159-TEMPUS-1- 2010-1-PS-TEMPUS-JPHES. The project website: www.egovacademy.ps Project Consortium: Birzeit University, Palestine University of Trento, Italy (Coordinator ) Palestine Polytechnic University, Palestine Vrije Universiteit Brussel, Belgium Palestine Technical University, Palestine Université de Savoie, France Ministry of Telecom and IT, Palestine University of Namur, Belgium Ministry of Interior, Palestine TrueTrust, UK Ministry of Local Government, Palestine Coordinator: Dr. Mustafa Jarrar Birzeit University, P.O.Box 14- Birzeit, Palestine Telfax:+972 2 2982935 mjarrar@birzeit.eduPalGov © 2011 2
- 3. © Copyright Notes Everyone is encouraged to use this material, or part of it, but should properly cite the project (logo and website), and the author of that part. No part of this tutorial may be reproduced or modified in any form or by any means, without prior written permission from the project, who have the full copyrights on the material. Attribution-NonCommercial-ShareAlike CC-BY-NC-SA This license lets others remix, tweak, and build upon your work non- commercially, as long as they credit you and license their new creations under the identical terms. PalGov © 2011 3
- 4. Tutorial Map Intended Learning Objectives A: Knowledge and Understanding Title T Name 3a1: Demonstrate knowledge of the fundamentals of middleware. 3a2: Describe the concept behind web service protocols. Session0: Syllabus and overview 0 Aldasht 3a3: Explain the concept of service oriented architecture. Sesson1: Introduction to SOA 2 Aldasht 3a4: Explain the concept of enterprise service bus. Session2: XML namespaces & XML schema 2 Aldasht 3a5: Understanding WSDL service interfaces in UDDI. Session 3: Xpath & Xquery 4 Romi B: Intellectual Skills Session4: REST web services 3 M. Melhem 3b1: Design, develop, and deploy applications based on Service Session5: Lab2: Practice on REST 3 M. Melhem Oriented Architecture (SOA). Session 6: SOAP 2 Aldasht 3b2: use Business Process Execution Language (BPEL). Session 7: WSDL 3 Aldasht 3b3: using WSDL to describe web services. Session8: Lab 3: WSDL practice 3 Aldasht C: Professional and Practical Skills Session9: ESB 4 Aldasht 3c1: setup, Invoke, and deploy web services using integrated Session10: Lab4: Practice on ESB 4 Aldasht development environment. Session11: integration patterns 4 M. Melhem 3c2: construct and use REST and SOAP messages for web services communication. Session12: Lab5: integration patterns 4 M. Melhem D: General and Transferable Skills Session13: BPEL 3 Aldasht d1: Working with team. Session14: Lab6: Practice on BPEL 3 Aldasht d2: Presenting and defending ideas. Session15: UDDI 2 Aldasht d3: Use of creativity and innovation in problem solving. d4: Develop communication skills and logical reasoning abilities.
- 5. Session 11: SOA design and Integration Patterns. This session aims to cover Service oriented architecture and how to utilize it in systems integration using different patterns and methodologies of best practice. After completing this session students will be able to: 1. Link SOA principles to integration 2. Open doors to integration patterns and understand how to use it in Enterprise Applications
- 6. Session contents 1. Review of Service Oriented Architecture 2. SOA – Principles 3. Integration 1. The challenge 2. Patterns 3. Enterprise integration patterns 4. Messaging 5. Why web services 6. Additional Patterns 4. SOA Integration Patterns 5. Summery
- 7. SOA “Service Oriented Architecture” Motivation • Challenges in enterprise application development – Many users and backend systems interact with the system. – Quality of services (QoS) requirements and other Non-functional requirements . – Development and integration projects costly and long running • For example point – to – point connections, often developed from scratch.
- 8. SOA “Service Oriented Architecture” Motivation (cont.) • Solution evolved into Service Oriented Architecture – Message Backbone • Point to point connection between applications • Simple, basic connectivity – Enterprise Application Integration • Connect application through a centralized hub • Easier to manage larger number of connections – Service Oriented Architecture • Integration and choreography of services through an Enterprise Service Bus • Flexible connections with well defined, standards-based interfaces
- 9. SOA “Service Oriented Architecture” Definition • No Single definition, different sectors different meaning • Architect – It is an Architectural style that aims to achieve loose coupling among interacting software agents. • Business Domain – Set of services exposed to customers an • Developers – A programming and deployment model realized by standards, tools and technologies such as Web services.
- 10. SOA Principles • Loose Coupling Refers to the number of dependencies between modules • Abstraction Contain essential information • Reusability • Autonomy Level of control over its underlying runtime execution • Statelessness • Discoverability (meta data)
- 12. The challenge • Organizations increase its dependency on IT systems. • Systems must provide an integrated solutions. • Systems must interoperate with each other. • Architectural trends of technology. • Changing business needs and requirements
- 13. Design Patterns, Why? • Knowledge reuse. • Patterns encapsulate knowledge of successful designs • Shows good solution to a common problem within a specific context. • Observed from real experience. • No repetition (copy-paste)
- 14. Enterprise integration Patterns Message Message Message Construction Routing Transformation Endpoint Endpoint Message Router Translator Channel Application Application A B Messaging Messaging Channels Monitoring System Endpoints Management • Gregor Hohpe [1] defined a visual pattern language describing message-based enterprise integration solutions • 6 categories of patterns contains around 65 patterns
- 15. Application Sample Application • Front end can uses web Front End service to interact. • Messages format defined App Logic in SOAP. • Access analytics service Adapter using system com adapter. Analytical Deal Messagin • Access deals from Library Manger g Lib existing services • Access service bus through messaging abstraction library
- 16. Request – Response Pattern Consumer Request Provider Request Channel Reply Channel Response • Similar to RPC • Asynchronous point – to – point channels • Separate messaging
- 17. Multiple Consumer Consumer 1 Requests Requests Provider Request Channel Reply Channel 1 ? Reply Channel 2 Responses Consumer 2 • Each consumer has its own queue • But how does the provider send the response? – Could send to all consumers – Hard code 17
- 18. Return Address Consumer 1 Requests Requests Provider Request Channel Reply Channel 1 Responses Reply Channel 2 Consumer 2 • Consumer send return address in request Header (WS-Addressing). • Service provide send response message to consumer. 18
- 19. Load balancing service providers Provider 1 Consumer Request Channel Provider 2 Reply Channel • Handle request by multiple providers. • One service receive requests • How to handle message order? 19
- 20. Correlation Identifier Provider 1 Consumer 1 1 2 Request Channel 2 Provider 2 1 2 1 2 Reply Channel • Consumer assign an identifier to each message • Message Id • GUID • Business Key • Provider include identifier in response message • Sender Match request and response 20
- 21. Content-Based Router Order Messages Widget Inv. Order Entry Gadget Inv. Content Based Router • Add a content based router • Router handle message forwarding • Content remain intact
- 22. Multiple specialized provider Provider 1 Consumer ? Provider 2 • Request message can be consumed by more than one service provider. • Each provider can handle specific type of message • How to route the request to the appreciate provider? • Sender should not worry about this task. • Find a coordination system 22
- 23. Composite messages • How to process a message with multiple targets. • Use a splitter to break out the message into separate messages. • Next use router to send messages to its targets. Composite Messages Order Entry Content Message Based Splitter Router
- 24. Aggregator • How to combine results messages? – Messages can be out of order – Conversations can be intermixed • Use a stateful filter, an Aggregator • Collects and stores messages until a complete set has been received • Publishes a single message created from the individual messages Aggregator
- 25. Communicating with multiple parties (Auction) • How can we send a message to dynamic set of providers? And return a single response message? • Scatter-Gather – Send message to pub-sub channel – Forward message to target vendor – Collect messages using Aggregator Auction Quote Vender 1 Channel Vender 2 Vender 3 Aggregator
- 26. Messaging Channels • Channels are: – Separate from applications – Asynchronous & reliable – Data is exchanged in self-contained messages – Loosely coupled integration
- 27. Message History • The key benefit of message based system is the loose coupling between participants, however the same property makes debugging and analyzing dependence not an easy task. – If we are not ware where message goes, we can’t assess the impact of the change in the message. – Another issue if we don’t know which application produce the message, it become difficult to solve problems in messages. • How can we effectively analyze and debug the flow of messages in a loosely coupled system?
- 28. Message Store • How we can report of message status, without loosely coupled and transient nature of messaging? Message -Take advantage of Store asynchronous nature of messaging infrastructure
- 29. Additional Patterns (Pipe and Filter) – Provides a solution to move an output from one system to another. – Pipes are the connection between the source system and the receiving system (sink) – Filters responsible of data transformation to the receiver for processing. – This pattern useful for data transfer from one system to another, into different formats. i.e. converting data from local university storage format into National Student Registry format. – Further reading: Microsoft Integration Patterns, patterns and practice 2005, CH6 Source Filter 1 Filter 2 Sink Pipe Pipe Pipe
- 30. Additional Patterns (Gateway) – Abstracts the access to an external systems to a single interface, by eliminating the need for multiple systems. – Simplifies the development and maintenance processes that are related to accessing external systems. – Common uses accessing mainframe programs and processing credit card transactions. Pattern replaces direct access to resources. – Further reading: Microsoft Integration Patterns, patterns and practice 2005, CH6 App 1 Gateway Resources App 2
- 31. Why Web Services? • Web service benefit: – Loose-coupling – Service oriented – Reliable communication – Vender independent – Bypass firewalls (HTTP/HTTPS)
- 32. SOA Patterns Categories: Foundational Inventory Patterns Logical Inventory Layer Patterns Inventory Centralization Patterns Inventory Implementation Patterns Inventory Governance Patterns Service Implementation Patterns Service Security Patterns Service Messaging Patterns
- 33. SOA Patterns: Logic Centralization How can the misuse of redundant service logic be avoided? Problem: If National student services are not consistently reused, redundant functionality can be delivered in other services, resulting in problems associated with inventory denormalization and service ownership and governance.
- 34. SOA Patterns: Service Layers How can group of services be organized based on functional commonality? Problem: Arbitrarily services delivered and governed by different teams can lead to design inconsistency and inadvertent functional redundancy.
- 35. SOA Patterns: Composition Autonomy How can compositions be implemented to minimize loss of autonomy? Problem: Composition controller services naturally lose autonomy when delegating processing tasks to composed services, some of which may be shared across multiple compositions.
- 36. Summary • Systems become more complex • Patterns help us to design robust applications • Interoperability and integration is key to build enterprise software • Next session will cover the business process execution language
- 37. References 1. http://eaipatterns.com/gregor.html 2. http://en.wikipedia.org/wiki/Creational_pattern 3. http://en.wikipedia.org/wiki/Structural_pattern 4. http://en.wikipedia.org/wiki/Behavioral_pattern 5. http://dictionary.reference.com/browse/Integration 6. http://en.wikipedia.org/wiki/Systems_integration 7. http://www.designpatternsfor.net/Presentations/AsynchronousMessagingPatt ernsWithWCF.pdf 8. http://drops.dagstuhl.de/volltexte/2006/828/pdf/06291.SWM.Paper.828.pdf 9. http://www.soapatterns.org/orchestration.php 10. Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf Addison-Wesley, 2004 11. Patterns of Enterprise Application Architecture, Martin Fowler Addison- Wesley, 2003 Enterprise SOA, Dirk Krafzig, Karl Banke, Dirk SlamaPrentice Hall, 2004 12. Integration Patterns 3ed, Microsoft, 2004