Pick up a telephone receiver, dial and speak soon thereafter with someone? That’s synchronous. Use e-mail and no response until minutes, hours or days later? That’s asynchronous.
With synchronous telephone calls, “you have to agree to be on a phone call, and we have to speak the same language. And when you ask questions on a phone call, you have to wait for an answer,” explains Doug Kaye, consultant and author (doug@rds.com) living in Marin County, Calif. “But with [asynchronous] e-mail, you send a message when you want. I read it when I want and respond when I want. If it’s in a different language, I can get it translated.”
Generally, real-time, synchronous messaging has other inconveniences. “If you wanted to ask five people the same questions, and you do it by telephone, you have to go through the effort of setting up and conducting the interviews,” says Kaye, author of “Loosely Coupled: The Missing Pieces of Web Services,” published by RDS Strategic Services LLC (www.rds.com). The problem is, though, if those same people wanted to contact and speak with you simultaneously, you physically cannot do that.
Tailor to schedule
But asynchronous messaging’s beauty is that communications can be tailored to sender/receiver abilities and schedules. With e-mail, its loosely coupled attribute gives “more of a serial capacity, spread out—vs. the burst [of the telephone call],” Kaye says. Responses typically are not real-time, though. That serial functionality is the same when automated systems communicate with messages to each other. “Each system has its own set of responsibilities, the language it speaks. Each system is responsible for scaling its tasks that are best suited for its system,” Kaye adds.
These messaging systems all seem to have quality-of-service issues requiring some additional layer of reliability built into the services, Kaye adds. For example, “you can have an unreliability messaging layer, but you can also add an acknowledgement or reliability layer on top of that,” he notes.
Clearly, real-time synchronous aspects exist within asynchronous systems, though. For example, robots must do something spatially at specified times. That requires the system sending a message to another to track the message. “But in a synchronous system, you do not have tickler file. You call me and you reach me or not,” he explains.
But overall, at some level, loosely coupled asynchronous systems break down into smaller tightly coupled systems, Kaye comments. “For example, send messages to a microprocessor in a milling machine. That microprocessor then sends tightly coupled hardware signals.” He notes that with tight coupling, interfaces between systems are very well defined. “The microprocessor knows exactly how to run that motor,” for instance.
As time constraints lessen or loosen with processes, though, “you’re more likely to use loosely coupled systems,” Kaye states. Clearly a fan of asynchronous messaging and loosely coupled systems, he emphasizes that this type of messaging gives scalable systems more independence of one another. One of the most important benefits of independence? “You can actually get by with somewhat less planning.”
That’s important, Kaye believes, because of how some industries grow. For example, if a factory is designed to produce 100 units per hour, and five years from now, production needs to increase to 10,000 units per hour, “you’ll build a fundamentally different factory [then].”
Applying that example to service-oriented architectures, however, Kaye forecasts that “if loosely coupled [truly asynchronous], though, it’s less likely you’ll have to change the architecture of your systems. And that’s a huge benefit.”
C. Kenna Amos, ckamosjr@earthlink.net, is anAutomation WorldContributing Editor.
RDS Strategic Services LLC
www.rds.com
With synchronous telephone calls, “you have to agree to be on a phone call, and we have to speak the same language. And when you ask questions on a phone call, you have to wait for an answer,” explains Doug Kaye, consultant and author (doug@rds.com) living in Marin County, Calif. “But with [asynchronous] e-mail, you send a message when you want. I read it when I want and respond when I want. If it’s in a different language, I can get it translated.”
Generally, real-time, synchronous messaging has other inconveniences. “If you wanted to ask five people the same questions, and you do it by telephone, you have to go through the effort of setting up and conducting the interviews,” says Kaye, author of “Loosely Coupled: The Missing Pieces of Web Services,” published by RDS Strategic Services LLC (www.rds.com). The problem is, though, if those same people wanted to contact and speak with you simultaneously, you physically cannot do that.
Tailor to schedule
But asynchronous messaging’s beauty is that communications can be tailored to sender/receiver abilities and schedules. With e-mail, its loosely coupled attribute gives “more of a serial capacity, spread out—vs. the burst [of the telephone call],” Kaye says. Responses typically are not real-time, though. That serial functionality is the same when automated systems communicate with messages to each other. “Each system has its own set of responsibilities, the language it speaks. Each system is responsible for scaling its tasks that are best suited for its system,” Kaye adds.
These messaging systems all seem to have quality-of-service issues requiring some additional layer of reliability built into the services, Kaye adds. For example, “you can have an unreliability messaging layer, but you can also add an acknowledgement or reliability layer on top of that,” he notes.
Clearly, real-time synchronous aspects exist within asynchronous systems, though. For example, robots must do something spatially at specified times. That requires the system sending a message to another to track the message. “But in a synchronous system, you do not have tickler file. You call me and you reach me or not,” he explains.
But overall, at some level, loosely coupled asynchronous systems break down into smaller tightly coupled systems, Kaye comments. “For example, send messages to a microprocessor in a milling machine. That microprocessor then sends tightly coupled hardware signals.” He notes that with tight coupling, interfaces between systems are very well defined. “The microprocessor knows exactly how to run that motor,” for instance.
As time constraints lessen or loosen with processes, though, “you’re more likely to use loosely coupled systems,” Kaye states. Clearly a fan of asynchronous messaging and loosely coupled systems, he emphasizes that this type of messaging gives scalable systems more independence of one another. One of the most important benefits of independence? “You can actually get by with somewhat less planning.”
That’s important, Kaye believes, because of how some industries grow. For example, if a factory is designed to produce 100 units per hour, and five years from now, production needs to increase to 10,000 units per hour, “you’ll build a fundamentally different factory [then].”
Applying that example to service-oriented architectures, however, Kaye forecasts that “if loosely coupled [truly asynchronous], though, it’s less likely you’ll have to change the architecture of your systems. And that’s a huge benefit.”
C. Kenna Amos, ckamosjr@earthlink.net, is anAutomation WorldContributing Editor.
RDS Strategic Services LLC
www.rds.com
![Mps035 Sm 1200x628 D[2]](https://img.automationworld.com/files/base/pmmi/all/image/2021/03/MPS035_SM_1200x628_D_2_.604a4a336bc60.png?auto=format%2Ccompress&bg=fff&fill-color=fff&fit=fill&h=146&pad=5&q=70&w=340)
