| Downloads |
|---|
| 16082.zip |
Editor's Note: Each month, this column discusses various aspects of the advanced administration of e-business sites. This month's column examines WAP and WML—specifically, how to host wireless applications on your IIS Web site.
The Internet is going wireless. Wireless technology has become crucial for transmitting and receiving up-to-the-minute information. Wireless Application Protocol (WAP) is one of the simplest implementations of wireless technologies; it's a standard for linking WAP devices to the Internet. WAP devices, such as cellular phones, Research In Motion (RIM) email devices, and pagers, have small screens that display as few as five lines of text, each line with approximately 10 characters. WAP uses Wireless Markup Language (WML), which is similar to HTML but doesn't require the use of a keyboard or mouse.
WAP devices use a WAP gateway to translate WML data into HTML data and relay the HTML data to the Web server. The server sends the information back to the WAP gateway, which converts it to WML so that the WAP device can understand it, as Figure 1, page 2, shows. How do you implement a WAP gateway? Commercially available gateways, such as the Nokia gateway, exist that let developers test and deploy customized WAP applications and services.
However, you don't need to install a private gateway, which would take a lot of time, money, and effort. Instead, you can use a WAP gateway that is available through wireless network operators, such as Sprint PCS, whose services you usually subscribe to when you buy a wireless device. A variety of WAP tools are also available that let you test your WAP applications in local mode.
WML is mainly a text-based language that uses tags. However, unlike HTML, WML has strict syntax rules because the content is compiled into a binary form when you transmit the data over the wireless network. (See Related Reading, page 5, for resources about WML, WAP, and Microsoft Active Directory—AD.) A WML document consists of a deck, which contains a series of sections called cards. Each card holds the data for one screen in a WAP browser, as Figure 2, page 2, shows. (Note that the size of a WML deck is limited. Some phones can't display a deck larger than 1.4KB.)
Changing MIME Types for IIS
You can store WML pages on your Web site; IIS can interpret these pages when you configure a few WAP MIME types. MIME types specify the format of the data sent over the Internet so the Web server can recognize and correctly process that data. To configure MIME types in IIS 5.0, follow these steps:
- Choose Start, Programs, Administrative Tools, Internet Services Manager.
- Right-click the machine name in the Internet Information Services folder, and select Properties.
- On the Internet Information Services tab under Computer MIME Map, click Edit, as Figure 3, page 2, shows.
- On the File Type dialog box, click New Type.
- On the File Type dialog box, which Figure 4 shows, enter the information in Table 1.
After you configure your WAP site and MIME types in IIS, place your WML documents in your WAP site IIS document tree, where you can access them through a WAP device or WAP emulator.
Wireless Tools
If you don't have a WAP device, don't worry. WAP emulators and software development kits (SDKs) are available that let you write, preview, and test your WAP applications from a desktop PC, simulating all aspects of a WAP device. Phone.com provides a free SDK called UP.SDK (really just a WAP emulator) that lets developers create WAP applications and includes several emulators for different types of phones.
In addition, WAP emulators are powerful tools for debugging because you can view source, which is unavailable on an actual WAP device.
You can install Phone.com's UP.SDK from the upsdkw40e.exe file, which you can download from http://www.phone.com. When you've installed the SDK, start UP.Simulator by choosing Start, Programs, UP.SDK 4.0, UP.Simulator. The simulator displays the phone emulator and a Phone Information window, which Figure 5 shows, that provides detailed error messages when there is invalid WML code. To test your WAP site, type the site's URL in the Go text box of the UP.Simulator dialog box.
The Business Case for the Employee White Pages WAP Application
Directory Services (DSs) such as AD are perfect for storing user data that needs to be available enterprisewide (e.g., email addresses, phone numbers). We wrote a WAP application called Employee White Pages that lets our employees browse the company employee list, select an employee, and email or directly dial that employee's cell phone right from their WAP device. AD dynamically derives the data.
The UI is crucial because WAP devices have so little screen real estate. We designed the opening UI of the Employee White Pages WAP application to list company employees in two ways—A through L and M through Z. The company has only 30 employees, so scrolling 15 names is effective in our case. If you work at a large company such as Microsoft, you won't want to list the 30,000 employees that represent A through L. You want to implement a simple search that restricts the amount of data returned to the device. Because a WAP device has limited input capabilities (i.e., the lack of a keyboard), you need to consider carefully how users will enter the search criteria.
You can download the five Active Server Pages (ASP) pages that make up the Employee White Pages WAP application (select_employees.asp, employees.asp, email.asp, call.asp, and do_email.asp) from the SQL Server Magazine Web site (http://www.sqlmag.com). To use the application, you need to populate the Email Address and Mobile Phone Number attributes in AD, which you can do in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in.
Under the Covers of the Employee White Pages WAP Application
When we started writing wireless applications, we discovered that they're just ASP files. Because WML has a smaller implementation than HTML and rigid and unforgiving rules of structure, writing wireless applications is fairly easy.
The first ASP file that executes in Employee White Pages is select_employees.asp, which Listing 1, page 4, shows.
Select_employees.asp renders WML to let the user choose which list of employees will appear on the WAP device. The first four statements use the Response object, as callout A in Listing 1 shows. The ContentType property of the Response object identifies the MIME type as WML for a WAP device. This statement is common to all the ASP files in the application. The next two statements use the addHeader property to add data to the HTTP header, which prevents the WAP device from caching the pages. By default, WAP devices cache everything they possibly can because, by nature, they have bandwidth restrictions. Finally, the Expires property of the
Response object sets the expiration value to 0. The expiration value specifies when the data in the user's cache for this WML page becomes invalid. This value is based on minutes. In this case, 0 means the data automatically expires.
In Select_employees.asp, the code
<?xml version="1.0"?> <!DOCTYPE wml PUBLIC _ "-//WAPFORUM//DTD WML _ 1.1//EN" "http://www.wapforum.org/ DTD/wml_1.1.xml">
defines the XML Document Type Definition (DTD) for WML. All WML files are in XML format. This DTD describes the structure of the XML document. WAP-enabled browsers understand this format of an XML document, and the DTD provides the definition to the document.
The rest of the ASP page is the XML-formatted WML document. The <wml> tag wraps the body of the document. The <card> tag wraps the content that is actually rendered to the WAP device. Figure 6 shows the results of select_employees.asp.
Now, let's look at employees.asp, which Web Listing 1 shows. Employees.asp is the heavy lifter for the WAP application. The structure and format of this ASP page is the same as the structure and format of select_employees.asp. The HTTP header information, the DTD, and the WML format (i.e., <wml> and <card> tags) are identical. What's different in this page is that we use the group returned by the select_employees.asp page with the Request object's QueryString property to display a list of employees in WML, as callout A in Web Listing 1 shows.
The ActiveX Data Objects (ADO) provider for DSs facilitates this return. The ADO provider for DSs lets you search AD and returns the results in a recordset that you can process as WML. This ADO provider demands a strange and rigid syntax, and the details are certainly beyond the scope of an article about WAP. However, you need to change some specifics to make the code work with your AD. Here are the key areas.
First, assign values to some variables that are specific to your Windows 2000 and AD implementation:
strDn = "CN=Administrator, _ CN=Users,DC= _ InterKnowlogy,DC=com" strPassword = "password" strWhere = _ "(physicalDeliveryOfficeName=*)"
StrDn represents the fully qualified distinguished name (DN) of the user who you'll securely bind to AD with. StrPassword is the password of that user. You need to change these values to be specific to your implementation. You can secure AD down to the lowest levels; although a user is authenticated, that user might not have the rights to list employee email and phone data in some implementations. By securely binding to the DS as the Administrator, the page runs under a security context that has permissions to list names, email addresses, and phone numbers. StrWhere represents the beginnings of the Where clause that we use to specify the scope of the search. The "(physicalDeliveryOfficeName=*)" criterion, which essentially means "give me everyone who has the Office attribute persisted," prevents the search from returning synthetic users such as IUSR_MachineName, Administrator, and Guest in the resulting recordset. You can change this attribute to one that is more applicable to your installation or simply leave it blank if you want the search to return all users in the recordset.
Now, apply the Root Domain Name of your AD to the proper format that the ADO provider for DSs needs. You need to change this name to a value specific to your implementation of AD:
strRootDomainNamingContext _ = "DC=InterKnowlogy, _ DC=com" strLDAPServer = "<" & _ "LDAP://" & _ strRootDomainNamingContext _ & ">"
This ADO provider for DSs lets you define the scope of your search. DSs such as AD are hierarchical. The choices are base, oneLevel, and subTree. Our AD is small, so we use the code
sDepth = "subTree"
to search the entire subtree. In large implementations, you might want to limit the scope of your search to one level to avoid potential latency problems.
Next, execute this command to get the recordset:
ocommand.CommandText = _ strLDAPServer & ";" & _ sFilter & ";" & FieldList _ Set rs = ocommand.Execute
Now that you have a recordset, you can iterate through it to display the results. In Web Listing 1, notice how we display the Last Name and First Name of the employee but href the email address. Href calls email.asp, which Web Listing 2 shows. Email.asp lets you email a person straight from your WAP device. Also notice in Web Listing 1 how we display the mobile telephone number with an href. Here, href executes call.asp, which Listing 2 shows. Call.asp makes the call for you by dialing the phone number. Figure 7 shows the results of call.asp.
Next Month
You learned how WAP technology allows anytime, anyplace, and anywhere access to information by using existing wireless devices and with little development effort or costs. Next month, I'll examine the configuration of IIS for Microsoft SQL Server access—specifically, how to leverage the power of SQL Server in HTML and ASP on IIS.
| Related Reading |
|
Here are some valuable references for information about Wireless Markup Language (WML) and building and administering Wireless Application Protocol (WAP) applications. For information about WML tutorials, go to http://www.wap-resources.net http://www.wirelessdevnet.com For information about WAP emulators and applications, check out http://www.anywhereyougo.com http://www.phone.com For details about Microsoft Active Directory (AD) and Directory Services (DSs), see these Tim Huckaby articles: "Extending the User Class in the AD Schema," September 2000 "Implementing Site Server Search Database Catalogs," July 2000 "Implementing Site Server Search on Your E-Commerce Site," June 2000 |
