Contribution 58

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (04:26, 3 July 2008) (edit) (undo)
(Engineer in the White Spaces)
 
Line 3: Line 3:
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.
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 little glyph to carry. There's not usually enough room to write all that, so we label the unfortunate arrow with either "XML over HTTP"---if viewing it from an internal perspective---or "SKU Lookup"---if we have an external perspective.
+
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 brave little arrow crossing the gap between programs looks like a direct contact, but it isn't. The space between the boxes isn't empty at all. It's filled with hardware and software components. In between boxes, you'll find some or all of the following:
+
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 interface cards
* Network switches
* Network switches
-
* Layer 2 - 3 firewalls
+
* Firewalls
-
* Layer 7 (application) firewalls
+
* IDS and IPS
-
* Intrusion Detection and Prevention Systems
+
* Message queues or brokers
-
* Message queues
+
-
* Message brokers
+
* XML transformation engines
* XML transformation engines
-
* Flat file translations
 
* FTP servers
* FTP servers
-
* Polling jobs
+
* "Landing zone" tables
-
* Database "landing zone" tables
+
-
* ETL scripts
+
* Metro-area SoNET rings
* Metro-area SoNET rings
* MPLS gateways
* MPLS gateways
* Trunk lines
* Trunk lines
* Oceans
* Oceans
-
* Ocean liners
+
* Cable-finding fishing trawlers
-
* Phillipine fishing trawlers (see, "Underwater Cable Break")
+
-
Even in the simple cases, there will be four or five computers between program A and B, each running their own programs to handle things like packet switching, traffic analysis, routing, threat analysis, and so on. As the architect bridging between those programs, you must consider this substrate.
+
There will always be four or five computers between program A and B, running their software for packet switching, traffic analysis, routing, threat analysis, and so on. As the architect bridging between those programs, you must consider this substrate.
-
I've seen a single arrow, running from one server to another, labelled "Fulfillment". It so happened that one server was inside my client's company while the other server was in a fulfillment house's company. That little arrow, so critical to customer satisfaction, really represented a Byzantine chain of events that resembled a game of "Mousetrap" more than a single interface. It had messages going to message brokers that appended lines to files, which were later picked up by an hourly job that would FTP the files to the "gateway" server (still inside my client's company.) The gateway server read each line from the file and constructed and XML message, which it then sent via HTTP to the fulfillment house.
+
I saw one arrow labeled "Fulfillment". One server was inside my client's company, the other server was in a different one. That arrow, critical to customer satisfaction, unpacked to 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 twenty steps.
It's essential to understand that 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."
It's essential to understand that 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."
-
Building the right failure modes is also vital. The last job of any structure is to fall down well. The same is true for our hardy little arrow. The interface needs to define what happens on each end when things come unglued. What if the caller sends more than 100 requests per second? Is it OK to refuse them? Should the receiver drop requests on the floor, refuse politely, or make the best effort possible?
+
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 protocol 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?
-
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?
+
Answering these questions is the essence of engineering the white spaces.
-
 
+
-
What happens when the caller sends a request with version 1.0 of the protocol 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?
+
-
 
+
-
When a bridge falls down, it is shocking, horrifying, and often fatal. Computers and networks, on the other hand, fall down all the time. They always will. Therefore, it's incumbent on us to ensure that individual computers and networks fail in predictable ways. We need to know what happens to that arrow when one end disappears for a while.
+
-
 
+
-
Decide what kind of load that arrow must support. Figure out what to do when the demand is more than it can bear. Decide what happens when the substrate beneath it falls apart, or when the duplicitous rectangle on the other end goes bonkers.
+
-
 
+
-
This is the essence of engineering the white spaces.
+

Current revision

Engineer in the White Spaces

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, running their software for packet switching, traffic analysis, routing, threat analysis, and so on. As the architect bridging between those programs, you must consider this substrate.

I saw one arrow labeled "Fulfillment". One server was inside my client's company, the other server was in a different one. That arrow, critical to customer satisfaction, unpacked to 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 twenty steps.

It's essential to understand that 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 protocol 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.


By Michael Nygard

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools