A arquitectura en pipeline (tamén denominada arquitectura pipe & filter e ás veces arquitectura baseada en compoñentes) é un termo pertencente á enxeñaría de software que define a estrutura dun sistema software como unha cadea de elementos de procesamento ordenados de tal maneira que a saída de cada elemento é a entrada do seguinte ^[1]. Aplícase na construción de sistemas software adicados ao procesado de información, onde a entrada é procesada en diferentes etapas para producir a saída desexada.

A arquitectura en pipeline propón a división do traballo ou funcionalidade global dun sistema en pasos ou tarefas independentes, cada unha das cales será realizada por un compoñente diferente chamado filtro (filter). As etapas-compoñentes serán conectadas mediante canles (pipes) polos que os datos pasan dun compoñente a outro. Esta estruturación permite paralelizar a execución dun sistema, dado que cada filtro pode executarse nun fío ou proceso independente, que á su vez favorece o reuso do compoñente. Así mesmo, non é necesario agardar a que se remate de procesar unha petición, xa que en canto o primeiro filtro queda libre e pasa os datos ao segundo, está en disposición de comezar a procesar unha nova petición.

A denominación anglosaxoa "pipeline" quere dicir en galego"tubaxe", en alusión directa a como a auga circula por tubaxes ou tubos nas casas e cidades. Nesta metáfora, a auga representa a ser a información e as tubaxes, os procesos polos que pasa.

A arquitectura en pipeline adoita encadrarse dentro das chamadas arquitecturas de fluxo de datos. É sen dúbida algunha o estilo que se definiu máis cedo e o que pode identificarse topolóxica, procesual e taxonomicamente con menor ambigüidade. Xurdiu na década dos 70, cando se crearon os primeiros comandos Unix, para controlar fluxos de datos entre diferentes elementos software^[2]. Formalmente, relaciónase coas redes de proceso descritas por Kahn en torno a 1974, e cos procesos secuenciais comunicantes (CSP) ideados por Tony Hoare catro anos máis tarde.

Prevaleceu o nome de tubaxes-filtros por máis que se sabe moi ben que os chamados filtros non realizan forzosamente tarefas de filtrado, como poden ser a eliminación de campos ou rexistros, senón que executan formas variables de transformación, unha das cales pode ser de filtrado. Historicamente, os primeiros compiladores de tubaxes-filtros operaban conforme a un estilo de tubaxe e filtro bastante puro, en ocasións en variantes de proceso por lotes. A medida que os compiladores se tornaron máis sofisticados, fóronse engadindo elementos tales como táboas ou símbolos, xeralmente compartidas por varios filtros.

O engadido de formas intermedias de representación, gramáticas de atributo, árbores de recoñecemento de atributos, compilacións converxentes a formatos intermedios e outras compilacións e engadidos, foron facendo que o modelo chegara a ser inadecuado para representar certos procesos, sendo preferible optar por outros estilos, como o de arquitectura en repositorio.

A arquitectura en pipeline modela a funcionalidade dun sistema software como unha serie de transformacións sobre un fluxo de datos, nun proceso comprendido por varias fases secuenciais, sendo entrada de cada unha a saída da anterior, con almacenamento temporal de datos ou buffering entre os procesos adxuntos. Os filtros non precisan coñecer o funcionamento dos seus veciños, unicamente se preocupan da súa entrada e saída. Neste sentido, esta arquitectura é similar a arquitectura en capas, coa diferenza de que na arquitectura en pipeline o camiño de saída é diferente ao de entrada.

É unha arquitectura popular que, debido á súa simplicidade e á súa facilidade para representar procesos secuenciais no mundo real, resulta moi apropiada para formalizar o deseño arquitectónico de sistemas que dan soporte a eses procesos de negocio. O sistema se percibe como unha serie de transformacións sobre sucesivas versións dos datos de entrada. Os datos entran ó sistema por un extremo, avanzan a través dos compoñentes, e saen polo extremo oposto. Así, esta arquitectura úsase principalmente cando se pode especificar a secuencia de transformación ou tratamento da información recibida nun número coñecido de pasos, cando non se require unha resposta asíncrona de cada paso, e cando se busca que todos os compoñentes situados "corrente abaixo" sexan capaces de inspeccionar e actuar sobre os datos que veñen de "corrente arriba" (pero non ao revés).

Por exemplo, un Order Processing Pipeline proporciona unha secuencia de pasos necesaria para procesar as compras dun sitio web. No primeiro paso obteríase a información de produto da base de datos do catálogo. No segundo, procesaríase a dirección do comprador. No seguinte, resolveríase a modalidade de pago. Noutro posterior confeccionaríase a factura, e no último realizaríase o envío. Cada etapa do fluxo representa unha tarefa.

