RVCM

RVCM

RVCM provides complete reliability for the subscribers RVCM uses ledger concept.

Two types of ledgers

1. File based

2. Process based

For process based ledger the publisher offers reliability only as long as he is running

Process based means memory

For File based ledger the publisher offers reliability all the time.

For each out bound message a certified sequence number will be added, message will be stored in the ledger file and then it will be placed on the network.

When the subscribed subscriber receives the message he should send conformation for the received message

The certified subscriber ledger file will be updated with incoming message subject name, the certified publisher transport name, and the last acknowledged message sequence number will be updated with conformed message sequence number.

For each received message the certified subscriber should send conformation to the publisher. When publishing RVD receives confirmation then only it understands that message has been delivered successfully.

The certified publisher provides reliability only for agreed subscribers by default when the certified subscriber receives the first message, that message will be having same sequence number as "Zero" irrespective of actual sequence number.

Same sequence number "0" indicates that the message is only reliable message which means there is no guarantee for the message second there is no certified delivery agreement has been established

After receiving the first message the certified subscriber internally will send certified delivery request to the publishing RVD then the list of listeners in the publisher ledger will be updated with agreed certified subscriber transport name.

After the agreement only the sublisher will provide offline message delivery to the agreed certified subscriber

When ever certified subscriber lost message by comparing last acknowledged message sequence number with the incoming message sequence number.

For the lost message he will send retransmission request for the publishing RVD.

When the publishing receives retransmission request it will check the ledger and if the agreement exist the message will be retransmitted

In certified delivery three advisory ___________ and messages will be used

3. Delivery Confirm

4. Delivery complete

5. Delivery no response

Delivery of confirm indicates the publisher is expecting confirmation from the certified subscriber for a published message

Delivery of complete indicates the certified publisher has received confirmation from all the certified subscribers for a published message.

Delivery of no response indicates the publisher has not received confirmation for a published message.

When ever certified publisher receives retransmission request he will retransmit all the messages who's adversary message status is delivered on no response

The adversary message status will be set for each message and for each subscriber individually

In order to provide certified message delivery from the first message itself the certified subscribed should be pre registered the certified subscriber at the publisher site

For pre registered certified subscriber the message numbers will be non zero values

There is a chance of duplicate message delivery by the certified publisher

Before receiving confirmation from the certified subscribers if the publisher goes offline when he is restarted he will retransmit all the messages who's adversary message status is delivered on no response

RVRAND stands for RV relay agent Demerol

RV follows BUS architecture which means it is pear to pear network thats way the publisher should be online 24/7 in order to deliver offline messages even if he doesn't have any messages to publish.

RVRAND will be acting as interface between publisher and subscribers in certified messaging.

The relay agent will have access to publisher ledger

The relay agent should be running on only on the publisher system if the publisher is offline and at that time if certified subscribers sends retransmission request the relay agent will retransmit all the offline messages to the certified subscribers

If relay agent is configured the certified publisher need not to be active in order to deliver offline messages

If at all the relay agent is configured we should make sure relay agent is online

RVR subscriber can also receive messages that are published by certified publisher but offline message delivery will be only for certified subscribers but not for RVR subscribers

If RVR subscriber sends retransmission request with in buffer interval or with in reliability time then RVR subscriber can receive offline messages

Only if the network link is broken

RVCACHE contains the most recently exchanged message data for any subject.

It will store only one message per subject

In order to get message data from RVCACHE application should send request on to a subject called "_SNAP."

In RV the load balancing is implemented by RVDQ

RVDQ means its collection of cooperative RV transport objects each having its own process

The DQ will be implemented only at the subscribers side

All the applications that are part of distributed queue should be listening on the same subject

In a distributed Queue only one application will be acting as scheduler and all other applications will be acting as workers

The role of scheduler is delivering messages to the workers in load balanced manner if all workers are busy then only the scheduler will process messages

All the DQ applications should have same values for

Cmq name

Scheduler activation

Scheduler heartbeat

Based on the requirement and systems configuration each worker can be configured with same values or different values for

Scheduler weight

Worker weight

Worker task

Worker complete time

If all applications are having same values for these 4 parameters one of the application will be picked randomly ac scheduler and this scheduler will deliver one message to one worker at a time

