For each of the requirements described in the following sections, I'll point out the requirement's business driver (that is, the fundamental reason for requiring interoperability in the solution) and business benefits. I'll also offer examples where appropriate. The purpose of this chapter isn't to provide solutions for these requirements ”it's to make sure you understand when they might arise and the reasoning behind them. These requirements and examples are the ones we'll use throughout the book.
Business requirement: To replace or extend an existing presentation tier by using the technology of a different platform, or to integrate an application written to a different platform with an existing presentation tier.
Business benefits: Allows selection of the presentation tier based on the best overall user experience, regardless of technology.
On a couple of occasions, I've been asked this question: "If you had five minutes with a team of developers proficient in J2EE and wanted to highlight a single advantage of using .NET, what would it be?" This is a tough question to answer, but if I had to pick only one piece of the .NET Framework, I'd have to say designing Web applications using ASP.NET. Don't get me wrong, some great innovations have been made in JSP technology and the frameworks that support this technology. Personally, I am a fan of Apache Struts and the concepts and ideas it employs. But when it comes to developing pages, I find that the current version of JSP (v1.2) can be likened to Microsoft's previous platform, Active Server Pages (ASP), leaving ASP.NET in a class of its own.
Many organizations that share my view have already recognized an opportunity to use ASP.NET for creating a new user experience, portal, or other user interface via the Web. Leveraging ASP.NET for this purpose can range from creating an ASP.NET page that needs to be integrated into an existing JSP framework to replacing the entire JSP portal over time. In either case, the interoperability requirement between the presentation and business tiers in an application remains the same.
This chapter's introduction described how interoperability, not migration, is the relevant issue today ”and this requirement fits well here. Many organizations looking to write a new version of an application already have the core infrastructure in place and working. However, for now, such organizations might not want to replace all the components just to deliver a new or updated user experience.
Introducing ASP.NET into an organization to extend or replace the existing JSP user interface that implements the presentation tier for a J2EE application has an interoperability requirement that follows a pattern similar to the one shown in Figure 2.3.
This sets in stone our first requirement and poses our first interoperability question: how does a typical ASP.NET presentation tier (a page, component, or replacement for a JSP equivalent) interoperate with a typical J2EE middle tier?
The reverse scenario is also very real. Imagine a business scenario in which an organization wants to adopt a third-party solution that runs on the .NET Framework in the business tier. This organization might have invested a lot of resources and development time in creating a Web experience by using JSP and probably won't want to force its users to relearn a new interface to work with the .NET services. In this case, the scenario shown in Figure 2.4 might work well, where the existing J2EE/JSP “based Web user interface is preserved but the new third-party service in .NET can still be utilized.
For both topologies, our first requirement for the presentation tier (as a client) is to call the business tier from the other platform. Herein lies our first interoperability challenge.
Business requirement: To create or integrate applications and services that have the ability to reuse exposed business tier components from an existing application or service.
Business benefits: Saves developer time and resources by utilizing components that already exist today, reducing the time required to deliver a solution .
The previous requirement focused on replacing all or parts of the presentation tier with a new solution. The business driver behind this decision might be to leverage some advantages of the other presentation tier, adding new functionality that isn't available, a new look and feel for the portal, or a mix of these. Our second requirement, the reuse of business tier components, takes a look at the interoperability requirements for a solution based on a scenario similar to the one described in the next paragraph.
Imagine an organization that has a number of applications and services already deployed using the J2EE platform. The organization wants to undertake a proof-of-concept project to create a new application or service in .NET, as shown in Figure 2.5.
To decrease time to market for developing its new .NET proof of concept, the organization has concluded that it could reuse some of the components that already exist in its J2EE implementations . For example, a set of security services (to allow authentication with other systems) might have already been created on the J2EE platform. These services have been proven in previous applications, and it seems unreasonable to expect the developers to spend time reinventing the wheel in order to use new technology.
Because the J2EE specification has evolved over a longer period of time than .NET, this type of interoperability requirement is realistic for many organizations that begin developing with .NET. Some organizations decide that certain business tier components in .NET will call business tier components in J2EE, which necessitates interoperability between the two business tiers, as shown in Figure 2.6.
The components that are called could return data from another source such as a message queue, so the J2EE business tier components could have their own access to the resource tier as well as to the new application. To reuse the business tier components from the J2EE platform, the .NET components need to communicate between the two tiers. This requirement, to reuse existing business tier components, defines our second interoperability scenario.
You might be wondering what the difference is in selecting a solution for this requirement and selecting one for our first requirement ”interoperability at the presentation tier ”given that it's just a different tier calling the business tier. Although the solutions and options to connect the two tiers are similar, components at the business tier tend to be used in different ways than components and pages at the presentation tier, which affects how we make the solution interoperable. The following sections describe some of these differences.
Many business tier components that are called from the presentation tier are usually called with the credentials of the signed-in user. In our first requirement, the authentication and authorization for calling the component at the business tier will likely be driven by the presentation tier. The credentials used to log on to the presentation tier can be passed to the business tier component to help achieve this. If we compare this with our earlier interoperability scenario in which a business tier component is invoked from within the same business tier, authentication is still an important part of the solution but will likely be performed using different credentials than those of the original signed-in user.
Again, this example will vary among different situations. The point is that it's likely that the security model for calling middle tier components from the presentation tier will be different from the security model for calling them from the corresponding middle tier. If the security model differs , this affects how you design a solution that can interoperate between the two platforms.
Components called from the corresponding business tier are much more likely to be part of a transaction (a coordinated set of processes) than those called from the presentation tier. Typically, a call from the presentation tier will be a one-off call driven by user input. For example, a presentation tier call to the business tier might be interpreted like this: "This is what the user asked for. Do something with it, and give me the result in a format I can understand."
In comparison, a call from the corresponding middle tier might be involved in a much larger transaction. The business tier component could be part of a complex system and might be subject to rollback ”in other words, if other parts of the transaction fail, this component must undo its actions. Additionally, the component might also be run synchronously with other components. As mentioned, the way a component interacts with a transaction can affect the choices and design for interoperability.
If you design a solution in which the presentation tier calls a business tier component on a different platform, you'll still expect a reasonable level of performance from the application. This is especially true for a presentation tier component because any performance- related delay could ultimately affect the user, leaving the user with the equivalent of the spinning hourglass.
Business tier components might also be subject to reasonable performance expectations. However, if a component is executed as part of a long- running asynchronous transaction, a performance degradation might not have a significant impact on the end user.
In general, interactions between components within the business tier are more coarsely grained and more loosely coupled than the interaction between components from the presentation tier and components from the business tier.
Business requirement: To create or integrate an application or service that has the ability to access data from an existing application or service.
Business benefits: Allows applications to share existing resources, thus avoiding the creation of duplicate points of data or multiple stores.
As with the second interoperability requirement, the third requirement assumes that a new application is being created. But instead of connecting J2EE and .NET components directly, interoperability is performed by sharing resources.
Imagine the following example: an organization has developed a public stock-trading application by using J2EE technology as shown in Figure 2.7. The application allows online users to trade and manage their stock portfolios via the Web.
Now suppose the organization wants to provide some new functionality, such as portfolio recommendations, and wants to deliver this information via a new interface. These new recommendations could be sent to a user via a cell phone or PDA. The organization chooses to develop the interface and business components on .NET, and the new recommendations will be accessed by the client as shown in Figure 2.8.
Unlike the second interoperability scenario, the functionality of this new application hasn't been implemented in J2EE. The EJBs and other J2EE components at the business tier don't apply to the business logic of the new .NET application; therefore, it doesn't make sense to reuse those components.
The data, however, is still valid in this requirement. All the account and portfolio data resides in a single database. To avoid duplicating that data, we need to access the tables and records from the business tier of our new application, as shown in Figure 2.9.
You might also have a requirement to access other areas of the resource tier. The database might be used to store and access account records, and for committing trades, a message queue might be used to execute orders in a timely fashion. To implement this performance boost for our new application, we might also want to provide interoperability for the message queue, as shown in Figure 2.10. The same interoperability technique can be applied to any other technology at the same tier.
Many variations and permutations can be applied to each of these requirements, but these three main requirements drive a significant portion of the solutions that we'll discover, work with, and expand upon in this book.