パッケージ jakarta.jms

インターフェース Destination

  • すべての既知のサブインターフェース:
    QueueTemporaryQueueTemporaryTopicTopic

    public interface Destination
    Destination オブジェクトは、プロバイダー固有のアドレスをカプセル化します。Jakarta Messaging API は、標準のアドレス構文を定義していません。標準のアドレス構文が検討されましたが、既存のメッセージ指向ミドルウェア(MOM)製品間のアドレスセマンティクスの違いは、1 つの構文でブリッジするには広すぎると判断されました。

    Destination は管理対象オブジェクトであるため、アドレスに加えてプロバイダー固有の構成情報が含まれる場合があります。

    Jakarta Messaging API は、クライアントによるプロバイダー固有のアドレス名の使用もサポートしています。

    Destination オブジェクトは同時使用をサポートします。

    Destination オブジェクトは、Jakarta Messaging 管理対象オブジェクトです。

    Jakarta Messaging 管理対象オブジェクトは、管理者が作成し、後で Jakarta Messaging クライアントが使用する構成情報を含むオブジェクトです。企業内で Jakarta Messaging API を管理するのが現実的です。

    管理対象オブジェクトのインターフェースは、Java Naming and Directory Interface(JNDI)API に明示的に依存していませんが、Jakarta Messaging API は、Jakarta Messaging クライアントが JNDI 名前空間でルックアップすることにより、管理対象オブジェクトを見つけるという規則を確立します。

    管理者は、名前空間の任意の場所に管理対象オブジェクトを配置できます。Jakarta Messaging API は命名ポリシーを定義していません。

    Jakarta Messaging プロバイダーは、管理者が JNDI 名前空間で管理対象オブジェクトを作成および構成するために必要なツールを提供することが期待されています。管理対象オブジェクトの Jakarta Messaging プロバイダー実装は、javax.naming.Referenceable および java.io.Serializable インターフェースを実装して、すべての JNDI ネーミングコンテキストに格納できるようにする必要があります。さらに、これらの実装は JavaBeans TM 設計パターンに従うことが推奨されます。

    この戦略にはいくつかの利点があります。

    • Jakarta Messaging クライアントからプロバイダー固有の詳細を隠します。
    • これは、Jakarta Messaging 管理情報を Java プログラミング言語のオブジェクト(「Java オブジェクト」)に抽象化し、共通の管理コンソールから簡単に編成および管理できるようにします。
    • すべての一般的なネーミングサービス用の JNDI プロバイダーが存在するため、Jakarta Messaging プロバイダーは、どこでも実行される管理対象オブジェクトの 1 つの実装を提供できます。

    管理対象オブジェクトは、リモートリソースを保持しないでください。そのルックアップでは、JNDI API 自体で使用されるもの以外のリモートリソースを使用しないでください。

    クライアントは、管理対象オブジェクトをローカル Java オブジェクトと考える必要があります。調べると、隠れた副作用が発生したり、意外な量のローカルリソースを使用したりすることはできません。

    導入:
    JMS 1.0
    バージョン:
    Jakarta Messaging 2.0
    関連事項:
    Queue, Topic