Saturday, October 2, 2010

TIBCO Tutorial: TIBCO RV messagingWhen I started working with a big investment bank I come across a new messaging technology called TIBCO Rendezvous or commonly called as TIBCO RV, I have heard Java Messaging Service (JMS) before but never heard about this TIBCO Rendezvous and it was so extensively used in my application that most of support issue was caused by this mysterious TIBCO RV. We had several TIBCO Topics also called TIBCO Subject separate for both Production and Non PRODUCTION environment but still since I don’t had basic knowledge of this technology I was afraid to do some experiment because there was always a risk to affect production environment. At that time I have searched for TIBCO tutorial and I didn't find anything which can help an application developer who wants to use TIBCO as middleware solution, so I decided to write my own experience in a form of short , concise and clear TIBCO tutorial Every post of this series will have something to offer in a short and clear format which I like and I hope you too for details you can always refer to TIBCO Rendezvous or TIBCO EMS specification or documentation .

Today I am going to share some of my experience while working with TIBCO RV , this is standard product used in most of the global banks for messaging, its great product which offers following benefits:

·location transparency

·platform independence

·reliable and fast

·comprehensive API

·Point to point delivery and publish/subscribe delivery.

Location transparencyLocation transparency means for sending and receiving message on a multicast network you need not to aware of physical location of sender or receiver as long as you know the topic (also called subject in TIBCO world), so its pretty simple Sender publish message on multicast topic in a network and all subscriber which have subscribed on that topic receives message without being knowing physical location of publisher.

Sender could be anywhere in the world e.g. New York, Tokyo, London, receiver can be anywhere e.g. London, Hong Kong or Tokyo.

Platform independenceTIBCO Rendezvous or TIBCO RV doesn't depend on platform, Sender can be running on UNIX box while receiver could be running on windows machine. Most of the time GUI runs on windows and server runs on Linux and they exchange messages via TIBCO.

Reliable and FastTIBCO Rendezvous or TIBCO RV makes best effort but not guaranteed to deliver message to receiver and it’s very fast since it’s operate on User Datagram Protocol (UDP) also. TIBCO RV is best suited for transmitting data which is going to be stale in few minutes and has very high volume e.g. Market data etc but not used for sending Order or execution message because there is always chance of loosing those messages which could create financial impact.TIBCO Rendezvous provides another solution for guaranteed message delivery known as TIBCO Certified messaging so normally application uses certified messaging to make guaranteed delivery sensitive data e.g. Order, Trade or Booking messages.

Comprehensive APITIBCO Rendezvous or TIBCO RV comes along with rich API in both C++ and Java languages and can be plugged into application easily, TIBCO RV API provides interfaces and classes for different modes of communication e.g. Point to Point, publish/subscribe, certified messaging etc.

Point to Point DeliveryTIBCO Rendezvous or TIBCO RV can be used for point-2-point delivery (some times also called Request/Reply mode), it used "INBOX" topic for doing so , when rvd (rendezvous daemon) sees INBOX topic instead of publishing that message into multicast network it makes direct connection to destination host and send that message over TCP/IP.

Publish/SubscribeTIBCO Rendezvous or TIBCO RV provides essential messaging functionality e.g. both Point to Point also called P2P and publish/subscribe. In PUBLISH/SUBSCRIBE mode there could be one sender and multiple receiver which subscribe on a TIBCO Topic also called as Subject. TIBCO RV receiver subscribes on multicast network on a particular topic and Sender sends message on that Topic, after that its TIBCO RVD responsibility to deliver those message. Communication between application process and TIBCO RVD is happens on TCP while communication between TIBCO RVD and multicast network happens on UDP protocol and that’s why TIBCO Rendezvous messaging or TIBCO RV is very fast.

Hope this would be useful, I will write some more post to explain things little more till then happy learning :)

Some of the tibco best practices, which I follow and have seen recommended :

1) Make sure your application only connects to one daemon, which should be your local daemon (running on localhost). Since connection between application and rendezvous daemon (RVD) is TCP, using a remote daemon to send messages to remote host is effectively TCP i.e. slower. Instead let RVD multicast your message using UDP protocol.

2) Keep track of your services and subject names. One of the most common issue is messing up with tibco services (UDP ports) and subject names. You can avoid that by assigning one service number to one process, and different service number in different environment, so that a test message doesn't go to production server. Since in most places test and production enviroment falls under same network, a config mistake may cause production issue. Generally, network engineer disable test to production message routing at network level, but you can't take as guaranteed.

3) Use proper subject names, which clearly specify who is publisher and what kind of message is e.g. OMS.Order.EQ or OMS.Order.FX