Лекция Протоколы прикладного уровня
Почему существуют два транспортных протокола TCP и UDP, а не один из них? Дело в том, что они предоставляют разные услуги прикладным процессам. Большинство прикладных программ пользуются только одним из них. Вы, как программист, выбираете тот протокол, который наилучшим образом соответствует вашим потребностям. Если вам нужна надежная доставка, то лучшим может быть TCP. Если вам нужна доставка датаграмм, то лучше может быть UDP. Если вам нужна эффективная доставка по длинному и ненадежному каналу передачи данных, то лучше может подойти протокол TCP. Если нужна эффективность на быстрых сетях с короткими соединениями, то лучшим может быть протокол UDP. Если ваши потребности не попадают ни в одну из этих категорий, то выбор транспортного протокола не ясен. Однако прикладные программы могут устранять недостатки выбранного протокола. Например, если вы выбрали UDP, а вам необходима надежность, то прикладная программа должна обеспечить надежность. Если вы выбрали TCP, а вам нужно передавать записи, то прикладная программа должна вставлять маркеры в поток байтов так, чтобы можно было различить записи.
Какие же прикладные программы доступны в сетях с TCP/IP? Общее их количество велико и продолжает постоянно увеличиваться. Некоторые приложения существуют с самого начала развития internet. Например, TELNET и FTP. Другие появились недавно: X-Window, SNMP. Протоколы прикладного уровня ориентированы на конкретные прикладные задачи. Они определяют как процедуры по организации взаимодействия определенного типа между прикладными процессами, так и форму представления информации при таком взаимодействии.
Не следует считать, что существующие протоколы исчерпывают все возможности сетевого обмена данными. Любой (подготовленный) разработчик ПО может предложить собственный (позволяющий успешно выполнять некоторые специфические действия) протокол; в случае действительного востребования этой разработки она будет признана стандартом (и включена в список документов RFC).
Протокол TELNET
Telnet обеспечивает взаимодействие с удаленным компьютером. Установив такую связь через Telnet, пользователь получает возможность работать с удаленным компьютером, как со "своим", т.е. теоретически получить в свое распоряжение все ресурсы, если к ним разрешен доступ. Реально Telnet предоставляет открытый доступ, но организация взаимодействия полностью определяется удаленным компьютером. Два вида услуг Internet требуют подключения к серверам через Telnet: библиотечные каталоги и электронные доски объявлений (BBS).
Программа Telnet в использовании очень проста. Для установки с ее помощью связи с каким-либо компьютером, подключенным к сети, необходимо знать его полный адрес в Internet, При установлении соединения с нужным компьютером следует указать в команде его адрес, В процессе соединения хост-компьютер запрашивает имя пользователя. Для работы в удаленной системе пользователь должен иметь там права доступа. После успешного подключения к хост-компьютеру пользователь должен указать тип используемого терминала. Для удобства работы пользователя хост-компьютер обычно указывает ему способ вызова справочной информации.
Работа с удаленной системой может вестись в "прозрачном" режиме, когда программы на сервере и у клиента только обеспечивают протокол соединения, и в командном, когда клиент получает в свое распоряжение набор команд сервера.
Следует заметить, что из соображений безопасности намечается тенденция сокращения числа узлов Internet, позволяющих использовать Telnet для подключения к ним.
Протокол TELNET позволяет обслуживающей машине рассматривать все удаленные терминалы как стандартные "сетевые виртуальные терминалы" строчного типа, работающие в коде ASCII, а также обеспечивает возможность согласования более сложных функций (например, локальный или удаленный эхо-контроль, страничный режим, высота и ширина экрана и т.д.) TELNET работает на базе протокола TCP. На прикладном уровне над TELNET находится либо программа поддержки реального терминала (на стороне пользователя), либо прикладной процесс в обсуживающей машине, к которому осуществляется доступ с терминала.
Работа с TELNET походит на набор телефонного номера. Пользователь набирает на клавиатуре что-то вроде telnet delta и получает на экране приглашение на вход в машину delta.
Протокол TELNET существует уже давно. Он хорошо опробован и широко распространен. Создано множество реализаций для самых разных операционных систем. Вполне допустимо, чтобы процесс-клиент работал, скажем, под управлением ОС VAX/VMS, а процесс-сервер под ОС UNIX System V.
Электронные доски объявлений (BBS). Независимо от Internet существуют маленькие диалоговые службы, предоставляющие доступ к BBS (Bulletin Board System - система электронных досок объявлений).
Это компьютеры, к которым можно подсоединиться с помощью модемов через телефонную сеть. BBS содержат файлы, которые можно переписывать, позволяют проводить дискуссии, участвовать в различных играх и имеют свою систему электронной почты.
Самой крупной и известной системой электронных досок объявлений является система CompuServe. Она насчитывает около двух миллионов пользователей. Для расширения своих возможностей CompuServe подключается к Internet и предоставляет своим пользователям право доступа к службам Internet.
Несмотря на относительную дешевизну обслуживания, ни одна из диалоговых систем BBS не может дать пользователям тех возможностей, которые предоставляет Internet.
Протокол FTP
Протокол FTP (File Transfer Protocol - протокол передачи файлов) распространен также широко как TELNET. Он является одним из старейших протоколов семейства TCP/IP. Также как TELNET он пользуется транспортными услугами TCP. Существует множество реализаций для различных операционных систем, которые хорошо взаимодействуют между собой. Пользователь FTP может вызывать несколько команд, которые позволяют ему посмотреть каталог удаленной машины, перейти из одного каталога в другой, а также скопировать один или несколько файлов.
Передача файлов с помощью протокола FTP
Назначение электронной почты - прежде всего обмен текстовой информацией между различными компьютерными системами. Не меньший интерес для пользователей сети Internet представляет обмен отдельными файлами и целыми программами.
Для того чтобы обеспечить перемещение данных между различными операционными системами, которые могут встретиться в Internet, используется протокол FTP (File Transfer Protocol), работающий независимо от применяемого оборудования. Протокол обеспечивает способ перемещения файлов между двумя компьютерами и позволяет абоненту сети Internet получить в свое распоряжение множество файлов. Пользователь получает доступ к различным файлам и программам, хранящимся на компьютерах, подключенных к сети.
Программа, реализующая этот протокол, позволяет установить связь с одним из множества FTP-серверов в Internet.
FTP-сервер - компьютер, на котором содержатся файлы, предназначенные для открытого доступа.
Программа FTP-клиент не только реализует протокол передачи данных, но и поддерживает набор команд, которые используются для просмотра каталога FTP-сервера, поиска файлов и управления перемещением данных.
Для установки связи с FTP-сервером пользователь при работе в Unix или MS DOC должен ввести команду ftp, а затем адрес или доменное имя его.
Если связь установлена, появится приглашение ввести имя пользователя. Пользователь, не зарегистрированный на сервере, может представиться именем "anonymus" и получит доступ к определенным файлам и программам. Если будет запрошен пароль, можно ввести свой адрес электронной почты. Поступившее после выполнения этих процедур приглашение позволяет работать с FTP-сервером.
Внимание! Основной режим передачи файлов - передача в коде ASCII. Для передачи двоичных файлов необходимо ввести команду binary. Для определения активного режима необходимо ввести команду status.
Так как большинство FТР-серверов работает под управлением операционной системы Unix, то технология работы в этой системе требует введения команд из командной строки компьютера и несколько затрудняет действия пользователя в этом режиме.
Операционная система Windows 95 позволяет работать с программой WS_FTP, что обеспечивает более удобный способ работы с серверами FTP. Еще один способ работы основан на использовании приложений - навигаторов WWW, таких, как Microsoft Interact Explorer, Netscape Navigator.
FTP — программа, предназначенная для передачи файлов между разными компьютерами, работающими в сетях TCP/IP: на одном из компьютеров работает программа — сервер, на втором пользователь запускает программу — клиента, которая соединяется с сервером и передает или получает по протоколу FTP файлы. Тут предполагается, что пользователь зарегистрирован на обоих компьютерах и соединяется с сервером под своим именем и со своим паролем на этом компьютере. Общий -формат команды FTP: FTP [ IP_address | hostName]
После получения приглашения от программы FTP пользователю доступны следующие основные команды.
"Type" — устанавливает режим пересылки файла — текстового ("ascii") или двоичного ("image").
"Dir." или "Ls" — показывает содержимое текущего каталога на удаленном компьютере
"CD" — изменяет текущий каталог.
"Get remote_file_name local_file_name" — считывает файл из удаленного компьютера в локальный.
"Put local_Jite_name remote_flle_name" — передать файл из локального Компьютера в удаленный.
"Close" — завершение FTP соединения.
"Open" — инициализировать другое соединение FTP.
"Quit" — завершить работу.
Сервер FTP зачастую настраивается таким образом, что соединиться с ним можно не только под своим именем, но и под условным именем anonymous — аноним. Тогда вам становится доступна не вся файловая система компьютера, а некоторый набор файлов, который составляет содержимое сервера anonymous ftp — публичного файлового архива. FTP - сервис прямого доступа, требующий полноценного подключения к Internet, но возможен и доступ через электронную почту — существуют серверы, которые могут прислать вам по электронной почте файлы с любых серверов anonymous ftp.
Протокол SMTP
Протокол SMTP (Simple Mail Transfer Protocol - простой протокол передачи почты) поддерживает передачу сообщений (электронной почты) между произвольными узлами сети internet. Имея механизмы промежуточного хранения почты и механизмы повышения надежности доставки, протокол SMTP допускает использование различных транспотных служб. Он может работать даже в сетях, не использующих протоколы семейства TCP/IP. Протокол SMTP обеспечивает как группирование сообщений в адрес одного получателя, так и размножение нескольких копий сообщения для передачи в разные адреса. Над модулем SMTP располагается почтовая служба конкретных вычислительных систем.
NFS
Сетевая файловая система NFS (Network File System) впервые была разработана компанией Sun Microsystems Inc. NFS использует транспортные услуги UDP и позволяет монтировать в единое целое файловые системы нескольких машин с ОС UNIX. Бездисковые рабочие станции получают доступ к дискам файл-сервера так, как-будто это их локальные диски.
NFS значительно увеличивает нагрузку на сеть. Если в сети используются медленные линии связи, то от NFS мало толку. Однако, если пропускная способность сети позволяет NFS нормально работать, то пользователи получают большие преимущества. Поскольку сервер и клиент NFS реализуются в ядре ОС, все обычные несетевые программы получают возможность работать с удаленными файлами, расположенными на подмонтированных NFS-дисках, точно также как с локальными файлами.
Протокол SNMP
Протокол SNMP (Simple Network Management Protocol - простой протокол управления сетью) работает на базе UDP и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении дел в сети internet. Протокол определяет формат данных, их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети.
HyperText Transfer Protocol (HTTP)
HTTP - это новый Internet протокол, который спроектирован специально для быстрого манипулирования с гипертекстовыми документами. Подобно другим Internet инструментариям, таким как FTP, WAIS и Gopher, HTTP - это клиент-сервер протокол. В модели клиент-сервер программа клиент, которая исполняется на компьютере пользователя, посылает запрос к программе сервера, которая исполняется на другом компьютере в сети Internet. Ответ на запрос сервер отсылает снова клиенту. В поцессе обмена этими сообщениями, клиент и сервер используют протокол (совокупность правил, согласно которым компьютеры взаимодействуют между собой). FTP, WAIS и Gopher - другие примеры протоколов клиент-сервер сети Internet, каждый из которых также доступен через WWW броузер. Однако HTTP был сконструирован специально для работы с гипертекстовыми документами.
На самом простом уровне HTTP серверы действуют подобно анонимным FTP серверам, поставляя файлы по запросам клиентов. Однако HTTP cервера поддерживают еще ряд важных дополнительных функций:
- возможность отсылать клиенту не только файлы, но также и дополнительную информацию, которая генеруется программами, которые исполняются на сервере;
- возможность брать данные, посланные клиентом и передать эту информацию другим программам, которые находятся на сервере, для дальнейшей обработки.
Специальные программы, которые находятся на сервере и исполняют эти функции, называются программами gateway (шлюз), поскольку они действительно действуют как шлюз между HTTP сервером и другими локальными ресурсами, такими как, например, базы данных. В точности так, как FTP сервер предоставляет возможность доступа к огромному количеству файлов, так и HTTP сервер предоставляет возможность доступа к огромному количеству программ: в этих двух случаях Вы определяете путем задания URL, какие (файловые или программные) ресурсы Вы б хотели получить.
Взаимодействие между сервером и этими gateway программами регулируется спецификациями Common Gateway Interface (CGI). Используя CGI cпецификации, программист может легко писать простые программы или скрипты на обработку запросов пользователя и тому подобное.
В настоящее время используется версия 1.1 протокола HTTP. Ее поддерживают все основные броузеры и WEB-серверы. Протокол HTTP 1.1 описан в RFC-2068 и превосходит предыдущую версию HTTP 1.0 – прежде всего, по производительности. Однако, есть и другие отличия, описанные ниже
Постоянные соединения. Протокол HTTP 1.1 устанавливает меньше TCP-соединений, чем HTTP 1.0. Версия 1.0 устанавливает и разрывает TCP-соединение для каждого HTML-запроса, а HTTP 1.1 создает TCP-соединение, сохраняющееся на протяжении многих запросов.
Протокол HTTP 1.1 поддерживает сжатие данных. Это означает, что файлы между клиентом и сервером могут передаваться сжатыми, что снижает нагрузку на сеть.
Протокол HTTP 1.1 поддерживает многие языки сетевого программирования.
Создание виртуальных хостов. Протокол HTTP 1.1 позволяет одному WEB-серверу иметь несколько доменных имен. В настоящее время эта ситуация распространена широко (например, когда поставщик услуг InterNet’а поддерживает несколько доменов).
Консорциум W3С работает над протоколом HTTP-NG (Next Generation), который, как предполагается, заменит HTTP. К HTTP-NG предъявляются следующие требования:
Простота – протокол HTTP-NG должен быть прост для реализации и обслуживания.
Расширяемость – на случай ситуации, не предусмотренной в процессе разработки.
Масштабируемость – вне зависимости от того, используется ли HTTP-NG в маленькой локальной сети или в сети InterNet.
Эффективность – ожидается, что протокол HTTP-NG будет намного эффективнее HTTP. Последний плохо работает в сетях с большим временем задержки. Причина в том, что HTTP – протокол одиночных запросов и ответов. Кроме того, он перегружен информацией. Протокол HTTP-NG призван устранить эти и другие недостатки.
В последнее десятилетие наметилась тенденция разработки формальных методов описания протоколов, значительно упрощающих разработку и тестирования новых протоколов передачи данных (см. подраздел 3.2), требования обеспечения конфиденциальности передаваемой по сетям информации инициировали разработку новых протоколов обеспечения секретности данных.
Лекция
Web-сервис
Веб-сервисы сегодня на слуху у западных сообществ разработчиков, аналитиков и менеджеров. Однако, в России технологии веб-сервисов пока новы и нуждаются в представлении. В этой серии статей мы попробуем познакомить Вас с этой концепцией. Каждая статья серии будет выходить примерно раз в месяц, поэтому просим следить за публикациями нашего сайта. Немного истории Чтобы понять, почему в головы IT-специалистам пришла концепция веб-сервисов, чем эта концепция отлична от иных попыток создания технологий разработки распределенных информационных систем (ИС) и, самое важное, чем она так хороша, как это следует из уст ведущих экспертов крупных компаний-вендоров и аналитиков IT-сектора, уместно вернуться на несколько лет назад и посмотреть как развивались технологии построения распределенных ИС, что было создано и с какими проблемами пришлось столкнуться. Как это обычно бывает, почти во всем “виноваты” деньги. Когда компьютерные сети вышли за рамки сугубо научных и военных учреждений (вспомним ARPAnet), они стали достоянием энтузиастов-частных лиц. Когда же частных лиц, пользующихся компьютерными сетями, стало достаточно много, сообразили, что компьютерные сети могут быть использованы для производства денег. Так компьютерные сети общего пользования, основная и самая распространенная из которых сегодня называется Интернет, стали бизнес-инструментом. Чтобы с помощью этого инструмента вести бизнес, он должен удовлетворять некоторому набору требований, главные из которых – безопасность и скорость передачи информации. Задачу выполнения этих требований стали решать на самом низком уровне – на уровне транспортных протоколов. Различные компании предложили различные реализации сетевых протоколов. Сетевые протоколы, как известно, задают правила формирования сетевых пакетов и обмена ими. Использующие эти правила (повторимся - различные для различных протоколов) сетевые приложения тем самым жестко привязываются к определенным протоколам. Между тем быстроразвивающиеся бизнес-отношения требовали, чтобы сетевые приложения, использующие различные протоколы, могли обмениваться между собой данными – таким образом, встала задача интеграции приложений. Вот здесь-то и начались мытарства. На протяжении нескольких лет было создано несколько технологий взаимодействия распределенных приложений, так или иначе позволявших реализовать обмен данными между приложениями (среди получивших наибольшее развитие - Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) и Common Object Request Broker Architecture (CORBA)), однако каждая из них была довольно сложна в реализации, не обладала необходимой универсальностью (т. е. все же зависела от выбора, например, одной и той же операционной системы для всех участников обмена) и, что особенно плохо, эти технологии с большим трудом стыковались между собой. Т. е. произошло лишь укрупнение групп невзаимодействующих между собой приложений, что, разумеется, не могло устраивать ни бизнес, ни IT-специалистов. Тогда был избран иной, противоположный, подход: обратились к базисным веб-технологиям, попробовали найти то немногое, что является основой Интернета. А эта основа состоит из следующих технологий:
Таким образом, веб-сервисы решают исходную задачу – задачу интеграции приложений различной природы и построения распределенных ИС. В этом и заключается основное принципиальное отличие веб-сервисов от предшественников. Уже сейчас ясно, что наиболее широкое применение веб-сервисы найдут в сфере интеграции корпоративных приложений (Enterprise Application Integration (EAI)). С помощью веб-сервисов можно несколько, порой сильно разнящихся между собой, бизнес-процессов выстроить в один-единственный цельный бизнес-процесс, достигнув при этом существенно более высоких показателей эффективности бизнеса – начиная от прямого увеличения выручки за счет улучшения продаж и обслуживания клиентов и кончая “банальным” сокращением накладных расходов при обмене данными. Так ли все хорошо? И все же веб-сервисы нельзя рассматривать как лекарство от всех бизнес-проблем, имеющихся сейчас или могущих возникнуть в будущем. Хотя веб-сервисы и являются логичным и уже вполне зрелым продолжением предшествовавших им технологий построения распределенных ИС, они – такая же технология, как и многие другие, имеющая свои плюсы и минусы и, как следствие, рамки применимости. Непонимание и неучет этих ограничений в реальных проектах может привести к весьма печальным последствиям. Подробнее остановимся на плюсах и минусах. К плюсам веб-сервисов можно отнести следующее:
Не менее подробно остановимся и на минусах веб-сервисов:
Анализируя вышеизложенное, на наш взгляд, можно заметить, что плюсы являют собой бизнес-преимущества стратегического плана, минусы же носят технологический характер и происходят больше от новизны технологий веб-сервисов и, мы уверены, решение этих проблем является лишь вопросом времени (причем не столь отдаленного, учитывая темпы развития IT-мысли). Web-сервисы как таковые Web-сервисы - это автономные модульные приложения, которые можно публиковать и вызывать по сети (например, Интернет). Каждый Web-сервис описывается предоставляемыми им интерфейсами. Web-сервисы проектируются с тем, чтобы свободно объединять клиентские приложения с серверами. Реализация сервера не требует, чтобы клиент работал на специфической платформе или был написан с использованием определенного языка программирования. Кроме определения интерфейсов, независимых от языка, в Web-сервисах реализована поддержка множественных механизмов соединения. Теперь поговорим о стандартах, лежащих в основе Web-сервисов. Прежде всего необходимо сказать о средствах публикации Web-сервисов в сети. Публикация означает, что Web-сервис должен быть "зарегистрирован" в некотором списке, чтобы клиентское приложение могло его найти. В настоящее время публикация осуществляется согласно стандарту UDDI (Universal Description, Discovery and Integration), созданному при сотрудничестве компаний Ariba, IBM и Microsoft. Основная идея стандарта состоит в объединении всех поставщиков товаров и услуг, доступных через Web, в едином реестре UDDI. Для создания такого реестра требовался формат описания сервисов, и он был предложен все теми же Ariba, IBM и Microsoft в виде языка описания Web-сервисов - Web Services Description Language (WSDL), построенного на основе XML. WSDL предназначен для описания сетевых сервисов как коллекций конечных точек сетевого взаимодействия, отвечающих за обмен сообщениями. WSDL позволяет описывать возможности Web-сервиса, перечислять доступные для каждого сервиса операции и описывать формат данных для каждого действия. Использование XML в качестве основы в какой-то степени упрощает создание таких WSDL-описаний, однако делать это вручную зачастую оказывается сложно. Реализация Web-сервисов Для работы с Web-сервисами используется протокол SOAP (Simple Object Access Protocol), служащий для обмена информацией в децентрализованных, распределенных средах. Для создания удаленных процедур в рамках этого протокола служит язык XML, а в качестве коммуникационного протокола применяется HTTP. Основанная на применении SOAP технология формирует базу для разработки кросс-платформенных распределенных приложений. При использовании Web-сервисов нет необходимости устанавливать специальное клиентское ПО, как это было при работе с распределенными приложениями на базе технологии CORBA. Использование HTTP-сообщений позволяет ориентироваться на самые различные типы программно-аппаратного обеспечения. Определение веб-сервиса Дадим формальное определение веб-сервиса. Веб-сервисом (см. документ W3C “Web-services architecture requirements”) называется программная система, идентифицируемая строкой URI, чьи публичные интерфейсы и привязки определены и описаны посредством XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов. Внимательно прочитав это крайне общее, но, тем не менее, очень точное по сути определение (именно в его общности и заключается, как ни парадоксально, его точность), можно увидеть, что единственное упоминание конкретной технологии сделано в отношении XML. Не говорится ни о применяемом сетевом протоколе, ни о языке программирования, ни о программной платформе. И хотя, как правило, для передачи сообщений в ИС на основе веб-сервисов в качестве транспортного протокола используется стандартный HTTP, его использование совершенно не обязательно, и можно использовать (посредством так называемых протокольных привязок (protocol bindings)), например, SMTP-протокол. На применение языков программирования также не накладывается никаких ограничений – уже разработаны веб-сервисы на Java, C++, C#, COBOL и других языках. С программными платформами, операционными системами и серверами приложений, дело обстоит еще проще (лучше) – возможны любые сочетания (например, можно найти и вызвать веб-сервис, развернутый на IBM WebSphere Application Server под управлением Linux, с рабочей станции Macintosh). Единственное условие – использование XML-сообщений (точнее SOAP-сообщений), поскольку реальной альтернативы XML как языку, позволяющему работать с различными типами данных, на сегодняшний день нет. |
||||||||||||||||||||||||||||||||||||||||||||||||||||
Стек технологий веб-сервисов Итак, концепция сервисно-ориентированной архитектуры подразумевает реализацию бизнес-процессов предприятия в виде совокупности сервисов, взаимодействующих друг с другом либо с пользователями в определенной последовательности и в соответствии с определенными правилами. Отметим, что, вообще говоря, это весьма нетривиальная задача - определить эту "определенную последовательность" и "определенные правила" таким стандартным для индустрии (разработки бизнес-приложений) образом, чтобы покрыть весь спектр существующих сценариев взаимодействия бизнес-объектов, учитывая исторически сложившееся многообразие технической и технологической реализации этого взаимодействия и самих бизнес-объектов. Решить эту задачу в рамках какой-либо единой технологии пока не удалось. И хотя тенденция консолидации существующего множества технологий веб-сервисов в настоящее время налицо, для реализации сервисно-ориентированных архитектур с помощью веб-сервисов сейчас применяется совокупность технологий, образующих так называемый стек технологий веб-сервисов (см. Рис. 1).
Рис. 1: Стек технологий веб-сервисов Стек технологий веб-сервисов принципиально разбивается на следующие две составляющие:
Эти составляющие в свою очередь образуются несколькими слоями (layers):
В целях понимания назначения слоев, дадим краткое описание каждого из них.
Представленный выше стек технологий веб-сервисов вводит иерархию во множество технологий веб-сервисов в соответствии с их функциональным назначением. При этом в таблице указаны лишь наиболее широко применяемые и устоявшиеся технологии. Стандартными названы технологии, получившие официальный статус стандартов международных консорциумов по разработке IT-стандартов (W3C, OASIS либо WS-I). В действительности, спектр технологий, описывающих те или иные аспекты использования веб-сервисов либо сервисно-ориентированных архитектур, крайне широк (см. раздел Стандарты нашего сайта), в частности, потому, что процесс разработки данных технологий является открытым - любая компания, некоммерческое объединение специалистов или даже один специалист может разработать и опубликовать спецификацию разработанной им технологии. В настоящее время это даже стало серьезной проблемой рынка веб-сервисов - количество спецификаций стало столь велико, что при фактической нерегламентированности глобального (в рамках всей индустрии) процесса их разработки, ввода в действие и использования, появляется опасность ввергнуть индустрию в хаос и технологическую разобщенность. А технологическая разобщенность - как раз то, от чего хотели уйти прежде всего, разрабатывая веб-сервисы и закладывая в качестве их концептуальной и технологической основы открытые и наиболее широко применяемые IT-технологии. |
||||||||||||||||||||||||||||||||||||||||||||||||||||
Лекция Web-сервис. Протокол SOAP
Web-сервисы и Snap-технологии В версии Kylix 2 компания Borland реализовала новое семейство технологий, названное Snap. На данный момент предлагаются три технологии из этого семейства, соответствующие трем уровням структуры приложений. Самый нижний, базовый уровень представлен технологией DataSnap, которая по сути выступает логическим продолжением механизмов работы с XML, реализованных в предыдущих версиях Delphi и Kylix, в частности, механизма MyBase. Используя DataSnap API, разработчики смогут реализовать доступ к любым широко распространенным базам данных на основе SQL, поставляя информацию в XML-синтаксисе под управлением протокола SOAP. Доступ к базам данных предоставляется большому кругу клиентских программ, включая так называемые "тонкие клиенты" и Web-сервисы, причем разработка такого доступа оказывается намного дешевле, чем раньше. Следующий уровень модели Snap, технология WebSnap, позволит значительно ускорить процесс разработки сложных Web-сайтов, предлагающих наряду с элементарным доступом к информации и более серьезные возможности. WebSnap позволяет объединить в едином процессе дизайнерскую работу и создание самой логики приложения. Кроме того, использование компонентов WebSnap позволяет отлаживать серверные приложения с помощью механизма WebSnap Debugging Web Server, который обеспечивает высокоуровневый мониторинг всех процессов взаимодействия, происходящих на сайте. В инструментарий WebSnap также входят серверные компоненты для реализации Web-страниц, предусматривающие написание сценариев на JavaScript. Верхний уровень модели Snap - это технология BizSnap, которая полностью внедряет Web-сервисы в объектно-ориентированную среду разработки. Опережая появление стандартной XML-схемы, средства BizSnap модернизируют определение модульных XML-преобразований, которые позволяют приложению работать с XML-данными, имеющими одно и то же содержание, но различную структуру. BizSnap позволяет создавать Web-сервисы на основе промышленных стандартов и пускать их в обращение, используя WSDL. Предусмотрено также создание - путем импорта WSDL-документов - программ-клиентов для работы с существующими Web-сервисами, созданными с использованием Microsoft .NET, Sun ONE или других технологий.
Инструментарий для создания Web-сервисов Как и любой новой экосистеме, архитектуре Web-сервисов для выживания необходимы развитые поддерживающие структуры. Руководство корпорации Microsoft (Редмонд, шт. Вашингтон) надеется, что созданная специально для этой цели платформа .Net окажется, несмотря на отсутствие практики ее применения, более приспособленной к выживанию, чем конкурирующая архитектура Sun ONE (Open Network Environment — открытая сетевая среда) фирмы Sun Microsystems, основанная на успевшей уже завоевать прочное положение платформе Java. Ключевыми компонентами этих ИТ-экосистем являются инструментальные средства, упрощающие разработчикам задачу создания кода для .Net или Sun ONE. Тестовый центр eWeek Labs провел испытания предварительных версий сред разработки корпорации Microsoft и фирмы Sun — Visual Studio .Net Enterprise Architect Beta 2 и Forte for Java 3.0 Enterprise Edition beta (Early Access release) соответственно — чтобы определить, насколько хороша каждая из них в деле создания Web-сервисов для корпоративного применения. Visual Studio .Net поступит в продажу к концу года; никакой официальной информации о ценах пока нет. Forte for Java 3.0 Enterprise Edition поставляется с сентября в редакциях для Windows NT 4.0, Solaris 8 и Red Hat Linux 6.2 по цене $1995. Прежде чем делать стратегический выбор в пользу того или иного инструментария, каждой конкретной службе ИТ необходимо тщательно исследовать вопрос, какая платформа ей больше подходит. Пользуясь удачной возможностью начать с нуля, Microsoft разработала для .Net новую модель, предназначенную специально для построения Web-сервисов и написания ПО для Интернета. В результате нас ожидает самая дорогостоящая и самая сложная модернизация Windows-среды за последнее десятилетие. Она потребует значительного переобучения персонала, а также внесения изменений — от небольших до довольно крупных — в существующий код, в частности в программы на языке Visual Basic и в Web-страницы, использующие скрипты ASP (Active Server Pages — активные серверные страницы) на базе языка VBScript. Среда Visual Studio .Net незаменима для будущих разработчиков .Net-приложений не только потому, что отличается интегрированностью, но и просто потому, что у нее пока нет конкурентов. Платформа Java, появившаяся более шести лет назад, требовала не менее серьезных перемен, но теперь это зрелый, проверенный практикой и заслуживший широкое признание язык программирования для написания серверных приложений. И как следствие, Java-разработчики располагают значительно более широким выбором инструментов. Дополнительную привлекательность Forte for Java придают средства для создания EJB-компонентов (Enterprise JavaBeans), Web-сервисов на базе XML (Extensible Markup Language — расширяемый язык разметки) и развертывания кода в среде сервера приложений iPlanet Application Server фирмы Sun-Netscape Alliance (мы использовали при тестировании версию iPlanet Application Server 6.0). Вместе с тем этому продукту приходится соревноваться с такими серьезными конкурентами, как JBuilder корпорации Borland Software. К тому же у Forte for Java есть крупный недостаток — отсутствие встроенной поддержки протокола SOAP (Simple Object Access Protocol — простой протокол доступа к объектам). Впрочем, и Forte for Java, и Visual Studio .Net не свободны от существенных пробелов в наборах функциональных возможностей — более по причинам “политического” выбора производителей, нежели из-за технологических сложностей. Первая поддерживает только один язык программирования (естественно, Java), а вторая использует единый редактор для написания программ на языках Cи++, C#, Visual Basic и ECMAScript (но не Java). Правда, представители Sun уверяют, что в последующих версиях Forte for Java будет реализована поддержка разработки на нескольких языках.
Что такое SOAP Протокол, основанный на спецификации XML и включающий:
SOAP Версия 1.2: |
HTTP-привязка SOAP HTTP имеет хорошо известную модель взаимодействия и шаблон обмена сообщениями. Клиент идентифицирует сервер по URI, подсоединяется к нему с помощью TCP/IP сети, отсылает HTTP-сообщение-запрос и получает HTTP-сообщение-отклик по тому же TCP-соединению. HTTP полностью коррелирует сообщение-запрос и соответствующий ему сообщение-отклик, поэтому приложение, использующее эту привязку, может реализовать корреляцию между отправленным в теле HTTP-запроса SOAP-сообщением и SOAP-сообщением, возвращенным в качестве HTTP-отклика. Подобным образом, HTTP идентифицирует конечный сервер по URI, URI-запросу, который может также служить идентификатором SOAP-узла сервера. HTTP могут использовать многочисленные посредники между начальным клиентом и сервером, инициировавшим обмен сообщениями, идентифицируемые по URI-запросу, в этом случае модель запрос/отклик является по существу сериями таких пар. Необходимо отметить, что HTTP-посредник и SOAP-посредник не являются тождественными понятиями. HTTP-привязка [SOAP Часть 2] использует функцию SOAP Web-метода, позволяющую приложениям выбирать один из так называемых Web-методов - GET или POST - чтобы использовать для обмена сообщениями с помощью HTTP. Кроме того, она использует два шаблона обмена сообщениями, которые дают приложениям два способа обмена SOAP-сообщениями посредством HTTP: 1) использование HTTP-метода POST для передачи SOAP-сообщений в теле HTTP-запроса и HTTP-отклика, и 2) использование HTTP-метода GET в HTTP-запросе для возвращения SOAP-сообщения в теле HTTP-отклика. Первый шаблон использования является HTTP-реализацией функции привязки - шаблона обмена SOAP-сообщениями типа "запрос-отклик", второй - шаблона обмена SOAP-сообщениями типа "отклик". Цель разработки этих двух способов - реализовать две парадигмы взаимодействия, одинаково хорошо подходящие для World Wide Web. Первый тип взаимодействия позволяет использовать данные в теле HTTP-метода POST для создания или изменения состояния ресурса, идентифицируемого по URI, в соответствии с которым направлен HTTP-запрос. Второй тип шаблона взаимодействия дает возможность использовать HTTP-запрос GET для получения представления о ресурсе без какого-либо изменения его состояния. В первом случае касающийся SOAP аспект вопроса состоит в том, что тело HTTP-запроса POST является SOAP-сообщением, которое кроме того, что должно быть обработано (согласно модели обработки SOAP) в соответствии со специфичной для приложения обработкой, должно также соответствовать семантике POST. Во втором случае типичной реализацией является получение представления запрашиваемого ресурса в виде SOAP-сообщения, а не в виде HTML- или XML-документа. То есть HTTP-заголовок типа содержимого сообщения идентифицирует это как медиа-тип "application/soap+xml". Вероятно, найдутся создатели Web-ресурсов, которые впоследствии обнаружат, что такие ресурсы проще всего найти и сделать доступными в виде SOAP-сообщений. Надо отметить, однако, что ресурсы могут быть доступны в виде различных представлений; желаемое или предпочтительное представление может быть получено путем опроса приложения с помощью HTTP-заголовка Accept. Следующим аспектом HTTP-привязки SOAP является проблема определения, какой из вышеуказанных двух шаблонов обмена сообщениями использовать. [SOAP Часть 2] содержит руководство, описывающее в каких обстоятельствах приложения могут использовать тот или иной определенный шаблон обмена сообщениями. Шаблон обмена SOAP-сообщениями с использованием HTTP-метода GET, используется в том случае, если приложение использует этот шаблон только для поиска информации, а сам ресурс в результате взаимодействия остается "нетронутым". Подобные взаимодействия трактуются в спецификации HTTP как безопасные и идемпотентные. Поскольку использование SOAP HTTP-метода GET не разрешено для SOAP-сообщения, содержащегося в запросе, приложения, которым необходим доступ к функциям взаимодействия с внешними объектами, которые поддерживаются только специфичным для привязки выражением внутри информационного множества SOAP (то есть в качестве заголовочных SOAP-блоков), не могут использовать этот шаблон обмена сообщениями. Необходимо отметить, что HTTP-метод POST привязки может применяться во всех случаях. |