Web-сервисы release

Скачать презентацию на тему: "Web-сервисы release" с количеством слайдов в размере 25 страниц. У нас вы найдете презентацию на любую тему и для каждого класса школьной программы. Мы уверены, что наши слайды помогут найти вам свою аудиторию. Весь материал предоставлен бесплатно, в знак благодарности мы просим Вас поделиться ссылками в социальных сетях и по возможности добавьте наш сайт MirPpt.ru в закладки.

Нажмите для просмотра
Web-сервисы release

1:

2: Оглавление Предшествующие технологии Определение веб-сервиса Плюсы веб-сервисов Минусы веб-сервисов Стек технологий веб-сервисов Технологии, обеспечивающие функциональность. Основные технологии web-сервисов Взаимодействие между компонентами сервисно-ориентированной архитектуры Свойства веб-сервисов Сервисы слабо связаны с бизнесом и между собой Взаимодействие сервисов определяется контрактами Сервисы изолируют внутреннюю логику от окружающего мира Сервисы допускают возможность композиции Сервисы могут использоваться многократно Сервисы являются самоуправляемыми Сервисы не имеют собственного состояния Сервисы должны быть обнаруживаемыми WS-I Basic Profile 1. 0

3: Предшествующие технологии Remote Procedure Calls (RPC) Distributed COM (DCOM) Remote Method Invocation (RMI) Common Object Request Broker Architecture (CORBA)

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

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

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

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

8: Стек технологий веб-сервисов

9: Технологии, обеспечивающие функциональность.

10: Технологии, обеспечивающие качество сервиса.

11: Основные технологии web-сервисов eXtensible Markup Language (XML); — рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML предназначен для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями. Simple Object Access Protocol (SOAP); — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Universal Description, Discovery and Integration (UDDI); — инструмент для расположения описаний веб-сервисов (WSDL) для последующего их поиска другими организациями и интеграции в свои системы. Web Services Description Language (WSDL). — язык описания веб-сервисов, основанный на языке XML.

12: Взаимодействие между компонентами сервисно-ориентированной архитектуры

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

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

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

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

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

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

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

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

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

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

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

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

25: WS-I Basic Profile 1. 0 В настоящее время в профиль входят следующие спецификации технологий: 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.

Скачать презентацию


MirPpt.ru