FrontlineSMS allows you to text message with large groups of people anywhere there is a mobile signal.

FrontlineSMS Architecture

For those trying to get their heads around the FrontlineSMS source code, here's a quick breakdown of the FrontlineSMS architecture as it stands, and some brief notes about how we plan to move it forward.

FrontlineSMS Core

The "FrontlineSMS Core" comprises the central controller of the FrontlineSMS system, managing interaction between phones, stored data such as contact details, and an end-user's view and manipulation of the system. The core is a mandatory part of any FrontlineSMS system, but it should be possible to extend or replace any other part of the system.

SMS Device Manager

The SMS device manager is the interface through which all SMS messages are sent and received. It manages connections to hardware SMS devices, such as mobile phones connected via cable or bluetooth, and software SMS devices such as Clickatell's HTTP service.

Hardware management is currently implemented via SMSLib, an open-source Java library allowing connection to AT- (Hayes)compatible devices. We're also planning to add support for Symbian phones and newer (FBUS) Nokia Series 40.

On the software side, FrontlineSMS currently supports sending SMS messages via Clickatell. In the works is support for sending and receiving with IntelliSMS. We are also modularising the software SMS device interface to allow for 3rd-party plugins to be added more easily.

Data Controller

The data controller handles connections to the underlying database. Currently, SQLite and MySQL are fully supported. In the future, we are hoping to move database handling to a 3rd-party library, which should massively improve the supported platforms. We also intend to implement a memory-only Data Controller to allow for running FrontlineSMS with increased privacy.

UI Generator/Controller

For the current UI layer, FrontlineSMS uses the ultra-lightweight Thinlet. It's a great little library - fast to get going and with great internationalisation support - the FrontlineSMS UI is already translated into 8 languages. Project contributors modifying this should bear in mind that we will be looking to modularise the UI code in the coming months.

External Systems

Keywords can trigger FrontlineSMS to make a call over HTTP or on the local machine with details of the message received. These systems can then process the message data, and respond to FrontlineSMS with instructions to send new messages.

FrontlineForms

FrontlineForms is a proprietary add-on for FrontlineSMS allowing a mobile Java client to connect to FrontlineSMS and share data with it. More details of FrontlineForms will follow in another post.

FrontlineSMS relies on many free and open source projects, and is grateful to them all:
SMSLib, Thinlet, RxTx, SQLiteJDBC, MySQL, Log4j, Silk iconset.

You can get to the source code from SourceForge.

Tags: arch, architecture, code, dev, development, frontline, frontlinesms, java, source, sourceforge

Next Post >

Comment

You need to be a member of FrontlineSMS to add comments!

Join this Ning Network

Comment by Tom MacWright on September 11, 2009 at 4:58pm: Are there any plans to nix the 'Request a Download' process when the open-sourceness of FrontlineSMS is better revealed? Since it's redistributable and I really hate giving away personal information, it seems like an odd and unnecessary kink in adoption (after all, most software is installed via a quick download or even just 'port install x').

Will there be any information on the main site about downloading the source easily? It's pretty standard-practice among these kinds of tools.

Comment by Ben Whitaker on August 11, 2009 at 5:08am: Hi Katrin,

