IST 421 Advanced Enterprise Integration Technology Choices Sandeep Purao, Ph.D. Associate Professor of IST

Where we are Enterprise Integration Module 1: The Context Organizational Processes Module 2: Structuring the Problem Integration Requirements Integration Fundamentals Technology Choices

Starting Points What is loose coupling? Are there established ‘styles’ that we can use to design integration solutions? Are there 'good design practices' for building enterprise integration solutions?

What is loose coupling?

Are there established ‘styles’ that we can use to design integration solutions?

Are there 'good design practices' for building enterprise integration solutions?

Coupling According to Wikipedia Two members of an intimate relationship Do we want applications connected or linked to one another in an intimate relationship? Is it the same as integrating applications? What is the difference between integration and coupling? What is tight coupling vs. loose coupling of applications? Which is desirable?

According to Wikipedia

Two members of an intimate relationship

Do we want applications connected or linked to one another in an intimate relationship?

Is it the same as integrating applications?

What is the difference between integration and coupling?

What is tight coupling vs. loose coupling of applications? Which is desirable?

Problem 1

Coupling / Integration Data Function aka Processing Presentation aka Interface Data Function aka Processing Presentation aka Interface Consider one link between two applications: What is the difference between integration and coupling? What is tight coupling vs. loose coupling of applications? Which is desirable?

Assumptions Assumption 0: I know how Chin sees the world, it is the same as me Assumption 1: I know where to reach Chin, at the Number 232.454.7676 Assumption 2: I know that Chin is there and will pick up the phone Assumption 3: I know that Chin will understand my question and how I ask it Demuestre por favor John' historia de ventas de s del enero de 2005 al diciembre de 2007. Kabir Chin Billing Coordinator Help Desk Operator

Assumptions = Coupling Assumption 0: I know the data encoding for the Billing app and I use it too Assumption 1: I know where the Billing app sits e.g. 196.23.123.02 Assumption 2: I know that the Billing app is up and running right now Assumption 3: I know that the Billing app follows my question/data format Billing: Please show me John’s History for the dates Jan 05 to Dec 07. Tight Coupling leads to Brittle Solutions

Reducing Assumptions http://billing.my.com 196.23.123.02 Indirection : the ability to reference something using a name instead of the value itself. http://inventory.my.com 196.23.768.93 http://helpdesk.my.com 196.23.456.64 Recall : Pointer Handle Proxy Location Send my request to http://billing.my.com Sending the request to 196.23.123.02

Recall :

Pointer

Handle

Proxy

Reducing Assumptions Send me John’s history Intermediate Storage : the ability to store content in an intermediate location for the intended receiver to retrieve it. Analogs : Answering machine Message Queue Time Send me Sally’s last payment You may not be up, here is what I need Let me retrieve the last message

Analogs :

Answering machine

Message Queue

Reducing Assumptions Shared schema : requiring mapping to a shared schema ensures format conversion. Recall : Babelfish Translator Format <request> <name>Sally</name> <detail>Paid</detail> <seq>Last</seq> </request> Let me translate my request to common format Let me translate the request to my format

Recall :

Babelfish

Translator

Loose Coupling A desirable quality of integration solutions Reduces assumptions Reduces brittleness Allows scalability Indirection Intermediate Storage Shared Schema Scheduling App I am new, I want to join the party and share my data Loose Coupling results in Robust Solutions

A desirable quality of integration solutions

Reduces assumptions

Reduces brittleness

Allows scalability

Integration: Technology Styles Options for EAI: enterprise application integration Recall: linking “legacy” applications Recall: the three-layer model of applications Technology Styles: different kinds of Middleware Middleware Something in the middle that will allow connecting applications Moving to question 2 ..

Options for EAI: enterprise application integration

Recall: linking “legacy” applications

Recall: the three-layer model of applications

Technology Styles: different kinds of Middleware

Data Exchange Data Function aka Processing Presentation aka Interface Data Function aka Processing Presentation aka Interface SQL + ODBC Extract data with SQL, Use ODBC for indirection XML Use XML for shared schemas

Messaging Data Function aka Processing Presentation aka Interface Data Function aka Processing Presentation aka Interface RPC Similar to function calls, to remote apps Message Queues Intermediate storage Message Brokers Routing to different recipients

Interface Extraction Data Function aka Processing Presentation aka Interface Data Function aka Processing Presentation aka Interface Screen scraping Extracting interfaces from green terminals Portals Aggregating interfaces Portal

Distributed Objects Data Function aka Processing Presentation aka Interface Data Function aka Processing Presentation aka Interface Registering Here I am and this is my interface Message I can respond to messages that confirm to my interface

Web Services Data Function aka Processing Presentation aka Interface Data Function aka Processing Presentation aka Interface Registering I am a service and this is what I am capable of Message Invoking services Process Create new services Self-Help Service

Patterns Patterns as Design Knowledge Alexander in Architecture Good Design Practices Consider an example from CS: Bubble Sort What is the nature of design knowledge for enterprise integration solutions? Moving to question 3 ..

Patterns as Design Knowledge

Alexander in Architecture

Good Design Practices

Consider an example from CS: Bubble Sort

What is the nature of design knowledge for enterprise integration solutions?

An Example Pattern Developing in Pairs Problem: People are scared to solve problems alone Context: Code ownership has been identified and development is proceeding Forces: People sometime feel they can solve a problem only if they have help. Some problems are bigger than an individual. Many people cannot be productive quickly in front of a keyboard. Effort goes up nonlinearly with number of people. Solution: Pair compatible designers to work together; together, they can produce more than the sum of the two individually. Resulting Context: A more effective implementation process. A pair of people is less likely to be blindsided than an individual developer. http://users.rcn.com/jcoplien/Patterns/Process/section40.html (adjusted)

Developing in Pairs

Problem: People are scared to solve problems alone

Context: Code ownership has been identified and development is proceeding

Forces:

People sometime feel they can solve a problem only if they have help.

Some problems are bigger than an individual.

Many people cannot be productive quickly in front of a keyboard.

Effort goes up nonlinearly with number of people.

Solution: Pair compatible designers to work together; together, they can produce more than the sum of the two individually.

Resulting Context: A more effective implementation process. A pair of people is less likely to be blindsided than an individual developer.

Example EI Patterns Message Translator Scatter Gather Translating message formats between systems Broadcasting a request to multiple recipients, then using an aggregator to collect responses http://www.enterpriseintegrationpatterns.com/eaipatterns.html 2008-1-May 1-May-2008

Using EI Patterns Applying good design practices to create a robust integration solution This example concatenates several EI patterns to create a new solution

Outcomes You should be able to: Describe different styles of integration without getting confused by terminology. Argue about appropriateness of different styles given a problem scenario. Understand the key elements of design knowledge for enterprise integration

You should be able to:

Describe different styles of integration without getting confused by terminology.

Argue about appropriateness of different styles given a problem scenario.

Understand the key elements of design knowledge for enterprise integration