TIBCO Rendezvous

In this section:

TIBCO Rendezvous is the messaging system that is the foundation of TIBCO ActiveEnterprise. TIBCO Rendezvous delivers true real-time publish/subscribe and request/reply messaging. It also supports qualities of service ranging from lightweight informational message handling to certified transactional delivery.

TIBCO Rendezvous uses a distributed architecture to eliminate bottlenecks and single points of failure. Applications can select from several qualities of service including reliable, certified, and transactional, as appropriate for each interaction.

Messaging can be publish/subscribe or request/reply, synchronous, or asynchronous, locally delivered, or sent using WAN or the Internet. TIBCO Rendezvous messages are self-describing and platform independent, with a user-extensible type system that provides support for data formats such as XML.


Top of page

x
Queuing Messages With TIBCO Rendezvous

TIBCO Rendezvous software uses subject-based addressing technology to direct messages to their destinations, so program processes can 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 locations of component processes become entirely transparent; any application component can run on any network host without modifying, recompiling, or reconfiguring. Application programs migrate easily among host computers. You can dynamically add, remove, and modify components of a distributed system without affecting other components.

Subject names consist of one or more elements separated by dot characters (periods). The elements can implement a subject name hierarchy that reflects the structure of information in an application system.

The following strings are examples of valid subject names:

For more information on subject-based addressing, see the documentation for TIBCO Rendezvous.

The server provides a TIBCO Rendezvous listener, supporting XML messages to and from the server system on TIBCO Rendezvous queues. Service Manager can accept messages arriving on a named queue and route these messages to either another queue or to a non-TIBCO Rendezvous destination.

Similarly, messages received through any of the other Service Manager listeners can be directed to a TIBCO Rendezvous queue. During the message flow, Service Manager can apply the standard document analysis, validation, transformation, and business logic capabilities to the document.

TIBCO Rendezvous support accepts and processes messages arriving at Service Manager on a TIBCO Rendezvous queue, regardless of the originator of the message. As messages arrive, they are accepted by Service Manager and processed.

Service Manager can also emit a message (in either XML or non-XML formats, for example, HIPAA, SWIFT, or HL7) to a TIBCO Rendezvous queue. You can do this regardless of the inbound protocol of the message.

The following topics describe how to configure the TIBCO Rendezvous network listener and emitter.



x
Registering TIBCO JAR Files

The TIBCO listener requires that you register the following jar file:

For the steps required to register the file, see Registering Library Files and Setting JVM Options.

Type

JAR File

TIBCO Listener

Tibrvj.jar is an archive file containing the Rendezvous classes JAR file located at [Tibrv home]/lib/tibrvj.jar.

Specify the Rendezvous shared library files, for example, C:\libraries (the directory in which the shared libraries are installed) in the Additions to the System Path section.

You can find it at [tibco rendezvous home]\bin.

The Additions to the System Path facility amends the path that is used at run time. Adding to the path enables a Java class to load a DLL (for example, tibrvj.dll) that is not already on the system path.

However, if the DLL loaded from Java requests another DLL, that search appears to be on the original path and fails, making it look as if the original load failed. The directory that contains the secondary DLL must also be on the path.

For instructions on registering JAR files, see Registering Library Files and Setting JVM Options.



x
TIBCO Listener Properties

The following table lists and describes the TIBCO listener properties. For instructions on creating a listener, see How to Create a Listener.

Property Name

Property Description

Event Queue Name

If this property is not specified, the listener listens on the TIBCO Rendezvous default queue.

Service Name

UDP service on which to listen for TIBCO Rendezvous messages. This property accepts a service name or a port number. The default TIBCO Rendezvous port during installation is 7500. If service, network, or daemon are not present, the listener attempts to connect to a local instance of running TIBCO Rendezvous service. Otherwise, specify the TIBCO Rendezvous instance in the form host:<port>.

Network

Network property instructing the Rendezvous daemon to use a particular network for all communications involving this transport. This property may be a host name, IP address, or network name. For more information about this property, see the TIBCO Rendezvous administration manual. If the daemon is running on the local host, this property may be omitted.

Daemon

RV Daemon information to find the TIBCO Rendezvous daemon and establish a connection.

Send Subject

Each Rendezvous message bears a subject name. The subject name is used by data consumers to receive all messages labeled with a given name. If the property is left blank, the TIBCO Rendezvous listener listens on subject *. For more information on the send subject property, see the Subject Names section in the TIBCO Rendezvous Concepts manual.

Reply Subject

Return subject of the message.

Field Name

Custom field name on which the listener filters.

Data Type

Select type of data for emission. Choices are: opaque, string, TibrvMsg, and TibrvXml.

Normalize To Decimal

