Client/Service relationships & Flow of Requirements.

Having both our friendly HS Lahman and a colleague point me at Lahman's
blog on the subject I have finally read...

http://pathfinderpeople.blogs.com/hslahman/2004/06/clientservice_r.html

The client/service relationship does, indeed, reflect a dependency
between the client and the service. However, that dependency is
reflected in a flow of requirements rather than a function calling
hierarchy. That is, the client(s) define the requirements for the
service. In particular, communications between the client and service
subsystems are entirely orthogonal to the flow of requirements. This is
an enormously important point in understanding the structure of OO
applications.

While I'm mostly in agreement with HS sentiments there are a number of,
ahh, umm, shall we say, "points of clarification" that need to be made.

1) Whilst requirements may, as HS says, "flow from client to Service",
this is a negotiated flow.

At any stage the owner of the Service is entitled to say one or more of
the following...
a) That requirement doesn't fit into my single clear responsibility. That
requirement is either your responsibility or that of another, possibly as
yet unwritten service.
b) Fulfilling that requirement requires state that I do not and should
not own. Ask it of the owner of that state, not me.
c) I have many other clients, adding that requirement will break my
obligations to them. Go make another plan, either implement that
requirement yourself, or possibly creating a new service that implements
that requirement, possibly using me to implement the bulk of the work.

2) This is perhaps a semantic quibble. A service may well have
preconditions, which are a requirement on the client to meet before
invoking the service. ie. There can well be a flow of requirements from
the service to the client.

3) I regard the dependency tree as clearly involving the call graph in two
ways.
a) If the service explicitly names compile time symbols of the client, do
not be surprised if it becomes very difficult to ever reuse that service.
(The old cry, "Waah! We can't do software reuse, it's too difficult.
Yes, well. You didn't write reusable software so don't cry now that you
can't get software reuse.) If enough symbols are involved change
"difficult" to "impossible to reuse", even within the same executable.

b) As an empirical observation, rather than a hard and fast rule. But one
with a high probability of being valid. Service code that makes explicit
synchronous function calls to the client often create thread races and
subtly smash invariants.

Thus I prefer the hard and fast rule that the service be entirely ignorant
of the client, and the client _only_ knowledgable about the interface of
the service. So much as a single upward reference is forbidden.

There are saner ways involving link time, boot time or run time
registration of clients that work better, often using the pattern that
both the client and the service depend on a common stateless
Javalike interface.


--


John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@xxxxxxxxxx
New Zealand


.

Relevant Pages

  • Re: Netzwerkproblem GBit -> 100MBit
    ... Acknowledgement" gerade auf dem Server, ... Richtung die Einstellung auf dem Client interessant. ... (Die Flow Control-Einstellung am Cisco ist etwas seltsam: ... eigentlich nur noch der Netgear Mist bauen, ...
    (de.comp.sys.novell)
  • Re: Client/Service relationships & Flow of Requirements.
    ... communications between the client and service ... subsystems are entirely orthogonal to the flow of requirements. ... I used to completely agree with HS' remarks above (accepting your ... called when particular external conditions are met. ...
    (comp.object)
  • Re: Does anyone have any answers?
    ... >There's a one-way flow of information from the servers to the clients. ... info goes from client to server. ... >client the hole cards of other players' hands. ...
    (rec.gambling.poker)