Программирование на основе потока

В компьютерном программировании программирование на основе потоков ( FBP ) — это парадигма программирования , которая определяет приложения как сети «черного ящика» процессов , которые обмениваются данными через предопределенные соединения посредством передачи сообщений , где соединения указываются вне процессов. Эти процессы «черного ящика» можно бесконечно повторно соединять для формирования различных приложений без необходимости внесения внутренних изменений. Таким образом, FBP естественным образом ориентирован на компоненты .

FBP — это особая форма программирования потоков данных , основанная на ограниченных буферах, информационных пакетах с определенным временем жизни, именованных портах и ​​отдельном определении соединений.

Введение

Программирование на основе потоков определяет приложения, используя метафору «фабрики данных». Он рассматривает приложение не как единый последовательный процесс, который начинается в определенный момент времени, а затем выполняет одно действие за раз, пока не завершится, а как сеть асинхронных процессов, взаимодействующих посредством потоков структурированных фрагментов данных. называемые «информационными пакетами» (IP). С этой точки зрения основное внимание уделяется данным приложения и применяемым к ним преобразованиям для получения желаемых результатов. Сеть определяется вне процессов как список соединений, который интерпретируется программным обеспечением, обычно называемым «планировщиком».

Процессы взаимодействуют посредством соединений с фиксированной пропускной способностью. Соединение прикрепляется к процессу посредством порта , имя которого согласовано между кодом процесса и определением сети. Один и тот же фрагмент кода может выполняться несколькими процессами. В любой момент времени данный IP-адрес может «принадлежать» только одному процессу или находиться в пути между двумя процессами. Порты могут быть простыми или массивными, как это используется, например, для входного порта компонента «Подборка», описанного ниже. Именно сочетание портов с асинхронными процессами позволяет поддерживать многие долго выполняемые примитивные функции обработки данных, такие как сортировка, слияние, суммирование и т. д., в виде программных черных ящиков .

Поскольку процессы FBP могут продолжать выполняться до тех пор, пока у них есть данные для работы и место для хранения результатов, приложения FBP обычно выполняются за меньшее время, чем обычные программы, и оптимально используют все процессоры на машине, не требуя специального программирования. для достижения этой цели.

Определение сети обычно имеет схематический вид и преобразуется в список соединений на каком-либо языке или нотации более низкого уровня. FBP часто является языком визуального программирования на этом уровне. Более сложные определения сетей имеют иерархическую структуру, состоящую из подсетей с «прикрепленными» соединениями. Многие другие потоковые языки/среды выполнения построены на основе более традиционных языков программирования, наиболее заметным из которых является Примером является RaftLib , который использует операторы C++, подобные iostream, для указания графа потока.

FBP имеет много общего с Линдой. язык в том смысле, что он, по терминологии Гелернтера и Каррьеро, является «координационным языком»: по сути, он не зависит от языка. Действительно, при наличии планировщика, написанного на достаточно низкоуровневом языке, компоненты, написанные на разных языках, могут быть связаны между собой в единую сеть. Таким образом, FBP соответствует концепции предметно-ориентированных языков или «мини-языков».

FBP демонстрирует «связь данных», описанную в статье о связи как самый слабый тип связи между компонентами. Концепция слабой связи, в свою очередь, связана с концепцией сервис-ориентированных архитектур , и FBP соответствует ряду критериев такой архитектуры, хотя и на более детальном уровне, чем большинство примеров этой архитектуры.

FBP продвигает высокоуровневый функциональный стиль спецификаций, который упрощает понимание поведения системы. Примером этого является модель распределенного потока данных для конструктивного определения и анализа семантики распределенных многосторонних протоколов.

История

Программирование на основе потоков было изобретено Дж. Полом Моррисоном в начале 1970-х годов и первоначально реализовано в программном обеспечении для канадского банка. На момент своего создания FBP находился под сильным влиянием некоторых языков моделирования IBM того периода, в частности GPSS , но его корни уходят корнями в назвал основополагающую статью Конвея о том, что он сопрограммами .

