TIBCO EMS STEP -6 :Messages

-

Messages:
Ø  EMS Extensions to JMS Messages :
o   The JMS specification details a standard format for the header and body of a message. Properties are provider-specific and can include information on specific implementations or enhancements to JMS functionality.
o   These are some message properties which EMS provides a select number of extensions to JMS.
o   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.
o   EMS also provides an EXPLICIT_CLIENT_ACKNOWLEDGE and EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode that restricts the acknowledgement to single messages.
o   EMS extends the MapMessage and StreamMessage body types.These extensions allow EMS to exchange messages with TIBCO Rendezvous, which contains certain features not available within the JMS MapMessage and StreamMessage.

Ø  JMS messages have a standard structure. This structure includes the following sections:
·         Header (required)
·         Properties (optional)
·         Body (optional)
Ø  JMS Message Header Fields The header contains 11 predefined fields that contain values used to route and deliver messages.
§  JMSDestination is used for , Destination to which message is sent and will set by  sender or publisher
§  JMSDeliveryMode is used for ,Persistent or non-persistent message. The default is persistent and will set by  sender or publisher
 EMS extends the delivery mode to include a RELIABLE_DELIVERY mode.
§  JMSExpiration is used for Length of time that message will live before expiration. If set to 0, message does not expire. The time-to-live is specified in milli seconds. If the server expiration property is set for a destination, it will override the JMSExpiration value set by the message producer and will set by  sender or publisher
§  JMSDeliveryTime is used for,it is a Read-only field. If the message producer has a delivery delay set, then the time returned here after calling the send method represents the earliest time when the EMS server will deliver the message to consumers. Once the message has been received, it carries that same value. This value is calculated by adding the delivery delay value held by the message producer to the time the message was sent. For transactions, the delivery time is calculated using the time the client sends the message, not the time the transaction is committed. and will set by  sender or publisher
§  JMSPriority Uses a numerical ranking, between 0 and 9, to define message priority as normal or expedited. Larger numbers represent higher priority and will set by  sender or publisher
§  JMSMessageID value is uniquely identifies each message sent by a provider.
§  JMSTimestamp is used for, Timestamp of time when message was handed off to a provider to be sent. Message may actually be sent later than this timestamp.
§  JMSCorrelationID this ID can be used to link messages, such as linking a response message to a request message. Entering a value in this field is optional. The JMS Correlation ID has a recommended maximum of 4 KB. Higher values may result in the message being rejected and will set by message client.
§  JMSReplyTo A destination to which a message reply should be sent. Entering a value for this field is optional.It will set by message client.
§  JMSType Message type identifier sets by client.
§  JMSRedelivered JMS provider If this field is set, it is possible that the message was delivered to the client earlier, but not acknowledged at that time.

Comments

Post a Comment

Popular posts from this blog

TIBCO EMS FAQ -5

-
131) What happens if the message expires/exceeded the value specified by maxredelivery property on queue? 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. 132) What are the wild cards that we use in ems?how do they work for queues and topics? *,> We can subscribe to wildcard topics, but cant publish to them. Where as in case of queues we can’t either send /receive. 133) Are bridges transitive? No 134) Tell me about flow control 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. 135) Tell me about flow control on bridges and routes? Flow control has to be specified on both sides of bridges where as on routes it operates differently on sender side and receiver side. 136) Nam...
Read more

TIBCO EMS FAQ -4

-
101) What are the permissions that you can grant to users to access topics? a. Subscribe b. Publish c. Durable d. Use durable 102) What is the difference between Queues and Topics? Queue • Guaranteed Service • Only the Target gets the message (One message per Consumer) • Uses Peer-to-Peer Mode to deliver messages • Blocking • Load Balancing is possible Topic • Reliable Service • Everyone active gets the message (One message may Consumers) • Uses Pub / Sub mode to deliver messages • Non-Blocking • Load Balancing is not possible. 103) What is the use of secured queues and topics? Setting ‘secure’ property to queues/topics can restrict unauthorized users from publishing/sending and subscribing/receiving the messages. 104) What are acknowledgement modes and where do you set them and what is the applicability of each mode? Ans:The acknowledge mode for incoming messages. Can be one of the following: • Auto — the message is automatically acknowledged when it is re...
Read more

TIBCO BW FAQ -2

-
31) What happens if you use check point activity first and confirm next? Ans)In the case of confirmable messages , you must consider the consequences of performing a checkpoint before or after a Confirm activity. If the checkpoint is taken before the Confirm activity, then a crash occurs after a checkpoint but before a confirm, the original message is resent. In this case, the restarted process can no longer send the confirmation. However, a new process is started to handle the resent message, and you can implement your process to handle the restarted and new processes appropriately. If the checkpoint is taken after a Confirm activity, there is potential for a crash to occur after the Confirm but before the checkpoint. In this case, the message is confirmed and therefore not redelivered. The process instance is not restarted, because the crash occurred before the checkpoint. You must consider the type of processing your process definition performs to determine when a checkpoint i...
Read more