Web технологии и языки веб-разработки Технология «КЛИЕНТ - СЕРВЕР» Протокол HTTP Cookie Плагины, сценарии, приложения Веб – сервисы. - презентация

1 Web технологии и языки веб-разработки Технология «КЛИЕНТ - СЕРВЕР» Протокол HTTP Cookie Плагины, сценарии, приложения Веб – сервисы

2 Клиент-серверные технологии ВЕБ Базовым протоколом сети гипертекстовых ресурсов ВЕБ является протокол HTTP. В его основу положено взаимодействие «КЛИЕНТ-СЕРВЕР», то есть предполагается, что: 1. Потребитель - КЛИЕНТ инициировав соединение с поставщиком-сервером посылает ему запрос; 2. Поставщик - СЕРВЕР, получив запрос, производит необходимые действия и возвращает обратно клиенту ответ с результатом.

3 ПРИ ЭТОМ ВОЗМОЖНЫ ДВА СПОСОБА организации работы компьютера-клиента: Тонкий клиент - это компьютер-клиент, который переносит все задачи по обработке информации на сервер. Примером тонкого клиента может служить компьютер с браузером, использующийся для работы с веб- приложениями. Толстый клиент, напротив, производит обработку информации независимо от сервера, использует последний в основном лишь для хранения данных.

4 Протокол HTTP HTTP HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) - протокол прикладного уровня для передачи гипертекста. Всё программное обеспечение для работы с протоколом HTTP разделяется НА ТРИ ОСНОВНЫЕ КАТЕГОРИИ: Серверы Серверы - поставщики услуг хранения и обработки информации (обработка запросов). Клиенты Клиенты - конечные потребители услуг сервера (отправка запросов). Прокси-серверы Прокси-серверы для поддержки работы транспортных служб.

5 Протокол HTTP «Классическая» схема HTTP-сеанса выглядит так: 1. Установление TCP-соединения. 2. Запрос клиента. 3. Ответ сервера. 4. Разрыв TCP-соединения. Клиент посылает серверу запрос, получает от него ответ, после чего взаимодействие прекращается. Обычно запрос клиента представляет собой требование передать HTML-документ или какой-нибудь другой ресурс, а ответ сервера содержит код этого ресурса.

6 Протокол HTTP В состав HTTP-запроса входят следующие компоненты: Строка состояния Поля заголовка. Пустая строка. Тело запроса. Строку состояния вместе с полями заголовка иногда называют также ЗАГОЛОВКОМ ЗАПРОСА.

7 Протокол HTTP Структура запроса клиента

8 Протокол HTTP Строка состояния имеет следующий формат: метод_запроса URL_pecypca версия_протокола_НТТР Метод, указанный в строке состояния, определяет способ воздействия на ресурс, URL которого задан в той же строке. Метод может принимать значения: GET, POST, HEAD, PUT, DELETE и т.д. для веб-программиста по-настоящему важны лишь два из них: GET и POST.

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

10 Протокол HTTP POST - основное назначение метода - передача данных на сервер. Однако, подобно методу GET, метод POST может применяться по-разному и нередко используется для получения информации с сервера. Как и в случае с методом GET, URL, заданный в строке состояния, указывает на конкретный ресурс. Метод POST также может использоваться для запуска процесса.

11 Протокол H T T P Версия протокола HTTP, как правило, задается в следующем формате: HTTP/версия.модификация Поля заголовка, следующие за строкой состояния, позволяют уточнять запрос, Поле заголовка имеет следующий формат: Имя_поля : Значение Назначение поля определяется его именем, которое отделяется от значения двоеточием

12 Протокол H T T P Во многих случаях при работе в Веб тело запроса отсутствует. При запуске CGI-сценариев данные, передаваемые для них в запросе, могут размещаться в теле запроса.

13 Протокол H T T P Получив от клиента запрос, сервер должен ответить ему. Знание структуры ответа сервера необходимо разработчику веб-приложений, так как программы, которые выполняются на сервере, должны самостоятельно формировать ответ клиенту.

