PROCEDURE-ORIENTED MIDDLEWARE
Procedure-oriented middleware is characterized by a client converting the parameters of a procedure into a message, sending this message to the server (or host), who then converts the message back into the parameters. This converting of the parameters into a message is called marshalling.
Good examples of this type of middleware are Open Network Computing (ONC) from Sun Microsystems, Inc. and Distributed Computing Environment (DCE) from Open Software Foundation (OSF).
The strengths of this procedural-oriented middleware are:
It uses standard types of naming service, remote process, and returns a
response.
It supports exceptions by returning a message that a failure occurred.
It hides the intricacies of the network by using the ordinary procedure call
mechanism familiar to every programmer.
These strengths are good, but are outweighed by the weaknesses.
Weaknesses:
It is not scaleable because RPC does not have a replication mechanism.
It cannot return another program, which means it is not reflexive.
It is a rigid process because it is tightly coupled to the procedure. The Client must wait to receive a response before continuing the process (known as synchronous communication).
It assumes that the network is available and the bandwidth is not a constraint. There is no optimization for the exchanges in messages.
It requires multi-threading. The client must send out a thread for the RPC.Likewise, the server also handles a thread for each client. This can cause lock-ups, especially with shared resources and a high volume of requesting clients.
If the network goes down, the server is slow, or the message is lost, the client is left waiting unless time-outs are programmed. The problem with time-outs is that the message may be sent more than once and this can create additional problems.
