1. /*

  2.  * Copyright 2002 Sun Microsystems, Inc. All rights reserved.

  3.  * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.

  4.  */

  5. 

  6. package javax.jms;

  7. 

  8. /** A <CODE>Destination</CODE> object encapsulates a provider-specific 

  9.   * address.

  10.   * The JMS API does not define a standard address syntax. Although a standard

  11.   * address syntax was considered, it was decided that the differences in 

  12.   * address semantics between existing message-oriented middleware (MOM) 

  13.   * products were too wide to bridge with a single syntax. 

  14.   *

  15.   * <P>Since <CODE>Destination</CODE> is an administered object, it may 

  16.   * contain 

  17.   * provider-specific configuration information in addition to its address.

  18.   *

  19.   * <P>The JMS API also supports a client's use of provider-specific address 

  20.   * names.

  21.   *

  22.   * <P><CODE>Destination</CODE> objects support concurrent use.

  23.   *

  24.   * <P>A <CODE>Destination</CODE> object is a JMS administered object.

  25.   *

  26.   * <P>JMS administered objects are objects containing configuration 

  27.   * information that are created by an administrator and later used by 

  28.   * JMS clients. They make it practical to administer the JMS API in the 

  29.   * enterprise.

  30.   *

  31.   * <P>Although the interfaces for administered objects do not explicitly 

  32.   * depend on the Java Naming and Directory Interface (JNDI) API, the JMS API 

  33.   * establishes the convention that JMS clients find administered objects by

  34.   * looking them up in a JNDI namespace.

  35.   *

  36.   * <P>An administrator can place an administered object anywhere in a 

  37.   * namespace. The JMS API does not define a naming policy.

  38.   *

  39.   * <P>It is expected that JMS providers will provide the tools an

  40.   * administrator needs to create and configure administered objects in a

  41.   * JNDI namespace. JMS provider implementations of administered objects

  42.   * should implement the <CODE>javax.naming.Referenceable</CODE> and

  43.   * <CODE>java.io.Serializable</CODE> interfaces so that they can be stored in 

  44.   * all JNDI naming contexts. In addition, it is recommended that these

  45.   * implementations follow the JavaBeans<SUP><FONT SIZE="-2">TM</FONT></SUP> 

  46.   * design patterns.

  47.   *

  48.   * <P>This strategy provides several benefits:

  49.   *

  50.   * <UL>

  51.   *   <LI>It hides provider-specific details from JMS clients.

  52.   *   <LI>It abstracts JMS administrative information into objects in the Java 

  53.   *       programming language ("Java objects") 

  54.   *       that are easily organized and administered from a common 

  55.   *       management console.

  56.   *   <LI>Since there will be JNDI providers for all popular naming 

  57.   *       services, JMS providers can deliver one implementation

  58.   *       of administered objects that will run everywhere.

  59.   * </UL>

  60.   *

  61.   * <P>An administered object should not hold on to any remote resources. 

  62.   * Its lookup should not use remote resources other than those used by the

  63.   * JNDI API itself.

  64.   *

  65.   * <P>Clients should think of administered objects as local Java objects. 

  66.   * Looking them up should not have any hidden side effects or use surprising 

  67.   * amounts of local resources.

  68.   *

  69.   * @version     1.0 - 3 August 1998

  70.   * @author      Mark Hapner

  71.   * @author      Rich Burridge

  72.   *

  73.   * @see         javax.jms.Queue

  74.   * @see         javax.jms.Topic

  75.   */

  76. 

  77. public interface Destination {

  78. }