This chapter is from the book
This chapter is from the book
This chapter is from the book
1.3 What's This Book About?
There are several complementary things going on in this book. On the one hand, it's an introduction to J2EE technologies, and can serve as a primer for anyone interested in learning about J2EE. The book emphasizes Web Services, so if you are already somewhat familiar with J2EE, but looking to dig more deeply into those technologies that can be used in the development of Web Services, then you should find more information about those topics here than in J2EE books with a different focus. Finally, it's a book about application architecture and design. I'm a strong believer that good software evolves; in fact, Web Services are a perfect example of this. Many companies today are faced with adding Web-Service functionality to existing applications. The degree to which they'll be able to do so easily is directly related to how much flexibility was designed into their applications initially. By using the same application over and over again within this book, deploying it as a standalone application, a servlet, a Web Service, and in other configurations, you'll see how an application can be designed to handle whatever future changes might be required.
Throughout the course of the book, I'll take a simple set of Java classes and evolve them into a number of different architectures. The purpose is twofold. Primarily, you want to gain an understanding about the various architectures that are available. This includes how difficult they are to implement, how well they perform, how well application development tools support the architecture, and similar factors. The secondary goal is to learn what features vary widely between architectures, and what things stay largely the same. By understanding this, we can segregate the architecture-dependent portions of an application so that if we choose, we can change the application architecture at some time in the future in a straightforward manner.
When I speak of changing application architecture, it doesn't mean changing the functionality provided by the application; instead, it means changing the environment in which the application runs. Architectural changes might be changes in the user interface technology used, changes in the way data is stored by the application, or changes in the way the application is distributed across multiple computers and how those distributed components are tied together.
In this book, the initial application will go through lots of changes along the way. Some of those changes will be permanent, as we discover better ways to structure the application to make it more flexible in adapting to different environments. Other changes might be specific to just one architectural model, and not carried forward into later versions; but that doesn't necessarily mean that they represent a dead end.