«Просто» сервисы

Темой очередного Технологического дня Oracle, прошедшего в конце августа, стали сервис-ориентированные архитектуры

Нынешняя позиция Oracle в вопросе сервис-ориентированных архитектур была выражена в ключевом докладе «Сервис-ориентированные архитектуры и интеграция: взгляд Oracle», сделанном в ходе очередного Технологического дня Oracle старшим директором по технологиям интеграции в регионе EMEA Дэниэлом Серейном

Для постоянных участников регулярно проводимых Технологических дней Oracle название очередной акции, состоявшейся в конце августа, «Решение Oracle по интеграции и бизнес-анализу», в какой-то мере оказалось неожиданностью. К такому выводу можно было прийти, наблюдая их реакцию до начала мероприятия. Видимо, поэтому, обосновывая тему и представляя программу дня, руководитель отдела технического консалтинга Глеб Ладыженский особо подчеркнул, что сегодня Oracle — совершенно иная компания, чем та, которой была год или чуть больше тому назад. По его словам, заметная трансформация Oracle связана с приобретением ею нескольких компаний, в том числе PeopleSoft, Collaxa. Вливание новых сил существенно расширило арсенал технологий, предлагаемых Oracle. Теперь появилась возможность предлагать рынку не только традиционные для корпорации системы управления базами данных и бизнес-приложения, но в дополнение к ним сформировать еще третье стратегическое направление, состоящее из интеграционных решений и решений по бизнес-анализу.

Появление третьего направления не просто результат слияний, а ответ корпорации на требования момента. Совершенно очевидно, что индустрия переживает переломный период, и Oracle соответствующим образом на него реагирует. Исторически сложилось представление о том, что информационные системы и приложения в основном статичны и детерминированы, что их можно и должно строить в соответствии с определенными требованиями. Но это было в прошлом, ныне атмосфера быстро меняющегося бизнеса предполагает такие условия и правила игры, которые не всегда могут быть априорно заданы, и этому новому бизнесу соответствуют только гибкие системы, способные адаптироваться к нему. Пока не появилось ничего другого из технологических решений, позволяющих сегодня удержаться на плаву, кроме сервис-ориентированных архитектур (service-oriented architecture, SOA). Сервисный подход, как средство для работы с неопределенной моделью бизнеса, в настоящее время является безальтернативным. Поэтому на протяжении нескольких последних лет практически всеми разработчиками таких архитектур он используется в качестве первоосновы для создания нового поколения информационных систем. Компания Oracle так же, как и другие поставщики решений для бизнеса, вынуждена отходить от традиционных архитектур в пользу сервис-ориентированных. Нынешняя позиция компании в этом вопросе была выражена в ключевом докладе «Сервис-ориентированные архитектуры и интеграция: взгляд Oracle». Его сделал старший директор по технологиям интеграции в регионе EMEA Дэниэл Серейн.

Серейн — известный ученый, его перу принадлежит несколько книг, причем не просто стереотипных, переписанных из технической документации, множеством коих заполнены прилавки, а авторских работ. Его труды публикует Springer, одно из самых престижных издательств. К тому же он преподает интеграционные технологии и все, что связано с программным обеспечением промежуточного слоя, в нескольких французских университетах.

Свое выступление Серейн начал с того, что описал сложности современных корпоративных систем, вызванные прежде всего несогласованностью между теми, кто руководит бизнесом, и теми, кто создает и эксплуатирует информационные системы. С этим разрывом можно было мириться до тех пор, пока информационные системы не были столь критичны для бизнеса. Однако сейчас, когда успешность бизнеса напрямую зависит от информационной поддержки, он должен быть преодолен. Поэтому Oracle реализует программу, нацеленную на устранение упомянутого разрыва.

Программа может быть оформлена в виде четырехуровневой интеграционной модели, где на каждом уровне реализуется интеграция соответствующих объектов. Нижний уровень — Connectivity & Data Management — обеспечивает интеграцию данных, некоторых приложений и связей с партнерами. Для характеристики сегодняшнего состояния того, что творится на этом уровне в большинстве компаний, точнее всего подходит определение «блюдо спагетти». При желании оно может быть заменено методологией и технологией, они включены в продукт Oracle Data Hub.

