A first (early beta) of CP2JavaWS has been released. It is a bridge between Cappuccino based (
http://www.cappuccino.org) RDA clients and Java remote services. It consists of a proxy (client side) and a servlet (server side), and manages parameters namespace, encoding, ordering, and cross-domain. Its use is as easy as with GWT (and does not require any generation
step thanks to the Objective-J runtime - interpreter step at runtime).
Project's home page :
http://sourceforge.net/projects/cp2javaws/
Documentation :
http://sourceforge.net/docman/display_doc.php?docid=137096&group_id=249667
Download (includes a working example) :
http://sourceforge.net/project/showfiles.php?group_id=249667
Usage
On the client-side :
var endPoint = [CP2JavaWSEndPoint
createForURL:@"http://localhost:8080/CP2JavaWSServletTest/CP2JavaWSEndpoint1"];
var remoteService = [endPoint
proxyForJavaServiceInterface:@"com.cp2javaws.demo.services.
IDemoService1" delegate:self sameDomain:true];
[remoteService method1:@"arg1StringValue"
andWithArg2:2 andWithArg3:new Date() delegateRespHandler:@selector(manageServiceMethod1Response:) delegateFailHandler:@selector(manageServiceMethod1Fail:)];
On the server-side :
Just subclass the provided CP2JavaWSJSONServlet servlet and implement the (abstract) method :
protected Object getService(Class serviceInterface)
Why not a Java to Objective-J generation tool for Cappuccino, like with GWT ?
I thought about such GWT like Java to Objective-J generation tool when I wrote notes/ideas about CP2JavaWS bridge (only for the remote service bridge, the GUI would have still been defined with CP classes and InterfaceBuilder, not in Swing). However I rejected that idea because it is sort of simplification/cheat : on one hand it allows far more easier development of the solution, it can lead to more optimized code (faster because of static code produced, no dynamic feature), it allows writing code in Java (and business objects used as services's parameters and return are declared only one time). But on the other hand it breaks the development cycle and isn't elegant.
After all, what would we say if object-relationnal mapping frameworks required to use a tool to generate some DAO from the mapping files ? Instead they use reflection APIs to dynamically generate objects from mapping description files. I know some implementations (based on the JDO specification) are based on a bytecode enhancement step (to compare with GWT generation step), that allows datastore type abstraction (database, but also filesystem, CICS, etc.) and better performance. But the result is that most people stayed with standard reflection based solutions (notably Hibernate, a defacto standard - not even based initially on any specification...)
Google had no other way to make GWT work than to use a generation step, because their end client code is pure javascript (so no way to implement such remote service proxy). Thanks to Cappuccino Objective-C runtime (converts Objective-J code into javascript at runtime using a JIT pre-interpreter), the proxy could be implemented without requiring a generation step.
The dynamic approach for Cappuccino to remote services seems better for me.
