Хью Тейлор

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

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

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

Цель: Оптимизация бизнеса посредством SOA

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

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

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

У цели: путь к управлению SOA

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

Но, тем не менее, гибкость имеет свою темную оборотную сторону: те самые гибкость и открытость, к которым мы так стремимся, могут внести хаос в Web-сервисы и сделать их ненадежными. А разве можно добиться повышения доходов и сокращения издержек благодаря повторному использованию таких потенциально неуправляемых механизмов, как эти Web-сервисы?

Как это ни парадоксально звучит, путь к успешной SOA, приносящей прибыль, лежит через жесткое управление. О необходимости строгих, но гибких рычагов осуществления контроля говорил еще Гарри Труман. Согласно его знаменитому высказыванию, «Если вы хотите жить в Республике, то лучше голосуйте за демократов». И только когда вы будете полностью уверены в том, что ваши Web-сервисы хорошо контролируются, грамотно управляются и что их безопасность тщательным образом обеспечивается, можно будет с уверенностью сказать, что от их совместного использования будет больше пользы, чем проблем. Только тогда свобода и гибкость будут оправданы.

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

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

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

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

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

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

В эффективности контроля заинтересованы все контролирующие инстанции самых разных уровней – от низшего до высокого, имеющиеся в вашей компании и в компании-партнере. В ведении контролирующих инстанций высшего уровня находятся финансовые положения, информация о которых необходима Комиссии по торговле ценными бумагами, и работа ваших внутренних контролирующих процедур (контролей), которая должна осуществляться в соответствие с требованиями статей 302 и 404 акта Sarbanes-Oxley. Закон Sarbanes-Oxley был принят после ряда корпоративных скандалов и изначально был направлен на обеспечение прозрачности деятельности американских компаний, однако с июля 2005 года ему должны следовать и все неамериканские компании, чьи акции представлены на американском фондовом рынке. Так что это актуально и для нас.

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

Замыкая круг

Если вы можете управлять SOA, следовать политикам и контролировать их – и все это в режиме реального времени, можно смело утверждать, что ваша SOA достигла необходимого уровня зрелости. Возможность осуществить все вышеперечисленное – это критерий определения степени зрелости SOA. Если вы хотите добиться успеха, ваша SOA должна быть хорошо управляема в режиме реального времени. Разумеется, этого непросто добиться, поскольку сами интерфейсы Web-сервисов и тот участок, который их соединяет непосредственно с корпоративными сервисными шинами (ESB), могут быть недоступны многим встроенным пакетам, осуществляющим управление ESB, не говоря уж о том, что обеспечить взаимодействие ESB-шин от разных вендоров – это очень сложная задача. Так что даже если вам удалось преодолеть эти трудности и наладить эффективное управление SOA на своем предприятии, перед вами будет стоять не менее трудоемкая задача – «замкнуть круг».

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

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

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

Заключение

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

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

По материалам sys-con.com

Комментарии