(Материал сайта 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. Ресурсы интернет.

Архитектура распределенных информационных систем и Web-приложений

Распределенная система - это набор независимых вычислительных машин, представляющийся их пользователям единой объединенной системой. Не смотря на то, что все компьютеры автономны, для пользователей они представляются единой системой.

К основным характеристикам распределенных систем:

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

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

Распределенные системы должны также относительно легко поддаваться расширению, или масштабированию. Эта характеристика является прямым следствием наличия независимых компьютеров, но в то же время не указывает, каким образом эти компьютеры на самом деле объединяются в единую систему.

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

Соответственно, такая распределенная система обычно называется системой промежуточного уровня (middleware). Отметим, что промежуточный уровень распределен среди множества компьютеров.

К особенностям функционирования распределенных систем относятся:

· наличие большого количества объектов;

· задержки выполнения запросов (так если локальные вызовы требуют порядка пары сотен наносекунд, то запросы к объекту в распределенных системах требует от 0.1 до 10 мс);

· некоторые объекты могут не использоваться на протяжении длительного времени;

· распределенные компоненты выполняются параллельно, что приводит к необходимости согласования выполнения;

· запросы в распределенных системах имеют большую вероятность отказов;

· повышенные требования к безопасности.

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

Для борьбы с отказами клиенты обязаны проверять факт выполнения запросов сервером. Безопасность в распределенных приложениях может быть повышена путем контроля сеансов связи (аутентификация, авторизация, шифрование данных).

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

Рисунок 1.12 – Схема доступа к серверу СУБД через Интернет

В настоящее время существуют три различных технологии, поддерживающие концепцию распределенных объектных систем: EJB, DCOM CORBA.

Основная идея, лежащая в разработке технологии EJB (Enterprise Java Beans ) – создать такую инфраструктуру для компонентов, чтобы они могли бы легко вставляться и удаляться из серверов, тем самым повышая или снижая функциональность сервера. EJB-компоненты являются Java-классами и могут работать на любом EJB-совместимом сервере даже без перекомпиляции. Основными целями EJB-технологии является:

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

2. Описать основные структуры EJB-системы и интерфейсы взаимодействия между ее компонентами.

3. Освободить разработчика от реализации EJB-объектов за счет наличия специального кодогенератора.

Благодаря используемойJava-модели, EJB является относительно простым и быстрым способом создания распределенных систем.

Технология DCOM (Distributed Component Object Model ) - программная архитектура, разработанная компанией Microcoft для распределения приложений между несколькими компьютерами в сети. Программный компонент на одном из компьютеров может использовать DCOM для передачи сообщений к компоненту на другом компьютере. DCOM автоматически устанавливает соединение, передает сообщение и возвращает ответ удаленного компонента. Способность DCOM связывать компоненты позволила Microcoft наделить Windows рядом дополнительных возможностей, в частности, реализовать сервер Microsoft Transaction Server, отвечающий за выполнение транзакций баз данных через Интернет.

В данной статье мне хотелось бы обсудить вопросы, связанные с проектированием web сервисов, предназначенных для межпрограммного взаимодействия. Так называемых – интеграционных web сервисов. Прежде всего, это сервисы, которым предстоит работать в различных решениях класса Enterprise Applications Integration (EAI), а также в B2B решениях. Вопросам разработки web сервисов с использованием различных платформ посвящено множество книг и статей, а вот вопросы проектирования освещены гораздо хуже. Вы можете найти массу статей с заклинаниями на тему SOA, которые будут совершенно бесполезны, когда вы приступите к проектированию своего web сервиса.
Итак, давайте рассмотрим ситуацию, когда у вас на руках есть две работающие системы (либо проекты двух систем), и перед вами стоит задача организовать взаимодействие между ними. Вам надоели схемы синхронизации на основе файлов импорта / экспорта, и вы остановили свой выбор на модной, современной и удобной технологии web сервисов. Я попытаюсь рассказать о том, на что следует обратить внимание и как избежать типичных ошибок при проектировании web сервиса для взаимодействия двух систем.

Немного SOA

И все же, сначала пару слов о небезызвестной SOA. Термин Service Oriented Architecture (SOA) довольно серьезно пострадал от беспорядочного употребления в маркетинговых целях. Его так часто употребляют в различных контекстах, что теперь сказать что-то определенное о SOA, кроме того, что это - «сервис ориентированная архитектура», уже трудно.
Тем не менее, SOA имеет такое же право на жизнь, как и «клиент – серверная архитектура» или «много уровневая архитектура». Как и любая другая «архитектура», SOA вводит ряд абстракций и правил, которые помогают нам в разработке определенного класса приложений. В данном конкретном случае, руководствоваться принципами SOA полезно при разработке механизмов взаимодействия и интеграции приложений в масштабе предприятия (Enterprise Applications Integration - EAI).
Итак, начнем с того, что SOA рассматривает приложения как сервисы или совокупности сервисов, которые обмениваются сообщениями напрямую, либо посредством некоторых интеграционных механизмов. Эти сервисы должны удовлетворять ряду условий или требований.
Во-первых, сервис должен иметь определенное «business value», иными словами, сервис должен иметь прикладное значение. Если вы не можете простыми словами объяснить заказчику или пользователю системы для чего нужен ваш сервис, то с точки зрения SOA это неудачный сервис. Пример плохого сервиса: «Сервис для получения глобально – уникальных идентификаторов». Пример хороших сервисов: «Сервис данных о сотрудниках предприятия» или «Сервис приема и обработки счетов к оплате» (Accounts Payable).
Во-вторых, с точки зрения SOA, сервисы должны быть автономными и независимыми. Это необходимо для того, чтобы как это принято в SOA, мы могли комбинировать одни сервисы с другими в зависимости от потребностей бизнеса. Если мы захотели использовать «Сервис приема и обработки счетов к оплате» и при этом узнаем, что нам придется установить и использовать «Сервис бюджетирования и финансового планирования», «Сервис ведения главной книги», и еще дюжину сервисов, то с точки зрения SOA все это выглядит просто отвратительно.
В-третьих, сервис должен быть функционально полным с прикладной точки зрения. Это требование комплиментарно предыдущему. Например, «Сервис приема и обработки счетов к оплате» позволяет добавить заявку, а отследить ее статус не позволяет. Но в принципе мы можем получить отчет по заявкам, из которого можно узнать о статусе заявки. Не правда ли, знакомая ситуация? С точки зрения SOA, да и с любой точки зрения – это не правильно. Сервис должен обеспечивать выполнение всех основных бизнес операций, связанных с прикладной областью или бизнес процессом, который он обеспечивает.
В-четвертых, все сервисы должны уметь предоставлять свои описания в некотором стандартизированном формате. WSDL и UDDI - это варианты форматов описания сервисов.
В-пятых, сервисы должны быть ориентированы на распределенное асинхронное взаимодействие без хранения состояния. Это типично для большинства современных распределенных систем, и это очень важное требование. Достаточно вспомнить, что клиент-серверная архитектура ориентирована на синхронное взаимодействие с хранением состояния, и именно это обстоятельство стало ключевым ограничением для дальнейшего развития этой архитектуры.
В-шестых, SOA предполагает, что благодаря выполнению предыдущих требований, сервисы будут способны объединяться для взаимодействия друг с другом при помощи различных интеграционных инструментов, типа брокеров и маршрутизаторов сообщений, серверов workflow и т.д. и т.п. Ключевым моментом здесь является тот факт, что интеграционные сценарии будут основываться на конфигурировании, часто визуальном, а не на разработке специального «интегрирующего» кода, как это делается в большинстве случаев сейчас.
Вот примерно так выглядят основные вехи, на которые мы должны ориентироваться и которые должны ограничивать нашу разыгравшуюся дизайнерскую мысль в процессе проектирования и разработки интеграционных web сервисов.

Проектирование контракта сервиса.

После того, как Microsoft в своей платформе Windows Communication Foundation – WCF (бывшая Indigo) использовала термин «контракт сервиса», он имеет все шансы сделаться стандартным термином де-факто.
Контракт сервиса - это описание сигнатур всех его операций (методов), плюс описание форматов данных, которыми он оперирует в качестве входных и выходных сообщений.
Для web сервисов контракт исчерпывающе описывается WSDL схемой сервиса. Однако согласитесь, что WSDL не очень хорошо приспособлен для человеческого восприятия. Гораздо нагляднее контракт можно изобразить в виде UML диаграммы классов. К счастью, большинство современных платформ для разработки web сервисов обеспечивают функцию автоматической генерации WSDL описания сервисов.
Правильно спроектированный контракт сервиса, залог успеха, и гарантия того, что ваш сервис проживет долгую и счастливую жизнь, и умрет своей смертью, потому что на смену ему придет новая технология, о которой мы сейчас ничего не знаем.
Microsoft предлагает специальный термин – “contract first” для описания подхода к проектированию, ориентированного в первую очередь, на контракт. Он предполагает, что проектирование сервиса должно начинаться с описания XSD схем сообщений (данных), затем создается WSDL описание операций сервиса, по которому генерируется код класса сервиса. И лишь после этого приступают к имплементации логики. Идея здравая, однако, я повторюсь, что работать с XSD и WSDL не очень удобно, даже с использованием визуальных средств типа XmlSpy. Кроме того, сам по себе принцип “contact first” не гарантирует нам получения правильного контракта сервиса.
Для меня принцип “contact first” означает, что при проектировании сервиса мы должны в первую очередь думать о его контракте и в последнюю - о деталях реализации. Следует взглянуть на будущий сервис c внешней стороны, глазами потребителя данных этого сервиса. Такой взгляд упрощает транспонирование требований предъявляемых к сервису в набор предоставляемых им операций. Например, мы разрабатываем сервис, предоставляющий данные о сотрудниках предприятия. Логично предусмотреть в нем операцию, возвращающую список всех сотрудников. Однако, в ходе анализа требований может оказаться, что потребителю данных нашего сервиса будет интересен, в первую очередь, список сотрудников конкретного подразделения. Это говорит нам о том, что в контракт операции, возвращающей список сотрудников, следует добавить параметр, позволяющий отфильтровать сотрудников конкретного подразделения, либо, нам следует выделить это действие в отдельную операцию сервиса. Такой подход будет соответствовать принципу “contract first”. И напротив, мы могли бы возложить на потребителя данных нашего сервиса обязанность выбрать сотрудников нужного ему отдела из общего списка. Придерживаться подобной стратегии при проектировании интеграционных сервисов – плохая практика. Разбирая конкретный данный случай, мы можем говорить о том, что такое решение не оптимально с точки зрения нагрузки на сервис или объема трафика, а также что такое решение снижает безопасность. Обобщая, можно сказать, что основания простоты и универсальности не должны превалировать при проектировании сервиса. Универсальность сервиса должна достигаться тщательным дизайном. Крайне сложно дать какие либо практические рекомендации в данном направлении. Не легко создать сервис, который бы не состоял из одного метода, вываливающего все внутренние данные системы наружу, и в тоже время был достаточно универсальным для того, чтобы его смог использовать не только тот потребитель, для которого вы проектировали сервис, но и любой другой. Чтобы добиться этого, следует обращать внимание на функциональную полноту контракта сервиса.
Давайте рассмотрим пример. Предположим, существует некая система учета и согласования счетов к оплате, из разряда тех, что обозначаются термином Accounts Payable. Система позволяет вводить данные счетов к оплате, обеспечивает бизнес процесс их согласования и, далее взаимодействует с бухгалтерской системой для формирования платежей. Ввод счетов и их согласование осуществляется, через UI системы. Перед нами стоит задача: создать web сервис, посредством которого другие системы могли создавать счета и отслеживать их статус.
Для простоты, будем считать, что счет к оплате имеет следующую структуру:

Где:
Number – уникальный номер счета, присваиваемый при создании
RecipientID – ссылка на справочник контрагентов, в котором хранятся все реквизиты получателя платежа
Amount – сумма к оплате
PaymentDate – дата оплаты
CategoryID – ссылка на справочник категорий платежей
Owner - имя сотрудника, который создал счет
Description – описание
State – состояния счета, вокруг которого строится бизнес процесс согласования счета.
Итак, исходные требования нам ясны. Схема данных для представления счета, тоже понятна. На основе представленной диаграммы будет создана вот такая XML схема, которая нас вполне устраивает:

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

Выглядит просто ужасно! Давайте разберем, что здесь не так.
Метод добавления счета AddPayment() принимает в качестве параметра структуру Payment, а возвращает номер, присвоенный счету. Структура Payment не очень подходящий тип данных для параметра этого метода, потому что она содержит ряд полей, заполнение которых подчиняется внутренней бизнес логике системы. Это поля Number, State и Owner. Мы не знаем этих бизнес правил, и не знаем, как заполнять эти поля. Для создания счета мы должны указать: получателя, сумму платежа, дату, категорию и описание. Поэтому имеет смысл создать метод именно с такими параметрами, который создаст счет к оплате и вернет его в структуре Payment.
Метод ListPayments() возвращает список счетов в виде массива структур Payment. Возможно, система должна возвращать только те счета, которые были созданы данным пользователем. Однако отсутствие соответствующего параметра в сигнатуре метода не должно вас удивлять. Более надежный и безопасный способ получить данные о пользователе, - взять их из данных аутентификации. Со временем в системе может накопиться огромное количество счетов, и данному методу не помешали бы параметры для фильтрации выдаваемого списка по датам.
Наконец, метод RemovePayment() - принимает номер счета и возвращает true в случае успешного удаления и false в противном случае. Использование Boolean в качестве результата не лучшее решение в данном случае. Причины неудачи операции удаления могут быть самыми различными от простого отсутствия счета с указанным номером, до нарушения логических ограничений системы (например, нельзя удалить счет со статусом Commited). Ситуация довольно распространенная. Ошибка может случиться при выполнении любого метода web сервиса, и, к счастью, инфраструктура web сервисов предлагает стандартный подход к решению этой проблемы. Для передачи данных об ошибке используется SOAP сообщение, в теле которого содержится элемент Fault с информацией об ошибке. Таким образом, нам не нужно расширять контракт нашего web сервиса для передачи сообщений об ошибках, и в случае метода RemovePayment() мы можем вполне обойтись без возвращаемого значения. В случае неудачи удаления счета, информация о причине будет передана в сообщении об ошибке.
После всех изменений наш web сервис будет выглядеть так:

Выглядит значительно лучше, но проблемы остались.
Давайте посмотрим на метод CreatePayment(). Для того чтобы создать счет, нам надо передать пять параметров. С параметрами amount, date, desc, у нас проблем нет. Но вот откуда взять ссылки на получателя (recipient) и категорию (category)? Как я уже упоминал, эти данные представляют собой ссылки на элементы соответствующих справочников нашей системы. И теперь нам становится понятно, что для успешного использования нашего web сервиса, мы должны предоставить доступ к значениям этих справочников.


Таким образом, окончательный вид контракта нашего web сервиса дополнился двумя методами EnumRecipient() и EnumCategory() и двумя типами данных RecipientInfo и CategoryInfo. Их не было в первоначальном контракте и необходимость этих методов не определяется первоначальными требованиями. Они служат для обеспечения синтаксической полноты контракта нашего сервиса. Теперь потребитель данных сервиса может вызвать методы EnumRecipient() и EnumCategory() для получения списков получателей и категорий, выбрать из них необходимые значения, и затем вызвать метод CreatePayment() для создания счета.
Теперь мы можем сказать, что мы спроектировали функционально и синтаксически полный сервис. Также, наш сервис достаточно универсален, и с большой вероятностью его удастся использовать для интеграции с другими системами, перед которыми будут стоять похожие задачи. Кроме того, контракт сервиса и его WSDL описание, включают в себя полные схемы данных всех сообщений. Это очень важно для того, чтобы наш сервис смогли использовать инструменты интеграции типа BizTalk Server, Fiorano ESB, Sonic ESB и др.
На последнем моменте хочется заострить внимание. Формат данных, которыми обменивается сервис, очень важен. Разработчики нередко впадают в одну из двух крайностей. Первая из них, это использование в качестве формата для всех сообщений «голого Xml». Причины тому могут быть самые разные, от попыток использования существующего кода импорта - экспорта Xml данных, до слишком буквального понимания сути web сервисов, как механизма обмена Xml сообщениями. Недостаток такого подхода достаточно очевиден, - схема данных не попадает в WSDL описание контракта сервиса, и это затрудняет его использование. На мой взгляд, существует единственный случай, когда такой подход оправдан. Это случай, когда нам заранее не известен формат передаваемых данных. Во всех остальных случаях, следует использовать типизированные сообщения.
Вторая крайность, это противоположность первой, и выражается она в том, что разработчики пытаются использовать в контракте сервиса существующие в системе внутренние форматы представления данных. Действительно, если в системе уже определены структуры и классы для представления данных (Data Transfer Objects), то почему бы не использовать их в контракте сервиса? Это не всегда это хорошая идея. Внутренние форматы данных могут оказаться не удобными для клиента сервиса. Они могут иметь специфический формат, который не поддерживается клиентской стороной. Пример такого формата DataSet из Microsoft ADO.NET. Данные DataSet прекрасно преобразуются XML и могут быть использованы ASP.NET web сервисами. Однако, это внутренний формат Microsoft, который не является отраслевым стандартом, он имеет свои особенности форматирования Xml представления, которые могут затруднить использование этих данных другими программными платформами web сервисов. Существует масса случаев, в которых использование DataSet оправданно и удобно, но интеграционные сервисы не относятся к их числу.
Таким образом, общие рекомендации по проектированию форматов сообщений web сервисов сводятся к следующему. Всегда старайтесь использовать типизированные сообщения, формат которых описывается определенной Xsd схемой. Проектируйте формат сообщений исходя из функциональных требований, и лишь в том случае, когда полученный формат совпадает с внутренним форматом данных системы, можно подумать об использовании внутреннего формата.

Протокол взаимодействия и его влияние на контракт

Под протоколом взаимодействия web сервиса мы понимаем ту часть требований, которая описывает последовательность взаимодействия сервиса и клиента, направление передачи данных, а также такие аспекты поведения сервиса, как транзакционность, асинхронность, и т.д.
Протокол взаимодействия и контракт сервиса очень тесно связанны. Помимо достаточно простых случаев, когда существует один сервис и его клиент, существуют и более сложные, в которых протокол взаимодействия требует наличия двух и более сервисов. Примером такого протокола может служить протокол асинхронного взаимодействия ASAP
Я не открою большого секрета, если скажу, что отличным способом построить контракт сервиса (по крайней мере, в плане используемых операций) является использование UML диаграмм взаимодействия. Мое личное мнение, наилучшие результаты дает применение Sequence diagram. На рисунке приведена Sequence diagram взаимодействия клиента и сервиса из примера AccountsPayable, рассмотренного выше. К сожалению данный пример достаточно прост, чтобы почувствовать насколько Sequence diagram облегчают проектирование контракта сервиса.

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

Вопросы безопасности

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

• Аутентификация клиентов сервиса
• Авторизация клиентов сервиса
• Безопасность передачи данных
• Хранение удостоверений для подключения клиентов к сервису

Аутентификация – это процесс подтверждения подлинности пользователя на основе предъявленных им удостоверений. Надежность механизмов аутентификации является критичной для обеспечения безопасности приложения в целом. Поэтому сразу стоит забыть об «анонимном доступе». Наилучший сценарий обеспечения аутентификации, воспользоваться средствами, предоставляемыми платформой web сервисов, которую вы используете. Обычно для аутентификации используются специализированные протоколы (Kerberos, NTLM) и их поддержка встраивается в платформу. Реализация собственных механизмов аутентификации наверняка потребует значительных затрат и чревата потенциальными сложностями реализации и дальнейшей поддержки.
Авторизация - это процесс предоставления пользователю полномочий по доступу к функциям и данным. Естественно, для того чтобы авторизовать пользователя, предварительно он должен быть аутентифицирован. Уловите разницу между аутентификацией и авторизацией. Аутентификация отвечает на вопрос «кто» такой клиент, а авторизация – на вопрос «что» может делать этот клиент. В подавляющем большинстве случаев, бизнес правила по которым тому или иному пользователю предоставляются права доступа к тем или иным данным и операциям определяются в самом приложении. И, следовательно, авторизация – это область ответственности приложения, предоставляющего сервис. Существует множество методов, практик и шаблонов реализации механизмов авторизации, описание которых может быть предметом отдельной статьи.
Помимо аутентификации и авторизации, защита данных при транспортировке их между сервисом и его клиентом является третьей составной частью в обеспечении безопасности web сервиса. Степень защиты определяется характером данных. Различают два способа защиты данных: цифровая подпись и шифрование.
Цифровая подпись используется для подтверждения подлинности данных. Она не защищает данные от несанкционированного прочтения, потому что данные не шифруются. Цифровая подпись позволяет удостовериться в том, что данные принадлежат именно владельцу подписи, а также в том, что данные не были изменены с момента подписи. Механизм цифровой подписи довольно прост. Он основан на использовании не симметричных алгоритмов шифрования, в которых используется пара ключей, один из которых приватный (закрытый) а второй публичный (открытый). Особенность не симметричных алгоритмов состоит в том, что данные, которые зашифрованы одним ключом, можно расшифровать только другим ключом. Цифровая подпись формируется следующим образом. Для данных вычисляется контрольная сумма (хэш код), которая шифруется приватным ключом владельца цифровой подписи. Это и есть цифровая подпись, она добавляется к данным. Так же, к данным может быть добавлен открытый ключ. С помощью открытого ключа, любой пользователь может расшифровать цифровую подпись и получить контрольную сумму, которую можно сравнить с контрольной суммой рассчитанной над текущими данными и, таким образом узнать, изменились ли данные.
В случае, когда нам необходимо не только обеспечить неизменность данных, но и скрыть от посторонних их содержимое, применяется шифрование. Обычно, при передаче данных применяется схема с сеансовым ключом, на механизме которой я не буду останавливаться, поскольку обычно она обеспечивается на инфраструктурном уровне. Итак, цифровая подпись и шифрование являются основными механизмами защиты данных при передаче. Мы можем задействовать эти механизмы на уровне транспортного протокола, либо на уровне сообщений SOAP. Каждый из способов имеет свои преимущества и недостатки.
Для обеспечения защиты данных на уровне транспортного протокола обычно применяют хорошо зарекомендовавший себя механизм SSL. При этом между клиентом и сервером устанавливается защищенное соединение, в котором шифруется весь трафик. Преимущество данного подхода состоит в том, что он практически не требует дополнительных усилий со стороны разработчика (за исключением, может быть некоторых особенностей при установлении соединения). Основная работа по настройке защищенного SSL соединения производится при развертывании приложения. К недостаткам такого подхода можно отнести то, что шифруется весь трафик, а не только те данные, которые действительно являются конфиденциальными, и это требует больших затрат вычислительных ресурсов. Описание того, как использовать SSL совместно с web сервисами ASP.NET 1.1 вы можете найти в моей статье по адресу http://stump-workshop.blogspot.com/2006/10/web-https-ssl.html
Механизмы защиты данных на уровне SOAP сообщений строятся на использовании таких расширений SOAP протокола, как WS-SecureConversation , WS-Trust , WS-SecurityPolicy и WS-Security . Обычно поддержка этих спецификаций встроена на уровне платформы, реализующей web сервисы, и для разработчика они доступны как на декларативном уровне (атрибуты или конфигурирование) так и в виде API. К преимуществам использования данных механизмов относится их гибкость и универсальность. Вы можете использовать как шифрование, так и цифровую подпись. Можно обеспечить защиту только сообщений отдельных операций сервиса, и даже отдельных частей SOAP сообщения. К сожалению не все платформы web сервисов в полной мере поддерживают данные спецификации. Например, в широко распространенном.NET Framework 1.1 нет поддержки WS-Security. Поэтому при использовании данной платформы придется реализовывать защиту на транспортном уровне.
Наконец есть третий путь, - реализовать свой механизм защиты как, например, описано . Следует, однако, понимать, что такой путь резко сокращает возможности использования вашего сервиса.
В заключении, стоит остановиться на таком вопросе, как хранение удостоверений для подключения к web сервисам. Мы уже говорили о том, что доступ к web сервисам следует предоставлять только аутентифицированным пользователям. Обратная сторона медали состоит в том, что нам необходимо указывать удостоверения (credentials) при подключении клиента к сервису. А следовательно, нам необходимо где-то хранить эти удостоверения. Когда нашей системе приходится взаимодействовать с несколькими сервисами, каждый из которых требует свои удостоверения, проблема приобретает особую остроту.
Что такое удостоверения. В большинстве случаев - это пара значений логин – пароль. Иногда это может быть клиентский сертификат или другой тип удостоверений, - все зависит от используемого протокола аутентификации. Следует четко понимать, что клиентские удостоверения относятся к данным, которые могут быть использованы для атаки злоумышленника на систему. Следовательно, эти данные требуют защиты. Вам следует учитывать это обстоятельство еще на стадии проектирования. При реализации интеграционных web сервисов, вам наверняка придется затратить некоторые усилия на разработку механизмов защищенного хранения клиентских удостоверений и их настройки / редактирования.

Вопросы реализации

Вопросы реализации web сервисов сильно зависят от платформы, с которой вы работаете, а их на сегодняшний день существует великое множество. Только Microsoft предлагает 4 платформы (ASP.NET 1.1, ASP.NET 2.0, WSE 1.0-3.0, WCF-Indigo). В мире Java их еще больше. Поэтому давать конкретные рекомендации весьма затруднительно. Однако есть моменты, на которые следует обратить внимание в любом случае.
Большинство платформ берут на себя формирование WSDL описания сервиса, предоставляя разработчику возможность работать с сервисом как с обычным классом. Поэтому, следует уделять постоянное внимание тем деталям, которые оказывают влияние на формирование правильного WSDL описания и XSD схем данных. К этим вещам относится использование Xml Namespace и префиксов, управление порядком сериализации данных, порядком и стилем генерации WSDL.
Следует стараться отделить бизнес логику от реализации сервиса. Хорошо, если у вас получится использовать единую бизнес логику внутри приложения и в web сервисе. В идеальном случае методы вашего web сервиса будут лишены всякой логики, кроме проверки параметров, формирования результатов и обработки ошибок, как показано на рисунке:

Заключение

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

, , Терминал , Сервер приложений , Сервер базы данных , Архитектура распределенных систем , , Сервис-ориентированная архитектура .

5.1.1 Основы Web-сервисов

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

В основе Web-сервисов лежат следующие универсальные технологии:

TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;

HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;

XML (Extensible Markup Language)– универсальный язык для работы с любыми типами данных.

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

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

Веб-сервисы могут использоваться во многих приложениях. Независимо от того, откуда запускаются веб-сервисы, с настольных компьютеров клиентов или с переносных, они могут использоваться для обращения к таким интернет-приложениям, как система предварительных заказов или контроля выполнения заказов. Веб-сервисы пригодны для В2В-интеграции (business-to-business), замыкая приложения, выполняемые различными организациями, в один производственный процесс. Веб-сервисы также могут решать более широкую проблему интеграции приложений предприятия (Enterprise Application Integration, EAI), осуществляя связь нескольких приложений одного предприятия с несколькими другими приложениями. Во всех перечисленных случаях технологии веб-сервисов являются "связующим звеном", объединяющим различные части программного обеспечения.

Как видно из рис. 5.1, веб-сервисы представляют собой оболочку, обеспечивающую стандартный способ взаимодействия с прикладными программными средами, такими как системы управления базами данных (СУБД), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), посредники пакетов планирования ресурсов предприятия (Enterprise Resource Planning, ERP), брокеров интеграции и пр.

