私は最近、SOA や ESB などについて多くの調査を行っています。
現在、いくつかのレガシー システムの再設計に取り組んでおり、現在よりも多くの SOA アーキテクチャを使用してシステムを構築したいと考えています。これらのサービスを約 5 つの Web サイトで使用していますが、レガシー システムで現在抱えている最大の問題の 1 つは、ほとんどの場合、バグの修正や更新を行うときに、5 つの Web サイトを再デプロイする必要があることです。かなり時間のかかるプロセス。
私の目標は、依存するすべてのサービスと Web サイトを再デプロイしなくても変更できるように、サービス間のインターフェイスを疎結合にすることです。
依存関係を壊したり更新したりせずに、既存のサービス インターフェイスを拡張する機能が必要です。以前にこの問題に遭遇した人はいますか? どのように解決しましたか？
これまでとは異なるスタイルのサービスを検討することをお勧めします。リクエスト/レスポンスではなく、イベントを使用して相互に連携するサービスを検討してください。私はこのアプローチを長年にわたってさまざまな分野のクライアントに使用してきましたが、大きな成功を収めています。過去 4 年間で、これらのトピックについてかなりの量の記事を書いてきました。開始できる場所の 1 つは次のとおりです。
http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/
それが役立つことを願っています。
いくつかの方法があります。私たちの SOA アーキテクチャには、サービスとの間で送受信される XML メッセージが含まれます。あなたが説明したことを達成する1つの方法は、XMLスキーマへのデータバインディングライブラリの使用を避け、汎用XMLパーサーを使用して、興味のないデータノードを無視して必要なデータノードだけを取得することです。このようにして、サービスは追加できます現在それを使用している人を壊すことなく、メッセージに新しいノードを追加します。通常、これは、より大きなスキーマ構造から 1 つまたは 2 つの情報が必要な場合にのみ行います。
別の方法として、私たちが使用するもう 1 つの (推奨される) ソリューションはバージョン管理です。サービスのバージョンは、特定のスキーマ/インターフェースに準拠しています。スキーマが変更された場合 (たとえば、インターフェイスが拡張または変更された場合)、サービスの新しいバージョンが作成されます。いつでも、2 つまたは 3 つのバージョンが常に移動している可能性があります。やがて、古いバージョンを非推奨にしてから削除し、最終的に依存するコードを新しいバージョンに移行します。このようにして、サービスに依存している人はサービスの既存のバージョンを引き続き使用できますが、特定の依存関係は新しいバージョンに「アップグレード」できます。呼び出されるサービスのバージョンは、依存コードの構成ファイルで定義されます。バージョン管理されるのはスキーマだけでなく、基礎となるすべての実装コードであることに注意してください。
お役に立てれば。
サービスの緩い結合を実現するための一般的な方法がいくつかあります。
Webサービスのドキュメント/リテラルスタイルを使用し、RPCの代わりにデータ（ワイヤー形式）で考え、スキーマベースのデータバインディングを避けます。
データを送信するときは契約を厳守しますが、受信データを処理するという仮定はほとんどありません。xpathはそのための優れたツールです（緩め、締める）
ESBを使用し、サービス間の直接のポイントツーポイント通信を避けます。
あなたが求めているのは簡単な話題ではありません。サービス指向アーキテクチャを疎結合にする方法はたくさんあります。
Thomas Erl のSOA book seriesをチェックすることをお勧めします。すべてを非常に明確かつ詳細に説明しています。