Export (0) Print
Expand All
Separating DSL Semantics from Implementation
Expand Minimize
Bb508960.skyscrapr_banner(en-us,MSDN.10).gif

Monitoring Quality Attributes

 

Rogério Cruz

May 2007

Summary: This article covers how to apply architecture statements to a real-world environment. (4 printed pages)

Contents

Introduction
A Rigid Architecture Framework
Security Issues
An API Nightmare
Lessons Learned and Takeaways
Critical-Thinking Questions
Further Reading
Glossary

Introduction

One of an architect's responsibilities is to evaluate application packages in order to check if the packages are compliant with architecture standards, if they can be deployed to the appropriate platforms, if they are secure, if they are scaleable, and so on. Many architects, however, fail to consider how much software packages cost to watch. Not only must operations teams watch software packages to determine whether they are running or whether they are satisfying user requests, but they must also be watched for change. Software is often patched, upgraded, or has its configurations changed in many ways—sometimes frequently. With so many things to watch for and so many options to track, if packages cannot be monitored in standard ways, costs can increase in unexpected ways and IT can become unmanageable.

A Rigid Architecture Framework

In my company, we have as an infrastructure-architecture rule that application servers must run applications, file servers must serve files and folders, and database servers must be used to manage relational data. This means that it is not recommended that I use the same server instance to run an application (a Web server, for example), run the database that it needs, and serve shared files and folders. We established this rule because running systems like this would compromise scalability and increase maintenance costs. For instance, in case of a hardware failure, I would have to reinstall an entire solution—application, database, and files—which would easily consume many hours or days, depending on the size and complexity of the package that I am supporting.

This first happened to me during the course of an application replacement for the human resources (HR) department. We had been using this application to manage employees, payment sheets, and so on, and it had become obsolete. HR had requested that our IT manager search for a packaged solution to replace the old application. Our architectural preference was for J2EE applications, which we communicated to the vendor of the current system in the hopes that they could provide us with a suitable replacement. Luckily, they had one available. A representative from the vendor's company came into our organization to install and test the new application.

Our J2EE platform was based on BEA WebLogic servers running in Linux, so our first test was an effort to try to deploy the vendor's application into a WebLogic/Linux server. I tried to deploy the application, but failed, because the application was designed to run within an Apache Tomcat server, using some particular feature of Tomcat not available to WebLogic. Disappointed, I agreed to install an independent instance of Tomcat in the same WebLogic/Linux server that I used to deploy the application. Again, the deployment failed; certain environment variables—used by the application, but available only under Windows—could not be configured properly on my Linux box.

The original promise of J2EE was that J2EE-compliant beans could be deployable across all brands of J2EE-compliant servers, and across all operating environments, with minimal fuss and effort. However, my "J2EE-compliant" application was able to run only on a Tomcat server, and run only if it could be installed on a Windows machine. We had no choice but to comply with these special conditions, because our only alternative would have been to build the application ourselves, which we could not afford to do. In this case, I had worked to isolate my specialized server from the rest of my J2EE infrastructure. We purchased the application and installed it on the same machine that also ran its own instance of an Oracle database under Microsoft Windows Server 2003.

This approach was totally contrary to our architecture guidelines, but I had no choice in the matter. During production, I had to pay special attention to that particular server, because I could no longer assume that it worked and responded the way that all the other servers did. For instance, when an automatic update ran on that Windows machine, I had to pay close attention and check to see if some missing DLL file stopped the Tomcat Server or caused some similar anomaly that we were generally not prepared to handle.

This turned out to be a costly application to run. We were determined that this would not happen to us again.

Security Issues

Then, one day, we purchased a custody-fund application. While this application performed its core business functions superbly, it lacked critical security features. The application was designed in this way, because the vendor's customers—for historical reasons, or because of preference—tended to implement their own security solutions. We were no exception.

Unfortunately, I discovered that this application required some customization to integrate with our security framework. We did not want to customize this application ourselves, because we thought that this would be too costly to do. We asked the vendor to do this, instead. After six months of collaborating with our internal development team, the vendor delivered us a "security-stable" version of their application. Their solution, however, was dependant upon Microsoft Internet Information Services (IIS) 5.0 Web server, ASP, and, of course, the Windows operating system. Not wanting to repeat our previous mistake of trying to manage a nonstandard system within our organization, we decided to host the application with an external provider. While this solved some immediate operational problems, this solution introduced its own difficulties—such as forcing us to manage daily database updates and mitigate latencies that remote connections create.

