Creating a Java EE Appliance With GlassFish Application Server on OpenSolaris

At the JavaOne conference Wednesday morning, Sun technical evangelists Peter Karlsson and Chuk-Munn Lee led a technical session on how to build a Java EE platform-based appliance with the GlassFish application server on OpenSolaris and offered many practical and insightful tips for developers and system administrators alike.

Lee started the session by defining an appliance as "an instrument or device, such as a toaster or wireless router, that performs a specific task." How robust an appliance is depends on a few factors:

• Ease of use: Is it plug and play?
• Compatibility with the environment: Does it blend in well and require, for example, no rewiring?
• Overhead: Does it cost less than the sum of its parts?
• Performance: Is it efficient, and does it accomplish its goal?

A key reason for developing appliances on the Java EE platform is that it includes the GlassFish application server. Also note these benefits:

• The hardware and software requirements are similar for most small to medium Java EE applications.
• Most telecommunications companies have already deployed Java EE technology-based appliances. Additional deployments mean consistency and uniform management practices.
• Software vendors can then offer application-specific Java EE appliances for OEMs.

Over the years, Java EE applications have virtually evolved as an operating environment, not an operating system. You can dive into their development without having an intimate knowledge of the background OS. Subsequently, the applications can manage their own resources, connections, and security.

Karlsson and Lee aim for the example appliance to be economical, with off-the-shelf parts and free and open-source software components; easy to install, configure, and deploy; performing reasonably well and functional at room temperature. The appliance should also support automatic updates.

The appliance runs only the preloaded applications and is not slated for development or for running such resources as databases and email. Nor does the appliance set SPECjbb benchmarks.

Karlsson and Lee picked four software components for the appliance.

First among them was OpenSolaris (May 2008 release), the open-source version of Sun's secure and well-tested Solaris OS. Three capabilities stand out:

• ZFS for state preservation, version management, and backups. As a 128-bit file system and thanks to a storage-pool model, ZFS is infinitely scalable and efficient. Its other big pluses are the data-backup model, a self-healing capability for corrupt data, and a simple administration interface.
• Service Management Framework (SMF) for monitoring services.
• Containers for establishing security.

To minimize the footprint, Karlsson and Lee installed only the required components and services.

They chose these three additional software components:

• Java SE 6 platform, which is ideal for developing and deploying applications on both desktops and servers
• GlassFish application server v2, which is open source, Java platform-compliant, and simple to configure. GlassFish offers both GUI and command-line tools, delivers high performance; supports web-service features, Java Business Integration (JBI), and clustering; and interoperates with Microsoft software. Other capabilities include support of multiple user profiles and Web 2.0 tools (NetBeans IDE and Eclipse) and technologies including Comet, Ruby on Rails, and jMaki. Also, conveniently, you can download modules from the GlassFish update center.
• Groovy and Grails, which are tightly integrated with the Java Virtual Machine (JVM)* and are handy for building the appliance's web administration interface.

The intuitive motherboard for the Solaris platform is the main hardware component of choice. Other components are the following:

• picoLCD 20x2 LCD display
• Keypad
• 12-volt external power supply

Here's a summary of the development and configuration processes that Karlsson and Lee went through:

1. Built a driver interface with the picoLCD and then configured the appliance's IP address and host name with the LCD and keypad input.
2. Auto-detected and deployed the application from a USB drive to the local medium.
3. Applied the OpenSolaris standard configurations and APIs.
4. Managed the applications -- auto-start, define resource dependencies, and so forth -- with the OpenSolaris Solaris Service Management Framework (SMF). SMF manages services, not processes. Once an application is installed, SMF generates an XML manifest that specifies the service name; the commands for starting, stopping, and restarting the service; the recovery actions in case of failure; and the locations for logs and such. When an application starts, OpenSolaris ensures that all the requirements and dependencies are met.
5. Integrated the appliance with tarmac, the OpenSolaris removable-media service, to detect USB content.
6. Integrated the GlassFish application server with SMF.

In addition, to take advantage of the Solaris ZFS capabilities, Karlsson and Lee did the following:

1. Retained a default copy for reset in case of problems, for example, during upgrades.
2. Placed each of the applications on its own ZFS file system.

Lee then showcased the GlassFish Administration Console and VisualVM interfaces, as well as the directory structures for deploying web applications in GlassFish. He called web applications "first-class citizens" for their ease of deployment in the example appliance.

Subsequently, Karlsson discussed the steps for the application deployment scenarios, either with a USB drive or from a URL: adding, upgrading, or rolling back applications to their previous versions, and backing up applications -- all fast, obvious, and seamless operations with a few commands and clicks.

Lee pointed out three lessons learned:

• Allow yourself ample time.
• Decide early on the application type supported by the appliance.
• Groovy and Grails work particularly well for databases.

Down the road, Karlsson and Lee will look into enhancements: self-configuration for Java EE application packages and more extensive support for tools and clustering. For now, the exercise is definitely worthwhile and, judging from a comment from an attendee, extremely enlightening and helpful.

_______
^* As used on this web site, the terms "Java Virtual Machine" or "JVM" mean a virtual machine for the Java platform.