he last five years has seen a revolution in mobile application development as carriers around the globe have embraced developers in an effort to raise the average revenue per subscriber (ARPU). It’s an exciting fact that, as developers, we can now tap carriers to distribute mobile applications; unfortunately, it generally means that we have to make business relationships with each carrier, a costly and time-consuming process. Some companies have made attempts to act as mobile aggregators or publishers, brokering these relationships for developers; one recent entrant to the fray is SMS.ac, whose approach is a novel mix of traditional Web programming and mobile applications.

SMS.ac permits developers to add custom applications, called mobile pods, to their portal. These mobile pods consist of HTML templates provided by your existing Web application, letting you present your content to SMS.ac subscribers within the SMS.ac service with a minimum of fuss. And there’s the potential for that to mean a lot of subscribers, as SMS.ac has already negotiated agreements with over four hundred carriers. Using the Mobile Pod architecture, you can create Web applications that appear to reside as a part of the SMS.ac portal on the Web or wireless terminal, and can interact with mobile consumers using SMS. Once a mobile pod is added to the SMS.ac portal, SMS.ac subscribers can interact with it directly on the SMS.ac home page.

Getting Started
SMS.ac makes integrating your application with the SMS.ac service easy: simply provide a front-end in a combination of HTML and their markup language, xPML (which sits atop HTML, as you soon will see) and deliver the content over HTTP. If you’re interested in using advanced capabilities of their service, such as two-way messaging via SMS, be prepared to throw in a few SOAP calls over HTTPS to get the job done. As a result, the barrier to entry is low; SMS.ac claims that existing services can be turned into production applications on their service in as little as twenty-four hours, and that’s no exaggeration.

To begin, you need a readily accessible Web application. Ideally, your Web application will support some kind of template-driven presentation, so that you can integrate the SMS.ac xPML hooks as just another presentation layer in your existing application. Because the SMS.ac service interacts with your application through the use of templates written in xPML, integration with SMS.ac is a platform-agnostic effort: you can use any platform that delivers Web content using HTTP and HTTPS, from your favorite scripting environment and Apache to Ruby on Rails or the Web server in Allegro Common Lisp. Figure 1 shows the relationship between your application server and SMS.ac.

Figure 1. Your Server and Theirs: This diagram shows the relationship between your application server and SMS.ac.

To get access to the SMS.ac xPML documentation, you should visit their developer Web site. Registration is free and enables you to view the documentation for the xPML language as well as their SOAP interface to their SMS aggregation service. With the documentation in hand, you can put together the necessary xPML interface between your application and the SMS.ac service.

When developing your application for SMS.ac, you must remember that SMS.ac will use your content via the templates you provide in response to SMS.ac requests. Thus, you’re not serving content directly to subscribers, but serving content to SMS.ac servers, which in turn forward content to providers. This is in stark contrast to the usual approach, in which your application interacts with your partners using Web services, and you provide the end communication with the subscriber (an exception to this is when using the SMS.ac messaging interface, which requires you to use SOAP over HTTPS). Your pod appears in a section of an SMS.ac user’s home page on their desktop or mobile device, as users can configure their SMS.ac page to contain several pods.

Once you develop and test the templates required for SMS.ac integration, commercialization is easy: simply return to the SMS.ac developer portal and submit the Pod for your application by clicking the “Build Pod” link. You’ll be taken to a simple HTML form which asks questions such as the user-visible name of your pod, a description for your pod, and the URL for the entry point for your pod (your pod’s home page, if you will). Once you submit your pod, SMS.ac will review your submission to ensure it meets their guidelines for quality and content, and once approved, will be available to all users on the SMS.ac home page.

xPML: The Secret Sauce Powering SMS.ac
Because you provide content to SMS.ac subscribers via templates, you needn’t interact directly with SMS.ac servers for information such as subscriber information or SMS short codes for a specific service. Instead, specific information flows to your application server via the URLs provided by the SMS.ac service when invoking your application, and you permit the SMS.ac servers to embed their data in your response content through templates. All of this is carried out using xPML, the XHTML-based markup language invented by SMS.ac.

When SMS.ac requests a page from your application server, it includes several URL-encoded data members for you to use, including the IsWap field, which is set to ‘1’ if the user is viewing the content through a handset browser. Other members include the unique ID of the subscriber and their gender. Table 1 shows the entities in a URL passed to your application server, which might look like this:

http://www.yourserver.com/pod.php?IsWap=0&smsac_size=1&smsac_oid=1234&smsac_oage=40&smsac_osex=Male&ssac_oloc=Boulder+Creek,+CA+USA&smsac_vid=31415&smac_vage=25

Of course, you can also handle additional form data from information provided by the user in the typical way as additional data members in the URL. All forms within pods use the GET method for FORM tags, and the user’s client will encode the fields of your form; when the SMS.ac Web site passes the URL with the form data on to your application server, the URL your server receives will include both the form data and the SMS.ac specific data.

Table 1. URL-encoded data members in SMS.ac-provided URLs

An obvious use of the unique ID of the pod viewer?the smsac_vid element?is as a key in your database for the preferences for that subscriber (for example, to store a town of interest for a weather application). Interestingly, the server sends two unique IDs to your application server in the URLs: the user ID of the person viewing the pod, and the unique ID of the person owning the pod. Thus, you can create two separate views of your pod, one tailored to the needs of general users, and one tailored to the pod owner or administrator. In fact, if the user browsing your pod is not a registered SMS.ac subscriber, the unique user ID will be zero, so you can actually provide three views of your content: one for the pod owner/administrator, one for registered SMS.ac users, and one for non-subscribers browsing the SMS.ac Web site. In PHP, you might write this:

   $view_mode = MODE_BROWSE;  if ( $smsac_oid == $smsac_vid )    $view_mode = MODE_PRIVATE;  else if ( $smsac_vid != 0 )    $view_mode = MODE_REG_USER;

