SOA Patterns

Copyright

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact

      Special Sales Department

      Manning Publications Co.

      20 Baldwin Road

      PO Box 261

      Shelter Island, NY 11964

      Email:

[email protected]

©2012 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

ISBN 9781933988269

Printed in the United States of America

Dedication

To Aya, Tohar, Neder, and Yarom You make my life rock!

Brief Table of Contents

Copyright

Brief Table of Contents

Table of Contents

Patterns and Antipatterns Covered Inside

Foreword

Preface

Acknowledgments

About this Book

About the Author

About the Cover Illustration

1. SOA patterns

Chapter 1. Solving SOA pains with patterns

Chapter 2. Foundation structural patterns

Chapter 3. Patterns for performance, scalability, and availability

Chapter 4. Security and manageability patterns

Chapter 5. Message exchange patterns

Chapter 6. Service consumer patterns

Chapter 7. Service integration patterns

2. SOA in the real world

Chapter 8. Service antipatterns

Chapter 9. Putting it all together—a case study

Chapter 10. SOA vs. the world

From quality attributes to patterns

Index

List of Figures

List of Tables

List of Listings

Table of Contents

Copyright

Brief Table of Contents

Table of Contents

Patterns and Antipatterns Covered Inside

Foreword

Preface

Acknowledgments

About this Book

About the Author

About the Cover Illustration

1. SOA patterns

Chapter 1. Solving SOA pains with patterns

1.1. Defining software architecture

1.2. Service-oriented architecture

1.2.1. What SOA is, and is not

1.2.2. SOA architectural benefits

1.2.3. SOA for the enterprise

1.3. Solving SOA challenges with patterns

1.3.1. Pattern structure

1.3.2. From isolated patterns to a pattern language

1.4. Summary

1.5. Further reading

Distributed Systems

Fallacies of Distributed Computing

SOA

Chapter 2. Foundation structural patterns

2.1. Service Host pattern

Problem

Solution

Technology Mapping

Quality Attributes

2.2. Active Service pattern

Problem

Solution

Technology Mapping

Quality Attributes

2.3. Transactional Service pattern

Problem

Solution

Technology Mapping

Quality Attributes

2.4. Workflodize pattern

Problem

Solution

Technology Mapping

Quality Attributes

2.5. Edge Component pattern

Problem

Solution

Technology Mapping

Quality Attributes

2.6. Summary

2.7. Further reading

Service Host Pattern

Transactional Service Pattern

Workflodize Pattern

Edge Component Pattern

Chapter 3. Patterns for performance, scalability, and availability

3.1. Decoupled Invocation pattern

Problem

Solution

Technology Mapping

Quality Attributes

3.2. Parallel Pipelines pattern

Problem

Solution

Technology Mapping

Quality Attributes

3.3. Gridable Service pattern

Problem

Solution

Technology Mapping

Quality Attributes

3.4. Service Instance pattern

Problem

Solution

Technology Mapping

Quality Attributes

3.5. Virtual Endpoint pattern

Problem

Solution

Technology Mapping

Quality Attributes

3.6. Service Watchdog pattern

Problem

Solution

Technology Mapping

Quality Attributes

3.7. Summary

3.8. Further reading

Decoupled Invocation

Parallel Pipelines

Gridable Service

Chapter 4. Security and manageability patterns

4.1. Secured Message pattern

Problem

Solution

Technology Mapping

Quality Attributes

4.2. Secured Infrastructure pattern

Problem

Solution

Technology Mapping

Quality Attributes

4.3. Service Firewall pattern

Problem

Solution

Technology Mapping

Quality Attributes

4.4. Identity Provider pattern

Problem

Solution

Technology Mapping

Quality Attributes

4.5. Service Monitor pattern

Problem

Solution

Technology Mapping

Quality Attributes

4.6. Summary

4.7. Further reading

Secured Message

Secured Infrastructure

Chapter 5. Message exchange patterns

5.1. Request/Reply pattern

Problem

Solution

Technology Mapping

Quality Attributes

5.2. Request/Reaction pattern

Problem

Solution

Technology Mapping

Quality Attributes

5.3. Inversion of Communications pattern

Problem

