The catalyst for the debates was Microsoft's .NET platform for developing and deploying Web services. While Sun won't admit it, Microsoft's leadership on standards such as Extensible Markup Language (XML) and Simple Object Access Protocol (SOAP) is changing the way in which many developers are integrating their information systems. Two years ago, the standard wisdom was to recode those systems in Java or wrap them in Java object containers. Today, standards such as XML and SOAP allow objects written in many languages to find each other across networks, describe what they do, and invoke each other. By championing these standards via .NET, Microsoft could relegate Java to being just another programming language rather than the integration and portability platform it has become.
In response to this threat, many vendors used JavaOne to announce or showcase Java tools with support for Web services technologies. IBM, for instance, demonstrated the Web services capabilities of its newly announced Version 4.1 releases of WebSphere Application Server Enterprise Edition and WebSphere Studio Application Developer. The products allow developers to visually compose Java 2 Enterprise Edition (J2EE) objects, publish them as Web services, and then link J2EE and non-Java objects via a drag-and-drop interface using the J2EE Connector Architecture (JCA). At present, these particular Web services capabilities aren't supported on any iSeries release of WebSphere Application Server. However, IBM sources are indicating that they will be supported on the iSeries in WebSphere Application Server 5.0, which will ship sometime during the third quarter of this year.
Not to be outdone, Sun announced new versions of its Forte line of development tools that incorporate a Web services module that the company posted on its Web site several months ago. Among other features, the module includes wizards that let developers easily define SOAP interfaces to Enterprise JavaBeans (EJBs), then generate XML documents that define the EJBs as new Web services. The XML documents comply with the Web Services Description Language (WSDL) that IBM and Microsoft have promoted as an industry standard.
While Sun, IBM, and other vendors tried to present a united front on Web services support, they couldn't cover up the fact that they are implementing that support using somewhat different technologies. As a result, you could use WebSphere Studio Application Developer to publish a Java object as a Web service, then find that it can only run on WebSphere Application Server--not on other J2EE-compliant application servers. The same scenario could apply to Java tools and application servers from BEA, Sun, Oracle, and other vendors. In short, today's Web services implementations have the potential to make Java's promise of "write once, run anywhere"--a promise that is already frayed at the edges--even less of a reality.
Such fragmentation is what Sun's Java Community Process (JCP) is designed to counter. Indeed, Java developers were anticipating that the JCP would publish Web services standards by the end of this year. Just before JavaOne, however, sources within Sun admitted that the release date for J2EE 1.4--the release that will specify how Web services are implemented in Java--has been pushed into the first quarter of next year. While the delay isn't stopping Java vendors from implementing Web services into their products, it is putting off the day when those implementations are truly portable. That gives Microsoft more time to advance the .NET development platform as the only one that supports Web services in a consistent manner...albeit on Windows servers only.
In the face of these developments, it is important for iSeries users to understand where IBM stands on the Java and .NET platforms. While the computer giant has been a vocal advocate of Java since its inception, its actions demonstrate that, unlike Sun, it has no ideological commitment to a single development platform. IBM is committed to whatever technologies it can use to integrate its own software portfolio--both internally and with the enterprise applications that its customers are choosing. That commitment has led it to work closely with Microsoft on XML-based Web services specifications that the two companies have submitted to standards bodies. Sun has chosen to not participate in these efforts and is clearly concerned over IBM's involvement with its archrival.
What conclusions should iSeries users draw from these developments? First, understand that Web services technologies are still in their infancy. If you use them to link objects inside or outside your enterprise, expect that you'll be revising those links until the underlying standards become stable. That doesn't mean you should avoid Web services; however, think twice about using them if the financial benefits won't outweigh the added maintenance headaches.
Second, realize that Java vendors may not fully embrace standards for implementing Web services for some time. In particular, IBM and Sun may find it hard to find common ground. IBM was slow to adopt the J2EE standard initially because some of its middleware technologies were excluded from the specification. In a similar manner, the computer giant may drag its feet on J2EE 1.4 compliance if Sun refuses to let the release support the XML standards that IBM is developing with Microsoft.
Finally, rest assured that IBM and the rest of the Java community will eventually settle on Web services standards. Why? Because if they don't, enterprise software vendors and developers could start switching to .NET running on Windows servers. That would erode IBM's substantial market share of key product categories such as servers, systems software, and middleware. Faced with such a prospect, the company would rather mend fences with Sun than concede industry leadership to Microsoft.