Сервис ориентированная архитектура реферат

Обновлено: 05.07.2024

Ознакомьтесь с SOA (сервис-ориентированной архитектурой) — важной вехой в эволюции разработки и интеграции приложений.

Что такое SOA (сервис-ориентированная архитектура)?

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

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

Таким образом, SOA представляет собой важную веху в эволюции разработки и интеграции приложений за последние несколько десятилетий. До появления SOA в конце 1990-х годов задача подключения приложений к данным и функциям из других систем предусматривала применение сложной двухточечной интеграции, которую разработчикам приходилось заново создавать (частично или полностью) в рамках каждого нового проекта разработки. Предоставление доступа к этим функциям с помощью SOA позволяет избавиться от необходимости каждый раз заново создавать глубокую интеграцию.

Обратите внимание, что SOA часто сравнивают с более современной архитектурой микросервисов, однако они слабо связаны друг с другом и работают на разных уровнях, как будет показано далее в этой статье.

Что такое ESB?

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

Теоретически, SOA можно реализовать без применения ESB, однако владельцы приложений вынуждены были бы искать уникальные способы предоставления доступа к интерфейсам — это очень трудоемкая задача (даже в случае многоразовых интерфейсов), которая к тому же значительно усложнит обслуживание в будущем. Фактически, в итоге ESB стали рассматриваться в качестве неотъемлемого элемента любой реализации SOA и эти термины часто использовались как синонимы, что вызывало путаницу.

Преимущества SOA

SOA предлагает существенные преимущества по сравнению с предшествующими архитектурами:

Примеры SOA

Уже в 2010 году реализации SOA активно использовались передовыми компаниями практически в каждой отрасли. Например:

  • Компания Delaware Electric внедрила SOA для интеграции систем, которые раньше не взаимодействовали друг с другом. В результате компании удалось повысить эффективность разработки и остаться на плаву во время пятилетней заморозки тарифов на электроэнергию.
  • Cisco использовала SOA, чтобы согласовать процесс заказа всех продуктов по всем каналам. Для этого подразделениям, дочерним компания и бизнес-партнерам Cisco были предложены сервисы, с помощью которых они могли добавить процессы заказа на свои веб-сайты.
  • Страховая компания Independence Blue Cross (IBC) из Филадельфии внедрила SOA, чтобы предоставить заинтересованным лицам — агентам IBC по обслуживанию клиентов, больницам и пользователям веб-сайта IBC — единый источник достоверных данных о пациентах.

SOA и микросервисы

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

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

Архитектура микросервисов появилась и получила широкое распространение на фоне растущей популярности виртуализации, облачных вычислений, гибких методик разработки и DevOps. Большая часть преимуществ микросервисов в этих контекстах связана с полным отделением компонентов, в результате которого упрощаются и улучшаются следующие процессы:

  • Гибкость и продуктивность работы разработчиков: используя микросервисы, разработчики могут встраивать новые технологии в одну часть приложения, не затрагивая при этом остальное приложение. Изменение, тестирование и развертывание отдельных компонентов можно выполнять независимо от других компонентов, сократив при этом итерационные циклы.
  • Масштабируемость: микросервисы позволяют получить максимальную отдачу от масштабируемости облачных сред — любой компонент можно масштабировать независимо от остальных компонентов, обеспечивая при этом максимально быстрое реагирование на изменения нагрузки и наиболее эффективное использование вычислительных ресурсов.
  • Устойчивость: и снова благодаря отделению сбой одного микросервиса никак не сказывается на работе других. Каждый микросервис может работать в соответствии с собственными требованиями к доступности, не ограничивая другие компоненты или приложение в целом.

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

SOA и IBM Cloud

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

Сделайте следующий шаг:

  • Откройте каналы взаимодействия с клиентами, поставщиками и партнерами с помощью IBM Cloud Pak for Integration.
  • Узнайте, как объединить все приложения и данные из нескольких частных и общедоступных облачных сред и обеспечить персонализированное взаимодействие с клиентами, посетив домашнюю страницу IBM Cloud Integration.

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


Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:

  • Сочетаемость приложений, ориентированных на пользователей.
  • Многократное использование бизнес-сервисов.
  • Независимость от набора технологий.
  • Автономность (независимые эволюция, масштабируемость и развёртываемость).

