It was written...
>
>
> When discussing Client/Server approaches, there are two things to
> consider:
>
> 1) The "native mode" IMAGE-intrinsics answer (which does not require SQL,
> ODBC, JDBC, etc... --  ADBC is ok because it provides a DIRECT link from a
> Java-enabled client to the native-mode MAGE intrinsics :-)
>
> 2) The emulation-mode "SQL" answer (which, for all practical purposes,
> requires some kind of ODBC-like layer between the client and the server).
>
>
> The operative phrase in Jim's original question is "to make it easier for
> the C/S application":
>

Although database level middleware is quick and easy to use for C/S
development, I believe that the above list should contain:

   3) The "remote method" answer (which allows server developers to express
their database as a series of remote invocable methods, thus encapsulating
the physical data with a logical series of API's)


> So, an answer that makes sense for a native-mode IMAGE-intrinsics solution
> may not make sense (from a performance viewpoint) for an
> SQL-bases solution.
>
> Normalization means "Keep together those things that belong together and
> keep apart those things that belong apart."
>
> Who is to say what "belongs" together and what "belongs" apart?  A
> particular state of "normalization" (or lack thereof) is neither good nor
> bad: It's some kind of compromise that you reach between theoretical
> consistency and practical performance.
>

Very well said. I would add the concept of "privacy". If a database is
completely normalized, a client using (2-tier C/S access technologies) will
be responsible for assembling a view of the data which meets their needs.
This assembly process directly impacts the number of database middleware
commands.

Whether a database is normalized or not, it still is the semantic blueprint
for how data will be managed, and is not the business of the client to be
privileged to this blueprint.

Changes to a server are possible w/out requiring commensurate changes on the
client (and vice-versa). This "looser coupling" is only accomplished when
deployment server using process-2-process based middleware (not ODBC, nor
native Intrinsics). Encapsulating the access to your data with a business
(logical) API allows for ongoing data restructuring and client redesign to
occur in a much looser (and distributed) fashion.

Table views can be used to provide some privacy, but they do not provide a
protection against changing database technologies, and are not a sufficient
representation (no behavior) of a reusable method.

It is valid to deploy C/S solutions using both ((#1 or #2) and #3)).
JDBC/ODBC can be used to separate the database from the application's core
business logic (requires the deployment of a "headless" application server)
AND remote method middleware can be used separate the client and the
application server. This model has been used with MPE as the server engine
for both the database and the application server, as well as with UNIX.

Jonathan van den Berg
Premier Software Technologies
fon: 408-257-8757
fax: 408-253-1184
www: www.premiersoft.com