Solution

Technology Mapping

Quality Attributes

5.4. Saga pattern

Problem

Solution

Technology Mapping

Quality Attributes

5.5. Summary

5.6. Further reading

Inversion of Communications

Inversion of Communications

Saga

Chapter 6. Service consumer patterns

6.1. Reservation pattern

Problem

Solution

Technology Mapping

Quality Attributes

6.2. Composite Front End (Portal) pattern

Problem

Solution

Quality Attributes

6.3. Client/Server/Service pattern

Problem

Solution

Technology Mapping

Quality Attributes

6.4. Summary

6.5. Further reading

Composite Front End

Client/Server/Service

Chapter 7. Service integration patterns

7.1. Service Bus pattern

Problem

Solution

Technology Mapping

Quality Attributes

7.2. Orchestration pattern

Problem

Solution

Technology Mapping

Quality Attributes

7.3. Aggregated Reporting pattern

Problem

Solution

Technology Mapping

Quality Attributes

7.4. Summary

7.5. Further reading

Service Bus

Orchestration

Aggregated Reporting

2. SOA in the real world

Chapter 8. Service antipatterns

8.1. Knot antipattern

Consequences

Causes

Refactoring

Known Exceptions

8.2. Nanoservice antipattern

Consequences

Causes

Refactoring

Known Exceptions

8.3. Transactional Integration antipattern

Consequences

Causes

Refactoring

Known Exceptions

8.4. Same Old Way antipattern

Consequences

Causes

Refactoring

Known Exceptions

8.5. Summary

8.6. Further reading

Knot

Transactional Integration

Chapter 9. Putting it all together—a case study

9.1. Problem

System Requirements

Quality Attributes

9.2. Solution

Structure (Edge Component, Gridable Service, Parallel Pipelines)

Communications (Inversion of Communications, Service Bus, Saga, Reservation)

Availability (Service Instance, Service Watchdog)

9.3. Summary

Chapter 10. SOA vs. the world

10.1. REST vs. SOA

10.1.1. What is REST anyway?

10.1.2. How REST and SOA are different

10.1.3. RESTful SOA

10.2. SOA and the cloud

10.2.1. The cloud terminology soup

10.2.2. The cloud and the fallacies of distributed computing

10.2.3. The cloud and SOA

10.3. SOA and big data

10.3.1. The big data technology mix

10.3.2. How SOA works with big data

10.4. Summary

10.5. Further reading

Rest

The Cloud

Big Data

From quality attributes to patterns

A.1. Introduction to quality attributes

A.2. From quality attributes to patterns

Index

List of Figures

List of Tables

List of Listings

Patterns and Antipatterns Covered Inside

Patterns

Service Host 19

Active Service 24

Transactional Service 29

Workflodize 35

Edge Component 39

Decoupled Invocation 47

Parallel Pipelines 51

Gridable Service 56

Service Instance 61

Virtual Endpoint 64

Service Watchdog 67

Secured Message 75

Secured Infrastructure 80

Service Firewall 86

Identity Provider 91

Service Monitor 98

Request/Reply 108

Request/Reaction 114

Inversion of Communications 120

Saga 129

Reservation 140

Composite Front End (Portal) 148

Client/Server/Service 154

Service Bus 162

Orchestration 170

Aggregated Reporting 177

Antipatterns

Knot 190

Nanoservice 195

Transactional Integration 202

Same Old Way 206

Foreword

Building distributed yet integrated systems remains a difficult problem to solve. First, it requires a solid understanding of the individual components to be connected. Next, we have to connect these components in a way that balances loose coupling against system-wide requirements, such as latency and security. Last but not least, the resulting system has to be monitored and managed. Over time, a number of approaches have set out to solve these challenges: distributed components, EAI messaging, and, more recently, service-oriented architectures (SOA). While these approaches and tools have been a tremendous help, there is still no easy step-by-step recipe for balancing potentially opposing requirements into a coherent solution.

This is why design patterns are such a critical resource for building successful SOA solutions. Patterns encode knowledge and experience in a way that can be applied in a variety of contexts and technologies. They are not a one-size-fits-all silver bullet, but they do present forces and counterforces that steer us toward a reusable, well-balanced solution. At the same time, they form an important vocabulary that allows us to communicate our design decisions succinctly and precisely.

