Distributed Computing Paradigms Distributed Application paradigms Distributed object paradigms

Distributed application paradigms Message passing paradigm Client server paradigm Peer to peer paradigm Message system paradigm Point to point message model Publish / subscribe model RPC model

Message passing pardigm The most fundamental paradigm Basic operations required are Send Receive For connection oriented Connect Disconnect Example : socket application program

Message passing using c

// server program to communicate with //client3 // server program to communicate with //client3.java till server says "bye" import java.net.*; import java.io.*; class server3 { public static void main(String args[]) try ServerSocket ss=new ServerSocket(127); Socket s=ss.accept(); BufferedReader sbr=new BufferedReader(new InputStreamReader(s.getInputStream())); BufferedReader cbr=new BufferedReader(new InputStreamReader(System.in)); PrintStream ps=new PrintStream(s.getOutputStream()); String sread="",cread=""; while(!sread.equalsIgnoreCase("bye")) sread=sbr.readLine(); System.out.print("\nServer : "+sread); System.out.print("\nClient : "); cread=cbr.readLine(); ps.println(cread); } s.close(); catch(Exception e) { System.out.println(e); } `

// continous communication till the server says //"bye“ import java // continous communication till the server says //"bye“ import java.net.*; import java.io.*; class client3 { public static void main(String args[]) try Socket s=new Socket("student",127); BufferedReader cbr=new BufferedReader(new InputStreamReader(System.in)); BufferedReader sbr=new BufferedReader(new InputStreamReader(s.getInputStream())); PrintStream ps=new PrintStream(s.getOutputStream()); String sread=" ",cread=" "; while(!cread.equalsIgnoreCase("bye")) System.out.print("\nClient :"); cread=cbr.readLine(); System.out.print(cread); ps.println(cread); sread=sbr.readLine(); System.out.print("\nServer :"+sread); } s.close(); catch(Exception e) { System.out.println(e); }

Client server paradigm Best known paradigm for network application the server process waits for requests, and the client in turn waits for responses.  Many Internet services are client-server applications. These services are often known by the protocol that the application implements. Well known Internet services include HTTP, FTP, DNS,

Programming facilities for client server paradigm Connection oriented socket API RPC API RMI API

Example : online auction For session control Server : waits to hear an announcement from auctioneer When the session starts Update the highest bid When the session ends Client : the auctioneer sends a request that announces the above 3 types of request For accepting bids Client : participant sends a new bid to server Server : accept a new bid and update the bid

A Sample Client-Server Application

Client-server system architecture vs Client-server system architecture vs. Client-server distributed computing In the client-server system architecture, the terms clients and servers refer to computers, while in the client-server distributed computing paradigm, the terms refer to processes.

Peer – Peer paradigm

Participating processes play different roles Has equal roles and responsibilities Well known example of peer to peer file transfer is napster.com(99,2001) and freenet.com etc., Both are used for online music sharing mp3 Companies went to loss because of no copyrights

Future of peer to peer

Disadvantages of a peer to peer network: the system is not centralized, making administration difficult lack of security no computer in the network is reliable Therefore, peer-to-peer networks are only useful for a small number of computers (generally about 10), and only suitable for applications that do not require a high level of security (it is not advisable in a business network containing sensitive data).

Can be implemented using protocols like jxta Jxta JXTA (Juxtapose) is an open source peer to peer protocol specification These protocols defined as a set of xml messages To allow any device connected to network to exchange messages and collaborate

Message system paradigm Is the elaboration of basic message passing paradigm Sender deposits a message on a system and forwards it to message queue associated with each receiver Point to point Publish/subscribe model

  The Point-To-Point Message Model In this model, a message system forwards a message from the sender to the receiver’s message queue. 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.

Point to point message in .net

JMS in java A JMS application is composed of the following parts: A JMS provider: A messaging system that implements the JMS specification. JMS clients: Java applications that send and receive messages. Messages: Objects that are used to communicate information between JMS clients. Administered objects: Preconfigured JMS objects that are created by an administrator for the use of JMS clients.

Point to point in jms Point-to-Point (Queue destination): In this model, a message is delivered from a producer to one consumer. The messages are delivered to the destination, which is a queue, and then delivered to one of the consumers registered for the queue. While any number of producers can send messages to the queue, each message is guaranteed to be delivered, and consumed by one consumer. If no consumers are registered to consume the messages, the queue holds them until a consumer registers to consume them.

In java

Publish/subscribe model Each message is associated with a topic or event. The process publishes a message announcing the vent or topic. The middleware message system distributes the message to all subscribers. Publish operation allows a process to multicast to group of processes. Subscribe operation allows a process to listen for such a multicast.

Publish/subscribe in jms Publish/Subscribe (Topic destination): In this model, a message is delivered from a producer to any number of consumers. Messages are delivered to the topic destination, and then to all active consumers who have subscribed to the topic. In addition, any number of producers can send messages to a topic destination, and each message can be delivered to any number of subscribers. If there are no consumers registered, the topic destination doesn't hold messages unless it has durable subscription for inactive consumers. A durable subscription represents a consumer registered with the topic destination that can be inactive at the time the messages are sent to the topic.

