DISTRIBUTED APPLICATION

Distributed Applications are software applications that are stored mostly on cloud computing
platforms and that run on multiple systems simultaneously. The systems run on the same
network and communicate with each other in an effort to complete a specific task or command.

A Distributed App (DApp) is designed to allow users of a network to collaborate and share
ideas, co-ordinate on tasks, access information, and exchange apps through a server. DApps
are mostly used on client-server networks where the user’s computer accesses information from
the server or cloud computing server. The different computer systems that have been
distributed across the network are normally tasked with similar or different objectives.

Distributed applications are broken up into two separate programs: the client software and the
server software. The client software or computer accesses the data from the server or cloud
environment, while the server or cloud processes the data. Cloud computing can be used
instead of servers or hardware to process a distributed application's data or programs. If a
distributed application component goes down, it can failover to another component to continue
running. Distributed applications allow multiple users to access the apps at once.

Heterogeneous Systems
The distributed system contains many different kinds of hardware and software working together
in a cooperative fashion to solve problems.

There may be many different representations of data in the system. This might include different
representations for integers, byte streams, floating-point numbers, and character sets. Most of
the data can be marshaled from one system to another without losing significance. Attempts to
provide a universal canonical form of information is lagging.

There may be many different instruction sets. An application compiled for one instruction set
can not be easily run on a computer with another instruction set unless an instruction set
interpreter is provided. There is no universal binary making process migration difficult. Recent
developments in the web and Java may provide a universal interpreted language on most
computers. Though a computer language is not an instruction set, this is a good compromise.

Some components in the distributed system may have different capabilities than other
components. Among these might include faster clock cycles, larger memory capacity, bigger
disk farms, printers and other peripherals, and different services. Seldom are any two computers
exactly alike.

Compiled By ​Diwas Pandey

1
CORBA
The Common Object Request Broker Architecture (CORBA) describes a messaging
mechanism by which objects distributed over a network can communicate with each
other irrespective of the platform and language used to develop those objects. CORBA
enables collaboration between systems on different operating systems, programming
languages, and computing hardware. CORBA uses an object-oriented model although
the systems that use the CORBA do not have to be object-oriented.

The essential concept in CORBA is the Object Request Broker (ORB). ORB support in
a network of clients and servers on different computers means that a client program
(which may itself be an object) can request services from a server program or object
without having to understand where the server is in a distributed network or what the
interface to the server program looks like. To make requests or return replies between
the ORBs, programs use the General Inter-ORB Protocol (GIOP) and, for the Internet,
its Internet Inter-ORB Protocol (IIOP). IIOP maps GIOP requests and replies to the
Internet's Transmission Control Protocol (TCP) layer in each computer.

The CORBA specification defines an architecture of interfaces and services that must
be provided by the ORB, with no implementation details. These are modular
components so different implementations could be used, satisfying the needs of
different platforms.

The ORB manages the interactions between clients and object implementations. Clients
issue requests and invokes methods of object implementations. There are two basic

Compiled By ​Diwas Pandey

2
types of objects in CORBA. The object that includes some functionality and may be
used by other objects is called a service provider. The object that requires the services

of other objects is called the client. The service provider object and client object
communicate with each other independent of the programming language used to design
them and independent of the operating system in which they run. Each service provider
defines an interface, which provides a description of the services provided by the client.

Dynamic Invocation ​- This interface allows for the specification of requests at runtime.
This is necessary when the object interface is not known at run-time. Dynamic
Invocation works in conjunction with the interface repository.

IDL Stub - This component consists of functions generated by the IDL interface
definitions and linked into the program. The functions are a mapping between the client
and the ORB implementation. Therefore ORB capabilities can be made available for
any client implementation for which there is a language mapping. Functions are called
just as if it was a local object.

ORB Interface ​- The ORB interface may be called by either the client or the object
implementation. The interface provides functions of the ORB which may be directly
accessed by the client (such as retrieving a reference to an object.) or by the object
implementations. This interface is mapped to the host programming language. The ORB
interface must be supported by any ORB.

ORB core - Underlying mechanism used as the transport level. It provides basic
communication of requests to other sub-components.

