Как разобраться в SOA

Появление ориентированного на сервисы программного обеспечения часто называют очередной революцией в программной индустрии. Разработчики постоянно наращивают возможности Web-сервисов, переходя от простого обмена сообщениями к полнофункциональным приложениям. На Web-сервисы возлагает большие надежды и английская компания Pennine Group, предлагающая свою платформу Software as a Service.

Многие полагают, что новые, ориентированные на сервисы подходы позволят решить серьезные проблемы, возникающие из-за недостаточной гибкости программных систем. Все большая ориентация на сервисы побудила нас проанализировать, упрощают или усложняют понимание программного обеспечения новые подходы — с учетом того, что именно понимание может обходиться дороже всего в программной инженерии [2].

Обсудим хронические проблемы, с которыми сталкиваются разработчики программ при работе с ориентированным на сервисы программным обеспечением. Затронем и вопросы, связанные с трудностями и ошибками при предоставлении сервисов.

Ориентация на сервисы

Модификация программного обеспечения по-прежнему остается весьма существенной проблемой для многих организаций, хотя новые методы разработки обещают сделать информационные системы более гибкими и упростить их совершенствование по мере изменения требований бизнеса. Как правило, разработчики тратят больше всего времени на то, чтобы разобраться в уже существующем программном обеспечении — желают ли они исправить в нем ошибки или расширить его функциональность. Под анализом программного обеспечения (software understanding) мы понимаем применение неких методик и процессов с целью разобраться в нем.

Платформа Software as a Service (SaaS) [1], предлагаемая как способ решения задач модификации программного обеспечения [3], автоматически обнаруживает специализированные программные сервисы, согласует условия приобретения их услуг, объединяет их в наборы, подключает, использует и отключает. По сути, никакую систему поддерживать и не нужно — она формируется как набор сервисов, отвечающих конкретным «сиюминутным» требованиям. SaaS включает в себя элементы аутсорсинга, т.е. обеспечения бизнес-функций по определенной цене при данном соглашении об уровне обслуживания, и предоставления приложений в аренду (application service providing, ASP). Однако SaaS выходит далеко за рамки этих двух подходов.

На первый взгляд, платформа SaaS выглядит полным аналогом ASP, однако она отличается специализацией предоставляемых услуг и размером сети их доставки. Подход SaaS предусматривает формирование набора специализированных, настроенных сервисов, а ASP — более общих, стандартизованных приложений. Кроме того, если сеть доставки арендуемых приложений, как правило, связывает одного клиента с одним поставщиком, то в SaaS предусматривается создание значительной сети поставщиков, объединяющей сервисы в большие по размеру наборы с тем, чтобы обеспечить требуемую функциональность.

По-видимому, оправдает себя механизм так называемой микрооплаты (micropayment): пользователи смогут платить только за те услуги, которые им нужны, и обращаться к ним, лишь когда они требуются. При этом расценки будут отражать соотношение спроса и предложения, сложившееся на рынке.

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

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

Установить доверительные отношения в рамках автоматизированного предоставления услуг, которое предлагает SaaS, намного сложнее. Поскольку способы ведения переговоров изначально ориентированы на человека и не сводятся только к цифрам, потребуются дальнейшие исследования методов автоматического согласования условий — прежде чем они станут настолько совершенными, что их можно будет использовать в повседневной практике бизнеса. Кроме того, любая схема гарантий и компенсаций должна иметь исковую силу, что создает еще одно препятствие к реализации глобального автоматизированного решения. Выбор правовой схемы, в рамках которой будут оформляться контракты, может обернуться сложными и очень ответственными задачами.

Опыт эксплуатации системы и взаимодействия потребителя с конкретным провайдером даст много полезной информации для последующих переговоров о предоставлении услуг. Агент, ведущий переговоры (например, автоматизированный брокер), может учитывать такие показатели, как результаты сравнения обещанного сервисом и реального времени обработки, уровень удовлетворенности пользователей или цены, и на основе этих данных формировать переговорную стратегию, обновлять свое представление о провайдерах и их предложениях. А поскольку организация должна доверять агенту, ведущему переговоры от ее имени, функциональность, скорее всего, останется ее прерогативой — только в этом случае она сможет осуществлять необходимый контроль.

Подобные проблемы, связанные с SaaS, возникают при передаче другой организации выполнения тех или иных функций по контракту [1, 3, 4]. Автоматизация, вероятно, еще усложнит этот процесс, но найти приемлемые решения все же возможно. Так, сегментация рынка наряду с развитием национальных законодательств будут способствовать формированию адекватных правовых схем.

