Application Servers

[ LiB ]  

Unfortunately I'm not certified to, nor is this book able to, fully explain how to operate an application server. For one thing, there are tons from which to choose. Luckily, the way Flash interacts with any application server is basically the same. Here I want to define what makes a web server an application server and give you an idea what it means to integrate an application server with your app.


A web server is just software running on a computer and optionally connected to the Internet. When the web server is configured properly, any user can type http:// followed by the IP address associated with the web server's Internet connection. Provided you've registered a domain name, users can alternatively type in that domain name and it will redirect to the associated IP address.

For performance reasons, you probably don't want to use the computer running a web server as your main work machine. However, it's not as though users visiting the web site will get full access to your machine. When configuring your server, you need to define a default root directory (that is, the default location to which users are sent when they type in your home web address). The common name for this folder is wwwroot . Inside that folder, you'll put your HTML documents, embedded images, and SWF files. You can structure subfolders , too. Inside my wwwroot, for example, I have a folder called clients , which you can reach by typing . Naturally, you can set up rules for passwords and thus protect certain folders and so on.

An application server runs in place of or on top of your web server. The way it differs is that when a user requests a specific page instead of just sending the user a document that's been prepared ahead of time, you can make the application server software first run a script, which then, effectively, creates a file and then sends that. Usually it doesn't produce an actual file but just sends contents of a file the same as it would if it were sending a copy of an actual file. The idea is that you can define a basic template that includes dynamic elements that don't get populated until the user requests a page. It's almost as though there is a monkey inside the machine that sees a visitor is attempting to receive a page, and that monkey opens up Dreamweaver and creates an HTML page that he saves and then sends to the visitor (all in a fraction of a second).

Listing 3.1 shows a simple ColdFusion template.

Listing 3.1. Simple ColdFusion Template
 1  <html> 2  <head> <title>roster</title> </head> 3  <body> 4  <B>All the people in the database:</B> <BR> 5  <table> 6  <cfquery name = "myPeople" datasource = "people"> 7                   SELECT * 8                   FROM PEOPLE 9  </cfquery> 10 <cfoutput query="myPeople"> 11   <tr> 12       <td width="200"><b>#first#</b></td> 13       <td width="200">#last#</td> 14   </tr> 15 </cfoutput> 16 </table> 17 </body></html> 

