Prepare article for publication

_posts/2024-03-04-the-four-tenets-of-soa-revisited.html

@@ -46,7 +46,7 @@ <h3 id="96e92c4bccef4d5789bbb5d860e3ce3f">
     </p>
     <ul>
         <li><a href="/2024/03/11/boundaries-are-explicit">Boundaries are explicit</a></li>
-        <li>Services are autonomous</li>
+        <li><a href="/2024/03/25/services-are-autonomous">Services are autonomous</a></li>
         <li>Services share schema and contract, not class</li>
         <li>Service compatibility is determined based on policy</li>
     </ul>

_posts/2024-03-11-boundaries-are-explicit.html

@@ -205,6 +205,6 @@ <h3 id="16ff65dbc4784ad1939257635d08039c">
         Many languages now come with support for asynchronous programming, often utilizing some kind of generic <code>Task</code> or <code>Async</code> <a href="/2022/03/28/monads">monad</a>. Since such types are usually contagious, you can use them to make boundaries explicit.
     </p>
     <p>
-        <strong>Next:</strong> Services are autonomous.
+        <strong>Next:</strong> <a href="/2024/03/25/services-are-autonomous">Services are autonomous</a>.
     </p>
 </div>

_posts/2024-03-03-services-are-autonomous.html → _posts/2024-03-25-services-are-autonomous.html

@@ -2,7 +2,7 @@
 layout: post
 title: "Services are autonomous"
 description: "A reading of the second Don Box tenet, with some commentary."
-date: 2024-03-03 12:44 UTC
+date: 2024-03-25 8:31 UTC
 tags: [Services, Architecture]
 ---
 {% include JB/setup %}
@@ -12,16 +12,16 @@
         <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 second tenet, quoting from the MSDN Magazine article unless otherwise indicated.
+        In this article, I'll go over the second tenet. The quotes are from the MSDN Magazine article unless otherwise indicated.
     </p>
     <h3 id="5021be8510304665ba3a8b9d9287a531">
         Services are autonomous <a href="#5021be8510304665ba3a8b9d9287a531">#</a>
     </h3>
     <p>
-        Compared with <a href="">the first tenet</a>, you'll see that Don Box had more to way about this one. I, conversely, have less to add. First, here's what the article said:
+        Compared with <a href="/2024/03/11/boundaries-are-explicit">the first tenet</a>, you'll see that Don Box had more to say about this one. I, conversely, have less to add. First, here's what the article said:
     </p>
     <blockquote>
         <p>
@@ -82,7 +82,7 @@ <h3 id="11028dabd5a540cf9160c06c3e1b283c">
         I don't know whether Don Box had something like this in mind when he wrote the word <em>transaction</em>, but in my experience, you don't want to go there. If you need to, you can make use of database transactions to keep your own service <a href="https://en.wikipedia.org/wiki/ACID">ACID</a>-consistent, but don't presume that this is possible with multiple autonomous services.
     </p>
     <p>
-        As always, even if a catchphrase such as <em>services are autonomous</em> sounds good, it's always illuminating to understand that there are trade-offs involved - and what they are. Here, a major trade-off is that you need to think about error-handling in a different way. If you don't already know how to address such concerns, look up <em>lock-free transactions</em> and <a href="https://en.wikipedia.org/wiki/Eventual_consistency">eventual consistency</a>. As Don Box also mentioned, durable queues are often part of such a solution, as is <a href="https://en.wikipedia.org/wiki/Idempotence">Idempotence</a>.
+        As always, even if a catchphrase such as <em>services are autonomous</em> sounds good, it's always illuminating to understand that there are trade-offs involved - and what they are. Here, a major trade-off is that you need to think about error-handling in a different way. If you don't already know how to address such concerns, look up <em>lock-free transactions</em> and <a href="https://en.wikipedia.org/wiki/Eventual_consistency">eventual consistency</a>. As Don Box also mentioned, durable queues are often part of such a solution, as is <a href="https://en.wikipedia.org/wiki/Idempotence">idempotence</a>.
     </p>
     <h3 id="7dc237c5f67c42c8b2c439140fc7a05b">
         Validation <a href="#7dc237c5f67c42c8b2c439140fc7a05b">#</a>
@@ -96,6 +96,18 @@ <h3 id="7dc237c5f67c42c8b2c439140fc7a05b">
     <p>
         It should also treat all input as suspect, until proven otherwise. Input validation is an important part of service design. It is my belief that <a href="/2020/12/14/validation-a-solved-problem">validation is a solved problem</a>, but that doesn't mean that you don't have to put in the work. You should consider correctness, versioning, as well as <a href="https://en.wikipedia.org/wiki/Robustness_principle">Postel's law</a>.
     </p>
+    <h3 id="2482dbc1c20248fdb61a7347abce49ef">
+        Security <a href="#2482dbc1c20248fdb61a7347abce49ef">#</a>
+    </h3>
+    <p>
+        A similar observation relates to security. Some services (particularly read-only services) may allow for anonymous access, but if a service needs to authenticate or authorize requests, consider how this is done in an autonomous manner. Looking up account information in a centralized database isn't the autonomous way. If a service does that, it now relies on the account database, and is no longer autonomous.
+    </p>
+    <p>
+        Instead, rely on <a href="https://en.wikipedia.org/wiki/Claims-based_identity">claims-based identity</a>. In my experience, <a href="https://en.wikipedia.org/wiki/OAuth">OAuth</a> with <a href="https://en.wikipedia.org/wiki/JSON_Web_Token">JWT</a> is usually fine.
+    </p>
+    <p>
+        If your service needs to know something about the user that only an external source can tell it, don't look it up in an external system. Instead, demand that it's included in the JWT as a claim. Do you need to validate the age of the user? Require a <em>date-of-birth</em> or <em>age</em> claim. Do you need to know if the request is made on behalf of a system administrator? Demand a list of <em>role</em> claims.
+    </p>
     <h3 id="75412f1e737a45dfaaf11c54e28013fa">
         Conclusion <a href="#75412f1e737a45dfaaf11c54e28013fa">#</a>
     </h3>