Synchronicity and Coupling

Are synchronous calls more tightly coupled than asynchronous? If so, why?

Consider this; in an asynchronous call I have to deal with an extra piece of information: a message correlation token (extra requirements adds to coupling). So, that's bad, right? Yes, it is - but it isn't a big issue - deal with it.

If I'm trying to keep the conversational requirements to a minimum, then wouldn't I be better off not stating a preference (agnostic synchronicity)? The very fact that I state a preference increases the coupling level, right? (additional requirements = higher coupling) Yes, it does - but convince the programmer to design an application where you don't know the synchronicity requirements. But all that shouldn't matter. The "ubiquitous protocol" stack (girthy as it may be) will abstract me from the considerations related to "protocol coupling" (correlation in the WS stack), right? Yes, the (semaphore / clock / correlation) issues will be factored into the protocol. Hence, we are having a moot discussion.

Ok, --- try this on: I reduce coupling (and increase flexibility) if I break up the transmission paths of a request/response message exchange pattern (mep). This is to say that I have stated that, "I don't care who sends me the result back". In a synchronous call, the implication is that the ultimate receiver doubles as the ultimate sender on the return path. Not so in an asynchronous conversation. Thus, I increased flexibility by stating that I don't care who sends me the return message. And you could argue that by adding to the **I don't care** attitude, I have decreased coupling.

Some might argue that long running transactions are facilitated by asynchronous calls. I believe that this is an implementation issue and not directly an issue of coupling. LRT's can be hydrated and dehydrated to maintain high performance. I will argue that synchronicity has very little impact on coupling. Now, I will also argue that synchronicity has a SIGNIFICANT impact on distributed computing performance. The ability to take a request and spawn it off to some other agent and have it return the results on your behalf is powerful (alternate return path). The ability to receive 1,00,000 request, sit on them for 72 hours (LRT's) and respond without your system blowing up is powerful as well. The ability to use SOAP over HTTP on the in-bound call and switch to SOAP over SMTP on the out-bound call is also powerful. All good things, but are they related to coupling?

I've been sitting on this blog for over a month now. The question I keep posing to myself is, "do synchronous calls increase coupling levels", and the answer that I keep coming back to is, "they do, but by such a small amount that you shouldn't care - however, synchronicity can DRAMATICALLY affect system performance and flexibility".

I've also landed on, "who cares". So what if synchronicity is a performance/flexibility issue and not a coupling issue. The point that people are making is that you have to strongly consider synchronicity in your distributed architecture. The real goal is to make your systems work with your business partners while not requiring a fleet of mainframes to make the system perform. I just don't want people to get in the habit of throwing too many things in the "coupling bucket", when they are actually more strongly related to other non-functional aspects of distributed systems design.

Am I right? Honestly - I'm still not sure.