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

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

Вступление

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

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

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

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

Основные концепции

Концепции СОП обеспечивают прочную основу для семантического подхода к интеграции программирования и логике приложений. У этого подхода есть три существенных преимущества:

  • Семантически он может повысить уровень абстракции для создания составных бизнес-приложений и, таким образом, значительно повысить скорость реакции на изменения (т. Е. Гибкость бизнеса ).
  • Дает повод для объединения методов интеграции и разработки программных компонентов в рамках единой концепции и, таким образом, значительно снижает сложность интеграции. Этот унифицированный подход обеспечивает «внутреннюю интеграцию» без необходимости репликации данных, что значительно снижает стоимость и сложность всего решения.
  • Автоматизируйте многопоточность и виртуализацию приложений на гранулярном (единичном) уровне.

Ниже приведены некоторые из ключевых концепций СОП:

Инкапсуляция

В 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, с входами и выходами, которые могут принимать форму входа / выхода других подключенных сервисов. Например, настраиваемая конструкция, используемая для фильтрации выходных данных служб, может принимать список заказов на продажу, заказов на покупку или любую другую структуру данных и фильтровать свои данные на основе объявленных пользователем свойств фильтра, хранящихся в интерфейсе этого экземпляра конструкции фильтра. . В этом примере структура, которая должна быть отфильтрована, становится входом конкретного экземпляра конструкции фильтра, а та же самая структура, представляющая отфильтрованные данные, становится выходом конфигурируемой конструкции.

Итерация

Составную службу можно объявить в виде цикла. Цикл может быть связан фиксированным числом итераций с необязательной встроенной задержкой между итерациями, и он может динамически завершаться с помощью конструкции «успешный выход из службы» или «выход из службы с ошибкой» внутри циклической составной службы. Более того, любой интерфейс службы может автоматически запускаться в режиме цикла или « 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 настройками управляют с помощью изобретательной функции под названием Service Overrides. Благодаря этой функции реализация службы может быть статически или динамически переопределена одной из многих возможных реализаций во время выполнения. Эта функция аналогична полиморфизму в объектно-ориентированном программировании . Каждую возможную реализацию переопределения можно связать с одним или несколькими портфелями конфигурации переопределения, чтобы управлять активацией групп связанных переопределений в различных установках приложения SOP во время развертывания .

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

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

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

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

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

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

История

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

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

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

Смотрите также

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