Software Development: Building Reliable Systems

#8 Thou shalt design web-centric applications and reusable components

As in the case of object-oriented programming, not all software architectures will be web-centric. With the explosion of the public Internet, corporate intranets and extranets, however, web-centric software is becoming more and more universal. This changes not only the way you design software, but also some of the very basic infrastructure requirements as well. Here are some of the infrastructure components needed for a typical web-centric application:

• Database server. A web-centric application will typically access one or more corporate databases. Unlike a two-tiered client-server application, however, a web-centric application is less likely to access a database directly. More commonly, a web-centric application would access some sort of middle- tier application server containing the business rules of the application. The middle-tier application would then communicate with the database server on behalf of the web-centric client. There are many advantages to such a multi-tiered approach, including greater application scalability, security, and flexibility.

• Application servers. In a web-centric architecture, application servers implement the business logic of the application. In many cases, this is programmed using the Java language. From a Java program, the Java Database Connectivity (JDBC) API is most often used to connect back to the central database. Specialized application servers may offer services such as DBMS data caching or transactions. A single business function is often broken down into components that execute across many application servers.

• Web servers. Web servers are used to store and distribute both Java applications and web pages containing text and graphics. Many advanced applications will generate web pages dynamically to provide a customized look and feel.

• Caching proxy servers. These servers, while not explicitly part of the application, are typically located strategically across the network to cut down on network bandwidth and provide faster access times to web-based data and applications.

• Reverse proxy servers. A reverse proxy server is typically used o provide remote users secure access over the Internet back to their corporate Intranet.

• Web clients . Until recently, a web client meant either Netscape's Communicator (or Navigator) browser or Microsoft's Internet Explorer browser. Today, a web client could still be one of these browsers, or it could be any of the following:

  • An HTML rendering JavaBean component in your application

  • An applet viewer built into a Java Development Kit (JDK)

  • A Java application

  • A collection of functions built directly into the operating system

One of the main advantages of web-centric design is that it starts taking IT out of the business of supporting heavyweight clients. In fact, most newer operating systems ship with one or more bundled web browsers so no additional client installation is required for a web-centric application. Even if you are deploying to older desktops without a bundled web browser, the popular browsers are available for free and easily installed. If a web-centric application is designed correctly, the end- user client really doesn't matter, as long as an HTML rendering component and Java Virtual Machine (JVM) are present.

If there is any disservice that the web has brought to software development, it is that inexperienced managers may believe that the web has trivialized web-centric software development. True, almost any word processor today can spit out HTML code and dozens of development tools promise "point and click" generation of Java code while the web makes software distribution a non-issue. All of this has allowed web-savvy organizations to develop new applications on "Internet time," several times faster than using traditional client-server environments. Its has not, however, by any means, trivialized software development. From requirements definition through production acceptance, the same disciplines that apply to client-server development hold true for web-centric development. We remind developers of this continually throughout our Web-Centric Production Acceptance (WCPA) process, presented in Chapter 13.

While embracing web-centric design does not necessarily require using reusable components, it certainly is a good time to start. More and more development organizations every day are investing in the design and development of reusable components. Chapter 17 of this book discusses component-based software development in greater detail, along with several of the more popular component frameworks. It is such frameworks that have fostered the popularity of reusable components. Consider some of the reasons why more and more people are investing in reusable component-based design.

It can take longer and be more expensive to design and implement a given function as a reusable component than as a non-reusable one. The savings only come when the component is reused. Especially with web-centric design, however, you will find your developers reusing well-designed components more and more. This reuse is facilitated by component standards such as JavaBeans and the wide range of development tools that support JavaBeans component integration. The cost trade off, therefore, is to compare the overhead of reusable design with the average number of times a component is expected to be reused. A reusable component, on average, might cost from 10% to 25% more to develop. Few development managers today could justify a 25% cost and schedule overrun just to save the next project money. However, properly implemented, reusable components can begin saving a project money today.

• If you invest in the design of reusable components and an accompanying framework, you will undoubtedly find components you can reuse from elsewhere in place of some of the code you would otherwise develop.

• It is likely components developed on your own project can be reused elsewhere in the organization.

• You can buy and sell components (either externally, or by exchanging with other development groups inside your company)

• Well built components are much easier to swap out and upgrade.