Best Practice 13 - Separate servers for different business processes
Best Practice 14 - Controlling Event Process Size and deploying Components on different nodes

Best Practice 13 - Separate servers for different business processes

As discussed in previous sections, a business process consists of one or more event processes. An important best practice is to run each Business Process on a separate "server instance" of an ESB Server. For instance, if there is a need to run two business processes on a single machine using the Fiorano ESB™, it is best to run two instances of the peer server, one dedicated for running event processes of first business process and other peer server instance for running second business process flows. This helps you manage individual business process without impacting other business processes. The practical benefit here is that if a particular peer server is shut down, only a single business process (typically running in production) is impacted. So, although there is no restriction on running multiple business processes (each composed of several event processes) on a single peer server, it is wise to use separate peers fore each separate business process.

It must be noted that while the form of separation described above is easily achieved using the Fiorano ESB™, it is difficult to achieve using many other ESB, including all that are based on BPEL technology. BPEL Servers are inherently centralized, with a hub-and-spoke architecture. Each business process deployed on the BPEL server further loads the hub, and while it is possible to add a new hub to the implementation, this is typically both difficult and extremely expensive in both hardware and software costs.

With Fiorano, you can run as many peer servers as you need on a single machine, as long as there is free CPU and Physical RAM, allowing you to seamlessly scale your implementation as demand grows with low incremental costs.

Best Practice 14 - Controlling Event Process Size and deploying Components on different nodes

An event process consists of one or more components that combine to create a business process; The Fiorano ESB™ peer-to-peer deployment architecture allows the components to be deployed on any available peer server across the network.

The precise deployment architecture for each solution needs to be determined experimentally. The simplest organization is to run all components of an event-process on a single peer server (i.e., in "hub-and-spoke" fashion) however, as the number of components increase, the following approaches are recommended:

Create multiple smaller event processes rather than a single, large event-process; a good rule of thumb is to limit the number of component instances per process to about 12.

• Run service components on different peers (installed on different machines over the network). The Fiorano ESB™ allows you to redeploy components dynamically at the click of a button, so you can experiment with running different components on different machines. This becomes particularly important when you have memory-heavy processes (such as large XML transformations), some of which can bring down an entire machine if there are too many concurrent instances. In such cases, it is always better to run different components on different machines to spread the load and ease memory utilization.