If you need this functionality on IS, you’ll need to persist the data to disk in some way. Using TN for this is common. You receive the request, write the data, then return the status–which might just be a simple http 200 status.
The key part of this is writing the data before returning “success” to the client. The client must wait for a positive status return before considering the message to be sent.
If IS fails, or the network fails, or the client fails after the data has been sent from the client to IS but before IS says “got it”, the client has no alternative than to resend. If you want a client-side “fire and forget” facility (client-side queueing) that is not susceptible to server or network outages, then you’ll need to implement such a thing or use an off-the-shelf component (MQ is often used for this).
Using Broker doesn’t really simplify this logic. If you send to Broker directly you won’t have to implement server-side persistence but your client still needs to make sure it is robust enough to assure data transfer in the face of server and network outages.
Using IS, you can have IS use a couple of different approaches to persist the data before returning “got it”. One is to have IS publish the doc to Broker right away, and then return control to the client. Another, is to submit the data/document to TN and if a bizdoc is returned from TN, success can be returned to the client.
HTH
#webMethods#webmethods-Protocol-and-Transport#Integration-Server-and-ESB