Сервисно-ориентированное программирование (SOP) — это парадигма программирования , которая использует «сервисы» в качестве единицы компьютерной работы для проектирования и внедрения интегрированных бизнес-приложений и критически важных программ. Сервисы могут представлять этапы бизнес-процессов , и, таким образом, одним из основных применений этой парадигмы является экономически эффективная доставка автономных или составных бизнес-приложений, которые могут «интегрироваться изнутри наружу». По сути, она продвигает сервисно-ориентированную архитектуру (SOA), однако это не то же самое, что SOA. В то время как SOA фокусируется на коммуникации между системами, использующими «сервисы», [1] SOP предоставляет новую технику для создания гибких модулей приложений с использованием сервисов в памяти в качестве единицы работы.
Служба в памяти в SOP может быть прозрачно вынесена наружу как операция веб-службы . Благодаря независимым от языка и платформы стандартам веб-служб, SOP охватывает все существующие парадигмы программирования, языки и платформы. В SOP дизайн программ вращается вокруг семантики вызовов служб, логической маршрутизации и описания потока данных через четко определенные интерфейсы служб. Все программные модули SOP инкапсулируются как службы, и служба может состоять из других вложенных служб иерархическим образом с практически неограниченной глубиной этой иерархии стека служб. Составная служба также может содержать программные конструкции, некоторые из которых являются специфичными и уникальными для SOP. Служба может быть вынесенным наружу системным компонентом, доступ к которому осуществляется через любой фирменный API или стандарты веб-служб, использующие технику подключаемого модуля в памяти.
Хотя SOP поддерживает базовые программные конструкции для упорядочивания, выбора и итерации, он отличается множеством новых программных конструкций, которые предоставляют встроенные собственные возможности, направленные на обработку списков данных, интеграцию данных , автоматизированную многопоточность сервисных модулей, декларативное управление контекстом и синхронизацию сервисов. Проектирование SOP позволяет программистам семантически синхронизировать выполнение сервисов, чтобы гарантировать его правильность, или объявлять сервисный модуль как границу транзакции с автоматическим поведением фиксации/отката.
Инструменты семантического проектирования и платформы автоматизации времени выполнения могут быть созданы для поддержки фундаментальных концепций SOP. Например, виртуальная машина служб (SVM), которая автоматически создает объекты служб как единицы работы и управляет их контекстом, может быть разработана для работы на основе метаданных программы SOP, хранящихся в XML и созданных инструментом автоматизации времени проектирования. В терминах SOA SVM является как производителем, так и потребителем услуг.
Концепции SOP обеспечивают надежную базу для семантического подхода к интеграции программирования и логике приложений. У этого подхода есть три существенных преимущества:
Ниже приведены некоторые ключевые концепции СОП:
В SOP программные модули в памяти строго инкапсулированы через четко определенные интерфейсы сервисов, которые могут быть вынесены наружу по требованию в виде операций веб-сервисов. Эта минимальная единица инкапсуляции максимизирует возможности повторного использования в других модулях сервисов в памяти, а также в существующих и устаревших программных активах. Используя интерфейсы сервисов для сокрытия информации , SOP расширяет принципы проектирования, ориентированные на сервисы, используемые в SOA, для достижения разделения задач между модулями сервисов в памяти.
Интерфейс сервиса в SOP — это объект в памяти, который описывает четко определенную программную задачу с четко определенными входными и выходными структурами данных . Интерфейсы сервиса могут быть сгруппированы в пакеты. Интерфейс сервиса SOP может быть вынесен вовне как операция WSDL , а отдельная служба или пакет сервисов могут быть описаны с помощью WSDL. Кроме того, интерфейсы сервиса могут быть назначены одной или нескольким группам сервисов на основе общих свойств.
В SOP свойства времени выполнения, хранящиеся в метаданных интерфейса службы, служат контрактом с виртуальной машиной службы (SVM). Одним из примеров использования свойств времени выполнения является декларативная синхронизация служб . Интерфейс службы может быть объявлен как полностью синхронизированный интерфейс, что означает, что только один экземпляр этой службы может работать в любой момент времени. Или он может быть синхронизирован на основе фактического значения ключевых входных данных во время выполнения, что означает, что никакие два экземпляра службы этой службы с одинаковым значением для их ключевых входных данных не могут работать одновременно. Кроме того, синхронизация может быть объявлена между интерфейсами служб, которые принадлежат к одной и той же группе служб. Например, если две службы, «CreditAccount» и «DebitAccount», принадлежат к одной и той же группе служб синхронизации и синхронизированы по полю ввода accountName, то никакие два экземпляра «CreditAccount» и «DebitAccount» с одинаковым именем счета не могут выполняться одновременно.
Вызыватель сервиса делает запросы на сервис. Это подключаемый интерфейс в памяти, который абстрагирует местоположение производителя сервиса, а также протокол связи, используемый между потребителем и производителем при прохождении через память компьютера, из среды выполнения SOP, такой как SVM. Производитель может быть внутрипроцессным (т. е. в памяти), вне процесса на той же серверной машине или виртуализированным в наборе сетевых серверных машин. Использование вызывателя сервиса в SOP является ключом к прозрачности местоположения и виртуализации. Еще одной важной особенностью уровня вызывающего сервиса является возможность оптимизировать полосу пропускания и производительность при общении между машинами. Например, «вызыватель SOAP» является вызывателем сервиса по умолчанию для удаленного общения между машинами с использованием стандартов веб-сервисов . Этот вызыватель может динамически заменяться, если, например, производитель и потребитель хотят общаться через упакованный фирменный API для лучшей безопасности и более эффективного использования полосы пропускания.
Слушатель сервиса получает запросы сервиса. Это подключаемый интерфейс в памяти, который абстрагирует протокол связи для входящих запросов сервиса, сделанных в среде выполнения SOP, такой как SVM. Благодаря этому абстрактному слою среда выполнения SOP может быть виртуально встроена в адрес памяти любой традиционной среды программирования или службы приложения.
В SOP модуль сервиса может быть реализован как Composite или Atomic сервис. Важно отметить, что модули сервиса, созданные с помощью парадигмы SOP, имеют экстравертную природу и могут быть прозрачно вынесены наружу с помощью таких стандартов, как SOAP или любого фирменного протокола.
Одной из важнейших характеристик SOP является то, что он может поддерживать полностью семантический подход к программированию. Более того, этот семантический подход может быть наложен на визуальную среду, построенную поверх полностью управляемого метаданными слоя для хранения интерфейсов сервисов и определений модулей сервисов. Более того, если среда выполнения SOP поддерживается SVM, способной интерпретировать слой метаданных, необходимость в автоматической генерации кода может быть устранена. Результатом является колоссальный прирост производительности во время разработки, простота тестирования и значительная гибкость при развертывании.
Реализация составной службы — это семантическое определение модуля службы, основанное на методах и концепциях SOP. Если вы посмотрите внутрь определения интерфейса составной службы в черном ящике , вы можете увидеть другие интерфейсы служб, соединенные друг с другом и соединенные с программными конструкциями SOP. Составная служба имеет рекурсивное определение, означающее, что любая служба внутри («внутренняя служба») может быть другой атомарной или составной службой. Внутренняя служба может быть рекурсивной ссылкой на ту же содержащую составную службу.
SOP поддерживает основные программные конструкции для последовательности, выбора и итерации, а также встроенное, расширенное поведение. Кроме того, SOP поддерживает семантические конструкции для автоматического отображения данных , перевода, манипуляции и потока через внутренние службы составной службы.
Служба внутри определения составной службы («внутренняя служба») неявно упорядочена через семантическую связность встроенных портов успеха или отказа других внутренних служб с ее встроенным портом активации. Когда внутренняя служба запускается успешно, все внутренние службы, подключенные к ее порту успеха, будут запущены следующими. Если внутренняя служба выходит из строя, все службы, подключенные к ее порту отказа, будут запущены следующими.
Логический выбор осуществляется с помощью управляемых данными ветвящихся конструкций и других настраиваемых конструкций. В общем случае настраиваемые конструкции — это службы, встроенные в платформу SOP с входами и выходами, которые могут принимать форму входов/выходов других подключенных служб. Например, настраиваемая конструкция, используемая для фильтрации выходных данных служб, может принимать список заказов на продажу, заказов на покупку или любую другую структуру данных и фильтровать свои данные на основе объявленных пользователем свойств фильтра, хранящихся в интерфейсе этого экземпляра конструкции фильтра. В этом примере структура, подлежащая фильтрации, становится входом конкретного экземпляра конструкции фильтра, а та же структура, представляющая отфильтрованные данные, становится выходом настраиваемой конструкции.
Композитная служба может быть объявлена циклической. Цикл может быть связан фиксированным числом итераций с необязательной встроенной задержкой между итерациями и может динамически завершаться с помощью конструкции «service exit with successful» или «service exit with failure» внутри циклической композитной службы. Кроме того, любой интерфейс службы может автоматически запускаться в режиме цикла или « foreach », если ему предоставлены два или более входных компонента при автоматической подготовке. Такое поведение поддерживается во время разработки, когда структура списка данных из одной службы подключается к службе, которая принимает одну структуру данных (т. е. не множественную) в качестве входных данных. Если свойство среды выполнения интерфейса композитной службы объявлено для поддержки «foreach» параллельно, то среда автоматизации среды выполнения может автоматически разбить цикл на несколько потоков и запустить его параллельно. Это пример того, как программные конструкции SOP предоставляют встроенную расширенную функциональность.
Конструкции отображения, перевода и преобразования данных позволяют автоматически передавать данные между внутренними службами. Внутренняя служба готова к запуску, когда она активирована и все ее входные зависимости разрешены. Все подготовленные внутренние службы в составе составной службы запускаются в параллельном пакете, называемом «гиперциклом». Это одно из средств, с помощью которых в SOP поддерживается автоматическая параллельная обработка. Определение составной службы содержит неявный направленный граф зависимостей внутренней службы. Среда выполнения для SOP может создать граф выполнения на основе этого направленного графа, автоматически создавая экземпляры и запуская внутренние службы параллельно, когда это возможно.
Обработка исключений — это ошибка времени выполнения в Java. Обработка исключений в SOP выполняется просто путем соединения порта отказа внутренних служб с другой внутренней службой или с программной конструкцией. Конструкции «Выход с отказом» и «выход с успехом» являются примерами конструкций, используемых для обработки исключений. Если не предпринимать никаких действий на порту отказа службы, то внешняя (родительская) служба автоматически выйдет из строя, а стандартные выходные сообщения от неисправной внутренней службы автоматически поднимутся на стандартный вывод родителя.
Композитная служба может быть объявлена как граница транзакции . Среда выполнения для SOP автоматически создает и управляет иерархическим контекстом для объектов композитной службы, которые используются как граница транзакции. Этот контекст автоматически фиксируется или откатывается при успешном выполнении композитной службы.
Специальные составные службы, называемые службами компенсации, могут быть связаны с любой службой в пределах SOP. Когда составная служба, объявленная как граница транзакции, дает сбой без маршрутизации обработки исключений, среда выполнения SOP автоматически отправляет службы компенсации, связанные со всеми внутренними службами, которые уже были выполнены успешно.
Атомарный сервис — это расширение в памяти среды выполнения SOP через интерфейс SNI (service native interface), по сути, это механизм подключаемого модуля. Например, если SOP автоматизирован через SVM, подключаемый модуль сервиса динамически загружается в SVM при потреблении любой связанной службы. Примером подключаемого модуля сервиса может быть подключаемый модуль коммуникатора SOAP , который может на лету преобразовывать любые входные данные сервиса в памяти в запрос SOAP веб-службы, отправлять его производителю сервиса, а затем преобразовывать соответствующий ответ SOAP в выходные данные в памяти на сервисе. Другим примером подключаемого модуля сервиса является стандартный подключаемый модуль SQL базы данных, который поддерживает операции доступа к данным, изменения и запроса. Еще одним примером, который может помочь установить фундаментальную важность атомарных сервисов и подключаемых модулей сервисов, является использование вызывающего сервис в качестве подключаемого модуля сервиса для прозрачной виртуализации сервисов в различных экземплярах платформы SOP. Эту уникальную виртуализацию на уровне компонентов называют «виртуализацией сервисной сетки», чтобы отличить ее от традиционной виртуализации на уровне приложений или процессов .
SOP предоставляет значительные возможности для поддержки сквозных проблем для всех приложений, созданных с использованием техники SOP. В следующих разделах определяются некоторые из этих возможностей:
Среда выполнения SOP может систематически обеспечивать встроенное и оптимизированное профилирование, регистрацию и измерение для всех служб в режиме реального времени.
На основе объявленных значений входных ключей экземпляра службы выходные данные нечувствительной ко времени внутренней службы могут кэшироваться средой выполнения SOP при запуске в контексте определенной составной службы. Когда служба кэшируется для определенных входных ключей, среда выполнения SOP извлекает кэшированные выходные данные, соответствующие ключевым входным данным, из своего кэша службы вместо того, чтобы потреблять службу. Доступность этого встроенного механизма для разработчика приложений SOP может значительно снизить нагрузку на внутренние системы.
SOP предоставляет механизм для связывания особого вида составной службы, службы триггера, с любой другой службой. Когда эта служба потребляется, платформа SOP автоматически создает и потребляет экземпляр связанной службы триггера с копией входов службы триггера в памяти. Это потребление не влияет на выполнение службы триггера. Триггер службы может быть объявлен для запуска при активации, сбое или успешном завершении службы триггера.
В дополнение к возможности вызова любой службы, события запроса на обслуживание и общая память являются двумя встроенными механизмами SOP, предоставляемыми для межсервисной коммуникации. Потребление службы рассматривается как событие в SOP. SOP предоставляет механизм событий на основе корреляции, который приводит к упреждению работающего композита, который объявил с помощью конструкции «wait» необходимость ожидания одного или нескольких других событий потребления службы с указанными входными значениями данных. Выполнение композитной службы продолжается, когда службы потребляются с определенными ключевыми входами корреляции, связанными с конструкцией ожидания. SOP также предоставляет общее пространство памяти с контролем доступа, где службы могут получать доступ и обновлять четко определенную структуру данных , которая похожа на структуру ввода/вывода служб. К механизму общей памяти в SOP можно программно обращаться через интерфейсы служб.
В SOP настройки управляются с помощью изобретательной функции, называемой Service Overrides. С помощью этой функции реализация службы может быть статически или динамически переопределена одной из многих возможных реализаций во время выполнения. Эта функция аналогична полиморфизму в объектно-ориентированном программировании . Каждая возможная реализация переопределения может быть связана с одним или несколькими портфелями конфигураций переопределения для управления активацией групп связанных переопределений в различных установках приложений SOP во время развертывания .
Отдельные службы могут быть безопасно развернуты для внешнего программного потребления с помощью уровня представления ( GUI ) или других приложений. После определения учетных записей служб среда выполнения SOP автоматически управляет доступом через механизмы предоставления учетных записей потребителей .
Среда выполнения SOP может систематически предоставлять встроенную аутентификацию и авторизацию сервисов . В целях авторизации проекты разработки SOP, учетные записи потребителей, пакеты и сервисы рассматриваются как ресурсы с контролем доступа. Таким образом, среда выполнения SOP может предоставлять встроенную авторизацию. Стандарты или фирменная авторизация и безопасность связи настраиваются с помощью переопределений сервисов, подключаемых модулей вызова и прослушивания сервисов.
Поскольку все артефакты SOP являются хорошо инкапсулированными службами, а все механизмы SOP, такие как общая память, могут быть предоставлены как распределяемые службы, крупномасштабная виртуализация может быть автоматизирована средой выполнения SOP. Кроме того, иерархический стек служб составной службы с несколькими графами выполнения, связанными с ее внутренними службами на каждом уровне, предоставляет огромные возможности для автоматизированной многопоточности в среде выполнения SOP.
Термин сервисно-ориентированное программирование был впервые опубликован в 2002 году Альберто Силлитти, Туллио Вернацца и Джанкарло Суччи в книге под названием «Повторное использование программного обеспечения: методы, приемы и инструменты». SOP, как описано выше, отражает некоторые аспекты использования термина, предложенного Силлитти, Вернацца и Суччи.
Сегодня парадигма SOP находится на ранних стадиях принятия в массе. Существует четыре рыночных драйвера, которые подпитывают это принятие: