anchor.diff:  
   | FlowFile Processor | Black Box | 
   Processors actually perform the work.  In <<eip>> terms a processor is 
  -doing some combination of data Routing, Transformation, or Mediation between
  +doing some combination of data routing, transformation, or mediation between
   systems.  Processors have access to attributes of a given FlowFile and its 
   content stream.  Processors can operate on zero or more FlowFiles in a given unit of work
   and either commit that work or rollback.
   
   | Connection | Bounded Buffer | 
   Connections provide the actual linkage between processors.  These act as queues
  -and allow various processes to interact at differing rates.  These queues then 
  +and allow various processes to interact at differing rates.  These queues  
   can be prioritized dynamically and can have upper bounds on load, which enable
   back pressure.
   
   | Flow Controller | Scheduler | 
  -The Flow Controller maintains the knowledge of how processes actually connect 
  +The Flow Controller maintains the knowledge of how processes connect 
   and manages the threads and allocations thereof which all processes use.  The
   Flow Controller acts as the broker facilitating the exchange of FlowFiles 
   between processors.
  
positive.code: 
  NiFi Architecture
  -----------------
  image::nifi-arch.png["NiFi Architecture Diagram"]
  
  NiFi executes within a JVM living within a host operating system.  The primary
  components of NiFi then living within the JVM are as follows:
  
  Web Server::
  The purpose of the web server is to host NiFi's HTTP-based command and control API.
  
  Flow Controller::
  The flow controller is the brains of the operation. It provides threads for extensions to run on and manages their schedule of when they'll receive resources to execute.
  
  Extensions::
  There are various types of extensions for NiFi which will be described in other documents.  But the key point here is that extensions operate/execute within the JVM.
  
  FlowFile Repository::
  The FlowFile Repository is where NiFi keeps track of the state of what it knows about a given FlowFile that is presently active in the flow.  The implementation of the repository is pluggable.  The default approach is a persistent Write-Ahead Log that lives on a specified disk partition. 
  
  Content Repository::
  The Content Repository is where the actual content bytes of a given FlowFile live.  The implementation of the repository is pluggable.  The default approach is a fairly simple mechanism, which stores blocks of data in the file system.   More than one file system storage location can be specified so as to get different physical partitions engaged to reduce contention on any single volume.
  
negative.code: - [[[bigdata]]] Wikipedia.  Big Data [online].  Retrieved: 27 Dec 2014, from: http://en.wikipedia.org/wiki/Big_data
  - [[[fbp]]] Wikipedia.  Flow Based Programming [online].  Retrieved: 28 Dec 2014, from: http://en.wikipedia.org/wiki/Flow-based_programming#Concepts
  - [[[seda]]] Matt Welsh.  Harvard.  SEDA: An Architecture for Highly Concurrent Server Applications [online].  Retrieved: 28 Dec 2014, from: http://www.eecs.harvard.edu/~mdw/proj/seda/
  
  