The WebLogic.Messaging namespace encapsulates a fully managed WebLogic JMS .NET client. Use the ContextFactory class, to establish an IContext network connection to WebLogic, then use the IContext to look up JMS destinations and JMS connection factories.
| Class | Description |
|---|---|
| Constants | Constants for different areas of JMS. |
| Constants.Context | These constants represent the parameter keys used for creating IContext instances. |
| Constants.Defaults | Message defaults |
| Constants.MessagePropertyNames |
IMessage property names specific to JMS optional capabilities and WebLogic extensions. |
| ContextFactory | This class is a factory for creating an IContext object instance, which represents a network connection to a WebLogic server. |
| ExceptionEventArgs | Provides data for the Exception event. When your asynchronous receive operation calls an event handler, an instance of this class is passed to the handler. |
| IllegalStateException |
This exception is thrown when a method is invoked at an illegal or inappropriate time or if the provider is not in an appropriate state for the requested operation. For example, this exception must be thrown if |
| InvalidClientIDException | This exception must be thrown when a client attempts to set a connection's client ID to a value that is rejected by a provider. |
| InvalidDestinationException | This exception must be thrown when a destination either is not understood by a provider or is no longer valid. |
| InvalidSelectorException | This exception must be thrown when a JMS client attempts to give a provider a message selector with invalid syntax. |
| MessageEOFException |
This exception must be thrown when an unexpected end of stream has been reached when a |
| MessageEventArgs | Provides data for the Message event. When your asynchronous receive operation calls an event handler, an instance of this class is passed to the handler. |
| MessageException |
This is the root class of all JMS API exceptions. It provides the following information:
|
| MessageFormatException |
This exception must 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 must also be thrown when equivalent type errors are made with message property values. For example, this exception must be thrown if |
| MessageNotReadableException |
This exception must be thrown when a JMS client attempts to read a write-only message. |
| MessageNotWriteableException |
This exception must be thrown when a JMS client attempts to write to a read-only message. |
| MessageSecurityException |
This exception must 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. |
| ResourceAllocationException |
This exception is thrown when a provider is unable to allocate the resources required by a method. For example, this exception should be thrown when a call to |
| TransactionInProgressException |
This exception is thrown when an operation is invalid because a transaction is in progress. For instance, an attempt to call |
| TransactionRolledBackException |
This exception must be thrown when a call to |
| Interface | Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IBytesMessage | A IBytesMessage object is used to send a message containing a stream of uninterpreted bytes. It inherits from the IMessage interface and adds a bytes message body. The receiver of the message supplies the interpretation of the bytes. This message type is for client encoding of existing message formats. If possible, one of the other self-defining message types should be used instead. 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. 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 When the message is first created, and when If If a client attempts to read a message in write-only mode, a If a client attempts to write a message in read-only mode, a |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IConnection | A IConnection object is a client's active JMS connection from the WebLogic Server client host to the JMS provider. The JMS provider may run on the same WebLogic Server as the client host. Connections support concurrent use. A connection serves several purposes:
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 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IConnectionFactory | An IConnectionFactory object encapsulates a set of connection configuration parameters that has been defined by an administrator. It is obtained by looking it up in WebLogic Server JNDI using the IContext.LookupConnectionFactory() method. A client uses it to create a connection from the WebLogic .NET client host server to the JMS connection host (which may the same server as the client host). An IConnectionFactory is the equivalent of the java JMS API javax.jms.ConnectionFactory class. An For more information, see the WebLogic JMS .NET client documentation. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IConnectionMetaData | A IConnectionMetaData object provides information describing the IConnection object. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IContext | This interface represents a network connection to a WebLogic Server, and also represents a naming context, which consists of methods for obtaining JNDI name-to-object bindings for JMS destinations and connection factories. The destinations and connection factories may be hosted directly on the WebLogic Server itself, or, if the WebLogic Server is part of a cluster, may be hosted on any WebLogic Server within the same cluster. Use a ContextFactory to create an IContext. SecurityAll JMS resources created using a particular context inherit the optional credential used to create the context. This credential can be overridden when creating anIConnection. NamesEach name passed as an argument to aIContext method is relative to that context. The empty name is used to name the context itself. A name parameter may never be null.ExceptionsAll the methods in this interface can throw aMessageException or any of its subclasses. Concurrent AccessAn IContext instance is guaranteed to be synchronized against concurrent access by multiple threads. Multiple threads each manipulating the same IContext instance need not synchronize. All JMS resources created using the sameIContext instance multiplex over that instance's network connection. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IDestination | A IDestination 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 The JMS API also supports a client's use of provider-specific address names.
A 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 This strategy provides several benefits:
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IMapMessage | A IMapMessage object is used to send a set of name-value pairs. The names are String objects, and the values are primitive data types. The names must have a value that is not null, and not an empty string. The entries can be accessed sequentially or randomly by name. The order of the entries is undefined. IMapMessage inherits from the IMessage interface and adds a message body that contains a Map. 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 When a client receives a
A value written as the row type can be read as the column type.
Attempting to read a null value as a primitive type must be treated as calling the primitive's corresponding |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IMessage | The IMessage interface is the root interface of all JMS messages. It defines the message header and the Acknowledge method used for all messages. 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. 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. With this in mind, the JMS message model has the following goals:
JMS messages are composed of the following parts:
Message Bodies The JMS API defines five types of message body:
Message Headers The
Message Properties A Properties allow an application, via message selectors, to have a JMS provider select, or filter, messages on its behalf using application-specific criteria. Property names must 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 Property values can be 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 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. Message properties support the following conversion table. The marked cases must be supported. The unmarked cases must throw a 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 The The The order of property values is not defined. To iterate through a message's property values, use A message's properties are deleted by the Getting a property value for a name which has not been set returns a null value. Only the The JMS API reserves the 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 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 clients. Provider Implementations of JMS Message InterfacesThe JMS API provides a set of message interfaces that define the JMS message model. It does not provide implementations of these interfaces. Each JMS provider supplies a set of message factories with its A provider must be prepared to accept message implementations that are not its own. They may not be handled as efficiently as its own implementation; however, they must be handled. Note the following exception case when a provider is handling a foreign message implementation. If the foreign message implementation contains a Message SelectorsA 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 Message selectors cannot reference message body values. 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 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:
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 must result in a 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 ValuesAs noted above, property values may be SQL treats a The The boolean operators use three-valued logic as defined by the following tables: The definition of the
The definition of the
The definition of the
Special NotesWhen used in a message selector, the Date and time values should use the standard 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IMessageConsumer | A client uses a IMessageConsumer object to receive messages from a destination. A IMessageConsumer object is created by passing a IDestination object to a message-consumer creation method supplied by a session.
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 For asynchronous delivery, a client can register a It is a client programming error for a |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IMessageProducer | A client uses a IMessageProducer object to send messages to a destination. A IMessageProducer object is created by passing a IDestination object to a message-producer creation method supplied by a session.
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 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. 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). A JMS provider should do its best to expire messages accurately; however, the JMS API does not define the accuracy provided. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IObjectMessage | An IObjectMessage object is used to send a message that contains a default(with Serializable attribute) or custom serializable (implementing ISerializable interface) object. It inherits from the IMessage interface and adds a body containing a single reference to an object. Only default(with Serializable attribute) or custom serializable (implementing ISerializable interface) objects can be used. When a client receives an |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IQueue | A IQueue object encapsulates a provider-specific queue name. It is the way a client specifies the identity of a queue to JMS API methods. For those methods that use a IDestination as a parameter, a IQueue object used as an argument. For example, a queue can be used to create a IMessageConsumer and a IMessageProducer by calling:
The actual length of time messages are held by a queue and the consequences of resource overflow are not defined by the JMS API. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ISession |
A A session serves several purposes:
A session can create and service multiple message producers and consumers. One typical use is to have a thread block on a synchronous If a client desires to have one thread produce messages while others consume them, the client should 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 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 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 The Java Transaction Service (JTS) or some other transaction monitor may be used to combine a session's transaction with transactions on other resources (databases, other JMS sessions, etc.). Since Java distributed transactions are controlled via the Java Transaction API (JTA), use of the session's The JMS API does not require support for JTA; however, it does define how a provider supplies this support. Although it is also possible for a JMS client to handle distributed transactions directly, it is unlikely that many JMS clients will do this. Support for JTA in the JMS API is targeted at systems vendors who will be integrating the JMS API into their application server products. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IStreamMessage | A IStreamMessage object is used to send a stream of primitive types. It is filled and read sequentially. It inherits from the IMessage interface and adds a stream message body. 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 When the message is first created, and when If If a client attempts to read a message in write-only mode, a If a client attempts to write a message in read-only mode, a
A value written as the row type can be read as the column type.
Attempting to read a null value as a primitive type must be treated as calling the primitive's corresponding |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ITextMessage | A ITextMessage object is used to send a message containing a String. It inherits from the IMessage interface and adds a text message body. This message type can be used to transport text-based messages, including those with XML content. When a client receives a |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ITopic | A ITopic object encapsulates a provider-specific topic name. It is the way a client specifies the identity of a topic to JMS API methods. For those methods that use a IDestination as a parameter, a ITopic object may used as an argument . For example, a ITopic can be used to create a IMessageConsumer and a IMessageProducer by calling:
Many publish/subscribe (pub/sub) providers group topics into hierarchies and provide various options for subscribing to parts of the hierarchy. The JMS API places no restriction on what a The organization of topics and the granularity of subscriptions to them is an important part of a pub/sub application's architecture. The JMS API does not specify a policy for how this should be done. If an application takes advantage of a provider-specific topic-grouping mechanism, it should document this. If the application is installed using a different provider, it is the job of the administrator to construct an equivalent topic architecture and create equivalent |
| Delegate | Description |
|---|---|
| ExceptionEventHandler | Exception handler event delegate. If a JMS provider detects a serious problem with a IConnection object, it informs the IConnection object's ExceptionEventHandler, if one has been registered. It does this by calling the listener's method, passing it a MessageException argument describing the problem. 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. para>A JMS provider should attempt to resolve connection problems itself before it notifies the client of them. Object Connection object that provides feedback regarding exception conditionExceptionEventArgs generated by JMS provider |
| MessageEventHandler | Message event delegate. A 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 IMessageConsumer message senderMessageEventArgs is the message passed to the listener |
| Enumeration | Description |
|---|---|
| Constants.DeliveryMode | The delivery modes supported by the JMS API are PERSISTENT and NON_PERSISTENT. A 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. Clients use delivery mode to tell a JMS provider how to balance message transport reliability with throughput. |
| Constants.DestinationType | Represents the type of the destination such as a queue or topic. |
| Constants.SessionMode | Session Modes available for Session objects |