1 CHAPTER ONE

Intersystem
Communications
 Introduction
2

 Integration of software refers to techniques for combining

existing software components to form a complete system.
 software integration includes at least one existing software
system.
 Integrative programming deals with an integration
approaches and techniques that connect different components
of IT infrastructure-
 people, applications, platforms and databases to enable a secure,
intra and inter application collaboration.
 Introduction
3

 Integrative solutions enable an organization to integrate

business processes internally and externally with business
partners.
 to create dynamic environments that supports current and evolving
business requirements, thereby creating a global organization
what is Integration ?
 It is the process of connecting multiple, independently
developed applications using incompatible technologies into a
single organization wide system with information flowing
 Inter-system communication
4

 What is intersystem communication?

 It is the communication between a set of heterogeneous systems that are
integrated together
 Software integration includes one or more of the following.
 System integration

 Functional integration or technology

 Incremental engineering

 Modification

System integration
 Process of connecting two or more system together
 The problem is to integrate them into one larger system satisfying the
combined requirements within the newly formed environment.
 Inter-system communication
5

Functional integration or technology integration

 Given a software system, this may have been functioning properly in the
field for a significant period.
 The problem is to integrate a new function or a new technology within the
system.
 The integrated system should provide the new functionality or use the new
technology, while preserving the original system functionality.
Incremental engineering
 A software system can be developed and delivered using available
technologies and with less functionality than it is intended to finally provide.
 New technologies and or more functions then can be integrated within the
system.
 The problem is to design the system with such future integration in mind.
 Cont..
6

Modification
 Sometimes an existing and properly functioning software system
must be decomposed and integrated to carry out modification.
The need for integration
 Most of organizations consist of more than one department, running
department specific applications and those applications interact with
each other to achieve the overall objective of the organizations.
 Information systems change overtime by growing in their size,
incorporating functionality of the existing standalone systems.
 So integration is used to exchange data
 Cont..
7

 Applications originally intended to operate separately, later on are

required to interoperate with others.
 Some of the reasons for integration are the following;
 The architecture of the organization information system depends
on constraints related to the technology but also to the
organization.
 Within an enterprise, each department may have its own IT
infrastructure, systems and databases which are maintained
independently
 So Integrating them may bring additional value to the company.
 Cont..
8

 Integration assists in formation of Zero Latency organization -

 when all functions within the organization work with the same up-to-
date information, latency between applications is eliminated/
reduced.
 Updating and integrating of applications is possible
whenever required.
 New applications can be created by integrating real time
data from different parts of the enterprise
 Cont..
9

Integrative Technologies/methods for integration

 Application integration is an integration framework composed of
a collection of technologies and services which form a
middleware to enable integration of systems and applications
across organizations.
 There are four methods used in application integration, these are:
1) File Transfer
2) Shared Database
3) Remote Procedure Invocation
4) Messaging
 Cont..
10

File transfer
 one application writes a file , another later reads.
 The applications need to agree on the filename and
location, the format of the file, the timing of when it
will be written and read, and who will delete the file.
 Produce the files at regular intervals according to the
nature of the business, which can be consumed or
read by another file.
 An important decision with files is what format to use.
 Cont..
11

 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 too read it,
you also have to be able to use processing tools on it.
 Cont..
12

Shared Database
 A common data base can be used for integrating applications.
 A single physical database can be shared by different
applications running on different platforms.
 This method integrates applications by having them store their
data in a single shared database.
 If a family of integrated applications all rely on the same
database, then we can be pretty sure that they are always
consistent all of the time.
 If we do get simultaneous updates to a single piece of data from
different sources, then we have transaction management systems
that handle that about as gracefully as it ever can be managed.
 Cont..
13
 Cont..
14

Remote procedure calls

 One application exposes some of its functionality so that it can be
accessed remotely by other applications as a remote procedure.
 The communication occurs real-time and synchronously.
 This method develops each application which is required to be
integrated as a large- scale object or component with
encapsulated data(hiding of the data for protection ).
 It provides an interface to allow other applications to interact
with the running application.
 Remote Procedure Invocation applies the principle of
