Integration Server 10.15 | Publish-Subscribe Developer’s Guide | Overview of Publishing and Subscribing | Overview of Publishing to a webMethods Messaging Provider | Publishing Documents to a webMethods Messaging Provider and Waiting for a Reply
 
Publishing Documents to a webMethods Messaging Provider and Waiting for a Reply
In a publish-and-wait scenario, a service publishes a document (a request) and then waits for a reply document. This is sometimes called the request/reply model. A request/reply can be synchronous or asynchronous.
*In a synchronous request/reply, the publishing flow service stops executing while it waits for a response. When the service receives a reply document from the specified client, the service resumes execution.
*In an asynchronous request/reply, the publishing flow service continues executing after publishing the request document. That is, the publishing service does not wait for a reply before executing the next step in the flow service. The publishing flow service must invoke a separate service to retrieve the reply document.
The following diagram illustrates how Integration Server and the webMethods messaging provider handle a synchronous request/reply. The webMethods messaging provider can be Broker or Universal Messaging.
Publishing a document to the webMethods messaging provider and waiting for a reply
Step
Description
1
A publishing service sends a document (the request) to the dispatcher. Integration Server populates the tag field in the document envelope with a unique identifier that will be used to match up the reply document with this request.
The publishing service enters into a waiting state. The service will not resume execution until it receives a reply from a subscriber or the wait time elapses. Integration Server begins tracking the wait time as soon as it publishes the document.
If validation is configured for the publishable document type, Integration Server validates the document against its publishable document type before sending the document to the dispatcher. If the document is not valid, the service returns an exception specifying the validation error. The service unblocks, but with an exception.
2
The dispatcher sends the document to the webMethods messaging provider.
Note:
If the webMethods messaging provider is not available, the document is guaranteed, and use of the client side queue is configured, the dispatcher routes the document to the outbound document store. For more information, see Publishing Documents When the webMethods Messaging Provider Is Not Available.
3
The webMethods messaging provider examines the storage type for the document to determine how to store the document.
*If the document is volatile, the webMethods messaging provider stores the document in memory.
*If the document is guaranteed, the webMethods messaging provider stores the document in memory and on disk.
4
The webMethods messaging provider routes the document to subscribers by doing one of the following:
*If the document was published (broadcast), the webMethods messaging provider identifies subscribers and enqueues a copy of the document for each subscriber.
*If the document was delivered, the webMethods messaging provider enqueues the document for the destination specified in the delivery request.
The Broker places documents in a queue for a subscriber. Universal Messaging places documents on a channel.
A document remains enqueued on the webMethods messaging provider until it is picked up by the subscriber. If the time-to-live for the document elapses, the webMethods messaging provider discards the document. For more information about setting time-to-live for a publishable document type, see webMethods Service Development Help.
If there are no subscribers for the document and the messaging provider has been configured to handle dead letters (sometimes called dead events), the webMethods messaging provider routes the document to the dead letter queue or dead event store. For more information about configuring the messaging provider to handle documents for which there are no subscribers, refer to the documentation for the webMethods messaging provider that is in use.
Note:
If the Broker is the webMethods messaging provider and a deadletter subscription exists for the document, the Broker deposits the document in the queue containing the deadletter subscription. For more information about creating deadletter subscriptions, see webMethods Service Development Help.
5
Subscribers retrieve and process the document.
A subscriber uses the pub.publish:reply service to compose and publish a reply document. This service automatically populates the tag field of the reply document envelope with the same value used in the tag field of the request document envelope.
The pub.publish:reply service also automatically specifies the requesting client as the recipient of the reply document.
6
One or more subscribers send reply documents to the webMethods messaging provider. The webMethods messaging provider stores the reply documents in memory.
The webMethods messaging provider enqueues the reply documents in the request/reply queue or channel for the Integration Server that initiated the request.
7
The Integration Server that initiated the request retrieves the reply documents from the webMethods messaging provider. Integration Server uses the tag value of the reply document to match up the reply with the original request.
8
Integration Server places the reply document in the pipeline of the waiting service. The waiting service resumes execution.
Notes:
*If the requesting service specified a publishable document type for the reply document, the reply document must conform to the specified type. Otherwise, the reply document can be an instance of any publishable document type.
*A single request might receive many replies. The Integration Server that initiated the request uses only the first reply document it retrieves from the webMethods messaging provider. Integration Server discards all other replies. First is arbitrarily defined. There is no guarantee provided for the order in which the webMethods messaging provider processes incoming replies.
*All reply documents are treated as volatile documents. Volatile documents are stored in memory and will be lost if resource on which the reply document is located shuts down or if a connection is lost while the reply document is in transit.
*When Universal Messaging is the webMethods messaging provider, reply documents use an encoding type of IData.
*If the wait time elapses before the service receives a reply, Integration Server ends the request, and the service returns a null document that indicates the request timed out. Integration Server then executes the next step in the flow service. If a reply document arrives after the flow service resumes execution, Integration Server rejects the document and creates a journal log message stating that the document was rejected because there is no thread waiting for the document.
*You can configure publishable document types and Integration Server so that Integration Server does not validate documents when they are published. For more information about validating publishable document types, see webMethods Service Development Help.