Web-сервисы release

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

и между собой
Взаимодействие сервисов определяется контрактами
Сервисы изолируют внутреннюю логику от окружающего мира
Сервисы допускают возможность композиции
Сервисы могут использоваться многократно
Сервисы являются самоуправляемыми
Сервисы не имеют собственного состояния
Сервисы должны быть обнаруживаемыми
WS-I Basic Profile 1.0

Object Request Broker Architecture (CORBA)

за рабочее место, к чему во многих случаях добавлялась плата

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

которые могут быть вызваны удаленно по сети посредством стандартизированных XML

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

бизнес-партнеров и клиентов при меньшей стоимости нежели с использованием иных

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

бизнес- и IT-политик взаимодействующих посредством веб-сервисов компаний находятся пока на

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

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

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

Simple Object Access Protocol (SOAP);
— протокол обмена структурированными сообщениями в распределённой вычислительной среде.

Universal Description, Discovery and Integration (UDDI);
— инструмент для расположения описаний веб-сервисов (WSDL) для последующего их поиска другими организациями и интеграции в свои системы.

Web Services Description Language (WSDL).
— язык описания веб-сервисов, основанный на языке XML.

вызов необходимого сервиса из реестра сервисов по описанию сервиса, а

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

Каждый компонент может играть либо лишь одну роль (быть, например, только пользователем сервиса) либо одновременно сразу несколько ролей (например, быть провайдером одних сервисов и пользователем других).

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

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

удовлетворять следующим критериям:

Сервисы слабо связаны с бизнесом и между собой
Взаимодействие

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

мера связанности отражает зависимость в отношениях между предметом автоматизации и

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

природы, могут быть узаконенная (допустимая) или техническая совокупность правил. Это

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

за исключением контрактной, скрыта от окружения; этим, собственно, и обеспечивается

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

замкнутость — образуют триаду, на основе которой строится взаимодействие между

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

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

виде сервиса следующего уровня, предназначенного для решения определенной задачи.

использован вызывающими его сервисами, то есть он может использоваться многократно,

как любая функция или подпрограмма

от друга и от среды обитания, они должны быть автономными,

то есть обладать свойствами самоуправления. Под «автономностью» понимается способность сервиса выполнить условия контракта самостоятельно, без внешнего управления. Абсолютная автономия предполагает полное распоряжение ресурсами; она не всегда возможна, особенно если приходится создавать сервисы, взаимодействующие с унаследованными приложениями. Полная автономность является условием для многократного использования, но это не единственное условие; не меньшее значение имеет отсутствие собственного состояния.

форме сохраняет информацию о своем состоянии, то оказывается привязанным к

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

перегружено реестрами сервисов, механизмами их обнаружения. Для этой цели должна

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

спецификации технологий:
SOAP 1.1;
WSDL 1.1;
UDDI 2.0;
XML 1.0;
XML

Schema Part 1: Structures;
XML Schema Part 2: Datatypes;
RFC2246: The Transport Layer Security Protocol 1.0;
RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile;
RFC2616: HyperText Transfer Protocol 1.1;
RFC2818: HTTP over TLS;
RFC2965: HTTP State Management Mechanism;
Secure Sockets Layer Protocol 3.0.