12. tibco - rendezvous

What is the TIB

• The Information Bus• A body of software that facilitates

the intelligent movement, organization and integration of data in a distributed environment

The Information Bus

TIB (The Information Bus)

Legacy System

s

Sales

HR

New Application

s

Financials

ERP

TIB Rendezvous

• The back bone of the TIBCO Communication.

TIB Rendezvous

• Easy Distributed Application.• Support different h/w and s/w

platforms.• Seamless connection among

different platforms and computers.

TIB/RV software suite

• TIB/RV Programming language.– The standard RV APIs.

(Uses C,C++,JAVA,Perl ,COM etc)

• RV Daemon (RVD)– runs on each m/c as information

enters & exits host computers.

TIB/RV Advantages…...

• No need of program to locate client or n/w address.

• Distributed application system.• Resilient System.

– Producer– Consumer

• Thread safe.

TIB/RV Adv. (Contd……)

• Easily protable.• Support Request/reply method.• Support multicast messaging.

Why Distributed system?

• De coupling & Data independence.– Low cost,easy maintenance,good

operation,high longevity.

• Location transparency.– Subject based addressing

• Information source & destination.– News-wire,sensors,point2point

connection.

Why Distributed system? (Contd…)

• Reliable delivery of whole message.– Uses RV Daemon.

• Certified message delivery.• Distributed Queue.• Fault Tolerant.

Subject-Based Addressing

• Applications publish data on the TIB under a semantically meaningful subject name

• Applications subscribe to subject names and receive all data published under those subject names

• Subject based addressing provides location transparency

SUBJECT NAMES

• Contains one or more elements separated by dot.

• It reflects the structure of information in an application system.

• Max length 255 char.(With delimiter)

• Max length for element 252.

• Maximum token 127.

Subject Name ( Contd……)

• Names begin with ’ _ ‘ is reserved e.g _INBOX,_LOCAL etc.

• Delimiter ‘.’• > Matches all the elements

remaining to right.• * Matches for any one element( Not

for partial sub strings of characters within an element )

Subject-Based Addressing

• TIB messages pass between communication endpoints

• Endpoints are determined by subject-based addresses

• Message handler routines are bound to communication endpoints– Messages are then processed on

arrival by the message handler routines

Subject-Based Addressing

• Applications address data, not hardware locations– Programs are not topology/address

dependent– Users and programmers do not have to

know networking details

• Applications send data on the TIB under a semantically meaningful subject

• Applications listen to subjects and receive all data sent under those subjects

• Subject-based addressing provides location transparency

Subject-Based Addressing

Location Transparency• De-couple front-end from back-end• Develop generic distributed applications

TIB/Rendezvous

App1 uses Subject.Based.Addressing App2 uses Subject.Based.Addressing

Publish Publish

Publish

SubscribeSubscribe

Subscribe

Back-End use Subject.Based.Addressing

Self-Describing Data

Data model

Application B

Application A

Data Model

What is your class

What are your attributes

What are their types

What are their values

TIB Reliable Data Protocol

• TRDP– TIB Reliable Data Protocol– A reliability protocol built on top of UDP

• TRDP provides– Subject Based Addressing– Sequenced delivery of messages from sender– Retransmission of missed messages within a

retransmission time window

• Multi-point TRDP Delivery– Sent via broadcast or multicast

transmission• Reliable TRDP Delivery is an

optimistic protocol based on NACKs

• The TIB/Rendezvous Daemon implements TRDP– Not the application

TIB Reliable Data Protocol

TIB Reliable Data Protocol

• Re-transmission– Requests are not sent immediately

due to heuristic back off– Requests received during the

heuristic back off period for the same message are ignored

– Delivered via original delivery method– Buffers are held for 60 seconds

TIB Technology

TCP

UDPUDP UDP

Subject Addressing and Filtering

Reliable Unicast Reliable Multicast Reliable Broadcast

IP

Link Layer Protocol

TIB/Rendezvous Daemon

• TIB/Rendezvous Daemon– RVD– RVRD

• Delivers messages reliably• Filters subject-addressed messages• Dispatches messages to application

processes

TIB/Rendezvous Daemons

Application A

TCP Service

RV API

Application B

TCP Service

RV API

Application C

TCP Service

RV API

RVD RVRD

Network

Host 1 Host 2