Arnon has harvested design decisions from years of building SOA solutions and has encoded his knowledge and experience in this book. He presents a conceptual framework of an SOA, which serves as the roadmap through various aspects of SOA design. For each aspect, he shares actionable guidance and examples from real-world project experience. At the end, he pulls all the pieces together in a real-world case study.

Rather than compiling a tome of every possible pattern that could be relevant to an SOA, Arnon selected and documented a core set of patterns and arranged them in a logical fashion. He discusses the trade-offs and design decisions involved in applying each pattern in detail, down to actual code examples. Like most tools, SOA patterns can be used, but also abused or overused. That’s why Arnon takes care to warn us of the temptation to SOA-ify every architectural nail with our newfound SOA hammer.

When Bobby Woolf and I wrote Enterprise Integration Patterns, Web Services had just entered the technology arena, and there was little knowledge and experience on how to turn individual services into a full-fledged service-oriented architecture. So, we decided to focus on messaging patterns first, with the hope of covering service patterns in the future. Alas, we never managed to complete that formidable task, so we are doubly thankful to Arnon—not only did he document the significant body of knowledge on SOA, he also filled in an important gap that we had left. Well done.

GREGOR HOHPE COAUTHOR OF ENTERPRISE INTEGRATION PATTERNS

Preface

In 1996, I led development in a small startup. I had worked on multiuser systems before, but this was the first big distributed system I wrote. I found out the hard way that it isn’t a simple task—a lot can and does go wrong, and simplified assumptions you make at the onset will come back to haunt you.

I learned my lesson, and I’ve been developing distributed systems ever since. Over the years, I discovered service-oriented architecture (SOA), and I found that, with its emphasis on interfaces and flexibility, it’s a really good way to build distributed systems and it brings a lot of benefits. As I spent a few years working on many projects, I saw that a lot of people misuse SOA, that a lot don’t understand it, and that good advice is hard to find. I decided to write a book—the year was 2006.

It is now 2012 and the book is finally finished. Any author will tell you that writing a book is hard, and it takes more time than initially thought. This is all true, but that’s not my excuse. I finished the first third of the book reasonably on schedule, but then I joined another startup, which consumed every shred of free time I had for almost four years. On the upside, I gained more experience and I went over what I had written and updated the technology mapping sections, so you’re essentially getting a second edition now. Also, the startup that prevented me from completing this book stars as the case study for chapter 9, so it did contribute something to the book as well.

Why patterns? That has to do with the first startup where I worked. As we worked on the development of the user interface (UI), I had this innovative idea—we should separate the UI logic from the UI controls and from the data-access code. This would give us more flexibility and better testability. It was only later that I learned that my innovation had been developed in the 1970s. It also had a name, and it was also more refined and solved the problem better—it was the Model-View-Controller (MVC) pattern. This discovery of documented architectural solutions and the time they can save in development sparked my interest in software patterns.

I really like the fact that patterns present a problem in context and don’t presume the solution is always correct. I think that’s a great way to present a topic, and it also let me break the book into independent bits, which makes the book usable as a reference and not something you need to read cover to cover.

One point about this book that’s relatively unique is that I wrote about architectural patterns and not design patterns. I think it is beneficial to provide guidance at the architectural level and to understand the impact it has on the system as a whole, and not focus solely on the local effect as design patterns do. This is especially important when we’re talking about SOA, because SOA is about the overall system more than it is about individual components. Another important benefit of focusing on architecture is that architecture transcends technology. The technology mapping section for each pattern shows just some examples of where each pattern can be used; you can apply the ideas using the technology of your choice.

This book summarizes my experience writing distributed systems in general, and SOA systems specifically. I hope you find it useful.

Acknowledgments

Writing a book takes a major effort, and even though my name is on the cover, there are a lot of people without whom this wouldn’t have happened. I’d like to thank David Stommer—the first person who said he would buy the book, back when I had the crazy idea to write it. A thank you is also due to Roy Osherove for introducing my SOA patterns idea to Manning.

