Recommend a language for an SMS engine

bridigo

Need to design an SMS engine from scratch. Could anyone recommend what programming language and database you would think most suitable for this purpose? It needs to be able to handle large quantities of SMSs, sending and receiving from Mobile operators SMS gateways. I know PHP and MySQL quite well, but am thinking Java and something more commercial for a database (like Oracle) may be better ???

The Corinthian

You might want a multi-tier solution, with say a C/C++ based app to handle the connection to the operators and a LAMP based architecture to handle your business logic for example.

bonkey

bridigo wrote:

Need to design an SMS engine from scratch.

Engine? Do you mean engine, or do you mean system? Are you talking about a component which can be used by other applications, or a system which includes this functionality, a UI, etc. etc. etc.

Could anyone recommend what programming language and database you would think most suitable for this purpose?

It depends what you want this engine for. If its an engine and will be used primarily in Web applications, then some form of Web Service might be the way to go. Alternately, if its to be dumped into thick-client applications, then the most probable options you'll want are C# or Java.

Thinking slightly further, how will you interface to SMS Gateways? What interfaces do they offer? And so on.

The answer you want will only be vaguely based on what you want to develop...its what you want to develop it for.

jc

The Corinthian

bonkey wrote:

Engine? Do you mean engine, or do you mean system? Are you talking about a component which can be used by other applications, or a system which includes this functionality, a UI, etc. etc. etc.

SMS gateways, be they for bulk or two-way SMS, will typically have three principle components:

1. Connection. This can be anything from a HTTP connection to a service provider, using a script, though to a robust multi-threading process that will connect to an operator’s SMSC via SMPP over a VPN.
2. Database & Associated Business Logic. Essentially where the core logging of SMS requests, responses and confirmations will take place, along with the business logic of how you’re handling them; what account they belong to, keywords used, sessions and what application is ultimately going to handle them.
3. Applications. In the case of two-way SMS, this could be a completely separate application - handling the incoming SMS and (possibly) responding accordingly. For simple outgoing bulk SMS, this can be what governs the format of the SMS (e.g. sending out MMS rather than SMS).

Anyhow, when someone’s talking about an SMS gateway or engine, that’s normally what they mean, so I’d assume what he / she is looking for is the best type of architecture and / or technology to handle that from a general perspective.

bridigo

That is correct, Corinthian, the SMS engine/gateway needs to do exactly what you describe from a general perspective. Connecting to operators SMSC over VPN. The app will receive a SMS form a suscriber, log in a database, send confirmation, and send text content to this suscriber once a week. The suscriber can SMS to change their type of suscription, text STOP, HELP etc. to the shortcode.

So perhaps the whole app could be written in C/C++ using a MySQL database on a Linux platform.

The Corinthian

Depending on whether you are looking to build a bespoke level enterprise level solution or just an application that will service a set number of clients, you may want to look at buying off the shelf components for the applications and/or connection. It may make financial sense if you don’t have the skills in-house.

bridigo

That's the thing, we need a very robust, bespoke enterprise level solution, so probably going to hire an experienced contractor/consultant with the desired skills that i'm trying to determine, and we could take care of the business logic in house.

aspnet

I've just spent the past year implementing an enterprise wide solution to the above in .NET

If you want to talk of boards send me an email or private message.

The Corinthian

bridigo wrote:

That's the thing, we need a very robust, bespoke enterprise level solution, so probably going to hire an experienced contractor/consultant with the desired skills that i'm trying to determine, and we could take care of the business logic in house.

Then build the connection tier to suit the platform that will be used for he core business logic - if it’s going to be on *nix then use C / C++, if on Windows then use C++ / C#. J2EE is also an option, which may be worth examining.

I don’t know how you intend to treat the applications attached to this system, but I would keep them as separate as possible from the core business logic.

Anyhow, HTH and feel free to contact me privately for anything further.

bridigo

Thanks, your help is appreciated. Im thinking Java on Linux, as I've heard there is an opensource SMPP Java toolkit - which may make development easier. Then seperate classes for each of the business logic components.

swiss

Also, I'm not sure if this is relevant, but the Parlay group in conjunction with OSA have released a series of APIs that provides a gateway between your service level logic and the telecommunications network. A white paper of the Parlay spec is available here.

This may be overcomplicating it somewhat for what you are trying to do, because it is more to do with the call control and mobility features of telecom networks, but there are also some very useful modules such as an MMS subsystem that may help you in what you are trying to accomplish. The zipped spec on this subsystem is also available here.