Pruning The Deadwood from Java EE

Posted by Charles Humble on Apr 07, 2009

Sections

Development,

Enterprise Architecture

Topics

Enterprise Application Blocks ,

Java

Tags

Java EE

A key reason for the success of the Java EE platform is its breadth of coverage, however the number of APIs and technologies that make up the specification also create issues for both developers and vendors wishing to adopt it. For new vendors wanting to build a Java EE application server, the complete specification represents a substantial barrier to entry reducing competition in the space. For new developers coming to Java EE, the vast numbers of APIs and acronyms can be intimidating. This is one of the reasons Java EE has a reputation for complexity, but it also means that new developers looking at the the platform don't always realise that it is as well suited for developing simple systems, such as basic CRUD web applications, as it is for building much more complex ones. One of the stated goals of Java EE 6 is to tackle these issues using three different techniques - profiles, pruning and extensibility.

Profiles may either be a subset of Java EE platform technologies, or additional JCP technologies not part of the base Java EE platform, or both. They are helpful to a vendor since they provide a lower entry point for producing a Java EE compliant product, and are also useful for a developer looking to get started with the platform. As well as formalising this concept for enterprise Java, Java EE 6 introduces the first Java EE profile, the web profile, which was looked at in detail in a previous InfoQ article.

Java EE 6 also starts the process of removing APIs that have been superseded or seen low levels of adoption amongst vendors and developers - a process referred to as pruning. It is performed as a multi-step process where a candidate is declared in one release and marked out as such in the Javadoc. Then, depending on community reaction, it may subsequently be relegated to an optional component in the next release.

The early draft review of Java EE 6 suggested two pruning candidates. The first was JAX-RPC [JSR 101, the Java APIs for XML-Based RPC], which defines client APIs for accessing SOAP web services via RPC as well as techniques for implementing web service endpoints. JAX-RPC suffers from a number of limitations, notably that neither web service annotations nor injection are supported for JAX-RPC service endpoints and handlers. The API was effectively superseded by JAX-WS with the release of Java EE 5. The second pruning candidate in the early draft review was JAXR [JSR 93, the Java API for XML Registries]. This provides a standard way of accessing different kinds of XML registries for building, deploying and discovering Web Services and includes bindings for both the ebXML Registry and the UDDI Registry v2.0 specifications. JAXR hasn't been superseded but has seen very limited adoption.

The public draft review of EE 6 has added two more APIs to the pruning list. EJB 2.x Container Managed Persistence which is now effectively replaced by the Java Persistence API [originally defined as part of JSR 220, Enterprise JavaBeans 3.0] and Java EE Application Deployment [JSR 88] which defines the interfaces between the run-time environment of a deployment tool and plug-in components provided by a Java EE application server. This API theoretically allows any Java EE application to be deployed into any Java EE compatible environment using the same deployment tool, but regrettably has been poorly supported by vendors.

In a similar vein to JSR 88, the Expert Group is also considering removing Java EE Management [JSR 77] which provides APIs for management tools to query a Java EE application server to determine its current status, applications deployed, and so on. Server management tools built using these APIs work in a cross-vendor manner providing system administrators with a means to switch application servers without changing management tools and processes, or to manage a network of multiple Java EE servers consisting of multiple vendor implementations of the platform. Like JSR-88 this API has suffered from poor vendor support.

As the APIs are trimmed down, the Expert Group hopes to reduce the need for APIs that may have limited appeal by providing more extensibility points within the specification. These interfaces and plug-in points should make it easier to create technologies that extend that platform whilst remaining well integrated into it, and may help the specification itself regain some of its focus.

• Older >