Рис.5.1. Веб-сервисы взаимодействуют с прикладными системами

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

Простой пример: поиск информации

В настоящее время большинство сервисов вызываются по Сети посредством ввода данных в HTML-формы и отправки этих данных сервису путем добавления их в строку унифицированного указателя информационного ресурса (Uniform Resource Locator, URL):

http://www.google.com/search?q=Skate+boots&btnG=Google+Search

Этот пример иллюстрирует простоту веб-взаимодействия (например, поиска, покупки акций или запроса маршрута движения), где параметры и ключевые слова внедряются непосредственно в URL. В данном случае представлен простой запрос поиска skate boots (ботинки с коньками) в строке обращения к поисковой машине Google. Ключевое слово search (искать) представляет сервис, к которому будет осуществлено обращение, а параметр Skate+boots является строкой поиска, которая была введена в HTML-форме на странице веб-сайта Google. Сервис поиска Google передаст этот запрос к различным поисковым машинам, которые вернут список URL для страниц, на которых имеется соответствие параметру поиска Skate+boots. Данный малоэффективный способ поиска в Сети полностью основан на установлении соответствия указанной текстовой строки и индексированных HTML-страниц.

XML - лучший способ отправки данных. XML предоставляет значительные преимущества при передаче данных через Интернет. Теперь предыдущий запрос можно представить в виде XML-документа:

