Off-load your communication headaches.

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.

When a program instance sends a message, it is queued in a local data store, until it has been successfully transferred to the ISB. Messages in an outbound queue on the ISB are stored until they are 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 100MB file attachment, and after transmitting 70MBs, the sending or receiving 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.

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.

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 or as an informational feature for end users of the program. This can be enabled on a per message basis through an optional argument in the CreateMessage() method call.

You can allow an unlimited number of instances of your program to be activated, or put a cap on them. Additionally, you can receive various levels of email alerts whenever a percentage of your limit is reached. Limiting the number of instances you allow can be useful, for example, as an added security measure or to control a product roll-out.

You can change between unlimited and limited instances at anytime, as well as change the entered limit.