GlassFish v2: Open for Business

   
By Ed Ort, January 2008  

Articles Index

Open-source software is becoming a very attractive choice for a lot of companies and their in-house developers. That's because the community can freely acquire and upgrade the source code for open-source software. This usually means that the software improves at a much faster rate than does proprietary software, and the upgrades are often more in tune with what companies and their developers actually want. And its low cost -- open-source software is usually free -- doesn't hurt matters either. That translates into a lot of interest and a quickly expanding amount of use.

However, companies have not trusted open-source software to manage their business-critical applications or to handle high-load, high-transaction environments. That's because open-source software tends to be unsupported and sometimes provides less performance, reliability, and ease of operation than its proprietary counterparts. In particular, when it comes to key enterprise components such as application servers, IT decision makers tend to relegate the open-source variety to niche or low-risk applications.

 
Companies no longer have to choose between an open-source application server and a robust, reliable, enterprise-ready application server. They can have both with GlassFish v2.

But with the availability of GlassFish v2 , companies now have an application server that is open source and has the characteristics needed to handle business-critical applications and the rigors of production environments. Companies no longer have to choose between an open-source application server and a robust, reliable, enterprise-ready application server. They can have both with GlassFish v2.

This article highlights the features that make GlassFish v2 a good choice for handling critical business applications and the demands of a production environment.

Contents
 
What Is GlassFish?
GlassFish v2 and Its Commercial Distribution
High Availability and Scalability
Enterprise-Grade Performance
Centralized Administration and Monitoring
Easy One-Step Configuration With Profiles
Interoperability With .NET
JBI Ready
Superior Message Handling
Attractive Support Pricing
Summary
For More Information
About the Author
 
What Is GlassFish?

In June 2005, Sun launched the GlassFish project -- an action that opened to the Java community the development of an application server compliant with Java Platform, Enterprise Edition 5 (Java EE 5). Since then an active community of developers called the GlassFish community has participated in the project. The initial result of their efforts was GlassFish v1, the first open-source, Java EE 5-compliant application server, and the reference implementation for Java EE 5. In addition, the GlassFish community released Toplink Essentials, the reference implementation of the Java Persistence API. The community also fosters a variety of subprojects, such as Metro, jMaki, Open Message Queue (Open MQ), Hudson, and Grizzly.

 
GlassFish v2 includes all the features in GlassFish v1 and adds features that make it an application server ready to take on the challenges of heavy-duty production environments.

The focus of GlassFish v1 was on developers. The objective was to provide an open-source and fully Java EE 5-compliant application server in which developers could deploy and test their Java EE 5 applications. The vision was simple deployments, that is, application deployments on single instances of GlassFish. GlassFish v1, which is available under the Common Development and Distribution License (CDDL), has been extremely popular, with more than 3 million downloads per year. It's had worldwide adoption and is available in multiple distributions, including a Sun-supported commercial distribution, Sun Java System Application Server Platform Edition 9.0. It's also available on multiple platforms including the Solaris, Windows, and Linux operating systems.

In September 2007, the GlassFish community released GlassFish v2, which includes all the function in GlassFish v1 and adds features that make it an application server ready to take on the challenges of heavy-duty production environments. This article outlines these features.

GlassFish v2 and Its Commercial Distribution
SunJava System Application Server

As mentioned earlier, GlassFish v1 has a Sun-supported commercial distribution. This is also the case for GlassFish v2. The Sun-supported commercial distribution of GlassFish v2 is Sun Java System Application Server 9.1. GlassFish v2 and Sun Java System Application Server 9.1 have the same code base. In addition, you can purchase support service from Sun for Sun Java System Application Server 9.1. For more information about support service, see the section Attractive Support Pricing.

You can deploy and redistribute both GlassFish v2 and Sun Java System Application Server 9.1 for free. However, unlike GlassFish v2, you can't modify Sun Java System Application Server 9.1 -- its code is available only in binary form. GlassFish v2 source code can be modified under either CDDL or the GNU General Public License (GPL) v2 with Classpath exception.

For the most part, this article uses the term GlassFish v2 to cover both the open-source application server, GlassFish v2, and its commercial distribution, Sun Java System Application Server 9.1. In the few places where the discussion differs between the two distributions, the article refers specifically to either GlassFish v2 or Sun Java System Application Server 9.1.

High Availability and Scalability

