Mobile Banking, AML and the Mobile Network Operator

There are two types of mobile banking systems. The type that front-ends an existing bank account and those that contain a self contained wallet to hold the funds. The majority of front-end systems allow users to transact off a credit card that they have preregistered onto the mobile banking application. Some of the systems allow users to transact off their savings, cheque or transmission accounts. In the front-end systems the bank that holds the funds is familiar with anti-money laundering (AML) and counter-terrorism financing (CTF).

But what about the wallet type systems. In both front-end and wallet type systems there is a drive to make the registration of new users as lightweight as possible and preferable entirely off their mobile device. Mobile operators prefer to deploy these wallet type systems since they then own the customer completely. But mobile operators do not necessarily understand the issues around anti-money laundering (AML) and counter-terrorism financing (CTF), because this is not something that they normally have to contend with. These regulations revolve around know-your-customer (KYC) and KYC prevents simple registration. As mobile operators start deploying and running these wallet type mobile banking systems then are going to be forced to adhere to banking regulations. So when users are signed up with insufficient KYC data there are a number of easy solutions to prevent or limit money laundering and terrorism financing. The simplist is to only allow funds to be loaded into the wallet and then enforce that these funds must be used to purchase goods or services. Another way would be to limit the size of transactions so that only small amounts can be unloaded to cash, or simply enforce that funds are loaded or unloaded from one specific banking account.

Unfortunately, not all producers of mobile banking systems have taken the moral high ground to ensure that their systems adhere to AML and CTF. In the short term the mobile operators purchasing these systems might get away with running them, but they will be forced to close them down or make expensive changes to them in the near future as global mobile banking regulations start being put in place.

Building Mobile Web applications

As mentioned in a previous blog of mine building a web application for a mobile phone is not the same as building one for a computer browser. My suggestions when expanding your application onto the Mobile Web is to 'forget' what you know about web development. The Mobile Web is different. There are three major differences namely bandwidth, the user interface and the limited functionality of the browser.

Bandwidth

Bandwidth although becoming much faster and cheaper still makes it difficult to develop a mobile web application that is extremely dynamic. You will also need to think carefully about the content you want to make available on your mobile web application. Not all of it is normally required when on the move. You need to think of your mobile web application as an extension of your full blown web application and not a replacement.

User Interface

Remember that a mobile web application will run on a small screen and the user will need to navigate typically with the phone's limited buttons or on higher range phones with a stylus. As a result navigation must be simple. In my mind it is best to build the screen vertically i.e. with a vertical scrollbar, but no horizontal one.

Limited Browser Capability

Unless you know that your application will only run on high end phones it is best to keep the screen simple. The majority of mobile phone browsers are very limited in functionality. Theprocessing power of the phone is also orders of magnitude slower than your PC so do not try to be too clever even if the browser supports functionaity like dynamic HTML. There are a lot of nuances that you will need to know about phone browser's such more phones support css built inline in the pages as opposed to residing in a separaste stylesheet, but I will not go into all these details. The dev.mobi website is a very good site to use as a reference particulary look at the online books.

I hope this information helps to get you started and I look forward to hearing about your success stories.

Setting up Glassfish to run as a service on Ubuntu

In order to do this a script needs be created and put into the /etc/init.d folder of the server. I copied this script from Cay Horstmann's Blog and made one or two changes. The main one being that I can spcify the domain to startup.

My script looks like this:

#!/bin/sh -e
### BEGIN INIT INFO
# Provides:          glassfish
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: glassfish initscript
# Description:       A simple initscript for the glassfish app server
### END INIT INFO
#
# Author:            Cay S. Horstmann (http://horstmann.com)
#

set -e

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/glassfish/bin
DESC="Glassfish Java EE5 App Server"
NAME=glassfish
ASADMIN=asadmin
DOMAIN=dev
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0

# Read config file if it is present.
#if [ -r /etc/default/$NAME ]
#then
#       . /etc/default/$NAME
#fi

#
#       Function that starts the daemon/service.
#
d_start() {
        $ASADMIN start-domain $DOMAIN \
                || echo -n " already running"
}