SOA — это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.

В этой статье я рассмотрю следующие паттерны, относящиеся к SOA:

Общая архитектура брокера объектных запросов (CORBA)

В 1980-х началось активное использование корпоративных сетей и клиент-серверной архитектуры. Возникла потребность в стандартном способе взаимодействия приложений, которые созданы с использованием разных технологий, исполняются на разных компьютерах и под разными ОС. Для этого была разработана CORBA. Это один из стандартов распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.

Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:

  • Не зависящие от платформы вызовы удалённых процедур (Remote Procedure Call).
  • Транзакции (в том числе удалённые!).
  • Безопасность.
  • События.
  • Независимость от выбора языка программирования.
  • Независимость от выбора ОС.
  • Независимость от выбора оборудования.
  • Независимость от особенностей передачи данных/связи.
  • Набор данных через язык описания интерфейсов (Interface Definition Language, IDL).

Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE, хотя начиная с Java 9 будет поставляться в виде отдельного модуля.

Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.

Принцип работы


Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.

Достоинства

  • Независимость от выбранных технологий (не считая реализации ORB).
  • Независимость от особенностей передачи данных/связи.

Недостатки

Веб-сервисы

И для решения этих задач в конце 1990-х начали появляться веб-сервисы.

[Веб-]сервисы можно публиковать, находить и использовать стандартным образом вне зависимости от технологий.
— Microsoft 2004, Understanding Service-Oriented Architecture


С точки зрения технологий SOA не просто сервисная архитектура, а набор политик, методик и фреймворков, благодаря которым мы предоставляем и получаем нужные сервисы.
— Microsoft 2004, Understanding Service-Oriented Architecture

Достоинства

Недостатки

Запрос/Ответ


Все эти паттерны можно отнести к либо к pull- (polling), либо к push-подходу:

Достоинства

Недостатки

Сервисная шина предприятия (ESB)

Сервисная шина предприятия использовала веб-сервисы уже в 1990-х, когда они только развивались (быть может, некоторые реализации сначала использовали CORBA?).


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

Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.


Главные обязанности ESB:

Также рекомендую не забывать, что реализации ESB уже достаточно развиты и в большинстве случаев позволяют использовать для своего конфигурирования пользовательский интерфейс с поддержкой drag & drop.

Достоинства

