Проектирование web сервисов. Управление Web-сервисами

В данной статье мне хотелось бы обсудить вопросы, связанные с проектированием 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 сервисов.

Глава 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. Организация взаимодействия клиентских приложений с вебсервисами в гетерогенных средах.

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

Широкое внедрение систем автоматизированного проектирования в практику решения инженерных задач существенно ограничивается высокой стоимостью лицензионного программного обеспечения САПР. Вместе с тем создание собственных систем автоматизированного проектирования связано с огромными затратами ресурсов и не может быть реализовано в сжатые строки, так как на разработку современных САПР требуются сотни человеколет. Проблема усложняется также и тем, что в реальных ситуациях эксплуатации многофункциональные интегрированные САПР (например, Micro-Cap 7, PSPICE, DISPC ) используются, как правило, крайне неэффективно, поскольку в процессе решения конкретных задач из базового программного обеспечения этих систем часто применяется не более 10-20% программного обеспечения, наиболее специфичного для каждого подразделения.

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

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

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

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

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

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

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

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

Для достижения поставленной задачи необходимо:

Разработать общую методику построения, автономного тестирования и развертывания на сервере веб-сервисов Java.

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

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

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

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

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

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

Основные результаты диссертационной работы сводятся к следующим:

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

2. Реализована общая методика построения восходящим методом веб-сервисов Java и соответствующих WSDL-документов, а также доставки их на сервер распределенной САПР после проведения автономного тестирования в среде разработки.

3. Разработана методика построения программного обеспечения веб-сервисов Java для решения типовых задач моделирования непрерывных систем при автоматизированном проектировании электронных схем.

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

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

6. Разработана методика построения распределенных САПР, обеспечивающая взаимодействие веб-сервисов Java и клиентских приложений произвольного типа в гетерогенных средах.

Заключение

При выполнении диссертационной работы были рассмотрены вопросы исследования и разработки методов построения платформенно-независимых распределенных САПР с сервис-ориентированной архитектурой и использованием веб-сервисов. Для конкретизации такой САПР была выбрана распределенная система для решения задач схемотехнического проектирования.

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

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

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

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

1. Автоматизация схемотехнического проектирования Текст.: монография / В.Н.Ильин [и др.]; под ред. В.Н.Ильина. М.: Радио и связь, 1987. - 368 с.

2. Автоматизация схемотехнического проектирования на мини-ЭВМ Текст.: учебное пособие / В.И.Анисимов [и др.]. JL: Изд-во Ленингр. ун-та, 1983. - 199 с.

3. Анисимов, В.И. Комплекс диалоговых пакетов моделирования аналоговых и цифровых электронных схем на IBM/PC Текст. / В.И.Анисимов, К.Б.Скобельцын, А.В.Никитин // Автоматизированное проектирование в радиоэлектронике и приборостроении: 1991.-С.3-6.

4. Анисимов, В.И. Чувствительность нелинейных систем к вариации параметров Текст. / В.И.Анисимов, Ю.М.Амахвр // Изв.СПБГЭТУ «ЛЭТИ». Сер. Информатика, управление и компьютерные технологии, -2007. Вып.2. - С. 22-26.

5. Анисимов, В.И. Моделирование непрерывных систем Текст.: учебное пособие / В.И.Анисимов. СПб.: ЛЭТИ, 2006. - 172 с.

6. Беллиньясо, М. Разработка Web-приложений в среде ASP.NET 2.0 Текст.: монография / М.Беллиньясо.; пер. с англ. под ред. Ю.Н. Артеменко. М.: ООО «И.Д.Вильямс», 2007. - 640 с.

7. Беллман, Р. Введение в теорию матриц Текст.: монография / Р.Беллман.; пер. с англ. под ред. В.Б. Лидского. М.: Наука, 1969. - 336 с.