Jms programming model Jms provider supports 6 types of classes header Properties body.(optional) Jms provider supports 6 types of classes Message: This represents a message without a message body. StreamMessage: A message whose body contains a stream of Java primitive types. It is written and read sequentially. MapMessage: A message whose body contains a set of name/value pairs. The order of entries is not defined. TextMessage: A message whose body contains a Java string...such as an XML message. ObjectMessage: A message whose body contains a serialized Java object. BytesMessage: A message whose body contains a stream of uninterpreted bytes.

Testing jms in jmeter

Toolkits based on the Message-System Paradigm The MOM paradigm has had a long history in distributed applications. Message Queue Services (MQS) have been in use since the 1980’s. The IBM MQ*Series6 is an example of such a facility. http://www-4.ibm.com/software/ts/mqseries/ Other existing support for this paradigm are Microsoft’s Message Queue (MSQ), http://msdn.microsoft.com/library/psdk/msmq/msmq_overview_4i lh.htm

For auction Each participant subscribe to begin auction event message The auctioneer signifies the beginning of the auctioning session by sending a begin auction even message Upon receiving the begin auction event a participant subscribes to an end auction event message The auctioneer subscribes to messages for new bid events A participant wishing to place a new bid issues a new bid event message At the end the auctioneer issues an end auction event

Remote Procedure Call 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.

There are two prevalent APIs for Remote Procedure Calls. Since its introduction in the early 1980s, the Remote Procedure Call model has been widely in use in network applications. There are two prevalent APIs for Remote Procedure Calls. The Open Network Computing Remote Procedure Call, evolved from the RPC API originated from Sun Microsystems in the early 1980s. The Open Group Distributed Computing Environment (DCE) RPC. Both APIs provide a tool, rpcgen, for transforming remote procedure calls to local procedure calls to the stub.  

RPC in auctioning system Provides a remote procedure for each participant to register itself and another procedure for a participant to make a bid Each participant provides the following remote procedures To allow the auctioneer to call a participant to announce the onset of session To allow the auctioneer to inform a participant of a new highest bid To allow the auctioneer to announce the end of session

Distributed object paradigms RMI ORB Object space Mobile agent paradigm Network services paradigm Collaborative application (Groupware) paradigm

RMI Remote method invocation Is an object oriented equivalent to RPC

Rmi in auctioning RPC Vs RMI Same as RPC but uses object and methods instead of procedures. RPC Vs RMI

ORB paradigm Object request broker This is a basis of CORBA (Common object request broker architecture)

Object spaces Object spaces is a computing paradigm originated by Dr. David Gelernter at Yale University. A language called Linda was developed to support the concept of global object coordination. A space is a shared, network-accessible repository for objects. Instead of communicating with each other, processes coordinate by exchanging objects through one or more spaces.

Object space Object Spaces is a paradigm for development of distributed computing applications. It is characterized by the existence of logical entities, called Object Spaces. All the participants of the distributed application share an Object Space. A provider of a service encapsulates the service as an Object, and puts it in the Object Space. Clients of a service then access the Object Space, find out which object provides the needed service, and have the request serviced by the object.

A space may be transient, or it may be persistent. An object may be identified using properties lookup; if a desired object is not currently available, a process can wait until one arrives. Objects deposited in a space are passive. Unlike other models, processes don’t modify objects in the space or invoke an object’s methods directly. To modify an object, a process must explicitly remove it, update it, and reinsert it into the space.

Space Process B Process A Write Read Space containing Entry Objects Waiting Take Process C Process D

Object spaces

Properties of spaces: Spaces are shared: Multiple processes physically located on same or different machines can interact with a space concurrently with the sapce handling all the protocol of concurrent access Spaces are persistent: Objects can be stored reliably in a space for a lease time or indefinitely until they are removed. Also lease time can be extended by renewing the lease Spaces are associative: Objects in a space are retrieved located via associative lookup, meaning we can prepare a template of one /multiple fields representing the query and get result back. This allows a lot of advantages to query using simple expressions rather than remembering object Id or the name

Spaces are transactionally secure: JavaSpaces transactions have the inbuilt ACID properties. Every operation in the space is atomic. Transactions are supported for single operations on a single space, as well as multiple operations over one or more spaces. Spaces let you exchange executable content: While in a space, objects are just passive data -- you can't modify them or invoke their methods. However, when you read or take an object from a space, a local copy of the object is created. As with any other local object, you can modify its public fields and invoke its methods, even if you've never seen an object like it before. This coupled with associative lookup offers advantages as compared to RMI.