За прошедшие годы FBP претерпел ряд изменений в названии: первоначальная реализация называлась AMPS (Advanced Modular Processing System). Одно крупное приложение в Канаде было запущено в 1975 году и по состоянию на 2013 год постоянно использовалось в производстве, работая ежедневно, вот уже почти 40 лет. Поскольку IBM считала, что идеи, лежащие в основе FBP, «слишком похожи на закон природы», чтобы быть патентоспособными, они вместо этого сделали основные концепции FBP общедоступными с помощью Бюллетеня технической информации «Модульная система программирования с чередованием задач, реагирующая на данные». , в 1971 году. Статья, описывающая его концепции и опыт его использования, была опубликована в 1978 году в журнале IBM Research IBM Systems Journal под названием DSLM. Вторая реализация была реализована как совместный проект IBM Canada и IBM Japan под названием «Менеджер разработки потоков данных» (DFDM) и некоторое время продавался в Японии в конце 80-х под названием «Менеджер программирования потоков данных».

Обычно в IBM эти концепции назывались «Потоком данных», но этот термин был сочтен слишком общим, и в конечном итоге было принято название «Программирование на основе потоков».

С начала 80-х по 1993 год Дж. Пол Моррисон и архитектор IBM Уэйн Стивенс усовершенствовали и продвигали концепции, лежащие в основе FBP. Стивенс написал несколько статей, описывающих и поддерживающих концепцию FBP, и включил материалы о ней в несколько своих книг. . В 1994 году Моррисон опубликовал книгу, описывающую FBP и предоставляющую эмпирические доказательства того, что FBP приводит к сокращению времени разработки.

Концепции

На следующей диаграмме показаны основные объекты диаграммы FBP (кроме информационных пакетов). Такая диаграмма может быть преобразована непосредственно в список соединений, который затем может быть выполнен соответствующим механизмом (программным или аппаратным).

Простая диаграмма ФБП

A, B и C — процессы, выполняющие компоненты кода. O1, O2 и два IN — это порты, соединяющие соединения M и N с соответствующими процессами. Процессам B и C разрешено выполнять один и тот же код, поэтому каждый процесс должен иметь свой собственный набор рабочей памяти, блоков управления и т. д. Независимо от того, используют ли они общий код, B и C могут свободно использовать один и тот же порт. имена, поскольку имена портов имеют значение только внутри компонентов, ссылающихся на них (и, конечно, на сетевом уровне).

M и N — это то, что часто называют « ограниченными буферами », и имеют фиксированную емкость с точки зрения количества IP-адресов, которые они могут хранить в любой момент времени.

Концепция портов позволяет использовать один и тот же компонент в нескольких местах сети. В сочетании с возможностью параметризации, называемой пакетами исходной информации (IIP), порты предоставляют FBP возможность повторного использования компонентов, что делает FBP архитектурой на основе компонентов . Таким образом, FBP демонстрирует то, что Рауль де Кампо и Нейт Эдвардс из IBM Research назвали настраиваемой модульностью .

Информационные пакеты или IP-адреса распределяются в так называемом «пространстве IP» (точно так же, как кортежи Линды распределяются в «пространстве кортежей») и имеют четко определенный срок жизни до тех пор, пока они не будут удалены и их пространство не будет освобождено - в FBP это должно быть явным действием со стороны процесса-владельца. IP-адреса, перемещающиеся по данному соединению (на самом деле это их «дескрипторы»), составляют «поток», который генерируется и потребляется асинхронно — таким образом, эта концепция имеет сходство с концепцией ленивых минусов , описанной в статье Фридмана и Уайза 1976 года.

IP-адреса обычно представляют собой структурированные фрагменты данных, однако некоторые IP-адреса могут не содержать никаких реальных данных, а используются просто как сигналы. Примером этого являются «IP-адреса в скобках», которые можно использовать для группировки IP-адресов данных в последовательные шаблоны внутри потока, называемые «подпотоками». Подпотоки, в свою очередь, могут быть вложенными. IP-адреса также могут быть объединены в цепочку для формирования «деревьев IP», которые перемещаются по сети как отдельные объекты.

