Notional architecture

This page includes the details of the notional architecture.

Deployment View

Source UMLet diagram

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

Package thunderforce.sforce

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.