Сервисно-ориентированное программирование

Сервис-ориентированное программирование (СОП) — это парадигма программирования , в которой «сервисы» используются в качестве единицы компьютерной работы для разработки и реализации интегрированных бизнес-приложений и критически важных программ. Сервисы могут представлять собой этапы бизнес-процессов , и поэтому одним из основных применений этой парадигмы является экономически эффективная доставка автономных или составных бизнес-приложений, которые могут «интегрироваться изнутри». По своей сути он продвигает сервис-ориентированную архитектуру (SOA), однако это не то же самое, что SOA. В то время как SOA фокусируется на взаимодействии между системами с использованием «сервисов», 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 Invoker» — это вызов службы по умолчанию для удаленной связи между компьютерами с использованием стандартов веб-сервисов . Этот инициатор можно динамически заменять, если, например, производитель и потребитель хотят взаимодействовать через упакованный проприетарный API для большей безопасности и более эффективного использования полосы пропускания.

Слушатель службы

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

Реализация услуги

В SOP сервисный модуль может быть реализован как составной или атомарный сервис. Важно отметить, что сервисные модули, построенные на основе парадигмы SOP, имеют экстравертную природу и могут быть прозрачно реализованы через такие стандарты, как SOAP или любой другой собственный протокол.

Семантический подход

Одной из наиболее важных характеристик SOP является то, что она может поддерживать полностью семантический подход к программированию. Более того, этот семантический подход может быть внедрен в визуальную среду, построенную поверх слоя, полностью управляемого метаданными , для хранения определений сервисного интерфейса и сервисного модуля. Более того, если среда выполнения SOP поддерживается SVM, способной интерпретировать уровень метаданных, необходимость в автоматической генерации кода может быть устранена. Результатом является огромный прирост производительности во время разработки, простота тестирования и значительная гибкость при развертывании.

Реализация сервиса: составной сервис

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

Конструкции программирования

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

Секвенирование

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

Выбор

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

Итерация

Составную службу можно объявить как циклическую. Цикл может быть связан фиксированным количеством итераций с дополнительной встроенной задержкой между итерациями и может динамически завершаться с использованием конструкции «завершение службы с успехом» или «завершение службы с ошибкой» внутри составной службы цикла. Более того, любой сервисный интерфейс может автоматически работать в циклическом режиме или в режиме « foreach », если при автоматической подготовке он поставляется с двумя или более входными компонентами. Такое поведение поддерживается во время разработки, когда структура списка данных из одной службы подключается к службе, которая принимает в качестве входных данных одну структуру данных (т. е. немножественное число). Если свойство среды выполнения составного интерфейса службы объявлено как поддерживающее параллельную поддержку foreach, то среда автоматизации среды выполнения может автоматически выполнить многопоточный цикл и запустить его параллельно. Это пример того, как программные конструкции SOP обеспечивают встроенную расширенную функциональность.

Преобразование, картирование и перевод данных

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

Обработка исключений

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

Транзакционная граница

Составная служба может быть объявлена ​​как граница транзакции . Среда выполнения SOP автоматически создает иерархический контекст для составных объектов службы, которые используются в качестве границы транзакции, и управляет им. Этот контекст автоматически фиксирует или выполняет откат после успешного выполнения составной службы.

Компенсация за услуги

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

Реализация сервиса: атомарный сервис

Атомарная служба — это расширение среды выполнения SOP в памяти через собственный интерфейс службы (SNI). По сути, это подключаемый механизм. Например, если SOP автоматизирован через SVM , подключаемый модуль службы динамически загружается в SVM при использовании любой связанной службы. Примером подключаемого модуля службы может быть подключаемый модуль SOAP- коммуникатора, который может на лету преобразовывать любые входные данные службы, находящиеся в памяти, в запрос SOAP веб-службы, отправлять их производителю службы, а затем транслировать соответствующий запрос. Ответ SOAP на выходные данные службы в памяти. Другим примером подключаемого модуля службы является стандартный подключаемый модуль базы данных SQL, который поддерживает доступ к данным, их изменение и операции запроса. Еще одним примером, который может помочь установить фундаментальную важность атомарных служб и подключаемых модулей служб, является использование средства вызова службы в качестве подключаемого модуля службы для прозрачной виртуализации служб в различных экземплярах платформы SOP. Эта уникальная виртуализация на уровне компонентов называется «виртуализацией сервисной сети», чтобы отличить ее от традиционных приложений или процессов. виртуализация .

