Accessing Service Broker from Different Databases
Consider the Asynchronous Procedure Execution example. One approach is to simply have one DB hosting all the SSB objects involved (the services, the procedure, the activation queue etc) and simply call the invocation procedure usp_AsyncExecInvoke across DBs, eg. EXEC SSBExecutionDB.dbo.usp_AsyncExecInvoke .... The SSB activated procedure could in turn run the code in the DB you invoke it from, by simply passing in a fully qualified 3 part name to execute:

EXEC SSBExecutionDB.dbo.usp_AsyncExecInvoke 'MyDb.dbo.MyProcedure';


Note that your procedure will execute under activation EXECUTE AS context and will thus be subject to the EXECUTE AS sandboxing. You must either mark the SSBExecutionDB as TRUSTWORTHY, or use code signing, see Signing an Activated Procedure.

This approach keeps all the SSB infrastructure in one place (in one DB) so it may be feasible for you. The disadvantage is that it does not leverage the loosely coupled SSB model which would allow you to schedule the async procedure even when the executionDB is not available. It also introduces a tight coupling between your DBs and the execution SSB DB, which creates problems vis-a-vis restores and failover (mirroring).