Сервис-ориентированная архитектура (SOA): опыт внедрения. Сервис-ориентированная архитектура

SOA Архитектурные особенности и практические аспекты

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

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

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

• Сервисы жизненного цикла. Эти сервисы являются своего рода «обёрткой», которая в большинстве случаев поставляет ИТ-пользователям «настояшие сервисы». Сервисы жизненного цикла отвечают за дизайн, внедрение, управление, изменение сервисов инфраструктуры и бизнес-функций.

Мировой рынок SOA

Средняя стоимость СОА-проекта оценивается AMR Research примерно в 500 тыс. долл. При этом крупные платформы, которые являются полнофункциональным инструментом для ведения бизнеса, представляют на рынке всего несколько фирм – IBM, Oracle, Tibco, Sun Microsystems, Software AG, Microsoft, SAP AG. Читать статью “SOA (мировой рынок)”

Российский рынок SOA

Сегодня на российском рынке есть несколько частично открытых SOA-продуктов, а ведущие разработчки ERP-систем, таких как SAP и Oracle обещают уже в этом (2009) году оснастить их библиотеками SOA-решений. Некоторые российские разработчики («1C», «Диасофт» и др.) также объявили, что сделали свои продукты SOA-открытыми. Читать статью “SOA (рынок России)”

Развитие SOA

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

Своего рода предшественницей SOA стала технология Enterprise Service Bus, предоставлявшая унифицированный механизм взаимодействия приложений.

Дополненная рядом других технологий, ESB позволила сформировать единую интеграционную платформу.

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

Тренд оказался настолько удачным и привлекательным, что моментально был взят на вооружение маркетологами. Ярлык 2.0 появился на многих программных решениях и в большинстве случаев его использование весьма спорно.

Такой всеобщей тенденции не удалось избежать и сервисно-ориентированной архитектуре. Читать статью “SOA 2.0”

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

Связь между сервисно-ориентированными и объектно-ориентированными структурами

Появление сервисно-ориентированного подхода произвело очередную реформу в теории разработки программного обеспечения, оставив в прошлом концепцию объектно-ориентированного программирования.

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

В парадигме ООП от разработчика требуется знание прикладного программного интерфейса, в котором объединены атрибуты и методы, сообща реализующие необходимый функционал. Но поскольку объектные системы обычно создаются на основе какого-то одного языка программирования (Delphi, C Яык программирования++, C Яык программирования#, Java и др.

) и фиксированных механизмов обмена информацией между объектами и модулями информационной системы, то и в ООП сохраняются все зависимости и ограничения. Такой подход удобен не всегда — в частности, он не позволяет оперативно реагировать на изменение ситуации и, к примеру, проектировать новомодные системы, опирающиеся на концепцию «ресурсы по требованию».

Кроме того, для модификации объектных систем нередко приходится переписывать коды связанных объектов и методов.

Cвести эти ограничения к минимуму позволяет технология SOA, которая многими уже признана как революция в технологии программирования.

Аналитики о сервисно-ориентированной архитектуре

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

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

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

Архитектурные особенности SOA

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

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

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

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

Архитектура веб-сервисов также является сервисно-ориентированной.

Более того, веб-сервисы — это суть SOA c двумя дополнительными ограничениями: интерфейсы базируются на интернет-протоколах (HTTP, FTP, SMTP Simple Mail Transfer Protocol – Простой протокол передачи почты, TCP), а все сообщения описываются в формате XML. Детальные описания стандарта веб-сервисов и спецификаций SOA приводятся на сайтах консорциума W3C и организации OASIS.

Практические аспекты применения SOA

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

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

Конечно, SOA-проект можно строить только на основных механизмах (механизме) поддержки, однако зрелый проект подразумевает больший уровень поддержки с ростом уровня ответственности, которая ложится на SOA-проект.

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

Вот шесть механизмов, с помощью которых поддерживается SOA-политика:

• Операционная модель жизненного цикла SOA
• Организация SOA
• SOA-процесс
• Портфель активов для сервисной интеграции в SOA
• Инструментарий SOA
• SOA-технологии

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

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

Второй подход – «снизу вверх» – соответственно подразумевает «тактическое управление», которое, наоборот, строит SOA-проект на основе создаваемых технологий, инструментов и сервисов. Большинство предприятий идет по пути «снизу вверх», начиная с конкретных сервис-ориентированных шагов, направленных на определённые предметные области.

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

Ссылки

Источник: http://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:SOA_%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BD%D1%8B%D0%B5_%D0%BE%D1%81%D0%BE%D0%B1%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D0%B8_%D0%BF%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D0%B0%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D1%8B

Журнал ВРМ World

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

Значение SOA

