ASP Development Guidelines

The application server is, or will eventually be used by, the WEB server, which is typically the IIS computer running the ASP page. ASP is the only client of your object. It brings special thread and security considerations.

Although many WEB sites using ASP do not use components at all, in this article it is assumed that the ASP is a bridge between Internet clients and components. The following asp/server01242000.asp ">asp component Guidelines (English) provides

partitioning services between ASP and Components

ASP is most commonly used to create HTML or XML files on the server for use by clients, so we mainly discuss this usage scenario. This leads to a common problem, if ASP pages are on the server, are they part of the business layer? In the component world, the answer is usually. Although the ASP does run on the server and may be in the same space as the application server, this does not make it part of the business logic.

With the development of user-interface tools or with more business-enabled business scenarios, there is a huge payoff in this clear distinction.

In this context, let's take a look at some of the most important business and presentation layer Partitioning guidelines:

• Separates UI code from business logic. This includes writing code that is coupled to the UI, such as using the MTS object of an ASP's internal component to separate it from the business logic code, as in a different DLL.

• Separates the transaction from the ASP page. Transaction ASPs are very good in some cases, but components and multi-tier applications can change that. Components should not rely on the client layer to manage their transactional and business logic semantics.

• The presentation component (the component that uses the request and response) is placed in the same machine and/or process as the WEB server. If an object that uses an ASP's internal component object is placed on a remote machine, all calls to the internal component will occur as callbacks. The IIS client is called a COM + server, which significantly reduces performance and complicates the security configuration. You can place these adjustment objects in a COM + application marked "library activation."

ASP exists on the server, so ASP pages must conform to resource sharing rules and remember scalability. Please see the details below:

• In sessions, management should try to avoid user-specific state.

• Keep the ASP stateless and allow resource pooling where possible.

Mode of Operation

When evaluating whether a piece of code is a business logic or presentation layer, ask yourself, "If I have to replace my ASP page with a keypad phone application, is the code still useful?" "If the answer is yes, then you can try dividing it into business logic code or user interface helper code."

If the code is not available after the client is changed, or if it is a helper that constructs the user interface, the code belongs to the presentation service layer. It is in an ASP page, or in a component that uses an ASP's internal component. It is not part of the business object component.

Understanding the difference between desktop and ASP clients

ASP is a special client of a component, unlike a traditional single-threaded Win32 application on the desktop. The main differences are summarized as follows.

• Thread Management: ASP is a multithreaded client. This means that you can have a lot of concurrent activities running together, and maybe working on different ASP pages at the same time. This means that the object cannot pretend that it is the only user to monopolize the system. This may be an unexpected reaction, for example, to develop a bad habit of storing objects in an ASP session or application variable.

• Security environment: ASP is performed by Internet Information Services 5.0 in the Web site, with low, medium, and three-level isolation. Even these web sites can have different security settings, allow or deny anonymous access, authenticate customers, and so on. All of these settings produce a large number of scenarios, where different user accounts end up using your object.

• Easy growth: This is not a technical issue, but a by-product of the facilities provided by the WEB application. Traditionally, adding a user base to a desktop application requires careful planning to transfer out to a known number of clients. The ASP has changed the process. After starting and running, the Asp-visual Basic application can be easily opened for use by all employees, all business partners, and all customers on a local or worldwide scale. It can be described in this way-a single e-mail message with a hyperlink can increase the user's base by 10 times times. Is your application ready for this? The only way to learn is to test the Web site for strength, to get the expected value of actual performance. For more information about strength testing, see the "Application Lifecycle" section.

How should Visual Basic objects be used within the ASP? Create and cancel your objects within the page range. That is, make the ASP page as stateless as possible, relying only on session or application variables in a transient state. Do not store objects in session or application variables. This locks the ASP thread to your session and cancels the expected value for all scalability. In other words, the WEB server does not handle more than dozens of users. If you need to store content in a session or application, make it data instead of an object.

There are many other guidelines that can be followed. We recommend that you read the column "Servin ' It Up" written by J. Meier on the MSDN voices. The column includes a wide range of technologies, practices, and techniques to help develop scalable, reliable ASP and component applications.

Reference

Asp#server ">msdn Voices:servin" it Up Column (English)

Seminaronline: Using a custom COM component under ASP (English)

ASP ">MSDN Magazine" do not store references in a VB object in a session or application

All Visual Basic 6.0 components are "unit threads," which means they all run in the STA cell. This means that if an object is created in a thread, all calls to that object must be serviced with the same thread. Many threads (from concurrent WEB site users) Use the same instance of an STA object, which can cause a series of activities that may become bottlenecks in the application.

In addition, storing an STA object created with Server.CreateObject in session scope effectively links the execution thread to the current user, limiting the maximum number of concurrent users for the application to the default 20xN (N = number of processors).

Mode of Operation

If you make objects stateless according to our recommendations, you do not need to store references for client reuse and store them within the scope of the application. Clients will be able to create, use, and cancel their own objects independently. This reduces the need to maintain session-specific objects because they do not preserve session-specific state.

The recommended approach is to make the object stateless, accessing the database or other stores (such as cookies and LDAP) when needed.

If you need to use session or application-scoped data, store the data, rather than the object that processes the data, here. You can create a class that encapsulates the processing of the desired value.

Reference

ASP > Information: Do not store STA objects in sessions or applications (Q243543)

PRB: Storing an STA COM component in a session, locking the session in a single thread (Q243815)

Information: Component Threading Model Overview (Q243544) under ASP (English)

Learn about new content in IIS 5.0

Internet Information Server 5.0 adds a number of new features. These improvements have been written to J.D. Meier's MSDN article: asp/server02282000.asp > follows the ASP in IIS 5.0. The following is an overview of the most important improvements in this article.

• Improved, Outstanding performance

• Server.Transfer and Server.Execute methods

• Centralized error-handling

• Improved Browser Capabilities

• Improved scripting engine

• Regular Expression Analyzer

• Integration with ADO recordset XML functionality

• New security, buffering, isolation, and management features