WebLogic.Messaging Namespace

This exception will be thrown when an unexpected end of stream has been reached when a IStreamMessage or IBytesMessage is being read.

This is the root class of all JMS API exceptions.

It provides the following information:

• A provider-specific string describing the error. This string is the standard exception message and is available via the Message property.
• A provider-specific string error code (WebLogic JMS does not normally set error codes)
• An inner exception. Often a JMS API exception will be the result of a lower-level problem. If appropriate, this lower-level exception is supplied as an inner exception to the JMS API exception.

This exception will be thrown when a JMS client attempts to use a data type not supported by a message or attempts to read data in a message as the wrong type. It is also thrown when equivalent type errors are made with message property values. For example, this exception will be thrown if IStreamMessage.WriteObject is given an unsupported class or if IStreamMessage.ReadShort is used to read a boolean value. Note that the special case of a failure caused by an attempt to read improperly formatted String data as numeric values throw a System.FormatException.

This exception will be thrown when a JMS client attempts to read a write-only message.

This exception will be thrown when a JMS client attempts to write to a read-only message.

This exception will be thrown when a provider rejects a user name/password submitted by a client. It may also be thrown for any case where a security restriction prevents a method from completing.

This exception is thrown when a provider is unable to allocate the resources required by a method. For example, when an attempt to send a message is rejected due to server quotas.

This exception is thrown when an operation is invalid because a transaction is in progress.

This exception may be thrown when a call to ISession.Commit results in a Rollback of the current transaction.

The primitive types can be written explicitly using methods for each type. They may also be written generically as objects. For instance, a call to IBytesMessage.WriteInt(6) is equivalent to IBytesMessage.WriteObject((int)6). Both forms are provided, because the explicit form is convenient for static programming, and the object form is needed when types are not known at compile time.

When the message is first created, and when ClearBody is called, the body of the message is in write-only mode. After the first call to Reset has been made, the message body is in read-only mode. After a message has been sent, the client that sent it can retain and modify it without affecting the message that has been sent. The same message object can be sent multiple times. When a message has been received, JMS has internally called Reset so that the message body is in read-only mode for the client.

If ClearBody is called on a message in read-only mode, the message body is cleared and the message is in write-only mode.

If a client attempts to read a message in write-only mode, a MessageNotReadableException is thrown.

If a client attempts to write a message in read-only mode, a MessageNotWriteableException is thrown.

Important: Applications must call IConnection.Start() to enable receivers to receive messages because new connections begin in a stopped state.

Connections support concurrent use.

A connection serves several purposes:

• It encapsulates an open connection with a JMS server. It can represents a network connection between the WebLogic Server client host and the JMS subsystem, if the JMS subsystem and the client host are two different servers.
• Its creation is where client authentication optionally takes place.
• It can specify a unique client identifier.
• It provides a IConnectionMetaData object.
• It supports an optional ExceptionEventHandler object.

Because the creation of a connection involves setting up authentication and communication, a connection is a relatively heavyweight object to create and close. Most clients will do all their messaging with a single connection. Other more advanced applications may use several connections.

A JMS client typically creates a connection, one or more sessions, and a number of message producers and consumers. When a connection is created, it is in stopped mode. That means that no messages are being delivered.

It is typical to leave the connection in stopped mode until setup is complete (that is, until all message consumers have been created). At that point, the client calls the connection's Start method, and messages begin arriving at the connection's consumers. This setup convention minimizes any client confusion that may result from asynchronous message delivery while the client is still in the process of setting itself up.

A connection can be started immediately, and the setup can be done afterwards. Clients that do this must be prepared to handle asynchronous message delivery while they are still in the process of setting up.

A message producer can send messages while a connection is stopped.

An IConnectionFactory object is a JMS administered object and supports concurrent use.

For more information, see the WebLogic JMS .NET client documentation.

IContext instances support concurrent use.

Security

Names

Exceptions

Concurrent Access

IDestination objects support concurrent use.

An IDestination 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. Clients should think of administered objects as local Java objects. Looking them up does not have any hidden side effects or use surprising amounts of local resources.

The primitive types can be read or written explicitly using methods for each type. They may also be read or written generically as objects. For instance, a call to IMapMessage.SetInt("foo", 6) is equivalent to IMapMessage.SetObject("foo", (int)6). Both forms are provided, because the explicit form is convenient for static programming, and the object form is needed when types are not known at compile time.