xmlns:s="www.xmlbus.com/SearchService">

Skate

boots

size 7.5

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

Данный пример представлен в форме SOAP-сообщения (Simple Object Access Protocol) - стандартной формы обмена XML-сообщениями - одной из технологий, лежащих в основе веб-сервисов. В SOAP-сообщении имя запрашиваемого сервиса и входные параметры представлены в виде отдельных XML-элементов. Рассматриваемый пример также иллюстрирует использование пространства имен XML (xmlns:), еще одного важного элемента веб-сервисов. Благодаря тому, что XML-документы поддерживают разные типы данных, сложные структуры и объединение схем, современные технологии веб-сервисов обеспечивают значительное преимущество над существующими возможностями обращения к программным приложениям посредством HTML и URL.

Следующее поколение Сети

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

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

ОБЩЕЕ ВЗАИМОПОНИМАНИЕ

Технология веб-сервисов существует на очень высоком уровне абстракции, позволяя поддерживать множество одновременных определений, которые иногда бывают противоречивы. На простейшем уровне веб-сервисы могут восприниматься как интернет-ориентированные текстовые брокеры интеграции. Любые данные могут преобразовываться в ASCII-текст и обратно, и этот подход в течение долгого времени был общим знаменателем для систем графического вывода и систем управления базами данных. Ориентированные на использование текста системы также лежат в основе успешного развития Интернета, на котором базируется дополнительная абстракция веб-сервисов. Любой компьютер или операционная система может поддерживать HTML, браузеры и веб-сервисы; и при получении по сети файлов им совершенно безразлично и даже неизвестно, с каким типом прикладной системы они взаимодействуют.

