Обзор технологии Web-сервисов. Обзор распределенных систем

Глава 1. Общая методика построения распределенных систем на основе веб-сервисов

1.1. Сервис-ориентированная архитектура.

1-2. Методика построения веб-сервисов Java.

1-3. Предварительное тестирование веб-сервисов.

Глава 2. Методы построения программного обеспечения веб-сервисов распределенной системы автоматизации схемотехнического проектирования

2-1. Математическое обеспечение систем автоматизации схемотехнического проектирования.

2-2. Веб-сервис для проектирования линейных систем в частотной области.

2-3. Веб-сервис для расчета стационарного режима нелинейных систем.

2-4. Сервис-ориентированная интегрированная система для частотного анализа линеаризованных схем.

2-5. Веб-сервис для расчета нелинейных систем в динамическом режиме.

Глава 3. Построение веб-сервисов на основе методов сжатия данных.

3-1. Методы устранения нулевых элементов при хранении и обработке матриц.

3-2. Методика разработки модифицированных версий веб-сервисов.

3-2-1. Модификация на символьном этапе.

3-2-2. Модификация на численном этапе.

3-3. Веб-сервис для расчета чувствительности схемных функций к вариации параметров.

3-3-1. Построение метода веб-сервиса на основе дифференцирования уравнений.

3-3-2. Метод веб-сервиса на основе присоединенной схемы.

3-4. Веб-сервис для расчета чувствительности переменных стационарного режима.

3-4-1. Построение метода веб-сервиса для расчета векторной чувствительности переменных.

3-4-2. Метод веб-сервиса для расчета скалярной чувствительности переменных.

Глава 4. Методы построения клиентских приложений распределенных САПР.

4-1. Методика построения клиентских приложений на основе WSDL-документа.

4-1-1. Развертывание веб-сервисов на сервере Apache Tomcat.

4-1-2. Методика импортирования файла WSDL и построения каркаса клиентского приложения.

4-2. Клиентские приложения распределенной системы схемотехнического проектирования.

4-2-1. Методика построения консольных клиентов.

4-2-2. Методика построения оконных клиентских приложений.

4-2-3. Методика построения клиентских веб- приложений.

4-3. Развертывание клиентских Java-приложений.

4-3-1. Развертывание клиентских Java-приложений, запускаемых из командной строки.

4-3-2. Развертывание клиентских Java-приложений, запускаемых из веб-броузера.

4-4. Организация взаимодействия клиентских приложений с вебсервисами в гетерогенных средах.

Введение диссертации (часть автореферата) на тему "Исследование и разработка методов построения распределенных систем автоматизированного проектирования на основе технологии веб-сервисов"

Заключение диссертации по теме "Системы автоматизации проектирования (по отраслям)", Анисимов, Денис Андреевич

Список литературы диссертационного исследования кандидат технических наук Анисимов, Денис Андреевич, 2013 год

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

01.06.2006 Майкл Папазоглоу, Виллем-Ян ван ден Хьювел

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

, а потому довольно сложно контролировать и измерять Web-сервисы, управлять их готовностью и производительностью.

Рассмотрим связи между управлением Web-сервисами и традиционными распределенными системами, а также подходы к управлению Web-сервисами и их основообразующие архитектурные концепции.

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

При управлении распределенными системами наборы инструментов и утилиты контролируют их действия, что облегчает принятие управленческих решений и внесение изменений в поведение систем. По традиции основное внимание до сих пор уделялось управлению последовательными уровнями новых технологий, которые вводились в эксплуатацию в распределенных средах. Однако такие методы не отвечают корпоративным требованиям, поскольку не соответствуют бизнес-функциям. Кроме того, многие инфраструктуры системного управления не обеспечивают контроля над соглашениями об уровне обслуживания (service level agreement, SLA) или получения от приложений на базе Web-сервисов информации об обслуживании, необходимой для устранения ошибок.

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

Поставщики средств управления предлагают измерительные инструменты только для конечных точек и узлов-посредников SOAP или серверов UDDI. Обеспечиваемое данными инструментами представление об использовании Web-сервисов приложениями страдает неполнотой: ему не хватает жизненно важной информации о состоянии и характеристиках Web-сервисов. Для получения таких сведений Web-сервисы должны стать измеримыми и более управляемыми. Этого можно достичь только путем стандартизации, которая обеспечит сквозную управляемость всех частей долгоживущей многошаговой транзакции, охватывающей несколько приложений, предприятий и действующих лиц.

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

