Project Labrador

[Tom Bradford <br...@dbxmlgroup.com>]

Hi All,

Over the past week, I've been working on an XML Object Broker called
Labrador, which will likely be included as part of Xindice, but may be
managed as a separate project (as it is very useful on its own).  It is
something that I started a few months ago, but had left sitting around
collecting dust.

If it is introduced into Xindice, it will mean that there will be some
changes to the XMLObject architecture, most notably the elimination of
Reflectable and SimpleReflectable, because reflection will no longer be
a function of Xindice, and Labrador will open Xindice up to various wire
protocols and APIs beyond the XML:DB APIs.

It's important to understand the motivation behind this project.  It is
*NOT* meant to be a SOAP and/or XML-RPC toolkit, and will not provide
the extensive functionality that projects like Apache Axis and Apache
XML-RPC (Helma) provide.  Its only purpose to be a simple object service
broker that you don't have to jump through hoops to work with.

Here's the idea behind Labrador:

   - An endpoint provides Request and Response implementations that are 
     very basic, but provide enough information for a Handler to do its
     job.  The endpoint cares nothing about the payload.  It's only 
     purpose is to expose the payload in a MIME compliant fashion.
     
   - The Labrador Broker gets the processing request.  It first asks any
     available Handlers if they are capable of dealing with the request,
     and if so, it asks them to extract the object ID.

     With the object ID, the Broker then asks any available Resolvers
     if they can resolve the object ID.  If so, it asks the Handler that
     was used earlier to process the request against the object
     instance.

Labrador already has two endpoints, a standard Servlet endpoint, and an
endpoint designed for the Xindice internal HTTP Server.  I am also
working on an internal VM endpoint, so that a servlet/network interface
isn't necessary to expose the Broker.  

Currently, there is one Resolver, and that is the Standard Object
reflection Resolver.  It provides better reflection, and a better set of
possible input/output types than the XMLObject system.  It's quite easy
to write a Resolver that exposes Instances that are parameterized
services, but for Xindice, we're not interested in this capability.

There are two Handlers, one is an XML-RPC Handler.  I wrote it from
scratch.  It's about 90% complete at this point.  The other is a SOAP
Handler, which barely has any functioning code.  I will also write a
Handler for standard GETs, so that a QueryString can be used to invoke
objects and return their results as non-wrapped content.

Overall, the way that XMLObjects are created won't change at all,
they'll just be more capable.  But how you access those XMLObjects will
expand greatly.  Labrador will probably also be used to expose a
Collection proxy for issuing queries and managing the databases.  In
this case, the XML:DB client can be a SOAP or XML-RPC client.

Let me know if you have any questions.  I'd very much like to hear some
feedback before moving forward full-steam.

-- 
Tom Bradford - http://www.tbradford.org
Developer - Apache Xindice (formerly dbXML)
Maintainer - jEdit-Syntax Java Editing Bean