Другими словами, для успешной реализации подхода SaaS потребуются новые бизнес-модели и новые технологии. Внедрение такого подхода — процесс не одномоментный. Компании оформляют свои предложения как сервисы и постепенно разбивают их на компоненты по мере того, как появляются новые возможности для обращения к дополнительной функциональности как внутри компаний, так и за их пределами. Скажем, General Motors приняла подобный подход применительно к организации производства по заказам [5].

Внутри компании, благодаря SaaS, можно увеличить гибкость и адаптивность информационных систем. Эта разновидность сервисного подхода, скорее всего, будет развиваться интенсивнее, поскольку в ней проблемы автоматического согласования контрактов отходят на второй план. Вне компании, прибегая к SaaS, можно извлечь дополнительный доход от имеющегося программного обеспечения и быстро получить новое, не обременяя себя проблемами его обслуживания и поддержки; компания получает возможность увеличить потенциальный возврат от инвестиций в программные продукты и снизить риск перехода на новые решения.

С SaaS связаны следующие основные концепции:

• организация открытого рынка сервисов;
• динамическое предоставление программного обеспечения в ответ на меняющиеся требования;
• возможность одноразового использования программного обеспечения с последующим его отключением;
• создание сети доставки услуг, в которой провайдеры могут заключать субконтракты на предоставление этих услуг;
• обеспечение прозрачности для потребителей программного обеспечения.

Сценарий SaaS

Чтобы проиллюстрировать проблемы, с которым сталкиваются при анализе программ в мире SaaS, рассмотрим некую вымышленную крупную компанию Bizness plc, ведущую свои операции в нескольких странах. В силу того, что она работает на международном рынке, сотрудники компании должны готовить квартальные отчеты на нескольких языках [4]. Bizness plc имеет собственный ИТ-департамент.

Джон, менеджер Bizness plc, составил свой последний квартальный отчет на английском языке и хочет воспользоваться автоматическим переводом. Он обращается к службе переводов, чтобы получить текст на французском, немецком, итальянском и испанском языках. Автоматизированный брокер ищет подходящий набор сервисов, соответствующий запросу Джона (описание этого набора, однако, не связывает запрос с реальными сервисами). Сразу после получения запроса брокер приступает к поиску организаций, которые предлагают соответствующие услуги, согласовывает условия предоставления этих услуг, следуя правилам ведения переговоров, установленных в Bizness plc, и формирует набор связанных контрактом сервисов для Джона.

Цепочка доставки готовит ответ на запрос Джона

На рисунке показана сформированная сеть доставки. Джону не нужно знать, какие компании предоставляют заказанные услуги: он взаимодействует только со своим автоматизированным брокером. В свою очередь, брокер может взаимодействовать только с теми поставщиками, с которыми был заключен прямой контракт. Как видно из рисунка, запрос Джона будут выполнять поставщики F, G, I и S. При этом G и S не имеют субконтрактов и всю работу делают сами. Провайдеры F и I заключили субконтракты на получение грамматической и словарной информации с провайдерами FG, ID и IG. Тем не менее, Джон о них ничего не знает — и знать не должен.

Джон передает свой документ предоставленному брокером сервису перевода. Получив результат, он обнаруживает, что перевод на итальянский язык отсутствует. Ему нужно выяснить, почему такое произошло и что следует изменить для выполнения текущей работы и всех последующих запросов к этому сервису.

Сначала Bizness plc требует объяснений от поставщика, результат работы которого не устроил заказчика. В автоматизированной среде один из многочисленных заранее определенных ответов служит для предоставления соответствующей информации или инициирует необходимые действия. Установить, насколько предложенные объяснения соответствуют истине, очень сложно — особенно, если для поставщика не предусмотрен серьезный штраф за невыполнение обязательств.

Если поставщик не предоставит объяснений, компания Bizness plc и ее поставщики в цепочке доставки могут предпринять юридические действия с целью заставить других провайдеров выполнить контракты. Однако подобные действия могут потребовать больших затрат времени и денег, чем изначально предусматривались для выполнения услуги и оправдывали ее использование (с учетом модели микрооплаты, предусмотренной в SaaS). Для контроля выполнения контракта в автоматизированной среде его участники могут воспользоваться услугами третьей стороны, которая осуществляет оплату (например, посредством условного депонирования). Она передает деньги подрядчикам только в том случае, если все стороны удовлетворены качеством предоставленных услуг. При необходимости окончательное разрешение конфликтов может осуществляться в арбитражном или административном суде.