SOA Patterns

Arnon Rotem-Gal-Oz

• Editore: Manning Publications
• Anno: 2012
• ISBN:
  9781933988269
• Argomento: Informatique
• Categoria: Assurance qualité et tests

SOA Patterns provides architectural guidance through patterns and anti-patterns. It shows you how to build real SOA services that feature flexibility, availability, and scalability. Through an extensive set of patterns, this book identifies the major SOA pressure points and provides reusable techniques to address them. Each pattern pairs the classic problem/solution format with a unique technology map, showing where specific solutions fit into the general pattern.

Part 1. SOA patterns

This is a book about service-oriented architecture (SOA) and about solving the challenges involved in implementing it. We’ll discuss that in two parts. Part 1, the first seven chapters, discusses SOA and a range of architectural patterns, demonstrating them in numerous examples; part 2, chapters 8–10, looks at how it all works in real life.

Chapter 1 introduces SOA and its components (services, consumers, messages, endpoints, contracts, and policies) as well as the patterns approach. The subsequent chapters detail the different patterns.

Chapter 2 takes a look at foundation patterns—basic patterns that are needed to get started with implementing services. Chapter 3 covers patterns related to performance, scalability, and availability. Chapter 4 looks at what’s needed to secure services and monitor their overall wellness. Chapter 5 details message exchange patterns, starting with the basic request/reply model and ending with long-running interactions. Chapter 6 covers patterns related to how consumers interact with services. Chapter 7 examines service composition patterns that show how you can go from a bunch of services to a system.

The patterns presented in the book are architectural patterns, and the architecture is driven by quality attributes (also known as nonfunctional requirements or “illities”). The discussion of each pattern also has a quality attributes section detailing sample scenarios. Appendix A provides a cross reference from quality attributes to the patterns and can be used to quickly look up relevant patterns.

Chapter 1. Solving SOA pains with patterns

In this chapter

• What is software architecture
• What SOA is and isn’t
• Pattern structure

How do you write a book on service-oriented architecture (SOA) patterns? As I pondered this question, it led to many others. Should I explain the context for SOA, or explain the background that’s needed to understand what SOA is? Should I mention distributed systems? Should I discuss when an SOA is needed, and when it isn’t? After much thought, it became apparent to me: a book on SOA patterns should be a practitioner’s book. If you’re faced with the challenge of designing and building an SOA-based system, this book is for you.

You might not even agree with an SOA-based approach, but are forced into using it based on someone else’s decision. Alternatively, you may think that SOA is the greatest thing since sliced bread. Either way, the fact that you’re here, reading this, means you recognize that building an enterprise-class SOA-based system is challenging. There are indeed challenges, and they cut across many areas, such as security, availability, service composition, reporting, business intelligence, and performance.

To be clear, I won’t be lecturing you on the merits of some wondrous solution set I’ve devised. True to the profession of the architect, my goal is to act as a mentor. I intend to provide you with patterns that will help you make the right decisions for the particular challenges and requirements you’ll face in your SOA projects, and enable you to succeed.

Before we begin our journey into the world of SOA patterns, there are three things we need to discuss:

• What is software architecture? The “A” in SOA stands for architecture, so we need to define this clearly.
• What is a SOA? This is an important question because SOA is an overhyped and overloaded term. We need to clearly define the term that sets the foundation for this book.
• How will each pattern be presented in the book? I’ve used a consistent structure to explain each of the patterns in this book. We’ll take a quick look at this structure so you know what to expect in the discussion of each pattern.

Let’s get started with the first question—what is software architecture?

1.1. Defining software architecture

There are many opinions as to what software architecture is. One of the more accepted ones is IEEE’s description of software architecture as the “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” (IEEE 42010). My definition agrees with this one, but is a bit more descriptive:

Definition

Software architecture is the collection of fundamental decisions about a software product or solution designed to meet the project’s quality attributes (the architectural requirements). The architecture includes the main components, their main attributes, and their collaborations (their interactions and behavior) to meet the quality attributes. Architecture can, and usually should, be expressed in several levels of abstraction, where the number of levels depends on the project’s size and complexity.

Looking at this definition, we can draw some conclusions about software architecture:

• Architecture occurs early. It should represent the set of earliest design decisions that are both hardest to change and most critical to get right.
• Architecture is an attribute of every system. Whether or not its design was intentional, every system has an architecture.
• Architecture breaks a system into components and sets boundaries. It doesn’t need to describe all the components, but the architecture usually deals with the major components of the solution and their interfaces.
• Architecture is about relationships and component interactions. We’re interested in the behaviors of the individual components as they can be discerned from other components interacting with them. The architecture doesn’t have to describe the complete characteristics of the components; it mainly deals with their interfaces and other interactions.
• Architecture explains the rationale behind the choices. It’s important to understand the reasoning as well as the implications of the decisions made in the architecture because their impact on the project is large. Also, it can be beneficial to understand what alternatives were weighed and abandoned. This may be important for future reference, if and when things need to be reconsidered, and for anyone new to the project who needs to understand the situation.
• There isn’t a single structure that is the architecture. We need to look at the architecture from different directions or viewpoints to fully understand it. One diagram, or even a handful, isn’t enough to be considered an architecture.

For a software system’s architecture to be intentional, rather than accidental, it should be communicated. Architecture is communicated from multiple viewpoints to cater to the needs of the stakeholders. The Software Engineering Institute (SEI) defines an architectural style as a description of component types and their topology, together with a set of constraints on how they can be used.

1.2. Service-oriented architecture

The term SOA was first used in 1996 when Roy Schulte and Yeffim V. Natiz from Gartner ...