The server installs Microsoft IIS (Internet Information Server) on your server and you have the advantage of ASP (Active Server Pages), and ASP uses ActiveX components to do all kinds of work for your network applications. Although you can use many ActiveX components in HTML and in IIS with ASP pages, server-side components are not common components running on a single server. It does not tell you any information about a product server that needs special care at run time. You won't be able to do anything to change its impact on server performance, security, and stability. Improper selection of server-side components may cause problems, including a noticeable drop in speed, security vulnerabilities, or other worse problems.
The client's components are executed on the user's computer. The client component includes the vast majority of popular components we now know: Tag controls, text boxes, command buttons, lattices, and so on. These components can be included in the client-side HTML code through <OBJECT> tags and/or HTML object syntax.
Most of the useful client components provide a specific kind of user interface. Remember that using a client component means that the real component has been uploaded to the client computer. The common practice is to download the components to the client computer. Of course, users have to wait for the download process, and the client computer must be configured to allow downloads.
In contrast to this, server-side components are executed on the server computer. The server-side component also does some work for the user, but it runs on the server. You have to recognize the difference and code accordingly. The server-side component encapsulates some logic or functionality for your entire application.
When a user uses an application, he will not actually see the server-side components. Most of these components can be contained by the <OBJECT> identity in the ASP script that needs to use the component. You can also include server-side components through the server's CreateObject syntax.
Build a robust component
Not many good materials are used to create robust components. But I'm here to recommend seven key steps that can help you create stable and secure server-side components that can be scaled gracefully and maintain performance. When creating a server-side network application, you need to place stability, security, and performance at the forefront of your mind.
Server-side components should not have a GUI (graphical user interface). Because the server-side component is running on the server, users of the network application are not able to see any conversations that might pop up. Your component needs to be able to communicate with scripts and other components without having to communicate with the user. Avoid all message boxes and any other graphical user interface units. You must develop code that returns results to communicate with state and other module information. If something goes wrong, do not throw an error message or use a message box to return a state variable. The last thing you need to do is lock the busy server waiting for the OK button to be pressed.
Server-side components must not be passed references or passed references to objects. It is common practice to pass control as a parameter to other processes or components. This includes references to other objects, such as recordsets. However, passing references to components on a network can cause a noticeable slowdown, making a busy server more sluggish and network applications performing more slowly in response to user needs.
Server-side components should contain as few methods and attributes as possible. Every call to a method or property requires a lot of processing. As a result, a well-written server-side component should have almost no obvious methods and attributes. The methods and properties that the component contains can bring more parameters. The fewer calls with many parameters, the better performance, especially if your network applications need to support many users. This technique is contrary to the experience of many developers. Minimizing the use of calls with many parameters can also create additional problems, making coding and debugging more difficult, but improving speed is commensurate with the effort.
Server-side components must implement the appropriate threading model. The use of single-threaded components may cause the server to limit a thread's session, which can lead to a noticeable drop in speed. You should choose the Room model threading option for VB and try to avoid single-threaded components. However, VB cannot create components that you can find in Visual C + + that have a thread-selection range. This also shows that VB is not a very suitable for this work development language.
Server-side components should use early binding. This is particularly important if your server application is to be expanded. Early-bound objects can save a lot of execution time by having reference resolution at compile time.
Server-side components cannot be used in declarations of application or session scopes. Notice how your control is scoped. Scopes describe how to create an instance of a component that is critical to the success of your service-side components. As discussed last month, there are three levels of scope: page-level, session-level, and application-level. Page-level scope objects can be created using the HTML and ASP scripting code of the page itself. The best performance of the page-level scope component can be obtained by using the room threads. For application-level and session-level scope components, it can be obtained by using the two-threading model of the ATL component. The threading model combined with the scope also affects the security performance of the server. For example, a room thread component that leverages an application-level scope runs in the system security environment, but not the current user's security environment. This may be a problem for those who are safe-minded.
For speed, the server-side component should be a component in the process, and for stability, it should be an out-of-process component. There are two ways to create a COM (OLE) server--both in-process and out-of-process. In VB, you use EXE or DLL extension to compile the server. An OLE server with a DLL extension is called a process server, and an EXE extension is called an out-of-process server. Out-of-process means that the component runs as a separate process and does not share the address space with the application that invoked it. Running Out-of-process components can cause performance degradation because Windows has to move data back and forth between two or more applications. A process means that the component runs in the address space of the application that invoked it. Communication between processes eliminates the need for intermediate objects, which makes performance significantly higher. The downside of a component in a process is that if the component fails, the application calling it will fail.
Server-side components make it possible to create best-of-breed solutions. With IIS, you may have to use MTS, and you can create high-performance, scalable network applications based on the strong processing power of Windows NT.
