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.

1.4 What Is the Starting Point?

So how do you achieve solution value, and how do you begin to organize your thoughts on where to start in application development? If we had to identify the single architectural principle that is the foundation of J2EE and at the heart of the WebSphere product family, we would have to choose layering. Commonly, application development is accomplished in a vertical fashion. At a minimum the division and estimation of work is determined by defining the application's primary user interfaces.
Business rules, behavior, and data are obtained and manipulated based upon activity conveyed via the user interface. It is the responsibility of the architecture to provide a blueprint that guides developers on when and how objects are defined during the development process. The importance of establishing this blueprint is realized in support of the iterative development process, where vertical slices of application functionality are delivered in iterations made up of planning, development, and assessment activities. The architecture must support vertical and horizontal dimensions of an application. Horizontal development activities consist of applying logging, exception handling, and start up/shutdown mechanisms. Basically, this is behavior that must be provided by all applications. Vertical activities involve implementing slices of application functionality from presentation to data source access. Having the infrastructure in place to allow development to occur in these two dimensions is the responsibility of the architecture.
Most experienced IT professionals will agree that developing and adhering to a standard architecture is key to the success of large-scale software development. Computer science pioneer Edsger Dijkstra validated this notion when he developed THE operating system in 1968. Since then, layered architectures have proven their viability in technological domains such as hardware and networking.
Layering has proven itself in the operating system domain; however, the same benefits are available when applied to e-commerce or thin-client oriented applications. Layered architectures have become essential in supporting the iterative development process by promoting reusability, scalability, and maintainability. Next we will define and justify a layered architecture for J2EE and WebSphere that is the foundation for the remainder of this book.

1.3 Today's Enterprise Applications Have New Requirements

With increased competition, lower projected e-commerce profit margins, increased legal issues, and new IT management requirements, three things are expected in today's enterprise applications:
Solution value— solutions that rely on a layered architecture that leverages reuse and 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 sooner.
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.

1.2 How Iterative Development Addresses Key IT Management Issues

To effectively build, deploy, and maintain an enterprise application, the project team should follow a proven process that supports an iterative development lifecycle, such as the Rational Unified Process (RUP).
Regardless of whether the development team follows a widely recognized process or creates its own, it should:
Focus on feasibility issues early in the development cycle— the project can be built incrementally by providing tangible value at each iteration in the cycle (Figure 1.1). The most difficult feasibility issues are addressed early in the process.
Figure 1.1. Iterative development process.
Build on early success— breaking the project up into smaller "chunks" allows the development team to deliver iterations early in the development cycle instead of waiting for the "big bang" delivery of the project as in the more traditional waterfall development process.
Ensure early participation and commitment by end users— while facilitating early discovery of requirements.
Reduce risk to the overall project— while increasing concrete deliverables risk can be reduced with each iteration

1.1 Why Software Development Must Consider the Whole Enterprise

The explosive growth of the Internet has created a truly global marketplace. Because this marketplace is accessible by any customer, anywhere in the world, even small companies have the potential to compete against multinational conglomerates. However, the irrational exuberance for Web-based business-to-business (B2B) and business-to-consumer (B2C) opportunities of the late 1990s is being tempered by the reality that enterprise applications require a sound architecture in order to provide reliability, scalability, performance, and security. To ensure viability in this network economy, companies are using technology to fundamentally change the way they do business. For example, technology is being used to:
Enhance communications through a distributed, connectionless network; providing access to information anywhere, anytime. Mobile computing solutions expand the reach of information by providing wireless solutions that utilize the same technologies and network.
Leverage existing technologies, making existing resources more productive and useful to an increased number of users. It is expensive to produce information—consider the time and effort involved in building a stock transfer or insurance processing system—yet providing an access wrapper into these proven systems is, relative to their total cost, fairly inexpensive. Thus reusing information in new contexts, rather than reimplementing, is a sound business decision. In fact, the wrapping of existing technology is proving to be a significant driver for the success of Web services.
Improve the visibility of information and data, opening new and existing sources of information to a larger population of customers, vendors, employees, and others. Static information can be quickly and easily updated while dynamic solutions can be delivered with minimal effort and programming resources.
Fulfill the promises of distributed computing with flexible, and easy-to-implement programming languages, tools, components, and interfaces. The complexity of building distributed systems, combined with compatibility issues between distributed models such as CORBA and DCOM, created high barriers to entry. Previous attempts at distributed computing tended to break down in heterogeneous environments. To address these issues, the industry has adopted Web services and, in the larger sense, a service-oriented architecture as the base distributed computing model. Combined with the power of the J2EE architecture, this distributed computing technology can be utilized to deliver flexible, high-performance, and standard solutions that can be easily changed to reflect new requirements and design needs.
Streamline and reengineer business processes to do business in ways never before imagined. Self-service applications have moved information closer to the end user and reduced administrative personnel. Electronic-commerce (e-commerce) transaction-based applications have increased marketplace competition and changed the way many companies present and sell goods and services. Internet technologies have lowered the barrier of entry for many start-up ventures and entrepreneurs; allowing them to compete with larger companies. The Web has equalized the playing field for businesses, making many small ones appear larger and many larger companies move like smaller businesses.
In this chapter, we will begin by looking at the motivations for enterprise application architectures and we will end by summarizing the focus of each chapter in this book. We will look at information technology (IT) issues, focusing on the process requirements of building enterprise solutions and look at what is needed overall to respond to competition, business pressures, and new requirements.

Java Chapter 1. Introduction

Welcome to Enterprise Java Programming with IBM WebSphere, 2nd Edition. This book was designed to help you understand how to design, build, and deploy applications based on the Java 2 Enterprise Edition (J2EE) using the IBM WebSphere family of tools and runtime. This book was written for technical managers seeking guidance in understanding J2EE and WebSphere; architects who wish to design scalable, secure enterprise applications; and for the day-to-day developer who wishes to create more robust, consistent code.
You'll find our approach to be a bit different than other books. Rather than simply focusing on the bits and bytes of each technology component that makes up WebSphere, we take a slightly broader view. We will show you how J2EE and WebSphere combine to form an architecture and runtime suitable for large, mission-critical applications.
If you have already invested in the award-winning WebSphere Studio family of tools, or you are considering doing so, this book will ensure that you get the maximum productivity benefits WebSphere has to offer. Through hands-on examples, we will illustrate how the IBM WebSphere Studio family of tools helps you master enterprise application development. These examples will also demonstrate some of the J2EE best practices which are intended to make your development tasks easier, your code more maintainable, and your enterprise projects successful. Along the way, we will also provide rationale for our approaches to building enterprise applications. We will start by discussing the importance of enterprise development, explaining the development process, and presenting the topology of properly layered enterprise applications.