「SOA」として知られるサービス指向アーキテクチャは、再利用可能な個別のコンポーネントを使用することで、デベロッパーは製品デザインにモジュール方式を採用し、モノリシックなソフトウェアを排除することができます。SOAの機能は、ビジネス機能の繰り返しに依存する組織のニーズを満たす傾向があり、SOAは特定のニーズを満たすために完全なWebアプリケーションを構築するのではなく、コンポーネントを再利用してアプリケーションの開発をスピードアップし、ミスを回避することができます。

消費者向けの製品であっても、DevOpsチームが社内向けの製品を構築していても、SOAサービスによってワークフローを改善できる可能性があるのです。

SOAの仕組み

典型的なSOAフレームワークは、以下の５つの水平層に依存しています：

  • 消費者インターフェース
  • ビジネスプロセス
  • サービス
  • サービスコンポーネント
  • 運用システム

特定の SOA フレームワークにとっては、上記のレベルとは少し違って見えるかもしれませんが、いずれにせよ、それらが果たす役割を理解することで、アプリ開発のための効果的な戦略として SOA を受け入れるようになれるはずです。

また、各層には、必要に応じて特定の機能を実行するようにデザインされた必須コンポーネントである ABB（Architectural Building Block）が多数含まれています。

消費者インタフェース層

「消費者インターフェース層」で、ユーザーが必要な機能にアクセスできるようになりますが、GUI インターフェースは、ユーザーを多くの SOA コンポーネントとその機能から分離することに注意することが重要です。分離はSOAフレームワークの欠点のように聞こえるかもしれませんが、実際には、それはシームレスなサービスの外観を作り出し、ユーザーが自分の好みの設定や保存もできます。そうすると、次にインターフェースを訪れたときには既にカスタマイズされた機能とデザインがあるため、それが’シームレスでパーソナルなコンポーネントに感じられるのです。

ビジネスプロセス層

最適なビジネスプロセスというのは、消費者の要求や業界の期待の変化に対する速やかな適応が必要です。SOA の登場以前は、大抵のデベロッパーはビジネスプロセスをアプリケーションの中核として組み込む必要があり、期待値が変化すれば、DevOpsチームはアプリケーションの手直しに奔走しなければなりませんでした。

そこで、「ビジネスプロセス層」を独立させることで SOA がより速くなります。ビジネスプロセスに必要な機能をアプリのデザインの中核に置くのではなく、サービス層と消費者の間に独立した機能を置くことができるのです。

このフレームワークでは、「進化」というのは、ソフトウェアコードの大部分を書き換えるのではなく、構成要素をいくつか追加、交換、調整するということによくなります。

サービス層

SOAの「サービス層」には、以下のような重要な機能を果たすコンポーネントが含まれます：

  • アクセス管理
  • ポリシー管理
  • サービスクラスタリング
  • サービスランタイムの有効化
  • サービスの確定

このような能力（ケイパビリティ）のカテゴリの中には、その仕事を正しく行うために複数の機能の実行が必要なものがあり、例えば、「サービスランタイムの有効化」能力のカテゴリーは、通常、以下が含まれます：

  • サービスコンテナ
  • サービスインタラクション管理者
  • サービスレジストリ
  • サービス品質管理者

他の SOA 層と同様に、デベロッパーはサービス層の進化するニーズに合わせて、コンポーネントの変更、削除、または追加ができます。もしあなたの会社がQoS（サービス品質）層に柔軟性を持たせたいなら、その新しい目標に到達するために関連するコンポーネントを更新するといいかもしれません。

サービスコンポーネント層

サービスコンポーネント層には、ユーザーがアクセスしたい実際のサービスが含まれており、このコンポーネントを独立した層にすることで、技術的なビジネスロジックや IT のニーズとユーザーの体験を切り離すことができます。

この層には、以下のように最大で５種類のABB（Architectural Building Block）があります：

  • サービスの実現と実装
  • サービスの公表と公開
  • サービスの展開
  • サービス呼び出し
  • サービスバインディング

