The Java camp patted itself on the back yesterday, holding a coming out party for the almost two dozen vendors whose products just won J2EE 1.3 (Java 2 Enterprise Edition) certification. Among the highlights of J2EE 1.3 are new connectivity standards for application, messaging, and XML web services integration.
In between the lines, however, questions emerged on whether the Java Community Process (JCP), which controls standards development, could fragment. So far, the JCP has shown remarkable cohesion, in spite of IBM’s worries that Sun was pulling a few too many strings. And, aside from Microsoft, which withdrew from Java by mutual consent, and some clean room experiments by HP, nobody has successfully engineered a different Java.
But could the JCP’s broad mission prove too much of a good thing? As long as the JCP limits itself to “plumbing” functions that lack intrinsic value, it’s on safe ground. Messaging extensions make sense, but APIs for business workflows? They’re another question.
Another pitfall: as the agenda grows too broad, it might grow overcautious. For instance, in tackling SOAP (an emerging, simplified messaging protocol for XML web services), the JCP lumped it under an umbrella spec covering all “on-the-wire protocols.” Are we getting as complex answer to a simple problem, and consequently, is that slowing down the standard process?
Some Java community members are already taking the law into their own hands. Last month, IBM and HP announced UDDI4J (UDDI, a web services registry, for Java) to provide a quicker alternative to the proposed official JAXR spec, which would cover registries of all types.
We don’t know how far left-field responses like UDDI4J will go (even IBM’s representative at the J2EE event yesterday hadn’t heard of it), but they should serve as a wake-up call to the JCP to place realistic boundaries on its mission.