If an application server is going to handle critical business applications, it must ensure that those applications are highly available. For an application server to meet the demands of production environments, it must scale to meet increasing workloads. GlassFish v2 ensures high availability and scalability through clustering and High-Availability Database (HADB) technology.

Clustering

A cluster is a group of GlassFish v2 application server instances that you can manage and monitor as a single logical entity. To create a cluster, you must first enable a GlassFish v2 domain for clustering. A GlassFish v2 domain or more precisely administrative domain is a logical boundary within which all GlassFish v2 entities are controlled by an administrator. At runtime, a domain equates to a GlassFish v2 application server instance or a cluster. You can easily enable clustering for a domain when you install GlassFish v2. For example, after you install GlassFish v2, you can use the following command to create a domain and enable it for clustering:

lib/ant/bin/ant -f setup-cluster.xml
 

You can also enable clustering for an existing domain from the GlassFish v2 Admin Console, which will be covered later in this article.

By enabling a domain for clustering, you give it a cluster profile. For information about profiles, see Easy One-Step Configuration With Profiles. You then have the flexibility to create or remove clusters from the domain and add or remove GlassFish v2 instances from a specific cluster. By adding instances to a cluster or adding clusters within a domain, you can scale to meet demands for increased application server capacity and speed. For more information about managing and monitoring clusters, see Centralized Administration and Monitoring.

 
If one application server instance in a cluster fails, the session interacting with that instance is rerouted to another instance in the cluster so that it can handle the session.

Perhaps the most important aspect of clustering is memory replication. In memory replication, information about the state of user sessions with deployed applications in a GlassFish v2 instance is replicated to a peer instance in the cluster. Each GlassFish v2 instance in a cluster sends session-state information to the next instance in the cluster, its replication partner. The order of instances in a cluster is based on the names of the instances. As the session-state information for a deployed application is updated in any instance, it is replicated around the cluster.

Playing an important role in memory replication is the load balancer, which is available as a plug-in with GlassFish v2. The load balancer is responsible for distributing workload among multiple GlassFish v2 instances. It also takes part in rerouting a session when an instance fails. If a GlassFish v2 instance in a cluster fails, the load balancer reroutes the sessions interacting with that instance to another instance in the cluster.

Figure 1. Handling a Failover in a Cluster
 

As Figure 1 shows, if Instance 1 fails, the load balancer routes the sessions interacting with Instance 1 to another instance, here Instance 2. If the routed-to instance is the replication partner of the failed GlassFish v2 instance, the sessions are handled there. But if the routed-to instance is not the replication partner, the replication partner transfers the replicated session data to the routed-to instance.

In other words, if the load balancer routes the sessions to Instance 3, which is not the replication partner, then Instance 2, which is the replication partner, sends the state data to Instance 3 to handle the sessions.

Through memory replication, GlassFish v2 makes deployed applications highly available. Users should notice little, if any, interruption in their interaction with these applications.

You can further increase availability by placing cluster instances and their replication partners on different machines. In this way, if one of the machines fails, session data is not lost.

High-Availability Database (HADB) Technology

Enterprises that require an extremely high level of availability can take advantage of High-Availability Database (HADB) technology, a feature that has been available with previous versions of Sun Java System Application Server and is available in version 9.1. HADB offers 99.999 percent ("five-nines") availability and provides a persistent database store for maintaining session-state information. HADB is not open source, but is free to use in production.

Note however, that the robust, in-memory replication offered through the clustering feature of GlassFish v2 should meet the high-availability needs of most installations. In addition, in-memory replication requires less installation setup and less administrative control than HADB -- plus, it's open source. Beyond that, in-memory replication takes advantage of a number of performance optimizations to outperform HADB. However, if you have operations that currently use HADB or if you require five-nines availability, you have the option of choosing Sun Java System Application Server 9.1 with HADB.

For more information about clustering and HADB, see Clustering in GlassFish Version 2.

Enterprise-Grade Performance

No matter how much you scale, you want an application server to perform well. You want it to handle its processing load in a way that gives excellent throughput and response time. GlassFish v2 meets those goals. In fact, GlassFish v1, in its commercial version, Sun Java System Application Server 9.0, was the first open-source application server that published a SPECjAppServer2004 benchmark result. SPECjAppServer2004 1 is an end-to-end application that exercises all major Java EE technologies implemented by compliant application servers, and does it in a way that reflects the complex of applications and high-volume transaction processing that is typical of an enterprise environment.

 
GlassFish v2 is the fastest open-source application server, with performance that surpasses the market-leading proprietary application servers.

