The IS server uses a process called the dispatcher to handle interaction with the broker. This dispatcher works differently depending on how you have configured your integration server. The dispatcher handles putting documents into the broker queues and pulling documents out of the broker queues. If you have client side queuing turned on(really don’t need this if you are using the broker and doesn’t work with clustering) then the document is persisted to disk on the IS side after the document is retrieved from the broker. I don’t see a lot of value to client side queuing when using the broker. You are in affect, maintaining persistent queues in two different places, overhead, overhead, overhead.
As far as publishing the document to the broker, the IS server will still persist the document to disk(outbound document store) if it cannot contact the broker(regardless of the client side queue setting). It will then preserve first in/first out when the broker comes back up by pulling from the outbound document store before processing new requests.
The original question brings up the critical element when designing integrations. Failure points exist in many places, knowing where these are and how to handle them is the job of the architect, not the software. Some are more risky than others, and these have to be weighed against cost and probability. I’ll give you the following example: When the IS server dispatcher retrieves a document from a broker queue, it hands it off to a IS trigger which in turn invokes a service. After that service successfully executes, an acknowledgment is sent back to the broker via the dispatcher to delete the document from the broker queue. It is possible(it doesn’t really happen that often or at all but it could) for the service to complete successfully and then have an IS server crash before the acknowledge is sent back to the broker.
In this case when the IS server comes back up the document will be reprocessed. This could be bad depending on how your integration is architected. Numerous examples of this can be found all throughout typical integrations including issues with your source and targets. Knowing where all of these situations are in a given integration and the risk associated with them is a critical component of the integration design.