#
#       Function that stops the daemon/service.
#
d_stop() {
        $ASADMIN stop-domain $DOMAIN \
                || echo -n " not running"
}

case "$1" in
  start)
        echo -n "Starting $DESC: $NAME [$DOMAIN]"
        d_start
        echo "."
        ;;
  stop)
        echo -n "Stopping $DESC: $NAME [$DOMAIN]"
        d_stop
        echo "."
        ;;
  reload|restart|force-reload)
        echo -n "Restarting $DESC: $NAME [$DOMAIN]"
        d_stop
        sleep 10
        d_start
        echo "."
        ;;
  *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
        exit 3
        ;;
esac

exit 0

You will need to decide on a service name (e.g. myglassfishservice) and then create a file with that name in the /etc/init.d folder.

cd /etc/init.d
sudo vi myglassfishservice

Paste the above script into the file. Check that the PATH variable points to the correct glassfish home folder and that the DOMAIN variable is the correct glassfish domain name. Then save the file.

Now setup the run groups by running the following command

sudo update-rc.d myglassfishservice defaults

This adds the symbolic links to your service in the folders /etc/rc0.d, /etc/rc1.d, ...

Now reboot the server and your specified domain on glassfish shold start

Installing Glassfish on Ubuntu

Following my article on setting up Glassfish on Solaris, I found the instructions for setting it up on Ubuntu at the Ubuntu forums. Here is the link Glassfish Server on Ubuntu Server

Installing openssl on 32bit Solaris 10 with gcc

Here is how to install openssl on Solaris 10 running on a 32 bit machine.

Prerequisites:
gcc 3.4.6 installed

Installation steps
1) Download openssl source from http://www.openssl.org/source/
2) Unzip and untar the file. e.g.

gzcat openssl-0.9.8h.tar.gz | tar -xpf -

3) cd to openssl directory e.g.

cd openssl-0.9.8h

4) Run configure e.g.

./Configure -shared solaris-x86-gcc

5) Run make

make

6) Run make install

make install

OpenSSL will then be installed

It's more secure if you own the security

I have been thinking about banking and making payments for goods a lot lately and suddenly came to the realisation that we as users always rely on somebody else for the security. Think about it. When we go to an ATM, we assume it is a real one that belongs to the bank because of its branding. If we go to an online website we look at the url, branding and possibly the certificate if we know what we are doing. What about a POS device. Just because it looks like a real one and has the VISA or Mastercard branding does not mean it is. There was a case in the UK a few years ago during some renovation to a storefront when some clever criminal setup a fake ATM were a real on used to be. It looked and operated like the real think. Except it kept saying that it was out of cash. Behind the machine was a little computer noting down the magstripe and PIN numbers of everyone that tried to use it. A similar attack can be achieved with a POS device. It is just so easy. So why do we trust the device. Is it because we just do not know what to look out for.

My view is that the banking industry has an obligation to ensure that financial services are secure. As the criminal minds change, they need to find better ways to combat theses types of attacks. Luckily they are. EMV technology combats this. During the processing of a transaction the smart card can actually validate the validity of the POS device, although I believe this is not always implemented. So how do we do this with other mediums of payments. Online payments are more tricky. Banks are looking at ways to do this, but currently no clear mechanism exists. A nice way would be to get the user to use their mobile phone to authenticate the transaction. As for mobile banking and payments, the only real option that banks are finaly realising is to use the SIM card to authenticate the transaction.

The bottom line is that we as users cannot assume that the device we use to enter our banking details is secure unless we own it or validate its authenticity.

Tool Reference Cards

I came across this very useful website at DZone called refcardz that has a list of reference cards for a wide variety of technologies and tools. Some of these are AJAX, GlassFish, Netbeans, Groovy, Flex, Rails, Design Patterns, RSS, Atom, IntelliJ and even C#. I find reference cards useful, so if you do this site is worth a look.

Java Card 3.0

