The term SOA is always mentioned with the underlying connotation that a client requests a resource and somehow there is an extra step of "service discovery" whi

The term SOA is always mentioned with the underlying connotation that a client requests a resource and somehow there is an extra step of "service discovery" which has it's own set of problems that branch out into various fields of physics and mathematics. When I see such branching complexity, I often think that the architecture is somehow wrongly backwards and try a simple reversal of responsibilities. In this case, the services would be looking for a job to complete, in effect turning the afromentioned step into "job discovery" which is indeed the kind of architecture I've been applying the past decade. Seems to be working well so far. Back pressure is handled at the front gate as none of the services pick up on the job, involuntary synchronization is still a problem, but avoidable by cleverly re-ordering the job queue. The job completion is communicated back to the front gate through pub/sub and the anecdotal evidence so far has been great.