Re: [Gnue-dev] New Architecture Drawing based on Whitepaper.

[Stanley A. Klein]

Reinhard -

I have no problem with the use of the term "object" to refer to things that
are not OOP.  (I happen to chair an Object Registration Working Group
within the IEEE Power Engineering Society, where the objects of interest
are data elements and data structures for use in communication protocols.
We sometimes call them "data objects" to distinguish them from OOP-type
objects.)

My main concern, and I think you may have answered it, is that while the
relational paradigm restricts data structures to tables and fields
(preferably normalized according to certain rules), an object paradigm
allows a wider range of data structures.  For example, an object paradigm
would allow a data structure whose components could themselves be tables.
Trying to map such a data structure into a single relational table can be
very complicated.

If all the various properties of a GNUe business object map to fields of
database tables it would seem that they could be expressed as SQL/gsd and
that the underlying paradigm is really relational regardless of the name.
BTW, I think this would be quite different from the old GEAS, which to the
extent I understood it, mapped an object paradigm onto a relational
database with all the attendant complexities.

If my understanding of your response is correct, then we need only guard
against people taking the apparent object paradigm too seriously and trying
to introduce  non-relational data structures on the front side of the
appserver.


Stan


At 06:40 AM 12/6/2002 -0500, Reinhard Mueller <address@hidden> wrote:
>
>Am Don, 2002-12-05 um 09.16 schrieb Stanley A. Klein:
>> However, there is a challenge in trying to do this that is evident from
>> your terminology.  "Table and field names" implies a relational paradigm.
>> "Class and property names" implies an object paradigm. =20
>[snip]
>> However, if the front side is object and the back side is relational, I
>> think there may be a problem.  These kinds of mappings tend to be complex
>> and less easy to understand.  Objects can have structures that don't easi=
>ly
>> map into tables and fields.
>
>A business object can basically have
>* basic properties, which map to a database field 1:1
>* calculated properties, which don't have a database mapping at all
>* compound properties, where every element maps to a database field 1:1
>* reference properties, which map to a database field 1:1 and
>* list properties, which map to a field in another table 1:1
>
>I don't see any problem in this.
>
>The basic misunderstanding here seems to be that everybody seems to hear
>"object" and thinks "oh, no, they are going to do inheritance,
>polymorphism and all that stuff!!"
>
>Please refer to the Appserver Whitepaper
>(http://www.gnuenterprise.org/docs/whitepaper.html) for an explaination
>of what we call a "business object". It is not "object" as in "object
>oriented programming", it's more "object" as in "thing".
>
>We use the terms "class" and "property" not because we want to refer to
>OOP, but we use them because they fit best for what we mean.
>
>Of course, there's some overlap between the classical OOP model and our
>business object definition. The main part of the overlap is the concept
>of "encapsulation", which means that we define the data elements and the
>code to operate on them side by side.
>
>I hope this brings some light into this issue.