Introduction

Overview

During the past two years , I have presented on the subject of interoperability between Microsoft .NET and Sun's J2EE at a number of conferences, customer meetings, and internal seminars . The majority of the presentations I've given have concentrated on the key takeaways and elements presented in this book. I decided to write this book because I wanted to share this information with a wider audience. My rationale and support for interoperability has evolved over time based on my experience, my work on development projects, and most importantly, customer feedback.

When the Microsoft .NET Framework was first released, I spent a lot of time looking at migration strategies and how customers could move existing applications based on the J2EE platform to the .NET platform. I soon adopted the view that we should concentrate on developing a broad strategy for migrating from J2EE, starting with examining common code patterns in a J2EE application. I had a background in designing applications for the J2EE platform, and I discussed with peers and customers how particular J2EE components could map well to their .NET equivalents. I then began writing some prototype code for identifying these patterns in J2EE and for using refactoring processes to migrate them to .NET.

The work went well. I delivered a number of prototypes that took raw Java source code from J2EE applications and reconstructed .NET components with a relatively high degree of accuracy. With the help of a newly released productMicrosoft Visual J# .NET, which enables existing Microsoft Visual Studio .NET users to develop solutions using the Java language syntax on .NET I created a number of key presentations and roadmaps .

I delivered one of my main presentations on the topic to the Southern California Architect Council in April 2002. This council is a group of top CTOs and CIOs from leading blue-chip enterprises in Southern California. The group gathers every quarter to discuss the direction and strategies for their adoption of Microsoft technology and products. I polished my "migration roadmap" presentation with some stunning (if I do say so myself ) demos. Some of these demos showed samples first running under J2EE, and then running under .NET after a few clicks of the mouse. I eagerly imagined the jaw-dropping gasps and wide- eyed stares my presentation was sure to elicit from the audience members , whom I knew were running their solutions on existing implementations of J2EE.

Part of the process of presenting to such a select audience involves screening the slides with the organizers of the event. I forwarded my slide deck to a couple of colleagues from the Southern California Microsoft office for review and awaited their feedback. Their feedback was brutally honest. It went something like this:

"Simon, the migration message that you have for moving from J2EE to .NET is great. We think you have some excellent points, a great message, and some awesome demos."

I was beginning to enjoy the feedback

"There's just one problem. Our customers aren't interested."

I was in shock . How could they not be interested? Did the customers invited to this event not care about .NET? Maybe they weren't J2EE adopters after all? Was I speaking to the right audience here?

I soon learned that the real reason wasn't that these customers weren't interested in .NET or that they weren't running any J2EE applications. It was that migration wasn't an option for them at that time. They didn't want to hear the "rip and replace" story from Microsoft, or anyone elseregardless of how accurate or technically astute that rip-and-replace story was. The facts showed that many of these CTOs and CIOs had already invested in J2EE. This commitment ranged from purchasing application servers from various J2EE vendors to building and training their own communities of developers and deploying production code. These executives weren't interested in entertaining a roadmap to migrate all their existing code to .NET just for the sake of moving to a new platform in the short term .

I still had some time before the presentation to absorb this feedback from my reviewers. Drawing on the energy and enthusiasm that I'd put into my migration strategy, I developed content based on interoperabilitynamely on strategies that would allow an application written for .NET to interoperate with an existing J2EE-based application. Given that migration often begins with interoperability, I was also able to recycle many parts of my original presentation.

The presentation, although not as rehearsed as I would've liked , went very well.