3.6 Putting it all together

< Day Day Up >

Figure 3-10 on page 81 shows a typical modern e-business application architecture around which we have placed the TMTP WTP components. This will help the reader to visualize how the WTP components could be placed. The application architecture introduced below will form the basis of most of the scenarios that we cover in later chapters. In the rest of this book, we have used the Trade and PetStore J2EE applications for our monitoring scenarios. Each of these examples is shipped with WebSphere 5.0.1 and Weblogic. Figure 3-10 shows an e-business architecture that may be used to provide a highly scalable implementation of each of these applications.

click to expand
Figure 3-10: Putting it all together

Typical features of such an infrastructure include the use of a Web tier consisting of many Web servers serving up the applications static content and an Application tier serving up the dynamic content. Generally, a load balancer will be used by the Web tier to distribute application requests among the Web servers. Each Web Server may then use a plug-in to direct any requests for dynamic content from the Web Server to the back-end application server.

The application server provides many services to the application running on it, including data persistence, that is, access to back-end databases, access to messaging infrastructures, security, and possibly access to legacy systems.

In the design shown in Figure 3-10 on page 81, we have made the following placement decisions:

Management Server: We have placed it in the intranet zone, as this is the preferred and most secure location for the Management Server.

Store and Forward Management Agent: We have used only one and placed it in the DMZ. This will allow the Management Agents within the DMZ and on the Internet to securely communicate with the Management Server. Many environments may have multiple levels of DMZ, in which case chaining Store and Forward agents would have been a better option.

Quality of Service Management Agent: We have chosen to use only one and place it behind our load balance, yet in front of one of the back-end Web Servers. We considered that this solution would give us a good enough statistical sample to monitor end-user experience time. Another option which we considered seriously was placement of a Management Agent and Quality of Service endpoint on each of our Web Servers. This would have given us the capability to sample 100% of our traffic. We discarded this option, as we felt that we did not need this level of detail to satisfy our requirements.

Synthetic Transaction Investigator Management Agent: We chose to place one of these on the Internet, as this will allow us to closely simulate a real end user accessing our e-business transactions. We also plan to place additional Synthetic Transaction Investigator Management Agents both in the DMZ and intranet, as well as on the Internet as specific e-business transaction monitoring requirements arise.

Rational Robot/GenWin Management Agent: Again, we chose to place one of these on the Internet in order to allow us to test end-user response times of our e-business infrastructure where it uses Java applets or other content, which is not supported by the STI Management Agent. Later plans are to deploy Rational Robot/GenWin Management Agents within the enterprise in order to monitor the transaction performance of our other enterprise systems, such as SAP, Seibel, and our 3270 applications, from an end user's perspective.

J2EE Monitoring Management Agent: We chose to deploy the Management Agent and J2EE monitoring behavior to each of our WebSphere Web Application servers. This will provide us with the ability to do detailed transaction decomposition to the method level for our J2EE based applications.

< Day Day Up >