Your responses to the SMS.ac service should be in xPML, which looks strikingly like HTML. Drawn from the SMS.ac Web site, here’s a simple example:

<(PodTitle text="Hello Mobile World!" link="http://www.sms.ac")>
Welcome Pod Developer
Hello! This pod is being shown to <(FirstName)> <(LastName)>

xPML markup is contained in the <( and )> brackets, and can consist of the following:

• Keywords, such as FirstName, which are recognized by the SMS.ac service and converted to their appropriate value before returning the page to the end user. These keywords let you access user-specific information (such as the same demographic information provided in the URLs the SMS.ac Web site sends to you) as well as things such as PodTitle, which lets you set the title of your pod as it’s displayed to the user.
• Assignments, which assign values to specific keywords recognized by the SMS.ac service. This lets you override things such as the title of your pod.
• Directives, such as the Msg directive, which sends an SMS message to the current user of your pod.

In addition to providing template substitution on your behalf, the SMS.ac service also recognizes the following xPML tags:

• The podlink tag permits you to link from one page to another within your pod. By default, the HTML anchor tag will always generate a new page, letting you easily code escapes from your pod to full-size Web pages. If instead you want to keep the user within the bounds of the pod?generally the case if you want to present the appearance of a stand-alone action&151;you should always use the podlink tag. Its syntax is the same as the anchor tag.
• The connect tag, which permits superdistribution of your content. Content enclosed within a connect tag is user-selectable; when the user selects the content, they are prompted to provide an address and a message to accompany the content, which will be sent to the indicated address.

You can use these anywhere you’d use conventional HTML markup:

…Next page…

One issue I have with xPML is that it’s not fully XML-compliant. In the interests of making xPML easy to understand and use, the architects at SMS.ac have introduced the <( and )> nomenclature to denote a template substitution. Unfortunately, this isn’t XML-compliant, and a number of XML-based tools are likely to have problems managing content destined for SMS.ac applications. If you’re using an XML-based environment such as XSLT to produce your mobile output, expect to spend a bit of extra time using the facilities of your environment to produce this XML-like output.

The SMS.ac Messaging Interface
The SMS.ac service provides two ways to interact with their subscribers using SMS: via the xPML <(Msg)> tag and via their messaging API, available through a SOAP interface.

When you register your pod, you can provide a two-way messaging keyword and a URL to which any SMS messages should be sent which contain that keyword. Once you do this, any SMS messages received by SMS.ac to their short code containing that keyword will be sent to your application server for processing by invoking the URL you specify along with the contents of the query and the subscriber unique ID of the originator of the message. Thus, a subscriber sending the message “map to sandy’s house” would generate a URL to the service registered with the map keyword that looked like this:

http://www.yourserver.com/pod.php?smsac_oid=1234&message=to+sandys+house

To send a response, you should include the <(Msg text="")> xPML tag in your response to this URL, like this:

<(Msg text="Take route 236 north out of town to Gulch Road, turn left, stop at 1212 Gulch Road.")>

The <(Msg)> tag lets you provide simple responses to user queries, but if you need to originate messages to pod users without a corresponding request, it’s time to call in the heavy artillery. The SMS.ac service provides a simple SOAP API with two methods, GetPodInfo and SendMessage. While the details of integrating a SOAP request with your application are out of the scope of this article, it’s enough to know that it’s possible to do, and once that’s done, it’s very easy to use the SOAP interface with SMS.ac. Simply issue a SendMessage call over HTTPS including your unique ID, password, and the ID of your pod, and the recipient unique ID of the recipient, and SMS.ac does the rest.

Getting Paid
All of this is well and good, but what about the bottom line? In practice, SMS.ac is an SMS aggregator. To generate revenue, SMS.ac uses premium SMS to bill their subscribers; consequently it’s easy for consumers to access the service and pay to use your pod. The widespread adoption of premium SMS by most carriers has generated an environment where micropayments can be truly commonplace; SMS.ac leverages their relationship with hundreds of carriers as an aggregator to aggregate those micropayments on behalf of developers such as you and me.

Once you publish your pod?by listing the description, URLs, and so forth with SMS.ac and pass their acceptance criteria?SMS.ac users can sign up to use your pod. In doing so, they generate premium SMS traffic to their mobile handsets, resulting in payments from the users?carriers to SMS.ac. These, in turn, are collected by SMS.ac and funneled back to developers. At present, the SMS.ac service has a Web-based transaction reporting interface that lets you monitor how your pod is being used as well as what SMS.ac will pay you for your pod’s use; SMS.ac pays developers in US dollars on a regular basis at the close of the carrier billing cycle. It’s reminiscent of the Qualcomm BREW Delivery System model, in which subscribers pay carriers, carriers pay Qualcomm, and Qualcomm pays you; the difference is that instead of subscribers having to manage additional line items on their mobile service bill, payment is handled via premium SMS. It’s a novel way to manage the billing process, and it keeps independent developers from having to hassle with each carrier or SMS aggregator in search of recurring revenue.

With xPML, SMS.ac has introduced some interesting ways to generate revenue from mobile consumers. While billing via premium SMS isn’t new (it is, of course, the sole purpose of premium SMS!) tying it to a template-based Web language for fixed and mobile browsers is. And with the simplicity of xPML, it’s easy to create small applications funded by micropayments from subscribers on hundreds of networks around the world.