Influences of Architecture
Architecture influences just about everything in the process of developing software. Architecture gives us the rules and regulations by which we must construct the software and, to some degree, how we even think about the problem. In the early days of computing, we thought of our problems in terms of batch processing. The business problem had to be thought of in terms of assembling a lot of information, formatting it appropriately, and then submitting it to the system for processing. Today, we have interactive systems that can prompt us, walk us through the collection of data, and process that data at much greater speeds than ever before.
The Web has given us a new variation on the standard client/server system. With the proliferation of networks and HTML browsers as standard software,[5] it is now possible to deliver and to deploy a system to users almost anywhere. There are limitations, however, to Web architectures. Their fundamental paradigm of interaction is stimulus/response. The server doesn't control the client directly, and as a general rule, all interaction with the system must be initiated by the client. When this is not the desired behavior, additional elements must be added to the architecture, and the result is a more complex, sometimes brittle system.
[5] Even my phone is capable of browsing Web pages over the Internet.
Web architectures are evolving. In the first edition of this book, most of my experience was with applications based on Microsoft's Active Server Pages (ASP) and the first version of JavaServer Pages. Because these technologies were relatively new, the systems they were used in had relatively simple architectures. The mappings between components and Web pages were simple, and the types of functionality found in the pages' scripts were straightforward. There were drawbacks to these simple architectures. They had a tendency to evolve into difficult-to-maintain monsters.
Today, more and more teams are adopting Web-centric architectures. Collectively, the industry is gaining more and more experience with Web systems. More and more technologies are being applied to Web architectures. The use of patterns and common mechanisms is gaining momentum.[6] All these factors are resulting in Web systems with relatively complex architectures as the norm.
[6] In my opinion, patterns and reusable assets are where the future of software development in general is heading.
In the first edition of this book, the Web Application Extension for UML (WAE) profile was introduced and was suitable for the majority of Web architectures in use at the time. When the first version of the Java Pet Store came out, I used it as a tool for understanding J2EE systems. At first, I had a lot of difficulty making the connections between the documentation supplied by the Blueprints book[7] and the source code. At the time, unfortunately it did not come with UML models,[8] which would have bridged the gap between the high-level text and the source. So I set about creating a UML model of the application. Along the way, I discovered a number of new architectural elements that made it difficult to model with the current version of the WAE. What was well suited to modeling the relatively simple applications of many Active Server Pagebased Web applications was unsuited for the relatively complex architectural elements I found in the Java Pet Store.
[7] Mark Johnson, Inderjeet Singh, and Beth Stearns, Designing Enterprise Applications with the J2EE™Platform, Second Edition (Boston, MA: Addison-Wesley, 2002).
[8] The current release of the Pet Store example does come with a very simple UML model; however, the version I have is little more than a summary of the key Java classes in the application and not a rich model as prescribed by this book.
It wasn't as though the Java Pet Store introduced anything new that couldn't be done with any other Web development platform.[9] It's just that this application used so much of the J2EE API (application programming interface) set and created a well thought-out and robust architecture that it exposed many limitations of the first version of the WAE. The results of that effort have in part contributed to the WAE's evolution into this second version (WAE2-UML).
[9] I'm sure that the marketing folk at Sun Microsystems would argue this point, however.
As a companion resource to this book, I have created a WAE-UML portal on the Internet at www.wae-uml.org. It's my intention to maintain this portal as a resource to those interested in the details of Web modeling and who are looking for additional examples or discussions related to the topic. For the time being, this Web site is hosted by a spare computer I keep in my closet. If for any reason the traffic and activity increase significantly, I'll find a suitable host.
This book, the Web site, reference applications, and models are all intended to help development teams understand the issues involved in building Web-centric applications. The information in this book is presented at varying levels of detail. It is not expected that every reader will use or be interested in every chapter; rather, the entirety of this text is intended for the team as a whole. This book is meant to be a companion to other fine application development books, that address specific aspects of the development process or technology. The reference applications and models are the most detailed source of information applied to a specific example and a great resource for those of us who learn best by example. The Web site is an attempt to keep this information as current as possible, to actively engage practitioners, and to elicit real-world experiences so that the entire community of Web application developers, especially modelers, will be successful in developing applications that work well.