With Linxter, one method call does a lot. Under the hood, CreateMessage() and CreateMessages() take care of a lot of complexities.
To get a better idea of how much communication plumbing Linxter takes care of for you, take a walk with us through the life of a message…
The CreateMessage() method call consists of 8 arguments, 7 of which are optional:
- Receiver ID – This is the program instance ID (the unique identifier of the program instance) that the message is being sent to (you can use multiple Receiver IDs to send the message to multiple program instances at the same time). Optionally, if this argument is null, a broadcast message is sent to every program instance that the sending program instance has a communication channel with. Note: The API maintains an up-to-date list of Receiver IDs that your program instance has communication channels with, as well as other related data. This data is available through several simple property calls.
- Activity ID – This identifier is Required. Each program registered to the ISB is assigned an ActivityID, which must be included in any message sent by instances of your program. This ID should be kept secret to protect your account.
- Body – This is the main content of the message. You are not constrained to any specific formatting. The content can be XML, MIME, plain text, a proprietary encoding, or even encrypted cipher text. The Body can be up to 1MB in size.
- File Attachments – Each message can have zero to many attachments, either as attachment paths to files or as binary resources.
- Message Tracking (Non-repudiation) – If enabled, your program instance will receive a notification of the date/time the message was picked-up by the receiving program instance(s).
- Priority –If used, provides support for message prioritization within queues. You can give messages a priority ranking, changing their sending order within their queue.
- SendViaSecondaryQueue – The secondary outbound queue runs on its own thread, and can send concurrently with the primary outbound queue. You can use the seconary 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.
- Tags – Optional labels you can add to the message. They can be used to represent the content of the message envelope, the use or operation the message is intended for, or for any other purpose.
When the CreateMessage() method call is made, the message is placed in the API’s encrypted managed queue, and then security and validation checks are performed. Neither the API nor the Internet Service Bus (ISB) reviews the content of the message Body or Attachments, except for determining size.
After the security and validation checks, the local encrypted managed API queue then sends the message…
… or messages, either immediately or based on a schedule.
Scheduled sending and receiving are automatically enabled when instances of your program are running. 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. All of the timing code for the scheduled sending and receiving is taken care of for you within the SDK. Sending and receving 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.
Note: In your code, you can also send and receive on-demand using the SendNow() and ReceiveNow() method calls.
Now, the API connects to the ISB. All of the ISB service points are load-balanced and geographically redundant. If your program is trying to send messages but is experiencing a temporary loss of Internet connectivity, then the API automatically enters into a retry mode and connects once the issue is resolved.
The API connects to the ISB … the API authenticates itself, and commences sending one or more messages.
All messages are encrypted using X.509 certificates. This provides for end-to-end security, regardless of the number of intermediaries involved in transferring the message and regardless of whether or not the transport is secure.
With assured information delivery, a core feature of Linxter, even if the sending program instance loses its network connection during message transmission, or if another failure interrupts the process, the transaction resumes with the message intact whenever the issue is resolved.
Another reliability and efficiency feature built into Linxter is chunking. For example, let’s say you are sending a message with a 100MB file attachment, and after transmitting 70MBs, the sending program loses its Internet connection. When the connection is re-established, the process picks up from where it left off. Reliability features like this are especially important with wireless (and its frequent interruptions in connectivity) becoming the norm.
The ISB, upon verified receipt of a message, performs security and validation inspections. Among the steps, the ISB verifies that communication channels between the sending program instance and the receiving program instances exist. Once verified, messages are placed in their assigned outbound queues, where they wait to be picked up by their receiving program instances. The outbound queues are load balanced as well as geographically redundant.
For the program instances receiving the messages, the same security and reliability features apply.