System Integration Styles

IT31032 SYSTEM INTEGRATION AND ARCHITECTURE

Thilina Samarasinghe
Lecturer | MBA(Gen) | MSc (CyberSec) | BSc (Hons) | CCNA
 Instructions to the reader

• Green Color Links – Read to brush your Knowledge

• Red Color Links – Read for exam purposes

Thilina Samarasinghe | MBA(Gen) | MSc (CyberSec) | BSc (Hons) |

System Integration Styles
System integration is the task of making separate systems work together to produce a unified set of
functionality.

The Systems probably run on multiple computers, which may represent multiple platforms, and may be
geographically dispersed (විසිර ගියා / சிதறடிக்கப்பட்டது). Some of the Systems may be run outside of the
enterprise by business partners or customers. Some Systems may need to be integrated even though they
were not designed for integration and cannot be changed. These issues and others like them are what
make System integration difficult.
Application Integration Criteria

What makes for good application integration?

• If integration needs were always the same, there would only be one integration style. That means Integration
needs change.

• Yet like any complex technological effort, application integration involves a range of considerations and
consequences that should be considered for any integration opportunity.

• The first criterion is application integration itself. If you can develop a single, stand-alone application that
doesn’t need to collaborate with any other applications, you can avoid the whole integration issue entirely.

• Realistically, though, even a simple enterprise has multiple applications, applications that need to work
together to provide a unified experience for the enterprise’s employees, partners, and customers.
The other main decision criteria are:

• Application coupling | how to do

• Integration simplicity | how to achieve
• Integration technology | what are the
• Data format | what are the
• Data timeliness | how to achieve
• Data or functionality | What to invoke
• A synchronicity | what is
Application coupling

• Even integrated applications should minimize their dependencies on each other so that each can
evolve without causing problems for the others.

• ඒකාබද්ධ යයදුම් පවා එකියෙකා මත ඔවුන්යේ යැපීම් අවම කළ යුතුය, එවිට එකියෙකාට ගැටළු ඇති යොකර පද්ධති වර්දෙය විය හැකිය.
• ஒருங்கிணைக்கப்பட்ட பயன்பாடுகள் கூட, ஒன்றுக்ககான்று தங்களுணடய சார்புகணைக் குணறக்க வேண்டும், இதனால் அணைப்புகள்
ஒன்றுக்ககான்று சிக்கல்கணை ஏற்படுத்தாைல் ேைர முடியும்.

• Tightly coupled systems make numerous assumptions about how the other systems work.

• තදින් බැඳුනු පද්ධති අයෙකුත් පද්ධති ක්‍රියා කරෙ ආකාරය පිළිබඳව යබායහෝ උපකල්පෙ කරයි. යමය එක්තරා බාධාව.
• இறுக்கைாக இணைக்கப்பட்ட அணைப்புகள் ைற்ற அணைப்புகள் எவ்ோறு கசயல்படுகின்றன என்பணதப் பற்றி பல அனுைானங்கணைச்
கசய்கின்றன. இது ஒரு தணடயாக உள்ைது.
Application coupling

•when the systems change and break those assumptions, the integration breaks.​

•එෙම් පද්ධති යවෙස් වෙ විට සහ එම උපකල්පෙ බිඳ දැමූ විට, ඒකාබද්ධතාවය බිඳ වැයේ
•அதாேது, அணைப்புகள் ைாறும்வபாது ைற்றும் அந்த அனுைானங்கள் உணடக்கப்படும்வபாது, ஒருங்கிணைவு உணடகிறது

•The interface for integrating systems should be specific enough to implement useful functionality, but general enough to
allow that implementation to change as needed.
•පද්ධති ඒකාබද්ධ කිරීම සඳහා වෙ අතුරු මුහුණත, ප්‍රයයෝජෙවත් ක්‍රියාකාරීත්වය ක්‍රියාත්මක කිරීමට ප්‍රමාණවත් විය යුතුය, ෙමුත් අවශ්‍ය පරිදි එම ක්‍රියාවට ෙැැංවීමට ඉඩ දීමට
තරම් සාමාෙය විය යුතුය.

