Lecture-IPT-Chapter-1A-INTERSYSTEM COMMUNICATION

ASSOSA University
College of Computing and Informatics

Department of Information Technology
IPT: Integrative Programming and Technologies

(ITEC4131)
By: Tarekegn D.(MSc.) @2021/22.

 Course Description
 IPT looks at systems integration with focus on communication
mechanisms and data standardization.
 learn how to choose by considering platform, data structure
similarity/dissimilarity as well as client requirements, to
represent data structure and how to transport data between
objects using XML related technologies.
Q: Why need to learn IPT?
 Legacy systems were built with many incompatible middleware
 Applications on the same middleware can work together

• But, applications on diffrent middleware cannot!
03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 2
 General Objectives of this course
 At the end of this course you will be able to:
CH 1: Define the concept of Intersystem Communication and

types
of system integration architecture and technologies
 Identify the role of Middleware , CORBA , DCOM , and
RMI , and web services(WSDL,SOAP,UDDI) in integrated
system.
 Learn the concept of Network programming; Message and
queuing services
 Apply system
03/06/2022
integration technologies to glue together
Copyright©2021/22 Tarekegn D.(MSc)\ 3
General Objectives of this course...
CH 2: Define the concept of data mapping and exchange:
Metadata;
Data representation and encoding;

 Create valid XML documents to apply DTD, XML schemas;
Parsing XML documents; XSL, XSLT and XPath
 Apply Data Mapping and Exchange technologies to represent
data between different applications.
CH3: Use Integrative Coding: Design Patterns; Interfaces;

Inheritance to develop sample applications
CH4: Finally discuss Miscellaneous Issues: Adopt and Adapt vs.
make; Versioning and version control
CHAPTER ONE
OVERVIEW OF INTERSYSTEM
COMMUNICATION
By: Tarekegn D.(MSc.) @2019/20.

.
Review of Key Concepts
 What is the fundamental concept of OOP?
 It is Class
– is an abstract data type, with an associated module
that implements it
– Writing this as a conceptual equation: Type + Module = Class
– Modules and types look very different
 Modules give structure to the implementation
 Types specifies how each part can be used

 what is the very core of the notion of class in OOP?
 It is interface
 From Type + Module = Class,Type&Module share the interface
» In modules, the interface selects the public part
» In types, the interface describes the allowed operations as
well as their properties
 As a result, the interface is at the very core of the notion of class

Review of Key Concepts...
 what is the main OOP extension mechanism?
– It is Subclassing
– Subclassing is affected by the dual nature of classes
– Writing this as a conceptual equation
Subtyping + Inheritance = Subclassing
 Subtyping : a partial order on types
 A valid operation on a type is also valid on a subtype
 Liskov Substitutability Principle:
• If S is a subtype of T, then replacing objects of type T
with objects of type S does not alter the properties of a
program
 Inheritance :a partial order on modules
 A module grants special access to its sub-modules
 Open/Closed Principle:
• An OO language must allow the
creation of modules closed for use but open for extension
 What is the basic building block of OOP?
 It is object
• is an individual unit of run-time data storage used
• Each object is capable of receiving msgs, processing data,
and sending msgs to other objects;
• Methods and data together form the object’s interface with the outside
world or other objects.
 What is the fundamental concept of Distributed OOP?
 It is Remote Interface
– Distributed objects have a separation between interfaces and
objects that implement the interfaces
• interfaces and the objects are in same/different machines.
 Allow programs to treat remote objects just like local objects
• remote references and remote invocation
 Recent implementation: Remote Object Invocation

 The basic building block of TCP/P Reference Model

 The basic building block of OSI Reference Model

Terminologies
 Remote object- is an object on another computer
 Client object- is the object making the request (sending a message
to the other object)
 Server object- is the object receiving the request
 Rmiregistry- is a special server that looks up objects by
name(Hopefully, the name is unique!)
 Rmic- is a special compiler for creating stub (client) and skeleton
(server) classes
 Marshalling– converting remote method arguments to a stream of
bytes in a stub
 Unmarshaling– reconstructing method arguments from a stream of
bytes in a skeleton

Terminologies...
 Interface
– is a point where interaction occurs between two systems,
devices, programs, etc.
– to be useful for integration, an interface must have stable and
well-defined characteristics.
– refer to a hardware or software component that translates or
converts from one interface to another interface(Adapt)
 Media
– is the medium with different sets of physical properties
through which data is conveyed.
– the common element among these various types of physical
media is
• the MAC protocol to manages access to the media for
outgoing/received messages.
Terminologies...
 Middleware
– is software used to “glue” together disparate systems without
those systems needing to know anything about each other.
– Knowledge of both systems is contained in the middleware.
 A protocol
– is a set of rules governing the exchange or transmission of
data electronically between devices.
– is like a language; both devices must understand the same
language in order to exchange data.
– for example, the network level might interact using Ethernet.
– the operating systems might interact using TCP/IP.

Terminologies...
 Data Format
– is the representation of text characters used as prerequisite
when exchange of information between the systems is takes
place.
 System
– is a group of hardware and software components that work
together in a cohesive manner to perform a task.
– a personal computer with a video card, memory, a disk drive
and an operating system is also a system.
 Services
– a unit of functionality that is designed to be deployed
independently and reused by multiple systems.

Terminologies...
 Components
– a unit of functionality that is designed to serve as a part of a
system or application.
– components are objects
• Data and associated operations
– Connectors are messages and method invocations
 Layers
– it is common to separate components into layers such that
they hide their implementation behind an interface.
– each layer acts as a
• Server: service provider to layers “above”
• Client: service consumer of layer(s) “below”
– connectors are protocols of layer interaction
Terminologies...
 An Application Programming Interface (API)
