ASP.NET Web Development
For some, the main motivation in learning to program with the .NET Framework and the .NET toolset is to create Web applications. Given the popularity and usefulness of Web-based applications, this motivation is certainly understandable.
In support of this interest, you will find in this section an introduction to the Web development technology offered through the .NET platform: Active Server Pages .NET (ASP.NET). I discuss the two portions of ASP.NET: ASP.NET Web applications and ASP.NET Web services.
| Cross-Reference | In Chapter 3, I introduced the topics of HTTP, URLs, and IIS. I presented these topics as prerequisites. In this chapter, I occasionally refer to these topics and related terminology. Additionally, I introduced the topics of HTML and client-side scripting in Chapter 4. At this point, a basic understanding of both HTML and client-side scripting is assumed as you explore the ASP.NET technology in this chapter. I encourage you to revisit these earlier chapters (and the references included in the "To Learn More" sections of these respective chapters) if you need a refresher. |
Understanding the ASP.NET Web Application Technology
You may have seen a .NET "Hello, World" Web application presentation before. That experience might have left you with the impression that to create a Web application, all you need to do is drag a control from the VS .NET IDE Toolbox into the ASP.NET Web Application project template ”a complete Web site, just like that!
| Note | In case you haven't seen a "Hello, World" Web application presented, don't worry. I'm going to show you one shortly. |
It is true that there is a minimal amount of training needed to begin coding ASP.NET applications. However, I suggest that there is a big difference between beginning and continuing. In other words, continuing to become a successful ASP.NET Web developer will require that you really understand the ASP.NET technology. In this section, my goal is to provide you with a sound understanding of ASP.NET.
This sound understanding will serve you well as a foundation. You will be well positioned to become a successful ASP.NET developer. Fortunately for you, ASP.NET development has greatly surpassed its .NET predecessor, Active Server Pages (ASP), by being much more "developer-friendly." As you will discover, ASP.NET is a very feature-rich portion of .NET technology. So buckle up, this will be an exciting ride as you learn about ASP.NET.
System Level: Comparing CICS with ASP.NET
Let's take quick, side-by-side look at a few characteristics of the mainframe's CICS and the Windows operating system's IIS [6] as they relate to application development. As you know, CICS is a full-featured, system-level software package that sits on top of the mainframe operating system. With ASP.NET development, on the other hand, you have IIS. Although IIS is also a full-featured , system-level software package, it happens to sit on top of the Windows operating system.
| Note | Vendors other than Microsoft are creating Internet server software packages. Some of these "alternate" Internet servers are more common on other operating systems. For example, it is rather common to have an Apache Internet software package running on the Linux operating system. This chapter ”and this book for that matter ”takes a Microsoft-centric view toward Windows and Web application development. Nevertheless, just be aware that although Microsoft has good market share, there continues to be competition, which is usually a good thing. |
CICS is host to a collection of system-level services (or software packages). Specifically , those services are CICS management, data management, data communication, and application programming interface. Together, these services support the CICS business applications. In other words, your application programs (presentation logic and business logic) interface with CICS through these provided services.
IIS also works with system-level software to support your business applications. Of course, the common language runtime (CLR) and the .NET Framework are there providing support for your managed applications. IIS relies on additional software such as the HTTP server, the Internet Server Application Programming Interface (ISAPI) software, and ASP.NET.
| Tip | Because all HTTP requests come through the ISAPI layer (Aspnet_isapi.dll), you can code ISAPI filters to intercept, monitor, and/or modify the HTTP Web. Prior to .NET, ISAPI development (also called ISAPI extensions ) was mainly limited to C/C++ developers. However, today the .NET Framework provides objects that can be used with any .NET-enabled language to develop routines that are analogous to ISAPI extensions. You will find these .NET Framework objects in the System.Web namespace as the IHttpHandler and IHttpModule inter- faces. ISAPI development has long been considered advanced-level development. Please refer to the references in the "To Learn More" section at the end of this chapter for more information. |
Let's examine a few more system-level comparisons. For example, you've always understood that your mainframe CICS business application required a general installation exercise. You're familiar with defining a CICS transaction, associating the transaction with your application program, and installing both the transaction and the program into the special CICS program control table (PCT) and processing program table (PPT).
Your ASP.NET Web applications also involve installation and deployment concerns. With ASP.NET, you will find yourself working with the IIS virtual directories, IIS Web site/applications folders, and in some cases, COM+ and/or the .NET Global Assembly Cache (GAC). Once your application is deployed, your ASP.NET end users will associate a URL with your Web site.
| Cross-Reference | I further discuss the topic of deployment (and IIS virtual directories) in Chapter 17. |
During runtime, all of your CICS end users would interact with this single CICS transaction associated with your application. Each time this CICS transaction was initiated, your actual application program was executed. With each execution of your program, there existed the potential for a new CICS task to be created and associated with the end user . The task continued to exist on a per-user basis. In your mainframe COBOL program, you had several CICS commands to choose from that provided limited programmatic access to the transaction, task, and user.
When it is time to run your Web application, your end users will use a URL to interact (by exchanging HTTP requests and responses) with the single instance of your application. Each time a new user (or a user visiting again who has closed and reopened his or her browser) begins to use your application, a new session is established. A session then exists that is associated with each user. The .NET Framework provides system-level intrinsic objects that enable programmatic access to the Application , Session , and User (also to the Server , Request , and Response ) intrinsic objects.
| Cross-Reference | I further discuss the Application, Session, User, Server, Request, and Response .NET intrinsic objects in the section ".NET Framework Support for ASP.NET Web Applications" later in this chapter. |
There are many other details on both sides of the fence (CICS and ASP.NET). I trust that I have covered enough of the basic system-level comparisons to help you feel comfortable with your new side of the fence: ASP.NET. The next section covers a few of the application-level CICS-to-ASP.NET comparisons.
Application Level: Comparing CICS with ASP.NET
I have certainly gotten the point across already that mainframe CICS application development is closely analogous to Windows and Web programming. Nevertheless, to catapult you forward into your understanding of ASP.NET, I will again refer back to those familiar legacy CICS techniques and concepts. Specifically, I will reflect on the following legacy mainframe CICS topics:
-
Pseudo-conversational design
-
The EIBCALEN field and the communication area length
-
The EIBAID field and attention keys
-
DFHCOMMAREA usage in the Linkage Section
The CICS Pseudo-Conversational Design
Probably one of the first topics you learned in mainframe CICS development was the concept of your application design moving to a pseudo-conversational model. This model emphasized the importance of a user interacting with your interface as if he or she were having a conversation ”yet in a disconnected way. Thus, your CICS transaction was removed from memory, saving resources after the completion of each program execution.
In other words, your application interface was to begin execution each time the user pressed an attention key (e.g., the Enter key, F1, F2, and so forth). Your application was to figure out which attention key was pressed, determine if any of the editable fields had changed, capture any data entry data, leverage the CICS DFHCOMMAREA (and possibly even CICS temporary storage [TS] queues) to retrieve and store data between executions, return a CICS screen to the end user, and actually end execution.
The CICS EIBCALEN Field
With the pseudo-conversational model, a CICS program would perform this execution cycle, sort of a round-trip, each time. Because each execution cycle would start with the program executing as if it was the first time executing, you added program logic to check the length of the Execute Interface Block (EIB) communications area (using the EIBCALEN field) and determine if this was in fact the first execution of the program.
The CICS EIBAID Field
When detecting that this was not the first execution (that an ongoing pseudo-conversation was in progress), you might have further interrogated the EIBAID field to determine which attention key had been pressed and executed any appropriate logic. In effect, this "appropriate logic" could be said to have been "tied" to the particular attention key. Meanwhile, you may have also added logic to examine each editable field's attribute byte (specifically, bit 7) to see if the Modified Data Tag (MDT) value had changed or not.
Obviously, this is a simplified high-level breakdown of the CICS application execution cycle. Nevertheless, I've gone into enough depth to be able to bring to your attention several very strong similarities. Let's turn now to ASP.NET. You'll find that the ASP.NET concepts are quite similar to those of CICS.
Looking at ASP.NET
ASP.NET is generally described as being a disconnected/stateless programming model. In fact, the protocol on which the majority of Web requests/network traffic is received (HTTP, as discussed in Chapter 3) is referred to as being a disconnected/stateless network protocol. Do you see where I'm going with this? The pseudo-conversational CICS model should remind you of the disconnected/stateless ASP.NET model. Interesting, isn't it? But wait, there's more.
When an end user (Internet or intranet browser) sends an HTTP request to the IIS Web server, the ASP.NET server engine is responsible for carrying out a complete phased execution cycle. The Web form (or Web page) goes through these phases (conceptually similar to the CICS execution cycle). As shown in Figure 13-11, there are various page events and methods involved during this cycle.
Figure 13-11: The general execution cycle of an ASP.NET HTTP request
| Note | I will refer back to Figure 13-11 several more times in subsequent sections. Please make a note of it. |
As with your mainframe CICS development, you can add logic to your ASP.NET application to influence the behavior of your application. For example, you can programmatically distinguish between the "first-time" execution and subsequent executions. Are you with me so far? Good! Let's continue.
Instead of your ASP.NET Web end user being limited to the use of CICS/mainframe-style attention keys, you can now provide richer, more "usable" controls for your end user to interact with. Your ASP.NET application will have logic (event procedures) that associates specific routines to an interface element. You have got to admit, it really is amazing just how close ASP.NET Web development is to mainframe CICS screen development.
| Note | You are not prohibited from using the function keys (F1, F2, key combinations, and so forth) as a means for the user to interact with the ASP.NET Web application. Visual controls have grown in popularity and remain very common. However, they are not the only choice for user interaction design. |
There is one other similarity that I will just mention for now. In the CICS scenario there exists the concern of "keeping" any captured data (in memory) from previous execution cycles ”possibly using the data in subsequent execution cycles. You have traditionally used the CICS DFHCOMMAREA to accomplish this on the mainframe.
As it turns out, ASP.NET offers features that directly support this same need to "save" data (between execution cycles). In ASP.NET circles, the phrases "session state" and "view state" are often used when addressing this concern. Although I briefly mention the topic of state management in this chapter, I further discuss it in Chapter 15.
| Cross-Reference | I further reference the CICS DFHCOMMAREA and CICS TS queues when I discuss ASP.NET's state management in Chapter 15. |
The point has been made: CICS development is similar to that of ASP.NET. This is important because you (presumably an experienced COBOL/CICS mainframe programmer) now have a jump start on learning about the ASP.NET technology. This is an opportunity for you to apply your past experience toward learning the .NET platform and the .NET toolset. You are well on your way to really understanding the ASP.NET technology. In the next section, you will create your first sample ASP.NET Web application.
Sample Code for Web Applications
The following sample applications, WebApplicationSampleCobol and WebApplicationSampleVB, demonstrate some of the basic ASP.NET concepts. You will begin with the COBOL .NET language choice for your first sample application. Following that, you will create a similar sample application using VB .NET. Please take a moment to walk through the creation of the first sample Web application, as detailed in the following steps.
| Tip | Although I suggest that you follow these steps to create your new ASP.NET project, you may wish to install and run the existing sample ASP.NET application that has been made available to you. In that case, you will need a small amount of preparation to get the ASP.NET sample application up and running. In Chapter 17, you will learn to create an installation/setup package. You can use the sample application in that chapter to assist you in installing the sample ASP.NET sample projects described in this chapter. Additionally, in case you need assistance in setting up your IIS Web server virtual directories, I cover that topic in Chapter 17 as well. |
-
Create a new COBOL .NET ASP.NET project. In an open VS .NET IDE New Project window select COBOL Projects as your project type and ASP.NET Web Application as your template selection. Enter WebApplicationSampleCobol as the name of your project and C:\Inetpub\ wwwroot as the location. [7] Once your New Project window resembles the example shown in Figure 13-12, click OK. As shown in Figure 13-13, a new folder will be created in the appropriate location.
Figure 13-12: Preparing to create a new COBOL .NET ASP.NET Web application in the New Project window -
Familiarize yourself with the VS .NET IDE. You will want to view the Solution Explorer window and notice the files that have been created for you (i.e., WebForm1.aspx and WebForm1.aspx.cob). Notice the Design tab and HTML tab in the WebForm1.aspx window. Additionally, notice the Toolbox that has been opened on the Web Forms tab. (You may have to manually open Solution Explorer and/or the Toolbox.)
Figure 13-13: A new folder is created under the C: \Inetpub\wwwroot folder location. -
Add two Web Forms server controls to the Web Form. From the Web Forms tab of the Toolbox, drag and drop a Button server control and a TextBox server control onto the Web Form. Your Design view should look similar to the Web Form example shown in Figure 13-14.
Figure 13-14: The WebApplicationSampleCobol project after Button and TextBox Web Forms server controls are added to the Web Form -
Open the WebForm1.aspx.cob file from the Solution Explorer window by double-clicking the file name ( optionally , click the View Code icon located at the top of the Solution Explorer window, or simply double-click the Web Form).
-
Add a PROPERTY statement for Text in the REPOSITORY section of the WebForm1 Class module as follows : PROPERTY PROP-TEXT AS "Text" . Then build (compile) your project.
-
Add the Button1_Click method. The easiest way to do this is to first switch over to the Design view of the WebForm1.aspx file. Then double-click the Button control that you added to the Web Form. Once you have done that, add the following line of code to this "event" method: SET PROP-TEXT OF TextBox1 TO "Hello World" . Your project is now ready to build and run.
Tip You can run your sample application from within the VS .NET IDE in debug mode. Optionally, you can navigate directly to your completed sample application using its URL: http://localhost/WebApplicationSampleCobol/WebForm1.aspx .
Now, the process was not that bad, right? For your convenience, I have included the top portion and bottom portion of the WebForm1.aspx.cob file in Listing 13-4. Please take a moment to review the sample code.
 |