SOAの層はそれぞれ、ユーザーの体験にとって重要なことを行いますが、これを機能の中核と見るのが妥当でしょう。このような本質的なSOAコンポーネントがなければ、何も起こりませんからね。

運用システム層

「運用システム層」には、SOAソリューションが機能するのに必要なハードウェアとソフトウェアが含まれており、この層には、サービス提供、ランタイム環境、仮想化およびインフラストラクチャ・サービスを管理する ABB があります。

運用システム層は、SOA がデータベースやレガシーソフトウェアなど、他のシステムに接続する場所でもあります。デジタル化は継続的なプロセスであるため、技術を移行する間、こういったシステムの一部に依存し続けないといけない可能性があります。

SOAの層については、Open Group の 「SOA Source Book」に詳しく載っています。

SOA とマイクロサービスの違い

SOA のコンセプトとマイクロサービス・アーキテクチャには、多くの共通点があり、おそらく、モノリシックでエンタープライズ向けのアプリケーションを、自己完結型の小さなビルディングブロックに分割することが最も重要です。ソフトウェアコンポーネントを更新したい場合、デベロッパーは、１つの機能を変更することで依存関係のある膨大なライブラリがどのように中断されるかを心配する必要がありません。どちらのアーキテクチャも、ビジネスプロセスを中断させることなく、継続的に開発するための余地があるのです。

SOA は、タスク完了に必要なコードとデータを含んでいるという点で、マイクロサービスとは異なります。マイクロサービスでは、他のアプリケーションや機能にデータを要求する必要があるかもしれませんが、SOAには必要なものがすべて含まれています。このアプローチは、SOA にある依存関係はマイクロサービスよりもさらに少ないということであり、それによって機能間の通信をほとんど必要としない疎結合を得ることができます。

SOA 使用の利点

SOA には、アプリケーションの機能をデザイン・実装するための新しいアプローチが必要ですが、DevOpsチームがこれを取り入れたのは、何かしらの利点があるからです。

関連記事： Data Mesh Architecture: Understanding the Four Key Components

柔軟性

SOAには、特定の OS も、プログラミング言語も、ファイルフォーマットも必要ありません。Webサービスや他のクラウドコンピューティングの概念と同様に、SOAコンポーネントはユーザーのニーズに適応できます。

ソフトウェア開発チームは、実質的にプログラミング言語全てでコンポーネントの記述ができます。以下に、最もよく使われるものをいくつかご紹介します：

  • Java
  • Python
  • XML（Extensive Markup Language：拡張可能なマークアップ言語）
  • WSDL（Web Services Description Language：ウェブサービスの特徴的な機能を記述するための言語）

ウェブサイトやモバイルアプリケーションにアクセスできる人であれば、誰でもSOA コンポーネントを利用できる可能性があります。アクセスを簡素化し、デベロッパーがコンポーネントを調整する方法をよりコントロールできるようにするのに、ESB（エンタープライズサービスバス）の使用を選ぶ可能性もあり、そうすることで、独立したサービスが互いに連携しているように見える、包括的なサービスインターフェースが提供されます。

ユーザーが Windows、Mac、Linux、その他の OS を好むかどうかは問題ではありません。クラウドコンピューティングは OS に依存せず、それによってSOAアーキテクチャは IT 環境全体において有用になるのです。

SaaSのコンポーネントを再利用

SOAソフトウェアのデザインに追加できるSaaS（Software-as-a-Service：サービスとしてのソフトウェア）コンポーネントは、おそらく既にたくさんお持ちのことでしょう。また、特にオーディエンスがそのようなコンポーネントを既に使っている場合、再利用したいオープンソース コンポーネントを吟味している可能性もありますね。

