Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Remote Procedure Call in Distributed systems 2, Lecture notes of Distributed Programming and Computing

Alexandria UniversityDistributed Programming and Computing

The design issues related to Remote Procedure Call (RPC) interfaces in distributed systems. It explains the advantages of using interfaces in distributed systems and how they support software evolution. It also discusses the impact of the distributed architecture on how service interfaces are defined, including the inability to access variables in a module running in another process and the limitations of parameter-passing techniques used in local procedure calls.

Typology: Lecture notes

2022/2023

Available from 04/13/2023

abdel-halim-mansour
abdel-halim-mansour 🇪🇬

3 documents

1 / 5

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Remote Procedure Call
Design issues for RPC
Interfaces in distributed systems
The modules of a distributed program might function as independent
processes. Particularly under the client-server architecture, each server
makes a set of operations accessible to clients. A file server, for
instance, might include instructions for reading and writing files. The
specification of the procedures provided by a server, which specifies
the kinds of arguments used in each operation, is referred to as a
service interface.
Programming using interfaces in distributed systems has a variety of
advantages because of the crucial distinction between interface and
implementation:
• As with any type of modular programming, programmers are only
concerned with the abstraction the service interface offers and
are not required to be familiar with implementation specifics.
• Extending to (perhaps heterogeneous) distributed systems,
programmers are also exempt from having to be familiar with the
underlying platform or programming language used to deliver the
service (an important step towards managing heterogeneity in
distributed systems).
pf3
pf4
pf5

Partial preview of the text

Download Remote Procedure Call in Distributed systems 2 and more Lecture notes Distributed Programming and Computing in PDF only on Docsity!

Remote Procedure Call

Design issues for RPC

Interfaces in distributed systems The modules of a distributed program might function as independent processes. Particularly under the client-server architecture, each server makes a set of operations accessible to clients. A file server, for instance, might include instructions for reading and writing files. The specification of the procedures provided by a server, which specifies the kinds of arguments used in each operation, is referred to as a service interface. Programming using interfaces in distributed systems has a variety of advantages because of the crucial distinction between interface and implementation:

  • As with any type of modular programming, programmers are only concerned with the abstraction the service interface offers and are not required to be familiar with implementation specifics.
  • Extending to (perhaps heterogeneous) distributed systems, programmers are also exempt from having to be familiar with the underlying platform or programming language used to deliver the service (an important step towards managing heterogeneity in distributed systems).
  • Since implementations may change as long as the interface (the external view) doesn't, this method naturally supports software evolution. Actually, the interface is flexible as long as it still works with the original. The distributed architecture of the underlying infrastructure has an impact on how service interfaces are defined:
  • A client module operating in one process is unable to access variables in a module running in another process. As a result, direct access to variables cannot be specified in the service interface. Notably, this criterion appears to be broken by the ability of CORBA IDL interfaces to provide attributes. The getter and setter methods that are automatically added to the interface are used to access the attributes rather than directly accessing them.
  • When the caller and procedure are in different processes, the parameter-passing techniques used in local procedure calls, such as call by value and call by reference, are ineffective. Call by reference in particular is not supported. Instead, the parameters are described as input or output, or occasionally both, in the definition of a method in the interface of a module in a distributed application. By delivering the values of the arguments in the request message and then including them as arguments in the operation to be conducted in the server, input parameters are sent to the remote server.

However many essential services already in existence are written in C++ and other languages. It would be advantageous to allow Java-based apps, among others, to access them remotely. Procedures written in various languages can call each other by using interface definition languages (IDLs), which are created for this purpose. In addition to having its type stated, an IDL provides a notation for designing interfaces in which each parameter of an operation may be characterized as for input or output. A straightforward CORBA IDL sample is shown in Figure 5.8. The Person structure is the same as the one that was used before to show marshalling. The RMI methods offered by a remote object that implements the PersonList interface are specified in that interface. For instance, the method getPerson, which gets a Person instance by name, provides its second argument as out, which denotes that it is an output argument. The method addPerson specifies its argument as in, denoting that it is an input parameter.

Although the IDL idea was primarily created for RPC systems, it also works for RMI and web services. Among our case studies are:

  • As an example of an IDL for RPC, see Sun XDR.
  • An IDL for RMI may be seen in CORBA.
  • the Web Services Descriptive Language (WSDL), which was created to support web services over the Internet
  • Storage and protocol buffers, which Google uses to store and exchange many types of structured data.