8. Богданов, A.B. Сервис-ориентированная архитектура: новые возможности в свете развития GRID технологий / А.В.Богданов, Е.Н.Станкова, В.В.Мареев (http//www.ict.edu.ru/lib/index.php?idres=5639)

9. Влах, И. Машинные методы анализа и проектирования электронных схем Текст.: монография / И.Влах, К.Сингхал.; пер. с анг. М.: Радио и связь, 1988. - 560 с.

10. Гамма, Э. Приемы объектно-ориентированного проектирования Текст.: монография / Э.Гамма, Р.Хелм.; пер. с анг. СПб.: Питер, 2001.

11. И. Гербер, Ш. Полный справочник по С# Текст.: монография / Ш.Гербер.; пер. с анг. СПб.: Питер, 2006. - 740 с.

12. Глориозов, Е.Л. Введение в автоматизацию схемотехнического проектирования Текст.: монография / Е.Л.Глориозов, В.Г.Сорин, П.П.Сыпчук. М.: Советское радио, 1976. - 232 с.

13. Даконта, М. XML и Java 2. Библиотека программиста Текст.: монография / М.Даконта, А.Саганич.; пер. с анг. СПб.: 2001. - 384 с.

14. Дей, Н. Eclipse: Платформа Web-инструментов Текст.: монография / Н.Дей, Л.Мандел, А.Райман.; пер. с англ. М.:, 2008.- 688 с.

15. Дейтел, Х.М. Технология программирования на Java 2: Книга 1. Графика, JavaBeans, интерфейс пользователя Текст.: монография / Х.М.Дейтел, П.Д.Дейтел, С.И.Сантри.; М.: ООО «Бином-Пресс», 2003.-560 с.

16. Дейтел, Х.М. Технология программирования на Java 2: Книга 2. Распределенные приложения Текст.: монография / Х.М. Дейтел, П.Д.Дейтел, С.И.Сантри.; М.: ООО «Бином-Пресс», 2003.-464 с.

17. Дейтел, Х.М. Технология программирования на Java 2: Книга 3. Корпоративные системы, сервлеты, JSP, Web-сервисы Текст.: монография / Х.М.Дейтел, П.Д.Дейтел, С.И.Сантри.; пер. с анг. М.: ООО «Бином-Пресс», 2003.- 672 с.

18. Демидович, Б.П. Основы вычислительной математики Текст.: монография / Б.П.Демидович, И.А.Марон. М.: Физматгиз, 1963. - 658 с.

19. Джеймс, О. Итерационные методы решения нелинейных систем уравнений Текст.: монография / О.Джеймс, Р.Венер.; пер. с англ. под ред. Э.В. Вершкова, Н.П. Жидкова, И.В. Коновальцева. М.: Мир, 1975.- 551 с.

20. Джордж, А. Численное решение больших разреженных систем уравнений Текст.: монография / А.Джордж, Дж.Лю.; пер. с англ. Х.Д. Икрамова М.: Мир, 1984. - 333 с.

21. Диалоговые системы схемотехнического проектирования Текст.: монография / В.И.Анисимов [и др.]. М.: Радио и связь, 1988. - 287 с.

22. Дунаев С.Б. Java для Internet в Windows и Linux Текст.: монография / С.Б.Дунаев. М.: ДИАЛОГ-МИФИ, 2004. - 496 с.

23. Зеленухина, В.А. Разработка Интернет-ориентированных виртуальных лабораторий математического моделирования посредством разделения вычислительных и визуализационных задач Текст. / В.А.Зеленухина, //Информационные технологии, 2010. №10. - С.

24. Зыков, A.A. Основы теории графов Текст.: монография / А.А.Зыков. -М.: Наука, 1987.-256 с.

25. Ильин, В.Н. Основы автоматизации схемотехнического проектирования Текст.: монография / В.Н.Ильин. М.: Энергия, 1979. - 391 с.

26. Имитационное моделирование производственных систем Текст.: монография / А.А.Вавилов [и др.]. Киев: Техника, 1983. - 415 с.

27. Как программировать на XML Текст.: монография / Х.М.Дейтел, [и др.].; пер. с анг. М.: ЗАО «Издательство БИНОМ», 2001.- 944 с.

28. Калиткин, H.H. Численные методы Текст.: монография / Н.Н.Калиткин. -М.: Наука, 1978,- 519 с.

29. Кнут, Д. Искусство программирования для ЭВМ Текст.: монография / Д.Кнут.; пер. с англ. Г.П.Бавенко, Ю.М.Ваяковского.; под ред. К.И.Бабенко, В.С.Штаркмана. М.: Мир, 1976. - 734 с.

30. Кристофидес, Н. Теория графов. Алгоритмический подход Текст.: монография / Н.Кристофидес.; пер. с анг. под ред. Г.П.Гаврилова. М.: Мир, 1978.-432 с.

31. Мак-Дональд, М. Microsoft ASP.NET 2.0 с примерами на С# 2005 для профессионалов Текст.: монография / М. Мак-Дональд, М.Шпушта; пер. с анг. под ред. Ю.Н. Артеменко. М.: ООО «И.Д.Вильямс», 2006. - 1408 с.

32. Михайлов, В.Б. Численно-аналитические методы решения сверхжестких дифференциально-алгебраических систем уравнений Текст.: монография /В.Б.Михайлов. СПб.: Наука, 2005. - 223 с.

33. Норенков, И.П. Введение в автоматизированное проектирование технических устройств и систем Текст.: монография / И.П.Норенков. -М.: Высшая школа, 1986. 302 с.

34. Норенков, И.П. Основы теории и проектирования САПР Текст.: монография / И.П.Норенков, В.Б.Маничев. М.: 1990. -334 с.

35. Норенков, И.П. Системы автоматизированного проектирования электронной и вычислительной аппаратуры Текст.: монография / И.П.Норенков, В.Б.Маничев. -М.: Высшая школа, 1983. 272 с.

36. Ноутон, П. Java 2 Текст.: монография / П. Ноутон, Г.Шилдт. ; пер. с англ. СПб.: БХВ-Петербург, 2001. - 1072 с.

37. Петренко, А.И. Основы построения систем автоматизированного проектирования Текст.: монография / А.И.Петренко, О.И.Семенков. -Киев: Высшая школа, 1984. 293 с.

38. Петренко, А.И. Табличные методы моделирования электронных схем на ЭЦВМ Текст.: монография / А.И. Петренко, А.И.Власов, А.П.Тимченко. -Киев: Высшая школа, 1977. 186 с.

39. Писсанецки, С. Технология разреженных матриц Текст.: монография / С.Писсанецки.; пер. с анг. под ред. Х.Д.Икрамова. М.: Мир, 1988. - 410 с.

40. Разевиг, В. Схемотехническое моделирование с помощью Micro-Cap 7 Текст.: монография / В.Разевиг. М. : Телеком, 2003. - 368 с.

41. Разработка распределенных приложений на платформе Microsoft .Net Framework Текст.: монография / С.Морган [и др.].; пер. с англ. М.: «Русская Редакция», 2008. - 608 с.

42. Разработка клиентских веб-приложений на платформе Microsoft .Net Framework Текст.: монография / Гленн Д. [и др.].; пер. с англ. М.: «Русская Редакция», 2007. - 768 с.

43. Руководство разработчика Borland JBuilder Текст.: монография / М.Ленди [и др.].; пер. с англ. М.: Издательский дом «Вильяме», 2004. -864 с.

44. Райе, Дж. Матричные вычисления и математическое обеспечение Текст.: монография / Дж.Райс.; пер. с анг. М.: Мир, 1984. - 264 с.

45. С# для профессионалов Текст.: монография / Симон Робинсон [и др.].; пер. с англ. С.Коротыгин [и др.]. М.: Лори, 2005. - 1002 с.

46. Саймон, P. Microsoft Windows 2000 API. Энциклопедия программиста Текст.: монография / Р.Саймон.; СПб.: ДиаСофт, 2002.-1088 с.

47. Секреты программирования для Internet на Java Текст.: монография / М.Томас [и др.].; пер. с англ. СПб.: Питер, 1997. - 640 с.

48. Сешу, С. Линейные графы и электрические цепи Текст.: монография / С.Сешу, М.Б.Рид.; пер. с англ. М.: Высшая школа, 1971. - 448 с.

49. Сигорский, В.П. Алгоритмы анализа электронных схем Текст.: /

50. B.П.Сигорский, А.И.Петренко. М.: Советское радио, 1976. - 606 с.

51. Сигорский, В.П. Математический аппарат инженера Текст.: монография / В.П.Сигорский. Киев: Техника, 1975. - 765 с.

52. Слипченко, В.Г. Машинные алгоритмы и программы моделирования электронных схем Текст.: монография / В.Г.Слипченко, В.Г.Табарный -Киев: Техника, 1976. 157 с.

53. Советов, Б.Я. Моделирование систем Текст.: монография / Б.Я.Советов,

54. C.А.Яковлев. М.: Высшая школа, 1985. - 271 с.

55. Сольницев, Р.И. Автоматизация проектирования систем автоматического управления Текст.: монография / Р.И.Сольницев. М.: Высшая школа, 1991. - 328 с.

56. Сольницев, Р.И. Основы автоматизации проектирования гироскопических систем. Текст.: монография / Р.И. Сольницев. М.: Высшая школа, 1985. - 240 с.

57. Степаненко, И.П. Основы микроэлектроники: учеб. пособие для вузов Текст / И.П.Степаненко. М.: Советское радио, 1980. -567 с.

58. Тарасик, В.П. Математическое моделирование технических систем Текст.: монография / В.П. Тарасик. Минск: Дизайн ПРО, 2004. - 639 с.

59. Троелсен, Э. Язык программирования С# 2005 и платформа.NET 2.0 Текст.: монография / Э.Троелсен,; пер. с англ. под ред. А.Г.Спивака. М.: ООО «И.Д.Вильямс», 2007. - 1168 с.

60. Тьюарсон, Ф.Р. Разреженные матрицы Текст.: монография / Ф.Р.Тьюарсон.; пер. с анг. М.: Мир, 1977. - 189 с.

61. Фадеев, Д.К. Вычислительные методы линейной алгебры Текст.: монография / Д.К.Фадеев, В.Н. Фадеева. М.: Изд-во Физ-мат литературы, 1963. - 734 с.

62. Феррара, А. Программирование web-сервисов для.NET Текст.: монография / А.Феррара, М.Мак-Дональд. СПб.: Питер, 2003. - 422 с.

63. Форсайт, Дж. Машинные методы математических вычислений Текст.: монография / Дж.Форсайт, М.Малькольм, К.Моулер.; пер. с англ. под ред. Х.Д.Икрамова. М.: Мир, 1980. - 277 с.

64. Цимбал, A.A. Технология создания распределенных систем Текст.: монография / А.А.Цимбал, М.Л.Аншина. СПб.: Питер, 2003. - 576 с.

65. Чуа, Л.О. Машинный анализ электронных схем Текст.: монография / Л.О.Чуа, Лин.Пен-Мин.; пер. с анг. -М.: Энергия, 1980. 631с.

66. Хайнеман, P. PSPICE Моделирование работы электронных схем Текст.: монография / Р.Хайнеман. -М.: Издательство ДМК, 2005. 327с.

67. Хабибулин, И. Разработка Web-служб средствами Java Текст.: монография / И. Хабибулин. СПб.: БХВ-Петербург, 2003. - 400 с.

68. Холл, М. Сервлеты и JavaServer Pages Текст.: монография / М.Холл.; пер. с анг. -СПб.: Питер, 2001. 496 с.

69. Эстербю, О. Прямые методы для разреженных матриц Текст.: монография / О.Эстербю, З.Златев.; пер. с анг. М.: Мир, 1987. - 111 с.

70. Янг, М.Д. Microsoft XML. Шаг за шагом Текст.: монография / М.Д.Янг.; пер. с англ. -М.: Издательство ЭКОМ, 2002. 384с.69. http://bigor.bmstu.ru/?doc=080IS/ai006.mod/?cou-140CADedu/CAD.cou

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

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 -сервисов, является протокол

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

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

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