View
216
Download
0
Tags:
Embed Size (px)
Citation preview
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