What's New in JBoss 4.0 The JBoss Application Server (JBoss AS) 4.0 is a production-ready Java 2 Enterprise Edition (J2EE) application server. It builds on the highly successful JBoss 3.2 line of open-source Java application servers with improved standards compliance and major feature enhancements. JBoss AS 4.0 offers the same level of quality and stability customers have grown to expect from JBoss 3.2. Key features of JBoss AS 4.0 include the following: It is officially certified to be fully compliant to the J2EE 1.4 specification. JBoss AS 4.0 is the first production-ready J2EE 1.4 application server in the industry. It provides full support for J2EE Web Services and the Service-Oriented Architecture (SOA). It supports the aspect-oriented programming (AOP) model for developing middleware solutions. JBoss AOP greatly improves developer productivity. It tightly integrates with Hibernate, the world's most popular object persistence framework, developed by JBoss, inside the application server container. It improves clustering and distributed caching support, with a new internal caching architecture.
J2EE Certification and Standards Compliance JBoss AS 4.0 is the industry's first officially certified J2EE 1.4 application server. The certification guarantees that JBoss AS 4.0 conforms to the formal J2EE specification. This allows developers to safely reuse J2EE components (for example, Enterprise JavaBeans [EJBs]) across different application servers. For example, a developer could easily migrate an EJB developed for WebLogic or WebSphere to JBoss. The certification makes JBoss 4.0 a safe upgrading choice for both existing JBoss users and users of other J2EE application servers. Compared with JBoss AS 3.2, JBoss AS 4.0 implements the following new J2EE specifications in order to be J2EE 1.4 compliant: JBoss AS 4.0 supports J2EE Web Services, including JAX-RPC (Java API for XML for Remote Procedure Call) and Web Services for J2EE Architecture, which leverages standard J2EE components (for example, EJBs) to provide a scalable and secure Web Services environment. It is the basis for implementing SOA in J2EE. The older JBoss.NET Web Services API in JBoss AS 3.2 is no longer supported. The new Web Services implementation is WS BasicProfile 1.0 compliant. JBoss AS 4.0 implements the JMS (Java Messaging Service) 1.1 specification instead of JMS 1.0 in JBoss AS 3.2. In JMS 1.0, client programming for the Point-to-Point and Pub/Sub domains was done using similar but separate class hierarchies. In JMS 1.1, there is now a domain-independent approach to programming the client application. JBoss AS 4.0 implements the JCA (Java Connector Architecture) 1.5 specification instead of the JCA 1.0 in JBoss AS 3.2. The JCA 1.5 specification adds support for the life cycle management of resource adapters, worker thread management, and transaction and message inflow from the resource adapter to the application server. JBoss AS 4.0 implements the new Java Authorization Contract for Containers (JACC) specification. JACC is a Java 2 permission-based mechanism for externalizing the authorization decision for accessing EJB methods and web resources. The new implementation is based on the JBoss AS 3.2 semantic of associating the J2EE declarative roles with the authenticated subject as a by-product of the JAAS authentication phase. JBoss AS 4.0 maintains compatibility with the JBoss AS 3.2 security configuration. JBoss AS 4.0 implements the EJB 2.1 specification instead of EJB 2.0 in JBoss AS 3.2. The EJB 2.1 specification extends the message-driven bean contracts to support other messaging types in addition to JMS. It supports stateless session beans as web service endpoints. It also includes a new container-managed service called the EJB timer service.
Server Configuration and Services A big change from JBoss AS 3.2.6 to 4.0.0 is the default server configurations. On JBoss AS 4.0.0, there are four server configurations: minimal The minimal configuration in JBoss AS 4.0.0 has the same meaning as the minimal configuration in JBoss AS 3.2.6. It starts the JBoss microkernel, JMX MBean server, and JNDI naming service. standard The standard configuration in JBoss AS 4.0.0 has the same meaning as the default configuration in JBoss AS 3.2.6. It starts all J2EE services in JBoss's optimized class loader. The JBoss AS 4.0.0 standard configuration yields better performance than other configurations when the components are deployed in the same JVM. But the deployed applications are less compartmentalized in this configuration. default The default configuration in JBoss AS 4.0.0 is new. It is the J2EE-certified configuration of the server. All J2EE services are deployed, and all components are compartmentalized. But the application performance in the JBoss AS 4.0.0 default configuration is not as optimized as that in the standard configuration. all The all configuration in JBoss AS 4.0.0 has the same meaning as the all configuration in JBoss AS 3.2.6. It starts all services, including clustering.
From JBoss AS 4.0.1, the server configuration names switch back to the JBoss 3.2 convention. The default configuration uses the JBoss optimized class loader, and the standard configuration goes away. The J2EE 1.4 certified configuration of JBoss (that is, the default configuration in JBoss AS 4.0.0) is distributed in a separate package from JBoss AS 4.0.1. In addition to server configuration name changes, JBoss AS 4.0 also adds support for new types of server services. SARDeployer now recognizes the *.deployer archives (both in expanded directories and in zip files) and the *-deployer.xml files as valid deployment options. The .deployer suffix is equivalent to the .sar suffix, and the -deployer.xml filename suffix is equivalent to the -service.xml descriptor filename suffix. These suffixes are sorted ahead of any other service types so that these .deployer services are started before other services. For example, the JBoss AOP services are deployed as a .deployer service archive (that is, the jboss-aop.deployer archive in the deploy directory). This makes sure that the JBoss AOP services are started early in the server startup process. JBoss AOP Support Aspect-oriented middleware is a key innovation in JBoss AS 4.0. It drastically simplifies middleware application development and allows developers to extend the container services. In JBoss AS 4.0, you can deploy AOP-based services and applications directly into the application server. You can find a detailed introduction to aspect-oriented programming and the JBoss AOP framework on the JBoss website, at www.jboss.org/products/aop. In JBoss AS 4.0.0's standard and all configurations (the default and all configurations in JBoss AS 4.0.1), AOP support is provided by the jboss-aop.deployer service. It is a new .deployer-type service similar to the .sar service. The following key features are supported by the jboss-aop.deployer service: By default, you have to instrument the bytecode of your AOP applications offline, using the aopc utility, before you can deploy them into the application server. But you can enable load-time bytecode instrumentation via a configuration attribute in the jboss-aop.deployer/META-INF/jboss-service.xml file. JBoss AS 4.0 ships with several prepackaged aspects to support security transaction asynchronous threads on plain old Java objects (POJOs). There are a number of predefined annotation tags in the baseaop.xml file. You can use those annotations in your POJOs to take advantage of the prepackaged aspect services. JBoss AS 4.0 defines a new XML deployment file type with the filename *-aop.xml. The *-aop.xml file specifies the binding for user-defined aspect classes. The aspect and binding become available to applications on the server. JBoss AS 4.0 defines a new JAR archive file type with the .aop filename extension. The .aop file can be used to package user-defined aspects and their bindings. The jboss-aop.xml file must reside in the META-INF directory in the .aop archive. The .aop archive can be bundled inside other deployment archive files to provide aspect services to a specific application.
Hibernate Integration Hibernate is a very popular object persistence framework developed by JBoss. It maps Java objects to tables in relational databases and vice versa. The object-relational mapping rules and datasources are specified in special Hibernate configuration files. In JBoss AS 4.0, Hibernate integration support is provided by the jboss-hibernate.deployer service, which is available in the default, standard, and all configurations. The jboss-hibernate. deployer service provides Hibernate framework libraries to all applications on the server. For Hibernate applications, JBoss defines a new .har service archive type. You can package your Hibernate-mapped Java objects and mapping configuration files in the .har archive. You can also specify a datasource name and a JNDI name for this particular Hibernate configuration in the hibernate-service.xml file in the .har archive. The benefit is that, in your applications, you only need to do a JNDI lookup to retrieve the correctly configured Hibernate SessionFactory object. There is no need to load the mapping and datasource configuration files manually in the application via API calls. In addition, the configuration settings in the hibernate-service.xml file are manageable via the JBoss JMX Management Console. The .har file can be bundled inside an .ear file or deployed on a standalone basis. Clustering and Caching Many of the JBoss AS 4.0 clustering and caching improvements have been backported and made available in JBoss 3.2.3 to 3.2.7. Here's an overview of those improvements: TreeCache, which is based on the JGroups technology, is officially adopted as the underlying distributed cache architecture for the clustering environment. CacheLoader support (store/read from secondary storage) for both shared and unshared back-end stores is added. Currently, there are CacheLoader implementations for the Sleepycat Berkeley DB (BdbjeCacheLoader), for generic JDBC datasources, and for the file system (FileCacheLoader). The HttpSession object is replicated across clustered servers. So if one server fails, the users are moved to a failover server without losing their sessions. The Single Sign-On (SSO) security context is replicated across clustered servers. This way, the user is not required to log in again when a server fails. The new loadbalancer service provides reverse-proxy support with silent failover.
|
