Обзор многофункциональной облачной платформы COREZOID

Реферат. В статье рассматриваются функциональные возможности и конкурентные преимущества платформы Corezoid, приводятся её архитектурные особенности и примеры применения.

Введение

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

Corezoid следует современной концепции “платформа как сервис” [1] , система прошла впечатляющий путь развития и доступна всем желающим [2]. Corezoid аккумулирует последние достижения технологии разработки и эксплуатации прикладного программного обеспечения. Базовым языком программирования платформы Corezoid является Erlang [3], что обеспечивает высочайшую степень параллелизма и масштабируемости. В Corezoid реализована оригинальная модель поведения, в которой в терминах статьи [4] можно усмотреть как потоки данных, так и переходы состояний, что позволяет отнести Corezoid к парадигме автоматного программирования [5,6].

План статьи следующий. В первом разделе “Модель использования” мы отвечаем на вопрос: что полезного делает Corezoid во внешнем мире, то есть формулируем функциональные возможности платформы. Затем в разделе “Модель предметной области” вводится глоссарий, то есть определяются основные понятия, присущие платформе Corezoid. Далее приводятся развернутые содержательные примеры, демонстрирующие выразительную силу платформы Corezoid. После этого в двух более формальных разделах “Метамодель языка” и “Алгоритмические свойства” поясняются теоретические основания предлагаемой платформы. Наконец, в заключении статьи выявляются конкурентные преимущества облачной операционной системы Corezoid, следующие из изложенного.

Рассматриваемые понятия компактно представляются диаграммами языка UML [7].

Модель использования

Облачная платформа Corezoid выполняет основные функции, представленные на рисунке 1.

Рис. 1. Варианты использования Corezoid

Вне системы находятся действующие лица, то есть внешние аппаратные, программные или люди, взаимодействующие с системой. Внутри системы находятся варианты использования, то есть описание последовательности событий/действий (сценариев), доставляющие значимые для действующих лиц результаты.

В данном случае можно выделить три действующих лица, которым соответствуют категории пользователей.

• Владелец процесса — категория пользователей, имеющих полномочия на создание и удаление процессов. Обычно владельцы процессов отвечают за результативность и эффективность своих процессов, а потому наблюдение процессов является значимым для них результатом.
• Оператор процесса — категория пользователей, отвечающих за оперативное управление процессами. Если процесс предусматривает ручное вмешательство, то обычно это предоставляется делать оператору.
• Бизнес-аналитик — категория пользователей, конструирующих и совершенствующих процессы.

На верхнем уровне можно выделить восемь вариантов использования, из которых два играют центральную роль.

• Изменить процесс — продвинутый вариант использования, позволяющий определить процесс. Определение процесса строится как совокупность диаграмм в специальном графическом редакторе. Как правило, описание процесса строится за несколько итераций, и на каждой следующей итерации изменяются и дополняются диаграммы, построенные на предыдущей итерации.

  • Создать процесс и Удалить процесс — простые варианты использования, нужные для разграничения полномочий пользователей.

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

  • Вмешаться в прогон процесса — все виды ручного вмешательства в процесс, если таковое вмешательство предусматривается регламентами.
  • Наблюдать прогон процесса — одним из сильнейших конкурентных преимуществ облачной платформы Corezoid является наличие встроенных средств избирательного и детального мониторинга выполнения процессов.
  • Запустить и остановить прогон процесса — очевидно необходимые варианты использования. Запуск процесса включает и начальную загрузку данных, а остановка и завершение процесса могут включать выгрузку данных, если это необходимо.

Модель предметной области

Модель предметной области — это конечный набор сущностей и понятий, используемых в предметной области, а также набор отношений между этими понятиям. Модель предметной области для платформы Corezoid представлена на рис. 2.

Процесс является наиболее общим понятием описываемой платформы Corezoid. Вообще говоря, процесс — это частично упорядоченное множество действий (иногда их называют мероприятиями или операциями), направленное на достижение определенной цели (производство товара, оказание услуги). В данном случае действиями являются простые вычисления и преобразования порций данных (или записей в терминах традиционных систем управления базами данных), которые здесь называются задачами (их можно называть и объектами, но слово “объект” перегружено, и поэтому мы используем слово “задача” как термин).

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

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

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

• Начальный узел всегда ровно один в процессе и служит для указания узла, фактически выполняемого первым, а также в качестве контрольной точки при отладке и трассировке процесса.
• Финальные узлы бывают двух разновидностей: успех и неудача. Как минимум, один финальный узел должен присутствовать в процессе, как правило присутствует несколько финальных узлов. Заметим, что на диаграмме состояний (см. ниже ) финальные узлы могут отсутствовать. Подобно начальному узлу, финальные узлы ничего не делают, а только отмечают факт завершения задачи в узле. Финальные узлы успех и неудача семантически эквивалентны и введены для наглядности: на диаграммах предлагается обозначать эти узлы различными значками.
• Нормальный узел и узел эскалации также семантически эквивалентны. Их различия условны, и введены для наглядности: на диаграммах предлагается закрашивать эти узлы различными цветами. При этом предполагается, что разработчик процесса использует нормальные узлы для описания “нормального” хода обработки задач, а узлы эскалации — для описания реакции на исключительные ситуации.

