Your SlideShare is downloading. ×
Designing Application over mobile environment
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Designing Application over mobile environment

48
views

Published on

detail description of message passing ; …

detail description of message passing ;
public subscriber

Published in: Engineering, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
48
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Prepared by: Mugisha Robert, Maulik Patel
  • 2. Introduction Issues and challenges Publish/subscribe paradigm Message Passing Point-to-point/Message Queuing Shared spaces Remote invocation References 2
  • 3.  Important characteristics that distinguish distributed applications from conventional applications which run on a single machine:  Inter-process communication.  Event synchronization.  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 models.  This presentation aims to present a classification of the paradigms for distributed applications over mobile environment. 3
  • 4. Abstractions  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. 4
  • 5.  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.  Internal problems  Non-synchronized clocks, concurrency problems, many modes of hardware and software failures involving the individual components of the system.  External threats  Attacks on data integrity, ensuring confidentiality, denial of service. 5
  • 6.  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 processes,  and the subscribe operation allows a process to listen for such multicast.  Each message is then associated with a specific topic or event.  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 subscribers. 6
  • 7. 7
  • 8. Decoupling  Between providers and consumers  Increase scalability  No dependencies  No coordination & synchronization  Create highly dynamic, decentralized systems Dimensions Of Decoupling  Space  Time  Synchronization (flow) 8
  • 9.  Space decoupling No need to hold references or even know each other 9
  • 10.  Time decoupling No need to be available at the same time 10
  • 11.  Synchronization decoupling Control flow is not blocked by the interaction 11
  • 12.  Message passing is the most fundamental paradigm for distributed applications.  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. 12
  • 13. Process A Process B a message Message passing 13
  • 14.  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. 14
  • 15.  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 decoupled.  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. 15
  • 16. 16  Messages stored in FIFO queue.  Producers append messages asynchronously  Consumers dequeue them synchronously  Coupled in sync (consumer side)
  • 17.  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. 17
  • 18.  Producers insert data asynchronously  Consumers read data synchronously  Coupled in sync (consumer side) 18
  • 19.  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. 19
  • 20.  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) 20
  • 21.  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)  IBM Tspaces(2001) 21
  • 22.  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 application program. 22
  • 23.  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 process B.  At the completion of the procedure, process B returns a value to process A. 23
  • 24. 24
  • 25.  Marshalling is the packing of procedure parameters into a message packet  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  On Return  The server stub marshals the return parameters  The client stub unmarshals return parameters and returns them to the client program 25
  • 26.  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 26
  • 27.  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 Publish-Subscribe Paradigm.’ 27
  • 28.  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." 28