Resin Java EE 6 Web Profile Implementation
We at Caucho are very excited in working steadily towards getting Resin certified on the recently finalized Java EE 6 Web Profile. Along with GlassFish and JBoss, we are aiming to provide one of the earliest solid implementations for Java EE 6. In fact, Resin is the only major application server focused solely on delivering a very lightweight implementation targeting just the Web Profile.
This blog entry briefly discusses the Java EE 6 Web Profile, what it offers and how it fits with the lightweight development philosophy of Resin as well as the details of our implementation including Resin extensions to the Java EE 6 Web Profile.
A Quick Look at the Java EE 6 Web Profile
Until the introduction of Profiles, Java EE has been an ever expanding monolithic API set. The traditionally one-size-fits-all approach has meant that most applications do not use a large number of APIs in Java EE. For example, most web applications do not use remoting but do use the web tier APIs like Servlet, JSP and JSF. The heavyweight footprint of application servers that implement the entire Java EE API set is a symptom of this underlying problem (although sadly not being the sole reason for the bloat obvious in some application servers).
Profiles in Java EE 6 are designed to address this problem by defining sub-sets of APIs geared towards particular types of applications. The Web Profile is the first and only profile defined in Java EE 6 (the expectation is that more profiles will be defined going forward). The Web Profile is composed of a complete set of Java EE APIs that is needed for a majority of modern web applications. The following table outlines the specific APIs included in the Java EE 6 Web Profile:
| API | Purpose |
|---|---|
| JSF 2, Facelet, JSP, Servlet 3 | Web tier |
| CDI, managed beans, interceptors | Dependency injection, context management, cross-cutting logic, events, extensibility, integration, testing |
| EJB 3.1 Lite | Business tier, declarative and programmatic transactions, declarative and programmatic security, testing |
| JTA | Transaction management |
| JPA 2 | Persistence tier |
| Bean validation | Constraints management |
Like Profiles, EJB 3.1 Lite is a sub-set of the full EJB API. It includes stateless session beans, stateful session beans, singleton beans, declarative and programmatic transactions, declarative and programmatic security as well as an embedded container geared towards out-of-container testing. EJB 3.1 Lite does not have support for message driven beans, asynchronous processing, scheduling, REST (JAX-RS) end-points, SOAP (JAX-WS) end-points, RMI/CORBA based remoting as well as backwards compatibility requirements for EJB 2.x.
The Java EE 6 Web Profile leaves out a number of APIs that are not used that often in web applications such as JAX-WS, JAX-RPC, JAXR, SAAJ, JAX-RS, JAXB, JMS, JAAS, JASPIC, JACC, JCA, JavaMail, the Java EE Management Specification (JSR 77) and the Java EE Deployment Specification (JSR 88). Note Profiles do not stop a vendor from adding APIs and features as they see fit. As we will discuss shortly, we have chosen to add a very small number of Java EE APIs and features on top of the Web Profile. Specifically, we see value in adding support for scheduling, asynchronous processing, messaging, message driven beans and Hessian based remoting.
Resin and Java EE
The Resin team has always focused on delivering a lightweight, fast, reliable and easy-to-use application server. We are as proud of our lightweight heritage as we are of our small, independent and personal nature as an organization that treats engineering as a craft. We have also always respected the value in standardization, developer choice, multilateral collaboration and having competing but compatible products. However, before the Java EE 6 Web Profile, it was difficult to reconcile these concepts in Resin. The choices were really split between either creating a lightweight Java application server or aiming for full standards compliance. Resin has historically chosen the lightweight implementation route along the same lines as Tomcat and Jetty (with some important differences we will discuss shortly).
The problems with earlier versions of Java EE are now well understood. They included an over-emphasis on CORBA/remoting in EJB 1.x, the heavyweight programming paradigm in EJB 2.x, the flawed persistence model in EJB 2.x entity beans, serious problems in portability as well as the complexity in XML deployment descriptors. While Java EE 5 went a long way to solving the issues around ease-of-use, we still saw a number of practical roadblocks in the way of creating a really lightweight implementation that Resin developers would find compelling.
Because of backwards compatibility requirements in EJB 3.0, it was still necessary to fully implement EJB 2.x and RMI/CORBA remoting. Due to the absence of profiles, we would have also been forced to support APIs like JAX-WS, JAX-RPC, JAXR, SAAJ, JACC, JAAS, JASPIC, JAXB, JCA, the Java EE Management Specification (JSR 77) and the Java EE Deployment Specification (JSR 88). As a result, we decided to continue to primarily focus on the Servlet API instead pursuing Java EE 5 compliance while still supporting the annotation-driven programming model in EJB 3/JPA as well as maintaining lightweight alternatives to RMI/CORBA such as Hessian.
With the Java EE 6 Web Profile, we finally feel confident that we can deliver a fully standards compliant version of Resin that is really on the mark in terms of features and usability. We believe the Web Profile enables us to create a very lightweight Java EE application server perhaps more compelling than any other server-side Java development option with a great “just-works-out-of-the-box” development experience.
Resin and Servlet Containers
While we are firm believers in lightweight development, we feel that taking the extreme approach of simply implementing the Servlet specification and nothing else is the wrong set of trade-offs to make. While this minimalist option seems good in theory, it quickly leads to a lot of easily avoidable complexity for a majority of cases. The fundamental problem is that modern web applications use a lot more than the Servlet API. In fact, there are very few non-legacy applications that use the Servlet API directly. Most applications need a transaction manager, persistence mechanism and higher-level presentation layer API, not to mention dependency injection, security, scheduling and crosscutting logic. Some applications also need support for messaging as well as remoting via an efficient binary protocol like Hessian.
As a result, development shops that go the plain Servlet engine route end up configuring numerous third-party APIs on top of the minimal container to get these features. Even while using the most efficient integration solution, configuring and maintaining these third-party APIs become tasks in their own right, especially compounded by the number of applications that need to be configured in an ad-hoc fashion. The complexity involved in such configuration tasks have very little to do with solving business domain problems. This development model is in stark contrast to platforms like Ruby on Rails which effectively promote ease-of-use and convention-over-configuration. Indeed we believe this development model is likely sensible only in contrast to using a full-scale Java application server that is very heavyweight or for systems that are really very specialized.
Besides development APIs, a vast majority of enterprise applications also need scalability features like resource/connection pools, security authentication providers, thread/process management, bandwidth throttling, caching, clustering and distributed transactions as well as management, monitoring and administration facilities. It is impossible or very difficult to add such features to a plain Servlet container as a third-party extension. Moreover, adding such foundational features on an a-la-carte basis takes away from the performance benefits to be achieved by having intelligent centralized coordination and resource sharing at the application server level.
Lastly, having a cohesive runtime that “just works” in a majority of cases allows us to create a simple vision covering all major application life-cycle stages including prototyping, development, testing, deployment, performance tuning, upgrades, maintenance and support, much like Ruby on Rails.
For these reasons, we believe a lightweight Resin implementation of the Java EE 6 Web Profile makes the right set of trade-offs by providing features that a majority of web applications need out-of-the-box, minimizing the configuration burden and focusing on ease-of-use.
The Resin Java EE 6 Web Profile Implementation
The basic Resin strategy to supporting the Java EE 6 Web Profile is to provide Caucho implementations for core APIs and integrate best of breed pluggable (but not invasive) open source implementations developed by other responsible, reputable organizations where it best makes sense. This strategy allows us to focus on delivering very high quality implementations where we can best add value to developers while not needlessly duplicating effort and leveraging the Java EE open source ecosystem in a sensible way.
In line with this philosophy, we are providing independent Caucho implementations for managed beans, interceptors, CDI, Servlet 3/JSP and EJB 3.1 Lite. Resin also includes its own high performance JTA compatible transaction manager, a very lightweight JMS implementation as well as the Hessian binary remoting protocol that offers better performance than RMI/CORBA and works over HTTP. Building on these core APIs, Caucho will integrate the reference implementations for JSF 2, Facelets, JPA 2 and bean validation.
Contexts and Dependency Injection
The Contexts and Dependency Injection for Java EE (CDI) API is one of the key parts of the Web Profile. It provides robust context management including support for conversations, type-safe next-generation generic dependency injection, stereotypes, interceptors, decorators, lightweight events as well as a powerful SPI intended for building portable extensions. As active participants in JSR 299, the Resin team played an important part in providing visionary support for the CDI API. We are very proud in offering a very high quality independent implementation of CDI. Our implementation, CanDI is one of the three major implementations of CDI, along with Apache’s OpenWebBeans and Weld, the reference implementation from JBoss. CanDI is the centerpiece for the Caucho implementation of the Java EE 6 Web Profile. Indeed, many parts of the Resin application server itself have been written using CanDI.
A number of possible additions to CDI are in the works via CanDI. For example, we are considering adding custom @TransactionScoped/@ThreadScoped in addition to the standard @ApplicationScoped, @SessionScoped, @RequestScoped and @ConversationScoped. We also plan to provide portable extensions for integrating popular open source and standard tools that developers would find useful. The possibilities include integration/ease-of-use CDI portable extensions for JMS, JDBC, JavaMail, Struts 2, Wicket, iBATIS and Quartz. We will also fully support all portable extensions developed by the Apache and JBoss CDI projects on CanDI/Resin. In the longer term, we plan to keep our eyes open on the Java ecosystem for other good candidates to create CDI portable extensions around as part of the evolution of the Resin community.
Servlet 3
Servlet 3 brings a major overhaul to this foundational Java EE API. The changes include full support for annotations, pluggable web.xml fragments, programmatic addition of Servlets, Filters, Listeners at runtime as well as asynchronous processing. While annotation support is geared towards ease-of-use and the asynchronous processing capabilities add better support for emerging paradigms like the real-time web, the rest of the changes are critical in improving pluggability for the rich set of third-party tools and frameworks that build on Servlets such as JSF, Facelets, Wicket, Struts 2 and the like. Taken as a whole, these changes will likely enable stronger innovation in the web tier based on the new capabilities in Servlet 3. We have long focused on excellent support for the Servlet API and will continue to do so with Servlet 3. In fact, it is one of our first APIs to get certified against the official compatibility test kit.
EJB 3.1 Lite
EJB 3.1 has both further ease-of-use elements as well as core features frequently requested by developers. The changes include session bean optional interfaces, singleton beans with concurrency control, cron-style declarative and programmatic timers, asynchronous bean invocation, support for packaging EJBs in WARs, embedded container support for unit testing, standardized global JNDI naming as well as the definition of EJB Lite. In addition to basic support for EJB Lite, Resin will include support for EJB scheduling (@Schedule, @Timeout), asynchronous processing (@Asynchronous), message driven beans (@MessageDriven) and Hessian based remoting (@Remote).
In our view, one of the most important changes in EJB 3.1 is the redefinition of EJBs as simple managed bean POJOs with additional services. We have taken this realignment to the logical next step by allowing developers to use EJB annotations in CanDI managed beans in addition to EJBs including the @TransactionAttribute, @Schedule, @Asynchronous, @RolesAllowed, @PermitAll, @DenyAll, @RunAs, @Lock , @Startup and @Remote. Here are a few examples of this capability:
@TransactionAttribute(REQUIRED)
public class BidDao {
// Resin thread-safe EntityManager proxy.
@PersistenceContext
private EntityManager entityManager;
public void addBid (Bid bid) {
entityManager.persist(bid);
}
}
@ApplicationScoped
public class NewsLetterGenerator {
@Schedule(dayOfMonth="L", month="*") // Last day of every month.
public void generateMonthlyNewsLetter() {
// Code to generate the monthly news letter goes here.
}
}
Unit Testing/Embedded Containers
Resin aims to provide excellent out-of-container unit/integration testing support for both JUnit and TestNG. Testing support will be based on the Resin embedded container built around CanDI. Using JUnit and TestNG bootstrap mechanisms, the Resin test tools will inject components under test directly into testing artifacts that can be run from the command-line or IDE. The following code example shows these capabilities:
// Deployment overrides for the test.
@ResinBeanConfiguration(beansXml="beans-test.xml")
public class AccountServiceTest {
@Inject
private AccountService accountService;
@Test
public void testGetAccount() throws Exception {
Account account = accountService.getAccount(1007);
assertNotNull(account);
}
}
Hessian Remoting
Hessian is an HTTP based binary communication protocol developed by Caucho. Hessian offers better performance than RMI/CORBA, SOAP or REST. Since it is HTTP based, it can work across firewalls much like web services. Because of these characteristics, we believe it is the ideal communication protocol for remoting using Resin and Java EE 6. Resin supports Hessian remoting through the EJB @Remote annotation as in the example below:
public interface BidService {
public void addBid(Bid bid);
}
@ApplicationScoped
public class DefaultBidService implements BidService {
…
}
Spring Support
A large number of Resin customers currently use the popular Spring framework and we have a high degree of respect for the Spring user community. We have always provided and will continue to provide excellent runtime support for the framework. Indeed, we believe great opportunities for even better Spring framework integration exist particularly via the common Dependency Injection for Java (JSR 330) annotations shared by both CDI and Spring IoC. We will explore such innovative integration possibilities going forward through the Resin Java EE 6 Web Profile implementation.
We look forward to your support, feedback and comments on these efforts as we work through the next few months of a promising new year for Resin.
Tags: candi, cdi, ejb 3.1 lite, java ee 6, resin 4.0, servlet 3, web profile
March 11th, 2010 at 11:20 pm
[...] were hopeful that other vendors will start supporting Java EE 6 soon. For the record – Caucho, Geronimo, JBoss, and WebLogic have announced plans to be Java EE 6 [...]