3

パターン指向のソフトウェア アーキテクチャ vol 2 で、並行ソフトウェアとネットワーク ソフトウェアの課題について読んでいます。

サービス アクセスには、OMG イベント サービスなどの再利用可能なコンポーネントに対するリモート操作の呼び出しが含まれることがよくあります。サービスとアプリケーションの静的および動的な進化をサポートすることは、ネットワーク化されたソフトウェア システムにおけるもう 1 つの重要な課題です。

進化は次の方法で発生する可能性があります

コンポーネント サービス ロールへのインターフェイスとコンポーネント サービス ロール間の接続は、多くの場合実行時に変更される可能性があり、新しいサービス ロールを実装して既存のコンポーネントにインストールおよびインストールすることができます。

システムに「オンデマンド」で構成され、システムが最初に設計されたときには実装が不明なサービスにアクセスする方法を決定することは、さらに困難です。ここでの設計上の課題は 2 つあります。

  1. 第 1 に、アプリケーションは、詳細なインターフェイスを認識していなくても、新しいサービスをエクスポートする必要があります。

  2. 第 2 に、アプリケーションはこれらのサービスを独自の制御フローと処理シーケンスに、実行時であっても透過的かつ堅牢に統合する必要があります。

以下の質問に答えて、上記のテキストを理解するためにあなたの助けが必要です.

  1. 「コンポーネント サービス ロールへのインターフェイスとコンポーネント サービス ロール間の接続は、多くの場合、実行時に変更される可能性がある」という著者の意味は何ですか? わかりやすい例で説明してほしい。

  2. 上記のオンデマンドの課題について述べた 2 つのポイントについて、著者は何を意味していますか。上記の 2 点について詳細を要求します。

お時間をいただきありがとうございます。

4

1 に答える 1

0

1.「コンポーネント サービス ロールへのインターフェイスとコンポーネント サービス ロール間の接続は、多くの場合、実行時に変更される可能性がある」という著者の意味は何ですか?

正確にはわかりません。次の理由により、インターフェイスは時間の経過とともに変化します。

  • SOAP から REST への移行、または XML から JSON への移行など、新しい技術標準を採用することはできますが、それは展開を通じて時間の経過とともにゆっくりと行われます。インターフェイスが急速に変化しているのを見てください。
  • ビジネス ニーズを満たすために、API またはインターフェイス コントラクト自体が変更されます。

2.上記のオンデマンドチャレンジの2点について、著者は何を意味していますか?

うーん、良いデザインパターンは、時間が経っても生き残る傾向があります (SOLID のように壊れることがないため、変更されることはありません)。あなたが参照している本は2000年に書かれたと思います-それ以来多くの変化がありました.そのため、パターンは生き残っているかもしれませんが、おそらく私たちが現在説明している方法は変化しています.解釈に)...

1.最初に、アプリケーションは、詳細なインターフェイスを認識していなくても、新しいサービスをエクスポートする必要があります。

懸念の分離 (基本的な OO のもの)、アプリのすべての部分は、他の部分が内部で何をしているかを本質的に認識していません (すべきではありません)。同様に、誰か (外部システムを含む) がインターフェイスを満足させている限り、内部でそれがどのように行われるかを誰が気にします。

2.次に、アプリケーションはこれらのサービスを独自の制御フローと処理シーケンスに透過的かつ堅牢に、実行時でも統合する必要があります。

私はこれを、プログラムが壊れてはならず、常にコンパイルする必要があり、アプリケーションが動的にコードを作成して実行している場合 (たとえば、ユーザー入力に基づいて)、動的コードが壊れないようにインプレースでチェックする必要があることを意味すると考えています。アプリを壊すこともありません。

于 2013-09-18T05:39:01.033 に答える