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:

• You send a Short Message from your phone to your friend's phone. The message goes to a Message Center.
• 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.
• If she's not available, the Message Center holds onto the message.
• 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:

• Short Message Application Part (SMAP) is an XML format for the messages themselves.
• 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.

Back to top

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.

<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>

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.

Back to top

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:

<?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.

<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:

...
         <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.

Back to top

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:

<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.

Back to top

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.
  
  
• For a complete list of XML tips to date, check out the tips summary page.
  
  
• Browse for books on these and other technical topics.
  
  
• Learn how you can become an IBM Certified Developer in XML and related technologies.
  
  

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 an interactive communications firm in Clearwater, Florida, USA, and is the author of several books on Web development, including XML Primer Plus (Sams). He's currently trying to buy a farm so he and his wife can raise alpacas and chickens. He loves to hear from readers and can be reached at: nicholas@nicholaschase.com.

Rate this article

Comments

Back to top

Table of contents

• What is SMS?
• SMAP messages
• A simple MMAP conversation
• Message responses
• Other options
• Resources
• About the author
• Comments