Taking Advantage of the BusinessObjects Enterprise Distributed Architecture

This section of the chapter discusses how the BusinessObjects Enterprise Framework and all the services that it provides are most effectively deployed. As mentioned earlier, BusinessObjects Enterprise is designed as an n-tier distributed system for information delivery. This distributed nature gives an organization a great deal of flexibility in how it might want to deploy BusinessObjects Enterprise in its environments. How BusinessObjects Enterprise is deployed will depend on the way in which the system is expected to be used, how many users are expected to be active in the system at any given time, and how many objects are expected to be processed at any given time.

Scaling Up

The term scaling up implies that a software product is able to take full advantage of the physical hardware resources it has access to and ultimately increase its performance as the hardware increases. BusinessObjects Enterprise was designed from its inception to effectively scale up.

All the BusinessObjects Enterprise servers are multithreaded components that are able to scale to take advantage of available physical hardware resources. They have been designed to operate on multiprocessor machines efficiently.

When a system is under high load, even being multithreaded isn't enough. If the load on the servers is high enough, I/O might start to become the limiting factor. BusinessObjects Enterprise deals with this by allowing an organization to configure multiple instances of a server on the same physical piece of hardware. This makes it possible for additional servers to share in the load and remove any I/O bottlenecks. A benefit in doing this is that automatic load balancing kicks in, making the system that much more efficient.

Scaling Out

Building on the scalability in BusinessObjects Enterprise for scaling up, the capability to distribute report processing loads to multiple physical machines is also available. This is beneficial in many ways.

As an example, an organization can scale its systems to very large levels by adding physical servers to the environment when needed. If an organization chooses to license BusinessObjects Enterprise using named or concurrent access licenses, additional hardware resources can be added to the environment as needed without purchasing additional BusinessObjects Enterprise user licenses. If processor licenses are initially purchased, new processor licenses must be purchased when the additional hardware is added. This is why it's important to understand the expected usage of the system as well as project the future growth of the system so that the appropriate license model is chosen.

The second benefit is the capability to assign tasks to certain computers. For example, the Job Server, Page Server, and File Repository Server could be grouped together on the same physical computer. The Page Server and Job Server both connect to databases and both communicate with the File Repository Server. Locating them on the same computer makes sense in many situations.

The next benefit of scaling out with BusinessObjects Enterprise is fault tolerance. BusinessObjects Enterprise provides the capability not only to have multiple instances of the same service running on the same computer, but also allows for those servers to be spread across multiple machines. BusinessObjects Enterprise has automatic fail-over support in each of its servers to complement the automatic load-balancing capabilities. This means that if a server goes offline for any reason, other servers registered to the BusinessObjects Enterprise Framework will automatically pick up the workload without user interruption.

Scaling Across Platform Boundaries

Some deployments of BusinessObjects Enterprise might require a distributed system on different operating systems. BusinessObjects Enterprise makes it possible for an organization to deploy BusinessObjects Enterprise across any of its supported operating system platforms. This provides a way for organizations to decide what deployment scenario best fits their needs, given the hardware available to them. A key benefit to being able to do this is that organizations might want to seamlessly mix functionality available from different operating systems. For example, an organization might require that reports process on Unix but still want the users authenticated using Windows NT accounts.

There might be situations in which it's necessary to have certain servers running on one operating system and the rest of the system running on another. For example, an organization might have the majority of BusinessObjects Enterprise operating on Unix, but want to seamlessly integrate the SQL Server Analysis cubes being used in the OLAP Intelligence reports created by the finance department. These reports can easily be added to the BusinessObjects Enterprise system running on Unix, as long as a WCS is running on Windows so that the OLAP Intelligence reports have access to SQL Server Analysis Services.

Caution

Although a mixed-platform deployment can solve problems, do not put clustered CMSs on different platforms. Because they both work together connected to a single database, and because drivers on platforms differ, database corruption can occur on some platform combinations.