CHAPTER 1 The big picture Internet Wireless network

WAP, voice, and other alternative web clients Brief WML overview Each WML file contains a deck of cards, each card being a presentation view and a possible point of interaction.3 WAP interaction is accomplished in much the same way as in HTML applications, through links or options that take the user to other cards within the same deck (similar to anchors in HTML), or to resources outside the current deck. One of the major differences between WML and HTML applications is that WML is based upon XML, while HTML is based upon SGML. This means that stricter rules apply to WML than to HTML, and that there is a document type definition (DTD) that tells the parser of the WML the order in which certain elements may appear. The following fragment constructs a WML deck of cards and, as you can see, although WML resembles HTML s look and feel, they are not the same. < ?xml version="1.0"?> < !DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" http://www.wapforum.org/DTD/wml_1.1.xml>

Cosmetix

3 It is possible for the deck to contain just one card.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

CHAPTER 1 The big picture Internet Wireless network

CHAPTER 1 The big picture Internet Wireless network WAP device WAP device WAP device WAP device WAP device WAP device Web site Web site Gateway This side knows WAP protocols This side knows TCP/IP and HTTP Converts: WAP requests to HTTP requests HTTP response to WAP response Figure 1.4 Connecting the WAP device to the Web requests from a WAP device with this model; it simply needs to format the responses to conform to the capabilities of the device. Today, the resources available for the WAP device are very limited: The display is extremely small and its drawing capabilities range from basic to nonexistent. While HTML applications are normally designed for clients running at least 800 x 600 in 256 or more colors, WAP applications are normally designed to show only a few characters in a row, and only a small number of rows on the same display. Compared to the Internet, the network connection is slow but improving, especially in Europe and Asia, which means that the application utilizes the fewest connections possible during a user s session. Processing power and memory are minimal. Based on these limitations, it is easy to imagine why WAP devices cannot support full-fledged HTML. What they do support is an XML dialect known as Wireless Markup Language (WML) and WMLScript, JavaScript s counterpart that supports a limited JavaScript subset feasible for weak phone processors. Thus, any content we return to a WAP request must be in WML, instead of in standard HTML.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

CHAPTER 1 The big picture What is a

WAP, voice, and other alternative web clients from their HTML development. Since coding with tags is usually simpler then using a full-fledged language and, since most content creation tools already accept tags, two benefits are: There is a single, consistent, and easy-to-follow style in the page. This makes tagged pages a breeze to work with for many content creators (and their tools). Many HTML developers can program simple tagged pages such as the one presented in listing 1.3. This introduction of the tag-based approach continues in chapters 2 and 3, where we talk at length about JSPs, servlets, and custom tags themselves. 1.5 WAP, voice, and other alternative web clients Up to now our discussions have assumed a classic web programming model, with an HTML browser and HTML content being generated by the server. Today, however, there is a great deal of buzz surrounding the concept of wireless and nontraditional access to the Web. At the forefront of this new wave of web clients is the Wireless Application Protocol (WAP) device. WAP is a set of specifications which enables users to browse online content and services using a wireless device. WAP devices range from cellular phones to pagers and Personal Digital assistants (PDA), such as PalmPilots. WAP preserves the architecture used through the Web, in which servers are holding the information and clients are accessing it through requests to the servers. The creators of WAP (the WAP Forum) took great pains to ensure that this model was very close to the traditional HTML web model, in order to keep the barrier to entry for this new technology as low as possible. How can a WAP device access a traditional web server? To access a web server, the WAP device should communicate using HTTP and TCP/IP; isn t that too complex for a cellular phone? To expect that level of software support from a mobile phone today is still a bit ambitious (although it is being anticipated), but WAP architecture obviates the need for HTTP and TCP/IP support on the phone by using gateways. WAP architecture As figure 1.4 shows, the telephone network is connected to the Web through a transcoding gateway. This gateway takes WAP requests and passes them to the Web as if they were HTTP requests; it then takes the HTTP responses and transforms them to WAP and returns them to the WAP device. Using these gateways, WAP devices can interoperate with the Web and fetch content without changing too much of the web infrastructure. In fact, any standard web server can receive

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

CHAPTER 1 The big picture What is a

