Planning a paper? This brings up my current head-banging experiment,
in which I am trying to describe the HTTP object model for WWW7.
The problem is, everyone seems to have a different definition of what
an "object model" is supposed to be. Is there a canonical definition
of that term in the dist-obj literature somewhere?
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).
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.
Anybody have their own definition?
....Roy
[1] http://www.w3.org/DOM/
[2] http://www.omg.org/
====================================
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.