When a client receives an IMapMessage, it is in read-only mode. If a client attempts to write to the message at this point, a MessageNotWriteableException is thrown. If ClearBody is called, the message can now be both read from and written to.

IMapMessage objects support the following conversion table. The marked cases are supported. The unmarked cases will throw a MessageException.

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

Attempting to read a null value as a primitive type will throw a NullPointerException.

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.

JMS messages are composed of the following parts:

• 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.
• 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.
• Body - The JMS API defines several types of message body, which cover the majority of messaging styles currently in use.

Message Bodies

The JMS API defines five types of message body:

• Stream - An IStreamMessage object's message body contains a stream of primitive values. It is filled and read sequentially.
• Map - An IMapMessage object's message body contains a set of name-value pairs, where names are String objects, and values are primitive type objects. The entries can be accessed sequentially or randomly by name. The order of the entries is undefined.
• Text - An ITextMessage object's message body contains a String object. This message type can be used to transport plain-text messages, and XML messages.
• Object - An IObjectMessage object's message body contains a Serializable .Net object.
• Bytes - An IBytesMessage 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.

Message Headers

The JMSCorrelationID header field is used for linking one message with another. It typically links a reply message with its requesting message. JMSCorrelationID can hold a provider-specific message ID, an application-specific String object, or a provider-native byte[] value.

Other message header fields include JMSMessageID - a unique message identifier, JMSDestination, JMSDeliveryMode, JMSPriority, JMSExpiration, JMSTimestamp, JMSRedelivered, JMSReplyTo, and JMSType.

Message Properties

An IMessage 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.

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

Property names obey the rules for a message selector identifier. Property names must not be null, and must not be empty strings. If a property name is set and it is either null or an empty string, an ArgumentException will be thrown.

Property values can be boolean, sbyte, short, int, long, float, double, and String.

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 MessageNotWriteableException is thrown. If ClearProperties 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.

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 will likely handle data in a message's body or header field 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.

Message properties support the following conversion table. The marked cases are supported. The unmarked cases will throw a MessageException.

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

In addition to the type-specific set/get methods for properties, JMS provides the SetObjectProperty and GetObjectProperty 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.

The SetObjectProperty method accepts values of class bool, sbyte, short, int, long, float, double, and String. An attempt to use any other class will throw a MessageFormatException.

The GetObjectProperty method only returns values of class bool, sbyte, short, int, long, float, double, and String.

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

A message's properties are deleted by the ClearProperties method. This leaves the message with an empty set of properties.

Getting a property value for a name which has not been set returns a null value. Only the GetStringProperty and GetObjectProperty methods can return a null value.

The JMS API reserves the JMSX property name prefix for optional 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 String[] IConnectionMetaData.getJMSXPropertyNames method returns the names of the JMSX properties supported by a connection.

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.

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.

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

Implementations of JMS Message Interfaces

The JMS API provides a set of message interfaces that define the JMS message model. It does not provide implementations of these interfaces.

JMS supplies a set of message factories with its ISession object for creating instances of messages.

Message Selectors

A JMS message selector allows a client to specify, by header field references and property references, the messages it is interested in. Only messages whose header and property values match the selector are delivered. What it means for a message not to be delivered depends on the IMessageConsumer being used.

Message selectors cannot reference message body values except via a WebLogic extension for XML text messages.

A message selector matches a message if the selector evaluates to true when the message's header field values and property values are substituted for their corresponding identifiers in the selector.

A message selector is a String whose syntax is based on a subset of the SQL92 conditional expression syntax. If the value of a message selector is an empty string, the value is treated as a null and indicates that there is no message selector for the message consumer.

The order of evaluation of a message selector is from left to right within precedence level. Parentheses can be used to change this order.

Predefined selector literals and operator names are shown here in uppercase; however, they are case insensitive.

A selector can contain:

• Literals:
  • A string literal is enclosed in single quotes, with a single quote represented by doubled single quote; for example, 'literal' and 'literal''s'. Like string literals in the C# programming language, these use the Unicode character encoding.
  • An exact numeric literal is a numeric value without a decimal point, such as 57, -957, and +62; numbers in the range of long are supported. Exact numeric literals use the integer literal syntax of the C# programming language.
  • An approximate numeric literal is a numeric value in scientific notation, such as 7E3 and -57.9E2, or a numeric value with a decimal, such as 7., -95.7, and +6.2; numbers in the range of double are supported. Approximate literals use the floating-point literal syntax of the C# programming language.
  • The boolean literals TRUE and FALSE.