Описанная выше система связей и процессов может быть «разветвлена» до любых размеров. Во время разработки приложения процессы мониторинга могут быть добавлены между парами процессов, процессы могут быть «разнесены» по подсетям или моделирование процессов может быть заменено реальной логикой процесса. Таким образом, FBP подходит для быстрого прототипирования .

На самом деле это образ конвейерной обработки данных: IP-адреса, перемещающиеся по сети процессов, можно рассматривать как виджеты, перемещающиеся от станции к станции на конвейере. «Машины» можно легко подключить, отключить от сети для ремонта, заменить и так далее. Как ни странно, это изображение очень похоже на изображение единичного записывающего оборудования , которое использовалось для обработки данных до появления компьютеров, за исключением того, что колоды карт приходилось переносить вручную от одной машины к другой.

Реализации FBP могут быть невытесняющими или вытесняющими — более ранние реализации имели тенденцию быть невытесняющими (мэйнфрейм и язык C), тогда как последняя реализация Java (см. ниже) использует класс Java Thread и является вытесняющей.

Примеры

Проблема с Telegram

Компоненты FBP часто образуют дополнительные пары. В этом примере используются две такие пары. Описанная проблема кажется очень простой на словах, но на самом деле ее удивительно сложно решить, используя традиционную процедурную логику. Задача, названная «проблемой телеграммы», первоначально описанная Питером Науром , состоит в том, чтобы написать программу, которая принимает строки текста и генерирует выходные строки, содержащие как можно больше слов, где количество символов в каждой строке не превышает определенного длина. Слова не могут быть разделены, и мы предполагаем, что ни одно слово не длиннее, чем размер выходных строк. Это аналогично проблеме переноса слов в текстовых редакторах.

В традиционной логике программист быстро обнаруживает, что ни структуры ввода, ни структуры вывода не могут использоваться для управления иерархией вызовов потока управления . В FBP же само описание проблемы предполагает решение:

• «Слова» явно упоминаются в описании проблемы, поэтому разработчику разумно рассматривать слова как информационные пакеты (IP).
• В FBP нет единой иерархии вызовов, поэтому у программиста нет соблазна сделать подшаблон решения высшим уровнем.

Вот наиболее естественное решение в FBP (в FBP не существует единственного «правильного» решения, но оно кажется естественным):

Проблема с телеграммой Питера Наура

где DC и RC означают «DeCompose» и «ReCompose» соответственно.

Как упоминалось выше, пакеты исходной информации (IIP) могут использоваться для указания параметрической информации, такой как желаемая длина выходной записи (требуемая двумя крайними правыми компонентами) или имена файлов. IIP — это фрагменты данных, связанные с портом в определении сети, которые становятся «обычными» IP-адресами, когда для соответствующего порта выдается «получение».

Пакетное обновление

Этот тип программы предполагает передачу файла «подробных данных» (изменений, добавлений и удалений) в «основной файл» и создание (по крайней мере) обновленного основного файла, а также одного или нескольких отчетов. Программы обновления, как правило, довольно сложно кодировать с использованием синхронного процедурного кода, поскольку два (иногда более) входных потока должны поддерживаться синхронизированными, даже если могут существовать главные потоки без соответствующих деталей, или наоборот.

Каноническая структура «пакетного обновления»

В FBP компонент многократного использования (Collate), основанный на идее модульной записи в Collator, значительно упрощает написание этого типа приложения, поскольку Collate объединяет два потока и вставляет IP-адреса скобок для обозначения уровней группировки, что значительно упрощает логику последующего процесса. Предположим, что один поток («главные» в данном случае) состоит из IP-адресов со значениями ключей 1, 2 и 3, а IP-адреса второго потока («детали») имеют значения ключей 11, 12, 21, 31, 32, 33. и 41, где первая цифра соответствует значениям главного ключа. Используя символы скобок для представления IP-адресов в скобках, сопоставленный выходной поток будет следующим:

