These sections provide an overview of the WebLogic JMS .NET client, illustrate how a JMS .NET client application accesses WebLogic JMS resources, and provide a brief summary of the WebLogic JMS .NET API.
It is assumed that the reader is familiar with .NET programming and JMS 1.1 concepts and features.
The WebLogic JMS .NET client is a fully-managed .NET runtime library and application programming interface (API). It enables programmers to create .NET C# client applications that can access WebLogic Java Message Service (JMS) applications and resources.
WebLogic JMS is an enterprise-level messaging system that fully supports the JMS 1.1 Specification and also provides numerous WebLogic JMS Extensions to the standard JMS APIs. To familiarize yourself with the features of WebLogic JMS, see the Messaging for Oracle WebLogic Server web page on the edocs Web site. For a summary of the WebLogic Server value-added JMS features, see “WebLogic Server Value-Added JMS Features” in Configuring and Managing WebLogic JMS.
For complete details about all the classes and interfaces in the JMS .NET API, see the WebLogic Messaging API Reference for .NET Clients documentation.
The WebLogic JMS .NET client, which is bundled with WebLogic Server 10g Release 3 and higher, is supported on Microsoft .NET Framework versions 2.0 through 3.5. Installation details are provided in Installing and Copying the WebLogic JMS .NET Client Libraries.
For this release, the WebLogic JMS .NET client supports the major standard features of the JMS Version 1.1 Specification. For a list of the JMS 1.1 standard features that are not supported, see Limitations of Using the WebLogic JMS .NET Client.
In addition to the standard JMS 1.1 Specification support, the WebLogic JMS .NET client also supports several WebLogic JMS extensions. For more information about the features supported and how they can be used with the JMS .NET client, see Using WebLogic JMS Extensions.
The WebLogic JMS .NET client supports the following messaging models:
Messages can be specified as persistent or non-persistent:
For more information, see “Understanding the Messaging Models” in Programming WebLogic JMS.
The WebLogic JMS .NET client supports the following message types, as defined in the JMS 1.1 Specification:
The XMLMessage type extension provided by WebLogic JMS is not supported in this release. Such messages are automatically converted to a TextMessage type when received by a .NET client.
For more information about using the supported message types, see Exchanging Messages Between Different Language Environments.
The following figure illustrates how a JMS .NET client application running in a .NET Framework CLR can access JMS resources deployed on WebLogic Server.
Note: | All of the WebLogic components shown in Figure 1-1 are hosted on a single instance of WebLogic Server 10g Release 3 or later. In a multi-server or cluster configuration, each of the WebLogic Server components can run on a separate instance of WebLogic Server. However, the JMS .NET client host must run on WebLogic Server 10g Release 3 or later, and the connection host and the JMS server must run in the same WebLogic Server 8.1 or later cluster. |
The major components depicted in the illustration consist of the following:
Traffic to the JMS servers is always routed from the .NET client through the JMS .NET client host to the connection host to the JMS servers. Traffic to the JMS .NET client is always routed from the JMS servers to the connection host and through the JMS .NET client host to the .NET client.
A brief summary of the process used to exchange messages between the JMS .NET client and a JMS server, as illustrated in Figure 1-1, is summarized in the following steps:
Instructions and examples for creating a JMS .NET client application are provided in Developing a Basic JMS Application Using the WebLogic JMS .NET API.
The following sections describe the configuration that must occur before a JMS .NET client application can access JMS resources.
The JMS .NET client requires that a listen port configured for T3 protocol is enabled on the WebLogic Server instance hosting the JMS .NET client host. When you install WebLogic Server, a default port is configured for use with T3 protocol. Because the default port configuration can be changed or disabled, the system administrator needs to ensure that the T3 protocol is enabled on the server’s default port, or add a network channel that supports the T3 protocol. For configuration information, see the following topics:
Before a JMS .NET client application can access JMS resources deployed on WebLogic Server, the WebLogic Server system administrator must configure the required JMS resources, including the connection factories, JMS servers, and destinations. For instructions for configuring JMS resources, see:
The JMS .NET client can communicate directly only with WebLogic Server 10g Release 3 and later. As shown in Figure 1-2, the JMS .NET client host must run on WebLogic Server 10g Release 3 or later, however, the connection host and the JMS server can run on WebLogic Server 8.1 or later. Both the connection host and the JMS server must be in the same cluster.
To access destinations on WebLogic Server 8.1 or later that are not in the same cluster as the .NET client host running on 10g Release 3 or later, you must configure the remote instance of WebLogic Server as a Foreign Server. For more information, see “Configuring Foreign Server Resources to Access Third-Party JMS Providers” in Configuring and Managing WebLogic JMS.
Note: | Although you can also use Foreign Servers to connect to third-party JMS providers using JMS Java clients, this feature is not supported in the WebLogic JMS .NET client. |
The following table lists the primary JMS .NET API classes and interfaces used to create a JMS .NET client application. For complete details about all the classes and interfaces in the JMS .NET API, see the WebLogic Messaging API Reference for .NET Clients documentation.
An
ITopic object is pub/sub IDestination that 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 an IDestination as a parameter, an ITopic object may be used as an argument. For example, an ITopic can be used to create an IMessageConsumer and an IMessageProducer by calling:
|
|
An
IQueue object is a point-to-point IDestination that encapsulates a provider-specific queue name. It is the way a client specifies the identity of a queue to JMS API methods.
|
|
The
IMessage interface is the root interface of all JMS messages. It defines the message header and the Acknowledge method used for all messages.
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.
|
|
An
IMapMessage object is used to send a set of name-value pairs. The names are String objects, and the values are primitive data types in the Java and C# programming languages. 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.
|
|
An
IObjectMessage object is used to send a message that contains a serializable object in the Java and C# programming languages. It inherits from the IMessage interface and adds a body containing a single reference to an object. C# objects cannot be read by Java programs, and vice versa. For more information, see Exchanging Messages Between Different Language Environments.
|
|
An
IStreamMessage object is used to send a stream of primitive types in the Java programming language. It is filled and read sequentially. It inherits from the IMessage interface and adds a stream message body. Its methods are based largely on those found in java.io.DataInputStream and java.io.DataOutputStream .
|
|