As I previously discussed, one approach to scaling Livelink is to examine the URI of each transaction and and route the transaction to the server (or farm of servers) specifically setup to deal with that transaction. For instance, and speaking generally, Liveink has two very different APIs usually referred to as LAPI and WAPI.

LAPI, or the Livelink Application Programming Interface, provides an object-level interface --- that is, it provides features and functions that (for the most part) work on a single object within Livelink and produce results that are expected to be processed further in some way. The Enterprise Library Services uses LAPI to access Livelink functions and the client-side desktop integration Livelink Explorer also uses LAPI for it's primary features.

WAPI, or the Web API, provides both the ability to work with container objects along with what they contain but it also necessarily provides rendering services (to display the multitude of objects). This means that transaction costs are not only orders of magnitude longer than LAPI transactions, but they are also very unpredictable because it is, in general, not possible to know how many objects will be used to create the returned content with any WAPI transaction. This is exactly the opposite of LAPI transactions that will only vary in time based upon available resources and not upon the content itself.

So, where there are two or more competing applications on a single Livelink deployment and at least one of them is LAPI based and at least one WAPI based, there is a natural deployment option available that sees a LAPI server (with many / most modules disabled) and a WAPI server (with a different set of modules disabled and enabled). This would allow for the LAPI-based applications to scale and perform independently from the WAPI-based applications and more clearly identifies the resource foot print for a Livelink application (a point of particular interest to those IT departments practicing charge-back).