Important characteristics that distinguish distributed applications from
conventional applications which run on a single machine:
Paradigm means “a pattern, example, or model.”
In the study of any subject of great complexity, it is useful to identify the
basic patterns or models, and classify the detail according to these
This presentation aims to present a classification of the paradigms for
distributed applications over mobile environment.
Arguably the most fundamental concept in computer science, abstraction is
the idea of detail hiding.
We often use abstraction when it is not necessary to know the exact details
of how something works or is represented, because we can still make use of
it in its simplified form. Getting involved with the detail often tends to
obscure what we are trying to understand, rather than illuminate it.
In software engineering, abstraction is realized with the provision of tools or
facilities which allow software to be built without the developer having to be
cognizant of some of the underlying complexities.
Widely varying modes of use
The system components are subject to wide variations in workload (e.g.
some web pages have millions of hits a day and some may have no hits).
Some applications have special requirements for high communication
bandwidth and low latency (e.g multimedia apps).
Wide range of system environments
A distributed system must accommodate heterogeneous hardware,
operating systems, and networks.
Non-synchronized clocks, concurrency problems, many modes of
hardware and software failures involving the individual components of
Attacks on data integrity, ensuring confidentiality, denial of service. 5
The publish/subscribe message model offers a powerful
abstraction for multicasting or group communication.
The publish operation allows a process to multicast to a group of
and the subscribe operation allows a process to listen for such
Each message is then associated with a specific topic or
Applications interested in the occurrence of a specific event may
subscribe to messages for that event.
When the awaited event occurs, the process publishes a message
announcing the event or topic.
The middleware message system distributes the message to all its
Between providers and consumers
No coordination & synchronization
Create highly dynamic, decentralized systems
Dimensions Of Decoupling
No need to hold references or even know each other
No need to be available at the same time
Control flow is not blocked by the interaction
Message passing is the most fundamental paradigm for
A process sends a message representing a request.
The message is delivered to a receiver, which processes the
request, and sends a message in response.
In turn, the reply may trigger a further request, which leads to a
subsequent reply, and so forth.
The basic operations required to support the basic message
passing paradigm are send, and receive.
For connection-oriented communication, the operations connect
and disconnect are also required.
With the abstraction provided by this model, the interconnected
processes perform input and output to each other, in a manner
similar to file I/O. The I/O operations encapsulate the detail of
network communication at the operating-system level.
In this model, a message system forwards a message from the
sender to the receiver’s message queue.
Unlike the basic message passing model, the middleware provides a
message depository, and allows the sending and the receiving to be
Via the middleware, a sender deposits a message in the message queue of
the receiving process.
A receiving process extracts the messages from its message queue, and
handles each one accordingly.
Messages stored in FIFO queue.
Producers append messages asynchronously
Consumers dequeue them synchronously
Coupled in sync (consumer side)
Here the nodes share a global address space and
communicate by writing to a global space.
A typical representative of this model is a bulletin board
where groups of people can share their ideas by posting
information at a common shared location.
Producers insert data asynchronously
Consumers read data synchronously
Coupled in sync (consumer side)
Tuple space model, processes communication by inserting
and removing tuples from a shared tuple space.
Which act like a globally shared memory.
Tuple communication decoupled in time because process
can insert and retract tuple independently.
Interaction model provide time & space decoupling.
An in-based interaction: implement one-to-n semantics(only
one consumer reads given tuple)
Read based interaction: implement one-to-n message
delivery(a given tuple can be read by all consumer)
There are three operation perform in tuple space
Out() :- To export a tuple into tuple space
in() :- To import a tuple from tuple space
Read():-To read a tuple from tuple space(without removing)
Tuple space has originally integrated at the language level
in Linda. The original Linda model is
Sun microsystem’s java spaces(1999)
As applications grew increasingly complex, it became desirable
to have a paradigm which allows distributed applications to be
programmed in a manner similar to conventional applications
which run on a single processor.
The Remote Procedure Call (RPC) model provides such an
abstraction. Using this model, inter-process communications
proceed as procedure, or function, calls, which are familiar to
A remote procedure call involves two independent processes,
which may reside on separate machines.
A process, A, wishing to make a request to another
process, B, issues a procedure call to B, passing with the call
a list of argument values.
As in the case of local procedure calls, a remote procedure
call triggers a predefined action in a procedure provided by
At the completion of the procedure, process B returns a
value to process A.
Marshalling is the packing of procedure parameters into a
The RPC stubs call type-specific procedures to marshal (or
unmarshal ) the parameters to a call
The client stub marshals the parameters into a message
The server stub unmarshals parameters from the message and uses
them to call the server procedure
The server stub marshals the return parameters
The client stub unmarshals return parameters and returns them to the
Binding is the process of connecting the client to the server
The server, when it starts up, exports its interface
Identifies itself to a network name server
Tells RPC runtime it’s alive and ready to accept calls
The client, before issuing any calls, imports the server
RPC runtime uses the name server to find the location of a
server and establish a connection
The import and export operations are explicit in the server
and client programs
Priya Venkitakrishnan, Sharan Raman, Smita Hegde & Sreekanth
Narasimhan, “Message Passing in Mobile Environments,” Project
Paper for Advanced Operating Systems Course, Spring 2002.
P.Th. Eugster, P.A. Felber, R. Guerraoui, A.-M. Kermarrec, ‘The
Many Faces of Publish/Subscribe’, Microsoft Research Limited.
Eiko Y oneki, ‘Mobile Applications with a Middleware System in
George Coulouris, Jean Dollimore, Tim Kindberg, “Distributed
Systems Concepts and Design”, Addison Wesley Publishers
Limited, Third Edition.
Deepak G, Dr. Pradeep B S,“Challenging Issues and Limitations
of Mobile Computing”, IJCTA | JAN-FEB 2012.
Yongqiang Huang, Hector Garcia-Molina, "Publish/Subscribe in
a Mobile Environment."