Certified Messaging :

Certified Messaging (CM) guarantees that
1. Message will be sent.
2. The order of the message will be same as sent.

The parameters for the CM transport:
Daemon
Service
Network
CMname
Ledger

CM which will allow persistant mechanism for the messages channeled using rendezvous.
——————————————————————————————–
RVCM configuration

tibrvcm.conf :This file defines the TIBCO Rendezvous certified messaging (RVCM) listeners for use by topics that export messages to a tibrvcm transport. The server preregisters these listeners when the server starts up so that all messages (including the first message published) sent by way of the tibrvcm transport are guaranteed. If the server does not preregister the RVCM listeners before exporting messages, the listeners are created when the first message is published, but the first message is not guaranteed. The format of this file is
transport listenerName subjectName

—————————————————————————————–

Difference between Reliable delivery and Certified delivery?

Reliable Delivery:
Ledger: None
Time Limit: Contains outbound messages for 60 seconds
Network Traffic: Minimal
File Storage: No file storage

Certified Delivery:
Ledger: The certified delivery library records outbound messages in a ledger, either within the program process storage, or in file storage.

Time Limit: The certified delivery library retains outbound messages in the ledger until either delivery is complete or the time limit (set by the program) expires.

Network Traffic:Additional network overhead to confirm delivery of each certified message.
File Storage: Optional file-based ledgers consume file storage for each message until delivery is complete (or the time limit expires).

———————————————————————————————————–

Why EMS-RV communication?

f you are doing migration of the projects ( in general, trading apps, most of the trading apps are using RV and other examples are TIBCO IM ) you can bridge messages to EMS or to RV and vice versa, and can do your migration very easily.

another good example of this scenario might be if you are using RV along the company and want to integrate an application that can communicate via JMS out of the box. Building a RV-JMS bridge might be much easier than developing the code to do that.

Message interaction between programs :

Three distinct kinds of interactions occur between programs  in Rendezvous environment.

Publish/Subscribe interactions.
Request/Reply interactions.
Multicast Request/Reply interactions.

Publish/Subscribe interactions:

These are driven by events. Communication is in one directions. The interaction consists of one multicast message, published once and received by all subscribers.

Example: Publishing the latest stock prices to hundreds of traders on a trading floor simultaneously.

Request/Reply Interactions

These interactions are driven by demand for data. The client requests data from a server, the server computes the individual response and returns it to the client. Communication flows in both directions. This consists of two point to point messages  : a request and a reply.
Example: transaction processing in ATM banking

Multicast Request/Reply Interactions

These interactions are also drive by demand for data. In Multicast request/reply, multiple servers can receive the request and respond. Communication is in both directions. Complete interaction consists of one multicast request message and any number of point-to-point messages
Example: Database query with multiple servers.

Remote RV communication :

Rendezvous uses ‘UDP’ protocol to communicate within the network locally. For communicating beyond the subnet or the network, it uses Remote RV’s (RVRD). RVRD uses ‘HTTP’ protocol for communicating outside the network. Each subnet can be divided into different IP addresses using different port no’s. This in turn leads to multicasting.

One of the machines in each subnet  on which RVRD is configured communicates with the other configured RVRD machine in the other subnet. In other words, these RVRD configured machines act as gateways in their respective subnets as each message is sent through these machines for any machine in the subnet to communicate with a machine in the different subnet.

-service “7500″ -network “113.193.125.221″ -daemon “tcp:7500″ “BW.Start” “hello world”



For training on TIBCO mail us at [email protected]