На прошедшем Саммите корпоративных архитекторов 2007 старший архитектор технического отдела компании CA Inc., являющейся поставщиком программных средств по управлению ИТ, Пол Липтон открыл свою презентацию «Новые возможности синергии в области SOA: как скоординировать управление рабочим циклом, сортировку и систему безопасности» словами: «Сейчас стало как никогда очевидно то, что мы купились на якобы новизну SOA. Как известно, новое – это хорошо забытое старое, и SOA – это всего лишь переосмысление ценных идей, которые возникли еще в 80-х.» Далее речь пошла о том, что вряд ли найдутся поставщики, не имевшие дело со стандартами XML, а расширяемость и масштабируемость языка XML – как раз и стали тем революционным фактором, который расширил наши горизонты.

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

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

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

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

Как говорит Липтон, «чем больше клиентов использует ваш сервис, тем больше осложняется система. Так что малейшая ошибка или сбой отражаются на всей системе. Разве новые клиенты, вторично использующие сервис, сообщают о том, что они его используют? Конечно же, нет, это глупость».

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

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

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

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

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

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

Корпоративная сервисная шина

Липтон ссылается на то, что поступает большое количество жалоб на такой компонент SOA как корпоративная сервисная шина (ESB). По его словам, этот термин вошел в употребление в сфере SOA из жаргона, существующего у программистов.

«Шина – это важнейший компонент персонального компьютера, аналогичным образом и SOA не может функционировать без ESB!»

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

«Главная проблема ESB в том, что для нее не существует стандартов. К каким бы системам стандартов мы ни обратились (OASIS и др.), мы нигде не найдем стандартов для ESB… Лучше всего она функционирует, если является единственной шиной в системе, так сказать, единственным автобусом в городе. Однако SOA работает со множеством систем. Важно не переоценивать значение ESB, допускайте возможность, что эта часть межплатформенного ПО вам может не понадобиться. Каждая корпоративная шина подобна центру вселенной. В тот момент, когда вы привязываете все ваши политики безопасности к одной шине, вы обрекаете свою SOA на провал».

Липтон добавил, что у разных ESB разный формат лог-файлов (файлов регистрации и протокола). «Неужели в случае проверки или составления отчетности вы будете изучать все эти форматы? Я в этом сомневаюсь».

Управление

Пол Липтон не обошел стороной и проблему управления SOA, назвав употребление «красивого слова «управление»» в данном контексте «несколько необоснованным».

По его словам, все управление SOA обычно осуществляется на уровне разработки, а именно – работы с XML-документами и кодом.

Липтон пояснил, что «программные средства управления должны хорошо интегрироваться в платформу разработки (например, Visual Studio, NetBeans и др). И здесь тоже не обходится без политик: во всех средствах управления предусмотрено множество механизмов сканирования. Так что лучшим выходом будет использование таких программных средств управления, которые способны распознавать коды как на языке Java, так и на COBOL».

Специалисты, работающие над проблемой управления, в основном концентрируют свое внимание на стандартах кодировки и на метаданных. А за красивой фразой «управление в режиме реального времени» скрывается всего лишь обычное слово «безопасность». Так считает Пол Липтон, старший архитектор технического отдела компании CA Inc.

По материалам сайта www.adtmag.com

Комментарии