スマートフォンやタブレット（※以降、単に「スマホ」）の普及に伴って、ひとつのシステムもしくはアプリケーションを、フロントエンドとバックエンドとに切り分けて捉えるアーキテクチャーが一般的になってきました。スマホでは、モバイル端末側にどこまでの機能を乗せて、サーバー側に何を残すか、「インターネットの向こうとこちら」でそれらをどう連携させるのか、これらを設計検討する事が*強制*されます。
スマホの普及と前後して、PCブラウザーの世界にも、JavaScriptを多用したUI強化→"UX"に付加価値を求める、という変化がありました。今調べると、最初のiPhoneが2007年に対して、最初のjQueryは2006年、HTML 5の最初の草案は2008年だったようです。PCブラウザーにおいても、コードがクライアントサイドに移って行くと、クライアント側でJavaScriptにやらせる範囲とサーバー側でやる範囲の切り分けを、やはり「インターネットの向こう側とこちら側」でどうするか、改めて考えていかねばなりません。
そうして、UIを担う「スマホ」や「コードリッチなPCブラウザー」などのクライアント側を「フロントエンド・アプリ」として抽象し、サーバー側は「バックエンド・サービス」として、そのフロント向けにAPI（Web API）を提供する役割を担わせるようなアーキテクチャーがひとつのパターンとなりました。
こうしたフロントエンド・アプリ−バックエンド・サービス間のI/Fをどう設計するかというと、、「インターネットの向こう側とこちら側」という課題に対する基本戦略は、(1) 通信頻度を下げたい、(2) 状態管理の必要なプロトコルは極力避けたい、この２点に尽きると言えます。通信頻度が低くて、状態管理の必要性を可能な限り除去したI/Fを「疎結合」なI/Fといいます。即ち、ちょうどうまく「粗結合」となる境界面（I/F）がよい。。
SOAは、システムの実装サイドの問題と言うより、要求・要件の管理の問題を解決しようとして出てきました。要求・要件の管理上の分割単位および各単位のライフサイクルと、それを実装するシステムの側の分割単位およびライフサイクルとを同期させることができるように、システムの側の分割方式を工夫しようという発想が、SOAの基本的なコンセプト（のはず！）です。その実現方式の鍵がシステムの側においては「粗結合」で構成する、というものでした。
スマホ向けシステムのフロントエンド−バックエンドという構成＝インターネット上の分散システムの実装上の課題の解法と、SOA＝大規模エンプラシステムの要求・要件の管理に関わる問題の解法（のひとつ）とが、「粗結合」という点で同じシステム要件を持っている、という話です。さらに言えば、スマホ向けシステムも企業業務システムも、サービス指向という切り口で統合的に捉えることができるだろう、否、捉える事が可能だと言うならむしろ積極的にそのように捉えて行こう、という話です。
◇
＜追記１＞
この投稿でいう「バックエンド・サービス」をクラウド環境として仕立てたのが「BaaS（Backend as a Service）」、ということですね。
なお、BaaSの「Service」と、この投稿での「バックエンド・サービス」の「サービス」は厳密には語彙のレイヤーが違います。「バックエンド・サービス」という“商材”の提供方式として、クラウドにdeploy、launchして行うという“業務”が「BaaS」、です。「BaaS」の「B」が「バックエンド・サービス」に相当します。「バックエンド・サービス」を「as a Service」として提供する事が「BaaS」です。まー、ほとんどどうでもいいです。
＜追記２＞
いわゆる「フロントエンド・エンジニア」のある方に伺ったら、“基盤”というと、サーバー、ネットワークからこの記事での「バックエンド・サービス」まで含んだものをイメージする、そうです。
