Best Practice 8 - Scaling by adding more peers/servers to the network
Best Practice 9 - Scaling by distributing load across multiple service instances
Best Practice 10 - Scaling via Transparent Resource Addition
Best Practice 11 - Changing your Processes Dynamically
Best Practice 12 - Parallelizing your Data Flows

This section discusses how composite applications and event-driven business processes deployed on an ESB can be scaled to increase overall throughput and to better utilize distributed system resources across the enterprise service grid.

An ESB can have either a traditional hub-and-spoke architecture or a distributed, peer-to-peer architecture. Hub-and-Spoke systems are easy to administer but difficult to scale, since as processes are added the hub becomes a communication bottleneck. ESB's such as Fiorano, based on a peer-to-peer architecture allow hardware resources scattered across the network to be effectively utilized to balance load and scale the number of processes running concurrently.

Best Practice 8 - Scaling by adding more peers/servers to the network

At the server level, the Fiorano peer-to-peer architecture enables increasing loads to be seamlessly distributed across the network through the dynamic addition of peer servers. Since data-flows between distributed processes are not routed through a central hub, the Fiorano architecture avoids load-related faults that plague most existing integration infrastructure and ESB solutions. The peer-to-peer architecture also allows dynamic load-balancing to be added to running applications.

Best Practice 9 - Scaling by distributing load across multiple service instances

At the service level, the Load-Balancing business service may be used to distribute the messages to multiple services for processing. To enable service-level load balancing on a service, one normally runs multiple instances of the service on different ESB Peers and routes data to the multiple running instances via a Distribution Service, as illustrated in the figure below:

The Distribution Service routes data to its output ports depending upon the relative weights associated with the ports. Load-balancing of Services across different nodes as defined in the foregoing can be set up either by the end-user/administrator or via programmatic APIs.

The load-balancing method described above increases the overall message throughout, since incoming messages are now processed by multiple instances of a service, typically running on different machines (or being processed by separate threads on a single machine). This technique is especially very useful when a particular service is becoming a bottleneck in the entire business flow. However, the drawback is that in general the messages may not be processed in the order in which they arrive, and this lack of ordering the tradeoff for performance with this load-balancing technique. It is possible to use an event-sequencing flow to ensure message ordering, thought this is not as optimal for performance as the general-purpose method outlined above.

Best Practice 10 - Scaling via Transparent Resource Addition

The Fiorano ESB (or any other peer-to-peer ESB) promotes a linear 'build as you grow' model, which allows an enterprise to add software resources in the form of Fiorano ESB Peers at network end-points to absorb additional load on the platform. For instance, if the load on a given set of peers processing data is determined to be too high, new Peers can be added incrementally to the network at runtime, without disrupting existing services and distributed processes. Since Fiorano platform peers reuse existing enterprise hardware, resource addition typically does not involve additional hardware deployments, unless explicitly required.

Best Practice 11 - Changing your Processes Dynamically

As far as possible, it is best not to stop existing production processes to incorporate any changes modifications to the implementation. Applications deployed on an ESB platform that supports a fully asynchronous communication model can be extended and modified dynamically at runtime with the addition or removal of new services and event-flow routes without stopping or disrupting existing processes in any way. Existing services within an application can be individually controlled via start/stop/upgrade/modify semantics, allowing incremental, dynamic, runtime changes to distributed processes. It must be noted that BPEL and other BPM-standards do not support such "on the fly" changes to processes and must always be redeployed after a change, almost always necessitating a bring-down of production processes.

Best Practice 12 - Parallelizing your Data Flows

With dispersed computation and parallel data flow between nodes, distributed ESB architectures such as Fiorano scale naturally and seamlessly with the addition of new peer nodes and Enterprise Services across the network. Information and data flowing between distributed services does not have to pass through a central hub because each Peer incorporates a JMS-compliant messaging server, allowing direct peer-to-peer connections to be set up on-the-fly between any set of peers across the network. This on-demand creation of peer-to-peer data-flow connections is unique to the Fiorano platform and enables linear scalability and performance as new peers are added to the system. Furthermore, since peers can be hosted on existing (already reasonably powerful)hardware at the end-point of the network, enterprises do not have to purchase expensive hardware each time there is an increase in performance requirements.