Features

Linxter cloud messaging uses flat transactions, also known as a two-phase commit process, from end-point to end-point. For example, when a program instance creates a message, it is stored in a local, encrypted queue (written to disk), until the message has been successfully transferred to the ISB. The message is not removed from the queue until it has been verified that is was received intact by the ISB. The same is true in reverse... messages in an outbound queue on the ISB are stored until it has been verified that they were successfully received by the retrieving program instance.

If your program is trying to send or receive messages but is experiencing a temporary loss of Internet connectivity, then the API automatically enters into a retry mode and connects to the ISB once the issue is resolved.

With assured information delivery, a core feature of Linxter, even if your program instance loses its network connection during the sending or receiving of a message, 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 10MB file attachment, and after transmitting 7MBs, the sending program loses its Internet connection. When the connection is re-established, the process picks up from where it left off, rather than starting over again. Reliability features like this are especially important with wireless (and its frequent interruptions in connectivity) becoming the norm.

An additional reliability features is guaranteed-once message delivery, meaning, the recipient endpoint will only receive a sent message once. This might seem trivial, but numerous platforms do not provide this allowing your endpoint to receive the same sent message more than once. Linxter cloud messaging also insures that messages are received in the order they were sent. This system wide feature is known as First In, First Out (FIFO). Again, this might seem trivial, but there are numerous platforms that do not provide this either.

Linxter has security built in at many layers, so that messages are secure from point-to-point. Messages in the API local data store are encrypted, the service calls from the API to the ISB use username token authentication and authorization, and the ISB back-end services run under secure middle tier identities and do not impersonate the caller identity.

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.

Messaging between program instances can only occur if a communication channel (digital contract) exists between them. You can specify what programs are permitted to establish communication channels with instances of your program.

A communication channel is a digital contract that enables and governs message-based data exchange between instances of Linxter enabled programs. Only when a communication channel exists between program instances can messages be processed between them.

Communication channels are created only after a communication channel request is made and accepted/approved. You have the flexibility to send communication channel requests either manually, automatically, or programmatically. You are also given flexibility in deciding how to handle communication channel requests received by instances of your program. When a request is received, it can be automatically accepted, require approval by an Administrator via Web Manager, or require approval via the recipient program instance.

Instances can easily be enabled to fully manage their communication channels. 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. Note: Your Administrators always have the ability to create and override communication channels via Web Manager.

Sending messages is asynchronous and non-blocking to your program. This means that your program can keep doing what it is doing and not worry about getting hung while processing a send or receive operation.

The sender and receiver program instances do not need to be online at the same time (asynchronous delivery). This becomes particularly useful when dealing with intermittent connections, such as unreliable networks, casual users or timed connections. It also means that should the receiver application fail for any reason, the senders can continue unaffected, as the messages they send will simply accumulate on the Internet Service Bus (ISB) for later delivery when the receiver restarts.

Message persistence, part of asynchronous delivery, allows you to specify how long a sent message is allowed to live in an outbound queue on the ISB. Since the data contained in some messages might only be relevant for short periods of time, this feature allows you to keep outdated communications from being received. You can also specify that a message can live for a very extensive period of time. This all depends on the requirements of your program.

Linxter hides complexities of enabling applications to communicate by making a variety of connectivity settings available to you through Web Manager. You customize these settings based on how you want instances of your program to interact with each other and with instances of other programs.

When registering a program to the ISB, a wizard takes you through each available setting. Once completed, instances of your program pull these settings from the ISB when they register themselves.

You can always edit your program settings from Web Manager. Updates are sent to all instances of your program, even if they have already been registered and activated. Web Manager allows you to reconfigure all of your settings on the fly, so you can meet business needs even as they change.

Linxter supports message non-repudiation. A sending program instance can receive a notification of the date/time a sent message was picked up by its recipient. This is useful if additional processing needs to occur based on verification of receipt, as an informational feature for end users of the program, or for information assurance compliance. This can be enabled on a per message basis through an optional argument in the CreateMessage() method call.