Управление распределенными сервисами

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

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

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

Требования к качеству

Поставщик и покупатель должны договориться об особенностях сервиса. В приложениях, объединяющих географически распределенные Web-сервисы, такой договор составляет суть корпоративного соглашения SLA. Цель состоит в том, чтобы улучшить фактическое качество услуг (quality of experience, QoE) для внутренних или внешних клиентов. QoE создает единую основу для измерения качества продукта или услуги, в том числе производительности, пред- и послепродажного обслуживания, степени удовлетворенности клиента. Поставщик часто должен заключить и контролировать выполнение несколько внутренних (для бизнеса или конечных пользователей) либо внешних (для поставщиков услуг, партнеров, аутсорсеров и т.д.) соглашений SLA. Вообще говоря, бизнес-процесс предполагает несколько соглашений SLA, управляющих взаимосвязанными услугами в интересах конечного пользователя. Для каждого уровня SLA одну из сторон можно считать поставщиком, а другую - потребителем.

Обеспечение качественного сервис-ориентированного управления требует измерения ключевых показателей эффективности (Key Performance Indicator, KPI) приложений и услуг. Поставщик услуг может рассмотреть общие KPI перед их применением к конкретным приложениям. К общим KPI бизнес-приложений относятся доступность и производительность сервиса, время отклика и скорость выполнения транзакций, время простоя и безопасность. Поставщик должен знать, соответствуют ли его услуги установленным показателям KPI, и бить тревогу в случае «накладок». Ему необходимо установить для сервиса целевые показатели KPI, научиться их измерять и анализировать, а также отчитываться о KPI, отличающихся от целевых.

Web-сервисы не могут самостоятельно выполнять эти сервис-ориентированные функции управления. Поэтому есть острая необходимость в инструментах контроля над Web-сервисами и управления ими.

Концептуальная архитектура управления

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

Консоль управления отображает информацию через интерфейс, позволяющий администраторам контролировать ресурсы и изменять их поведение. Интерфейс управления использует такие механизмы, как журналы, события, команды, интерфейсы API и файлы конфигурации . Как показано в левой нижней части рис. 1, интерфейс также применяет метаданные о свойствах ресурса:

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

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

Платформы распределенного управления

Широко применяются несколько стандартных платформ распределенного управления. Среди наиболее известных следует упомянуть SNMP (Simple Network Management Protocol - «простой протокол управления сетью», www.ietf.org/rfc/rfc1157.txt ), CIM (Common Information Model - «общая информационная модель», www.dmtf.org/standards/cim/ ), WBEM (Web-Based Enterprise Management - «технология корпоративного управления на базе Web», www.dmtf.org/standards/wbem/ ) и OMI (Open Management Interface - «открытый интерфейс управления», www.openview.hp.com/ downloads/try_omi_0001.html ).

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

Модель CIM, разработанная рабочей группой по управлению распределенными системами DMTF (Distributed Management Task Force), описывает все управляемые элементы предприятия, в том числе системы, сети и приложения. CIM не зависит от реализации и позволяет управляющим приложениям собирать необходимые данные из разных источников. Группа разработала также WBEM - набор стандартов управления и технологий Internet, нацеленных на унификацию управления корпоративной вычислительной средой. Опираясь на WBEM, можно построить интегрированный набор инструментов на базе стандартов, использующих преимущества развивающихся Web-технологий.

Интерфейс OMI, совместно разработанный компаниями Hewlett-Packard и webMethods , предоставляет поставщикам систем управления и другим заинтересованным сторонам легкий открытый доступ к управлению ресурсами, связанными с платформой интеграции и к относящимся к ней бизнес-процессам. OMI позволяет управляющим инфраструктурам с помощью программного интерфейса получить доступ к управлению интегрированной платформой бизнес-процессов. Через этот интерфейс пользователи могут управлять набором объектов OMI, представляющих доступные ресурсы.

Управление Web-сервисами

Когда традиционные централизованные управляющие приложения переходят к распределенным динамическим архитектурам SOA, они могут более гибко выполнять основные функции управления. В рамках SOA платформа управления Web-сервисами WSMF (Web Services Management Framework) обеспечивает поддержку обнаружения, анализа, защиты и обращения к ресурсам, а также выполнение функций управления и поддержку инфраструктурных управляющих сервисов и наборов инструментов. Те же технологии, определяющие бизнес-процессы и высокоуровневые процессы управления ИТ, теперь могут согласовываться с технологиями менеджеров ресурсов, инфраструктурных сервисов и управления ресурсами.

