サービス指向アーキテクチャとは何ですか?

サービス指向アーキテクチャー(SOA)は、分散コンピューティングの進化として今世紀の初めに登場しました。SOA以前は、サービスはアプリケーション開発プロセスの最終結果として理解されていました。SOAでは、アプリケーション自体がサービスで構成されています。サービスは個別に提供することも、より大規模な複合サービスのコンポーネントとして組み合わせて提供することもできます。

サービスは、RESTやSOAP(Simple Object Access Protocol)などのプロトコルを使用してネットワーク経由で対話します。サービスは疎結合です。つまり、サービスインターフェイスは基盤となる実装から独立しています。開発者またはシステムインテグレーターは、各サービスがどのように実装されているかを必ずしも知らなくても、1つ以上のサービスをアプリケーションに構成できます。

この記事は、Java SOAの概要と、SOAPベースのWebサービスを使用して実装されたサービス指向アーキテクチャーの主な特徴です。また、SOAとマイクロサービスを簡単に比較し、JavaでのRESTfulとSOAPベースのWebサービスの違いについて説明します。

SOAおよびWebサービス

SOAとWebサービスは頻繁に混同されますが、同じものではありません。SOAは、開発者が複数のアプリケーションサービスをより大きな複合サービスに結合できるようにするアーキテクチャです。SOAは、SOAPベースのWebサービスまたはREST API、あるいは両方の組み合わせを使用して実装できます。SOAでは、サービスは要求に応答できるリモートで利用可能なリソースであることを理解することが重要です。Webサービスは、特定のプロトコルを使用して実装されます。

なぜサービス指向アーキテクチャなのか?

SOAは、次の3つの一般的な企業の課題に対処します。

  • ビジネスの変化に迅速に対応します。
  • 既存のインフラストラクチャへの投資を活用します。
  • 顧客、パートナー、およびサプライヤーとの新しい対話チャネルをサポートします。

エンタープライズインフラストラクチャは、オペレーティングシステム、アプリケーション、システムソフトウェア、およびアプリケーションインフラストラクチャ間で異質です。その結果、多くのエンタープライズシステムは、相互に依存するさまざまなサービスを提供する複雑で一貫性のないアプリケーションで構成されています。現在のビジネスプロセスを実行している既存のアプリケーションは重要であるため、最初から開始するか、それらを変更することは微妙な提案です。しかし、企業はビジネスの需要を満たすために技術インフラストラクチャを変更および拡張できなければなりません。

SOAとマイクロサービス

マイクロサービスは、SOAから進化したアーキテクチャスタイルです。どちらも分散アーキテクチャであり、どちらも分離されたパラダイムを提供します。サービス指向アーキテクチャーはインフラストラクチャーに重きを置いていますが、マイクロサービスはより柔軟で軽量な開発スタイルを提供します。両方に長所と短所があり、両方が広く使用されています。一般的に言って、SOAは、より形式的なものをサポートするためのリソースを持つ確立された企業によって、より頻繁に実装または保守されます。マイクロサービスは、敏捷性を必要とする新規または成長中の組織にアピールすることがよくあります。

モノリシックアーキテクチャと比較すると、SOAの疎結合の性質により、新しいサービスをプラグインしたり、新しいビジネス要件に合わせて既存のサービスをアップグレードしたりすることが比較的シームレスになります。また、さまざまなチャネルでサービスを利用できるようにし、レガシーアプリケーションをサービスとして公開して、インフラストラクチャへの投資を保護するオプションも提供します。

それらは疎結合であるため、SOAコンポーネントは、他のコンポーネントへの影響を最小限に抑えて変更できます。コンポーネントは、標準化された方法でアーキテクチャに追加することもでき、負荷に対応するように拡張することもできます。

例として、企業が既存のアプリケーションのセットを使用して、新しい複合サプライチェーンアプリケーションを作成する方法を考えてみましょう。既存のアプリケーションは異種であり、さまざまなシステムに分散していますが、それらの機能は公開され、標準のインターフェイスを使用してアクセスされます。

マシュータイソン

SOAの主な特徴

SOAは、別のコンポーネントによって提供されるサービスを消費する単一のコンポーネントのように単純な場合もあれば、MuleSoftのESBなどのエンタープライズサービスバスを介して相互作用する一連のコンポーネントのように高度な場合もあります。規模に関係なく、SOA実装を成功させる秘訣は、目的を達成するためにできるだけ複雑さを使用しないことです。最初と最後の質問は常に次のようになります。この設計は私たちのビジネス要件を満たしていますか?

規模や複雑さに関係なく、サービス指向アーキテクチャーのパターンはほぼ同じです。

  • サービスプロバイダーはエンドポイントを公開し、各エンドポイントで利用可能なアクションを説明します。
  • サービスコンシューマーは要求を発行し、応答を消費します。
  • サービスプロバイダーは、要求を処理するためのメッセージを生成します。

