ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

SMS-Powered Applications SMS-Powered Applications

by Dejan Bosanac
06/09/2004

Every business tries to get as close as it can to its customers. The aim is to keep customers up to date with company news, products or service updates, relevant information about their accounts, or to send them notifications for important events. Email messages are widely used for these purposes and that is usually an appropriate way to inform customers. But there is a drawback to using email exclusively for communication with customers. Not all customers have a habit of checking their mailboxes regularly, so information can be delivered in a matter of hours or even days. Sometimes, this is not fast enough, and in some cases, it could be good for the company's public image to make it better. Mobile phones are a commodity today, and SMS (Short Message Service) messages offers an intriguing solution. Messages are delivered in a matter of seconds, and customers are far more likely to receive and read them, no matter their Internet habits or current locations.

This is by no means the only way SMS messages could work for you. You could provide your users with two-way communication by enabling customers to send you an SMS request in a specified format and get a response from the system. This user interface would be far from being user-friendly, but for simple request-response situations, it would work well enough.

Beside SMS messages, there are many technologies currently used for messaging by mobile users. Still, SMS messaging is the most widely adopted, and there are good reasons for that. MMS (Multimedia Messaging Service) messages have become popular, but many mobile devices doesn't support them yet, and some people are unlikely to change their current phones for several years. EMS (Enhanced Message Service) is a proprietary technology, which restricts its wide adoption among phone makers. In this light, some analysts predict that SMS will be dominant technology in this field for the next few years. So we can definitely say that it is here to stay.

There are many companies that offers SMS gateway services and enables various interfaces (HTTP, FTP, XML-RPC, SMTP) that could be used for sending (and in some cases, receiving) SMS messages. Also, you could find some gateway products and open source projects for the same purpose. This approach is appropriate for most cases, because developers know these technologies well and it doesn't require a big development effort for a solution that will work. But if you want to heavily use SMS messages or greater flexibility in your system, you will probably want to skip the "middleman" and work directly with your mobile provider.

This article will describe the basics needed for developing an SMS-powered application that can communicate directly with the mobile operator of your choice, all using Java and open source tools and libraries.

Protocol

SMS messages are transferred using Short Message Peer to Peer (SMPP) protocol. This is an open industry standard protocol developed to enable transfer of short messages between mobile users, called External Short Message Entities (ESMEs), and Short Message Service Centers (SMSCs). An ESME represents a fixed-network SMS client, and that is where our application resides in the system. For the SMSC, we will assume a mobile provider or a center that is responsible for delivering the message to mobile user. The communication may also involve Routing Entities (REs) that are responsible for message routing between ESMEs and SMSCs (and of course, other routing entities).

SMPP defines a set of operations in the form of Protocol Data Units (PDUs). PDUs are well-formed packets that are transferred between entities. A PDU consists of a header and an optional (depending on the PDU type) body. We will not dig deeper into PDU formats in this article because all of these low-level operations are abstracted by the API that will be described later in the text. Detailed description of the SMPP protocol could be found on the official SMPP forum site.

From the OSI stack perspective, SMPP presents an application layer protocol and relies on a TCP/IP (or X.25) network protocol that is responsible for packet delivery. So the basic requirement for using SMS messages is providing a reliable network connection to your mobile provider (just as it would be needed for any HTTP data transfer).

The first thing the ESME (our application) should do is to establish a session with the message center. There are three connection types that could be used, depending on the application's role in the system. An ESME can establish the connection as a transmitter (TX), meaning it can only send messages to the SMSC for a delivery to mobile users. Next, it can behave as a receiver (RX), in which case it can only receive messages from an SMSC. Finally, first two modes are combined in a transceiver (TRX) session type that enables application to both send and receive SMS messages.

In order to get a picture of how a SMPP session works, we will go through one example where the application connects to the SMSC as a transceiver, gets a request from the user (such as a request for the balance on a user's account for an online banking system), and responds back (with the user's balance). This arrangement is shown in Figure 1. This will also be our example Java application later. The labels on the arrows represents PDU types that are exchanged between an ESME and a SMSC.

Figure 1
Figure 1. Example of PDUs transferred between an ESME and a SMSC

After establishing the network connection and binding as a transceiver, the ESME is enabled to receive messages. The user sends SMS messages in an appropriate format (such as BALANCE 123456, meaning "Give me the balance for account number 123456") and the SMSC delivers the message to the application (shown as the deliver_sm and deliver_sm_resp PDUs). After checking for correct format and retrieving the data from the database, the application returns the current balance back to the user (the submit_sm and submit_sm_resp PDUs). The application can exchange messages with the message center as long as it has a valid, bound session to it. When the application wants to terminate the session, it should unbind the session (with the unbind and unbind_resp PDUs) and close the network connection.

A few more things should be said about the SMPP protocol. First, it is an asynchronous protocol, which means that the ESME could send the next message before it receives a confirmation that the previous one had been received by message center. This approach leads to better network utilization and overall performance. The asychronous nature of the protocol also affects the API architecture, which will be discussed in the later section.

Security is always a concern when one is talking about communication protocols. PDUs are transferred plain, so they are vulnerable to interception and impression attacks. If you want to prevent these kind of attacks, you should consider some additional security measures, such as using a leased line to the message center or using an SSL connection.

API

One way to make your application "speak" SMPP is to use the SMPP API, an open source Java API. We will demonstrate the basics of this library through a simple demo application.

For a start, let's define requirements for this demo application. It will serve as an extension of the e-banking system, enabling customers to check their balances using their mobile phones. For each customer there is a defined phone number that he or she must use for communicating with the system. The format of the user's request message is:

BALANCE <ACCOUNT_NUMBER>

where BALANCE is a keyword and is followed by the account number of the customer. If the user makes a proper request, he or she will receive a message containing the current balance. Otherwise, an error message with an appropriate explanation will be delivered to the phone. As a technical requirement, we will insist that the application can successfully deal with network connection problems, because for this kind of application, needing to restart every time the connection to the SMSC is lost would make the application much less usable and hard to administer.

For a start, we have to establish a connection to the SMSC and bind it with appropriate credentials. For that purpose, we should use the ie.omk.smpp.Connection class. As noted earlier, SMPP is an asynchronous protocol, but the nature of the protocol does not keep us from using it synchronously, if we desire. SMPP API enables communication of both types, with synchronous communication as the default. In our demo we will still use it in asynchronous way because of all of the benefits mentioned above. Here is the code snippet for establishing the connection to the SMSC:

private void connect() {
  try {
    conn = new Connection("localhost", 2775, true);
    conn.addObserver(this);
  } catch (UnknownHostException uhe) {
    System.exit(0);
  }

  boolean retry = false;
        
  while (!retry) {
  try {
    conn.bind(
      Connection.TRANSCEIVER, "sysId", 
      "secret", null
    );
      retry = true;
    } catch (IOException ioe) {
      try {
        sleep(60 * 1000);
      } catch (InterruptedException ie) {
      }
    }
  }
                
}

All example code for this article can be downloaded at the end of the article.

Pages: 1, 2

Next Pagearrow