GlassFish v2 is the fastest open-source application server, with performance that surpasses the market-leading proprietary application servers. In July 2007, GlassFish v2 posted the highest-ever score on SPECjAppServer for a single Sun Fire T2000 server, 2 at the time beating competitors by as much as 20 percent.

Recently, a scalable result was posted for GlassFish v2 that is the third-highest score ever published on this benchmark . 3 That result is within 20 percent of the best result ever published, even though it uses far less hardware, space, and power than used in benchmarks producing competitive results.

Note that an application server's performance depends on the mix of applications that it runs. Your results may vary from those in the SPECjAppServer2004 benchmarks.

One area that has gotten a significant performance boost in GlassFish v2 is web services technology. The collection of web services technologies in GlassFish v2 is called Metro. Metro includes core web services technologies such as Java API for XML-Based Web Services (JAX-WS) 2.1 as well as technologies that support web services interoperability between Java EE and Windows .NET environments. JAX-WS 2.1, in tandem with a companion technology, Java Architecture for XML Binding (JAXB), has been tested in a rigorous web services benchmark and has shown outstanding performance results in terms of the number of requests processed per second.

For more information about GlassFish v2 performance, see SJSAS 9.1 (Glassfish V2) Posts New SPECjAppServer 2004 Result and A Scalable SPECjAppServer 2004 Submission.

Centralized Administration and Monitoring
 
The Admin Console give you a central point of control over the GlassFish instances and clusters in your enterprise.

You can manage and monitor GlassFish v2 instances or clusters from a single GlassFish v2 Admin Console, officially known as the Sun Java System Application Server Admin Console, or from the GlassFish v2 command line interface (CLI). Not only does this give you a central point of control over the GlassFish instances in your enterprise, but it allows you to manage or monitor each cluster independently.

Easy-to-Use Admin Console

One of the important aspects of the Admin Console is its ease of use. You'll notice this when you log in to the Admin Console. The first page displayed is a Common Tasks page that brings together common operational tasks. Figure 2 shows the Common Tasks page for a domain that's enabled for clustering.

 

Notice that buttons are displayed for tasks such as creating a new cluster, deploying an enterprise application, and monitoring data. These buttons are supplemented by a navigation tree that gives you an alternate path to performing administrative tasks. To initiate an operational task, you simply click the appropriate button in the page or click a node in the tree. For example, to create a cluster in a domain enabled for clustering, start by clicking the Create New Cluster button in the page or clicking the Clusters node in the navigation tree.

Also notice that supporting documentation for administrative tasks is directly available in the Common Tasks page. These documents are part of an extensive library of reference documents available in the Sun Microsystems Documentation page.

The Common Tasks page and many other elements of the Admin Console are dynamic. These elements, which are part of the set of next-generation user interface components developed in Project Woodstock, take advantage of Ajax capabilities to provide fast responses to your entries and a smooth transition between displays.

Comprehensive Monitoring

The Admin Console also makes it easy to monitor a wide range of application server-related data. Simply click the View Monitoring Data button on the Common Tasks page to display a tabbed page where each tab presents data about a different aspect of the application server or its operating environment. The Call Flow tab, for instance, displays call flow data, as shown in Figure 3.

 

By monitoring the call flow for a given transaction, you can track the transaction as it moves through various application server containers, as shown in Figure 4.

Figure 4. Call Flow Details for a Transaction
Click the image to enlarge it.
 

GlassFish v2 is enabled for Java Management Extensions (JMX) technology. This means that if you already use JMX to monitor and manage resources in your enterprise, you can easily extend that approach to also manage and monitor GlassFish v2 resources. You can also incorporate GlassFish v2 into an end-to-end management and monitoring approach implemented through the Sun Management Center and Halcyon's PrimeAlert for Sun Application Server.

Intelligent Command Line Interface (CLI)

You can also perform a complete range of administration tasks related to GlassFish v2 through the CLI. In general, you can perform almost any GlassFish v2-related administrative task either through the Admin Console or through the CLI. For example, you can use the CLI to start and stop a GlassFish v2 domain, create a cluster, or turn on or off the gathering of call flow data. The CLI also has a "best matches" feature that suggests alternative entries if you make an error when you enter a command. For example, if you mistype the keyword domain in an asadmin command as follows:

