Реферат. В статье рассматриваются функциональные возможности и конкурентные преимущества платформы 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 представлена на рис. 2.
Процесс является наиболее общим понятием описываемой платформы Corezoid. Вообще говоря, процесс — это частично упорядоченное множество действий (иногда их называют мероприятиями или операциями), направленное на достижение определенной цели (производство товара, оказание услуги). В данном случае действиями являются простые вычисления и преобразования порций данных (или записей в терминах традиционных систем управления базами данных), которые здесь называются задачами (их можно называть и объектами, но слово “объект” перегружено, и поэтому мы используем слово “задача” как термин).
Платформа Corezoid позволяет манипулировать задачами, подсчитывать их количества, суммировать числовые значения в задачах и тому подобное. В некоторых простых, но важных случаях, например, во многих бизнес-процессах документооборота, этого уже оказывается достаточно. Однако область применения облачной операционной системы Corezoid документооборотом не ограничивается, поскольку одним из важнейших средств платформы является свободное взаимодействие с любыми внешними приложениями через API (программный интерфейс приложения).
Внешние приложения вполне могут получать и обрабатывать информацию из реального мира и отправлять управляющие и информационные сигналы в реальный мир. Таким образом, сфера применения процессов облачной операционной системы Corezoid лимитирована исключительно доступными API и фактически является неограниченной.
Узел (или corezoid) является центральным понятием описываемой платформы, именно в узлах проявляется оригинальность и выразительная сила облачной платформы Corezoid. Узел определяет, что необходимо сделать с каждой задачей, в форме линейно упорядоченного набора функций. Узлы бывают пяти типов.
Указанные понятия находятся в левой части диаграммы на рис. 2 и относятся к описанию процессов. В правой части диаграммы показаны сущности, относящиеся к выполнению процессов. Эти два мира связаны через функции (команды), описанные в узлах, и применяющиеся к задачам в экземплярах узлов.
![]() |
---|
Рис. 2. Модель предметной области Corezoid |
Функция является элементом программы выполнения задачи в узле. Каждая функция имеет тег, или название, которое определяет выполняемую команду, а также набор аргументов, специфических для команды. Общий список функций (команд) приведен в следующей таблице.
Название | Аргумент(ы) | Описание | Примечание |
---|---|---|---|
Condition | 1) условие; 2) целевой узел |
Условие является конъюнкцией сравнений значений параметров задачи с константами. Если условие выполнено, то задача переводится в целевой узел | не меняет задачу, завершает обработку |
API Call | специфические аргументы метода API | Синхронный вызов метода внешнего API в форматах JSON, XML, SOAP. Задача зависает в узле, пока метод API выполняется. | меняет задачу, выполнение продолжается |
Waiting for callback | URL внешнего процесса | Синхронизация с внешним процессом. Задача зависает в узле, пока не придёт ответ от внешнего процесса | меняет задачу, выполнение продолжается |
Code | 1) язык; 2) код |
Интерпретируется фрагмент кода на указанном языке (Java Script или Erlang). Доступ к параметрам задачи через переменную data. | меняет задачу, выполнение продолжается |
Copy task | 1) процесс; 2) часть задачи |
Задача, возможно частично, копируется в начальный узел другого процесса | не меняет задачу, выполнение продолжается |
Modify task | 1) процесс; 2) часть задачи |
Задача, возможно частично, модифицируется, если находится в узле “Waiting for callback” или “Set state” | не меняет задачу, выполнение продолжается |
Call process | 1) процесс; 2) часть задачи |
копируется в начальный узел другого процесса, тем самым вызывается обработка этой задачи другим процессом. Когда обработка закончена, вызванный процесс должен вернуть обработанную задачу командой Reply to process. | выполнение продолжается |
Reply to process | Задача возвращается вызвавшему процессу. Идентификатор процесса хранится в самой задаче. | не меняет задачу, выполнение продолжается | |
Sum | 1) куда суммировать; 2) что суммировать |
Суммируются значения некоторых параметров задачи | не меняет задачу, выполнение продолжается |
Set parameter | 1) имя параметра; 2) значение |
Присваивается значение параметру задачи. | меняет задачу, выполнение продолжается |
Queue | Текущая задача переводится в локальное хранилище. При этом хранилище может работать в одном из двух режимов: в режиме очереди (FIFO = First In First Out) или в режиме стека (LIFO = Last In First Out). Задача находится в хранилище, пока не поступит сигнал Get task from queue. | не меняет задачу, выполнение продолжается | |
Get task from queue | 1) имя процесса; 2) имя узла |
Из очереди в указанном процессе и в указанном узле извлекается задача для обработки | меняет задачу, выполнение продолжается |
Delay | 1) время | Обработка задачи приостанавливается на указанное время | не меняет задачу, выполнение продолжается |
Task Counter (Alert when there is tasks queue) | 1) предельное количество задач в узле | Используется для запуска/закрытия эскалации по количеству задач в узле. Например, пусть необходимо реагировать на разное количество задач в очереди, которые требуют обработки. Если количество объектов в очереди превышает: a) 50, уведомляем менеджера; б) 100, уведомляем руководителя менеджера. При снижении количества объектов в очереди мы сможем уведомить менеджера/руководителя о уменьшении количества необработанных задач | не меняет задачу, имеет приоритет |
Time limit (Limit the time of the task in the node) | 1) предельное время; 2) целевой узел |
Если время нахождение задачи в узле превышает предельное время, то задача переводится в целевой узел | не меняет задачу, имеет приоритет, завершает обработку |
Функции в узле упорядочены и выполняются в том порядке, в котором записаны, причём две функции, функция 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 имеет три уровня:
На уровне графического интерфейса пользователю доступны следующие основные функции (рис. 9):
Управление пользователями
Создание групп пользователей
Управление диаграммами
Отчеты
Предоставление доступа к отчету пользователям/группам пользователей
![]() |
---|
Рис. 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 |
На вход процесс интерпретатор принимает два параметра:
Результат работы — создание нового процесса, который используя заложенные в него команды, будет преобразовывать входящую строку.
Входные данные для созданного процесса:
Выходные данные:
Пример
На основании команд
"0q1->1q1R", "1q1->0q1R", "Bq1->BSTOP"
Интерпретатором создается процесс, который преобразует input “000111”
в output ”111000”
(рис. 15).
![]() |
---|
Рис. 15. Синтезированная на платформе Corezoid машина Тьюринга, реализующая поразрядную инверсию битовой шкалы |
В целом Coreziod — это мощная перспективная платформа, обладающая всеми возможностями облачной операционной системы и имеющая ряд конкурентных преимуществ, из которых важнейшими мы считаем следующие три.
Corezoid — это универсальный вычислитель. Платформа позволяет программировать любые реальные процессы и обрабатывать любые объемы существующих данных без ограничений. В настоящее время платформа Coreziod успешно применяется различными организациями в следующих предметных областях:
Corezoid — это эффективная и масштабируемая платформа. Облачные вычисления и облачное хранение данных обеспечивают неограниченную масштабируемость, а природный параллелизм базовой системы программирования Erlang обеспечивает возможность обработки данных процессов практически в реальном времени. В частности:
Corezoid — это удобная среда прототипирования и разработки программного обеспечения процессов. Готовая облачная инфраструктура обеспечивает быстрый старт и ничтожные накладные расходы на изучение программных технологий. Современный и изящный графический редактор диаграмм поддерживает наглядность и хороший стиль программирования. Развитая система индикаторов и средств отладки устраняют болезненные препятствия при переходе от прототипа к промышленной эксплуатации.
Прямые эксперименты показывают:
Мы уверены, что облачная платформа Coreziod — это наилучший выбор для реинжиниринга и оптимизации процессов, не связанных обязательствами следовать унаследованным решениям.