Указанные понятия находятся в левой части диаграммы на рис. 2 и относятся к описанию процессов. В правой части диаграммы показаны сущности, относящиеся к выполнению процессов. Эти два мира связаны через функции (команды), описанные в узлах, и применяющиеся к задачам в экземплярах узлов.

Рис. 2. Модель предметной области Corezoid

Функция является элементом программы выполнения задачи в узле. Каждая функция имеет тег, или название, которое определяет выполняемую команду, а также набор аргументов, специфических для команды. Общий список функций (команд) приведен в следующей таблице.

Функции в узле упорядочены и выполняются в том порядке, в котором записаны, причём две функции, функция Counter limit и функция Time limit, имеют приоритет и выполняются в первую очередь, если присутствуют в узле и выполнены условия их выполнения. Эти две функции позволяют избегать переполнения очереди задач и избегать бесконечного зависания задач в узлах. Особый статус этих функций на диаграмме рис. 2 подчеркнут тем, что они вынесены в свойства экземпляра узла.

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

Индикатор — это средство наблюдения и мониторинга хода процесса. Предусмотрены следующие индикаторы, показывающие статистику за период и/или мгновенное значение в реальном времени:

• количеству входящих в узел задач;
• количество исходящих из узла задач;
• количество потребленных тактов всего;
• количество потребленных тактов выбранным процессом.

Экземпляр узла — это программный объект, обладающий “свободой воли”. С каждым экземпляром узла связана очередь задач, подлежащих обработке. Экземпляры узлов работают независимо и асинхронно, нет никакого “супервизора”, который бы их подгонял.

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

Задача — это пассивная структура данных, используемая для хранения и переноса информации от одного обрабатывающего экземпляра узла к другому во время прогона процесса. Пафос облачной платформы Corezoid состоит в том, что задач может быть и бывает много: тысячи и миллионы. Каждая задача — это набор именованных параметров.

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

Содержательные примеры

В первом примере рассматривается взаимодействие покупателя и поставщика при покупке и поставке товара. Этот бизнес-процесс хорошо всем известен, и если не вдаваться в излишние детали, устроен сравнительно просто (рис. 3).

Рис. 3. Процесс закупки на стороне заказчика

Процесс закупки начинается на стороне заказчика, у которого возникает потребность, и он размещает заказ. В терминах платформы Coreziod это означает, что объект “заказ”, возникший на стороне покупателя, передается на сторону поставщика с помощью функции Copy task. Вызываемый процесс не должен ничего специально “знать” о вызывающем процессе, вся необходимая информация находятся в самой переданной задаче. Другими словами, взаимодействие между процессами осуществляется по данным, а не по управлению, что делает процессы максимально независимыми.

Далее процесс поставщика через какое-то время даёт ответ на поступивший заказ в виде счета. Процесс покупателя ждёт поступления счета. Это делается с помощью функции Waiting for callback. Если ответ (счет) не поступит в определённое время, причём это время определяется на стороне покупателя, то процесс закупки заканчивается неудачей. Таким образом, хотя общий синхронизирующий “супервизор” взаимодействия процессов отсутствует, ни один процесс не может “зависнуть” на бесконечное время.

Если всё в порядке, и счет поступил вовремя, то это отмечается модификацией исходного заказа на стороне покупателя. Это означает, что счет не создается как отдельный от заказа объект, а имманентно привязан к определённому заказу. Таким образом, платформа Corezoid позволяет автоматически исключить ошибки типа “перепутан номер заказа” и “это чужой счет”. Заметим, что при этом учитывается случай, когда поставщик может отказаться от выполнения заказа по своим причинам (для этого поставщику достаточно установить параметр order == false в заказе).

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

Рассмотрим теперь процесс на стороне поставщика, рис. 4.

Рис. 4. Процесс закупки на стороне поставщика

Продолжая этот же пример, рассмотрим как модифицируются и совершенствуются описания процессов на платформе Corezoid. Допустим, что на стороне поставщика необходимо удовлетворить требованиям международных стандартов управления качеством и предусматривается обязательный “анализ осуществимости”, то есть проверка того, что поставщик сможет выполнить все свои обязательства, причем эта проверка производится до выставления счета (рекламный слоган: “если не понравится, то вернём деньги” уже давно не отвечает современным требованиям). Учет этого обстоятельства на стороне стороне поставщика совершенно не затрагивает процесс на стороне заказчика, как и должно быть, и на стороне поставщика изменения минимальны и консервативны, добавляется всего один узел.

