Active Server Pages Architecture

Transcription

1 Active Server Pages Architecture Li Yi South Bank University Contents 1. Introduction Host-based databases Client/server databases Web databases Active Server Pages ASP Components ADO and Database The steps of executing a query ASP Attributes References:

2 1. Introduction The development of databases always comes with the newer and better hardware and the demand for applications that match the new hardware. In the past 20 years, we have seen the development of databases not only in DBMS, but also in the evolution of database connectivity, which is from centralised computing to Client/Server computing. These client/server structure databases have a great impact to the use of databases. 1.1 Host-based databases The host-based databases are performed on one computer system with attached unintelligent, "dumb," terminals. A limited number of users can only connect to the databases running on the monolithic mainframe through the dumb monitors. There is no friendly interface at all for the users. When the users want to do queries, they must know schema of the databases clearly. What they have typed in will send to the mainframe without any processing. The application of databases will do everything. As a result, the users of the databases will be limited because each user occupies resource of the mainframe independently, even worse the mainframe will be easily overloaded because it will do everything from any trivial things to complicated businesses queries. The performance of the databases will be very poor when the users climbs up to a certain number. 1.2 Client/server databases When the number of users accessing a database grows too high or when too many features are integrated into the database, it is increasingly possible that the centralising database model fails. And with the proliferation of low-cost hardware, especially the advent of cheap PCs, client/server databases have gained popularity in the recent years. 2

3 Client/server has revolutionised the way of designing and building databases applications. It splits the processing load between clients and servers to get the best of both worlds. A database application is two-tier or three-tier based on the separation of the application logic from the Graphic User Interface (GUI) and the database. In a two-tier client/server database, the application logic is buried either inside GUI on the client (fat client) or within the database on the server (fat server) or both. A user runs a GUI on the client, and then sends queries over a network to a database server. The database server processes the request and returns a result. Simplicity is a good feature of two-tier databases, the two-tier databases are easier to develop than the three-tier or N-tier for small databases. But the databases do not scale well. Many SQL statements are sent over the network and selected data must be downloaded for analysis on the client. When new and more stringent requirements must be introduced into databases, two-tier databases become exponentially harder to develop and normally failed. Three-tier was designed to meet this new challenge. In a three-tier or N-tier (more than three tiers) client/server database, the application logic (or process) lives in the middle-tier. Instead of interacting with the database server directly, the client calls business logic on the server. The business logic then accesses the database on the client's behalf. Only service requests and responses are sent between the client and server, so it performs much well than two-tier. It also provides better security by not exposing the database schema to the client and by enabling more fine-grained authorisation on the server. 1.3 Web databases Web technology is a very special case in client/server computing world. Almost every database vendor is rushing to support this technology at the moment. There are two reasons to explain this, one is that enterprise web servers need powerful databases to support, and the other reason is that 3

4 databases need to be extended their services to the biggest wide range group, web group. The typical web databases are three-tier or N-tier. The users run standard browsers on the client side and the requests are transferred over the Internet to HTTP servers. The HTTP servers then interact with database servers and change the result into HTML files to send back to the browsers. Because HTTP is a stateless connection protocol, web databases need find a way to "remember" each user's operations. They also should have capability of handling with enormous users concurrently. If the web databases support Java, or ODBC/JDBC, they are platform independent because they can connect with different web servers or the Internet directly. It does not need to care about server platform, client platform and network protocol. Performance is a big problem of web databases. Users concern the response time of the databases and the web masters concern the throughput. Optimisation is always used at web server. When a web server receives a service request from a client, it first looks up a result in its cache to see if it is there already. If it does, the result will send back to the client directly without connecting to a database server. If it can not find the result in the cache, it will connect to the database server and fetch the result. The result will normally stored in the server cache and send back to the client. When there are more than one user's request coming into the web server, a queue will be built on web server and optimisation will make them use the server resource reasonably. Web databases can be two-tie, three-tie or N-tie. The two-tie web databases are the simplest to develop and may gain some good performance from this simple structure. However, they are lack of flexibility to deal with other web things and normally they are vendor dependence. The three-tie or N-tie web databases are powerful and flexible. But the middle tie may add the overhead because the databases are not connected with the Internet directly. 4

