Sun Microsystems: Left behind at Web services altar?
ZapThink LLC, special to SearchWebServices
by Jason Bloomberg and Ron Schmelzer
The battle over Web services platforms is heating up. The market is polarizing, with Microsoft leading the .NET charge, and the Java/J2EE charge led by...IBM. Sun Microsystems, the creator of the Java language, appears to be lagging behind, as IBM, BEA, Hewlett Packard, and the rest of the Java Web services camp prepares to fight. So, what happened to Sun? How did they fall from Java industry leader to Web services also-ran? And what can they do to get back into the battle?
ZapThink has identified four areas where we believe Sun has made strategic errors. Each of these errors has slowed down Sun's acceptance in the Web services marketplace. ZapThink believes, however, that it is not too late for Sun to address each of these strategic issues.
Strategic error #1: Narrow commitment to Sun's "Write Once, Run Anywhere" vision
One of the fundamental issues that Sun is struggling with is how Web services fit into their well-established Write Once, Run Anywhere vision for Java. This core vision requires a common platform at the virtual machine level across heterogeneous environments. Write Once, Run Anywhere implies that the device or system that plans to make use of remote functionality actually hosts the code that executes the remote logic.
However, Web services, regardless of the implementation, subscribe to a Write Once, Access Anywhere philosophy that implies that the executing logic can be written once and executed in a single execution architecture. Basically, a JavaBean that performs a tax calculation can be run on Windows, Unix, Linux, and AS/400 systems as long as a Java runtime exists on those platforms. However, that same JavaBean exposed as a Web service can be run on all those platforms with the only requirement that they be able to communicate using Web services protocols.
Sun, however, is missing the picture. It's not important where the code resides, but how it is accessed. Sun is in a great position to make their platform be the "best consumer and producer" of Web services. However, IBM, BEA, Hewlett Packard, Oracle and others have taken the lead in building Java Web services platforms. Sun is missing the boat by being overprotective of what should be the single architecture for the production and execution of Web services. In fact, ZapThink believes that because Java represents one of the largest current installed architecture bases, it would be quite logical to fully Web services-enable the J2EE specification. Well, Sun doesn't seem to get that picture. They seem to think their world is shrinking, when it could in fact be expanding.
Strategic error #2: Sun is lukewarm in its support of Web services standards
Sun has been late to the party for years. They were one of the last to support UDDI, haven't yet joined the WS-I, and have been unclear about their support of WSDL and other initiatives. Their lack of early and strong support is reflected in a weak, ill-fitting jumble of assorted APIs, applications, technologies, and standards. Customers want to build Web services on top of J2EE, but Sun isn't providing the tools and infrastructure they need. As a result, these customers will go to BEA and IBM, thus fulfilling Sun's prophecy that Web services will eat away at their bottom line.
Strategic error #3: Misplaced support for ebXML at the expense of Web services
Sun reveals its hard line position on Web services by the way they position ebXML as an alternative to Web services. ebXML is an architectural framework for enabling automated B2B communications. ebXML has offered an entire stack of protocols ranging from SOAP-like messaging-level wire protocols to higher level business process and business document specifications. However, as Web services become an increasingly de facto standard for platform-independent distributed computing, the need for a parallel stack of standards for B2B computing, like that offered by ebXML, becomes less relevant.
However, ebXML's value doesn't lie in its lower level protocols. ebXML's true, and potentially lasting, value lies in its higher level business- and process-oriented specifications. ZapThink believes that it is likely that ebXML to hitch itself to the Web services bandwagon. However, given that Sun is ebXML's primary corporate backer, they have become overprotective of ebXML's role as an alternative to Web services. This approach is dangerous to both Sun and ebXML. If ebXML were to embrace Web services as its communications framework, both formats would benefit greatly. Hardly any company has built ebXML-centric products, while the number of Web services products on the market or in development has grown exponentially. ZapThink recommends that Sun adopt a strong pro-Web services stance while presenting ebXML as the de facto B2B implementation of Web services.
Strategic error #4: Spending too much time and energy fighting Microsoft
Not only does Sun frequently sue Microsoft, but Sun CEO Scott McNealy is widely known for his diatribes against the company. For example, Mr. McNealy said, "Microsoft can try to spin the answers from now until judgment day, but it's clear that the world's biggest software company didn't have [the consumer's] best interests in mind." He also said, "On the one hand, [Sun has] an open industry-wide community that works together to continually extend the potential of the network with compatible, vendor-neutral technologies; on the other, a set of products (more accurately promised products) controlled by a single company [namely, Microsoft] with a record for locking customers into proprietary solutions, selectively sharing its source code, and not documenting (read: hiding) its programming interfaces." Microsoft, however, spends very little time talking about Sun. They're too busy writing software and building their market.
Furthermore, Sun seems to equate Web services with Microsoft. In fact, Microsoft created neither Web services nor XML. However, Microsoft is a very smart and shrewd competitor. They "saw the light" of Web services and have aggressively pursued a Web services strategy. Microsoft believes that they are best capable of delivering on Web services consuming and producing technology, and they have set out to prove it. You'd think that Sun would have seen the same light. Instead, their marketing message has become increasingly defensive, and as a result, their sales, consulting, and product delivery has been slow to respond to customer demands.
Sun must jump on the Web services bandwagon and communicate to the world that the Java platform is the "most capable producer and consumer of Web services." Sun must also drop the idea that ebXML competes with Web services. They should fully support the Web services specifications, and devote their energy to improving their Web services implementations. Sun may be so committed to Java that they fail to realize how it must now play in a much larger universe. Web services specifications aren't executables. They are nothing but a set of XML-based protocols. At the end of the day, Web services are written in programming code. In fact, Web services will be written in C++, Java, Visual Basic.NET, or C#. It's up to Sun to make the case that Java is the best choice.
In addition, Sun should forget about Microsoft for a while. Sure, they're the big bully who doesn't play fair, but whining to the teacher doesn't earn them respect from the other kids on the playground. Instead, Sun should put all their energies into pushing what's cool at Sun. After all, the kids on the playground would rather play with them.
Copyright 2002 ZapThink LLC provides quality, high-value, focused research, analysis, and insight on emerging technologies that will have a high impact on the way business will be run in the future. To register for a free email subscription to ZapFlash, click here.
For More Information:
- For more insightful opinion and commentary, read other Guest Commentary columns.
- Tired of technospeak? The Web Services Advisor column provides a clear understanding of Web services.
- Looking for shortcuts and helpful developer tips? Visit our Tip Exchange for time-saving XML and .NET tips.
- Visit our huge Best Web Links for Web Services for hand-picked resources by our editors.
- Discuss this article, voice your opinion or talk with your peers in our Discussion Forums.
- Visit Ask the Experts for Web services, SOAP, WSDL, XML, .NET, Java and EAI answers.