Javaspaces is a set of API that provides a special kind of service to a JINI federation. It can operate as part of a bigger JINI federation or be in a single federation on its own. Every object in the space is of type ‘Entry’ which is a interface in net.jini.core.entry package For example, we have to write a Task object in space, its definition would be public class Task implements Entry {         public String content;       // a no-arg constructor         public Task() {         }     } It’s a no-marker interface, all members of the class should be public as this lets to lookup objects in space using associative lookup, should have a no argument constructor to facilitate serialization to transfer objects in and out of space

Conventions that our entries An entry must have a public constructor that takes no arguments Another convention is that fields of an entry should be declared public A third convention is that fields of an entry must contain references to objects, rather than primitive types

API write: Places one copy of an entry into a space. If called multiple times with the same entry, then multiple copies of the entry are written into the space. read: Takes an entry that is used as a template and returns a copy of an object in the space that matches the template. If no matching objects are in the space, then read may wait a user-specified amount of time until a matching entry arrives in the space. take: Works like read, except that the matching entry is removed from the space and returned as the result of the take. In addition, the JavaSpace interface supplies the following methods, which can be useful in many applications:

Distributed applications using object spaces To build applications based on object spaces, one designs distributed data structures and distributed protocols that operate over the object spaces. A distributed data structure is composed of multiple objects that are stored in one or more spaces. A distributed protocol defines the way participants share and modify these data structures in a coordinated way. 10/21/2019

Distributed applications using object spaces - 2 Example: The participants are a set of controllers for printers. The data structure is a queue of printing tasks for multiple printers The protocol may be that each participant will try to coordinate with each other to avoid duplicating the same task and to handle errors.

Example applications - chat room – auction

JavaSpace Is an implementation which supports the object space paradigm. Is based on Jini – it runs on top of Jini, as a service.

Component-based Technologies Microsoft’s COM, Microsoft DCOM, Java Bean, and Enterprise Java Bean are also based on distributed- object paradigms. In addition, application servers, are popular for enterprise applications, are middleware facilities which provide access to objects or components. IBM’s WebSphere, http://www.as400.ibm.com/products/websp here/docs/as400v35/docs/admover.html

The Mobile Agent Paradigm A mobile agent is a transportable program or object. In this model, an agent is launched from an originating host. The agent travels from host to host according to an itinerary that it carries. At each stop, the agent accesses the necessary resources or services, and performs the necessary tasks to accomplish its mission.

Mobile agent is a distributed computing paradigm. 10/21/2019 Mobile agent is a distributed computing paradigm. It has become viable, with recent technologies such as those provided by Java. It has great potential for network applications. It has not been widely deployed.

Mobile (transportable) agents An agent is “an independent software program which runs on behalf of a network user”. A mobile agent is a program which, once it is launched by a user, can travel from node to node autonomously, and can continue to function even if the user is disconnected from the network.

Process for migration System Agent 1 System Agent 2 Every system in the network contains System Agent Local system agent communicates with the remote system agent If the remote system agent permits that particular mobile agent, the mobile agent is migrated to the remote system. Mobile Agent communicates with the local system agent for the remote resource Mobile Agent is created in search of resources

Advantages of Mobile Agents They allow efficient and economical use of communication channels which may have low bandwidth, high latency, and may be error-prone. They enable the use of portable, low- cost, personal communications devices to perform complex tasks even when the device is disconnected from the network. They allow asynchronous operations and true decentralization

The mobile agent paradigm vs. the client-server paradigm

Basic Architecture An agent server process runs on each participating host. Participating hosts are networked through links that can be low- bandwidth and unreliable. An agent is a serializable object whose execution state can be frozen for transportation and reconstituted upon arrival at a remote site.

Basic Architecture

What’s in the Agent? An agent is an object, hence it contains state data and methods. Among the instance data is an itinerary of the sites to be visited, which may be dynamically constructed or adjusted. Other data may include an agent ID or other authentication data. The agent’s behavior at each stop can be pre- programmed and dynamically adjusted.

Mobile-agent applications Information retrieval Monitoring Virtual market-place/ meeting room Shareware  

The Network Services Paradigm In this paradigm, service providers register themselves with directory servers on a network. A process desiring a particular service contacts the directory server at run time, and, if the service is available, will be provided a reference to the service. Using the reference, the process interacts with the service. This paradigm is essentially an extension of the remote method call paradigm. The difference is that service objects are registered with a global directory service, allowing them to be look up and accessed by service requestors on a federated network. Java’s Jini12 technology is based on this paradigm.

The Collaborative Application (Groupware) Paradigm In this model, processes participate in a collaborative session as a group. Each participating process may contribute input to part or all of the group. Processes may do so using: multicasting to send data to all or part of the group, or they may use a virtual sketchpads or whiteboards which allows each participant to read and write data to a shared display.

Distributed Application Paradigms

Summary - 1 The paradigms presented were: Message passing Client-server Message system: Point-to-point; Publish/Subscribe Distributed objects: Remote method invocation Object request broker Object space Mobile agents Network services Collaborative applications