| french | english |
 |
|
| Sign in | |
| 21-02-09 / 17:10 : Web 3.0/Client MVC/non J2EE server (cjed) |
| Following GWT, Cappuccino opened the path for web 3.0. Common JSP taglibs libraries (RIA web 2.0) are deprecated (JSF RichFaces, ADF, etc.), and the newly announced JSF 2.0 version is only a slight evolving. RDA applications (RWA if the container is a web browser) then access directly to the server's services layer (application or business layer, depending on the required workflow and transaction management), and the presentation layer (MVC) is moved on the client side (Cappuccino uses Next/Cocoa AppKit). Calls to remote services are made using a bridge framework, a proxy, that is either specifically generated (when using GWT), or a generic dynamic one when using CP2JavaWS (uses the Objective-J runtime forwardInvocation method as there isn't yet a Cappuccino implementation of NSProxy class. However these dynamic features are far more powerfull and easy to use than Java dynamic proxies). On the server side there is no more need for a servlet, a sole servlet filter can be used (also allows to set url mapping), that is the solution that was retained for CP2JavaWS. The interesting point with filters is that we don't set anymore a dependency (such criticism was made on Struts, that requires to subclass a servlet, ActionServlet). Someway filters can be seen as interfaces. We can then even add classic servlets declarations (Struts, Spring MVC) to the application, and attach the CP2JavaWS filter (for example) to these. That filter will determine what requests it should manage, and will forward other requests to the filter chain (up to the classical servlet). We will then be able to invoke application layer services from multiple client technologies : classical (html produced from JSP tags rendering) and RDA (dom/javascript based like Cappuccino). Such configuration will also help when migrating applications and/or during maintenance operations. Then why using a J2EE server anymore ? Its servlet/jsp container isn't so much relevant (we don't use jsp), and the interesting remaining stuff is the various connectors (JDBC, JCA, asynchronous messages channels). Even sessions management could be done in another technology (we could imagine an Objective-C based server side, that idea was suggested by Cappuccino members). What about the messages format ? JSON seems the growing one, as it is easy to learn, despite its lack of support for namespaces and cycles (have to be managed manually - by a non standard way -, the case in CP2javaWS). In fact that format wasn't intended to exchange complex objects graphs, nor contracts (WSDL and SOAP were conceived with these goals in mind). JSON is only a simple text representation of a javascript objects graph (we can even use eval() on such string to get the javascript objects). In CP2JavaWS documentation I introduced some discussions about JSON limitations and possible extensions. However the greater benefits (in terms of ease of development) when combining Cappuccino with a bridge solution like CP2JavaWS overcome its limitations. Moreover CP2JavaWS still manages heterogeneous collections elements, and nested ones (and soon cycles). When the methodSignatureForSelector method will be implemented in Cappuccino, we will be able to check for passed method's arguments with a contract (Objective-J protocol/interface that will be specified when getting the proxy). |
| Comments |
| Write a comment |