Методы управления сервисами

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

Управлять инфраструктурой Web-сервисов удается не всегда, но организации могут контролировать поток сообщений SOAP, которыми обмениваются приложения. Действительно, анализ трафика и изменение сообщений SOAP (которые могут быть перехвачены во многих точках сети приложений, связанных через Web-сервисы) являются основными принципами управления Web-сервисами. Контейнеры для сервисов облегчают построение среды потока сообщений типа «запрос-ответ». Подобно контейнерам J2EE, контейнеры для Web-сервисов подразумевают физическое проявление конечной точки абстрактного сервиса и обеспечивают реализацию сервисного интерфейса.

ИТ-администраторы могут вводить средства управления сервисами в конвейер SOAP, используя агентов либо посредников. Управление сервисами с помощью агентов соответствует контейнерному стилю управления. В данном случае «родной» для платформы контейнер Web-сервиса имеет возможности управления. С архитектурной точки зрения выгода этой модели состоит в следующем. Агент способен использовать преимущества конфигурации конкретной инфраструктуры контейнера бизнес-приложений (сервера приложений), который администраторы могут кластеризовать и защищать для достижения требуемого уровня обслуживания.

В отличие от подхода с использованием агентов, который непосредственно связывает управляющие серверы Web-сервисов с контейнерами, посредник (или брокер) действует как клиентская конечная точка, а затем передает запрос фактической конечной точке сервиса (рис. 2 ). Администраторы развертывают средства управления на уровне посредника, что позволяет осуществлять управление и контроль. Посредническая модель полностью отделена от узлов Web-сервисов и может использоваться в любой среде. Через узел-посредник допускается направлять сервисы с нескольких платформ, что также облегчает централизованное конфигурирование и управление.

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

Управление инфраструктурными сервисами

Для управления услугами платформа WSMF использует свойства управляемости архитектурных ресурсов. Они определяют стандартные схемы, метаданные и интерфейсы языка описания Web-сервисов WSDL (Web Services Description Language), описывающие поведение ресурсов, с помощью которого последние обеспечивают доступ к информации об управляемости . Как правило, ресурсы реализуют только применимые, а не все свои стандартные свойства управляемости, которые включают в себя эксплуатационный статус, метрику и отношения.

Свойства управляемости реализуются через информационную модель управляемости, которая представляет управляемость ресурса и сопутствующую информацию, такую как состояние, конфигурация и отношения . Платформа управления сервисами использует информацию из этой модели, которая может, например, указывать, что заголовок сообщения SOAP содержит цифровое удостоверение личности клиента. WSMF извлекает эти сведения и задействует для идентификации клиента (например, при подсчете сообщений SOAP определенного клиента для конкретного Web-сервиса).

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

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

Web-сервис является управляемым, если его свойства управляемости доступны через стандартные интерфейсы управления, подобные функциональным интерфейсам . Интерфейсы управления отличаются лишь тем, что имеют семантику, связанную с управлением, и их использует система управления Web-сервисами, а не клиент. На рис. 3 показаны интерфейсы управления Web-сервиса, доступные для платформы WSMF. Документ WSDL описывает интерфейсы управления и конечные точки, которым WSMF может посылать сообщения, связанные с управлением. WSMF логически играет роль связующего звена между поставщиками и потребителями Web-сервисов.

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

Как показано на рис. 3, наряду с распределенным мониторингом и реализацией политики WSMF предлагает централизованную платформу управления и политик. Она работает совместно с каталогами сервисов и средствами идентификации как при получении информации (такой, как статистика производительности сервисов, сведения о взаимозависимости сервисов), так и при ее отсылке. Политика в виде наборов правил направляется компонентам управления сервисами. Эти правила определяют поведение компонента управления сервисами - когда и куда посылать оповещения, как обрабатывать транзитный трафик сообщений, соблюдать политику защиты и соглашения SLA и т.д.

Управление сервисами и приложениями

В дополнение к традиционным средствам разработки прикладных сервисов для эффективного управления системами и приложениями архитектура SOA на базе Web-сервисов требует двух ключевых функций:

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

