Introduction Achieving Interoperability
Business ChallengesIt is a common trait for business to have large and diverse systems and a rare one for them to have unified systems. Be it through acquisitions, mergers, staff and policy turnover, or a hundred other reasons the fact remainsthey have systems built in different languages, running on different software platforms, and targeting different hardware. Add on top of this the need for businesses to be increasingly more nimblefueling a requirement for integrated, interoperating systems that can aggressively respond to business requirements coherently and quicklyand you have a major challenge facing businesses today. A few years ago the typical business data system was a simple, monolithic affair with business assets in a mainframe that were accessible via a tightly coupled user interface. Transfer of assets between domains was usually manualfor example the transfer of an order from a sales-facing system to a realization and delivery system was typically done by an operator keying in details of a printout from one system to the other. The operator herself was the interoperability layer. Over time as systems evolved, technologies evolved to allow networking and to automatically integrate across protocols such as CORBA. These, however, proved to be very difficult and expensive to develop and maintain. Today's landscape sees the data center split into two main deployment types. On one side is the Microsoft stack of products, covering everything except the hardware, from the operating system through the software platform to the application, with the Windows Server family and the .NET framework and runtime. Developers have a host of tools that allow them to develop and target this platform and can receive exceptional time to market and cost of development metrics. On the other side is the open family of Java EE software frameworks, which can run on a variety of hardware platforms and that run applications written with the Java language. With this it has been shown that they offer exceptional runtime characteristics. Technologies such as Enterprise Java Beans (EJB) are designed with the characteristics of security, scalability, manageability, and performance in mind and are particularly useful in large-scale systems that serve large numbers of users. However, getting an effective data center implementation of a product that utilizes these two sets of assets is a difficult process. Development management has often had to choose between the productivity of the .NET environment and the runtime characteristics of the Java EE platform. Having a "best of both worlds" solution was difficult given that there were few easy or cheap ways to get products running on these platforms to talk to each other effectively. Consider the example of a company whose system is the result of several mergers and acquisitions and has an array of databases implemented on different technologiesdiverse hardware for applications; different runtime platforms; and applications of varying architectures. Integrating this system would be a very challenging process indeed. Enter Web servicesabstract entities that encapsulate business processes and expose them via a standard interface. The underlying implementation doesn't matter! In the example just mentioned, each system's data retrieval layer can wrap itself in a Web service so that it exposes a standard interface. Then the development manager who wants to use his junior staff who are great at quickly putting together ASP.NET or JSP pages has an ideal opportunity to make the most of Web services technology and build a front end that can consume these Web services via proxies. It should be easy, but it isn't. Why? Because while standards may be, well, standarddifferent implementers of software that uses these standards and allows you to build software that exposes these standards have done it in slightly different ways. These different ways mean that not everything that is wrapped with a Web service can talk cleanly to everything else that knows how to talk to a Web service. This interoperability is not as simple as it should be. This, then, gives rise to a book such as this one in your hands. Armed with the knowledge that you'll gain from reading this book, you'll be able to go forth into your development team or data center and either solve interoperability problems you're having or, better still, design a system that doesn't suffer from interoperability problems. Technology for InteroperabilityThere are several technology solutions for interoperability covered in this book. The first and most obvious one is Web services, whereby you can wrap your business entities in a standards-based layer so that their technology implementation is abstracted. Therefore, anything that interacts with this layer doesn't need to know about the technology that drives it and should interoperate cleanly. It's a powerful and compelling methodology, but it is not without its drawbacks. It is challenged in two main areasdiverse support for standards and performance. Strategies for handling these are used throughout the book. A well-known and well-used methodology for integration and interoperability is the use of a messaging platform. This is where communication between layers is done through simple messages passed through managed queues. Technologies such as JMS, MQSeries, and MSMQ are examples of this. They can make for a very powerful and very performant interoperability layer, particularly where there are real-time requirements. Another technology, platform unification, allows for clean interoperability between .NET and Java EE applications. With this concept the runtime layer is unified, and application developers for one language can deploy their applications to the runtime traditionally used by another. For example .NET developers can rehost their applications on Java EE. As such, the .NET and Java EE applications don't need to go through a separate layer to talk to each otherthey are on the same platform and can talk cleanly. Interoperability doesn't just have to happen at the application layer; it can also take place on the resource tier. With new technologies allowing more and more business logic to be driven closer to the database, interoperability problems may also be solved. As the application layers get thinner, the easier it is for them to communicate with each other. Structure of the BookThis book covers two main constituents of any Java EE.NET integration. The first one pertains to the integration type such as synchronous or asynchronous, outlining how individual Java and .NET components can integrate using their diverse technology set. The second constituent relates to the quality of service requirements, such as security, reliability, and scalability, essential to meet a Service Level Agreement (SLA) across the heterogeneous enterprise environment. If you take a closer look at the book structure, you'll notice that the book represents a catalog of integration strategies that adheres to the following format:
The strategy catalog comprises the core of this book and can be used as a reference manual on Java EE.NET interoperability. Before delving into the strategy discussion, it is helpful to review the fundamentals of the Java EE and .NET platforms. The emphasis in reviewing these platforms will focus on their interoperability characteristics. Both platforms expose APIs to develop component-based, loosely coupled integration points. The platform overview is followed by Part II, "Synchronous Integration Solutions," which discusses common business scenarios and reasons for synchronous integration. The de facto technology to integrate disparate applications is based on Web services. Chapter 4, "Web Services for Synchronous Integration," demonstrates how a .NET application can discover and access a Web service implemented in Java and vice versa. The synchronous integration discussion continues with the .NET Remoting technology that remains an alternative to Web services and is adopted by open source and various commercial solutions. The .NET Remoting is shipped as part of the Microsoft Indigo Services. Chapter 6, "Resource Tier Synchronous Integration," details database and legacy integration. It demonstrates a simple strategy to build a Data Access Layer to connect to heterogeneous RDMSs, such as MySql and SQL Server. All in all, synchronous integration strategies are useful if you have two systems with tight coupling or strong dependencies. The industry, however, is heavily leaning toward asynchronous application integration. Asynchronous integrations between Java EE and .NET systems are easier to maintain, less brittle, and tend to be more scalable. Therefore, the majority of the strategies in this book fall under Part III, "Asynchronous Integration Solutions." The first two strategies, Automatic Callback and Response Polling, are based on Web services technologies. They fundamentally differ from the approach taken in the previous section. The main goal of these strategies is to factor out remote calls from the rest of the request processing. The response can be sent via the callback or polling technique. Chapter 9, "Messaging," unveils five distinct strategies that help to automate and streamline the Java EE and .NET system integration around MOM, SMTP, and Enterprise Service Bus technologies. Reliable message delivery is the key differentiator of these strategies. Similar to the previous section, Chapter 10, "Resource Tier Asynchronous Integration," shows how to asynchronously communicate with back-end resources. Part IV of the book addresses "Quality of Services" for interoperability. It incorporates several chapters that discuss how to implement a secure, reliable, interoperable Java EE.NET environment. This section encompasses distributed transactions and management of a heterogeneous environment, but most importantly it provides best practices on the enterprise architecture that mitigates security, manageability, availability, and reliability risks. The table here outlines strategies listed in this catalog.
Aside from the integration and systemic quality strategies, this book discusses how to deploy a .NET application under a Java EE application server and how to manually port a .NET application to Java. These strategies are included in Chapter 16, "Migrating .NET Applications to Java." Each chapter of this book intends to give the reader an overview of the technologies and concepts used by individual strategies. Messaging, resource pooling, threading, and asynchronous programming models differ under the Java EE and .NET platforms. Understanding these programming models under each platform enables the reader to effectively apply strategy within a specific domain. What the Book Is and Is NotThis book is a collection of Java/.NET integration strategies and best practices. It categorizes the interoperability technologies architecturally into synchronous integration, asynchronous integration, bridge, and Quality of Services. Then different business scenarios (including WS-I interoperability scenarios) are used to put these interoperability technologies into context. Standards-based technology is explicitly introduced with examples of using different vendor products, thus enabling developers and architects to build vendor-agnostic interoperability solutions. This book is not about interoperability design patterns. There are better and specialized design pattern books available that are related to integration and interoperability. This book uses a less formal language structure than design pattern when discussing Java/.NET interoperability, with the intent of making the contents easier to read. This book is not a programmer's cookbook. A programmer's cookbook for Java/.NET interoperability usually includes a great deal of sample programs and intensive tutorial on the programmatic APIs to cover the full .NET and Java programming language features. The book does include, however, sample programs to illustrate how to craft a design strategy. This book is not a summary of interoperability standard specifications. The goal was to keep the contents concise and short, so instead, URLs and references to interoperability literature and standards specification are included. Who Should Read the BookThis book is targeted at novice, practicing .NET and Java developers. For novice developers, there are code samples for each integration and interoperability strategy, which are structured in the form of Problem/Solution/Example. This provides developers with a quick start for building interoperable solutions and allows for design reuse. For practicing developers, the "Best Practices and Pitfalls" sections highlight many "gotchas" from field experience. They can benefit from learning from the success or failure of others' past experience. This book is also extremely useful to architects and IT managers. The text includes extensive discussion of emerging interoperability technologies and analysis of what they can or cannot do today. Architects and IT managers may get a brief overview of which interoperability technologies are relevant to their operating environments and can facilitate their architectural planning. BenefitsThis book is intended to provide added values to the readers with the following benefits:
SummaryInteroperability between Java EE and .NET applications is the "holy grail" in cross-platform integration. It is highly complex, time-consuming, and prone to implementation risks. Many integration and interoperability problems are not discovered until the interoperable solution is implemented. To manage interoperability, architects and developers need to identify the complex, technical issues for their interoperability technologies prior to implementation. It is often an exploratory experience with many trials and errors. This book intends to mitigate these risks by identifying the technology complexity and issues while using sample scenarios, describing best practices, and highlighting pitfalls. With the availability of many new interoperability technologies such as Web services, you can see that standards-based integration and interoperability technologies become viable and increasingly important. Synchronous and asynchronous Web services have become a preferred choice of integration and interoperability technologies. When compared with earlier literature that emphasized vendor-specific technologies (such as .NET Remoting and bridge), those standards-based technologies provide more design options from which to choose. Design reuse also becomes a priority to developers and architects. Many one-time integration efforts were made in the past to enable a .NET application interoperating with a Java application. In particular, when a proprietary technology or highly customized solution is used, developers cannot sustain the maintenance and ongoing support, thus this book puts considerable focus on reusable design strategies. Finally, Quality of Services (QoS) for interoperable solutions denotes reliability, availability, scalability, security, and manageability. Traditionally, application development targets completion of coding and deployment. But, nowadays, with complex interoperable systems, the post-deployment phase and QoS are just as important. Very often, the QoS issues are deeply rooted in the application architecture design. Quality of Services is a key theme in this book. Errata and Sample Codes DownloadReaders can check updates, errata and sample codes from the Prentice Hall book Web site www.prenhallprofessional.com/title/0131472232 and http://javanetinterop.dev.java.net. Selective sample codes, scripts, snippets, and additional release notes from chapters in the book will be available for download from the above URLs. They are provided for education and illustration purposes, and are not guaranteed to work on every operating system environment due to the changing software versions of the open source software components and any potential issues in the environment setup. The authors provide these sample codes as supporting materials. Readers' FeedbackReaders can send their feedback to the authors via email:
The authors will try their best to consider readers' input for revision in the future reprints. |
EAN: 2147483647
Pages: 170