Engineer in the White Spaces
2015-08-16 09:53
302 查看

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, connected 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 room to write all that, so we label the arrow with either “XML over HTTP” from an internal perspective, or “SKU Lookup” for the external perspective.
That arrow bridging programs looks like a direct contact, but it isn’t. The white space between the boxes is filled with hardware and software components. 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 will always be four or five computers between program A and B, run- ning their software for packet switching, traffic 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 was in a different one. That arrow, critical to customer satisfaction, unpacked a chain of events that resembled a game of “Mousetrap” more than a single interface. Messages went to message brokers that dumped to files, which were picked up by a periodic FTP job, and so on. That one “interface” had more than 20 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 back one response per HTTP reply. Expect up to 100 requests per second, and deliver responses in less than 250 milliseconds 99.999% of the time.”
There’s more we need to know about 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 do when replies take more than 250 milliseconds? Should it retry the call? Should it wait until later, or assume the receiver has failed and move on without that function?
• What happens when 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 interface disappears for a while? Answering these questions is the essence of engineering the white spaces.
Engineer in the White Spaces
Michael NygardA 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, connected 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 room to write all that, so we label the arrow with either “XML over HTTP” from an internal perspective, or “SKU Lookup” for the external perspective.
That arrow bridging programs looks like a direct contact, but it isn’t. The white space between the boxes is filled with hardware and software components. 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 will always be four or five computers between program A and B, run- ning their software for packet switching, traffic 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 was in a different one. That arrow, critical to customer satisfaction, unpacked a chain of events that resembled a game of “Mousetrap” more than a single interface. Messages went to message brokers that dumped to files, which were picked up by a periodic FTP job, and so on. That one “interface” had more than 20 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 back one response per HTTP reply. Expect up to 100 requests per second, and deliver responses in less than 250 milliseconds 99.999% of the time.”
There’s more we need to know about 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 do when replies take more than 250 milliseconds? Should it retry the call? Should it wait until later, or assume the receiver has failed and move on without that function?
• What happens when 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 interface disappears for a while? Answering these questions is the essence of engineering the white spaces.
相关文章推荐
- Linux用户添加root权限
- Codeforces Round #261 (Div. 2) D. Pashmak and Parmida's problem (树状数组求逆序数 变形)
- linux下lv卷的扩展
- css样式简介
- Java日志框架——不同日志框架转换,日志记录请求的Level值不能一一映射
- 网络编程TCP(四)
- iOS应用中增加emoji表情输入功能
- It’s All About Performance
- du命令 实现Linux 某个文件夹下的文件按大小排序
- Java NIO系列教程(三) Buffer
- UIPageControl
- POJ 2699 The Maximum Number of Strong Kings
- Linux学习笔记-----RPM包管理----yum在线管理之使用setup配置IP
- The New Villa (Uva 321 bfs)
- http 206 Range -- 端点续传(resumed download) -- POST/PUT/DELETE
- shape和selector和layer-list的(详细说明)
- 再谈工厂三姐妹
- Java中Scanner的nextInt(),next(),nextLine()方法总结
- Kali Linux 2.0版本下载地址
- react native跨平台