Configuring an RIA with OpenSwing and Spring
When creating an RIA with an OpenSwing-based GUI, it's possible to use a classic DispatcherServlet servlet provided with Spring as the unique access point for all HTTP requests; these requests come from the "ClientUtils.getData()" utility method provided by OpenSwing that can be used in a client-side application to generate requests to the server-side application: all data retrieval classes located in the client-side application will use this utility method to remotely contact the server-side via the HTTP protocol.

In any J2EE Web application there must be a defined "WEB-INF/web.xml" file; with Spring this is the first file to configure too. When combining OpenSwing with Spring, a typical web.xml content is like the one described in Listing 1.

As shown in there, a DispatcherServlet servlet class is defined; moreover, other XML files must be defined: they are the other classical files required by Spring: applicationContext.xml and dataAccessContext-....xml

When defining the DispatcherServlet servlet, Spring requires another XML file be created: "xxx-servlet.xml" in which "xxx" is the name of the servlet defined in the web.xml (in our example: "controller"); Listing 2 shows the "controller-servlet.xml" file.

OpenSwing provides two main classes that must be defined in this XML file:
• OpenSwingHandlerMapping - This job of this class is to get all the requests coming from the DispatcherServlet: these HTTP requests always contain a serializable object of the org.openswing.swing.message.send.java.Command type that contains a server-side bean name to invoke; this bean is a controller type object recognized by the Spring framework; all controller type beans in a "controller-servlet.xml" file must be defined as having as an "id" the "methodName" values stored in the command object and defined in the client-side layer.

At this point the Spring framework is the only actor: it's possible to define a facade, dao objects, transactions, and any other Spring component. Consequently, it's possible to include any technology that Spring allows to connect: ORM layers (such as Hibernate or iBatis or TopLink or JPA), EJB, etc.

The only constraint to respect is that the value to return to the client-side must be an object that extends org.openswing.swing.message.response.java.Response. If the client request is generated by a grid control or a lookup then the return value must be a VOListResponse; if the client request is generated by a form then the return value must be a VOResponse type as with any other application based on OpenSwing and not on Spring (independent of the number of tiers, two or three tiers).
• OpenSwingViewResolver - This class returns a Response type object to the client side; this object has been generated in the server-side application and is given back through HTTP by serializing the object.

So OpenSwingViewResolver doesn't render a Web page. It serializes objects for the client-side application.

It's possible to include any kind of Interceptor object in a Spring configuration as in any application based on Spring. The OpenSwingHandlerMapping class provided by OpenSwing always extracts the command serialized object from the request and stores it as the request's attribute named OpenSwingHandlerMapping. COMMAND_ATTRIBUTE_NAME. In this way the command object is available to all interceptor objects added to the application.

Optionally OpenSwing provides an interceptor class named SessionCheckInterceptor that could be included in "controller-servlet.xml" file: this interceptor checks each HTTP request coming from the client side; SessionCheckInterceptor dispatches requests only if the command object contains a session identifier previously stored in the servlet context (when the client was authenticated); if a command object doesn't contain a session identifier or it contains a session identifier not stored in the servlet context then the request is rejected.

The choice of storing session identifiers in the servlet context instead of in the session context bound to the client derives from the nature of three-tier client/server applications based on the Swing front-end: these applications may be started without a browser (for example, by directly using Java Web Start), so that the traditional means of client session identification (cookies or URL rewriting) can't be applied outside the browser. Consequently, session info bindable to a client must be stored in the servlet context and fetched starting from a client session identifier that must be sent from client to server in each command object.

SessionCheckInterceptor class extracts the client session identifier from the request (through the Command.getSessionId method) and checks in the ServletContext if this identifier is stored. Session identifiers are stored in a HashSet whose attribute name is OpenSwingHandlerMapping. USERS_AUTHENTICATED; if the identifier is stored then the interceptor returns true, otherwise it returns false and gives an org.openswing.swing.message.response. java.ErrorResponse object back to the client.

Resources
• JMatter - http://jmatter.org/
• JGoodies - www.jgoodies.com/
• JDNC - Java Desktop Network Components: https://jdnc.dev.java.net/
• JSR 296 - Swing Application Framework: http://jcp.org/en/jsr/detail?id=296
• JavaDesktop: http://community.java.net/javadesktop/
• OpenSwing Framework: http://oswing.sourceforge.net
• Spring Application Framework: www.springframework.org
• Hibernate Framework: www.hibernate.org/
• iBatis: http://ibatis.apache.org

• Developing Rich Client Applications Using Swing - II