encapsulation to integrating applications.
 If an application needs some information that is owned by
another application, it asks that application directly.
 Cont..
15

 If one application needs to modify the data of another, then it

does so by making a call to the other application.
 Each application can maintain the integrity of the data it owns.
 Furthermore, each application can alter its internal data without
having every other application be affected.
 Cont..
16

Messaging
 Messaging allows interaction between applications possible.
 one application publishes a message to a common message channel.
 Other applications can read the message from the channel at a later time.
 Message passing can be used to transfer packets of data frequently,
immediately, reliably, and asynchronously, or synchronously using
customizable formats.
 Asynchronous messaging is fundamentally a practical reaction to the
problems of distributed systems.
 Sending a message does not require both systems to be up and ready at
the same time.
 Cont..
17

 The reason a messaging system is needed to move messages from

one computer to another is that computers and the networks that
connect them are inherently unreliable.
 Just because one application is ready to send a communication
does not mean that the other application is ready to receive it.
 Even if both applications are ready, the network may not be
working, or may fail to transmit the data properly.
 A messaging system overcomes these limitations by repeatedly
trying to transmit the message until it succeeds.
 Under ideal circumstances, the message is transmitted successfully
on the first try, but circumstances are often not ideal.
 Cont..
18

 A message is transmitted in five steps:

1) Create — the sender creates the message and populates it with
data.

2) Send — the sender adds the message to a channel.

3) Deliver — the messaging system moves the message from the sender’s
computer to the receiver’s computer, making it available to the receiver.

4) Receive — the receiver reads the message from the channel.

5) Process — the receiver extracts the data from the message.

 Cont..
19
 Cont..
20

 This diagram also illustrates two important messaging concepts:

 1) Send and forget — in step 2, the sending application sends
the message to the message channel.
 Once that send is complete, the sender can go on to other work
 while the messaging system transmits the message in the
background.
 The sender can be confident that the receiver will eventually
receive the message and does not have to wait until that
happens.
 2) Store and forward— in step 2, when the sending application
sends the message to the message channel, the messaging system
stores the message on the sender’s computer, either in memory or
on disk.
 Cont..
21

 In step 3, the messaging system delivers the message by

forwarding it from the sender’s computer to the receiver’s
computer, and then stores the message once again on the
receiver’s computer.
 This store-and- forward process may be repeated many times, as
the message is moved from one computer to another, until it
reaches the receiver’s computer.)
22 Middleware
 Introduction
23

 What is Middleware?
 Layer between OS and distributed applications

 Provides common programming abstraction and

infrastructure for distributed applications.
 Hides complexity and heterogeneity of distributed system

 Bridges gap between low-level OS communications and

programming language abstractions.
 (large) set of predefined components

 Standard for constructing and interconnecting components

 Interchange, Upgrade, Adaptation and aggregation

 What does Middleware?
24

 Enabling Interactions
 Facilitate components interactions (e.g., supporting naming
and dynamic discovery of services)
 Dealing with heterogeneous components (e.g., components
and services developed using different technologies)
 What does Middleware?
25

 Supporting Interactions
 Provide solutions for common problems of interactions
(e.g. inconsistencies and synchronization in accessing shared
resources, persistance)
 Provide support for openness (new components getting in
the system)
 Provide support for problems (fault recovery, replication)

 Provide support for system manager (monitoring, and

logging)
 What does Middleware?
26

 Promoting Context-Awareness
 Have components be aware of “what’s happening” (e.g., a
new component has connected, a component changed its
state, the room temperature has changed)
 Virtualization of environmental resources into digital
resources (e.g., a thermostat as a software object)
27
 Operating System Vs Middleware
28

 Operating Systems
 Provide high-level
abstractions for the
resources of computer
 Facilitate and organize
access to resources
 Middleware
 Provide high-level
abstractions for the
resources of a network
 Facilitate and organize
access to distributed
resources
29
 Middleware Requirements
