message.html

来自「SUN公司官方J2EE中文帮助文档 应该不错 有兴趣的下来看看 html格式的」· HTML 代码 · 共 1,316 行 · 第 1/5 页

HTML
1,316
字号
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN""http://www.w3.org/TR/REC-html40/frameset.dtd">
<!--NewPage-->
<HTML>
<HEAD>
<!-- Generated by javadoc on Thu Jan 17 03:51:31 PST 2002 -->
<TITLE>
Java 2 Platform EE v1.3: Interface  Message
</TITLE>
<LINK REL ="stylesheet" TYPE="text/css" HREF="../../stylesheet.css" TITLE="Style">
</HEAD>
<BODY BGCOLOR="white">

<!-- ========== START OF NAVBAR ========== -->
<A NAME="navbar_top"><!-- --></A>
<TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0">
<TR>
<TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1">
<A NAME="navbar_top_firstrow"><!-- --></A>
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3">
  <TR ALIGN="center" VALIGN="top">
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="package-summary.html"><FONT CLASS="NavBarFont1"><B>Package</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> &nbsp;<FONT CLASS="NavBarFont1Rev"><B>Class</B></FONT>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../index-all.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A>&nbsp;</TD>
  </TR>
</TABLE>
</TD>
<TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM>
</EM>
</TD>
</TR>

<TR>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
&nbsp;<A HREF="../../javax/jms/MapMessage.html"><B>PREV CLASS</B></A>&nbsp;
&nbsp;<A HREF="../../javax/jms/MessageConsumer.html"><B>NEXT CLASS</B></A></FONT></TD>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
  <A HREF="../../index.html" TARGET="_top"><B>FRAMES</B></A>  &nbsp;
&nbsp;<A HREF="Message.html" TARGET="_top"><B>NO FRAMES</B></A></FONT></TD>
</TR>
<TR>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
  SUMMARY: &nbsp;INNER&nbsp;|&nbsp;<A HREF="#field_summary">FIELD</A>&nbsp;|&nbsp;CONSTR&nbsp;|&nbsp;<A HREF="#method_summary">METHOD</A></FONT></TD>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
DETAIL: &nbsp;<A HREF="#field_detail">FIELD</A>&nbsp;|&nbsp;CONSTR&nbsp;|&nbsp;<A HREF="#method_detail">METHOD</A></FONT></TD>
</TR>
</TABLE>
<!-- =========== END OF NAVBAR =========== -->

<HR>
<!-- ======== START OF CLASS DATA ======== -->
<H2>
<FONT SIZE="-1">
javax.jms</FONT>
<BR>
Interface  Message</H2>
<DL>
<DT><B>All Known Subinterfaces:</B> <DD><A HREF="../../javax/jms/BytesMessage.html">BytesMessage</A>, <A HREF="../../javax/jms/MapMessage.html">MapMessage</A>, <A HREF="../../javax/jms/ObjectMessage.html">ObjectMessage</A>, <A HREF="../../javax/jms/StreamMessage.html">StreamMessage</A>, <A HREF="../../javax/jms/TextMessage.html">TextMessage</A></DD>
</DL>
<HR>
<DL>
<DT>public interface <B>Message</B></DL>

