Re: [Gnue-dev] Why the Object metaphor?

[Stanley A. Klein]

First, let me say I think this is a very important discussion.  I said in
an earlier posting in this thread that GNUe is at the bleeding edge of
technology.  I really meant it.  I don't think you can find an other
project/product, commercial or free software, that is attempting to serve
as wide a range of uses and OS/database platforms as GNUe.  I had a similar
discussion with Reinhard and Jan and it resulted in what I regard as a
major insight in describing the relationship between business rules and
information security.

I hope we can work through the (somewhat email-based) difficulty in making
ourselves clear and avoiding the appearance of emotional ad hominem
arguments while we are discussing this extremely difficult subject.  I
think GNUe will be the better for our having done so.

There are two problems I see evident in the discussion so far.  The first
problem is that there are only so many words in the language and they tend
to get reused with different meanings in different contexts.  We try to be
concise and use these words, but each use comes with baggage, and we have
to be careful not to get the various baggages mixed up.  

"Object" is a word that gets overused.  We try to keep the uses separate,
but sometimes it is difficult.  It might be a good idea to either come up
with a different word or add a modifier, such as "business object" whenever
we use it.  And we need to have the mental discipline to keep the baggages
from the various uses of "object" separate.

The second problem is that we seem to be mixing up the deep infrastructure
and the user-viewable infrastructure in our discussions.  It may help to
refer to something like the old ANSI-SPARC three-layer model of a database
system.  The layers are the physical layer, the enterprise layer and the
application layer.  The physical layer is where the storage and the
database management system reside.  It is strictly the domain of computer
techies.  The enterprise layer is where the overall enterprise schema
resides, and where every data element of the enterprise is known.  It is
the domain of the enterprise data administrator, who is both a techie and a
business person.  The application layer contains views of the enterprise
needed for specific purposes.  This is where business users interact with
the database system.

With respect to the models themselves, I lean to the relational model, but
I think the object model may also have its uses.  

I am very comfortable with the relational model.  Tables are easy to
understand.  People use them all the time, in both technology and ordinary
written communications.  I think that both the relational model and
spreadsheets are based on tables, as was paper-and-ink accounting (although
paper and ink obviously don't have a computer to force consistently
following certain principles in the way things are structured :-).

The relational model for databases replaced the network and hierarchical
models, which I found incomprehensible (as did a lot of other people).  (In
response to a comment by Dan, I would point out that the hierarchical model
is not the same as a hierarchical taxonomy that categorizes things.)

Objects (of OOP type) are also useful.  People understand them because they
have the flexibility to represent things people encounter in the real
world.  I personally find that a lot of the programming technology related
to OOP is difficult to understand, mainly because its expression is so
concise and its ability to reuse work is so extensive that a reader needs
to go through everything in detail to be able to understand anything.
(GNUe has progressed to the point that I can't understand anything anymore
about what is going on in the code. There are just too many "where did that
come from" situations. :-)

I've addressed the relational versus object issue in the past from the
perspective of the security framework.  The main concern I have is that the
user (or really the enterprise data administrator) needs to be able to
trace the data items across Appserver (in the multi-tier model) to be able
to set up the security if higher levels of assurance are required.  I think
if the system is relational on both sides of Appserver, that works (and is
what Reinhard has stated to be the case).  I don't know too many object
databases, and understand them to be tricky, but if both sides of Appserver
are based on the object model, that is traceable, too.

Regarding business users underatanding of the system, I think that can be
done within the relational model.  I think that is essentially what is
going on in GNUe-sb (although I haven't yet figured out how to update my
copy of the GNUe-sb CVS or tried further to straighten out my attempt to
subscribe to the GNUe-sb e-mail list).  When I last looked, the effort
there was all in terms of SQL.

Let me toss one other hot button into the discussion.  I recently attended
something called the monthly "Collaborative Exploration Workshop."  It is a
combined Federal government, industry, etc. meeting that is exploring
issues in e-government.  A speaker at the last meeting talked about "Web
Services," which I had always taken to be a buzzword without content behind
it.  The speaker (the former CIO of Utah) talked about web services as a
more loosely coupled replacement for the (he implied legacy) tightly
coupled concept of multi-tiered systems.  (BTW, he also admitted that many
people use the term as a content-free buzzword that can mean whatever they
happen to be selling. :-)

Many of the things he mentioned I recognized as being present in GNUe, and
I'm sure that GNUe can be a useful component in the kind of system he was
talking about.  Should we keep the "web services" concept in mind, even as
we are discussing the key building block of a multi-tiered system?

I hope I've contributed to the (continuation) of this valuable discussion.
Let's keep it going.  I think we will all learn something as a result.


Stan Klein