A huge thanks goes to the Manning team for keeping the faith and pushing me forward. Specifically, I’d like to thank Michael Stephens, who not only contacted me with the offer to start this project but also kept nagging me to finish it. I’d like to thank Cynthia Kane, my development editor, for her patience and help in making the narrative more compelling. Also a huge thank you to Andy Carroll, my copyeditor, for taking my blubber and turning it into succinct English, and to Elizabeth Martin, my proofreader. Another thank you goes to Olivia Booth for organizing the reviews. And while he’s not a Manning member, I’d also like to thank Eric Bruno who unfortunately couldn’t join me as a coauthor but who did a lot of housekeeping and helped organize the book.

More thanks go to the following reviewers for providing feedback and helping make this book better: Antti Koivisto, Barry Polley, Clarence Scates, Dan Dobrin, Darren Neimke, Dave Crane, Eddy Vluggen, Eric Bowman, Eric Farr, Glenn Stokol, Gregor Hohpe, Kunal Mittal, Pat Dennis, Rick Wagner, Robert Trausmuth, Robin Anil, Roy Prins, Srikanth Vadlamani, Stephen Friend, Tijs Rademakers, and Udi Dahan.

Special thanks to Gregor Hohpe for contributing the foreword to my book and to Karsten Strøbæk for reviewing the manuscript and for his technical proofread of the book just before it went into production.

I’d especially like to thank my wife, Aya, for pushing me to man up and finish the book, and for spending nights alone while I wrote it.

Last but not least, I would like to thank all the MEAP readers, who, even though the book took ages to complete, kept on buying more and more copies and helped motivate me to complete it.

About this Book

Service-oriented architecture has been around for years now. The hype surrounding it in the past has finally waned, and we are now free to do real work and build real systems using it.

Do not mistake the lack of hype for a lack of relevance. If anything, SOA is more relevant than ever, as it’s practically the only good way to build cloud-based solutions (something I’ll discuss in chapter 10). Additionally, the SOA landscape has become more complicated over the years because SOA is now living side-by-side (or is integrated) with other architectures like event-driven architecture, REST, and big data (discussed in chapters 5 and 10).

SOA-related technologies are more mature now, but technology alone is not enough without proper architecture. That’s the main point behind this book: solving the architectural challenges of distributed systems in general and of SOA specifically by using architectural solutions expressed as patterns and antipatterns.

Roadmap

Part 1 of this book focuses on SOA patterns. It looks at ways to solve SOA challenges by using contextual solutions:

Chapter 1 introduces SOA, its components, their relations, and the benefits of SOA. The chapter also introduces the concept of patterns and the pattern structure used in the book.

Chapter 2 introduces some of the fundamental building blocks for building services.

Chapter 3 tackles the core challenges of SOA, namely performance, scalability, and availability. These aspects are hard to get right because SOA adds latency by its very nature (because there are more components and distribution).

Chapter 4 takes a look at different aspects of security and the management of services. Security is often a neglected part of any solution, and when we’re talking about SOA, which is composed of many services, this can prove to be a grave mistake.

Chapter 5 covers the common interaction patterns for services, from the simple request/reply interaction to more advanced options.

Chapter 6 looks at patterns for integrating services and service consumers, especially UIs that are not services in themselves.

Chapter 7 takes a look at patterns that handle the composition and integration of services.

Part 2 focuses on different aspects of SOA in the real world:

Chapter 8 introduces SOA antipatterns. These are some of the things that can go wrong when you implement SOA, and this chapter discusses how to redesign or refactor the solutions to solve the problems.

Chapter 9 demonstrates, via a case study, how the different patterns can work together to create a greater whole—a complete system.

Chapter 10 takes a look at additional architectures and technologies and how they work with SOA. Specifically, the chapter covers the REST architectural style, cloud computing, and big data.

SOA Patterns can be read cover to cover, but the discussion of each individual pattern and antipattern pretty much stands on its own and can be read for reference when you face a specific challenge. To help with that, the book includes an appendix that maps quality attribute scenarios back to individual patterns and helps identify patterns that are relevant to problems you face.

Who should read this book?

