Enterprise Integration Patterns 1.SOA and Patterns 2.Messaging 3.Using the EIP language to design message flows.

Slides:



Advertisements
Similar presentations
웹 서비스 개요.
Advertisements

3 Copyright © 2005, Oracle. All rights reserved. Designing J2EE Applications.
Technical Track Session Service-Oriented Architecture Terry Woods.
Component Patterns – Architecture and Applications with EJB copyright © 2001, MATHEMA AG Component Patterns Architecture and Applications with EJB JavaForum.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Introduction To System Analysis and Design
Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica System architectures Updated: November 2014.
Apache Axis: A Set of Java Tools for SOAP Web Services.
Internetworking Devices that connect networks are called Internetworking devices. A segment is a network which does not contain Internetworking devices.
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
TCP: Software for Reliable Communication. Spring 2002Computer Networks Applications Internet: a Collection of Disparate Networks Different goals: Speed,
Course Instructor: Aisha Azeem
SOA, BPM, BPEL, jBPM.
Spring Integration - basics Martin Toshev, Diyan Yordanov Cisco Systems.
C8: Enterprise Integration Patterns in Sonic ™ ESB Stefano Picozzi Solutions Architect.
ESB Guidance 2.0 Kevin Gock
Computer System Architectures Computer System Software
Christopher Jeffers August 2012
Chapter 17 Networking Dave Bremer Otago Polytechnic, N.Z. ©2008, Prentice Hall Operating Systems: Internals and Design Principles, 6/E William Stallings.
Framework: ISA-95 WG We are here User cases Studies
Protocol Architectures. Simple Protocol Architecture Not an actual architecture, but a model for how they work Similar to “pseudocode,” used for teaching.
Enterprise Application Integration Paulo Marques Informatics Engineering Department University of Coimbra 2008/ “EAI in 2 hours!”
December 15, 2011 Use of Semantic Adapter in caCIS Architecture.
Pattern Oriented Software Architecture for Networked Objects Based on the book By Douglas Schmidt Michael Stal Hans Roehnert Frank Buschmann.
1 © NOKIA 1999 FILENAMs.PPT/ DATE / NN SIP Service Architecture Markus Isomäki Nokia Research Center.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Lecture 15 Introduction to Web Services Web Service Applications.
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 09. Review Introduction to architectural styles Distributed architectures – Client Server Architecture – Multi-tier.
Cosc 4765 SSL/TLS and VPN. SSL and TLS We can apply this generally, but also from a prospective of web services. Multi-layered: –S-http (secure http),
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
1 Introduction to Middleware. 2 Outline What is middleware? Purpose and origin Why use it? What Middleware does? Technical details Middleware services.
(Business) Process Centric Exchanges
Web Services Based on SOA: Concepts, Technology, Design by Thomas Erl MIS 181.9: Service Oriented Architecture 2 nd Semester,
XML Web Services Architecture Siddharth Ruchandani CS 6362 – SW Architecture & Design Summer /11/05.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
1 Geospatial and Business Intelligence Jean-Sébastien Turcotte Executive VP San Francisco - April 2007 Streamlining web mapping applications.
AUTHORS: MIKE P. PAPAZOGLOU WILLEM-JAN VAN DEN HEUVEL PRESENTED BY: MARGARETA VAMOS Service oriented architectures: approaches, technologies and research.
Architectural Patterns Support Lecture. Software Architecture l Architecture is OVERLOADED System architecture Application architecture l Architecture.
Service Oriented Architecture CCT355H5 Professor Michael Jones Suezan Makkar.
Lecture 6: Sun: 8/5/1435 Distributed Applications Lecturer/ Kawther Abas CS- 492 : Distributed system & Parallel Processing.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
Enterprise Integration Patterns CS3300 Fall 2015.
SOA-10: Event-Driven SOA: EDA in an SOA World Ken Wilner Vice President of Technology.
EGOS LLC CCSDS 14/ Question Question; Why a Service Viewpoint? Short Answer; Because a service viewpoint provides a useful additional level.
Callista Enterprise Test Driven ESB Development Sofia Jonsson
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
AMQP, Message Broker Babu Ram Dawadi. overview Why MOM architecture? Messaging broker like RabbitMQ in brief RabbitMQ AMQP – What is it ?
IT3002 Computer Architecture
Integration Patterns in BizTalk Server 2004 Integration Patterns Explained What are integration patterns? What patterns does BizTalk Server 2004 provide.
So you think you know pub/sub ? Udi Dahan in
Christian Stiller Technical Account Manager SOA-23: Enterprise Integration Patterns in Sonic ™ ESB.
1 SERVICE ORIENTED ARCHITECTURE ANTHONY GACHANGO D61/70547/2008 DIS 601.
SOA & Event Driven Architecture Steve Else, Ph.D., Certified Enterprise Architect, SOA COP Srinidhi Boray, Certified Enterprise Architect, Ingine, Inc.
1 Device Controller I/O units typically consist of A mechanical component: the device itself An electronic component: the device controller or adapter.
Background Computer System Architectures Computer System Software.
Wednesday, March 16, 2016 PESC + SOA A flexible and distributed SOA architecture to implement the PESC Standard Jam Hamidi
Week #8 OBJECTIVES Chapter #5. CHAPTER 5 Making Networks Work Two Networking Models –OSI OPEN SYSTEMS INTERCONNECTION PROPOSED BY ISO –INTERNATIONAL STANDARDS.
IP Security (IPSec) Matt Hermanson. What is IPSec? It is an extension to the Internet Protocol (IP) suite that creates an encrypted and secure conversation.
Software Architecture Patterns (3) Service Oriented & Web Oriented Architecture source: microsoft.
A service Oriented Architecture & Web Service Technology.
Last Class: Introduction
Sabri Kızanlık Ural Emekçi
Layered Architectures
Distribution and components
Software Testing and Maintenance Designing for Change
Service-centric Software Engineering
Applying Use Cases (Chapters 25,26)
Software Testing and Maintenance Designing for Change
Presentation transcript:

