New York University

Computer Science Department

Courant Institute of Mathematical Sciences

 

Active Server Pages

 

Course Title: Application Servers                                           Course Number: g22.3033-011

Instructor: Jean-Claude Franchitti                                            Session: 3

 

 

 

In November 1996, Microsoft formally introduced the Active Platform at the Site Builders Conference and the Professional Developers Conference. At those events, the audience saw a picture of the "Active Platform" shown below, that outlined the major parts of Microsoft's vision of the future of Internet development. The two pillars of client-side and server-side scripting share a common tool set and are both based on consistent standards and protocols.

 

 

 

 

The Active Platform was Microsoft's vision of the next generation of distributed computing. It exploits the best of the centralized programming models as well as the best of decentralized programming. The Microsoft vision has profound implications for the Internet (not merely for industrial-strength client/server programming) and for the way that systems are developed and deployed. Microsoft's model creates applications that are logically centralized and physically decentralized. A logically centralized system can be administered from anywhere. Such a system is conceptually simple, and when properly tooled, is easy to manage. Physically decentralized systems can be more efficient, fault tolerant, powerful, and scaleable.

 

The most striking thing about the Active Platform picture is that both sides of the diagram are almost identical, evidently different only to the extent of system services.

 

Scripting

 

Client-side scripting and server-side scripting have different missions in life. Client-side scripts most often add improved user interface and data validation (when HTML forms are used). Server-side scripts, especially in Active Server Pages, are practically unlimited; but they are primarily used to capture business rules and access to data (the second and third tiers in 3-tier client/server programming).

 

The important thing to stress here, however, is that server-side can, if properly implemented, create client-side scripts. One of the most important questions in Internet development is the one that makes you choose between programming to the broadest audience and programming for the richest on-line experience. To the extent that you choose the former, server-side scripting is important for two reasons:

 

·        Server-side scripts can sense the capabilities of requesting client programs.

·        They can be as powerful as you, the designer, want, regardless of how thin the client is.

 

For example, the thinnest client on the Internet is the one that cannot render graphics of any kind. The ALT parameter of the IMG tag in HTML originally was intended to help such clients interpret important parts of the screen that they otherwise couldn't see, by describing the area in words instead of an image. With an Active Server Page, your application can sense when such a browser (for that's what these kinds of programs are-as opposed to Web client programs that have more processing power) is making a request of your Web site. You can then present such graphics-challenged browsers with whole paragraphs, not merely short expressions, to give them as much information as possible, given their inherent limitations.

 

In today's Internet, a major difference between Web clients brands is whether they recognize ActiveX controls or not. Again, the Active Server Page doesn't care one way or the other. If it senses the ability to interpret ActiveX controls, it presents them; otherwise, it includes static images (or text, if necessary).

 

Of far greater importance than these mundane issues is the fact that Active Server Pages promote a new level of processing power into the Web server. It is critical to remember that the Web server was never designed to be an application server. It was designed to deliver HTML. This remains its primary mission, even on the Active Platform, but with Active Server Pages, this design constraint ceases to be a constraint at all.

 

The scripts that are contained in Active Server Pages, especially those driven by Active Server components, bring virtually all the power of traditional client/server programming to the Web server. Indeed, to the extent that Active Server components are utilized, Active Server Pages can do things that even the most sophisticated client/server programs can't.

 

Components

 

Components may be the single most important feature of Active Server Pages. Their importance to ASP is understandable when you step back and see how pervasively Microsoft has embraced components in virtually everything they create. Everything from the Internet Explorer to Windows NT 5.0 has been "componentized" by Microsoft engineers. Components give programmers many advantages, including lower development time and cost, added flexibility, easier maintenance, and most important, easy scaleability.

 

For the ASP development community, on the server-side, server components are either intrinsic to the Active Server or they are user-defined. On the client-side, ActiveX controls provide functionality similar to server components.

 

Active Server Components

 

Active Server Components basically do two things. First, they directly expose operating system services to your Active Server Pages. Second, they encapsulate business rules in a way that is extremely easy to program. Perhaps even more important in the long run, Active Server Components are easy to create. That is, by using programming tools and environments optimized to work with the Active Platform, writing sophisticated server components is no longer the province of the advanced programmer.

 

There is a truism in programming that the best programmers are users. Active Server components will prove that not only to be true but important, as well. In the summer of 1996, it was estimated that the number of lines of Visual Basic code finally exceeded the number of lines of code written in COBOL, the perennial champ. Perhaps the biggest reason Visual Basic is so prolific is that users, not professional programmers, wrote these "extra" lines of code. Active Server component development will bring the same ease of programming to the Internet that Visual Basic brought to creating Windows programs.

 

To get a feel for what server components are and what they do, take a look at a few of those that ship with the Active Server.

 

The Browser Capabilities component is the component that permits an Active Server Page to determine what kind of browser or Web client program is making a request. It makes this determination by looking to the User Agent HTTP header and looking up the identified browser in the browscap.ini file. All of the listed features of the browser are exposed as properties of the Browser Capabilities component.

 