The Java Card development kit allows you to write code that can run on a smart card. For those that have written code using Java card you will know that the only resemblance to Java is the code style. Almost the entire class library, the garbage collection etc. is different. You also need to understand the APDU format since the coding is done at quite a low level to the smart card.

When writing code for a mobile phone typically the code is written to run on the phone itself. With the Java card technology this code can now run on the SIM card. This has a huge advantage in security since a smart card by nature is very secure. Different portions of the card can only be accessed with certain PIN's and some parts of the card can only be written to when the card is created.

Typically for a mobile banking application the transactions need to be secure. There is no more secure way than signing and encrypting the transaction using a key that is resident on the SIM card. For a SIM browser based application this is typically how it is done, but for an application on running on the phone it is tricky to utilize the SIM cards inherent security.

With Java Card 3.0 it is now possible to write an application using classes and methods that a typical Java developer is used to that can run on the SIM card and to utilize all the security features of the SIM card. This is going to open up the SIM card to a huge group of Java developers to write secure applications.

The specs can be found here http://java.sun.com/products/javacard/3.0/

Installing Glassfish onto Solaris 10

Check the correct version of java is running

* Open a terminal window
* Use bash
type: bash
* Get the version of java
type: java -version
* Check the version is java 1.6 or above

Upgrading java version

* ftp the install package of the JDK to /opt/dropzone
* Give the install execution access
type: chmod a+x jdk-6u10-beta-bin-b24-solaris-i586-14_may_2008.sh
* Install the JDK by running the install script
type: ./jdk-6u10-beta-bin-b24-solaris-i586-14_may_2008.sh
* Check that the installation work by doing a directory listing
type: ls -l
* Move the installation to /usr/jdk/instances
type: mv ./jdk1.6.0_10 /usr/jdk/instances
* Check that in moved successfully
type: ls -l /usr/jdk/instances
* Move the latest symbolic link to point to the new installation
type: rm /usr/jdk/latest; ln -s instances/jdk1.6.0_10 /usr/jdk/latest;
* Check that the latest symbolic link points to the new installation
type: ls -l /usr/jdk/latest
* Move the java symbolic link to point to the new installation
type: rm /usr/java; ln -s jdk/latest /usr/java;
* Check the new java version is being picked up
type: java -version

Copy the relevant deployment of Glassfish to the server

* ftp the install package of Glassfish to /opt/fundamo/dropzone
* Install Glassfish by running the install jar
type: java -Xmx256m -jar glassfish-installer-v2ur2-b04-sunos_x86.jar
* Check that the installation work by doing a directory listing
type: ls -l
* Move the installation to /opt
type: mv ./glassfish /opt
* Change directory to /opt/glassfish
type: cd /opt/glassfish
* Make the ant binaries executable
type: chmod -R +x lib/ant/bin
* Setup the installation for a non-clustered install
type: lib/ant/bin/ant -f setup.xml
o Clustered installations are not covered here, but you should run lib/ant/bin/ant -f setup-cluster.xml
* Move the symbolic link to asadmin to point to the new Glassfish installation
type: rm /usr/sbin/asadmin; ln -s /opt/glassfish/bin/asadmin /usr/sbin/asadmin;

Create the domain

* Go to the glassfish installation directory
type: cd /opt/glassfish
* Create the domain called mydomain that listens on port 80 for HTTP and port 443 for HTTPS. The admin port is port 4848
type: asadmin create-domain --adminport 4848 --domaindir ./domains --profile developer --instanceport 80 --domainproperties http.ssl.port=443 mydomain
* To start and stop the domain use
type: asadmin start-domain mydomain
type: asadmin stop-domain mydomain
* Test the server is running
type: http://<ip address of the server>
type: https://<ip address of the server>
* Configure you application via the administrator console
type: http://<ip address of the server>:4848

Set the domain to run as a service

