Devbits

JEE 5 makes most of the deployment descriptors optional. For example, the annotation @Stateless can be used to identify a stateless session bean instead of adding a declaration in META-INF/ejb-jar.xml of an EJB module. To add to this, WebLogic Server 10 has extended the JEE annotation support to include annotations that make web modulea??s deployment descriptor optional. For example, the @WLServlet annotation can be used as an alternate for declaration in WEB-INF/web.xml. Finally, the JEE Spec has made the META-INF/application.xml optional in an enterprise application. In case META-INF/application.xml is absent, the app servers are required to examine the contents and make inference about their types. For example, a module ending with a??.wara?? must be interpreted as a web module and should be deployed as one.

With configuration scattered around in source files and packaging details, an administrator might want to examine the consolidated configuration. The developer of the application might also want to examine the containera??s view of the configuration for debugging. Two of the build time tools packaged with WebLogic Server help the administrators & the developers do exactly this. Both AppMerge & AppC now support a new flag a??writeInferredDescriptorsa??. When this flag is used, these tools write out an updated version of the descriptors that include the configuration information from annotations and packaging. In case, the descriptors does not exist in the source application, these tools write out new descriptors if the flag is used.

Leta??s assume we have an application flight.ear that has no descriptors. It has two archived modules:

$ jar tf flight.ear
statusApp.war
statusCheck.jar

Leta??s assume that statusApp.war has no descriptors and has one Servlet that is annotated with @WLServlet annotation.

$ jar tf statusApp.war
WEB-INF/
WEB-INF/classes/
WEB-INF/classes/weblogic/
WEB-INF/classes/weblogic/examples/
WEB-INF/classes/weblogic/examples/flight/
WEB-INF/classes/weblogic/examples/flight/Status.class

Leta??s assume that the statusCheck.jar has no descriptors either. It has some class files, one of which is a Stateless session bean thata??s annotated with @Stateless & @Remote annotations

$ jar tf statusCheck.jar
weblogic/
weblogic/examples/
weblogic/examples/flight/
weblogic/examples/flight/FlightCheck.class
weblogic/examples/flight/FlightCheckBean.class

If we were to invoke AppMerge in the following way, ita??ll generate a new version of flight.ear, called flightX.ear.

$ java weblogic.appmerge -writeInferredDescriptors -output flightX.ear/ flight.ear

(In this example, I appended a a??/a?? at the end of flightX.ear so that the tool creates the output application as a directory. We could drop the '/' in the end (-output flightX.ear) and the tool would generate an archive.)

If we were now to examine flightX.ear, ita??ll have a deployment descriptor.

$ cat flightX.ear/META-INF/application.xml
<?xml version='1.0' encoding='UTF-8'?>
<jav:application xmlns:jav="http://java.sun.com/xml/ns/javaee">
  <jav:module>
    <jav:web>
      <jav:web-uri>statusApp.war</jav:web-uri>
      <jav:context-root>statusApp</jav:context-root>
    </jav:web>
  </jav:module>
  <jav:module>
    <jav:ejb>statusCheck.jar</jav:ejb>
  </jav:module>
</jav:application>

Similarly, the two modules in flightX.ear would now have descriptors:

$ jar tf flightX.ear/statusApp.war WEB-INF/web.xml
WEB-INF/web.xml
$ jar tf flightX.ear/statusCheck.jar META-INF/ejb-jar.xml
META-INF/ejb-jar.xml

These descriptors can now be examined to see how the containers would deal with the module deployment. Note that the descriptors in the modules would have a??metadata-completea?? attribute on the root element set to true.

The flag "writeInferredDescriptors" can also be used for deployment optimization. If we were to deploy flightX.ear, the annotation processing would not be done because metadata-complete is set to true. Module discovery wouldna??t be done either because META-INF/application.xml would now be present in the application.

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.