- 1: Start Development with Software Requirements
- 2: Honor Your Users and Communicate with Them Often
- 3: Don't Allow Unwarranted Requirements Changes
- 4: Invest Up Front in Software Architecture
- 5: Don't Confuse Products with Standards
- 6: Recognize and Retain Your Top Talent
- 7: Understand Object-Oriented Technology
- 8: Design Web-Centric Applications and Reusable Components
- 9: Plan for Change
- 10: Implement and Always Adhere to a Production Acceptance Process
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
8: Design Web-Centric Applications and Reusable Components
As in the case of object-oriented programming, not all software architectures are web-centric. With the explosion of the public Internet, corporate intranets, and extranets, however, web-centric software is becoming more universal. This changes not only the way you design software, but also some of the very basic infrastructure requirements. Here are some of the infrastructure components needed for a typical web-centric application:
Database server. A web-centric application typically accesses one or more corporate databases. Unlike a two-tiered client/server application, however, a web-centric application is less likely to access the database directly. More commonly, a web-centric application accesses some sort of middle-tier application server containing the business rules of the application. The middle-tier application then communicates with the database server on behalf of the web-centric client. Such a multi-tiered approach offers many advantages, 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 applications servers.
Web servers. Web servers are used to store and distribute both Java applications and web pages containing text and graphics. Many advanced applications 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 server. A reverse proxy server is typically used to 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 be one of these browsers, or any of the following:
HTML-rendering Java Bean component in your application
Applet viewer built into a Java Development Kit (JDK)
Java application
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 new 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're 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's 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. But it hasn't trivialized software development. From requirements definition through production acceptance, the same disciplines that apply to client/server development hold true for web-centric development.
While embracing web-centric design doesn't necessarily require using reusable components, it certainly is a good place to start. More development organizations every day are investing in the design and development of reusable components. Several of the popular component frameworks have fostered the popularity of reusable components. Let's consider some of the advantages of building reusable components:
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, developers increasingly reuse well-designed components. This reuse is facilitated by component standards such as Java Beans components integration. The cost tradeoff, therefore, is to compare the overhead of reusable design with the average number of times a component can be reused. A reusable component, on average, might cost from 10–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 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's likely that components developed for one project can be reused elsewhere in the organization on other projects.
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.