Tibco不可多得的内部培训资料

TIBCO‘s information bus (TIB)一、introduction===============================Examples of Valid Subject Names:===============================1. NEWS.NATIONAL.ARTS.MOVIES.REVIEWS2. CHAT.DEVELOPMENT.BIG_PROJECT.DESIGN3. News.Sports.Baseball4. finance5. Long.subject_name.is.valid.even.though.quite.uninformative===============================Examples of INVALID Subject Names:===============================News..Natural_Disasters.Flood- Invalid null element in subject stringWRONG.- Invalid null element at the end of the subject string.TRIPLE.WRONG..Invalid subject string with three null elements===============================Reserved Names===============================_INBOX.- Inboxes are subject names used for point-to-point message delivery- All system generated inbox names begin with this prefix_LOCAL.- Subject names with this prefix are ―local‖to the TIBCO Rendezvous daemon- These messages do not reach the network_RV.- Subject names with this prefix are TIBCO Rendezvous advisory messages_RVCM.- Subject names with this prefix indicate internal administrative messages associated with certified message delivery- Application programs must not send to subjects with this prefix_RVFT.- Subject names with this prefix indicate internal administrative messages associated with TIBCO Rendezvous fault tolerance software- Application programs must not send to subjects with this prefixPublish/subscribe messages are like radio broadcasts; the sender picks a frequency, and any listener who tunes to that frequency receives the broadcast. The broadcast subject name is analogous to a radio frequency. Any application that listens for a subject receives all messages bearing that subject name.The Rendezvous Daemon (rvd) is a runtime background process that implements TIBCO Reliable Datagram Protocol (TRDP). The daemon sends, listens for, filters and routes subject-based messages reliably, detects lost messages and requests re-transmission. Daemons can be started automatically or manually.The Rendezvous API supplies the message structure and communication type and passes messages to the daemon via a TCP connection. Usually a Rendezvous daemon is run on the same machine as the Rendezvous application but remote daemon connections are possible.In the above slide the various layers of the stackpass up traffic, but only if a higher layer hasregistered interest in some manner.The Network Interface Card (NIC) will onlyprocess network traffic which meets one of threecriteria:- Own hardware address- Broadcast- Address contained on Multicast tableThe NIC Driver will process and forward trafficwhich is registered at the TCP/IP layerThe TCP/IP layer will only forward traffic which is routed to an open TCP/UDP port, e.g. 7500/UDP default for the TIBCO Rendezvous daemonThe TIBCO Rendezvous daemon will only forward traffic on which a connected consumer application has registered subject interest, and only after the complete message has been receivedTRDP is implemented by the TIBCO Rendezvouseach outbound message packet. TRDP uses abuffer to store outbound messages for a specifiedinterval. If a message packet is lost the consumingrvd requests retransmission. Buffer operations areprivate to the TRDP implementation; there is noAPI to access it.TRDP is optimistic: it assumes messages will arriveat their destination. Only if a message is lost willTRDP send a negative acknowledgement (NAK)requesting retransmission. Compare this with TCP which is pessimistic: explicit acknowledgment of each received message is required.The default buffer interval is 60 seconds and should not be increased. If stronger delivery assurance is required, Rendezvous certified (RVCM) messaging should be usedTIBCO Rendezvous Certified MessagingWhile standard Rendezvous communication is highly reliable, business requirements often dictate the need for even stronger assurance of message delivery. RVCM fulfills this need, guaranteeing the deliveryof each message at its intended destination.Standard Rendezvous reliablesubscribers can receive certifiedmessages published on a subject thatthey have subscribed to. However, theywill not participate in recovery attemptsat the API level (as you will find detailedlater in this unit).Automatic Discovery1. CM listener receives a CM message, it detects thisbecause such a message has two additional labels:- The name of the CM sender- The sequence number for the message within theCM interaction; this sequence number will be set to 0(by the CM API at the subscriber) until a full certifieddelivery agreement has been established (seebelow)2. The CM listener records the CM sender name andsubject name in its ledger file.3. The CM listener sends a request for registration tothe CM sender.4. The CM sender receives the request forregistration and will decide whether it accepts theregistration (it can be instructed to reject allregistration requests from this subscriber).- If it rejects the request, it will inform the listener and no Certified Delivery agreement will have been established.- If it accepts the request, it will record the listener in its ledger file and any subsequent message(s) will be recorded in the ledger file and require acknowledgement from the subscriber.5. The certified sender explicitly informs the certified listener of the acceptance, which completes the Certified Delivery agreement.We refer to the two CM transports that participate in a certified delivery agreement as a certified sender and a certified listener, and the labeled messages that flow between them are certified messages. Notice the subtle difference in terminology—before establishing a certified delivery agreement, the participating transports are CM senders and CM listeners; afterward, they are certified senders and certified listeners. Similarly, a labeled message becomes a certified message only when the sender and receiver maintain a certified delivery agreement.Certified Message StructureAn RVCM message contains three additional fields thatare added to the message. These are:1. The correspondent name of the CM transport that sentthe message.2. A sequence number assigned by the sending CMtransport.3. A time limit, after which the sending program no longerexpects its CM transport to certify delivery of themessage.Depending on your design, the CM transport name can be persistent (name generated and reused by you) or non-persistent (automatically generated by the CM API)Routing Daemon OperationsRendezvous routingdaemons (rvrd) forwardmessages betweennetworks. Each rvrdcontains one or more"software routers." Each"software router" connectsone or more local networkswith one or more othersoftware routers. Each rvrdbuilds a representation ofthe whole network and canselect an optimal route.Each software "router" willonly allow specifiedsubjects to be imported andexported to reduce networkload and to increasesecurity. Each rvrd registers interest (subject names that subscribers have registered with Rendezvous daemons) on the local network and passes that information to neighbors. Thus, messages will only be sent to networks where there is at least one active subscriber.Whereas rvd delivers messages to applications on computers within a single network, an rvrd delivers messages beyond network boundaries. Rendezvous routing daemons efficiently connect applications on separate IP networks so that messages flow among them as if on a single network. Rendezvous routing daemons forward messages between networks, allowing applications on one network to listen for and receive messages from applications other networks. Rendezvous routing daemon administrators control with subject names the messages that can traverse their networks. An rvrd subsumes rvd functionality,so it is not necessary to run both on the same host.Load BalancingIn the above example, the administrator hasspecified that G imports foo.> with weight 1(retaining the default weight), and bar.> withweight 10. Conversely, H imports foo.> withweight 10, and bar.> with weight 1. When all thecomponents operate properly, messages withsubjects foo.> travel through F and H, whilemessages with subjects bar.> travel through Eand G. If E were to fail, all messages would travelthrough F and H (because that route has thelowest path cost).TIBCO Rendezvous Fault ToleranceTIBCO Rendezvous Fault Tolerance(RVFT) coordinates a set of concurrentprocesses within a group of FTmembers. A FT group is a set ofapplication processes that cooperatefor fault tolerant services. An RVFTgroup can have any number ofmembers. New members can join andexisting members can leave FT groupsat any time. Processes can bemembers of more than one FT group.More than one FT group can exist onthe same network. FT group names,therefore, must be unique.In this example, four applications inthe FT group Acme.FT.Group cooperate to broadcast Rendezvous messages. The Active Goal is 1, meaning only one application will actively publish data. Application A, with a weight of 20 (highest in the group), is the Active member (the actual publisher). The other members process the same information stream but do not publish. They also listen for heartbeats from the Active member. The "ranking inactive" member is next in line to take over publishing should the Active member fail or exit.===============================Heartbeats===============================Each Active member publishes a heartbeat to all other members it its FT group. A heartbeat produces aregular, periodic stream of Rendezvous messages indicating that the Active member is "alive", i.e., actively processing the re quired task(s). All inactive members in the FT group subscribe to the Active member‘s heartbeat message.If inactive processes fail to hear the Active member‘s heartbeat within a specified interval, the Ranking Inactive member will take over processing.Any number of Rendezvous applications that are not members of the FT group can be used to passively monitor the heartbeats of active members in an FT group. Such passive monitors have no influence on the FT group or its members, and members do not know that they are being monitored by applications outside the group.It is important to clarify what we mean by "active" and "inactive". All the API does is to call a user function or method with a parameter indicating what the new state of the application should be. It is up to the application to specify what the appropriate behavior is to become "active" or "inactive".===============================Several parameters are used to dictate andmanage RVFT group and member behavior, including:===============================- FT Group Name is the attribute that binds members of a group together. Applications can join as many groups as they like using different group names. If an application joins the same group twice, results are undefined.-Active goal is the number of active members specified by the design of the FT group. Any number of members may be active in an FT group. RVFT will automatically activate and deactivate members to ensure that the active goal is met. If it cannot be met, advisory messages will be published. Each member MUST specify exactly the same active goal as the other members. Differences may result in erratic behavior with members alternating rapidly between becoming activate and inactivate.-Member weight specifies the ability of the application to complete assigned tasks, relative to other members in the FT group. When a process joins a FT group it specifies its weight. Member weight is used to determine member rank, which in turn is used to determine Active member status1. Member rank is a unique number assigned to each FT group member. To determine rank (and,therefore, active and inactive status), RVFT sorts members according to their weight. The member with the highest weight receives the rank of 1, indicating that it outranks all other members. Members with the next highest weight receive a rank of 2, and so on. Therefore, a member with a rank of n takes precedence over a member with rank n + 1. In case of a tie (members with the same weight), RVFT determines the rank based on seniority. Members of higher weight always outrank members of lower weight. Note that weight signifies processing capacity, meaning hardware and operating system capabilities must be carefully considered when assigning weight to members. RVFT applications can be programmed to adjust their weight dynamically at any time. RVFT will automatically recalculate member rank accordingly anytime a member‘s weight changes.2. Each RVFT group member must specify a heartbeat interval. This interval is used to determine theinterval at which an active member will publish its heartbeat message.1) The activation interval is the interval that an inactive member waits before becoming active when a heartbeat signal is lost. When a process joins a fault-tolerance group, it specifies its activation interval. All members of a FT group must specify the same activation interval.2) When process joins an FT group, it may specify a preparation interval. This parameter specifies how long an inactive member needs to prepare before becoming active. If its value is 0, no prep time will be allowed. It might be used to allow an application some time to connect e.g. to a database to speed up the final activation process. It will be asked to become active only after the activation interval has expired.===============================RVFT in Action===============================With these intervals in mind, let‘s revisit the "RVFT Operations" diagram and consider the sequence of events should Application A go down. Inactive members track heartbeat messages from each active member. When the time since the last heartbeat from an active member reaches this activation interval, Rendezvous fault tolerance software instructs the ranking inactive member to activate - in this case Application B. (Note that the preparation interval must also be adhered to if this parameter has been specified.)Once active, Application B begins publishing data as well as heartbeat signals. Since the remaining two members have the same weight, RVFT breaks the tie and assigns ranking inactive status to the member with more seniority (Application C). Application D remains inactive, and all three functioning applications continue to cooperate in the FT group.TIBCO Rendezvous Distributed QueueThis example illustrates a TIBCORendezvous distributed queue.A task message comes into an distributedqueue group from either a reliable or certifiedRendezvous sender. The group includesmember applications: one scheduler and fiveworkers. In an distributed queue group therecan only be one scheduler at a time, and atask can only be assigned to one worker at atime. Uncompleted tasks can be reassignedto another worker.Distributed queue group members cooperateto process each inbound task. All memberslisten for inbound messages on the same subject name. Workers process inbound task messages from the scheduler.Membership in a distributed queue is determined by the distributed queue group name, which should be a unique name on the network. The scheduler assigns each inbound message as a task to the worker with the highest weight, provided the worker is available. A worker is consideredavailable unless its assigned pending tasks exceed its task capacity or the preferred worker is also the scheduler (allowable only if all workers are busy). A worker that receives a task has the complete time interval to finish the task. A complete time of zero indicates that the worker has an indefinite amount of time to complete the assigned task. Because the scheduler is a FT component, scheduler weight is used todetermine rank among schedulers. Also, the scheduler heartbeat and activation interval parameters are used to manage and reassign schedulers. All members of a distributed queue group must specify the same scheduler heartbeat and activation interval.。