По словам Клива Финкельштейна (Clive Finkelstein), автора инфотехники(information engineering), до появления концепции SOA при разработке систем вкачестве отправного момента для программирования бизнес-логики использовалисьдиаграммы рабочих потоков и блок-схемы систем. Разработанные вручную программытщательно тестировались, после чего внедрялись.

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

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

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

Сервис-ориентированная архитектура: основные понятия

Очень часто становление того или иного подхода сопровождается появлениемневерных или ошибочных трактовок, как это было, например, с концепциейфедеративного Хранилища данных.

Не миновала “сия чаша” и сервис-ориентированнуюархитектуру. Так, по крайне мере, считает представитель компании BEA ДжеримиУэстерман (Jeremy Westerman).

Именно поэтому в одной из своих статей,посвященных SOA, он специально останавливается на “проблемных местах” иприводит подробные пояснения:

1. SOA не является чем-то новым: IT-отделы компаний успешно создавали иразвертывали приложения, поддерживающие сервис-ориентированную архитектуру, ужемного лет – задолго до появления XML и Web-сервисов.
2. SOA – это не технология, а способ проектирования и организацииинформационной архитектуры и бизнес-функциональности.
3. Покупка самых новых продуктов, реализующих XML и Web-сервисы, не означаетпостроения приложений в соответствии с принципами SOA.

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

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

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

SOA “подталкивает” к использованию альтернативных технологий и подходов(таких как обмен сообщениями) для построения приложений посредством связываниясервисов, а не посредством написания нового программного кода.

В этом случае,при надлежащем проектировании, применение сообщений позволяет компаниямсвоевременно реагировать на изменение рыночных условий – “настраивать” процессобмена сообщениями, а не разрабатывать новые приложения.

Слова Джерими Уэстермана в определенной степени перекликаются с точкойзрения Клива Финкельштейна. “Родоначальник инфотехники” сетует, что до недавнихпор термин “сервис-ориентированная архитектура” был синонимом “Web-сервис”.

Клив Финкельштейн определяет SOA следующим образом – вызов Web-сервисов спомощью средств и языков управления бизнес-процессами.

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

В самом общем виде SOA предполагает наличие трех основных участников:поставщика сервиса, потребителя сервиса и реестра сервисов (см. рис. 1).Взаимодействие участников выглядит достаточно просто: поставщик сервисарегистрирует свои сервисы в реестре, а потребитель обращается к реестру сзапросом.

Рис. 1. Общая схема SOA

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

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

Поэтому, как правило, сообщения являютсяXML-документами, которые соответствуют XML-схеме.

Любой разговор о SOA невольно переходит на рассуждение о роли и местеWeb-сервисов. Несмотря на то, что основные положения SOA сложились задолго допоявления Web-сервисов, сегодня Web-сервисы занимают центральное место в SOA(см. рис. 1). Так, Джерими Уэстерман отмечает, что использование XML иWeb-сервисов “поднимает SOA на более высокий уровень”.

Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяютприменять SOA ко всем технологиям и приложениям, установленным в компании. Какизвестно, Web-сервисы базируются на широко распространенных и открытыхпротоколах: HTTP, XML, UDDI, WSDL и SOAP.

Именно эти стандарты реализуютосновные требования SOA – во-первых, сервис должен поддаваться динамическомуобнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоватьсянезависящий от платформы интерфейс (XML).

Наконец, сегодня Web-сервисы рассматриваются как эффективный инструмент дляинтеграции, в том числе для взаимодействия процессов, выполняемых в различныхкомпаниях. Особое место среди различных спецификаций, предназначенных дляописания систем и приложений на уровне бизнес-процессов, занимает язык BPEL4WS(подробнее см. “Бизнес-процессы иXML”).

Преимущества использования SOA

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

Стратегическая ценность SOA:

• Сокращение времени реализации проектов, или “времени выхода на рынок”.
• Повышение производительности.
• Более быстрая и менее дорогая интеграция приложений и интеграция B2B -остановимся более подробно на данном пункте.

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

Крометого, часто при внедрение необходимо написание программного кода. SOAпредусматривает размещение сервисов в сети в режиме исполнения, т.е.

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

Тактические преимущества SOA:

• Более простые разработка и внедрение приложений.
• Использование текущих инвестиций.
• Уменьшение риска, связанного с внедрением проектов в области автоматизациейуслуг и процессов.
• Возможность непрерывного улучшения предоставляемой услуги.
• Сокращение числа обращений за технической поддержкой.
• Повышение показателя возврата инвестиций (ROI).

Перспективы

Совершенно очевидно, что SOA “набирает обороты”.

По крайней мере, около годаназад сотрудники Gartner уверенно заявили о том, что к 2008 году преобладающейпрактикой проектирования и разработки компьютерных программ станетсервис-ориентированная архитектура (с вероятностью 0,7). Таким образом, SOAположит конец господствовавшей последние 40 лет архитектуре монолитногопрограммного обеспечения.