30

 Network communication
 marshalling/unmarshalling(converting data values from their
local representation to a network format
 Coordination
 activation/termination, threading, group requests,
synchronicity
 Reliability
 delivery guarantees, total/partial ordering, atomicity,
replication
 Scalability
 transparency of access/location/migration/replication, load
balancing
 Heterogeneity
 platform, operating system, network OS, programming
language
 Middleware Services
31

 Data Management Services

 Database and file system middleware
 Communication Services
 RPC (Remote Procedure Call) and messaging middleware.
 Distribution Services
 location, time and security services.
 Object Management Services
 by using Object Request Brokers (ORBs).
 Application Co-operation Services
 Transaction-Processing (TP) monitors, e-mail, etc.
 Presentation Services
 User Interfaces, printing and multi-media middleware.
 System Management Services
 Configuration-, change-, operations-, problem-, and
performance-management services
 Distribution Support in Middleware
32

 Hidden from application programmers

Five distributed services required
 Remote communication protocols
 e.g., RPC, message passing
 Directory services
 for accessing shared, globally-available services
 Security services
 protection of shared resources via authentication
 Transaction services
 for concurrent data access/update
 System management services
 service monitoring, management, and administration
 Advantages of Middleware
33

 Real time information access among systems

 Streamlines business processes and helps raise

organizational efficiency.

 Maintains information integrity across multiple systems

 Disadvantages of Middleware
34

 high development costs.

 implementations are very time consuming, and need a lot of
resources.
 There are few people with experience in the market place.
 There exists relatively few satisfying standards.
 The tools are not good enough.
 Middleware often threatens the real-time performance of a
system.
 Middleware products are not very mature.
 Cont’d
35
 Part I: Remote Procedure Call (RPC)
36

 When a process on machine A calls a procedure on

machine B, the calling process on A is suspended, and
execution of the called procedure takes place on B.
 Information can be transported from the caller to the
called in the parameters and can come back in the
procedure result.
 No message passing at all is visible to the
programmer . This method is known as Remote
procedure call (RPC) .
 Part I: Remote Procedure Call (RPC)
37

 Remote procedure call (RPC) is an Inter-

process communication technology that
allows a computer program to cause a
subroutine or procedure to execute in
another address space (commonly on
another computer on a shared network)
without the programmer explicitly coding
the details for this remote interaction.
 Part I: Remote Procedure Call (RPC)
38

 Masks remote function calls as being local

 Client/server model
 Request/reply paradigm usually implemented with message
passing in RPC service
 Marshalling of function parameters and return value
 The most famous RPC toolset is DCE (Distributed Computing
Environment)
 Part I: Remote Procedure Call (RPC)
39

 The RPC system hides the details that allow

communication to takes place by providing a stub on
client side.
 Typically a separate stub exits for each separate
procedure
 When the client invokes a remote procedure , the RPC
system calls the appropriate stub , passing it the
parameter provided to the remote procedure .
 This stub locate the port on the server and marshals the
parameter
 Parameter marshalling involves packing the parameters
into a form that can be transmitted over network
 Part I: Remote Procedure Call (RPC)
40

 The stub then transmits a message to the server

using message passing
 Similar stub on the server side receives this message
and invokes the producer on the server
 If necessary return values are passed to the client
using the same techniques
41
 Part I: Remote Procedure Call (RPC)
42

Remote
Caller RPC Service RPC Service
1) Marshal args Function
2) Generate ID message
3) Start timer 4) Unmarshal
call(…) 5) Record ID fun(…)

8) Unmarshal 6) Marshal
9) Acknowledge 7) Set timer
 Part I: Remote Procedure Call (RPC)
43
 Properties of RPC
44

 Language-level pattern of function call

 easy to understand for programmer
 Synchronous request/reply interaction
 sender and receiver need to connect to the network at the
same time
 natural from a programming language point-of-view
 matches replies to requests
 built in synchronisation of requests and replies
 Distribution transparency (in the no-failure case)
 hides the complexity of a distributed system
 Various reliability guarantees
 deals with some distributed systems aspects of failure
 Disadvantages of RPC
45

 Synchronous request/reply interaction

 tight coupling between client and server
 client may block for a long time if server loaded
 leads to multi-threaded programming at client
 slow/failed clients may delay servers when replying
 multi-threading essential at servers
 Distribution Transparency
 Not possible to mask all problems
 RPC paradigm is not object-oriented
 invoke functions on servers as opposed to methods on objects
 Part II: Object-Oriented Middleware (OOM)