This is a book about service-oriented architecture, so it will appeal to anyone tasked with building a system based on these principles. It is also about building distributed systems in general, and I believe a lot of the patterns will appeal to a wide audience.

As its main concern is with software architecture, the book is naturally targeted at software architects. I’d like to think it’s also relevant for a wider audience, including developers who are tasked with building services and managers who want to understand the range of possible solutions.

The technology mapping sections of the book contain code excerpts mainly in C# and Java, but these are just examples and the designs are applicable in other languages. I’ve applied some of the patterns in projects that used Ruby and Scala and still found them relevant.

Code conventions

All the code in the examples used in this book is presented in a monospaced font like this. For longer lines of code, a wrapping character may be used to keep the code technically correct while conforming to the limitations of a printed page.

Annotations accompany many of the code listings and numbered cueballs are used if longer explanations are needed. Longer listings of code examples appear under clear listing headers; shorter listings appear between lines of text.

Author Online

Purchase of SOA Patterns includes free access to a private web forum run by Manning Publications where you can make comments about the book, ask technical questions, and receive help from the author and from other users. To access the forum and subscribe to it, point your web browser to www.manning.com/SOAPatterns. This page provides information on how to get on the forum once you’re registered, what kind of help is available, and the rules of conduct on the forum.

Manning’s commitment to our readers is to provide a venue where a meaningful dialog between individual readers and between readers and the author can take place. It’s not a commitment to any specific amount of participation on the part of the author, whose contribution to the AO remains voluntary (and unpaid). We suggest you try ask the author some challenging questions lest his interest stray!

The Author Online forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.

About the Author

With more than 20 years of experience in software, Arnon Rotem-Gal-Oz has spent the last 15 years as an architecture and system designer of large distributed systems, including business intelligence (BI) and analytics systems, C4ISR systems, and customer care and billing systems. He has experience with a variety of technologies (Java,.NET, Scala, Hadoop, NoSQL, CEP, and others) on diverse platforms (Linux, Windows, Solaris, iOS, AS/400). Arnon currently works as the director of architecture for Nice Systems developing big data and SOA systems. Prior to that, Arnon worked as VP R&D in a couple of startups in the cloud and internet industries. Arnon blogs at http://arnon.me.

About the Cover Illustration

The figure on the cover of SOA Patterns is a Capidji Bachi, a personal officer of the Ottoman sultan, in ceremonial dress. The illustration is taken from a collection of costumes of the Ottoman Empire published on January 1, 1802, by William Miller of Old Bond Street, London. The title page is missing from the collection and we have been unable to track it down to date. The book’s table of contents identifies the figures in both English and French, and each illustration bears the names of two artists who worked on it, both of whom would no doubt be surprised to find their art gracing the front cover of a computer programming book ... two hundred years later.

The collection was purchased by a Manning editor at an antiquarian flea market in the Garage on West 26th Street in Manhattan. The seller was an American based in Ankara, Turkey, and the transaction took place just as he was packing up his stand for the day. The Manning editor did not have on his person the substantial amount of cash that was required for the purchase and a credit card and check were both politely turned down. With the seller flying back to Ankara that evening the situation was getting hopeless. What was the solution? It turned out to be nothing more than an old-fashioned verbal agreement sealed with a handshake. The seller simply proposed that the money be transferred to him by wire and the editor walked out with the bank information on a piece of paper and the portfolio of images under his arm. Needless to say, we transferred the funds the next day, and we remain grateful and impressed by this unknown person’s trust in one of us. It recalls something that might have happened a long time ago.

The pictures from the Ottoman collection, like the other illustrations that appear on our covers, bring to life the richness and variety of dress customs of two centuries ago. They recall the sense of isolation and distance of that period—and of every other historic period except our own hyperkinetic present. Dress codes have changed since then and the diversity by region, so rich at the time, has faded away. It is now often hard to tell the inhabitant of one continent from another. Perhaps, trying to view it optimistically, we have traded a cultural and visual diversity for a more varied personal life. Or a more varied and interesting intellectual and technical life.

We at Manning celebrate the inventiveness, the initiative, and, yes, the fun of the computer business with book covers based on the rich diversity of regional life of two centuries ago, brought back to life by the pictures from this collection.

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