2.1 Case Study Analysis and Design Artifacts

What Type of A&D Process Is Appropriate for Web Applications?
A question we are commonly asked in our consulting practice is what advice we can give about setting up a development process for Web applications. Simple question. Difficult answer. The problem is that Enterprise Java applications can be approached from two sides—Web-up and enterprise-down.
The Web-up approach is where a Web site built using ad-hoc, seat-of-the-pants development methods must suddenly be rearchitected to scale up to thousands—or millions—of users to meet new demands. In this case, we see that there is often no development process in place, as it has not been necessary in the small-team environment that most Web shops employ. The enterprise-down approach is where a traditional IT organization finds it must reinvent itself to address the needs of customers and partners on the global Internet. In this case, there is often a set of development practices in place, but they do not necessarily apply to the development tools, techniques, and timescales that Web development necessitates.
We have found a happy medium where most groups doing Enterprise Java development can reside. We often recommend that our clients begin by looking at two books—Extreme Programming Explained by Kent Beck [Beck] and UML Distilled 3rd Ed. by Martin Fowler [Fowler].
Extreme programming (XP), the subject of Beck's book, is a radical revisiting of old theories about software development. It proposes a very rapid, highly productive development cycle that is characterized by constant testing, minimal up-front design, and tight control of software iterations. We have seen several cases where small teams (in the range of 3 to 10 programmers, which is about the limit of what XP can handle) can produce very high-quality software in a very short time using this process. On the other hand, there is often a need for some slight formalism in analysis and design artifacts, specifically where developers are learning new technologies, and need to be able to see, at a glance, where the new technologies fit into an overall picture of a software system. For this purpose we often recommend that an XP-like process be combined with some (but not all) elements of UML. Since many Web programmers (coming from both sides) are very visual people, we have seen that they may prefer a more diagrammatic approach to rapid design than the text-based CRC-card approach suggested by [Beck]. We often take this XP-plus-UML approach ourselves, and it is what we recommend for most small teams beginning to learn Enterprise Java technologies.
However, there may be a need for a more large-scale approach. If a team is large (over 15 people) or it must produce specific requirements and design documentation to fit an existing corporate or governmental process, then a more elaborate technique like RUP (described in [Jacobson]) may apply. While RUP is a well-understood and complete process, we feel that it may be overkill in many cases, as it does not accommodate itself well to either Web timescales or team sizes. However, there are those cases for which it must be chosen.
Another approach that is just emerging, and is particularly well-suited for developing enterprise applications, is model-driven development (MDD). MDD separates concerns by developing a platform-independent model (PIM) of the business application. This model focuses on the business domain, simplifying the domain discovery process by separating the complexities introduced by architecture and implementation domains.
The PIM is then translated by automated tools to a platform-specific model (PSM), using translation patterns that are developed for a particular deployment architecture and implementation language, like J2EE. These transformation patterns can be developed by platform experts and provide an excellent way of formalizing and codifying the architectural rules and best practices. See http://www.omg.org for further details.
You must consider carefully your timescales and the size of your team before you select a development process. The same process may not be appropriate for different projects

Chapter 2. Introduction to the Case Study

Learning a new technology is often complicated by the fact that most sources of information tend to throw a lot of acronyms and new terms at you without providing any context. It's just as important to understand where and why to use a new technology as it is to understand how to use it. In this book we'll present most of the examples of how you use each technology in the context of a case study about a company developing a simple J2EE application for tracking hours spent on projects.
This sort of time tracking—for instance, consultants and legal firms track time spent on projects so that they can bill their hours—is common in many companies. Many other companies have in-house service groups (such as IT organizations) that must track time for internal billing purposes. What's more important, though, is that the example is complicated enough, both from a UI and a domain object perspective, to provide a backdrop complex enough to show you how to apply J2EE technologies in a real-world environment.

1.6 Layered Architecture Benefits

