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

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

Введение

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

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

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

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

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

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

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

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

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

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

Сервисный интерфейс

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

В SOP свойства среды выполнения, хранящиеся в метаданных интерфейса службы, служат в качестве контракта с виртуальной машиной службы (SVM). Одним из примеров использования свойств времени выполнения является то, что в декларативной службе синхронизация. Интерфейс службы может быть объявлен как полностью синхронизированный интерфейс, что означает, что в любой момент времени может работать только один экземпляр этой службы. Или он может быть синхронизирован на основе фактического значения ключевых входных данных во время выполнения, что означает, что никакие два экземпляра службы этой службы с одинаковым значением для своих ключевых входных данных не могут работать одновременно. Кроме того, синхронизация может быть объявлена ​​для интерфейсов служб, принадлежащих одной группе служб. Например, если две службы, «CreditAccount» и «DebitAccount», принадлежат одной группе служб синхронизации и синхронизируются в поле ввода accountName, то два экземпляра «CreditAccount» и «DebitAccount» с одинаковым именем учетной записи не могут выполняться. в то же время.

Вызов службы

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

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

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

Внедрение услуги

В SOP сервисный модуль может быть реализован как составной или атомарный сервис. Важно отметить, что сервисные модули, построенные с помощью парадигмы СОП, имеют экстравертный характер и могут быть прозрачно экстернализованы с помощью таких стандартов, как МЫЛО или любой проприетарный протокол.

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

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

Внедрение сервиса: составной сервис

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

Программные конструкции

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

Последовательность действий

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

Выбор

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

Итерация

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

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

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

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

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

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

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

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

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

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

Атомарная служба - это расширение в памяти среды выполнения SOP через собственный интерфейс службы (SNI). По сути, это подключаемый механизм. Например, если СОП автоматизирован через SVM подключаемый модуль службы динамически загружается в SVM при использовании любой связанной службы. Примером подключаемого модуля службы может быть МЫЛО подключаемый модуль коммуникатора, который может на лету преобразовывать любые входные данные службы в памяти в запрос SOAP веб-службы, отправлять его поставщику службы, а затем преобразовывать соответствующий ответ SOAP в выходные данные службы в памяти. Другой пример подключаемого модуля службы - это стандартный подключаемый модуль SQL базы данных, который поддерживает операции доступа к данным, их изменения и запросов. Еще один пример, который может помочь установить фундаментальную важность атомарных служб и подключаемых модулей служб, - это использование инициатора службы в качестве подключаемого модуля службы для прозрачной виртуализации служб в различных экземплярах платформы 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 способствует встроенному микроконтролю над прозрачностью местоположения компонентов услуги любого модуля услуги. Это приводит к автоматическому и детальному виртуализация компонентов приложения (по сравнению со всем процессом приложения) через кластер или сетка рабочих платформ СОП.
  • Сервис-Ориентированная Архитектура (SOA) и спрос на интегрированные и составные приложения: вначале внедрение SOP будет следовать кривой принятия SOA с небольшим отставанием. Это связано с тем, что сервисы, созданные с помощью SOA, можно легко собрать и использовать с помощью SOP. Чем больше веб-сервисов разрастается, тем больше смысла использовать семантическую природу СОП. С другой стороны, поскольку SOA является неотъемлемой частью SOP, SOP обеспечивает рентабельный способ доставки SOA на основные рынки.
  • Программное обеспечение как сервис (SaaS): возможности текущих платформ SaaS не могут решить проблемы настройки и интеграции, необходимые для крупных предприятий. СОП может значительно снизить сложность интеграции и настройки. Это приведет к внедрению СОП в платформы SaaS следующего поколения.

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