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 componentsas a string of bytes or bits.

Both components have to share a common syntax and semanticunderstanding.

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 2Organisation 1

Application A Application 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 positioningthe 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

vHR

Legacysystem

Global3 Regions 144 Countries

X 3 applications

Datawarehouse

Original entries

A real example

FrankfurtTampaSydney

London800+ 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 ISO3166-1 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 toIntegrate with