Преимущества и недостатки веб-сервисов.

К преимуществам веб-сервисов можно отнести следующее:

Веб-сервисы позволяют компании интегрировать свои бизнес-процессы с бизнес-процессами бизнес-партнеров и клиентов при меньшей стоимости, чем с использованием других интеграционных технологий. Стоимость подобных решений на основе веб-сервисов доступна даже для SMB (Small and Medium Business), что откроет для таких компаний новые перспективы развития;

Поскольку веб-сервисы организуются в публичные реестры (UDDI-реестры, ebXML-реестры или иные), доступные заинтересованным лицам по всему миру, порог выхода компаний на новые рынки снижается, возможности же для наращивания клиентской базы напротив возрастают;

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

Построение новых корпоративных решений с применением веб-сервисов реализуется быстрее и совокупно дешевле, поскольку основное внимание сосредотачивается на создании бизнес-логики решения, программирование самих веб-сервисов лишь по необходимости “обрамляет” этот процесс, не требуя больших трудозатрат за счет эффективного применения повторно используемого кода и адаптированных средств разработки (IDE и SDK).

К недостаткам (минусам) веб-сервисов можно отнести:

Стандарты интеграции бизнес-процессов, вопросы управления транзакциями и выработка единых бизнес- и IT-политик взаимодействующих посредством веб-сервисов компаний находятся пока на стадии разработки (мы отметим следующие начинания: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS (аббревиатура “BPEL” произносится кратко как “бипль”)) корпорации IBM, XLANG корпорации Microsoft и спецификации WS-Coordination и WS-Transaction – результат сотрудничества IBM, Microsoft и BEA). Очевидно, без их четкой формализации и опубликования построение ИС на основе веб-сервисов может идти лишь с переменным успехом;