14 Протокол H T T P Имена некоторых наиболее часто встречающихся в запросе клиента полей заголовка и их назначение приведены в таблице:

15 Протокол H T T P Подобно запросу клиента, ответ сервера также состоит из четырех перечисленных ниже компонентов: Строка состояния Поля заголовка Пустая строка Тело ответа

16 Протокол H T T P Ответ сервера клиенту начинается со строки состояния, которая имеет следующий формат: Версия_протокола Код_ответа Пояснительное_сообщение Версия_протокола - задается в том же формате, что и в запросе клиента, и имеет тот же смысл. Код_ответа - это трехзначное десятичное число, представляющее в закодированном виде результат обслуживания запроса сервером. Пояснительное_сообщение - дублирует код ответа в символьном виде. Это строка символов, которая НЕ обрабатывается клиентом. Она предназначена для системного администратора или оператора, занимающегося обслуживанием системы, и является расшифровкой кода ответа.

17 Протокол H T T P Из трех цифр, составляющих код ответа, первая (старшая) определяет класс ответа, остальные две представляют собой номер ответа внутри класса. Например: если запрос был обработан успешно, клиент получает следующее сообщение: HТТР/ ОК HTTP версия протокола, а код. В этом коде символ 2 означает успешную обработку запроса клиента, а остальные две цифры (00) - номер данного сообщения

18 Протокол H T T P В используемых в настоящее время реализациях протокола HTTP первая цифра не может быть больше 5 и определяет следующие классы ответов: 1 - специальный класс сообщений, называемых информационными. Код ответа, начинающийся с 1, означает, что сервер продолжает обработку запроса. При обмене данными между HTTP- клиентом и HTTP-сервером сообщения этого класса используются достаточно редко. 2 - успешная обработка запроса клиента. 3 - перенаправление запроса. Чтобы запрос был обслужен, необходимо предпринять дополнительные действия. 4 - ошибка клиента. Как правило, код ответа, начинающийся с цифры 4, возвращается в том случае, если в запросе клиента встретилась синтаксическая ошибка. 5 - ошибка сервера. По тем или иным причинам сервер не в состоянии выполнить запрос.

19 Протокол H T T P Примеры кодов ответов, которые клиент может получить от сервера, и поясняющие сообщения приведены в таблице:

20 Протокол H T T P В теле ответа содержится код ресурса, передаваемого клиенту в ответ на запрос. Это не обязательно должен быть HTML-текст веб-страницы. В составе ответа могут передаваться изображение, аудио-файл, фрагмент видеоинформации, а также любой другой тип данных, поддерживаемых клиентом. О том, как следует обрабатывать полученный ресурс, клиенту сообщает содержимое поля заголовка Content-type.

21 Протокол H T T P Ниже представлен пример ответа сервера на запрос В теле ответа содержится исходный текст HTML-документа. Поля заголовка и тело сообщения могут отсутствовать, но строка состояния является обязательным элементом, так как указывает на тип запроса/ответа.

22 Протокол H T T P Поле с именем Content-type может встречаться как в запросе клиента, так и в ответе сервера. В качестве значения этого поля указывается MIME-тип содержимого запроса или ответа. MIME-тип также передается в поле заголовка Accept, присутствующего в запросе.

23 Протокол H T T P Спецификация MIME (Multipurpose Internet Mail Extension - многоцелевое почтовое расширение Internet) первоначально была разработана для того, чтобы обеспечить передачу различных форматов данных в составе электронных писем. Однако применение MIME не исчерпывается электронной почтой. Средства MIME успешно используются в WWW и, по сути, стали неотъемлемой частью этой системы.

24 Протокол H T T P Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA ( Internet Assigned Numbers Authority ).

25 Протокол H T T P До появления MIME компьютеры, взаимодействующие по протоколу HTTP, обменивались исключительно текстовой информацией. Для передачи изображений, как и для передачи любых других двоичных файлов, приходилось пользоваться протоколом FTP.