На рис. 4 представлены концептуальные компоненты архитектуры, которые объединяют каналы управления сервисами и прикладные каналы, разработанные в соответствии с принципами SOA. Эта архитектура обеспечивает постоянную связь между прикладным каналом Web-сервисов и каналом управления. К числу управляющих приложений, которые она может обслуживать, относятся управление готовностью, производительностью, конфигурацией, заданиями, планирование загрузки, защита ресурсов и поиск неисправностей.

В этой архитектуре управление сервисами подразумевает подбор сервисов, взаимодействующих друг с другом при передаче данных или координации определенных операций, что облегчает оказание одной или нескольких бизнес-услуг. Вместо того чтобы предписывать конкретный протокол управления или технологию измерений, архитектура обеспечивает работу с протоколом SOAP, расширениями JMX (Java Management Extensions), технологией WBEM и другими (в том числе будущими) технологиями и стандартами.

На рис. 4 к управляемым ресурсам относятся физические и логические программные и аппаратные средства. Эти ресурсы публикуют свои свойства управляемости в виде Web-сервисов, которые реализуют разные интерфейсы, например определенные в спецификации распределенного управления Web-сервисами WSDM (Web Services Distributed Management). Интерфейс управления ресурсом описывается документом WSDL, схемой свойств ресурса, документами метаданных и, возможно, набором политик, связанных с управлением.

В процессе управления или в бизнес-процессе менеджеры ресурсов могут непосредственно обращаться к ресурсам. Как показано на рис. 4, на двух взаимодействующих предприятиях бизнес-процесс основан на базовых сервисах, таких как проверка кредитоспособности, отгрузка, обработка заказа и управление складскими запасами. Управляющие приложения архитектуры контролируют ресурсы через их интерфейсы или сервисы инфраструктуры . Эти менеджеры обеспечивают ряд функций, в том числе простой мониторинг, контроль, автономную настройку и восстановление, управление качеством, сквозное управление бизнес-процессами, предоставление системных ресурсов и услуг на основе политик. Обычно они поддерживают интерфейсы и контент для консолей управления и отображают информацию, связанную с управлением. Менеджеры взаимодействуют с ресурсами и сервисами инфраструктуры, применяя интерфейсы Web-сервисов. Кроме того, менеджеры сервисов используют язык WS-BPEL (Web Services Business Process Execution Language) для описания и выполнения процессов управления, которые обеспечивают исполнение заданных сценарием функций управления.

Решения на базе SOA, предназначенные для разработки приложений и управления ими, поощряют применение методов множественного связывания, а также следующие общедоступные сервисы управления:

• управление SLA и фактическим качеством услуг, в том числе измерение производительности и готовности, сервисы оповещения;
• обеспечение видимости и управляемости, в том числе интерактивный мониторинг, администрирование и создание отчетов;
• поддержка адаптируемости сервисов, в том числе контроль над версиями, маршрутизация, дифференцированные услуги и преобразование сообщений;
• поддержка Web-сервисов и механизмов безопасности на основе XML.

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

Литература

1. An Architectural Blueprint for Autonomic Computing. White paper, IBM, Oct. 2004; www-3.ibm.com/autonomic/ pdfs/AC wpFinal.pdf .
2. J.D. Case et al., Introduction to Version 3 of the Internet-Standard Network Management Framework, IETF RFC 2570. Apr. 1999; www.rfc-editor.org/rfc/rfc2570.txt .
3. G. Bullen et al., Open Management Interface Specification, v. 1.0, revision 1, Organization for the Advancement of Structured Information Standards. 2001; www1.webmethods.com/PDF/OMI_Spec.pdf .
4. H. Kreger et al., Management Using Web Services: A Proposed Architecture and Roadmap, tech report, IBM, Hewlitt-Packard and Computer Assoc. June 2005; www-128.ibm.com/developerworks/library/ specification/ws-mroadmap .
5. M. Potts, I. Sedukhin, H. Kreger, Web Services Manageability - Concepts (WS-Manageability), tech. report, IBM, Computer Assoc. and Talking Blocks. Sept. 2003; www3.ca.com/Files/SupportingPieces/ web_service_manageability_concepts.pdf .
6. W. Vambenepe, ed. Web Services Distributed Management:Management Using Web Services (MUWS 1.0) Part 1 and 2, Organization for the Advancement of Structured Information Standards. Mar. 2005; www.oasis-open.org/committees/download.php/11819/ wsdm-muws-part1-1.0.pdf .