( м1 д11 д12 ) ( м2 д21 ) ( м3 д31 д32 д33 ) (д41)
 

Поскольку мастера со значением 4 не было, то последняя группа состоит из одной детали (плюс скобки).

Структуру вышеуказанного потока можно кратко описать, используя BNF -подобную нотацию, например:

{ ( [м] d* ) }*
 

Collate — это многоразовый черный ящик , которому нужно только знать, где находятся поля управления во входящих IP-адресах (даже это не является строго необходимым, поскольку процессы преобразователя могут быть вставлены выше по течению для размещения полей управления в стандартных местах), и его фактически можно обобщить. к любому количеству входных потоков и любой глубине вложенности скобок. Collate использует для ввода порт типа массива, что позволяет использовать переменное количество входных потоков.

Мультиплексирование процессов

Программирование на основе потоков естественным образом поддерживает мультиплексирование процессов. Поскольку компоненты доступны только для чтения, любое количество экземпляров данного компонента («процессов») может работать асинхронно друг с другом.

Пример мультиплексирования

Когда компьютеры обычно имели один процессор, это было полезно при большом количестве операций ввода-вывода; теперь, когда машины обычно имеют несколько процессоров, это начинает становиться полезным, когда процессы также нагружают процессор. На диаграмме в этом разделе показан один процесс «Балансировщик нагрузки», распределяющий данные между тремя процессами, обозначенными S1, S2 и S3 соответственно, которые являются экземплярами одного компонента, которые, в свою очередь, передаются в один процесс по принципу «первым пришел». по принципу «первым обслужен».

Простая интерактивная сеть

Схема общего интерактивного приложения

На этой общей схеме запросы (транзакции), поступающие от пользователей, поступают на диаграмму в левом верхнем углу, а ответы возвращаются в левом нижнем углу. «Внутренние части» (справа) взаимодействуют с системами на других сайтах, например, с помощью CORBA , MQSeries и т. д. Перекрестные соединения представляют собой запросы, которым не нужно идти на серверные части, или запросы, которые должны циклически проходить через сети более одного раза, прежде чем будет возвращен пользователю.

Поскольку разные запросы могут использовать разные серверные части и могут требовать разное количество времени для их обработки (если они используются), необходимо предусмотреть возможность соотнесения возвращаемых данных с соответствующими запрашивающими транзакциями, например, хеш-таблицами или кэшами.

Приведенная выше диаграмма схематична в том смысле, что окончательное приложение может содержать гораздо больше процессов: процессы могут быть вставлены между другими процессами для управления кэшами, отображения трафика соединения, мониторинга пропускной способности и т. д. Также блоки на диаграмме могут представлять «подсети» — небольшие сети с одним или несколькими открытыми соединениями.

Сравнение с другими парадигмами и методологиями