Enterprise Integration Patterns 1.SOA and Patterns 2.Messaging 3.Using the EIP language to design message flows

What have we seen in Healthcare Domain? Lots of different systems – Sources and Sinks – Some you are in control of, others not Lots of different data types – And representations Lots of different participants – Organizations agreeing to share data All connected via network – A complex distributed system

How to Integrate? The architectural question is how to integrate all these systems into something – Coherent – Extensible – Maintainable – (reasonably) simple to understand This is really what SOA was designed to tackle – Complexity management – Change management

SOA

What is a Pattern? An abstraction that defines high level – Relationships between components – Actors – Reusable – Independent of implementation – Encapsulates knowledge already learned When you face a problem, consider existing patterns that are applicable – saves you from re-inventing the wheel and making the same mistakes as others – Patterns are the language by which system architecture and design are expressed and shared.

What is an Enterprise Integration Pattern (EIP)? An enterprise is a ‘big’ business – Often contain legacy apps, COTS apps, third party services and internal components What is integration? – Making all those bits work together seamlessly to fulfill business workflow So an EIP is a reusable abstraction that is useful in solving the problems raised by enterprise Integration

Back to Basics The EIPs we will look at are Defined by – Gregor Hohpe, Bobby Woolf and others in – Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions – – Well worth looking at! They leverage the most primitive building block that distributed systems are based on: – The Message

Messages A message is a discrete piece of data sent from one application to another Messages typically contain headers (metadata) and a body (application payload) metadata dataData description Something happened!Do something superset

Middleware Messages are exchanged between middleware (message oriented middleware) – The middleware understands the message format – Does not always understand the contents of the message, in particular the body. It does understand at least some of the metadata in the headers Middleware is the glue that combines the higher level applications.

Messages and Middleware Machine A Machine B Machine C Distributed Applications Middleware Services OS, e.g. Windows OS, e.g. Mac OS X OS, e.g. Linux Network messages

Loose Coupling Essential for – complexity management – Allowing change – Allowing growth Message oriented middleware helps to create loosely coupled systems – Based on the simplest exchange pattern (one-way) – Message format and metadata is independent of the components the middleware connects.

Middleware acting as an Enterprise Service Bus (ESB) The ESB is the glue between different components. It passes messages via the bus To different destinations. Means there is a many to one relationship between components. Components are glued to the bus, not each other.

Sending a Message The second simple abstraction: Channel A component that can send a message from a source to a destination – Could be implemented in many ways Method invocation TCP/IP message Pigeon

Sending a message Channels are one-way Which means communications are asynchronous To model request/response use two channels

Binding Messages to Applications Applications are independent of the messaging system So you need adapters that are able to take application specific data and create a message and send it to a channel. At the other side you need Message endpoints that can receive a message From a channel and pass it to an application in an application specific way. These are the glue components to bind applications to the messaging system. If an application changes, then the adapter or endpoint needs changing Isolates change across the system.

Putting it together Message goes to adapter, then to channel, then to endpoint. So far so simple. But we have really solved any integration problems yet

Transformation Sending and receiving applications may expect different data types or formats. So we may need to transform the message somehow to suit the receiving application.

Translation Notation is not strict Arrows are often A short cut for channels

Pipes and Filters The inclusion of the translator works for now – But what if there are other steps that need to take place, for example if the message has been signed and encrypted then we need to verify the signature and decrypt message. – Signature verification and decryption are common processes We don’t want to hard code these into endpoints or the translator. We want to reuse. A pipes and filters architecture allows us to do this. – The message passes through a number of components that process the message (filters) – They send the message down the pipe (channel) they are connected to. – They all deal with the same message/channel abstraction – They can be composed flexibly depending on the circumstance