Which ever allocation has highest scheduler weighr that application will be initial scheduler. The worker weight specifies the prerority of the worker . Worker stasks specifies number of messages a worker can process simultaneously

Worker complete time specifies the amount of time a worker requires to complete given message processing.

Worker tasks is also referred as worker queue

When ever scheduler recives messages he will deliver all the messages to the high prority owrker ans schedular will continioue to do so till the high prority worker becomes busy

A worker will be treated as busy if he is worker queue is full or if he unable to complete message processing with in specific amount of time.

When the high prority worker becomes busy then the schedular will delever messages to the second high proroty worker

In this manner the schedular will distribute meesage amoung workers for load balenced message processing

At reqular intervels wich is ssecified by schedular heart beat the schedilar will be sending hard beat messages to all the workers indecating that he is active

If the schedular stops sending hear beadschedular weightw messages

The worker who has second highest schedular weight will beome or will be activated as new schedular after the intervel which is specified by ______________

And the initial s__________________________________________________________________________

Internelly all the dq appliccations are certified messaging applications the DQ is implemented with the help of RF FT

RVFT --- RV fault tolerance

RVFT is responcible for _________________

Making sure that the DQ applicatiosn are communicating properly and it is also responcible for activating working as schecular and deactivating schedular

The dq group should contain min 3 applications

For load balance functionality

CMQ-certified message queue

Using cmq name applications will be logically grouped under a named distributed queue

All the DQ applications should have same business logic

If the publisher to DQ is certified publisher the DQ application should send confirmation other wise the dont need to send confirmation

RVRD stands for RV Routing De_____

RVRD ________ message routing between networks

If a system is configured with RVRD we dont need to use RVD because RVRD contais the functionality of RVD

In each network RVRD should be configured the communication protocol between RVRD is TCP

While routing messages across network RVRD can compress and de-compress messages

While configuring RVRD the network information should be exported and should be imported in both RVRD configurations and the subject names also should be configured

We need to configure the network and the neibering networks in router

RVA

RVA stands for RV agent

RVA will be acting as firewall between browser applications and RVD

The browser application can connect to RVA either using TCP protocol or as http application using "http tunneling" mechanism this restriction is imposed dud to security issues.

The subjects which will be used in browser communication should be configured

VC

VC stands for Virtual Circuits

VC enables point to point communication between RV applications

In both the RV applications Virtual circuit transport objects should be created

Each virtual circuit transport object is call as a terminal

Terminals guarantees that messages are always travel between the terminal

Virtual circuits can be configured programmatically only

Broadcast means delivering messages to unknown number of applications (used in RVR)

Multi casting means delivering messages to known applications (used in RVCM)

Uni-cast means delivering messages to only one application (used in VC)

In RV synchronous communication if the reply subject is not specified RV will automatically create a reply subject who's name starts with "_inbox"

If a system has multiple network interfaces then for each interface we are suppose to configure service with different port number so that system can receive messages from multiple UDP interfaces, for this the system should have multicast address

Multicast address range is 224.0.0.0 to 239.255.255.255

C:\Users\sundeep>RVD -listen 7575 - reliability 500 -http 7676 logfile C:\RVLOGG

ER.LOG

To test the network

rvperfm -messages 20000 -size 1500 -interval 5000 -batch 5000 -subject PERF

RVPERFS - SUBJECT PERF

For subscriber(slave )

EMS stands for Enterprise message service

EMS is based on JMS specification

JMS--- Java message service

EMS is based on TCP protocol

EMS follows Hub and spoke architecture

EMS supports 3 types of communication models

Synchronous

Asynchronous

Asynchronous with reply

EMS synchronos and asynchronous with reply are flexible than RV synchronos and asynchronous with reply

EMS supposts 2 messing models

Point to point

Publish subscribe

EMS point to point is more flexible than RV point to point

RV publish subscribe is faster and flexible than EMS publish subscribe

Point to point messaging modal works under a domain called queue

Publish subscribe under a domain called TOPIC

In order to connect to a EMS server for point to point communication application should specify new connection factory and for message exchange they should specify the destination as QUEUE