•கணினி ஒருங்கிணைப்புக்கான இணடமுகம் பயனுள்ை கசயல்பாட்ணடச்கசயல்படுத்த வபாதுைானதாக இருக்க வேண்டும், ஆனால் வதணேக்வகற்ப அணத கசயல்
படுத்த அனுைதிக்கும் அைவுக்கு கபாதுோனதாக இருக்க வேண்டும்.​
Integration simplicity — When integrating a system into an enterprise, developers should strive to minimize
changing the application and minimize the amount of integration code needed. Yet changes and new code will
usually be necessary to provide good integration functionality

Integration technology — Different integration techniques require varying amounts of specialized software
and hardware

Data format — Integrated applications must agree on the format of the data they exchange or must have an
intermediate translator to unify applications that insist on different data formats.
Data timeliness — Integration should minimize the length of time between when one application decides to
share some data and other applications have that data. Data should be exchanged frequently in small chunks,
rather than waiting to exchange a large set of unrelated items. Applications should be informed as soon as
shared data is ready for consumption. Latency in data sharing must be factored into the integration design; the
longer sharing can take, the more opportunity for shared data to become stale (පරණයි/பழணையான), and the more
complex integration becomes.

Data or functionality — Integrated applications may not want to simply share data, they may wish to share
functionality such that each application can invoke (ඉල්ලසිටිෙවා /வகாருகிறது) the functionality in the others.
A synchronicity — In a synchronous programming model, things happen one at a time. When you call a
function that performs a long-running action, it returns only when the action has finished, and it can return
the result. This stops your program for the time the action takes.

An asynchronous model allows multiple things to happen at the same time.

Reference Link

As you can see, there are several different criteria that must be considered when choosing and
designing an integration approach. The question then becomes:

How do we meet the criteria?

நா ம் எப்படி அளவுகக ல்களள சந்திக்கிக ம்?
ක ොයි විදිහටද නිර්ණොය අපි සපත රගන්කන්
Which integration approaches best address which of these criteria?
There’s more than one approach (ප්රයේශ්‍ය\அணுகுமுணற) for integrating systems.

Each approach addresses some of the integration criteria better than others.

The various approaches can be summed up in four main integration styles:

• File Transfer — Have each systems produce files of shared data for others to consume and consume
files that others have produced.

• Shared Database — Have the systems store the data they wish to share in a common database.

• Remote Procedure Invocation — Have each system expose some of its procedures so that they can
be invoked remotely, and have systems invoke those to run behavior and exchange data.

• Messaging — Have each system connect to a common messaging system, and exchange data and
invoke behavior using messages.

Each style has its advantages and disadvantages. Two systems may integrate using multiple styles such that
each point of integration takes advantage of the style that suits it best. Likewise, a system may use different
styles to integrate with different systems . Some integration approaches can best be viewed as a hybrid of
multiple styles
File Transfer
File Transfer
An enterprise has multiple systems that are being built independently, with different languages and platforms.

Organizations,
• Different system are built at different times, leading to different technology choices .
• Different systems are built by different people, whose experience and preferences lead them to different
approaches to building applications.

Developers may Think,

• Getting an application out and delivering value is more important than ensuring that integration is
addressed, especially when that integration isn't adding any value to the application under development.

How can integrate multiple systems so that they work together and can exchange information?
In an ideal world, you might imagine an organization operating from a single cohesive piece of
software, designed from the beginning to work in a unified and coherent way. Of course, even the
smallest operations don't work like that. Multiple pieces of software handle different aspects of the
enterprise.

• As a result, any organization must worry about sharing information between very divergent
applications.

• These can be written in different languages, based on different platforms, and with some different
assumptions about how the business operates.

• Tying such systems (Intergrating) together requires a lot of knowledge of understanding how to
link together systems on both a business level and a technical level.
Solution to a vivid Systems to integrate,

What is needed is a common data transfer mechanism that can be used by a variety of languages and
platforms yet seems natural to each. It should require a minimal amount of specialized hardware and
software, making use of that the enterprise already has available.
Files are a universal storage mechanism, built into any enterprise operating system, available from any
enterprise language. The simplest approach would be to somehow integrate the applications using files*.