サービス指向アーキテクチャーの実装

SOAを実装するには、基本的なサービスアーキテクチャから始めて、通信と相互運用性を可能にするプロトコルやその他のツールを意味するインフラストラクチャを提供します。図2に、一般的なサービスアーキテクチャの図を示します。

マシュータイソン

この図では、3人のコンシューマーがエンタープライズサービスバスにメッセージを送信してサービスを呼び出します。エンタープライズサービスバスは、メッセージを変換して適切なサービス実装にルーティングします。ビジネス・ルール・エンジンは、サービスまたはサービス全体のビジネス・ルールが組み込まれています。サービス管理層は、監査、課金、およびロギングなどのアクティビティを管理します。

このアーキテクチャのコンポーネントは疎結合であるため、アプリケーション全体への影響を比較的最小限に抑えて、スイッチアウトまたは更新できます。これにより、企業は必要に応じてビジネスプロセスを追加または更新できる柔軟性が得られます。ほとんどの場合、個々のサービスへの変更が他のサービスに大きな影響を与えることはありません。

SOAPとRESTfulWebサービス

たとえばJAX-RSAPIまたはSpringBoot Actuatorを使用して、SOAスタイルを採用し、RESTで実装することは可能ですが、その説明はこの記事の範囲外です。SOAPとRESTfulWebサービスの有用な比較については、「SOAPとRESTとJSON」を参照してください。また、RESTfulWebサービスとマイクロサービスに関連するより軽量なスタイルの間にもいくつかの重複があります。

SOAPベースのWebサービス

SOAPを使用して実装されたWebサービスは、RESTful Webサービスまたはマイクロサービスの実装よりも堅固ですが、SOAの初期よりもはるかに柔軟です。ここでは、SOAPベースのWebサービスに必要な高レベルのプロトコルについて説明します。

SOAP、WSDL、およびXSD

SOAP、WSDL、およびXSDは、SOAPベースのWebサービス実装の基本的なインフラストラクチャです。WSDLはサービスを記述するために使用され、SOAPはサービスコンシューマーとプロバイダーの間でメッセージを送信するためのトランスポート層です。サービスは、XMLスキーマ(XSD)を使用して正式に定義されたメッセージと通信します。WSDLはサービスのインターフェースと考えることができます(Javaインターフェースに大まかに類似しています)。実装はJavaクラスで行われ、ネットワークを介した通信はSOAPを介して行われます。機能的には、コンシューマーはサービスを探し、そのサービスのWSDLを取得してから、SOAPを使用してサービスを呼び出します。

Webサービスセキュリティ

WS-I Basic Profile 2.0仕様は、メッセージのセキュリティに対応しています。この仕様は、資格情報の交換、メッセージの整合性、およびメッセージの機密性に焦点を当てています。

Webサービスの発見

Webサービス発見の基礎となると、UDDI(Universal Description、Definition and Integration)は歴史に溶け込んでいます。今日では、エンドポイントURLを介して、SOAPベースのWebサービスを他のサービスと同じように公開するのが一般的です。例として、あなたは、JAX-WSサービス・エンドポイント・インタフェースとその使用することができます@WebServiceし、@WebMethod注釈を。

Webサービスの構築と展開

Java開発者には、Apache Axis2やSpring-WSなど、SOAPベースのWebサービスを構築およびデプロイするためのいくつかのオプションがあります。ただし、Java標準は、XMLWebサービス用のJavaAPIであるJAX-WSです。JAX-WSの背後にある中心的な考え方は、Javaクラスを作成し、それらに注釈を付けて必要なアーティファクトを作成することです。内部的には、JAX-WSは、JavaクラスをXMLにバインドするための汎用ライブラリであるJAXBを含むいくつかのJavaパッケージを使用します。

JAX-WSは、根本的な複雑さとプロトコルを開発者から隠し、JavaベースのSOAPサービスを定義およびデプロイするプロセスを合理化します。Eclipseのような最新のJavaIDEには、JAX-WSWebサービスの開発を完全にサポートしています。JAX-WS仕様は、JakartaEEで進行中の開発にも選択されています。

結論

SOAPベースのWebサービスで実装されたサービス指向アーキテクチャーには、RESTfulWebサービスやマイクロサービスよりも厳密で正式なサービス定義が必要です。ただし、一部の大規模な組織は、SOAPによって実施されるより正式なスタイルを引き続き支持しています。多くの大規模なレガシーシステムもSOAPに基づいて構築されており、一部のB2Bおよび内部システムは、より正式に定義されたAPIコントラクトにSOAPベースのWebサービスを選択します。大規模なエンタープライズシステムを開発または保守している場合でも、SOAパターンを理解し、それを実装するためのオプションを評価できることは、プログラミングのキャリアに役立ちます。

このストーリー、「サービス指向アーキテクチャーとは」もともとJavaWorldによって公開されました。