|
Actually, these kinds of semi-structured messages rather than rigurous
method
signatures, is one of the ways you can use SOAP, if I read it right.
In stead of WRITING code
to handle it on the server, we'd want to use existing SOAP code if we went
that way, I think.
James
-----Original Message-----
From: Kimbro Staken
[mailto:[EMAIL PROTECTED]
Sent: Sat 3/16/2002 10:40 AM
To: [EMAIL PROTECTED]
Cc:
Subject:
[proposal] API a different approach
Tonight I was thinking about the API a bit and it's been kind
of bothering
me that maybe it isn't the right way to go. My concern is
primarily that
the API will be brittle and not extensible. This was a major
problem with
the CORBA API and I hated it. Now that we have the opportunity
to fix it,
I think we should consider a different approach.
I'd like
to propose an API with one method in it.
Hashtable run(Hashtable
message);
It's still an RPC like API but based on a more flexible
message mechanism
rather then static parameters.
Instead of defining
methods with static sets of parameters we would define
messages that have
any number of parameters and that can change over time.
For instance
instead of calling the insertDocument method via XML-RPC
like
this.
Vector params = new
Vector();
params.addElement("/db/root");
params.addElement("test");
params.addElement("<doc>value</doc>");
String
result = (String) client.execute("insertDocument", params);
It would be
called like this.
Hashtable message = new
Hashtable();
message.put("method",
"insertDocument");
message.put("collection",
"/db/root");
message.put("key", "test.xml");
message.put("document",
"<doc>value</doc>");
Vector params = new
Vector();
params.addElement(message);
Hashtable result = (Hashtable)
client.execute("run", params);
String key = result.get("result");
In
Java the code is longer but will be simpler in a scripting language
which
is where I expect most direct use of the RPC API to exist. Java
developers
should still use the XML:DB API.
For instance in Perl to setup the
message would just be.
%message =
(
"method" =>
"insertDocument",
"collection"
=> "/db/root",
"key" =>
"test.xml",
"document" =>
"<doc>value</doc>"
);
$result =
$client->execute("run", ($message));
My Perl is rusty so this
might not be exactly right, but close enough.
This has several major
benefits
- Named parameters make the code more self documenting.
- The
order of parameters does not need to be known.
- The API is completely
dynamic and extensible. You can both add messages
and add parameters to
messages easily.
- There is no need for separate endpoints for internal and
external apis.
You simply set different parameters to pass compressed docs
vs.
uncompressed docs.
- The API could be user extensible by simply
defining a package or
filesystem location and then dynamically loading
classes from there that
match the name of the method.
The server
side implementation of this will be a little more complex
because you have
to build the dispatcher, but it is straight forward code.
This also
gives us a clean way to invoke XMLObjects remotely.
I realize that for
Java developers this can be considered "kludgy" or
"ugly" or "sloppy", but
the calls can be wrapped in what ever client API
you want. That client API
will still be brittle, but I'm not worried about
that. XML is supposed to
be about flexibility and lately I've really been
bothered by how inflexible
Xindice has become. I also realize that we don'
t need XML-RPC or SOAP to
implement something like this, but I still think
the client libraries are
valuable.
What are the reasons not to do this?
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)
|