26 Протокол H T T P В соответствии со спецификацией MIME, для описания формата данных используются тип и подтип. Тип определяет, к какому классу относится формат содержимого HTTP-запроса или HTTP-ответа. Подтип уточняет формат. Тип и подтип отделяются друг от друга косой чертой: тип/подтип

27 Протокол H T T P Т.к. в большинстве случаев в ответ на запрос клиента сервер возвращает исходный текст HTML-документа, то в поле Content-type ответа обычно содержится значение text/html. идентификатор text описывает тип, сообщая, что клиенту передается символьная информация, а идентификатор html описывает подтип, т.е. указывает на то, что последовательность символов, содержащаяся в теле ответа, представляет собой описание документа на языке HTML.

28 Протокол H T T P В таблице приведены примеры MIME-типов, наиболее часто встречающиеся в заголовках HTML-запросов и ответов:

29 Протокол H T T P Для однозначной идентификации ресурсов в сети Веб используются уникальные идентификаторы URL. Единообразный идентификатор ресурса URI ( Uniform Resource Identifier ) - короткая последовательность символов, идентифицирующую абстрактный или физический ресурс. URI не указывает на то, как получить ресурс, а только идентифицирует его. Это даёт возможность описывать с помощью RDF (Resource Description Framework) ресурсы, которые не могут быть получены через Интернет (имена, названия и т.п.).

30 Протокол H T T P Самые известные примеры URI - это URL и URN. URL (Uniform Resource Locator) - это URI, который, помимо идентификации ресурса, предоставляет ещё и информацию о местонахождении этого ресурса. URN (Uniform Resource Name) - это URI, который идентифицирует ресурс в определённом пространстве имён, но, в отличие от URL, URN не указывает на местонахождение этого ресурса.

31 Протокол H T T P URL имеет следующую структуру: :// : / где: схема - схема обращения к ресурсу (обычно сетевой протокол); логин - имя пользователя, используемое для доступа к ресурсу; пароль - пароль, ассоциированный с указанным именем пользователя; хост - полностью прописанное доменное имя хоста в системе DNS или IP - адрес хоста; порт - порт хоста для подключения; URL - путь - уточняющая информация о месте нахождения ресурса.

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

33 Обеспечение безопасности передачи данных HTTP Самым простейшим является расширение HTTPS, при котором данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический SSLTLS протокол SSL или TLS, обеспечивая защиту этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Чтобы подготовить веб-сервер для обработки HTTPS соединений, администратор должен получить и установить в систему сертификат для этого веб-сервера.

34 Обеспечение безопасности передачи данных HTTP SSL (Secure Sockets Layer) – криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший название TLS. Этот протокол использует шифрование с открытым ключом для подтверждения подлинности передатчика и получателя.

35 Обеспечение безопасности передачи данных HTTP Для доступа к веб-страницам, защищённым протоколом SSL, в URL вместо схемы http, как правило, подставляется схема https, указывающая на то, что будет использоваться SSL-соединение. Стандартный TCP-порт для соединения по протоколу https Для работы SSL требуется, чтобы на сервере имелся SSL-сертификат.

36 Обеспечение безопасности передачи данных HTTP В сети Веб поддерживаются 3 типа аутентификации при клиент-серверных взаимодействиях: Basic - базовая аутентификация, при которой имя пользователя и пароль передаются в заголовках http-пакетов. Пароль при этом не шифруется и присутствует в чистом виде в кодировке base64. Для данного типа аутентификации использование SSL является обязательным. Digest - дайджест-аутентификация, при которой пароль пользователя передается в хешированном виде. По уровню конфиденциальности паролей этот тип мало чем отличается от предыдущего, так как атакующему все равно, действительно ли это настоящий пароль или только хеш от него: перехватив удостоверение, он все равно получает доступ к конечной точке. Для данного типа аутентификации использование SSL является обязательным. Integrated - интегрированная аутентификация, при которой клиент и сервер обмениваются сообщениями для выяснения подлинности друг друга с помощью протоколов NTLM или Kerberos. Этот тип аутентификации защищен от перехвата удостоверений пользователей =>для него не требуется протокол SSL. При использовании данного типа аутентификации можно работать по схеме http, во всех остальных случаях необходимо использовать схему https.

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