For publish subscribe communication application should specify topic connection factory for connecting to EMS server and they should specify topic for message exchange

Queues and Topics are logical destination for information

Queue connection factory Topic connection factory Queues and topics will be created by EMS administrator and thy will be assigned with JNDI names and will be stored in JNDI location of EMS server

JNDI is a directory in which resources will be stored as name object pairs

The EMS client applications should perform JNDI look up by specifying names of connection factory object and the destination when the look up si success they will be return with connection and reference to destination

One connection factory object can generate multiple connections

One connection factory object can be used by multiple client applications

In EMS for each message there will be at least 2 acknowledgments

1 accknoledge will be from EMS server to the message sender after EMS server receives message successfully

2nd acknoledgment will be from message receiver to the EMS server after receiver receive the message successfully

For each received message the receiver should send confirmation to the EMS server

When EMS server receives acknowledgmenet fro m the receiver then only it assumes that message has been delivered successfully and then it will delete the message from the destination.

If the receiver dose not ackledge the message the EMS server assumes message has not been delivered and it will continuously redeliver the message to the receiver

We can explicitly specify the number of times EMS server should redelever unacknowledge message using a property called maxredelivery"

After Maxredelivery occurs the message will be deleted this property can be specified only for queues.

Fig

In point to point each message there will be exactly one receiver

Point to point provides one to one message delivery

When sender sends message to EMS server and when EMS server receives the message successfully it will put the message on to queue and then it will send acklodment to the sender

If the receiver is active it will deliver the message to the receiver and when EMS server receives acklodment from the receiver it will delete the message from the queue

By default it is not necessary for the receiver to be online in order to receive messages

EMS server will store all the messages that are sent by sender during receivers absence and when ever receiver becomes online it will deliver the messages to the receiver

By default the queue can receive online messages and offline messages also.

Two types of queue's

1. Exclusive

2. Non exclusive

The default is non exclusive queue

Exclusive and non exclusive will be considered only if queue is configured with multiple receivers or multiple receivers are listening on the same queue.

The advantage of non exclusive queue with multiple receivers is EMS server provides load balanced message delivery for the queue receivers

When ever sender sends messages to non exclusive queue if multiple receivers are active EMS server will deliver one message to one receiver at a time in round robin. If non exclusive queue has pending or offline messages when multiple receivers becomes online based on PRE-Fetch property it will deliver the messages to the receivers in round robin.

By default the pre-fetch value is 5 for topic 64.

The advantage of exclusive queue with multiple queue receivers is EMS server provides fault tolerant based message delivery for the queue receivers

If a queue has exclusive property that queue is called exclusive queue

For exclusive queue and for online messages and for offline messages EMS server will deliver all the messages to the receiver who ever connects first

Start EMS server

7222 default port number

Go to tibco ems and select start ems adminstraator

Connect tcp://localhost:7222(enter)

UN:(enter)

PW:(enter)

We need to create factory object

CREATE FACTORY SENDER.QCF QUEUE(ENTER)

TO SEE THE PROPERTIES OF THE FACTORY OBJECT

SHOW FACTORY SENDER.QCF

TO ADD PROPERTIES

ADDPROP FACTORY SENDER .QCF URL=tcp://localost:7222 CLIENTID=SENDERNODE

IF WE CROSS CHECK IT WILL SHOW THE NEW UPDATES

CREAT E ONE MORE FACTORY

CREATE FACTORY RECEIVER.QCF QUEUE URL=tcp://localhost:7222 clientid=receiver

SHOW FACTORIES

SHOW FACTORIES QUEUE

CREATE QUEUE POLICIES.QUEUE

TO SEE THE PROPERTIES

SHOW QUE POLICIES.QUEUE

SHOW STACK QUEUE POLICIES.QUEUE

To fine out how many clients are connected

SHOW CONNECTIONS

To fine out complete details

SHOW CONNECTIONS FULL

To find out how many subscribers are connected

SHOW CONSUMERS

SHOW CONSUMER

Ex: SHOW CONSUMER 1

Select the queue Polocy queue

Select input specify Policy. Request-101

Configure the receiver

Specify JMS Queue receiver

Connection specify the receiver

Message type text

Acknowledge mode auto

Destination que browse "policies.queue"