Динамическое использование информации бизнес-реестров веб-сервисов, вызов веб-сервисов, требует решения вопросов доверительности отношений между различными бизнес-реестрами. Кроме того, есть трудности в совместном использовании бизнес-реестров различных форматов (например, задача поиска определенного веб-сервиса в UDDI-реестре и ebXML-реестре требует различных подходов в силу различия XML-документов, описывающих один и тот же веб-сервис в каждом из этих реестров. Хотя, надо отметить, что есть попытки решить эту проблему созданием единого браузера реестров. В качестве примера - графическая утилита Registry Browser корпорации Sun Microsystems, реализующая набор интерфейсов JAXR (Java API for XML Registries);

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

Вопросы безопасности функционирования ИС на основе веб-сервисов пока не урегулированы до конца. Спецификация WS-Security – продукт деятельности корпораций IBM и Microsoft – в настоящее время достаточно молода, не “устоялась” и частично все еще дорабатывается. Однако, в силу общности положений спецификации WS-Security, уже готовится к выпуску следующий слой спецификаций, посвященных вопросам безопасности: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.

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

Определение веб-сервиса

Назовем сервисом (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:

является повторно используемым;

определяется одним или несколькими явными технологически-независимыми интерфейсами;

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

Веб-сервисом (см. документ W3C “Web-services architecture requirements”) называется программная система, идентифицируемая строкой URI, чьи интерфейсы и привязки определены и описаны посредством XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов.