You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ever since I first encountered the four tenets of SOA, they've stayed with me in one form or other. When helping teams to design services, even what we may today consider 'modern services', I've drawn on some of those ideas. There are insights of a general nature that are worth considering even today.
61
61
</p>
62
62
<p>
63
-
<strong>Next:</strong> Boundaries are explicit.
63
+
<strong>Next:</strong><ahref="/2024/03/11/boundaries-are-explicit">Boundaries are explicit</a>.
Copy file name to clipboardexpand all lines: _posts/2024-03-11-boundaries-are-explicit.html
+9-9
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
layout: post
3
3
title: "Boundaries are explicit"
4
4
description: "A reading of the first Don Box tenet, with some commentary."
5
-
date: 2024-03-02 13:16 UTC
5
+
date: 2024-03-11 8:03 UTC
6
6
tags: [Services, Architecture]
7
7
---
8
8
{% include JB/setup %}
@@ -12,7 +12,7 @@
12
12
<em>{{ page.description }}</em>
13
13
</p>
14
14
<p>
15
-
This article is part of a series titled <ahref="">The four tenets of SOA revisited</a>. In each of these articles, I'll pull one of <ahref="https://en.wikipedia.org/wiki/Don_Box">Don Box</a>'s <em>four tenets of service-oriented architecture</em> (SOA) out of the <ahref="https://learn.microsoft.com/en-us/archive/msdn-magazine/2004/january/a-guide-to-developing-and-running-connected-systems-with-indigo">original MSDN Magazine article</a> and add some of my own commentary. If you're curious why I do that, I cover that in the introductory article.
15
+
This article is part of a series titled <ahref="/2024/03/04/the-four-tenets-of-soa-revisited">The four tenets of SOA revisited</a>. In each of these articles, I'll pull one of <ahref="https://en.wikipedia.org/wiki/Don_Box">Don Box</a>'s <em>four tenets of service-oriented architecture</em> (SOA) out of the <ahref="https://learn.microsoft.com/en-us/archive/msdn-magazine/2004/january/a-guide-to-developing-and-running-connected-systems-with-indigo">original MSDN Magazine article</a> and add some of my own commentary. If you're curious why I do that, I cover that in the introductory article.
16
16
</p>
17
17
<p>
18
18
In this article, I'll go over the first tenet, quoting from the MSDN Magazine article unless otherwise indicated.
Notice that there's nothing here about Windows Communication Framework (WCF), or any other specific technology. This is common to all four tenets, and one of the reasons that I think they deserve to be lifted out of their original context and put on display as the general ideas that they are.
38
+
Notice that there's nothing here about <ahref="https://en.wikipedia.org/wiki/Windows_Communication_Foundation">Windows Communication Framework</a> (WCF), or any other specific technology. This is common to all four tenets, and one of the reasons that I think they deserve to be lifted out of their original context and put on display as the general ideas that they are.
39
39
</p>
40
40
<p>
41
41
I'm getting the vibe that the above description was written under the impression of the disenchantment with distributed objects that was setting in around that time. The year before, <ahref="https://martinfowler.com/">Martin Fowler</a> had formulated his
"<strong>First Law of Distributed Object Design:</strong> Don't distribute your objects!"
46
46
</p>
47
-
<footer><cite>Martin Fowler, <ahref="https://blog.ploeh.dk/ref/peaa">Patterns of Enterprise Application Architecture</a>, (his emphasis)</cite></footer>
47
+
<footer><cite>Martin Fowler, <ahref="/ref/peaa">Patterns of Enterprise Application Architecture</a>, (his emphasis)</cite></footer>
48
48
</blockquote>
49
49
<p>
50
-
The way that I read this then, and the way I <em>still</em> read it today, is that in contrast to distributed objects, you should treat any service invocation as a noticeable operation, somehow distinct from normal code.
50
+
The way that I read the tenet then, and the way I <em>still</em> read it today, is that in contrast to distributed objects, you should treat any service invocation as a noticeable operation, <em>"putting a premium on boundary crossings"</em>, somehow distinct from normal code.
51
51
</p>
52
52
<p>
53
-
Perhaps I read to much into that, because WCF immediately proceeded to convert any SOAP service into a lot of auto-generated C# code that would then enable you to invoke operations on a remote service using (you guessed it) a method invocation.
53
+
Perhaps I read to much into that, because WCF immediately proceeded to convert any <ahref="https://en.wikipedia.org/wiki/SOAP">SOAP</a> service into a lot of auto-generated C# code that would then enable you to invoke operations on a remote service using (you guessed it) a method invocation.
54
54
</p>
55
55
<p>
56
56
Here a code snippet from the <ahref="https://learn.microsoft.com/dotnet/framework/wcf/how-to-use-a-wcf-client">WCF documentation</a>:
What happens here is that <code>client.Add</code> creates and sends a SOAP message to a service, receives the response, unpacks it, and returns it as a <code>double</code> value. Even so, it looks just like any other method call.
64
+
What happens here is that <code>client.Add</code> creates and sends a SOAP message to a service, receives the response, unpacks it, and returns it as a <code>double</code> value. Even so, it looks just like any other method call. There's no <em>"premium on boundary crossings"</em> here.
65
65
</p>
66
66
<p>
67
67
So much for the principle that boundaries are explicit. They're not, and it bothered me twenty years ago, as it bothers me today.
How do you make boundaries explicit? <ahref="#55bd772540a047a3b8db0d1aee373e87">#</a>
74
74
</h3>
75
75
<p>
76
-
This problem isn't isolated to WCF or SOAP. Network calls are slow and unreliable. Perhaps you're connecting to a system on the other side of the Earth. Perhaps the system is unavailable. This is true regardless of protocol.
76
+
This problem isn't isolated to WCF or SOAP. <ahref="https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing">Network calls are slow and unreliable</a>. Perhaps you're connecting to a system on the other side of the Earth. Perhaps the system is unavailable. This is true regardless of protocol.
77
77
</p>
78
78
<p>
79
79
From the software architect's perspective, the tenet that boundaries are explicit is a really good idea. The clearer it is where in a code base network operations take place, the easier it is to troubleshot and maintain that code. This could make it easier to spot <em>n + 1</em> problems, as well as give you opportunities to <ahref="/2020/03/23/repeatable-execution">add logging</a>, <ahref="https://martinfowler.com/bliki/CircuitBreaker.html">Circuit Breakers</a>, etc.
"Abstraction is <em>the elimination of the irrelevant and the amplification of the essential.</em>"
183
183
</p>
184
-
<footer><cite>Robert C. Martin, <ahref="/ref/doocautbm">Designing Object-Oriented C++ Applications Using The Booch Method</a>, chapter 00, (his emphasis)</cite></footer>
184
+
<footer><cite>Robert C. Martin, <ahref="/ref/doocautbm">Designing Object-Oriented C++ Applications Using The Booch Method</a>, chapter 00 (sic), (his emphasis)</cite></footer>
185
185
</blockquote>
186
186
<p>
187
187
The existence of a boundary is essential, so while we might want to eliminate various other irrelevant details, this is a property that we should retain and surface in APIs. Even better, it'd be best if we could do it in such a way that it can't easily be swept under the rug, as shown above.
0 commit comments