The user never sees this actual page; instead, lines 6 through 15 get replaced with the results of the SQL "SELECT * FROM PEOPLE" . That is, the "people" data source (basically an Access database file that you've identified as a data source) has a table called people from which all records are drawn. What actually appears in the web page is each first name (in bold) followed by each last name (followed by a line break <BR> ). Figure 3.5 shows that output.

Figure 3.5. A ColdFusion template displays this excerpt from a database.

All the people in the database:













What's wild is that if the user does selects View, Source in his browser, he'll see what appears to be a manually created HTML page (see Figure 3.6).

Figure 3.6. The actual HTML produced by ColdFusion looks as though it could have been typed by hand.


So the idea is you write code that gets processed the moment the user requests a page. In the case of displaying all records in a database, if the user comes back later and that database has been updated, he'll see the new results. I really think the image of a monkey taking orders and producing HTML pages by hand is the best one to understand how application servers work.


There are just a few more concepts to make sure you understand servers generally . First, application servers operate on the standard procedure of request and response. That is, a user makes a request, and the server responds with the answer (usually a web page generated on-the-fly ). There are ways to fake it so that users believe they are spontaneously receiving notice when changes occur. This usually involves a polling technique where a script in the client's page (written in JavaScript, for example) will periodically re-request a new web page. In this way, you might see sports scores update as they happen. In fact, you're still probably following the request and response model.

One exception is when a persistent connection is established. Although several technologies can make persistent connections, you'll learn how to do so here only using Flash Communication Server. The thing is, you can do quite a lot with request and response.

I described how a ColdFusion template can populate itself and then send out a standard HTML page to the user. In fact, you don't have to bury your code right into a single template. You may find it useful to recycle the code that grabs all records from a database and use that in several different pages. Most application servers should have a mechanism for you to do this. In the case of ColdFusion, there's CFCs, or ColdFusion Components. These are pure code files that can run scripts upon request from any template in the web site. The reason I point this out is that when it comes to Flash accessing the power of an application server, there are no need to generate an HTML page. That is, Flash just wants the raw data from the databaseit doesn't need the records formatted with bold text. In the case of the preceding ColdFusion example, Flash just wants the results from the SQL query and can handle displaying itself.

Application servers can do many things, butby farthe most common thing is accessing databases. You can either look through a database to get records that match your query or you can send values that get inserted into the database. I suppose you can do other things, such as create or modify tables in the database.

Generally, however, you either grab data or send data (or do both, such as add a record and then find out the new total number of records). Writing to a database involves little more than packing up the variables to send, invoking a remote method (on an app server), and expecting that method to take the variables it received and put them into the database.

When requesting data from a database, you can follow a couple of approaches. You can just grab everything from a table in a database and then worry about parsing through it once inside Flash. Of course, this can mean a long initial download of data, but it also means searching for information within that data will be very quick because it's done entirely inside Flash. You need to consider how large a block of data is appropriate. One benefit of making repeated requests for data from a database is that the data will always be as current as your last request. It's really sort of subjective , and you just have to look at the nature of the datahow large it is, and how timely , for instance.

The process of extracting just records that match your need is called making a query . A query is basically a matching expression such as "all records in the students table with a last name of smith." Queries return an array full of records. Each record is a generic object with property names that match the columns (or field names ) in the database. Your application server can build queries in several ways. For a concise book on using SQL (a common query language), check out Sams Teach Yourself SQL in 10 Minutes (Sams, 2001).

Besides accessing databases, an application server can act as your gateway to web services. Because the Flash Player is restricted from directly accessing a web service residing on a separate domain, you need to go through your application server. It's called making your server act as a proxy because all it does is forward your request and channels the response back to Flash. You can find simple starter files for most common application servers in the Macromedia TechNotes 16520 and 14213. (Just type those numbers into the Search field at All you do is install the files on your application server as directed, and then Flash movies (residing on your server) can use your application server as a proxy, which then makes calls to outside web services.

Finally, application servers include several other unique features that may prove useful. For example, it's usually really easy to trigger a script that sends out an email. In addition, an application server usually has logging capabilities. Also, various approaches to authentic connections are usually available. I guess I just want to point out application servers can do more than just access databases and web services.

Integrating Flash

It was tough to explain application server concepts without mentioning how Flash integrates. For the most part, separating Flash from the application server is similar to basic code data separation. The Flash movie is the presentation of data, whereas the methods on the application server are the code. Although we can't keep things totally separate, the model fits. If for no other reason, you should strive to keep things modular and separate so that you have less to maintain.

Integrating Flash with the power of your application server is mostly an issue of configuring your work environment. That is, you need a way to test locally while working but then seamlessly migrate your application to the real server when you're ready for the public. Your work environment is discussed later in this chapter; for now just realize that Flash has a different set of restrictions when on a web server than when running locally (which includes when you "test movie"). That is, on a server, a Flash movie can only access data residing on the same domain. Actually, with the Flash Player 7 there's a new restriction that the domain name has to match exactly (for example, is considered different from ). If an existing Flash 6 movie makes such a cross-domain attempt and the user is using the Flash Player 7, the user will see the dialog box shown in Figure 3.7.

Figure 3.7. This Security dialog box appears when users visit old content that doesn't abide by the new "exact domain matching" rules.


To bypass this (so that the user doesn't even see that dialog box), just set up a policy file. The idea is you can place policy files on any server (for which you control) and specify the other domains that are allowed to access your server. For example, my publisher can post SWFs on their domain that attempt to access . Provided I placed a policy file on that effectively says "it's okay to accept connections from," it'll work.

The deceptive part is that you could build a huge application that successfully reaches out to application servers and web services on other domainsbut only while you're testing. You can even successfully test the SWFs in a browser.

But not until you put the SWFs on an actual web server (say in the wwwroot folder locally) will you see it doesn't work!

I realize these are somewhat esoteric details, but you really need to know the potential and limits before you build an application.

[ LiB ]  

Macromedia Flash MX 2004 for Rich Internet Applications
Macromedia Flash MX 2004 for Rich Internet Applications
ISBN: 0735713669
EAN: 2147483647
Year: 2002
Pages: 120 © 2008-2017.
If you may any questions please contact us: