Engineer in the white Spaces

?

Engineer in the white Spaces

Michael Nygard

A SySTEM consists of interdependent pRogRAMS. We call the arrangement of these programs and their relationships architecture. When we diagram these systems, we often represent individual programs or servers as simplistic little rectangles, connecte D by Arrows.
One little arrow might mean, "synchronous request/reply using Soap-xml over HTTP." That's quite a lot of information for one glyph to carry. There ' s not usually enough box to write all that, so we label the arrow with either "XML over HTTP" from an internal pers Pective, or "SKU Lookup" for the external perspective.
That arrow bridging programs looks as a direct contact, but it isn ' t. The white space between the boxes are filled with hardware and software. This substrate may contain:
???? Network interface cards?
? Network switches?
? Firewalls?
? IDS and IPS?
? Message queues or brokers?
? XML transformation engines?
? FTP servers
"Landing zone" Tables Metro-area SoNET rings MPLS Gateways
Trunk lines
Oceans
Cable-finding Fishing Trawlers
There is always being four or five computers between program A and B, run-ning their software for packet switching, Traffi C analysis, routing, threat analy-sis, and so on. As the architect bridging those programs, you must consider this substrate.
?
?? I saw one arrow labeled "Fulfillment". One server was inside my client's com-pany, the other server is in a different one. That's arrow, critical to customer satisfaction, unpacked a chain of events the resembled a game of "mousetrap" more than a Single interface. Messages went to message brokers the dumped to files, which were picked up by a periodic the FTP job, and so on. That one "interface" had more than steps.
It's essential to understand the static and dynamic loads that arrow must carry. Instead of just "Soap-xml over HTTP," that one little Arrow should also say, "Expect one query per HTTP request and send B Ack One response per HTTP reply. Expect up to requests per second, and deliver responses in less than milliseconds 99.999% of the time. "
There ' s more we need to know on that arrow:
? What if the caller hits it too often? Should the receiver drop requests on the "floor", refuse politely, or make the best effort possible?
? What should the caller does when replies take more than milliseconds? Should it retry the call? Should it wait until later, or assume the receiver has a failed and move on without this function?
? What happens when is the caller sends a request with version 1.0 of the Pro-tocol and gets back a reply in version 1.1? What if it gets back some HTML instead of XML? Or an MP3 file instead of XML?
? What happens when one end of the the interface disappears for a while? Answering these questions is the essence of engineering, the white spaces.

Engineer in the white Spaces