CP2JavaWS : GWT like Cappuccino to Java remote services bridge


News: CP2JavaWS : GWT like Cappuccino to Java remote services bridge

  1. 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:@"<a href="http://localhost:8080/CP2JavaWSServletTest/CP2JavaWSEndpoint1" ]"="" rel="nofollow">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.
  2. <> Ah, at last ! Now both people with any use for this delightfully obscure niche technology have some support.
  3. Thank you for your comment, I agree Cappuccino is a really nice technology, and finally not so much obscure nor niche technology (see this third article featuring Cappuccino) : http://ajaxian.com/archives/yet-more-ajax-experience-videos-frameworks See current release (0.3) notes (now supports full objects graphs for services method's arguments and return - see provided example in the distribution -, including nested List and Map collections, and heterogeneous collection elements) : http://sourceforge.net/forum/forum.php?forum_id=914256 The server servlet will be replaced by a servlet filter, and an authentication filter will be added (will provide full digest security). Objects graphs cycle management is also planned. best, Jerome