000010 IDENTIFICATION DIVISION. 000020 CLASS-ID. WebForm1 AS "WebApplicationSampleCobol.WebForm1" 000030 INHERITS CLASS-PAGE. 000040 ENVIRONMENT DIVISION. 000050 CONFIGURATION SECTION. 000060 SPECIAL-NAMES. 000070 REPOSITORY. 000080 CLASS CLASS-EVENTARGS AS "System.EventArgs" 000090 DELEGATE DELEGATE-EVENTHANDLER AS "System.EventHandler" 000100 CLASS CLASS-OBJECT AS "System.Object" 000110 CLASS CLASS-PAGE AS "System.Web.UI.Page" 000120 CLASS CLASS-BUTTON AS "System.Web.UI.WebControls.Button" 000130 CLASS CLASS-TEXTBOX AS "System.Web.UI.WebControls.TextBox" 000140 PROPERTY PROP-BUTTON1 AS "Button1" 000150 PROPERTY PROP-TEXT AS "Text" 000160 . 000170 000180 OBJECT. 000190 DATA DIVISION. 000200 WORKING-STORAGE SECTION. 000210 01 Button1 OBJECT REFERENCE CLASS-BUTTON PROPERTY. 000220 01 TextBox1 OBJECT REFERENCE CLASS-TEXTBOX PROPERTY. 000230 PROCEDURE DIVISION. . . . <code generated by Web Forms Designer> . . . 001230 METHOD-ID. PAGE_LOAD AS "Page_Load" PRIVATE. 001240 DATA DIVISION. 001250 LINKAGE SECTION. 001260 01 PARAM-SENDER OBJECT REFERENCE CLASS-OBJECT. 001270 01 PARAM-E OBJECT REFERENCE CLASS-EVENTARGS. 001280 PROCEDURE DIVISION USING BY VALUE PARAM-SENDER PARAM-E. 001300 END METHOD PAGE_LOAD. 001310 001320 METHOD-ID. Button1_Click PRIVATE. 001330 DATA DIVISION. 001340 LINKAGE SECTION. 001350 01 sender OBJECT REFERENCE CLASS-OBJECT. 001360 01 e OBJECT REFERENCE CLASS-EVENTARGS. 001370 PROCEDURE DIVISION USING BY VALUE sender e. 001371 SET PROP-TEXT OF TextBox1 TO "Hello World". 001380 END METHOD Button1_Click. 001390 001400 END OBJECT. 001410 END CLASS WebForm1.
| |
I copied the sample code in Listing 13-4 from the particular file referred to as the code-behind file. In other words, the WebForm1.aspx.cob file contains the "server-side" code used "behind" the WebForm1.aspx file. Listing 13-5 presents the code contained in the WebForm1.aspx file. Notice that it only contains HTML code at this point. Additionally, notice that the first line (which is called a page directive ) contains a CodeBehind= clause that makes the association between the actual code-behind file and the HTML/UI page.
| |
<%@ Page language="cobol" Codebehind="WebForm1.aspx.cob" AutoEventWireup="false" Inherits="WebApplicationSampleCobol.WebForm1" %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > <HTML> <HEAD> <title>WebForm1</title> <meta name="GENERATOR" Content="Fujitsu NetCOBOL for .NET 1.0"> <meta name="CODE_LANGUAGE" Content="cobol"> <meta name="vs_defaultClientScript" content="JavaScript"> <meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5"> </HEAD> <body MS_POSITIONING="GridLayout"> <form id="Form1" method="post" runat="server"> <asp:Button id="Button1" style="Z-INDEX: 101; LEFT: 56px; POSITION: absolute; TOP: 40px" runat="server" Text="Button"></asp:Button> <asp:TextBox id="TextBox1" style="Z-INDEX: 102; LEFT: 56px; POSITION: absolute; TOP: 88px" runat="server"></asp:TextBox> </form> </body> </HTML>
| |
Following the same steps detailed previously for the COBOL .NET sample project, I have created another sample application using VB .NET. Figure 13-15 shows an ASP.NET Web application with WebApplicationSampleVB as the project name.
Figure 13-15: The WebApplicationSampleVB project after Button and TextBox Web Forms server controls have been added to the Web Form
The code from the WebApplicationSampleVB project's code-behind file, WebForm1.aspx.vb, is shown in Listing 13-6.
| |
Public Class WebForm1 Inherits System.Web.UI.Page Protected WithEvents Button1 As System.Web.UI.WebControls.Button Protected WithEvents Button2 As System.Web.UI.WebControls.Button Protected WithEvents TextBox1 As System.Web.UI.WebControls.TextBox #Region " Web Form Designer Generated Code " 'This call is required by the Web Form Designer. <System.Diagnostics.DebuggerStepThrough()> _ Private Sub InitializeComponent() End Sub Private Sub Page_Init(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Init 'CODEGEN: This method call is required by the Web Form Designer 'Do not modify it using the code editor. InitializeComponent() End Sub #End Region Private Sub Page_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load 'Put user code to initialize the page here End Sub Private Sub Button1_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button1.Click TextBox1.Text = "Hello World" End Sub End Class
| |
Looking at the code from the VB .NET code-behind file in Listing 13-6, notice the Button1_Click event method and the logic used to change the Text property of the TextBox control. Additionally, notice the Page Init and Page Load event methods. You may recall the sequence of page events shown in Figure 13-11. Recalling this sequence, you can anticipate the relative order in which the event methods are triggered.
A Word About the Code-Behind File
Inevitably, you will come across ASP.NET Web application examples showing a single-file Web Form design as opposed to a two-file Web Form design. The difference between these designs is that the single-file design will have a "script block" (resembling the following: <script runat="server">logic</script> ) included in the HTML-based .aspx file.
The two-file Web Form design is identified by having an .aspx file and a code-behind file. The code-behind file would then contain the page and other control event-handling methods. Using VS .NET's IDE and project templates, you will typically be creating your ASP.NET projects using the two-file Web Form design. This is a good thing. Some of the advantages of the two-file code-behind design are as follows:
-
Your source code, which is easily human-readable during design time, becomes more difficult for others to read once it is "compiled" into your assembly (DLL). This added level of privacy [8] is important to some organizations, especially when it is time to put the software distribution package together.
-
During design time, you will experience better VS .NET IDE IntelliSense and debugging support.
-
Events and event handlers must be manually bound.
-
Separating your business logic from your presentation logic means cleaner, more maintainable code.
| |
When you get a chance, consider exploring your VS .NET IDE's New Project window Project Types choices. Under the Other Projects folder, you will notice the Application Center Test Project and Enterprise Template Project choices.
You can use the Application Center Test Project to build stress/load tests for your ASP.NET applications. Optionally, you can access the Application Center Test tool by clicking the Start button and selecting Programs Microsoft Visual Studio .NET Visual Studio .NET Enterprise Features Microsoft Application Center Test.
The Enterprise Template Project is useful when you are building a large-scale application and you want to use a template that is broader than the default ASP.NET template. These two Other Projects templates are good examples of VS .NET being designed with developer productivity in mind.
| |
Now that you have seen the sample "Hello, World" ASP.NET Web applications (in COBOL .NET and VB .NET), you can drill down into the .NET Framework classes. Once you learn about the .NET Framework Web namespaces, you will be well on your way to having a more complete picture of what it takes to build ASP.NET Web applications.
.NET Framework Support for ASP.NET Web Applications
The collection of .NET Framework objects for ASP.NET Web support is both extensive and exhaustive. In this section, you will learn about a subset of them. I discuss others in the later section "Understanding the ASP.NET Web Services Technology." I will defer discussing yet others until later chapters as appropriate.
The following lists of topics present the structure of my discussion of the .NET Framework support for ASP.NET (those .NET namespaces directly related to both Web application and Web services development):
Web application namespaces discussed in this chapter:
-
System.Web
-
System.Web.UI
Web services namespaces discussed in this chapter:
-
System.Web.Services
-
System.Web.Services.Description
-
System.Web.Services.Discovery
-
System.Web.Services.Protocols
Web application namespaces discussed in later chapters:
-
System.Web.UI.HtmlControls (discussed in Chapter 14)
-
System.Web.UI.WebControls (discussed in Chapter 14)
-
System.Web.Caching (discussed in Chapter 15)
-
System.Web.SessionState (discussed in Chapter 15)
-
System.Web.Mail (discussed in Chapter 16)
-
System.Web.Security (discussed in Chapter 18)
Web namespaces not discussed (please see the VS .NET Help text for more information about these namespaces):
-
System.Web.Hosting
-
System.Web.Configuration
-
System.Web.Services.Configuration
-
System.Web.UI.Design
-
System.Web.UI.Design.WebControls
As you can see, there are quite a few namespaces for ASP.NET Web development. It's even more amazing when you compare this impressive list with the small list of .NET namespaces provided for Windows development. (Recall that there were only two: System.Windows.Forms and System.Windows.Forms.Design.) Suffice it to say, the ASP.NET development arena is feature rich.
The System.Web Namespace
Do you remember the intrinsic objects I mentioned earlier in the section "System Level: Comparing CICS with ASP.NET"? Namely, they were the Server, Application, Session, User, Request, and Response objects. Well, guess what? Among the many objects exposed in the System.Web namespace, you will find objects that have a one-to-one relationship with the so-called intrinsic objects mentioned earlier.
As you further familiarize yourself with the System.Web namespace, you will notice that the majority of its objects (classes, delegates, interfaces, and enumerations) are prefixed with "Http" (see Figure 13-16). This is understandable, given that the System.Web namespace is primarily used for the communication between the client (browser) and the server (IIS, ISAPI, and ASP.NET). Recall that the communication between the client and the server is done via HTTP.
Figure 13-16: The System.Web namespace as shown in the VS .NET IDE Object Browser
Among the many interesting classes in the System.Web namespaces is the System.Web.HttpContext class. This class encapsulates all HTTP-request specific information (including access to the intrinsic objects). For example, you can use the Session property of the HttpContext class to obtain an instance of the HttpSessionState object. Then, using the HttpSessionState object, you can obtain the SessionID or manipulate the TimeOut value for a session. As shown in Figure 13-17, the HttpContext object includes several useful methods and properties.
Figure 13-17: The members of the System.Web.HttpContext class as shown in the VS .NET IDE Object Browser
Another class from the System.Web namespace is the Application object. The Application object is exposed as HttpApplication . You will often see this class (and the HttpSessionState class) being used when you browse through your ASP.NET Web application's Global.asax.cob and/or Global.asax.vb file. In the "Hello, World" sample Web applications you created earlier, you may recall seeing the Global.asax.cob and/or Global.asax.vb files in the Solution Explorer window.
The Global.asax files are used as a convenient location to handle application-level events raised by ASP.NET (or by HTTP modules). As shown in Figure 13-18, the events associated with the Application intrinsic object are raised in a specific order. It would be wise to be aware of this event firing order. Each event shown in Figure 13-18 has it own significance and can be "handled" with appropriate logic (i.e., coding logic in an event method that is located inside of Global.asax.cob/Global.asax.vb).
Figure 13-18: The Application object's events and their firing order. Not shown are the PreSendRequestHeaders, PreSendRequestContent, and Error events, which can fire in a nondeterministic order.
| Note | The Application_OnStart and Application_OnEnd event methods seen in most Global.asax.vb/Global.asax.cob modules are actually event methods triggered from the HttpApplicationFactory object. The HttpApplication object is created from the HttpApplicationFactory object. For more information about the HttpApplicationFactory object, please refer to the HTTP- and ISAPI-related references provided at the end of this chapter in the "To Learn More" section. |
You may have noticed in Figure 13-18 the indication that the page-level events occur during the time (right after the PreRequestHandlerExecute event) that the Application object's events are occurring. I briefly discussed the page-level events earlier in section "Looking at ASP.NET," along with Figure 13-11.
It is time to bring your exploration into the System.Web namespace to a close. You have been exposed to quite a bit with just two .NET System.Web classes: HttpContext and HttpApplication. As time allows, please revisit the System.Web namespace for continued learning. In the next section, you will dive into a different namespace that also supports Web application development: System.Web.UI.
The System.Web.UI Namespace
This particular namespace serves as the basis for the user interface controls that you will be using as you build Web pages. There is a class in this namespace called Control (as in System.Web.UI.Control ). Interestingly, every control ”even the page itself ”derives (either directly or indirectly) from the System.Web.UI.Control class.
| Note | For comparison, you should be reminded that in the earlier discussion on Windows development in the section "Introducing the System.Windows.Forms Namespace" that all of the user interface objects for Windows were derivatives of the System.Windows. Forms.Control class. This is, of course, more than just a naming convention. This is a good example of using inheritance and object orientation to extend a base class to more specific implementations . |
This is important to realize because of the underlying benefits gained through inheritance (again, there's that object orientation that I warned you about). Once you're familiar with the base class for Web server controls (System.Web.UI.Control), then you'll basically learn everything else accumulatively. By following the inheritance lineage, you'll discover that there are more than a dozen categories of controls.
This is in contrast to the impression easily obtained from the manner in which the controls are presented in the VS .NET IDE Toolbox. I believe that a person who is new to .NET and VS .NET is at risk of being misled into thinking that there are only two types of controls: HTML controls and Web Forms controls. For example, if you were to go to the VS .NET IDE Toolbox, you would see what looks like two choices for "controls." As shown in Figure 13-19, you can select the HTML tab in the Toolbox. Optionally, as shown in Figure 13-20, you can select the Web Forms tab in the Toolbox.
Figure 13-19: The VS .NET IDE Toolbox with the HTML tab selected
Say that you want to make sense of all this and begin your research. You read somewhere that there is no such thing as HTML controls, but HTML elements do exist. You further discover that the "icons" shown on the HTML Toolbox tab represent HTML elements, not HTML controls. Then, just as you are starting to feel comfortable with your new understanding, you hear that these HTML elements can be set to "Run As a Server Control." You continue to research and discover that you can add an HTML attribute ( runat="server" ) to these HTML elements to convert them into HTML server controls.
Assume that the next leg of your journey led you to learn about Web Forms server controls. There, you realized that the object model for Web Forms server controls is richer (more properties, methods, and so forth) than that of the HTML server controls. The choice seemed easier then. And so, your journey continues.
Figure 13-20: The VS .NET IDE Toolbox with the Web Forms tab selected
| Note | At this point, you have half of the battle won ”with controls, that is. I present a more extensive discussion of controls (e.g., Web Form controls, user controls, and so on) in the next chapter (Chapter 14). For now, simply realize that there is a huge difference between the "icons" shown in the HTML Toolbox tab and the Web Forms Toolbox tab. Additionally, please note that there are at least a dozen categories of Web server controls defined in the System.Web.UI namespace. |
Before you go much further, take a step back for a moment ”back to the System.Web.UI namespace and the System.Web.UI.Control class. After all, understanding the relative hierarchy of this base classes derivative will help in your extended learning. Consider for a moment the hierarchy of classes (ASP.NET server controls) that all inherit directly or indirectly from the System.Web.UI.Control base class, as shown in Listing 13-7.
| |
System.Web.UI.Control System.Web.UI.BasePartialCachingControl System.Web.UI.PartialCachingControl System.Web.UI.StaticPartialCachingControl System.Web.UI.DataBoundLiteralControl System.Web.UI.HtmlControls.HtmlControl System.Web.UI.HtmlControls.HtmlContainerControl System.Web.UI.HtmlControls.HtmlAnchor System.Web.UI.HtmlControls.HtmlButton System.Web.UI.HtmlControls.HtmlForm System.Web.UI.HtmlControls.HtmlGenericControl System.Web.UI.HtmlControls.HtmlSelect System.Web.UI.HtmlControls.HtmlTable System.Web.UI.HtmlControls.HtmlTableCell System.Web.UI.HtmlControls.HtmlTableRow System.Web.UI.HtmlControls.HtmlTextArea System.Web.UI.HtmlControls.HtmlImage System.Web.UI.HtmlControls.HtmlInputControl System.Web.UI.HtmlControls.HtmlInputButton System.Web.UI.HtmlControls.HtmlInputCheckBox System.Web.UI.HtmlControls.HtmlInputFile System.Web.UI.HtmlControls.HtmlInputHidden System.Web.UI.HtmlControls.HtmlInputImage System.Web.UI.HtmlControls.HtmlInputRadioButton System.Web.UI.HtmlControls.HtmlInputText System.Web.UI.LiteralControl System.Web.UI.TemplateControl System.Web.UI.Page System.Web.UI.UserControl System.Web.UI.WebControls.Literal System.Web.UI.WebControls.PlaceHolder System.Web.UI.WebControls.Repeater System.Web.UI.WebControls.RepeaterItem System.Web.UI.WebControls.WebControl System.Web.UI.WebControls.AdRotator System.Web.UI.WebControls.BaseDataList System.Web.UI.WebControls.Button System.Web.UI.WebControls.Calendar System.Web.UI.WebControls.CheckBox System.Web.UI.WebControls.DataListItem System.Web.UI.WebControls.HyperLink System.Web.UI.WebControls.Image System.Web.UI.WebControls.Label System.Web.UI.WebControls.BaseValidator System.Web.UI.WebControls.BaseCompareValidator System.Web.UI.WebControls.CustomValidator System.Web.UI.WebControls.RegularExpressionValidator System.Web.UI.WebControls.RequiredFieldValidator System.Web.UI.WebControls.LinkButton System.Web.UI.WebControls.ListControl System.Web.UI.WebControls.CheckBoxList System.Web.UI.WebControls.DropDownList System.Web.UI.WebControls.ListBox System.Web.UI.WebControls.RadioButtonList System.Web.UI.WebControls.Panel System.Web.UI.WebControls.Table System.Web.UI.WebControls.TableCell System.Web.UI.WebControls.TableRow System.Web.UI.WebControls.TextBox System.Web.UI.WebControls.ValidationSummary System.Web.UI.WebControls.Xml
| |
While you view the hierarchy of derived server controls in Listing 13-7, observe that there are groups of classes for System.Web.UI.HtmlControls.HtmlControl and for System.Web.UI.WebControls.WebControl . Although the names may seem redundant, if you study the actual naming pattern in the hierarchy, the names will actually make sense. At the very least, they are consistent.
| Tip | The System.Web.UI.Page class and the System.Web.UI.Control class are two classes that you might consider focusing on as you continue your research. From there, it will be much easier to gain an understanding of the remaining server control classes in the System.Web.UI namespace. Remember that the Page class is the actual object used for your Web page. These two classes will serve as the foundation for all of your user interface “related ASP.NET Web application development. |
For now, there is one other observation that I would like to point out (from the hierarchy of derived server controls). Can you spot the System.Web.UI.Page class? Yes, that is right. There it is ”a derivative of System.Web.UI.Control. The actual Web page that you place "controls" onto during design time is itself a "control." You may recall that I referred to the Page class much earlier in this chapter. Please take a moment to revisit Figure 13-11. The figure in question illustrates the page life cycle and event firing order associated with the Page object.
| Note | You should pay particular attention to the placement/association of each class group . For example, you should notice that the System.Web.UI.Page class (and the System.Web.UI.UserControl class) derives from the System.Web.UI.TemplateControl class. This will help you understand why most of the "controls" have "common" properties, methods, and so forth. |
The System.Web.UI.Page Class and Client-Side Scripts
As you may know, the use of client-side scripts (JavaScript, JScript, VBScript, and so forth) on your Web page can offer performance gains by offloading processing from the server to the client browser. Also, you can use client-side scripts to create a richer, more responsive Web Form.
Practically all of the Web pages you will see with client-side scripts will have its client-side script included in one of two ways: placed inside of a script block HTML tag or added as an attribute to an HTML element tag. In both of these cases, you will see the client-side script in the .aspx file during design time and deployment time. The script block and HTML attribute methods of client script insertion would resemble the following:
-
<script >ScriptBlockLogic</script>
-
<A HREF="www.EclecticSoftwareSolutions.Com" onClick="alert('This will take you to my Home Page.');">
As it turns out, you can use the System.Web.UI.Page class to separate client-side script from your HTML-based .aspx file. This is made possible through the use of any of the following public Page class methods:
-
RegisterArrayDeclaration
-
RegisterClientScriptBlock
-
RegisterHiddenField
-
RegisterOnSubmitStatement
-
RegisterStartupScript
You can use these new System.Web.UI.Page class methods to possibly get away from needing to include any actual code in your HTML-based .aspx file. Using these methods, you can store the client-side script in your page's code-behind file. When the page is rendered, the script is combined with the HTML and sent to the client's browser for execution.
| Tip | Using these Page methods for your client-side script brings another benefit. By having your client-side script located within your code-behind file, you can easily add logic to effectively build your client-side script. In other words, your client-side script can become dynamic. Your conditional server-side logic can react as needed to affect the client-side script. This is in contrast to the client-side script being physically located in the HTML-based .aspx file and becoming static. |
Deciding on which Page method to use will depend on where (on the target page) you want your client-side script to be inserted. Also, depending on "when" in the page's life cycle you want the client-side script executed, one "Register"-type Page method or another will be appropriate. Keep these basic points in mind:
-
Insert client-side script in the HTML form (the effect is similar to locating the script in the HTML header) if you want to explicitly call the script function for execution.
-
Insert client-side script directly in the body of your HTML page when you need to include the output of the function in the resulting displayed Web page.
-
Insert client-side script as an event handler if you want the appropriate event to trigger its execution.
As you recall, the topic of client-side scripting was previously acknowledged as a .NET retraining prerequisite topic (see the section "Client-Side Scripting Languages" in Chapter 4). It would certainly be appropriate to revisit the earlier client-side scripting discussion. For now, understand that using the Page methods discussed here for client-side script insertion is optional. As usual, it is good to know what your options are.
You've barely scratched the surface of the System.Web.UI namespace and the System.Web.UI.Control class topics. Nevertheless, it's time to conclude this chapter's introduction to ASP.NET Web application development. You can see that you'll definitely want to extend your learning. The references located at the end of this chapter in the "To Learn More" section should prove useful toward that goal. For now, there remains one additional portion of ASP.NET technology to briefly discuss. Let's now switch gears and focus on ASP.NET Web services.
Understanding the ASP.NET Web Service Technology
If there is one part of .NET that has received more attention (perhaps a larger share of Microsoft's marketing budget) than the others, Web services would definitely be it. The Web services technology is sometimes advertised as being the next generation of Web programming. Although I cannot substantiate such lofty claims, I will agree that XML Web services has much to offer and should hold a high spot on any serious Web developer's retraining agenda.
Given that there is an abundance of information publicly available already on the topic of XML Web services (or simply Web services ), I will keep my discussion here brief. As usual, references are provided at the end of this chapter in the "To Learn More" section for your continued learning. I begin by showing the general architecture of a Web service application in Figure 13-21.
Figure 13-21: The general architecture of a Web service application
To continue my discussion of Web services, I will first revisit the mainframe CICS started task analogy that I previously introduced in Chapter 2.
| Note | Although the CICS LINK and XCTL commands also support the initiation of CICS programs and the exchange of data between CICS programs, a CICS started task runs as a separate CICS task. For this reason, the CICS started task fits as a closer analogy to the .NET XML Web service. |
A Mainframe Analogy for XML Web Services
Let's now compare Web services (synonymous with ASP.NET XML Web services) to the mainframe CICS transaction/program model referred to as a started task. Table 13-1 compares the basic characteristics of both.
| CICS STARTED TASK | WEB SERVICE |
|---|---|
| A CICS started task is an online application that does not have a "screen type" user interface. An application programming interface (API) is used instead. | A Web service is an online application that does not have "screen type" user interface. After all, XML Web services are themselves ASP.NET Web programs (that service other programs). You use the VS .NET New Project template of ASP.NET Web service to create Web services (using COBOL .NET and/or VB .NET). |
| A CICS started task can be programmatically initiated (using a CICS START command) from a eparately running CICS program. Additionally, you can use interval control to initiate a CICS started task based on a schedule. | A Web service can be programmatically initiated in much the same way that other Windows and Web programs are. Once a client application establishes a Web reference (usually during design time) to the Web service, a "call" is made from the client consumer to the Web service's publicly exposed method. The targeted method is required to have a <WebMethod> attribute applied. Refer to System.Web.Services for .NET Framework namespace support. |
| A CICS started task uses a temporary storage file (DFHTEMP) to facilitate the programmatic exchange of data. The CICS START/FROM and RETRIEVE/INTO commands are used to pass data to and from a CICS started task. | A Web service uses XML and Simple Object Access Protocol (SOAP) to facilitate the programmatic exchange of data. Fortunately, the mechanics of SOAP occur mostly behind the scenes. Nevertheless, be aware that SOAP is there, in the background. Refer to System.Web.Services.Protocols for .NET Framework support. |
| A CICS started task has an implied contract in place for the structure of the data record passed using START/FROM and RETRIEVE/INTO. In other words, the layout of the data record passed has to match the layout retrieved. | A Web service has an implied contract in place that describes the service being exposed by the WebMethod. The contract is in the form of an XML document written in an XML grammar referred to as Web Services Description Language (WSDL). Refer to the two namespaces System.Web.Services.Configuration and System.Web.Services.Description for .NET Framework support. |
| A CICS started task is installed in the CICS program control table (PCT). The associated CICS program is then installed in the processing program table (PPT). Together, the PCT and PPT make it possible to locate a CICS started task and program when you want to initiate the online process. | A Web service can be located through the "discovery" process. The XML document referred to as the .disco file enables discovery of the Web service. Alternatively, you can use a public registry service such as the Universal Description, Discovery, and Integration (UDDI) to enable a more broad, public discovery process. A registry service would then provide a URL to the .disco file. Refer to System.Web.Services.Discovery for .NET Framework support. |
Each of the basic characteristic comparison points in Table 13-1 shows a one-to-one match between a (mainframe) CICS started task and an (ASP.NET) XML Web service. A lot of people are amazed at how similar the two worlds are. When you have spent years being successfully trained on the mainframe platform, it sure is nice that your invested experience can be leveraged toward your continued career interests.
Noteworthy ASP.NET Web Service Observations
The first time that you use VS .NET's IDE (using the ASP.NET Web Service Project template) to create a new Web service, you will notice a few differences between the Web service project and the Web application project. For one, your default "surface," the item that looks like a Web Form, will be named with an .asmx suffix. The .asmx suffix is characteristic of Web services (as opposed to the .aspx suffix used for Web applications).
| Note | When you view your project files in the Solution Explorer window, you will notice that a WebService1. vsdisco file is created for you (when you use VB .NET as your language choice). |
Once you open the .asmx file and navigate to the Code view, you have a nice surprise waiting for you. The ASP.NET Web service projects (both COBOL .NET and VB .NET) provide their own built-in "Hello, World" sample. All you have to do is uncomment the code (represented as a HelloWorld WebMethod ), build, and run. After you uncomment the built-in WebMethod, the resulting code should resemble the code snippets in Listing 13-8.
| |
. . . . . .VB.NET <WebMethod()> Public Function HelloWorld() As String HelloWorld = "Hello World" End Function . . . . . .COBOL.NET 000530 METHOD-ID. HELLOWORLD AS "HelloWorld" CUSTOM-ATTRIBUTE IS CA-WEBMETHOD. 000540 DATA DIVISION. 000550 LINKAGE SECTION. 000560 01 RET-VAL OBJECT REFERENCE CLASS-STRING. 000570 PROCEDURE DIVISION RETURNING RET-VAL. 000580 SET RET-VAL TO N"Hello World". 000590 END METHOD HELLOWORLD.
| |
Not only is there a functional built-in sample, but also you will notice something else when you execute the Web service project. You will notice that a "test harness" is automatically built for you. The .asmx file dynamically builds a Web page that serves as a client consumer. You use this Web page to test your Web service. Can it get any better?
There is yet one more treat! The test page has a link available for you to view the dynamically built Web service description document (.wsdl file). While the Web service is executing, you will notice the Service Description link near the top of the test Web page. If you click the link, an XML document will be displayed (as shown in Figure 13-22).
Figure 13-22: The service description XML document (.wsdl) for the sample "Hello, World" applications
There is one last difference to note between ASP.NET Web services (.asmx) and ASP.NET Web applications (.aspx). ASP.NET Web services have a special collection of .NET Framework namespaces:
-
System.Web.Services
-
System.Web.Services.Configuration
-
System.Web.Services.Description
-
System.Web.Services.Discovery
-
System.Web.Services.Protocols
XML Web Services Continue to Evolve
The ASP.NET XML Web services arena is rather new. Many things are evolving (as I type) to help solidify its presence. Specifications, standards, and practices are being put in place as partnerships and alliances are being formed .
For example, the UDDI specification recently moved to be under the umbrella of the Organization for the Advancement of Structured Information Standards (OASIS). This happened just 2 months after Microsoft, IBM, and VeriSign submitted the WS-Security specification (a proposed standard for Web services security) to OASIS. Meanwhile, Microsoft, IBM, and BEA released the WS-Coordination and WS-Transaction specifications (proposed standards for distributed Web services and Web service “based transactions).
| Note | The WS-Security specification for XML Web services was released in April 2002. |
Microsoft, IBM, and other members of the Web Services Interoperability Organization (WS-I) are hard at work, teaming up to work on the Global XML Web Services Architecture (GXA) platform. More specifications for XML Web services are on the way. Among the specification releases expected in the future are the following:
-
WS-Attachments specification
-
WS-Inspection specification
-
WS-Referral specification
-
WS-Routing specification
The alliances formed in the WS-I, the GXA platform, and the XML Web service specifications being produced just may be what is needed to ensure the long- term success of XML Web services. Only time will tell. Certainly, this is an area that will require monitoring as it continues to evolve. Meanwhile, be aware that thousands of very useful and dependable XML Web services are being developed using VS .NET and the existing specifications and standards.
[6] Feel free to revisit Chapter 3 for more information. IIS was originally introduced there.
[7] I am assuming that you have IIS installed and running locally and that you are logged on with a user account that has administrative-level rights (over your local workstation). You may need to consult with your manager for the appropriate environment configuration used at your particular company.
[8] Use of an "obfuscator" software tool can elevate this "level of privacy" to a "level of security."
EAN: 2147483647
Pages: 204