Adapter messages can be delivered using either the TIBCO Rendezvous transport or the JMS transport. This section introduces the transports and explains the quality of services available under each.
To fully understand the TIBCO Rendezvous features used by adapters, you should read TIBCO Rendezvous Concepts. The book is available in the TIBCO Runtime Agent installation area in the <install-path>
/tibco/tibrv/doc
folder.
Before configuring an adapter service with the JMS transport, you should be familiar with JMS concepts, which are explained fully in the TIBCO Enterprise for JMS User’s Guide. The book is available from the machine on which the TIBCO Enterprise for JMS software is installed in the <install-path>
/tibco/jms/doc
directory.
TIBCO Rendezvous integrates distributed applications by providing a common, message-based communication mechanism. One main component is the TIBCO Rendezvous daemon, which runs on each participating computer on your network. All information that travels between adapter instances passes through the TIBCO Rendezvous daemon as the information enters and exits host computers. The daemon also passes information between adapters running on the same host. Many hardware and software platforms are supported, so programs on different kinds of computers on a network can communicate seamlessly.
TIBCO Rendezvous software uses subject-based addressing™ technology to direct messages to their destinations. An adapter configured with a publication service sends that information on a well-defined subject name. Each adapter configured with a subscription service listens on a subject name. The TIBCO Rendezvous daemon handles the network messages corresponding to the peer-to-peer communication between the publication adapter and the subscription adapter. This allows adapters to communicate without knowing the details of network addresses or connections. Subject-based addressing conventions define a uniform name space for messages and their destinations.
The publication and subscription services interactions are driven by events (usually the arrival or creation of data). An adapter publication service makes information available for general distribution. Communication is in one direction (publisher to subscribers), and often one-to-many as shown in the next diagram. The complete interaction consists of one multicast message, published once, and received by all subscribers.
In publication and subscription services interactions, data producers are decoupled from data consumersthey do not coordinate data transmission with each other, except by using the same subject name. The adapter publishes data to the network at large.
Demand for data drives request response interactions. An adapter requests data from a vendor application; the application computes an individual response and returns it to the adapter. Communication flows in both directions, as shown in the next diagram. The complete interaction consist of two point-to-point messagesa request and a response.
In request interactions, data producers coordinate closely with data consumers. A adapter does not send data until a request is made by a vendor application. Each program sends its message to a specific inbox name within the other program.
The adapter sends its response specifically to the vendor application that requested the data. The requesting application listens until it receives the reply, and then stops listening (unless it expects further installments of information).
If your adapter uses the TIBCO Rendezvous transport, the reliable and certified delivery protocols are available. Table 2 compares the two delivery protocols.
The transactional delivery mode requires an additional component, TIBCO Rendezvous TX. The mode provide transaction control over messages, store-and-forward messaging, and exactly-once delivery. Note that distributed transactions are not supported.
This mode allows multiple adapters to distribute the load among the distributed queue members. The service is used for adapters configured with the subscription service or request response to provide process level load balancing.
Note that a distributed queue cannot be used for adapters configured with the publication or request response invocation services. See the TIBCO Rendezvous Concepts book for more information.
The adapter can be configured to send messages in one of the following wire formats.
An adapter should generally use the TIBCO ActiveEnterprise wire format to send messages. Messages that use the TIBCO ActiveEnterprise wire format are TIBCO Rendezvous messages with some structure imposed. The structure includes control information that makes it easier for the receiving application to process the message.
The XML Message
wire format conforms to specifically constructed and fully compliant XML Schema (XSD) based on the existing definition of the TIBCO ActiveEnterprise schema.
An adapter can send messages using the TIBCO Rendezvous wire format. This wire format does not include control information in the message. This wire format should only be used for communicating with applications configured for the TIBCO environment that do not support the TIBCO ActiveEnterprise wire format.
The TIBCO Rendezvous wire format should be chosen to communicate with a native TIBCO Rendezvous application while the TIBCO ActiveEnterprise wire format should be chosen to communicate among TIBCO applications that use TIBCO ActiveEnterprise Operations for their service configurations.
This section provides an overview of TIBCO Enterprise for JMS product. See the TIBCO Enterprise for JMS User’s Guide for more information.
JMS is based on creation and delivery of messages. Messages are structured data that an adapter sends to another adapter or vendor application. An adapter publication service produces messages that are consumed by an adapter subscription service. The TIBCO Enterprise for JMS server acts as an intermediary for the message and sends it to the correct destination.
The next diagram shows an adapter publication service producing a message, sending it by way of the server, and an adapter subscription service receiving the message.
JMS supports publish and subscribe (topics), and point-to-point (queues) interactions.
In a publish and subscribe message system, producers address messages to a topic. In this model, the producer is known as a publisher and the consumer is known as a subscriber.
Many publishers can publish to the same topic, and a message from a single publisher can be received by many subscribers. Subscribers subscribe to topics, and all messages published to the topic are received by all subscribers to the topic. This type of message protocol is also known as broadcast messaging because messages are sent over the network and received by all interested subscribers, similar to how radio or television signals are broadcast and received.
The next diagram shows publish and subscribe messaging. Each message consumer subscribes to a topic. When a message is published to that topic, all subscribed consumers receive the message.
There can be a time dependency in publish and subscribe mode. By default, subscribers only receive messages when they are active. If messages are delivered when the subscriber is not available, the subscriber does not receive those messages. The JMS API provides a method to remove part of the timing dependency by allowing subscribers to create durable subscriptions. Messages for durable subscriptions are stored on the server until the message expires or the storage limit is reached. Subscribers can receive messages from a durable subscription even if the subscriber was not available when the message was originally delivered.
Point-to-point messaging has one producer and one consumer per message. This style of messaging uses a queue to store messages until they are received. The message producer sends the message to the queue; the message consumer retrieves messages from the queue and sends acknowledgement that the message was received.
More than one producer can send messages to the same queue, and more than one consumer can retrieve messages from the same queue. The queue can be configured to be exclusive, if desired. If the queue is exclusive, then all queue messages can only be retrieved by the first consumer specified for the queue. Exclusive queues are useful when you wish for only one application to receive messages for a specific queue. If the queue is not exclusive, any number of receivers can retrieve messages from the queue. Non-exclusive queues are useful for balancing the load of incoming messages across multiple receivers. Regardless of whether the queue is exclusive or not, only one consumer can ever retrieve each message that is placed on the queue.
The next diagram shows point-to-point messaging using a non-exclusive queue. Each message consumer receives a message from the queue, acknowledges receipt of the message, and the message is taken off the queue so that no other consumer can receive it.
JMS messages use the XML Message
wire format that conforms to specifically constructed and fully compliant XML Schema (XSD) based on the existing definition of the TIBCO ActiveEnterprise schema.
The following delivery modes can be specified when using the JMS transport:
A JMS message is marked as persistent or non persistent.
TIBCO Adapter™ Concepts April 2005 Copyright © TIBCO Software Inc. All rights reserved www.tibco.com |