*Example file is An XML file which is used to store data in the form of hierarchical elements. Data stored in XML files can
be read by computer programs
Have each application produce files containing information that other applications need to consume. Integrators
take the responsibility of transforming files into different formats. Produce the files at regular intervals
according to the nature of the business.
An important decision with files is what format to use. Very rarely will the output of one application be exactly
what's needed for another, so you'll have to do a fair bit of processing of files along the way. Not just do all the
applications that use a file have to read it, you also must be able to use processing tools on it. As a result,
standard file formats have grown up over time. Mainframe systems commonly use data feeds based on the file
system formats of COBOL. Unix systems use text-based files. The modern fashion is to use XML. An industry of
readers, writers, and transformation tools has built up around each of these formats.

Reference Link
Draw backs of File Transfer style

• Read while write

The applications will need to implement a locking mechanism or follow a timing convention to ensure that one
application is not trying to read the file while another is still writing it.

• Infrequency
One of the most obvious issues with File Transfer is that updates tend to occur infrequently, as a result systems can
get out of synchronization.

Ex-
A customer management system can process a change of address and produce an extract file each night, but the
billing system may send out the bill to old address on the same day
Draw backs of File Transfer style

• Inconsistency
If a customer changes his address on the same day with two different systems, but one of them makes an error and
gets the wrong street name, it will create two inconsistent addresses for a customer. need some way to figure out
how to resolve this. The longer the period between file transfer, the more likely and more painful this problem will
become.

• File Management
managing all the files that get produced, ensuring they are all read, and none get lost. This goes beyond what file
system-based approaches can do
Draw backs of File Transfer style

• Lack of Timeliness

File Transfer enables systems to share data, but can lack timeliness
timeliness of integration is often a critical issue.

If changes do not work their way quickly through a family of systems, incorrect things may occur due to the staleness of
data.
For modern businesses, everyone must have the latest data as much as possible. Not just this reduce errors, it also
increases people's trust in the data. Rapid updates also allow inconsistencies to be handled better.

The more frequently synchronize, the less likely to get inconsistencies and the less effort they are to deal with.
Draw backs of File Transfer style

File Transfer enables systems to share data, but can lack timeliness

But however rapid the changes, there's still going to be problems. If an address is updated inconsistently in rapid
succession, how to decide which one is the true address? take each piece of data and say that one application is the
master source for that data, but then must remember who is the master for what data.

File Transfer also may not enforce data format sufficiently. Many of the problems in integration come from incompatible
ways of looking at the data. Often these represent subtle business issues that can have a huge effect. These cases of
*semantic dissonance are much harder to deal with than inconsistent data formats.

*semantic dissonance would refer to lack of agreement in meaning or a lack of consistency in language.
Shared Database
What is needed is a central, agreed-upon datastore that all the systems share, so that any of them
have access to any of the shared data whenever they need it.

Integrate systems by having them store their data in a single Shared Database.
• If a family of integrated systems all rely on the same database, that the systems can mostly* be
consistent.

• Do get simultaneous updates to a single piece of data from different sources.

• Since the time between updates is so small, any errors are much easier to find and fix.

Shared Database is made much easier by the widespread use of SQL-based relational databases. Pretty
much all application development platforms can work with SQL, often with quite sophisticated tools.

No need to worry about multiple file formats.

* mostly - යබායහෝ දුරට கபரும்பாலும்

Since any application pretty much must use SQL anyway this avoid adding another technology for everyone
to master.

Since everyone is using the same database, this forces out problems in semantic dissonance.
Draw backs of shared database style

One of the biggest difficulties with Shared Database is producing a suitable design for the shared database.
Producing a unified schema that can meet the needs of multiple systems is a very difficult exercise, often
resulting in a schema that system programmers find difficult to work with.

Multiple applications using a Shared Database to frequently read and modify the same data can
cause performance bottlenecks and even deadlocks as each application locks others out of the data. When
the applications are distributed across multiple computers, the database must be distributed as well so that
each application can access the database locally, which confuses the issue of which computer the data
should be stored on. A distributed database with locking conflicts can easily become a performance
nightmare.
Thank you