[Ann] Labrador 0.2 (Was Armi - Alternate to RMI (Commons-scratchpad))

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

On Sunday, January 6, 2002, at 04:45 PM, Paul Hammant wrote:
> I guess Tom, out of politeness I should learn more about Labrador 
> (rather that just hope I can write a Labrador transport for ARMI..

Yes, you absolutely should.

I've just released Labrador 0.2.  To quote the README:

The 0.2 version of the Labrador XML Object Broker introduces better type 
conversions, better array support, lots of bug fixes, and an  internal 
HTTP Server.  Still no SOAP support, but it should be ready by version 
0.5.  Also, still no DateTime support, which you can expect in 0.3.

You can find Labrador as well as some examples of using it at:
    http://xml-labrador.sourceforge.net

Regarding XML-Commons...  I've been seeing a lot of overlap lately 
between some of the things going on in Jakarta and in XML.  There should 
probably be a concerted effort for everybody to get on the same page and 
consolidate things.  The packages should just be called "Commons" and be 
shared between all of the projects.

As far as Labrador is concerned, I'll keep plugging along with it until 
people take notice and see the value in it.  There's probably a bit of 
overlap between Labrador and ARMI, only problem being that Labrador 
isn't being managed under the Apache umbrella.

--
Tom Bradford - http://www.tbradford.org
Developer - Apache Xindice (Native XML Database)
Creator - Project Labrador (XML Object Broker)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Ann] Labrador 0.2 (Was Armi - Alternate to RMI (Commons-scratchpad))

[Paul Hammant <Pa...@yahoo.com>]

Tom,

>> I guess Tom, out of politeness I should learn more about Labrador 
>> (rather that just hope I can write a Labrador transport for ARMI..
>
>
> Yes, you absolutely should.
>
> <snip>

I''ve just been looking at it (from CVS).

*Similarities*.

You are publishing on a similar basis to Glue and ARMI.  Glue and ARMI 
have 'publish(Object bean)' you have 'register(Object bean)'.  Glue and 
ARMI overload that with 'publish(Object bean, Class[] 
onlyTheseInterfaces)'  You may want to think about the interface 
filtering that the other two do.

*Differences*

The client code for Labrador depends on XMLRPC (currently).  This is 
snipped from your docs:

         String url = "http://localhost:1980/xmlrpc/test";
         XmlRpcClient client = new XmlRpcClient(url);
         Vector v = new Vector();
         v.add(args[0]);
         System.out.println(client.execute("hello", v));

This so sucks it is unbelievable.  It is not your fault dude of course 
dude as that is a third party lib (yes I know it is at Apache). ARMI is 
directly inspired by Glue which I will credit with the novelties :

         String url = "http://localhost:1980/xmlrpc/test";
         MyAutoClassInterface myac = (MyAutoClassInterface) ARMIorGlue.lookup(url);
         System.out.println(myac.hello(args[0]));

Has XML-RPC code been tested for speed?  E.G. 100,000 iterations of the hello method as listed

Glue is first class in that it represents an interface remotely.  Fully. 
 Granted in your example, there is no MyAutoClassInterface (there is 
only MyAutoClass).  As such there could be no prepackaged jar of 
interfaces for the MyAutoClass service pre-existing on the client 
machine.  With ARMI I plan to pump the lot on demand.

ARMI unlike Glue and Labrador recognoses that some method calls in the 
primary (or any) service might create connections to other services.  As 
such it is a blend of pass by value and pass by reference.  It's niche 
at the moment is Facade publishing for 100% Java solutions

*Marshalling*

You opted for a custom marshalling scheme that can be tacked onto a HTTP 
request/reply.  You're using a real temporary file, but I guess that is 
a temporary solution?  You've done a huge amount of work on difficult 
things like XML Documents etc.  This is really cool and I may at some 
point crib the code (whilst crediting fully its source).

*Integrations*

You have a servlet adaptor that will allow publishing via third party 
tools like Tomcat, Jo!, or Resin.  This is very cool.  Full on 
webservice.  You also have a tiny HTTP server built in that should allow 
the minimal required to punch through firewalls.  Both I guess will form 
the basis for full SOAP compatability.  Again I think I should be 
inspired here.

> Regarding XML-Commons...  I've been seeing a lot of overlap lately 
> between some of the things going on in Jakarta and in XML.  There 
> should probably be a concerted effort for everybody to get on the same 
> page and consolidate things.  The packages should just be called 
> "Commons" and be shared between all of the projects. 

+1

> As far as Labrador is concerned, I'll keep plugging along with it 
> until people take notice and see the value in it.  There's probably a 
> bit of overlap between Labrador and ARMI, only problem being that 
> Labrador isn't being managed under the Apache umbrella. 

There is overlaps as you say between ARMI and Labrador.

If I could summarise the differences:

ARMI - For 100% Java solutions.  Full & near seamless interface or 
facade publishing
Labrador - Clients can be multi language.  Integrations with Third Party 
Webservers.

A future?

I sure there is a possibility for merge or something....

Regards,

- Paul H




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>