• Save
Technology Choices for Enterprise Integration
Upcoming SlideShare
Loading in...5
×
 

Technology Choices for Enterprise Integration

on

  • 2,398 views

An example of a set of slides used for a course on Advanced Enterprise Integration, a senior-level class at Penn State

An example of a set of slides used for a course on Advanced Enterprise Integration, a senior-level class at Penn State

Statistics

Views

Total Views
2,398
Views on SlideShare
2,394
Embed Views
4

Actions

Likes
3
Downloads
0
Comments
0

2 Embeds 4

http://www.slideshare.net 3
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Technology Choices for Enterprise Integration Technology Choices for Enterprise Integration Presentation Transcript

  • 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?
  • 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?
  • 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
  • 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
  • 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
  • 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
  • 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 ..
  • 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 ..
  • 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)
  • 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