Интеграция приложений: методы взаимодействия, топология, инструменты. Часть 4
Алексей Добровольский
Вернемся теперь на пять лет назад, когда основной платформой интеграции приложений были транспорты на основе очередей сообщений и программное обеспечение промежуточного слоя, ориентированное на обработку сообщений, которое играло роль «хаба» в рассмотренной ранее архитектуре «хаб + спицы».
Подобный инструментарий промежуточного слоя стоил слишком дорого, а специалисты по нему — еще дороже. Когда появился новый метод межплатформного взаимодействия, Web-сервисы, родился и новый подход к организации основы для интеграции — сервисная шина предприятия (Enterprise Service Bus, ESB). Реальным отличием ESB от шины сообщений предприятия стала поддержка дополнительных методов взаимодействия между приложениями и хабом, прежде всего, протокола SOAP. Основанный на ESB подход подавался как более дешевая, простая в реализации альтернатива предыдущей концепции.
Что же получилось в действительности? Появились новые продукты, поддерживающие SOAP, в старые продукты такая поддержка была добавлена, однако они не стали дешевле, а значит, доступнее своих предшественников. Означает ли это конец еще одной красивой сказки? Вовсе нет. Если отбросить пропаганду, то поддержка «хабом» интеграционной системы широкого спектра методов взаимодействия и протоколов облегчает и удешевляет интеграцию. Но не в разы, а на проценты — что уже неплохо с учетом стоимости интеграционных проектов.
Вокруг архитектуры, ориентированной на сервисы (Service-Oriented Architecture, SOA), также очень много маркетинговой шумихи. На мой взгляд, SOA — это не конкретные продукты и даже не технология, а лишь концепция построения информационных систем путем представления их в виде сервисов, доступных для «наружного» использования, в том числе путем их интеграции с другими приложениями. Это означает, что для пользователей ничего не изменится, пока ведущие поставщики программного обеспечения (и прежде всего, производители бизнес-приложений наподобие ERP, CRM, EAM и т.д.) не модифицируют свои системы в соответствии с SOA. Только тогда можно получить реальный выигрыш; пока же популярные бизнес-приложения — это замкнутые системы с очень «узким» внешним интерфейсом.
Однако ведущим поставщикам программного обеспечения это не так уж и нужно — хотя бы по той причине, что SOA даст теоретическую возможность клиентам выбирать компоненты от разных поставщиков по принципу «лучший в классе» и объединять их в информационную систему предприятия. При этом производителям, скорее всего, потребуется переписать свои системы. Вместе с тем, в настоящее время поддержка SOA является одним из тех немногих «крючков», которые могут побудить имеющихся клиентов переходить на новые версии бизнес-систем, а также способствовать правильной — с точки зрения поставщика — ориентации новых клиентов. Так или иначе, следующие несколько лет покажут, насколько жизнеспособна концепция SOA.
Алексей Добровольский (ADobrovolsky@croc.ru) — директор по разработке программного обеспечения компании «КРОК Инкорпорейтед» (Москва).
30.09.2006
Кроме этой статьи Вы можете посмотреть по тематеке текущего раздела:
2 статьи в разделе "Энциклопедия"
6 статей в разделе "Статьи".
2 статей в разделе "История".