Unit 2

Technologies for distributed computing

• Remote procedure call

• Distributed object frameworks
• Service-oriented computing
 Remote procedure call
• RPC is the fundamental abstraction enabling the execution of
procedures on client’s request.
• RPC allows extending the concept of a procedure call beyond
the boundaries of a process and a single memory address
space.
• The called procedure and calling procedure may be on the
same system or they may be on different systems in a
network.
• The concept of RPC has been discussed since 1976
• Figure 2.14 illustrates the major components that enable an
RPC system.
• The system is based on a client/server model.
• The server process maintains a registry of all the available
procedures that can be remotely invoked and listens for
requests from clients that specify which procedure to invoke,
together with the values of the parameters required by the
procedure.
• RPC maintains the synchronous pattern that is natural in IPC
and function calls. Therefore, the calling process thread
remains blocked until the procedure on the server process
has completed its execution and the result (if any) is returned
to the client.
Developing a system leveraging RPC for IPC consists of the following
steps:
• Design and implementation of the server procedures that will be
exposed for remote invocation.
• Registration of remote procedures with the RPC server on the node
where they will be made available.
• Design and implementation of the client code that invokes the
remote procedure(s).
• An important observation has to be made concerning the
passing of parameters and return values.
• Since the server and the client processes are in two separate
address spaces, the use of parameters passed by references
or pointers is not suitable in this scenario, because once
unmarshaled these will refer to a memory location that is not
accessible from within the server process.
• Second, in user-defined parameters and return value types, it
is necessary to ensure that the RPC runtime is able to marshal
them. This is generally possible, especially when user-defined
types are composed of simple types, for which marshaling is
naturally provided.
Distributed object frameworks

• Distributed object frameworks extend object-oriented

programming systems by allowing objects to be distributed
across a heterogeneous network
• It leverage the basic mechanism introduced with RPC and
extend it to enable the remote invocation of object methods
and to keep track of references to objects
the common interaction pattern is the following:
• The server process maintains a registry of active objects that
are made available to other processes.
• The client process, by using a given addressing scheme,
obtains a reference to the active remote object.
• The client process invokes the methods on the active object
by calling them through the reference previously obtained.
Parameters and return values are marshaled as happens in
the case of RPC.
• Object activation and lifetime: The first element to be
considered is the object’s activation, which is the
creation of a remote object.
• Two types: server-based activation and client-based
activation.
• In server-based activation, the active object is created in
the server process and registered as an instance
• In the case of client-based activation, the creation of the
remote object is implicit
• Examples of distributed object frameworks
• Common object request broker architecture (CORBA) :
introduced by the Object Management Group (OMG) for
providing cross- platform and cross-language interoperability
among distributed components.
• A fundamental component in the CORBA architecture is the Object
Request Broker (ORB), which acts as a central object bus
• To simplify cross-platform interoperability, interfaces are defined in
Interface Definition Language (IDL )
• Distributed component object model (DCOM/COM1)
• DCOM introduces a set of features allowing the use of COM
components beyond the process boundaries.
• A COM object identifies a component that encapsulates a set of
coherent and related operations; it was designed to be easily
plugged into another application to leverage the features exposed
through its interface.
• Java remote method invocation (RMI) : Java RMI is a standard
technology provided by Java for enabling RPC among distributed
Java objects.
• RMI is based on the stub-skeleton concept. Developers define an
interface extending java.rmi.Remote that defines the contract for IPC
• The RMI runtime will automatically retrieve the class information for
the stub component
• .NET remoting : Remoting is the technology allowing for IPC
among .NET applications. It provides developers with a uniform
platform for accessing remote objects from within any
application developed in any of the languages supported by .NET.
• The Remoting infrastructure will automatically provide all the required
information to generate a proxy on a client application domain.
Service-oriented computing

• Service-oriented computing organizes distributed systems in

terms of services
• Service orientation expresses applications and software
systems as aggregations of services that are coordinated
within a service-oriented architecture (SOA).
What is a service?
• A service encapsulates a software component that provides a set
of coherent and related functionalities that can be reused and
integrated into bigger and more complex applications.
• four major characteristics that identify a service:
• Boundaries are explicit: A service-oriented application is generally
composed of services that are spread across different domains, trust
authorities, and execution environments.
• Services are autonomous: Services are components that exist to offer
functionality and are aggregated and coordinated to build more
complex system. They are not designed to be part of a specific system.
• Services operate in an unknown environment and interact with third-party
applications.
• Services share schema and contracts, not class or interface
definitions: Services are not expressed in terms of classes or
interfaces, as happens in object-oriented systems, but they define
themselves in terms of schemas and contracts.
• At the same time, a service orientation requires that contracts and
schema remain stable over time
• Services compatibility is determined based on policy: Service
orientation separates structural compatibility from semantic
compatibility.
• Structural compatibility is based on contracts and schema and can be
validated or enforced by machine-based techniques. Semantic compatibility is
expressed in the form of policies
•
• Service-oriented architecture (SOA)
• SOA is an architectural style supporting service orientation. It organizes a
software system into a collection of interacting services. SOA encompasses a
set of design principles that structure system development and provide
means for integrating components into a coherent and decentralized system.

• Features: Standardized service contract, Loose coupling, Abstraction,

Reusability, Discoverability etc
• Web services : Web services are the prominent technology for
implementing SOA systems and applications. They leverage Internet
technologies and standards for building distributed systems.
• Web service exposes a set of operations that can be invoked by
leveraging Internet-based protocols.
• HTTP is the most popular transport protocol used for interacting with
Web services.
• Service orientation and cloud computing: Web services and Web 2.0-
related technologies constitute a fundamental building block for
cloud computing systems and applications.
• Web 2.0 applications are the front end of cloud computing systems
• Cloud computing is also used to elastically scale and empower
existing software applications on demand.