Главная
Декларация по УСН
Сервис ориентированная архитектура представляет собой. SOA – вместо реинжиниринга бизнес-процессов – реинжиниринг предприятия. Сервисы как компоненты информационной системы

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Санкт-Петербургский государственный электротехнический университет

Кафедра МОЭВМ

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

Выполнил:

Орешко Д.В.

Санкт-Петербург 2004

программный инфраструктура операционный

Введение

1. Предпосылки

2. Архитектура SOA

3. Базовые стандарты SOA

4. Реестр сервисов

5. Оркестровка

6. Что такое Web-сервисы

8. Проблемы SOA

9. Достоинства

Литература

Введение

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

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

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

1. Предпосылки

Как решается задача интеграции приложений? Традиционный подход -- построение промежуточного программного слоя того или иного типа. Оптимальной для объединения разнородных платформ и решений выглядела технология взаимодействия распределенных объектов CORBA, позволявшая инкапсулировать бизнес-логику приложений, выполняющихся на разных платформах и созданных с использованием разных языков программирования, организовав связь между ними на базе строго описанных интерфейсов. Аналогичные возможности -- правда, с естественным ограничением гетерогенности -- предлагала корпорация Microsoft в рамках своей компонентной модели DCOM. Однако этим решениям не хватало универсальности; даже применение CORBA сильно зависело от реализации в продуктах разных поставщиков, появлялись новые объектные модели, не поддерживающие CORBA, интеграция по-прежнему реализовывалась на достаточно низком уровне, практически, исключая возможность динамичного изменения связей между приложениями в ходе выполнения. Важно и то, что все предлагаемые средства интеграции фокусировались на технологических особенностях реализации приложений и не позволяли учитывать специфику бизнес-процессов, в которых эти приложения использовались.

В то же время новые потребности бизнеса диктуют и новые условия интеграции. Динамичность ИТ-среды, ее нацеленность на решение бизнес-задач, необходимость быстрых изменений в ответ на изменение этих задач -- эти характеристики приобретают ключевое значение при проектировании или реформировании корпоративных ИТ-инфраструктур. В этих условиях отдельные, «точечные» решения по интеграции настолько усложняют и саму инфраструктуру, и процесс управления ею, что становятся абсолютно неприемлемыми. Представим себе, к примеру, что в компании существует несколько приложений, каждое из которых интегрировано со всеми остальными посредством соответствующих интерфейсов. Если таких приложений -- n, то всего потребуется n(n-1) интерфейсов. С добавлением всего лишь одного нового приложения появится 2n новых интерфейсов, для которых потребуется соответствующее документирование, тестирование и поддержка. В примере на рис. 1 пять взаимодействующих приложений порождают 20 интерфейсов, а добавление шестого приложения потребует еще 10. При этом придется вносить модификации в код каждого из существующих приложений для учета новых интерфейсов и проводить соответствующее тестирование. Чтобы избежать этого, нужна модель интеграции, которая позволит максимально упростить процесс добавления новых приложений и минимизирует число интерфейсов взаимодействия.

Еще одна серьезная проблема -- избыточность программных компонентов и сложность их многократного использования. В рис. 1 приводится пример программной инфраструктуры банка, включающей в себя несколько групп приложений для различных направлений банковской деятельности, которые были разработаны в рамках никак не связанных между собой проектов. В результате, с большей долей вероятности возможна ситуация, когда одна функция (скажем, получение баланса по вкладу) реализована многократно в системе автоматизации банкоматов, в системе поддержки филиалов и в системе расчетов по кредитным картам, -- даже если все эти системы используют одни и те же данные о счете из общей базы данных. А теперь предположим, что банк намерен разработать новые системы, например, для обслуживания клиентов в Internet или выдачи ссуд в режиме on-line. Расширение функциональности программной среды банка повлечет за собой дополнительную избыточность, если в этой среде отсутствуют механизмы многократного использования компонентов, поддерживающих различные задачи бизнеса. Все эти интеграционные проблемы и привели к появлению идеи сервисно-ориентированной архитектуры (service-oriented architecture, SOA). Для разрешения этих проблем простого набора технологий уже недостаточно. Нужен общий, архитектурный подход, концепция архитектуры программной среды предприятия, в которой возможна адекватная потребностям бизнеса динамика разработки, интеграции и эксплуатации приложений.

2. Архитектура SOA

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

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

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

Отметим некоторые из этих принципов.

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

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

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

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

Как бы неожиданно это ни показалось, перечисленные принципы были сформулированы американским архитектором Кристофером Александером в отношении архитектуры современного мегаполиса. В 1987 году он и его коллеги опубликовали работу под названием «Новая теория городского проектирования» (A New Theory of Urban Design), где излагались взгляды на возможность децентрализованного развития городов. В своей работе Александр показал, как можно осуществлять развитие городов с учетом существенной демографической разнородности жителей. Аналогичным образом SOA, основанная на адаптации этих принципов, позволяет объединить в общий взаимодействующий организм информационные системы, принадлежащие различным автономным организациям и их относительно автономным структурным подразделениям.

Общая схема.

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

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

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

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

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

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

Подобные контракты существовали и до появления Web-сервисов. Например, в архитектуре CORBA для описания интерфейса объектов использовался язык IDL, который уступает WSDL по ряду существенных параметров. Главный из них -- отсутствие поддержки XML и XML Schema, ставших наиболее распространенными языками разметки передаваемых по сети сообщений и представления моделей данных. Технические контракты, формулируемые провайдером сервисов, должны быть доступны потенциальным потребителям для интерпретации, анализа и реализации интеграции. Для этого используется специальный реестр, каталогизирующий доступные сервисы.

3. Базовые стандарты SOA

Набор базовых стандартов SOA держится на трех «китах». В их число, кроме WSDL и UDDI, входит протокол SOAP -- простой механизм для создания структурированных пакетов данных, предназначенных для обмена информацией между сервисами (сетевыми приложениями). Эту тройку стандартов объединяет то, что все они построены на базе языка XML и являются открытыми, то есть их развитием занимаются независимые комитеты по стандартизации. Чтобы понять, как они работают вместе, сравним технологию Web-сервисов с общением по телефону. В таком случае XML -- это язык, на котором ведется разговор, SOAP описывает правила набора номера, UDDI представляет собой телефонную книгу, а WSDL объясняет, что такое разговор по телефону и как его вести.

4. Реестр сервисов

Сейчас в области Web-сервисов сложились две группировки: одна включает IBM, BEA и Microsoft, а вторая -- Sun, Fujitsu и Oracle. Каждая из них продвигает свои разработки. Например, для управления транзакциями первая предлагает протокол WS-Transactions, а вторая -- WS-Transactions Management; для гарантированной доставки сообщений первая выпустила WS-ReliableMessaging, а вторая -- WS-Reliability. И так -- по всем направлениям технологии Web-сервисов. В результате на роль «заполнителей дыр» в SOA сейчас претендует множество различных методов, но явного лидера нет.