– is a defined and documented software interface that a software
program may use to interact with a system or a specific sub-
system or feature of a system.
 Electronic Data Interchange (EDI)
 the standardized exchange of information, data (documents)
between the IT systems of organizations.
 organizations documents are also referred to as messages.
 Integration
– is the process of inter-connecting one system with another
system in order to provide a useful exchange of information,
data and/or control between the systems.

Terminologies...
 System Integration
– is a process whereby a cohesive system is created from
components that were not specifically designed to work
together.
– components of an integrated system are often systems
in their own right.
 Systems Integration Architecture
– provides a bridge between the heterogeneous operational
applications and platforms.
– ties together the mix of platforms, operating systems,
transports, and applications.
– encompasses the multiple layers of new and existing systems
and the middle ware in between.
– enables new applications to use existing resources
1. Intersystem Communication
 A system communication is defined as the connection of two or
more IT systems(Inter vs Intra system Communication)
 for the purpose of sharing data and other information resources.
 What is Intersystem Communication?

• the communication between the set of heterogeneous systems
that are integrated together.
 which puts together many heterogeneous subsystems
 the produced information objects are extremely different,

 yet should be contribute to the same process

...
 Q: How can establish the system which makes combination of
independent systems possible and relatively easy to user?
 Ans:
 By using level of design in integrated systems architecture that
involves
• the description of elements from which systems are built,
• interactions among those elements,

• patterns that guide their structure, and
• constraints on these patterns.

Representation Concepts for Architecture
 Component: An object with independent existence, i.e.
 A module, process, procedure, or variable
 Interface: A typed object that denotes a logical point of interaction
between a component and its environment.
 Configuration: A collection of Constraints that wire the objects
into a specific architecture
 Mapping: A relationship that defines a syntactical translation from
the language of an abstract architecture to the language of a
concrete architecture
 Architectural Style: A language of design elements, constraints
that determine how they are to be used and a semantic definition of
the connectors associated with this style.

1.1 Architectures for integrating system
• It provides a bridge between the heterogeneous
operational applications and platforms.
• A well-designed system, encompasses
– all of the system elements
– the relationships between the elements and
– the user interfaces to those elements.
– usually keep working no matter how many
applications are exchanged on.
– Why?
• Because it has good integrating architectural
design, which is the backbone of any complex
computer system.
1.1 Architectures for integrating system…
 Types of well-known system Integration Architectures
A. Point-To-Point Architecture for System Integration(P2P-SIA)
Tightly coupled application components communication by
using participating devices known as “Peers.“
B. Hub And Spoke Architecture for System Integration(H-SIA)
Cross application components communication decoupled by
centeral device or server called a “ hub “.
C. Distributed Architecture for System Integration(D-SIA)
Distributed application components communication by using
smaller device known as “Agents.“
D. Service Oriented Architecture for System Integration (SOA-
SIA)
loosely coupled application services communication by
using concept known as “we services.“
A. P2P-SIA
• is the original architecture used to support systems integration
• the simplest of the integration architectures

A. P2P-SIA…
 Advantages
– are often fast and efficient
– Simple to create for few number of applications
 Disadvantages
as the number of applications increases;
– the overall complexity of the environment increases
– result in high maintenance costs and a lack of flexibility when it
becomes necessary to make changes

B. H-SIA
• worked on the principle that:
– all information coming from the applications had to be
processed within a single machine or server called a "hub".
– Hub
• Acting as a central point of control
• dealt with all message processing including
– routing, splitting and combining of messages, mapping,
and so on
– Hub and Spoke implementations decouple the sending and
receiving applications
• How the Hub and Spoke different from Point-to-Point?
– the applications on either side of the hub can be modified
independently of each other
03/06/2022 Copyright©2021/22 Tarekegn D. 25
(MSc)\
B. H-SIA…

(MSc)\
B. H-SIA…
 Advantages
– the integration environment becomes less complex
– achieving an easily controlled and managed environment
 Disadvantages
– The initial setup of two-way communications can be
challenging
– Both the source and target applications need some knowledge
of each other in order to process messages
– As the number and complexity of processes increase,
• performance can suffer and
• hubs often become difficult to manage, maintain, and
extend.

C. D-SIA
• Is a solution to the Hub and Spoke scalability issue
• by performing message translation, routing, splitting, and
combining closer to the source and target systems
– by using smaller computers known as “Agents.“
• Agents
– are connected to just one system and reduce the processing load
on that system
– take information from the application they are connected to,
then process it,
– and send it to any target application(s) interested in receiving
that information

C. D-SIA...
• Tier-Architectures of Applications
– Two-tier architecture: Clients and Servers
– Three-tier architecture:
• First tier: clients with GUI
• Middle tier: business logic
• Third tier: System services (databases)
– Peer-to-peer architecture: Equal peers

C. D-SIA…

C. D-SIA…
 Advantages
– is governed by centralized process rules
– Efficient processing by distributing the workload among
dedicated processors
– able to grow relatively easily
 Disadvantages
– Many organizations have a mix of platforms and operating
systems thus integrating them all will increase complexity

D. SOA-SIA
• is essentially an enhanced version of distributed integration
architecture by
– using concept known as “web service“
• Uses loosely coupled software services to support the requirements
of business processes and software users
• Provides an integrated environment which spreads out the
workload, breaking down the different "silos" of business
functionality and operations.
• an application can customize and/or change the individual pieces or
"services" that it uses penning their processes to other applications
• vast and complex component based applications can be developed

D. SOA-SIA …

Middleware technology
• The traditional middleware technology definition
• It lies in the middle between the OS and the applications
• stresses vertical layers

• Applications on top of middleware(top interfaces),
middleware on top of the OS (bottom interfaces)
• The modern middleware technology definition
• The middleware lies in the middle between Application-to-

