サービス指向アーキテクチャ（SOA）は、分散コンピューティングの進化として今世紀の初めに登場しました。 SOA以前は、サービスはアプリケーション開発プロセスの最終結果として理解されていました。 SOAでは、アプリケーション自体がサービスで構成されています。サービスは個別に提供することも、より大きな複合サービスのコンポーネントとして組み合わせることができます。
サービスは、RESTやSOAP（Simple Object Access Protocol）などのプロトコルを使用してネットワーク経由で相互作用します。サービスは疎結合です。つまり、サービスインターフェイスは基盤となる実装から独立しています。開発者またはシステムインテグレーターは、各サービスがどのように実装されているかを必ずしも知らなくても、1つ以上のサービスをアプリケーションに構成できます。
この記事は、JavaSOAの概要とSOAPベースのWebサービスを使用して実装されたサービス指向アーキテクチャ。また、SOAとマイクロサービスを簡単に比較し、JavaでのRESTfulとSOAPベースのWebサービスの違いについて説明します。
サービス指向アーキテクチャを使用する理由
SOAは3つの一般的な企業の課題に対処します：
- ビジネスの変化に迅速に対応します。
- 既存のインフラストラクチャへの投資を活用します。
- 顧客、パートナー、サプライヤーとの新しい対話チャネルをサポートします。
エンタープライズインフラストラクチャは、オペレーティングシステム、アプリケーション、システムソフトウェア、およびアプリケーションインフラストラクチャ間で異種です。その結果、多くのエンタープライズシステムは、複雑で一貫性のないアプリケーションで構成され、相互に依存するさまざまなサービス。現在のビジネスプロセスを実行している既存のアプリケーションは重要であるため、最初から始めるか、それらを変更することは微妙な提案です。しかし、企業はビジネス需要を満たすために技術インフラストラクチャを変更および拡張できる必要があります。
Asモノリシックアーキと比較して構造、SOAの疎結合の性質により、新しいサービスをプラグインしたり、新しいビジネス要件に合わせて既存のサービスをアップグレードしたりすることが比較的シームレスになります。また、さまざまなチャネルでサービスを利用できるようにし、レガシーアプリケーションをサービスとして公開して、インフラストラクチャへの投資を保護するオプションも提供します。
疎結合であるため、SOAコンポーネントは、他のコンポーネントへの影響を最小限に抑えて変更できます。 。コンポーネントは、標準化された方法でアーキテクチャに追加することもでき、負荷に対応するように拡張することもできます。
例として、企業が既存のアプリケーションのセットを使用して新しい、複合サプライチェーンアプリケーション。既存のアプリケーションは異種であり、さまざまなシステムに分散していますが、それらの機能は標準のインターフェースを使用して公開およびアクセスされます。
図1.サービス指向アーキテクチャーのサプライチェーンアプリケーション
SOAの主な特徴
SOAは、別のコンポーネントによって提供されるサービスを消費する単一のコンポーネントのように単純な場合もあれば、MuleSoftのESBなどのエンタープライズサービスバスを介して相互作用する一連のコンポーネントのように高度な場合もあります。規模に関係なく、SOA実装を成功させる鍵は目的を達成するために、できるだけ複雑さを少なくすること。最初と最後の質問は常に次のとおりです。この設計はビジネス要件を満たしていますか？
規模や複雑さに関係なく、サービス指向アーキテクチャのパターンほぼ同じです：
- サービスプロバイダーはエンドポイントを公開し、各エンドポイントで利用可能なアクション。
- サービスコンシューマーはリクエストを発行し、レスポンスを消費します。
- サービスプロバイダーはリクエストを処理するためのメッセージを生成します。
サービスの実装-指向アーキテクチャ
SOAを実装するには、基本的なサービスアーキテクチャから始めて、通信と相互運用性を可能にするプロトコルやその他のツールを意味するインフラストラクチャを提供します。図2に、一般的なサービスアーキテクチャの図を示します。
図2.サンプルのサービスアーキテクチャ
この図では、3人のコンシューマーがエンタープライズサービスバスにメッセージを送信してサービスを呼び出します。エンタープライズサービスバスは、メッセージを変換して適切なサービス実装にルーティングします。 。ビジネスルールエンジンは、サービス内またはサービス間でビジネスルールを組み込みます。サービス管理レイヤーは、監査、請求、ロギングなどのアクティビティを管理します。
このアーキテクチャのコンポーネントは疎結合であるため、アプリケーション全体への影響を比較的最小限に抑えて、スイッチアウトまたは更新できます。これにより、企業は必要に応じてビジネスプロセスを追加または更新できる柔軟性が得られます。ほとんどの場合、個々のサービスへの変更が他のサービスに大きな影響を与えることはありません。
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開発者には、SOAPベースの構築とデプロイのためのいくつかのオプションがあります。 Apache Axis2やSpring-WSなどのWebサービス。ただし、Java標準はJAX-WS（XML Webサービス用のJavaAPI）です。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パターンを理解し、それを実装するためのオプションを評価できると、プログラミングのキャリアに役立ちます。