HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
Who Will Be King of J2001?

Lately I've received a number of e-mails and had conversations regarding J2EE compliance and what it means to the industry. Each conversation or message has a slightly different slant depending on whether the person on the other end is a vendor or a reader or a colleague. What almost everyone seems to agree on is that the J2EE standard has done more to create a basic parity among vendors than any other event in the short but colorful history of Java.

Parity excites end users (in this case developers or IT departments) and depresses vendors. IT departments love the portability of J2EE because it allows them to move from one vendor to another as they see fit. Vendors dislike parity because it reduces their ability to charge premiums – they're selling a commodity.

To avoid the commodity problem, vendors naturally attempt to differentiate themselves from one another by providing additional features and new functionality. With J2EE this is a complex task and one fraught with danger. Yet there are several areas where vendors can add value without necessarily forsaking compliance with the specification. It's this differentiation that in fact will drive IT users to move from one implementation to another as they look for specific features. In a sense, the very cause of commoditization is also the driver behind specialization.

I see a number of areas that vendors will be likely to address as they begin the process of differentiating themselves. For lack of a better name I've termed this J2001 – next year's J2EE. This has nothing to do with the EJB 2.0 specification or anything else official: it's my own word. What follows is my view of what's likely to be used to sell products in 2001.

Clustering capabilities will be highlighted as vendors continue to push on the topics of reliability, availability and scalability. Some vendors are pursuing multiple VMs running on a single machine (or processor) as a way of achieving better clustering. Others are clustering at the machine level. I expect major players in the industry to have a clustered solution and for them to beat on each other about which one is best. I wouldn't be surprised to see integration of hardware clustering solutions as the logical next step in the quest for speed and scalability.

Personalization services will become a hot topic. Let's face it – the Web abounds with personalized sites. The integration of personalization into product offerings will be another area where vendors begin to establish dominance. The degree of integration and flexibility of personalization will be vital in determining the best solution.

Closely aligned with personalization but truly another topic is the idea of business rules engines. Such engines already exist as stand-alone products, and several vendors have either written their own or integrated them into their products as add-ons. I expect the critical factor surrounding this area to be the ability to define rules that affect and are aware of EJBs. Another key to success will be the ability to provide a rules interface that business users, not IT technicians, can understand.

Integration into systems management systems such as Tivoli, Unicenter or OpenView will also be a key consideration as large IT organizations begin to demand greater control of J2EE services from network management consoles.

Transaction/commerce engines will also become a key factor. The whole point of EJB is to do transactions. But, from the EJB perspective, this is a somewhat artificial, programmatic transaction. From the B2B or B2C standpoint a transaction involves the exchange of cash or other valuables. Commerce engines already exist, and many of them run on EJB servers. Look for vendors who have commerce offerings to extend their product, and for vendors who don't, to seek partners to provide this necessary functionality. I see 2001 as the year that commercially available negotiation (not auction) engines finally hit their stride.

I could go on, but this list is probably big enough. Every project I see these days asks questions along these lines. It's the answers to these questions that will decide who will be king of J2001.

Author Bio
Sean Rhody is editor-in-chief of Java Developer's Journal. He is also a respected industry expert and a consuitant with a leading Internet service company. He can be contacted at: [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.