ADDPROP QUEUE POLICIES.QUEUE EXCLUSIVE

What if the receiver is not sending acknowledgment

Select receiver 1

Go to queue receiver

Change the acknowledge mode to client

Run the sender and send one message

Lets set the property max redelivery

ADDPROP QUEUE POLICIES.QUEUE MAXREDELIVERY=10

Undelivered queue if queue has max-redelivery property when redelivery limit exceeds the message will be deleted from source queue. If the sender specify a JMS property called "JMS_TIBCO_PRESERVE_UNDELIVERED". Them unacknowledged messages after max redeliver limit will be redirected to undelivered queue.

Undelivered queue will contain unacknowledged messages and expired messages for the destinations which has the properties max redelivery and the undelivered queue is "$sys.undelivered "

To set the JMS_TIBCO_PRESERVE_UNDELIVERED at the sender

Get JMS application

Properties

Select sender go to advanced

Go to JMS application properties a

D specify the jms application properties

Select input

Specify "true" at jms tibco preserve undelivered

By default the message will be on the destination till EMS receives acknoledgment from the receiver we can explicitly specify the life time of message by using the property JMS Expiration

Select que sender---> input ---> jms expiration----> specify 60

Select receiver and change the acknowledge mode to auto

Create one jms connection------------> name-----> JMS_admin_conn

Get a process

Name---> DELIVERY_NACK_AND)EXPIRED_MSGS(ADMINTASK)

SPECIFY ONE jms RECEIVER AND ONE jms Que sender

Connection-> select jms admin conn

Destination que ---> $sys.undelivered

Select que sender

HMS connection---> jms_Admin_conn

Sestination que----> polacie queue

Select input

Map body to body

Run only admin and receiver

GET JMS QUEUE Message

By default the queue receiver will receive all the messages from the queue in order to receive specific message at a time we can use "Get JMS Queue Message Activity"

For this activity we need to specify a message selector which specifies the message that needs to be received.

First select JMS application properties

Go to properties and specify

REQUEST_ID

Set the type to string

Have one process

Message_Picker

Jms connection

Name---> JMS_conn_message_picker

Select the process message picker

Specify JMS que message

Start--->get jms ue message ---> end

Select the Get Jms Que message

Jms connect JMS message picker

Que Polacie queue

Advanced

JMS application property ---> JMS application property

Message selector----->REQUEST_ID='REQ-202'

Select the sender process

Name-->101

Input

Request_id --> "REQ-101"

Body---> "REQ-101"

Copy past the sender

Change all the 101's to 202

Also create more 303,404 etc

Select 202

Create a group

Repeat un till true

h(Index)

$h >= 2(condition)

First run the sender

Run the message picker

PUBLIC subscribe

In public subscribe each message can be received by multiple subscribers thats why the public subscribe offers one to many message delivery.

When ever publisher publish message to EMS server EMS server will deliver that message to all active subscribers.

By default all the subscribers should be active in order to receive messages while publisher is publishing messages other wise they can not receive messages

Thats my the default topic subscribers are called non durable subscribers

A non durable subscriber is a subscriber who can receive messages only when he is online

EMS server dose not provide offline messages for non durable subscribers

If a topic has only non durable subscribers EMS server dose not store pending messages for that topic

A durable subscriber is a subscriber who can receive online messages and offline messages

EMS server will hold the messages which were published during durable subscriber absence and when ever durable subscriber becomes online EMS server will deliver all the offline messages to the durable subscriber the EMS server will store the messages on to the topic only if the topic has at least one durable subscriber

There are two ways of creating Durable subscriber

1. By EMS administrator

2. Dynamically by applications

For EACH SUBSCRIBER THE EMS SERVER WILL MAKE COPY OF MESSAGE AND WILL BE DELEVERED

But where as in the case of RV broadcasting irrespective of number of subscribers the message will be traveled on the network only once.

Even though at messaging level the public subscribe of EMS provides one to many message delivery internally the EMS server will treat each subscriber as a point to point messaging

We are not suppose to make all the applications as durable subscribers

When ever a durable subscriber is created a mirror image for the actual subscriber will be created even though the message will be received by actual subscriber and send conformation still EMS server will store the messages.