Normalize data from scientific to decimal notation.

Add Data Type Info

Add attribute of datatype, the value of which is the field type name.

Accepts non-XML (flat) only

Select true if non-XML input is expected. If enabled, XML input still can be passed to the listener. Preparsers do not run.

Optimize Favoring

Use this option to customize listener performance. For smaller transactions, select performance. For large payloads that could monopolize the amount of memory used by Service Manager, select memory.

Multithreading

Indicates the number of worker threads. (Equivalent to the number of requests that Service Manager can handle in parallel.) Setting this to a value of greater than 1 enables the listener to handle a second request while an earlier request is being processed. The total throughput of a system is affected by the number of threads operating.

Default: 1 Max value: 99

Execution Time Limit

Maximum time a request can take to complete. A request that takes longer to complete terminates. Prevents runaway requests.

See also the description of the system property, Kill interval.

Whitespace Normalization

Specifies how the parser treats whitespace in Element content. Choose preserve to turn off all normalization as prescribed by the XML Specification.Choose condense to remove extra whitespace in pretty printed documents and for compatibility with earlier versions.

Polling Interval

Indicates the frequency (in seconds) that the listener returns control to Service Manager to determine if a stop listener was requested. The listener is constantly connected to the queue to retrieve incoming messages. 2.0 is the default value.

Default Java File Encoding

Default encoding if incoming message is not self-declaratory that is, XML.

Agent Precedence

Sets the order by which Service Manager selects the agent or agents to process the document. It does this by looking for a document entry in the configuration dictionary and when a match is found, the agent specified in that document entry is selected. If no matching document entry is found or no agent is specified, the engine looks in the input protocol configuration (listener). To have the processing agent taken directly from the listener (thus ignoring the document entry), use <listener> overrides <document>.

Possible values are <document> overrides <listener> and <listener> overrides <document>.

<document> overrides <listener> is the default value.

Always reply to listener default

If true, the default reply definition is used in addition to defined destinations.

Error Documents treated normally

If true, error documents are processed by configured preemitters.

Listener is Transaction Manager

If true, agents run in a local transaction. Agents can roll back uncompleted transactions.

Record in Activity Log(s)

If set, activity on this channel will be recorded in the activity logs, else the activity will not be recorded.



x
Configuring a TIBCO Rendezvous Emitter

Messages are sent to the destinations at the completion of a workflow. The state of the document determines which destination is used. The order in which the destinations are used cannot be predicted. Destinations cannot accept responses. These configurations also are used to send a message over a different protocol.

Note: Configuring a TIBCO Rendezvous emitter is not required if the emitter protocol used in the outlet of the channel is the same as the listener protocol used in the inlet of the channel. For more information on inlets and outlets, see Defining an Inlet and Defining an Outlet.

To route an output document or error message to a protocol other than that of the listener, you must configure an emitter. For example, an application may send input over TCP but want to route the output to an TIBCO Rendezvous queue.



x
TIBCO Rendezvous Emitter Properties

The following table lists and describes the TIBCO Rendezvous emitter properties. For instructions on creating an emitter, see How to Create an Emitter.

Property Name

Property Description

Destination (required)

Host:port on which the RVD daemon is listening.

Send Subject

Each Rendezvous messages has a subject name. The subject name is used by data consumers to receive all messages labeled with a given name. If the property is left blank, the iWay TIB/Rendezvous emitter defaults the send subject for the TIB/Rendezvous message to IWAYDEFAULTSUBJECT.

Reply Subject

Return address, to which recipients can send reply messages. If this property is omitted, no default value is supplied.

Field Name

Character string. Each field can have a maximum of one name. Several fields can have the same name. If the field name property is not specified, the TIBCO Rendezvous message with which the payload is associated is emitted with the default field name of IWAYDEFAULTOBJECT.

Service Name

UDP service to use whenever TIBCO Rendezvous conveys messages (service name or port number).

Network

Network for network transport objects to communicate with other transport objects.

Data Type

Type of data for emission. Select one of the following:

  • Opaque
  • String
  • TibrvMsg
  • TibrvXml


x
TIBCO Rendezvous Troubleshooting

The following table describes an error that you may encounter when using a TIBCO Rendezvous listener.

Error

Reason

Solution

Failed to open Tibrv 
in native 
implementation: 
TibrvException 
[error=901, 
message=Library not 
found: tibrvj]]: 
[line 3]

The system path was not updated to include the shared library directory.

Use the Path Settings pane to register %TibcoRV home\bin in the Path field. For this to take effect, the server must be stopped and restarted.

Another reason for this error is that although the libraries were included using this pane, the server was not stopped and started again to include the libraries in the configuration. Restarting the server is not sufficient.


iWay Software