Will Sun be the ONE for Web services?
Concentrating on B2B infrastructure, Sun is working hard to add Web services to its Java platform and its own iPlanet products.
Several Sun products and third-party tools now make it possible to build and deploy Java-based Web services. You can expect the company to add XML and Web service APIs that will become standard equipment in its Java platform within the next year and a half.
In the meantime, Web service support for the established J2EE standard comes in the form of downloadable add-ons, iPlanet products, and third-party tools. The new Microsoft .Net Framework is still in beta, but Sun's Java platform is over five years old. By any measure, the Java platform (and programming language) is a real computing success story.
Currently, a wide range of application servers support the J2EE 1.3 standard, including BEA, Borland, IBM, and iPlanet (Sun's application-server product wing). For open-source aficionados, there's even the free JBoss application server.
Java runs in a virtual machine that provides a robust set of APIs and protects programs through garbage collection. There's an abundance of cross-vendor support from companies like BEA, Borland, IBM, iPlanet, and WebGain for any shop that commits to Java.
With the arrival of Sun's HotSpot compiler technology in the Java 2 JDK 1.3, Java performance has arguably been raised a notch--while .Net performance remains an unknown.
Not just Java
Sun ONE includes more than just Java; it combines support for J2EE, XML, LDAP, and a Web services API.
The J2EE standard is still the core of Java enterprise computing. With over 5,000 Java runtime classes available, J2EE includes support for a handful of APIs for building Web applications.
Strengths include database support, EJBs (Enterprise JavaBeans) for building business components that work with databases, and JSPs (Java Server Pages) and servlets for creating dynamic Web applications.
Other supporting-cast standards bundled in J2EE include JNDI (Java Naming and Directory Interface) for naming and directory services, JMS (Java Message Service) for messaging, Java RMI (Remote Method Invocation), and JDBC (Java Database Connectivity) for database programming.
To some extent, the shift from J2EE to Web services simply means using different APIs to accomplish the same tasks at a more universal level. For instance, in Web services, SOAP and XML are used instead of Java RMI to send data between networked applications. Similarly, UDDI is used instead of JNDI to look up and manage remote services or objects.
Thanks to Sun's stringent certification program, switching among J2EE application servers without significantly rewriting your code is fairly easy. Compared with older standards (notably CORBA), this option has become a lot more manageable with J2EE. No matter how you slice it, the cross-vendor support for Java is miles ahead of Microsoft .Net.
Although Java has never been a W3C standard, its growth is managed by the JCP (Java Community Process), which allows multiple vendors--guided by Sun--to design new APIs and features. The new Web service standards have sent the JCP into high gear. For example, the current J2EE 1.3 standard doesn't yet have XML or Web services built in, as .Net does.
Currently, Java developers must add XML support with the Java API for XML (JAX) Pack, a free download. Sun plans to include XML parsing in the next version of the J2EE 1.4 standard, but evolving XML standards will mean multiple downloads.In addition to the parsing, Web service APIs will be added to J2EE 1.4 in late 2002, with tool and application server support coming shortly thereafter. New JAX Packs will debut in early 2002, adding more direct support for Web services. At press time, only the basic JAX Processing (JAXP) was available. But the APIs planned for the future include those for XML Messaging (JAXM), which will interface with XML-based RPC, including SOAP, and Java API for XML Registries (JAXR) for registering and discovering Web services.
Of course, these Java implementations will work with the underlying open-source standards (SOAP and WSDL), but they offer higher-level APIs to save development effort.
In the meantime, Sun is working with tools vendors to ensure that it's possible to create Web services with minimal developer hassle. Though the brand-new .Net includes more support for Web services in its CLR runtime engine, real Java tools and support for Web services are shipping (even if they won't officially be part of Java until 2002).
Java's Web service support comes in products such as application servers from IBM and iPlanet. To these standards, the Sun ONE platform adds ebXML, an e-business specification that builds on SOAP to include support for transactions using JavaBeans. Any setup requiring multiple components and transactions can take advantage of ebXML as an option where simple SOAP leaves off.
Sun ONE products
Sun's initial Web service focus will be on B2B, including corporate portals and integration of large organizations (such as supply-chain vendors).
Don't look for consumer Web services like Microsoft HailStorm; Sun is planning to deliver a platform that allows businesses to create their own Web services. One exception to this is Sun ONE Webtop--a Web services version of StarOffice.
The iPlanet Integration Server, B2B Edition (US$40,000 per CPU), has recently been improved with support for Web services. This product (a counterpart to Microsoft BizTalk Server 2000) can integrate disparate systems through XML. It adds SOAP support, as does a new version of iPlanet Application Server (Enterprise Edition, US$19,995 per CPU). Supporting products include a messaging server, iPlanet Message Queue for Java (US$4,000 per CPU).
The corporate portal is an important focus for Sun's strategy.
The company expects Web services to be used for security and role-based personalization in iPlanet Portal Server. This sounds similar to Microsoft Passport in that Web services will be used to authenticate and personalize content. But for Sun, identities and preferences might be maintained in corporate LDAP directories at first, rather than UDDI, which will be used in the mid- to long-term future for locating and describing Web services.
Sun expects LDAP to be even more critical in the short term, as corporations strive to integrate their own organizational data stores and with those of trading partners.
For developers, Sun's Forte for Java, Enterprise Edition, an integrated development environment, has recently been Web service-enabled, with wizards to automate the creation of XML (see story, "Tools for building Web services").
The company is also working with third-party Java tool vendors, such as Borland, IBM, and WebGain, to ensure that Web service wizardry is bundled into future Java tools.
Sun's Java platform has already overcome many of the problems of effective distributed computing. The company's vision of network computing would seem to be a natural fit for the brave new world of Web services. In this view, they're more evolutionary than revolutionary.
Thanks to a quick response from its partners, there's every indication that the Java platform is ready to roll with Web services. Understandably, it will take about a year for XML and SOAP APIs to appear in the J2EE standard.
In the meantime, IT shops running Sun ONE can choose Java-enabled iPlanet and third-party tools to move forward with Web services without a huge investment in developer expertise.
The bottom line is that no developer will have to write those XML SOAP wrappers by hand. And as new APIs make their way into Java in 2002, it should become even easier to develop Web services on the Sun platform.