asadmin start-domian
 

the CLI suggests an alternative:

Closest matching command(s):
    asadmin start-domain
 
Administering Large-Scale Deployments

The Admin Console and CLI supplied with GlassFish v2 are excellent tools for deploying and configuring single instances or clusters. For large-scale enterprise deployments, you can use Sun N1 Service Provisioning System (N1SPS). The N1SPS Plug-In for Sun Java System Application Server makes it easy to install, configure, and manage Sun Java System Application Server 9.1 installations across your enterprise. You can also use the plug-in to configure and manage existing GlassFish v2 installations, but you can't use it to install them. For more information about N1SPS, see Provisioning Sun Java System Application Server With N1SPS.

For more information about the Admin Console in GlassFish v2, see the GlassFish Project - Admin Console (GUI) home page. For more information about the monitoring capabilities in GlassFish v2, see GlassFish Version 2 Monitoring Capabilities.

Easy One-Step Configuration With Profiles

Optimization is an important requirement for an application server, but each use of the server might require a different kind of optimization. For example, a developer who is building and testing an application might be particularly interested in optimizing the speed with which the application server responds to application requests, but not particularly interested in security. By comparison, security is very important in a production environment, so it's a primary focus of people who deploy applications.

 
You can configure and optimize GlassFish v2 for a particular type of use simply by specifying the appropriate profile when you create the application server domain.

You can manually tune an application server to meet specific requirements by setting configuration parameters, but that can take a lot of time and effort. Or you might use a specific edition of an application server that is preconfigured for a particular type of use. In fact, previous releases of the Sun Java System Application Server were available in various editions. For example, the Platform Edition was geared toward developers, and the Enterprise Edition was geared toward large enterprises. However, installing and managing multiple editions of an application server for different uses can be unwieldy.

A better solution would provide a single edition of the application server but also provide preset configurations for specific usage patterns. In fact, that is how GlassFish v2 is distributed. It's available in one moderately sized distribution bundle, and it supports various usage profiles. Each profile presets configuration parameters for a particular type of use. GlassFish v2 supports three profiles: developer, cluster, and enterprise.

The developer profile optimizes GlassFish v2 for use in a development environment. This means that the configuration parameters support objectives such as fast startup, but don't support things like logging or session replication. The cluster profile sets configuration parameters that enable cluster creation and session replication. The enterprise profile optimizes GlassFish v2 for a production environment. It supports things like logging and other security-related features.

Table 1 summarizes some of the characteristics of the three profiles.

Table 1: GlassFish v2 Profile Characteristics and Settings
 
Characteristic
Description
Value in Developer Profile
Value in Cluster Profile
Value in Enterprise Profile
Security store
The type of store used for security artifacts such as keys and certificates. There are two main types of stores: JKS (Java Key Store), the proprietary type of keystore implementation provided by Sun, and NSS (Network Security Services), a set of libraries designed to support cross-platform development of security-enabled client and server applications. The store types differ in terms of format and in the tools that can be used to configure them. NSS is typically the preferred type of security store for enterprise solutions.
JKS
JKS
NSS
Quick startup
Option to enable the application server for quick startup. Quick startup is accomplished through a Java-NIO based implementation that is part of the on-demand services framework.
true (enabled)
false (disabled)
false (disabled)
JVM
Java Virtual Machine configuration parameters.
Hotspot VM configuration parameters
Hotspot VM configuration parameters
Determined by the JDK
Session replication mechanism
Option that identifies the session replication mechanism.
None
In-memory replication
HADB
 

You specify a profile when you create a domain. For example, the following command creates a domain and specifies the enterprise profile for that domain:

asadmin create-domain --user admin --adminport 4848 --profile enterprise dev-domain
 

That's all you need to do to configure and optimize a GlassFish v2 application server instance for a particular type of use -- in this case, use in a production environment.

For more information about profiles, see One Pager: Usage Profile Support for Application Server.

Interoperability With .NET

Interoperability is an important requirement in an enterprise. That's because an enterprise's application resources are typically distributed across a range of operating environments. For example, the client part of an application might be in one environment, such as Java EE, and the web services it needs might be in another environment, such as Microsoft's .NET framework. GlassFish v2 enables web services-based applications to interoperate between Java EE and .NET environments.

