Explore topic-wise InterviewSolutions in .

The JMS Topic Requestor activity is used to communicate with a JMS application’s request-response SERVICE. This service invokes an operation with INPUT and output. The request is sent to a JMS topic and the JMS application RETURNS the response to the request.

The JMS Topic Requestor activity is used to communicate with a JMS application’s request-response service. This service invokes an operation with input and output. The request is sent to a JMS topic and the JMS application returns the response to the request.

The JMS QUEUE REQUESTOR activity is used to SEND a request to a JMS queue name and RECEIVE a response back from the JMS client.

The JMS Queue Requestor activity is used to send a request to a JMS queue name and receive a response back from the JMS client.

The USER that is ASSIGNED to the QUEUE and the user USED while CREATING.

The user that is assigned to the queue and the user used while creating.

Advantages: as the message broadcasts only once thereby reducing the amount of BANDWIDTH used in publish and subscribe model. REDUCES the network traffic.

Disadvantages: OFFERS only last-hop DELIVERY. So can’t be used to SEND messages between servers.

Advantages: as the message broadcasts only once thereby reducing the amount of bandwidth used in publish and subscribe model. Reduces the network traffic.

Disadvantages: Offers only last-hop delivery. So can’t be used to send messages between servers.

• Multicast is a messaging MODEL that broadcasts messages to many consumers at once rather than SENDING messages individually to each consumer. EMS uses Pragmatic general multicast to BROADCAST messages published to multicast ENABLED topics.
• Each multicast enabled topic is ASSOCIATED with a channel.

• SUBSCRIBE
• PUBLISH
• DURABLE
• USE durable

• RECEIVE
• SEND
• BROWSE

You can CHANGE in the tibemsd.conf FILE or you can change USING the ems admin CONSOLE.

You can change in the tibemsd.conf file or you can change using the ems admin console.

• VIEW
• CREATE
• DELETE
• MODIFY
• PURGE

• Queues.conf
• Topics.conf
• Routes.conf
• Factories.conf
• Stores.conf
• Groups.conf, users.conf, transports.conf

Flow CONTROL has to be specified on both sides of bridges where as on ROUTES it operates differently on sender side and RECEIVER side.

Flow control has to be specified on both sides of bridges where as on routes it operates differently on sender side and receiver side.

Sometimes the producer may send messages faster than the CONSUMERS can receive them. So, the message capacity on the server will be EXHAUSTED. So we use FLOW CONTROL. Flow control can be specified on destinations.

Sometimes the producer may send messages faster than the consumers can receive them. So, the message capacity on the server will be exhausted. So we use flow control. Flow control can be specified on destinations.

*,> you can SUBSCRIBE to wildcard topics but can’t PUBLISH to them. Where as in case of QUEUES we can’t either send /RECEIVE.

*,> you can subscribe to wildcard topics but can’t publish to them. Where as in case of queues we can’t either send /receive.

• Static-created by SERVER.
• Dynamic-created by CLIENT. 
• TEMPORARY DESTINATIONS.

If the jms_preserve_undelivered property is set to true, then it moves he MESSAGE to undelivered message QUEUE, if set to false, the message is DELETED by the SERVER.

If the jms_preserve_undelivered property is set to true, then it moves he message to undelivered message queue, if set to false, the message is deleted by the server.

TOPICS and QUEUES m-hops.

Topics and queues m-hops.

• Point-to-point
• Publish-subscribe
• MULTICAST

• GUI MODE
• CONSOLE mode
• SILENT mode

GLOBAL, SECURE, maxmsgs, maxbytes, FLOW control, sender name, sender_name_enforced, TRACE, maxRedelivery.

Global, secure, maxmsgs, maxbytes, flow control, sender name, sender_name_enforced, trace, maxRedelivery.

It is the MAIN CONFIGURATION file that controls the CHARACTERISTICS of the EMS SERVER.

It is the main configuration file that controls the characteristics of the EMS server.

TWO MODES:

1. SYNCHRONOUS and ASYNCHRONOUS.
2. DEFAULT is asynchronous.

Two Modes:

This file defines the LOCATIONS EITHER store files or a database, where the EMS SERVER will store messages or METADATA. Each store configured is either a file-based or a database store.

This file defines the locations either store files or a database, where the EMS server will store messages or metadata. Each store configured is either a file-based or a database store.

• Some applications require the same message to be sent to more than ONE destination possibly of DIFFERENT types. So we USE bridges in that scenario.
• CREATE BRIDGE source=type: dest_name target=type:dest_name [selector=selector]

• TEXT
• Simple
• Bytes
• Map
• XML test
• OBJECT
• Object REF
• STREAM

• AUTO
• CLIENT
• Dups_ok
• No_ack
• EXPLICIT
• Explicit_client_dups_ok
• TRANSITIONAL
• LOCAL transitional

