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

Legacy Systems

ERP

Financials

New Applications

TIB (The Information Bus)

HR

Sales

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 subjectbased 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

Subject-Based Addressing
Applications listen to subjects and receive all data sent under those subjects Subject-based addressing provides location transparency

Location Transparency
De-couple front-end from back-end Develop generic distributed applications
App1 uses Subject.Based.Addressing App2 uses Subject.Based.Addressing

Publish

Subscribe

Publish

Subscribe

TIB/Rendezvous
Subscribe Publish

Back-End use Subject.Based.Addressing

Self-Describing Data
Data model Data Model

Application A

Application B

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

TIB Reliable Data Protocol

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

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

Subject Addressing and Filtering

TCP

Reliable Unicast UDP

Reliable Multicast UDP IP

Reliable Broadcast UDP

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
Host 1 Host 2

Application A

Application B

Application C

RV API TCP Service

RV API TCP Service

RV API TCP Service

RVD Network

RVRD

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

Publish Messages Application

Rendezvous Standard API

TCP Subscribe Messages

Rendezvous Daemon

TRDP

UDP

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

Publish Messages Application Rendezvous Professional API Rendezvous Standard API TCP Subscribe Messages Rendezvous Daemon

TRDP
UDP

Certified Delivery Agreement

Publisher 4
5 Accept registration LOG LOG

Subscriber
2

3 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
Host 1 Host 2

Application A

Application B

Application C

RV API TCP Service

RV API TCP Service

RV API TCP Service

RVD Network

RVRD

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
Application A

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

RV API TCP Service

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

Application C

Logical Network

Service 5439

RV API
Service 7500

TCP/IP connectivity to the daemon

Service 8265

Service 9123

RVD UDP Services

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 interfaces 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 functions 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 lowlevel 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 Daemon

Each RV routing daemon maintains a subscription list to control message passing between the connected networks
RVRD Video Publisher

Video Publisher

Video Publisher RVRD Video Publisher

RVRD

Video Publisher

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
C A B D

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

F.Anet.moo.com

G.Bnet.moo.com

H.Bnet.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 Company Segment Division Business Function Source System Business Object Type Description A unique corporate code, MHP. A segment code, corresponding to education, financial services, etc.. A division code, such as Learning Organizational units in MHE such as sales, order management, finance, customer service, etc Source application where the message originated from The type (class name) of the business object, like ORDER, PAYMENT, SHIPPING, etc. Use a generic class name for messages that are not associated with a specific content class. An optional parameter indicating the operation being applied or being requested. For examples, NEW, DEL, UPD, etc. Recommend? Yes Yes Yes Yes Yes Yes

Action / Operation (optional)

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.CRE ATE.
Subject name may contain filters after base subject address.e.g:MHP.MHE.LEARNING.SALES.PRIMIS.ORDER.UPD.P UB.

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.