The EMS administrator should carefully check and delete the messages from durable subscribers

Fig

New project --- > ems.topics

JMS

JMS connection

Name: JMS_CONN_PUB

Go to advanced

PUB.TCF

One more JMS connection

Advanced topic--- SUB.TCF

Copy past JMS connection

That makes one publisher and two subscribers

Get a process

Name PUB

One more process

Name Sub1

Go to Publisher process

Get a JMS topic publisher

JMS connection select JMS Conn PUB

Topic select the topic---- policies.request.topic

Select Input in Body--- "vehicle policy"

Select sub one

JMS topic subscriber

Connection JMS connection sub1

Topic policies.request.topic

Copy past that process

Change the connection to JMS connection sub2

Load all the 3 process in the test

To make one subscriber as durable subscriber

Create durable POLICIES.REQUESR.TOPIC ds

SHOW Durable

SHOW Durable ds

Select topic subscriber

Check the potion durable subscriber

Subcriber name ds

To register run the subscriber which we have changed to durable

To see the actual storage the command is

SHOW DB ASYNC

Show consumers

How can the ems adminstrator can delete the messages form the mirror image

Command is-----> purge durable ds

Durable subscription dynamically

Sub2 process

Select durable subscription

Sub name dyn-ds

Run the sub2 once

Message select

Using message selectors a subscriber can explicitly specify the type of messages that he want to receive

The message selector will be applied on the EMS server while delivering messages to the subscribers

Message selectors follows SQL 92 syntax

Message selectors can not be applied on message body elements we should use only header properties which are also referred as JMS application properties

Sub1 want to receive only vehicle policies

Sub2 wants to receive only health and properties policies

Specify one JMS application properties

Define one property "+"

Policy_Type

Type--->string

vehicle policies_type='VEHICLE'

vehicle policies_type='VEHICLE'

Select Sub1

Topic subscriber

Go to advanced

Go to jms application properties and specify JMS application properties

Message selector---> policies_type='VEHICLE'

Select Sub2

Topic subscriber

Go to advanced

Go to jms application properties and specify JMS application properties

Message selector---> policies_type in =('HEALTH','PROPERTY')

Select publisher

Select topics publisher

Advanced

JMS application properties--- JMS application pro

Copy past the topic subscriber

Change the names to vehicle, health and properties

Select property input

Other properties---- policy type---- "PROPERTY'

Do mapper check and repair

Health

Policy type --- "HEALTH'

Do mapper check and repair

Select vehicle

Policy type --- "velicle"

Destination Bridge

Using destination bridging a message can be redirected to multiple destinations which exist in the same server.

A bride can be created between topic to topic

Topic to queue

Que to toipc

And queue to queue

Bride direction should be uni directional only we are not suppose to create bridge which results in bi-directional

The advantage of bridge is with out resending same message multiple times and with out reconfiguring the applications messages can be delivered to or redirected to multiple destinations

There are 2 ways of creating bridges

1. Bridge.config----------------

[:]

=

2. EMS ADMIN TOOL

a. CREATE BRIDGE SOURCE=:

Target==

From ems admin tool we can bridge only one destination with another destination but from bridges.configaration file we can bridge one destination with one or more destinations

Create queue POLICIES.MONITOR.QUEUE

Create bridge source=TOPIC:POLICIES.REQUESTS.TOPIC Target= QUEUE= POLICIES.MONTOR.QUEUE

Show topic policies.request.topic

TO test lets have a JMS connection ----- JMS_CONN_MONITOR

Have a process ---- POLICIES_MONITOR

Specify one QUEUE receiver

Go to connection and select a connection

Specify the queue ----POLICIES.MONTOR.QUEUE

If we delete the bridge

Queue receiver will not receive any messages

Delete bride command

Delete bridge source=TOPIC:POLICIES.REQUESTS.TOPIC Target= QUEUE= POLICIES.MONTOR.QUEUE

Create bridge source=TOPIC:POLICIES.REQUESTS.TOPIC TARGET=QUEUE=POLICIES.MONITOR.QUEUE SELECTOT="POLICY_TYPE IN ('VEHICLE','HEALTH')"

Ems Route

