Load Balancing with Enterprise Adapters By Shyam Narain

---

About webMethods and Enterprise Integrations

Enterprise-Wide Integration is delivered by webMethods using the webMethods Platform. The platform roughly consists of two parts:

1. The hub -- the webMethods Broker(s)
2. The clients -- the webMethods adapters connected to the Broker and to an application

A client's primary function is to translate messages from the hub to a format that the resource understands. In short, the client receives data sent from the hub and executes some logic on it. Of course, this is more a complex process than is described here, but let's keep the picture clear.

The hub is the beating heart. It sends messages to and receives messages from clients and decides which clients get which messages depending on rules defined within Client Groups. Each client a member of a Client Group and connects to the Broker using Broker Clients.

---

A Sample Integration

For purposes of this webMethods Ezine article, let's say we're Company X and we are integrating our systems using the Enterprise Broker.

Our company runs an ERP with a large, back-end database on Server 1. On Server 2, we host the back-end database of an internal Web portal.

Our architecture will feature the following:

• On Server 1: The webMethods Enterprise Server and an ERP adapter
• On Server 2: A database adapter to connect to our database instance.

---

Using Load Balancing

There are several reasons to load-balance. Most notably, they are:

• Performance concerns
• Fail-over protection

A performance issue example can be demonstrated within the above integration. Let's say that end-user activity on the Web portal spikes and flurry of queries are made to the database. These queries cause certain database triggers to fire and, suddenly, documents are lining up in the Database Adapter queue, crying to be freed. (As the documents are queueing, of course, our end-users are just left to wait...)

Failover is much simpler. Let's assume that during the peak of traffic described above, the Database Adapter gives up and goes down completely and all of the documents are lost forever. What to do now?

To avoid this scenario, use Substitution. Substitution says that if a particular adapter is unavailable for use, another adapter should pick up the work.

---

How Substitution Works

The magic of Substitution rests in the "Shared State" option. Shared State means that multiple clients on multiple host machines can publish or subscribe to documents in parallel. The Shared State attribute is configurable, but can't be selected when using the Adapter Configuration Tool to build a new client of the Hub.

It should be noted that the clients handle documents on a first-come, first-served basis.

In the performance issue discussed above -- where the document queueing generates a bottleneck -- the Shared State feature makes the transaction from the Database Adapter to the Broker much quicker. Instead of one adapter working its way through the queue, two or more identical adapters are sharing the traffic.

If one of the adapters crash, Shared States becomes a cheap failover system. When one adapter fails, the adapter(s) that were previously serving as a load-balancing adapters are now serving as the backup adapters. Whether run from the same server as the failed adapter or from another server entirely, State Sharing is built-in backup.

In the Adapter Configuration Tool it's also possible to configure the amount of "sessions" created by the adapter. My personal experience shows that State Sharing improves performance more than increasing the amount of sessions available to an adapter.

---

Shared State -- Using the Old School API Technique

If you are using the API to connect to the Broker, this is the way to implement shared State:

• Make a new BrokerConnectionDescriptor and set the state sharing as true
• Make a BrokerClient, pass it a clientID and the new descriptor

Note: At startup, be sure that the client is aware that other instances may be actively running. You don't want the client to perform operations that can affect the shared client state, such as removing subscriptions.

---

Shared State -- Editing the Adapters.cfg

Okay, first of all, altering any form of the adapters.cfg without knowing what you are doing is something that webMethods Support won't appreciate. Therefore, BACKUP this file before working on it -- it's a simple operation and it can save you from "accidents".

Time to take a look at the adapters.cfg file.

adapters.cfg has a lot of lines in there and they weren't made for fun, so let's leave them alone. We're only looking for the sharedEventOrdering property, which must be set to "None". If you have intelligent adapters installed, make sure that "shared true" is added/edited between the accolades.

Now, save this file and start up the Adapter Configuration tool.

Using Adapter Configuration, create the exact same adapter with the exact same name, the exact same Client Group and, of course, connecting to the exact same Broker. It doesn't matter if the adapters are running on the same host.

To double-check your work, launch your Manager tool and find your clients. Double-click on them and in the "Sessions" tab, look for "State Sharing is Enabled".

---

[1]  

Go Deeper on the Subject: The wMUsers Discussion Forums