System Integration Week 7 – Lecture 1

For a successful client/server request We need –To identify the host and process that can provide the service –To transfer messages to/from the requesting process in one host from/to the serving process in another host reliably and quickly –The messages to be understood – both syntax and semantics.

Definitions within this context Syntax – the rules governing the structure of the message – the schema – the format of the message Semantics – the meaning of the words/data/attributes within that structure Remember the message is passed between the two components as a string of bytes or bits. Both components have to share a common syntax and semantic understanding. Both applications have to agree what is to happen with a message

Three problem domains A complete new system where we can predefine the services, the message structures and the data dictionaries Building a new system that is to be integrated with one or more existing systems in the same organisation that may be on different platforms Integrating systems between two or more organisations – some times many hundreds – e.g. a B2B community

Degrees of integration Does it need to be synchronous? Are we integrating processes or just sharing data? Do we need transactional integrity? And we must not forget –Scalability –Heterogeneity –Fault tolerance

Client Trans. Servers Database WEB Server Client Trans. Servers Database WEB Server Client Trans. Servers Database WEB Server Organisation 2 Organisation 1 Application AApplication B Application C

Six different approaches Load balancing Transaction oriented middleware Message oriented middleware (MOM) Remote Procedure Calls (RPCs) Distributed Objects/Components WEB Services Problem: Selecting an approach that is mature V Not positioning the organisation for the future.

Why is this important? Integration of a new application with other systems already in operation, often takes more than 50% of development time

Basic requirements Business rules defining the policies and rules that an organisation adopts to allow a systematised approach to running the organisation The corporate data dictionary defining the name, meaning and format of all data elements (entities and attributes), and the usage of those elements. An architecture for integrating systems

Few organisations acquire all of their applications At the same time From the same vendor Using the same development tools After establishing a corporate data dictionary and business rules and, Mergers happen

v HR Legacy system Global 3 Regions 144 Countries X 3 applications Data warehouse Original entries A real example Frankfurt Tampa Sydney London 800+ data flows

Encoding schemes & Data types How the 8 bit byte represents a character –ASCII 7 & 8 bit, EBCDIC, Unicode, big end V little end. Data types –Integers, Floating point, Character strings – dependent on language and word length

Primary keys in the legacy systems are different and incompatible with a new system. Peoplesoft HR uses a 9 digit staff ID allocated automatically at set-up Legacy payroll system uses a 6 char staff ID The new Student Records system wants to use a code compatible with the 9 digit Student ID An example:

Attributes, while the same in principle, have different names and lengths In system 1 the first line of the address is Called “Address_line_1” With a length of 30 chars In system 2 the same line is Called “StreetName” With a length of 40 chars An so on

Classifications while seemly the same, are subtly different Each university classifies staff into Full-time, Part-time and Casual. You need business rules for this In NSW Universities, full-time is any one working more than 30 hours And in Victorian universities it is any one working more than 25 hours And the classifications, or business rules, are determined by state Government definition An example:

Coding methods are different In one system, Australia is defined by the ISO code as “AU” In another, it is “AUS” And in another, it is “061”

Classifications may differ at the global level between different applications. For tax reasons, the Accounting Department wants Isle of Man and The Channel Islands listed as separate countries But the HR department says they are not and wants them included in the UK A problem when calculating a KPI as Revenue per FTE, by country A business rule is required!

In some countries, governments wants certain information collected, others do not. The US needs ethnic origin and disability collected for equal opportunity statistics But in Europe this is a big no no.

Departments using applications have different priorities, for good reason The HR department wants the HR system to record people when they apply for a job The Accounting department does not want people to be added to the payroll until they are employed Accounting traditionally complains that HR is not as rigorous as it should be in updating personnel details eg. They might not record a change of department prior to the payroll being calculated.

Database oriented systems have different back-up and recovery strategies to legacy systems Legacy systems often take a back-up at the end of an up-date run and if the next run fails then they re-run When back-up strategies are different, there is a danger of missed information or duplicated information – application integrity

New systems go though a number of releases, often adding functionality All adds up to two or three interface changes per week to be developed and tested New functionality More geographies Further applications to Integrate with