* Go to the domains glassfish installation directory
type: cd /opt/glassfish/domains/mydomain
* Create a password file called .passwordfile that contain the following lines
AS_ADMIN_USER=<admin username>
AS_ADMIN_PASSWORD=<admin password>
AS_ADMIN_MASTERPASSWORD=changeit
* Create the service
type: asadmin create-service --passwordfile ./domains/mydomain/.passwordfile ./domains/mydomain
* Check the service was created
type: svcs -a | grep mydomain
o You should see output like this
disabled 16:24:09 svc:/application/SUNWappserver/mydomain:default
* Remove the AS_ADMIN_MASTERPASSWORD line from the password file by editing /opt/glassfish/domains/mydomain/.passwordfile (I don't know why, but the service does not start unless you do)
* Enable the service
type: svcadm enable svc:/application/SUNWappserver/mydomain:default
* Check that it is online
type: svcs -a | grep mydomain
o You should see output like this
online* 16:24:09 svc:/application/SUNWappserver/mydomain:default
o If not check the log at
/var/svc/log/application-SUNWappserver-mydomain:default.log

Leveraging the mobile phone

There are huge opportunities to leverage the mobile phone to communicate with your user base. The mobile phone is one of the few devices where you can push a message to your users in real time. Unlike a website or instant messaging application where the user needs to be logged on or email where the user needs first read their email, with a SMS or WAP push message the user can be contacted immediately.
There are many opportunities to leverage the mobile phone for marketing, notifying or prompting users. For instance there are a number of banks like First National Bank's inContact and MTN Banking that send out SMS alerts whenever money is paid from or to your bank account. There are a huge number of companies using SMS messages for marketing messages. There are a number of other uses particularly for two factor authentication like sending an SMS message with a one time pin (OTP) that is entered onto a website during the login process. This proves the user has the mobile phone in addition to knowing the username and password.
With all this added ability comes the inevitable risks. Too many marketing messages will annoy the user. It is therefore essential that the user always has an opt out option. There is also the added risk that the SMS can be spoofed. For instance an SMS can be sent to a user with a WAP link asking them to go to log onto your website, but the link points to a phishing site. This might enable somebody to get hold of a user's password.
So the bottom line is that 'yes' it is a great opportunity to contact your user base, but speak to some consultants who have a strong knowledge about this space before you do so, because there are a lot of pitfalls.

How a SIM browser works

A SIM browser is basically a lightweight browser loaded onto a mobile phones SIM card. It basically renders a form of xml on the phone and allows for communication to a SIM browser gateway. There are to leading suppliers of SIM browser platforms. Gemalto with their S@T Platform and Smarttrust with their WIG platform. Both of these platforms working in a similar way although the format of the xml differs.

The xml is either loaded onto and stored on the SIM card or it can be dynamically downloaded on request. The nice thing about the way the xml is rendered is that it is rendered at the SIM level so it communicates to the mobile phone itself through the same protocol that is used for the other phone specific features. What this means is that the menus and prompts are consistent which the other menus and prompts on the phone.

Communication to the gateway is via SMS, but the SIM browser controls the communication. In the xml an http url is configured and the SIM browser packs this request up into SMS messages and sends them to the gateway. The gateway then unpacks the SMS messages and forwards it onto the application server. The application server would then respond with some xml, which is converted to byte code and packed into SMS messages on the gateway. These SMS messages and then sent to the phone where the SIM browser unpacks the SMS messages and renders the response to the user.

Since the SIM browser runs on the SIM card it has access to the 3DES security plugins on the SIM card and can encrypt data such as passwords or perform generate MAC values to check message integrity. A Security server can also be used on the gateway to perform password translations before passing the password into another security zone.

Mobile Java Banking Applications

Mobile Java Application used for mobile banking are a great idea, but they do come with some few complexities. J2ME is great, the application is sandboxed on the device so there is little bit more security, the Java application will run on a number of handsets, they are written in java and not some obscure phone OS, but two issues in particular bother me.
Although the application is in Java and will run on a wide variety of handsets, there is a complexity firstly to make the user interface look 'nice' on different screen sizes and phone types. The Java APIs and classes on different handsets also differ so whenever your application does something that is not within the standard J2ME spec you are not sure whether it will work or not on all the handsets and this forces the application to be tested on every handset that you want to support. This is a huge overhead for testing and there does not seem to be a clear solution to the problem.

The second issue, particularly with banking applications is that to reduce network traffic you would like to save some data on the device. If you do this you have a big problem because users often change their phones. Even if there is a process to 'rebuild' this data from the server what happens to the data on the old phone. It is not likely that the average user would delete the application and therefore this data could get into the wrong hands. If no data is stored on the phone then you do not get much gain over using J2ME vs simply using the phone's web browser.

Choosing an application server

How do you go about choosing a Java application server? We are currently in the process of doing this and after much deliberation we have come to the following conclusion. There are only really a handful to choose from: IBM Websphere, Sun GlassFish, JBoss, BEA Weblogic and Oracle. Oracle has just bought BEA Weblogic so one of these will be phase out over time. So right I am not sure which one more clarity on this will probably be available from Oracle soon. So the first question is cost. JBoss and GlassFish are free and only require a support license so if you want to embed or setup the app server as part of your product then I would choose one of these. IBM Websphere has all the bells and whistles, but in my mind is far to bulky for most applications and besides the last time I looked it only supports the IBM Java VM. This Java VM is always at least few months behind the Sun VM in terms of supported Java versions.

The next question is whether your client requires a 'big name' behind the server. This eliminates JBoss as it is perceived to be open-source and therefore unreliable. Although in practice this is not the case.

So the bottom line is that with the uncertainty of the BEA-Oracle takeover, Websphere's bloat and JBoss being opensource, the only real option at the moment is Sun's GlassFish.

Coding with incomplete specs

With the current project deadlines it is important to have coding techniques which work when the specifications are being developed after coding has started. So how do you do this. I use two techniques:

Delay decisions as long as possible

I group the work items of an increment into three types namely:

Items that are fully spec'ed with specs that will not change, items that have incompete specs and then items that are fully spec'ed that might change due to dependencies on other incompletely spec'ed items.
First I tackle the completely spec'ed items that will not change and in parallel firm up the specs of the incomplete items that have dependencies.
Next I tackle the items that are completely spec'ed by still have dependencies on incomplete spec'ed items. Choose the order of these items and make a firm best guess decision using all the information that you have at this point on what the dependent item spec would be. After these items are developed the and the best guesss decisions are make ther might be some changes required later where you guessed incorrectly, but the decisions you have made will help define the outstanding specs.

Note that this is not procrastinating, it is a process of waiting as long as possible before you make the decision so that you can make the decision with as many facts as possible. Make a firm decision based on all the facts you have at that time.

Isolating unknown areas of code

The second technique I use is to isolate and code where the specs are unclear. Typically I would create an interface to the unspec'ed area or create a stub of some sort. This allows me to continue with the development without worrying about the details of the unspec'ed or unclear portion of code. When these spec's become clear I can then flesh out the stub or implement the classes according to the spec without impacting the other code.

Mobile Channels

Yet again I see a newscast of a mobile application that was developed in a 1st world country being deployed into a 3rd world country assuming that the environment is similar to what they are used to. This article covers a deployment into Africa, but they want to deploy a Java based solution! Most users in Africa do not even own a compatible handset. It is essential when purchasing or building a mobile application to look at the demographics and environment of the target market to ensure compatibility or else you will be severely limiting your reach.

Continous Builds

Continuous builds are an XP and Agile developer process. It is a process where changes made by the development team are automatically picked up and then followed by a build and a set of automated tests. This the generates a dashboard of all the code modules and their current state. Flagging broken tests or code. Developers can then pick these up and fix them as soon as possible before continuing with more development.
We use Hudson (https://hudson.dev.java.net/) because it is very easy to setup, integrates easily to any and maven as build tools and CVS and SVN for the version control.
The key thing to get right when setting up a continuous build server is to ensure that the build and automated testing can run without user interaction and outside of any IDE. It is no good having unit test that work from inside Eclipse, because you need to be able to run these in a batch type mode. Without this ability, you will always be relying on your developers/testers to run these tests and under pressure this is the first thing that a developer will stop doing right.
Hudson also has the ability to run and report on other checks such as code coverage of the automated tests and 3rd party tools to check for silly coding mistakes. We are using Cobertura (cobertura.sourceforge.net/) for code coverage and Findbugs (findbugs.sourceforge.net/) for code checking and they both work really well particularly in Hudson where we can flag tests that do not have enough code coverage.

Get Agile

Not only is it good practice but in the current environment it is essential that development of new feature is rapid. So with this in mind whether you are starting out on a new project or are adding features to an existing one it is very important that automated tests are built for the application. These tests should be both unit tests and integration tests.
For our unit tests we use JUnit and MockControl. You have probably all heard of JUnit, but possibly not MockControl. MockControl allows you to teach an interface to respond a certain way, thus allowing you to create a stub, but without the need to build a new class. It can check the number of calls made to the stub and it can respond a certain with a certain object by integrating the calling parameter values.
For our Domain layer we use an in-memory database such as HypersonicSQL for this type of testing.
Integration testing is a little more complicated since a certain amount of data needs to be available on the database. For these we use a database of the same type as the production database and load the database using DBUnit.
Next time I will look at automated build and continuous integration using Hudson.

Characters are not always what they seem

We recently ported our application from Linux to Solaris and suddenly pound signs on the web front-end became a ? marks. This was because Solaris has a different default character set that cannot display a pound sign. Since we were not allowed to change the character set of the operating system, we had to make changes in our code.

In tracking down the issue a developer logged out the pound sign at various points in the code. They all appeared as ? marks. So it seemed that the moment the pound sign was created it was converted. It turned out that this was a wild goose chase. The byte value fro the pound sign was correct. The operating system was converting it when it wrote it to the screen or log file. It seems obvious now that this should happen, but it was not that obvious at the time.

It is very important to always specify the character set when converting byte values to characters. If you are not sure of the character set to use UTF-8 should be adequate for most applications.

In Java web applications you also need to ensure that the HTTPServletRequest's character set is set otherwise some characters sent to the server in the GET or POST requests will not convert correctly. This needs to be done before reading any parameter values from the request.

The other common place to set the character set is when reading and writing files or reading and writing data from a network connection.

SMS message lengths

One of the critical issues with writing a system that interacts with users using SMS messages is the cost of the SMS messages. This cost needs to be accommodated in the business plan as it has a major ongoing cost. Since SMS messages are normally 160 bytes for a single message and 140 bytes for concatenated messages it is critical to ensure that you message fits into the fewest number of messages. You do not want your message to span 2 SMS messages because it is one byte too long.
SMS messages use a 7-bit alphabet and the majority of characters fit into one byte. There are as always exceptions such as the euro symbol or a square bracket. This alphabet is specified in the GSM 03.38 specification.
Have a look at http://www.dreamfabric.com/sms/default_alphabet.html to see the full alphabet.

Processing incoming requests

Let us look at processing incoming request from different mobile applications. Depending on the channel the request might be asynchronous or synchronous, by this I mean the response is is sent using a different connection to the request vs the response being sent on the same connection of the request.
An example of an asynchronous channel would be SMS. The mobile phone sends a SMS to the server via the mobile network operator's infrastructure, the server process the request and then establishes a connection to the mobile network operator to send out the reply SMS. The incoming and out going SMS are not tied together in any way other than by the data they contain.
An example of a synchronous channel would be HTTP over GRPS. Here a connection is opened, the HTTP request data is sent to the server, the server processes the request and sends the response data down the connection and the connection is closed.
For asynchronous communication your application will require a level of internat thread management. This is difficult to achieve using many web scripting languages such as php whereas for synchronous communication you can get away with a web scripting language. To build an application that supports both types of communication requires a lot of thread management and synchronization techniques.

Security for mobile applications

Security capabilities differ considerably depending on the channel used. By channel I mean the technology used for the user interface and the communication mechanism to the back-end application. Some channels allow for no encryption at all and are deemed to be very insecure. A standard text SMS would be such a channel. The text cannot be encrypted so entering a password in an SMS is not a good idea. SMS messages use a store and forward protocol and thus can be intercepted and changed. In addition to this they are left in the 'Sent Messages' list on the users phone. More secure channels such as the SIM Browser solution from Gemalto and Smarttrust allow for data encryption within the SIM card of a GSM mobile phone. The encryption normally used 3DES and a secure key resident on the SIM card. This channel will be extremely secure as the encryption is performed within hardware components. For the MTN Banking run by the MTN mobile operator a Mastercard PIN is entered on the mobile phone.

Off-deck applications

On mobile devices off-deck applications are much easier to deploy since deployment of on-deck applications can be difficult for the average user. Off-deck applications include SMS, USSD, IVR, WAP, HTML etc. The way this type of application works it the the user submits a request by dialing a phone number, submitting a url from the phone browser or sending an SMS. The server on receiving this request guides the user through the application using menus and prompts for input.
In general off-deck applications are easy to use, but require more bandwidth and this could be expensive. It is critical to look at the cost of communication when building this type of application. The Fundamo mobile banking and payment system supports a wide range of channels and each of these have been tuned to reduce the bandwidth of the communication.
I will look at each channel in more detail in later posts and explain how they work and communicate to the server, but in my next blog I will look at the security aspect of the communication. Security is crucial for m-commerce, m-payments and m-banking systems.

On-deck applications

There are a number of on-deck application frameworks that can be used for developing mobile applications. Some examples include Java ME, Windows Mobile, Google's Android phone, Symbian applications etc. Some of these frameworks are more widely supported across and range of mobile phones and some are specific to certain operating systems on the phone. Determining what to develop your application in really depends on which phones are more widely used. This information can normally be obtained off the web or from the mobile network operators.
One you decide on the application framework you will need to look at the differences in screen resolution for the phones used by your customer base.
For the above reasons on-deck applications are difficult if your application has a wide user base. Java ME is probably supported my the widest variety phones, but ways to managed the screen resolutions will need to be built into your application. In the past the Java classes present in the virtual machines differ from one phone manufacturer to the next. This adds to the complexity of your deployment because classes might be missing or clash with existing ones. The bottom line is that there is an ongoing overhead to test new phones as they become available and manage the screen resolution and packaging differences.

Future proofing your m-commerce application

It is essential to abstract the communication and user interface rendering layer from the business process of the application as one would in a typical web application. This is critical whether you are writing an on-deck (mobile device resident) application or a thin client application. What makes this more complicated is that your application will need to deal with multiple communication and user interface rendering implementations concurrently.

My suggestion would be to employ agile development processes. If you have not read Lean Software Development: An Agile Toolkit by Mark and Tom Poppendieck then I strongly recommend reading it. One of the tools they cover is in how to delay decisions as long as possible during the development process. One of the benefits of this is that it forces interfaces to be build thereby abstracting the decision. So by using this tool changes in the communication mechanism and/or the user interface will not impact the rest of your application. Future devices with new user interfaces or ways of sending your application data can also easily be added.

Why is m-Commerce not like e-Commerce

m-Commerce applications are considerably more complex. The biggest complexity lies in the user interface and the communication to the back-end server. With e-commerce applications typically a browser with HTML is used for the user interface and HTTP/S is used fro the communication to the back-end server.
With m-Commerce you are dealing with a wide variety of potential devices. Most of devices that will use your system are probably not even built yet. There are a lot of different mobile phones and devices and each one has different criteria in terms of screen size, supported colors and input mechanisms. How do you write a user interface that will work with a wide variety of devices and look good? More importantly in the time it takes to build your m-commerce application a whole new set of device will have been developed. How do you deal with that added complexity?
Then there is the communication to the back-end server. Will your application communicate using HTTP/S, SMS, USSD or another one of the many protocols supported by mobile devices? How will this data be securely transmitted to your back-end server? In future posts I will be looking at how you can decide what to support and how to implement some of these solutions.