Summary
The Cripsy project aims to simplify Web service client development by exposing remote calls to a client as though those calls were local Java method invocations. The recently released 1.1 version promises better exception handling, as well as validation error wrapping for business methods.
Advertisement
The Crispy project released version 1.1 of its Web service invocation API. The new release features better handling of exceptions occurring in the process of remote calls, as well as validation error wrapping for business methods.
Crispy aims to abstract out the semantics, as well as the syntax, of remote Web service calls, alleviating the need to decide at development time whether to use SOAP, XML-RPC, RMI, or some other remote call framework:
Crispy is a simple Java codebase with an API that sits between your client code and the services your code must access. It provides a layer of abstraction to decouple client code from access to a service, as well as its location and underlying implementation... These calls are simple Java object calls (remote or local calls are transparent).
Crispy presently supports the following protocols
Web-Service (JAX-RPC)
XML-RPC (e. g., Apache XML-RPC)
Burlap and Hessian (Caucho)
RMI
EJB (with JNDI lookup)
JBoss Remoting
REST (REpresentational State Transfer)
Http invoker (HTTP call with serializable Java objects)
CORBA (experimental)
While Crispy's aim of making a developer's life easier seems useful, what do you think of the Crispy project's goal to make all remote calls appear as local method calls? Almost twelve years ago, the key architects of RMI and Jini, including Jim Waldo and Ann Wollrath, pointed out in A Note on Distributed Computing [PDF file] that local and remote call semantics are fundamentally different, and that making remote calls appear as local calls could only lead to unstable systems.
While all the remote method call frameworks Crispy supports share a similar goal, each framework has unique failure handing semantics. Doesn't Crispy's 1.1 release claims of providing protocol-level wrapping still leave the responsibility of handling protocol exceptions with the developer? What do you think of Crispy's goals of hiding remote call complexity from the client?
> Like that paper you linked to says, it's like Deja Vu all > over again.
One of the criticisms of RMI, for instance, is what I think its creators may consider RMI's strength, which is that it exposes RemoteException in the remote interfaces, forcing a client developer to deal with that remote failure. I've seen very few examples of people actually knowing how to handle a RemoteException, and I suspect many people just handle it as if it was a RuntimeException - perhaps log it, and then have it bubble up the exception chain.
And handling RemoteException in any other way may not even be a good idea, because writing recovery code can be very tricky. You would want to factor remote failure handling out to a bigger unit of work, i.e., a transaction. Transactions were really invented to deal with failure of a computation, and are much better understood than someone's custom recovery code would be.
When any operation inside a transaction fails, you roll back the transaction. In that case, you don't really care to handle a remote exception, because the failure of that remote call inside the transaction appears to you as a transaction abort. In other words, there is not much point in that scenario to have RemoteException as a checked exception - a runtime remote exception signifying failure would suffice. BTW, note that in EJB 3, they removed the RemoteException declaration requirement from EJB business methods.
Previous Topic