Была создана организация Web Services-Interoperability (http://www.ws-i.org/), которая пытается выработать некий общий знаменатель для технологии Web-сервисов. В августе нынешнего года она выпустила документ WS-I Basic Profile 1.1, определяющий требования к различным компонентам SOA, которые могут гарантировать их совместимость и прояснить тонкости использования Web-сервисов. Программный интерфейс реестра сервисов составляет часть стека протоколов взаимодействия. В наборе технологий Web-сервисов таким стандартом является UDDI (Universal Description, Discovery and Integration). Его спецификация является единственной из ядра основополагающих стандартов Web-сервисов, разработанной вне рамок консорциума World Wide Web Consortium. Таким ядром принято считать спецификации, входящие в профиль WS-I Basic Profile, призванный обеспечить общую для различных инструментальных платформ базу взаимно совместимых технологий описания, публикации, обнаружения и вызова сервисов.

Для разработки данной спецификации в 2000 году был сформирован Консорциум UDDI (UDDI.org), объединивший более 200 корпоративных членов. В соответствии со своим трехлетним мандатом, консорциум выпустил три версии спецификации и перестал существовать в 2003 году. Уже зрелый стандарт, реализованный многими разработчиками, UDDI был передан в организацию Organization for the Advancement of Structured Information Standards (OASIS), занимающую важное место в мире ИТ-стандартов. Текущей версией UDDI, официально принятой в качестве стандарта OASIS, является вторая; ратификация третьей версии ожидается в конце лета этого года, а технический комитет UDDI в составе OASIS уже разрабатывает очередную порцию нововведений.

UDDI обладает весьма развитой функциональностью, существенно более богатой чем, аналогичный компонент набора стандартов CORBA -- CORBA Naming Service. В отличие от предыдущих поколений реестров, UDDI был изначально нацелен на применение как внутри организаций, так и между ними, поэтому реестры UDDI одинаково удобны для ведения информации о нескольких или о тысячах сервисах. Для этого UDDI предусматривает гибкую информационную модель и средства распределения доступа. C точки зрения применимости UDDI в SOA, наиболее методологически значимым элементом информационной модели UDDI является возможность стандартизации типов сервисов (рис. 3). Интерфейс сервиса, описанный WSDL-документом, или даже отдельную его характеристику (скажем, стоимость или поддержка некоего протокола, такого, как HTTP Basic или WS-Security для авторизации) можно представить самостоятельным объектом метаданных в UDDI. Совокупность ссылок на такие объекты характеризует профиль интероперабельности данного сервиса. Используя те или иные параметры, потребитель может найти в реестре сервис, соответствующий его техническим или деловым потребностям.

Рис. 3. Стандартизация типов сервисов

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

С момента публичного представления первой версии UDDI функционирует общедоступный реестр UDDI Business Registry (UBR), который сейчас состоит из четырех географически распределенных реплицируемых узлов: Microsoft (западное побережье США), IBM (восточное побережье США), SAP (Европа) и NTT Telecom (Азия). Наиболее популярным применением UDDI все же остается организация закрытого сообщества взаимодействующих информационных систем либо внутри компании, либо в строго ограниченном кругу ее деловых партнеров. Очевидно, что частный реестр UDDI при этом является центральным звеном корпоративной сервис-ориентированной архитектуры.

5. Оркестровка

Весьма интересна терминология, связанная с веб-сервисами. Так, средства обмена сообщениями, с помощью которых несколько независимых агентов стремятся достичь желаемого состояния, получили название "хореографии", а взаимодействие сервисов - "оркестровки". Для "оркестровки" (т.е., по сути, описания бизнес-логики) были разработаны (с участием крупнейших вендоров, таких, как IBM, Microsoft, Oracle и BEA Systems) специальные средства программирования - BPEL4WS, XLANG, WSFL и др.

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

К ранним языкам определения бизнес-процессов путем комбинирования Web-сервисов относятся XLANG компании Microsoft (www.gotdotnet.com/team/ xml_wsspecs/xlang_c/default.htm) и Web Services Flow Language (WSFL) компании IBM (www-3.ibm.com/software/solutions/ webservices/pdf/WSFL.pdf). XLANG основан на языке WSDL; его основное назначение состоит в определении бизнес-процессов и организации обмена сообщениями между Web-сервисами. WSFL позволяет описывать как публичные, так и частные процессы. Определяется обмен данными, последовательность выполнения и отображение каждого шага процесса на конкретные операции.

6. Что такое Web-сервисы

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

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

Для демонстрации возможностей SOAP может быть использована недавно вышедшая реализация SOAP Toolkit версии 2.0 производства Microsoft. Объект SOAPClient выступает в роли посредника (proxy), предоставляющего интерфейс Web-сервиса и позволяющего работать с ним как с обычным COM-объектом.

Рис. 4. Механизм взаимодействия клиента и сервера SOAP

Клиентское приложение создает экземпляр объекта SOAPClient. SOAPClient читает файлы описания методов Web-сервиса (на языках WSDL и Web Services Meta Language, WSML). Эти файлы могут храниться и на стороне клиента. Клиентское приложение, используя возможности позднего связывания методов объекта SOAPClient, вызывает метод сервиса. SOAPClient формирует пакет запроса (SOAP Envelope) и отправляет его на сервер. Можно применить любой транспортный протокол, но, как правило, используется HTTP.

Серверное приложение Listener (это может быть ISAPI-приложение или ASP-страница) принимает пакет, создает объект SOAPServer и передает ему пакет запроса. Помимо этого Listener обрабатывает HTTP-пакеты от клиента, отправляет клиенту пакеты с результатом работы сервиса, обрабатывает ошибки и использует функциональность SOAP-объектов. SOAPServer читает описание Web-сервиса, загружает описание и пакет запроса в деревья XML DOM. SOAPServer вызывает метод объекта или приложения, реализующего сервис. Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServer в пакет ответа и отправляются клиенту. Объект SOAPClient проводит разбор принятого пакета и возвращает клиентскому приложению результаты работы сервиса или описание возникшей ошибки.

WSDL-файл - это документ в формате XML, описывающий методы, предоставляемые Web-сервисом, а также параметры методов, их типы, названия и местонахождение сервиса Listener. Мастер SOAP Toolkit автоматически генерирует этот документ, фрагмент которого приведен ниже: SOAP Envelope (Пакет) - это XML-документ, который содержит в себе запрос на выполнение метода или ответ на него. Удобнее всего рассматривать пакет как почтовый конверт, в который вложена информация.

Рис. 5. Структура SOAP-пакета

7. Четыре уровня адаптации SOA

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

Уровень 1.

Реализация отдельных Web-сервисов. Это начальный уровень развертывания SOA, на котором технологии Web-сервисов используются для разработки новых приложений или преобразования существующих, например, для интеграции с помощью WSDL-интерфейсов систем, написанных на С++, Cobol и Java. Здесь компании должны реализовать этапы создания и развертывания сервисов. Для создания предлагается инструментарий WebSphere Studio Application Developer, а также набор средств Emerging Technology Toolkit, который позволяет разработчикам опробовать новые решения в области Web-служб. Развертывание Web-сервисов поддерживается сервером приложений WebSphere Application Server.

Уровень 2.

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

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

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

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

Интеграция унаследованных систем. Здесь стоит выделить еще одну архитектурную концепцию, используемую для сервисно-ориентированной интеграции. Речь идет о концепции сервисной шины предприятия (enterprise service bus, ESB). Ее задача -- предоставить единый механизм передачи запросов и получения результатов сервисов, выполнения необходимых преобразований сообщений и транспортных протоколов (скажем, от SOAP на базе HTTP к SOAP на основе WebSphere MQ), обеспечения требований безопасности доступа и, что наиболее важно, управления потоком обращений к сервисам. Благодаря такому управлению выполняется нужная последовательность вызовов сервиса для реализации бизнес-процесса; определение процесса как серии обращений к сервисам поддерживается, например, в разработанном усиловиями IBM и Microcoft языке Business Process Execution Language (BPEL). Обратившись к схематичной иллюстрации шины ESB (рис. 3), можно увидеть, что этот подход решает одну из главных проблем интеграции -- проблему минимизации интерфейсов. Добавление нового сервиса к общей картине приведет к появлению одного и только одного дополнительного интерфейса для интеграции с остальными компонентами архитектуры.

Рис. 6. Модель сервисной шины

Все задачи интеграции, отображения бизнес-процессов компании в сервисы -- предмет реализации на втором и третьем уровнях перехода к SOA в трактовке IBM. На этих уровнях вступают в действие все четыре этапа жизненного цикла сервисов, и используется множество программных продуктов. Второй уровень -- это реализация SOA для ограниченного числа подразделений в компании. Здесь, на этапе создания к средствам разработки WebSphere Studio Application Developer добавляется система WebSphere Host Access Transformation Services. Для развертывания используется поддерживающий язык BPEL сервер интеграции бизнес-процессов WebSphere Business Integration Server Foundation и шлюзы CICS Tranaction Gateway или IMS Connect. Для использования полученных возможностей предлагается WebSphere Portal, а функции управления возлагаются на модули семейства Tivoli -- Access Manager и Monitoring for Transaction Performance.

Уровень 3.

Трансформация ИТ-инфраструктуры в масштабе предприятия. Здесь речь идет о сервисно-ориентированной интеграции приложений и процессов уже в масштабах всей компании, причем согласованный, сервисный подход к ИТ-инфраструктуре распространяется не только на внутренние подразделения, но и на партнеров и поставщиков. Здесь вступают в действие системы, обеспечивающие более глубокую детализацию разработки и интеграцию сервисов с учетом всех уже рассмотренных типов интеграции. IBM предлагает WebSphere Business Integration Modeler и Rational Rose XDE для этапа создания сервисов, WebSphere Business Integration Message Broker для развертывания, DB2 Information Integrator и Lotus Workplace для стадии использования. Управление такой полноценной средой SOA реализуется с помощью инструментов семейства Tivoli -- Identity Manager, Business System Manager и Monitoring for Business Integration, а также WebSphere Business Integration Monitor.

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

Уровень 4.

Изменения в бизнесе. Последний уровень связан с изменениями в самих способах ведения бизнеса в ответ на глобальные трансформации ИТ-инфраструктуры. Здесь надо обратить внимание на связь между SOA и стратегией on-demand computing, которую проповедует IBM и которой подчинена вся стратегия развития ее программных и аппаратных решений. SOA становится архитектурной основой для реализации принципов данной стратегии на прикладном уровне благодаря гибкости, которую обеспечивает сервисный подход к реализации и развертыванию приложений. В SOA для поддержки бизнес-процессов используются не монолитные приложения, а динамичные сервисы, и потому всякое изменение в требованиях для решения бизнес-задач быстро получит адекватное отражение на уровне приложений: необходимые сервисы будут найдены, реконфигурированы и собраны в единое целое.

8. Проблемы SOA

Несогласованность стандартов. В области Web-сервисов сложились две группировки: одна включает IBM, BEA и Microsoft, а вторая -- Sun, Fujitsu и Oracle. Каждая из них продвигает свои разработки. Например, для управления транзакциями первая предлагает протокол WS-Transactions, а вторая -- WS-Transactions Management; для гарантированной доставки сообщений первая выпустила WS-ReliableMessaging, а вторая -- WS-Reliability. (Стоит отметить, что после анонсирования Microsoft Visual Studio Team System, а также предложений IBM по конкретным решениям, основанным на SOA, это противостояние стало минимальным, и можно ожидать продвижения в разработке единых стандартов, регламентирующих использование Web-сервисов).

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

9. Достоинства

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

Внедрение не требует полной перестройки корпоративной инфраструктуры. Предприятиям не нужно отказываться от привычных, хорошо себя зарекомендовавших приложений. Достаточно снабдить их соответствующими интерфейсами -- и Web-сервисы готовы. «Практическая ценность SOA для бизнеса заключается в возможности постепенного эволюционного развития корпоративной информационной инфраструктуры». Благодаря Web-сервисам бизнес-менеджеры могут гораздо активнее участвовать в создании корпоративных приложений. Правда, пока это лишь теоретическая возможность: необходимы специальные инструменты, позволяющие создавать сервисы без программирования. Но они уже начинают появляться. Например, компания UnitSpace выпустила ПО промежуточного слоя BCR. Оно позволяет адаптировать приложения к SOA, создавая Web-сервисы на основе заданных бизнес-аналитиками метаданных, без программирования. «Средства автоматического преобразования форматов позволяют приложениям обмениваться данными на основе их общей семантики, а выполнением бизнес-процессов управлять с помощью сценариев, написанных на стандартном языке BPEL.

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

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

Литература

1. Сергей Кузнецов. Обзор октябрьского 2003 года номера журнала Computer (IEEE Computer Society, Vol. 36, No. 10, October 2003).

2. Валентин Колесов Демонстрация работы SOAP на примере написания Web-сервер.

3. Отчет "Сервис-ориентированная архитектура" (Service Oriented Architecture. InfoWorld Research Report. 2005).

4. Хао Хи (Hao He) "Что такое сервис-ориентированная архитектура" (What is Service-Oriented Architecture?).

5. Клив Финкельштейн (Clive Finkelstein) "Корпорация: сервис-ориентированная архитектура" (The Enterprise: Service-Oriented Architecture (SOA)).

6. Джерими Уэстерман (Jeremy Westerman) "Сервис-ориентированная архитектура сегодня: введение в SOA" (SOA Today: Introduction to Service-Oriented Architecture).

7. Владимир Беленкович, Тимофей Горшков Логическая структура понятия сервисов в рамках SOA.

8. Елена Гореткина Непростой путь от Web-сервисов к SOA.

9. Даниил Фейгин Концепция SOA.

10. Наталья Дубова SOA: подходы к реализации.

Размещено на Allbest.ru

...

Подобные документы

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

    курсовая работа , добавлен 02.12.2013

    Объект CORBA и жизненный цикл серванта. Общий протокол межброкерного взаимодействия (GIOP). Связывание с языком высокого уровня. Статические и динамические вызовы. Применение технологии CORBA при построении распределенных информационных приложений.

    курсовая работа , добавлен 23.12.2014

    Сущность, развитие и применение СОМ-технологий, их достоинства, недостатки, терминология. Особенности СОМ-интерфейса, сервера, клиента, расширений. Локальные и удаленные серверы, их функции и реализация. Технология OMG CORBA и архитектура комплекса.

    курсовая работа , добавлен 13.11.2011

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

    лабораторная работа , добавлен 30.06.2009

    Обзор существующих объектных архитектур. Архитектура программного обеспечения. Создание веб-сервиса "Библиотека", предоставляющего механизмы работы с данными на стороне клиентского приложения. WEB-сервис и трехуровневая архитектура в основе приложения.

    лабораторная работа , добавлен 16.06.2013

    Технология CORBA (Общая Архитектура Брокера Объектных запросов): интерфейс, управление объектами. Создание сервисного приложения, простейшего объекта. Установка связи между клиентом и серверным объектом. Массивы, обработка ошибок и устойчивость к сбоям.

    реферат , добавлен 09.11.2011

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

    контрольная работа , добавлен 15.06.2014

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

    реферат , добавлен 28.11.2015

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

    реферат , добавлен 22.06.2011

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

Обзор терминологии SOA

Часть 1. Сервис, архитектура, управление и бизнес-термины

Бертран Портье (Bertrand Portier)
Опубликовано 25.06.2008

Серия контента:

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

Организационное замечание

Перечисленные ниже термины не выстроены по алфавиту, равно как и по степени важности. Они организованы скорее в блочном стиле. Мы начинаем с "сервиса", поскольку это фундаментальное понятие в рамках SOA. На этом понятии мы строим определения таких терминов, как "архитектура", "управление" и "бизнес". Во многих случаях мы разбиваем объемные термины на их составные компоненты.

Сервис

Сервисы являются, несомненно, сердцем сервис-ориентированной архитектуры: сам термин сервис широко используется. Однако разные люди понимают его по-разному, а потому вопрос "Что такое сервис?" часто приводит к долгим спорам. Мне приходилось слышать, как люди разговаривают о бизнес-задачах, бизнес-сервисах, функциях приложений, технических сервисах и сервисах из области инфраструктуры. Позвольте, я дам вам определение, основанное на IBM Rational® Method Composer Plug-in for SOA Governance и на IBM Rational® Unified Process for Service-Oriented Architecture. Дополнительную информацию вы найдете в .

"Сервис – это видимый ресурс, выполняющий повторяющуюся задачу и описанный внешней инструкцией".

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

  • Ориентация на бизнес : сервисы ориентируются не на возможности ИТ, а на нужды бизнеса. Ориентация сервисов на бизнес поддерживается анализом сервиса и техникой проектирования.
  • Инструкции : сервисы самодостаточны и описываются в терминах интерфейсов, операций, семантики, динамических характеристик, политик и свойств сервиса.
  • Повторное использование : повторное использование сервисов обеспечивается их модульным планированием.
  • Соглашения : сервисные соглашения заключаются между сущностями, именуемыми поставщиками и пользователями. Эти соглашения основываются на сервисных инструкциях и не влияют на реализацию самих сервисов.
  • Размещение и видимость : в течение своего жизненного цикла сервисы размещаются и становятся видимы благодаря сервисным метаданным, реестрам и хранилищам.
  • Агрегация : на слабо связанных сервисах строятся объединяющие бизнес-процессы и сложные приложения для одного или нескольких предприятий.

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

Также важно учитывать, что не все является сервисом. Есть такие ИТ-функции, которые размещать в качестве сервисов смысла нет. Такие аналитические техники, как IBM Service-Oriented Modeling and Architecture (SOMA), помогают определять соответствие сервисов перечисленным выше идеям. Все эти моменты (включая все выделенные термины из данного раздела) мы подробно рассмотрим в данной статье.

Архитектура

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

На форуме Open Group Architecture Forum (TOGAF) есть два определения архитектуры в зависимости от контекста:

  1. "Формальное описание или подробный план системы на уровне компонентов для руководства в процессе ее создания.
  2. Структура компонентов, их взаимосвязи, принципы и направления развития, определяющие их разработку и эволюцию."

Эти два определения критически важны для понимания "A" (архитектуры) из аббревиатуры SOA. Заглянув глубже, мы видим также, что архитектура необходима для следующего:

  • Разработка и моделирование на разных уровнях абстракции
  • Отделение инструкции от реализации
  • Построение гибких систем
  • Проверка на соответствие бизнес-требованиям
  • Анализ объема изменений при появлении новых требований
  • Проверка на соответствие правилам

Архитектура предприятия

Вот определение из Википедии:

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

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

Вы можете отнести "архитектуру" на уровень проектов, а "архитектуру предприятия" - на уровень организаций. Отметьте также упоминания о процессах, информационных системах, персонале, целях, стратегии и бизнес-ориентировке ИТ.

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

Ориентация на сервисы

Как написано в техническом обзоре IBM SOA foundation, "... ориентация на сервисы – это путь интеграции бизнеса как набора связанных сервисов." Больше информации об IBM SOA foundation вы найдете в .

Ключевое слово здесь - "бизнес". Ориентация на сервисы, например, позволяет гибко реализовывать и связывать сервисами бизнес-процессы из одной отрасли бизнеса (ОБ), разных ОБ, а также с бизнес-партнерами.

Эталонная модель SOA foundation

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

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

Рисунок 1. Эталонная модель SOA foundation

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

В IBM SOA foundation SOA определена следующим образом:

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

SOA обладает следующими характеристиками:

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

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

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

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

Она не зависит от технологий, на которых построена. Как вы увидите в разделе "Модельно-управляемая архитектура" (Model-Driven Architecture - MDA) во второй статье данной серии, это разделение важно.

Рисунок 2. Структура решений SOA

Структура состоит из 5 функциональных слоев (снизу вверх):

  • Эксплуатационные системы : представляют существующие ИТ-решения, показывают ценность и важность вложений в ИТ для SOA и возможность их использования.
  • Сервисные компоненты : реализуют сервисы, при этом могут использовать одно или более приложений с уровня эксплуатационных систем. Как вы видите из модели, у пользователей и бизнес-процессов, в отличие от сервисов, нет прямого доступа к компонентам. Существующие компоненты могут быть повторно использованы или, если они для этого подходят, внедрены в SOA.
  • Сервисы : представляют размещенные в среде сервисы. Эти сервисы являются управляемыми видимыми сущностями.
  • Бизнес-процесс : представляет операционные программы, создающие бизнес-процессы в виде хореографий сервисов.
  • Пользователи : представляют каналы, используемые для доступа к бизнес-процессам, сервисам и приложениям.

Управление

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

Этот раздел содержит определения из IBM Rational Method Composer Plug-in for SOA Governance. Здесь определяются термины "управление", "ИТ-управление", "SOA-управление", а также определяется разница между управлением, руководством и соответствием. Тут же описываются проблемы, стоящие перед SOA-управлением. Более подробную информацию о Rational Method Composer вы найдете в .

Управление

"Под управлением мы подразумеваем:

  • Установление цепочек ответственности, полномочий и связей, чтобы уполномочить людей (права на принятие решений)
  • Установление механизмов для измерений, расчетов и контроля с тем, чтобы люди могли выполнять свои обязанности в рамках своей ответственности

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

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

ИТ-управление

"ИТ-управление касается тех моментов управления, которые относятся к процессам в сфере информационных технологий в организации и того, насколько эти процессы соответствуют целям бизнеса."

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

SOA-управление

"SOA-управление – это надстройка над ИТ-управлением, ориентированная на сервисы и прочие продукты жизненного цикла SOA."

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

"SOA-управление предназначено для решения следующих проблем:

  • Какие новые организационные должности и структуры нужны для идентификации, разработки и совместного использования сервисов?
  • Какие метрики поддерживают вложение средств, обслуживание, жизнеспособность и совместное использование сервисов?
  • Как бизнесу решить вопрос об инвестициях в создание и обслуживание сервисов?
  • Что такое зрелость производства в области сервис-ориентированности?
  • Какие необходимы образование, обучение или наставничество?"

Жизненный цикл

Жизненный цикл сервиса

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

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

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

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

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

В определении жизненного цикла SOA IBM SOA foundation отмечает четыре фазы:

  • Модель состоит из бизнес-анализа и разработки (требования, процессы, цели, ключевые показатели продуктивности) и ИТ-анализа и разработки (определение и спецификация сервисов).
  • Сборка состоит из программирования сервисов и построения сложных приложений.
  • Размещение состоит из размещения приложений и средств времени исполнения, таких как Enterprise Service Buses (ESB).
  • Руководство состоит из поддержки операционной среды, мониторинга производительности сервисов и слежения за соблюдением сервисных политик.

Определенные выше SOA-управление и процессы поддерживают эти четыре фазы. Это отображено на рисунке 3.

Рисунок 3. Жизненный цикл SOA

Бизнес

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

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

Ориентация на бизнес

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

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

Компонентное представление бизнеса

сайтponent Business Model® - стратегический метод, позволяющий компаниям фокусироваться на своих ключевых сферах деятельности – на том, чем компания отличается от своих конкурентов, на отслеживании потребления ресурсов и установлении лучшей связи бизнеса со сферой ИТ. В вы найдете дополнительную информацию о Component Business Model. С помощью и благодаря ориентации на сервисы достигается интеграция и взаимодействие этих компонентов бизнеса, а также гибкость, благодаря которой можно проводить аутсорсинг компонентов: у каждого из компонентов бизнеса есть своя уникальная цель, а сообщаются они между собой посредством набора бизнес-сервисов, которые они поставляют другим компонентам либо получают от других компонентов. Это можно рассматривать как часть "бизнес-архитектуры".

Бизнес-моделирование

Бизнес-моделирование определяется IBM Rational Unified Process® следующим образом:

"Дисциплина Rational Unified Process Business Modeling предоставляет точное руководство для описания с помощью набора подходов и техник, на разных уровнях формализации "текущего" или "желаемого" бизнеса".

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

SOA – долговременная стратегия реорганизации бизнеса и ИТ-систем, цель которой - быстрое реагирование на перемены. В есть ссылка на журнал IBM Systems (том 44, номер 4), рассказывающий о SOA, в котором вы найдете более подробное рассмотрение связанных с бизнесом сторон сервис-ориентированного мышления.

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

Бизнес-процесс – это последовательность действий, дающая полезный результат.

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

Бизнес-деятельность и задачи

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

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

Моделирование бизнес-процессов

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

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

Задачи для людей

Довольно часто в процессах требуется человеческое вмешательство (например, утверждение командировки или кредита). Такие задачи при моделировании бизнес-процесса определяются как ручные, и для каждой задачи назначается определенная роль. После размещения для выполнения процессов SOA потребуется поддержка задач, выполняемых людьми. Такие продукты, как, например, IBM WebSphere Process Server, предоставляют пользователям списки ожидающих их задач для людей. При их комбинировании с такими продуктами, как IBM WebSphere Portal и Lotus Sametime, пользователи также могут сотрудничать между собой и оповещать систему о принятых ими решениях, чтобы система могла продолжать выполнение процессов. Этот человеческий фактор критически важен для успеха SOA.

BPEL

IBM, Microsoft и другие компании участвовали в разработке языка Business Process Execution Language (BPEL) for Web services specification (язык выполнения бизнес-процессов для создания спецификаций Web-сервисов), являющегося средством формального описания бизнес-процессов и протоколов взаимодействия.

Отрасли

В разных сферах деятельности и отраслях бизнес-процессы могут иметь свою специфику, как, например, в страховании. Отраслевые бизнес-процессы определяются промышленными консорциумами. Например, TeleManagement Forum определяет enhanced Telecom Operations Map (eTOM) для телекоммуникационной отрасли. Кроме того, компании, чтобы выделиться среди конкурентов, могут внедрять свои собственные бизнес-процессы, основанные на проверенных моделях, таких как IBM Industry Models. В приведена ссылка на IBM Insurance Application Architecture (IAA), которая является примером IBM Industry Models.

Управление бизнес-процессами

Управление бизнес-процессами (Business Process Management - BPM) занимается полным жизненным циклом бизнес-процессов с целью повышения их эффективности, гибкости и управляемости.

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

Заключение

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

Благодарности

Я хотел бы поблагодарить моих коллег из IBM, которые внесли большой вклад в сервис-ориентированную архитектуру и описанные в статье идеи. Особую благодарность выражаю Ричарду Джонсону (Richard D. Johnson) и Стиву Киндеру (Steve Kinder) за рецензию на эту статью.

Аннотация

Продолжительность курса

· Лекции – 45 мин;

· Ответы на тесты - 15 мин.


Теоретический курс



Понятие SOA

Согласно IT Gartner SOA SOA SOA SOA приложение».

Анатомия SOA

Слайды №6, 7

Рассмотрим логическую структуру SOA приложения. Как правило, подобное приложение на логическом уровне можно разделить на две большие части:

1. Бизнес – домен

2. IT – домен

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

IT – домен отвечает за создание сервисов, подключения существующих не – SOA приложений и т.д.

Если разделить SOA на уровни, то мы увидим следующие семь уровней:

Уровень 1: Уровень унаследованных систем. Состоит из существующих заказных приложений, называемых также унаследованными системами, например, приложения системы управления взаимосвязями с клиентами (CRM) и планирования ресурсов предприятия (ERP) и т.д. Многоуровневая архитектура SOA может помочь улучшить уже существующие системы и способствовать их интеграции с использованием сервис - ориентированных методов.

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

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

Уровень 4: Уровень объединения (хореографии) бизнес процессов. На этом уровне определяется способы объединения сервисов, определенных на Уровне 3. Сервисы связаны в поток путем группировки (хореографии) и, следовательно, они действуют совместно как отдельное приложение. Для проектирования потоков приложения могут использоваться визуальные инструменты компоновки.

Уровень 5: Уровень презентации. SOA отделяет пользовательский интерфейс от компонентов, но без пользовательского интерфейса, как правило, обойтись нельзя. Пользовательский интерфейс позволяет вывести сервисы на уровень интерфейса приложения или презентации.

Уровень 6: Интеграция (ESB). Этот уровень допускает интеграцию сервисов путем предоставления набора таких возможностей, как интеллектуальная маршрутизация, посредничество протоколов и других механизмов преобразований, обычно описанных как ESB (Enterprise Service Bus) – корпоративная сервисная шина.

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

Стандарты SOA

Слайды №8, 9

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

Спецификации SOAP, WSDL и UDDI де-факто определяют стандартную инфраструктуру текущей технологии Web-сервисов. Две группы по стандартизации работают над официальными стандартами Web-сервисов – W3C и OASIS (Organization for the Advancement of Structured Information Standards).

W3C фокусируется на спецификациях инфраструктуры ядра технологии, а OASIS на высокоуровневой функциональности.

Simple Object Access Protocol (SOAP) – протокол обмена сообщениями, основанными на XML, определяет как Web - сервисы могут посылать сообщения друг другу. Это высокоуровневый протокол, который лишь определяет структуру сообщений и несколько правил по их обработке. SOAP не зависит от транспортного протокола, поэтому обмениваться SOAP - сообщениями можно через множество транспортных протоколов. В настоящее время чаще всего для передачи SOAP – сообщений в качестве транспортного протокола используется HTTP.

Web Services Definition Language (WSDL) – стандарт для описания Web - сервисов. Описание на WSDL содержит всю информацию необходимую для доступа и использования Web - сервиса, включая интерфейс Web сервиса. Описание на WSDL – это XML документ, содержащий набор определений, таких как типы данных, формат сообщений и т.д.

Таким образом, WSDL определяет стандартный описательный механизм для Web – сервисов, документ WSDL описывает, какую функциональность предлагает Web – сервис, как получить доступ и т.д. Документ WSDL может быть откомпилирован для создания proxy для клиентов, которые вызывают данный сервис (proxy позволяет клиенту «думать», что сервис расположен на той же машине, что и сам клиент).

Universal Description Discovery and Integration (UDDI) – «желтые страницы», в которых могут быть зарегистрированы Web - сервисы и их описания на WSDL. UDDI сам по себе Web - сервис и является реестром общего назначения, где могут быть зарегистрированы не только Web - сервисы.

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

Транспортные протоколы для Web-сервисов

В процессе разработки Web – сервиса, необходимо определить какие транспортные протоколы будет поддерживать Web-сервис для обмена сообщениями. В настоящее время, для транспортировки XML – сообщений чаще всего используется HTTP (основной протокол, используемый web-серверами и web – браузерами), а при реализации Web-сервисов на платформе Java может использоваться Java Messaging Service (JMS), который является частью спецификации J2EE. Web-сервис может поддерживать несколько транспортных протоколов, это обстоятельство находит свое отражение в WSDL файле сервиса.

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

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

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

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

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

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

Форматы сообщений

Когда мы выбрали транспортный протокол для Web-сервиса, необходимо определиться с форматом собственно сообщений, которыми мы будем обмениваться. Формат сообщений описывает, как сообщение должно быть подготовлено к отправке по транспортному протоколу. Например, мы можем оформлять наши сообщения в SOAP – формате или в виде обычного XML. Независимо оттого, что мы выбрали – SOAP или XML, мы можем пересылать их через HTTP или JMS.

Web-сервис может поддерживать несколько транспортных протоколов и форматов сообщений.

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

Слайд №10

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

У SOA есть и другие достоинства.

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

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

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

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

Проблемы использования SOA

Слайд №11

В целом идеи SOA понятны и производителям ПО и клиентам, однако нельзя сказать, что данная технология находится в зрелом состоянии. Недостаточно проработаны стандарты, не хватает инструментов управления. Как и часто бывает в таких случаях, сложилось группировки производителей программного обеспечения, разрабатывающих свои спецификации. В результате на роль «заполнителей дыр» в SOA сейчас претендует множество различных методов, но явного лидера нет. Сближение подходов намечается в рамках организация Web Services Interoperability (www.ws-i.org), которая пытается выработать некий общий знаменатель для технологии Web-сервисов. Она выпустила документ WS-I Basic Profile, определяющий требования к различным компонентам SOA, которые могут гарантировать их совместимость и прояснить тонкости использования Web-сервисов.

Перспективы и прогнозы

Аналитики с большим оптимизмом смотрят на будущее SOA и Web-сервисов. Так, по прогнозу компании Gartner, к 2008 г. более 60% предприятий будут использовать эту архитектуру в качестве основного принципа при создании ответственных бизнес-приложений.
В IDC подсчитали, что в прошлом году предприятия потратили на поддержку Web-сервисов 1,1 млрд. долл., а в 2008 г. израсходуют 11 млрд. долларов. Компания ZapThink, занятая исследованиями в области SOA, прогнозирует, что рынок инструментов для реализации Web-сервисов вырастет со 120 млн. долл. в 2003 г. до 8,3 млрд. долл. в 2008 г. Аналитики объясняют такой подъем тем, что SOA, позволяющая снизить расходы на IT , становится главной стратегией при решении проблем интеграции разнородных систем. Отношение предприятий к SOA становится более серьезным, и они переходят от экспериментов к реальным внедрениям.

Понятие Web – сервиса

Слайд №13

Web - сервисы можно рассматривать как «plug and play» приложения. Web -сервис представляет собой часть информационной системы или бизнес-процесса, к которой можно обратиться в том числе и через Интернет с целью сборки требуемой информационной системы.

Отличие Web - сервисов от приложений других типов в том, что Web – сервисы разрабатываются для поддержки связи и взаимодействия приложений с приложениями. Другие Web приложения поддерживают коммуникации человек – человек (например, e-mail) или человек – приложение (браузеры). Технология Web – сервисов позволяет приложениям общаться с другими приложениями без участия человека.

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

Основными возможностями, предоставляемыми Web-сервисами, являются:

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

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

· Доступ к Web –сервису можно осуществлять как через интранет, так и через Интернет.

На концептуальном архитектурном уровне Web-сервисы – это основанные на стандартах «обертки» для сервисов и ресурсов, которые провайдер делает доступными для потребителей.

Виды Web – сервисов

По формату сообщений, Web – сервисы разделяются на:

1. Web – сервисы, основанные на сообщениях SOAP.

2. Web – сервисы, основанные на технологии Representational State Transfer (REST).

3. Web – сервисы, основанные на XML-RPC.

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

По способу обработки входящих сообщений Web - сервисы могут быть:

1. Синхронные

2. Асинхронные

Список источников

1. Об использовании BPMS - http://www.bpms.ru

2. Демонстрация BPMS - http://www.unify.ru/demo/bpm/index.html

3. Материалы исследований компании ZapThink - http://www.zapthink.com

4. Материалы о механизмах интеграции компании Intersoft Lab -

http://www.iso.ru/journal/articles/themes/17

5. Техническая библиотека компании BEA - http://dev2dev.bea.com/soa/

6. Техническая библиотека компании Sun - http://java.sun.com/webservices/index.jsp

7. Техническая библиотека компании IBM –

http://www-128.ibm.com/developerworks/ru/views/webservices/libraryview.jsp

8. mig_ssdoc\\$/ПРОИЗВОДСТВО SOA/Архитектура/Презентация платформы v2.ppt

9. mig_ssdoc\\$/ПРОИЗВОДСТВО SOA/Архитектура/Архитектура системы v2.doc

Приложение 1

Рисунок для иллюстрации архитектуры фронт – офисного решения Diasoft.

Аннотация

Данный документ предназначен для проведения лекционных занятий по теоретическому курсу "Основы сервисно – ориентированной архитектуры".

Требования к знаниям слушателей:

· Знание основ архитектуры построения распределенных многозвенных приложений;

По итогам обучения, слушатели должны:

· Получить представление о принципах построения приложений в SOA;

· Узнать о ключевых технологиях, применяемых в SOA;

· Иметь представление о сервисах, как основных строительных элементах SOA приложений;

· Узнать об использовании корпоративной сервисной шины ESB для интеграции Web - сервисов;

· Получить информацию о системах управления бизнес – процессами (BPMS).

· Получить основные сведения об архитектуре фронт – офисного решения Diasoft.SOA

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

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

Продолжительность курса

· Лекции – 45 мин;

· Ответы на тесты - 15 мин.


«Основы сервисно – ориентированной архитектуры»

Теоретический курс

1. Краткий обзор сервисно – ориентированной архитектуры (SOA)..... 4

1.1. Понятие SOA................................................................................................................... 4

1.2. Предпосылки возникновения SOA........................................................................... 4

1.3. Эволюция архитектуры корпоративных IT систем............................................... 4

1.4. Анатомия SOA................................................................................................................ 5

1.5. Стандарты SOA.............................................................................................................. 6

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

1.7. Проблемы использования SOA................................................................................. 8

1.8. Перспективы и прогнозы............................................................................................. 9

2. Инфраструктура для приложений в SOA.............................................. 9

2.1. Элементы инфраструктуры для реализации приложений в SOA.................... 9

2.2. Понятие Web – сервиса................................................................................................ 9

2.3. Схема регистрации и поиска Web – сервисов....................................................... 10

2.4. Механизм вызова Web – сервисов и конвертация данных \ протоколов с использованием ESB................................................................................................................................... 11

2.5. Использование ESB для интеграции приложений.............................................. 11

2.6. BPEL - язык описания бизнес - процессов............................................................. 12

2.7. BPMS – система управления бизнес - процессами.............................................. 14

3. Архитектура фронт - офисного решения Diasoft................................. 17

3.1. Особенности фронт – офисного решения Diasoft............................................... 17

3.2. Архитектурные слои фронт – офисного решения Diasoft................................. 18

Список источников..................................................................................... 19

Приложение 1............................................................................................... 20


Краткий обзор сервисно – ориентированной архитектуры (SOA)

Понятие SOA

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

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

20 ответов

Маленький тизер:

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

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

    SOA - новый значок для некоторых очень старых идей:

      Разделите свой код на повторно используемые модули.

      Инкапсулируйте в модуле любое дизайнерское решение, которое может измениться.

      Создайте свои модули таким образом, чтобы их можно было комбинировать различными способами (иногда называемыми "семейством" или "продуктовой линейкой").

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

    Что нового в SOA

      Вы делаете это в сети.

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

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

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

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

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

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

      Надеюсь, это дало по крайней мере кому-то лучшую картину SOA.

      Предположим, у вас есть четыре повара. В SOA вы предполагаете, что они ненавидят друг друга, поэтому вы стараетесь позволить им разговаривать друг с другом как можно меньше.

      Как вы это делаете? Ну, сначала вы определите роли и интерфейс - повар 1 сделает салат, повар 2 сделает суп, повар 3 сделает стейк и т.д. Затем вы разместите блюда, хорошо организованные на столе (так это интерфейсы) и сказать: "Все, пожалуйста, поместите свое творение в свои назначенные блюда. Не заботьтесь ни о ком другом".

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

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

      Одна из самых успешных реализаций SOA была на Amazon. Из-за их дизайна они могут повторно упаковать всю свою инфраструктуру и продать ее как Amazon Web Service.

      * Это только один аспект SOA.

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

      IMHO, SOA имеет смысл только на уровне предприятия и ничего не значит для одного приложения.

      На многих предприятиях каждый отдел имел собственный набор корпоративных приложений, который подразумевал

        Аналогичная функция была реализована несколько раз

        Данные (например, данные клиента или сотрудника) должны быть разделены между несколько приложений

        Приложения были децентрализованными.

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

        Не нужно переопределять подобные функции снова и снова (например, предоставлять услуги клиента или сотрудника)

        Облегчает интеграцию приложений вместе и доступ к общим данным или функциям

      • Развитие, ориентированное на предприятие усилие.

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

      Это 1000-футовый вид SOA. Однако это не останавливается. Существуют и другие концепции, дополняющие SOA, такие как организация бизнес-процессов (BPM), корпоративная шина обслуживания (ESB), комплексная обработка событий (CEP) и т.д. Они решают проблему ИТ/бизнес-ориентирования , что заключается в том, как ИТ-специалисты смогут эффективно поддерживать бизнес.

      SOA - это аббревиатура сервис-ориентированной архитектуры.

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

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

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

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

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

      Таким образом, вы определяете протокол, который вы будете использовать для взаимодействия (скажем, это могут быть веб-службы SOAP), и пусть ваша "система-то-то-дело-работа-работа" взаимодействует с небольшими службами для достижения вашего "большой цели".

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

      Итак, вы покупаете Oracle SOA, а Oracle становится боссом всех ваших частей. Все остальные игроки должны работать с SOA через службу (веб-сервис или что-то еще). Монолит Oracle заботится обо всем (монолит не подразумевается уничижительным). О да, у вас есть ASP.NET MVC спереди или что-то еще.

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

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

      из блога ittoolbox.

      Ниже описываются сходства и отличия от прошлых методов проектирования:

      SOA и структурированное программирование o Сходства: большинство похоже на вызовы подпрограмм, где передаются параметры, а функция функции абстрагируется от вызывающего абонента - например, CICS и выполнить и зарезервированное слово COBOL CALL. Копировальные книги используются для определения структуры данных, которая обычно определяется как XML-схема для служб. o Различия: SOA слабо взаимосвязана, что означает, что изменения в сервисе оказывают меньшее влияние на потребителя ("вызывающая" программа), а службы взаимодействуют между языками и платформами.

      SOA против OOA/OOD o Сходства: инкапсуляция, абстракция и определенные интерфейсы o Различия: SOA слабо связан с иерархией классов или наследованием, абстракции низкого уровня - уровень класса и бизнес-сервис

      SOA и устаревшая разработка на основе компонентов (CBD) - например, CORBA, DCOM, EJB o Сходства: Повторное использование через компоненты сборки, Интерфейсы, Удаленные вызовы o Различия: широкое внедрение стандартов, XML-схем и маршализированных объектов, сервис-оркестровка, проектирование для повторного использования проще, услуги ориентированы на бизнес и ИТ-ориентированные, бизнес-услуги являются конечно-крупными (широкими по охвату)

      SOA (для интеграции) по сравнению с интеграцией корпоративных приложений (EAI) o Сходства: лучшие практики (четко определенные интерфейсы, стандартизованные схемы, управляемая событиями архитектура), многоразовые интерфейсы, общие схемы o Различия: стандарты, принятие и улучшенные инструменты

      Ну, вы видите. SOA означает сервис-ориентированную архитектуру... Проще говоря, вы пишете фрагмент кода, который является очень общим, т.е. он делает кое-что, что может использоваться во многих приложениях... может быть чем-то вроде адресной книги или может быть калькулятором. и вы запускаете этот код в IIS. Таким образом, вы предоставляете услугу через свой код. Таким образом, вы являетесь поставщиком услуг. Теперь кто-то хочет использовать аналогичный код, тогда ему не нужно снова писать код. Он просто использует ваш код, возможно, через веб-службу. Следовательно, он становится потребителем услуг. Следовательно, создание программы с использованием таких сервисов называется SOA. И свободная связь существует, поскольку поставщик услуг и потребитель могут взаимодействовать, даже если они используют языки программирования diff. Надеюсь, вы понимаете.

      Вячеслав Ерохин

      В статье рассматривается сервис-ориентированная архитектура (SOA ) как бизнес-концепция. Предлагается подход к управлению жизненным циклом SOA с помощью методики «Управление SOA » (SOA Governance ), основанной на средствах управления архитектурой предприятия (Enterprise Architecture Management ) и стратегического управления ИТ.

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

      SOA – это архитектура

      SOA – Service Oriented Architecture – архитектура, ориентированная на сервисы. SOA – это прежде всего бизнес-концепция архитектурного подхода к построению предприятия. Более ранние концепции не ставили в центр внимания архитектуру предприятия

      SOA – первая широко известная бизнес-концепция, концентрирующаяся на архитектуре. Таким, образом, SOA надо понимать и применять в контексте управления архитектурой предприятия (Enterprise Architecture Management ). Архитектура предприятия включает разные слои: бизнес-архитектура, информационная архитектура, техническая архитектура и т.д. SOA начинается с уровня бизнес-архитектуры.

      SOA – это сервисы

      Концепция SOA концентрируется на архитектуре, но архитектуре ориентированной на сервисы. Что такое сервисы и в чем разница с более ранними концепциями?

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

      Таким образом, в SOA стоит выделить первый уровень - бизнес-архитектуры. В свою очередь бизнес-сервисы не существуют в отрыве от миссии компании, ее стратегии и целей. Бизнес-сервисы вытекают из места компании во внешней конкурентной среде. Долгосрочное развитие бизнеса может быть основано только на конкурентных преимуществах и их сочетании, обеспечивающем синергетический эффект. Обычно таких преимуществ немного – два-три. Большая удача – если их пять-шесть. Главная задача выживания компании – это задача создания и сохранения ее конкурентных преимуществ. Но конкурентные преимущества – или по-другому бизнес-потенциалы (Business Capabilities ) – не строятся на основе процессов. Это функции компании как целого организма во внешней среде.

      Бизнес-потенциалы

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

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

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

      Основные правила, заложенные в основу концепции бизнес-потенциалов:

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

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

      • обеспечить сохранение поддержки критически важных бизнес-потенциалов
      • обеспечить достижение стратегических целей предприятия.

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

      Сервис или процесс

      Бизнес-потенциалы (Business Capabilities ) легко декомпозировать в бизнес-сервисы, но трудно – в бизнес-процессы. Сервисный подход ориентирован на стратегические цели компании – создание и сохранение бизнес-потенциалов.

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

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

      SOA – это не технологическая платформа

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

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

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

      SOA – вместо реинжиниринга бизнес-процессов – реинжиниринг предприятия

      Стив Джонс, автор книги «Enterprise SOA Adoption Strategies. Using SOA to deliver IT to the businesss» утверждает: «Большинство компаний совершают одну принципиальную ошибку в отношении технологий: они рассмативают их через призму существующих процессов. Компании спрашивают: "Как эти новые технологические возможности могут улучшить и оптимизировать текущую работу?" Но вместо этого они должны спрашивать: "Что новое могут позволить нам делать технологии?" В отличие от автоматизации суть реинжиниринга - в новаторстве, в использовании новейших технологических возможностей для достижения совершенно новых целей. Один из самых сложных элементов реинжиниринга - умение найти новые, незнакомые возможности технологии».

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

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

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

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

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

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

      Что такое SOA Governance ?

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

      SOA Governance – это процесс управления жизненным циклом предприятия, построенного на основе SOA . SOA Governance – это также инфраструктура управления жизненным циклом SOA . Эффективное управление SOA - это не просто технология. Это подход к жизненному циклу, в котором участвуют все ответственные сотрудники организации, и учитываются различные активы организации.

      Создание инфраструктуры управления SOA, предполагает решение ряда типовых задач:

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

      Создание высокоэффективных бизнес-сервисов

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

      Реализация подхода SOA Governance позволяет ответить на следующие вопросы:

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

      Управление жизненным циклом сервисов

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

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

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

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

      Оценка эффективности

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

      Процесс SOA Governance

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

      Процесс SOA Governance состоит из четырех этапов:

      • Планирование – анализ потребностей в элементах SOA
      • Согласование (определение) – проработка подхода к управлению SOA , согласование отдельных элементов SOA между собой
      • Разработка (реализация) – разработка и ввод управления SOA в действие
      • Функционирование (оценка) – мониторинг и оценка внедренных решений и управление ими.

      Планирование инфраструктуры SOA

      На этапе планирования анализируются потребности организации и выявляются области, в которых требуется более эффективное управление.

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

      На этом этапе реализуются следующие мероприятия:

      • Выделение в ИТ-стратегии компании направления, ориентированного на использование SOA.
      • Определение необходимого уровня возможностей ИТ и SOA
      • Формулирование и уточнение видения и стратегии развития SOA
      • Изучение возможностей и проводимые мероприятия в области управления SOA .
      • Разработка плана управления SOA.

      Согласование и определение - проработка подхода к управлению SOA

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

      На этапе определения принимаются различные решения в области управления SOA :

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

      Разработка и реализация - ввод модели управления в действие

      На этапе реализации решения по управлению SOA претворяются в жизнь. На этом этапе выполняются следующие работы:

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

      Функционирование и оценка - мониторинг внедренных решений и управление ими

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

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

      • Контроль выполнения разработанных политик и методов управления, таких как соглашения об уровне обслуживания, анализ уровня повторного использования и изменения политик
      • Анализ показателей эффективности бизнес-архитектуры и ИТ-инфраструктуры.

      Инструменты SOA Governance

      Эффективное управление предприятия, построенного на основе SOA возможно только с использованием соответствующего инструментария.

      Требования к инструментарию SOA Governance позволяют сформировать набор продуктов, отвечающий задачам управления SOA :

      Поддержка архитектурного подхода

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

      Поддержка элементов сервис-ориентированной архитектуры

      Инструмент SOA Governance должен обеспечивать поддержку элементов сервис-ориентированной архитектуры. Наиболее важной является поддержка типов артефактов:

      • Логический сервис (бизнес-сервис)
      • Технический сервис (веб-сервис)
      • Функциональный домен
      • Функциональный модуль
      • Техническая операция

      Поддержка процесса управления жизненным циклом сервис-ориентированной архитектуры

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

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

      Ведущие поставщики программного обеспечения предлагают различные наборы инструментов, реализующих SOA Governance . Наиболее функционально полные решения предлагают компании IBM , Oracle , Software AG .

      Пример реализации SOA Governance на основе Oracle Fusion Middleware и системы управления архитектурой предприятия Alfabet planningIT

      Интегрированное решение на основе alfabet planningIT и Oracle Fusion Middleware позволяет предоставить сквозную услугу по управлению жизненным циклом ИТ-инфраструктуры на основе SOA . Благодаря взаимодействию Oracle Fusion Middleware и alfabet planningIT можно успешно проектировать, разрабатывать и внедрять сервис-ориентированную архитектуру (SOA ).

      Решение alfabet /Oracle обладает определенными преимуществами перед другими решениями SOA Governance :

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

      Процессы, поддерживаемые интегрированным решением

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

      Функции, поддерживаемые интегрированным решением.

      • Создание в planningIT описания технических сервисов (WSDL ), соответствующих технической реализации логических сервисов, их экспорт в репозитарий Oracle .
      • Генерация из planningIT проектов Java в Oracle IDE для реализации соответствующих технических сервисов.
      • Импорт из Oracle в planningIT существующих технических сервисов для планирования бизнес-приложений и логических сервисов.
      • Формирование в planningIT описания бизнес-приложений в терминологии SOA – как набора логических сервисов, реализованных в виде технических сервисов (веб-сервисов).
      • Построение в planningIT упрощенных диаграмм процессов BPEL и их экспорт в Oracle .
      • Импорт из Oracle BPEL Engine в planningIT статистики об использовании сервисов для целей централизованного планирования SOA .

      Компоненты, используемые в интегрированном решении

      Компоненты Oracle Fusion Middleware (FMW ):

      • Oracle Services Registry (UDDI) – центральный реестр сервисов
      • BPEL PM & BPEL Designer (JDeveloper) – разработка и выполнение процессов на BPEL
      • Датчики (sensors) – сбор и нформации о KPI процесса
      • Web Services Manager – управление доступом к веб-сервисам

      Компоненты alfabet planningIT :

      • Logical Inventory – единый репозитарий на основе развитой метамодели
      • Application Architecture Management – управление архитектурой приложений
      • Enterprise Architecture Management – управление архитектурой предприятия

      Стадия планирование

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

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

      Основным объектом интеграции alfabet planningIT и Oracle Fusion Middleware является объект «Сервис». В репозитарии alfabet planningIT существует артефакт «Технический сервис» (Technical Service ), который корреспондирует с термином «Сервис» (Service ) в SOA . Такой сервис может быть описан с использованием WSDL . Технический сервис в planningIT может быть создан или повторно использован для технической реализации логических сервисов. Логические сервисы в planningIT могут быть объединены в форме бизнес-приложений. Бизнес-приложение является артефактом репозитария, играющим ключевую роль в процессе планирования, управления, анализа затрат и т.п.

      Продукты Oracle обеспечивают интегрированную поддержку проектирования, реализации и внедрения сервисов. Oracle Fusion Middleware реализует сервисную шину предприятия (ESB ) и оркестровку сервисов (BPEL ), а также предоставляет возможности мониторинга развернутых сервисов с помощью репозитария сервисов.

      Система Alfabet planningIT также предоставляет инструментарий для оценки влияния изменений и проведения анализа затрат внедрения изменений. Oracle Fusion Middleware обеспечивает поддержку реализации, развертывания и выполнения сервисов, спланированных и прототипированных в planningIT .

      Стадия согласование (определение)

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

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

      Стадия разработка (реализация)

      Для обеспечения технической реализации логических сервисов пользователи planningIT могут детализировать описание логических сервисов в терминах технических сервисов. При этом технические сервисы могут быть импортированы из репозитария веб-сервисов Oracle . Если же необходимого технического сервиса не существует, то описание такого сервиса может быть создано в planningIT и затем опубликовано в репозитарии Oracle (OraSR +WSM ) со статусом «В стадии разработки». В то же время генерируется новый проект Java для реализации соответствующего технического сервиса.

      Диаграмма процессов BPEL в Oracle соотносится с объектом бизнес-приложение (Business Application ) в репозитарии planningIT . Бизнес-приложение в planningIT – это набор бизнес-сервисов, которые поддерживают бизнес деятельность – а не программный компонент. Таким образом, бизнес-приложение может быть описано в виде диаграммы BPEL , описывающей оркестровку технических сервисов.

      Бизнес-приложение может быть экспортировано из planningIT в виде проекта BPEL в формате XML . Все технические сервисы, соответствующие бизнес-приложению, должны быть включены в проект в формате XML и экспортированы в репозитарий Oracle (OraSR +WSM ). Диаграмма BPEL , разработанная в planningIT также может быть экспортирована для последующего использования в среде разработки Oracle (Oracle IDE ).

      Стадия функционирование (оценка)

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

      Сквозная интеграция alfabet planningIT с Oracle FMW означает, что предприятия теперь могут вести управление эволюцией элементов SOA и жизненным циклом сервисов на основе надежных и последовательных данных и визуальной информации.

      Модуль «Управление архитектурой предприятия» planningIT может использоваться для передачи и агрегирования данных с уровня внедренных сервисов на уровень бизнес-планирования, где менеджеры осуществляют оценку рисков, затрат, доступности и качества ИТ-сервисов для важных бизнес-процессов и продуктов. planningIT может импортировать статистику об использовании сервисов из Oracle BPEL Engine . Эта информация может использоваться для централизованного планирования SOA .

      Заключение

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



      Декларация по УСН

Вам также может понравиться