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

Re: Ozone object identity...

> What David seems to suggest is that every ozone
> object should be globally and eternally unique (GEU),
> and retrievable via a retrieval mechanism in Ozone 
> that you feed with a identifier object. I believe this 
> is good, and that it breaks my suggestion for using Object.
> 

There are two stages of my requirement here. 

1. For our RDF database, we have a lot of anonymous objects that are
tedious to be named. These objects are containers for other objects and
need to be searched (indexed) by its component's attributed.

In a more concrete way in the context of RDF, a Model is a set of
Statement. A Statement is simply a triple of (Resource, Resource,
String) or (Resource, Resource, Resource). The query on Model is to give
an "template" triple with null acting as a wildcard and retrive all
statements that match the template. 

We want to support indexing on all three elements. Given a template
statement, we want to have all matching statement returned. 

As RDF is quite verbose (generating a lot of statement), it would be
nasty for an implementation to name all of the statements and keep track
of the uniquness of the names. 

In this requirement, we only need something unique with in an instance
of Ozone database. 

2. On another project, we need to support discountinuous operations on
the database. This is mostly for handheld devices which connect to
database, retrive some objects, disconnect, use the object locally and
connect back to the database to perform some synchronization.

A concrete example is a phone book. We currently have a lot of devices
arround us that has a phone book on them: phone, pda, computer, company
intranet and etc. It's nasty to try to synchronize all the phone book.
Sometime, I remember I have a number for someone but can't remember
where I stored it. 

We want to use Ozone as a central repository for the phone book and have
all clients retrive the information from it.

For Palm, the phonebook is synchronized which hotsync. A copy of the
query result is "cached" on the client device and carried with the
users. Users may do some change on the PDA and later on store the change
back to the server. 

This calls for some way to store the object proxy locally and synchonize
to the server while it's connected again. 

In this requirement, we need something to be stored locally and be able
to connect back to its global instance while done. Consider the
combination of different local copies and potentially different servers
we may want to sync to. For example, I want to sync the business phone
book from company intranet db and personal phone book with the one on my
PC.

A identity with GEU properrty would help to solve the problem much
faster.

> My suggestion was to use Object as the minimal interface
> for the identifier, so that the API wouldn't be locked to
> a particular identity class for all future.
> 

I am all for using Object as the minimal interface. However, we do need
to extend it a little bit because of the problem mentioned in my
previous mail about the Java Object model be transient, e.g. the object
identity is established by using the memory address of the object at
runtime. We need a identity that has GEU properties.

I think using an Identity object (better, interface) with the following
methods to representing the properties.

1. An additional method to the OzoneObject:

Identity identity();

2. Two Ozone object ozOne and ozTwo are identical 

  IF AND ONLY IF

ozOne.identity().equals(ozTwo.identity());

The equals will give us the desired property of identity. However, for
implementation purposes to satisfy additional requirements, we need the
Interface to have two additional methods:

1. hashCode() to make easy integration with Collection framework

2. toString() to return a string representation of the identity that
satisfy the caching requirement.

> I don't think an int value (as returned by Object#hashCode())
> will suffice for GEUness. If it does, all we have to do is
> providing a tagging interface (like "OzoneObjectIdentifier")
> that says that the actual identifier object's hashCode()
> will produce GEU values.
> 

I don't think a int will cut it for GEU. To some extreme extents, a long
won't cut it. Both value are finite and using them will eventually
encounter repeation at some point. 

Plus, a long value doesn't carry much information for a cache database
to work with. 

Suppose that I am implementing a Phone book client for Palm that retrive
its data from an ozone database and put the result of query into the
Palm's phonebook application. I want to query the database, retrive a
bag of object, stuck the object's value into the native phone book
database for Palm's default phone book app along with the identify in
some hidden field in the database and release the object hold the
values.

Later on, I connect back the server, marshall the database entry from
the phone book database into object and connect them correct to the
actual object on the ozone instance. 

There are a lot of book keeping needed in this senario. My client side
cache database need to keep track of what database (could be multiple of
them) a particular object is retrived from, what version was on the
client, and how to connect this proxy back its actual object.

The best place to keep this info is in a "serializbale" identity value.
It's best for this value to carry this information.

Probably I am going too fast in extending Ozone to suppor two thing at
the same time but a GEU identity can solve the two problem at the same
time.

> My second proposal will be to state that the 
> OzoneObjectIdentifier interface will provide a getKey()
> method that returns something GEU. This would still
> leave the mechanism for identity up to the implementor
> (allowing for different implementations), and the
> object would be serializable too.
> 
> What type should getKey() return? It should be something
> primitive. If one can ensure GEU using long (which I doubt),
> let it return long. I know that byte[] will always work,
> and be generic enough. Any OzoneObjectIdentifier will in
> effect be a wrapper around the thing that getKey() returns.
> 
> I dislike David's String proposal. This will tie the concept
> of GEU Ozone objects to a particular GEU-mechanism, when we
> only need the GEUness. I believe that both serialized and
> externalized OzoneObjectIdentifier objects should be
> compatible between implementations.
> 
> But I believe that David's thoughts are good, but that it
> should be implemented as a bean that implements 
> OzoneObjectIdentifier, and whose toString() method 
> generates the String David proposes.
> 

I totally agree with this approach. Let me put this in a more
implementation context and see if we can agree on.

We need to add one identity interface with the following properties.
Let's call it OzoneObjectIdentity for the sake of discussion.

interface OzoneObjectIdentity {
    /**
     * must return hash code. The return value is 
     * for hashing purpose only. It doesn't carry 
     * any meaning.
     */
    public int hashCode();

    /**
     * this methods carry additonal semantics for
     * the object returning the identity in which
     * 
     * ozOne.identity().equals(ozTwo.identity())
     * IF AND ONLY IF
     * ozOne is identical to ozTwo
     */
    public boolean equals();

    /**
     * toString will return a String value with the
     * following properties.
     *
     * ozOne.identity().toString().equals(ozTwo.identity().toString())
     * IF AND ONLY IF
     * ozOne is identical to ozTwo
     */
    public String toString();
}

OzoneRemote will be extended to have one additional method

public OzoneObjectIdentity identity();

OzoneInterface will be extended to have an additional method

public Object getObjectByIdentity(OzoneObjectIdentity identity);

-----

Here are some thoughts on some possible implementation.

For the current Ozone implementation, it could probably get away by
wrapping the OzoneObjectIdentity with the long value used by the
container for the object. The serialization form of that identity is a
string of digits. 

For the cached implementation, it may returned a OzoneObjectIdentity
with additional inforamtion on host, port and class info as propsed by
my previous mail.

---

The format of the information on the seralized or stringified object
identity are for the database implementor only. No info on this should
be visible to the API's users. 

---

So, how about this? Can we accept this as a extension to Ozone? 

David Li
DigitalSesame