CRISPY is a new project that aims to provide a single point of entry for remote invocation for a wide number of transports: RMI, EJB, JAX-RPC, XML-RPC, Caucho's Burlap and Hessian protocols, JBoss Remoting, and REST.

CRISPY works by using properties to configure a service manager, which is then used to invoke the remote API. An example from the CRISPY home page:

Properties prop = new Properties();
prop.put(Property.REMOTE_URL_AND_PORT, "http://localhost:9080/axis/services");
prop.put(Property.EXECUTOR_CLASS, JaxRpcExecutor.class.getName());

ServiceManager manager = new ServiceManager(prop);
Calculator calc = (Calculator) manager.createService(Calculator.class);
System.out.println("1 + 2 = " + calc.add(1, 2));

How does this compare with projects such as Apache's WSIF? While such APIs certainly make remote invocation easier, part of their justification is that service protocols might change; do you ever change the transport mechanism once a service has been implemented?

Apache Commons Remoting has added support for CRISPY. Now you can used Cremoting to invoke CRISPY to invoke JBoss Remoting to invoke RMI, which allows you to execute methods remotely.

Peace,

Cameron Purdy
Tangosol Coherence: This space available.

But can you invoke all of that through an ESB?

Good idea Cameron, now we can use cremoting the next time we want to replace CRISPY with something else11

Hi, I am the developer of Crispy. Can you say, which meant with:

Apache Commons Remoting has added support for CRISPY.

Hi, I am the developer of Crispy. Can you say, which meant with:

Apache Commons Remoting has added support for CRISPY.

Hi Mario, it was not intended to be serious, but as humor; I should have been more clear on that. I was specifically pointing to how certain Apache commons projects abstract out things that are already abstract, and similarly how the Jboss remoting can already support a variety of implementations for remoting, which is coincidentally what Crispy can do. So if you imagine Crispy sitting on top of Jboss remoting (abstract on top of abstract), nothing could be funnier than for Apache to provide yet another abstraction to sit on top of it all.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Hi Cameron, I have understand your hint. For the JBoss Remoting API is your comment potential right. But remote technologies as WebService or XML-RPC are not easy to learn and not intuitive for OO programming. The second point is a change of the remote technology is difficult without an abstraction layer. Performance, security, interoperability and so on are influenced by the remote technology. But the right decision is important for a successful project.

Interesting, but I still prefer Spring's approach, which gives me everything I need. Granted, Spring's approach is centered around a remote service (as opposed to purely remote objects), but this simplifies things and works for me. I use Spring to instantiate my service bean and "export" the interface via a remoting protocol, and then on the client side I setup an "invoker" proxy and write my code directly to the service interface. I don't write a single line of code to deal with remoting, as it is all handled in the Spring configuration. Spring injects its proxy into any beans of mine that require the service interface.

Interesting, but I still prefer Spring's approach, which gives me everything I need.

This is correct. I find the SpringFramework also very good. Crispy complements this framework by more remote technology (e.g. XML-RPC). The current version of Crispy has a integration to Spring. Other lightweight container as HiveMind (Jakarta) or PicoContainer (codehaus) can use Crispy for remote invocation. And of course, you can use Crispy pure in every application where you need remote services.

I don't write a single line of code to deal with remoting, as it is all handled in the Spring configuration. Spring injects its proxy into any beans of mine that require the service interface.

Crispy works just as. You can to swap out the properties in a file:

Properties props = new Properties();
props.load(FileInputStream("example.properties"));

In the next version Crispy can load the properties from a file as Spring:

ApplicationContext ctx = new ClassPathXmlApplicationContext("/example.xml");

Interesting, but I still prefer Spring's approach, which gives me everything I need. Granted, Spring's approach is centered around a remote service (as opposed to purely remote objects), but this simplifies things and works for me. I use Spring to instantiate my service bean and "export" the interface via a remoting protocol, and then on the client side I setup an "invoker" proxy and write my code directly to the service interface. I don't write a single line of code to deal with remoting, as it is all handled in the Spring configuration. Spring injects its proxy into any beans of mine that require the service interface.

Here. Here. I agree. You can switch out the exporter and invoker and use a different protocol w/o the code knowing at all, which protocol it is using or even if it is using a remote protocol. Spring's support is the best I have seen.

Some commments may suggest that CRISPY is to be deployed on the SERVER side, where as (at least as far as I can tell) CRISPY is to be used on the client side.
It allows the client application to connect to different servers and to invoke different services using different protocols in a prety much the same manner.
I think that CRISPY can potentially be used to decouple the service location functions of client's applications from the service consumption functions. (The Service Locator pattern). One can use a config file to hook things together (like IoC) or possibly some logic to programmatically determine which server/service/protocol to use depending on the context (availability, price, priority, ...etc).
PS: I never used CRISPY, but this is how I imagine it to be used.

Does CRISPY support AJAX2 ?

Does CRISPY support AJAX2 ?

AJAX2 is not supported. It is possible and a interesting idea to invoke JavaScript function in Java (e.g. Rhino), but Crispy is prior for the language Java.

Very good idea. Some of the benefits are probably similar to what you can get using Apache Camel. We use a similar home-made approach where I work, for two reasons. a) some of the systems we communicate with are old and cannot run java, provide http-hosted services or similar. Instead they have platform- and architeture-specific ways of receiving data for which we have to implement client code ourselves (this is actually not THAT difficult). b) there is a shortage of test versions of these older systems, sometimes there is none at all. That means you have to use a different integration protocol while developing and testing from the one you use in production. Pluggable protocols are usefull for this. While testing on your workstation, you typically redirect output to a byte array or local file and validate the contents. It is really usefull to be able to do that with only config parameter changes, so you actually test the system you are going to run in production (given that the protocol implementations are already verified).