This turned out to be a costly application to run. We were determined that this would not happen to us again.

An API Nightmare

The cost of monitoring a nonstandard system was not something that we wanted to pay again, nor did we want to deal with managing another application run on a foreign host. To avoid these problems with our next application—a cash-management system—we decided to have it custom-built. We had not done this before.

The development team of a partner company was contracted to perform the requisite analysis, build the application, document all processes, and propose a software-development model, based on this project. We also wanted them to create a reusable J2EE application framework that we could use to help us lower the cost of developing the next application.

Our mistake was that we did not specify an architecture guideline and a framework environment to guide the development process, before initiating the requisite analysis. The development process was conducted with no restrictions applied to the application programming interface (API) use or integrated development environment (IDE) configuration, code standards, and so on. Worse, yet, developers were free to apply any design pattern that they wanted to use and had never had the chance to use. The project turned into an "API test laboratory." I now have a relatively small number of applications that contain all of the J2EE design patterns that you can imagine.

One result of this disaster is that a simple maintenance task, such as adding a field in a Web form, now affects the entire persistence layer. Problem diagnosis is now nearly an impossible task, because of the complexity of this application. Maintenance and evolution of this system is a nightmare, because my developers spend most of their time trying either to discover how the existing code works or to figure out how to test it.

This turned out to be a costly application to run. We would have been better off running, monitoring, and managing nonstandard systems in our midst. We were determined that this would not happen to us again.

Lessons Learned and Takeaways

  • There is a saying: "Penny-wise, pound-foolish." For the sake of a few inconveniences and a little cost, accept that your architecture should not be too rigid; otherwise, you might cause a chain of events that can lead to you tackling problems that you are not truly prepared to handle.
  • Learn to integrate applications that depend on multiple platforms and operational environments.
  • Know your limitations.

Critical-Thinking Questions

  • How rigid is my architecture framework?
  • Have I prioritized my guidelines?
  • How prepared am I to evaluate third-party applications, to ensure compatibility with my architecture guidelines?
  • How do I mitigate integration issues, instead of avoiding them?

Further Reading

  • McLaughlin, Brett. Building Java Enterprise Applications, Volume I: Architecture, Beijing, China: O'Reilly Media, 2002.
  • Nyberg, Gregory, Robert Patrick, Paul Bauerschmidt, Jeffrey McDaniel, and Raja Mukherjee. Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications. Indianapolis, IN: Wiley Publishing, Inc., 2003.

Glossary

Apache—A Web server for Unix-like systems, Microsoft Windows, Novell NetWare, and other operating systems.

API—An application programming interface. An API is a source-code interface that a computer system or program library provides to support requests for services to be made of it by a computer program.

ASP—Microsoft's server-side script engine for dynamically generated Web pages.

DLL—Also known as a dynamic-link library. A DLL is Microsoft's implementation of the shared library concept in the Microsoft Windows and OS/2 operating systems.

IDE—An integrated development environment. An IDE is a type of computer software that assists computer programmers in developing software.

IIS—Microsoft Internet Information Services. IIS is a set of Internet-based services for servers using Microsoft Windows.

J2EE—Java Platform, Enterprise Edition. Also known as Java 2 EE, J2EE is a programming platform for developing and running distributed, multitier architecture Java applications, based largely on modular software components running on an application server.

Tomcat—A Web container developed at the Apache Software Foundation (ASF).

WebLogic—A J2EE Platform product family, owned by BEA Systems, Inc.

 

About the author

Rogério Cruz is an architect for one of Europe's largest commercial-banking organizations, and is responsible for the development, maintenance, and support of their J2EE-based intranet and Internet systems. His team is responsible for technical regulation, architecture guidelines, and definitions. He works with businesses to create solutions that maximize efficiency and minimize time-to-market. You can contact Rogério at cruzrogerio@yahoo.com.br.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.

Show:
© 2014 Microsoft