Devbits

There were a lot of sessions about Rich Internet Applications at the recent Web 2.0 Expo & JavaOne conferences. The poster children frameworks of "Web 2.0" have been the JavaScript libraries that have made web sites slicker. However there is a new breed of frameworks that promise the experience of desktop, the connectivity of Internet & the ease of web development. Some of the possible advantages that such applications offer over traditional browser based web applications are:

Offline Access: The often used argument for offline access doesn't stand any good in an increasingly connected world. However, the ability to buffer data in the background to cover up for network jitters makes a good case for usability.

Local Resources: Applications running from within the browser have restrictions on what they can access on the local machine. They also have limitations in terms of how much can they store temporarily in cookies. Outside the browser, all these restrictions are mostly gone. The applications can cache more data for better performance.

Better Push: A lot of web applications have alerts as an integral part of application workflow. With desktop applications, it's possible to have a lighter mechanism to alert the user than requiring her to keep the browser running at all the times.

User Controls: Multimedia applications have a better user experience if they are controllable by non-standard user inputs like volume and channel controls. This is usually not possible from within the browser.

Data Integration: An application running on the desktop has direct access to local data (like other resources). So they are more suited to mashup a user's online data with the local data. Even if local data is not involved, a desktop is a better place to mashup personal data from two different services.

There is no doubt that the experience could be functionally better for the end-users. But, using any application built on such frameworks would need some form of deployment on the customer desktop. Compare that with the web applications that need no deployment. It'll be interesting to see how the end-users take to this.

Scala sources compile to class files that can run on JVM. So there is no doubt that most of Java EE development should be possible in Scala. Here is a simple servlet written in Scala.

package net.aseem.tryingoutscala.web
import javax.servlet.http._

class Payroll extends HttpServlet {

  override def doGet(request: HttpServletRequest, response: HttpServletResponse) =

    response.getWriter().println("Hello World")

}

What is yet not available is a reasonable IDE for Scala based Java EE application development. There is a Scala plugin for Eclipse that works great for Scala applications. So I went ahead and used it along with another plugin to get an effective Java EE development environment for Scala. I used Oracle Enterprise Pack for Eclipse (formerly know as WLS Tools) along with Scala Plugin for Eclipse to develop and deploy aforementioned Scala servlet. I installed these plugins on Eclipse IDE for Java EE Developers (version Ganymede) and tested the servlet on WebLogic Server 10g Release 3 (10.3).

Scala project
I created a Scala project called TryingOutScala (File > New > Project > Scala Wizards > Scala Project) an added Servlet 2.5 spec jar to it's build path (Project > Properties > Java Build Path > Libraries > Add External JARs). I added the jar from WLS installation at BEA_HOME/modules/javax.servlet_1.0.0.0_2-5.jar. Then I created the above mentioned Scala servlet in this project (File > New > Other > Scala Wizards > Scala Class).

Web project
Next I created a dynamic web project called Payroll (File > New > Project > Web > Dynamic Web Project) and added TryingOutScala project to it's Java EE module dependencies (Project > Properties > Java EE Module Dependencies). To web.xml of this project (located in WebContent/WEB-INF) I added the servlet from the Scala project.

<servlet>
  	<servlet-name>Home</servlet-name>
  	<servlet-class>net.aseem.tryingoutscala.web.Payroll</servlet-class>
</servlet>
<servlet-mapping>
  	<servlet-name>Home</servlet-name>
  	<url-pattern>/</url-pattern>
</servlet-mapping>

Scala Library
Our Scala servlet was now ready to be deployed, except Scala compiled classes need at least one library in classpath at runtime: scala-library.jar. For my installation, this file was available at /usr/share/java/scala-library.jar. Though packaging this library inside the web application would have worked, it would have considerably increased the size of the application. So I deployed it as a shared application library using the following command:

java weblogic.Deployer -username *** -password *** -library -deploy -name scala-library /usr/share/java/scala-library.jar

This library could also have been deployed using the console.

I added the following two lines to the top of manifest file of the web project (WebContent/META-INF/MANIFEST.MF) to ensure that the deployed library is available to the deployed application:

Extension-List: scalalib
scalalib-Extension-Name: scala-library

Deployment & Testing
To deploy the Scala servlet, I first added my local WLS installation to the available runtimes for the IDE (Window > Preferences > Server > Runtime Environments). After this was done, Payroll project was deployed by simply running it on the server that had just been added (Run > Run > Run on Server).