Flylib.com

Books Software

 
 
 

Developing the Case Study


Developing the Case Study

My experience with patterns is that the behavior and implementation of patterns is a mystery even after considerable thought and paper diagramming. Of course, if you are a student, your experience is probably to go ahead and implement the pattern as part of an exercise for class. My intent in this book is to give you the generic perspective that is useful in a pattern yet also hand you an implementation of the pattern that runs within the context of a larger application.

To fulfill this intent, I spend a chapter defining a fictitious company, the business drivers that lead to an update in the company's application, and the requirements that lead to an application that leverages Web Services. It would be exceptional if I could show you how to implement a complete Enterprise Resource Planning (ERP) system and we could sit and dissect it for weeks, but I have decided to use a smaller, more contained application centered on opening a coffee company to the broader world. My grandfather's coffee company, the P.T. Monday Coffee Company (based in Milwaukee, Wisconsin, throughout the early 1900s), serves as the foundation for the case study. What makes this situation unique is showing how a niche player in the coffee industry can take advantage of Web Services to become a player in a larger integrated value chain.

Once I have laid out the groundwork for the company, I spend the remainder of the book showing various patterns and how those patterns fulfill the application architecture, design, and implementation.

At the time of publication, I did not have a complete application; rather, I focused on the pattern samples for Web Services. Over time, my intention is to fill out the application in the SourceForge open -source project. Details about how to download and run the application are available in Appendix A.



Who Should Read This Book

Application architects , designers, and programmers who are interested in refining their knowledge of Web Services should read this book, as well as programmers who are interested in getting hands-on experience with Apache Axis. Ideally, a reader of this book has some sophistication in the Unified Modeling Language (UML), the Java 2 platform, software patterns, and Web Services. Anyone with fewer than three to four years of experience in programming systems, designing systems, or architecting systems should take the time and care to understand the constructs introduced in the book and read the references in the "Additional Reading" sections.

Several chapters discuss the patterns that the Web Service platform embodies. These chapters do not intend to introduce a specific Web Service platform implementation, but they should be enough to give you a good understanding of the underlying motivations and organization of most platforms. When I discuss a specific Web Service platform, I use the Apache Axis platform that plugs into the Apache Tomcat engine.

Finally, my target audience should have practical experience with software patterns. Although this is not a mandatory prerequisite, it is helpful to understand the level of abstraction at which I approach each pattern.



How the Book Is Organized

Pattern books take a variety of directions to portray patterns to the reader. Some books use rigid templates, and others lean more toward readable prose. Purists usually like the prior, and book readers, like me, like the latter. To be honest, I think pattern books should serve both types of readers. I have taken the approach to organize the book as a readable, prose -based, stand-alone piece of work.

A brief introduction to the topic of Web Service Patterns leads off the book. Next, I present the high-level requirements, business drivers, and architecture of the case study. After the case study, the chapters discuss various software patterns and how each one fulfills the system structures embodied in the high-level architecture. I introduce a single pattern per chapter (with the exception of two chapters that introduce variants and a necessary dependent pattern) along with how the pattern fulfills the needs of the case study. In addition to how the pattern specifically addresses the case study, each pattern documents the more general problem and solution that the pattern addresses. Figure 1 illustrates the relationships between the patterns.

click to expand
Figure 1: Pattern relationships

The patterns come in five categories:

Learning It is important to understand the Web Service environment, where it originated from, and the mechanisms that help it fulfill its purposes of implementation and location transparency. The "learning" patterns fulfill this need.

Adapting These patterns help refine your knowledge of a Web Service environment. These patterns change your way of thinking from object orientation to a flatter, more component-like approach for building representations of data and processes. The "adapting" patterns are used throughout the remainder of the book as base patterns.

Determining changes Throughout my career I have been interested in messages and events. Although Web Services have asynchronous calls and although the service implementations could be based on a message-oriented architecture, I still find the traditional event patterns (the Observer and Publish/Subscribe patterns) interesting in the environment. They add a mechanism that programmer's expect from today's services.

Refining These patterns are necessary enhancements to disprove that Web Services are monolithic in nature. Web Services are simply an access mechanism to behavior implemented in a language. These patterns help you understand the Web Service environment better and help you mold the environment to your own needs.

Creating flexibility Finally, you can create more flexible Web Services that better suit your needs with a few additional patterns. The patterns in this category could easily be shuffled throughout different points in the book, but I chose to put them at the end because they are simply internal mechanisms and contracts to Web Services that help create a more optimized and flexible environment. In essence, they are extensions of the other patterns, not base patterns.

Note  

Some of the later patterns in the book could easily be rearranged. For example, the Service Factory pattern could follow the Business Process pattern. The Physical Tiers pattern could follow the Service-Oriented Architecture pattern. I chose to structure the book in a way that would help you best learn the Web Service environment. In this spirit, I waited as long as I could before I ratcheted up the complexity with patterns such as the Physical Tiers pattern and Service Factory pattern.

Finally, I present a variety of architectural, design, and implementation patterns (idioms) in the book. Several times, you will have to switch hats from architecture to design, but I hope to create a logical flow as to how you would go about understanding a complete application.