Working with Mobile Web Services - Using the Mobile Cloud - Cloud Computing Bible (2011)

Cloud Computing Bible (2011)

Part V: Using the Mobile Cloud

Chapter 21: Working with Mobile Web Services

IN THIS CHAPTER

Learning about Web services

Using Web sites on mobile devices

Understanding how services are discovered

Understanding push technology

Mobile devices use more network traffic in consuming Web services than do fixed-line systems. Most people find that their use of Web services is increasing dramatically year after year. Indeed, as this chapter shows you, the Web is becoming a source of rich content for mobile devices.

Mobile devices present some challenges for Web services. Specifically, their device characteristics don't match the resolution and detail of desktop computers. For that reason, many service protocols are specifically aimed at providing the necessary translation required to make Web sites look good on mobile devices.

To use a Web service, a device needs to know about that service and know how to access it. This chapter describes some of the methods used for Web service discovery based on standard methods.

Mobile devices can transmit specific information about the condition of the device and its user. This information, when properly parsed and logically analyzed, can be used to create context-aware services. Location-based services are offered as the prime example of this feature.

Push services are an important mechanism in e-mail and in certain forms of publishing. In this chapter, you learn about different push services, including how BlackBerry does push and the Lemonade Profile. The Short Message System (SMS) is a form of message push service and is described in this chapter. The chapter is rounded out by a look at the Wireless Access Protocol (WAP), which is a push mechanism for publishing Web site data that is device-specific. You also learn about some of the data synchronization standards used in mobile technology.

Understanding Service Types

Mobile Web services are those in which information is transferred between applications (especially a browser) and services over an Internet connection. As you saw in Chapter 20, more information is transferred over mobile connections now than is transferred over fixed lines. Early cell phones and feature phones depended upon native applications for most of their enhancements. Web services have made the development of mobile Web applications much easier and more powerful, and thus these types of applications are steadily replacing native applications that are usually platform-specific and proprietary. The tendency to include sensors of all types in mobile devices is making the mobile Web a very rich service indeed.

Mobile interoperability

In the current market, the mobile Web is fractured into many different competing operating systems and proprietary hardware. This isn't going to change anytime soon, and the market will probably be supporting many different products for years to come. The fact is that the approach Apple has taken with the closed iOS products, the iPhone, iTouch, and iPad does tend to make these devices more reliable, and because they are more predictable, they are easier to use. For these benefits, you tender a certain amount of flexibility. The lack of expandable storage on these devices is a classic example of vendor lock-in.

There are open-system alternatives to systems like the iOS or BlackBerry OS. The two best examples are the Android OS and the Symbian OS. Open-system hardware and software tends to evolve more quickly than proprietary systems because there are more players and the work tends to get wider review. There's also a higher emphasis placed on interoperability in open systems.

