http://xml.apache.org/xmlrpc/
We could have a factory that publishes a service or interface over HTTP and a binding on the client side that turns the same interface calls into RPC calls. The example code seems quite cumbersome, but I have a feeling that if the interface only uses standard class types, we could have hide the XMLRPC implementation behind java interfaces and use reflection at runtime on both sides to build the method lists. XMLRPC also forces two exception to be handled on the client side (XmlRpcException and IOException), but I think they could be rethrown as a custom derivative of RuntimeException (like Glue does). The difference with this is that we can place the XMLRPC jars in CVS (they are Apache jars).
Perhaps an important factor is need. Do we really need this if we are going to have native RMI solution along the same lines. At least for the Soapification service there is the realistic possibility of non-java clients.
Opinions?
Regards,
- Paul H
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
