Это не панацея от бед! О чем забывают при создании SOA-систем

 ВЛАДИМИР ЭНГЕЛЬС, выпускник ЮРТУ. Участвует в проектировании и реализации распределенных и SOA-систем. Ведущий системный архитектор SOA/BPM в московском представительстве компании Oracle

Это не панацея от бед!
О чем забывают при создании SOA-систем

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

А нужно ли вообще SOA бизнесу?

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

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

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

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

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

Для многих российских компаний сложилась уникальная ситуация. В России не так сильно, как в других странах, актуален «груз унаследованных систем». Использование инноваций – это единственный шанс стать технологическим лидером в свой отрасли.

Этап подготовки к проекту

Еще до инициализации проекта необходимо определиться с некоторыми вопросами.

Место SOA в стеке технологий

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

Но ничто не бывает бесплатно. За использование промежуточного ПО необходимо платить налог – либо финансами, либо производительностью, либо аппаратным обеспечением, либо чем-то другим. И это важно понимать, вступая на путь SOA.

Почему вокруг SOA так много названий, технологий и продуктов?

Еще одно важное отличие промежуточного ПО от других видов ПО – большой спектр решаемых задач. Отсюда появление большого количества компонентов и технологий относящихся к промежуточному ПО. И это число постоянно растет с развитием предметной области. Но далеко не все технологии и компоненты нужны в одном проекте. На практике для каждого решения желательно подбирать конкретный состав продуктов и технологий. Проблему выбора нередко серьезно затрудняет «маркетинговый шум».

Технологии ради технологий

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

SOA и моделирование бизнеса

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

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

А сколько это стоит?

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

Какова будет производительность?

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

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

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

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

Перечислим только некоторые проблемы такого подхода:

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

Как организовать разработку SOA-решений?

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

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

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

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

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

Распределение времени и средств по этапам складывается примерно следующее (см. таблицу 1).

Таблица 1. Оптимальные этапы реализации SOA-решений

 Как можно видеть, такой подход удобен всем:

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

Этап проектирования

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

Модель мастер-данных

Среди всей совокупности данных, используемых в компаниях, есть определенная специфичная категория (15-20% от всего объема), которая используется как «язык информационных систем», лежащий в основе самого бизнеса компании. Такие данные называют мастер-данными. Первая задача, стоящая перед архитектором (или аналитиком) при построении и/или развитии информационной системы, выделить (идентифицировать) мастер-данные и создать на их основе модель мастер-данных. Модель мастер-данных включает в себя следующие компоненты (но ими не ограничивается):

• определение типов данных (бизнес-объектов, справочников, вспомогательных данных и технологических данных);
• определение событий;
• определение исключительных ситуаций;
• определение интерфейсов.

В SOA-системах модель мастер-данных – это межсистемный язык, со своим, как правило, очень длительным, жизненным циклом и желательно с версионностью (смотрите, например, «Методы работы с моделью мастер-данных в SOA-проектах», http://soa.it-consultants.ru/?q=node/4). От того, насколько тщательно спроектирован этот язык, очень многое зависит, так как модель данных будет непосредственно использоваться во всех без исключения прикладных проектах.

SOA-системы: распределенные и многопоточные

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

Взаимодействие с внешним миром

В параллельных системах часто возникает еще одна проблемная область – организация взаимодействия с внешней средой. И поскольку логика такого взаимодействия может быть очень сложной, то имеет смысл выделить отдельный класс интерфейсных задач (сервисов), которые будут инкапсулировать такую логику. Хорошим примером такого подхода может служить набор из шести веб-сервисов продукта Oracle SOA Suite для организации интерфейсного взаимодействия с пользователем – Human Workflow Services.

Проблема взаимного исключения

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

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

Интерфейс с пользователем

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

Этап разработки

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

Этап внедрения

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

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

Этап эксплуатации

Рассмотрим важные моменты при эксплуатации проекта.

Нужно ли гибкое конфигурирование и настройка в SOA-решении?

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

Самые известные средства данного класса решений – это поддержка бизнес-правил, изменение маршрутизации запросов средствами шины сервисов и формирование «на лету» цепочек утверждения документов. Все эти средства есть и поддерживаются, но они требуют более чем тщательного и продуманного подхода к использованию. Только представим себе, к каким последствиям может привести неправильное бизнес-правило о предоставлении скидки?! А ведь большинство таких ошибок не будут видны без специальных средств диагностики.

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

«Сильное взаимодействие» или «Слабое взаимодействие»

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

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

24*7 или 8*5?

Практически каждое техническое задание, где есть требование высокой готовности, требуется готовность на уровне 24*7. Причем одни хотят высокую готовность, выражаемую как 99,9, другие как 99,99, а некоторые и как 99,9999. Получается своего рода негласное соревнование. А ведь конечная цена SOA-решения в зависимости от числа этих девяток увеличивается по экспоненциальному закону.

При анализе же задачи часто убеждаешься, что заказчику достаточно и скромной величины 8*5. В крайнем случае, с учетом шестидневной рабочей недели и при работе во всех часовых поясах России это будет 16*6. Конечно же, режим 24*7 нужен для некоторых компаний, но уж точно не для всей SOA-системы. И здесь очень важно еще на этапе проектирования провести группировку участков системы, к которым предъявляются различные требования по уровню поддержки высокой готовности.

Этап вывода из эксплуатации

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

Таблица 2. Продукты Oracle для всех этапов проекта