Майкл Папазоглоу ([email protected]) - профессор Университета Тилбурга (Голландия). В сферу его научных интересов входят распределенные системы, сервис-ориентированные архитектуры и Web-сервисы, интеграция корпоративных приложений, технологии и приложения электронного бизнеса. Виллем-Ян ван ден Хьювел ([email protected]) - доцент Университета Тилбурга. К его научным интересам относятся сервис-ориентированные архитектуры, эволюция систем и увязка новых корпоративных информационных систем с унаследованными.

Стандарт управления Web-сервисами

Согласованное сквозное управление Web-сервисами невозможно без разработки общеотраслевых стандартов. С этой целью организация OASIS (Organization for the Advancement of Structured Information Standards) активно развивает спецификацию распределенного управления Web-сервисами WSDM (Web Services Distributed Management; www.oasis-open.org ). Она определяет протокол обмена управляющей информацией через Web-сервисы. При решении проблем управления распределенными системами WSDM подразумевает две задачи: управление с использованием Web-сервисов (management using Web services, MUWS) и управление Web-сервисами (management of Web services, MOWS).

MUWS устанавливает использование технологий Web-сервисов как основы современной платформы управления распределенными системами, в том числе применение Web-сервисов для упрощения взаимодействия управляемых ресурсов и управляющих приложений. Так, MUWS определяет, как описывать свойства управляемости ресурсов с помощью документов WSDL. Описание этих свойств способствует более эффективному выявлению и анализу ресурсов. Поскольку ИТ-менеджеры обычно фокусируются на конкретной задаче или области управления, они должны иметь возможность эффективно выявлять подходящие свойства управляемого ресурса.

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

Michael Papazoglou, Willem-Jan van den Heuvel, Web Services Management: A Survey, IEEE Internet Computing, Nov/Dec 2005. IEEE Computer Society, 2005, All rights reserved. Reprinted with permission.

Web-сервисы - новое слово в технологии распределенных систем. Спецификация Open Net Environment (ONE) корпорации Sun Microsystems и инициатива. Net корпорации Microsoft обеспечивают инфраструктуры для написания и развертывания Web -сервисов. В настоящий момент имеется несколько определений Web -сервиса. Web -сервисом может быть любое приложение, имеющее доступ к Web , например, Web -страница с динамическим содержимым. В более узком смысле Web -сервис - это приложение, которое предоставляет открытый интерфейс, пригодный для использования другими приложениями в Web . Спецификация ONE Sun требует, чтобы Web -сервисы были доступны через HTTP и другие Web -протоколы, чтобы дать возможность обмениваться информацией посредством XML -сообщений и чтобы их можно было найти через специальные сервисы - сервисы поиска. Для доступа к Web -сервисам разработан специальный протокол - Simple Object Access Protocol (SOAP) ,который представляет средства взаимодействия на базе XML для многих Web -сервисов. Web -сервисы особенно привлекательны тем, что могут обеспечить высокую степень совместимости между различными системами.

Гипотетический Web -сервис, разработанный в соответствии с архитектурой ONE Sun , может принимать форму, в которой реестр сервисов публикует описание Web -сервиса в виде документа .

Огромный потенциал Web -сервисов определяется не технологией, примененной для их создания. HTTP , XML и другие протоколы, используемые Web -сервисами, не новы. Функциональная совместимость и масштабируемость Web -сервисов подразумевает, что разработчики могут быстро создавать большие приложения и более крупные Web -сервисы из меньших Web -сервисов. Спецификация Sun Open Net Environment описывает архитектуру для создания интеллектуальных Web-сервисов .Интеллектуальные Web -сервисы задействуют общее операционное окружение. Совместно используя контекст, интеллектуальные Web -сервисы могут выполнять стандартную аутентификацию для финансовых транзакций, предоставлять рекомендации и указания в зависимости от географического местоположения компаний, участвующих в электронном бизнесе .

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

Взаимосвязь этих технологий условно представлена на рис. 10.1 .

Рис. 10.1.

