Slide1 l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 34

Enterprise Integration PowerPoint PPT Presentation


  • 273 Views
  • Uploaded on
  • Presentation posted in: General

Enterprise Integration. Erik Doernenburg ThoughtWorks, Inc. [email protected] Agenda. Challenges in enterprise application development Design patterns Enterprise Integration patterns Interop technologies Conclusion & Resources. The challenge.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Enterprise integration l.jpg

Enterprise Integration

Erik Doernenburg

ThoughtWorks, Inc.

[email protected]


Agenda l.jpg

Agenda

  • Challenges in enterprise application development

  • Design patterns

  • Enterprise Integration patterns

  • Interop technologies

  • Conclusion & Resources


The challenge l.jpg

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


Finance operator application l.jpg

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


Portfolio management tool l.jpg

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


Design patterns l.jpg

Design Patterns


Why design patterns l.jpg

Why design patterns?

  • Code reuse remains difficult

    but…

  • Knowledge reuse can be very valuable

  • Patterns encapsulate knowledge of successful designs


Using technology successfully l.jpg

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


Patterns l.jpg

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


Enterprise integration patterns l.jpg

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


Pattern request response l.jpg

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


Multiple consumers l.jpg

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


Pattern return address l.jpg

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


Load balanced service providers l.jpg

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


Pattern correlation identifier l.jpg

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


Multiple specialised providers l.jpg

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.


Pattern content based router l.jpg

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


Composite messages l.jpg

Composite messages

  • How can we process a message that contains multiple elements?

OrderMessage

Widget Inv.

Order

Entry

?

Gadget Inv.


Pattern splitter router l.jpg

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


Producing a single response l.jpg

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


Pattern aggregator l.jpg

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


Communicating with multiple parties l.jpg

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


Pattern scatter gather l.jpg

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


Complex composition l.jpg

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


Interop technologies l.jpg

Interop technologies


Major interop technologies l.jpg

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


Interop technology characteristics l.jpg

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


Messaging l.jpg

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


Why web services l.jpg

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


Web services development l.jpg

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


Conclusion l.jpg

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


Recommended books l.jpg

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


  • Login