Delivery Service

• Reliable Delivery– Can survive brief

network glitches– No confirmation– No registration– No ledger

• Certified delivery– Can survive beyond

session and process restart

– Confirmation of every receipt

– Registration of cooperating applications

– Ledger

Reliable Publish/Subscribe

• Lightest-weight protocol for non-critical message delivery

• Reliable ordered delivery• Broadcast to hundreds and

thousands of applications (one to many)

• Loss detection with transparent re-transmission

Reliable Delivery Architecture

Application

Rendezvous Standard API

TCP

Rendezvous Daemon

TRDP

UDP

Publis

h M

ess

ages

Subscrib

e M

essa

ges

Certified Publish/Subscribe

• Critical ordered message delivery• Guaranteed delivery beyond

session and process restart• Dynamic discovery broadcast

protocols• Point-to-point message protocols• Automatic recovery protocols

Certified Delivery Architecture

Application

Rendezvous Standard API

TCP

Rendezvous Daemon

TRDP

UDP

Publis

h M

ess

ages

Subscrib

e M

essa

ges

Rendezvous Professional API

Certified Delivery Agreement

LOG

14

3

5LOG

2

Accept registration

Publisher Subscriber

Request registration

Certified Messaging

• RVCM is a quality of service that is layered on top of TIB/RV standard APIs– Provides for critical ordered message

delivery with acknowledgement– Appropriate when each message on a

specific subject builds upon information in the previous subject

– In situations of intermittent physical connectivity

Certified Messaging

• The TIB/RV daemons do not differentiate between RVCM messages and other RV messages– No additional logging/caching takes place in

the rendezvous communication daemons

• Additional system administration may be required to manage, control subject names and disk files used by the RVCM application

Features of Certified Message Delivery

• Message Logging– Memory based or– File-based ledger

• Message delivery acknowledgements per delivery tracking sessions

• Time limit configuration for message delivery specified by the sender

Features of Certified Message Delivery

• Advisory messages are sent directly to the enabled delivery tracking sessions– It does not broadcast these advisories on

the network

• Messages between a delivery tracking session and a non-RVCM (reliable) session occur without acknowledgements

TIB/Rendezvous Daemons

Application A

TCP Service

RV API

Application B

TCP Service

RV API

Application C

TCP Service

RV API

RVD RVRD

Network

Host 1 Host 2

Transports

• A communication connection to the TIB/RV daemon is called a Transport

• A transport contains network context for the application

• An application may create more than one transport and use them as required

• Creating a Transport makes a connection between the API and daemon

Transports

• If the daemon is not running, it is automatically restarted

• Many API functions require a transport handle

• Transport requires three parameters– Service– Network– Daemon

Transports

• tibrvTransport_Create() creates the TCP connectivity from the TIB/rv library to the TIB/rv Daemon

• The TIB/rv Daemon then communicates on behalf of the application to and from the network

Application A

TCP Service

RV API

RVD

UDP

Transports

• A transport can communicate only with other transports in the same service group– Communication occurs between

identical UDP ports

• To communicate with more than one service group, applications must initialize more than one transport

Service, Network and Daemon

Service 1732

Service 5439

Service 7500

Service 8265

Service 9123

Application C

RV API

RVD

UDP Services

TCP/IP connectivityto the daemon

Logic

al N

etw

ork

Service

• TIB/RV Daemon divides the network into logical partitions called service groups

• Each transport belongs to a single service group

• A transport can communicate only with other transports in the same service group

Sample Service Parameters

• Specify the service by specifying service parameter– Service Name

• Example: “rendezvous”

• UDP port number– Example: “7500”

Specifying Service

• When an application specifies a service– The transport creation function calls

getservbyname(), which searches a network database such as NIS, DNS, or a flat file such as /etc/services for the decimal integer to ehich the service name has been defined

• If a port number is specified, it must be a string representing a decimal integer– Example: “7890”

Specifying Service

• If you specify NULL,– The transport creation function calls

getservbyname()– If getservbyname() does not find

rendezvous, the transport creation function uses UDP port 7500

– Its recommended to define Rendezvous as a service especially if UDP port 7500 is already in use

Specifying Service

• For example, network administrators might add the following service entry to the network database – Rendezvous 8000/udp

• Now programmers can conveniently specify NULL as transport argument to initialize a transport using the default service

