For example, you could build an order entry application in which all the business services objects-such as the customer, order, order details, and product objects-are located on the server. The client application could call these objects and have them maintain state from the beginning to the end of each order. This would require you to maintain state on the server, but with only a small number of clients, doing so should not adversely affect server performance. However, in a larger system, maintaining state on the server will significantly slow the server's performance.
One scenario has no performance loss caused by stateful business services components on the server: when one component on a server calls a second component on the same server, it makes no difference in performance if the second component is stateless or stateful. If the two servers share a direct network connection, you can also put the second component on a second server. A common example of this is a Web server, such as Microsoft Internet Information Server (IIS). With IIS, you can use stateless ASP documents to communicate with the client. These stateless ASP documents can use stateful or stateless business services components, such as Visual Basic objects, to build the Web pages. These Visual Basic objects will be on either the Web server or another server directly connected to the Web server. Because the ASP document is stateless and will exist only for a few milliseconds (long enough to perform a service for the client), any object it uses will also exist only for a few milliseconds. The ASP document can be considered the main business services component; the Visual Basic objects are the secondary business services components. The ASP document orchestrates the entire process of performing the service for the client.
Installation considerations
In addition to performance issues, the ease at which business services components can be installed and upgraded on the client computers must also be taken into consideration. Ideally, corporations should be using a set of client computers with a limited number of configurations. For example, let's say a corporation buys only computer models V, VII, and VIII from Northwind Traders, and each of these models has only one standard software package installed. This means that there are only three possible configurations for the client computers. If you created a new business services component, you could test the installation process on one of each of the three computer models used by the corporation. If the component installs properly and none of the software that was originally on the computers is affected by the installation, there should be no problems with installing this businesses services component on all the client computers in the corporation. If you do run into installation problems, you could find the cause of the errors and change your installation techniques to fix them. In this type of controlled client environment, installing and upgrading a component on the client should be fairly easy. In brief, for the most part, the process of installing components onto the client can be greatly simplified by performing extensive testing. The installation of a new system onto a large number of clients (hundreds to thousands) using Microsoft Systems Management Server (SMS) could require up to six months of testing.
On the other hand, if a corporation has a wide range of unknown client computers, you could not use representative test computers to make sure that the new business services components would install properly on all the clients. Upgrading a component on these unknown clients could also result in problems. There are many possible solutions to this problem. For example, Norton Antivirus will check for updates to its virus-checking program at a set interval. When that interval is reached, a component will ask users whether they want to check for any updated components over the Internet. If any updates are found, they are automatically downloaded.
Components can also be installed in typical fashion over the Internet using .CAB files or using products such as SMS that can push components onto the client. Many techniques are available for getting the components onto the client. The major drawback with any technique is the possibility of dynamic link library (DLL) conflicts and a failure of the installation process.
As you can see, there are no standard answers as to the best location for business services components. The decision depends on the system that is being built, the configuration of the clients, the servers that are available, and so forth. Each decision usually requires the balancing of many factors.