Metro and Web Services Interoperability
 
GlassFish v2 enables web services-based applications to interoperate between Java EE and .NET environments, with support for secure and reliable messaging as well as transactions.

Recall that GlassFish v2 includes Metro, which provides a robust set of technologies for web services. However, Metro is more than a stack of technologies for web services that run in Java EE. Metro also enables web services to interoperate with the Windows Communication Foundation (WCF), the web services stack in Microsoft's .NET framework. Both Metro and WCF implement a set of web services specifications commonly called WS* specifications -- they all begin with "WS" -- that enable secure, reliable, and transaction-oriented web service interactions. The implementation of the WS* specifications in Metro is called Web Services Interoperability Technology (WSIT). As Figure 5 shows, WSIT allows a web service client in GlassFish v2 to interact with a web service endpoint in .NET 3.0, or a web service client in .NET 3.0 to interact with a web service endpoint in GlassFish v2. GlassFish v2 client-to-GlassFish v2 endpoint communication is also supported.

Figure 5. Metro Interoperability With .NET
 

And because Metro and WCF support secure, reliable, and transaction-oriented web service interactions, a web services client can request that its interchanges with a web service be secure, that they be reliably received, or that they be handled as transactions that can be committed or rolled back -- or any combination of these.

A Simple Interface for Configuring Web Service Interoperability

The interoperability characteristics of a web service endpoint in GlassFish v2 are specified in an XML file called the WSIT configuration file. A web services developer can code the required XML in the file. However, XML can be verbose and the contents of a WSIT Configuration File can be extensive. A simpler way to develop an interoperable web service is to use the NetBeans IDE, versions 5.5.1 or 6.0. To enable the NetBeans IDE 5.5.1 for WSIT, you install a WSIT plug-in module. The plug-in module is already packaged in the NetBeans IDE 6.0. Once enabled, the IDE presents a simple checkbox interface for configuring a web service with WSIT characteristics such as secure messaging, reliable messaging, and transaction support. Figure 6 shows this interface in the NetBeans IDE 6.0.

Figure 6. Specifying Reliable Message Delivery for an Interoperable Web Service
Click the image to enlarge it.
 

Notice that the Reliable Message Delivery and Deliver Messages In Exact Order checkboxes are selected in Figure 6. Selecting these checkboxes is all you need to do to enable a web service for reliable message delivery and to ensure that messages sent by the client are delivered to the web service endpoint in the exact order they are sent.

You can then deploy the web service on GlassFish v2 using the NetBeans IDE. In the process, the IDE generates the appropriate artifacts including the configuration file and all the appropriate XML code for the configuration selections.

Consider the time, difficulty, and cost of implementing web services interoperability between the Java EE platform and the .NET framework. To do that typically requires a lot of custom code as well as some expensive messaging infrastructure. With Metro, you can get this support at no extra cost -- it's already built into GlassFish v2.

For more information about support in Metro for web services interoperability with .NET, see Project Tango: An Overview (PDF) and the Metro Project.

JBI Ready

GlassFish v2 has built-in support for Open ESB, an implementation of Java Business Integration (JBI). JBI as specified by JSR 208 is a Java standard for structuring business systems according to a service-oriented architecture (SOA). In an SOA approach, an application can be assembled from distinct services, where each service performs one or more business-related processes. SOA gives an enterprise a lot of agility in building these composite applications because services and data that are used in one application can be shared and reused in other applications. Approaches like this that integrate services and data to make new applications are often called integrated application systems. In the past, implementing an integrated application system required using a lot of custom code or investing in proprietary systems. JBI standardizes the way an integrated application system is structured and eliminates the need for special coding or proprietary solutions.

JBI defines an environment for plug-in components, where each plug-in component provides the technology to run a particular type of service, to orchestrate the order in which services run, or to perform other business process-related tasks such as transforming data formats. For example, one JBI component might be an EJB service engine that runs services deployed as Java EE enterprise archive (EAR) files. Another component might be an SQL service engine that runs SQL queries. A third component might be a Business Process Execution Language (BPEL) service engine that runs BPEL statements that orchestrate a business process. Some plug-in components are binding components that communicate with other environments to provide or use services. For example, one binding component might use SOAP over HTTP to run a remote service that does a credit check. Another binding component might use SMTP to send an email notification about the credit check.

