The Profile Story
Introducing the Java EE Web Profile
Introduced in Java EE 6, the Web Profile radically streamlines the platform and enables the creation of a new dawn of lightweight, agile, compelling application servers with a laser focus on web application development. In this article, we will discuss what the Web Profile is, what it contains, why it is so empowering, give you a quick tour of the profile and tell you about the application servers – currently available and upcoming – that implement the Web Profile.
Much like other mainstream development platforms like Microsoft .NET, Java EE attempts to provide a comprehensive runtime covering as many server-side application use-cases as possible. As a result Java EE has had an ever-expanding set of APIs gradually added to it over the years. The problem is that until the introduction of Profiles, Java EE has also been a monolithic API set. This one-size-fits-all approach has meant that most applications do not use a significant 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.
Similarly, SOA centric “headless” applications might use features like messaging, remoting, SOAP and REST but have no use for JSF or JSP. The heavyweight feel of application servers that implement the entire Java EE API set is a symptom of this underlying problem (although this is not the only source of the problem; some commercial offerings have now become notorious for adding extraneous “enterprise” bells and whistles beyond Java EE to their platform that approaches the magnitude of gigabytes!). This “heaviness” often manifests itself as large download sizes, convoluted installation, slow startup/shutdown times, large runtime memory footprint, slow deployment, elaborate management consoles and sluggish administrative responsiveness.
Profiles in Java EE 6 are aimed at this problem by defining sub-sets of APIs geared towards particular types of serverside applications (it is also a not-so-subtle hint to some implementers that “enough is enough”). Following the previous examples, profiles geared towards web applications or SOA applications might make sense. The Web Profile is the first and only profile defined in Java EE 6 (the expectation is that other profiles will be defined going forward as needed).
Inside the Web Profile
The Web Profile is composed of a complete set of Java EE APIs that is needed for a majority of modern web applications. This includes APIs for the presentation tier, business tier, persistence tier, transactions, security, dependency injection, cross-cutting logic, constraint management and testing. Table 1 outlines the specific APIs included in the Java EE 6 Web Profile.
Note the Web Profile includes EJB Lite, not the full EJB API. Like profiles, EJB 3.1 Lite is a sub-set of the full EJB API intended specifically for web applications. 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 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. Table 2 shows features in the EJB Lite vs. full EJB API.
The Java EE 6 Web Profile leaves out a number of APIs that are not used frequently 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). The Web Profile also only includes support for WAR files and not EAR files.
Note profiles do not stop a vendor from adding APIs and features as they see fit. For example, as I'll discuss shortly, Resin adds support for JMS, EJB scheduling, asynchronous processing, message driven beans and remoting.
It's Always about the Tradeoffs
As you can see, the Java EE 6 Web Profile is all about trade-offs and those trade-offs were not easy to decide on. Adding redundant APIs would mean making the profile less streamlined. Missing frequently used APIs would mean leaving obvious gaps that Java EE developers would have to fill themselves (likely by integrating third-part APIs) – taking away from the Java EE promise of standardization, portability, vendor-neutrality and providing a platform that trends towards zero configuration so that developers can focus on application-level development concerns rather than system-level configuration concerns.
Ultimately, the overriding motivation was making the Web Profile as small as possible by focusing on the 80% web application use-case. Particularly tough were the decisions on whether or not to include JavaMail and JAX-RS. Similarly it was difficult to decide whether or not to include JCA for greater vendor pluggability. In some ways, the Web Profile gets rid of the cruft that has built up in Java EE over the years and paves the way for a next-generation of lightweight Java EE application servers. In fact, for the Resin team, it raises the question of whether full profile application servers have a significant place in the server-side market any more.
The flip side of the profile story is whether it compromises flexibility – so what happens when you want to use APIs outside the Web Profile? There are three answers to this question. The first is that the vendor you are using may provide you a smooth upgrade path by providing the additional APIs in a transparent, pluggable fashion. As we will discuss shortly, the OSGi based GlassFish Web Profile server is a great example of this. The second answer is for you to choose a vendor that ships with the additional APIs you need (remember that the vendors can add whatever APIs they want beyond the Web Profile). The last and probably the most unlikely option is to simply switch application server implementations.
Another facet of the profile debate is whether or not to simply have a profile with the Servlet specification and no other Java EE APIs. While this option might seem compelling in a Zen-inspired minimalist sense, 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 and crosscutting logic. As a result, starting with a plain Servlet engine necessitates 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. In reality the configuration task is really the domain of an administrator or integrator working at the system level rather than a developer working at the application level. This complex development model is in stark contrast to platforms like Ruby on Rails which effectively promote ease-of-use and convention-over-configuration. Indeed 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. This is also an approach that has the most potential to severely limit standardization and vendor-neutrality.
- Inside the Web Profile
- A First Taste