46

 Objects can be local or remote

 Object references can be local or remote
 Remote objects have visible remote interfaces
 Masks remote objects as being local using proxy objects
 Remote method invocation

local OOM OOM remote

object object
object A request request skeleton
broker broker
object B
/ /
object
object
manager
proxy manager
object B object B
 Properties of OOM
47

 Support for object-oriented programming model

 objects, methods, interfaces, encapsulation, …

 Synchronous request/reply interaction

 same as RPC

 Location Transparency
 system (ORB) maps object references to locations

 Services compromising multiple servers are easier to build with

OOM
 RPC programming is in terms of server-interface (operation)

 RPC system looks up server address in a location service

48

Reading Assignment
what are disadvantages
of OOM?
 Distributed Object Paradigms
49

 Distributed object computing extends an object-oriented

programming system by allowing objects to be distributed
across a heterogeneous network.
 Distributed Object Paradigms
50
 Cont’d
51

 The architectures of CORBA, DCOM and Java/RMI provide

mechanisms for transparent invocation and accessing of remote
distributed objects.
 Though the mechanisms that they employ to achieve remoting
may be different, the approach each of them take is more or
less similar.
 All three distributed object technologies are based on a
client/server approach
 They are Implemented as network calls operating at the level
of bits and bytes transported on network protocols like TCP/IP.
 Why Distributed Technology Standards?
52

 In order to avoid the hard and error prone implementation of

network calls directly in the client and server (objects).
 To address complex networking interactions

 by abstract and hide the networking issues

 and instead let the programmer concentrate on

programming the business logic.
 The basic idea behind network abstractions like RPC (Remote
Procedure Call) is to replace the local (server) and remote
(client) end by stubs.
 This makes it possible for both client and server to strictly use
local calling conventions and thereby be unaware of calling a
remote implementation or being called remotely.
 Cont’d
53

 The marshalling and un marshalling actions :

 are responsible for converting data values from their local
representation to a network format and on to the remote
representation .
 Format differences like byte ordering and number
representations are bridged this way.
54

 The object services offered by all three approaches are

defined through interfaces.
Interface :
 The interface is for all defined as a collection of named
operations, each with a defined signature and optionally a
return type.
 The interface serves as a contract between the server and

client.
 How Remoting Works?
55

 To invoke a remote method, the client makes a call to the

client proxy.

 The client side proxy packs the call parameters into a request
message and invokes a wire protocol like (Internet Inter-ORB
Protocol)IIOP(in CORBA) or (Object Remote Procedure Call) ORPC(in
DCOM) or (Java Remote Method Protocol) JRMP(in Java/RMI) to
ship the message to the server.
 Cont’d
56

 At the server side, the wire protocol delivers the message to

the server side stub.
 The server side stub then unpacks the message and calls the
actual method on the object.
 In both CORBA and Java/RMI, the client stub is called the
stub or proxy and the server stub is called skeleton.
 In DCOM, the client stub is referred to as proxy and the
server stub is referred to as stub.
 CORBA
57

 It is a standard architecture for distributed object systems.

 It allows a distributed, heterogeneous collection of objects to
interoperate.
 Relies on a protocol called the Internet Inter-ORB Protocol
(IIOP) for remoting objects
 Everything in the CORBA architecture depends on an Object
Request Broker (ORB).
 Cont’d
58

 ORB: acts as a central Object Bus over which each CORBA

object interacts transparently with other CORBA objects
located either locally or remotely.

 CORBA is the most used middleware standard in the

non-Windows market.
 The OMG was founded in 1989 to promote the adoption of
object-oriented technology and reusable software components.
 ORB
59

 Delivers client requests and server responses

 provides a layer of indirection between clients and servers
 The ORB hides object
 location
 Implementation
 execution state
 communication mechanisms
 Requests on an object are made using its reference
 Clients can obtain references in three ways
 create an object to get its reference
 invoke a lookup service (naming, trading)
 use persistent references to objects
