[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ozone object identity...

Falko Braeutigam wrote:
> 
> On Mon, 30 Apr 2001, David Li wrote:
> > I am back. Got side track to do some Waba hacking. Waba is a Java VM
> > implementation for small device like Palm or Pocket PC. There will be
> > some relevance with the object identity we are discussing here later on.
> >
> > Well... This is getting philosophical but here we go.
> 
> philosophical? maybe. but not waste!
> 

I'm very intrigued with this thread and think it is well worth the
discussion. I haven't had time to look at the source yet but have been
working with the system and ran through the examples. I've worked with
Versant before and also Poet Navajo(Java embedded ODMG base).
Looking from a design perspective, we have to look at the purpose(s)
for Ozone to determine its design. Now that people are working on the
follow on versions is a good time to open up discussions.

Overall, we need to look at the applications and context
that ozone is to support. This includes the Web, embedded, and other
enterprise or personal use. My personal interest is for a home
objectbase that organizes inventory as well as other applications.

> ok. What you are saying is: hashCode() + equals() does not make up the identity
> of an object. I agree. But this wasn't the problem. The problem was that 1) we
> wanted to use a proxy as a key in a hashtable and 2) we needed something that
> we could store and find the corresponding object in the db later on.
> 
> Olas suggestion to return an object that properly implements hashCode() +
> equals serves both 1) and 2) well.
> 
> Except that my idea of naming the method that return this object 'identity()'
> does not really correspond to the idea of this method. This breaks my own ideas
> since, as I stated from the beginning, I do not want to give the programmer an
> ID or identity or something like that.

Looking at the identity of the object, there is one issue. I agree with
Falko as an implementer point of view that if the ID of an object is
completely internalized then this is a good thing for the implementer
and the programmer. However, the questions are as follows: 
Do we want to allow an externalized representation of an ozone object? 
Does this solve another class of problems for the programmer?. 
I'd like to skip down past the W3C links as I think they are pertinent
to this discussion. 

> 
> > and an identity is the most important value of an object in a OO world.
> 
> True but again, IMO the programmer does not need a way to directly access this
> identity of a persistent object.

> > My idea is to return a String repreenting the Object ID. My current
> > thinking is to use an URI to represent the object id. This idea is
> > largely influence by the RDF and Semantic Web
> > (http://www.w3.org/2001/sw/). The idea is to make each ozone object
> > universal on Internet.
> > 
> > The format of the URL will be roughly look like the following:
> >
> > ozonedb:remote://ozone.d11e.com:3333/com.d11e.MyObject/1.0/1234/5678
> 
> Hmmm.... I don't like this. (read on!)
> 
> >
> > The ideas here are largely influenced by the following
> >
> > I. Webizing existing systems:
> >
> >   http://www.w3.org/DesignIssues/Webize.html
> >
> > II. Universal Resource Identifiers -- Axioms of Web Architecture
> >
> >   http://www.w3.org/DesignIssues/Axioms.html
> >
> > III. Naming and Addressing: URIs, URLs, ...
> >
> >   http://www.w3.org/Addressing/
> >

My understanding of the web is that each document which could be
considered an object has a unique identifier which is based on a
compound name in Naming system terms. We are all familiar with the
format URI and the static web is essential completely externalized. We
may even need to discuss whether we think the web is brain dead or not.
I don't know exactly where I am going with this so bear with me. From an
application stand point, the externalized aspect of the web makes each
request to get a document as simple a http. This returns a document or
perhaps a document fragment if the end point url is an application
(servlet, cgi, etc.) that takes an XPath query or just another page
based on the query parameters(key value pairs). I point this out because
one of the points Tim O'Reilly points out is that UNIX is powerful
because of input/process/output model. This allows commands to be
chained such as ls | grep foo | wc -l which would count the number of
files from the current working directory that match the argument to
grep. The point is that these applications can be grouped and chained in
ways that weren't thought of ahead of time because of the
input/process/output model. In this way, a web serving XML files can be
processed in this manner via XML tools such as XSLT.
Input/XSLT(transform or process)/output. So what is the point?
If ozone is going to play in the web world, I believe it must have an
externalized form to XML and I believe this requires an externalizable
object identifier.

Other possible uses of ozone is is the PDA/Phone embedded space where
synchronization is very important. Whether this is done in an external
or a pure object format I'm not sure. I know poet Navajo had that
ability to externalize to XML and the XML ID was the externalized form
of the object ID. When using Versant, it seemed to me that the object ID
API was very helpful. Some objects have no relational
equivalence(equals()). This means that there was no key to the object so
an equals method could not really be defined by the programmer -- or at
least it made no sense to do so. They called their ID's GUID (Globally
Unique Identifier) and it was made up of three parts. When doing some
web research on GUIDs, it turns out that DEC used GUIDs for RPC and
Microsoft uses them for their distributed system(what ever the current
name is). The Versant design was pre-web. The parts were essentially the
machine ID(I assume from the ethernet ID) plus the object base ID (more
than one obase possible for each machine) and the third part was the
object ID. They said the ID lasted from the creation to the death of the
object and the ID's where never reused. There are problems with any ID
approach. If the internal ID generation changes or the external format
changes, the processor must handle both ways and the two generation
methods can't conflict or overlap. Some of the problems are as follows:

1. Schema evolution and object ID's - serialization handles this is some
special cases, other cases fail.
2. Object migration and replication.
3. Import and export and what to do with the object ID's.

So if you look at object identifiers globally then a three part OID
makes sense. Machine or host id, objectbase id(upon creation), and the
object portion. An object replicated to another server would change the
first two parts and one copied from one db to another on the same
machine would only change the second part. This it seems to me solves
many of the distributed objectbase class of problems.

I wanted to show a bit of the APIs from EJB for reference as well. All
remote objects in EJB extend from java.rmi.Remote (marker interface) and
then javax.ejb.EJBObject. EJBObject has the following method: boolean
isIdentical(EJBObject). This method says that the stub you are working
with is referencing the same server object. EJBObject also has a Handle
getHandle() method which returns a Handle which is Serializable and has
the method EJBObject getEJBObject().

<snip>
public interface Handle
extends java.io.Serializable

The Handle interface is implemented by all EJB object handles. A handle
is an abstraction of a network
reference to an EJB object. A handle is intended to be used as a
"robust" persistent reference to an EJB
object. 
</snip>

This means that an EJB handle can be serialized to disk or other
persistent store and then once recreated in memory has enough info to
recreate the object by talking to the server and then the server will
create the object and the stub is returned. I also looked at the
java.rmi.MarshalledObject class which has a equals() hashcode() and
get() method that returns the object stored inside the Marshalled
object. This object gets tagged with the codebase URL so the system may
load the class if needed. One other thing related to this was the
ObjectSpace distributed object system. Some of the neat things here was
the ability to migrate objects which required a codebase server(for
class loading) and something like the marshalled object which enables
agents and the ability to create the stubs of the fly and load them in
the VM. I think java 1.3 rmi can do this but I haven't kept up.

I wanted to participate in this discussion even though I'm pretty much a
newbie to Ozone so I hope some of this is helpful.

Eric