[
Lists Home |
Date Index |
Thread Index
]
Leigh Dodds wrote:
>
> Fieldings dissertation presents a number of architectural styles, and
> evaluates each of them within a defined context: distributed hypermedia.
> However he doesn't cover RPC in this classification (correct me if I'm wrong,
> I've only read through the whole thing once). RPC is mentioned in a
> later section [1] though.
Here you go:
"3.4.1 Client-Server (CS)
The client-server style is the most frequently encountered of the
architectural styles for network-based applications. A server
component, offering a set of services, listens for requests upon those
services. A client component, desiring that a service be performed,
sends a request to the server via a connector. The server either rejects
or performs the request and sends a response back to the client. A
variety of client-server systems are surveyed by Sinha [123] and Umar
[131].
Andrews [6] describes client-server components as follows: A client is a
triggering process; a server is a reactive process. Clients make
requests that trigger reactions from servers. Thus, a client initiates
activity at times of its choosing; it often then delays until its
request has been serviced. On the other hand, a server waits for
requests to be made and then reacts to them. A server is usually a
non-terminating process and often provides service to more than one
client.
Separation of concerns is the principle behind the client-server
constraints. A proper separation of functionality should simplify the
server component in order to improve scalability. This simplification
usually takes the form of moving all of the user interface functionality
into the client component. The separation also allows the two types of
components to evolve independently, provided that the interface doesn't
change.
The basic form of client-server does not constrain how application state
is partitioned between client and server components. It is often
referred to by the mechanisms used for the connector implementation,
such as remote procedure call [23] or message-oriented middleware [131]"
I think that I want to emphasize Mark Baker's point about constraints,
with a quote from the dissertation:
"There are two common perspectives on the process of architectural
design, whether it be for buildings or for software. The first is that a
designer starts with nothing--a blank slate, whiteboard, or drawing
board--and builds-up an architecture from familiar components until it
satisfies the needs of the intended system. The second is that a
designer starts with the system needs as a whole, without constraints,
and then incrementally identifies and applies constraints to elements of
the system in order to differentiate the design space and allow the
forces that influence system behavior to flow naturally, in harmony with
the system. Where the first emphasizes creativity and unbounded vision,
the second emphasizes restraint and understanding of the system context.
REST has been developed using the latter process."
I've been trying to stress in my recent messages that REST is what you
get if you take RPC and start imposing disciplines that have been
demonstrated to work in large, loosely coupled systems.
There are probably only a few hundred people on the planet who have
thought through most of the issues on application protocol design (is
there even a relevant book?). And I don't include myself in that list.
Yet RPC protocols turn us all into protocol designers. We all get to
re-invent how we will handle race conditions and what sorts of
intermediaries we want to support and what information needs to be made
available to them and how that information should be made available to
them and what the security implications are and how we will compose our
services and ...
Before someone points out that SOAP is "even more general than RPC":
that makes the amount of effort it takes to design a good SOAP protocol
even greater.
Paul Prescod
|
