The Structure of the Book

With the book's broad audience in mind, I'd like to summarize the structure of this book as a whole:

• Refreshing some .NET and J2EE fundamentals Targeting the readers of a book on interoperability between two technologies is difficult. Many of the chapters will appeal to two distinct audiences: readers with a J2EE background who are now learning how to build solutions that interoperate with .NET, and readers who have followed a more traditional Microsoft approach over the years and are now looking to integrate with existing J2EE implementations . (Many readers of course will have skills in both these areas.)

  To ensure that readers from both backgrounds have sufficient knowledge of each other, Part I, "Getting Started," will explore some fundamentals of both technologies. This section will cover Microsoft .NET from a Java perspective and J2EE from a Microsoft perspective, hopefully providing enough terminology to clarify the structure and technical elements of the book for both audiences.

• Outlining business requirements for interoperability Architects and developers usually don't design solutions that interoperate for no reason. More often than not, an application that has the capability to interoperate with another application is driven by one or more business requirements. For example, suppose Application A needs to interoperate with Application B due to specific business needs or use cases. In Part I of the book, we'll look at three common business-requirement scenarios, the requirements for interoperability, and the business benefits that enabling those scenarios would yield. Part I concludes by introducing some of the technical challenges of exchanging data between .NET and Java.

• Exploring technologies for interoperability For the developer, a key goal of reading this book is to get to the meat of the information. Given each scenario and business requirement outlined in Part I, we'll discuss which interoperability technologies apply and how you can realistically use them. Many technical options are available for creating a solution that can bridge both the .NET and J2EE platforms. This book will examine two architectures, identify the scenarios in which they fit best, and see where the technology really applies. Part II, "Interoperability Technologies: Point to Point," will look at point-to-point interoperability and cover options for connectivity. Part III, "Interoperability Technologies: Resource Tier" addresses interoperability at the resource tier and discusses how .NET and J2EE can interoperate in a reliable, asynchronous way.

• Advanced interoperability At the time of this writing, I still had not found many books, white papers, and resources that cover .NET- to-J2EE interoperability. One of the reasons for this lack of material is that the ability to interoperate among so many systems has changed and evolved so rapidly during such a short period of time. As a result, few people have managed to capture all the options and information concisely.

  The latest evolvement in interoperability technology is what I refer to as advanced interoperability . We'll cover this in Part IV of the book, aptly named "Advanced Interoperability." I wanted to cover this subject in the book because we're at a point in time where advanced interoperability is a reality in many areas of implementation. The focus of this section isn't to tell you (as a developer or solutions architect) what interoperability solutions can be performed, but to actually show them in action. This part of the book will include many code samples and guides for putting these technology options into practice.

  To me, advanced interoperability is about what happens next , after the communication channels between .NET and J2EE have been opened. In many cases, just getting the two systems to communicate and exchange data over a common protocol is an achievement in itself, but this alone doesn't lead to creating business applications and services that are reliable, secure, and production-worthy. We need to broaden our thinking to include the services and features that are required to build a business-ready solution.