application and middleware-to-middleware
• emphasis on horizontal communication
• A key feature of middle ware is interoperability
Integrative middleware technology
• But, many incompatible middleware systems exist
• Applications on middle ware A can work together

• Applications on middleware B can work together, too
• But, A-applications and B-applications cannot!
• The integrative middleware technology definition

• Any program design that serves to "glue together" or mediate
between two separate and often already existing programs
• This definition also emphasis on horizontal communication

Integrative middleware technology...
• The most common SW type that enables integration b/n
application/system
» program/component written in one programming language,
running on one platform to interact with an application
object across the network that are written in other
programming languages and running on other platforms
» a layer of software to mask heterogeneity and to provide a
convenient programming model to application
programmers.
» the primary role is to transfer data between applications.
» decouple the Frontend and Backend applications
– in order to enable changes on one side to be transparent
to other side

• The primary functions are
– data generation
– Validation
– Authorization
– Conversion and re-formatting
– transaction mapping and logging.
• The primary services are:

 communication facilities
 naming remote entities(objects)&persistence(distributed file
system)
 distributed transactions and facilities for security

 An adapted Middleware reference model with layers, interfaces,
and protocols for networked communication.
Middleware

• Middleware Protocols
 a middleware is an application that contains general-purpose
protocols to provide services
 example of middleware services
 authentication and authorization services
 distributed transactions (commit protocols; locking
mechanisms)
 middleware communication protocols (calling a procedure or
invoking an object remotely, synchronizing streams for real-
time data, multicast services)
 hence an adapted reference model for networked
communications is required

• Presentation layer:
– to provide common data formatting/representation (wrapping
for tunneling, compression, character sets, (un)marshalling etc.)
in heterogeneous environment for object
• Session layer :
– Map object references to hosts to provide a series of related
connection-oriented transmissions between network nodes.
<URL:http://192.168.1.10:8080/Middleare/mywebservice.java>
– Implements object activation policies in the object adapter
– Object adapters need to be able to start up severs
• which register in an implementation repository or registry
– Implement operation dispatch
– Implement synchronization

• DCE(Distributed Computing Environment)
• RPC: Remote Procedure Calls
• Remote Object Invocation(ROI)

• DCOM: Distributed Component Object Model
(Microsoft, homogeneous implementation)
• CORBA: Common Object Request Broker
Architecture (OMG, heterogeneous)
• Java RMI (Oracle, homogeneous)
• Web Service (WS) – (Any, heterogeneous)
• Message Queuing Services - Sockets

• Difference
– Compile-time vs Run-time Objects
• Compile-time objects are dependent on particular
programming language.
• Run-time objects, the implementation is left “open” and this
approach to object-based distributed systems allows an
application to be constructed from objects written in multiple
languages.
– Run-time objects scheme may use object adapters that act as
wrappers that give implementations an object appearance.

• Intra-enterprise
• Most middleware technology has been designed for private

• Inter-enterprise
– Middleware technology has been designed for public
– adds at least two challenges

• Firewalls( & inter-enterprise security in general)
• Different middleware may be used at the two ends
• As well as different operating system, languages, etc

• So, what is solution?
• As a solution:
• Web Services
• Technology neutral interfaces to packages
• forget the idea of a single middleware technology in

intra-enterprise
• aims to address challenges of inter-enterprise
• high-level communication protocols
– remote procedure calls (RPC)
– remote object invocation (RMI,CORBA,DCOM,WS)

DCE(Distributed Computing Environment)
• is Architecture proposed by OSF
– defined and promoted by the Open Systems Foundation (OSF).
– Goal: to standardize an open UNIX environment to support
distributed computing
• First product from OSF
• Integrated package of software and tools for developing
distributed applications on an existing OS (UNIX or non-
UNIX)
• Hierarchically layered architecture
• is best described as an influential early middleware product
• subsequently fell behind in the marketplace due to
– its lack of standardized support for object-oriented languages.

DCE... Why DCE ?
– Provides tools( DCE threads, RPC) and services( Directory
service et) to support distributed applications
– DCE components are well integrated
• Placement of each service in the hierarchically layered
architecture is important.
– Provides interoperability and portability across heterogeneous
platforms
– Supports data sharing
– Interoperates with global computing environments

DCE... Hierarchy
• From bottom to top
– Kernel and Transport Service
– Processes and Threads
– Basic computational units supported by the kernel.
– Everything else is a user-level component that
communicate via RPC and group comm.
– RPC and group communication
– Basic system services
– Time, directory naming
– Distributed File Service
– Distributed Services
– Concurrency control, group management
– Applications
– Security Services(Left) and management Services(Right)
DCE... Architecture overview

DCE... Supports Key Features
• The client server model
• Remote Procedure call model
• Data sharing model (Directory service, DFS)
• Distributed component Model
• Proven multi-platform interoperability.
• A mature set of relatively low-level support services.
• A mature interoperability protocol that is also used by DCOM.
• Support for object-like access to remote components.
• A lack until recently of any standard way to specify objects in its
IDL.

CORBA(Common ORB Architecture)
• Specification designed by An Object Management Group's (OMG)

– is a standard or specification and not a particular piece of
software.
– Several implementations of the CORBA standard
• vendor-independent architecture
– open infrastructure that applications employed to work together
over networks.
– Enables enterprise-wide integrated computing by providing
interoperability between components.
– The components can be written in different languages, for
different platforms, and by different vendors.
• A common analogy is to consider CORBA as a software bus,
similar in function to the hardware bus

CORBA...
• can work with any number of clients and any number of servers
• also includes interfaces for specific industries:
– medical devices, telecom data streaming, and finance /currency
• Object web-the marriage of distributed objects &WWW
• Major computing companies chosen CORBA as the common way
to connect distributed objects across the internet and intranet
– sun, JavaSoft, IBM, Netscape, Apple, Oracle, BEA Systems..
• What features of CORBA lets you incorporate legacy systems
(existing systems) within the bus?
– It uses objects as unifying metaphor(representation)
– Entire system is self-described and component based
– Specification of a service is always separated from
implementation