По сути, Web -сервисы являются одним из вариантов реализации компонентной архитектуры , при которой приложение рассматривается как совокупность компонентов, взаимодействующих друг с другом. Как уже неоднократно говорилось, взаимодействие компонент, выполняющихся на разных платформах, представляет собой достаточно сложную задачу, в частности, требует разработки коммуникационного протокола , учитывающего особенности передачи данных между различными платформами. Одной из основных идей, положенных в основу рассматриваемой технологии Web -сервисов, является отказ от бинарного коммуникационного протокола . Обмен сообщениями между компонентами системы осуществляется посредством передачи XML -сообщений. Поскольку XML -сообщения представляют собой текстовые файлы, транспортный протокол передачи может быть самый различный - XML -сообщения можно передавать по HTTP -, SMTP -, FTP -протоколам, причем использование различных транспортных протоколов прозрачно для приложений. Как уже говорилось, протокол, обеспечивающий возможность взаимодействия Web -сервисов, называется SOAP (Simple Object Access Protocol ). Он определен на основе XML . SOAP обеспечивает взаимодействие распределенных систем, независимо от объектной модели или используемой платформы. Данные в рамках SOAP передаются в виде XML -документов особого формата. SOAP не навязывает какого-либо определенного транспортного протокола. Однако в реальных приложениях наиболее часто реализуется передача SOAP -сообщений по протоколу HTTP . Также широко распространено использование в качестве транспортного протокола SMTP , FTP и даже "чистого" TCP . Итак, SOAP определяет механизм, с помощью которого Web -сервисы могут вызывать функции друг друга. В каком-то смысле работа этого протокола напоминает вызов удаленной процедуры - вызывающая сторона знает имя Web -сервиса, имя его метода, параметры, которые метод принимает, оформляет вызов этого метода в виде SOAP -сообщения и отсылает его Web -сервису.

Однако описанный подход годится лишь в том случае, если заранее известны "сигнатуры" методов, которые реализует Web -сервис. Но как быть, если это не так? Для решения этой проблемы в модель Web -сервиса введен дополнительный слой - слой описания интерфейсов сервисов. Этот слой представлен в виде описания WSDL .

Согласно определению W3C , " WSDL - формат XML для описания сетевых сервисов как набора конечных операций, работающих при помощи сообщений, содержащих документно-ориентированную или процедурно-ориентированную информацию". Документ WSDL полностью описывает интерфейс Web -сервиса с внешним миром. Он предоставляет информацию об услугах, которые можно получить, воспользовавшись методами сервиса, и способах обращения к этим методам. Таким образом, в случае если сигнатура метода Web -сервиса точно не известна (например, она изменилась со временем), у целевого Web -сервиса может быть запрошено WSDL -описание - файл, в котором эта информация будет содержаться.

Следующим слоем технологии является сервис Universal Description, Discovery and Integration (UDDI) .Эта технология предполагает ведение реестра Web -сервисов. Подключившись к этому реестру, потребитель сможет найти Web -сервисы, которые наилучшим образом подходят для решения его задач. Технология UDDI дает возможность поиска и публикации нужного сервиса, причем эти операции могут быть выполнены как человеком, так и другим Web -сервисом или специальной программой-клиентом. UDDI , в свою очередь, также представляет собой Web -сервис.

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

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

Следует отметить, что с их применением могут строиться и так называемые "стандартные" приложения, где в качестве Web -сервиса оформляется серверная часть.

Простой протокол доступа к объектам (SOAP)

Базовым протоколом, обеспечивающим взаимодействие в среде Web -сервисов, является протокол

Изначально World Wide Web (WWW) представлялась ее создателям как "пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой". Поэтому первые Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная.

Следующим этапом развития Веб стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем – на ISAPI. Common Gateway Interface (CGI) – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Веб-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Веб-страниц и наполнение Веб перестало быть чисто статическим.

Интерфейс ISAPI – это особенность Microsoft Internet Information Server. ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Веб-сервера. У других Веб-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Веб-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). У довольно популярного Веб-сервера Apache также имеется возможность выполнять Веб-приложения, реализованные в виде библиотек; такие библиотеки называются Apache DSO (Dynamic Shared Objects ).

Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра.

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

Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Веб-страницы кода, выполняемого Веб-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.

Новейшая версия технологии Active Server Pages – ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Веб-приложения и Веб-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Веб-приложений.

В общем случае клиентом Веб-сервера может быть не только персональный компьютер, оснащенный обычным Веб-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Веб-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP – Wireless Access Protocol) и соответствующие языки разметки ( WML – Wireless Markup Language, СHTML – Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования).

Другим способом поддержки различных типов клиентов является создание "разумных" серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET.

Другим направлением развития клиентских частей Веб-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Веб-браузере. В частности, современные Веб-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Веб-страницу, но интерпретируется не Веб-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты – специальные Java-приложения, которые пользователь получает в составе Веб-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX – выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Веб-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.

