Войти
Сервисно-ориентированное программирование (SOP) - это парадигма программирования, использующая «сервисы» в качестве единицы компьютерной работы для разработки и внедрения интегрированных бизнес-приложений и критически важных программ. Сервисы могут представлять собой этапы бизнес-процессов, и поэтому одним из основных приложений этой парадигмы является рентабельная поставка автономных или составных бизнес-приложений, которые могут «интегрироваться изнутри»
СОП по своей сути продвигает сервис-ориентированную архитектуру (SOA), однако, это не то же самое, что SOA. В то время как SOA фокусируется на связи между системами с использованием «сервисов», SOP предоставляет новую технику для создания гибких приложений модулей с использованием сервисов в памяти в качестве единицы работы.
Служба в памяти в SOP может быть прозрачно экстернализована как операция веб-службы. Благодаря независимым от языка и платформ стандартам веб-служб, SOP охватывает все существующие парадигмы программирования, языки и платформы. В SOP дизайн программ вращается вокруг семантики вызовов служб, логической маршрутизации и описания потока данных через четко определенные интерфейсы служб. Все программные модули SOP инкапсулируются как службы, и служба может состоять из других вложенных служб в иерархическом порядке с практически неограниченной глубиной для этой иерархии стека служб. Составной сервис также может содержать программные конструкции, некоторые из которых специфичны и уникальны для SOP. Служба может быть внешним компонентом из другой системы, доступ к которой осуществляется либо с помощью стандартов веб-служб, либо через любой проприетарный API через механизм подключаемых модулей в памяти.
Хотя SOP поддерживает базовые программные конструкции для упорядочивания, выбора и итерации, она отличается множеством новых программных конструкций, которые предоставляют встроенные собственные возможности, ориентированные на манипулирование списком данных, интеграция данных, автоматизированная многопоточность сервисных модулей, декларативное управление контекстом и синхронизация сервисов. Дизайн SOP позволяет программистам семантически синхронизировать выполнение служб, чтобы гарантировать ее правильность, или объявлять служебный модуль как границу транзакции с автоматическим режимом фиксации / отката.
Инструменты семантического проектирования и платформы автоматизации времени выполнения могут быть созданы для поддержки фундаментальных концепций СОП. Например, (SVM), который автоматически создает служебные объекты как единицы работы и управляет их контекстом, может быть разработан для запуска на основе программы SOP метаданных, хранящихся в XML и созданных инструмент автоматизации времени проектирования. С точки зрения SOA, SVM является одновременно производителем и потребителем сервиса.
Концепции СОП обеспечивают прочную основу для семантического подхода к интеграции программирования и логике приложений. У этого подхода есть три существенных преимущества:
Ниже приведены некоторые из ключевых концепций SOP:
В SOP программные модули в памяти строго инкапсулируются через четко определенные сервисные интерфейсы, которые по запросу могут быть экстернализованы как операции веб-сервисов. Этот минимальный модуль инкапсуляции максимален. z объединяет возможности повторного использования в других служебных модулях в памяти, а также в существующем и устаревшем программном обеспечении. Используя сервисные интерфейсы для сокрытия информации, 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 поддерживается SVM, способной интерпретировать уровень метаданных, необходимость в автоматической генерации кода может быть устранена. Результат - огромный прирост производительности при разработке, простота тестирования и значительная гибкость в развертывании.
A Реализация составной услуги представляет собой семантическое определение модуля услуги, основанное на методах и концепциях СОП. Если вы заглянете внутрь определения интерфейса , заключенного в черный ящик, составной службы, вы можете увидеть другие интерфейсы службы, связанные друг с другом и связанные с конструкциями программирования SOP. Составная служба имеет рекурсивное определение, означающее, что любая служба внутри («внутренняя служба») может быть другой атомарной или составной службой. Внутренняя служба может быть рекурсивной ссылкой на ту же содержащую составную службу.
SOP поддерживает базовые программные конструкции для последовательности, выбора и итерации, а также встроенное расширенное поведение. Кроме того, SOP поддерживает семантические конструкции для автоматического отображения данных, преобразования, манипулирования и передачи между внутренними службами составной службы.
Служба внутри определения составной службы («внутренняя служба») неявно упорядочивается через семантическую связь встроенных портов успеха или сбоя других внутренних служб с его встроенный порт активации. Когда внутренняя служба работает успешно, все внутренние службы, подключенные к ее успешному порту, будут работать дальше. В случае сбоя внутренней службы все службы, подключенные к ее порту сбоя, будут запущены следующим образом.
Логический выбор осуществляется посредством управляемых данными конструкций ветвления и других конфигурируемых конструкций. В общем, настраиваемые конструкции - это сервисы, встроенные в платформу SOP, с входами и выходами, которые могут принимать форму входа / выхода других подключенных сервисов. Например, настраиваемая конструкция, используемая для фильтрации выходных данных служб, может принимать список заказов на продажу, заказов на покупку или любую другую структуру данных и фильтровать их данные на основе объявленных пользователем свойств фильтра, хранящихся в интерфейсе этого экземпляра конструкции фильтра.. В этом примере структура, которая должна быть отфильтрована, становится входом конкретного экземпляра конструкции фильтра, а та же структура, представляющая отфильтрованные данные, становится выходом конфигурируемой конструкции.
Составная служба может быть объявлена в цикле. Цикл может быть связан фиксированным числом итераций с необязательной встроенной задержкой между итерациями, и он может динамически завершаться с использованием конструкции «успешный выход из службы» или «выход из службы с ошибкой» внутри составной службы цикла. Более того, любой служебный интерфейс может автоматически запускаться в циклическом режиме или режиме «foreach », если он снабжен двумя или более входными компонентами после автоматической подготовки. Это поведение поддерживается во время разработки, когда структура списка данных из одной службы подключена к службе, которая принимает единственную структуру данных (т. Е. Не множественное число) в качестве входных данных. Если свойство времени выполнения интерфейса составной службы объявлено для поддержки «foreach» в параллельном режиме, тогда среда автоматизации времени выполнения может автоматически выполнять многопоточность цикла и запускать его параллельно. Это пример того, как программные конструкции SOP обеспечивают встроенную расширенную функциональность.
Отображение данных, конструкции преобразования и преобразования позволяют автоматически передавать данные между внутренними службами. Внутренняя служба готова к запуску, когда она активирована и все ее входные зависимости разрешены. Все подготовленные внутренние службы в составе составной службы запускаются в параллельном пакете, называемом «гиперциклом». Это одно из средств поддержки автоматической параллельной обработки в SOP. Определение составной службы содержит неявный ориентированный граф зависимостей внутренних служб. Среда выполнения для SOP может создать граф выполнения на основе этого ориентированного графа путем автоматического создания экземпляров и параллельного запуска внутренних служб, когда это возможно.
Обработка исключений - это ошибка времени выполнения в Java. Обработка исключений в SOP просто выполняется путем подключения порта отказа внутренних служб к другой внутренней службе или к программной конструкции. Конструкции «Выход с ошибкой» и «Выход с успехом» являются примерами конструкций, используемых для обработки исключений. Если на порте отказа службы не будет предпринято никаких действий, тогда внешняя (родительская) служба автоматически завершится с ошибкой, а стандартные выходные сообщения от отказавшей внутренней службы автоматически перейдут в стандартный вывод родительской службы.
Составная служба может быть объявлена как граница транзакции. Среда выполнения для SOP автоматически создает и управляет иерархическим контекстом для объектов составных служб, которые используются в качестве границы транзакции. Этот контекст автоматически фиксируется или откатывается после успешного выполнения составной службы.
Специальные комбинированные услуги, называемые компенсационными услугами, могут быть связаны с любой услугой в рамках СОП. Когда составная служба, объявленная как граница транзакции, выходит из строя без маршрутизации обработки исключений, среда выполнения SOP автоматически отправляет службы компенсации, связанные со всеми внутренними службами, которые уже были успешно выполнены.
Атомарная служба - это расширение в памяти среды выполнения SOP через собственный интерфейс службы (SNI). По сути, это механизм подключаемого модуля. Например, если SOP автоматизирован с помощью, подключаемый модуль службы динамически загружается в SVM при использовании любой связанной службы. Примером подключаемого модуля службы может быть подключаемый модуль коммуникатора SOAP, который может на лету преобразовывать любые входные данные службы в памяти в запрос SOAP веб-службы и отправлять его производителю службы., а затем преобразовать соответствующий ответ SOAP в выходные данные в памяти службы. Другой пример подключаемого модуля службы - это стандартный подключаемый модуль SQL базы данных, который поддерживает операции доступа к данным, их изменения и запросов. Еще один пример, который может помочь установить фундаментальную важность атомарных служб и подключаемых модулей служб, - это использование инициатора службы в качестве подключаемого модуля службы для прозрачной виртуализации служб в различных экземплярах платформы SOP. Эта уникальная виртуализация на уровне компонентов называется «виртуализация сервисной сети», чтобы отличать ее от традиционных приложений или виртуализации на уровне процессов .
СОП предоставляет значительные возможности для поддержки сквозные проблемы для всех приложений, созданных с использованием техники SOP. В следующих разделах описаны некоторые из этих возможностей:
Среда выполнения SOP может систематически обеспечивать встроенное и оптимизированное профилирование, ведение журнала и измерение для всех служб в режиме реального времени.
На основе объявленных ключевых входных значений экземпляра службы выходные данные не зависимой от времени внутренней службы могут кэшироваться средой выполнения SOP при запуске в контексте конкретной составной услуги. Когда служба кэширована для определенных ключевых входных значений, среда выполнения SOP извлекает кэшированные выходные данные, соответствующие введенным по ключу входам, из своего кэша службы вместо использования службы. Доступность этого встроенного механизма для разработчика SOP-приложения может значительно снизить нагрузку на серверные системы.
SOP предоставляет механизм для связывания особого вида составной службы, службы триггера, с любой другой службой. Когда эта служба потребляется, платформа SOP автоматически создает и использует экземпляр связанной службы запуска с копией в памяти входных данных службы запуска. Это потребление не влияет на выполнение запускающей службы. Можно объявить, что триггер службы запускается после активации, сбоя или успешного завершения службы запуска.
Помимо возможности вызова любой службы, события запроса на обслуживание и общая память - это два встроенных механизма СОП, обеспечивающих связь между службами. Потребление услуги рассматривается как событие в СОП. SOP предоставляет основанный на корреляции механизм событий, который приводит к упреждению работающей композиции, которая с помощью конструкции «ожидания» объявила необходимость дождаться одного или нескольких других событий потребления службы с указанными значениями входных данных. Выполнение составной службы продолжается, когда службы потребляются с определенными входными ключами корреляции, связанными с конструкцией ожидания. SOP также предоставляет пространство разделяемой памяти с контролем доступа, где службы могут получать доступ и обновлять четко определенную структуру данных , аналогичную структуре ввода / вывода служб. Доступ к механизму разделяемой памяти в SOP можно получить программно через сервисные интерфейсы.
В SOP настройками управляют с помощью изобретательной функции, называемой «Переопределения службы». Благодаря этой функции реализация службы может быть статически или динамически переопределена одной из многих возможных реализаций во время выполнения. Эта функция аналогична полиморфизму в объектно-ориентированном программировании. Каждую возможную реализацию переопределения можно связать с одним или несколькими портфелями конфигурации переопределения, чтобы управлять активацией групп связанных переопределений в различных установках приложения SOP во время развертывания.
Выбрать службы могут быть безопасно развернуты для внешнего программного потребления с помощью уровня представления (GUI ) или других приложений. После определения учетных записей служб среда выполнения SOP автоматически управляет доступом с помощью механизмов обеспечения учетной записи пользователя .
Среда выполнения SOP может систематически обеспечивать встроенную аутентификацию и авторизацию службы . В целях авторизации проекты разработки СОП, пользовательские учетные записи, пакеты и услуги рассматриваются как ресурсы с контролем доступа. Таким образом, среда выполнения SOP может обеспечить встроенную авторизацию. Стандарты или проприетарная авторизация и безопасность связи настраиваются с помощью переопределений служб, подключаемых модулей вызова и прослушивания служб.
Поскольку все артефакты SOP представляют собой хорошо инкапсулированные службы, и все механизмы SOP, такие как разделяемая память, могут быть предоставлены как распределенные службы, крупномасштабная виртуализация может быть автоматизирована средой выполнения СОП. Кроме того, иерархический стек сервисов составного сервиса с множественными графами исполнения, связанными с его внутренними сервисами на каждом уровне, предоставляет огромные возможности для автоматизированной многопоточности в среде выполнения SOP.
Термин сервис-ориентированное программирование впервые был опубликован в 2002 году Альберто Силлитти, Туллио Вернацца и Джанкарло Суччи в книге «Повторное использование программного обеспечения: методы, методы и инструменты». СОП, как описано выше, отражает некоторые аспекты использования термина, предложенного Силлитти, Вернацца и Суччи.
Сегодня парадигма СОП находится на ранней стадии широкого распространения. Есть четыре рыночных движущих фактора, способствующих этому принятию:
