[go: up one dir, main page]
Scribd
Upload
51 views16 pages

Service-Oriented Architecture: Prof Ehab E. Hassanien Dr. Dina Ezzat

The document discusses integration and loose coupling in service-oriented architecture (SOA). It describes how separate applications in silos make it difficult to provide a consistent view of functionality and data. Integration allows applications to communicate and share data and functionality to avoid duplications. Loose coupling, a key principle of SOA integration, minimizes the effect of changes to one application on others. The document also discusses interface semantics using function names versus payload semantics embedding operations in messages. It provides examples of file sharing, database sharing, and socket-based data sharing between applications.

Uploaded by

Muhammed Abdallah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
51 views16 pages

Service-Oriented Architecture: Prof Ehab E. Hassanien Dr. Dina Ezzat

The document discusses integration and loose coupling in service-oriented architecture (SOA). It describes how separate applications in silos make it difficult to provide a consistent view of functionality and data. Integration allows applications to communicate and share data and functionality to avoid duplications. Loose coupling, a key principle of SOA integration, minimizes the effect of changes to one application on others. The document also discusses interface semantics using function names versus payload semantics embedding operations in messages. It provides examples of file sharing, database sharing, and socket-based data sharing between applications.

Uploaded by

Muhammed Abdallah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 16

Service-Oriented

Architecture
Prof Ehab E. Hassanien
Dr. Dina Ezzat
Integration
Integration
●
With separate applications that operate in their individual silos, it
becomes difficult to provide a consistent and unified view of the
functionality and data in an organization. Of course, large
organizations usually have a large number of applications, and the
problem becomes even harder for these large organizations.
●
In order to solve these problems, the applications must be able to
communicate with each other and be able to share functionality and
data with each other.
●
This sharing of data and functionality helps avoid duplicating data and
functionality and hence provides more consistent and unified data and
functionality to the end user.
●
Designing new applications or modifying existing applications
so that they are able to share data and functionalities is called
software integration.
Loose Coupling
●
Of all the concepts, the idea of loose coupling is the major
driving principle of the march toward SOA-type integration
patterns.
●
This drive for loose coupling has occurred because the number
and kinds of applications being integrated have progressively
become very large.
●
This requires integration patterns to minimize the effect on
other applications due to the changes made to one application.
●
However, the most important business reason for requiring
loose coupling is that businesses require agility to meet today’s
changing business needs.
Loose Vs. Tight Coupling
Interface and Payload Semantics
●
The interaction between a client application and a server application
usually results in the execution of a transaction or activity on the
server side. The client must specify the activity that needs to be
performed on the server side. This specification usually is done in
two different ways:
– The requested transaction or activity can be encoded in the
operation signature of the server component’s interface, or
– it can be embedded in the message itself.
●
In the first case, the requested transaction or activity is specified by
using a self-descriptive function/method name such as
updateBalance() or retrieveBalance().
●
This is referred to as interface semantics and is common in RPC-style
interfaces. The next Figure shows this kind of semantics in a
schematic manner.
Interface Semantics in RPC-style
Interface and Payload Semantics
●
In the second case, the transaction or activity to be
performed is embedded directly in the message. This is
usually done in two ways. The name of the operation/activity
can be included in the header of the message, if the
underlying MOM provides such a field as part of the message
header.

●
Alternatively, the name of the activity/operation can be part
of the application-specific payload. This we refer to as
payload semantics.
– Payload semantics is common when MOMs are employed. These
MOMs provide a generic API with functions such as MQGET() and
MQPUT(). The semantics of these functions is purely technical.
Payload semantics in which the remote functionality
required is encodedin the message
Sockets and Data Sharing
The three significant methods of sharing data
between applications are
1) File-based data sharing,
2) Common database,
3) Sockets.
File-Based Data Sharing

Two applications running on the same computer


exchanging data through a file on the computer’s file
Using the File Transfer Protocol

Two applications running on two different computers


exchanging data through a file. The file is transferred
from one computer to another by the use of the FTP
Tasks that need to be performed
for file-based data sharing
●
■ The software developers for both the application writing to the file and the
application reading from the file must agree on the format of the file.
●
■ The software developers for both the application writing to the file and the
application reading from the file must agree on a file-naming convention.
●
■ The software developers must agree on the directory in which the file
must be created and/or transferred if need be.
●
■ Software developers for data-sharing applications must agree on the
application responsible for deleting the file when it is no longer needed.
●
■ Software developers must implement a locking mechanism that disallows
other applications from reading from the file when one application is writing
to the file.
●
■ If the two applications sharing data through files are running on two
different servers (machines), the software developers must decide on which
application will be responsible for transferring files from one server to the
other.
Tasks that need to be performed
for file-based data sharing (cont.)

1- The software developers for both the application


writing to the file and the application reading from the
file must agree on the format of the file.

2- The software developers for both the application


writing to the file and the application reading from the
file must agree on a file-naming convention.

3- The software developers must agree on the


directory in which the file must be created and/or
transferred if need be.
Tasks that need to be performed
for file-based data sharing
4- Software developers for data-sharing applications must
agree on the application responsible for deleting the file
when it is no longer needed.

5- Software developers must implement a locking


mechanism that disallows other applications from reading
from the file when one application is writing to the file.

6- If the two applications sharing data through files are


running on two different servers (machines), the software
developers must decide on which application will be
responsible for transferring files from one server to the other.
Common Database

You might also like