Программные системы по мере развития достигают такого уровня сложности, что существующие подходы и концепции разработки ПО становятся малоэффективными. Как правило, при этом рождается новая парадигма программирования, на которую постепенно переходят все разработчики. Cоздание концепции процедурного, модульного и объектно-ориентированного программирования - это примеры давнего или недалекого прошлого; будущее же, похоже, за сервисно-ориентированными архитектурами.
Сервисно-ориентированная архитектура
Как известно, повторное использование программного кода упрощает разработку больших информационных систем. До недавнего времени с этой целью традиционно применялся объектно-ориентированный подход (ООП), подразумевающий жесткое объединение компонентов и объектов приложения в одно целое. В парадигме ООП от разработчика требуется знание прикладного программного интерфейса, в котором объединены атрибуты и методы, сообща реализующие необходимый функционал. Но поскольку объектные системы обычно создаются на основе какого-то одного языка программирования (Delphi, C++, C#, Java и др.) и фиксированных механизмов обмена информацией между объектами и модулями информационной системы, то и в ООП сохраняются все зависимости и ограничения. Такой подход удобен не всегда - в частности, он не позволяет оперативно реагировать на изменение ситуации и, к примеру, проектировать новомодные системы, опирающиеся на концепцию "ресурсы по требованию". Кроме того, для модификации объектных систем нередко приходится переписывать коды связанных объектов и методов. Cвести эти ограничения к минимуму как раз и позволяет технология SOA (Service Oriented Architecture - сервисно-ориентированная архитектура), которая многими уже признана как революция в технологии программирования. Аналитики уверены, что по мере развития стандартов SOA компании освоят эту область, а вендоры модернизируют свои продукты в соответствии с ее требованиями.
На самом деле SOA - это всего лишь иной стиль построения современных корпоративных систем. Он ориентируется на сервисы, характеризуется распределенной архитектурой и слабосвязанными интерфейсами. Сервис в данном случае - это не что иное, как единица работ, выполняемая сервис-провайдером для обеспечения желаемого результата потребителю сервиса. Именно сервис, а не объект, как в ООП, является повторно используемым, и при этом он не зависит от технологий, языковых сред и других ресурсов. Интегрирующую роль между сервис-провайдером и потребителем берут на себя программные агенты.
Ряд архитектурных особенностей SOA позволяет уменьшить степень связанности различных элементов системы. Для взаимодействия компонентов используется сравнительно небольшой набор простых интерфейсов, которые обладают только самой общей семантикой и доступны всем провайдерам и потребителям. Через эти интерфейсы передаются сообщения, ограниченные некоторым словарем. А поскольку даны только общая структура корпоративной системы и словарь, то вся семантика и бизнес-логика, специфичная для приложений, описывается непосредственно в этих сообщениях.
Корпоративная информационная система, построенная на основе SOA, состоит из набора сущностей, доступных через прикладные программные интерфейсы. Встроенный механизм поиска и обнаружения сервисов в общем реестре позволяет потребителю выйти на оператора, предлагающего искомую функцию. Так, клиенты, желающие решать определенную задачу, связываются с сервис-провайдером и через прикладные программные интерфейсы выполняют необходимые действия - эта процедура наглядно проиллюстрирована на рис. 1: компонент A использует сервис, предоставляемый компонентом B через интерфейс 1, а компонент B использует программные интерфейсы 2–4, предоставляемые сущностями C, D и E.
Все компоненты корпоративной системы должны поддерживать общий "язык", на котором составляются сообщения. Каким именно может быть этот язык - нетрудно догадаться, если вспомнить, что SOA и веб-сервисы в статьях и книгах обычно упоминаются вместе.
Архитектура веб-сервисов также является сервисно-ориентированной. Более того, веб-сервисы - это суть SOA c двумя дополнительными ограничениями: интерфейсы базируются на интернет-протоколах (HTTP, FTP, SMTP, TCP), а все сообщения описываются в формате XML. Детальные описания стандарта веб-сервисов и спецификаций SOA приводится на сайтах консорциума W3C и организации OASIS - мы же не будем лишний раз тратить время на знакомство с ними, а посмотрим, как функционируют программные системы, созданные в новой архитектуре SOA.
Практические аспекты сервисно-ориентированной технологии позволяют решить проблемы масштабируемости, интегрировать сети передачи данных и голоса, упростить процедуры проектирования и управления сетями, а также создать другие распределенные приложения, прозрачно взаимодействующие с ресурсами систем при помощи прикладных программных интерфейсов и открытых стандартов.
Модели веб-сервисов
Сервисно-ориентированная модель веб-сервисов, опубликованная в августе 2003 года, описывает действия, задания и связанные с ними данные. В ней выстраивается логическая взаимосвязь между программными агентами и сервисами, которые те предоставляют или запрашивают (рис. 2).
Как и в SOA, веб-сервис решает определенные функциональные задачи с помощью одного или нескольких программных агентов, действующих от лица их владельца (провайдера). Интерфейс, семантика и вспомогательные метаданные сервиса описываются набором документов в формате XML. Типы и шаблоны сообщений, которые передаются при взаимодействии сервисов, заданы в соответствующем интерфейсе, а их семантика указывает на модели поведения взаимодействующих сервисов. Решаемые при этом задачи (service task) представляют собой наборы действий, которые в конечном счете изменяют состояние всей системы.
Весьма интересна терминология, связанная с веб-сервисами. Так, средства обмена сообщениями, с помощью которых несколько независимых агентов стремятся достичь желаемого состояния, получили название "хореографии", а взаимодействие сервисов - "оркестровки". Для "оркестровки" (т.е., по сути, описания бизнес-логики) были разработаны (с участием крупнейших вендоров, таких, как IBM, Microsoft, Oracle и BEA Systems) специальные средства программирования - BPEL4WS, XLANG, WSFL и др.
Два компонента взаимодействуют через сервис-провайдера (рис. 3), проверяющего корректность запроса и при необходимости предоставляющего дополнительную информацию, скажем, о состоянии счета клиента. Каждый провайдер предлагает определенные сервисы, которые, в свою очередь, реализуют дополнительные сценарии обращений к вспомогательным ресурсам, - таким образом сервис, являющийся основным, агрегирует элементарные сервисы (рис. 4).
Если перейти к бизнес-аспектам, то веб-сервисы упрощают выход компаний на новые рынки и экономят средства на ИТ-инфраструктуре: общие реестры доступны любым заинтересованным клиентам во всем мире, надстройка (в отличие от встраивания) веб-сервисов над корпоративными системами не требует их существенного изменения, а общедоступные API (прикладной интерфейс программирования) решают упомянутые ранее проблемы повторного использования кода и масштабируемости сервера приложений.
Спецификации NGOSS
Сложность новой сервисно-ориентированной архитектуры корпоративных систем вынуждает производителей бизнес-ПО заниматься ее упрощением и адаптацией для решения каких-то определенных задач. Одна из наиболее очевидных областей применения SOA - это ИС коммуникационных компаний. Ведь системы оперативной поддержки (OSS) и поддержки бизнес-операций (BSS) должны быть тесно интегрированы с административными и бизнес-функциями телекоммуникационного предприятия. Добиться этого без особого труда позволяют SOA и ее производные.
Международная ассоциация, объединяющая свыше трехсот организаций, - Telecommunication Management Forum (TMF) - как раз и занимается разработкой отраслевых стандартов для сервисно-ориентированных решений. NGOSS (New Generation Operations Software and Systems) - это инициатива TMF по упрощению и стандартизации процессов определения, разработки и внедрения OSS/BSS-систем в телекоммуникационной индустрии.
В проводимых TFM работах можно выделить пять направлений:
описание жизненного цикла и методологии использования и внедрения NGOSS в организации;
составление расширенной карты бизнес-процессов eTOM (enhanced Telecom Operations Map);
описание общей информационной модели обмена данными SID (Shared Information/Data model);
составление TNA (Technology Neutral Architecture) - архитектуры компонентов и их взаимодействия, не завязанной на технологиях;
разработка методологии проверки решений и продуктов на соответствие спецификациям NGOSS.
В основе NGOSS лежит распределенная, ориентированная на использование интерфейсов архитектура (DIOA - Distributed Interface-Oriented Architecture). Наверное, поэтому эксперты считают DIOA аналогом SOA. Подразумевается, что сервисы, соответствующие спецификациям стандарта, отвечают следующим требованиям.
Описание сервиса осуществляется в терминах:
- метаданных для описания интерфейса;
- метаданных для описания поддерживаемых операций;
- для каждой операции - описание возможных возвращаемых результатов.
Описание моделей поведения сервиса содержит:
- начальные условия для вызова определенной операции;
- конечные условия, в которых оказывается система после выполнения операции.
Сервисы DIOА разделяются на три категории. В первую входят общие базовые принципы, такие, как регистрация, именование и поиск сервисов. Во вторую - базовые сервисы OSS (системы управление процессами). Наконец, в третью - прикладные сервисы OSS, характерные для конкретного разработчика или сервис-провайдера, например биллинг, служба поддержки и др. Сервис-провайдер должен сочетать в себе все эти категории. Причем базовые сервисы подробно описываются в спецификациях NGOSS, а прикладные зависят от конкретных разработок.
NGOSS-система характеризуется разделением программного кода, выполняющего функциональность компонентов и автоматизирующего бизнес-процессы. То есть она строится из набора сервисов, объединенных с помощью технологий интеграции и управления. Внешнее описание сервиса отделяется от внутренней реализации путем представления, называемого контрактом. Контракт позволяет связать бизнес-описание компонента с его технологической реализацией и по сути является спецификацией сервиса, выполненной в технологически нейтральной форме. Каждый такой контракт привязан к одному прикладному программному интерфейсу, а его экземпляры предоставляют сервисы другим сущностям.
Архитектурной единицей сервиса является компонент, который может поддерживать один или несколько контрактов. В рамках технологически нейтральной архитектуры NGOSS термином "сервис" обозначается функциональность компонента, доступная при использовании контрактов (рис. 5).
Концепция единообразного представления и хранения информации для ее использования в различных бизнес-процессах является одним из основополагающих принципов NGOSS. Примерами такой информации могут служить SLA (Service Layer Agreement - соглашение об уровне обслуживания), сведения о клиентах, сетевая топология и т.п. Доступ к данным осуществляется с помощью сервисов, интерфейсы которых специфицированы информационными контрактами (information services contracts).
Соглашение об уровне обслуживания фактически представляет собой договоренность двух сторон, посредством которой утверждаются общие используемые сущности (продукты, сервисы, ответственности и т.п.). Иными словами, SLA - это набор целей и процедур, принимаемых обеими сторонами для достижения указанного качества обслуживания (Quality of Service). Такое соглашение может быть как внешним, формальным контрактом, направленным на качество сервиса, так и внутренним, отражающим внутрифирменные бизнес-процессы и ориентированным на локальные ресурсы и компоненты сервисов. Элемент соглашения (agreement item) связан со спецификацией уровня сервиса (Service Level Specification), представляющей собой группу требований по пороговым величинам, метрикам и допустимым отклонениям.
Как было сказано ранее, контракт является одним из центральных понятий спецификаций NGOSS. Он задается как абстрактный контейнер и адаптируется под конкретную задачу при создании классов, описывающих характеристики, поведение и семантику. Контракт использует информацию общего доступа (Shared Information) и отражает функциональность компонентов NGOSS (рис. 6).
От теории - к практике
Практическая реализация сервисно-ориентированной архитектуры в виде веб-сервисов или сервисов OSS требует конкретизации при описании интерфейсов и вспомогательных функций, к примеру для поиска и регистрации сервисов.
Веб-сервисы реализуют слабосвязанное взаимодействие, которое не предъявляет требований к СУБД или ширине канала между компонентами, в то время как составным частям агрегированной услуги зачастую необходимы совместные ресурсы и общая система управления. Именно поэтому в спецификациях NGOSS и SID наибольшее внимание уделяется модели классов.
В спецификациях NGOSS понятие сервисов выступает в различных ипостасях: как агрегированная услуга, предоставляемая клиентам; как вспомогательные сервисы поиска, именования и регистрации; как сервисы управления и интеграции систем OSS/BSS. Первый вид сервисов описывается контрактом, и качество предоставляемой услуги отслеживается с помощью механизма SLA. Вспомогательные сервисы регистрации и поиска в спецификациях NGOSS в целом совпадают со спецификациями на архитектуру веб-сервисов и SOA для электронной коммерции. Сервисы управления и интеграции являются специфичными для OSS/BSS, поскольку они определяют сценарии обращения к элементарным сервисам и ресурсам сервис-провайдера.
Владимир Беленкович – генеральный директор компании "Би-эС-Би", vbelenkovich@bs4b.net.
Тимофей Горшков – студент-дипломник МФТИ, timophey@pochta.ru.
