Web 3.0/Client MVC/non J2EE server

Posted: February 21, 2009 in IT/Dev
Tags: , , , , , , ,

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 themethodSignatureForSelector 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).

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s