Аналитики компании ZapThink, специализирующейся на вопросах развития иприменения сервис-ориентированно1 архитектуры, выяснили, что в 2004 годукомпании переходили от пилотных проектов к реальным внедрениям в рамках своихотделов.

Так, целый ряд организаций из различных сегментов экономики, включаяфинансовые услуги, страхование, аэрокосмическую отрасль, здравоохранение,фармацевтику, розничную торговлю, государственный сектор и промышленность,”подняли” Web-сервисы до уровня SOA.

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

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

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

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

Сотрудники ZapThink прогнозируют, что 2005 год станет “годом SOA”.

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

Публикации

Источник: https://iso.ru/rus/document6072.phtml

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

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

Сервис-ориентированная архитектура (Service-oriented architecture, SOA) представляет собой эволюцию распределенных вычислений, спроектированных по принципу запрос/ответ для синхронных и асинхронных программных систем.

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

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

Разработчики и интеграторы приложения имеют возможность создавать приложения, объединяя между собой один и более сервисов без знания того, как устроены эти сервисы изнутри. Например, сервис может быть разработан на .NET или J2EE, а его потребитель — на совершенно иной платформе или языке программирования [5, 6].

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

• Каждый SOA-сервис имеет свой интерфейс, описанный в универсальном формате XML с использованием WSDL (Web Services Description Language), который является стандартом, используемым для описания сервисов.
• SOA-сервисы общаются между собой сообщениями, формально определены с помощью XML-схемы, иначе называемой XSD (XML Schema Definition). Связь между потребителями и источниками сервисов, как правило, осуществляется в неоднородной среде, без особых знаний о том, кто опубликовал тот или иной сервис.
• SOA-сервисы содержатся в реестре, который выступает в качестве каталога. Поэтому потребитель сервиса может легко найти нужный ему сервис и запросить его вызов. Universal Description, Discovery and Integration (UDDI) — это стандарт, используемый в реестре сервисов для их описания, определения и интеграции.
• Каждый SOA-сервис имеет качественную характеристику (Quality of Service, QoS). Некоторыми из основных элементов QoS являются такие требования безопасности, как авторизация, аутентификация, надежность обмена сообщениями, а также политики доступа на совершение вызовов этого сервиса.

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

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

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

Потребители сервисов могут вызывать нужные им сервисы путем простой отправки сообщений. Эти сообщения, как правило, видоизменяются и перенаправляются на шину сервисов (Service Bus) и далее к целевому сервису.

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

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

SOA-инфраструктура

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

WSDL, UDDI и SOAP — это фундаментальные части SOA-инфраструктуры.

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

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

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

Хотя J2EE и .NET платформы являются основными для написания SOA-приложений, это не означает, что только ими и ограничивается круг.

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

Новые спецификации, такие как Java API for XML Bindings (JAXB), используемый для отображения XML документов для классов Java, Java API for XML Registry (JAXR), используемый для стандартного общения с реестрами UDDI, а также Java API for Remote Procedure Call (XML-RPC), используемый для удаленного вызова сервисов, облегчает разработку и развертывание веб-сервисов, которые могут быть перенесены между различными окружениями J2EE, одновременно взаимодействую с сервисами на других платформах, таких как .NET.

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

Многочисленные определения, относящиеся к QoS, разрабатываются в таких организациях по стандартизации, как W3C.

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

BPEL4WS или WSBPEL (Web Services Business Process Execution Language) — это определение, которое является частью оркестрации сервисов.

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

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

Бизнес-процессы

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

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

• Входные данные (input) — данные, которые нужно обработать, чтобы затем сформировать выходные данные (результат).
• Выходные данные (output) — все данные, полученные из процесса. Выходные данные представляют собой бизнес-цели и показатели, необходимые для бизнес-деятельности.
• События (events) — уведомления о возникновении чего-либо важного, например, визуальная индикация. Они могут возникать до, во время выполнения и после выполнения процесса.
• Подпроцесс (subprocess) — более мелкий процесс или этап в рамках процесса. Подпроцесс используется тогда, когда невозможно представить объем работы одним набором действий. Он имеет те же элементы, что и процесс.
• Действие (activity) — наименьший элемент работы в процессе.
• Показатели производительности (performance metrics) — атрибуты, представляющие эффективность процесса для определения его соответствия необходимой производительности. Эти показатели помогают определить производительность и сравнить ее с требующимися значениями. Они также выделяют потенциальные области совершенствования процесса, реализуя в конечном итоге цикл улучшений, обещанный архитектурой SOA.

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

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

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

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

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

Источник: https://novainfo.ru/article/12106