программирование Джексона (JSP) и Разработка систем Джексона (

Основные статьи: Структурное программирование Джексона и разработка системы Джексона

Эта методология предполагает, что программа должна быть структурирована как единая процедурная иерархия подпрограмм. Его отправной точкой является описание приложения как набора «основных строк», основанных на структурах входных и выходных данных. Затем одна из этих «основных линий» выбирается для управления всей программой, а остальные необходимо «инвертировать», чтобы превратить их в подпрограммы (отсюда и название «инверсия Джексона»). Иногда это приводит к так называемому «конфликту», требующему разделения программы на несколько программ или сопрограмм. При использовании FBP этот процесс инверсии не требуется, поскольку каждый компонент FBP можно рассматривать как отдельную «основную линию».

FBP и JSP разделяют концепцию обработки программы (или некоторых компонентов) как анализатора входного потока.

В более поздней работе Джексона « Разработка системы Джексона» (JSD) эти идеи получили дальнейшее развитие.

В JSD проект сохраняется как проект сети до заключительного этапа реализации. Затем модель преобразуется в набор последовательных процессов по количеству доступных процессоров. Джексон обсуждает возможность прямого выполнения сетевой модели, существовавшей до этого шага, в разделе 1.3 своей книги (курсив добавлен):

Спецификация, созданная в конце этапа системного синхронизации, в принципе, может быть выполнена напрямую. Необходимая среда будет содержать процессор для каждого процесса, устройство, эквивалентное неограниченному буферу для каждого потока данных, а также некоторые устройства ввода и вывода, с помощью которых система подключается к реальному миру. Такую среду, конечно, можно обеспечить с помощью подходящего программного обеспечения, работающего на достаточно мощной машине. Иногда такое прямое выполнение спецификации возможно и даже может быть разумным выбором.

FBP был признан М. А. Джексоном как подход, следующий его методу «Разложение программы на последовательные процессы, взаимодействующие с помощью механизма, подобного сопрограмме».

Аппликативное программирование

Основная статья: Язык прикладного программирования

У. Б. Акерман определяет аппликативный язык как язык, который выполняет всю свою обработку посредством операторов, применяемых к значениям. Самым ранним известным аппликативным языком был LISP.

Компонент FBP можно рассматривать как функцию, преобразующую входной поток(и) в выходной поток(и). Затем эти функции объединяются для выполнения более сложных преобразований, как показано здесь:

Две функции, питающие одну

Если мы обозначим потоки, как показано, строчными буквами, то приведенную выше диаграмму можно кратко представить следующим образом:

в = G(F(a),F(b));
 

Так же, как в функциональной нотации F может использоваться дважды, поскольку он работает только со значениями и, следовательно, не имеет побочных эффектов, в FBP два экземпляра данного компонента могут работать одновременно друг с другом, и поэтому компоненты FBP не должны иметь побочных эффектов. или. Функциональная нотация может явно использоваться для представления хотя бы части сети FBP.

Тогда возникает вопрос, могут ли сами компоненты FBP быть выражены с использованием функциональной записи. У.Х. Бердж показал, как потоковые выражения могут быть разработаны с использованием рекурсивного аппликативного стиля программирования, но эта работа проводилась в терминах атомарных значений (потоков). В FBP необходимо уметь описывать и обрабатывать фрагменты структурированных данных (IP-адреса FBP).

Более того, большинство аппликативных систем предполагают, что все данные доступны в памяти одновременно, тогда как приложения FBP должны иметь возможность обрабатывать длительные потоки данных, используя при этом ограниченные ресурсы. концепцию «ленивых минусов» Фридман и Уайз предложили способ сделать это, добавив к работе Берджа . Это устранило требование, чтобы оба аргумента «против» были доступны в один и тот же момент времени. «Ленивые минусы» фактически не создают поток до тех пор, пока не будут реализованы оба его аргумента — перед этим он просто записывает «обещание» сделать это. Это позволяет динамически реализовать поток спереди, но с нереализованной внутренней частью. Конец потока остается нереализованным до самого конца процесса, а начало представляет собой постоянно удлиняющуюся последовательность элементов.

Линда

Основная статья: Линда

Многие концепции FBP, по-видимому, были открыты независимо в разных системах на протяжении многих лет. Линда, упомянутая выше, является одной из таких. Разницу между этими двумя методами иллюстрирует метод балансировки нагрузки «школы пираний» Линды — в FBP для этого требуется дополнительный компонент «балансировщика нагрузки», который направляет запросы к компоненту в списке, который имеет наименьшее количество IP-адресов, ожидающих быть обработаны. Очевидно, что FBP и Linda тесно связаны, и один из них можно легко использовать для моделирования другого.

Объектно-ориентированное программирование

Основная статья: Объектно-ориентированное программирование

Объект в ООП можно описать как полуавтономную единицу, содержащую как информацию, так и поведение. Объекты взаимодействуют посредством «вызовов методов», которые по сути представляют собой вызовы подпрограмм, выполняемые косвенно через класс, к которому принадлежит принимающий объект. Доступ к внутренним данным объекта возможен только посредством вызовов методов, поэтому это форма сокрытия информации или «инкапсуляции». Однако инкапсуляция появилась раньше ООП — Дэвид Парнас написал одну из основополагающих статей об этом в начале 70-х годов. - и является базовой концепцией в вычислительной технике. Инкапсуляция — это сама суть компонента FBP, который можно рассматривать как черный ящик , выполняющий некоторое преобразование входных данных в выходные данные. В FBP частью спецификации компонента являются форматы данных и структуры потоков, которые он может принимать и которые он будет генерировать. Это представляет собой форму проектирования по контракту . Кроме того, к данным IP-адреса может получить прямой доступ только процесс, владеющий им в данный момент. Инкапсуляцию также можно реализовать на сетевом уровне, если внешние процессы защищают внутренние.

В статье К. Эллиса и С. Гиббса проводится различие между активными и пассивными объектами. Пассивные объекты содержат информацию и поведение, как указано выше, но они не могут определить время этого поведения. С другой стороны, активные объекты могут это сделать. В своей статье Эллис и Гиббс утверждают, что активные объекты имеют гораздо больший потенциал для разработки обслуживаемых систем, чем пассивные объекты. Приложение FBP можно рассматривать как комбинацию этих двух типов объектов, где процессы FBP будут соответствовать активным объектам, а IP-адреса будут соответствовать пассивным объектам.

Модель актера

Основная статья: Модель актера

FBP рассматривает Карла Хьюитта как актор асинхронный процесс с двумя портами: один для входных сообщений и один для управляющих сигналов. Управляющий сигнал излучается самим актером после каждого раунда выполнения. Цель этого сигнала — избежать параллельного выполнения тела актера и, таким образом, обеспечить доступ к полям объекта актера без синхронизации.

См. также

• Активные объекты
• Модель актера
• Апач НиФи
• БМДФМ
• Взаимодействие последовательных процессов (CSP)
• Параллельные вычисления
• Поток данных
• Схема потока данных
• Программирование потоков данных
• FBD — функциональные блок-схемы (язык программирования по стандарту IEC 61131)
• Функциональное реактивное программирование
• Линда (координационный язык)
• Платформы разработки с низким кодом
• Уменьшение карты
• Узел-RED
• Конвейерное программирование
• Уэйн Стивенс
• XPoc
• Yahoo трубы

Внешние ссылки

• Раздов, Аллен (декабрь 1997 г.). «Строительство предприятий по переработке данных» . DMReview . Архивировано из оригинала 15 марта 2005 г. Проверено 15 июля 2006 г.
• Майер, Энтони; Макгоф, Стивен; Гуламали, Муртаза; Янг, Лори; Стэнтон, Джим; Ньюхаус, Стивен; Дарлингтон, Джон (2002). «Значение и поведение сеточно-ориентированных компонентов» (PDF) . Лондонский центр электронных научных исследований Имперского колледжа науки, технологий и медицины. Архивировано из оригинала (PDF) 4 февраля 2012 г.
• Блэк, Эндрю П.; Хуан, Цзе; Костер, Райнер; Уолпол, Джонатан; Пу, Калтон (2002). «Инфопайпы: абстракция для потоковой передачи мультимедиа» (PDF) . Мультимедийные системы . 8 (5). Спрингер-Верлаг: 406–419. дои : 10.1007/s005300200062 . S2CID   5700383 . Проверено 10 августа 2006 г.
• Кра, Дэвид (октябрь 2004 г.). «Серверы zSeries и iSeries в грид-домене» . IBM DeveloperWorks . Проверено 13 июля 2006 г.
• Людешер, Бертрам; Алтинтас, Илкай; Беркли, Чад; и другие. (сентябрь 2004 г.). «Управление научными рабочими процессами и система Кеплера» (PDF) . Суперкомпьютерный центр Сан-Диего . Проверено 14 июля 2006 г.
• Бикл, Джерри; Ричардсон, Кевин; Смит, Джефф (2005). «Обзор технических характеристик программного обеспечения OMG для робототехники» (PDF) . Группа управления объектами - Программные коммуникации. Архивировано из оригинала (PDF) 14 июля 2006 г. Проверено 15 июля 2006 г.
• Блажевич, Марио (2006). «Комбинаторы потоковых компонентов» . Труды по экстремальным языкам разметки . Архивировано из оригинала 18 сентября 2007 г. Проверено 9 ноября 2006 г.
• Каулер, Барри (1999). Flow Design для встраиваемых систем, 2-е издание . Книги по исследованиям и разработкам / Миллер Фриман. ISBN  978-0-87930-555-0 .
• патент США 5204965 , Гутери, Скотт Б.; Барт, Пол С. и Барстоу, Дэвид Р., «Система обработки данных с использованием потоковых хранилищ», выпущено 20 апреля 1993 г., передано Schlumberger Technology Corporation.  
• Моррисон, Дж. Пол (март 2013 г.). «Потоковое программирование» . Новости разработчиков приложений (1). Архивировано из оригинала 8 августа 2014 г. Проверено 25 мая 2014 г.
• Стэплин, Джордж Питер (2006). «Потоковое программирование Tcl — TFP» . Проверено 7 октября 2010 г.
• Джонстон, Уэсли М.; Ханна, младший Пол; Миллар, Ричард Дж. (март 2004 г.). «Достижения в языках программирования потоков данных». Обзоры вычислительной техники ACM . 36 (1): 1–34. дои : 10.1145/1013208.1013209 . S2CID   5257722 .
• Костер, Райнер; Блэк, Эндрю П.; Хуан, Цзе; Уолпол, Джонатан; Пу, Калтон (апрель 2003 г.). «Прозрачность потоков в промежуточном программном обеспечении информационных потоков» . Программное обеспечение: практика и опыт . 33 (4): 321–349. CiteSeerX   10.1.1.15.3933 . дои : 10.1002/сп.510 . S2CID   37356020 . Проверено 5 декабря 2006 г.
• Стивенсон, Тони (февраль 1995 г.). «Обзор «Потокового программирования» » . PC Update, журнал Мельбурнской группы пользователей ПК, Австралия. Архивировано из оригинала 25 сентября 2006 г. Проверено 6 декабря 2006 г.
• Леа, Дуг (май 2001 г.). «Составление односторонних сообщений» . Архивировано из оригинала 7 сентября 2006 г. Проверено 6 декабря 2006 г.
• Бауэрс, Шон; Людешер, Б.; Нгу, АХХ ; Кричлоу, Т. «Возможность повторного использования научного рабочего процесса посредством структурированной композиции потока данных и потока управления» (PDF) . Научный поток '06. Архивировано из оригинала (PDF) 5 февраля 2007 г. Проверено 6 декабря 2006 г.
• Сорбер, Джейкоб; Костадинов, Александр; Гарбер, Мэтью; Бреннан, Мэтью; Корнер, Марк Д.; Бергер, Эмери Д. (2007). «Эон». Eon: язык и система времени выполнения для вечных систем . Материалы 5-й международной конференции «Встраиваемые сетевые сенсорные системы» - Сессия: Управление электропитанием. п. 161. дои : 10.1145/1322263.1322279 . ISBN  9781595937636 . S2CID   12851752 .
• Фидлер, Ларс; Дэйси, Тимоти (2014). «Системы и методы составной аналитики» . Национальная служба технической информации. Архивировано из оригинала 26 августа 2014 г. Проверено 1 апреля 2014 г.
• Мэтт, Карчи (2014). Потоки данных и системы реактивного программирования: Практическое руководство . Независимая издательская платформа CreateSpace. ISBN  978-1497422445 .
• Лампа, Сэмюэл; Дало, Мартин; Альварссон, Джонатан; Спьют, Ола (2018). «SciPipe — библиотека рабочих процессов для гибкой разработки сложных и динамических конвейеров биоинформатики» . bioRxiv : 380808. doi : 10.1101/380808 . Проверено 2 августа 2018 г.