Network Parameter

• Every application transport communicates with other transports over a single network

• On computers with more than one network interface, the network parameter instructs the TIB/Rendezvous Daemon to use a particular network for all communications involving this transport

Network Parameter

• To communicate over more than one network, applications must initialize more than one transport– Network can be specified in several ways– NULL specifies the default network interface

• If the application is connecting to a remote daemon, the network parameter must refer to the network from the perspective of the remote computer that hosts the daemon process

Sample Network Parameters

• Specifying the network– Host Name

• Name of the machine

– Host IP Address• “ 3.209.129.43”

– Network Name or IP Number• loopback, “10.2.3.0”

– Interface Name (where supported)• lan0, lle1, hme1

Specifying the Network-Network Name

• When an application specifies a network name,– The transport function calls

getnetbyname(), which searches a network database such as Network Information Services (NIS) or a flat file such as /etc/networks

Specifying the Network-Interface Name

• When an application specifies an interface name,– the transport creation function searches the

interface’s table for the specified interface name

• “lan0”

– The specified interface name must be one that is known to:

• Ifconfig• Netstat

Specifying the network

• When an application specifies NULL for the network parameter,– The transport creation function calls

the “C function” gethostbyname()(which allows transport creation function to use the interface which corresponds to the host name of the system)

Specifying Multicast Addressing

• Multicast addressing– Broadcast capability implemented at

hardware level• Therefore, multicast filtering is more

efficient than the service group filtering at the software level

– Rendezvous software supports multicast addressing only when the “network” supports multicast

Sample Multicast Parameters

• Network Specification– “lan0;224.1.1.1”

• List of one or more multicast groups– “lan0;224.1.1.1, 224.1.1.5, 224.1.16”

• Single send/broadcast address– “lan0; ; 224.1.1.6”

Daemon Parameter

• Daemon parameter specifies how and where to find the TIB/Rendezvous Daemon to establish a communication transport

• Daemon can be specified on a remote computer

• NULL specifies the default-find to the local daemon on TCP socket 7500

Local Daemon

• For local daemons, the transport creation function’s daemon parameter is specified and the –listen option to the daemon process as a (TCP) communication type and a socket number, separated by a colon– Example: “tcp:7500”

Local Daemon

• When an application specifies NULL, tibrvTransport_Create() will use “tcp:7500” as the default daemon

• To use the default client socket, supply NULL as the daemon argument to the transport creation function and omit the –listen option to the daemon process

Remote Daemon

• In most cases, applications use a local daemon, running on the same host as the application

• Certain situations require a remote daemon– The applications runs on a notebook

computer that is not directly connected to the network

– The application connects to a network at a remote site

Specifying a Remote Daemon

• When an application specifies a remote daemon connection, tibrvTransport_Create() requires a three part daemon parameter– This introduces the remote host name

as the middle part of the three part parameter• Communication type: Remote host

Name: Socket number• Example: “tcp:notlocal.hostname.com:6555”

Establishing Connections with TIB/RV Daemon

Step 1• The daemon process opens a client

socket and waits for a client to request a connection– The –listen option of the

TIB/Rendezvous Daemon (RVD) specifies where RVD should listen for new client application transports

Establishing Connections with TIB/RV Daemon

Step 2• The application calls the transport

creation function, which contacts the daemon at the client socket specified in its daemon parameter

• The daemon parameter of the transport creation function must correspond to the –listen option of daemon process– They must specify the same communication

type and socket number

Establishing Connections with TIB/RV Daemon

• If no daemon process is listening on the specified client socket, then the transport creation call automatically starts a new daemon process– New daemon process listens on the

specified client socket, then attempts to connect to it

Establishing Connections with TIB/RV Daemon

Step 3• The daemon process opens a

conduit for private communication with the new application support

• All future communication uses that conduit– Request socket is now free for

additional requests from other client transports

Summary

• TIB/Rendezvous communications take place within a the context of a transport

• Asynchronous transports can recover subscriptions automatically if the TIB/Rendezvous Daemon is restarted

• A transport is asynchronous and event driven

Summary

• A transport explicitly binds together a service group and a network for use by the messaging software

• A program may use more than one transport, but it is not recommended that more than one thread share a a transport

• Programmers use transport handles to reference transports

TIB/Rendezvous Daemon

Rendezvous Daemon (RVD)