それぞれのユーザーインターフェースに、必要なコンポーネントを的確に組み込むことができます。レストランで料理をするようなものだと思えばいいでしょう。タマネギは複数の料理に使えますが、新しいレシピに入れる前に、何らかの方法でタマネギを再発明する必要はないですよね。これは、SOA にも当てはまります。あなたが組み立てるコンポーネントは、本質的に、ユーザーの特定のニーズに応えるレシピを作るのです。

迅速な進化でビジネス価値を上げる

大規模なモノリシック・ソフトウェア・アプリケーションの構築には、数ヶ月から数年かかることがありますが、時間が経つと、競合他社がより新しい製品をリリースし、ビジネス価値を奪う可能性があります。そこで  SOAのアーキテクチャパターンを採用することで、より迅速に適応するチャンスが生まれます。

サービスレジストリに新しい部品を追加するだけでいいので、生産時間を短縮し、競合他社に差をつけることができるのです。

DevOpsのプロセスの短縮は、サービス契約の仕様を遵守することにもつながります。例えば、クライアントのサービス契約書に、あなたのところの製品が５秒以内に決済を確認するよう記載されているかもしれません。そうなると消費者の製品への支払い方法の変化が、サービスの動作速度に影響を与える可能性があります。同様に、クライアントがより多くの顧客を獲得するにつれて、支払い処理が遅くなる可能性があります。でも慌てる必要はありません。新しいコンポーネントを追加して、以前のバージョンをアシストしたり、置き換えたりすればいいのです。これでサービス契約の仕様を満たすことができ、金銭的な損失を回避し、ブランドの評判を維持することができますね。

スケーラビリティ

SOA は、ユーザーの需要が急激に増加した場合に、迅速なスケーラビリティを実現する可能性を秘めています。対処の仕方は、具体的な状況によって異なりますが、AWS、Microsoft Azure、IBMなどのクラウドサービスプロバイダーは、短時間の活発な活動に対応するために、より多くのサーバーパワーを起動させるでしょう。

長期的なソリューションが必要な場合は、通信プロトコルを確認しましょう。【サービス提供者】と【サービス利用者】が同じイントラネット（内部ネットワーク）に接続されている場合は、通常、TCP（Transmission Control Protocol）が最適な選択肢となります。ユーザーがインターネット経由でサービスにアクセスする場合は、HTTPを使うといいでしょう。これは、それほど速く動作しませんが、ロードバランシングを使ってスケーラビリティをアシストすることができます。

他にも、以下のような選択肢があります：

  • JMS（Javaメッセージサービス）
  • Apache ActiveMQ
  • Apache Thrift
  • SOAP（Simple Object Access Protocol）
  • RESTful HTTP API

いずれにせよ、ユーザーの要求の増加や減少に対応するためのいい方法があります。さらに、例えば内部ユーザーにはTCPを使い、外部ユーザーにはRESTful API でマイクロサービスに接続することができるというような、一度に複数のプロトコルを使うのもいいでしょう。

SOAの欠点

SOA には多くの利点があるのに、すべての企業が採用しているわけではないのはなぜでしょうか？全テクノロジーと同様に、潜在的な欠点があるからです。成功の前に立ちはだかる最も高い壁には、例えば以下のようなものがあります：

  • SOAフレームワークへの移行に伴う、多額の資金投入は大変に思えるかもしれない。
  • 多くの人がインターフェースを使うと、負荷が非常に重くなることがある。
  • 負荷が高くなると応答速度が遅くなることがある。
  • コンポーネント同士のインタラクションが必要な場合も多く、その場合、多くのメッセージが発生し、それによって管理が大変になる。

Integrate.io でSOAコンポーネントを管理する

SOAは多数のコンポーネントが連携して動作するため、APIを作成し管理する方法が必要です。Integrate.io は、サーバーサイドスクリプティングと業界をリードするセキュリティで、即座にAPIを作成することができます。14日間の無料トライアルを開始し、ノーコードAPI作成と自動化がSOAの成功にどのように役立つかをご確認ください。

関連記事： What is a Reusable API?