Wow. Good luck with that, the world could use a good HTTP object model.
> The problem is, everyone seems to have a different definition of what
> an "object model" is supposed to be.
You got that right. A quick perusal of
http://www.objs.com/workshops/ws9801/papers/index.html
reveals that the term "object model" -- like the terms "event", "event
model", "session", "pattern", "component", and so on -- can be overloaded
to mean, well, just about whatever the author intends.
> Is there a canonical definition of that term in the dist-obj
> literature somewhere?
In the aforementioned workshop I like Frank Manola's position paper
http://www.objs.com/workshops/ws9801/papers/paper022.html
which links to Frank's excellent (long) paper "Towards a Web Object
Model" at
http://www.objs.com/OSA/wom.htm
which gives the definition of "object model" as something that defines
"how the heterogeneous resources that make up the system can be modeled
as objects," where "objects" are "basic data structuring capabilities"
(presumably including methods for accessing, manipulating, and storing
the data stored in those structures). Frank goes on to view the Web in
its current incarnation as an object model:
| The Web, even in its current form, can be viewed as a simple form of
| distributed object system, with a particularly simple object model. In
| this model, HTML pages are considered as objects (actually, state),
| having identify provided by URLs, and methods defined by, or that are
| invoked via, HTTP servers. The methods supported by HTTP servers are
| extensible, and HTTP supports negotiation to find out what they are
| (even though GET and POST are the only methods generally used). The
| basic resemblance of the Web to a simple object system has created a
| natural interest in seeing how far the resemblance can be further
| developed.
Frank goes on to describe what needs to be done to make this object
model more substantial:
| 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
|
| As a result, what is needed to progress toward a Web object model is:
|
| 1. a richer base representation than HTML, in order to better
| represent "object state" (in particular, better support for semantic
| identification of fields, rather than simply supporting presentation
| aspects of data)
| 2. an API to this state, so that programs can readily access it
| (without complex parsing)
| 3. an enhanced ability to define relationships between this state
| and specified pieces of code that can serve as object methods
And goes on to consider XML, DOM, RDF, and some other technologies that
may help the Web rise to this task.
Let's compare this with what you (Roy) consider an object model:
> 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.
See, now, I find this fascinating. I would never have called this
HTTP's "object model" at first, but rereading it, I can see all kinds
of things that I consider to be part of an object model: interfaces,
encapsulation, data hiding. So yeah, now I do think this makes for
an interesting abstract model, and want to hear more of your thoughts on
it. And you're right, it's different from other "object models":
> 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).
> [1] http://www.w3.org/DOM/
> [2] http://www.omg.org/
See now, I would consider both of these to be object models, too. Which
means, like the Cheshire Cat, a word like "object model" means exactly
what I want it to mean, no more, no less.
> 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.
Ugh, I know, I can't find the OMA guide either --- browsing OMG's web
site is almost as painful as... browsing Microsoft's Web site. For all
of their "where do you want to go, toadie?" hype, www.microsoft.com is a
land of dangling links and lack of information. Example: being the
naturally curious person I am, I want to know more about COM++++++
(however many plusses there are now, I'm still nonplussed). So I go to
and take the link from there to DCOM (for which, since the page is in
frames, the URL does not show in the browser). Both the DCOM
technical overview nor the DCOM business overview give 404 Object Not
Found errors. (By the way, why is world leader Microsoft.Com still
using a HTTP 1.0 web server? Are HTTP 1.1 Web servers not available?)
So then I figure, forget DCOM, I'll look into COM+. Let me tell you, it
is IMPOSSIBLE for me to tell what COM+ is from looking on the Microsoft
web page. It's an object model. It's a component model. It's a
communication model. It's a transaction model. It's an event model.
It's a runtime service model. It's a floorwax and a dessert topping and
nature's laxative, too. Who's in charge here???
> Anybody have their own definition [of "object model"]?
I think the problem with object models is, everyone has their own
definition. Still, the work you (Roy) described for the HTTP object
model sounds compelling to me. Just like, if Jim Whitehead were to
expound on an abstraction for distributed authoring and versioning that
encapsulated the lessons of WebDAV, I would look forward to that, too.
One more thing, the OMG object model:
> In CORBA V2.1 August 1997, Section 1.1:
>
> The object model provides an organized presentation of object concepts
> and terminology. It defines a partial model for computation that embodies
> the key characteristics of objects as realized by the submitted
> technologies. The OMG object model is abstract in that it is not directly
> realized by any particular technology. The model described here is a
> concrete object model. A concrete object model may differ from the
> abstract object model in several ways:
>
> o It may elaborate the abstract object model by making it more
> specific, for example, by defining the form of request parameters
> or the language used to specify types.
>
> o It may populate the model by introducing specific instances of
> entities defined by the model, for example, specific objects,
> specific operations, or specific types.
>
> o It may restrict the model by eliminating entities or placing
> additional restrictions on their use.
>
> An object system is a collection of objects that isolates the
> requestors of services (clients) from the providers of services by a
> well-defined encapsulating interface. In particular, clients are
> isolated from the implementations of services as data representations
> and executable code.
>
> The object model first describes concepts that are meaningful to
> clients, including such concepts as object creation and identity,
> requests and operations, types and signatures. It then describes
> concepts related to object implementations, including such concepts as
> methods, execution engines, and activation.
>
> The object model is most specific and prescriptive in defining
> concepts meaningful to clients. The discussion of object
> implementation is more suggestive, with the intent of allowing maximal
> freedom for different object technologies to provide different ways of
> implementing objects.
>
> There are some other characteristics of object systems that are
> outside the scope of the object model. Some of these concepts are
> aspects of application architecture, some are associated with specific
> domains to which object technology is applied. Such concepts are more
> properly dealt with in an architectural reference model. Examples of
> excluded concepts are compound objects, links, copying of objects,
> change management, and transactions. Also outside the scope of the
> object model are the details of control structure: the object model
> does not say whether clients and/or servers are single-threaded or
> multi-threaded, and does not specify how event loops are programmed
> nor how threads are created, destroyed, or synchronized.
>
> This object model is an example of a classical object model, where a
> client sends a message to an object. Conceptually, the object
> interprets the message to decide what service to perform. In the
> classical model, a message identifies an object and zero or more
> actual parameters. As in most classical object models, a distinguished
> first parameter is required, which identifies the operation to be
> performed; the interpretation of the message by the object involves
> selecting a method based on the specified operation. Operationally, of
> course, method selection could be performed either by the object or
> the ORB.
So "abstract object model" = not realized by any particular technology.
"concrete object model" = realized by some particular technology.
"classical object model" = client sends messages to objects.
and no object model contains information about the control structure.
Which means, I guess, that threads and event loops I guess have their
own models. Which means that my own PhD work is not an "object model"
but an "event model". With a twist of garnish (add the word "global"
and it's a "Global Event Model (GEM)" in neon lights... :).
----
adam@cs.caltech.edu
I hope you know that this will go down on your permanent record.
-- Violent Femmes