Недостатки

  • Ниже скорость связи, особенно между уже совместимыми сервисами.
  • Централизованная логика:
    • Единая точка отказа, способная обрушить системы связи всей компании.
    • Большая сложность конфигурирования и поддержки.
    • Со временем можно прийти к хранению в ESB бизнес-правил.
    • Шина так сложна, что для её управления вам потребуется целая команда.
    • Высокая зависимость сервисов от ESB.

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

    В основе микросервисной архитектуры лежат концепции SOA. Назначение у неё то же, что и у ESB: создать единое общее корпоративное приложение из нескольких специализированных приложений бизнес-доменов.

    Главное различие микросервисов и шины в том, что ESB была создана в контексте интеграции отдельных приложений, чтобы получилось единое корпоративное распределённое приложение. А микросервисная архитектура создавалась в контексте быстро и постоянно меняющихся бизнесов, которые (в основном) с нуля создают собственные облачные приложения.

    Характер построения/проектирования микросервисов не требует глубокой интеграции. Микросервисы должны соответствовать бизнес-концепции, ограниченному контексту. Они должны сохранять своё состояние, быть независимыми от других микросервисов, и потому они меньше нуждаются в интеграции. То есть низкая взаимозависимость и высокая связность привели к замечательному побочному эффекту — уменьшению потребности в интеграции.

    [Микросервисы — это] маленькие автономные сервисы, работающие вместе и спроектированные вокруг бизнес-домена.
    — Sam Newman 2015, Principles Of Microservices

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

    Сэм Ньюман, автор Building Microservices, выделяет восемь принципов микросервисной архитектуры. Это:

    • Проектирование сервисов вокруг бизнес-доменов
      Это может дать нам стабильные интерфейсы, высокосвязные и мало зависящие друг от друга модули кода, а также чётко определённые разграниченные контексты.
    • Культура автоматизации
      Это даст нам гораздо больше свободы, мы сможем развернуть больше модулей.
    • Скрытие подробностей реализации
      Это позволяет сервисам развиваться независимо друг от друга.
    • Полная децентрализация
      Децентрализуйте принятие решений и архитектурные концепции, предоставьте командам автономность, чтобы компания сама превратилась в сложную адаптивную систему, способную быстро приспосабливаться к переменам.
    • Независимое развёртывание
      Можно развёртывать новую версию сервиса, не меняя ничего другого.
    • Сначала потребитель
      Сервис должен быть простым в использовании, в том числе другими сервисами.
    • Изолирование сбоев
      Если один сервис падает, другие продолжают работать, это делает всю систему устойчивой к сбоям.
    • Удобство мониторинга
      В системе много компонентов, поэтому трудно уследить за всем, что в ней происходит. Нам нужны сложные инструменты мониторинга, позволяющие заглянуть в каждый уголок системы и отследить любую цепочку событий.


    Сообщество предпочитает другой подход: умные конечные точки и глупые каналы. Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными — они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. Они оркестрируются с помощью простых REST-подобных протоколов, а не сложных протоколов вроде WS-Choreography или BPEL либо какого-то централизованного инструмента.
    — Martin Fowler 2014, Microservices

    Достоинства

    Недостатки

    Антипаттерн: архитектура равиоли (Ravioli Architecture)


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

    Заключение

    В последние десятилетия SOA сильно эволюционировала. Благодаря неэффективности прежних решений и развитию технологий сегодня мы пришли к микросервисной архитектуре.

    Эволюция шла по классическому пути: сложные проблемы разбивались на более мелкие, простые в решении.

    Проблему сложности кода можно решать так же, как мы разбиваем монолитное приложение на отдельные доменные компоненты (разграниченные контексты). Но с разрастанием команд и кодовой базы увеличивается потребность в независимом развитии, масштабировании и развёртывании. SOA помогает добиться такой независимости, упрочняя границы контекстов.


    Повторюсь, что всё дело в слабой взаимозависимости и высокой связности, причём размер компонентов должен быть больше прежнего. Необходимо прагматично оценить свои потребности: используйте SOA, лишь когда это необходимо, поскольку она сильно увеличивает сложность. И если на самом деле вы можете обойтись без SOA, то лучше выберите микросервисы подходящего размера и количества, не больше и не меньше.

    Клиент-серверные архитектуры. Базы данных, SQL. Распределенные архитектуры, Active Directory, ASP, CGI. OC– Nowell Netware, Microsoft, Unix.

    Сложность ПО растет. Необходима интеграция различных решений. Ответ SOA

    Сервис ориентированная архитектура (service-oriented architecture - SOA) - принципы построения корпоративной программной инфраструктуры, позволяющий разным приложениям обмениваться данными и процессами независимо от ОС, на которых они исполняются, и языков программирования, на которых они написаны. В такой модели приложение или часть приложения называется сервисом. Другое приложение, или потребитель сервиса, может его найти и вызвать. Доступ выполняется через локальную сеть или Интернет. Таким образом, SOA — это не продукт и даже не технология, а концепция создания и интеграции отдельных корпоративных приложений.

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

    Все сервисы независимы друг от друга.Они выполняют определенные действия по запросам, полученным от других сервисов, и возвращают результаты. Все детали этого полностью скрыты: в концепции SOA сервисы - это "черные ящики".

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

    1 Лекция 3 40 Сервис-ориентированная архитектура Сервис-ориентированная архитектура (СОА, Service-Oriented Architecture SOA) это парадигма организации и использования распределенных возможностей, которые могут принадлежать различным владельцам. СОА это модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам. Типичные составляющие СОА: сервисные компоненты (сервисы); контракты сервисов (интерфейсы); соединители сервисов (транспорт); механизмы обнаружения сервисов (регистры).

    3 Соединитель сервисов (или транспорт) обеспечивает обмен информацией между отдельными сервисными компонентами. Наряду с открытыми стандартами описания интерфейсов, использование гибких транспортных протоколов для обмена информацией между сервисными компонентами позволяет повысить программную совместимость сервисориентированной системы. Механизмы обнаружения сервисов (или регистры сервисов) используются для поиска сервисных компонентов, обеспечивающих требуемую функциональность. Выделяют 2 основных категории систем обнаружения: статические системы обнаружения сервисов (например, UDDI) ориентированы на хранение информации о сервисах в редко изменяющихся системах; динамические системы обнаружения сервисов ориентированы на системы, в которых допустимо частое появление и исчезновение сервисных компонентов. 42

    4 Связанность программных систем 43 Связанностью называют степень знания и зависимости одного объекта от внутреннего содержания другого. Программные системы можно разделить на 2 типа: сильносвязанные системы (Strong coupling): зависимый класс содержит ссылку непосредственно на определенный класс, предоставляющий некоторые возможности (примеры: Java RMI, NET Remoting); слабосвязанные системы (Loose coupling): зависимый класс содержит ссылку на интерфейс который может быть реализован одним или несколькими конкретными классами (пример: СОА). Основная цель использования концепции слабосвязанных программных систем это уменьшение количества зависимостей между компонентами. При уменьшении количества связей, уменьшается объем возможных последствий, возникающих в связи со сбоями или системными изменениями. Традиционный подход разработки распределенных приложений, поддерживаемый технологиями распределенных объектов, основывается на тесной связи между всеми программными компонентами. Слабосвязанность

    5 программных компонентов, поддерживаемая технологией веб-сервисов, позволяет значительно упростить координацию распределенных систем и их реконфигурацию. 44 Физические соединения Стиль взаимодействий Сравнение сильносвязанных и слабосвязанных систем Сильносвязанные системы Точка-точка Синхронные Слабосвязанные системы Через посредника Асинхронные Модель данных Общие сложные типы Простые типы Связывание Статическое Динамическое Платформа Сильная зависимость от базовой платформы Независимость от платформы Развертывание Одновременное Постепенное

    8 уровня, что и изменяемый, равно как и компонентов более низкого и более высокого уровня. Например, известный веб-сервис Google Translate постоянно претерпевает изменения. Изначально, он обеспечивал только веб-интерфейс для перевода и ограниченный набор языков. Постепенно увеличивались функциональные возможности сервиса: расширялся набор языков, появилась возможность голосового воспроизведения перевода, при переводе отдельного слова начали выдаваться словарные статьи с несколькими результатами перевода и т. п. При этом API (Application Programming Interface) и интерфейс менялся незначительно. Рекурсивность. Однотипные решения имеют место на различных уровнях архитектуры. 47

    9 Подход СОА 48 С точки зрения информационных технологий, логика предприятия может быть разделена на: бизнес-логику (БЛ) и логику приложения (ЛП). Бизнес-логика документальная реализация бизнестребований, которые исходят из проблемной области, в которой работает предприятие. БЛ, как правило, структурирована в процессах, которые выражают эти требования, а также ограничениях и зависимости от Рисунок 15 Уровни логики предприятия внешних влияний. Логика приложения это реализация БЛ, организованная на основе различных технологических решений. ЛП выражает процессы БЛ посредством приобретенных или специально разработанных программных систем в условиях ограниченных технических возможностей и зависимостей от поставщика решения

    13 наибольшей совместимости должны обладать необходимым уровнем детализации. 6. Сервисы должны быть автономными. Свойство автономности требует, чтобы область бизнес-логики и ресурсов, используемых сервисом были ограничены явными пределами. Это позволяет Рисунок 16 Сервисы, используемые в качестве элементов другого сервиса сервису самому управлять всеми своими процессами. Также это устраняет зависимость от других сервисов, что освобождает сервис от связей, которые могут препятствовать его применению и развитию. Вопрос автономности наиболее важный аргумент при распределении бизнес-логики на отдельные сервисы. 52

    16 8. Сервисы должны поддерживать обнаружение. Обнаружение сервисов позволяет избежать случайного создания избыточного сервиса, обеспечивающего избыточную логику. Метаданные сервиса должны подробно описать не только общую цель сервиса, но и функциональность, реализуемую его операциями. На уровне СОА, обнаружение характеризует способность архитектуры обеспечить механизмы поиска, такие как реестр или каталог. На уровне сервиса, принцип обнаружения относится к процессу проектирования отдельного сервиса, так чтобы данный сервис настолько подавался обнаружению, насколько это возможно. 55

    17 56 Совместимость с другими сервисами Слабосвязанность Автономность Повторное использование Сервис Поддержка обнаружения Контракт использования Скрытая внутренняя логика Неиспользование информации о состоянии Рисунок 18 Свойства сервисов согласно подходу СОА

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

    Ключевые слова

    Текст научной работы

    Сервис-ориентированная архитектура имеет следующие ключевые характеристики:

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

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

    WSDL, UDDI и SOAP — это фундаментальные части SOA-инфраструктуры. WSDL используется для описывания сервисов, UDDI для регистрации и поиска сервисов, протокол SOAP — как способ формирования данных между потребителем и провайдером сервиса, используемый по умолчанию. Таким образом, потребитель сервиса имеет возможность найти нужный сервис в реестре UDDI, получить WSDL, описывающий этот сервис и, наконец, вызвать этот сервис, используя SOAP протокол.

    WS-I Basic Profile, разработанный и сопровождаемый Web services Interoperability Organization, является другой важной частью, необходимой для тестирования сервисов и их взаимодействия. Поставщики сервисов могут использовать Basic Profile для тестирования совместимости сервиса на различных платформах и технологиях.

    Существуют критические значимые внутренние системы на предприятиях, которые используются для поддержания таких требований, как безопасность и надежность. Предприятия применяют SOA как средство разработки и развертывания приложения, и базовые составляющие веб-сервисов, такие как WSDL, UDDI и SOAP не могут удовлетворить этим повышенным требованиям. Как было упомянуто выше, эти требования являются частью QoS. Многочисленные определения, относящиеся к QoS, разрабатываются в таких организациях по стандартизации, как W3C.

    Если предприятие решает использовать SOA, то сервисы могут быть интегрированы для структурирования разрозненных данных и приложений. Интеграция приложения означает, что требования процесса, такие как асинхронное взаимодействие, параллельные вычисления, трансформация данных должны быть приведены к единому виду. BPEL4WS или WSBPEL (Web Services Business Process Execution Language) — это определение, которое является частью оркестрации сервисов. Предприятия, использующие сервис-ориентированную архитектуру в своей ИТ-инфраструктуре, имеют возможность создавать монолитные приложения, используя набор уже существующих приложений, которые предоставляют свои функциональные возможности через собственные интерфейсы ввода/вывода данных.

    По мере увеличения на предприятии количества сервисов и бизнес-процессов, управление инфраструктурой позволяет системному администратору управлять запуском сервисов в неоднородном окружении, что является крайне важным. Web Services for Distributed Management (WSDM) определяет, что любые сервисы, реализованные в соответствии со специальным стандартом, могут управляться специализированным совместимым решением вручную.

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

    Если смотреть на бизнес-процесс с технической точки зрения, то составляющие его элементы можно разделить на следующие:

    Хотя концепция SOA принципиально не нова, SOA отличается от существующих альтернатив [3] тем, что большинство поставщиков программного обеспечения одобрило и приняло эту концепцию и имеет в своем распоряжении платформенные ресурсы для использования SOA. С повсеместным набором стандартов, SOA дает лучший вариант последующего использования единожды выполненных инвестиций предприятия и позволяет создавать новые приложения, которые могут быть построены из сторонних приложений, новых или разработанных ранее и другими компаниями. SOA позволяет изменять приложения, не затрагивая при этом потребителей сервисов, которые застрахованы от неожиданных изменений в реализации сервисов. SOA позволяет модернизировать отдельные сервисы, избавляя от необходимости полностью переписывать приложение или пользоваться приложением, которое больше не удовлетворяет требованиям бизнеса. И наконец, SOA обеспечивает предприятиям большую гибкость в разработке приложений и бизнес-процессов, используя существующую инфраструктуру для совмещения новых сервисов с уже имеющимися.

    Не стоит также забывать, что в сервис-ориентированных архитектурах должны быть спроектированы сервисы системы безопасности [1, 2, 4].

    Список литературы

    Цитировать

    Читайте также: