While some interesting business solutions can be built without it, the true workhorse behind the Open Text ECM Suite is the Content Server that will forever be burned into my brain as the Livelink Enterprise Server, or simply Livelink. Watching Open Text play with brands and branding has been an interesting exercise but I'll not go into that here, rather for this particular post, whether I say Livelink or LES, I am referring to what is currently branded as Content Server. Oh, and while I'm at it, when I say "Livelink server", unless I explicitly say otherwise, I am speaking of a single llserver[.exe] process and all threads associated with it not about a piece of hardware.

I say it is a workhorse and I mean it; virtually all business logic and governance activities (access control, retention management, user management, etc) are performed by Livelink servers. It is a Turing Machine in that there is virtually nothing that it cannot be programmed to do ... it is, in fact, a running interpreter of a computer language called Oscript. Now Open Text has taken a lot of public abuse from it's competitors (many of which are now part of the Open Text family!) regarding Oscript but the truth of the matter is that while it is proprietary and essentially a single-use language (neither of which are good things for consumers of their products), it is also incredibly powerful and, frankly, it is Open Text's problem that Oscript is single-use not, for the most part, Livelink customers and users.

I've always had a schizophrenic viewpoint over Oscript because as an IT expert and manager, proprietary is bad ... virtually any amount of money IT puts into a proprietary solution will not be recoverable except (hopefully) by achieving the expected ROI. In general, proprietary / single-use code costs more over the long term. That being said, Oscript has been solving problems that elude even many high-use languages of today (like PHP-based solutions). It has proven to be irreplaceable so far and, I suspect, the amount of continual development of Oscript modules just make it less and less likely that it will be replaced --- abandoned for another next-generation platform perhaps but Livelink itself will always rely on Oscript for at it's core that is all Livelink is, an interpreter of Oscript.

Actually, it isn't really Oscript that makes Livelink feel like outdated technology, it is the monolithic approach of llserver and the 'one-size-fits-all' deployment strategies that still exist within Open Text's core departments. While it is completely understandable that a Customer Support department does not like to go outside of normal deployment boundaries, it does mean that the overall cost of running large Livelink sites increases. What is interesting, however, is that there is nothing about Livelink itself that demands this, that software is quite capable of offering choices.

Each Livelink Server is Independent from all Others

This is one of the juicy little secrets (that isn't really secret at all but) that few deployments really take full advantage of. While it is common place to use multiple Livelink servers both Vertically Scaled and Horizontally Scaled, in virtually all cases the Livelink servers are all identically setup and configured (save for the obvious port allocations). But there really is no particular functional requirement to do so, as long as there are no code or DB schema conflicts then Livelink will happily function with radically different code sets.

To be more clear, from a Livelink server perspective, it is completely possible to run two distinct servers with entirely different Oscript modules enabled safely hitting the same database tables. I should point out that such an approach has value only where there are multiple, distinct Livelink applications and each wishes to have control over their resources but still desire the content of the applications be shared. In most situations the added cost of design and administration of treating them separately outweighs the benefits and a deployment of a farm of identically configured Livelink servers is easy.

Still, in today's virtual server world where memory footprint again starts to matter, it might make sense to look at how you use Livelink and see if you can slice off some of it and dedicate resources to it. The payoff might be an overall decrease of resource use and increase of end user happiness. There are two different but not necessarily orthogonal approaches: Application Layer URI-based load-balancing; and, IP-based load-balancing. I'll discuss each separately next.