SSNNotify was originally conceived as a replacement for the now discontinued Amazon Services Order Notifier (ASON). Sometime during 2010, Amazon announced that it was discontinuing support for ASON and would stop distributing new copies.
The problem for users was that ASON used X.509 certificates to communicate with Amazon servers and as a way to discover a Seller's account. These X.509 certificates had an expiration date that, when expired, would require the user to install a new certificate to continue using ASON. When Amazon discontinued ASON, there was no longer any way to install a new certificate and the program would stop working.
Web vs. Desktop
At the time, we were working on our first public application that was unrelated to order processing but saw this as a great opportunity to introduce our company to the community and decided that we needed to quickly develop a replacement.
We evaluated a few different architectures including web based, but soon decided that we needed a desktop application and, since we wanted to capture as much of the market as possible, wanted to support all the major platforms. The web based application architecture was definitely attractive since we could support all of the major platforms and be certain that users were getting the latest version; all the things we love about the web.
The problem for SSNNotify in the context of a web application was twofold:
- Firstly, and perhaps most importantly, was the perceived security of the application. As I've discussed, Amazon uses X.509 certificates to authenticate the user and is the only thing that is used to locate your order information. So if a malicious user were to gain access to your X.509/Private Key pair, they would have the ability to view all of your order information. If we were to have built a web application, the user would have had to entrust us, an unknown entity, with this sensitive data and in turn we would have had to have a much higher level of security in place to minimize any issues. So, as an unknown entity there was the possibility of being perceived as an unacceptable risk by the users which may have had an impact on adoption rates.
- The second issue with a web based application was infrastructure. As a small company just starting out, and planning the development of a free application, we were unsure if we could support a large amount of users with the small amount of resources available. Looking back, I am confident that we made the right decision, as we have a large amount of users who expect to check for new orders every 15 minutes. Some of our users have a large volume of orders, somewhere in the 10,000 a month range, which could cripple our infrastructure, especially around the holidays, the most crucial time of the year for a retail business.
So it all boiled down to two things: supporting the major operating systems and shipping a desktop application. The language clearly needed to be Java since we needed to support multiple platforms quickly and so we evaluated both the NetBeans Platform and Eclipse RCP.
Eclipse RCP vs. NetBeans Platform
We liked the fact that Eclipse RCP used native components but in the end this turned out to be a bigger con than a pro. Since we needed to develop SSNNotify quickly, we needed to have access to all the great open source components that were already available for Swing and, since the NetBeans Platform is based on Swing, the winner for this consideration was clear.
The other consideration during evaluation was the need to provide an installer since our target users are considered to be of low technical ability. The NetBeans Platform was the clear winner in this category as well since NetBeans IDE includes the ability to quickly build an installer for your application. So, based on our requirements for a Swing based application, and the need to include an installer, the NetBeans Platform was the winner.
We also use the NetBeans Platform's update capabilities in a custom way to allow SSNNotify users to easily check for and install updates. The module system makes this simple to do and keeps downloads to a minimum as only the modules that have updates are downloaded. The module system has also allowed us to create a subscription based plug-in that adds functionality to SSNNotify that goes beyond the abilities of ASON. We are also grateful for the Lookup system and use it frequently to facilitate a loosely coupled design.
There are of course many other benefits in using the NetBeans Platform such as its Wizard dialogs and the Options system with built in import/export abilities. Overall, we are very happy with our choice and we do not think that SSNNotify would have made it to market as quickly as it did had we chosen another architecture/platform.
We would like to extend our many thanks to Oracle and the NetBeans community for making and maintaining such a fine platform for Java and Swing application development.
The freely available SSNNotify:
Our subscription-based application that adds several enhancements to SSNNotify: