いわゆるプロセスのパイプライン処理について教えてください．
サーバーやクラウドで複数の処理を実行する場合、パイプラインが有効であると言われます．これを設計要件の一義におくべきという方もおられます．
パイプラインは、例えば処理１が標準出力に書き込み、処理２が標準入力で受け取って協調して動作すれば、処理１の実行を待ってから処理２を実行させるより全体のスループットは向上するというものです．
私が持っている疑問は次のようなものです．各項目にご意見/ご解答をいただければ幸いです．もし記述が誤っていたらご指摘ください．
１．複数のリソースをやりとりするときはどうなるのか？
処理１が複数のリソース（普通に言えば複数のファイル）を生成し、処理２もこのリソースを受け取って処理するような場合はどのようにするのでしょうか？私が単純に考えたのは次のような方法です．
① 処理１で複数の出力リソースを1本の標準出力にまとめてしまう．
② 名前付きパイプを使用する．
①は処理の方法をパイプと言う処理の呼び出され方に従属させるものでそもそも無理があるような気がします．②は処理１の出力が不特定多数のリソースになるような場合、パイプの名前の一覧をパイプで渡す（？）などというテクニックが必要になるようにも考えられます．
ともにパイプ自体が複数のリソースの授受に優れているとは考えづらいように思えます．また複数のリソースをやり取りする処理間では必ずしもパイプの利点は生かせないように思えます．
２．パイプがもたらす処理への足かせ
処理１と処理２の実行をパイプで実現する場合、処理１は単純に標準出力に書き出し、処理２は標準入力を読みます．標準入力はシーク（seek）できません．単に最初から読んで必要な情報は自分で保存してゆく必要があります．また必要な情報に行き着くまではひたすら読まねばなりません．
処理２の読み込みは必ずしもシーケンシャルな読み込みのみでは大変な場合がありえます．ファイルだったらランダムアクセスができますが、そういう訳にはゆきません．つまりパイプという処理方式が処理２のアルゴリズムに制約条件をもたらします．入力がファイルなら自由にその中を行き来できるのですが、それが出来なくなるからです．
３．パイプの向き/不向き
パイプが威力を発揮するのは、処理１と処理２もひたすら入力を読んで、若干の加工をしそのまま出力へ書き込むような場合でしょう．もし処理１が入力を最後まで読んで、その後に加工して一気に出力を行うようなパターンの場合、パイプによって得られる恩恵は多くはないでしょう．
４．XMLをパイプで扱う場合
XSLTですらストリーミングはXSLT 3.0のワーキングドラフトに初めて登場し、Saxon 9.5（9.6）で実装が始まっている段階です．つまりこれからの技術です．
XMLを扱うのにXSLTを使用せず、一般のプログラミング言語で処理を実装する場合、パイプライン処理を実現するにはJavaだったらStAXのようなパーサーを用いるか、SAXを使用する必要があるのではないでしょうか？
XMLを扱う場合XPathが使用できるか否かで非常に違いがあるように思います．XSLT 3.0のストリーミングでは使用できるXPath式には制約があり//paraなどXMLを全部なめる必要があるものは使用できません．ましてや一般のプログラミング言語で実装する場合、XPathの使用はほぼ絶望的ではないでしょうか？これはプログラミングの大きな制約条件になるように思えます．
つまり全体として必ずしもパイプという呼び出され方（処理のされ方）を処理の実装の設計要件に置くといろいろ大変になるのではないかというように思えます．プログラミングの制約条件が増えるばかりだからです．一般的には処理に要求される機能がそもそも実現できるのか？という方が重要なファクターに思えるのですがいかがでしょうか？
以上 よろしくお願いいたします．