Processing Chain

Routing We can now send a message down a channel and apply various processing/filtering steps. – Each filter is connected to an incoming and an outgoing channel But the endpoints are hard coded. – This is not flexible – What if an endpoint changes? – Introduce a Router – A router knows where to send a message E.g. a Content-Based Router could use – Message type (in headers) – Message content (in body) Or a Context Based Router – Receives context information from a central configuration location – For example a ‘testing’ context could route differently to a ‘production’ context.

Routing A Router is connected to multiple channels and contains The logic to decide which channel it should send to.

Multiple Recipients Not all channels want to be point to point. Here a recipient list router is used to send to a predetermined set of endpoints

Multiple Recipients Here the publish/subscribe pattern is modeled. Endpoints subscribe to channels That are of interest to them. Subscribers receive messages. This moves the logic of knowing who should receive messages to the endpoints. The channel does not need to know who the subscribers are or why they have subscribed.

Routing A content based router and a recipient list are not that loosely coupled – The first needs to know how to map content to channels What if either changes? – The latter has to know about all recipients What if that needs to change? The pub/sub channel is more loosely coupled – It doesn’t know or care about who gets the message – But there may be situations where you need to ensure that a message is only processed exactly once E.g. credit card transaction

Dynamic Routing In the content based router example, some steps are hard coded and routing decisions are made after some pre- processing. – To make it more flexible, we could move the router to the beginning of the route. But the route is still hard coded in the router. In more sophisticated routes, you may want to change the routing path as you move through the route. – The processing done by one filter may affect how later filter processing is done. – For example error processing – Routes that encapsulate one or more coarse grained business level functions that connect various underlying subsystems together.

Process Manager Process Manager sends to channels and each component returns results to the Process manager. One central decision point that can evaluate at runtime. But messages always go back to manager which increases overhead.

Process Manager Exception Handling using Process Manager

Routing Slip This allows each processor to pass the message to the next processor without going back to a central unit. – The processing chain is calculated up front – The ‘slip’ is the calculated route. It is put into the message metadata – Filters have small generic routers attached to them – These mini routers update the slip, then pass the message to the next channel in the list Can be used for service orchestration – Multiple underlying services performing a higher level business function Downside: route cannot be altered after it has been initialized

Scatter Gather Rather than defining long sequential processing chains, it may be possible to execute steps in parallel – For example you could check a user’s account status and whether the item they have ordered is in stock at the same time. – These processes are not dependent on one another so they can be executed in parallel – The results of both processes can be aggregated and decisions made about how to proceed.

Splitter and Aggregator

Scatter Gather To facilitate this, metadata could be added to the message header to define the processes that need to be completed and processing status values. – So the aggregator knows When all processes have finished What actions to take based on the return values of the processors

Splitter and Aggregator

Message Exchange Patterns Channels are one way, so the basic building block of a messaging system is asynchronous communication. We have seen the pub/sub exchange pattern We have seen the scatter/gather exchange pattern The request/response is also very common – Web Services – HTTP

Request Response Channels are one-way Which means communications are asynchronous To model request/response use two channels and a correlation ID in the messages. This potentially adds overhead. But remember that channels are an abstract pattern You could implement a channel that returns data down an open TCP connection if request/response is required and an open connection is available. This is actually not uncommon. For example a channel that uses HTTP (in built request/response) will often use an HTTP Accept response header for asynchronous communications. For request/response messages it can send data down the open socket and pass the data to the message endpoint which experiences it as asynchronous.

System Management Message oriented systems are loosely coupled – But that can make debugging and verifying message flow very difficult especially when distributed across many machines and service – There are various techniques for coping with this that use the messaging framework itself to control and monitor. – Two levels of monitoring System level – message processing time, throughput – Look at most at some of the metadata in message Business application monitoring – Look at the payload of the messages

Control Bus Process Manager revisited, this time with a channel to a control bus. The control bus receives messages created by the Process Manager in response to the messages that it processes. Allows monitoring exceptions, throughput, processing time, keeping a message history. A separate channel from the control bus to the process manager allows runtime configuration of the manager.

Wire Tap A wire tap is a simple Recipient List with two recipients. One channel is the tap that can be switched on or off (via Control Bus) when messages need to be inspected in a point to point channel.

Detour A Detour routes a message via a different route for validation, testing and debugging purposes. A Context Based Router can be used to implement the pattern, for example if the control bus signals to the router that the validation route should be taken.

Enterprise Integration Patterns 1.Patterns are a way of dealing with complexity in a coherent way 2.EIPs are compos-able message oriented patterns for building loosely coupled systems that need to integrate diverse sub-systems