No. PERSISTENT messages published to a topic are WRITTEN to disk only if that topic has at least ONE durable subscriber or one subscriber with a fault-tolerant connection to the EMS server. In the ABSENCE of a durable subscriber or subscriber with a fault-tolerant connection, there are no SUBSCRIBERS that need messages resent in the event of a server failure. In this case, the server does not needlessly save persistent messages. This improves performance by eliminating the unnecessary disk I/O to persist the messages.

No. Persistent messages published to a topic are written to disk only if that topic has at least one durable subscriber or one subscriber with a fault-tolerant connection to the EMS server. In the absence of a durable subscriber or subscriber with a fault-tolerant connection, there are no subscribers that need messages resent in the event of a server failure. In this case, the server does not needlessly save persistent messages. This improves performance by eliminating the unnecessary disk I/O to persist the messages.

Persistent:

When a producer sends a PERSISTENT message, the producer must wait for the server to reply with a confirmation. The message is persisted on disk by the server. This DELIVERY mode ensures delivery of messages to the destination on the server in almost all circumstances. However, the cost is that this delivery mode incurs two-way network traffic for each message or committed transaction of a group of messages

Non-Persistent:

• Sending a NON_PERSISTENT message omits the overhead of persisting the message on disk to improve performance.
• If authorization is disabled on the server, the server does not send a confirmation to the message producer.
• If authorization is enabled on the server, the DEFAULT CONDITION is for the producer to wait for the server to reply with a confirmation in the same manner as when using PERSISTENT mode.
• Regardless of whether authorization is enabled or disabled, you can use the npsend_check_mode parameter in the tibemsd.conf file to specify the conditions under which the server is to send confirmation of NON_PERSISTENT messages to the producer.

Reliable:

• EMS extends the JMS delivery modes to include reliable delivery. Sending a RELIABLE_DELIVERY message omits the server confirmation to improve performance regardless of the authorization setting.
• When using RELIABLE_DELIVERY mode, the server never sends the producer a receipt confirmation or access denial and the producer does not wait for it. Reliable mode decreases the VOLUME of message traffic, ALLOWING higher message rates, which is useful for messages containing time-dependent data, such as stock price quotations.

Persistent:

When a producer sends a PERSISTENT message, the producer must wait for the server to reply with a confirmation. The message is persisted on disk by the server. This delivery mode ensures delivery of messages to the destination on the server in almost all circumstances. However, the cost is that this delivery mode incurs two-way network traffic for each message or committed transaction of a group of messages

Non-Persistent:

Reliable:

EMS supports MESSAGES up to a maximum SIZE of 512MB. However, we recommend that application programs use smaller messages, since messages approaching this maximum size will strain the performance LIMITS of most current hardware and OPERATING system platforms.

EMS supports messages up to a maximum size of 512MB. However, we recommend that application programs use smaller messages, since messages approaching this maximum size will strain the performance limits of most current hardware and operating system platforms.

• MAP Message
• TEXT Message
• STREAM Message
• BYTES Message
• OBJECT Message

• If a message expires or has exceeded the VALUE specified by the maxRedelivery property on a QUEUE, the server checks the message’s JMS_TIBCO_PRESERVE_UNDELIVERED property. If JMS_TIBCO_PRESERVE_UNDELIVERED is SET to true, the server moves the message to the undelivered message queue, $sys.undelivered. This undelivered message queue is a system queue that is always present and cannot be deleted. If JMS_TIBCO_PRESERVE_UNDELIVERED is set to false, the message will be deleted by the server.
• You can only set the undelivered property on individual MESSAGES, there is no way to set the undelivered message queue as an option at the per-topic or per-queue level.

• HEADER (REQUIRED)
• PROPERTIES (OPTIONAL)
• BODY (optional)

• The JMS STANDARD specifies TWO delivery modes for messages, PERSISTENT and NON_PERSISTENT. EMS also includes a RELIABLE_DELIVERY mode that eliminates some of the overhead associated with the other delivery modes.
• For consumer sessions, you can specify a NO_ACKNOWLEDGE mode so that consumers do not need to acknowledge RECEIPT of messages, if desired. EMS also provides an EXPLICIT_CLIENT_ACKNOWLEDGE and EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode that restricts the acknowledgement to single messages.
• EMS extends the Map Message and Stream Message body types. These extensions allow EMS to EXCHANGE messages with TIBCO Rendezvous and Active Enterprise formats that have certain features not available within the JMS Map Message and Stream Message.

• SECURE Property
• Trace Property
• Store Property
• Redelivery policy
• Flow CONTROL
• EXCLUSIVE property for QUEUES

• As long as the durable subscriber EXISTS
• EXPIRATION TIME of the message
• Storage limit of that TOPIC

• Point-to-Point (QUEUE)
• PUBLISH and SUBSCRIBE (TOPIC)
• MULTICAST (Topic)