• Identifiers:
  • An identifier is an unlimited-length sequence of letters and digits, the first of which must be a letter. A letter is any character for which the method Char.isLetter returns true. This includes '_' and '$'. A letter or digit is any character for which the method Char.isLetterOrDigit returns true.
  • Identifiers cannot be the names NULL, TRUE, and FALSE.
  • Identifiers cannot be NOT, AND, OR, BETWEEN, LIKE, IN, IS, or ESCAPE.
  • Identifiers are either header field references or property references. The type of a property value in a message selector corresponds to the type used to set the property. If a property that does not exist in a message is referenced, its value is NULL.
  • The conversions that apply to the get methods for properties do not apply when a property is used in a message selector expression. For example, suppose you set a property as a string value, as in the following:

    myMessage.SetStringProperty("NumberOfOrders", "2");

    The following expression in a message selector would evaluate to false, because a string cannot be used in an arithmetic expression:

    "NumberOfOrders > 1"

  • Identifiers are case-sensitive.
  • Message header field references are restricted to JMSDeliveryMode, JMSPriority, JMSMessageID, JMSTimestamp, JMSCorrelationID, and JMSType. JMSMessageID, JMSCorrelationID, and JMSType values may be null and if so are treated as a NULL value.
  • Any name beginning with 'JMSX' is a JMS defined property name.
  • Any name beginning with 'JMS_' is a provider-specific property name.
  • Any name that does not begin with 'JMS' is an application-specific property name.
• White space is the same as that defined for the C# programming language: space, horizontal tab, form feed, and line terminator.
• Expressions:
  • A selector is a conditional expression; a selector that evaluates to true matches; a selector that evaluates to false or unknown does not match.
  • Arithmetic expressions are composed of themselves, arithmetic operations, identifiers (whose value is treated as a numeric literal), and numeric literals.
  • Conditional expressions are composed of themselves, comparison operations, and logical operations.
• Standard bracketing () for ordering expression evaluation is supported.
• Logical operators in precedence order: NOT, AND, OR
• Comparison operators: =, >, >=, <, <=, <> (not equal)
  • Only like type values can be compared. One exception is that it is valid to compare exact numeric values and approximate numeric values; the type conversion required is defined by the rules of numeric promotion in the C# programming language. If the comparison of non-like type values is attempted, the value of the operation is false. If either of the type values evaluates to NULL, the value of the expression is unknown.
  • String and boolean comparison is restricted to = and <>. Two strings are equal if and only if they contain the same sequence of characters.
• Arithmetic operators in precedence order:
  • +, - (unary)
  • *, / (multiplication and division)
  • +, - (addition and subtraction)
  • Arithmetic operations use numeric promotion in the Java programming language.
• arithmetic-expr1 [NOT] BETWEEN arithmetic-expr2 AND arithmetic-expr3 (comparison operator)
  • "age BETWEEN 15 AND 19" is equivalent to "age >= 15 AND age <= 19"
  • "age NOT BETWEEN 15 AND 19" is equivalent to "age < 15 OR age > 19"
• identifier [NOT] IN (string-literal1, string-literal2,...) (comparison operator where identifier has a String or NULL value)
  • "Country IN (' UK', 'US', 'France')" is true for 'UK' and false for 'Peru'; it is equivalent to the expression "(Country = ' UK') OR (Country = ' US') OR (Country = ' France')"
  • "Country NOT IN (' UK', 'US', 'France')" is false for 'UK' and true for 'Peru'; it is equivalent to the expression "NOT ((Country = ' UK') OR (Country = ' US') OR (Country = ' France'))"
  • If identifier of an IN or NOT IN operation is NULL, the value of the operation is unknown.
