Message & Attachment Life
When registering a program to the ISB, you can choose how long messages and their attachments sent by instances of your program are allowed to live in an outbound queue on the ISB if it is not picked up by the intended receiving program instance. This feature allows you to keep outdated communications from being received, since data contained in some messages might only be relevant for short periods of time.
Transport
You can allow instances of your program to initially try and communicate via TCP, and if unable, then try HTTP. TCP is faster. However, if you know that instances of your program will be running in an environment in which they cannot use TCP, then you should select the HTTP only option.
Note: All messages are encrypted using X.509 certificates. This provides for end-to-end security, regardless of the number of intermediary networks involved and regardless of whether or not they are secure.
Message Sending and Retrieval
Sending and receiving messages is asynchronous and non-blocking to your program. This means your program instance can keep on doing what it is doing and not worry about getting hung while processing a send or receive operation. This is true regardless if done via the on-demand method calls or if scheduled intervals are used.
On-demand
In your code, you can send and receive on-demand using the SendNow() and ReceiveNow() method calls.
Scheduled Sending and Receiving
Sending
Scheduled sending is automatically enabled when your program instance is running. Your instance will only try to send a message if there is one or more waiting to be sent in your local queue.
Receiving
Scheduled receiving is automatically enabled when your instance is running and there is a subscription to the MessageReceivedEvent. If, in your code you are not subscribed to that event, your app would not know it received a message and the content of it would be lost. This is why scheduled receiving does not start until you are listening to the MessageReceivedEvent.
Fixed or Range Interval
The schedule can be a fixed time interval, or an allowed range which an instance can choose from (either programmatically or via a user interface control). The settings for these events can be dynamically updated through Web Manager.
Seconary Outbound Queue
The secondary outbound queue runs on its own thread, and can send concurrently with the primary outbound queue. You can use the secondary outbound queue, for example, when the primary is sending lots of short messages that need to arrive to their recipients quickly, and the secondary for sending messages with attachments which would take longer to send, and would otherwise block the shorter messages sent afterwards.
Note: With both outbound queues, you can give messages a priority ranking, changing their sending order within their queue.
Message and Attachment Size
Lastly, we allow you to control the maximum sizes of messages and attachments that your program instances can send as well as receive. This serves as a preventive measure, irrespecitive of your program code, to help avert misuse of your program.