38 Cookie Если сервер будет проверять TCP-соединения и запоминать IP- адреса компьютеров-клиентов, он не сможет различить запросы от двух браузеров, выполняющихся на одной машине. Если допустить, что на компьютере работает лишь одна клиент-программа, то никто не может утверждать, что в промежутке между двумя запросами она не была завершена, а затем запущена снова уже другим пользователем

39 Cookie Если вы когда-нибудь пользовались почтовым ящиком на mail.ru или на другом сервере, предоставляющем почтовые услуги пользователям Веб, вспомните, как вел себя клиент после того, как вы создали для себя почтовый ящик на сервере.mail.ru Когда вы в следующий раз обратились с того же компьютера к mail.ru, вы, вероятно, заметили, что после загрузки веб - страницы ваше регистрационное имя уже отображалось в соответствующем поле ввода.mail.ru Такие сведения позволяет получить дополнительное средство под названием COOKIE. Механизм COOKIE позволяет серверу хранить информацию на компьютере клиента и извлекать ее оттуда.

40 Cookie Инициатором записи COOKIE выступает сервер. Если в ответе сервера присутствует поле заголовка Set-cookie, клиент воспринимает это как команду на запись cookie. В дальнейшем, если клиент обращается к серверу, от которого он ранее принял поле заголовка Set-cookie, помимо прочей информации он передает серверу данные cookie. Для передачи указанной информации серверу используется поле заголовка Cookie.

41 Сервер А Сервер В Сервер С КЛИЕНТ запрос ответ клиент записывает cookie на диск ответ 1-й сеанс2-й сеанс запрос ответ запрос включает в заголовок запроса поле Cookie ответ запрос ответ ТАКИМ ОБРАЗОМ, процедуру записи и получения cookie можно представить себе как своеобразный «ЗАПРОС» сервера, инкапсулированный в его ответе клиенту. Соответственно получение cookie также можно представить себе как ответ клиента, инкапсулированный в составе запроса к тому же серверу

42 Какие данные передаются в поле заголовка Set-cookie и как они влияют на поведение клиента? Поле Set-cookie имеет следующий формат: Set-cookie: имя = значение; expires = дата; path = путь; домен = имя_домена, secure Пара имя = значение - именованные данные, сохраняемые с помощью механизм cookie. Эти данные должны храниться на клиент-машине и передаваться серверу в составе очередного запроса клиента.

43 Какие данные передаются в поле заголовка Set-cookie и как они влияют на поведение клиента? Поле Set-cookie имеет следующий формат: Set-cookie: имя = значение; expires = дата; path = путь; домен = имя_домена, secure Дата, являющаяся значением параметра expires, определяет время, по истечении которого информация cookie теряет свою актуальность. Если ключевое слово expires отсутствует, данные cookie удаляются по окончании текущего сеанса работы браузера.

44 Какие данные передаются в поле заголовка Set-cookie и как они влияют на поведение клиента? Поле Set-cookie имеет следующий формат: Set-cookie: имя = значение; expires = дата; path = путь; домен = имя_домена, secure domain - определяет домен, с которым связываются данные cookie. Чтобы узнать, следует ли передавать в составе запроса данные cookie, браузер сравнивает доменное имя сервера, к которому он собирается обратиться, с доменами, которые связаны с записями cookie, хранящимися на клиент-машине. Результат проверки будет считаться положительным, если сервер, которому направляется запрос, принадлежит домену, связанному с cookie. Если соответствия нет, данные cookie не передаются.

