Richard Monson-Haefel's Blog

December 2003 Archives

What's Richard Monson-Haefel up to in 2004?

So what's next? I've wanted to write a book on J2SE for a couple of years, but since this space is already crowded I've put it off. Recently, however, I've decided to test out some material for such a book - I may post it on the Internet. The purpose of the book, tentatively titled This is Java, is to explain how Java works under the hood. If all goes well, the material will be easy to read and accessible to intermediate developers and Über-wonks alike.

In addition to working on This is Java I'm going to be very involved in the JCP Executive Committee this coming year. There are a lot of specs going through the process now and probably a lot more to come, so this will take up a fare amount of my time. I'm also working on JSR-220 (EJB 3.0) and the Apache Geronimo and the OpenEJB projects. Of course all these efforts are more or less philanthropic since they don't pay cash. To earn a living I'll be spending about 20 hours a week consulting and/or doing some training – nothing solid to report on that end yet.

Explicit vs. Implicit Programming Models for J2EE

An explicit programming model, by my definition, is one that reflects the complexity of the underlying system by offering developer very precise fine-grained control. An example of an explicit programming model is EJB, which gives developers a lot of control over how enterprise beans interact with their container system and serve requests. EJB is explicit, because it exposes a lot detail about the underlying system to the developer. An explicit programming model like EJB offers developers a lot of control, and therefore flexibility, but at a cost. Explicit programming models tend to be complex and difficult to master.

An implicit programming model, also by my definition, is one that hides the complexity of the underlying system. I can't think of any good examples of implicit programming models in J2EE today. All the standard J2EE APIs are pretty much explicit. Something that comes close, IMO, is the JAX-RPC Service Endpoint (JSE) component, which is really just a POJO (plain old Java object). The JSE allows you to develop sophisticated Web services but doesn't require familiarity with SOAP, http, or even the Servlet APIs. Its not prefect: You still have to know about the JNDI Environment Naming Context to do something useful, but it’s a start in the right direction.

Personally, I would like to see all of the J2EE components and APIs offer a simpler, optional, programming model. One that can be easily mastered by novices but allows users to incrementally leverage more sophisticated features as needed.

IBM and BEA: Are they thumbing their noses at the JCP?

The Java Community Process (JCP) is designed to facilitate the creation of standard, vendor-agnostic Java technologies. This is my quick and dirty definition, the keys to which are the words "facilitate" and "vendor agnostic". The primary objective of the JCP is to provide a framework for defining Java standards. In most cases, an expert group develops the standards based on a set of objectives defined by the proposed JSR (Java Specification Request). In other words, usually the specification is grown from scratch under the auspicious of the JCP. This, however, is not a requirement. The actual specification can be grown from scratch (e.g. JSP, JSF, EJB, etc.), based on established non-JCP standards (e.g. CORBA, DOM, SAX, ext.), or an existing implementation or architecture as is the case here. It really doesn't matter very much as long as the JCP accepts the JSRs, approve their progression through community and public drafts, and endorses the final specifications. The bottom line is that the JCP is not supposed to stifle the development of specifications seeded outside of the process - to the contrary. If leading vendors want to hammer out the details before beginning a JSR, then so be it. Who cares how it got started?

Contrary to what my friend from Microsoft Land may say, the JCP is not doomed to obsolescence – not by a long shot. The truth is, IBM and BEA need the JCP. Neither of these companies could go it alone, outside the JCP. For example, before EJB/J2EE, both IBM and BEA marketed proprietary server-side component models. IBM's was called Component Broker and BEA's was called M3 (a.k.a. Ice Berg). Both vendors abandoned their proprietary architectures in favor of Enterprise JavaBeans. Why? Because their customers had more confidence in standards based solutions than proprietary ones. It’s the money that talks, and the money (customers) prefers standards to proprietary solutions. That hasn't changed and since IBM and BEA are not a standards organization, they will always need the JCP – or something like it - to manage the standards on which their products are built.

A little history illustrates the necessity of a standards organization like the JCP. In the mid to late 90's CORBA, not J2EE, was the leading application server standard for non-Microsoft vendors. The OMG defines the CORBA standards and initially vendors fell in line with those standards. But after Visigenic and IONA emerged as the market leaders (not unlike IBM and BEA today) they became more antagonistic toward the OMG. Now to be perfectly honest, I think the OMG was getting a little carried away, but that doesn't change the outcome. IONA and Visigenic thumbed their noses at the OMG to their own undoing. Where are Visigenic and IONA today? Are they still the major players? No, I'm afraid not. They've become minor players in the J2EE market. EJB and J2EE came along and everyone – vendors, customers, and developers – jumped the CORBA ship and went to J2EE. J2EE is the centerpiece of server-side products in Java Land because it’s a vendor agnostic standard that vendors respect and follow. IBM and BEA know this and are not eager to repeat the mistakes of their predecessors. They will continue to work with and conform to the requirements of the JCP. If they don't, J2EE will be lost and so will IBM's WebSphere and BEA's WebLogic.

This work is licensed under a Creative Commons License.