CORBA...
Q. Why we sound CORBA is integrating Middleware technology
– Because
• it is a standard that enables an application object written in
one programming language, running on one platform to
interact with an application object across the network that
are written in other programming languages and running on
other platforms
• with its Legacy integration, rich distributed object
infrastructure, Location transparency, Network transparency,
Direct object communication, Dynamic Invocation Interface
 Example: a client application object written in C++ and running
under Windows can communicate with a server application object
on a remote machine written in Java running under LINUX/UNIX.

CORBA...
Object management architecture (OMA)
Overall OMA consists 3-basic components

CORBA...
1. Object Request Broker (ORB)
– the core of any CORBA application integration.
– responsible for all communication
• locating objects
– implementation specific
– finding the object implementation for the request,
– known IOR(Inter-Object Reference)
– preparing the object implementation to receive the
request,
• transferring invocations and return values
• communicating the data making up the request.
• notifying other ORBs of hosted Objects
• must be able to communicate IDL invocations via IIOP
CORBA...
• If an ORB is OMG compliant, then it is interoperable with all other
OMG compliant ORBs
• The structure of CORBA ORB architecture with diverse interfaces:

CORBA...
• Client Side:
• Client IDL Stubs : static interface to object services.
• DII (Dynamic invocation interface) :discover methods to be
invoked at run time
• Interface repository APIs : database containing registered
component interface definitions and which can be queried at
runtime
• Whenever an interface definition is compiled, the IDL
compiler assigns a repository identifier to that interface.

CORBA...
• Server Side:
• Server IDL skeleton : static interfaces to the service
exported by the server
• DSI(Dynamic skeleton interface) : run time binding
mechanism for servers to handle incoming method calls.
• Object Adapter : provides run time environment for
instantiating server objects, passing requests to them, and
assigning them object Ids.
• Implementation repository : database containing the
implementation (code, and possibly also state) of objects.
• run time repository of information a server provides.
• an object adaptor could contact to find out exactly what
needs to be done.
CORBA...
• Between Client and Server
• IDL compiler:
• specific program that has defined mappings for
application programming language.
• supports IDL code compilation to generate Client IDL
Stubs/Skeleton
• ORB interface:
• Common static interfaces to the object services in
client side and service exported by the server side

CORBA...
2. Horizontal facilities
• consist of general-purpose high-level services that are
independent of application domains.
• Collection of IDL defined frameworks that provide services
of direct use to application objects.
• Such as: User interface, Information management, System
management, Task management
• Examples : mobile agents , data interchange, workflow ,
printing facilities, firewalls etc.
3. Vertical facilities
• consist of high-level services that are targeted to a specific
application domain.
• Examples electronic commerce, banking, manufacturing.

CORBA... CORBA Components
• IDL (Interface Definition Language)
• Client/Server CORBA Objects
• ORBs(Object Request Brokers)
• GIOP / IIOP(General/Internet Inter ORB Protocols)

CORBA... IDL Architecture
 Defines public interface for any CORBA object.
 Client and Server
implemented based on
compilation of the IDL
 OMG has defined mappings
for:
 C, C++, Java, COBOL,
Smalltalk, ADA, Lisp,

Python, and IDLscript

CORBA... IDL Features
• Features :
– Pass by reference and by value
– In, out, and inout parameters
– Inheritance, polymorphism, encapsulation
– Throwing of exceptions
– The Any Type (resolved at runtime)
– Callbacks
• Enables Peer-to-Peer Object Communication.
– Also supports:
• structs, unions, enumerations, all c++ scalars, arrays,
sequences, octets, strings, constants, and typedefs.

CORBA... Client / Server Objects
• Abstract objects based upon a concrete implementation
 Do not have their own implementation.
 The elements of a CORBA object (interface, implementation,
and location) are held rendered via other elements.
• Implemented via a Servant
 A servant is a block of code (usually an instance of a class)
which implements the public interface of the CORBA object.
 Depending on the server policies, there may or may not be
multiple instances of the servant and it may or may not be
multi-threaded.
• Configured in code or at server startup
 Unlike COM+ and EJB, the policies for a CORBA object
which control things such as:
 Security, threading, and persistence are not console
configurable

CORBA... Object Model
 Has a traditional remote object model
 an object residing at an object server is remote accessible

through proxies
 All CORBA specifications are given by means of interface
descriptions, expressed in an Interface Definition Language
(IDL).
– An interface is a collection of methods and their parameters
– It provides a precise syntax for expressing methods and their

parameters.
– objects specify which interfaces they implement.
CORBA... Object services
• provide basic functionality
• includes creating objects, controlling access to objects,
keeping track of relocated objects and to consistently
maintain relationship between objects.
• The Naming Service :
• which allows clients to find objects based on names;
• Persistence service :
• provides an interface to store components on storage servers.
• Event Service :
• Allows components on bus to dynamically register or
unregister interest in events.
• Load Balancing
• Fail-over support and Security
CORBA... Communication Models
 Invocation object models supported in CORBA are the following.
Request type Failure semantics Description
Synchronous At-most-once Caller blocks until a response is

returned or an exception is
raised
One-way Best effort delivery Caller continues immediately

without waiting for any response
from the server
Deferred At-most-once Caller continues immediately

synchronous and can later block until
response is delivered
03/06/2022 66
Copyright©2021/22 Tarekegn D.(MSc)\
CORBA... Application Implementing involves in
general the following steps

For example implementing a CORBA application in
Java involves the following steps

