01: /*
02: * @(#)Destination.java 1.16 02/04/09
03: *
04: * Copyright 1997-2002 Sun Microsystems, Inc. All Rights Reserved.
05: *
06: * SUN PROPRIETARY/CONFIDENTIAL.
07: * This software is the proprietary information of Sun Microsystems, Inc.
08: * Use is subject to license terms.
09: *
10: */
11:
12: package javax.jms;
13:
14: /** A <CODE>Destination</CODE> object encapsulates a provider-specific
15: * address.
16: * The JMS API does not define a standard address syntax. Although a standard
17: * address syntax was considered, it was decided that the differences in
18: * address semantics between existing message-oriented middleware (MOM)
19: * products were too wide to bridge with a single syntax.
20: *
21: * <P>Since <CODE>Destination</CODE> is an administered object, it may
22: * contain
23: * provider-specific configuration information in addition to its address.
24: *
25: * <P>The JMS API also supports a client's use of provider-specific address
26: * names.
27: *
28: * <P><CODE>Destination</CODE> objects support concurrent use.
29: *
30: * <P>A <CODE>Destination</CODE> object is a JMS administered object.
31: *
32: * <P>JMS administered objects are objects containing configuration
33: * information that are created by an administrator and later used by
34: * JMS clients. They make it practical to administer the JMS API in the
35: * enterprise.
36: *
37: * <P>Although the interfaces for administered objects do not explicitly
38: * depend on the Java Naming and Directory Interface (JNDI) API, the JMS API
39: * establishes the convention that JMS clients find administered objects by
40: * looking them up in a JNDI namespace.
41: *
42: * <P>An administrator can place an administered object anywhere in a
43: * namespace. The JMS API does not define a naming policy.
44: *
45: * <P>It is expected that JMS providers will provide the tools an
46: * administrator needs to create and configure administered objects in a
47: * JNDI namespace. JMS provider implementations of administered objects
48: * should implement the <CODE>javax.naming.Referenceable</CODE> and
49: * <CODE>java.io.Serializable</CODE> interfaces so that they can be stored in
50: * all JNDI naming contexts. In addition, it is recommended that these
51: * implementations follow the JavaBeans<SUP><FONT SIZE="-2">TM</FONT></SUP>
52: * design patterns.
53: *
54: * <P>This strategy provides several benefits:
55: *
56: * <UL>
57: * <LI>It hides provider-specific details from JMS clients.
58: * <LI>It abstracts JMS administrative information into objects in the Java
59: * programming language ("Java objects")
60: * that are easily organized and administered from a common
61: * management console.
62: * <LI>Since there will be JNDI providers for all popular naming
63: * services, JMS providers can deliver one implementation
64: * of administered objects that will run everywhere.
65: * </UL>
66: *
67: * <P>An administered object should not hold on to any remote resources.
68: * Its lookup should not use remote resources other than those used by the
69: * JNDI API itself.
70: *
71: * <P>Clients should think of administered objects as local Java objects.
72: * Looking them up should not have any hidden side effects or use surprising
73: * amounts of local resources.
74: *
75: * @version 1.0 - 3 August 1998
76: * @author Mark Hapner
77: * @author Rich Burridge
78: *
79: * @see javax.jms.Queue
80: * @see javax.jms.Topic
81: */
82:
83: public interface Destination {
84: }
|