• identifier [NOT] LIKE pattern-value [ESCAPE escape-character] (comparison operator, where identifier has a String value; pattern-value is a string literal where '_' stands for any single character; '%' stands for any sequence of characters, including the empty sequence; and all other characters stand for themselves. The optional escape-character is a single-character string literal whose character is used to escape the special meaning of the '_' and '%' in pattern-value.)
  • "phone LIKE '12%3'" is true for '123' or '12993' and false for '1234'
  • "word LIKE 'l_se'" is true for 'lose' and false for 'loose'
  • "underscored LIKE '\_%' ESCAPE '\'" is true for '_foo' and false for 'bar'
  • "phone NOT LIKE '12%3'" is false for '123' or '12993' and true for '1234'
  • If identifier of a LIKE or NOT LIKE operation is NULL, the value of the operation is unknown.
• identifier IS NULL (comparison operator that tests for a null header field value or a missing property value)
  • "prop_name IS NULL"
• identifier IS NOT NULL (comparison operator that tests for the existence of a non-null header field value or a property value)
  • "prop_name IS NOT NULL"

JMS providers are required to verify the syntactic correctness of a message selector at the time it is presented. A method that provides a syntactically incorrect selector will result in a InvalidSelectorException. JMS providers may also optionally provide some semantic checking at the time the selector is presented. Not all semantic checking can be performed at the time a message selector is presented, because property types are not known.

The following message selector selects messages with a message type of car and color of blue and weight greater than 2500 pounds:

"JMSType = 'car' AND color = 'blue' AND weight > 2500"

Null Values

As noted above, property values may be NULL. The evaluation of selector expressions containing NULL values is defined by SQL92 NULL semantics. A brief description of these semantics is provided here.

SQL treats a NULL value as unknown. Comparison or arithmetic with an unknown value always yields an unknown value.

The IS NULL and IS NOT NULL operators convert an unknown value into the respective TRUE and FALSE values.

The boolean operators use three-valued logic as defined by the following tables:

The definition of the AND operator

The definition of the OR operator

The definition of the NOT operator

Special Notes

When used in a message selector, the JMSDeliveryMode header field is treated as having the values 'PERSISTENT' and 'NON_PERSISTENT'.

Date and time values use the standard Java long millisecond value which is the difference, measured in milliseconds, between a given time time and midnight, January 1, 1970 UTC. When a date or time literal is included in a message selector, it should be an integer literal for a millisecond value. For an example of how to convert between Java millisecond timestamps and .NET times, see the API doc for IMessage.JMSTimestamp.

Although SQL supports fixed decimal comparison and arithmetic, JMS message selectors do not. This is the reason for restricting exact numeric literals to those without a decimal (and the addition of numerics with a decimal as an alternate representation for approximate numeric values).

SQL comments are not supported.

A message consumer can be created with a message selector. A message selector allows the client to restrict the messages delivered to the message consumer to those that match the selector.

A client may either synchronously receive a message consumer's messages or have the consumer asynchronously deliver them as they arrive.

For synchronous receipt, a client can request the next message from a message consumer using one of its Receive methods. There are several variations of Receive that allow a client to poll or wait for the next message.

For asynchronous delivery, a client can register a MessageEventHandler object with a message consumer. As messages arrive at the message consumer, it delivers them by calling the MessageEventHandler's mesage event handler method.

It is a client programming error for a MessageEventHandler to throw an exception.

A client also has the option of creating a message producer without supplying a destination. In this case, a destination must be provided with every send operation. A typical use for this kind of message producer is to send replies to requests using the request's JMSReplyTo destination.

A client can specify a default delivery mode, priority, and time to live for messages sent by a message producer. It can also specify the delivery mode, priority, and time to live for an individual message as a parameter to a send operation.

A client can specify a time-to-live value in milliseconds for each message it sends. This value defines a message expiration time that is the sum of the message's time-to-live and the GMT when it is sent (for transacted sends, this is the time the client sends the message, not the time the transaction is committed).

When a client receives an IObjectMessage, it is in read-only mode. If a client attempts to write to the message at this point, a MessageNotWriteableException is thrown. If ClearBody is called, the message can now be both read from and written to.

• ISession.CreateConsumer(IQueue queue)
• ISession.CreateProducer(IQueue queue)

An ISession object is a single-threaded context for producing and consuming messages.

Warning: While an IConnection object supports multi-threaded access, an ISession object only supports single threaded access and multi-threaded behavior is undefined. If an application requires multiple concurrently active consumers and/or producers, then the application must create multiple sessions. For additional information on multi-threading, read the following paragraphs carefully, also see the WebLogic .NET programmer's guide best practices section for examples of improperly coding applications for thread safety when using sessions and their child messages, consumers, and producers.