CORBA... Advantages
– Rapid development of API’s
– Inter-language and operating system operability
• language mappings support : Java, C, C++, COBOL, IDL(CORBA's
own Interface Description Language), Ada, and SmallTalk…
– IIOP faster than HTTP
– Legacy integration
• associated with software that is outdated
– Rich distributed object infrastructure
• Location transparency
– Hides where it really located
• Network transparency
– Hides how it really connected

DCOM (Distributed Component Object Model)
 designed by Microsoft .NET initiative
 the distributed extension to COM (Component Object Model)
that builds an object remote procedure call (ORPC) layer on top
of DCE RPC to support remote objects
• provides the same functionality but across machines over a
network.
• can also work on a network within an enterprise or on other
networks besides the public Internet(uses TCP/IP and HTTP)
• a protocol that enables software components to communicate directly
over a network in a reliable, secure, and efficient manner.

DCOM…
 an Application-level protocol for object-oriented uses the
RPC(Remote Procedural Call) mechanism to transparently send
and receive information between COM components (i.e., clients
and servers) on the same network.
 Addresses issues such as:
– Interoperability: Different applications, languages
– Versioning: Compatibility between a new version of a
server and old versions of clients
– New interfaces should preserve the old interface
– Naming: Use Globally unique identifiers

DCOM…
Properties of DCOM
 Distributed shared memory management
– provides interfaces for distributed components to share memory
 Network interoperability and transparency
 Dynamic loading and unloading

– manages reference counts to objects
– Unloads objects whose reference count is 0

DCOM…
 Services of DCOM
 responsible for initializing a connection between components, and
– Negotiating protocols for communication
 provides support for persistent storage

– Objects can persist
 Components can be assigned “intelligent names” called monikers

DCOM Architecture
 COM: Adds facilities to communicate across process and machine

boundaries.
 SCM: Service Control Manager, responsible for activating objects
 Proxy marshaler: handles the way that object references are passed between
different machines.
 Creating objects
 DCOM provides functions to create objects given a server name and a class id
– The SCM on the client connects to the SCM of the server and requests
creation of the object
 One of the fundamental rules of DCOM is that a DCOM object can only be
accessed through an interface.
 The client program is completely isolated from the server's implementation
through interfaces.
 The client program knows nothing about the COM object or Object class that
implements the COM object.
o All it can see is the interface.
 Every DCOM interface inherits from an interface known as IUnknown

o Interface names start with I
Cont…
 The IUnknown interface has three methods:
• AddRef(), Release() and QueryInterface()
• AddRef() and Release() are used to manage reference counts (for memory
management)
 Through IUnknown, it can control the lifetime of an object and invoke

QueryInterface.
 QueryInterface is the basic method to navigate among interfaces.
• This means that a client proxy dynamically loads multiple server stubs in the
remoting layer depending on the number of interfaces being used.

IDL in DCOM
 The IDL language used by COM/ DCOM is called MIDL.
 Interface specifications are compiled by the standard Microsoft IDL Compiler
(also denoted as MIDL), which creates the code of sever stubs and client proxies.
 When a client passes a moniker to access an object, COM looks up a Running
Object Table (ROT) for the moniker name:
– If it exists, a pointer to the object is returned
– Else, a new object instance is created, its state is restored, its reference is
entered in ROT, and a pointer to the object is returned to the client
• Monikers contain reference to the object’s persisted state

The three different layers of DCOM and CORBA
 The top layer is the basic programming architecture, which is visible to the developers
of the client and object server programs.
 The middle layer is the remoting architecture, which transparently makes the interface
pointers or object references meaningful across different processes.
 The bottom layer is the wire protocol architecture, which further extends the remoting
architecture to work across different machines.

DCOM VS. CORBA Summary
.

RMI(Remote Method Invocation)
• It is a real distributed application interface for Java, written to
provide easy access to objects existing on remote virtual machines
• provide access to objects existing on remote virtual machines
• Remote objects can be treated similarly to local objects
• Handles marshaling, transportation, and garbage collection of the
remote objects
• Became part of the JDK with version 1.1
• Not an all-purpose ORB architecture like CORBA and DCOM
• Not language independent
• RMI is purely Java-specific
• Java to Java communications only
03/06/2022 80
Copyright©2021/22 Tarekegn D.(MSc)\
 RMI System Architecture
 Built in three layers (they are all independent):

– Stub/Skeleton layer
– Remote reference layer
– Transport layer
 The Stub/Skeleton layer
 The interface between the application layer and the rest of the system
 Stubs and skeletons are generated using the RMIC compiler
 This layer transmits data to the remote reference layer via the abstraction of marshal
streams (that use object serialization)
 This layer doesn’t deal with the specifics of any transport
 Client stub responsible for:
– Initiating remote calls
– Marshaling arguments to be sent
– Informing the remote reference layer to invoke the call
– Unmarshaling the return value

– Informing remote reference the call is complete

Cont…
 Server skeleton responsible for:
– Unmarshaling incoming arguments from client
– Calling the actual remote object implementation
– Marshaling the return value for transport back to client
 The Remote Reference Layer
 The middle layer
 Provides the ability to support varying remote reference or invocation
protocols independent of the client stub and server skeleton
 Remote reference layer responsible for:
• managing the "liveliness" of the remote objects
• managing the communication between the client/server and virtual
machines

(MSc)\
Cont…
 The Transport Layer
– Actual network/communication layer that is used to send the information
between the client and server over the wire
– Currently TCP/IP based
 Responsible for:
– Setting up connections to remote address spaces
– Managing the connections
– Listening to incoming calls
– Maintaining a table of remote objects that reside in the same address space
– Setting up connections for an incoming call
– Locating the dispatcher for the target of the remote call

(MSc)\
 How RMI System Works
 When a client receives a reference to a server, RMI downloads a
stub that translates calls on that reference into remote calls to the
server.
 The stub marshals the arguments to the method using object
