IBM, BEA join on Java strategy

IBM and BEA Systems, usually staunch rivals, are collaborating on ways to smooth out technical differences between their respective Java software lines.

The two companies on Tuesday announced that they have published specifications for three additions to their products that would make it easier for customers to run programs on their respective Java application servers. The changes are expected to be fully implemented within BEA's WebLogic and IBM's WebSphere in the next major release of their products, both due next year.

		Get Up to Speed on... Web services Get the latest headlines and company-specific news in our expanded GUTS section.

IBM and BEA will submit the specifications to the industrywide Java standardization effort, called the Java Community Process, and will make the guidelines available to other companies without charging royalties, the companies said.

The two companies, which are in a battle for the top spot in the market for Java application servers, have already collaborated on other technical specifications in Java as well as Web services standards. IBM and BEA garnered about two-thirds of the revenue for Java application servers in 2002, according to market researcher Gartner Dataquest.

Executives from both companies said that the effort to create more common technical underpinnings for their Java server software was in response to requests from customers and independent software vendors (ISVs).

"We faced feedback, especially from ISVs, which (were less interested) in new features that are WebLogic-specific than ones that were common with WebSphere," said Scott Dietzen, chief technology officer at BEA. "This bridging strategy allows us to get common technology and certainly make it standard over time."

The Java 2 Enterprise Edition standard is designed to allow customers to run Java applications on application servers from any provider. But in practice, there are significant differences between products. ISVs, for example, generally create a version of their add-on products, such as performance-tuning tools, for both IBM's WebSphere and BEA's WebLogic.

The common tools will make it simpler for a company to write software that runs on either application server and will give ISVs an easier and quicker way to build add-ons for both products, executives said.

The three technical specifications are these: Service Data Objects, which provides a common way to pull data from multiple data sources, such as Extensible Markup Language-based file systems and relational databases; Timer for Application Servers, a mechanism for scheduling processing jobs; and Work Manager for Application Servers, for setting up processing tasks in parallel.

IBM plans to implement the specifications in the next major release of WebSphere, which is due next year, said Rod Smith, vice president of emerging technology at IBM's software group. IBM expects to release a developers kit for Service Data Objects next week.

One analyst said that the collaboration between IBM and BEA is notable for its exclusion of Sun Microsystems. Java steward Sun directs the Java standardization process and controls the Java brand, but with only single-digit market share, Sun's Java server products lag behind BEA and IBM significantly, according to Gartner Dataquest numbers.

"You could say this announcement is the beginning of the end of Sun's leadership in the Java space, as the two market leaders are now collaborating explicitly on driving the direction of Java," said Jason Bloomberg, an analyst at research firm ZapThink.

In a statement, Sun on Tuesday applauded the IBM-BEA joint effort and noted that several Java standardization efforts have originated at companies other than Sun.

IBM's Smith emphasized that the three specifications will be submitted as Java Specification Requests, or JSRs, which are then developed into standards through the Java Community Process. Java standardization efforts typically take about 18 months.

"Each of these areas doesn't have a direct parallel (in the JCP). They are very natural JSRs and in no way are we suggesting an alternative to the Java standards approach," Smith said. "Getting them into the JCP is the next step and getting the broader community to adopt them."