Download - 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.