45 Какие данные передаются в поле заголовка Set-cookie и как они влияют на поведение клиента? Поле Set-cookie имеет следующий формат: Set-cookie: имя = значение; expires = дата; path = путь; домен = имя_домена, secure Путь, указанный в качестве значения параметра path, позволяет выполнить дальнейшую проверку и принять окончательное решение о том, следует ли передавать данные cookie в составе запроса. Помимо домена с записью cookie связывается путь. Если браузер обнаружил соответствие имени домена значению параметра domain, он проверяет, соответствует ли путь к ресурсу пути, связанному с cookie сервером клиенту. Сравнение считается успешным, если ресурс содержится в каталоге, указанном посредством ключевого слова path, или в одном из его подкаталогов. Если и эта проверка дает положительный результат, данные cookie передаются серверу. Если параметр path в поле Set-Cookie отсутствует, то считается, что запись cookie связана с URL конкретного ресурса, передаваемого сервером клиенту.

46 Какие данные передаются в поле заголовка Set-cookie и как они влияют на поведение клиента? Поле Set-cookie имеет следующий формат: Set-cookie: имя = значение; expires = дата; path = путь; домен = имя_домена, secure secure, указывает на то, что данные cookie должны передаваться по защищенному каналу.

47 Для передачи данных cookie серверу используется поле заголовка Cookie. Формат этого поля достаточно простой: Cookie: имя=значение; имя=значение;... C помощью поля Cookie передается одна или несколько пар имя = значение. Каждая из этих пар принадлежит записи cookie, для которой URL запрашиваемого ресурса соответствуют имени домена и пути, указанным ранее в поле Set-cookie.

48 Клиентские СЦЕНАРИИ И ПРИЛОЖЕНИЯ ВЕБ-ПРИЛОЖЕНИЕ - приложение, в котором : клиентом выступает браузер, сервером - веб-сервер. Рассмотрим типы программ, обеспечивающих работу Веб и использующих HTTP-протокол. Никакой HTTP-обмен невозможен без клиента и сервера.

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

50 Программы, выполняющиеся на КЛИЕНТ-МАШИНЕ Одним из типов программ, предназначенных для выполнения на клиент- машине, являются сценарии, например, JavaScript (VBScript). Исходный текст сценария представляет собой часть веб-страницы, поэтому сценарий JavaScript передается клиенту вместе с документом, в состав которого он входит. Обрабатывая HTML-документ, браузер обнаруживает исходный текст сценария и запускает его на выполнение.

51 Программы, выполняющиеся на Программы, выполняющиеся на КЛИЕНТ-МАШИНЕ Ко всем программам, которые передаются с сервера на клиент - машины и запускаются на выполнение, предъявляется одно общее требование: эти программы должны быть лишены возможности обращаться к ресурсам компьютера, на котором они выполняются.

52 Программы, выполняющиеся на Программы, выполняющиеся на КЛИЕНТ-МАШИНЕ Такое требование вполне обосновано : передача по сети и запуск Java-апплетов и JavaScript-сценариев происходит автоматически без участия пользователя, поэтому работа этих программ должна быть абсолютно безопасной для компьютера. Другими словами, языки, предназначенные для создания программ, выполняющихся на клиент - машине, должны быть абсолютно непригодны для написания вирусов и подобных программ.

53 Программы, выполняющиеся на СЕРВЕРЕ Код программы, работающей на сервере, не передается клиенту. При получении от клиента специального запроса, предполагающего выполнение такой программы, сервер запускает ее и передает параметры, входящие в состав запроса. Средства для генерации подобного запроса обычно входят в состав HTML-документа

54 Результаты своей работы программа оформляет в виде HTML-документа и передает их веб-серверу, а последний, в свою очередь, дополняет полученные данные HTTP- заголовком и передает их клиенту. Взаимодействие клиента с программой, выполняющейся на сервере.

55 Насыщенные ИНТЕРНЕТ-ПРИЛОЖЕНИЯ Насыщенное интернет-приложение (Rich Internet application) – еще один подход, который заключается в использовании программных модулей, например Adobe Flash или JAVA-АППЛЕТОВ, для полной или частичной реализации пользовательского интерфейса, поскольку большинство браузеров поддерживает эти технологии (как правило, с помощью плагинов).

