210 likes | 344 Views
MastersThesis Presentation. COMPARING DIFFERENT SOFTWARE INTEGRATION TECHNOLOGIES. Author Jones Olaiya Ogunduyilemi (Internet & Software Technology) E-mail: oladjones@itu.dk. Supervisor: Yvonne Dittrich Associate Professor Software Development Group. 04 April 2008. Agenda.
E N D
MastersThesis Presentation COMPARING DIFFERENT SOFTWARE INTEGRATION TECHNOLOGIES Author Jones Olaiya Ogunduyilemi (Internet & Software Technology) E-mail: oladjones@itu.dk Supervisor: Yvonne Dittrich Associate Professor Software Development Group 04 April 2008
Agenda • Introducing the project • Application situation in Minton • Application integration in perspectives • Expectation • Techniques & Technologies • Levels of integration • Criteria & requirements • Patterns • Demonstration (prototypes) • Technologies compared • Observation and future perspectives • Errors detected • 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
Sales CI Sys. HR Inv sys SCM SAP ERP CRM etc DB DB DB DB DB DB DB DB DB Ordering sys Resource Tracking sys. DB DB Applications in Minton
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 integrationTechniques Manual integration (heavily depend on human efforts) • Print re-typing • Copy re-entry Semi – 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)
CI Sys. Inv sys Sales DB DB DB Ordering sys DB POINT – TO - POINT 6 connections 12 interfaces
Sales HR SCM CRM ERP SAP etc Inv sys CI Sys. DB DB DB DB DB DB DB DB DB Ordering sys Resource Tracking sys. DB DB COMPLEXITY 11 applications: 55 connections 110 interfaces
S P S P S P S P P S S S P RCM CI System Sales/Marketing Resource Tracking Middleware Integration Efforts MIDDLEWARE Minton Ordering/ Scheduling Warehouse Management System Accounts Receivable 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
DEMO PROTOTYPE 1: FILE TRANSFER PROTOTYPE 2: REQUEST – REPLY POINT .TO-POINT PROTOTYPE 3: MESSAGING /IBM WEBSPHERE MQ [6.0 PROTO] PROTOTYPE 4 : MIDDLEWARE / DATABASE SCHEMA DETECTION Links: http://www.itu.dk/people/oladjones/DBRWA/users/ PROTOTYPE 5 : WEB SERVICES PROTOTYPE 6: CORBA
Invoicing system Customer info system Central server A P I CI Sys. A P I Inv Sys. FTP FTP Send data Shared folder Fetch data FILE Store data Request data Use data Fetch data DB DB Prototype 1File sharing integration
Request Channel m Inv. Sys (Invoicing System) CI Sys. (Customer Info System) Reply Channel m Prototype 2Request – reply point-to-point Inv Sys CI Sys
Prototype 4MIDDLEWARE / DB SCHEMA DETECTIONLinks: http://www.itu.dk/people/oladjones/DBRWA/users/
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