5 2. Active Server Pages Active Server Pages (ASP) is an Internet Server Application Programming Interface (ISAPI) extension which builds on top of the ISAPI infrastructure to provide a server-side application framework, making it even easier to build dynamic Web applications. ISAPI is an alternative approach to Common Gateway Interface (CGI) and is adopted by Internet Information Server (IIS) because each CGI invocation of process is very resource intensive and a busy Web server could have severe performance problems. If web technologies are used to deal with database via HTTP, then the data and its state need to be kept track of, as it flies around the world. ASP is an excellent tool to help developers do that on the Windows NT world. ASP is supplied with ActiveX Data Objects (ADO) that provides a high performance interface to databases that are Open Database Connectivity (ODBC) or OLE DB compliant. Fig. 1 shows the general structure of how ASP to connect the databases. Server: Windows NT Internet Information Server Client CGI Scripts Browser Internet WWW ASP ADO ActiveX ODBC SQL Server Or Oracle MTS HTML files Fig. 1 The connectivity of ASP with the database on the web 5

6 *ADO is a high-level interface, which is a wrapper around OLE DB. OLE DB is a COMbased, low-level programming interface that provides access to data from all parts of an organisation (relational, access, file). * If there is a native OLE DB provider for the database, it does not have to go through ODBC - the extra layer of processing. 2.1 ASP Components Active Server Pages allows the developer to include VBScript or JScript code in the HTML pages, which is executed on the server. ASP has its own object model, which is exposed for the above scripting languages. Its built-in objects give the way to integrate code with the requests sent from the browser, and the web pages, or responses, sent back from the server. There are six built-in objects provided by the Active Server Pages core engine. These objects are Application, Session, Response, Request and ObjectContext. They only relate to each other logically, not in a hierarchy object models. The diagram below shows how these objects fit together. Request Server Object Client Response Server Application ObjectContext Session Fig. 2 The built-in objects of ASP Application and Session objects The Application object represents an entire Active Server Pages application. This object is used to share information among all users of a given application. A Session object is maintained for each user who requests a page. Variables stored in the Session object are not discarded when the user jumps between 6

7 pages in the application; instead, these variables persist for the entire time the user is accessing pages in the application. Request and Responses objects To be able to manage the way HTTP communications work, Active Server Pages use a Request object to store the details of the browser, the request itself and a whole host of other information. A Response object stores all the information required for the server's response to the client and provides methods and properties that can be used to create and modify what is returned back to the client. ObjectContext objects The ObjectContext object is used by Microsoft Transaction Server (MTS) initiated to commit or abort transactions. These objects cover normal web server functions. But when a client request needs to query a database, ADO will be needed. 2.2 ADO and Database To develop a dynamic web site, web pages is needed to link with a database of some kind. (It is not that kind of static pages translated from databases.) The traditional way to do that is through Common Gateway Interface (CGI) or Internet Server Application Programming Interface (ISAPI) directly. An easier way is provided by ASP, which is supplied with a component called the Database Access Component. The component is a whole hierarchy of objectscollectively known as the ActiveX Data Objects (ADO), which is the 'missing link' between web pages and almost any kind of stored data. ADO is powerful enough to achieve excellent results with a minimum amount of work. It consists of just four objects and two collections. They are Connection, Recordset, and Error object; Fields, and Parameters collection. The relationship between them is as follows: 7

8 Connection Command Parameters Parameter Recordset Fields Errors Error Fig. 3 ADO objects The object model is like a hierarchy structure, but not absolutely. One command can be executed by different ways with different objects. The following is a briefly introduction all of the objects and collections shown in the figure. The Connection Object The Connection object represents the link to the data source. It can directly execute statements against the data source, manage transactions. The Command Object The Command object is a query that can be issued against the data source. It provides a means to access and modify data. It can be executed directly against the data source, or it can be used in conjunction with a Recordset object to retrieve data. The Parameters Collection The Parameters collection is a dependency of the Command object and can be used in conjunction with a parameterised query (such as a SQL statement) or stored procedure. Each of the query's (or procedure's) parameters is represented by a Parameter object. The Recordset Object 8

9 The Recordset object is the most intricate of the ADO objects. It supports features such as data paging, disconnected recordsets, filtering, sorting, and storing multiple data sets in a single Recordset object. The Fields Collection The Fields collection exists within the Recordset object, and represents a list of fields (the columns of the recordset). The Errors Object The Errors collection consists of individual Error objects - an Error object is created when an error occurs while accessing data. ADO provides the following main features to run the databases. Connection Before we can access any part of a database, we need to establish a connection to it. A predefined link between the consumer and the data provider can be built by creating an instance of the Connection object, and placing information in its properties. The default ConnectionTimeOut is 15 seconds. Closing the Connection The resources that were being used to support the connection on the serverside are released when a connection is closed. But the object can only be removed from the memory by setting it to Nothing.. Connection Pooling When a connection is closed, it is placed in the connection pool and waits to be reused by any others. The connection itself is only closed if it is not reused within a certain period time. Otherwise it is reused exactly the same as the cached connection. This process saves overhead by reducing the number of times we need to physically go through the connection process because opening and closing connections can be resource-hungry for Web server. Certainly, one can cancel the usage of connection pooling. 9

