Газета
 04 декабря 2006, 00:00   1612

Подводные камни SOA

Интеграция корпоративных бизнес-приложений на основе SOA.
Автор: Кирилл Перов
Интеграция корпоративных бизнес-приложений на основе SOA.

Если вы управляете крупным предприятием, располагающим собственным ИТ-отделом, то для вас автоматически становятся актуальными проблемы, с которыми сталкиваются специалисты при запуске новых бизнес-приложений. Интеграция корпоративных бизнес-приложений на основе SOA является наиболее современным подходом, но таит в себе и риски. Представим следующую, довольно распространенную, ситуацию. В силу различных причин, среди которых можно назвать смену менеджмента или смену приоритетов развития, слияние/разделение компаний, устаревание бизнес-приложений, отсутствие универсального приложения, полностью удовлетворяющего потребности всего предприятия, через 5–10 лет своего развития крупный бизнес сталкивается с тем, что разные подразделения и отделы используют программное обеспечение от различных поставщиков, возможно, даже на различных платформах. К чему это приводит? Наглядный пример из банковской отрасли: пусть некоторое приложение организует работу с сервисом пластиковых карт, а другое — со всеми счетами клиентов кредитной организации. Необходимо каким-то образом согласовывать получаемую информацию, причем делать это как синхронно, так и асинхронно. Конечно, возможна совместная работа этих двух приложений, но кто знает, сколько таких систем будет еще? А можно ли так же реализовать совместную работу сразу трех систем? На практике это приводит к необоснованному увеличению бюджета проекта, и зачастую конечный результат мало кого устраивает. Причиной этого является тот факт, что данная задача не тривиальна и требует либо всех ресурсов большого ИТ-отдела в течение длительного времени, либо привлечение интеграторов, для которых задача также оказывается трудоемкой.
Сервисно-ориентированная архитектура, SOA (Service-Oriented Architecture), — это способ проектирования приложений, основанный на использовании программных сервисов со стандартными интерфейсами. Нужно особо подчеркнуть, что SOA — это не программный продукт, т. е. вы не сможете приобрести себе «коробку с SOA», а затем внедрить продукт на предприятии. Это лишь набор принципов, руководствуясь которыми вы получаете ряд полезных преимуществ. Основная идея при этом заключается в унификации приложений, организации их в виде веб-сервисов и интеграции их за счет выделенного централизованного решения.
Таким образом, несмотря на значительные затраты на первых этапах внедрения SOA-решений, в дальнейшем компания минимизирует свои затраты на интеграцию новых бизнес-приложений и бизнес-процессов. Кстати, не нужно забывать, что оценка «15 лет» предлагается для полного цикла внедрения данного решения на предприятиях класса промышленного гиганта Intel.
Возможно, у вас уже возник вопрос, какие решения необходимо приобрести, чтобы выстроить на предприятии архитектуру SOA. Крупнейшие разработчики бизнес-систем уже предлагают значительный набор программных средств, которые могут помочь в этом сложном процессе.
Ядром данных технологий является промышленная сервисная шина (Enterprise Service Bus, ESB). Данное программное обеспечение находится на промежуточном уровне (Middleware) и предоставляет базовые сервисы для сложных архитектур, основанных на посылке сообщений через шину.
К подобной шине и подключаются все бизнес-системы предприятия, «обернутые» в оболочку — веб-сервис. Использование веб-технологий позволяет решить задачу по гибкой настройке приложений под нужды бизнеса.
Программные средства ESB предлагают такие компании, как Oracle, BEA, IBM, Microsoft, Cape Clear Software, Sonic Software, Software AG и др.
Основными используемыми технологиями ESB являются HTTP, XML, UDDI, WSDL и SOAP (см. глоссарий).
Технология HTTP используется для передачи гипертекстовых документов между участниками взаимодействия. Это «транспортный» уровень.
На XML описываются схемы веб-сервисов, передаются сообщения, удаленно вызываются процедуры и т. п. XML удобен тем, что существует возможность как структурированного предоставления информации, так и описания структуры данных.
WSDL и SOAP «работают на XML». Эти протоколы являются расширениями XML, специально описанными наборами тегов для предоставления структурированной информации соответственно по веб-сервисам и протоколу обмена сообщений.
WSDL позволяет достаточно гибко описать веб-сервис, а протокол обмена и доступа к данным «SOAP-конверт» генерируется на основе данного описания.
Таким образом, описав веб-сервис, мы автоматически получаем и доступ к данным посредством SOAP.
UDDI предоставляет универсальный реестр для доступа к веб-сервисам.
Таким образом, благодаря гибкому описанию веб-сервисов, которое может получить любой потребитель сервиса SOA, позволяет интегрировать различные решения, выполняя лишь одно действие — оркестровку веб-сервисов. При этом для оркестровки веб-сервисов могут не требоваться навыки программирования или специальные технические знания. Достаточно лишь знания базовых технологий.
Помимо оркестровки веб-сервисов, также должна решаться задача по их интеграции. Данный вопрос тесно связан с проблемами описания бизнес-процессов в рамках инфраструктуры предприятия. Для описания бизнес-процессов в большинстве ESB-решений используется язык BPEL (см. глоссарий). Единственным недостатком данного языка является, на наш взгляд, отсутствие стандарта. Однако вскоре стандарт должен появиться (версия 2.0). А в настоящий момент используется спецификация OASIS BPEL 1.1. Несмотря на это, даже данный «черновик» уже используется в подавляющем большинстве решений ESB.
К сожалению, можно констатировать, что основная часть представляемого ИТ-компаниями материала по SOA носит маркетинговый характер и содержит незначительное количество технических деталей. Как правило, данный факт может говорить о том, что технология является молодой, и компании, развивающие ее, стремятся продать свое решение, а не успешно внедрить его. В данном случае можно напомнить об ажиотаже, возникшем после появления языка XML, среди представителей бизнеса, и (напротив) сдержанном отношении к новому стандарту со стороны программистов. Результат известен: по оценкам некоторых экспертов, проекты, в которых особый акцент делался на технологию XML (сразу после появления соответствующих инструментальных средств), успешно оканчивались лишь в 20–30 % случаев. Данный пример, однако, не означает, что применяемая технология неудачна — неудачно ее использование.
Поэтому всем, кто собирается применять решение SOA для бизнеса, следует помнить, что данный подход является наиболее современным и перспективным, но может таить в себе и подводные камни, которые необходимо выявить на этапе проектирования, а не на этапе реализации.
 