serialization, and sends the marshalled Invocation across the wire to
the server.
 On the server side the call is received by the RMI system and
connected to a skeleton, which is responsible for un-marshalling the
arguments and invoking the server's implementation of the method.

(MSc)\
 How RMI System Works
 When the server's implementation completes, either by returning a
value or by throwing an exception, the skeleton marshals the result
and sends a reply to the client's stub.
 The stub un-marshals the reply and either returns the value or
throws the exception as appropriate.
 Stubs and skeletons are generated from the server implementation,
usually using the program rmic.
 Stubs use references to talk to the skeleton.
 This architecture allows the reference to define the behavior of

communication.
(MSc)\
 Steps To Develop RMI
 Create remote interfaces
– clients will use these to invoke remote methods
 Create remote implementation classes
– these implement the remote interfaces and provide the remote functionality
 Create server initialization application
– creates remote objects and binds them in the registry
– isn't needed if all remote implementation classes have a main() method that creates
instances and
binds them in the registry
 Create client classes
– these can utilize remote objects
03/06/2022
– they locate remote objectsCopyright©2021/22
by (MSc)\
Tarekegn D. 87
 Steps To Develop RMI
 .

 Example: App server: interface
import java.rmi.*;
public interface AppInterface extends Remote {
public String AppCall() throws RemoteException;
}
89
03/06/2022 Copyright©2021/22 Tarekegn D.
(MSc)\
 Example: App server: class
import java.rmi.*;
import java.rmi.server.*;
public class App extends UnicastRemoteObject

implements AppInterface {
private String message; // Strings are serializable
public App(String msg) throws RemoteException {

message = msg;
}
public String AppCall() throws RemoteException {

return message;
}
}
90
(MSc)\
 Example: Registering the App server
class AppServer {
public static void main (String[] argv) {
try {
Naming.rebind("rmi://localhost/AppServer",
new App("App, Service!"));
System.out.println("App Server is ready.");
}
catch (Exception e) {
System.out.println("App Server failed: " + e);
}
}
}
91
(MSc)\
 Example: The App client program
class AppClient {
public static void main (String[] args) {
AppInterface app;
String name = "rmi://localhost/AppServer";
try {
app = (AppInterface)Naming.lookup(name);
System.out.println(app.AppCall());
}
catch (Exception e) {
System.out.println("AppClient exception: " + e);
}
}
}
92
(MSc)\
 rmic(RMI Compiler)
 The class that implements the remote object should be compiled as usual
 Then, it should be compiled with rmic:
– rmic App
– This will generate files App_Stub.class and App_Skel.class
 These classes do the actual communication

– The “Stub” class must be copied to the client area
– The “Skel” was needed in SDK 1.1 but is no longer necessary

(MSc)\
Trying to Run RMI
 In three different terminal windows:
1. Run the registry program:
• rmiregistry
2. Run the server program:
• java AppServer
3. Run the client program:
• java AppClient
 If all goes well, you should get the “App, Service!” message
94
(MSc)\
RPC vs RMI
 RMI supports system-wide object references
 RMI can have object-specific stubs, not necessar-
ily have general-purpose client-side and server-
side stubs
 Pass objects as arguments (object migration)
 Migrated objects can interact with both original
and new hosts

(MSc)\
Web Services
Web services are open standard ( XML, SOAP, HTTP etc.) based
Web applications that interact with other web applications for the
purpose of exchanging data
• Web Services are self-contained, modular, distributed, dynamic
applications
• Web services are XML-based information exchange systems that
use the Internet for direct application-to-application interaction
• These systems can include
– Programs
– Objects
– Messages
– documents.

(MSc)\
Web Services…
• It covers all the details necessary to interact with the service,
including message formats (that detail the operations), transport
protocols and location.
– This allows and encourages WS-based applications to be
• loosely coupled
• component-oriented
• cross-technology implementations.

• The basic Web services platform is XML + HTTP
Web Services...
 Benefits
1. Exposing the existing function on to network:
– allows you to expose the functionality of your existing code over the
network.
– So, other application can use the functionality of your program.
2. Connecting Different Applications i.e. Interoperability:
– allows to make the application platform and technology independent.
3. Standardized Protocol:
– allows to standardization of protocol stack that gives the business many
advantages like wide range of choices, reduction in the cost due to
competition and increase in the quality.
4. Low Cost of communication:
– allows to uses SOAP over HTTP protocol for the communication, so you
can use your existing low cost internet for implementing Web Services.

Web Services...
• All the standard Web Services works using following components
i. SOAP (Simple Object Access Protocol)
ii. UDDI (Universal Description, Discovery and Integration)
iii. WSDL (Web Services Description Language)

WS...
 A popular interpretation of Web services is based on SOA:
• Uses 3 specifications components:
– WSDL
s n
– SOAP
atio
– UDDI
Ap ts,
plic
p
• Contains 2 Artifacts:
res Conce
– Service
and
– Service description
hite ces:
• Plays 3 roles:
Arc servi
ctu
– Service provider
– Service registry b
We
– Service requester
• Supports 3 behaviors(Operations):
– Publish: service descriptions
• Service provider &Service registry
– Find/ lookup: service descriptions
• Service requester &Service registry
– Bind/ invoke: services & service description.
• Service requester &Service provider
100
03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\
Communication Paradigms
Socket communication
Low-level API for communication using underlying
network protocols
Remote Invocation
A procedure call abstraction for communicating between
entities
Indirect Communication
Communicating without direct coupling between sender
and receiver

(MSc)\
Network programming…
• Network programming refers to writing a programs
that running on Networked machines.
– programs running on client machines make requests to a
program (often called as server program) running on a server
machine.
• They involve networking services provided by the
transport layer, which is part of the Internet software
stack, often called TCP/IP stack
• The transport layer comprises two types of protocols,
TCP (Transport Control Protocol) and UDP (User
Datagram Protocol).

