ogram to execute. 8. Testing # . /sever # ps -ef grep sever root 2894 1 1 10:42:26? 0:00 . / sever root 2994 10839 0 10:42:33 pts/4 0:00 grep sever // This shows that the server is running with process id # ./client usage: . ./client server_host # /client 122.102.201.11 Node State is Active // 1. Client connects to server // 2. Calls the getState procedure // 3. Gets response as "1" // 4. Prints string "Node State is Active" corresponding to "1" in switch condition 27.7 Conclusion Remote procedure call defines a powerful technology for creating distributed client- server programs. The RPC runtime libraries manage most of the details relating to network protocols and communication. With RPC, a client can connect to a server running on another platform. For example, the server could be written for Linux and the client could be written for Win32. This makes RPC programming different from normal socket based communication. It is to be noted that RPC in not quite common in working on Web pages when using the Internet. One of the most important concepts to understand about the Web services framework (WSF) is that it is not a distributed object system. Web services communicate by exchanging messages, more like JMS than RMI. The WSF doesn't support remote references, remote object garbage collection, or any of the other distributed object features developers have come to rely upon in RMI, CORBA, DCOM, or other distributed object systems. Web communication deals with a browser type of client process and Web server type of server process (socket programming). The RPC is for distributed environment. This concluding paragraph is intended to give the reader an understanding on how RPC is different Fundamentals of EMS, NMS and OSS/BSS from socket programming that is discussed in the preceding chapter and Web communication that will be discussed in the next chapter. Additional Reading 1. Per Brinch Hansen. The Origins of Concurrent Programming: From Semaphores to Remote Procedure Calls. New York: Springer, 2002. 2. John Bloomer