Глоссарий. SOA (Service-Oriented Architecture) — сервисно-ориентированная архитектура — подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами.
ESB (Enterprise Service Bus) — промышленная сервисная шина — программное обеспечение промежуточного уровня (Middleware), основанное на стандартах, которые предоставляют базовые сервисы для сложных архитектур, основанных на посылке сообщений через шину.
Middleware (здесь) — промежуточное (связующее, межплатформенное) программное обеспечение, состоящее из агентов, являющихся посредниками между различными компонентами распределенного приложения.
Web Service — веб-сервис, веб-служба — программная система, идентифицируемая строкой URI, внешние интерфейсы которой описаны при помощи языка WSDL. Другие программные системы могут взаимодействовать с веб-службой, благодаря описанию WSDL посредством обмена сообщений на базе SOAP.
XML (eXtensible Markup Language) — расширяемый язык разметки. Предназначен для представления структурированных данных для хранения и обмена информацией между приложениями (в частности, веб-сервисами).
SOAP (Simple Object Access Protocol) — простой протокол доступа к объектам. Основан на XML. Используется для обмена сообщениями и удаленного вызова процедур (Remote Procedure Call, RPC).
WSDL (Web Services Description Language) — язык описания веб-сервисов, который основан на языке XML.
BPEL (Business Process Execution Language) — язык реализации бизнес-процессов. Это язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия веб-служб.
 
В таблице приведено сравнение достоинств и недостатков централизованного интеграционного решения на основе SOA. Противоположный подход в данном случае — интеграция между собой отдельных бизнес-приложений.
«+» «-»
Централизованное решение для всей инфраструктуры предприятия обеспечивает достаточную степень управляемости ресурсами, технологиями, продуктовым рядом и т. п. Внедрение интеграционной платформы может потребовать изменений приложений, как разработанных собственными силами, так и заказных
Централизованная информационная система обеспечивает развитие бизнеса в ходе слияний и поглощений, быстрое внедрение новых продуктов, в том числе и новых услуг, повышение производительности банковских систем, снижение операционных издержек и т. д. Разработка интеграционной платформы на первом этапе требует значительных затрат ресурсов по сравнению с разработкой частных интеграционных решений.
Гибкость в управлении конкретными бизнес-процессами (изменение за минуты и часы, а не за месяцы и годы). Длительный процесс внедрения полного интеграционного подхода. Часть аналитиков утверждает (основываясь на опыте внедрения SOA-решений в компаниях, входящих в список Fortune 500), что полное завершение проекта может занять 15 лет. Однако они же замечают, что первые преимущества SOA станут заметны уже в течение 6 месяцев.
Поделиться:
Главные новости
Все новости компаний