The idea here is to provide a lot of flexibility in the components that compose a JBI-based system and give an enterprise a wide range of choices in the type of services it can incorporate into its composite applications. As an implementation of JBI, Open ESB allows you to integrate services into loosely-coupled composite applications.

 
GlassFish v2 provides the runtime environment for Open ESB. It offers a rich set of service engines that run particular types of services, and binding components that communicate with other environments to provide or use services.
An Open ESB Runtime Environment

GlassFish v2 provides the runtime environment for Open ESB. It offers a rich set of service engines and binding components. And because Open ESB is JBI-based, you can add JBI-compliant service engines and binding components to those that GlassFish v2 provides.

As Figure 7 shows, web services deployed in a GlassFish v2 application server communicate with the JBI runtime environment through JAX-WS and a component called the Sun Java EE Engine. As is the case for other JBI components, the Sun Java EE Engine uses a lightweight messaging infrastructure called the Normalized Message Router (NMR) to communicate with other service engines and binding components. Note that in Figure 7, SE stands for service engine and BC stands for bind component.

 
Managing Open ESB components

You can use the Admin Console or the CLI to manage the Sun Java EE Engine as well as other Open ESB components in GlassFish v2. For example, you can use the Admin Console to deploy a JBI service assembly, which contains part or all of a composite application, simply by clicking the Deploy Java Business Integration (JBI) Service Assembly button in the Common Tasks page. You can start, stop, shut down, or uninstall the Sun Java EE Engine from the Admin Console or the CLI. For example, you can start the Sun Java EE Engine by entering the following command in the CLI:

asadmin start-jbi-component sun-javaee-engine
 
Tools for Building Composite Applications

On the development side, the NetBeans IDE 6.0 provides a rich set of tools for building composite applications that run in an Open ESB environment. These tools include a BPEL design tool, a graphical Web Services Description Language (WSDL) editor, a Composite Application Service Assembly (CASA) editor, as well as tools for managing schemas and XSLT transforms.

Use the NetBeans IDE 6.0 to build composite applications. Then deploy, run, and manage them in GlassFish v2.

For more information about Open ESB support in GlassFish v2, see Sun Java EE Engine: Bridging Java EE Web Services and JBI Components and the Open ESB Project.

Superior Message Handling

An efficient messaging server is crucial in connecting business software to form an efficient enterprise. GlassFish v2 provides Open Message Queue (Open MQ), a complete Java Message Service (JMS) implementation for message-oriented system integration. JMS is a messaging standard that allows Java EE-based application components to create, send, receive, and read messages. In implementing JMS, Open MQ provides a full-fledged messaging server and is the open-source version of the Sun Java System Message Queue product. Open MQ can run on its own -- it has its own set of administration tools -- or fully integrated into GlassFish v2.

 
GlassFish v2 provides Open MQ, a complete Java Message Service (JMS) implementation for message-oriented system integration.

When used with GlassFish v2, the message broker, the Open MQ component that provides JMS-based message delivery services to clients, can be in the same process as GlassFish v2. That is, they both run in the same Java Virtual Machine. This relationship of Open MQ to the application server is called EMBEDDED mode. The message broker can also simply share the same life cycle as GlassFish v2 in LOCAL mode or run separately in REMOTE mode.

Efficient and Reliable Message Delivery

Using Open MQ, you can connect legacy and new applications with the assurance of reliable message delivery. The delivery of messages is guaranteed, and messages are delivered in the exact order they are sent.

Open MQ supports asynchronous messaging, meaning that an application can send a message and continue processing without waiting for the message to be received. Messages can be sent in a publish-subscribe manner. In this approach, the sender of the message, known as the publisher, sends the message to an intermediate target known as a topic, as shown in Figure 8. Multiple applications, known as subscribers, that subscribe to the topic consume the message by removing it from the topic. Notice that the publisher is totally independent of the subscribers. Alternatively, a message can be sent point to point, that is, to a specific recipient. In this case, the message is sent to a queue, and the recipient consumes the message by removing it from the queue.

Figure 8. Publish-Subscribe Mechanism in Open MQ
 