The Browser Capabilities component is a clever piece of code, but it doesn't have anything to do with the operating system. One component that does get closer to the OS is the TextStream component. This component relies on the FileSystem object, which, as the name suggests, accesses low-level file I/O. With this component, opening or creating text files in the directory system is simple and direct. Navigating through the files' contents is equally straightforward.

 

Choosing a Scripting Language

 

Until the advent of the Active Server, programmers spent too much time worrying about infrastructure (e.g., programming Database Management System (DBMS) connections) and not enough time in their core competence (i.e., doing something useful with the recordsets fetched from the DBMS). By bringing the system services closer to the program and abstracting these services into server components, Active Server Pages promises productivity gains absolutely unrivaled in the history of computing.

 

The other feature of Microsoft's vision for Active Server Pages is in one of Microsoft key design goals for ActiveX Data Objects: universal access, not universal storage. This preference to know where everything is instead of collecting everything in one place is the natural extension of the overall mission of Active Server Pages-to keep things logically centralized and physically decentralized.

 

 

 

 


 

 


Active Server Pages introduced a whole new concept to web development - scripting language of your choice. Before ASP came around, the web development tools such as ColdFusion by Allaire required that you know a proprietary scripting language (in the case of ColdFusion it is CFML). On the other hand there was (still is) Perl, which with packages provides access to databases and other functionality that you have come to expect from a web development environment.

 

ASP provides a better way of doing things - it modularizes the web development effort. It gives you the option of choosing your scripting language, something most other web development tools do not offer. While there are many scripting languages around, the two most prominent are - VBScript and JavaScript. You can also use PerlScript, an ActiveX scripting engine available from ActiveState Tools, Corp. that you can use for scripting your ASP pages.

 

Going back to VBScript and JavaScript, a common question that has been asked is "what is the best scripting language, VBScript or JavaScript?" In reality, there is no "better" scripting language. It all depends on what context you ask the question. Here are some of the factors you may want to consider before settling on one.

 

a. Ease of Use

 

People will tell you VBScript is easier than JavaScript, simply because it looks like the Visual Basic language. While this is true, a programmer with Java experience may think otherwise. People with no programming background may find VBScript easier to use because

 

·        It is easier to understand owing to its English-like syntax. E.g. If you want to get first 2 letters in a word, do Left(someWord, 2) in VBScript, whereas in JavaScript you do someWord.substr(0,2)

 

·        There is more ASP reference material with VBScript than there is with JavaScript.

 

·        JavaScript is case-sensitive and VBScript isn't. While this argument is valid, case-sensitivity helps people understand the syntax better.

 

b. Features

 

Both scripting languages are powerful in their own right. JavaScript offers a rich set of object-oriented framework to work with - you could create classes. But with its version 5, this functionality extends to VBScript as well.

 

Again, sometimes people confuse power with lines of code. Just because something can be done in VBScript with one line of code when it takes three lines in JavaScript does not mean JavaScript is any less powerful.

 

However, JavaScript and VBScript differ in some features

 

·        Error handling:

There was no error handling mechanism in earlier versions of JavaScript (in version 1.2, they started talking about it in 1.3). VBScript on the other hand provides a small but sufficient set of error handling capabilities.

 

·        Arrays:

Handling multi-dimensional arrays is easier in VBScript than in JavaScript. VBScript arrays can easily be dimensioned and re-dimensioned. JavaScript on the other hand provides a great feature - associate arrays, something that can easily replace dictionary objects.

 

·        Collection objects:

With VBScript, one can enumerate items in a collection using the For Each.. Next loop. This way, you avoid using an index to get the value of any item within the collection.
Note: JScript version 3 supports an Enumerator object which lets you loop through the collection without using any index.

 

c. Client-side Scripting

 

"Why?" you may wonder. Although client-side scripting has nothing to do even remotely with the server-side, you may find yourself considering this in some situations

 

·        This factor becomes important when you have to work on a team and the team members are new to scripting. Instead of climbing two learning curves, settle on one language for both client-side and server-side scripting. JavaScript can be a good candidate in these situations, as runs on most browsers. VBScript, on the other hand, does not run on Netscape browsers, which at this time constitute about half the browser market.

 

·        If you are working in an Intranet environment where the standard browser is Internet Explorer, you can choose either VBScript or JavaScript.

 

How about both JavaScript and VBScript?

 

ASP not only supports multiple scripting languages, but it lets you mix languages within a single page. For instance, you can have both JavaScript and VBScript routines on the same page. This ability, while it offers flexibility, is not all that efficient when you have a large number of pages. Consider this only if necessary, when one language does not give you what you want.

 

Conclusion

 

You will have to choose a scripting language to write ASP pages, especially when you are new to ASP. The language should not become a holy grail, but instead you should give both VBScript and JavaScript a try before you decide what's best for you.