Broker
A broker pattern is the easiest pattern / architecture to separate here. A broker component is simply an component within a distributed system tasked with coordinating communication between other components. The system at large can be synchronous (a request that waits for a response) or asychronous (a message that receives a response later or never). A broker pattern is simply system that uses brokers for coorindating its communication. Generally in these type of systems you don't use the term client - server but rather producer - consumer. Most often I see this implemented in asychronous environments or in systems where the producer (the thing sending the message) doesn't know anything about the signature of the consumer, or when the producer needs to fan out to many consumers.
client server dispatcher
A client server dispatcher pattern has three main components. The client can be thought of as the source of the request and the server is the destination. In between the client and server you have a dispatcher which creates a channel for requests to navigate to the server. In this way you can abstract the physical location of the server endpoint. This is almost always a request response model and the reason I see this implemented most often is to maintain the ability to do things that swap out physical endpoints for other endpoints for performance reasons, or to allow versioning or API endpoints.
service oriented architecture
Unlike the other two, service oriented architecture is not a pattern but rather an architecture. An large SOA environment will likely have client server dispatcher patterns and also broker and/or pub sub patterns. In SOA, a service is suppose to represent a single business activity, be a black box to the client (except possibly for the services signature), be self contained, but may consist of other underlying services.
This one is a bit more abstract so I will give you a use case.
In an SOA environment I work with we have a business process that assigns credits to be approved to sales people based on where that company is geographically located. The workflow process that assigns the work has both functionality find the salesman for a company but geographical location. Instead we have an enterprise service bus that sits on a completely separate server. This *service bus" sits behind a reverse proxy that distributes the requests to different servers running the same service bus based on current load.
In this way you could way that we are using a client server dispatcher model where the workflow is the client, the reverse proxy is the dispatcher, and the final service bus is the server. However, once the request gets to the final destination it then is routed to one of several hundred small, individual "applications" (or services) that is tasked with doing one thing and one thing only. In this case the service takes in a company id and returns a salesman.
Once it gets to the service that service then reaches out to various web services (our erp system, our SugarCRM system, etc) and returns the username of the salesman. The client has no idea about the logic in the service and moreover doesn't even really know that service exists. It only knows to send in this data with this "key" and then takes the response and assigns the unit of work to whatever the value of the response was. Similarly the service has no idea what the client is doing with this information or even that the client exists.
In this regard we have very very loose coupling. The client and service are abstracted by multiple levels of abstraction. This service doesn't care if the client is expecting a response immediately (reauest response) or if it's a pub sub or anything.