• Delivers message reliably• Filters subject-addressed messages• Dispatches messages to application

processes• Shields applications from operating

system idiosyncrasies, such as low-level sockets and file descriptor limits

Rendezvous Daemon (RVD)

• Daemon process starts automatically when needed

• Daemon process automatically exits after a 15-minute period of inactivity unless it is started with the –permanent option

Rendezvous Daemon (RVD)

• Reasons to manually start a daemon– To specify optional parameters– To start a daemon that will accept

connections from applications running on remote computers

• The command RVD starts the Rendezvous Daemon Process

Rendezvous Daemon (RVD)

• If the daemon parameter of the session initialization call specifies a remote daemon, then– the daemon does not start automatically– the daemon on the remote computer must

be started manually– Since a transport cannot automatically start

a remote daemon, auto start feature of a local daemon can be suppressed by making it appear remote

RVD Commands

• Rvd– [listen [<ip_address:]<tcp_port>]– [-permanent]– [-foreground]– [-logfile [<filenam>]]– [-reliability <time>]– [-http [<ip_address>:]<http_port>]

or [-no-http]

-listen <port>

• Specifies where the Rendezvous Daemon should listen for clients

• Corresponds to the daemon parameter of the session initialization call

• If listen option is not specified RVD uses “tcp:7500” as default

-permanent

• If this parameter is present, RVD runs indefinitely until terminated

• If this parameter is NOT present, RVD exits after 15 minutes during which no Rendezvous application connect to it

-foreground

• Available only on UNIX platforms• If this parameter is present, RVD

runs as a foreground process• If it is not present, RVD runs as a

background process

-logfile <filename>

• Send output log to this file• When absent, default is stderr

-reliability <time>

• Specifies the time for which daemon retains outbound messages

• Retaining message data allows the daemon to re-transmit message packets upon request from another daemon process (which did not correctly receive the data)

TIB/Rendezvous Routing Daemon Concepts

Rendezvous Routing Daemon

• A runtime software component from TIB/Rendezvous– RVRD – Rendezvous routing daemon

• Routes TIB/Rendezvous Messages using Subject-Based Addressing– Maintains location transparency across the

LAN/WAN– Extends publish/subscribe across the

LAN/WAN• Delivering broadcast messages between networks

requires additional software components

RVRD Tasks

• Monitors subject interest expressed by each TIB/Rendezvous transport on the local network

• Requests subjects from other networks by passing subject interest information to neighboring routing daemon processes

RVRD Tasks

• Receives subject interest information from neighbors and tracks delivery addresses

• Delivers messages as appropriate– To routing daemons on other network– To attached client applications

• Acting as an RVD process

– Re-sends them on the local network

Transparent Forwarding

• TIB/Rendezvous applications on one network can listen for subject names and receive messages from other network transparently

RVRD vs. RVD

• RVRD subsumes RVD functionality– There is no need to run an RVD on a

machine that is running an RVRD daemon

– The RVRD on that host will act as an RVD process for connected applications

– Computers running one of the routing daemons do not need a separate RVD

Routing Daemon Concepts

• One routing daemon must exist on each network segment

• Routing daemons must be permitted to export and import relevant subject names

• The importing networks must express interest in the relevant subject names

Routing Daemon Concepts

• Network administrators must enable daemons to exchange point-to-point messages by– Declaring them as neighbors or

proxies for other neighbors– Configuring routers, firewalls and/or

NATs

Rendezvous Routing DaemonEach RV routing daemon maintains a subscription list to control message passing between the connected

networks

RVRD

RVRD

RVRD

Video Publishe

r

Video Publishe

r

Video Publishe

r

Video Publishe

r

Video Publishe

r

Subject Interest

• Allows cooperating neighbors to handle dynamic importing and exporting of TIB/Rendezvous messages

• When a routing daemon detects interest in a subject, it sends a subject interest request to its neighbors– The request includes the subject name and

a delivery address indicating where to send messages with matching subject names

Subject Interest

• Each routing daemon process maintains an interest list of subjects and delivery addresses as requested by neighbors

• When the message with a matching subject name arrives, the routing daemon distributes it to the appropriate destinations– Local network (locally) and/or– Neighbor routing daemons

Adjacency

• Two networks are called adjacent when they are connected by a direct physical network link without intervening networks– B and C are adjacent– C and D have intervening B network

