Distributed Systems Assessment - Essay Example

Communication between components in a distributed system may be done using "Message Passing", "Remote Procedure Call" or "Remote Object Invocation". The key features of these three mechanisms are given below: Message Passing: The Message Passing Interface (MPI) model refers to a computing model in which a computation comprises one or more processes that communicate by calling library routines to send and receive messages to and from other processes. In most implementations of MPI, a fixed set of processes is created at program initialization, and one process is created per processor. However, these processes may execute different programs. Hence, the MPI programming model is also referred to as Multiple Program Multiple Data (MPMD) programming model to distinguish it from the Single Program Multiple Data (SPMD) model in which every processor executes the same program, but on different data. Because the number of processes in an MPI computation is normally fixed, processes can use point-to-point communication operations to send a message from one named process to another. These operations can be used to implement local and unstructured communications. A group of processes can call collective communication operations to perform commonly used global operations such as summation and broadcast. The most important feature of MPI model from a software engineering viewpoint is its support for modular programming. A mechanism called a communicator allows the MPI programmer to define modules that encapsulate internal communication structures. These modules can be combined by both sequential and parallel composition. Algorithms that create just one task per processor can be implemented directly, with point-to-point or collective communication routines used to meet communication requirements. Algorithms that create tasks in a dynamic fashion or that rely on the concurrent execution of several tasks on a processor must be further refined to permit an MPI implementation. For example, consider the branch-and-bound search algorithm, which creates a tree of ''search'' tasks dynamically. This algorithm cannot be implemented directly in MPI; however, it can be refined to obtain an algorithm that creates a fixed set of worker processes that exchange messages representing tree nodes to be searched. The resulting SPMD algorithm can be implemented as an MPI program. Algorithms that are not easily modified in this way are better implemented using alternative technologies, namely, Remote Procedure Call or Remote Object Invocation. Remote Procedure Call: As the name refers, Remote Procedure Call (RPC) is a mechanism by which, a subroutine or procedure stored at remote location can be executed. It is very useful in distributed computing as the procedure can be executed virtually at any location. The user of the may call a procedure lying on a remote computer without having to the under layer network technologies and details. It is a client / server protocol, where the requesting program is known as client and the service-providing program is known as server. In the remote procedure call model, one thread of control logically winds through two processes: the caller's process, and a server's process. These two processes may be executed on virtually any processors, connected through any communication medium. The caller process first sends a call message to the server process and waits for a reply message. The call message includes the procedure's parameters, and the reply message includes the procedure's results. Once the reply message is received, the results of the procedure are extracted, and caller's execution is resumed. It can now use the result of the remote procedure recently executed. On the server side, a process is dormant awaiting the arrival of a call message. When one arrives, the server process extracts the procedure's parameters, computes the results, sends a reply message, and then waits for the next call message. In the example model, detailed above, only one of the two processes is active at any given time. But actually it is implementation dependent. Different Operating Systems may deal with the problem differently, for example, Sun Microsystem has implemented the RPC protocol making no restriction on the concurrency model. The implementation may choose to have RPC calls be asynchronous, so that the client may do useful work (which is independent to the result of the RPC call) while waiting for the reply from the server. Another possibility is to have the server create a separate task to process an incoming call, so that the original server can be free to receive other requests and pass them to the same or different processors. When program statements that use RPC are compiled into an executable program, a stub is included in the compiled code that acts as the representative of the remote procedure code. When the program is run and the procedure call is issued, the stub receives the request and forwards it to the client runtime program in the local machine. The client runtime program has the knowledge of how to address the remote computer and server application and sends the message across the network that requests the remote procedure. Similarly, the server includes a runtime program and stub that interface with the remote procedure itself. Results are returned the same way. Following diagram explains the flow of messages in Remote Procedure Call model: There are a few important ways in which remote procedure calls differ from local calls to the procedures or subroutines [RFC 1057 page 2-3, also RPC 5531 pg 5]: 1. Error handling: failures of the remote server or network must be handled when using remote procedure calls. 2. Global variables and side-effects: since the server does not have access to the client's address space, hidden arguments cannot be passed as global variables or returned as side effects. 3. Performance: remote procedures usually operate one or more orders of magnitude slower than local procedure calls. 4. Authentication: since remote procedure calls can be transported over insecure networks, authentication may be necessary. It can, therefore, be concluded that even though there are tools to automatically generate client and server libraries for a given service, the protocols still needs to be designed very carefully, keeping in mind the security and performance issues. Remote Object Invocation: Remote Object Invocation model is Object Oriented implementation of Remote Procedure Call. In this model, clients may execute remote method calls on a server using transparent interface. It provides a way to interact with classes and objects on different classes and objects on other networked computers. From the perspective of the client, objects on the server may be referenced as if they were local. CORBA is introduced by OMG and provides an IDL (Interface Definition Language) and an API (Application Programming Interface, that enables client / server object interaction with a specific implementation of an Object Request Broker (ORB). ORB is a middleware that establishes the client / server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across the network. The invocation is typically of the form object.operation(args), where object is the requested object, operation is the operation or method to be invoked, and args are the arguments passed to the object. The ORB intercepts the call and is responsible for finding an object that can implement the request, passing it's the parameters, invoking its method and returning the results. The client does not have to be aware of where the object is actually located, its programming language, its operating system or any other system aspects that are not part of the object's interface. In doing so, the ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems. Being of Object Oriented technology, this model has all the features of it including, data-hiding, abstraction, persistence, inheritance etc. and security mechanisms may be implemented in the object itself, compared to external development as required by RPC. References 1. Jim Farley (1998). "Java Distributed Computing" published by O'Reilly & Associates, Inc., 101, Morris Street, Sebastopol, CA 95472 in 1998. 2. Request for Comments (RFC) # 1057 titled "RPC : Remote Procedure Call." by Sun Microsystems Inc. in June 1988 page number 2 to 3. 3. Request for Comments (RFC) # 5531 titled "RPC : Remote Procedure Call Protocol Specifications version 2." by Sun Microsystems in May 2009 page number 5. 4. Kamel M., Leue S. (1998) "Validation of the General Inter-ORB Protocol (GIOP) Using the Spin ModelChecker". Technical Report CWC03, Department of Electrical and Computer Engineering University of Waterloo, 1998 5. Kamel M., Leue S. (Nov. 1998) "Validation of Remote Object Invocation and Object Migration in CORBA GIOP using Promela/Spin''. Paper published and presented in the 4th International SPIN Workshop (SPIN'4), Paris, France on 2nd Nov. 1998 6. Decouchant D., Duda, A. (Oct. 1990) "Remote execution and communication in GUIDE - an object-oriented distributed system". In the proceedings of Experimental Distributed Systems, 1990, IEEE workshop on 11-12 October 1990 page numbers 49 to 53. 7. Yuasa K., Kumar Sinha P. (Mar. 1993) "Network Programming Support with Object Oriented Paradigm", In proceedings of Computers and Communications, 1993, Twelfth Annual International Phoenix Conference on 23-26 March 1993 page numbers 495 to 501. 8. Michi Henning, Steve Vinoski (1999). "Advanced CORBA Programming with C++" published by Addison Wesley Longman, Inc., One Jacob Way, Reading, Massachusetts 01867 on Feb. 12, 1999. Read More