With increased competition, lower projected e-commerce profit margins, increased legal issues, and new IT management requirements, what is needed is an architecture that provides:
Solution value— reliance on a layered architecture that leverages reuse produces dynamic, scalable, solutions that can be easily changed to meet new business needs.
Speed to market— a focus on the business domain and not the application infrastructure can help meet the ever-growing strategic application backlog. By using a repeatable standard development process that reuses legacy information and systems, a development team can begin to bring solutions to the marketplace faster.
Secure solutions— by protecting assets, legally and technically, an IT organization can not only produce flexible solutions, it can also give the enterprise a strategic advantage in the marketplace.
That architecture framework is the J2EE platform

1.5 What Is a Layered Architecture?

What is a layered architecture, and what does layering mean? Application layering is the separation of architectural concerns whose boundaries are supported by interface contracts. Typically, these layers are stacked vertically so that each layer interacts only with the layer directly underneath it (Figure 1.2).
Figure 1.2. Layers.
Because an interface contract exists between each layer, changes can be affected on Layer 3 with minimal side effects on Layer 1. Moreover, Layer 3 can be totally replaced, as long as it meets Layer 2's contract, without affecting Layer 1. This property is known as strict layering.
As mentioned earlier, the principle of layering is core to J2EE and WebSphere. From the J2EE perspective, this concept has been the driving force behind much of the standards work that defines the platform. This can be seen in how presentation and data access are designed. The WebSphere Application Server fully leverages this architecture by allowing individual layers to be scaled and distributed independently.
Critics of strictly layered architectures argue that performance, and sometimes extensibility, are sacrificed since more activity is required to propagate down through the layers. Extensibility can suffer if contracts defined between the layers are not robust enough to handle future requirements. However, being able to strategically distribute the application layers, use the domain layer across multiple applications, and easily configure different data sources and user interfaces overcomes such criticism.
Nonstrict layering (Figure 1.3) allows higher layers to access any layer defined below it and answers the critics' arguments against performance and extendibility; however, it nullifies the benefits of strict layering.
Figure 1.3. Nonstrict layering.

1.5.1 Common layering schemes
Traditional two-tier client/server-based applications can be partitioned into two layers—presentation and data access. A two-tier Graphical User Interface (GUI) application would simply query a data source, compute, and display the information to the user. A consequence of this simple architecture is that knowledge about the business domain is both scattered throughout the user interface, and is forced into complex database schemas.
Object technology encourages not only the abstraction and reuse of presentation logic, but also business processes and data. Therefore, decoupling application logic from application presentation results in scalable three-tier distributed systems that allows objects defined to model business data and processes to be used across application boundaries. With the explosion of the Internet and related technologies, enterprise application requirements have made the existence of layered application architecture imperative.
The most common layers of an application can be partitioned into presentation, domain, and data source sections (Figure 1.4). The most important layer is the domain. This is where business process and state are captured. Presentation layer objects either consume or exercise domain objects. Data source objects defined in the data source layer access specific data sources on behalf of domain objects requesting or saving state.
Figure 1.4. Client/server layers.
It is not enough to merely stipulate the layers in a graphic and expect developers to properly partition application elements into a layered architecture. Developers must implement functionality within each layer in a consistent fashion. Moreover, message interaction between layers must be formalized.
Formalizing layer interaction should involve a decoupled design that includes appropriate indirection in support of layer substitution. Additionally, behaviors prescribed across all applications, namely exception handling, logging, start up, and shutdown operations, should be formalized and consistently applied.
1.5.2 Layered Architecture Definition
The primary motivation for layering is to create and preserve a reusable domain model that spans application boundaries. Other advantages to this architecture are that it helps organize the project and allows construction and validation of each layer to vary independently. Of course this can be accomplished with three layers; however, introducing two additional layers between presentation and data source layers further decouples the domain from application presentation and data source requirements (Figure 1.5). An example of layer substitution would be enabling the domain layer for pervasive devices or a voice response unit. In Figure 1.5, this would imply creating only the new presentation layer constructs and the necessary mediators to interact with the existing domain model.