Summary: 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:
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:
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
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
The
The
Listing 3. SMAP message
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
Listing 4. Using the ServiceContext to specify billing information
The specification also allows you to add arbitrary HTML code to the
Message responses
Once the message is received and dealt with, the receiver sends a response. If all has gone well, it sends a
Listing 5. Sample SuccessResponse
In this case, the body contains a
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.
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.
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.
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> |
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.
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.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.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.
No comments:
Post a Comment