For reference, there's also some documentation of common patterns in ROS: http://wiki.ros.org/ROS/Patterns/Comm...
Depending on what you're trying to achieve, and what the timing requirements are, parameters, topics, services, or a single process may all be valid choices.
If each node in the pipeline is responsible for part of the system state, it could publish that state on a latched topic, and your other nodes could subscribe to that topic. ROS doesn't guarantee the timing of message delivery, so if your state needs to be set before the data reaches the next node in the pipeline, this probably isn't the right choice.
If your state follows the data, you could simply include it in the message that is passed from one node to the next. Downside here is that your state isn't persistent outside of the nodes.
If you do have synchronization requirements and your data is small, you could use the parameter server, and call setParam immediately before you publish, and then getParam at the beginning of the next callback. Since these are blocking, you're guaranteed that the new state is pushed to the parameter server before the next node requests it.
If you have synchronization requirements and your shared data is large, or if more than one node can set the same shared variables, you could implement a separate node to hold your shared state, and each node could update that shared state either by publishing (fast but not guaranteed timing) or by service call (blocking and guaranteed update); and then retrieve the shared state either by subscribing to a shared state topic, or by making a service call to request the state. Writing your own node to manage the shared state also gives you built-in type safety and more control over update semantics and atomicity.
(this is basically just implementing your own parameter server, with custom data types and less load on the ROS master)
Finally, if your state is very large (100's Megabytes) or you have tight deadlines on how quickly it needs to be transferred to other components, it may be better to pull all of the pieces of your pipeline in a single process (you can still use ROS pub/sub within a process), and communicate your shared state in a more traditional way, with shared memory and mutexs to prevent concurrent updates.