A session serves several purposes:

• It is a factory for its message producers and consumers.
• It supplies message factories.
• It provides a way to lookup IQueue or ITopic objects for those clients that need to dynamically use provider-specific destination names (most applications instead lookup destinations using the IContext JNDI lookup method).
• It supports a single series of transactions that combine work spanning its producers and consumers into atomic units.
• It defines a serial order for the messages it consumes and the messages it produces.
• It retains messages it consumes until they have been acknowledged.
• It serializes execution of message listeners registered with its message consumers.

A session can create and service multiple message producers and consumers. Do not multi-thread the session - for example do not call two producers from the same session concurrently - see the Warning note above and read on for more information.

One typical use is to have a thread block on a synchronous IMessageConsumer until a message arrives. The thread may then use one or more of the ISession's IMessageProducers.

If a client desires to have one thread produce messages while others concurrently consume them, the client must use a separate session for its producing thread.

Once a connection has been started, any session with one or more registered message listeners is dedicated to the thread of control that delivers messages to it. It is erroneous for client code to use this session or any of its constituent objects from another thread of control. The only exception to this rule is the use of the session or connection Close method.

It should be easy for most clients to partition their work naturally into sessions. This model allows clients to Start simply and incrementally add message processing complexity as their need for concurrency grows.

The Close method is the only session method that can be called while some other session method is being executed in another thread.

A session may be specified as transacted. Each transacted session supports a single series of transactions. Each transaction groups a set of message sends and a set of message receives into an atomic unit of work. In effect, transactions organize a session's input message stream and output message stream into series of atomic units. When a transaction commits, its atomic unit of input is acknowledged and its associated atomic unit of output is sent. If a transaction Rollback is done, the transaction's sent messages are destroyed and the session's input is automatically recovered.

The content of a transaction's input and output units is simply those messages that have been produced and consumed within the session's current transaction.

A transaction is completed using either its session's Commit method or its session's Rollback method. The completion of a session's current transaction automatically begins the next. The result is that a transacted session always has a current transaction within which its work is done. If a Commit call throws an ambiguous exception, then the result of the transaction is ambiguous: either all operations within the transaction succeeded, or all operations rolled back.

The primitive types can be read or written explicitly using methods for each type. They may also be read or written generically as objects. For instance, a call to IStreamMessage.WriteInt(6) is equivalent to IStreamMessage.WriteObject((int)6). Both forms are provided, because the explicit form is convenient for static programming, and the object form is needed when types are not known at compile time.

When the message is first created, and when ClearBody is called, the body of the message is in write-only mode. After the first call to Reset has been made, the message body is in read-only mode. After a message has been sent, the client that sent it can retain and modify it without affecting the message that has been sent. The same message object can be sent multiple times. When a message has been received, the JMS has internally called Reset so that the message body is in read-only mode for the client.

If ClearBody is called on a message in read-only mode, the message body is cleared and the message body is in write-only mode.

If a client attempts to read a message in write-only mode, a MessageNotReadableException is thrown.

If a client attempts to write a message in read-only mode, a MessageNotWriteableException is thrown.

IStreamMessage objects support the following conversion table. The marked cases are supported, while the unmarked cases will throw a MessageException.

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

Attempting to read a null value as a primitive type will throw a NullPointerException.

This message type can be used to transport text-based messages, including those with XML content.

When a client receives a ITextMessage, it is in read-only mode. If a client attempts to write to the message at this point, a MessageNotWriteableException is thrown. If ClearBody is called, the message can now be both read from and written to.

• ISession.CreateConsumer(ITopic topic)
• ISession.CreateProducer(ITopic topic)

An exception listener allows a client to be notified of a problem asynchronously. Some connections only consume messages, so they would have no other way to learn that their connection has failed.

A MessageEventHandler delegate object is used to receive asynchronously delivered messages.

Each session must insure that it passes messages serially to the listener. This means that a listener assigned to one or more consumers of the same session can assume that the onMessage method is not called with the next message until the session has completed the last call.

An IMessageProducer client marks a message as persistent if it feels that the application will have problems if the message is lost in transit. A client marks a message as non-persistent if an occasional lost message is tolerable.