60

 When a CORBA client requests a service from a CORBA server

object, the ORB is responsible for:
 Find the implementation of the server object.

 Prepare the object for requests.

 Give the object reference back to the client object.

 Communicate the requests to the server object.

 Returning the server result back to the client.

61

 A CORBA object interacts with the ORB either through the ORB
interface or through an Object Adapter(either a Basic Object
Adapter (BOA) or a Portable Object Adapter (POA))

 The ORB simplifies distributed programming by decoupling the

client from the details of the method invocations. This makes
client requests appear to be local procedure calls.
 The IDL Interface
62

 Whenever a client needs some service from a remote

distributed object, it invokes a method implemented by the
remote object.
 The service that the remote distributed object (Server)
provides is encapsulated as an object
 The remote object's interface is described in an Interface
Definition Language (IDL).
 The interfaces specified in the IDL file serve as a contract
between a remote object server and its clients.
 Stubs and Skeletons
63

 Used in CORBA’s static invocation

 Programming language-specific counterparts to IDL définitions
 Stubs and skeletons are generated using the IDL definitions
 Stubs: create and issue requests on the client side
 surrogates or proxies

 perform marshaling of requests

 Skeletons :receive and forward requests to objects on the

server side
 perform unmarshalling of requests

 return results via the server and client ORBs to the stub
 Static Method Invocation
64

 Define object classes using IDL

 Run IDL file through language precompiler
 Add implementation code to skeletons
 Compile code
 Bind class definitions to Interface Repository
 Register the run-time objects with Implementation Repository
 Dynamic Method Invocation
65

 Obtain interface name from Interface Repository

 Obtain method description from Interface Repository
 Create argument list
 Create request
 Invoke request
 Internet Inter-ORB Protocol (IIOP)
66

 The Internet Inter-ORB Protocol (IIOP) was developed in the

CORBA 2.0 specification as a protocol for communication
between ORBs from different vendors.

 IIOP is a specialisation of the General Inter-ORB Protocol

(GIOP) and runs on top of TCP/IP. CORBA relies on IIOP or
other specialisations of GIOP for remoting objects.
67

 The interactions are done either by the ORB interface or

through an Object Adapter.

 The ORB interface is an abstract interface for an ORB to

decouple applications from implementation details.
 This interface provides various helper functions such as

 converting object references to strings and vice versa,

 creating argument lists for requests made through the
dynamic invocation interface.
68

 The Object Adapter assists the ORB with delivering requests

to the object and with activating the object.
 The object adapter associates object implementations with the
ORB.
 Object adapters can be specialised to provide support for
certain object implementation styles (such as OODB object
adapters for persistence and library object adapters for non-
remote objects)
 CORBA Supports:
69
 CORBA Services
70

 Collections of system-level services packaged with IDL-

specified interfaces are called CORBA services.
 They are used to augment and complement the functionality of
the ORB.
 OMG has published standards for sixteen object services:
 CORBA object services
71
 Benefits of CORBA
72

 Programming-language independent interface.

 Legacy integration

 Rich distributed object infrastructure.

 Location transparency.

 Network transparency

 Direct object communication.

 Dynamic Invocation Interface.

 DCOM
73

 which is often called 'COM on the wire‘.(Distributed

Component Object Model )
 supports remoting objects by running on a protocol called the
Object Remote Procedure Call (ORPC).
 A DCOM server is a body of code that is capable of serving
up objects of a particular type at runtime.
 Cont’d
74

 Each DCOM server object can support multiple interfaces each

representing a different behavior of the object.
 A DCOM client calls into the exposed methods of a DCOM
server by acquiring a pointer to one of the server object's
interfaces.
 The client object then starts calling the server object's exposed
methods through the acquired interface pointer as if the
server object resided in the client's address space.
 Cont’d
75

 DCOM is now heavily used on the Windows platform.

 COM is the world most widely used component software model and
dominates the desktop market.
 The Microsoft Interface Definition Language, MIDL, is used to
define interfaces for the DCOM (and RPC) objects.
 MIDL is an extension of DCE(Distributed Computing Environment)
(RPC) IDL and is based on C syntax and data types.
 The COM specification is at the binary level. This allows
