Chapter 9. Putting it all together—a case study
In this chapter
This book details a lot of different patterns, and each pattern handles just one aspect of building a solution, like security, scalability, and integration. But real systems have lots and lots of different challenges that need to be resolved. It’s interesting to see how the patterns can combine to provide a single cohesive solution—that’s what this chapter is about.
The case study discussed in this chapter is divided into two parts: background presenting the problem, and a solution. The problem introduction describes the system that was developed as well as the quality attributes of that project. The second part, which takes up most of the chapter, presents the solution and the patterns that were used in it.
This chapter demonstrates how you can combine multiple patterns to create a larger whole. It also shows how patterns fit into the development lifecycle, demonstrating how to choose appropriate patterns based on the requirements, and offering a glimpse into the implementation of the patterns in that project. (Note that the implementation here is one of many way you can implement this book’s patterns.)
In a nutshell, service orientation is an approach to analyzing some of the aspects of enterprise architecture—specifically functional decomposition, business processes, and data architecture. Applying service orientation means focusing on breaking down business capabilities and functions into business-level services. The business level services are logical components whose composition and interactions provide the business’s processes.
SOA, as explained in the first chapter, is an architectural style (a software concept) concerned with building interconnected coarse-grained components. SOA focuses on flexibility and composition. The resemblance between the “service oriented architecture” and “service orientation” names isn’t accidental. SOA is a good fit for implementing service orientation.
I do know a bit more about software architecture, so let’s focus on that. Figure 9.5 illustrates how the Gridable Service pattern was utilized in the system. The Identification service is the grid root, and it distributes a search to different machines that register on the grid. Within each machine, there’s an instance of the Identification Worker service, which contains a local database that contains part (a shard) of the overall database (we used Cassandra for that) and computational agents—the Identifier Node and Worker components, that work against the database to perform the image search.
We’ve already talked about two components that were used to handle failures: the Saga-Fault event that services can raise when something is wrong, and the Service Instance pattern. The third measure taken against service failure that we’re going to discuss is the implementation of the Service Watchdog pattern in the system.
The point of this chapter isn’t to show off how many patterns I know, or how many we implemented in this case study. The point of this chapter is to provide you with a glimpse into how the patterns in this book can be implemented. The patterns in this book are architectural, and as such they can be interpreted in different ways. The technology mapping section for each pattern only touched on implementations briefly; this chapter has shown a little more detail about what’s involved.
The next, and final, chapter takes a look at another aspect of SOA meeting the real world—how SOA works with other important and common architectures and technologies (REST, the cloud, and big data).