<P>
The <CODE>Message</CODE> interface is the root interface of all JMS 
 messages. It defines the message header and the <CODE>acknowledge</CODE> 
 method used for all messages.

 <P>Most message-oriented middleware (MOM) products treat messages as 
 lightweight entities that consist
 of a header and a payload. The header contains fields used for message
 routing and identification; the payload contains the application data
 being sent.

 <P>Within this general form, the definition of a message varies
 significantly across products. It would be quite difficult for the JMS API
 to support all of these message models.

 <P>With this in mind, the JMS message model has the following goals:
 <UL>
   <LI>Provide a single, unified message API
   <LI>Provide an API suitable for creating messages that match the
       format used by provider-native messaging applications
   <LI>Support the development of heterogeneous applications that span
       operating systems, machine architectures, and computer languages
   <LI>Support messages containing objects in the Java programming language
       ("Java objects")
   <LI>Support messages containing Extensible Markup Language (XML) pages
 </UL>

 <P>JMS messages are composed of the following parts:
 <UL>
   <LI>Header - All messages support the same set of header fields. 
       Header fields contain values used by both clients and providers to 
       identify and route messages.
   <LI>Properties - Each message contains a built-in facility for supporting
       application-defined property values. Properties provide an efficient 
       mechanism for supporting application-defined message filtering.
   <LI>Body - The JMS API defines several types of message body, which cover
       the majority of messaging styles currently in use.
 </UL>

 <H4>Message Bodies</H4>

 <P>The JMS API defines five types of message body:
 <UL>
   <LI>Stream - A <CODE>StreamMessage</CODE> object's message body contains 
       a stream of primitive values in the Java programming 
       language ("Java primitives"). It is filled and read sequentially.
   <LI>Map - A <CODE>MapMessage</CODE> object's message body contains a set 
       of name-value pairs, where names are <CODE>String</CODE> 
       objects, and values are Java primitives. The entries can be accessed 
       sequentially or randomly by name. The order of the entries is 
       undefined.
   <LI>Text - A <CODE>TextMessage</CODE> object's message body contains a 
       <CODE>java.lang.String</CODE> object. The inclusion 
       of this message type is based on our presumption that XML will 
       likely become a popular mechanism for representing content of all 
       kinds, including the content of JMS messages.
   <LI>Object - An <CODE>ObjectMessage</CODE> object's message body contains 
       a <CODE>Serializable</CODE> Java object.
   <LI>Bytes - A <CODE>BytesMessage</CODE> object's message body contains a 
       stream of uninterpreted bytes. This message type is for 
       literally encoding a body to match an existing message format. In 
       many cases, it is possible to use one of the other body types, 
       which are easier to use. Although the JMS API allows the use of  
       message properties with byte messages, they are typically not used,
       since the inclusion of properties may affect the format.
 </UL>

 <H4>Message Headers</H4>

 <P>The <CODE>JMSCorrelationID</CODE> header field is used for linking one 
 message with
 another. It typically links a reply message with its requesting message.

 <P><CODE>JMSCorrelationID</CODE> can hold a provider-specific message ID,
 an application-specific <CODE>String</CODE> object, or a provider-native 
 <CODE>byte[]</CODE> value.

 <H4>Message Properties</H4>

 <P>A <CODE>Message</CODE> object contains a built-in facility for supporting
 application-defined property values. In effect, this provides a mechanism 
 for adding application-specific header fields to a message.

 <P>Properties allow an application, via message selectors, to have a JMS 
 provider select, or filter, messages on its behalf using 
 application-specific criteria.

 <P>Property names must obey the rules for a message selector identifier. 

 <P>Property values can be <CODE>boolean</CODE>, <CODE>byte</CODE>, 
 <CODE>short</CODE>, <CODE>int</CODE>, <CODE>long</CODE>, <CODE>float</CODE>,
 <CODE>double</CODE>, and <CODE>String</CODE>.

 <P>Property values are set prior to sending a message. When a client 
 receives a message, its properties are in read-only mode. If a 
 client attempts to set properties at this point, a 
 <CODE>MessageNotWriteableException</CODE> is thrown. If 
 <CODE>clearProperties</CODE> is called, the properties can now be both
 read from and written to. Note that header fields are distinct from 
 properties. Header fields are never in read-only mode. 

 <P>A property value may duplicate a value in a message's body, or it may 
 not. Although JMS does not define a policy for what should or should not 
 be made a property, application developers should note that JMS providers 
 will likely handle data in a message's body more efficiently than data in 
 a message's properties. For best performance, applications should use
 message properties only when they need to customize a message's header. 
 The primary reason for doing this is to support customized message 
 selection.

 <P>Message properties support the following conversion table. The marked 
 cases must be supported. The unmarked cases must throw a 
 <CODE>JMSException</CODE>. The <CODE>String</CODE>-to-primitive conversions 
 may throw a runtime exception if the
 primitive's <CODE>valueOf</CODE> method does not accept the 
 <CODE>String</CODE> as a valid representation of the primitive.

 <P>A value written as the row type can be read as the column type.

 <PRE>
 |        | boolean byte short int long float double String 
 |----------------------------------------------------------
 |boolean |    X                                       X
 |byte    |          X     X    X   X                  X 
 |short   |                X    X   X                  X 
 |int     |                     X   X                  X 
 |long    |                         X                  X 
 |float   |                               X     X      X 
 |double  |                                     X      X 
 |String  |    X     X     X    X   X     X     X      X 
 |----------------------------------------------------------
 </PRE>

 <P>In addition to the type-specific set/get methods for properties, JMS 
 provides the <CODE>setObjectProperty</CODE> and 
 <CODE>getObjectProperty</CODE> methods. These support the same set of 
 property types using the objectified primitive values. Their purpose is 
 to allow the decision of property type to made at execution time rather 
 than at compile time. They support the same property value conversions.

 <P>The <CODE>setObjectProperty</CODE> method accepts values of class 
 <CODE>Boolean</CODE>, <CODE>Byte</CODE>, <CODE>Short</CODE>, 
 <CODE>Integer</CODE>, <CODE>Long</CODE>, <CODE>Float</CODE>, 
 <CODE>Double</CODE>, and <CODE>String</CODE>. An attempt 
 to use any other class must throw a <CODE>JMSException</CODE>.

 <P>The <CODE>getObjectProperty</CODE> method only returns values of class 
 <CODE>Boolean</CODE>, <CODE>Byte</CODE>, <CODE>Short</CODE>, 
 <CODE>Integer</CODE>, <CODE>Long</CODE>, <CODE>Float</CODE>, 
 <CODE>Double</CODE>, and <CODE>String</CODE>.

 <P>The order of property values is not defined. To iterate through a 
 message's property values, use <CODE>getPropertyNames</CODE> to retrieve 
 a property name enumeration and then use the various property get methods 
 to retrieve their values.

 <P>A message's properties are deleted by the <CODE>clearProperties</CODE>
 method. This leaves the message with an empty set of properties.

 <P>Getting a property value for a name which has not been set returns a 
 null value. Only the <CODE>getStringProperty</CODE> and 
 <CODE>getObjectProperty</CODE> methods can return a null value. 
 Attempting to read a null value as a primitive type must be treated as 
 calling the primitive's corresponding <CODE>valueOf(String)</CODE> 
 conversion method with a null value.

 <P>The JMS API reserves the <CODE>JMSX</CODE> property name prefix for JMS 
 defined properties.
 The full set of these properties is defined in the Java Message Service
 specification. New JMS defined properties may be added in later versions 
 of the JMS API.  Support for these properties is optional. The 
 <CODE>String[] ConnectionMetaData.getJMSXPropertyNames</CODE> method 
 returns the names of the JMSX properties supported by a connection.

 <P>JMSX properties may be referenced in message selectors whether or not
 they are supported by a connection. If they are not present in a
 message, they are treated like any other absent property.

 <P>JMSX properties defined in the specification as "set by provider on 
 send" are available to both the producer and the consumers of the message. 
 JMSX properties defined in the specification as "set by provider on 
 receive" are available only to the consumers.

 <P><CODE>JMSXGroupID</CODE> and <CODE>JMSXGroupSeq</CODE> are standard 
 properties that clients 
 should use if they want to group messages. All providers must support them.
 Unless specifically noted, the values and semantics of the JMSX properties 
 are undefined.

 <P>The JMS API reserves the <CODE>JMS_<I>vendor_name</I></CODE> property 
 name prefix for provider-specific properties. Each provider defines its own 
 value for <CODE><I>vendor_name</I></CODE>. This is the mechanism a JMS 
 provider uses to make its special per-message services available to a JMS 
 client.

 <P>The purpose of provider-specific properties is to provide special 
 features needed to integrate JMS clients with provider-native clients in a 
 single JMS application. They should not be used for messaging between JMS 

⌨️ 快捷键说明

复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?