CRISPY, a New Remoting Framework

Posted by Boris Lublinsky on Jun 03, 2009

Sections

Enterprise Architecture

Topics

Web Services ,

SOA

Tags

Services ,

Web services ,

Distributed Programming

 

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 TheServerSide.com 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.

1. Back to top

   An Argument on Distributed Computing

   by Geoffrey Wiseman

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

   Reply

2. Back to top

   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.

   Reply

3. Back to top

   New my @!%*

   by Richard Featherstone

   In my book 3 years old ain't new

   Reply

• Older >