IDL Skeleton Interface ​- The ORB calls method skeletons to invoke the methods that
were requested from clients. Object Adapters (OA) - Provide the means by which object
implementations access most ORB services. This includes the generation and
interpretation of object references, method invocation, security, and activation.

Requests -The client requests a service from the object implementation. The ORB
transports the request, which invokes the method using object adapters and the IDL
skeleton
Object Adapters - ​Object Adapters (OA) are the primary ORB service providers to
object implementations. OA has a public interface that is used by the object
implementation and a private interface that is used by the IDL skeleton.

Compiled By ​Diwas Pandey

3
INVOCATION IN CORBA

Static and Dynamic Invocation

The CORBA ORB in the BEA Tuxedo product supports two types of client/server invocations:
static and dynamic. In both cases, the CORBA client application performs a request by gaining
access to a reference for a CORBA object and invoking the operation that satisfies the request.
The CORBA server application cannot tell the difference between static and dynamic
invocations.

When using static invocation, the CORBA client application invokes operations directly on the
client stubs. Static invocation is the easiest, most common type of invocation. The stubs are
generated by the IDL compiler. Static invocation is recommended for applications that know at
compile time the particulars of the operations they need to invoke and can process within the
synchronous nature of the invocation. The figure illustrates static invocation.

While dynamic invocation is more complicated, it enables your CORBA client application to
invoke operations on any CORBA object without having to know the CORBA object's interfaces
at compile time. The figure illustrates the dynamic invocation.

When using dynamic invocation, the CORBA client application can dynamically build operation
requests for a CORBA object interface that has been stored in the Interface Repository. CORBA
server applications do not require any special design to be able to receive and handle dynamic
invocation requests. Dynamic invocation is generally used when the CORBA client application
requires deferred synchronous communication, or by dynamic client applications when the
nature of the interaction is undefined.

Compiled By ​Diwas Pandey

4
Some examples of services are​:
☞ Naming and Trading Services:

● The basic way an object reference is generated is at the creation of the object when the
reference is returned.
● Object references can be stored together with associated information (e.g. names and
properties).
● The naming service allows clients to find objects based on names.
● The trading service allows clients to find object based on their properties.

☞ Transaction Management Service: provides two-phase commit coordination among

recoverable components using transactions.

☞ Concurrency Control Service: provides a lock manager that can obtain and free locks for
transactions or threads.

☞ Security Service: protects components from unauthorized users; it provides authentication,

access control lists, confidentiality, etc.

☞ Time Service: provides interfaces for synchronizing time; provides operations for defining and
managing time-triggered events.

Compiled By ​Diwas Pandey

5
ORB & INTERFACE
An object request broker (ORB) is a middleware application component that uses the common
object request broker architecture (CORBA) specification, enabling developers to make
application calls within a computer network. ORB is an agent that transmits client/server
operation invocations in a distributed environment and ensures transparent object
communication.

ORB supports a wide variety of middleware services, including but not limited to the notification,
event triggers, transaction processing, persistence, and security. ORB can be configured to fit
into a variety of environments and handle a wide range of client requests. Thus, developers can
modify ORB to meet task requirements for inbound client requests.

ORB does the following:

● Searches, matches, and instantiates remote machine objects

● Gathers parameters between application objects
● Handles security issues across machine boundaries
● Retrieves and publishes data objects on local machines available for other ORBs
● Invokes remote object methods using static and dynamic method invocation.
● Instantiates idle objects automatically
● Routes callback methods
● Communicates Inter-ORB Protocol (IIOP) with other ORBs via the Internet

The Basic Object Adapter

☞ The object adapter (OA) is the primary interface between the server object implementation
and the ORB.

Services provided by the OA:

● Object registration: OA provides operations by which certain entities, specified in a given

programming language, are registered as CORBA objects.
● Object reference generation: OA generates object references to CORBA objects.
● Object upcalls: OA dispatches incoming requests to the corresponding registered
objects.
● Server process and object activation: if needed, OA starts up server processes and
activates objects as a result of incoming invocations.

Compiled By ​Diwas Pandey

6