56 Насыщенные ИНТЕРНЕТ-ПРИЛОЖЕНИЯ Возникновение данного подхода обусловлено тем, что в рамках веб - приложений с «тонким» клиентом взаимодействие пользователя с приложением реализуется в существенной степени через сервер, что требует отправки данных на сервер, получение ответа от сервера и перезагрузку страницы на стороне клиента.

57 Насыщенные ИНТЕРНЕТ-ПРИЛОЖЕНИЯ При использовании Java-апплетов в состав HTML-документа включается специальный дескриптор, описывающий расположение файла, содержащего код апплета, на сервере. После того как клиент получает HTML-код документа, включающего апплет, он генерирует дополнительный запрос серверу. После того как сервер пересылает клиенту код апплета, сам апплет запускается на выполнение.

58 Насыщенные ИНТЕРНЕТ-ПРИЛОЖЕНИЯ Передача клиенту Java-апплета.

59 НАСЫЩЕННЫЕ ИНТЕРНЕТ-ПРИЛОЖЕНИЯ При использовании насыщенных интернет- приложений приходится сталкиваться со следующими проблемами: необходимость обеспечения безопасной среды выполнения («песочница»); для исполнения кода должно быть разрешено исполнение сценариев; потеря в производительности (т.к. выполняется на клиентской стороне); требуется много времени на загрузку; Для разработки насыщенных интернет- приложений используются пакеты Curl, Macromedia Flash, Adobe Flex, Microsoft Silverlight и др.

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

61 Серверные веб - приложения Плагин (plug-in) - независимо компилируемый программный модуль, динамически подключаемый к основной программе, предназначенный для расширения или использования ее возможностей. Обычно выполняются в виде разделяемых библиотек. Сценарий (скрипт, script) - программа, которая автоматизирует некоторую задачу, которую пользователь выполняет вручную используя интерфейсы программы.

62 Веб - сервисы Веб-сервис (web service) - программная система, имеющая идентификатор URI, и общедоступные интерфейсы которой определены на языке XML. Описание этой программной системы может быть найдено другими приложениями, которые могут взаимодействовать с ней в соответствии с этим описанием посредством сообщений, основанных на XML, и передаваемых с помощью интернет-протоколов. Веб-сервис является единицей модульности при использовании сервис- ориентированной архитектуры приложения.

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

64 Веб - сервисы Интерфейс компонентов SОА-программы осуществляет инкапсуляцию деталей реализации конкретного компонента (ОС, языка программирования и т. п). SOA хорошо зарекомендовала себя при построении крупных корпоративных программных систем. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы Microsoft.NET, IBM WebSphere, SAP NetWeaver, Diasoft и др.).

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

66 Веб - сервисы Веб-сервисы.NET имеют следующие достоинства: Межплатформенность. Язык программирования, который позволяет создавать XML-документы и отправлять информацию посредством HTTP, позволяет взаимодействовать с любым веб-сервисом. Можно получать веб-услугу из системы, отличной от.NET.

67 Веб - сервисы Веб-сервисы.NET имеют следующие достоинства: Простота. Поддержка сообщений на понятном человеку языке. Переход от двоичных стандартов, применяемых в СОМ и CORBA, к XML-тексту позволил упростить исправление ошибок и обеспечил возможность осуществлять взаимодействие с веб-сервисами по обычным каналам HTTP.

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

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

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

71 Облачные вычисления При этом пользователю такой системы предоставляются услуги, которые можно разделить на следующие виды: IaaS (Infrastructure-as-a-Service) - инфраструктура как сервис. PaaS (Platform-as-a-Service) - платформа как сервис. SaaS (Software-as-a-Service) - программное обеспечение как сервис.

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

73 Термин получил распространение после конференции по Web 2.0 Медиа в 2004 году с подачи Тима О'Рейли для выражения нового способа взаимодействия разработчиков ПО и конечных пользователей через Веб. Ключевой принцип идеологии Web 2.0 был сформулирован как: «Интернет - как платформа».

