Появление ориентированного на сервисы программного обеспечения часто называют очередной революцией в программной индустрии. Разработчики постоянно наращивают возможности 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). Для контроля выполнения контракта в автоматизированной среде его участники могут воспользоваться услугами третьей стороны, которая осуществляет оплату (например, посредством условного депонирования). Она передает деньги подрядчикам только в том случае, если все стороны удовлетворены качеством предоставленных услуг. При необходимости окончательное разрешение конфликтов может осуществляться в арбитражном или административном суде.

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

Существует и иное (возможно, менее дорогое) решение. Джон может попытаться диагностировать проблему и установить ее источник, чтобы либо предъявить претензии конкретному поставщику, либо исправить ошибку при последующих обращениях к сервису. Кроме того, он может еще раз обратиться к брокеру и потребовать повторного выполнения работы, указав, что брокер должен отказаться от услуг «проштрафившейся» службы перевода и найти ей альтернативу. Джону придется оценить, что обойдется дешевле: изменить требования и, возможно, воспользоваться более дорогим сервисом или попытаться устранить возникшую проблему (в конце концов, провайдер уже мог обратиться к своему субподрядчику и предпринять корректирующие действия).

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

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

Анализ ошибок

Джон может предпринять самостоятельную попытку разобраться в программном обеспечении, но, скорее всего, он обратится к эксперту Алисе с просьбой помочь диагностировать и решить проблему. Алиса — программист, работающий в ИТ-департаменте Bizness plc.

Во-первых, Алиса соберет информацию об ошибке. Однако собранная информация окажется очень скудной; более того, она будет фрагментарна, а собрать ее окажется непросто. Алисе необходимо понять, как ведет себя программное обеспечение в работе, но у нее нет средств для точного воспроизведения соответствующих процессов. Bizness plc не принадлежит служба, услугами которой воспользовался Джон, — компания просто заключила контракт с другими организациями на предоставление конкретных услуг по определенной цене. На рисунке мы видим возможные источники ошибки (I, ID, IG), но Алисе известно лишь о провайдерах услуг первого уровня (F, G, I, S). В сил этого она знает только, что работа службы перевода на итальянский язык оказалась неудовлетворительной, но не знает, кто предоставляет услуги на основе субконтрактов провайдеру, отвечающему за перевод на итальянский язык.

Так какой именно информацией располагает Алиса? Ей известны требования, выдвинутые Джоном, предоставляемая брокером информация о наборе услуг провайдеров первого уровня, а также сведения о провайдерах, с которыми брокер заключил контракт.

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

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

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

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

Анализ программ

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

При традиционном подходе Алиса должна была бы создать мысленную модель системы и проанализировать точку возникновения ошибки [6]. Для этого ей пришлось бы разбираться в архитектуре, потоках данных и потоке управления, возможно, с помощью таких инструментов, как средства квантования программ (например, CodeSurfer — www.grammatech.com) или объектные браузеры (скажем, NetBeans). Однако большая часть этой информации может оставаться недоступной, и Алисе придется разбираться не в самой системе, а во взаимосвязях между сервисами, входящими в предоставленный набор. Для этого, в свою очередь, ей необходимо знать языки и правила организации наборов сервисов, а также хорошо представлять, как они использовались в конкретном случае. Данный подход отличается от традиционного подхода, применяемого при анализе систем, степенью детализации. Сервисы, как правило, имеют большую степень детализации, чем выражения исходного кода, которые традиционно анализируют инженеры, чтобы разобраться в программном обеспечении.

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

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

Анализ изменений

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

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

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

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

Возможные решения

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

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

Проблема: частичная открытость сети доставки. Алиса может попытаться решить проблему путем переговоров с провайдерами, но не исключено и более технологичное решение. Речь идет о создании сервиса, который способен «видеть» всю сеть доставки и, возможно за плату, предоставит Алисе необходимую информацию (чтобы она узнала о существовании ID и IG). Плата станет компенсацией провайдерам, отказавшимся от конфиденциальности, и ее размер придется с ними согласовывать.

Проблема: анализ состояния программного обеспечения. Некоторые традиционные подходы к анализу распределенного программного обеспечения предусматривают получение информации о состоянии [8], которая поможет Алисе найти источник ошибки. Однако составить полную картину будет весьма затруднительно, поскольку сеть доставки открыта лишь частично, а обмен информацией между провайдерами ограничен из-за соображений конфиденциальности.

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

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

