1. Discuss the concepts of interface (API). (15 marks) API stands for application program interface. The applications are the tools, games, social networks and other software that we users use to interact with the computer. Programming is how engineers create all the software that makes our lives so much easier and an interface is a common boundary shared by two applications or programs that allow both to communicate with one another.
An application-programming interface (API) is a set of programming instructions and standards for accessing a Web-based software application or Web tool. A software company releases its API to the public so that other software developers can design products that are powered by its service.
An API is a software-to-software interface, not a user interface. With APIs, applications talk to each other without any user knowledge or intervention. When you buy mobile phone online and enter your credit card information, the mobile phone Web site uses an API to send your credit card information to a remote application that verifies whether your information is correct. Once payment is confirmed, the remote application sends a response back to the mobile phone Web site saying it's OK to issue the phone.
Users only see one interface -- the mobile phone Web site but behind the scenes, many applications are working together using APIs. This type of integration is called seamless, since the user never notices when software functions are handed from one application to another.
In technical perspective API is a specification written by providers of a service that programmers must follow when using that service It describes what functionality are available, how they must be used and in what format they will accept an input or return an output.
API analogy: Every time a user wants to access a set of data from an application, you have to call the API. But there is only a certain amount of data the application will let you access, so you have to communicate to the operator in a very specific language—a language unique to each application.
For example we can take API as a middleman between a programmer and an application. This middleman accepts requests and, if that request is allowed, returns the data. The middleman also informs programmers about everything they can request, exactly how to ask for it and how to receive it.
API calls: they are applied whenever a developer or tool requests information from an API, they need to call (or, more technically speaking, create a request to) that API. Many open APIs have strict limits on how many times people can make a call in order to limit traffic and not overwhelm the API with requests.
How it works
An API resembles Software as a Service since software developers don't have to start from scratch every time they write a program. Instead of building one core application that tries to do everything -- e-mail, billing, tracking, etcetera -- the same application can contract out certain responsibilities to remote software that does it better.¬
For example Web conferencing is software as a service since it can be accessed on-demand using nothing but a Web site. With a conferencing API, that same on-demand service can be integrated into another Web-based software application, like an instant messaging program or a Web calendar.
The user can schedule a Web conference in his Web calendar program and then click a link within the same program to launch the conference. The calendar program doesn't host or run the conference itself. It uses a conferencing API to communicate behind the scenes with the remote Web conferencing service and seamlessly delivers that functionality to the use.

2. Both local and remote procedure call should be (effectively) be indistinguishable to programmers. This requires:
i. Semantic transparency ii. Syntactic transparency
Justify
I. Semantic transparency; - Semantics of remote procedure calls are identical to those of local procedure calls.
II. Syntactic transparency; - A remote procedure call should have the same syntax as a local procedure call.
Justification:
RPCs can’t achieve the same semantics as the local procedure calls due to following differences
a).RPCs unlike local procedure calls ,the called procedure is executed in an address space that is disjoint to the calling program’s address space hence the called procedure cannot have access to the calling program’s environment’s variables or data values .hence
 Passing addresses (pointers) as arguments is meaningless.
 So, passing pointers as parameters is not attractive.
 An alternative may be to send a copy of the value pointed, but this has subtly different semantics and can difficult to implement
 Call by reference can be replaced by copy in/copy out but at the cost of slightly different semantics.
b). Remote procedure calls are more vulnerable to failure than local procedure calls this is because they involve two different processes network and two different computers. Hence programs that make use of RPC must have the capability to handle those errors which won’t occur in local procedure calls. This makes it more difficult to make RPCs transparent
c) RPCs consume much more time (100 to 1000 times) than local procedure calls due to the involvement of communication network. Hence, achieving semantic transparency is not easy
3. Discuss the communication protocols for RPCs
Remote Procedure Call (RPC) provides a different paradigm for accessing network services. Instead of accessing remote services by sending and receiving messages, a client invokes services by making a local procedure call. The local procedure hides the details of the network communication. When making a remote procedure call:
1. The calling environment is suspended, procedure parameters are transferred across the network to the environment where the procedure is to execute, and the procedure is executed there.
2. When the procedure finishes and produces its results, its results are transferred back to the calling environment, where execution resumes as if returning from a regular procedure call.
The following steps take place during an RPC:
1. A client invokes a client stub procedure, passing parameters in the usual way. The client stub resides within the client's own address space.
2. The client stubs marshalls the parameters into a message. Marshalling includes converting the representation of the parameters into a standard format, and copying each parameter into the message.
3. The client stub passes the message to the transport layer, which sends it to the remote server machine.
4. On the server, the transport layer passes the message to a server stub, which demarshalls the parameters and calls the desired server routine using the regular procedure call mechanism.
5. When the server procedure completes, it returns to the server stub (e.g., via a normal procedure call return), which marshalls the return values into a message. The server stub then hands the message to the transport layer.
6. The transport layer sends the result message back to the client transport layer, which hands the message back to the client stub.
7. The client stub demarshalls the return parameters and execution returns to the caller.
Semantics:
Call-by-reference: The client and server don't share an address space. That is, addresses referenced by the server correspond to data residing in the client's address space.
One approach is to simulate call-by-reference using copy-restore. In copy-restore, call-by-reference parameters are handled by sending a copy of the referenced data structure to the server, and on return replacing the client's copy with that modified by the server.
However, copy-restore doesn't work in all cases. For instance, if the same argument is passed twice, two copies will be made, and references through one parameter only changes one of the copies.
.

4. Discuss the concept behind the following terms:
i. Server binding
In computer programming, to bind is to make an association between two or more programming objects or value items for some scope of time and place. The Client/Server Binding works by having a non¬dedicated copy of mfserver running on the server tier; this copy of mfserver communicates with any and all clients using an agreed server name. Themfserver module can be run using its built-in defaults, as its only function is to receive requests from the client to establish or terminate a connection. This is applicable if you have more than one network connectionon your computer, example. If you have one computer at your home, and you have two, or there, or four network cards plugged into it, each will have their own IP address. You can use ‘bind’ so that the server will only listen to a particular IP address.

ii. Lightweight RPC Lightweight Remote Procedure Call (LRPC) is a communication facility designed and optimized for communication between protection domains on the same machine. The LRPC is a communication facility designed and optimized for cross-domain communications. It uses simple control/data transfer and simple stubs and its designed for concurrency.
It uses the stubs. The stubs are responsible for managing all details of the remote communication between client and server and send messages to each other to make RPC happen.

5. Differentiate between:
i. Monolithic kernel OS and Micro-kernel OS.
Monolithic kernels are used in UNIX and Linux. Microkernels are used in QNX, L4 and HURD.
Monolithic kernels use signals and sockets to ensure IPC, microkernel approach uses message queues.
Monolithic kernels are faster than microkernels.
Adding a new feature to a monolithic system means recompiling the whole kernel, whereas with microkernels you can add new features or patches without recompiling. ii. Cross domain and cross machine.
A cross domain is a form of controlled interface that provides the ability to manually and automatically access and transfer information between different security domains it facilitate exchange of information across networks with varying security protocols while cross machine is where we have two or more machine closely communicating through sharing of resources (processor speed, disk space). This machine is connected/linked through communication links.

REFERENCE

i) Mok, A. K. (1983). Fundamental design problems of distributed systems for the hard-real-time environment.

ii) Coulouris, G. F., Dollimore, J., & Kindberg, T. (2005). Distributed systems: concepts and design. pearson education.

iii) Mullender, S. (1993). Distributed systems. ACM Press/Addison-Wesley Publishing Co.