December 26, 2007
Defining SOA: Part II, Client/Server
In the previous post on defining SOA I claimed that SOA is an architectural style building on four other architectural styles. The first one of these is Client/Server.
Describing client/server is easy -- not because I am such a genius (far from it), but it has already been done numerous times. Let's take a look at the definition from Roy Fielding's now-famous dissertation (The link is to Chapter 3; REST is defined in Chapter 5 if you are interested):
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].
SOA takes from the client/server style the two roles -- i.e., in each interaction one party is the client (what I call "service consumer") and the other is the server (service) which handles the request coming from the client*. Unlike traditional client/server, the roles are held only for a particular set of interactions -- a given interface that the service exposes. In another set of interactions the roles can be reversed and a component that once was a server can now act as a client even working with the very same component that was previously its client.
Like REST, SOA takes the constraint of separation of concerns which allow the service and its service consumers to evolve independently (as long as the interface is kept).
To support this, services should takes care of all its internal state without exposing its internal state or its internal structures outside of the service. This also allows the service to scale behind the interface but for that we also need constraints and capabilities from the next architectural style layered system, which
I'll discuss in the next installment on this subject.
*You can compose SOA with other architectural styles such as EDA and have the service also push data, but that isn't something SOA does in its basic form.
Posted by Arnon Rotem-Gal-Oz at 05:13 PM Permalink
|
