Notional architecture

This page includes the details of the notional architecture.

Deployment View

Source UMLet diagram

Thunderforce lives inside Mozilla Thunderbird as an extension that communicates with the remote Salesforce.com servers using the simple object access protocol (SOAP) and caches information locally using SQLite. A SOAP implementation and SQLite are both built into the Mozilla platform.

Note that this approach will limit the number of Thunderforce clients that can run simultaneously due to API call limits. Thunderforce will include features that limit the number of API calls made in addition to basic API call statistics, such as expected versus actual API calls per hour and the total number of API calls over the past 24 hours. Those statistics can be divided into your organization's daily API call limits to determine how many Thunderforce installations you can have active during the day.

A future extension to the deployment view can involve an optional network server that receives workflow outbound messages from Salesforce.com and broadcasts those changes to local clients to reduce the amount of polling that Thunderforce has to do. Such a server can also substantially increase Thunderforce's scalability as it can be deployed to more computers without drastically increasing the number of API calls performed in a day. Perhaps a generic, client-agnostic solution similar to this might get built in the future (note that this is not a promise of future functionality).

Runtime View

Source UMLet diagram

Thunderforce is largely structured using the model-view-controller pattern to present Salesforce.com data to the end-user using bidirectional interconnects. With Salesforce.com as the master record, changes from any part of the system are pushed down to the lowest layer, and notifications regarding that change propagate from the lowest layer to the top, which is the view.

Salesforce.com's AJAX Toolkit and Mozilla Thunderbird's interfaces differ in various ways. To resolve this impedance mismatch, the Thunderbird interface implementation layer performs the necessary translations, implementing Salesforce.com as regular Thunderbird objects in the process.

Above the model layer, Thunderforce implements a minimal set of XML user interface language (XUL) overlays to extend the view and JavaScript-based user interface behavior override code to extend the controller. With this strategy, most of Thunderforce's functionality lives within the model and leverages Thunderbird's built-in functionality as much as possible.

Module View

Salesforce.com data layer (model)

The diagram above depicts how the data layer components relate to each other. They all extend from the API abstract class, which includes methods from the Salesforce.com AJAX toolkit.

To facilitate bidirectional use of the Salesforce.com API, the BidirectionalAPI extension of API implements an event notification system and periodic polling

Work in progress...

A general write-back flag is included to tell an API implementer to return as quickly as possible and update its backing store later instead of synchronously. The cache object will use the write-back flag to signal offline mode so that changes are logged for an eventual commit to Salesforce.com. When write-back is off, write-through caching is implemented in the cache.

Updates that are routed through the cache will cause the cache to signal an immediate update to the registered listeners. Before committing that change, however, the objects being updated are queried to see if any have changed in a conflicting way. If that is the case, then an exception is thrown with an appropriate error message so that the user will know that a change conflicted with their action and that the current states of Thunderforce for the conflicting objects are now consistent with Salesforce.com. If the change does not conflict, the record is updated and an immediate background data refresh is triggered to account for changes to formula fields and Apex triggers, etc. Listeners are notified of the data change from the cache. When the changes come back from the server, the changes that were already in the cache are not propagated back to listeners.