OneBusAway/onebusaway-application-modules — pull request #86 by kurtraschke (2014-02-10 21:56:25+00:00)
Title: Improve federation of OBANYC TDS methods.

The OBANYC `NycTransitDataService` methods were folded into the core `TransitDataService` in onebusaway/onebusaway-application-modules@4501b66c7410b2909a75b1091684aa2fda440d7b.

This PR is to improve the federation annotations on those methods (and in a few cases the method signatures as well). For single-TDS deployments without federation, these changes would have no impact, and the new method signatures are in fact just a return to [the method signatures formerly used in `NycTransitDataService`](https://github.com/camsys/onebusaway-nyc/blob/4553b7dbb872e2db3290a8f598e008feea665871/onebusaway-nyc-transit-data/src/main/java/org/onebusaway/nyc/transit_data/services/NycTransitDataService.java).

The specific changes and rationales are as follows:

* `getActiveBundleId`: The active bundle ID is a property of an instance, not a specific agency. The most likely use case for a consumer in the federated case is to determine the bundle IDs of all of the instances backing the federation server. Thus the `FederatedByAggregateMethod` annotation is used. In this PR a `List` is used, but that could be replaced with `Map` if it were desired to have (instance ID, active bundle ID) tuples.

* `getPredictionRecordsForTrip`, `routeHasUpcomingScheduledService`, `stopHasUpcomingScheduledService`: An explicit 'agencyId' parameter is not necessary, because `FederatedByEntityIdMethod` can extract the agency ID from a parameter or even a property of a parameter.

* `getSearchSuggestions`: As with `getActiveBundleId`, partition by agency ID doesn't really make sense; logically a consumer of a federated instance is going to want to get search suggestions aggregated from all of the TDS instances backing the federation server. As the return type of `getSearchSuggestions`