ISB Services

Three of Everything

The ISB services used by the Platform-as-a-Service packages are duplicated in sets of three. This allows for an instance of a service to be brought down for a scheduled restart or maintenance, while two remain up and running.

We employ this practice to mitigate the risk of a second service instance becoming unexpectedly unavailable while the one has been temporarily brought down. If such a circumstance occurs, the third instance is still available.

Private Cloud package users can designate the number of duplicate service sets used by their ISB. They can increase or decrease them as needed.

The Services

The Linxter SDK encapsulates all the details of how to communicate with the Linxter Internet Service Bus (ISB). The ISB is a collection of back-end services, which include:

  • Inbound service handles messages sent by your program instances to other program instances.
  • Outbound service is where program instances retrieve messages that are addressed to them.
  • Object store service handles the transfer of file attachments.
  • Hostname service manages the addresses used by program instances for calling services.
  • Registration service handles program instance registration and re-issue of registration tokens.

The services are designed to be autonomous, interoperable, and scalable. Location transparency is another important aspect, allowing multiple data centers to be set up around the globe, with various kinds of redundancy.

The specific location of the services is not important, and may change over time based on the loads and security needs of the back-end systems. All of the addresses are managed internally by the Linxter SDK so you, as an application developer, do not have to worry about it.

Below is a high-level illustration of the ISB architecture: Linxter Internet Sevice Bus