Chapter 16: Interoperability Futures

In the previous 15 chapters, we covered a significant amount of content and a number of topics for achieving interoperability between .NET and Java. In this final chapter, I want to recap some of the lessons we have learned and the goals of the book, and take a look at how interoperability between .NET and Java could evolve .

Topics and Goals of the Book

Part I, "Getting Started," introduced some of the fundamentals of .NET and Java interoperability, including business requirements for interoperability and three common scenarios. In Part I, we also investigated data exchange between the two platforms. After defining the term point-to-point interoperability , in Part II, "Interoperability Technologies: Point to Point," we looked at two technologies that could immediately bridge the communication gap between .NET and Java. These technologies were .NET Remoting and XML Web services. For each technology, I showed a number of permutations of how interoperability could work ”for example, how .NET Remoting could be used to expose both an Enterprise JavaBean (EJB) and a component hosted through Component Services, and how both .NET and Java clients could use Universal Description, Discovery, and Integration (UDDI) to locate Web services within an organization.

Part III, "Interoperability Technologies: Resource Tier ," covered a broad range of interoperability topics related to the resource tier. After covering how to create a shared database, the remainder of Part III concentrated on asynchronous interoperability. A number of options were shown for connecting either a .NET or Java client to either Microsoft Message Queuing (MSMQ) or WebSphere MQ. Toward the end of Part III, we also saw how technologies such as the MSMQ-MQSeries Bridge and BizTalk Server could both aid in bridging these message queues and provide additional value. And Part IV, "Advanced Interoperability," is focused on advanced interoperability. This part started with a discussion of the benefits of interoperability at the presentation tier ”namely, sharing session state and authentication, with the samples showing examples of each. The last three chapters have focused on the latest specifications for Web services. For each of the areas ”Security, Binary Attachments, and Routing ” sample code was shown to demonstrate that although the specifications and ideas are relatively new, implementations can be achieved using the right tools and processes.

I have had three goals for each chapter and for this book as a whole: to thoroughly cover the topic, to maintain a neutral stance regarding .NET and Java, and to provide sample code.

Thoroughly Cover the Topic

I really wanted to show as many examples, requirements, and permutations of interoperability between .NET and Java as possible, and to do this in such a way that would provoke thought, and lead to a number of prototypes and, ultimately, implementations.

For the technical content, I wanted to make a distinction between point- to-point and resource-tier interoperability, and highlight them accordingly . Often papers and articles that explain interoperability cover only one of the topics (for example, how Web services can enable a particular interoperability scenario or how to connect .NET to a particular message-queuing product). I considered it important to give both fair coverage.

Maintain Neutrality Regarding .NET and Java

My second goal was to maintain a neutral stance throughout the book. There is a lot of debate in the industry about the pros and cons of .NET and Java. Developers in general tend to be a religious bunch, and organizations can also be guilty of following one vendor or standard when a mix can often pay dividends . (See the "Technology-Aligned Development" section in Chapter 2, "Business Requirements for Interoperability," for more details.)

What I've strived for is a balanced view of the two platforms. While I have my own opinions about which technology is more suitable for a particular task, the goal of the book has been to provide an impartial view of each technology and to show how interoperability between the two is possible.

One decision pertinent to this goal was the choice of the Web services vendor for the Java platform. When I was mapping out the content for the book and the areas that I wanted to show, it struck me that choosing the correct Web services stack for Java would be crucial for many of the chapters.

I had a number of options. I could have selected a particular J2EE Application Server vendor and used its Web services toolkit. This might have worked well for the application server in question, but I didn't want the book to alienate any readers who had chosen another. I could have also selected the open - source option, Apache Axis. The Axis stack could have worked given that it's independent of an application server, but I found the implementation too verbose for the samples and topics that I wanted to present. Also, at the time of this writing, it was unclear whether the toolkit supported the latest Web services specifications (for example, WS-Security, WS-Routing, and DIME).

This left me looking at third-party solutions. Out of the many products available, I chose to work with GLUE from The Mind Electric. (The technical reasons for this decision can be found in Chapter 5, "Connectivity with XML Web Services, Part 1.") In my opinion, GLUE takes an elegant approach with its implementation, and it follows a logic similar to a number of APIs also found in .NET. When we examined the code samples, you might have noticed how the flow, logic, and structure of the code of the two are very similar. This similarity offers many benefits for developers who work with both. In addition, The Mind Electric has a great underlying platform with Electric XML (which was used for the serialization examples in Chapter 3, "Exchanging Data Between .NET and Java") and appears to be very forward looking ”most notably, by being one of the first vendors to adopt some of the latest Web services specifications shown in the previous three chapters.

Whatever Java Web services stack you select, I hope you find that many of the samples, lessons, and recommendations outlined in this book remain applicable .

Provide Sample Code

As you might have noticed, many chapters have been built around the sample code that ships on the accompanying CD. This approach comes from projects and presentations that I undertake, where I tend to be as pragmatic as possible.

I've sat through many presentations on the future and goals of Web services, industry standards, and new products. And while I really applaud all the efforts in these areas, I am naturally inquisitive to see how things work in code. My goal in this book, therefore, was to show as much working sample code as possible. Reading about how technology works is great, but taking examples and learning from them by running them in your own environment provides more benefit than reading alone.