Indigo Incoming: How Will the Java World Respond?

The competition between the Java technology family and Microsoft’s .NET is the defining reality of enterprise software development today. Each side has good ideas, and both J2EE and the .NET Framework owe a debt to the other. (For more on this, see Opinari #1, How Progress Happens). Most important, each forces the other to get better.

Yet while these two technology families have much in common, one of their most significant differences–the process used to create them–is about to be put in the spotlight. In the Java world, groups of vendors and individuals work together through the Java Community Process (JCP). With .NET, Microsoft alone controls its future. In trying to divine the future of these competing platforms, it’s useful to think about the impact this difference has. And given Microsoft’s recently-announced Indigo technology, the point is anything but academic. The Java world will respond in some way, and the JCP is how that response will be created.

Technologies defined by groups of vendors have some clear advantages. By creating multi-vendor agreement, they can provide portability, interoperability, or both. Standards for web services provide a clear example of the benefits of this approach, defining broadly-supported agreements that allow applications to communicate. But technologies defined by groups of vendors also have some clear disadvantages. They take longer to appear, since reaching agreement among competing organizations is usually harder than getting everybody to agree within a single company. It’s also harder to make radical shifts when changes in technology warrant it.

The response of the J2EE and .NET camps to the rise of service-oriented development is a case in point. No distributed object technology has been wildly successful, and so the way forward appears to rely on the simpler idea of services. Together with today’s widespread agreement on web services standards, this technology shift makes the creation of a platform for service-oriented applications an excellent idea. Big conceptual shifts sometimes require big changes in technology design, and this looks like one of those times.

Microsoft’s response to this shift is the technology code-named Indigo. Designed from scratch for a service-oriented world, Indigo will displace a number of current .NET technologies, including .NET Remoting, ASP.NET Web Services (commonly called ASMX), Enterprise Services (formerly called COM+), and others. Although it won’t ship for a while yet, Indigo is a clear example of the kind of wholesale re-thinking that a single vendor can offer. Microsoft’s direction is clear, as is its embrace of the service-oriented approach.

Can the Java world make this kind of large-scale shift? I can’t help being a little skeptical. The technologies in Indigo are analogous to several key parts of J2EE, including Java Remote Method Invocation (RMI), Enterprise JavaBeans (EJB), the Java API for XML-Based RPC (JAX-RPC), and to some extent the Java Message Service (JMS). How likely is it that the people participating in the JCP for all of these efforts would agree to kill their technology and create in its place a unified approach? And even if this did happen, how long would it take to reach agreement across all of these diverse groups, then transform that agreement into shipping products?

Innovation requires a willingness to change, sometimes radically. The processes that create multi-vendor technologies don’t lend themselves to this kind of change, and so responding aggressively to technology shifts as large as the move to service-oriented development is hard. A single vendor can more easily introduce completely new approaches, if only because the internal process for doing so is easier. I’m sure the development of Indigo within Microsoft wasn’t without pain. People who have spent years working on something are rarely happy to chuck it in favor of something new. Yet the company was able to bite the required bullets to make this kind of substantial change possible. Is this also true of the people who control the future of J2EE?

Multi-vendor technologies have some clear advantages, but rapidly reacting to substantial shifts in technology isn’t one of them. I can’t wait to see the Java world’s response to service-oriented development and the arrival of Indigo.

• Indigo Incoming: How Will the Java World Respond?
   
• Now Available: A Visual Introduction to SQL, Second Edition
   

Now Available: A Visual Introduction to SQL, Second Edition

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, David helps information technology professionals around the world understand, use, market, and make better decisions about enterprise software technologies. David has given keynotes at conferences and in-house events in the U.S., Europe, Latin America, and the Middle East, and his seminars have been attended by tens of thousands of developers and decision makers in thirty-five countries. David’s books have been translated into ten languages and used in courses at MIT, ETH Zurich, and other universities. His consulting clients have included HP, Microsoft, Stanford University, and other technology vendors and users.

©Copyright2007 David Chappell and Associates
All rights Reserved.