Chapter 2: Business Requirements for Interoperability

The objective of this chapter is to introduce the concept of business requirements for interoperability and explain the role that these requirements play in helping you select a correct design and choose technical options when building a solution. The term business requirements for interoperability refers to business drivers, needs, or requirements that compel you to create a solution that benefits from being written partly for the Microsoft .NET Framework and partly for the Java2 Enterprise Edition (J2EE) framework. These solutions either can be created anew or can exist within the enterprise already.

We'll work with three common requirements throughout this chapter and look at the two architectural concepts that are derived from them. The three requirements we will look at are interoperability at the presentation tier, reuse of business tier components , and business tier resource sharing. The two architectural concepts that we'll be deriving from these and using throughout the book are point-to-point interoperability and resource tier interoperability. You might have your own requirements, scenarios, or ideas ”maybe from projects you've been involved with or interoperability use cases you've come across. The requirements and scenarios presented in this chapter are based on my own experience with customers. My goal in presenting them is to capture some of the fundamental designs that drive interoperability with .NET and J2EE in business software solutions today.

Technology-Aligned Development

Before we look at some requirements, I want to introduce the term technology- aligned development . For the past few years , development of applications at a particular company has tended to be aligned to a particular platform or technology. For example, in one of my previous positions , I consulted for a company that used J2EE technology for all its applications and services. The organization standardized on this single technology, mandated by the CIO, and chose a preferred vendor to supply the application server that the company used.

The mindset of the architects and developers who worked for this company was aligned with the technology decisions that had been made, hence the term technology-aligned development . For example, when the business had a new requirement for an application, the architects and developers were already thinking in terms of the preferred technology. If the application would be hosted on the Web, discussions were immediately started about the best way of using JavaServer Pages (JSP), Java tag libraries, and Servlets to construct and present this experience to the user . This Web-based front end naturally had to call business tier, or middle tier, components. Therefore, these discussions led to the J2EE-specific components that would reside at the business tier, how they would be invoked, and the required protocols. Because J2EE-specific components often have to work with persistent data, the conversation turned to J2EE- specific ways of accessing databases.

The choices made for architecting the system at that time were largely based on the platform and technology the company had standardized upon. Such companywide decisions are in no way specific to J2EE ”many Microsoft- based projects have taken the same route. As applications take on a more loosely coupled and service-oriented approach, the ability to create solutions that are independent of the technology is becoming much more important for organizations ”even more so as applications and processes run across organizations via partnerships, mergers, or acquisitions. It might be possible to dictate your organization's strategy for technology development; however, choosing a technology for outside companies that you work with or might become part of requires a more heterogeneous approach.

Figure 2.1 shows the technology-aligned development paradigm. The figure shows some system building blocks we'll use in our requirements and the diagrams throughout this book. Excluding the client making the request, the figure depicts three tiers. The presentation tier contains the technology required to host Web-based applications. For the J2EE platform, this will likely be a combination of JSPs and Servlets, hosted on a J2EE application server or a Web server such as Apache Tomcat. For .NET, this is ASP.NET hosted via Microsoft Internet Information Server (IIS), which we briefly covered in Chapter 1, "Microsoft .NET and J2EE Fundamentals."

Figure 2.1: Technology-aligned development for a J2EE-specific application or service.

For the business tier (or middle tier ), Figure 2.1 shows a number of Enterprise Java Beans (EJBs) for the J2EE platform and Serviced Components for .NET. For both J2EE and .NET, we could have used ways of hosting the components other than the ones shown in the figure, but these fit the scenarios described in this book and map well to many applications that are in production today.

Finally, to the right, the figure shows the resource tier . The resource tier contains a number of systems and services that tend to be shared resources within an application. Such resources can include databases, message queues, and brokers , all of which we'll cover in Part III.

As mentioned previously, the concept of technology-aligned development isn't exclusive to any platform. Figure 2.2 shows the same approach taken in a Microsoft-centric world. The arrows in the figure show a Microsoft Web-based application calling the ASP.NET tier, which references business tier Serviced Components that persist data in a database.

Figure 2.2: Technology-aligned development for a .NET-specific application or service.

Now that we have some nomenclature for the tiers, let's look at the requirements and business drivers for enabling interoperability in your solutions.