
See Ya Later, VB Eventually VB will join PowerBuilder and Clipper (probably along with Perl and Tcl) on the shelf. The mind share of the majority of developers will gravitate to the lingua franca: Java. For the first time, developers within corporations, commercial software vendors and academia have agreed on a common language and toolset. Moreover, the fruit of their labor is portable, object-oriented and network-aware.
IBM Japan is using Java to provide a framework for Java classes to transmit themselves around a network as agents (aglets) executing autonomously in both connected and disconnected mode. To deal effectively with mobile computers and low-bandwidth connections, agents can download themselves when the opportunity knocks, perform tasks without network resources and then forward themselves onto another host as the opportunity arises. Besides obvious applications to document routing and messaging, this may not have much in common with the way many of you view business applications today. However, consider the future needs for bill presentment, e-commerce and complex queries and push transactions, and the picture changes. Everything is being developed using Java tools and delivered as a class that can be leveraged by any moderately trained Java programmer on your staff. That's not going to happen with VB.
JavaSoft has created a strategy for pluggable e-commerce components. Common e-commerce entities such as payments, protocols and wallets are implemented within an extensible framework. Competing vendors can implement their technologies for payment protocols, authentication, content delivery or microtransactions as long as they conform to the framework. The framework provides Java developers and integrators with components, databases, a gateway security model and message standards.
Whither Microsoft? I'd like to have included a Microsoft example in the list above, but Microsoft has invested as much in confusing the issue as anything else. On the one hand, Microsoft's price performance with J++ is great. On the other hand, Microsoft seems to have invested even more in PR, legal fees and questionable deviations to the Java-class API, resulting solely in an implementation that's not portable. Microsoft needs to realize that given a choice, the enterprise will choose portability. Microsoft's Java arguments effectively remove that option for Java developers who use the Windows API as a substitute for Java's portable API. And for what? A more efficient way to get at the clipboard?
Microsoft has the talent and capacity to make its platform the first among many. Indeed in terms of raw Java performance, price and support for standards such as servlets, Microsoft is well on its way. However, instead of focusing solely on technology, Microsoft has allowed the reactionary marketing element to take over. Microsoft needs to re-examine a page from its own playbook. It wasn't until Microsoft embraced the standards of IP that it succeeded in displacing Novell. Ironically, given Java's popularity, Microsoft may not succeed in displacing Unix until it drops the pretense of Java "Microsoft's way." Microsoft will succeed if it concentrates on making NT robust and scalable, plays down its competition with Java standards, and focuses on minimal, elegant ways to leverage Java into DCOM and vice versa.
Brian Walsh is the founder of bwalsh.com, a Portland, Ore., consulting firm specializing in Internet and client/server product strategies, development and testing. Send your comments on this column to him at brian@bwalsh.com.
|