Am EMS route enables message routing across EMS servers the destinations that are part of message routing should have the property global

Topic names should be same in all the routed servers

In the routed servers the QUE name should be name of the QUEUE in the routing server @name of routing server

This queue is called Remot queue or routed que

In which ever server publisher exists route should be created in that server

Two types of routers

1. Active routeh

2. Pasive routers

Active route is the one in which publisher exists the messages will be published connections will be initeated and the routhe information will be in local routes configuration file

Pasive route is the one which accrpts qiuted connections receives messages and whos routes configuraton will be dynamically created by remote host by default all the routs belongs to zone

A ZONE defines or restrits the functionality of EMS server routing

There are 2 types of zones

1 hop

Mhop

Default is mhop

In mhop zone topic messages can be routed to one or more servers queue messages will be routed to only one server

In 1 hop zone topic messages and queue messages can be routed to only one server

The subscriber which is in the routed server is not supposed to be configured with no acknowledge acknowledgment mode

For providing _______________ at the server level internally the EMS server maintains temporary durable

We are not supposed to create route which results in cycle

Copy past the ems folder 2 times

Past it in other server in tibco folder

The syntax for creating route is

1. Routes.config

i. [route=name]

ii. Url=

2. EMS admin tool

i. Create route [route-name] url=

Go to broadcasting server go to bin folder

We need to enable routing

For that open the configuration file tibemsg

Server = broadcasting_ems_ server

GO to listen and specify some port number 10000(for 7222)

Go to routing set to enabled

Open routs configuration file

Subscribers-ems-server

Localhost:20000

Zone_name=SEATTLE------------ optional

Open Queues configuration file

SERVICES.WIMAX.LTE GLOBAL

Open topics configuration file

SERVICES.WIMAX.LTE.DISTRIBUTION GLOBAL

Open factories config file

[ROUTE.QCF]

Type=queue

URL=tcp://localhost:10000

[ROUTE.TCF]

Type=TOPIC


Go to second server subscribers _server

Go to bin

Go to tibemsd

Specify the server name ---- SUBSCRIBERS-EMS-SERVER

Listen port----- 20000

Ser the routing to ----- enabled

Open queues config file

SERVICES.WIMAX.LTE@BROADCASTING-EMS-SERVER GLOBAL

Open topics

Services.wimax.lte.distribution global

Open factories config file

[ROUTE.QCF]

Type=queue


[ROUTE.TCF]

Type=TOPIC


To start the server

Go to the server location from command prompt

c:/> cd d:\adv_ems\broadcasting_Server\bin

And run the command

Tibemsd

Start admin tool for that

Go the the bin location

And run the command

tibemsadmin

Connect to the server command

Connect tcp://localhost:10000

Start the second server

Go to the location fo seond server

d:\adv_ems\subscriber_Server\bin

Run the command ----- tibemsd

Start admin tool for that

Go to the bin location

Run the command--- tibemsadmin

Check the routs

SHOW ROUTES

SHOW ROUTES BROADCASTING -EMS-SERVERS

To test the routers if they work or not

Got a JMS connection

In the new project

Name jms conn 10000

Jmdi context url change 7222 to 10000

Go to advanced

Sepcify the factortdetails

Route.tcf

Route.qcf

Specify another connection

Got a JMS connection

In the new project

Name jms conn 20000

Jmdi context url change 7222 to 20000

Go to advanced

Sepcify the factortdetails

Route.tcf

Route.qcf

Specify two process definitions

PUBLICSHERS_10000

Open the process

Specify one queue sender and one topic publisher

Select quesender

Got the jms connection --- jms conn 10000

Specify the queue

Input specify some message in the body--- "route testing"

Select topic publisher got the connection --- jms conn 10000

Specify the topic

Go to input specify message "route testing"

Start to jms que sender to end

Start to topic publisher to end

Select second process

Name subscribers_20000

Go in to the process

Select wait for jms topic message

Wait for jms queue message

Select jms wait for topic select the connection 20000

Specify the topic

Go to wait for jms queue message

Select jms connection

Specify the queue

Run the test on bot the servers

First start the subscribers

Then publish the message

Start to wait for jms topic message to end

Start to wait for jms que message

Documents

RVCM