問題タブ [soa]

BizTalk を Service Bus として組織に導入しました。これにより、新しい Web GUI が多数の既存のバックエンド システムにリンクされます。既存のシステムをサービス (WCF) としてラップし、BUS に接続しました。

また、レガシー システム GUI の一部を新しい Web GUI に置き換えています (既存の機能を確実に複製します) が、すべてのレガシー サービス/API を BUS 経由で公開するか、それらに直接接続するか、別の方法で構成し、バスを介してそれらを公開します。たとえば、顧客管理システムに、検索、追加、取得、更新、請求詳細の設定という 5 つの既存のサービス/API があるとします。

これらの各サービスを BUS を介して公開することは理にかなっていますか (レイテンシが追加されると主張する人もいます)。それとも、BUS は検索、追加、取得、更新などの粗粒度のサービスのみを公開し、細粒度のサービスは公開しないでください。GUI はきめ細かいサービスに直接接続する必要がありますか?

理想的な SOA/ESB では、Update と Set Billing Details の両方を 1 つの粗粒度サービスに構成するという印象を受けましたが、これは正しいですか?

私は SOA/ESB パラダイムに忠実であり続けたいと思っています。誰か教えてください。

今後のプロジェクトで非同期実行を行うためのソリューションとして MSMQ を使用することを検討しています。WCF と MassTransit などのフレームワーク、または手書きの MSMQ クライアントを使用して、MSMQ からタスクを配置/読み取りすることの違いを知りたいです。

基本的に、アプリケーションは複数の Web サイト (LAN を介した内部またはインターネットを介した外部) であり、サービス層 (WCF または通常の Web サービス) を介してデータを読み書きします。次に、このサービス レイヤーは次の 2 つのいずれかを実行します。1. データベースにデータを書き込む 2. メッセージをキューに入れることでバックグラウンド プロセスをトリガーします。3. 明らかに、データベースからデータを取得することもできます。キューの反対側にある小さなエージェント (Windows サービス) は、キューを監視し、タスク コマンドに基づいて実行します。

このアーキテクチャは、スケーリング (キューとエージェントの追加) が非常に簡単で、RPC や分散実行などに比べて実装が簡単です。また、エージェントの処理はリアルタイムである必要はありません。また、エージェントとサービス層は、共通のドメイン オブジェクトとリポジトリなどを共有することを除いて、別個のアプリケーションです。

どう思いますか？上記の要件に対するアーキテクチャの提案を歓迎します。ありがとうございました！

あなたは優れたソフトウェア製品を持っているのに、なぜそれをSOA互換にするのでしょうか？

SOAの基盤には次のものがあります。

• ゆるく結合
• 再利用性
• ステートレスサービス
• サービス間の正式な契約
• 粗い粒度
• 非同期
• 抽象基礎となるロジック（ブラックボックス）
• 構成可能（ビルディングブロックとしてのサービス）
• 発見可能なサービス
• 自律サービス

それらのほとんどはクラウドコンピューティングに適用できるので、私の質問は、クラウドコンピューティングはSOA思考の産物ですか、それともこれらは2つの異なるモンスターですか？

現在、私の組織内では、パイロット SOA プロジェクトのいくつかの規則を考え出そうとしています。一見したところ、データ エンドポイントに直接アクセスせずに、サービスのユーザーにビジネス サービスの使用を強制するのが最善であると考えました..しかし、これが当てはまらない、または開発者にとって「有効」である可能性がある特定のシナリオはありますか?サービス外の特定のデータ エンドポイントにアクセスするには?

これを公開すると、実際に再利用が損なわれるのではないかと常に恐れています。誰もが、利用可能な同じバックエンドデータを使用して同様のビジネスサービスを「再発明」し、「理論的には..より簡単に」書くだけになるからです。 「私のデータベースを使用するこの他のサービスは何をするのか?」と尋ねるのではなく、新しいビジネス サービスを提供します。

サービスがデータベースへのほぼ直接的なパス スルーである場合でも、開発者の時間を節約し、最終的にはビジネス コストを節約するルールを適用することができるからです。

考え？

誰かがSOAを含むソフトウェア製品またはアプリケーション（商用またはオープンソース）の実例を提供できますか？

たとえば、ソフトウェア製品の最新リリースバージョンがSOA互換になっていると主張するX社のように。

1 つの Oracle システムが 2 つの別個の CRM システム (PeopleSoft と Siebel) のデータ マスターである状況があります。Oracle システムは、顧客データ、在庫データ、製品情報、および製品価格について、CRUD メッセージを BizTalk に送信します。BizTalk はメッセージをフォーマットし、アクションのために PeopelSoft および Siebel Web サービス インターフェイスに転送します。データの最初の同期後、進行中の操作により、データの配信が成功したにもかかわらず、外部の Siebel および PeopleSoft システムでデータが正確でない状況が作成されました (これは、これらのシステムが「成功」を返すときに何を意味するかについての別の会話です)。 ' BizTalk へ)。

この分散サービス指向のアプローチでシステム データを調整するために、他の同様の実装は何をしますか? 比較のためにすべてのシステムから定期的にダンプを実行していますか? 失敗した更新を見つけて同期を確保するための他の手法や方法はありますか?

あなたの考えや経験は大歓迎です。ありがとう！

追加情報

では、なぜシステムが同期しなくなるのでしょうか? 宛先システムがメッセージを受信したことを BizTalk に通知する場合、それは多くのことを意味します。場合によっては、HTTP 200 は、それを取得してステージング テーブルに配置したことを意味し、後でコミットします。これは成功する場合もあれば、さまざまなデータの問題に対応しない場合もあります。HTTP 200 が意味する場合があります... はい、データを受信して​​コミットしました。HTTP を使用すると、注文の配信に問題が発生する可能性があります。これらの問題はすべて、事前に多くの建築計画を立てることで解決できたはずです。それは行われませんでした。順序付けられていない配信がデータを踏むのを防ぐための更新/作成タイムスタンプはありません。宛先システムからのデータ通信の完全な往復確認応答はありません。これらはすべて、同期がずれることになります。

パラメータを Xml としてストアド プロシージャに渡す必要があります。

中間層に WCF サービスがあり、データ層を呼び出して、要求を適切なストアド プロシージャに転送します。

設計は、WCF サービスがリポジトリに渡す Xml の構築を担当することです。

中間層の Xml に含まれるパラメーターを制御するか、クライアントによって構築されたディクショナリを使用して中間層で Xml に変換するかを考えています。

現時点では、後者を選択しました-たとえば：

ただし、最初の方法で行う必要がある場合があります。例えば

ハイブマインドは何を勧めますか？