Отметим, что с ростом объема используемых данных и числа посетителей Веб-сайтов возрастают и требования к надежности, производительности и масштабируемости Веб-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Веб-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Веб-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в сервер приложений в виде бизнес-объектов. В зависимости от типа сервера приложений подобные бизнес-объекты могут быть выполняющимися самостоятельно COM-серверами, CORBA-серверами, а также объектами COM+, выполняющимися с помощью служб компонентов Windows 2000, или объектами EJB (Enterprise Java Beans), исполняемыми сервером приложений , поддерживающим спецификаци ю J2EE (Java 2 Enterprise Edition). В качестве механизма доступа к данным подобные объекты могут использовать OLE DB, ODBC, JDBC (это зависит от того, как реализован бизнес-объект).

Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Веб-сайт с CRM-системами (Customer Relationship Management) или с ERP-системами (Enterprise Resource Planning), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.

Поскольку современный Интернет – это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Интернет таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа "предприятие-клиент" ( B2C – business-to-consumer). Не менее важными становятся и задачи интеграции Веб-приложений c данными и приложениями партнеров с целью реализации схемы "предприятие-предприятие" ( B2B – business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки.

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

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

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

Обобщая вышесказанное можно выделить основные особенности веб-архитектуры [ , ]:

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

Схематически такую архитектуру (в трехзвенном варианте) можно представить, как показано на рис. 5.9 .

Рис. 5.9.

5.1.8. Сервис-ориентированная архитектура

Решение многих описанных выше задач, возникающих при создании современных Веб-приложений, теперь начинает возлагаться на Веб-сервисы – не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Веб-приложений (а также из самих Веб-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP . Для описания Веб-сервисов используется XML-подобный язык WSDL, а для организации реестров Веб-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах – интерфейс UDDI .

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

(SOA, service-oriented architecture) – модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами .

OASIS (Организация по распространению открытых стандартов структурированной информации) определяет SOA следующим образом ( OASIS Reference Model for Service Oriented Architecture V 1.0): Сервисно-ориентированная архитектура – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение.

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

Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.)

Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределенных программных комплексов.

SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft).

Основными целями применения SOA для крупных информационных систем, уровня предприятия, и выше являются :

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

Принципы SOA:

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

Архитектура не привязана к какой-то определенной технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать, дополнительно, механизм файловой системы, для обмена данными.

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

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

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах.Net и сервисы на Java, работающие на платформах Java EE , могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