CHAPTER 1 The big picture What is a tag-based solution like? We ll defer specifics about custom JSP tags until chapter 3, but will mention some of the basics of this extension mechanism to afford a glimpse at its benefits. Developing with tags resembles the server pages development model with one crucial difference the development language is not a script, but is rather based on sequences of characters (usually starting with a < and ending with a > ) known as tags. A tagged server page includes the page s content (usually HTML) plus tags that can be used to add logic to the content. When the user asks for a tagged page, the server interprets the page, finds all the logic tags, and executes them along with the page content. To see an example of tag-based programming, let s look at a ColdFusion fragment (listing 1.3) which mimics the ASP code in listing 1.1. Listing 1.3 Sample ColdFusion fragment that generates dynamic content You asked for the server located on your local machine. You asked for the server #CGI.SERVER_NAME# As you can see, instead of using VBScript (the language of choice in listing 1.1) we are now using special ColdFusion tags (prefixed with CF). Using these tags, the developer can easily implement simple logic. ColdFusion started up with a limited tag set geared toward database manipulation and presentation. They soon added tags to perform programming tasks, including iteration over arrays with tags such as CFLOOP; catching exceptions with tags such as and ; and performing various utility operations with tags such as , and . 1.4.1 Benefits of a tag-based approach How is using tags any different from embedding script in a server page? After all, this may look like yet another case of server pages with just a different scripting syntax (tag-based, instead of the more common programming syntax). In a way, this is correct; however, tag-based technologies offer advantages. Using tags is much more comfortable for many HTML developers who are very familiar with the use of tags

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

CHAPTER 1 The big picture At the other

Tag-based programming

(more program code)

Separating these two layers is a problem in the other extension mechanisms we ve mentioned, but the page-centric nature associated with server pages applications makes the problem much more pronounced. Whereas a CGI developer can come up with his or her own page-generation template system to separate presentation and business logic, server pages technologies dictate a specific template system into which the developer is locked. In addition, the powerful scripting language that can be used within the pages makes it possible to implement quick and dirty applications that place the majority of the business logic directly inside the server page. The result is that many server pages-based applications lack an adequate separation of layers. 1.4 Tag-based programming Thus far we ve covered a number of different approaches to dynamic web development. We ve seen how CGI scripts allow the building of dynamic sites, but suffer from some significant performance problems. We ve seen how server API solutions may overcome CGI s speed issues, but add a lot of complexity to development and tie you very closely to a particular server vendor. We ve looked at server page approaches which are acceptably quick at execution time and much easier to implement than API solutions, but encourage poor separation between presentation and business logic layers. What is the next step in the evolution of dynamic web development? It is none other than the subject of this book: tag-based development. JSP custom tags are not the first tag-based approach. ColdFusion, a product from Allaire Corp., is a well-known implementation of this tag-based concept and was introduced before custom JSP tags. ColdFusion still enjoys a solid market share for web development, but is less attractive to many developers because it is a proprietary solution while custom tags are defined in the open JSP specification. Being a purely Java solution, custom tags also enjoy all the normal benefits such as being cross platform, widely supported, and written in a fully functional language. Cold- Fusion does not boast this same cross platform ability, nor is it an open standard that is available to multiple vendors. As we ll see in future chapters, engines that run custom JSP tags within a web server can be built by any company willing to adhere to certain open standards. At least a dozen vendors have built these solutions today, Allaire being one of them.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services

CHAPTER 1 The big picture At the other

