I see your distinction. Previously, I had referred to #1 as "object
models" and #2 as "component models", but those are just words, words,
words, for the same thing.
> >| The fundamental components of any object model are:
> >| 1. data structures that can represent object state
> >| 2. ways to associate behavior (object methods) with the object state
> >| 3. ways for the object methods to access and operate on that state
> This description of an object model in terms of "fundamental components" is
> an example of usage #1. An extensive description of a number of different
> "object models" (in this sense) can be found in the X3H7 Object Model
> Features Matrix (http://www.objs.com/x3h7/h7home.htm). This is the way I
> generally use the term "object model"; it's a generalization of how the
> term "data model" is used in the phrase "the relational data model" (I'm
> basically a database person, so I guess this makes sense).
I think it makes a lot of sense to approach objects from the database
standpoint, since data persistence problems seem similar for both
objects and databases when you distribute them.
That X3H7 features page is a really excellent overview of all of the
major object models (with the exception of the Java Object Model, which
I guess would fall into usage #1 where the language is concerned, and
usage #2 where the Beans component model is concerned).
> > > What I view to be the HTTP object model is the theory of HTTP resource
> > > access and manipulation from the black-box viewpoint of an HTTP client.
> > > That is, the model of the server's resources that a client must "imagine"
> > > they are manipulating via the HTTP interface. In that sense, the HTTP
> > > object model is always abstract.
> > > The HTTP object model differs from things like the Document Object
> > > Model (DOM) [1] and OMG's Object Management Architecture [2]. DOM
> > > considers the object model to be the set of interfaces for
> > > manipulating a document as a hierarchy of objects (i.e., what HTTP
> > > would refer to as one representation of a resource after it has
> > > been delivered to the client). In that sense, what DOM is
> > > defining is an API for client-side manipulation of the entities
> > > present in a hypermedia workspace (a concrete model).
> The DOM seems to me to be an example of "object model" usage #2: it is a
> description of a (particular kind of) document *in* objects (in terms of
> various kinds of object interfaces). It's hard for me to tell from the
> discussion, but the HTTP object model may also be a usage #2 example.
Yes, from my understanding it is.
> Usage #2 is what the object analysis & design folks often mean by "object
> model" (when you're through with the design, you have an "object model" of
> your application). When in this environment, usage #1 is sometimes
> referred to as a "metamodel" (or "metametamodel", depending on what level
> you're at: and if you think the meaning of "object model" is hard to get
> hold of, try anything with "meta" in front of it!)
Heh. I believe you. :)
> > > OMG's view of object model is given by example in CORBA 2.1 (below).
> > > The real definition is supposed to be in the OMA Guide, but I have
> > > yet to find a copy of that.
> The OMG's usage of "object model", particularly the one in the OMA Guide,
> is generally usage #1 (the reason the OMA may not be accessible is that the
> text has not kept up with the development of other OMG specifications, and
> is undergoing major rewriting; the object model section in particular
> needs a lot of work).
Thanks; I thought they were just keeping some information from
non-consortium members. Personally, I look forward to reading the new
OMA guide... someday...
----
adam@cs.caltech.edu
If the enemy is in range, so are you.