Второй уровень, Business Service, собственно, и реализует SOA, на нем приложения интегрируются средствами сервисов. Показательно, что, говоря о SOA, Серейн отделил приставку Web от сервисов, это исключительно важно. Да, идея сервисов действительно зародилась в среде Web, действительно стек протоколов (SOAP, WSDL, UDDI и др.) ведет свою родословную от Web, но при переносе в корпоративное пространство она теряет связь с WWW, не смотря на то, что везде и всюду их упорно называли Web-сервисами. Понять то, почему нужно было годами называть сервисы в корпоративной среде Web-сервисами, невозможно.

Третий уровень, Business Process Management, здесь интегрируются потоки работ, составляющих бизнес, причем эта интеграция не ограничена рамками предприятия, в него могут включаться связи с поставщиками, партнерами и потребителями. В BPM входит полный замкнутый цикл, реализуемый в бизнесе от проектирования, через внедрение, эксплуатацию, наблюдение, совершенствование и т. д. Для реализации этого уровня предназначен Oracle BPEL Process Manager.

Верхний, четвертый уровень — Business Visibility — представлен средствами бизнес-аналитики, работающими в режиме реального времени (Business Activity Monitoring и Real Time Business Intelligence).

SOA в интерпретации Oracle

Старший директор Oracle по технологиям интеграции в регионе EMEA Дэниэл Серейн ответил на несколько в?о?просов Computerworld Россия.

Мы говорим о сложных системах, поэтому строим архитектурные сооружения. А для создания сооружений нужны строительные блоки, объекты и клей, собирающий их воедино. До последнего времени было непонятно, что можно использовать в качестве компонентов. Десять лет назад новинкой были объекты, CORBA, компонентная модель Java и .Net. Потом появились Web-сервисы со своими объектами, но в корпоративных средах требуется более широкое представление о том, что такое объект. Сервисы — это, в конечном счете, интерфейс и язык описания интерфейса, в данном случае язык WSDL, на котором описываются характеристики сервисов. Его достоинство в том, что это универсальный язык, прежде CORBA или Java использовали собственные IDL. Теперь можно не беспокоиться о природе объектов, можно использовать любые объекты и склеить их в единую систему универсальным клеем, в этом преимущество сервисной модели.

Стандарт SOAP — отличная технология, но она хороша для того, для чего она была разработана, а именно для Web. Но Internet-технологии не обладают необходимыми качествами, прежде всего надежностью и быстродействием, RMI или CORBA быстрее. Ведь SOAP — всего лишь один из возможных транспортных стандартов, который использует обмен сообщениями на основе протокола HTTP. По определению он не может обеспечить достаточно высокую скорость обмена. Существуют альтернативные решения, относящиеся к программному обеспечению промежуточного слоя, ориентированному на обмен сообщениями, все это удачно укладывается в то, что сейчас принято называть корпоративной сервисной шиной.

Мне кажется все дело в природе бизнеса, в его коренном отличии от технических систем управления. Технические системы тоже могут быть сложными настолько, что для их описания приходится использовать статистические методы, в бизнесе природа неопределенности совершенно иная. Она следует из участия человека в контуре управления, ни один управляющий не захочет, чтобы его деятельность была на 100% прозрачна, в конце концов, бизнес — это в некотором смысле игра, причем игра азартная, где нельзя держать все карты открытыми. Поэтому средства для описания и моделирования бизнес-процессов должны быть адекватны природе бизнеса.

Мы идем сверху вниз. Мы начинаем с обсуждения проблем с заказчиком, вместе с ним мы должны попытаться формально выразить его стремления, бизнес-цели, вместе с ним мы описываем настоящие и будущие бизнес-процессы. Например, используя BPEL, формулируем технологический процесс управления. Затем определяем функциональный состав программного обеспечения, необходимого для поддержания каждого из этапов технологического процесса. Следующий шаг: оформляем функции как сервисы и переходим на технический уровень, подбирая необходимые адаптеры и прочие специальные средства.

Здесь нет противоречия. Проектирование BPM действительно ведется практически с чистого листа, но в качестве сервисов вполне можно использовать существующие компоненты, просто оформив их нужным образом.

Можно сказать и так. Да, мы сохраняем существующее, но придаем ему новые качества.