Views on the Industry

Java Implementations (1/2/4)

Design Patterns
The single most important development in the Java community, and for the Java Economy, has been the work done on Design Patterns. Initiated within Sun's Java Center group of professional services expertise, the Design Patterns are the base for J2EE applications. There is no other starting point that produces so great an ROI as has been created in the Patterns that span presentation tier, business logic tier, and integration tier. For customers that have utilized the Design Patterns, they are in a comfortable position to begin making architecture decisions for the implementation of Java web services.

Pre-built components
With the introduction of pre-built applications, customers now have the capability to dramatically reduce development time, while also standardizing implementations according to industry best practices. The Theory Center was a Java start-up that introduced the concept of pre-built J2EE components to be utilized with app servers. There were several additional component start-ups, including companies like Flashline that offered component repositories (http://java.sun.com/features/2001/03/ejb.html), and there was great promise to a component marketplace. Why did this never materialize? For one, the standards were new, and customers were mainly using app servers for non-component development. Theory Center was acquired by BEA, which transformed the product-line in to a larger packaged application, as opposed to offering discreet components. That was too much for BEA, for this strategic oversight opened the door to low-end competitive offerings that did not have the resources to build their own component solution set. BEA and Gartner began to sell the vision of an application platform suite that has still yet to materialize (remember this, JBoss). Meanwhile the initially successful methodology of selling component solutions with the core app server became an afterthought, or it would be assured that customers would be responsible to build their own set of components.

While this was certainly a model that BEA's most advanced customers were to follow, drawing from their larger J2EE developer organizations, it left for all other customers to fend for themselves in developing J2EE. IBM's answer to this problem was not the continued development of the San Francisco components, but rather was simply to re-invest in Global Services expertise to build components for customers per engagement. There can be no doubt tht IBM has built a sizeable database of reusable code, but nothing that has been put in the hands of developers. The J2EE developer community is thus faced with a world of platforms and very limited resources dedicated to applications, and the building blocks components. What was once the direction of the J2EE market, has now turned in to a build it yourself mentality that needlessly replicates the same code over and over, even among the same development teams.

For if J2EE is truly to stand on its own or go head-head with .Net, the developers need to be equipped with everything the J2EE platform has to offer. This means that the current app server market will need to become a much larger J2EE marketplace filled with reusable components accompanying best practices. Only when J2EE is sold with applications will it become a Java Operating System, capable of taking on the Windows estbalishment.

posted by douglas dooley @ 8:56 AM