EETimes

Embedded Systems October 2000 Vol13_11

Issue link: http://dc.ee.ubm-us.com/i/71842

Contents of this Issue

Navigation

Page 49 of 181

The WAP model is based on a scaled down version of the standard Web model. Typical cl ient applications are web browsers such as Netscape avigatOl- and Inte rnet Explorer. Browsers make information avai lable to a user by nav- igating through hypertext links and forms. Unseen client applications may contain Web-enabled connectivity without the use r really knowing it. An example is an application that logs data from a remote location and posts the data on a Web page. The client application accesses the data posted on the Web page and presents the data to the user in what appears to be a stand-alone application. erver process requeslS from mul- tiple clients across the Web. Desktop clie nts typically request serve rs to retrieve Web pages, navigate hypertext links, and access database. Database access is achieved via the Common Gateway Interface, or CGI. A server invok s a CGI script using client data to access, process, and return data to the client. A proxy acts on behalf of the clien ts it se rves, and behaves as a sort of fun- nel. Clients usually reside behind fire- wal ls. Proxies receive requests from clients behind a firewall and wait for re ponses outside the firewall. Al l transactions go through the proxy, and proxies may flag 01- rej ect some transactions. Proxies can also be advantageous, especially in inu-anets. An intranet is an internal network that utilizes In ternet protocols. Proxies can cache docume nts and Web pages, allowing faster access to frequently I -equested information. Web browsing on wireless non-pes Web technology is fairly mature on PCs and workstations, mo tly due to tile capability and speed of desktop machines and the rapidly evolved fea- tures supported by HTML. The Internet and tile World Wide Web are based on wired technology. [t's a different story on non-PCs, such as cellular phones and wireless PDAs. The computational power and display capabilities of handheld wire- less devices are feeble compared to desktop devices. Having a four-lin e LCD display on a cellular phone witll primitive graphics capability seems extravagant. PDAs are mild exceptions with bitmapped images and touch- screens. A desktop computer with a Megabit connection makes the Internet seem blazingly fast, but be aware that a cellular phone may be able to receive data only as quickly as 300bps. Witll the throughput, display, and computational limitations of hand- held devices, running a browser tllat interpre ts and displays complex HTML information is out of tile ques- tion . The alternative is to create a new, scaled down, highly structured lan- guage and protocol for limited capa- bili ty wireless devices and still enable Web access. That's the idea behind WAP. WAP architecture fundamentals The WAP model is based on a scaled down version of the standard Web model. The WAP model is consistent with most Web architectural conven- tions, such as standard naming via URL and standa rd Content typing and content form ats are consistent with Web content typ ing and format. This means that WAP applications and types, such as lists, images, and display formats, are direct analogs to Web applications. A card is the fundamental WAP dis- play unit. A card re prese nts one screen's wortll of data. The basic data can be text, a form , a single-bit bitmap, or a menu. There can be one or more cards per WAP client applica- tion. Multiple cards reside in a deck. A WAP browser, or user agent, decides 48 OOOBER 2000 Embedded Systems Programming how the information in a card is ren- dered on its particular display. The rendering and application functionali- ty resides in the top-level application layer called tile Wireless Application Environment (WAE). The WAE encompasses a micro-browser, sup- ports code written in WML and WMLScript, and al 0 includes the Wire less Telephony Application (WTA). The WTA conta ins direct access to telephone related functions. Instead of calling the WAP browser a micro-browser or client program, the WAP documentation calls it a User Agent. WML The Wireless Markup Language (WML) is derived from the eXtensible Markup Language (XML). XML is itself a markup language de rived from the Standard Generalized Markup Language (SGML), best known as the daddy of HTML. XML allows designer to custom protocols. de ign docume nt types. Whe reas everyone developing in HTML is bur- dened with its all-inclu ive nature, XML can be used to create any type of document. HTML must be all things to all application domains. Not so with XML. Custom languages for specific application domains can be created using XML. Rather than accommodat- ing everyone, an XML-based markup language can servi ce a specific domain, such as limited resource wire- less devices. This reasoning prevailed when the decision was made to base WMLon XML. WML is designed with small in mind: a small display, a small amount of memory in the target device, and a small amount of computing power. WML applications are composed of cards that reside in decks. A deck can contain multiple cards. A card con- tains units of user interaction. These units of interaction are simple menu selections, text entry fi eld , text for- mats, and the like. WML also provides an event-handling capability that is used to navigate from card to card

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11