Distributed systems

You can also configure a system so its subsystem components are distributed across a set of servers. Each server has a Command or Launcher that runs the corresponding maps.

Data flows across servers between the distributed system components as indicated in the following example of a distributed system. This data flow is possible because maps can directly communicate data across servers when they execute.

There are four basic source and target types: file, database, message, and application. Within these four types, wide ranges of options are available to retrieve data from a remote location and to send data to a remote location, similar to the following scenarios:

• A map source or target can be a file that is in a shared location, allowing multiple servers to have direct access to it.
• Using the application adapter architecture, you can use any connectivity method to retrieve data from a remote location and to send data to a remote location. For example, you can use sockets, remote procedure calls, or directly call a local application that connects indirectly to another server to pass data. Databases and messages within messaging systems can also be accessed remotely.

The primary benefit of a distributed system is that you decide which subsystem components run on specific servers so that you can balance the overall execution load of the system across the servers in your enterprise. The data flow between servers is managed automatically as maps are executed. You do not need a global manager to coordinate this data flow.

You can easily add more servers to a distributed system at a later time. The Integration Flow Designer enables you to rearchitect the distribution of subsystem components across a new set of servers.