Сквозные проблемы

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

Инструментарий обслуживания

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

Декларативное и контекстно-зависимое кэширование сервисов

На основе объявленных ключевых входных значений экземпляра службы выходные данные нечувствительной ко времени внутренней службы могут кэшироваться средой выполнения SOP при запуске в контексте конкретной составной службы. Когда служба кэшируется для определенных входных значений ключа, среда выполнения SOP извлекает кэшированные выходные данные, соответствующие входным ключам, из своего кэша службы вместо использования службы. Доступность этого встроенного механизма для разработчика приложения СОП может значительно снизить нагрузку на серверные системы.

Сервисные триггеры

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

Межсервисная связь

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

Переопределение службы

В SOP настройки управляются с помощью изобретательной функции, называемой Service Overrides. Благодаря этой функции реализация службы может быть статически или динамически переопределена одной из многих возможных реализаций во время выполнения. Эта особенность аналогична полиморфизму в объектно-ориентированном программировании . Каждую возможную реализацию переопределения можно связать с одним или несколькими портфелями конфигурации переопределения, чтобы управлять активацией групп связанных переопределений в различных установках приложений SOP во время развертывания .

Предоставление учетной записи потребителя

Некоторые службы можно безопасно развернуть для внешнего программного использования с помощью уровня представления ( GUI ) или других приложений. После определения учетных записей служб среда выполнения SOP автоматически управляет доступом через механизмы предоставления учетных записей потребителей .

Безопасность

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

Виртуализация и автоматическая многопоточность

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

История

Термин сервис-ориентированное программирование был впервые опубликован в 2002 году Альберто Силлитти, Туллио Вернацца и Джанкарло Суччи в книге «Повторное использование программного обеспечения: методы, техники и инструменты». СОП, как описано выше, отражает некоторые аспекты использования термина, предложенного Силлитти, Вернаццей и Суччи.

Сегодня парадигма СОП находится на ранних стадиях массового внедрения. Этому внедрению способствуют четыре рыночных фактора:

• Многоядерная архитектура процессора: из-за проблем с рассеиванием тепла при увеличении тактовой частоты процессора выше 4 ГГц ведущие поставщики процессоров, такие как Intel, обратились к многоядерной архитектуре для обеспечения постоянно растущей производительности. См. статью «Бесплатный обед окончен ». Это изменение в дизайне приводит к изменению способа разработки наших программных модулей и приложений: приложения должны быть написаны для одновременной работы , чтобы использовать многоядерные процессоры, а написание параллельных программ является сложной задачей. задача. SOP предоставляет встроенную возможность автоматической многопоточности .
• приложений Виртуализация : SOP обеспечивает встроенный микроконтроль над прозрачностью местоположения компонентов службы любого сервисного модуля. Это приводит к автоматической и детальной виртуализации компонентов приложения (а не всего процесса приложения) в кластере или сетке платформ времени выполнения SOP.
• Сервис-ориентированная архитектура (SOA) и спрос на интегрированные и составные приложения: вначале внедрение SOP будет следовать кривой внедрения SOA с небольшим отставанием. Это связано с тем, что сервисы, созданные с помощью SOA, можно легко собрать и использовать с помощью SOP. Чем больше веб-сервисов распространяется, тем больше смысла использовать семантическую природу SOP. С другой стороны, поскольку SOA является неотъемлемой частью SOP, SOP обеспечивает экономически эффективный способ доставки SOA на основные рынки.
• Программное обеспечение как услуга (SaaS): возможности существующих платформ SaaS не позволяют решить сложности настройки и интеграции, необходимые крупным предприятиям. SOP может значительно упростить интеграцию и настройку. Это приведет к тому, что SOP станет частью платформ SaaS следующего поколения.

См. также

• Микросервисы

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

• Сервис-ориентированное программирование: новая парадигма повторного использования программного обеспечения
• Grid-виртуализация и решения на базе Itanium®