В жизни не только меняются существующие процессы, а появляются новые процесса! Как они должны взаимодействовать с прежними? В рассматриваемом примере допустим, что ввиду роста бизнеса поставщик отказывается от затратных прямых поставок, и передаёт часть процесса, связанного с доставкой, специальной логистической компании (склад), сосредотачиваясь на производстве.

Одно из возможных решений приведено на рис. 5. Хорошо видно, что на стороне покупателя ничего не поменялось, и изменения на стороне поставщика опять минимальны, достаточно очевидны и могут быть сделаны буквально “на ходу”.

Рис. 5. Включение в процесс закупки третьей стороны

Не будет преувеличением сказать, что платформа Corezoid поощряет реинжиниринг процессов, а отнюдь не препятствует развитию бизнеса.

Рассмотрим еще пример, в котором ярко проявляются возможности платформы Corezoid по параллельной и конвейерной обработке задач, выстраиванию очередей задач и масштабированию процессов. В примере рассматривается обработка звонков клиентов в магазин. Общая схема бизнес-процесса представлена блок-схемой на рис. 6.

Рис. 6. Блок-схема бизнес-процесса “Звонки клиентов в магазин по телефону”

Средствами облачной платформы Corezoid этот процесс реализуется следующим образом. Организуется два процесса: первый процесс отвечает за ведение очередей звонков клиентов (рис. 8), а второй процесс отвечает за обработку звонков клиентов оператором (рис. 9). Заметим, что первый процесс “ничего не делает” — в этом процессе только отслеживается изменение состояния звонков и они помещаются в соответствующие очереди. При этом события, управляющие переходами состояний звонков в первом процесса, возникают во втором процессе.

Рис. 7. Процесс “Очередь звонков клиентов”

Рис. 8. Процесс “Взятие клиента в работу оператором”

Метамодель языка

Язык облачной операционной системы Corezoid имеет три уровня:

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

На уровне графического интерфейса пользователю доступны следующие основные функции (рис. 9):

• Управление пользователями

  • Приглашение пользователей в систему

  • Создание групп пользователей

    • Добавление
    • Удаление

• Управление диаграммами

  • Создание
  • Редактирование
  • Просмотр
  • Примерение (Запуск)
  • Тестирование
  • Предоставление доступа пользователям/группам пользователей
  • Загрузка данных поштучно через интерфейс
  • Загрузка данных из файла или через API

• Отчеты

  • Создание
  • Редактирование
  • Просмотр

Предоставление доступа к отчету пользователям/группам пользователей

Рис. 9. Одна из страниц интерфейса пользователя облачной платформы Corezoid

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

Диаграмма состояний описывает переходы между состояниями данных, и представляет собой хранилище “ключ-значение” с возможностью получать данные из любой диаграммы процессов.

Диаграмма процессов описывает бизнес-логику, последовательность вызовов внешних сервисов, исполнение фрагментов кода. Оба типа диаграмм являются диаграммами ориентированных графов, то есть состоят из узлов, соединенных стрелками. Основная информационная нагрузка находится в узлах, стрелки являются не более чем визуальным средством повышения наглядности (рис. 10).

Рис. 10. Метамодель диаграмм процесса и состояний платформы Corezoid

На графы процессов в системе Corezoid накладываются следующие контекстные условия:

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

Из этого следует, что граф диаграммы является односторонне связным направленным орграфом без петель, то есть сетью с одним источником и несколькими стоками.

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

Центральным элементом языка является набор функций в узле. Сами функции имеют простую структуру (рис. 11).

Рис. 11. Функции облачной операционной системы Corezoi

Алгоритмические свойства

Описание всякой облачной платформы или системы программирования должно давать исчерпывающие ответы на три вопроса:

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

Применяются различные методы задания операционной семантики. Самым простой и очевидный способ ответить на вопрос “как работает система” — предъявить алгоритм работы, то есть интерпретатор определяемого языка, записанный на каком-либо другом языке, который считается известным. Язык блок-схем или диаграмм деятельности UML — один из самых распространенных языков описания алгоритмов. Примем язык диаграмм деятельности как известный. В этом случае на рис. 12 приведена диаграмма деятельности, которая описывает алгоритм интерпретации, непрерывно работающий в каждом узле запущенного процесса в облачной платформе Corezoid.

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

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

Рис. 12. Алгоритм интерпретации узла облачной операционной системы Corezoid

Свойство алгоритмической полноты имеет несколько академический характер. Говорят, что некоторая система программирования алгоритмически полна, если всякий алгоритм, который задан в заведомо полной системе программирования, возможно задать и в рассматриваемой системе. Основной приём доказательства алгоритмической полноты состоит в том, чтобы средствами рассматриваемой системы программирования построить интерпретатор заведомо полной системы. Машина Тьюринга [8] считается алгоритмически полной моделью. В этой модели присутствует потенциально бесконечная лента, разбитая на ячейки, в которых записаны символы. Имеется головка чтения/записи, которая может передвигаться на одну ячейку влево и вправо, а также читать символы с ленты и записывать символы на ленту. Наконец, имеется устройство управления, которое по двум параметрам, а именно прочитанному на ленте символу и текущему состоянию, определяет три параметра: символ, который надо записать на ленту, куда надо сдвинутся и в какое состояние перейти. Считается, что перед началом работы на ленте записаны символы входных данных, головка чтения/записи обозревает самый левый символ, а устройство управления находится в некотором начальном состоянии. Далее машина Тьюринга работает до тех пор, пока устройство управления не перейдет в заключительное состояние.

В качестве доказательства алгоритмической полноты и одновременно в качестве примера выразительной силы, приведем реализацию на платформе Corezoid интерпретатора машины Тьюринга. Этот интерпретатор воспринимает на входе текстовую запись команд машины Тьюринга и синтезирует реально выполнимый рабочий процесс на платформе Corezoid, который эмулирует работу машины Тьюринга, поданной на вход интерпретатора. Блок-схема интерпретатора представлена на рис. 13.

Рис. 13. Интерпретатор машины Тьюринга

Сам интерпретатор машины Тьюринга в Corezoid представлен на рис. 14. Мы видим, что нетривиальный алгоритм записывается на языке платформы Corezoid достаточно естественно.

Рис. 14. Раскрутка облачной операционной системы Corezoid

На вход процесс интерпретатор принимает два параметра:

• commands (array) — список команд машине Тьюринга
• proc_name — название нового процесса

Результат работы — создание нового процесса, который используя заложенные в него команды, будет преобразовывать входящую строку.

Входные данные для созданного процесса:

• input — строка исходных данных.

Выходные данные:

• output — преобразованная строка.

Пример

На основании команд

"0q1->1q1R", "1q1->0q1R", "Bq1->BSTOP"

Интерпретатором создается процесс, который преобразует input “000111” в output ”111000” (рис. 15).

Рис. 15. Синтезированная на платформе Corezoid машина Тьюринга, реализующая поразрядную инверсию битовой шкалы

Заключение

В целом Coreziod — это мощная перспективная платформа, обладающая всеми возможностями облачной операционной системы и имеющая ряд конкурентных преимуществ, из которых важнейшими мы считаем следующие три.

Corezoid — это универсальный вычислитель. Платформа позволяет программировать любые реальные процессы и обрабатывать любые объемы существующих данных без ограничений. В настоящее время платформа Coreziod успешно применяется различными организациями в следующих предметных областях:

• Финансовые организации, финтех
• Retail, E-commerce, FMCG
• Страхование
• Энергетика
• Логистика
• Технологические компании
• Аграрная промышленность
• И другое

Corezoid — это эффективная и масштабируемая платформа. Облачные вычисления и облачное хранение данных обеспечивают неограниченную масштабируемость, а природный параллелизм базовой системы программирования Erlang обеспечивает возможность обработки данных процессов практически в реальном времени. В частности:

• на текущий момент система выполняет 660 тыс. процессов
• обрабатывается несколько десятков тысяч объектов в секунду

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

Прямые эксперименты показывают:

• Начальное обучение занимает 2-3 дня
• Всего было обучено более 3,000 человек
• скорость разработки и получения рабочего процесса в Corezoid в 4 раза быстрее по сравнению с системой управления бизнес-процессами Appian.

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

Литература

1. Butler B., "PaaS Primer: What is platform as a service and why does it matter?" Network World, February 11, 2013.
2. https://www.corezoid.com/ru/whitepaper
3. https://www.erlang.org/
4. Bock C., Odell J., “Ontological Behavior Modeling”, Journal of Object Technology, Volume 10, (2011), pp. 3:1-36
5. Shalyto A.A., Tukkel N.I.,” SWITCH-Technology: An Automated Approach to Developing Software for Reactive Systems” // Programming and Computer Software, 27(5), 2001.
6. Shalyto A.A. “Logic Control and "Reactive" Systems: Algorithmization and Programming” //Automation and Remote Control. 2001. N1, pp.1-29.
7. Rumbaugh J., Jacobson I., Booch G., “The Unified Modeling Language Reference Manual”, (2nd Edition), Addison-Wesley, 1999.
8. Hopcroft J., Motwani R., Ullman J.D. Introduction to Automata Theory, Languages, and Computation. — Addison-Wesley, 2001.