Re: Distributed applications and OOD

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 09/11/04 

Date: Sat, 11 Sep 2004 16:59:36 GMT

Responding to Bertilsson...

> For developing distributed applications, using EJB or Web Services,
> following pattern is very common: Data is transfered between the
> client and server using value-objects which purpose is to hold data
> and doesn't implement any logic at all. On the server-side, client
> requests are handled by facade objects that are stateless, which means
> that they have no member variables. Behind the facade layer there use
> to be a business logic layer or data access layer that are also
> stateless. All layers on the server-side use to operate on the
> value-objects.
>
> From my point of view this does not look like a object oriented
> design. You have pure data objects and pure functional objects. But
> still it is the only working design for distributed applications.
> Every attempt to have objects containing both data and logic, will
> have drawbacks. For example, if you use this kind of objects on the
> server-side, you still have to write data transfer objects, which will
> carry almost the same data as the "real" object, and you will have
> duplication in your code.
>
> What do you guys think of this?
> * This design is a bad design.
> * Or, this is still a good OO design.
> * Or, OO design is not suitable in distributed applications.
> * Or???

It depends on where the observer is standing. B-) In an OOA model all
those stateless objects will be stateful. For example, when
implementing an OOA model in an EJB/J2EE environment, each OOA class
will often end up being implemented in as many as four classes at the
OOP level. That's because the OOA model represents the customer's view
of the solution for only functional requirements. It is only when one
deals with nonfunctional requirements that one may need things like
stateless objects. So the OOA model doesn't even describe distributed
boundaries (except indirectly since they typically map to subsystem
boundaries).

[Basically one has three choices for where state lives in a distributed
environment: in the client, in the DB, or in the server. If it is in
the DB one has simpler clients and servers but the DB traffic is greatly
increased. If it is in the server one has low DB traffic and a simpler
client, but faces resources contention problems. If it is in the client
one has low DB traffic and a spartan server, but a more complex client
who must understand data dependencies between transactions. IOW, there
is no free lunch.]

A simplistic answer is that it is not good OO design but it is a
necessary optimization for nonfunctional requirements. That is, one has
to make compromises with the computational models as the level of
abstraction decreases.

Frankly, though, this doesn't worry me all that much. The OOPLs already
make substantial compromises with the computational model and procedural
processing (e.g., the separation of message and method, which is crucial
to good OOA/D does not exist in the OOPLs). However, those compromises
are benign so long as the OOA/D was done properly.

The same thing holds true for other optimizations like stateless objects
that are done during OOP. If the OOA/D is done properly, then the
process of transforming into optimized OOPL code during OOP is quite
straight forward. (Full code generators like PathMATE do this sort of
thing routinely.) The essential OOness of the design will still be
there despite the mechanisms. For example, full code generators for
translation often target straight C for performance reasons. The
resulting code is still structured in an OO fashion even though it is
written in a procedural language.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Relevant Pages

  • Re: suid bit files + securing FreeBSD (new program: LockDown)
    ... I found the design maybe LockDown or your IDS could use ... So you need at least one CFC server, ... the client boots, it will just use the files it already have and update ... The multicast address the client is a member of. ...
    (FreeBSD-Security)
  • Re: VB connection to SQL server
    ... > the client machine begins to lose its relevance and accuracy as soon as it ... > aware that the data is probably out of date, a client sided cursor might ... > design minimises the possibility that records will have changed in the ... >> The Database server is in the office, and people use the Vb program from ...
    (microsoft.public.vb.database)
  • Re: Architectural feedback
    ... That can influence your design. ... bank branches absolutely must be able to function with a failed server (or ... This means a lot of functionality is duplicated on the ... > with WinForms-based apps (assume all client machines are Windows running ...
    (microsoft.public.dotnet.general)
  • Re: events not fired on the non-development machine
    ... Can it be that my design is completely wrong? ... > good design to implement connection points in this case (don't ask me why ... server to it. ... the terms "client" and "server" are used too ...
    (microsoft.public.vc.atl)
  • Re: Distributed applications and OOD
    ... existing on the server... ... is the smart client a bad idea, is an overworked server a bad ... only understood by the system that created it, thus .NET remoting ... > still it is the only working design for distributed applications. ...
    (comp.object)