Architecture - Hillsborough-Transit-Authority/onebusaway-application-modules GitHub Wiki
Originally, the OneBusAway system architecture was just a single server process that handled both the web and phone for just one transit agency, King County Metro. However, in order to expand OneBusAway to more easily serve multiple, distinct user-interfaces for multiple transit agencies with support for high-availability, clustering, and dynamic fail-over, the architecture needed an update. We moved to a more modular design where different user-facing interface components, whether they be web, phone, SMS, apis, or something else entirely, can be more easily run as multiple distinct processes, with actual transit data served from a back-end server process that can better partition data across multiple transit agencies in a reliable way.
This document serves to describe the architecture with a high-level overview as an introduction to developers so they might both understand OneBusAway as a whole and also understand which module to look at when modifying or adding new functionality.
Architecture Overview
Consider the following diagram:
IVR = interactive voice response = phone system
The diagram shows separation between the user interface services layer and the transit agency data services layer. Notice that each of the user interface services runs as separate, and possibly redundant, instances. Also notice that the transit agency data services are broken up in to multiple service instances as well. The separation of user interface services was made for a couple of reasons: the separation of concerns supports more targeted development and multiple processes can more easily run for fail-over and clustering as performance needs change.
The separation of the data later was made for similar reasons, but with a slight twist. The data for different transit agencies gets compiled into an optimized graph structure to support fast trip planning operations. These graphs take a non-trivial amount of time to build and they can grow quite large in size for large overlapping transit agencies. Much as we wanted to move away from one unified server process at the user interface level, we wanted to similarly break up the transit agency data so that updates to data from one agency didn't require reprocessing the data for all agencies. We went with a federated approach, where federation is a partitioning scheme that takes advantage of the of existing, natural boundaries in the data.
For example, consider serving data for both Seattle-area and Portland-area transit agencies. Since users aren't really able to easily take public transit from one area to the other (Amtrak excluded from the discussion for now), we can federate these two data sources into two distinct islands of data. Updates to one shouldn't require changing the other. Note that federations are partitioned at the agency level, since there can be a lot of overlap between agencies and their areas of service (example: King County Metro + Sound Transit + Pierce Transit + Community Transit).
Where do the various modules we've defined above fit into this overall schemed? The user interface modules are pretty obvious. Modules for the web interface (onebusaway-webapp), the phone interface (onebusaway-phone), the sms interface (onebusaway-sms-webapp) and the external APIs (onebusaway-api-webapp) are each pretty clear to their purpose. Each of the user interface services has controlled access to transit data through an instance of the org.onebusaway.transit_data.services.TransitDataService interface. This interface is defined in onebusaway-transit-data, along with all the bean classes for data passed back and forth by the interface. Implementation of that interface is handled by the onebusaway-transit-data-federation module, which provides the bulk of the business logic for schedule computation, real-time arrival handling, trip planning, and other operations. For more detail on how calls to TransitDataService are routed to the appropriate federated implementation instance, see FederatedTransitDataDesign.