10 Cursor types, Cursor locations and Lock types A cursor is a pointer to a record in a database or recordset. To get good performance from the concurrent environment, the users need to define these three parameters carefully... Filtering The Filter property of the Recordset object can reduce the number of records that users can see in a recordset based upon their filter criteria. All the information is still there in the recordset - it is just hidden from view until the users clear the filter. By applying the filter, the users only get a subset of all the rows. Paging This is a good way to look at data one 'page' at a time. It would not take any custom programming to implement this. Indexing Indexing will reduce processing time when performing searching for a record and sorting a recordset. But the index itself resides in the client-side cursor that ADO provides. That means it is not indexing the database itself, it is indexing the Recordset object. Execute SQL It is important to define a right execute method for executing SQL code against the data provider. For example, if the adexecutenorecords is not defined in the execution of a SQL statement which does not need to return any record, ADO will generate a recordset of no records, which takes up extra memory and time and is essentially a waste of resources. Stored procedures To use a stored procedure within a database can get much better performance than to running a dynamic query because the stored procedure is already 10

11 compiled on the server and a dynamic query must be syntax-checked and compiled before it is executed. Transactions ADO has a number of methods and properties to support transactions. Disconnected Recordset ADO gives us disconnected and remote-able recordsets, which in turn allows for better functionality in the stateless environment of the WWW. A disconnected recordset is a standard ADO recordset without an associated connection to a database. If the web server-side code opens a recordset and disconnects it from the database server from within that server-side script, the web server is playing the role of 'client' to the database server. The client only receives web pages that are generated on the web server, not the actual recordset. 2.3 The steps in executing a query The following are steps to execute a very basic SQL command. 1. The web server starts an application to provide services for querying the database. Application object is started. All users can share variables at this application level. 2. A user uses a browser to visit a web page that contains a SQL query service. The user then inputs some data by customising the query and submits it by "Get" or "Post" method to the server through HTTP protocol. 3. The web server then may create a session for the user to remember the "client" when the user gives a query next time. 4. The query is interpreted and the cache is checked to see if the query can be completed on site. If yes, the web server produces a dynamic result web page to send back to the user. 5. If no, the web server connects to the database server. Before doing that, it checks if the wanted connection is already existed in the Connection Pool. 11

12 If yes, it will use that to connect to the database server. If no, it will create a new connection. 6. After setting up the connection, the Command object will tell the database server what should be done. This command goes through ODBC or OLE DB and is changed to a language that the database can understand. 7. The Recordset object will get the result and then manipulate it to produce the web page. 8. When there is no need to interact with the database server, the connection to the database will be closed and the connection will be thrown in the connection pool. 9. The resulting web page is sent back to the user, and the data fetched from the database server will be left in the cache. 3 ASP Attributes Performance ASP is a script language, which means the web server needs to read each line of the ASP file and then run it. Microsoft Transaction Server (MTS) can be used to improve the performance of ASP. MTS is viewed as an object broker and uses COM to map client applications to services resident in software components (objects). It is designed to reduce the time and complexity in the development of N-tier applications by supplying much of the infrastructure to provide a robust, scalable, high performance and distributed architecture. Portability ASP is originally designed to run on Windows environment. However, Chili!Soft Inc. ( have implemented an ASP scripting engine for many non-microsoft Web Servers and they claim that this is functionally equivalent to the Microsoft implementation. This means that ASP does not force vendor lock-in and your Web applications can now be freely ported to other platforms (like Unix) without code change. Powerful 12

13 ASP can not only run some scripts and connect different databases through ODBC, but also do other things through ActiveX server components. Scalability Future versions of MTS will work with the Cluster Server technologies to provide dynamic load balancing, scalability and high availability. Learning curve It is easy to learn because it is just a script language and it uses Visual Basic syntax. References: Scott M. Lewandowski (1998) "Frameworks for Component-Based Client/Server Computing", ACM Computing Surveys, Vol. 30, No. 1, March 1998, pp