|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
javax.jms Interface Destination
- All Known Subinterfaces:
- Queue, TemporaryQueue, TemporaryTopic, Topic
public interface Destination
Destination
对象封装特定于提供者的地址。JMS API 不定义标准地址语法。尽管曾考虑过标准地址语法,但最终决定现有面向消息中间件 (MOM) 产品之间的地址语义差异太大,难以通过单个语法来概括。
由于 Destination
是一个管理对象,因此除其地址之外,它可能还包含特定于提供者的配置信息。
JMS API 还支持客户端使用特定于提供者的地址名称。
Destination
对象支持并发使用。
Destination
对象是一个 JMS 管理对象。
JMS 管理对象是由管理员创建且随后供 JMS 客户端使用的包含配置信息的对象。它们使在企业中管理 JMS API 成为现实。
虽然管理对象的接口并不明确依赖于 Java Naming and Directory Interface (JNDI) API,但 JMS API 约定 JMS 客户端通过 JNDI 名称空间查找管理对象。
管理员可以将管理对象放在名称空间的任何地方。JMS API 不定义命名策略。
JMS 提供者应该提供管理员在 JNDI 名称空间中创建和配置管理对象所需的工具。管理对象的 JMS 提供者实现应该实现 javax.naming.Referenceable
和 java.io.Serializable
接口,以便它们可以存储在所有 JNDI 命名上下文中。此外,建议这些实现遵循 JavaBeansTM 设计模式。
此战略有以下几点好处:
- 它向 JMS 客户端隐藏了特定于提供者的细节。
- 它将 JMS 管理信息抽象到 Java 编程语言的对象(“Java 对象”)中,通过通用管理控制台可以容易地组织和管理这些对象。
- 由于所有流行的命名服务都会有 JNDI 提供者,因此 JMS 提供者能够交付一个在任何地方都能运行的管理对象的实现。
管理对象不应占用任何远程资源。它的查询不应该使用远程资源,JNDI API 本身使用的那些资源除外。
客户端应该将管理对象视为本地 Java 对象。查询它们不应带来任何隐藏的副作用或使用大量的本地资源。
version |
| |
See also | javax.jms.Queue, javax.jms.Topic |
A Destination
object encapsulates a provider-specific
address.
The JMS API does not define a standard address syntax. Although a standard
address syntax was considered, it was decided that the differences in
address semantics between existing message-oriented middleware (MOM)
products were too wide to bridge with a single syntax.
Since Destination
is an administered object, it may
contain
provider-specific configuration information in addition to its address.
The JMS API also supports a client's use of provider-specific address names.
Destination
objects support concurrent use.
A Destination
object is a JMS administered object.
JMS administered objects are objects containing configuration information that are created by an administrator and later used by JMS clients. They make it practical to administer the JMS API in the enterprise.
Although the interfaces for administered objects do not explicitly depend on the Java Naming and Directory Interface (JNDI) API, the JMS API establishes the convention that JMS clients find administered objects by looking them up in a JNDI namespace.
An administrator can place an administered object anywhere in a namespace. The JMS API does not define a naming policy.
It is expected that JMS providers will provide the tools an
administrator needs to create and configure administered objects in a
JNDI namespace. JMS provider implementations of administered objects
should implement the javax.naming.Referenceable
and
java.io.Serializable
interfaces so that they can be stored in
all JNDI naming contexts. In addition, it is recommended that these
implementations follow the JavaBeansTM
design patterns.
This strategy provides several benefits:
- It hides provider-specific details from JMS clients.
- It abstracts JMS administrative information into objects in the Java programming language ("Java objects") that are easily organized and administered from a common management console.
- Since there will be JNDI providers for all popular naming services, JMS providers can deliver one implementation of administered objects that will run everywhere.
An administered object should not hold on to any remote resources. Its lookup should not use remote resources other than those used by the JNDI API itself.
Clients should think of administered objects as local Java objects. Looking them up should not have any hidden side effects or use surprising amounts of local resources.
|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Submit a bug or feature
Copyright 2007 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.
PS : 未经我党受权你也可自由散发此文档。 如有任何错误请自行修正;若因此而造成任何损失请直接找人民主席,请勿与本人联系。谢谢!