Pola contra, un sistema de procesado ou transformación de fluxos de datos de entrada que se modela como un único compoñente no canto de como un pipeline será máis difícil de se construír de xeito colaborativo nun equipo de desenvolvedores, ademais de agrupar artificialmente tarefas que se descompoñen de xeito natural en varias etapas de procesamento. Máis importante, cambios nos requirimentos dalgunha das tarefas, ou a aparición ou desaparición de etapas obrigarían a modificar o compoñente completo.

En función das súas características, a arquitectura en pipeline presenta as seguintes fortalezas:

• Reflicte na arquitectura as etapas lóxicas de procesado da información (secuencia de tarefas), polo que a estrutura do sistema e o propio procesado son doados de comprender e favorecen o seguimento do fluxo da información. Tamén se facilita a modelaxe e o mantemento do sistema.
• Facilita engadir, eliminar, intercambiar ou reordenar os pasos de procesamento con esforzo reducido, así como a reutilización de compoñentes de procesamento de datos (filtros). Como o resultado de cada etapa é a entrada da seguinte, e non é necesario que unha coñeza o funcionamento das demais, conséguese un baixo acoplamento.
• Aporta flexibilidade para executar os pasos de xeito secuencial ou en paralelo e/ou duplicar etapas por motivos de rendemento. Tamén permite facilmente a atención concorrente de peticións, xa que un filtro pode comezar o procesado do seguinte unha vez o filtro precedente concluíu, e mesmo que a petición anterior non chegara aínda ao final do pipeline. Isto é así porque cando un compoñente xera unha saída e lla transmite ó seguinte, queda listo para un novo procesado.
• Posibilidade de presentar ou almacenar os resultados finais de varias formas.
• Posibilidade de almacenar resultados intermedios de xeito explícito, para procesamentos adicionais.

A arquitectura en pipeline tamén presenta unha serie de debilidades:

• Tenden a unha organización de procesamiento batch, e polo tanto resulta difícil soportar interaccións baseadas en eventos, polo que non favorecen unha estruturación axeitada para aplicacións interactivas.
• O formato e modo de transferencia dos datos debe acordarse entre cada par de compoñentes. Do contrario, pode ser necesario engadir aos filtros capacidades de conversión de datos á entrada e/ou á saída. Estas transformacións de datos son potencialmente custosas, penalizando o rendemento e incrementando a complexidade dos filtros. Para evitalas, débese evitar que os filtros adxuntos manexen información en diferentes formatos, aínda que isto á súa vez penaliza a independencia dos filtros, facendo máis difícil reusalos ou implicando posibles duplicidades nas súas funcionalidades internas.
• Resulta complicado dar soporte a varios fluxos diferentes pero relacionados (por exemplo, que deban sincronizarse).

• Tubaxes e filtros poden ser vistos como unha forma de programación funcional, na que se utilizan secuencias de bytes como obxectos de datos; máis especificamente, poden ser vistos como unha forma particular de mónada de E/S. En xeral, os fundamentos desta arquitectura son un concepto moi natural no paradigma de programación funcional (equivale á composición de funcións matemáticas).
• O concepto de tubaxe é tamén fundamental para o framework web Cocoon ou calquera implementación XProc (os estándares do W3C).

En sistemas UNIX, GNU/Linux e compatibles, denomínanse pipelines ás utilidades que permiten ligar dinamicamente a execución de pequenas aplicacións ou comandos para realizar tarefas complexas. En concreto, neste contexto unha pipeline é unha redirección da saída estándar dun programa á entrada estándar doutro programa, de xeito que nos permite enlazar a saída dun comando como entrada doutro. Esta ligazón acádase usando o símbolo : | (pipe) ^[3].

Por exemplo, se escribimos:

$ comando1 | comando2 | comando3

a saída do comando1 é tomada como entrada polo comando2, que a utiliza, e á súa vez a saída deste é tomada polo comando3 como entrada. Deste xeito, poderiamos ler un arquivo paxinado escribindo:

$ cat arquivo | more

Tamén poderiamos usar o mesmo comando cat para descargar o contido do arquivo á saída estándar, e simultaneamente o comando grep para realizar a procura dunha palabra (por exemplo, palabra) nese contido, e finalmente amosar os resultados ordenados alfabéticamente co comando sort:

$ cat arquivo | grep palabra | sort

Unha das tarefas de procesado onde é habitual empregar unha estrutura baseada en pipelines é no deseño dun compilador de código fonte^[4].

As táboa seguinte mostra os diferentes filtros que compoñen un compilador e a función que teñen:

Outro caso típico é o tratamento de documentos XML como refacho en SAX, certos mecanismos determinados motores de servidores de bases de datos^[5].

• Arquitectura Software