CHAPTER 1 The big picture At the other extreme, the presentation resides in a module totally separate from the one implementing the business logic, and the interaction between the two is defined by a set of well-known interfaces. This type of application provides the necessary separation between the presentation and the business logic. Why is this separation so crucial? In most cases the developers of the presentation layer and the business logic are different people with different sets of skills. Usually the developers of the presentation layer are graphics designers and HTML developers who are not necessarily skilled programmers. Their main goal is to create an easy-to-use, attractive web page. The goal of programmers who develop the business logic is to create a stable and scalable application that can feed the presentation layer with data. These two developers differ in the tools they use, their skill sets, their training, and their knowledge. When the layers aren t separated, the HTML and program code reside in the same place. Think back to our previous discussions of CGI and web server API extension techniques. Many sites built with those techniques have code (either in a module or a CGI script) that executes during a page request and returns HTML. Imagine how difficult it is to modify the User Interface if the presentation logic, HTML in our example, is embedded directly in a script or compiled code. Though developers can overcome this difficulty by building template frameworks that break the presentation away from the code, this requires extra work for the developer since the extension mechanisms don t natively support such templating. Server pages technologies are not any more helpful with this problem. Many developers simply place Java, VBScript, or other scripting code directly into the same page as the HTML content. Obviously, this implies maintenance challenges as the server pages now contain content requiring the skills of both content developers and programmers. They must check that each updating of content to a specific server goes through without breaking the scripts inside the server page. This check is necessary because the server page is cluttered with code that only the business developer understands. This leaves the presentation developer walking on eggshells out of concern for preserving the work of the business logic developer. Worse, this arrangement can often cause situations in which both developers need to modify a single file, leaving them the tedious task of managing file ownership. This scenario can make maintaining a server pages-based application an expensive effort (which undermines many of the achievements related to server pages). Listing 1.2 A tightly coupled page

Welcome to my dot-com (some program code)

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services

CHAPTER 1 The big picture Listing 1.1 Sample

Dynamic web servers Another issue is the proprietary nature of the server pages. Aside from PHP (an open-source software freely available to most web servers), server pages technologies are only available on a single server (e.g., server side JavaScript on Netscape servers) and sometimes even only on a single operating system (ASP, which relies heavily on COM and is, largely, Microsoft-only). This means that you usually cannot leverage your ASP experience on Netscape and UNIX. Furthermore, the API used to extend the scripting language with low-level services is very different among the various systems; thus, porting complex projects requiring custom language extensions is very difficult. Simply put, when using server pages you lock yourself in with a vendor, which is often an unpleasant arrangement. These disadvantages are insignificant compared to the most egregious shortcoming of server page technologies: the lack of separation between your application s business logic and the presentation logic that displays it. This unfortunate weakness isn t the problem of server page mechanisms alone, in fact all the mechanisms we ve explored thus far have suffered from it. Before we discuss the way to overcome this hurdle we should define the need for separation. 1.3.4 Separating business and presentation logic One of the greatest challenges in web development is in cleanly separating presentation and business logic. All of the web server extension methods we ve looked at so far have suffered from this obstacle. What does it mean to separate these layers? To start with, we can partition any application into two parts: Business logic The portion of the application that solves the business need (e.g., the logic to look into the user s account, draw money, and invest it in a certain stock). Implementing the business logic often requires a great deal of coding and debugging, and is the task of the programmer. Presentation layer Takes the results from the business logic execution and displays them to the user. The goal of the presentation layer is to create dynamic content and return it to the user s browser, which means that those responsible for the presentation layer are graphics designers and HTML developers. If applications are composed of a presentation layer and a business logic layer, what separates them, and why would we want to keep them apart? Clearly there needs to be interaction between the presentation layer and the business logic, since the presentation layer presents the business logic s results. But how much interaction should there be, and where do we place the various parts? At one extreme, the presentation and the business logic are implemented in the same set of files in a tightly coupled manner, so there is no separation between the two.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services

CHAPTER 1 The big picture Listing 1.1 Sample

CHAPTER 1 The big picture Listing 1.1 Sample ASP fragment that generates dynamic content < % @Language = "VBScript" %> < % If Request.ServerVariables("SERVER_NAME") = "localhost" then %> You asked for the server located on your local machine. < % else %> You asked for the server < %= Request.ServerVariables("SERVER_NAME") %> < % end if %> This fragment obviously contains standard HTML, with the exception of special text found between the < % and %> characters. That special text is the script the server executes when this page is requested. In this case (and in most ASPs), the script is written in Microsoft VBScript language. This particular ASP fragment creates dynamic content which is affected by the value of a server variable, SERVER_NAME. You should be able to make out the conditional logic in this fragment, which dictates that if the value pointed to by SERVER_NAME is the string localhost , a message is returned to the user stating they are on their local machine. Otherwise, a different message is returned, including the value of the variable SERVER_NAME. This logic is pretty easy to identify, even if you ve never before seen ASP. The scripting languages for server page technologies have been designed to keep the entry barrier low, so that both beginning programmers and ambitious HTML developers can readily grasp the syntax. To further simplify the generation of dynamic content, server pages technologies provide a means of extending the core scripting syntax with objects that enable low- level functionality, such as database access and email support. Most server pages environments ship with built-in support for popular databases, which greatly simplifies the task of generating data-driven web applications. This simplicity, coupled with the fact that the server does not have to repeatedly open (and initialize) new processes, makes server pages technologies the foundation of many web applications. Yet, as you may imagine, this simplicity comes at a price. Server pages drawbacks A number of issues must be admitted in any complete discussion of server pages. To begin, there is the matter of speed. Server pages-based applications are slow relative to the server API counterpart. Yes, the programmer s productivity is enhanced, but the performance decline makes it obvious there is room for improvement.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services

