User:Hemantk2/sandbox

Remote Procedure Call (RPC
Introduction Remote Procedure Call (RPC) is a protocol that one program can use to request a service from a program located in another computer in a network without having to understand network details. (A procedure call is also sometimes known as a function call or a subroutine call.) RPC uses the client/server model. The requesting program is a client and the service-providing program is the server. Like a regular or local procedure call, an RPC is a synchronous operation requiring the requesting program to be suspended until the results of the remote procedure are returned. However, the use of lightweight processes or threads that share the same address space allows multiple RPCs to be performed concurrently. 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 a client runtime program in the local computer. 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. In computer science, a remote procedure call (RPC) is an inter-process communication that allows a computer

program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction. That is, the programmer writes essentially     the same code whether the subroutine is local to the executing program, or remote. When the software in question uses object-oriented principles, RPC is called remote invocation or remote method invocation. History The idea behind RPC goes back to RFC707 from 1976. It proposed "resource sharing" and the basic idea behind RPC. Courier of Xerox was one of the first implementations, and NCS of Apollo Computer, as a basis for DCE / RPC was used Microsoft has its own implementation of RPC, MSRPC and DCOM , which is based on CORBA. A of RPC systems most commonly used, Sun RPC implementation, also known as ONC RPC. This is also used as the basis for their Network File System (NFS). Remote Method Invocation (RMI) was introduced in the Java environment, which emerged in the 90s, which is conceptually similar technology. Nowadays, more and more use of XML as IDL and HTTP as the network protocol. The big advantage of this way of working, better known as Web services, the simplicity and standardization of XML and HTTP have been widely recognized in most modern operating systems. Examples of such a system are SOAP, XML-RPC , and JAX-RPC. Remote Procedure Call (RPC) is a protocol that one program can use to request a service from a program located in another computer in a network without having to understand network details. (A procedure call is also sometimes known as a function call or a subroutine call.) RPC uses the client/server model. The requesting program is a client and the service-providing program is the server. Like a regular or local procedure call, an RPC is a synchronous operation requiring the requesting program to be suspended until the results of the remote procedure are returned. However, the use of lightweight processes or threads that share the same address space allows multiple RPCs to be performed concurrently. 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 a client runtime program in the local computer. 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. There are several RPC models and implementations. A popular model and implementation is the Open Software Foundation's Distributed Computing Environment (DCE). The Institute of Electrical and Electronics Engineers defines RPC in its ISO Remote Procedure Call Specification, ISO/IEC CD 11578 N6561, ISO/IEC, November 1991. RPC spans the Transport layer and the Application layer in the Open Systems Interconnection (OSI) model of network communication. RPC makes it easier to develop an application that includes multiple programs distributed in a network. Alternative methods for client/server communication include message queueing and IBM's Advanced Program-to-Program Communication (APPC). There are several RPC models and implementations. A popular model and implementation is the Open Software Foundation's Distributed Computing Environment (DCE). The Institute of Electrical and Electronics Engineers defines RPC in its ISO Remote Procedure Call Specification, ISO/IEC CD 11578 N6561, ISO/IEC, November 1991. RPC spans the Transport layer and the Application layer in the Open Systems Interconnection (OSI) model of network communication. RPC makes it easier to develop an application that includes multiple programs distributed in a network. Alternative methods for client/server communication include message queueing and IBM's Advanced Program-to-Program Communication (APPC). The idea of treating network operations as remote procedure calls goes back at least to the 1980s in early ARPANET documents Bruce Jay Nelson is generally credited with coining the term One of the first business uses of RPC was by Xerox under the name "Courier" in 1981. The first popular implementation of RPC on Unix was Sun's RPC (now called ONC RPC), used as the basis for Network File System. The RPC Model RPC is a simple and popular paradigm for implementing the client-server model in a distributed system. An RPC can be initialized by the applicant (client) which is a message or request message, sends it to a server, in order to carry a particular procedure, making use of the supplied arguments. Following the completion of the procedure, the server sends a reply message or reply back to the client. On this method, there are different variations creating multiple ( incompatible ) RPC protocols exist. A number of standardized RPC systems to servers accessible for different client machines are necessary. In this way, making abstraction of the platform-specific differences, or may be programs in multiple programming languages to communicate with each other. The majority of these systems use a description language (IDL) interface for multiple platforms to indicate the ability to invoke an RPC This language unambiguously describes the interface, regardless of the machine or the programming language ultimately used. Examples of such systems include Sun RPC (also known under the name of ONC RPC), Distributed Computing Environment (DCE), SAP RFC (Remote Function Call), Microsoft's DCOM (partly based on DCE) and CORBA.

Message passing An RPC is initiated by the client, which   sends a request message to a known remote server to execute a specified procedure with supplied parameters. The remote server sends a response to the client, and the application continues its process. While the server is processing the call, the client is blocked (it waits until the server has finished processing before resuming execution), unless the client sends an asynchronous request to the server, such as an XHTTP call. There are many variations and subtleties in various implementations, resulting in a variety of different (incompatible) RPC protocols. An important difference between remote procedure calls and local calls is that remote calls can fail because of unpredictable network problems. Also, callers generally must deal with such failures without knowing whether the remote procedure was actually invoked. Idempotent procedures (those that have no additional effects if called more than once) are easily handled, but enough difficulties remain that code to call remote procedures is often confined to carefully written low-level subsystems.

Sequence of events during a RPC 1.	The client calls the client stub. The call is a local procedure call, with parameters pushed on to the stack in the normal way. 2.	The client stub packs the parameters into a message and makes a system call to send the message. Packing the parameters is called marshalling. 3.	The client's local operating system sends the message from the client machine to the server machine. 4.	The local operating system on the server machine passes the incoming packets to the server stub. 5.	The server stub unpacks the parameters from the message. Unpacking the parameters is called unmarshalling. 6.	Finally, the server stub calls the server procedure. The reply traces the same steps in the reverse direction.

Standard contact mechanisms To let different clients access servers, a number of standardized RPC systems have been created. Most of these use an interface description language (IDL) to let various platforms call the RPC. The IDL files can then be used to generate code to interface between the client and server. The most common tool used for this is RPCGEN.

Open Network Computing (ONC) Remote Procedure Call (RPC) is a widely deployed remote procedure call system. ONC was originally developed by Sun Microsystems as part of their Network File System project, and is sometimes referred to as Sun ONC or Sun RPC. ONC is considered "lean and mean", but has limited appeal as a generalized RPC system for WANs or heterogeneous environments]. Systems such as DCE, CORBA and SOAP are generally used in this wider role. ONC is based on calling conventions used in Unix and the C programming language. It serializes data using the XDR, which has also found some use to encode and decode data in files that are to be accessed on more than one platform. ONC then delivers the XDR payload using either UDP or TCP. Access to RPC services on a machine are provided via a port mapper that listens for queries on a well-known port (number 111) over UDP and TCP. Implementations of ONC RPC exist in most Unix-like systems. Microsoft supplies an implementation for Windows in their Microsoft Windows Services for UNIX product; in addition, a number of third-party implementation of ONC RPC for Windows exist, including versions for C/C++, Java, and .NET (see external links). ONC RPC was described in RFC 1831, published in 1995. RFC 5531, published in 2009, is the current version. Authentication mechanisms used by ONC RPC are described in RFC 2695, RFC 2203, and RFC 2623. In 2009, Sun relicensed the ONC RPC code under the standard 3-clause BSD license and then reconfirmed by Oracle Corporation in 2010 following confusion about the scope of the relicensing. Remote Function Call is the proprietary SAP AG interface for communication between a SAP System and other SAP or third-party compatible system over TCP/IP or CPI-C connections. Remote function calls may be associated with SAP software and ABAP programming and provide a way for an external program (written in languages such as PHP, ASP, Java, or C, C++) to use data returned from the server. Data transactions are not limited to getting data from the server, but can insert data into server records as well. SAP can act as the Client or Server in an RFC call. Technical overview A Remote Function Call (RFC)is the call or remote execution of a Remote Function Module in an external system. In the SAP system, these functions are provided by the RFC interface system. The RFC interface system enables function calls between two SAP systems, or between a SAP system and an external system. RFC interfaces The RFC interface system is made up of the following interfaces: •	Calling interface for ABAP programs •	Each ABAP program can call a remote function module using the command CALL FUNCTION...DESTINATION. The parameter DESTINATION informs the SAP system that the called function module runs in a different system to the calling system. RFC communication with the remote system takes place as a part of the CALL FUNCTION command. •	RFC function modules in a SAP system must be proper function modules and must be registered in the SAP system as remote. •	If the calling program and the called program are both ABAP programs, the RFC interface provides both communication partners. The calling program can be any ABAP program, and the called program must be a function module that is registered as remote. •	Interfaces for calling non-ABAP programs If either the calling program or the called partner is not a SAP program, it must be programmed in such a way that it can play the role of the other partner in RFC communication. To implement RFC partner programs in non-SAP systems, read: Components of the SAP Communication Technology. RFC-supported and GUI-supported interfaces can be used by external programs to call function modules in SAP systems, and execute them in these systems. Likewise, ABAP programs can also use these interfaces to use functions supplied by external programs. Functions are remote-enabled by setting the "Remote-enabled module"-flag in the Attributes tab of the ABAP Workbench: Function Builder (transaction SE37).

The communication between the various parties in an RPC system is preferably as transparent as possible. This means that the developer can write code for procedures on another machine will be carried out, without knowing the details of the underlying communication In order to realize the communication between the client and the server RPC systems and programming languages use stubs or proxy objects. As a remote procedure call is handled by the client stub as a local procedure would be called in a separate code In place of the procedure to be carried out, it will, however, the stub compose a message and send it to the server. On the server, this message is then received by a server stub, the message turns out, the variables and calls the appropriate function in the server. The result is then passed back to the server stub, which it sends back to the client stub in turn. This picks up the message and passes the result in the same way as would be the procedure performed locally. Stubs are usually generated starting from the IDL description of the interface.