1. COMPARING DIFFERENT SOFTWARE INTEGRATION TECHNOLOGIES Author Jones Olaiya Ogunduyilemi (Internet & Software Technology) E-mail: oladjones@itu.dkoladjones@itu.dk Supervisor: Yvonne Dittrich Associate Professor Software Development Group MastersThesis Presentation 04 April 2008

2. Agenda 1.Introducing the project 2.Application situation in Minton 3.Application integration in perspectives 4.Expectation 5.Techniques & Technologies 6.Levels of integration 7.Criteria & requirements 8.Patterns 9.Demonstration (prototypes) 10.Technologies compared 11.Observation and future perspectives 12.Errors detected 13.Questions

3. 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

4. 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

5. 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)

6. 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

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

8. POINT – TO - POINT CI Sys. DB Ordering sys DB Inv sys DB Sales DB 6 connections 12 interfaces

9. 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

10. Middleware Integration Efforts RCM CI System Ordering/ Scheduling Sales/Marketing Resource Tracking Warehouse Management System Accounts Receivable P S S P S P S P S P S P S Minton MIDDLEWARE 7 applications: 7 connections 14 interfaces

11. 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.

12. 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.

13. 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

14. Criteria and requirements CriteriaRequirements Application coupling Scalability Interoperability Data format Availability Cross platform Low cost Data Security Remote Communication (synchronicity) Maintainability and reusability Performance Efficiency Reliability Data consistency

15. 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/http://www.itu.dk/people/oladjones/DBRWA/users/ PROTOTYPE 5 : WEB SERVICES PROTOTYPE 6: CORBA

16. Prototype 1 File sharing integration Customer info system CI Sys. APIAPI Invoicing system Inv Sys. APIAPI DB Central server FILE Shared folder Fetch data Send data Fetch data Request data DB Store data Use data FTP

17. Prototype 2 Request – reply point-to-point Inv. Sys (Invoicing System) CI Sys. (Customer Info System) Request Channel Reply Channel m m Inv SysCI Sys

18. Prototype 4 MIDDLEWARE / DB SCHEMA DETECTION Links: http://www.itu.dk/people/oladjones/DBRWA/users/http://www.itu.dk/people/oladjones/DBRWA/users/

19. CriteriaPoint-to-pointMiddlewareService oriented Scalability Scalability is not guaranteed in a complex enterprise solution 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

20. 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.

21. 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