1 /* 2 * The contents of this file are subject to the terms 3 * of the Common Development and Distribution License 4 * (the License). You may not use this file except in 5 * compliance with the License. 6 * 7 * You can obtain a copy of the license at 8 * https://glassfish.dev.java.net/public/CDDLv1.0.html or 9 * glassfish/bootstrap/legal/CDDLv1.0.txt. 10 * See the License for the specific language governing 11 * permissions and limitations under the License. 12 * 13 * When distributing Covered Code, include this CDDL 14 * Header Notice in each file and include the License file 15 * at glassfish/bootstrap/legal/CDDLv1.0.txt. 16 * If applicable, add the following below the CDDL Header, 17 * with the fields enclosed by brackets [] replaced by 18 * you own identifying information: 19 * "Portions Copyrighted [year] [name of copyright owner]" 20 * 21 * Copyright 2006 Sun Microsystems, Inc. All rights reserved. 22 */ 23 24 25 package javax.jms; 26 27 /** A <CODE>Destination</CODE> object encapsulates a provider-specific 28 * address. 29 * The JMS API does not define a standard address syntax. Although a standard 30 * address syntax was considered, it was decided that the differences in 31 * address semantics between existing message-oriented middleware (MOM) 32 * products were too wide to bridge with a single syntax. 33 * 34 * <P>Since <CODE>Destination</CODE> is an administered object, it may 35 * contain 36 * provider-specific configuration information in addition to its address. 37 * 38 * <P>The JMS API also supports a client's use of provider-specific address 39 * names. 40 * 41 * <P><CODE>Destination</CODE> objects support concurrent use. 42 * 43 * <P>A <CODE>Destination</CODE> object is a JMS administered object. 44 * 45 * <P>JMS administered objects are objects containing configuration 46 * information that are created by an administrator and later used by 47 * JMS clients. They make it practical to administer the JMS API in the 48 * enterprise. 49 * 50 * <P>Although the interfaces for administered objects do not explicitly 51 * depend on the Java Naming and Directory Interface (JNDI) API, the JMS API 52 * establishes the convention that JMS clients find administered objects by 53 * looking them up in a JNDI namespace. 54 * 55 * <P>An administrator can place an administered object anywhere in a 56 * namespace. The JMS API does not define a naming policy. 57 * 58 * <P>It is expected that JMS providers will provide the tools an 59 * administrator needs to create and configure administered objects in a 60 * JNDI namespace. JMS provider implementations of administered objects 61 * should implement the <CODE>javax.naming.Referenceable</CODE> and 62 * <CODE>java.io.Serializable</CODE> interfaces so that they can be stored in 63 * all JNDI naming contexts. In addition, it is recommended that these 64 * implementations follow the JavaBeans<SUP><FONT SIZE="-2">TM</FONT></SUP> 65 * design patterns. 66 * 67 * <P>This strategy provides several benefits: 68 * 69 * <UL> 70 * <LI>It hides provider-specific details from JMS clients. 71 * <LI>It abstracts JMS administrative information into objects in the Java 72 * programming language ("Java objects") 73 * that are easily organized and administered from a common 74 * management console. 75 * <LI>Since there will be JNDI providers for all popular naming 76 * services, JMS providers can deliver one implementation 77 * of administered objects that will run everywhere. 78 * </UL> 79 * 80 * <P>An administered object should not hold on to any remote resources. 81 * Its lookup should not use remote resources other than those used by the 82 * JNDI API itself. 83 * 84 * <P>Clients should think of administered objects as local Java objects. 85 * Looking them up should not have any hidden side effects or use surprising 86 * amounts of local resources. 87 * 88 * @version 1.0 - 3 August 1998 89 * @author Mark Hapner 90 * @author Rich Burridge 91 * 92 * @see javax.jms.Queue 93 * @see javax.jms.Topic 94 */ 95 96 public interface Destination { 97 } 98