Сервис-ориентированная архитектура сейчас является одной из самых обсуждаемых тем в ИТ-сфере. Даже выпущена очередная книга «Для чайников» по этой теме: SOA – это способ построения ИТ-системы, SOA связывает приложения по сети с помощью общего протокола коммуникаций, позволяя компаниям повторно использовать старое ПО, зачастую, интегрируя их с помощью web-сервисов. А некоторые аналитики предсказывают, что более двух третей ИТ-отделов к следующему году будут использовать SOA полностью или частично. В данной статье, вместе с аналитиками, мы рассмотрим шесть острых вопросов, с которыми сталкиваются компании при выборе SOA-решений.
[Перепечатка материалов 12NEWS.ru разрешается только с предварительного согласования с редакцией или автором. Если вы читаете этот материал на другом ресурсе, пожалуйста, сообщите нам об этом editor@12news.ru]
Ашок Кумар, сотрудник Avis Budget Group, говорит, что у него это получается. Его фирма начала использовать SOA около двух лет назад в части своих компаний, где намеревалась вместе с партнерами открыть новые каналы по организации путешествий. «Теперь они могут напрямую работать с нами, не обращаясь к посредникам. Так что и они, и мы экономим немного денег. Благодаря SOA, стоимость привлечения новых партнеров сейчас снизилась до нуля», -говорит Ашок Кумар, работающий в Нью-Джерси руководителем отдела обслуживания архитектуры информационных систем.
По мнению Ашока Кумара, теперь его фирма может привлечь партнера за один день, вместо месяца, потому что с SOA - это только вопрос настройки сервиса: не нужно выполнять крупные изменения в ПО. «Когда мы начинали, стоимость привлечения нового партнера колебалась от 40 до 50 долларов, теперь она составляет 3-4 доллара», - сообщил он.
Любая компания столкнется с затратами на внедрение SOA, но многие ИТ-эксперты говорят, что в долгосрочном прогнозе затраты уменьшатся. Аналитик в данной области Джудит Харвиц, основной автор книги «Сервис-ориентированная архитектура для чайников», говорит, что SOA нельзя рассматривать в качестве быстрого способа вернуть инвестиции.
Джудит Харвиц отмечает, что традиционные подходы к созданию приложений предполагают, что вы начнете с нуля и разработаете что-то для решения определенной проблемы. SOA позволяет компаниям быть гибкими и органично реагировать на крупные изменения. Компания может несколько месяцев после ввода в действие SOA не видеть заметной выгоды, но если компания неожиданно расширится, то «произойдет серьезное изменение в возможности справиться с этим изменением, отреагировать должным образом и обеспечить нужным ПО», - говорит он.
«Сопутствующий вопрос, который задают люди: «Сколько денег тратят организации на SOA», - утверждает старший аналитик компании Forrester Research Ларри Фалтон. «На этот вопрос очень сложно ответить, т.к. пять лет назад я собирался создать ERP-систему, и сейчас я собираюсь построить ERP-систему с использованием SOA. Мне нужно $5 млн. на проект, значит ли это, что $5 млн. требуется на SOA? Нет, это не так. $5 млн. требуется на бизнес-решение в целом», - говорит он.
Майк Уэст из компании Saugatuck Technology говорит, что есть два вида отдачи от SOA. Первый – это когда ИТ-отдел может уменьшить количество денег, которое тратится компанией на обеспечение сервисами. Уэст полагает, что адаптация SOA все еще находится на ранних этапах, и что, возможно, только 10-15% компаний используют SOA и экономят таким образом. И еще меньше компаний используют SOA, чтобы увеличить прибыль», - говорит он.
Система PayPal, принадлежащая Интернет-аукциону eBay, может служить таким примером. Мэтью Менгеринк, вице-президент по технологиям, сообщил, что PayPal использует SOA для обеспечения внешних разработчиков инструментами, необходимыми для подключения в режиме on-line магазинов к платежной системе PayPal, для обмена деньгами между покупателями и продавцами. PayPal обеспечивает группу из 240 000 разработчиков с помощью шестнадцати API-функций.
«Задача найти эксперта по SOA усложняется тем, что люди в мире ИТ по-разному представляют себе SOA», - говорит Мэтью Менгеринк. Лучший выход – это научить своих сотрудников, считает он, потому что идеи и технологии, лежащие в основе SOA, не так сложны. Конечно, легче, если вы внедряете SOA в такой организации как PayPal. «Если взять действительно крупную компанию, там вам скажут, что такое SOA, - говорит Мэтью Менгеринк, - тот, кто располагает ресурсами, может рассказать, что такое мир».
«SOA требует другого склада ума по сравнению с традиционными подходами к построению ИТ-инфраструктуры, - говорит Ашок Кумар. - Многие умеют программировать на Java и понимают, как сделать один web-сервис, но свести все вместе в сервис-ориентированной архитектуре сложно. Многим приходится тяжко с данной задачей, поэтому мы стараемся обращаться к внешним поставщикам. И даже в этом случае сложно найти талантливого человека», - говорит он.
«По правде говоря, я думаю, что Microsoft сейчас ищет ключ к SOA. В данный момент их стратегия SOA несколько таинственна. До нее сложно докопаться. Я думаю, они поняли, что SOA - это существенная сила на рынке», - говорит Фалтон.
От поставщиков, относящихся к SOA серьезно, ожидают сейчас обеспечения надежной системы сообщения на предприятии (ESB). Джудит Харвиц описывает ESB как «мозговой центр сообщения» для сервисов в SOA, действующих как посредник между компонентами SOA, сервисами инфраструктуры и бизнес-процессами. ESB должны быть многосторонними, пишет он в книге «SOA для чайников», соединяя различные типы связующего ПО, хранилища определений метаданных, регистров и интерфейсов сервисов. По мнению Ларри Фалтона, в отличие от IBM и BEA работы Microsoft над ESB менее открытые.
В книге «SOA для чайников» Джудит Харвиц и соавторы перечисляют семь других продуктов Microsoft, которые поддерживают SOA. В том числе Microsoft Windows Server, платформа инфраструктуры для связи приложений, сетей и web-сервисов; Microsoft.NET, среда разработки для построения приложений и web-сервисов; и Windows Communication Foundation, набор технологий обмена сообщениями, который позволяет компонентам SOA общаться друг с другом и упростить разработку и запуск системы.
Ларри Фалтон говорит, что Microsoft идет в ногу со временем, поддерживая web-сервисы и сервисные интерфейсы в целом.
Майк Уэст менее оптимистичен, когда его спрашивают, есть ли у Microsoft ключ к SOA. «Не совсем, - он отвечает. - У SOA открытые стандарты, которые позволяют использовать продукты поставщиков более-менее взаимозаменяемо. Подходы Microsoft к web-сервисам более ориентированы на продукты Microsoft.»
По мнению Джудит Харвиц, Microsoft не удалось решить ряд вопросов, например, таких как управление и предоставление клиентам механизма для размещения отдельных сервисов, - «У них интересные мысли и планы по этому поводу, - говорит она. - Я не думаю, что они уже продумали все до конца».
«Несмотря на все свои преимущества, можно поспорить, что SOA нагрузит вашу сеть увеличенными требованиями и сложным сетевым управлением и операциями», - пишет консультант Дэвид Якобс в статье для ИТ-профессионалов. «Так как каждое приложение в SOA состоит из множества отдельных компонентов, сбой в любом месте сети может уронить все приложение, - отмечает он. - Ваши действия по мониторингу сети и немедленная реакция при возникновении проблем после внедрения SOA становятся более важными».
Avis Budget использует SOA для сервисов клиентов, включая: резервирование, проверку и отправку уведомлений. Пропускная способность хорошо удовлетворяет потребности внутренних пользователей, но Ашок Кумар говорит, что они столкнулись с проблемой обеспечения достаточной пропускной способности для удаленных пользователей.
Джудит Харвиц отмечает, что SOA приносит проблемы масштабируемости, в зависимости от того, как далеко требуется проникнуть за пределы файервола компании и в системы клиентов, поставщиков и партнеров. «Я не думаю, что влияние на сеть имеет такое значение, если у вас распространенное приложение, и требуются возможности коммуникаций», - говорит она. И добавляет, что ESB поможет упростить коммуникацию среди компонент и сервисов.
«Поставщики технологии SOA больше сконцентрировались на увеличении возможностей и функций, чем на возможности масштабирования, и пользователи расплачиваются за это», - отвечает консультант Дэвид Линтикум. Он рекомендует моделировать деятельность и тестировать реальные сценарии перед тем, как запустить SOA. «Вы не знаете, как система будет вести себя до того, как подвергнете ее испытанию», - пишет он. Также он рекомендует добавить мощности источнику каждого SOA-сервиса для улучшения производительности.
Ларри Фалтон отмечает, что всегда есть место для расширения сети. «Я всегда могу построить систему, которая работает лучше, если хочу посылать двоичные данные, а не преобразованные, например, с помощью XML. Но смогу ли я их создавать и изменять так же быстро? Мы всегда запрашиваем оборудование и операционные системы и оболочки, которые поддерживают все более и более высокие уровни абстракции… Действительно ли более эффективно делать то же самое более тяжелым способом? Сколько процессоров сейчас меньше гигагерца? Немного. Мы позволяем компьютерам выполнять за нас какую-то работу в процессе жизненного цикла приложения, так что мы можем создавать их быстрее».
ИТ-руководство в Avis Budget, когда занялись SOA, полагало, что безопасность – это второстепенная забота. Теперь безопасность компании выросла в одну из важнейших задач. Использование SOA открыло новые каналы с партнерами, и компании необходима уверенность, что важные данные, такие как - информация о водительском удостоверении и кредитной карте - хорошо закодированы внутри базы данных и во время передачи.
Управление защитой информации – одна из ключевых проблем, с которой приходится сталкиваться внедряющим SOA.
Майк Уэст, сотрудник Saugatuck Technology, писал в своем исследовании, опубликованном в прошлом году, что безопасность традиционных приложений «неэффективна и неповоротлива», когда дело касается SOA, потому что защита и права доступа, включая пароли и полномочия, сильно отличаются в зависимости от приложений. Он пишет, что один только вход в систему с паролем для больших организаций не подходит из-за плохой масштабируемости и осложняется задачами секретности и конкуренции при обращении к среде SOA среди бизнес-партнеров.
Меньше проблем вызывает интегрированный подход к управлению полномочиями, который работает по принципу доверия источнику информации и использует язык разметки защиты данных (SAML). Запросы для контроля доступа к информации могут быть закодированы в запросах браузера или включены в транзакции web-сервисов.
«В этом случае сервер управления полномочиями выдает информацию о пользователе и правах доступа, которые требуются приложению, - пишет Майк Уэст. - Приложению, сервису или закрытому интерфейсу сервисов не нужен будет доступ к файлам или полномочия конкретного пользователя, потому что ему нужно будет только знать и доверять информации и источнику информации». Он же описывает границы ИТ-безопастности как «пористую мембрану», позволяющую данным путешествовать среди широкого множества бизнес-партнеров, клиентов и прочих лиц, не являющихся сотрудниками. У SOA есть собственные уязвимые места, которые требуют адекватного управления на множестве фронтов внутри предприятий и при общении с поставщиками.
Более оптимистичным взглядом отличается Мэтью Менгеринк, который говорит, что на самом деле вопрос безопасности становится проще после внедрения SOA. Но это применимо в сравнении с огромной задачей, с которой столкнулась система PayPal по безопасным платежам через web. «SOA в PayPal отдельно обеспечивается разработчиками», - отмечает он.
Вопрос безопасности – это проблема, по меньшей мере, части ИТ-руководителей, внедряющих SOA, но это не единственная неизвестная область, с которой вы столкнетесь при построении сервис-ориентированной архитектуры. Одним из неисследованных уязвимых мест SOA, по мнению Ларри Фалтона, является проблема обеспечения единства представления данных и доступа к данным через множество сервисов.
Повторное использование старого ПО для новых бизнес-процессов – это отлично, но обнажает ахиллесову пяту большинства предприятий: их клиентская база со временем видоизменилась.
Приводя пример, Ларри Фалтон отмечает, что пять лет назад, компании, работающие в области связи, представляли своего клиента человеком, проживающим в квартире или доме, куда они присылали счет. «Сегодня вы скорее скажете, что клиент – это некто, кто получает счет для нескольких помещений. Это небольшое изменение, но старые приложения не смогут с ним справиться… Для того, чтобы все блоки, из которых построены сервисы, могли быть легко управляемыми, чтобы проводить изменения быстро, необходимо выяснить, как объединить данные. Люди все еще борются с этой задачей». Есть около 15 поставщиков, которые предлагают хорошую ESB, но достижения области в управлении данными куда более скромные.
Проблема защиты средств на вложения в новые проекты SOA – это другое потенциальное уязвимое место. Даже, несмотря на то, что SOA может сэкономить деньги компании в долгосрочном прогнозе, Ашок Кумар говорит, что убедить людей, распоряжающихся деньгами, заглядывать в будущее крайне сложно.
Джудит Харвиц утверждает, что неизвестные стороны SOA находятся «не в области технологий». Она говорит, что проблемы вызывают люди, которые развивают технологии, особенно, когда они не взаимодействуют с людьми из бизнеса или не думают о том, в каких сервисах на самом деле нуждается бизнес.
Ларри Фалтон говорит, что темных сторон у SOA меньше, чем воздействий, оказываемых SOA. Одно из воздействий - это необходимость закупать технологии для поддержки SOA и замешательство, в которое можно прийти, когда понимаешь, сколько существует продуктов, из которых можно выбирать.
By Jon Brodkin,
Аналитик JavaWorld
Перевод и адаптация: Алексей Маринин
12NEWS©
© Издание 12NEWS (ИП Маринин А.Л.), 2007