///Tip: Use XML to Send SMS Messages

Tip: Use XML to Send SMS Messages

Reap the benefits of MMAP and SMAP

Many developers tend to think of Web services as a way to easily move information from one place to another, but it’s also important to understand how integral a Web service can be to the overall application. This tip gives some examples of using XML for Short Message Service (SMS) messages. If you’re familiar with SMS, you’ll find out how adding this tool to your toolbox can help you; if you’re not an SMS developer, you’ll see a real-life example of how Web services are integrated into an application.

Most of the time, when people talk about Web services, they think of two different scenarios: performing a remote procedure call, or moving data from one place to another. In this tip, I show you a situation in which the message is the medium: SOAP messages that carry on an SMS transaction. This situation truly takes advantage of the SOAP message structure. The header can be used for purposes such as billing or authentication, and the body passes the actual messages.

I start by looking at SMS itself.

What is SMS?

Short Message Service (SMS) is the term used for short (typically less than 160 characters) messages that are sent between mobile phones — instant messaging for the mobile set, if you will. It’s hugely popular in parts of Europe and Japan, and is slowly gaining popularity in the United States. Typically, it works like this:

&#8226 You send a Short Message from your phone to your friend’s phone. The message goes to a Message Center.

&#8226 If your friend is available — meaning, her phone is turned on, and she’s in the service area — the Message Center sends it to her phone.

&#8226 If she’s not available, the Message Center holds onto the message.

&#8226 When your friend becomes available, her phone requests the messages, which are then delivered.

In this way, SMS is more like e-mail than paging or cell phones, even though phones are usually where they come into play.

For some time now, these transactions have been carried out using HTTP, but each vendor has created its own implementation, leading to interoperability problems. To solve this problem, the SMS Forum has developed two specifications:

&#8226 Short Message Application Part (SMAP) is an XML format for the messages themselves.

&#8226 Mobile Message Access Protocol (MMAP) is a SOAP-based protocol for sending those messages.

In this tip, I look at how SMAP and MMAP work.

SMAP messages

The heart of an MMAP transaction is the actual message to be passed, which gets expressed as an SMAP message. The SMAP protocol was developed on the theory that when compared to the binary form that SMS messages currently take, this XML-based format is more interoperable in the short-term and easier to convert to other formats later on, if necessary.

When it comes to structure, a simple SMAP text message to be passed to a phone has much in common with a SOAP message.

Listing 1. SMAP text message



<SMAP:SubmitRequest
xmlns:SMAP="http://www.smsforum.net/schemas/smap/v1.0"
xsi:schemaLocation="http://www.smsforum.net/schemas/smap/v1.0
http://www.smsforum.net/schemas/smap/v1.0/smap.xsd">
<SMAP:ShortMessage>

<SMAP:Header>
<SMAP:Destination>
<SMAP:Number>5555309</SMAP:Number>
</SMAP:Destination>
</SMAP:Header>

<SMAP:Body>
<SMAP:Text>Jenny, I've got your number.</SMAP:Text>
</SMAP:Body>

</SMAP:ShortMessage>

</SMAP:SubmitRequest>
<body>
</body>
</html>

The SMAP text message consists of a header, which contains meta information (such as the destination for the message), and the body, which contains the actual message.

SMAP defines several operations, from sending a message to altering or cancelling a message that has been sent but not delivered.

A Simple MMAP Conversation

The nice thing about MMAP, in my opinion, is that it takes advantage of the SOAP message structure. The header is used for meta-information, such as billing and session coordination, and the body is used for the message itself.

Consider, for example, the simplest possible situation: An application sends a message to a particular phone. This is considered an immediate mode situation, and might look something like this:

Listing 2. MMAP transaction

<?xml version="1.0" encoding="UTF-8"?>

<SOAP:Envelope
xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope
http://www.w3.org/2003/05/soap-envelope">
<SOAP:Header>

<MMAP:MMAPHeader SOAP:mustUnderstand="1"
xmlns:MMAP="http://www.smsforum.net/schemas/mmap/v1.0"
xsi:schemaLocation="http://www.smsforum.net/schemas/mmap/v1.0
http://www.smsforum.net/schemas/mmap/v1.0/mmap.xsd">

<MMAP:ApplicationContext bodyType="Request"
sourceOperationReference="1138"/>

</MMAP:MMAPHeader>

</SOAP:Header>
<SOAP:Body>

<SMAP:SubmitRequest
xmlns:SMAP="http://www.smsforum.net/schemas/smap/v1.0"
xsi:schemaLocation="http://www.smsforum.net/schemas/smap/v1.0
http://www.smsforum.net/schemas/smap/v1.0/smap.xsd">
<SMAP:ShortMessage>
<SMAP:Header>
<SMAP:Destination>
<SMAP:Number>5555309</SMAP:Number>
</SMAP:Destination>
</SMAP:Header>
<SMAP:Body>
<SMAP:Text>Jenny, I've got your number.</SMAP:Text>
</SMAP:Body>
</SMAP:ShortMessage>
</SMAP:SubmitRequest>

</SOAP:Body>
</SOAP:Envelope>

The SOAP:Header contains the MMAPHeader, which contains information about the request itself. The ApplicationContext specifies the type of message as a Request, SuccessResponse, or ErrorResponse. It also provides a sourceOperationReference, an identifier that gets included in the response, so the requester can recognize it. Because of the SOAP:mustUnderstand attribute, if the receiver doesn’t understand the MMAPHeader, it must reject the message to avoid processing it incorrectly.

The SOAP:Body contains the actual SMAP message.