Beyond its processing capabilities, Open MQ is easy to install and manage. You can install it using a GUI-based installer based on openInstaller. Or you can do a file-based install in which you unpack an archive distribution and then run a setup script to configure Open MQ for use. Open MQ provides its own Admin Console and CLI to perform Open MQ-related operations such as starting a message broker. In addition, Open MQ supports Java Management Extensions (JMX)-based monitoring, clustering, and authentication through the Java Authentication and Authorization Service (JAAS).

High Performance and Availability

Open MQ has been tested as a stand-alone application or integrated into GlassFish, with excellent performance results. In addition, Open MQ supports high availability, both from a data and message broker perspective. The high-availability capabilities are realized when you use Open MQ with a highly available JDBC provider. OpenMQ has been tested with the HADB feature of Sun Java System Application Server 9.1, Oracle Real Application Clusters (RAC), and mySQL.

For more information about Open MQ, see the Open Message Queue project.

Attractive Support Pricing

A flexible set of subscription options is available for Sun Java System Application Server 9.1. You can get support service with full indemnification, on-demand software updates and upgrades, Sun Developer Expert assistance, and more. Subscription prices start at a low $4500 a year for four sockets. For more details, see Java System Application Server Subscriptions.

Summary

Characteristics such as high availability, scalability, enterprise-grade performance, centralized administration, easy one-step configuration, and efficient and reliable message delivery make GlassFish v2 an enterprise-quality application server with the robustness to handle the demands of production environments and the reliability to handle business-critical applications. Add support for web service interoperability and a JBI-compliant runtime, and you have an application server that gives enterprises a lot of flexibility in meeting their application processing needs. Whether it's the open-source, GlassFish v2, or the Sun-supported commercial distribution of GlassFish v2, Sun Java System Application Server 9.1, GlassFish v2 is open for business.

1 SPEC and the benchmark name SPECjAppServer 2004 are registered trademarks of the Standard Performance Evaluation Corporation. Sun Java System Application Server 9.0 achieved 521.42 JOPS@Standard (1 Sun Fire T2000 [8 cores, 1 chip] application server and 1 Sun Fire T2000 [6 cores, 1 chip] database server). For the latest SPECjAppServer 2004 benchmark results, visit the SPEC web site.
2Comparison is based on all SPECjAppServer 2004 scores using a single Sun Fire T2000 as the application server as of July 10, 2007. Referenced scores: Sun Java Application Server 9.1 achieved 883.66 JOPS@Standard (1 Sun Fire T2000 [1 chip, 8 cores] application server and 1 Sun Fire T2000 [1 chip, 6 cores] database); BEA Weblogic 9.1 achieved 801.70 JOPS@Standard (1 Sun Fire T2000 [1 chip, 8 cores] application server and 1 Sun Fire T2000 [1 chip, 6 cores] database); Sun Java Application Server 9.0 achieved 521.42 JOPS@Standard (1 Sun Fire T2000 [1 chip, 8 cores] application server and 1 Sun Fire T2000 [1 chip, 6 cores] database); IBM WebSphere achieved 616.22 JOPS@Standard (1 Sun Fire T2000 [8 cores, 1 chip] application server and 1 Sun Fire X4200 [2 chips, 4 cores] database server); BEA Weblogic 9.0 achieved 615.64 JOPS@Standard (1 Sun Fire T2000 [1 chip 8 cores] application server and 1 Sun Fire V490 [4 chips, 8 cores] database).
3 Comparison is based on all SPECjAppServer 2004 scores published as of 11/23/07. Referenced scores: Sun Java Application Server 9.1 achieved 8439.36 JOPS@Standard (6 Sun SPARC Enterprise T2150 application servers [6 chips, 48 cores] and 1 Sun Fire E6900 database [24 chips, 48 cores]); Oracle Application Server 10.1 achieved 10519.43 JOPS@Standard (Twelve HP BL860c application servers [24 chips, 48 cores] and two HP Superdome database servers [40 chips, 80 cores]); Oracle Application Server 10.1 achieved 9459.19 JOPS@Standard (11 HP BL860c application servers [22 chips, 44 cores] and two HP Superdome database servers [40 chips, 80 cores]).

For More Information
About the Author

Ed Ort is a staff member of JSC. He has written extensively about relational database technology, programming languages, web services, and Ajax.

Rate and Review
Tell us what you think of the content of this page.
Excellent   Good   Fair   Poor  
Comments:
Your email address (no reply is possible without an address):
Sun Privacy Policy

Note: We are not able to respond to all submitted comments.