CHAPTER 1 The big picture Generate content (say

Dynamic web servers The extensions need to be developed in a low-level language such as C or C++. This places the extension development knowledge bar at a fairly high level. A bug in an extension can often bring an entire web server down. This means extensions must be tested thoroughly and the extension developer must be an experienced developer. The overall result is that developing a server API extension is very expensive (in terms of salaries and development time), rendering server API inapplicable for many tasks. Some other extension technique was needed. We ll see in chapter 2 how JSP and its custom tags can be developed with far more ease than a server API extension; namely because they are written in the well known, standard Java language. This fact alone addresses all the weaknesses of an API approach since the Java is fairly high-level, strictly standard, and robust enough that a simple bug won t blow up an entire web server, and JSP greatly simplifies the generation of dynamic content. NOTE We are not saying that the server API is useless. In fact, many interesting problems (e.g., content filtering and redirection in the native web server) can only be solved within the context of the server API. Moreover, most of the extension techniques that we are about to see use the server API to link to the web server. This API is, however, more suited for low-level tasks and too cumbersome and costly to use in developing full-scale web applications. 1.3.3 Server pages techniques The goal of the server pages approach to web development is to support dynamic content without the performance problems of CGI, or the difficulty of using a server API. The most popular server page approaches today are Microsoft Active Server Pages (ASP), JSP from Sun Microsystems Inc., and an open-source approach called PHP. Server pages development simplifies dynamic web development by allowing programmers to embed bits of program logic directly into their HTML pages. This embedded program logic is written in a simple scripting language (which, depending on what your server supports, could be VBScript, JavaScript, Java, or something else). At runtime, the server interprets this script and returns the results of the script s execution to the client. Let s look at an example of ASP in listing 1.1.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services

CHAPTER 1 The big picture Generate content (say

CHAPTER 1 The big picture Generate content (say read a static file) A request arrives Send results to the user Call method in module Is the requested file handled by a module? Yes No Figure 1.3 Executing a module with a web server API servlets or JSPs they re based on), the industry addressed the performance shortcomings of CGI by introducing a new web extension mechanism, the web server API. 1.3.2 Web server APIs In a web server API, the application developer first writes a loadable module (a DLL in Microsoft Windows, a shared object in UNIX) that follows the API definition for the specific server. The web server loads this module on startup, and calls it whenever a user makes a request which should be handled by that module. Popular APIs include Netscape Server Application Programming Interface (NSAPI) for Netscape Enterprise Server, and Internet Information Server Application Programming Interface (ISAPI), though all popular servers have one. Most web servers use a configuration file which contains directives specifying which modules to load and the requests a particular module should handle. By loading the extension module directly into the web server, we gain unmatched performance since invoking our extension is merely a function call. Unlike CGI, the function calls take place within a single process that is already running; namely, the web server process itself. We can also save state inside the web server address space. This allows us to save the results of expensive processing (such as objects that are slow to initialize) in a central location so that they can be shared by requests instead of being created over and over again. These two features alone address both of the major shortcomings we saw with CGI. Server API drawbacks Oddly enough, the unmatched performance available by writing to the web server API did not win this extension method the popularity of CGI or other extension techniques that we will discuss. It failed to catch on for several reasons: Each server has a different API. This means there is no standard that can be learned once and applied across servers.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services