One effort to make mobile devices more interoperable is the W3C Mobile Web Initiative (http://www.w3.org/Mobile). This initiative sought to make browsing the Web with mobile devices more reliable by setting standards that Web site designers can use to make their sites mobile-friendly. There are guidelines on the Mobile Web Initiative Web site that you can read on best practices, as well as a site-checking tool that does an assessment of a site for you.

The problem with mobile site optimization is that many different devices exist, and it is impossible to support more than a few of them. These factors need to be addressed, among others:

• Variable screen sizes and resolutions

• Slow transmission over the connection and limited rendering speeds on the device (something that is improving over time)

• Different methods of navigation through the interface

• Limited use of windows and lack of some standard graphical user interface controls

• Exclusion of certain file formats such as PDF, rendering engines such as Adobe Flash, and cookies

• Message size limitations

• Nonstandard and often onerous transmission costs

Vendors approach the problem of interoperability in several ways. A common way is to create individual sites within a Web site for different devices. Content is served up to a device based on the device's identity and content negotiation. With the rise of smartphone applications, many organizations are creating application frontends to their sites. To my mind, the best of these sites have been created by the major news organizations: BBC, CNN, AP, and the New York Times.

Compare the front page for the Web site of the New York Times on a standard 1024x768 resolution monitor in Figure 21.1 versus the same content displayed on an Apple iPhone 480x320 resolution screen. These two screenshots taken of the page (http://www.nytimes.com/) on September 1, 2010, illustrate the different approaches that designers have taken to show dense content on different resolutions screens. While the computer display is loaded with ads, the iPhone app displays on a single large advertisement. The content is displayed on the application with much less leading content, and in a strictly hierarchical navigational system. Each story is a link in the form of a large button to the full text of the story. Many large links on the display have been replaced by fewer, but easier to select, buttons. There is also less use of graphics and images on the application.

FIGURE 21.1

The New York Times home page on a standard computer monitor (left), and the New York Times home page on the same day within the iPhone 3g application (right)

9780470903568-fg2101.eps

One approach to improving interoperability that was considered by the Mobile Web Initiative's Device Description Working Group (http://www.w3.org/2005/MWI/DDWG/) was to create a database of device characteristics, called a Device Description Repository. This repository would then be used in concert with the DDR Simple API to modify content so screen size, markup language, and image format support is delivered to a device correctly. This work ended in December 2008 with a recommendation for adoption to the W3C, but it hasn't resulted in an industry standard, although it might be incorporated into some later work.

A specific top-level domain has been created for the producers and consumers of mobile services and products called .MOBI, which is maintained as a registry called the Mobile Top Level Domain (mTLD). The purpose of this domain is to create sites that render correctly on mobile devices. This domain is a sponsored domain and was created by a group of companies in the mobile space that include Ericsson, Google, GSM Association, Hutchison Whampoa, Microsoft, Orascom Telecom, Samsung, Telefónica Móviles, Telecom Italia Mobile, Syniverse Technologies, T-Mobile, Visa, and Vodafone. The domain received ICAN approval in July 2005.

Figure 21.2 shows the dotMobi (http://mtld.mobi/) registration service for this domain. Afilias (http://www.afilias.info/) acquired the registry service in February 2010 and serves as its DNS service provider.

dotMobi participated in the work of the Mobile Web Initiative and has a tool called Ready.mobi that analyzes Web sites and scores them. However, dotMobi doesn't mandate that a Web site use any specific technologies, only that it be mobile-device-friendly.

FIGURE 21.2

The .MOBI domain is specifically set aside for mobile Web products and services; shown here is the dotMobi registration service home page.

9780470903568-fg2102.tif

The establishment of the .MOBI domain has been subject to criticism from the W3C's director, Tim Berners-Lee, on the grounds that the Web sites on the Internet should be device-independent. It is suggested that a better mechanism for content compatibility on the mobile Web is to use content negotiation, cascading style sheets, or other devices. In HTTP, content negotiation is a mechanism by which user agents can be served a different document or file format based on going to the same URI. For example, if a device goes to the URI and is recognized as belonging to a supported type, then the program logic serves up the appropriate content.

Another effort aimed at promoting standards on mobile networks is the Open Terminal Platform (OMTP; http://www.omtp.org/). The group was an industry association formed in 2004 by several mobile vendors, including Huawei, LG Electronics, Motorola, Nokia, Samsung, and Sony Ericsson. On July 1, 2010, OMTP became part of the Wholesale Applications Community (WAC; http://www.wholesaleappcommunity.com/), a group that exists to promote the market for mobile applications. The members of the WAC are AT&T, Deutsche Telekom AG, KT, Orange, Smart Communications, Telecom Italia, Telefónica, Telenor, and Vodafone; the sponsors are Ericsson and Nokia. Figure 21.3 shows the WAC's home page.

The OMTP worked in many areas, including creating universal charging standards for micro-USB devices, mobile security, position measurements, device management, and standardized APIs. They have an initiative called the BONDI API (http://bondi.omtp.org/) based on a set of JavaScript APIs and a security framework based on XACML for creating mobile interfaces and subsystems. An open-source project has released an SDK (http://bondisdk.org/) for this API. BONDI, which is named for the Australian beach near Sydney, is one of several efforts to create standard mobile APIs. Two others are:

GSMA OneAPI (http://www.gsmworld.com/oneapi/)

Joint Innovation Lab (JIL; http://www.jil.org/)

FIGURE 21.3

The Wholesale Applications Community is an industry group aimed at standardizing and promoting mobile applications.

9780470903568-fg2103.tif

Performing Service Discovery

Web services are useful only if they can be discovered by mobile devices and accessed by those devices by mutually supported protocols. If protocols are standard and open, the chances of being able to exchange information is increased. Web services are a form of publishing: In some cases, they involve messaging; in others, they use a publish/subscribe metaphor; and in other cases, they are broadcast. The nature of the protocol supports the mechanism for data transfer that is required.

One standard for publishing a Web service that is used in cloud computing and contributes to the Service Oriented Architecture (SOA) is the Web Service Description Language (WSDL). This protocol was described in Chapter 14. In WSDL, the service is described in terms of an interface or endpoint that can be accessed to send information to and get information back from the service.

Note

The Web site for these various OASIS Web service discovery protocols may be accessed at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-dd.

Several mechanisms exist for aggregating WSDL documents into a searchable form. The Universal Description, Discovery, and Integration (UDDI; http://www.oasis-open.org/committees/uddi-spec/) service is an open registry of business services. UDDI is an OASIS standard that is searchable and is in the XML format. Documents stored in UDDI conform to the Web Service Inspection Language (WSIL) format, which makes the information searchable. IBM has a UDDI federated search technology in its Business Explorer for Web Services product (BE4WS; http://www.alphaworks.ibm.com/tech/be4ws).

UDDI publishes information in the following forms:

• White pages with identification information

• Yellow pages with industry categorization based on standard schema or taxonomies

• Green pages that specify the service endpoints

The WS-Discovery service provides a means for advertising services on small networks using a multicast protocol. Typically, the service is delivered using SOAP over UDP. WS-Discovery is an OASIS standard and is used as part of network discovery in Windows (WSDAPI), in the Device Profile for Web Services (DPWS), and in the Windows Rally technologies. Microsoft uses Windows Rally to provision network nodes such as computers, access points, printers, and other network-connected devices.

ebXML, which stands for Electronic Business using eXtensible Markup Language is a joint standard of OASIS and UN/CEFACT and aims to create a searchable global registry of business services. The standard is maintained by the freebXM (http://www.freebxml.org/) initiative.

Context-aware services

As mobile computing has grown, each mobile device contains and is capable of transmitting a large amount of information concerning the condition or state of the device and the user who carries the device. When parsed properly, this information can provide intelligent systems with not only the user's identification, but the context in which that user finds himself.

Location is the prime example of context. When we search for something near us, the search engine returns results that are location-based and thus have context. When a phone transmits its GPS coordinates to a service, that service may be able to compare that location to the customer's registered home or work address and then send information appropriate to each environment back to the user. Or more specifically, if a phone transmits its location as being in a specific building or room to a service, then the service can display a map showing where the nearest restroom is or where the light switches are located, or it can provide instructions for how to work the overhead display in the room. You can see how this very tailored and specific information could be incredibly valuable and useful.

Note

Keith Jones, an SOA Designer at IBM, published an article, “Building a context-aware service architecture” (http://www.ibm.com/developerworks/architecture/library/ar-conawserv/index.html?ca=drs-), that goes into more detail on this topic and addresses different approaches.

When a mobile user is connected to her mobile service, she is exchanging two different sets of information:

Physical context: Information derived from measurements made from the mobile device or its sensors

Logical context: Information derived from the user or from the manner in which the user has interacted with services over time

As an example to demonstrate the difference between the two, the identification string associated with your cell phone's SIM card is a physical attribute, and your service login ID and its associated password are a logical attribute. Physical context provides location, ambient device conditions, device states, and more. Logical contexts are information about the purpose a location serves, a digital identity and its associated attributes, relationships, interests, past searches, Web sites visited, privileges, and preferences.

Chapter 14 covers Service Oriented Architectures. An SOA provides a set of methods for using modules to construct loosely coupled complex systems from standard parts. You may recall from that discussion that the essence of SOA is that the method of construction of the modules is abstracted out of the system and encapsulated, and what SOA requires is a standard method for exposing the services that a module provides as a standard interface exposed by an API. The API's methods remain invariant, even when the module is moved, re-architected, or subsumed into another module. SOA requires a standard messaging protocol and a form of federated database system.

In a Web service, the mobile client plays the role of a service consumer and the Web service is the service provider. In Figure 21.4, a system for processing contextual information is shown, based on the ideas of a Service Oriented Architecture.

A system of this type provides a much richer environment in which to respond to requests and allows both service providers and content providers to either narrowcast or tailor information for a specific user based on his current context. The Context Logic Processor plays the role of the orchestrator providing programmed logic that works with the data parsed by the Context Parser.

The Context Parser takes all the input data (digital signals in many cases) and applies a logical schema to create the needed structured objects for the Logic Processor's use. This infrastructure can be placed in the cloud. The concept of creating a structured representation of concepts and their relationship in a domain is referred to as ontology. Ontology is a formal way of specifying a shared abstraction. Ontologies are used in all fields of computer science and are at the heart of efforts to create the Semantic Web, in artificial intelligence, library classification scheme, and so on. The specific ontology that applies to a mobile SOA is the Web Ontology Language (OWL; http://www.w3.org/TR/owl2-overview/), and the formal semantics and Resource Data Framework (RDF/XML; http://www.w3.org/TR/rdf-primer/) serializations are under active development.

FIGURE 21.4

A Service Oriented Architectural approach to processing requests using contextual data from mobile users

9780470903568-fg2104.eps

MEMS

MEMS stands for microelectromechanical systems and is a class of very small sensor or actuator devices where small mechanical systems are driven by electricity to indicate a position. MEMS as a class can be between 1 and 1000 micrometers in size, and they are packaged into components that often include a microprocessor, memory, and other components. Several MEMS are packaged in smartphones, and their numbers and complexity are growing over time.

The incorporation of low-cost geo-sensors in the form of Global Positioning System (GPS) chips into mobile devices opens the mobile user to a whole range of services based on the client's location. This type of service is sometimes referred to as context-aware services, but location is just one context that can be used in processing client requests and returning relevant information. There are many more.

The following are built into the latest cell phones:

• Accelerometers for measuring relative motion changes

• Gyroscopes

• Image sensors in the form of CCD chips

• Proximity sensors

• Light sensors

• Sound sensors

• Compasses

• Pressure sensors (barometer)

• Thermisters (resistance thermometer devices or RTDs)

The iPhone uses the proximity sensor to turn the screen off when a user puts the phone to his face. The Droid, Nexus One, and iPhone have dual microphones so they can perform Active Noise Cancellation (ANC). These sensors have the ability to measure the physical world around the user and translate an analog signal into a digital one that can be used to enhance a cloud-connected user's experiences. These types of devices are called Micro-Electro-Mechanical systems or MEMS for short, and the MEMS industry is experiencing explosive growth.

MEMS are everywhere you look. They are in smart watches like the Casio Pathfinders, cars, the Wii-mote, Rock Band instruments, on the suits actors wear to do green-screen work, in Qualcomm's mirasol Display (http://www.qualcomm.com/qmt/) used for e-readers, and (as previously mentioned) in smartphones. Without MEMS, smartphones would be stupid phones, and smartphones are driving both innovation and demand for these 21st-century devices. MEMS are turning smartphones into the ultimate digital Swiss Army knife.

Location awareness

The idea behind context-aware services is that your device is constantly being polled for or sending data from its sensors that indicate the condition of the device. For a desktop that never moves anywhere, knowing the location is a one-time thing. Suppose you type a search in Google on your desktop like this:

pizza 02052

Google returns a search that shows you the pizza joints in that ZIP code. You can see how this kind of search would be helpful for shopping, social networks, services, and other location-based information.

However, when you are motoring around with your smartphone, laying rubber to the road, and cutting the night with your beams, you don't need to tell Google what your zip code or location is because your phone has already given that information to Google's Web service. If you're lucky, your iPhone might ask you if you want to share your location with this service, but usually the information is simply passed on through with your query. There are many examples of location-aware services based on GPS data, where your location is found to within a few feet through the triangulation of three or more overhead satellite distances and positions.

Skyhook Wireless operates services, as shown in Figure 21.5, that are based on a Wi-Fi Positioning System (WPS). The advantage of WPS is that there are hundreds of millions of Wi-Fi access points worldwide and they are closer to the mobile device, so there isn't the significant lag time during triangulation that you experience with GPS. Skyhook holds a patent on a hybrid positioning system it calls XPS, which uses several location technologies in concert: WPS, GPS, and cellular tower triangulation to obtain accurate user location to within a few feet and taking just a few seconds.

FIGURE 21.5

Skyhook Wireless (http://www.skyhookwireless.com) provides a location service that identifies a Web site visitor's location.

9780470903568-fg2105.tif

The system uses a large reference database of Wi-Fi access points and cell tower IDs, raw position data from each location source (a signal), and the company's proprietary algorithm to locate the device. The XPS system is constantly polling locations to update them and recalibrating data points to improve accuracy over time. Failing that, the system performs a location analysis based on your IP address and your known service provider.

Loki (http://www.loki.com) has a Java API that works with the Skyhook network and its browser plug-in to locate users for subscribing Web sites.

Push services

Push services are a technology where the transaction is initiated on a server and sent automatically to the client. The opposite of a push is a pull technology, in which the client polls for and requests a transaction. In some instances, push can be a form of publishing and is described as conforming to the publish/subscribe model. The following services are examples of push technologies:

• Automated software updates

• Comet, an Ajax application data transfer (Comet uses either HTTP streaming or long polling, described below.)

• Instant Messaging

• e-mail

• HTTP streaming (also known as HTTP server push)

• Java pushlet

• RSS services

• Software installations

• Teleconferencing

Not all push technologies used in mobile applications are server-based. The IRC protocol and the XMPP IM and VoIP protocol are two examples of peer-to-peer push technologies. Bidirectional Streams Over Synchronous HTTP (BOSH) is a transport protocol that, when combined in XMPP Over BOSH (http://xmpp.org/extensions/xep-0124.html), can be used for push service. The XMPP PubSub extension is how Apple creates a push service for MobileMe.

Cross-Ref

WAP Push is covered in the section “Defining WAP and Other Protocols” later in this chapter.

Push e-mail is the penultimate example of a push service. In push e-mail, the service is always connected to the client, and it sends out to the client more or less immediately any new e-mail that arrives at the server. In the parlance of system design, the active transfer process is referred to as “push,” the server is called the Mail Delivery Agent (MDA), and the client is called the Mail User Agent (MUA). The concept of push is that the mail is sent without the client asking for it, whereas the process of sending mail when the client asks for mail is referred to as “polling.”

The well-known e-mail protocol POP3 is a polling protocol; IMAP can support both push and polling. Push-IMAP is a push technology, as is the SMTP protocol. Push-IMAP (http://tools.ietf.org/html/rfc3501) stands for the Push extensions for Internet Message Access Protocol (P-IMAP); it is an addition to the IMAPv4 protocol that was added for mobile clients. P-IMAP allows an IMAP server to automatically keep a connection alive and update using what essentially amounts to a heartbeat signal and response. These signals are short and compressed, can contain commands and macros, and can be sent in three ways: using the IMAP IDLE command (http://tools.ietf.org/html/rfc2177), as SMS, or using WAP Push. P-IMAP contains a feature that sends rich e-mail in a manner similar to SMTP.

Some polling mechanisms set the polling interval so short that the system appears to behave as if it is a push technology, so it can sometimes be hard to tell the difference. With a technique called long polling, the client requests information from the server, and if the server doesn't have information to send back to the client, it queues the request until a response with data is possible. When the server sends a response, the client typically sends another request to add to the queue, thus maintaining the apparent connection. A mobile device that is polling is constantly activating its antenna and network services and draining its battery. This is one reason that the BlackBerry and its push service gives a noticeably longer battery life between charges than other smartphones, Blackberry turns on its antenna only when required.

Both push and polling have pluses and minuses associated with them. Polling offers the advantages that the client need not be permanently connected to the network and that the MDA (Mail Delivery Agent) can identify the location of the client from the details of the query. However, polling requires the client and the server to engage in handshaking, so it imparts lots of overhead to mail transfers. Whereas a delay of a minute or more doesn't matter for many applications, for some applications—like stock market information—time is critical.

The following are examples of services that use push e-mail:

• Apple MobileMe (http://www.apple.com/mobileme/).

• DataViz Roadsync (http://www.dataviz.com/) for Android and Symbian S60 using Microsoft Exchange ActiveSync.

• Fifth C BlacMail Server (http://www.fifthcsolutions.com/).

• Google Gmail (https://mail.google.com/).

• Mail2Web (http://www.mail2web.com/).

• Microsoft Exchange ActiveSync (http://www.microsoft.com/windowsmobile/activesync/default.mspx).

• Microsoft Windows Mobile (http://www.microsoft.com/windowsmobile/).

• RIM's BlackBerry Enterprise Server (BES; http://na.blackberry.com/eng/services/server/5/). BlackBerry devices use their own proprietary e-mail protocols.

• Seven (http://www.seven.com/). Seven provides push e-mail, messaging, and sync for multiple mail and IM services and devices.

• Yahoo! Mail (http://mail.yahoo.com/).

The immense popularity of the BlackBerry devices' push e-mail system has led to a widespread adoption of this technology by many e-mail service providers. Thus, you also find push e-mail with Push-IMAP on some Nokia Symbian S60 and its Intellisync Wireless Email, Sony Ericsson Smartphones, and Cybershot phones among others.

The BlackBerry Push Service

Developers use the BlackBerry Push Service to push application updates, images, text, audio, and other content to BlackBerry users using Java applications or BlackBerry Widgets that they develop using the service. The Push Service transfers up to 8KB messages directly. If the content is larger than that, the content provider sets up its system so the notification is a push service and the device downloads the data from the content provider.

BlackBerry Push Service uses the following steps:

1. Content provider sends a push request to the server.

2. BlackBerry servers send a response back to the content provider.

3. BlackBerry servers push the data out to BlackBerry clients.

4. BlackBerry clients send a response to the BlackBerry server that the message was received.

5. BlackBerry servers forward the acknowledgement to the content provider.

6. The content provider sends a read notification to the BlackBerry server.

Figure 21.6 illustrates the BlackBerry Push service.

Note

You can read more about the BlackBerry Push Service at http://na.blackberry.com/eng/developers/javaappdev/pushapi.jsp.

FIGURE 21.6

An illustration of the BlackBerry push technology

9780470903568-fg2106.eps

The Lemonade Profile

The Lemonade Profile (http://www.lemonadeformobiles.com/) uses a set of e-mail extensions to provide access to mobile devices. It builds on the IMAP protocol for delivery and on the Message Submission SMTP profile. The Lemonade Profile is an alternative mechanism for push e-mail. When a message is available, a timely notification is provided and the Mail Submission Agent (MSA) used in SMTP can be used to retrieve the e-mail from an IMAP data store. The advantage of the Lemonade Profile is that it uses both IMAP and SMTP and can be used by any IMAP client.

This mechanism is an alternative to a Push-IMAP specification, but uses instead a combination of short notification and the IDLE command in IMAP. The Lemonade Profile is a specification of the IETF as RFC 5550 (http://tools.ietf.org/html/rfc5550). A Push-IMAP specification has been developed but not standardized.

Using SMS

The Short Message Service (SMS) is a text-notification service that has evolved into a primary communications protocol for near-real-time message passing. SMS, or texting, forms a secondary method for mobile users to communicate with one another, and it's valuable because it occupies a middle ground between an Instant Message and a Chat. Internet Service Providers have noticed a drop in e-mail volume over the past years that they attribute to the widespread use of SMS. The majority of cell phone subscribers have SMS text-message accounts.

The word short refers to the limitation of the number of characters that can be sent in a single message. A message can be only 140 octets (or 140 * 8 bits = 1120 bits).

This maximum size in characters is as follows:

• For 7-bit characters (upper ASCII), which includes numbers, letters, and symbols, the limit is 160 characters.

• For 8-bit characters (full ASCII), the limit is 140 characters.

• For 16-bit character representations, like those used by pictographic languages, there's a lower limit of no more than 70 characters.

A form of SMS called Concatenated SMS or Long SMS allows longer messages to be sent using multiple packets containing a User Data Header that contains the segment number. The limit for this multipart or segmented SMS is 153 characters for 7-bit, 134 for 8-bit, and 67 for 16-bit encoding. The practice of sending this type of SMS is relatively rare.

SMS was designed to operate over the control channel during times of low traffic. A control channel is sending and receiving handshake information so the connection is maintained correctly; it also is used to send messages with commands that control phone features such as ringtones. Every so often, the control channel is synchronized and for a while no messages need to be exchanged. It is during those periods that SMS packets are transmitted. This arrangement makes SMS a very low-overhead messaging service.

SMS is a store-and-forward system for communications. In a unicast message sent using Short Message Service Point-to-Point (SMS-PP), when a phone or PC sends an SMS message, that message is sent over the control channel to a Message Controller, and then onto a Short Message Service Center (SMSC). The SMSC forwards the SMS message to a Message Controller connected to the party receiving the SMS, and then the SMS message is sent onto the recipient. If the recipient moves to another location, the SMSC can send the SMS message to the appropriate SMS controller. The SMSC keeps trying to send the message until it receives a response from the receiving party that the message was received.

An SMS message can be retained at the SMSC for many days until the message reaches its intended recipient. Also, SMS messages are retained on the sending and receiving systems in their SIM cards until they are deleted. SMS also supports broadcasting, sending the message from one person to many.

SMS is not a particularly secure method of communication. Over a GSM network system, transfers use a weak encryption. One-way authentication is also performed, which is another vulnerability. An SMS message also can pass through multiple networks, which exposes the message to various attacks, and there is no protection for a message that appears on a stolen phone. SMS over GSM is also the target of SMS spoofing, which is where a message comes from a party who misidentifies himself as someone else.

SMS is a subscription service; you can purchase a certain amount of message transfers, after which you are charged for additional messages, usually on a per-byte basis. The cost on a usage basis can be onerous. Certain plans allow for unlimited texting. While SMS is certainly convenient, you can't count on getting timely delivery with your message. It can take minutes or hours for a message to arrive. Also, basic SMS is strictly text and doesn't allow you to send media files or any other binary content.

Many of the smartphone providers offer upgrade versions of SMS, including the following:

Enhanced Messaging Service (EMS): EMS allows you to attach sounds, pictures, icons, and even formatted text with your message.

Multimedia Messaging Service (MMS): MMS supports the sending of audio, video, and even animation with the SMS text. (MMS uses a combination of WAP and SMS for its transport.)

SMS was initially developed for GSM networks. Over time, SMS has moved to 3G networks and even has satellite phone network.

Not all texting systems are SMS, even if they appear so. RIM BlackBerry and NTT DoCoMo i-mode use SMTP to send short messages. Other exceptions include NTT DoCoMo ShortMail and J-Phone SkyMail.

Some SMS services go through an SMS gateway. This service works by aggregating SMS traffic or using what is called the SS7 (Signal System No. 7) telephony signaling protocols. An SMS gateway service works by taking the messages received at the SMSC and sending those messages over aggregated or enhanced networks. An SMS gateway is more reliable and faster than SMS itself, so these services can be used in mission-critical notification systems, for businesses, and even in polling or voting. Examples of some SMS gateways include the following:

• Direct to SMSC gateway

• Direct to mobile gateway appliances

• Skype clients

• Some GSM e-mail like the M-Mail service

• Microsoft Outlook and Windows Live Messenger

• Yahoo! Messenger

To view a list of SMS gateways, see the following Web sites:

http://en.wikipedia.org/wiki/List_of_carriers_providing_SMS_transi

http://www.dmoz.org/Computers/Mobile_Computing/Wireless_Data/Short_Messaging_Service/

For most SMS users, their SMS phone number is their mobile phone number. However, some SMS services offer a short code as an SMS phone number. The short code is usually 4 to 6 digits in length and often can be reserved so the numbers represent words and phrases. Many short code numbers provide automatic services. For example, when you are given a short code and told to put the word “Haiti” or “Pakistan” in the subject line, sending the SMS to that number may make a donation to the agency of your choice and charged on your phone bill. Some companies use short codes to narrowcast advertisements. They have been used as updating services, subscription list opt-ins or opt-outs, and for many other purposes.

Defining WAP and Other Protocols

The Wireless Application Protocol (WAP) is an application-layer network protocol that allows a WAP browser on a mobile device to communicate with a WAP-enabled Web site. Data is transferred between the two in the form of the Wireless Markup Language and is specially formatted to fit on that mobile device. Web sites can be composed in WML, or the data can be automatically converted to WML.

WAP was originally created by the WAP Forum in 1997, but is now part of the Open Mobile Alliance (OMA; http://www.openmobilealliance.com). Figure 21.7 shows the home page of the Open Mobile Alliance, which is the standards body for many of the protocols described in this chapter.

WAP has had a mixed history of success. It is widely used in Asia, but has had limited success in Europe and the U.S. With the advent of MMS services (described in the preceding section), there has been a broader adoption of WAP over the last couple of years. WAP's usage has been limited due to limitations in WML (Wireless Markup Language), developer tools, and problems with being able to successfully transmit mobile device characteristics. As mobile devices get more capable and with the new versions of the protocols, some of these difficulties are being addressed.

FIGURE 21.7

The Open Mobile Alliance is a standards body administering many mobile Web service protocols.

9780470903568-fg2107.tif

WAP 1.2 is a protocol suite that consists of a number of different technologies that are designed to work over different wireless networks such as GSM or CDMA. Essentially, this WAP 1.2 serves the role of a gateway.

The WAP 1.2 protocol stack from top to bottom includes the following:

Wireless Application Environment (WAE): A set of application specific markup languages, of which WML is an example

Wireless Session Protocol (WSP): Similar to a compressed version of HTTP

Wireless Transaction Protocol (WTP): A transaction monitoring service based on a request/response mechanism

Wireless Transport Layer Security (WTLS): A public-key encryption method that is used for the same purpose as TLS and SSL before it

Wireless Datagram Protocol (WDP): Provides unreliable data transport data formatting

Wireless Data Network, GSM, CDMA, or another network type

The last update for WAP was version 2.0 released in 2002. Version 2.0 uses the lightweight eXtensible Hypertext Markup Language Mobile Profile (XHTML MP) for its modified Web page rendering. Used with XHTML MP is the WAP CSS Cascading Style Sheet. In WAP 2.0, HTTP is used for complete transport and the gateway and protocol stack described above is eliminated. There is a new specification for XHTML that is part of the release of HTML 5.

WAP Push is a form of WAP added to version 1.2 that allows content to be pushed from content providers to mobile clients using a gateway service. WAP Push works sending messages that contain the link to the WAP address over a WDP carrier such as GPRS or SMS. GSM networks don't use GPRS and must use SMS. When a WAP Push Service Indication (SI) notification is received, the user has the option to download the content using this service. Figure 21.8 shows how the WAP Push system works.

FIGURE 21.8

WAP Push uses a set of gateways to push content onto wireless clients.

9780470903568-fg2108.eps

Performing Synchronization

Data synchronization is an important Web service for mobile devices. Contact, calendar, and information on devices often need to be synchronized between multiple systems. The most commonly used standard for performing synchronization is SyncML (Synchronization Markup Language).

All or some the following data types may be synchronized by SyncML:

• Bookmarks

• Calendar

• Contacts

• E-mail

• Files

• Memos

• Music

• Photos

• SMS

• Tasks

• Video

SyncML is implemented using a SyncML server or alternatively as a SyncML hosted service. The client portion of SyncML is either a browser plug-in or client connector software. Different servers and clients allow for the synchronization of different data types. Some backup software also uses SyncML. The standard is an open platform-independent protocol maintained by the Open Mobile Alliance as part of the Data Synchronization and Device Management group (http://www.openmobilealliance.org/Technical/DS.aspx).

The SyncML protocol finds support in a number of products from major mobile software and hardware vendors. It has the advantage over standard Internet protocols. SyncML also can be used to share iCalendar data. Tables of SyncML servers, services, clients, and plug-ins may be found at http://en.wikipedia.org/wiki/SyncML.

Several proprietary synchronization technologies are in wide use. Microsoft Exchange and Windows Mobile use a technology called ActiveSync (http://www.microsoft.com/windowsmobile/activesync/default.mspx) that has gone through several development cycles. Exchange server is so widely used that many other vendors have licensed ActiveSync from Microsoft for use in their mobile mail clients. You can find ActiveSync on the Apple iPhone, on certain models of Google Android, in the WebOS operating system developed by Palm and now part of HP, and in Lotus Domino and Novell GroupWise e-mail servers. Exchange ActiveSync is a push e-mail service. An open-source version of ActiveSync called SynCE (http://www.synce.org/moin/) exists.

The desktop-to-mobile sync application Windows Mobile Device Center (previously called ActiveSync) allows a mobile client to synchronize to a desktop or Microsoft Exchange Server. Desktop ActiveSync is also supported by some third-party mail servers. Windows Mobile Device Center (http://www.microsoft.com/windowsmobile/) can synchronize the following data between Windows Mobile phones and desktops:

• Personal Information Management (PIM) data with Microsoft Outlook

• Music and videos with Windows Media Player

• Photos with Windows Photo Gallery

• Files and folders from Windows Explorer

• Favorites with Internet Explorer

Figure 21.9 shows the current version of Windows Mobile Device Center.

FIGURE 21.9

The Windows Mobile Device Center

9780470903568-fg2109.eps

Summary

In this chapter, the use of Web services on mobile devices was considered. Mobile devices present a number of challenges for Web services and Web site designers. There are many different device types, different mobile operating systems, and in many cases competing standards. Some of the methods used to standardize Web services for mobile devices were presented.

This chapter considered how mobile devices are becoming increasingly smarter and how that intelligence can be used to create Web services that are highly customized for an individual user and the context in which they find themselves.

A number of different Web services use a push mechanism for sending data to mobile devices. You learned about how the BlackBerry performs this task, how SMS uses push for messaging, the Wireless Access Protocol, and other services of this type.

This chapter ends Cloud Computing Bible, but is not the end of the story. As you well know, we are really only at the beginning of what is possible in computer science and in human/machine interaction. Computers have the potential to unify the human race, to correct human deficiencies, and to enhance the human condition. As a species, we face great challenges in the years to come. It is my fervent hope that the technologies you have read about in this book contribute to an understanding and solution to these problems so that all of us, our children, and our planet have a better future.