8.8. サービスレプリケーションの仕組み

helloworld.esb などのサービスを取得し、それを Node2 および Node1 にデプロイするとどうなりますか ?レジストリーに jUDDI を使用し、1 つの中央 jUDDI データベースにアクセスできるようにすべてのノードを設定していることを前提とします。Node2 は、FirstServiceESB - SimpleListener サービスがすでに登録されていることを見つけます。したがって、このサービスに 2 番目の ServiceBinding を追加するため、このサービスには 2 つの ServiceBinding があります。したがって、Node1 がダウンすると、Node2 は機能し続けます。

両方のサービスインスタンスは同じキューをリッスンするため、負荷分散がある点に注意してください。

このタイプのレプリケーションは、サービスの可用性を高めたり、負荷分散を提供するために使用したりできます。4 つの個別のサービスで設定されるアプリケーションサービスについて考えてみましょう。それぞれのサービスは同じ機能を提供し、同じサービスコントラクトに準拠します。これらは、同じトランスポートプロトコルを共有する必要がない場合にのみ異なります。ただし、アプリケーションサービスのユーザーには、サービス名とカテゴリーで識別される単一のサービスのみが表示されていました。ServiceInvoker は、アプリケーションサービスが実際にはクライアントから 4 つの他のサービスで設定されるという事実を非表示にします。個別のサービスの失敗をマスクし、複製されたサービスグループの少なくとも 1 つのインスタンスが利用できる限り、クライアントが前進進捗できるようにします。

サービスのレプリケーションは、サービスコンシューマーの制御外にあるサービスプロバイダーによって定義できます。そのため、メッセージの送信者がレジストリー内で記述されている場合に、別のサービスの使用にサイレントにフェイルオーバーしたくない場合があります。org.jboss.soa.esb.exceptionOnDeliverFailure メッセージプロパティーを true に設定すると、ServiceInvoker によって再試行が行われず、MessageDeliverException が出力されます。すべてのメッセージにこのアプローチを指定する場合は、JBossESB プロパティーファイルの Core セクションで同じプロパティーを定義します。