Listing 3. SMAP message

<SOAP:Envelope xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope
http://www.w3.org/2003/05/soap-envelope">
<SOAP:Header>

<MMAP:MMAPHeader SOAP:mustUnderstand="1"
xmlns:MMAP="http://www.smsforum.net/schemas/mmap/v1.0"
xsi:schemaLocation="http://www.smsforum.net/schemas/mmap/v1.0
http://www.smsforum.net/schemas/mmap/v1.0/mmap.xsd">

<MMAP:ApplicationContext bodyType="Request"
sourceOperationReference="1138"/>
<MMAP:ServiceContext serviceName="wallart">
<MMAP:AccessControl>
<MMAP:ApplicationIdentity>BRoom</MMAP:ApplicationIdentity>
<MMAP:Authentication>
<MMAP:Password>titogi</MMAP:Password>
</MMAP:Authentication>
</MMAP:AccessControl>
</MMAP:ServiceContext>

</MMAP:MMAPHeader>

</SOAP:Header>
<SOAP:Body>
...

At present, you can use plain text or MD5-encoded passwords, but the SMS Forum plans to extend this capability to include stronger security, such as certificates and tokens.

You can also use the ServiceContext to specify billing information. For example:

Listing 4. Using the ServiceContext to specify billing information

...

<MMAP:ServiceContext serviceName="wallart">
<MMAP:AccessControl>
<MMAP:ApplicationIdentity>BRoom</MMAP:ApplicationIdentity>
<MMAP:Authentication>
<MMAP:Password>titogi</MMAP:Password>
</MMAP:Authentication>

<MMAP:Billing identity="229ss">
<MMAP:Cost type="debit">
<MMAP:CostAmount amount=".3" units="dollar"/>
</MMAP:Cost>
<MMAP:ApplyTo>
<MMAP:Name>Tommy Heath</MMAP:Name>
<MMAP:Account>92988322</MMAP:Account>
</MMAP:ApplyTo>
<MMAP:Description>Per Message Plan</MMAP:Description>
</MMAP:Billing>

</MMAP:AccessControl>
</MMAP:ServiceContext>
...

The specification also allows you to add arbitrary HTML code to the Billing element, as long as it’s well-formed.

Message Responses

Once the message is received and dealt with, the receiver sends a response. If all has gone well, it sends a SuccessResponse, such as:

Listing 5. Sample SuccessResponse

<SOAP:Envelope xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope
http://www.w3.org/2003/05/soap-envelope">
<SOAP:Header>
<MMAP:MMAPHeader SOAP:mustUnderstand="1"
xmlns:MMAP="http://www.smsforum.net/schemas/mmap/v1.0"
xsi:schemaLocation="http://www.smsforum.net/schemas/mmap/v1.0
http://www.smsforum.net/schemas/mmap/v1.0/mmap.xsd">
<MMAP:ApplicationContext bodyType="SuccessResponse"
sourceOperationReference="1138"/>
</MMAP:MMAPHeader>
</SOAP:Header>
<SOAP:Body>

<SMAP:SubmitResponse
xmlns:SMAP="http://www.smsforum.net/schemas/smap/v1.0"
xsi:schemaLocation="http://www.smsforum.net/schemas/smap/v1.0
http://www.smsforum.net/schemas/smap/v1.0/smap.xsd">

<SMAP:MessageRef>3263827</SMAP:MessageRef>

</SMAP:SubmitResponse>

</SOAP:Body>
</SOAP:Envelope>

In this case, the body contains a SubmitResponse with a reference number, but no indication of whether the operation succeeded or not. That information resides in the ApplicationContext element, where the bodyType is set as SuccessResponse. The sourceOperationReference refers back to the value provided with the original request, so they can be correlated.

Other Options

I haven’t even begun to scratch the surface of all that you can do using MMAP and SMAP to send SMS messages with XML. The MMAP protocol supports not only this type of simple immediate message, but also sessions — and even peer-to-peer connections — in which both parties exchange information asynchronously within a single session. Between all of the capabilities that are built into MMAP, and the fact that it is designed to prevent interoperability problems, you’ll find that it allows you to build sophisticated applications based on SMS.

Resources

• Find out more about SOAP at the XML Protocol Working Group .

• Learn more about SMS in general at the SMS Forum , which also includes SMS and SMPP FAQs . You can also join the SMS Forum online discussion .

• Check out the MMAP specification .

• SMAP and MMAP are still in their early stages, but you can download a variety of SMPP tools .

• Check out the wide variety of fun, informative sites at GeckoBeach Wireless Links .

• Find a broad array of articles, columns, tutorials, and tips at the developerWorks XML and SOA and Web services zones. While you’re at it, subscribe to the Web services/XML Tips newsletter .

• Browse a wide range of XML-related titles at the developerWorks Developer Bookstore .

• Learn how you can become an IBM Certified Developer in XML and related technologies .

2010-05-26T11:37:41+00:00 April 11th, 2005|XML|0 Comments

About the Author:

Nicholas Chase, a Studio B author, has been involved in Web site development for companies such as Lucent Technologies, Sun Microsystems, Oracle, and the Tampa Bay Buccaneers. Nick has been a high school physics teacher, a low- level radioactive waste facility manager, an online science fiction magazine editor, a multimedia engineer, and an Oracle instructor. More recently, he was the Chief Technology Officer of Site Dynamics Interactive Communications in Clearwater, Florida, USA, and is the author of four books on Web development, including XML Primer Plus (Sams). He loves to hear from readers and can be reached at nicholas@nicholaschase.com.

Leave A Comment