COMPARING DIFFERENT SOFTWARE INTEGRATION TECHNOLOGIES

Author

Jones Olaiya Ogunduyilemi

(Internet & Software Technology)E-mail: oladjones@itu.dk

Supervisor:Yvonne Dittrich

Associate ProfessorSoftware Development Group

MastersThesis Presentation

04 April 2008

Agenda1. Introducing the project2. Application situation in Minton3. Application integration in perspectives4. Expectation5. Techniques & Technologies6. Levels of integration7. Criteria & requirements8. Patterns9. Demonstration (prototypes)10. Technologies compared11. Observation and future perspectives12. Errors detected13. Questions

Introduction• Application communicating together

• Its complexities (hosting on different OS, Programming languages, protocols etc)

• Efforts to link programs together:– The need for programs to share data in a

uniformed, consistent way– The need for programs to communicate

independently – How new application could be added to the

current architecture in a scalable way– Security issues

Applications in Minton

CI Sys.

DB

Ordering sys

DB

Inv sys

DB

SAP

DB

ERP

DB

Sales

DB

Resource Tracking sys.

DB

CRM

DB

SCM

DB

HR

DB

etc

DB

APPLICATION INTEGRATION 4 types of application integration have evolved

• Simple replication (a simple duplication of all or portions of an application, creating a single master with multiple slaves.)

• Data integration (use of tools that move data from a master application to one or more slave application)

• Function integration (one application programmatically invoking code that lies in another application) and, finally,

• True application integration (making one application available within the context of another without actually duplicating the application itself)

Organisational target• Connecting application together and ensure

interoperability between applications

• Scalability

• Efficient sharing of data

• Maintainability

• Security

• De-coupling

• Transparency / Reliable message delivery

• Certified message delivery

• Accuracy / Fault tolerance

Applicaion integrationTechniquesManual integration (heavily depend on human efforts)

• Print re-typing• Copy re-entrySemi – Automated (combine human effort + automation)

• File transfer/point-to-point• Shared Database Automated integration (serve as intermediate layer)

• Middleware(generic interface through which applications communicate handling routing, data transfer etc)

• Service oriented integration (publish – subscribe technique)

POINT – TO - POINT

CI Sys.

DB

Ordering sys

DB

Inv sys

DB

Sales

DB

6 connections

12 interfaces

COMPLEXITY

CI Sys.

DB

Ordering sys

DB

Inv sys

DB

SAP

DB

ERP

DB

Sales

DB

Resource Tracking sys.

DB

CRM

DB

SCM

DB

HR

DB

etc

DB

11 applications: 55 connections 110 interfaces

Middleware Integration Efforts

RCM CI System

Ordering/Scheduling

Sales/Marketing

Resource Tracking

WarehouseManagementSystem

AccountsReceivable

PS

S

P S

P

S P SP

SP

S

MintonMIDDLEWARE

7 applications: 7 connections 14 interfaces

Service-Oriented Integration

Connects applications through the exchange of documents, usually in the form of XML documents.

Does not imply interaction with a specific instance of a remote object. Instead, when the document is passed from the consumer to the provider, it triggers the execution of a specific function or service that is self-contained and stateless.

Integration Architectural Patterns

• Files sharing

• Shared Database

• Remote procedure call

• Messaging

• Services (Service-Oriented Integration)

• Distributed Object Integration (also known as instance-based integration), which allows the client to manage the lifetime of a specific remote object instance.

LEVELS OF INTEGRATION• DATA LEVEL• Data centric accessing different Databases without changing to

application code

• MESSAGE LEVEL• Application dependent and more invasive as it requires more

modification to existing applications (creating interface etc) – Data transport across heterogeneous platforms– Location independence– Self-describing data– LAN and WAN capability

• SERVICE LEVEL• Messages are sent with location independence

– Subscribers need not know where the data is coming from– Publishers need not know where the data is going to

Criteria and requirements

Criteria Requirements

•Application coupling•Scalability•Interoperability•Data format•Availability•Cross platform•Low cost•Data Security•Remote Communication (synchronicity)

•Maintainability and reusability•Performance•Efficiency•Reliability•Data consistency

DEMOPROTOTYPE 1: FILE TRANSFER

PROTOTYPE 2: REQUEST – REPLY POINT .TO-POINT

PROTOTYPE 3: MESSAGING /IBM WEBSPHERE MQ [6.0 PROTO]

PROTOTYPE 4 : MIDDLEWARE / DATABASE SCHEMA DETECTIONLinks: http://www.itu.dk/people/oladjones/DBRWA/users/

PROTOTYPE 5 : WEB SERVICES

PROTOTYPE 6: CORBA

Prototype 1File sharing integration

Customer info system

CI Sys. API

Invoicing system

Inv Sys.API

DB

Central server

FILE

Shared folder

Fetch data

Send data Fetch data

Request data

DB

Store data

Use data

FTP FTP

Prototype 2Request – reply point-to-point

Inv. Sys

(Invoicing System)

CI Sys.

(Customer Info System)

Request Channel

Reply Channelm

m

Inv Sys

CI Sys

Prototype 4 MIDDLEWARE / DB SCHEMA DETECTION

Links: http://www.itu.dk/people/oladjones/DBRWA/users/

DB Connector

User Interface

AJAX Engine

PROG2

API

CI SYS

API

Q

PROG 4

API

Q

Inv. SYS

API

Q

PROG 2

API

M

DATABASE SERVER

DB DB DB

XMLHTTP Request XMLHTTP Response

MOM

XMLHTTP Request XMLHTTP Response

XMLHTTP Request XMLHTTP Response

QM

Key Message channel Client connection XMLHTTPRequest XMLHTTPResponse Message M

Q

QM

CI SYS

API

PROG 4

API

Criteria Point-to-point Middleware Service oriented

Scalability •Scalability is not guaranteed in a complex enterprise solution

•Scalable •Scalable

Exchange format

•Data are exchanged based on the agreed format.

•Most cases cross platform format (xml)

•XML

Reliability •Only reliable for prototyping and integrating very few applications

•Reliable but initially complex to setup

•More reliable but less established technology

Strength •Commonly for low level integration•Many point to point integrations already exist•No major up front investment required

•Reliable, guaranteed delivery•Enables real-time business decisions•Out of box adapters for many enterprise systems

•Standards based integration•High degree of reuse•Wide tool support including open source•Low up front investment

Weakness •Costly over time•Tight coupling•Scalability issues•Opportunities for reuse are slim•Complex to add new application to the architecture

•High upfront cost•Relatively complex design patterns•Requirements for third party middleware

•Lack of transaction support•Demands for more policy•Less established technology

Technologies compared

Future proposal• XML: The ability to store, parse, validate, query and update XML

documents efficiently in the database.

• Web Services: The ability to expose database objects (tables, stored procedures, and so on) as Web services and also be able to invoke external Web services from within the database.

• Asynchronous Message Queuing: The ability to guarantee the delivery of messages, exactly once, to other networked and distributed applications in spite of system failures.

• Event Notification: The ability to distribute important business events to a large number of users and devices, in a format appropriate to the receiver, in an efficient manner.

• Query Notification: The ability for an application to “subscribe” to changes in the databases that affect the results of a specific query and to be notified when the changes take place.

• Security: the security level of access to database through middleware or API should be well defined in order to ensure that data are securely guided between applications that access them.

ERRORS DETECTED IN THE REPORT

• Chapter four contains wrong figure numbers (this was caused by interchanging chapters during re-organisation)

• Chapter 6 section 6.7 (page 102) paragraph 3

• Could not append all codes due to cost of printing in ITU