Reaching the Mobile Market with and xPML

Reaching the Mobile Market with and xPML

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, whose approach is a novel mix of traditional Web programming and mobile applications. 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 subscribers within the service with a minimum of fuss. And there’s the potential for that to mean a lot of subscribers, as 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 portal on the Web or wireless terminal, and can interact with mobile consumers using SMS. Once a mobile pod is added to the portal, subscribers can interact with it directly on the home page.

Getting Started makes integrating your application with the 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; 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 xPML hooks as just another presentation layer in your existing application. Because the service interacts with your application through the use of templates written in xPML, integration with 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

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

To get access to the 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 service.

When developing your application for, you must remember that will use your content via the templates you provide in response to requests. Thus, you’re not serving content directly to subscribers, but serving content to 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 messaging interface, which requires you to use SOAP over HTTPS). Your pod appears in a section of an user’s home page on their desktop or mobile device, as users can configure their page to contain several pods.

Once you develop and test the templates required for integration, commercialization is easy: simply return to the 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, 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 home page.

xPML: The Secret Sauce Powering
Because you provide content to subscribers via templates, you needn’t interact directly with 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 service when invoking your application, and you permit the 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

When 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:,+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 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 specific data.

Table 1. URL-encoded data members in URLs

Parameter Description Values
IsWapSet to 1 (true) if user is viewing pod thru a handset0 (false) / 1 (true)
smsac_sizeSize of Pod1 or 2
smsac_oidUnique ID of pod ownerSystem generated
smsac_oageAge of pod owner0-99
smsac_osexSex of pod ownerMale / Female
smsac_olocLocation of pod subscriberCity, State, Country
smsac_vidUnique ID of pod viewerSystem generated
smsac_vageAge of pod viewer0-99
smsac_vsexSex of pod viewer 
smsac_vlocLocation of Pod viewerCity, State, Country

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 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 users, and one for non-subscribers browsing the 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 service should be in xPML, which looks strikingly like HTML. Drawn from the Web site, here’s a simple example:

<(PodTitle text="Hello Mobile World!" link="")>

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 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 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 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 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 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 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 Messaging Interface
The 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 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:

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 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 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 does the rest.

Getting Paid
All of this is well and good, but what about the bottom line? In practice, is an SMS aggregator. To generate revenue, 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; 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 and pass their acceptance criteria? 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 These, in turn, are collected by and funneled back to developers. At present, the service has a Web-based transaction reporting interface that lets you monitor how your pod is being used as well as what will pay you for your pod’s use; 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, 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.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist