A.4. A Send Only Service

A.4.1. Background

The simplest form of notification is one-way communication — the intended recipient is provided with some information, but no method is provided for them to respond. In other words, the service can send the user information, but not the other way around.

This was the form of our "first pass" approach, and served to familiarise ourselves with the techniques required to communicate with the GSM modem. Care was taken, however, to ensure that the system was modular and extensible to cater for future growth. Figure A-1 below shows a block diagram of the complete service. This first implementation included all the links shown in the diagram except those labelled (2) and (3).

Figure A-1. Overview of the SOAP service



A.4.2. SOAP Encapsulation

In any web service, data needs to be transferred from the client to the service. Using SOAP as a transport encoding requires that this data be encapsulated as an XML document. The intention was to make this document as simple as possible, so as to allow the widest variety of applications.

The resulting schema allowed the client to send an XML document that encapsulated one or more SMS messages, each of which could have one or more intended recipients. A typical (and somewhat minimal) client request would be an XML document similar to the one in Figure A-2.

Figure A-2. Typical SOAP request to send SMS

    <?xml version="1.0" encoding="iso-8859-1" ?>
    <soap:Envelope xmlns:soap="…">
      <soap:Body>
        <sms:sms xmlns:sms="…">
          <sms:sendsms>
            <sms:phone>0821234567</sms:phone>
            <sms:message>Hello World!</sms:message>
          </sms:sendsms>
        </sms:sms>
      </soap:Body>
    </soap:Envelope>
       


This request shows a client asking for the message "Hello World!" to be sent to the owner of the cell phone whose number is 0821234567.

The web service would process this request, and would send the client a SOAP response indicating the status of this message. A typical SOAP response (and in fact, the response to the previous example) is shown in Figure A-3.

Figure A-3. Typical SOAP response

    <?xml version="1.0" encoding="iso-8859-1" ?>
    <soap:Envelope xmlns:soap="…">
      <soap:Body>
        <sms:sms xmlns:sms="hellip;">
          <sms:sentsms>
            <sms:phone>0821234567</sms:phone>
            <sms:message>Hello World!</sms:message>
            <sms:status>ERROR</sms:status>
            <sms:id>S0015</sms:id>
          </sms:sentsms>
          <sms:newsms>R0006</sms:newsms>
        </sms:sms>
      </soap:Body>
    </soap:Envelope>
       


The response contains the full information of the request, as well as various other fields containing information on the status of the message.

The most important of these is the status field. This contains information on whether or not the service was able to send the message. In the above example, this status is "ERROR", probably because 0821234567 in not a valid cell phone number. Success is indicated by an "OK" in this field. This information comes directly from the GSM modem.

A message identifier is sent back in the id field. This identifier is discussed in section on the database backend (Section A.6). The meaning of the newsms flag will become apparent in Section A.7 when we deal with received SMS messages.

A.4.3. HTTP transport

SOAP itself doesn't specify a transport method; this is left to the implementer. Just about any network-capable transport can be used. Internet file transfer protocols (such as FTP), mail protocols (such as SMTP and POP3), and online chat protocols (such as IRC and Jabber) have all successfully been used to transport SOAP datagrams. By far the most common method, however, is the hypertext transfer protocol (HTTP), which is the same protocol that is used to deliver web pages.

There are many SOAP over HTTP implementations, most of which include their own embedded web server. In the spirit of keeping it simple, it was decided to forgo these complications in favour of the existing web server software.

Thus, the service described in this paper runs as a common gateway interface (CGI) script on an Apache web server. The CGI takes an HTTP "POST" method and passes the information (as well as meta-information about the client — server connection) to another program. This CGI service implementation simply reads information from the standard input stream and writes it to the standard output stream, and so could be written in just about any programming language. The Practical extraction and report language (Perl) was used to create the CGI interface in this service, mainly because of the author's familiarity with this language. Perl libraries for dealing with XML documents are widely available, and the XML::Parser module (based on the eXpat XML parser) [9] was used for this implementation.

A.4.4. Limitations

Like e-mail, the short message service employs a "best attempt" delivery method. This means that just sending an SMS message does not guarantee that intended recipient of that message will receive that message. Facilities exist to provide confirmation of delivery and notification of failure, in much the same way as e-mail servers generate status reports when mail cannot be delivered.

Unfortunately, this limitation means that the SOAP service cannot guarantee delivery of a client's message. The status field that it returns to the client will indicate whether or not it has successfully managed to send the message, rather than whether the recipient has received it. No handling of delivery confirmation or failure notification currently exists in the service.

When the web service is communicating with the GSM modem, it does an exclusive lock on the serial port connecting the computer to the modem. This is necessary in order to ensure that the modem's responses to commands that are sent are correctly interpreted.

This locking, however, means that only one client may be served at a time. Since the transaction with the web server takes a matter of seconds, this limitation shouldn't pose much of a problem for low usage levels. However, if the service were to scale to high volumes of client connections properly, a queuing method would need to be employed to overcome this problem. This first pass implementation does not use such a queue, although the database described in Section A.6 could be used to achieve this.