Who Dials the Phone

Module 1 of 5 in the chapter The Client and Server, chapter 2 of the Integration Architect course. Each module stands on its own. Previous chapter: Think Like an Integration Architect · Next: Finding the Server

The question this module answers: In any integration, which side is the client and which is the server, and how do you tell?

Let’s start with the smallest brick there is. What is an integration?

An integration is a system or process that needs to talk to another system or process. That’s all. And I say “process” on purpose, because the two don’t have to be far apart. You can have an integration on the same physical machine: one process running that needs to talk to a different process. It could be another machine in the same data center. Or it could be a machine on the other side of the world. The distance changes a lot of the details. It doesn’t change what’s happening.

And when they talk, one of three things is going on. One side is sending data, or asking for data, or asking the other side to do something.

Somebody Dials

Here’s the part people skip. An integration has to start somewhere. Two processes wake up, and now they need to communicate. But they can’t both just wait. One of them has to start the conversation.

Think about calling someone. If I want to talk to a colleague, I dial the phone and call them. If they want to talk to me, maybe they send me an email. Either way, one side starts the conversation.

Integration works the same way. There’s almost always a client who dials the phone, and a server who answers.

• The client is the one that starts the conversation. It knows who it wants to reach and decides when to call.
• The server is the one that answers. It has to be there already, listening, before anyone calls. It doesn’t know a call is coming until it rings.

That’s the whole definition. It isn’t about which system is bigger, or more important, or which one owns the data. A small partner system can be the client and Salesforce the server. Salesforce can be the client and a tiny web service the server. Ask one question: who dials?

Push or Ask

Now the second question, which is a different question. Once the call is connected, which way does the data go?

I may call a colleague and say, “What’s going on?” and they tell me things. I called, but they did the talking. Or I may call and tell them things. Same phone call, same caller, and the information goes the other way.

So a client can call and push data, or call and ask for data. Pushing and asking are about the data. Client and server are about who dials. You saw this in the first chapter, with Data Loader: a load and an export are both started by your laptop, and the data goes opposite ways.

Here are two calls from the Steve Trucking landscape we met in chapter 1.

Click to enlarge

Redrock dials, and pushes its manifests in.

Click to enlarge

A Recipient’s phone dials, and asks. Both are clients; the data goes opposite ways.

Redrock is a client: it dials, and it pushes. The Recipient’s phone is a client too: it dials, and it asks, and the answer comes back to it. In both calls, Salesforce is the server. It didn’t start either conversation. It was listening, and it answered.

One Call, Many Turns

So far, each call did one thing: push, or ask. Real conversations often do more. Once the client is connected, it can take several turns on the same call. It asks for something and gets the answer. It sends something and gets an answer to that. Then it hangs up. Back and forth, pushing and asking.

But look at who drives it. Every turn is the client’s. The server answers each one, and never starts one of its own.

Click to enlarge

One call, many turns. Redrock opens it, takes every turn, and closes it.

On the web, each of those turns is a request and its response, and several of them can travel over the one connection the client opened. Chapter 3 takes a request apart. For now, the picture is enough: the client opens the line, the client takes the turns, and the client hangs up.

If the Line Drops, the Caller Calls Back

Think about the phone again. Someone calls you, and halfway through, the call drops. Who calls back? The person who made the original call. You may not even have their number.

With a client and a server, that’s a strict rule. If the connection drops, it’s the client that reconnects. The server doesn’t call out to find it.

And there’s a good reason. A server can be taking calls from thousands of clients at the same time; a busy one, hundreds of thousands. It’s answering whoever rings. It doesn’t keep a list of who to call back, and it couldn’t call them all if it did. Its job is to be there, listening, when the client tries again.

So what if a server does need to start a conversation? Then, for that conversation, it’s dialing, and that makes it the client. Salesforce answers Redrock when Redrock sends manifests. When Salesforce calls Redrock to send a delivery’s status back, Salesforce is the client and Redrock is the server. Same two systems, two calls, and each one is a client in one and a server in the other. That’s not an exception to the rule. That’s the rule: the client is whoever dials. Module 4 comes back to the two systems that call each other.

This is why I keep saying the client owns the conversation. It started it, it’s the one waiting for the answer, and if anything goes wrong on the line, it’s the one that has to notice and call again.

“Almost Always”

I said almost always, and I mean it. Even where it looks like nobody dialed, somebody did. When we get to events in chapter 11, a system that wants to hear about changes in Salesforce still starts the conversation: it calls Salesforce, subscribes, and then waits on the line for the news to arrive. The waiting is different. The dialing isn’t. And if that line drops, it’s the subscriber that calls back, and asks for everything after the last event it saw.

The same is true when an AI agent calls a tool. The agent dials; the tool answers. Chapter 21 comes back to that, and to who the agent is signed in as when it does.

Why It Matters Who Dials

So why make such a fuss about it? Because the side that dials and the side that answers carry very different jobs.

The client has to know where the server is, prove who it is, speak the server’s language, and deal with whatever goes wrong on the way there and back. The server has to be there, listening, decide who’s allowed in, and answer what it’s asked. Get the client and the server mixed up on a project, and you’ve put those jobs on the wrong team.

That’s the rest of this chapter. Module 2 is how the client finds the server. Module 3 is how it knocks on the door. Module 4 is each side’s dance moves, which I call the client–server tango. And in module 5, you’ll be the client yourself.

What an Architect Decides Here

• For every arrow, which system dials and which one answers.
• Separately, whether each call pushes data, asks for data, or asks the other side to do something.
• Where each server must already be listening, and who keeps it listening.
• For every client, how it notices a dropped connection and reconnects, because the server won’t call it back.
• When two systems both start conversations with each other, that they are two calls, with two clients, drawn as two arrows.

Explore

• The previous chapter, Every Arrow Is a Decision: who starts the call isn’t which way the data goes.
• The next module, Finding the Server: addresses, domains, ports, and someone listening.