(MSc)\
Network programming
• The most widely used programming interfaces for these protocols
are sockets.
• A socket is an endpoint of a two-way communication link between
two programs running on the network.
• Socket is bound to a port number so that the TCP layer can identify
the application that data is destined to be sent.
• Sockets provide an interface for programming networks at the
transport layer.
• Network communication using Sockets is very much
similar to performing file I/O.
– In fact, socket handle is treated like file handle.

(MSc)\
Network programming
Socket Programming
• is a way of connecting two nodes on a network to
communicate with each other.
• One socket(node) listens on a particular port at an
IP, while other socket reaches out to the other to
form a connection.
• Server forms the listener socket while client
reaches out to the server.

(MSc)\
Network programming
Socket Programming

Network programming
• Server/Client Applications Socket Programming
– The basic mechanisms of client-server setup are:
• A client app send a request to a server app.
• The server app returns a reply.
• Some of the basic data communications between
client and server are:
– File transfer - sends name and gets a file.
– Web page - sends url and gets a page.
– Echo - sends a message and gets it back.

(MSc)\
Network programming
• Server Socket
– create a socket - Get the file descriptor!
– bind to an address -What port am I on?
– listen on a port, and wait for a connection to be
established.
– accept the connection from a client.
– send/recv - the same way we read and write for a file.
– shutdown to end read/write.
– close to releases data.
–.

(MSc)\
Network programming
• The streams used in file I/O operation are also applicable
to socket-based I/O.
• Socket-based communication is independent of a
programming language used for implementing it.
– That means, a socket program written in Java language can
communicate to a program written in non-Java (say C or C++)
socket program.

(MSc)\
Network programming
• ...

Network programming
• The Socket API is a low-level programming facility for
implementing IPC.
• The upper-layer facilities are built on top of the operations
provided by the Socket API.
• The Socket API provides a programming construct called a
“socket”.
• A process wishing to communicate with another process must
create an instance or instantiate a socket.
• Two processes wishing to communicate can instantiate
sockets and then issue operations provided by the API to send and
receive data.

(MSc)\
Network programming
• A socket is uniquely identified by the IP address of the machine
and the port number at which the socket is opened (i.e. bound to).
• Port numbers are allocated 16 bits in the packet headers and
thus can be at most 66535.
• Well-known processes like FTP, HTTP and etc., have their sockets
opened on dedicated port numbers (less than or equal to 1024).
• Hence, sockets corresponding to user-defined processes have to be
run on port numbers greater than 1024.
• There are two types of sockets
1. User Datagram Protocol (UDP) transports packets in a
connectionless manner.
– each data packet (also called datagram) is addressed and routed individually
and may arrive at the receiver in any order.

(MSc)\
Network programming
• For example, if process 1 on host A sends datagrams m1 and m2
successively to process 2 on host B, the datagrams may be
transported on the network through different routes and may arrive
at the destination in any of the two orders: m1, m2 or m2, m1.
• Sockets that use UDP for transport of packets are called
“datagram” sockets

(MSc)\
Network programming
• A process wishing to send or receive data using the datagram
socket API
• must instantiate a DatagramSocket object , which
is bound to a UDP port of the machine and local to the process.
• the sender process must instantiate a DatagramPacket object that
carries the following information: (1) a reference to a byte array
that contains the payload data and (2) the destination address (the
host ID and port number to which the receiver
process’ DatagramSocket object is bound).
• the receiving process must instantiate a DatagramPacket object that
references a byte array and call the receive method of the
DatagramSocket object, specifying as argument, a reference to the
DatagramPacket object.

(MSc)\
Network programming

(MSc)\
Network programming
2. Transmission Control Protocol (TCP) is connection-oriented and
transports a stream of data over a logical connection established
between the sender and the receiver.
• As a result, data sent from a sender to a receiver is guaranteed to be
received in the order they were sent.
• messages m1 and m2 are delivered in the same order they were
sent
• sockets that use TCP for transport are called “stream” sockets.

(MSc)\
Network programming
Client side Socket Operations
1. Get connection to server:
client = new Socket( server, port_id );
2. Create I/O streams for communicating to server
is = new DataInputStream( client.getInputStream() );
os = new DataOutputStream( client.getOutputStream() );
3. Perform communication with server
Receiive from server :
String line = is.readLine();
Send to server :
os.writeBytes("Hello\n");
4. Close sockets:
client.close();

