web-dev-qa-db-ja.com

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

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

アイデアは、既存のサービスをビルディングブロックとして使用して新しいサービスを構成することにより、新しいサービスを迅速に開発できるというものです。新しいメソッドを実装するときに、オブジェクトの既存のメソッドを呼び出す方法に似ています。これは、SOAからの生産性向上の多くが原因であるはずです。

enter image description here

誰かが実際にこれを実際に行いますか？私はこれを書面で延々と繰り返し見たことがありますが、実際の実装を実際に体験したことはありません。ほとんどのテキストではトランザクション処理についての言及も省略されています。これは、合成可能なサービスを実現する上で最大の障害であると私には思われます。

まず、重要なサービスを作成する前に、トランザクションの問題に取り組む必要があります。確かに、例にサービス「findCurrentTime（）」と「writeLogMessage（）」がある場合、トランザクションについて心配するのは簡単ではありませんが、「depositMoney（）」や「withdrawMoney（）」などの実際の例がある場合はそうではありません。

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

  1. WS-Atomic Transactionなどで実際のトランザクションを実装する
  2. Bへの呼び出しが失敗した場合に「cancelA（）」などでAへの呼び出しを補正する補正ベースのソリューションを実装する

これらはどちらも非常に問題があるようです/私にはほとんど使用できません：

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

私にはサービス構成は非常に基本的なSOA原則であり、実際にSOAのメリットを得られない場合、（便利なことに）サービスの作成。現実とは何ですか？SOAユーザーの90％が実際のサービス構成なしで "criplled SOA"を使用していますか？または、ほとんどのユーザーが実際にサービス構成を使用しており、私は難しさを誇張していますそれの？

web-servicessoatransaction
15
Janne Mattila

簡単な答えは「はい」です。

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

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

0
James Anderson

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

より具体的な懸念のいくつかに答えるために...

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

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

報酬ベースのアプローチを検討する：

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

一部の状況では問題ではありません：

これは、最終的には一貫したアプローチです。 1つのサービスがメールを送信するとします。サービス構成が失敗して再起動すると、電子メールが再度送信されます。それは受信者にとって少し煩わしいですが、おそらく彼らはそれが重複していることに気づき、ほとんど問題なくすべてが続行できます。

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

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

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

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

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

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

4
user2800708