SOAサービス構成は実際に機能しますか？

SOAサービスの主要な設計原則の1つは、サービスの構成可能性の原則（https://en.wikipedia.org/wiki/Service_composability_principle）です。

アイデアは、既存のサービスを構成要素として使用して新しいサービスを構成することにより、新しいサービスを迅速に開発できるということです。新しいメソッドを実装するときにオブジェクトのexisingメソッドを呼び出す方法に似ています。これは、SOAによる生産性の向上の多くがもたらされることになっている場所です。

実際に誰かがこれを実際にしていますか？私はこれを文章で延々と繰り返してきましたが、実際の実装を実際に経験したことはありません。また、ほとんどのテキストでは、トランザクション処理に関する記述が省略されています。これは、構成可能なサービスを実現する上で最大の障害であると思われます。

最初に、重要なサービスを作成する前に、トランザクションの問題に取り組む必要があります。もちろん、例にサービス「findCurrentTime（）」および「writeLogMessage（）」がある場合、トランザクションについて心配することは簡単ですが、「depositMoney（）」および「withdrawMoney（）」などの実世界の例を持っている場合はそうではありません。

私は2つのオプションを知っています：

1. WS-Atomic Transactionなどを使用して実際のトランザクションを実装する
2. Aへの呼び出しを「cancelA（）」またはBへの呼び出しが失敗した場合に何らかの補償を行う補償ベースのソリューションを実装する

これらは両方とも非常に問題があるように思われます。

• WS-Atomic Transaction
  • 多くの複雑さのは、私は警告したことが最もアドバイス「お尻の痛みは、それを行ういけません」
  • サポートは制限されています。たとえば、オープンソースのESBを使用する場合、ServiceMix、Mule、またはWSO2の主要な代替はサポートしません
• 補償
  • 補償の処理を実装することは私にとって非常に複雑に思えます。サービスAが成功し、サービスBから回答を得られず、失敗したか成功したかわからない場合はどうすればよいですか？このようなロジックを（合成サービスの実装者として）手動で処理すると、手首を切り裂きたいと思うようになります。
  • また、重要なサービスで補償方法を使用する方法もわかりません。サービスAが「depositMoney（）」で成功した場合、他のアクションがすぐに別の場所に送金し、「compensateDepositMoney（）」を受け取ったとします。ワームの大きな缶のようです。

私にとっては、サービスの構成は非常に基本的なSOAの原則であるため、サービスを（便利に）構成できない場合は、SOAの利点を実際には得られないようです。。現実は何ですか？90％のSOAユーザーは、実際のサービスを使わずに「暗号化されたSOA」を使用していますか？または、ほとんどのユーザーが実際にサービス構成を使用しており、その難しさを誇張していますか？

簡単な答えは、はいです！

私はこれをいくつかの大規模な金融機関で見ましたが、うまくいきました。

トランザクションの問題は複雑ですが、通常はOracles WebLogic EAIやIBMs Websphere ESBなどの（高価な）ミドルウェアによって処理されます。

はい、実際に機能させることができます。ただし、これは最善のアプローチではない場合があり、デフォルトのオプションとして必要以上に使用される可能性があります。私の意見では、組織がITを進化させてより大きなタスクを自動化するにつれて、レガシーシステムを統合する方法としてSOAが普及しました。非常に面倒ですが、レガシーシステムを再利用できる場合は価値があります。グリーンフィールドプロジェクトを開始できるほど幸運な場合は、他のアプローチを検討する必要があります。

より具体的な懸念事項に回答するには...

トランザクションを使用できます：

1. WS-TXはPITAであり、私はそれを避けるでしょう。
2. すべてのサービスが単一のアプリケーションサーバーで実行されている場合があります。その場合、XAトランザクションですべてのサービスをスパンできます。これが、アプリケーションサーバーなどが発明された理由です。

補償ベースのアプローチを検討する：

補償アクションは、障害が発生した場合にのみ考慮する必要があります。サービス構成ツールには、最初にワークフローステップを実行するときにクリアされるが、以降の呼び出しで設定されるフラグを制御できますか？JMSで可能な再送信フラグと同様。その後、1.5フェーズコミットと呼ばれるものを使用できます。これは基本的に、フラグがクリアされている場合は先に進むことを意味しますが、フラグが設定されている場合は、最初に呼び出しを行って、状態が既に更新されており、もう一度行う必要があるかどうかを確認します。これには依然として手動のエラー処理が必要であり、指摘するように複雑であるか、不可能でさえあります。

状況によっては問題ではありません：

これが最終的に一貫したアプローチです。1つのサービスがメールを送信するとします。サービス構成が失敗して再起動されると、電子メールが再度送信されます。これは受信者にとってはやや面倒ですが、おそらく重複していることに気づき、問題なく大丈夫です。

また、送信された電子メールのログを保持し、それを使用してフラグが設定されている場合に重複を排除し、その方法で電子メールを一度だけ送信することもできます。

非同期メッセージングを使用して、トランザクションを小さな断片に分割できます。

トランザクションのJMSキューを考えてみましょう。サービスコーディネーターは、単一のTxで状態を更新し、キューにメッセージを投稿できます。ダウンストリームサービスは、メッセージを受け取り、単一のTxで状態を更新できます。これで、複数の作業単位でサービスを調整していますが、それぞれがアトミックです。何かが失敗し、問題なく再起動する必要がある場合。

これは、データベースとJMSキューを介してXAトランザクションを実行していることを意味しますが、XAのオーバーヘッドを完全に回避するために、最後のリソースgambitを使用すると依然として効率的です。

または、このパターンを使用できますが、データベースとJMSへの1.5フェーズコミットを使用します。または、トランザクションなしでJMSを実行できますが、クラスタリングにより信頼性を高めることができます。

非同期メッセージングは​​、生産者と消費者が互いにより独立し、全体的なシステムでのカップリングの量を減らし、システムをより柔軟にすることができるため、システムの分離にも役立ちます。この種のデカップリングは、多くの多様なサービスを備えた大規模な組織の場合、非常に重要です。

いいえ、それは神話です。これは、サービスアーキテクチャを設計するときの誤った意図です。たくさんの問題があります：

1. 非常に密な結合。1つのサービスが変更された場合、システム全体をテストする必要があります。
2. このようなサービスは非常にきめ細かいものであるため、多くの内部通信があります。
3. 細分化された結果として、多くのサービスがあります。システムの理解が難しくなり、クエリの追跡が難しくなっています。
4. エンティティサービスは十分にカプセル化されていません。そこではビジネスルールはチェックされず、このロジックは運用サービスにあります。したがって、どのサービスでも任意のエンティティサービスを呼び出して、そのインターフェイスにある共通の更新クエリでデータを更新できます。このような種類のエンティティサービスは、プロセス中心の動作中心のサービスとは対照的に、データ中心と呼ばれることがよくあります。
5. これらのサービス間の通信の本質的な性質は同期的です。そのため、選択されるトランスポートはhttpになる可能性があります。したがって、そのすべての欠点については後で説明します。

サービスアーキテクチャにアプローチするさらに間違った方法があります。だから注意してください。