(MSc)\
Network programming
Server side Socket Operations
1. Open Server Socket:
ServerSocket server;
DataOutputStream os;
DataInputStream is;
server = new ServerSocket( PORT );
2. Wait for Client Request:
Socket client = server.accept();
3. Create I/O streams for communicating to clients
is = new DataInputStream( client.getInputStream() );
os = new DataOutputStream( client.getOutputStream() );
4. Perform communication with client
Receiive from client: String line = is.readLine();
Send to client: os.writeBytes("Hello\n");
5. Close sockets: client.close();
(MSc)\
Network programming
• For multithreade server:
while(true) {
i. wait for client requests (step 2 above)
ii. create a thread with “client” socket as parameter (the thread
creates streams as in step (3) and does communication
as stated in (4). Remove thread once service is provided.
}

Message And Queuing Services(MQS)
• In message queuing, a message is a collection of data sent by one
program and intended for another program
• Messaging: Programs communicate by sending each other data in
messages rather than calling each other directly.
• Queuing: a mechanism by which messages are held until an
application is ready to process them
– Messages are placed on queues in storage, allowing programs to run
independently of each other, at different speeds and times, in different
locations, and without having a logical connection between them
• Provides asynchronous between COM/DCOM Components
• Typical API for en-queuing and de-queuing messages
• Reliability guaranteed - but still a very new product and needs
maturation

MQS...
• Allows and promotes the loose coupling of components
– allows components to post messages for other components
– asynchronous rather than synchronous
– also known as MOM (Message-Oriented Middleware
• Two basic models
– point-to-point
• one component posts a message to a server
• only one component will consume a posted message
– publish/subscribe
• allows a component to publish a message to a topic on a
server
• components interested in a particular topic can subscribe to
that topic (messages can be consumed by a number of
components)
MQS...
• Publish-Subscribe Messaging
– Used when multiple
applications need to receive
the same messages
– The central concept is the
Topic.
– There may be multiple
Senders and multiple
Receivers.

MQS...
Point-to-Point Messaging
• Used when one process needs
to send a message to another
process
• There are two basic types:
– The first one involves a client
that directly sends a message to
another client.
– The second and more
common implementation is
based on the concept of a
Message Queue.
• even though there may be
multiple Senders of messages,
but there is only a single
Receiver.
MQS...
• Programming Model of message queuing

MQS...
• Main features of message queuing
– There are no direct connections between programs
– Communication between programs can be time-independent
– Work can be carried out by small, self-contained programs
– Communication can be driven by events.
– Applications can assign a priority to a message.
– Security
– Data integrity
– Recovery support

MQS...
VS
• No direct connections between programs in message queuing

Low-level Data Communications
• is defined as the interchange and processing encoded information
between distant locations using protocol
• A communications protocol is a system of digital message
formats and rules for exchanging those messages in or between
computing systems and in telecommunications

Summary
 Intersystem Communication
 is the communication between the set of heterogeneous
systems which puts together many heterogeneous subsystems
 By using level of design in integrated systems architecture
that involves
• the description of elements from which systems are built,
• interactions among those elements,
• patterns that guide their structure, and
• constraints on these patterns.

Summary...
 The integrated systems architecture can be
 Point-To-Point Integration Architecture
 Tightly coupled application components communication
 Hub And Spoke Integration Architecture
 Cross application components communication decoupled by
centeral device or server called a "hub".
 Distributed Integration Architecture
 Distributed application components communication by
using smaller computers known as “Agents.“
 Service Oriented Architecture (SOA)
 loosely coupled application services communication by
using concept known as “we services.“

Summary...
Integrative middleware technology
• The layer of software to mask heterogeneity and to enables
integration b/n program/component written in one programming
language, running on one platform to interact with an application
object across the network that are written in other programming
languages and running on other platforms
• Integrative middleware layer
– Presentation layer: to provide common data
formatting/representation
– Session layer : to map object references and Object adapters to
hosts to provide a series of related connection-oriented
transmissions between network nodes.
Summary...
 Main application implementation or integration middleware
technology
• Distributed computing environment (DCE) middleware
• RPC(OSF, heterogeneous platform + Cross-language)
=remote call
• Objects oriented middleware
• Cross-language
• CORA(OMG, heterogeneous platform)
= object reference+ remote call
• DCOM (Microsoft, homogeneous platform)
= object reference + remote call
• Language-specific
• Java-RMI(Oracle, heterogeneous platform)
= object reference + remote call
Summary...
• Service oriented middleware
• WS(Any, heterogeneous + Cross-language)
=message passing + object reference + remote call
• Message oriented middleware
• MQS(Any, heterogeneous + Cross-language)
=message passing + Sockets reference + remote call

Summary...
 Main application communicate paradigms between entities
Inter-Process Communication (IPC)
• IPC provides a low-level communication API
• e.g., Socket API
Remote Invocation
• Programmer can transparently invoke a remote function by
using a local procedure-call syntax
• e.g., RPC/RMI
Indirect Communication
• Allows one-to-many communication paradigm
• Enables space and time decoupling
• e.g., Multicasting and Message-Queue Systems

Summary...
 Example of the overall process of using a Integrative Program-
ming Technology with interoperability protocol on the Internet

Summary...
Read more...
p t e r- 1
f C h a
En d o
Thank You
?

Lecture-IPT-Chapter-1A-INTERSYSTEM COMMUNICATION

Uploaded by

Copyright:

Available Formats

You might also like

Lecture-IPT-Chapter-1A-INTERSYSTEM COMMUNICATION

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture-IPT-Chapter-1A-INTERSYSTEM COMMUNICATION

Uploaded by

Copyright:

Available Formats

ASSOSA University

College of Computing and Informatics

IPT: Integrative Programming and Technologies

By: Tarekegn D.(MSc.) @2021/22.

 Applications on the same middleware can work together

CH 1: Define the concept of Intersystem Communication and

Data representation and encoding;

CH3: Use Integrative Coding: Design Patterns; Interfaces;

By: Tarekegn D.(MSc.) @2019/20.

 Types specifies how each part can be used

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 6

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 8

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 9

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 10

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 11

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 13

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 14

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 16

 What is Intersystem Communication?

 the produced information objects are extremely different,

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 18

• interactions among those elements,

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 19

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 20

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 23

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 24

03/06/2022 Copyright©2021/22 Tarekegn D. 26

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 27

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 28

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 29

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 30

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 31

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 32

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 33

• stresses vertical layers

• The middleware lies in the middle between Application-to-

• Applications on middle ware A can work together

• The integrative middleware technology definition

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 35

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 36

• The primary services are:

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 37

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 38

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 39

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 40

• Remote Object Invocation(ROI)

• Message Queuing Services - Sockets

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 42

• Most middleware technology has been designed for private

– Middleware technology has been designed for public

– adds at least two challenges

• As well as different operating system, languages, etc

• forget the idea of a single middleware technology in

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 44

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 45

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 46

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 48

03/06/2022 Copyright©2021/22 Tarekegn D.(MSc)\ 49

• Specification designed by An Object Management Group's (OMG)