В бизнесе гибкость и быстрая реакция решают все. Слияния и приобретения компаний, новые нормативы и инструкции, повышение ожиданий клиента - все это вынуждает компанию быстрее реагировать на изменения в требованиях. Масштабные приложения, такие как ERP- и CRM-решения, повышают производительность, но вместе с тем углубляют разнородность и разобщенность ИТ-инфраструктуры. Это в свою очередь снижает способность компании оперативно реагировать на перемены. Приходится координировать, автоматизировать и оптимизировать деятельность пользователей и различных бизнес-систем, распределенных по всему предприятию, и делать это в условиях непрерывно меняющихся бизнес-процессов. Иначе говоря, требуется управление бизнес-процессами.
Увы, действуя радикальными методами, то есть заменяя старые приложения новыми, гибкости не добиться. Точнее говоря, можно постоянно заниматься перестройкой корпоративных приложений, но это обязательно нарушит работу компании.
Единственный выход, который виден, - разбить монолит корпоративных приложений на модульные компоненты, удобные для внесения изменений и пригодные для повторного использования во многих бизнес-процессах. Новая парадигма разработки ПО, основанная на этой идее, получила название "ориентированной на сервисы архитектуры" (Service-Oriented Architecture, SOA). Монолитное построение ПО противно природе SOA - в ней приложения создаются из модульных сервисов. Нужная функциональность собирается из слабосвязанных и общедоступных сетевых сервисов. При использовании SOA интеграция приложений выполняется на намного более высоком уровне абстрагирования, позволяя поставщикам скрыть внутренние сложности сервисов от приложений или пользователей, которые используют и развертывают эти сервисы.
Что такое сервис?
Чтобы продвигаться дальше, надо дать определение сервиса. Сервис на бизнес-уровне - это некая повторяющаяся бизнес-операция, которую менеджер осознает как элементарную и дискретную. На уровне ИТ сервис -отдельная программная функция, обеспечивающая постоянный и независимый от имплементации интерфейс. Это определение ИТ-сервиса дано компанией Forrester Research. Суть его в том, что когда сервис смотрит на мир интерфейсом, я понимаю, как его попросить, чтобы он что-то сделал, и понимаю, что получу в ответ. А вот как сервис это сделает - это его сугубо личное дело, это скрыто за интерфейсом. Что происходит за интерфейсом, нам неизвестно. Сервис нужно понимать как отдельную программную функцию, которая может выполняться по запросу любой системы, независимо от ее ОС, языка программирования или географического местоположения. При этом сервис может меняться, может выполнять задачу одним способом или другим. Главное - чтобы он не менял интерфейс. Таков первейший из принципов сервиса.
Как правило, в сервисориентированной архитектуре считается обязательным и принцип слабой связанности сервисов. С одной стороны, слабая связанность - это та же самая независимость интерфейса от имплементации. Интерфейс постоянен, имплементация может изменяться. И если я заменю сервис на аналогичный, то запрашивающая сторона ничего не должна почувствовать. С другой стороны, слабая связанность - это свойство протокола взаимодействия. Если я кого-то попросил, я не должен ожидать, пока он ответит, я должен заниматься своим делом. А когда сервис сможет ответить, он сам пошлет мне результат.
Наконец, важную роль играет размер сервиса. Сервис не должен плыть слишком мелко. Чтобы выполнить какую-нибудь низкоуровневую технологическую операцию, например изменить запись в базе данных, не нужно делать сервис. Сервис должен быть крупным и выполнять какие-то задачи, понятные менеджерам и бизнес-пользователям. К примеру, GetAccountBalance (получение информации об остатке на счете), CancelOrder (отмена заказа), заведение клиента в банковской системе или пополнение кредита клиента.
Еще один принцип сервисориентированой архитектуры - это многократное использованные сервисов. Сервис сам по себе может быть сложной структурой, а не только некоей жестко запрограммированной функцией. Внутри него может идти очень насыщенная жизнь. И то, что снаружи выглядит сервисом, внутри может быть составлено из десятка сервисов. Я прошу сервис сделать что-нибудь, а он, в свою очередь, сначала сам просит более мелкие сервисы, причем в определенном порядке. А эти сервисы, возможно, просят другие. Разворачивается целая хореография сервисов. Возможно, будут запрашиваться не только сервисы, но и простые куски кода. Но самое главное - когда вся эта система договорится между собой, сервис, который я запросил, вернет мне ответ.
В SOA предполагается, что ПО станет более модульным, и упростится интеграция унаследованных систем, доступ и интеграция которых будут реализованы по сервисной схеме. В модульном ПО можно использовать повторное использование сервисов - давняя мечта многих разработчиков и ключевая цель многих ИТ-менеджеров, пытающихся сократить затраты на управление ПО.
И, наконец, последняя принципиальная вещь - общая схема взаимодействия сервисов в сервисориентированной архитектуре. Выражения "сервисы взаимодействуют между собой" или "сервисы взаимодействуют через сервисную шину", по сути, совершенно неверны. В любой момент есть три участника взаимодействия: service provider, service requester и service catalog. Иными словами, в любой момент существуют запрашивающая сторона, которая в общем случае может и не быть сервисом, и сервис, который отвечает на этот запрос. То есть правильнее говорить, что есть только один сервис - тот, который отвечает. И есть еще директория или справочник, где мы можем найти информацию о сервисах.
Новая волна SOA
Заметьте, что выше не было ни слова о Web-сервисах. Сервисориентированная архитектура - это понятие, которое не оперирует технологиями. И возможностей для построения сервисориентированной архитектуры множество. Более того, у характерных для SOA методов разработки и стандартов интеграции - длинная история. Нынешняя волна SOA-технологий, которая связывается с Web-сервисами, пока еще очень молода.
SOA стало узнаваемым и популярным термином в 2003 году, когда начальный шум вокруг Web-сервисов пошел на спад по причине отсутствия существенных подвижек. Несмотря на то что концепция SOA отнюдь не нова, ее современная реализация в виде Web-сервисов смогла в корне изменить процессы разработки ПО. Хотя предыдущие поколения распределенной архитектуры программирования и обещали гибкость и повторное использование компонентов, картину всегда портила одна мелочь: интеграция обеспечивалась только при условии, что во всех компонентах используется единая объектная модель или язык программирования. В Web-сервисах такого требования нет, и они в состоянии работать, не замечая барьеров между различными средами: между Microsoft и Unix или .Net и J2EE. Точно так же как поиск Web-страницы работает одинаково на любой платформе, межпрограммные взаимодействия могут стать независимыми от платформы, если Web-сервисы будут создаваться на основе единых стандартов.
Одна из движущих сил новой волны SOA - принятие открытых стандартов, в том числе языка XML. XML-язык для компоновки сервисов, или BPEL (Business Process Execution Language), описывает порядок отбора и компоновки сервисов в потоки процессов, включая те, в которых поддерживаются транзакции. Он разрабатывается сообществом OASIS и стандартизирован. С разными оговорками и особенностями реализации BPEL принят большинством поставщиков инфраструктурных платформ и EAI-решений (Enterprise Application Integration - интеграция приложений предприятия). Таким образом, новая волна SOA также означает переносимость моделей процессов, выполняемых на разных инфраструктурных платформах и поддерживаемых с использованием инструментов проектирования любых поставщиков.
Вопросы компоновки сервисов
Однако возникает вопрос, годится ли HTTP, стандартный протокол Интернета, для компоновки сервисов. В активно продвигаемой парадигме "поиска сервиса через Интернет", HTTP неявно подразумевается. Много слов сказано по поводу того, как компании должны через брандмауэр подключаться к провайдерам Web-сервисов, находя их в UDDI-реестрах - "телефонных книгах" Web-сервисов. Однако сервисы, найденные в Интернете, пока не играют какой-либо существенной роли в бизнес-процессах компаний. Более того, у специалистов есть серьезные сомнения, что это вообще когда-нибудь случится.
Зато такие параметры взаимодействия, как надежная доставка, безопасность, восстановление транзакций и масштабируемость производительности, сегодня гораздо важнее, чем наличие протокола, поддерживающего работу через брандмауэр.
По этой причине существующие поставщики интеграционного ПО промежуточного уровня, в том числе Tibco и IBM, предлагают собственные высокопроизводительные, надежные шины обмена сообщениями в качестве альтернативного (взамен HTTP) средства компоновки сервисов. Будучи реализованы как подключаемые модули (plug-ins) в поддерживаемом многими поставщиками стандарте JMS (Java Messaging Service), эти шины обладают преимуществами проверенной архитектуры, но без необходимости ориентироваться на одного поставщика. С такими подключаемыми модулями конкурирует технология корпоративной сервисной шины (Enterprise Service Bus, ESB).
Корпоративная сервисная шина
Здесь надо сделать более подробное отступление и поговорить об архитектуре взаимодействия сервисов. Как раньше осуществлялась интеграция систем? Сначала интегрировали взаимодействия попарно (точка-точка). Такая система в принципе работает, но приложение при этом должно содержать знание о том, с кем оно разговаривает, в каком формате посылать ему вопросы и каких ждать ответов. В принципе это сделать можно, но если чуть тронуть и попытаться внести изменения в одно приложение, то за счет этих жестких связей нужно вносить изменения и во все другие приложения. Поэтому при числе связей больше трех такая система нежизнеспособна.
Потом появляется схема "звезда". Идея в том, чтобы все приложения разговаривали со специальными брокерами запросов, и уже эти брокеры сами разбирались, что делать. Эта схема взаимодействия реализована в технологии EAI. Недостаток - наличие центрального элемента и, опять-таки, трудность изменений. Потом появляется идея шины. Давайте все компоненты корпоративной системы, которые уже стали сервисами, соединим через корпоративную шину. Корпоративная сервисная шина - это некая инфраструктура, позволяющая сервисам подключаться в различных местах и передавать друг другу сигналы, вызвать сервисы и получать ответы на эти вызовы.
Сервисы бывают разные. Есть крупные бизнес-функции, "смотрящие" на пользователя. Есть сервисы, которые используются только для обращения к другим системам. Например, сервисы, поддерживающие взаимодействия портлет для портала. Существуют технологические сервисы, которые разработчикам бизнес-положений совершенно не видны, но поддерживают сервисную среду: обеспечивают доступность, следят за безопасностью и так далее. И, наверное, самый главный сервис - сервис бизнес-хореографии, или сервис, который исполняет модель. В нем содержится модель исполнения некоторого бизнес-процесса. И когда инициируется бизнес-процесс, то начинает исполняться определенная бизнес-модель, которая занимается процессом. Словом, есть различные категории сервисов, и они все связаны между собой тем, что называется корпоративной сервисной шиной.
Шина - это по определению структура распределенная, подсоединиться к которой можно в разных местах. Корпоративная сервисная шина замыкает на себя все без исключения приложения в масштабе корпорации, то есть она существует в любой точке корпорации этой инфраструктуры. При этом важно, что контроль над корпоративной сервисной шиной остается централизованным.
Важно заметить, что шина соединяет не только сервисы и их потребителей, но и любые приложения и функции, которые не являются сервисами. Ведь движение в сторону SOA - как правило, эволюционное. Если компания решила идти в этом направлении, это совершенно не значит, что у нее немедленно все приложения станут сервисами. И через корпоративную сервисную шину могут "разговаривать" как сервисы с потребителями, так и обычные приложения, которые еще не стали сервисами.
Какие функции у корпоративной сервисной шины? Во-первых, она маршрутизирует запрос на сервис и ответ на запрос. Запрашивая сервис на предприятии, я могу и не знать, кто мне ответит. Я спрашиваю шину, мне нужно, чтобы мой запрос обслужили, и шина должна подобрать мне сервис. То есть она должна маршрутизировать мой запрос тому сервису, который способен функционально обслужить его. Шина отвечает за то, чтобы правильный сервис-реквестор нашел правильного сервис-провайдера. Хотя шина может и просто послать запрос по адресу, который указан в запросе.
Еще одна функция корпоративной сервисной шины - это трансформация сообщения. Система, которую мы интегрируем, создавалась исторически, данные находятся в разных форматах. И эти форматы надо как-то привести друг к другу. Это означает, что шина должна "думать" и в этом направлении, должна понять, что вот это приложение или сервис не понимает посылаемых данных, сама переформатировать их и отправить, а потом еще сделать обратную конвертацию. То есть на шине лежат низкоуровневые операции по стыковке систем.
Следующая функция корпоративной сервисной шины - это обработка событий. Если какая-либо корпоративная система нуждается в получении информации о каких-то событиях, то эту связь также удобно организовывать через корпоративную сервисную шину. Наконец, последняя из важнейших функций корпоративной сервисной шины - обеспечение качества работы служб и сервисов. Например, система отправляет запрос на сервис, но при этом указывает, что ответ нужно получить с максимальной скоростью или минимальной затратой процессорной мощности. И шина должна решить, какой сервис может предоставить ответ, например, с максимальной скоростью.
По сути, в шине заключен технологический интеллект нашей интегрированной системы. В этом случае сервис следит за тем, чтобы исполнялись его процессы, и не задумывается о технологических нестыковках, разных форматах и т. д. Кроме того, ESB основана на отраслевых стандартах J2EE и Web-сервисов, поэтому обеспечивает более дешевую коммуникационную инфраструктуру для компоновки сервисов без привязки к какой-либо частной архитектуре интеграции.
Мощь SOA
Способность SOA составлять процессы из стандартных строительных блоков-сервисов - самая важная особенность этой технологии, если речь идет о повышении гибкости бизнес-процессов. В SOA разработчики создают комплексные приложения, связывая и организуя сервисы в потоки процессов, которые сами по себе могут предоставляться как сервисы. То, что с точки зрения бизнес-аналитика выглядит как исполняемый бизнес-процесс, ИТ рассматривает как еще один комплексный сервис, поддерживаемый инфраструктурой SOA. И это весьма существенная смена парадигмы.
Разделение монолитного приложения на различные классы сервисов, взаимодействующих через стандартную шину, приводит к тому, что подобная система очень легко модифицируется.
Например, вам нужно поддержать в ИТ-системе новую банковскую услугу. Если у вас монолитная банковская система, то вам придется вмешиваться в нее в десятках, а то и в сотнях мест. Где надо вносить изменения, реализуя банковскую систему в SOA? По сути - только в трех местах. Во-первых, надо написать новый сервис, то есть запрограммировать непосредственно новые бизнес-функции (при этом, конечно, можно и нужно использовать уже существующие сервисы). Затем описать новые правила исполнения этого бизнес-процесса в сервисе, который отвечает за хореографию бизнес-процессов, то есть согласовать его работу с другими бизнес-сервисами, согласовать новый сервис с бизнес-моделью в целом. И третье - внести изменения в сервисную шину, в технологический интеллект SOA, чтобы обеспечить взаимодействие с этим сервисом других сервисов. И все.
Вот это и есть та гибкость, которую обещает SOA. И это главное преимущество сервисориентированной архитектуры. Можно как из кубиков собирать ИТ-систему. В этих кубиках имеются стандартные стыковочные узлы, и если один кубик не годится, то можно взять другой. Таким образом, можно очень быстро изменять ИТ-систему. И второе важнейшее преимущество - это снижение затрат, потому что один и тот же кубик можно использовать многократно. Если есть, например, сервис добавления нового пользователя, то он будет использоваться в любых приложениях, поддерживающих тот бизнес-процесс, где требуется добавление пользователя.
Кроме того, превращая концепции сервисов и процессов в неотъемлемую составляющую разработки приложений, SOA превращает гибкость и быстроту внесения в бизнес-процессы в необходимое условие корпоративной ИТ-инфраструктуры. Существующие сегодня стандартные средства проектирования SOA, хотя и неразвиты еще во многом, но уже многократно ускоряют и упрощают создание модели взаимодействия сервисов - это так же просто, как нарисовать блок-схему сервисов. Те же средства позволяют превратить полученную модель в исполняемый бизнес-процесс.
Наконец, откуда берутся эти самые сервисы? Можно создавать сервисы с нуля. Сегодня обострилась конкуренция между серверами приложений ведущих поставщиков инфраструктурных решений, таких как IBM, Microsoft, BEA и Oracle, в области инструментальных средств для быстрого создания нестандартного кода, который может развертываться как повторно используемые Web-сервисы. Популярно также альтернативное решение - "инкапсулирование" существующих систем с использованием компонентов промежуточного уровня, называемых интеграционными адаптерами и предоставляющих функциональность в виде Web-сервисов без нестандартного кода. Третий способ создания сервисов состоит в простом приобретении их у поставщиков корпоративного ПО. Новые версии систем автоматизации приложений, таких как SAP и Siebel, поставляются как наборы фирменных Web-сервисов, готовых для создания разнообразных сочетаний. Ну и, наконец, вы вправе скомпоновать сервисы, реализованные всеми перечисленными способами, в едином бизнес-процессе. И именно в этой универсальности мощь SOA.
Функциональная полнота
Мощь SOA велика, однако остаются определенные сомнения в том, позволит ли компоновка охватить весь спектр функциональности корпоративных приложений и будет ли оправданным для компаний или ИТ-подразделений предоставлять такие приложения, как Web-сервисы. Сможет ли компоновка сервисов конкурировать с функциональным многообразием монолитных корпоративных приложений, таких как ERP, или, с другой стороны, удастся ли корпоративные приложения эффективно преобразовать в наборы повторно используемых Web-сервисов?
Кому, как не SAP, самому крупному поставщику корпоративного ПО, знать ответ на эти вопросы? В SAP полагают, что ответ на оба вопроса положительный, но в компании все равно считают: отдельные Web-сервисы слишком мелки, чтобы служить строительными блоками корпоративных бизнес-процессов. Из чего, например, состоит вроде бы простая функция отмены заказа? Это отправка клиенту подтверждения, затем удаление заказа из плана производства, освобождение выделенных в связи с заказом материалов, отмена выставленного счета и изменение состояния заказа во многих бизнес-системах. SAP называет такую функцию корпоративным сервисом предприятия, стандартным строительным блоком бизнес-уровня, относящимся к сквозному процессу, который создан за счет компоновки множественных низкоуровневых сервисов.
Сейчас SAP преобразовывает свои ранее монолитные приложения в корпоративные сервисы, используя платформу NetWeaver, и создает наборы составных, основанных на сервисной архитектуре приложений, которые называет xApps. В архитектуре SAP Enterprise Services Architecture предусмотерны средства создания корпоративных сервисов, компоновки их в бизнес-процессы с использованием каркаса SAP Composite Application Framework и затем выполнения созданных процессов на сервере приложений NetWeaver.
Стадии принятия SOA
Как же начать продвижение к сервисориентированной архитектуре? Многих может смутить тот маркетинговый шум, который поднялся вокруг сервисориентированной архитектуры. Конечно же, она не появится на предприятии сразу, это последовательный и эволюционный процесс. И существуют различные стадии продвижения к SOA.
Первая стадия - это анализ ИТ-системы предприятия и декомпозиция вашей предметной области. Сначала анализ производится сверху вниз, когда ИТ-директор детально, до мелких функций выясняет, что нужно бизнесу. Вторая стадия - анализ снизу вверх, когда ИТ-директор уточняет, что есть на предприятии, какие функции повторяются, что с критическими функциями и можно ли их "обернуть" интерфейсом. Наконец, третья стадия - спецификация, когда ИТ-директор категоризирует свои сервисы и создает общую картину сервисов предприятия. И четвертая стадия - это появление веб-сервисов на предприятии.
Пять компонентов SOAС точки зрения логической архитектуры функционирования SOA можно выделить пять важных компонентов.1. Интеграционная среда. Традиционные программы исполняются и компонуются с помощью обмена сообщениями между внутренними операциями. Для поддержки сообщений разработана общая семантика, например, модели данных, и различные алгоритмы. SOA совершенствует эту инфраструктуру и семантическую поддержку, таким образом существенно сокращая барьер для интеграции и повторного использования программ. 2. Синтезированные вычисления. Любой бизнес-процесс затрагивает множество корпоративных систем (среди них унаследованные системы, ERP и CRM), настольных приложений (Microsoft Excel и Word) и коммуникационных систем (e-mail, телефон, факс). Например, для обработки запроса по возможности продления кредита обычно требуются телефонные звонки и обмен электронными сообщениями между службами работы с клиентами, продаж и бухгалтерии. Вычислениям по обслуживанию кредита требуются данные и процессы ERP и CRM-систем. Для обеспечения эффективной работы бизнес-процессов на предприятии требуется поддерживать некий синтез вышеперечисленных приложений. 3. Таксономия абстрактных сервисов (Abstracted service taxonomy, AST). AST -- это модель бизнес-системы и функциональностей, реализованная в виде решетки сервисов. AST решает три основные проблемы: отсутствие доступа к функциональности бизнес-систем, сложность управления избыточной и несовместимой информацией и выполняемыми функциями систем, а также невозможность применения функций системы для всех или наиболее значимых корпоративных бизнес-процессов. 4. Мониторинг событий и бизнес-деятельности (Business activity monitoring - BAM). Обработка событий -- необязательное, но очень важное дополнение к сервисам. Если произошло событие -- например, задерживается заказ на погрузку, -- основанная на SOA система может инициировать некоторые действия, запустив другие сервисы. Через сервисы осуществляется прямой доступ к другим интеллектуальным ресурсам предприятия, которые могут быстро проанализировать оправданность тех или иных действий. Все аспекты работы SOA должны отображаться событиями. 5. Процессы с полным жизненным циклом. Так как практика создания ПО перешла от написания конкретного кода к монтированию сервисов, процессы стали отличаться от своих предшественников. Внутренняя работа процессов, созданных классическим написанием кода, в основном непонятна и ненадежна. Процессы, созданные благодаря сервисам с хорошо определенными интерфейсами, существенно более предсказуемы и легки для понимания. Более устойчивая структура этих процессов в дополнение к новым программным продуктам, созданным для их использования, способствует появлению нового вида процессов, которые и получили название "процессов с полным жизненным циклом". |
