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, message transfers are encrypted using SSL (port 443), and the ISB back-end services run under secure middle tier identities and do not impersonate the caller identity.

When a program instance sends a message, it is queued in a local datastore, 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.

The API provides additional reliability and efficiency for file transfers by enabling chunking. For example, let’s say you are transferring a 100MB file, and after transmitting 70MBs you lose your Internet connection… when the connection is re-established, it picks up from where it left off. This is especially important with wireless connectivity becoming the norm.

The API uses port 443 for sending and receiving data with the ISB. No special holes need to be opened in your firewall or those of your remote offices, business partners, or customers.

You are not constrained to any specific formatting. The contents of your message can be sent as XML, MIME, plain text, a proprietary encoding, or even encrypted cipher text.

Yes. A message can have zero to many associated attachments that get sent along with the message. File attachments can be identified as paths to files or passed as binary resources.

Yes. When registering a program to the ISB, a developer can choose how many instances of their program are allowed to be activated. This setting can be used to control the pace of deployment, or used as a security measure if there are a specific number of known users. This setting, like all settings in Linxter, can be updated at anytime.

Channels are created only after a communication channel request is sent and approved. When registering a program to the Linxter ISB, you specify how you want communication channel requests handled by instances of your program. You can have channel requests automatically accepted or require one of two types of approval. For more details, click here.

Yes. When registering a program to the ISB, you have two options. You can allow instances of your program to receive channel requests either from any program, or only from programs you whitelist.

When registering a program to the ISB, a developer can choose how long a message is allowed to live in an outbound queue on the ISB if it is not picked up. 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. This is especially important for machine-to-machine transactions, or time-sensitive data in which only the most recent data is needed.