Роль Алисы

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

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

Литература
  1. K.H. Bennett et al. An Architectural Model for Service-Based Software with Ultra Rapid Evolution. Proc. IEEE Int'l Conf. Software Maintenance, IEEE CS Press, 2001.
  2. T.A. Standish. An Essay on Software Reuse. IEEE Trans. Software Eng., vol. SE-10, no. 5, Sept. 1984.
  3. K.H. Bennett et al. Prototype Implementations of an Architectural Model for Service-Based Flexible Software. Proc. 35th Hawaii Int'l Conf. System Sciences, IEEE CS Press, 2002.
  4. M. Turner, D. Budgen, P. Brereton. Turning Software into a Service. Computer, vol. 36, no. 10, Oct. 2003.
  5. Beyond the Hype of Web Services - What Is It and How Can It Help Enterprises Become Agile, EDS, www.eds.com/about_eds/homepage/ home_page_lehmann.shtml.
  6. A. Von Mayrhauser, A.M. Vans. Program Comprehension During Software Maintenance and Evolution. Computer, vol. 28, no. 8, Aug. 1995.
  7. V.T. Rajlich, K.H. Bennett. A Staged Model for the Software Life Cycle. Computer, vol. 33, no. 7, July 2000.
  8. J. Moe, D.A. Carr. Understanding Distributed Systems via Execution Trace Data. Proc. IEEE Int'l Workshop Program Comprehension, IEEE CS Press, 2001.

Николас Голд (n.e.gold@co.umist.ac.uk) — профессор факультета вычислительной математики Манчестерского института науки и технологии. К сфере его основных научных интересов относятся анализ, развитие и поддержка программного обеспечения. Клер Найт (claire.knight@volantis.com) — инженер-разработчик компании Volantis Systems. Специализируется на визуализации и анализе программ, Java, технологиях grid и Web-сервисах. Эндрю Мохан (a.mohan@postgrad.umist.ac.uk) — аспирант Манчестерского института науки и технологии. К области его основных научных интересов относятся поддержка и развитие программного обеспечения, анализ и качество программ. Малколм Манро (malcolm.munro@durham.ac.uk) — профессор факультета компьютерных наук университета Дурхама. К его основным интересам относятся визуализация, анализ, поддержка и модификация программного обеспечения. Занимается исследованиями в области Software as a Service, использованием байесовых сетей для тестирования и анализа программ.

Nicolas Gold, Andrew Mohan, Claire Knight, Malcolm Munro. Understanding Service-Oriented Software. IEEE Software, March-April 2004. IEEE Computer Society, 2004, All rights reserved. Reprinted with permission.

Технология, ориентированная на сервисы

Существует множество технологий, которые могут быть использованы для создания сервис-ориентированного программного обеспечения. Сюда относится все, начиная от комплексных приложений, продаваемых через провайдеров, и заканчивая конкретными компонентами или фрагментами кода. Консорциум W3C определяет сервис-ориентированную архитектуру (service-oriented architecture, SOA) как набор исполняемых компонентов, интерфейсы которых можно публиковать и находить с помощью автоматизированных средств. Web-сервис — это конкретный экземпляр компонента (или компонентов), имеющий открытый интерфейс (определенный и описанный на XML). Другие системы могут его находить и использовать, передавая сообщения, которые пересылаются с помощью Internet-протоколов.

В настоящее время термин «сервис-ориентированный» зачастую применяется к более традиционным технологиям DCOM и CORBA, а с недавнего времени — также и к платформам J2EE и .NET, и к Web-сервисам. Нет причин считать, что та или иная технология является отличительной особенностью именно SOA. Такие стандарты, как SOAP для Web-служб, позволяют гарантировать, что гетерогенность решений не создает каких-либо проблем.

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

Контроль версий помогает гарантировать, что организации со временем смогут использовать различные версии сервисов, не испытывая проблем с совместимостью. Например, платформа .NET поддерживает версии сборок (наборов классов) в C#, которые затем могут задействоваться в коде с различными параметрами. Это позволяет указывать, какие из версий совместимы. Разные версии могут сосуществовать, причем конкретный экземпляр выбирается во время исполнения, и используется корректная сборка.

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