Путь сервисно-ориентированным архитектурам открыт
Последнее олицетворение Web-сервисов — сервисно-ориентированная архитектура (SOA) — обсуждается уже давно. И велико же было удивление ИТ-сообщества, когда корпорации Cisco, EMC и ряд других производителей сетевого оборудования объявили о своем приходе в бизнес SOA.
В конце концов, архитектура SOA сама по себе полна неясностей, но оказавшись в общем инфраструктурном «котле», она может стать воистину «шарадой в загадке, покрытой тайной». Достаточно сказать, что SOA постоянно путают с одним из многочисленных приложений, связанных с интеграцией B2B, предоставлением ПО в качестве услуги, организацией корпоративных потоков работ…список заблуждений легко продолжить. На самом деле это приложение, поставляемое в виде сервиса, и точка.
И тем не менее ограничиваться столь узким представлением нельзя. Дело в том, что у многих (если не у большинства) организаций нет достаточного стимула для развертывания в соответствии с определением архитектуры SOA в масштабе всего предприятия. А если расширить понятие сервисно-ориентированной архитектуры, включив сюда инфраструктуру, осведомленную о приложениях, то ценность SOA заметно повышается.
Именно переход на SOA как для представителей основного бизнеса, так и для ИТ-служб дает возможность ускорения и удешевления разработки приложений, позволяет снизить расходы на интеграцию. Отпадает необходимость писать заново уже существующий компонент или приложение, их можно просто вызвать из разрабатываемой вами программы, избежав, таким образом, избыточности. В ходе реализации аналогичных процессов вам, вероятно, уже удавалось интегрировать две системы с относительно небольшими затратами.
Однако представителям бизнеса такие преимущества в краткосрочной перспективе могут показаться явно недостаточными. Действительно, если корпоративная архитектура SOA еще не развернута, то на разработку приложений, отвечающих сервисно-ориентированной концепции, придется затратить гораздо больше усилий. Трудность заключается в том, что инициативы, направленные на создание дополнительных ценностей для организации, не соответствуют обычной процедуре разработки приложений. В общем случае представители бизнеса просят сотрудников ИТ-службы реализовать какую-то вполне конкретную функциональность и создать набор описывающих ее спецификаций. При этом речь не идет о других приложениях, которые получат возможность обращаться к тем же сервисам, как это происходит при проектировании архитектуры SOA.
Следовательно, для построения архитектуры SOA необходимы весомые причины, затрагивающие интересы предприятия в целом. И, кажется, одна из таких причин лежит на поверхности. Чем вынуждена заниматься сегодня в ужасной спешке практически каждая организация? Конечно же, обеспечивать соблюдение предписаний нормативных актов. Требования закона Сарбейнса-Оксли к системам хранения и выборки информации плюс требования к безопасности, предъявляемые законом об отчетности и безопасности медицинского страхования (HIPAA), заставляют компании жестко выстраивать бизнес-процессы и формировать специальную инфраструктуру, внедряя системы хранения и обеспечения безопасности. Осведомленность этой инфраструктуры о приложениях объективно растет.
В последние годы явилось новое поколение устройств обеспечения безопасности с поддержкой технологии XML, которые работают на уровне приложений и, проводя глубокий анализ пакетов, блокируют подозрительный трафик. Это оборудование выпускается такими компаниями, как F5, Forum Systems и DataPower. Впрочем, производители уже сейчас выходят за рамки создания сетевых экранов на основе XML. Разработчики DataPower, например, предлагают вертикальный инструмент, связывающий безопасность Web-сервисов с финансовой схемой XML.
А инициатива Cisco Aon должна найти воплощение в анонсированном новом семействе маршрутизаторов с поддержкой XML. Анализируя трафик XML в режиме реального времени, подобные устройства смогут классифицировать информационное наполнение и обеспечивать его маршрутизацию в нужное место, например, в хранилище EMC Centerra для проведения архивирования.
Представьте, что инфраструктура, осведомленная о приложениях, обеспечивает четкое и прозрачное соответствие определенным техническим условиям, сводя к минимуму затраты на поддержку. Руководители большинства предприятий многое бы отдали за такую возможность.
Ясно, что реальное продвижение SOA предполагает людей, которые понимают ценность инфраструктуры, осведомленной о приложениях и связанной с архитектурой SOA. Ведь в долгосрочной перспективе именно она является наилучшим решением, обеспечивающим выполнение требований нормативных актов. Конечно, для того чтобы эта система работала, корпоративные приложения должны стать составной частью SOA. Не кажется ли вам, что в данном случае уже не собака крутит хвостом, а хвост собакой? Возможно. Но страх зачастую оказывается лучшим стимулом, и если условием соблюдения нормативных актов является предварительное создание необходимой инфраструктуры, пусть будет так.
Эрик Кнорр - ответственный редактор журнала InfoWorld, eknorr@pacbell.net
Три основные проблемы, с которыми сталкивались компании, пытающиеся получить максимальную отдачу от использования приложений уровня предприятия
Eric Knorr. Building the Compliance Infrastructure. CIO Magazine. July 15, 2005