74 Правомерность термина оспаривают многие эксперты, в том числе Тим Бернерс-Ли, поскольку многие компоненты технологий Web2.0 существовали еще с первых лет существования сети Веб. Web 2.0 можно рассматривать и как подход к построению систем, при котором они становятся тем лучше, чем больше людей ими пользуются в процессе сетевых взаимодействий.

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

76 Еще одна важная концепция Web 2.0 – «Архитектура участия», которая поощряет пользователей повышать ценность ПО, путем его использования.

77 В качестве ключевых для Web 2.0 рассматриваются следующие технологии: Веб-сервисы - это программы, доступ к которым осуществляется через протокол HTTP, а обмен данными происходит в формате XML (или производном от него). Веб-сервис реализуется на серверах компании, её создавшей. В любой момент пользователю доступны самые свежие данные; Веб-сервисы являются платформо-независимыми, поскольку инструменты для работы с HTTP и XML есть в любом современном языке программирования.

78 В качестве ключевых для Web 2.0 рассматриваются следующие технологии: AJAX. Использование Ajax стало наиболее популярно после того как Google начала активно использовать его при создании своих сайтов, таких как Gmail и Google Maps.GoogleGmailGoogle Maps

79 В качестве ключевых для Web 2.0 рассматриваются следующие технологии: Веб-синдикация (на основе технологий RSS или Atom) - одновременное распространение информации в том числе аудио- и видео- на различные страницы или веб-сайты.

80 В качестве ключевых для Web 2.0 рассматриваются следующие технологии: Веб mash-up - сервис, который полностью или частично использует в качестве источников информации другие сервисы, предоставляя пользователю новую функциональность для работы. Веб mash-up сервис может становиться также новым источником информации для других веб mash-up сервисов. Т.о., образуется сеть зависимых друг от друга сервисов, интегрированных друг с другом.

81 В качестве ключевых для Web 2.0 рассматриваются следующие технологии: Теги - ключевые слова, описывающие рассматриваемый объект, либо относящие его к какой-либо категории. Теги можно рассматривать как метки, которые присваиваются объекту, для определения его места среди других объектов.

82 В качестве ключевых для Web 2.0 рассматриваются следующие технологии: Фолксономия - популярная классификация, практика совместной категоризации информации (ссылок, фото, видео клипов и др.) посредством произвольно выбираемых меток (тегов). Примеры использования фолксономии: Flickr, del.icio.us.Flickrdel.icio.us

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

84 К недостаткам Web 2.0 можно отнести следующие: 1.Зависимость от наличия постоянного соединения; 2.Зависимость работоспособности сайтов от решений сторонних компаний; 3.Зависимость качества работы сервиса от качества работы многих других компаний; 4.Недостаточные возможности существующей веб-инфраструктуры для выполнения сложных вычислительных задач в браузере; 5.Уязвимость конфиденциальных данных, хранимых на сторонних серверах, при несанкционированном доступе.

85 1.Написать доклад на тему: « КОНЕЦ ЦИВИЛИЗАЦИИ И WEB-ТЕХНОЛОГИИ » 2.Письменно ответить на контрольные вопросы

86 Контрольные вопросы: 1.Что такое HTTP-протокол? 2.Что такое толстый клиент и тонкий клиент? 3.Какую структуру имеет запрос клиента? 4.В какой части запроса клиента находится URL запрашиваемого ресурса? 5.Какую роль выполняют поля заголовка запроса клиента? 6.Какую структуру имеет ответ сервера? 7.Назначение URL, URN, URI? 8.Чем https отличается от http? 9.Какие типы аутентификации поддерживаются в Веб? 10.Что такое Cookie и для чего они предназначены?

87 Объем – 2 – 3 страницы формата А4 +1 титульная страница И + 1 страница со списком литературы Содержание доклада : доказать либо гибель либо расцвет цивилизации Размер шрифта – 12 пт., межстрочный интервал – 1,5 Требования к докладу: УДАЧИ!!!

88