Differential Calculus
Java platform players jockey for position to stand out in the Web services crowd
by Paul Kapustka
Even as they work together on defining the XML-related standards that unite them, major application server and development-tool vendors in the J2EE market are already mapping out ways to gain a competitive edge on each other in the nascent market for Web services.
The latest in a long line of "Holy Grail" paradigms that hold the promise of application interoperability, Web services are already having a greater impact than many of its predecessors, in part because much of the infrastructure—in the form of Internet XML protocols—is already in wide use.
Though the Java Community has not yet agreed on a standard package of technical underpinnings for Web services, all of the major vendors in the space are paying lip service to the imminent arrival of an initial package that adds standardized support for some basic Web service technologies such as Simple Object Access Protocol (SOAP) and HTTP.
But even as they unite under the Java banner—in no small part to gain some leverage against their common foe, Microsoft—J2EE players IBM, BEA, Sun Microsystems, and Oracle, as well as Borland, IONA, Macromedia, and others are scrambling to convince users that their stepping stones should be the first ones that users take down the Web services path. These efforts sometimes come with claims that seem to undermine Java's historic interoperability attractiveness.
Evolving the Standard
One thing that all J2EE vendors agree on is user desire for fully defined Java specifications for Web services, a project that is currently proceeding forward on two intertwined fronts. One is the IBM-led Java Specification Request (JSR) 109, a Java Community Process effort meant to better define the programming model and runtime architecture for implementing Web services in Java.
JSR 109's stated goal is to combine the work of several other JSRs in discrete areas that include such issues as defining the Java interfaces to XML registries like Universal Description, Discovery, and Integration, (UDDI), and whether or not new client and server APIs are needed to support Web services (see Figure 1).
Better Web service support is also the major focus of the forthcoming Version 1.4 of J2EE, the next major release of J2EE from Sun. Due out by the fall of 2002, J2EE's stated goal, in part, is to "extend J2EE 1.3 and build on J2SE 1.4 with a full set of facilities for the development, deployment, and execution of multitier, server-centric Web service applications." Currently, the Web page for J2EE 1.4 says it plans to include work from JSR 109, among other JSRs, in its specification.
But exactly how far these two specifications will go in determining Web-service standards for J2EE is still unclear. What's also unclear is whether or not vendors will wait for the standards process to implement their own Web-services solutions, a tack that may cause some friction within the theoretically interoperable community. Already, BEA is drawing some fire for its proposed Cajun framework, which will support only Web services running on the company's WebLogic server products.
Umbrella-type specifications like JSR 109 "are obviously going to take some time" to complete, says Mark Driver, research director at Gartner. "The question is, what are the core services that all will share?"
There doesn't seem to be any disagreement over the needs for more concrete J2EE standards at the lower levels of Web services, such as better support for SOAP services and defining Java interfaces to XML registries. "SOAP and XML are not really argued about," says Drew Engstrom, product line manager for Sun's Forte line of development tools.
John Magee, senior director for Oracle 9i product marketing, says Oracle is firmly behind JSR 109, which was scheduled to reach final draft stage in late February. There's a need, Magee says, "to merge Java and Web services. The more tightly [standards] are put into J2EE, the better for all."
Above and Beyond
Gartner's Driver, however, cautions enterprise customers to closely monitor vendors who get too far ahead of the standards game. Early J2EE Web-services market movers like IBM and BEA, he says, may purposely move ahead of the Java standards process, either in an attempt to drive the standard, or to gain market share.
"Every one of the vendors needs to make a decision about how far to go out beyond the basic Java standards," Driver says. The danger is that the standard might move in another direction, forcing the leader to backtrack.
"Sometimes when the standards move forward, you see vendors scrambling to undo," Driver says. "That's why we caution our clients that they may need to end up rewriting code" if they choose a standards frontrunner.
IBM, which in December announced that both its WebSphere application server and DB2 database products were certified with the J2EE 1.3 specification, is already looking beyond simple Web service needs, according to Stefan van Overtveldt, program director for WebSphere technical marketing.
"The [overall] Web services picture is far from complete," says van Overtveldt. And improvements for lower-level protocols like SOAP and Web Services Description Language (WSDL), he says, "only focus on the application enablement piece" of the Web services picture.
The paradigm of Web services will truly support dynamic e-business, van Overtveldt says, when its arsenal includes features like endpoint management (which would control how your Web service is available to other applications), third-party verification, and programs for metering and billing of Web services. Though work on defining some Java standards in these areas is underway, progress is understandably slow.
Vendor acceptance and deployment of such standards, Gartner's Driver says, is likely to vary widely as Web services become more complex.
"As you go up the stack, with things like security, it's going to be more competitive," Driver says. "Then there are questions about how you do testing of services, and how to see if someone else's service can scale. These are all huge inhibitors [to Web service growth] over the next few years."
Playing to Strength
One of the current dilemmas in the J2EE application server market is the fear of commoditization—a theory that says as the bar rises on what's included in a "standard" implementation, there's little room for differentiation from vendor to vendor. Not surprisingly, J2EE vendors all see Web services as a market arena where they can add differentiation, mostly tuned toward each company's classic strengths.
IBM, for example, is adamant about its support for technologies outside the Java environment. "It's not all about J2EE," says IBM's van Overtveldt. "Contrary to our competitors, we also think it's important to leverage existing applications. We want to allow our customers to rapidly take existing applications, from SAP, or IBM mainframe and AS/400 systems, and very rapidly turn them into Web services."
IBM has even embraced the idea of interoperability with Microsoft's competing .Net Web services framework, an openness that Gartner's Driver says has helped IBM achieve its commanding lead in the J2EE application server market (see Figure 2).
"One of the primary problems for Sun has been its knee-jerk reaction that says anything supported by Microsoft must be bad," Driver says. When Microsoft helped develop the first versions of SOAP, Driver says, Sun was "hostile" and didn't embrace it. "IBM did not have that problem," Driver notes. "They're smart enough to know that you need to keep your enemies close to you."
IBM's van Overtveldt proudly asserts his company's record in helping develop and extend Web-service standards.
"The first SOAP [implementation] was Microsoft-only," he says. "We got together with them and expanded SOAP beyond the Windows platform. We saw it as a reliable, necessary protocol. And we really are taking the approach that if the technology is important for our customers, we'll partner with whomever we need to."
According to Sun's Engstrom, Web services are moving forward with standards "that pretty much every vendor agrees with. No vendor is going to say [now] that SOAP is a bad idea." And though his company is the steward of the Java standards, Engstrom says there is "enough room to differentiate," even under the standards umbrella.
"Standards don't really tell developers how to build applications," Engstrom says. "With Web services, there are lots of areas to differentiate, lots of areas to add value. Some partners of ours, for example, are going to make money in the private registry business. There are lots of angles."
Sun's slant, Engstrom says, is to provide a complete "stack" of Web services infrastructure, which includes development tools, application server platforms, and Sun's server hardware. In his own department, Engstrom says Sun is "all about making developers more productive—by doing the little things the standard doesn't address."
One example of this process is a tool to bring existing applications (such as SAP, PeopleSoft, and IBM CICS programs) into the Web-services arena with XML adapters. "A big issue for us is how to retrofit," Engstrom says. "Because the applications running today are not going away."
Extending the Stack
Byron Sebastian, senior director of product management at BEA, says his company is also striving to integrate other legacy platforms into its WebLogic J2EE platform (see Figure 3). For example, the company's newest product (code-named "Cajun") is designed to give developers who don't have Java expertise a way to quickly make their programs J2EE compliant.
While BEA is drawing criticism from some corners of the Java community for adding nonstandard tweaks to its Java products, Sebastian says there's not enough in the standards today to support promise of true Web services.
"A lot of the groundwork" has been laid in the area of Web services, Sebastian says, "but the standards alone are not sufficient to realize [Web services'] promise. What we're doing is building in the capability to make Web services real."
According to Sebastian, that capability means better support for the ideas of loosely coupled application integration and asynchronous communications, two of the key underpinnings of Web services' potential power.
"Loosely coupled integration is a very important notion, even for in-house applications," says Sebastian, who claims that BEA is pushing beyond standards in the area of XML mapping technologies. Even inside corporations, Sebastian says, there are "different systems, built by different divisions, on different platforms, at different times."
Currently, Sebastian says, companies integrate such applications in tightly coupled ways, which causes problems when the underlying applications need to change. "Then the integration points break," says Sebastian. Web services standards, he says, need to provide for "public contracts" that describe ways to loosely couple applications, so that underlying applications have the flexibility to change without breaking the integration "contracts."
Oracle, meanwhile, is going hard after new development projects with its Oracle 9i application server platform (see Figure 4) and its new JDeveloper set of tools. Though until recently Oracle simply resold developer software licensed from Borland, Magee says its new tools are closely tied to Oracle's server for performance reasons.
"The battleground [for J2EE and Web services] is going to shift to developer productivity," Magee says. "We've put a lot of emphasis on our development tools, and a lot of focus on our server side, to get things like EJB [Enterprise Java Beans] right. It's becoming a platform game, and the standalone tools vendors are going to struggle."
The standalone tools vendors, not surprisingly, beg to differ. Axel Kratel, senior product manager for Borland's Java business unit, says a tactic of locking into a single-vendor development platform doesn't jibe with the mix of heterogeneous platforms found inside many larger corporations.
"Even within a company, you will find a BEA [application] server in one department and an iPlanet server in another," Kratel says. "The reality is that many customers have mixed environments. And they're going to want the best, most productive development environment, one that doesn't lock you into a [single] server platform."
Borland's JBuilder toolset, Kratel says, can be used with any of the leading J2EE application server platforms, a "Switzerland" type strategy also employed by SilverStream and Macromedia, which have developed J2EE development and integration product suites that seek to add functionality above the basic application-server level.
And though Oracle pledges to adhere to Java standards, it's also pushing Web services forward, promising interoperability with Microsoft's .Net services, as well as providing its own support for protocols like SOAP and UDDI, as IBM does in its WebSphere suite of products.
"The point of standards [groups] is not to love each other but to compete," Oracle's Magee says. "It's all about how well you make it work out of the box."
Hang Together or...
But even as the individual vendors pursue their proprietary extensions, the power and promise of Java's interoperability should keep the group on somewhat of a shared path, Gartner's Driver says.
"Large companies that have heterogenous data centers and multiple vendor suppliers already tend to look toward Java," Driver says. "And on the application side, SAP, IBM, and Oracle are all moving to Java. So you have to go there."
Even though Driver and Gartner predict that Microsoft's .Net will take an initial lead over J2EE platforms in Web-services deployment, they also believe that Java's interoperability will gradually lure an equal or greater number of adherents.
"The Achilles heel with .Net is that it's a single-platform system," Driver says. "It locks you into using Microsoft's database products, when you use [Microsoft's] Web server products. It's never going to completely address what Java does."
"Java is integratable, while .Net is integrated," says Sun's Engstrom. "If you buy .Net, you have to use SQL Server. But the Java approach is, if you don't like IBM's Web server, you can plug in BEA or iPlanet. There's competition at every level for customer choice."
"Look at the success of J2EE. No vendor is going to go to the market and say they have a better idea," says Oracle's Magee. "No vendor is big enough to step outside."
"You have to give Sun credit for keeping [the Java Community] relatively unified," Gartner's Driver says. "If we start to see fragmentation, that's bad. Java's success depends on how well it remains unified."
BEA's Sebastian says his company remains committed to the J2EE process, where it has been an active participant. But he also knows the group's work is far from done. "For Web services to realize their value proposition, all the standards need to be in place," Sebastian says. "But right now, the standards are just not advanced enough."
The success of Web services, whether Java-based or not, will depend on vendors' and users' abilities to overcome a host of technical and implementation challenges. That calls for progress on multiple fronts, as the marketplace sets the requirements, developers advance the technology, and the industry sorts out the standards. The interaction of those key forces will determine the future of Web services on the Java platform.
About the Author
Paul Kapustka has been covering the computer and networking industries since 1991. He is a freelance writer living in Burlingame, California. Reach Paul at .
|