Posts Tagged ‘JSON’

A new 0.5 version of CP2JavaWS bridge is available at Sourceforge. It includes the following new features :

– full digest authentication (rfc2617) support (tested on Safari and Firefox), with automatic retrigger of original connection.
Besides digest parameters settings (nonce life, realm, etc.), the authentication filter allows to set list of services that require (or not) authentication (using includes and excludes).
Authentication occurs only once (for the first service that requires it).

Note : only works with sameDomain (when using JSONP digest authentication could happen, but there is no mean to check response status nor retrieve response headers – see security considerations)

– session/state management : JSESSIONID cookie is automatically retrieved once authentication challenge ends (Authentication-info response header with Ok code) and added to following requests (had to be coded for Safari – Firefox handles it natively).

Note : only works with sameDomain (when using JSONP, for security reason the server isn’t allowed to set a cookie to the client, as it originates from another domain).

– a new Habilitation fillter has been added : it allows (through a custom habilitation service) to set access rules for services, depending on the user, remote service and method called (these rules apply after authentication check).

– sameDomain setting moved from remoteService to endPoint (the same for all services of a web app).

– the packaged cp2javaws-filter.jar now includes the right files (sources files were ok however).

A new 0.32 version of CP2JavaWS is available at Sourceforge :

Encoding and decoding of client objects now also supports CPCoding, through new CP2JSEncoder/CP2JSDecoder.
These coder provide transparent backward compatibility with previous versions of CP2JavaWS that were based on the CPJSONAware protocol :

– if no CPCoding implementation is found on custom objects, it uses instead the old toJSObject/objectWithJSObject methods from CPJSONAware categories.

– Furthermore it does the switch at each node level ! That is for custom objects we can etiher implement CPCoding protocol’s methods (if the serialization requires particular work, for example to exclude some attributes or choose arbitrary JSON keys – different from ivar names), or benefit from the automatic encoding of objects provided by the CPJSONAware categories (then custom objects have to import CPObject_CPJSONAware.j, and JSON keys will match exactly ivar names).

The site nice-panorama.com provides tutorials on Cappuccino, and notably a new one about serialization solutions for client/server communications : CPKeyedArchiver/CPKeyedUnarchiver (extends CPCoder and requires to implement the CPCoding protocol in custom classes), JSON and CPPropertyListSerialization (plist format, that is also available on OSX/Objective-C FoundationKit, in XML and now also in binary for better space management). The format produced by CPKeyedArchiver doesn’t have an equivalent in Objective-C (it is a proprietary one, called plist280), and classic/basic property list (plist) don’t allow to manage custom objects (moreover Cappuccino’s CPPropertyListSerialization doesn’t manage yet arrays nor Date type).

Then for now communication with an Objective-C backend isn’t as easy as it could be. For a J2EE server side the JSON format is preferable (no native CPCoding equivalent in Java, nor plist format support). However JSON has to be extended in order for managing custom objects namespace (that is what CP2JavaWS does, it can manage custom objects and nested collections).

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

The reference site about rich client / Web 2.0 (soon 3.0), Ajaxian, today published an article about CP2JavaWS Cappuccino/Java webservices bridge.

A new version of CP2JavaWS (0.31) is available at sourceforge. It includes the following changes :

– CP2JavaWSJSONServlet has been replaced by a filter. Then no need anymore for a servlet. If a servlet is still present, your application could then manage both JSON requests (originated from Cappuccino client applications using CP2JavaWSRemoteService proxy), through the CPJSONFilter, and classic web requests (managed by your servlet, Struts or Spring MVC servlet for example).

– the CPJSONFilter can work with any service factory (custom framework and/or injection container). A listener is provided for integration with spring container (see the provided demo). You have then to add cp2javaws-springsupport.jar in web-inf/lib besides cp2javaws-filter.jar (and spring.jar obviously). If not using Spring, spring.jar (and cp2javaws-springsupport.jar) can be removed, avoiding any dependency.

– for custom service factory/framework, a listener example is provided (see server source code, DummyContextWrapperListener.java and DummyContextWrapper.java). Just modify these classes to get you service factory injected, and then export these two classes into a support.jar (the same as with cp2javaws-springsupport.jar).

– fixed date timezone management.