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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
