Draft RPC-able interface for client/server communication in Xindice

[James Bates <ja...@amplexor.com>]

I have used what's currently in org.apache.xindice.client.corba as an insipration for the API that needs to be exposed over the
network, and built a first draft of an RPC-able version of it.

I've merged CollectionManagerServant and CollectionServant functionality, but they could be separated again if wanted.

I haven't thought deeply about the separation between simple and internal API's yet, as discussed earlier. I wanted to first
get something that is as close as possible to the current corba API's...

The most important change is the CollectionHandle class, which is meant to be serializable, and thus can be used to let clients designate particular collections, thus emulating "remote object" behaviour.

The server-side implementation of CollectionService would have to keep a hashtable probably to map these handles to real collections.

This is just a start and possible a ground for some further discussion. I'm going to start making a server-side implementation of the API and a new org.apache.xindice.server.Service that starts up an XML-RPC server to expose the API.

The code is in package org.apache.xindice.client.rpc, in analogy with the current CORBA servants. It is quite unrelated to the rest of the codebase (for the moment), so it shouldn't interfere with the existing build process.

James

Re: Draft RPC-able interface for client/server communication in Xindice

[Kimbro Staken <ks...@xmldatabases.org>]

On Wednesday, March 13, 2002, at 11:02 AM, James Bates wrote:

> I have used what's currently in org.apache.xindice.client.corba as an 
> insipration for the API that needs to be exposed over the
>
> network, and built a first draft of an RPC-able version of it.
>
> I've merged CollectionManagerServant and CollectionServant functionality,
>  but they could be separated again if wanted.
>
> I haven't thought deeply about the separation between simple and internal 
> API's yet, as discussed earlier. I wanted to first
>
> get something that is as close as possible to the current corba API's...

In my opinion this should definitely not be a design goal. There is no 
legacy to worry about. I'm going to rewrite the XML:DB API and I don't 
care one bit how much this new API looks like the old API. Beyond that I 
don't think anyone uses the CORBA API for anything. Obviously we need to 
keep the basic functionality, but beyond that it doesn't need to look 
anything like the CORBA API structurally.

>
> The most important change is the CollectionHandle class, which is meant 
> to be serializable, and thus can be used to let clients designate 
> particular collections, thus emulating "remote object" behaviour.
>

This should not be a design goal either. Keep it simple, simple, simple! :
-)

> The server-side implementation of CollectionService would have to keep a 
> hashtable probably to map these handles to real collections.
>

We really should avoid any kind of server side state. That is one of the 
very major problems with CORBA overall and one of the biggest appeals of 
going to a stateless protocol. I actually started reworking the CORBA API 
at one point to make it stateless, but that is such a major PITA in CORBA 
I shelved it. In HTTP based protocols you get that by default, let's not 
ruin it. :-)

> This is just a start and possible a ground for some further discussion. I'
> m going to start making a server-side implementation of the API and a new 
> org.apache.xindice.server.Service that starts up an XML-RPC server to 
> expose the API.
>
> The code is in package org.apache.xindice.client.rpc, in analogy with the 
> current CORBA servants. It is quite unrelated to the rest of the codebase 
> (for the moment), so it shouldn't interfere with the existing build 
> process.
>

Probably shouldn't commit things like this. Just post them somewhere where 
we can look at them to discuss. Also I haven't tagged the tree yet so the 
trunk is still closed to new additions. I'll post when it's open and what 
the tags are for the 1.0 tree. I'll take care of this today, in the 
process I'm going to need to remove this code.



> James
>
>
Kimbro Staken - http://www.kstaken.org - http://www.xmldatabases.org
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org
Senior Technologist (Your company name here)