Skip to content

Commit

Permalink
Prepare article for publication
Browse files Browse the repository at this point in the history
  • Loading branch information
@ploeh
ploeh committed Mar 11, 2024
1 parent abb92d3 commit f4c1c98
Show file tree
Hide file tree
Showing 2 changed files with 11 additions and 11 deletions.
4 changes: 2 additions & 2 deletions _posts/2024-03-04-the-four-tenets-of-soa-revisited.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ <h3 id="96e92c4bccef4d5789bbb5d860e3ce3f">
I'll do that in a series of articles, each covering one of the tenets.
</p>
<ul>
<li>Boundaries are explicit</li>
<li><a href="/2024/03/11/boundaries-are-explicit">Boundaries are explicit</a></li>
<li>Services are autonomous</li>
<li>Services share schema and contract, not class</li>
<li>Service compatibility is determined based on policy</li>
Expand All @@ -60,6 +60,6 @@ <h3 id="ad6f66b0ac954647bebf4d288939d2ab">
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.
</p>
<p>
<strong>Next:</strong> Boundaries are explicit.
<strong>Next:</strong> <a href="/2024/03/11/boundaries-are-explicit">Boundaries are explicit</a>.
</p>
</div>
18 changes: 9 additions & 9 deletions ...s/2024-03-02-boundaries-are-explicit.html → ...s/2024-03-11-boundaries-are-explicit.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
layout: post
title: "Boundaries are explicit"
description: "A reading of the first Don Box tenet, with some commentary."
date: 2024-03-02 13:16 UTC
date: 2024-03-11 8:03 UTC
tags: [Services, Architecture]
---
{% include JB/setup %}
Expand All @@ -12,7 +12,7 @@
<em>{{ page.description }}</em>
</p>
<p>
This article is part of a series titled <a href="">The four tenets of SOA revisited</a>. In each of these articles, I'll pull one of <a href="https://en.wikipedia.org/wiki/Don_Box">Don Box</a>'s <em>four tenets of service-oriented architecture</em> (SOA) out of the <a href="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.
This article is part of a series titled <a href="/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 <a href="https://en.wikipedia.org/wiki/Don_Box">Don Box</a>'s <em>four tenets of service-oriented architecture</em> (SOA) out of the <a href="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.
</p>
<p>
In this article, I'll go over the first tenet, quoting from the MSDN Magazine article unless otherwise indicated.
Expand All @@ -35,7 +35,7 @@ <h3 id="3d25f37d4da8482fa846b8660823b8cd">
</p>
</blockquote>
<p>
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.
Notice that there's nothing here about <a href="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.
</p>
<p>
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, <a href="https://martinfowler.com/">Martin Fowler</a> had formulated his
Expand All @@ -44,13 +44,13 @@ <h3 id="3d25f37d4da8482fa846b8660823b8cd">
<p>
"<strong>First Law of Distributed Object Design:</strong> Don't distribute your objects!"
</p>
<footer><cite>Martin Fowler, <a href="https://blog.ploeh.dk/ref/peaa">Patterns of Enterprise Application Architecture</a>, (his emphasis)</cite></footer>
<footer><cite>Martin Fowler, <a href="/ref/peaa">Patterns of Enterprise Application Architecture</a>, (his emphasis)</cite></footer>
</blockquote>
<p>
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.
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.
</p>
<p>
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.
Perhaps I read to much into that, because WCF immediately proceeded to convert any <a href="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.
</p>
<p>
Here a code snippet from the <a href="https://learn.microsoft.com/dotnet/framework/wcf/how-to-use-a-wcf-client">WCF documentation</a>:
Expand All @@ -61,7 +61,7 @@ <h3 id="3d25f37d4da8482fa846b8660823b8cd">
<span style="color:blue;">double</span>&nbsp;<span style="font-weight:bold;color:#1f377f;">result</span>&nbsp;=&nbsp;client.Add(value1,&nbsp;value2);</pre>
</p>
<p>
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.
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.
</p>
<p>
So much for the principle that boundaries are explicit. They're not, and it bothered me twenty years ago, as it bothers me today.
Expand All @@ -73,7 +73,7 @@ <h3 id="55bd772540a047a3b8db0d1aee373e87">
How do you make boundaries explicit? <a href="#55bd772540a047a3b8db0d1aee373e87">#</a>
</h3>
<p>
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.
This problem isn't isolated to WCF or SOAP. <a href="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.
</p>
<p>
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 <a href="/2020/03/23/repeatable-execution">add logging</a>, <a href="https://martinfowler.com/bliki/CircuitBreaker.html">Circuit Breakers</a>, etc.
Expand Down Expand Up @@ -181,7 +181,7 @@ <h3 id="fffc782323e746ef9a7b662132e17257">
<p>
"Abstraction is <em>the elimination of the irrelevant and the amplification of the essential.</em>"
</p>
<footer><cite>Robert C. Martin, <a href="/ref/doocautbm">Designing Object-Oriented C++ Applications Using The Booch Method</a>, chapter 00, (his emphasis)</cite></footer>
<footer><cite>Robert C. Martin, <a href="/ref/doocautbm">Designing Object-Oriented C++ Applications Using The Booch Method</a>, chapter 00 (sic), (his emphasis)</cite></footer>
</blockquote>
<p>
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.
Expand Down

0 comments on commit f4c1c98

Please sign in to comment.