components to be written in a diversity of programming
languages.
 The hardware platform must support COM services in order to
provide DCOM.
 DCOM Supports:
76
 Java/RMI
77

 Java/Remote Method Invocation, is a standard developed by

JavaSoft.
 Java has grown from a programming language to three basic
and completely compatible platforms;
 J2SE (Java 2 Standard Edition): is the foundational programming
language and tool-set for coding and component development.
 J2EE (Java 2 Enterprise Edition) : supplements J2SE and is a set
of technologies and components for enterprise and Internet
development.
 J2ME (Java 2 Micro Edition): is used for creating software for
embedded, mobile, consumer and other small devices like
Personal Digital Assistants (PDA) and mobile phones.
 Cont’d
78

 RMI supports remote objects by running on a protocol

called the Java Remote Method Protocol (JRMP).
 Object serialisation is heavily used to marshal and un marshal
objects as streams.
 Both client and server have to be written in Java to be able to
use the object serialisation.
 The Java server object defines interfaces that can be used to
access the object outside the current Java virtual machine
(JVM) from another JVM on for instance a different machine.
 Cont’d
79

 RMI registry on the server machine holds information of the

available server objects and provides a naming service for
RMI.
 A client acquires a server object reference through the RMI
registry on the server and invokes methods on the server
object as if the object resided in the client address space.
 The server objects are named using URLs and the client
acquires the server object reference by specifying the URL.
 Cont’d
80

 When a Java/RMI client requests a service from the Java/RMI

server, it does the following [Java/RMI]:
 Initiates a connection with the remote JVM containing the
remote object
 marshals the parameters to the remote JVM

 waits for the result of the method invocation

 Un marshals the return value or exception returned

 Returns the value to the caller.

 Cont’d
81

 By using serialisation of the objects, both data and code

can be passed between a server and a client – this allows
different instances of an object to run on both client and
server machines.
 To insure that code is downloaded or uploaded safely, RMI
provides extra security.
 Java/RMI can be used on a diversity of platforms and
operating systems as long as there is a JVM implementation
on the platform.
 Comparison of Distributed Object Technologies
82

Programming languages
 CORBA is a specification and can therefore be used on
heterogeneous platforms, operating systems and programming
languages as long as there is an ORB implementation for the
platform and a language mapping for the programming
language.
 DCOM also supports multiple programming languages since it

is a binary standard.
 Java/RMI is only applicable as middleware between clients

and servers implemented in the Java language since it relies

heavily on Java object serialisation.
83

 Java offers an ORB (Java/IIOP) implementation as part of the

Java 2 Enterprise Edition (J2EE) that is quite similar in syntax
as RMI and that possibly will replace RMI as the preferred
Java middleware.
 Exposing Java objects directly through an ORB or through the
Java-IDL mapping makes it possible to invoke Java objects
from non-Java environments.
84

Development support
 Development support in the form of Integrated Development
Environments (IDE)
 In both CORBA and Java (including Java/RMI), have been

quite poor compared to the Microsoft development tools.

 This situation is however improving with support of design and
