CRISPY, a New Remoting Framework

| by Boris Lublinsky Follow 1 Followers on Jun 03, 2009. Estimated reading time: 2 minutes |


In his new article entitled CRISPY Web services Sachin Mahajan discusses a new framework called CRISPY (Communication per Remote Invocation for different kinds of Services via ProxYs) - a unified API for remote invocation over a wide number of transports including: RMI, EJB, JAX-RPC, REST, XML-RPC, direct Java invocation, etc. All calls can execute synchronously or asynchronously. According to CRISPY project web site, CRISPY:

... works by using properties to configure a service manager, which is then used to invoke the remote API. 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. The special on this idea is, that these calls are simple Java object calls (remote or local calls are transparent).

The main advantages of CRISPY are

  • .. easy to use.
  • ...minimal to configure.
  • You can call a remote method from Java object, like a local call.
  • You don't need to know, how the (remote) technology work.
  • You can easy change the technology (for example from XML-RPC to RMI).
  • The services don't know a remote-interface or a RemoteException (how RMI).
  • The parameter can be a complex object (in parts without programming a Serializabler (Marshalling) or Deserializabler (Unmarshalling)).

CRISPY also provides a fine invocation control through interceptors and/or modifiers. Interceptors can be invoked both before and after method invocation and can be used, for example, for logging, call timing, etc. Modifiers can be also invoked before or after method invocation. They can be used for transformation/extension/enrichment of invocation parameters, for example, adding security headers, transformation/extension/enrichment of execution results.

Main components of the CRISPY framework include:


  • ServiceManager - It is a factory to create the service.
  • Properties - To configure the Service Manager.
  • Service Interface - Plain java class.
  • Proxy/Executor - All calls from Service Interface are delegated to Proxy/Executor.

CRISPY can be also combined with other popular frameworks. A list of currently implemented integrations include SpringFramework, HiveMind (Jakarta), PicoContainer (codehaus), OSGi, AspectJ, etc.

A discussion at compares CRISPY to Apache WSIF, Spring remoting and other frameworks providing similar capabilities - a unified invocation model over multiplicity of transports.

CRISPY can be used in many cases requiring decoupling of the client code from invocation protocols and service locations.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

An Argument on Distributed Computing by Geoffrey Wiseman

Ah, another remoting framework that wants to argue with a note on distributed computing.

Re: An Argument on Distributed Computing by Peter Veentjer

I agree with you, don't treat remote objects as local ones. I have been helping a customer with performance problems, and one of the causes was a chattiness "we didn't know that object was a remote object".

But on the other side: it is nice that if you do a remote call, no implementation specific details get in your code. That is one of the things I like about the remoting architecture of Spring for example.

New my @!%* by Richard Featherstone

In my book 3 years old ain't new

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss