Extending Your Application Even Further

By now you will have noticed that both the IM and SMS interfaces are very similar in their approach to sending and receiving messages. They share an almost identical message send and receive structure, the only real difference is the source/destination address. Thus it should be relatively straightforward to build a gateway CFC that handles both IM and SMS messages, in fact it is only the onIncomingMessage() method that you will need to modify to get this to work. Let's stem through what is needed to get this to work.

For starters, let's reproduce our simple "echo" method.

In this example we do not cater to any unknown gateways but we could have quite easily put a default case in our application. The next evolution of this would be to take the incoming message and pass it off to another part of the application that would work out the appropriate response to the incoming message.

Modify the onIncomingMessage() function of your sms.cfc to include the following code:

 <cffunction name="onIncomingMessage">         <cfargument name="CFEvent" type="struct" required="YES">          <!--- Generate and return the message.--->         <cfset incomingMessage = Trim(arguments.CFEvent.data.message)>         <cfscript>          msg = structNew();         msg.command = "submit";         newmsgText = incomingMessage;         if(arguments.CFEvent.GatewayType eq 'SMS') {                 msg.destAddress = arguments.CFEvent.originatorID;                  msg.shortMessage = newmsgText;          }         elseif(arguments.CFEvent.GatewayType eq 'XMPP') {                 msg.buddyID = arguments.CFEvent.data.SENDER;                  msg.message = newmsgText;          }         msg.command = "submit";          return msg;         </cfscript> </cffunction> 

If we were to extend this a step further, it is not hard to see how we could take our IM application and twist it into an SMS and IM application without too much refactoring. In fact the entire switch statement block that we created earlier in our IM application would just get dropped in above the <cfscript> tag.

The next set is to put our SMS application live and actually start sending text messages to real mobile phones and not just our test phone. To do this you will need to get a real SMPP account for your gateway to connect to. You can of course talk to your telecom provider and see if they can let you access their SMSC server. Most of the major mobile phone carriers provide SMPP accounts directly (AT&T, BT, France Telecom etc) for access to a specific carrier's mobile customers. The one limitation here is that these accounts may not give you access to any mobile phone, they may only give you access to that carriers mobile phone users.

For access to cross-carrier mobile phone subscribers, you'll need an SMPP account with a "Connection Aggregator". This is a company that will provide you with a single, simple SMPP account, and then they will take responsibility for routing messages to and from the individual mobile phone networks.

This is much more of an issue in the North American market where cross wireless network interoperability is much more of an issue. For our North America readers, here is a short list of a few connection aggregations:

• SimpleWire: http://www.simplewire.com/services/smpp/

• World Text: http://www.world-text.com/index.php

• Hay Systems Ltd: http://www.hslsms.com/apply-1.html

The other thing you may want to look into at the same time as you set up your SMSC account is to get a short code for your gateway instead of a long phone number. A short code is a small, easy to remember phone number, like 555432 that users can send messages to instead of [phone]. It is plain to see that one is much easier to remember than the other. In the U.S., short codes are managed by the Common Short Codes Administration (CSCA) and can be found at http://www.usshortcodes.com/.