(Материал сайта http://se.math.spbu.ru)

Введение.

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

Существует шесть основных характеристик распределенных систем.

1. Совместное использование ресурсов. Распределенные системы допускают совместное использование как аппаратных (жестких дисков, принтеров), так и программных (файлов, компиляторов) ресурсов.
2. Открытость. Это возможность расширения системы путем добавления новых ресурсов.
3. Параллельность. В распределенных системах несколько процессов могут одновременно выполнятся на разных компьютерах в сети. Эти процессы могут взаимодействовать во время их выполнения.
4. Масштабируемость . Под масштабируемостью понимается возможность добавления новых свойств и методов.
5. Отказоустойчивость. Наличие нескольких компьютеров позволяет дублирование информации и устойчивость к некоторым аппаратным и программным ошибкам. Распределенные системы в случае ошибки могут поддерживать частичную функциональность. Полный сбой в работе системы происходит только при сетевых ошибках.
6. Прозрачность. Пользователям предоставляется полный доступ к ресурсам в системе, в то же время от них скрыта информация о распределении ресурсов по системе.

Распределенные системы обладают и рядом недостатков.

1. Сложность . Намного труднее понять и оценить свойства распределенных систем в целом, их сложнее проектировать, тестировать и обслуживать. Также производительность системы зависит от скорости работы сети, а не отдельных процессоров. Перераспределение ресурсов может существенно изменить скорость работы системы.
2. Безопасность . Обычно доступ к системе можно получить с нескольких разных машин, сообщения в сети могут просматриваться и перехватываться. Поэтому в распределенной системе намного труднее поддерживать безопасность.
3. Управляемость . Система может состоять из разнотипных компьютеров, на которых могут быть установлены различные версии операционных систем. Ошибки на одной машине могут распространиться непредсказуемым образом на другие машины.
4. Непредсказуемость . Реакция распределенных систем на некоторые события непредсказуема и зависит от полной загрузки системы, ее организации и сетевой нагрузки. Так как эти параметры могут постоянно изменятся , поэтому время ответа на запрос может существенно отличаться от времени.

Из этих недостатков можно увидеть, что при проектировании распределенных систем возникает ряд проблем, которые надо учитывать разработчикам.

1. Идентификация ресурсов . Ресурсы в распределенных системах располагаются на разных компьютерах, поэтому систему имен ресурсов следует продумать так, чтобы пользователи могли без труда открывать необходимые им ресурсы и ссылаться на них. Примером может служить система URL(унифицированный указатель ресурсов), которая определяет имена Web-страниц.
2. Коммуникация . Универсальная работоспособность Internet и эффективная реализация протоколов TCP/IP в Internet для большинства распределенных систем служат примером наиболее эффективного способа организации взаимодействия между компьютерами. Однако в некоторых случаях, когда требуется особая производительность или надежность, возможно использование специализированных средств.
3. Качество системного сервиса . Этот параметр отражает производительность, работоспособность и надежность. На качество сервиса влияет ряд факторов: распределение процессов, ресурсов, аппаратные средства и возможности адаптации системы.
4. Архитектура программного обеспечения . Архитектура ПО описывает распределение системных функций по компонентам системы, а также распределение этих компонентов по процессорам. Если необходимо поддерживать высокое качество системного сервиса, выбор правильной архитектуры является решающим фактором.

Задача разработчиков распределенных систем - спроектировать программное и аппаратное обеспечение так, чтобы предоставить все необходимые характеристики распределенной системы. А для этого требуется знать преимущества и недостатки различных архитектур распределенных систем. Выделяется три типа архитектур распределенных систем.

1. Архитектура клиент/сервер . В этой модели систему можно представить как набор сервисов, предоставляемых серверами клиентам. В таких системах серверы и клиенты значительно отличаются друг от друга.
2. Трехзвенная архитектура . В этой модели сервер предоставляет клиентам сервисы не напрямую, а посредством сервера бизнес-логики .

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

1. Архитектура распределенных объектов . В этом случае между серверами и клиентами нет различий и систему можно представить как набор взаимодействующих объектов, местоположение которых не имеет особого значения. Между поставщиком сервисов и их пользователями не существует различий.

Эта архитектура широко применяется в настоящее время и носит также название архитектуры веб-сервисов . Веб-сервис - это приложение, доступное через Internet и предоставляющее некоторые услуги, форма которых не зависит от поставщика (так как используется универсальный формат данных - XML) и платформы функционирования. В данное время существует три различные технологии, поддерживающие концепцию распределенных объектных систем. Это технологии EJB, CORBA и DCOM.

Для начала несколько слов о том, что такое XML вообще. XML - универсальный формат данных, который используется для предоставления Web-сервисов. В основе Web-сервисов лежат открытые стандарты и протоколы: SOAP, UDDI и WSDL.

1. SOAP (Simple Object Access Protocol ), разработанный консорциумом W3C, определяет формат запросов к Web-сервисам. Сообщения между Web-сервисом и его пользователем пакуются в так называемые SOAP-конверты (SOAP envelopes , иногда их ещё называют XML-конвертами). Само сообщение может содержать либо запрос на осуществление какого-либо действия, либо ответ - результат выполнения этого действия.
2. WSDL (Web Service Description Language). Интерфейс Web-сервиса описывается в WSDL-документах (а WSDL - это подмножество XML). Перед развертыванием службы разработчик составляет ее описание на языке WSDL, указывает адрес Web-сервиса, поддерживаемые протоколы, перечень допустимых операций, форматы запросов и ответов.
3. UDDI (Universal Description, Discovery and Integration) - протокол поиска Web- сервисов в Internet (http://www.uddi.org/ ). Представляет собой бизнес-реестр, в котором провайдеры Web-сервисов регистрируют службы, а разработчики находят необходимые сервисы для включения в свои приложения.

Из доклада может показаться, что Web-сервисы - наилучшее и безальтернативное решение, и вопрос только в выборе средств разработки. Однако это не так. Альтернатива Web-службам существует, это семантический Web (Semantic Web ), о необходимости создания которого уже пять лет назад говорил создатель WWW Тим Бернерс-Ли .

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

Список литературы

1. Соммервилл И. Инженерия программного обеспечения.
2. Драница А. Java против.NET. - "Компьютерра ", #516.
3. Ресурсы интернет.