When we designed Service Broker we tried to make a very clear distinction between design time (when you write the code) and deployment time (when the code is actually used in production). We took very explicit measures to be able to completely reconfigure the deployment without changing a single line in the the application code. We considered things like the message type, contract and service names used as design time. How you write your activated procedure and the RECEIVE, the code that issues BEGIN DIALOG/SEND verbs are all, again, considered design time.
Deployment time are things like routing information (which changes when the physical topology of the network changes), certificates used for security (they expire and require replacement), permissions, endpoints ports etc.
A special case is dialog security and remote service bindings: it is a mixture of design time (application code specifies WITH ENCRYPTION = ON) and deployment time (a remote service binding is present). The idea is that if an application requires dialog security it must specify ENCRYPTION = ON (which is the default if not specified) and then the administrator, at deployment time, must configure dialog security. Or, if the application does not explcilty require dialog security it can specify ENCRYPTION = OFF and then is up to the administrator, at deployment time, to configure dialog security if he chooses so.
Everything related to endpoint security (transport security) is considered deployment time.
Finally a great deal of care was put in place to make the programing experience and the available API behave identically whether your pair of services is local within a database, in two databases on the same instance or on two separate instances (ie. make sure coupling does not creep in).
I provided this explanation in hope it sheds some light and puts things better in perspective. To answer your questions: you certainly can write an application that is compeltely agnostic to the actual physical layout of your deployment, including the name, location, listening port and number of hosts involved. Basically the application code is all about services conversing with services and has 0 knowledges about routes, certificates, endpoints and so on. But that is all from the point of view of application development. In practice the deployment is often automated and is an application in itself. Even if, as often the case is, is the same person or team that codes both applciations (or both sides of the same application) is healthy to think at it as two compeltely separate tasks (or apps). If you can make this separation and keep the code clean, you're nealy there. The 'app' code has no knowledge whatsoever about where the service it talks to is, or where has the message it processes was sent from. The configuration code (or app) is all about knowing exactly where a service resides, how should a route be configured, what endpoints are listening on what ports etc etc.
As a side note, there is a thing called Service Broker Dynamic Routing which allows a configuration in which SSB itself is used to configure a large deployed site (ie. SSB can contact a central repository to locate routing info) but I would not recommend it.