A

C

DB

Service Groups

• Group of transports that use the same UDP service to communicate– Rendezvous software communicates with

other members of a service group on the same network so they can share messages with each other

• Programs use rvrd to cooperate across a WAN with programs that belong to a particular service group– The local programs must join the same

service group

Service Groups

• Routing daemons link compatible service groups on adjacent networks so they behave like a single large network

Fault Tolerance Among Routing Daemons

• Fault tolerance protects the routing daemons against hardware failures, process failures, and LAN segmentation

• While neighbor rvrd links appear to create redundant paths, the cooperating daemons forward messages only once

• In failure situations, rvrds automatically readjust to continue service smoothly

Neighbors

• A pair of routing daemon processes on adjacent networks are neighbors only if they are declared as neighbors– There must be a point-to-point network

route between neighbors

• To declare a neighboring routing daemon, use the neighbor functionality in the Browser Administration Interface

Neighbors

• Non-neighbor routing daemons on adjacent networks do not exchange subject interests directly with each other

• Other information may still flow over the physical link between the two networks– Examples: telnet, ftp, http etc.

Restricting Messages

• Network administrators can use routing daemons in several important ways– Restrict sensitive information to

particular networks– Limit the volume of messages between

networks– Constrain information to flow only in

one direction between two networks

Restricting Messages

• Restrict Messages by Service Port– Limit communication between networks

to particular service groups

• Restrict messages by Subject Name– Subject names specify exactly which

messages may enter and leave– The routing daemon blocks all other

subject names

Fault Tolerance Example: Redundant Routing Daemons

Anet.moo.com

E.Anet.moo.com

G.Bnet.moo.com H.Bnet.moo.com

F.Anet.moo.com

Bnet.moo.com

Routing Daemon Log

• RVRD can output a running log of activity– System/Network administrators can

use the generated log files to monitor neighbor connections, subject interest, and message flow

• The browser administration interface provides different options for determining what gets logged

Passive Neighbor Connection

• rvrd can passively accept connections from its neighbor

• To specify a passive neighbor, following information is required– Neighbor name– Local connect port

• This is useful in the cases of unidirectional firewalls and modems

Accept Any as Neighbor

• Instead of declaring a specific set of neighbors, a routing daemon can declare that it accepts neighbor connections from any routing daemon

• This configuration is especially useful for hub topologies, dial-in connections, and any situation in which a routing daemon might operate with a large number of potential neighbors

Firewalls

• Firewalls restrict the flow of information across organizational boundaries– Rvrd can be configured to allow messages

to pass as TCP point-to-point packets across the firewall

– In addition, RVRD can be configured to • Use proxy deliveries• Use reply name substitution• Accept only local application connections• Use passive connection

Erroneous Neighbors on the same Network

• It is an error to configure two neighbors to serve the same logical local network

• It is an error to use routing daemons to duplicate the effort of another forwarding mechanisms

MHE-TIB/RV subject name

Token Description Recommend?Company A unique corporate code, MHP. YesSegment A segment code, corresponding to education, financial

services, etc..Yes

Division A division code, such as Learning YesBusiness Function Organizational units in MHE such as sales, order

management, finance, customer service, etc…Yes

Source System Source application where the message originated from YesBusiness Object Type The type (class name) of the business object, like

“ORDER”, “PAYMENT”, “SHIPPING”, etc.Use a generic class name for messages that are notassociated with a specific content class.

Yes

Action / Operation(optional)

An optional parameter indicating the operation beingapplied or being requested. For examples, “NEW”,“DEL”, “UPD”, etc.

Yes

MHE-TIB/RV subject name(Contd..)

Suggested order for the subject name:-

Company.Segment.Division.BusinessFunction.System.ObjectType.Operation.

Eg:-

MHP.MHE.SCHOOL.CSOP.ORACLE.CUSTOMER.CREATE.

Subject name may contain filters after base subject address.e.g:-

MHP.MHE.LEARNING.SALES.PRIMIS.ORDER.UPD.PUB.

MHE-TIB/RV subject name(Contd..)

• Reasonable subject name upto 20 tokens.

• Recommended between 3 to 8.• Environment execluded from subject

name afetr careful thought.• Service prots and different n/w

segments will be used to isolate TIB MSgs from other environments.