License is LGPL
(chosen because some of our libraries, such as the serial port accessor from SUN wouldn't fit under GPL)

Details of how to download are all on sourceforge:
https://sourceforge.net/projects/frontlinesms/develop

To check out the source code enter the following URL in your Subversion SVN client:
https://frontlinesms.svn.sourceforge.net/svnroot/frontlinesms

You don't need any logins, this is open to the anonymous public for download.

Of course, the new developers group will cover this in more detail once it is launched.

Comment by Ben Whitaker on August 7, 2009 at 1:59pm: yes bART,
there isn't a single file - SVN will check out all of the files individually.

The standard java build should work on the Mac, and I think there's a build target for mac too?

Comment by bART Sullivan on June 22, 2009 at 10:39am: and how large is the file? Should I use the SVN?

Comment by Alex Anderson on June 22, 2009 at 10:29am: Hi bART! The HEAD of trunk/ should be stable, so I'd recommend using that.

Comment by bART Sullivan on June 22, 2009 at 10:06am: Hello guys - which version should I download to run on my mac? There are some features in the UI I'd like to tweak.

Comment by Martin Konzett on February 4, 2009 at 8:05am: don't worry ... this was just my 15 minutes birds eye view brainstorm ...

@MVC ... don't know Thinlet
@spring ... agree
@community ... not agree

please feedback on my other points ...

I am trying to get involved soon and I am sure the project will be (even more) successful ...

cheers, martin

Comment by Tom Godber on February 4, 2009 at 7:35am: Hi Martin,

I'll echo Alex and say thanks for the feedback - it's always good to have people get involved, and if you wanted to be really helpful and create those Linux installers that would be even better! It's on our to do list, but behind some more critical features right now.

I think there is a little misunderstanding which comes from you being a web developer - it is worth noting that FrontlineSMS is foremost a product designed to run on the widest possible array of hardware, inlcuding 486s running Windows 95, with limited connectivity. If you reconsider what you have said - all valid for a server-based webapp - whilst considering it as a desktop app with this target userbase, perhaps the design decisions will make more sense. I'll expand a few points here for anyone who is interested in our architectural thoughts:

Spring is a wonderful framework - we use it all the time on servers - but it carries with it considerable overhead (megabytes in the jar and processor cycles at runtime) which are not acceptable for the limited benefits FrontlineSMS would gain from it.

The application does use some MVC separation concepts, but we have made sacrifices to work with Thinlet which is an incredibly good lightweight GUI framework that runs with very low hardware requirements. There are certainly points where the architecture can be improved, but our overriding concern has been to provide maximum features and performance on minimum hardware and budget. Use of features like generics has often been guided by the libraries we are working with - you will find they do show up in the parts of the code with few/modern external library dependencies!

Java Web Start is great for people running modern PCs, but not a priority given what I've said about our target market. It may well happen, but we have to consider what is of benefit to the widest possible userbase when prioritising these features!

In a web server context, MySQL is fairly scalable where SQLlite may not be - however given the volumes of data passing through a typical FrontlineSMS system either is quite up to the job! Similarly, multi-tier architectures and some of the other concepts you mention make sense for a server, particularly one which may need to be clustered or distributed over multiple boxes, but actually they impede performance and effectively reduce scalability on the low-end hardware we're targetting.

Hopefully that explanation makes sense - all valid criticisms from one perspective but we think we've generally made the right choices overall!

As for Ning vs SourceForge vs Google vs mailing lists - Frontline existed on Ning before we were ready to fully open source, and we've just kept using it. Some people prefer one, some the other - really it's down to personal preference (I personally prefer Ning, for what it's worth). Hopefully the actual underlying platform is pretty irrelevant as long as it is capable of delivering good support and communit co-ordination!

Best regards,

Tom Godber, Masabi.

Comment by Martin Konzett on February 4, 2009 at 6:27am: @sourceforge ... IMHO ... sf was big, good, and useful 5 years ago, now it is full of ads and nasty DHTML menus ... the insides of the features, like issue tracking are 10 years old ... i stopped using it ...

now i use code.google.com which is very good with state of the art features and no ads, also full google analytics support

i was using gforge - a free clone of sourceforge - for several years on a dedicated machine ... there you have at least no ads, but you need a guy to maintain it ...

cheers, martin

Comment by Alex Anderson on February 4, 2009 at 6:05am: Hi Martin,

Thanks for taking an interest in the project, and thanks also for your detailed feedback.

We're all new to SourceForge, so if you have any advice on features that we could be taking advantage of, I'd be grateful to hear more specific suggestions.

Hopefully Carlos or I will have time to respond in more detail soon.

Thanks,

Alex