development patterns (for instance CORBA design patterns,
JavaBeans and EJB patterns) for the different technologies
(see [Link] and debugging of
remote objects.
85

Development support
 The system development support of COM in popular
languages like Visual Basic and Java (with Microsoft
extension) is very good when using Microsoft Visual Studio as
the development environment.
 Objects can easily be registered as COM server objects

without any specific coding.

 COM clients can import the interfaces to the COM server

objects through wrappers (of the client proxies) and then used
them as ordinary objects in the language.
86

Development support
 Especially the Java tools have became mature and supportive
in almost all kind of application development.
 The introduction of the CCM(Configuration Control and
Management) will probably make the development of CORBA
objects much easier.
87

Interface definition Language

 Both DCOM and CORBA offer an interface definition
language (IDL) to describe the interfaces for their respective
objects.
 For both cases, the IDL is language neutral and is used to
define mappings between different programming languages.
 The Microsoft Interface Definition Language (MIDL) is not like

the CORBA IDL specified by a formal notation (BNF).

 It is however some differences in both syntax and semantics
between the interface notions.
88

 Java/RMI does not have an own language for interface

description but have defined interface declarations as a
separate concept in the language and the interfaces are
stored as .java files.
 Java objects that implement the [Link] interface are
accessible by remote Java clients.
89

Object-oriented support
 Java/RMI and CORBA support multiple inheritance at the
interface level where DCOM only supports single inheritance.
 The implication of the missing support for inheritance is that
COM components can not be modified to create new
components. It does however allow some flexible forms of
programming.
 DCOM and Java/RMI support multiple interfaces for an
object (or component), each representing a different view or
behaviour of the object.
 Such a concept did not exist in the CORBA 2.0 specification
[Chung], but is included as part of the CORBA 3.0
specification.
90

Interface identification
 CORBA identifies interfaces by the interface name and the
implementations by mappings in the Implementation.
 Interfaces and classes (implementations) are uniquely defined in
COM by use of UUID. And the UUIDs are registered in the Windows
System registry.
 UUIDs allow for versioning where a server can extend the
functionality by implementing a new interface with a new UUID, while
also implementing the old interface .
 Older clients request the old interface without knowing about the
new, new clients can use both the old and the new interface.
 Java/RMI identifies classes by name and implementations by
mappings to an URL in the RMI registry.
91

Object identification
 Object reference in CORBA

 An interface pointer in COM and

 ObjIDs (faulting reference) in Java/RMI, provides unique

identification of server objects.
92

Invocation of objects
 CORBA and DCOM support both static and dynamic
invocations of objects.
 the MIDL compiler creates the proxy and stub code, which

are registered in the Windows system registry.

 Any Java object inherits the [Link], which holds the
type information.
93

Parameter passing
 The three technologies support parameters passing by either
value or by reference.
 COM and CORBA interfaces are passed as references, Java

Interfaces must implement the [Link] interface to be

passed by reference, all other objects and parameters are
passed by value.
 Parameters that are Java objects must implement the

Serializable interface to be passed by value.

94

Garbage collection
 CORBA does not attempt to perform general-purpose garbage
collection, but some CORBA products do include proprietary services
for garbage collection.
 Both DCOM and Java attempts to perform garbage collection of
remote server objects.
 A COM server object keeps track of the clients by using reference
counting. When no clients reference the COM object instance, it
deletes itself.
 The DCOM method for garbage collection (a pinging mechanism) has
been criticised due to increased network traffic.
 Java objects have a built-in reference counting where a separate
process within the JVM, the garbage collector releases instances when
no other object has references to the object.
95

Hardware support
 CORBA and Java/RMI are supported on nearly all
hardware platforms.
 The main advantage with Java middleware is that the same

version of an application can with few changes run on any

platform with a compatible JVM.
 DCOM is mainly supported on the Windows platform, but it

has been attempts to provide COM on other hardware

platforms without being very successful;
96

Network protocols
 The DCOM network protocol is strongly tied to RPC, the
CORBA and Java/RMI network protocols are not .
 The CORBA GIOP (General Inter-ORB Protocol) specification

was submitted to provide interoperability between ORBs

operating on different network protocols.
 The IIOP is the Internet specialisation of GIOP providing

transport over secure socket layers over TCP/IP.

 All CORBA 2-compliant ORBs are free to use alternative
protocols, as long as they provide IIOP as well .
97

Security
 CORBA provides security in two levels
 Level1:comprises user authentication, authorisation, data
encryption and integrity.
 Level 1 allows applications that are not security savvy(know-
how), to relegate themselves to a secure domain.
 Level2:provides a stronger security model where applications
are security aware.
 DCOM expects the user to be authenticated and authorised as
a user in the Windows NT domain to control access to the
components.
 Java/RMI uses the built-in Java security
98

Component Models
 All three standards(CORBA,COM and Java RMI) have their
component model extensions,
 CORBA with the CORBA Component Model (CCM),

 COM with the Microsoft Transaction Server (COM+/MTS),

 Java/RMI with the Java Bean and Enterprise JavaBeans (EJB)

component models.
 Microsoft is deliver a new application development framework

called .NET.