Web-сервис — это программное обеспечение, которое предоставляет платфор-менно-независимый доступ к своим данным другим программным продуктам через Интернет, с использованием XML и таких стандартов, как SOAP, WSDL и UDDI.

Для чего могут использоваться Web-сервисы на практике? Представьте фондо­вую биржу, серверы которой имеют полную информацию о текущих котировках всех ценных бумаг, оборачиваемых на данной бирже. Это очень важная информа­ция, онлайн-доступ к которой может быть очень ценным и полезным для удален­ных программных систем. Или другой более близкий простому человеку пример: сервер метеобюро может содержать информацию о погодных условиях в некотором регионе или на всей планете. Эта информация также может быть использована сто­ронними приложениями.

Многим часто приходилось видеть информеры погодных сайтов, однако это не самый удобный метод получения реальной информации для корпоративных при­ложений, так как он ограничивает возможцости оперирования получаемой инфор­мацией. С таким информером можно сделать только две вещи: "повесить" у себя на сайте или убрать его с сайта, если он там уже размещен. Но как быть с приложе­ниями, которым необходимо получать исходные данные f сервера метеобюро и об­рабатывать их для выполнения каких-либо сложных операций (например, для графического моделирования карт с нанесением соответствующей температуры на регионы)?

Для решения таких проблем сервер фондовой биржи или метеобюро может стать провайдером (поставщиком) Web-сервисов, а приложения, которые полу­чают от них данные через Интернет, -— потребителями этих данных. Таким обра­зом формируется архитектура клиент-сЬрвер, где поставщик данных является сервером, а потребитель — клиентом, при этом программное обеспечение сервера и клиента не обязательно должно быть совместимым, главное условие – под­держка Web-сервисов.

Обмен между сервером и клиентом производится по стандартным протоколам Интернет, таким, например, как HTTP. Web-сервис сам описывает себя и опреде­ляет API взаимодействия с ним. при этом элементы данного API автоматически преобразуются в языковые конструкции для того языка программирования, кото­рый использует клиентское приложение. Описание Web-сервисов происходит по спецификации WSDL (Web Services Description Language — язык описания Web-сервисов). Передача самих данных от сервера к клиенту производится в формате SOAP (Simple Object Access Protocol — простой протокол доступа к объектам).

Другими словами, клиентское приложение обращается к файлу WSDL по его URL, т.е. обычным GET-методом. При этом оно получает описание методов Web-сервиса и далее может использовать их как свои (т.е. без написания дополнитель­ного кода на стороне клиента — Web-сервис становится как бы удаленным про­должением клиентской программы).

Практическое использование Web-сервисов в IBM Lotus Domino 7

Что такое Web-сервисы и почему они важны?

Серия контента:

Этот контент является частью # из серии # статей: Практическое использование Web-сервисов в IBM Lotus Domino 7

https://www..jsp?series_title_by=Практическое+использование+web-сервисов+в+ibm+lotus+domino+7

Следите за выходом новых статей этой серии.

Возможно, вы встречались с упоминаниями о Web-сервисах в технических статьях, описаниях программных продуктов или даже в диалогах с сослуживцами. Видно, кому-то Web-сервисы нужны и важны, однако, повстречавшись с определениями вроде "Грамматика XML для определения наборов конечных точек для обмена сообщениями," вы решили, что такие сложные вещи и трогать не стоит.

К счастью, Web-сервисы можно разъяснить и так, чтобы поняли все, при этом не вникая в подробности того, как всё это работает. Вам стоит попробовать разобраться, что такое Web-сервисы, поскольку область их (а также имеющей к ним отношение сервис-ориентированной архитектуры, SOA) применения в мире IT постоянно расширяется.

Web-сервисы можно воспринимать как автомобиль: вам не надо знать на техническом уровне, как работают поршни, распредвалы и топливные инжекторы - вы и без этого можете купить автомобиль, управлять им и разговаривать о машинах с друзьями (если они, конечно, не механики). То же и с Web-сервисами, вам как специалисту IT достаточно просто разобраться, что это такое и как они работают, чтобы понять, зачем они вам нужны.

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

Эта серия статей поможет разработчикам Domino понять и использовать Web-сервисы в IBM Lotus Domino V7.0. Эта вступительная статья содержит достаточно полезной информации, и пригодится любому желающему понять, что же такое Web-сервисы. Технологии в Lotus Domino V7.0 позволяют разработчикам легко создавать и использовать Web-сервисы, и позже мы детально коснёмся этого.

Вначале давайте разберёмся, что такое Web-сервис.

Что такое Web-сервис?

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

Связь между тремя и более машинами

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

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

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

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

В структуру коммуникаций с использованием Web-сервисов включены многие элементы, которых мы коснёмся в этой статье. Однако идея остаётся той же, что и у обычного диалога - программы общаются, используя знакомый им язык, иногда по сети. Программы могут как находиться на одном компьютере, так и размещаться на разных машинах в разных точках земного шара, соединённые через интернет маршрутизаторами и серверами. Хорошо то, что программам и компьютерам не обязательно быть одинаковыми. Благодаря Web-сервисам переговариваться могут как две программы Microsoft .NET на одном ноутбуке, так и программа Java на канадском сервере iSeries с программой C++ на компьютере с ОС Linux из Китая.

В коммуникациях посредством Web-сервисов используются следующие стандартные технологии:

• XML. Язык (формат данных), используемый компонентами Web-сервисов.
• Протокол SOAP. Сообщения XML, которыми обмениваются программы
• Библиотека описаний Web-сервисов (WSDL). Файл XML, в котором определены формат сообщений SOAP и то, как их посылать

Для осуществления связи между Web-сервисами также может использоваться стандартная технология, известная как Universal Description, Discovery, and Integration (UDDI). Мы рассмотрим это далее в статье, однако поскольку использование UDDI не обязательно, многие Web-сервисы её не используют.

Немного терминологии: публикация и использование Web-сервисов

Прежде чем заняться разъяснением наших терминов, давайте рассмотрим часть связанной с Web-сервисами терминологии.

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

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

XML: родной язык

Язык XML используется для общения между компонентами Web-сервисов. Сообщения, пересылаемые между приложениями, равно как определяющие Web-сервис файлы, имеют формат XML. На рисунке 1 показана структура простого файла XML.

Рисунок 1. Базовая структура XML

Как видите, некоторая информация в файле (такая как имя, фамилия) окружена тегами, заключёнными в треугольные скобки. Имя John показано как John . Ещё есть элементы, в которые вложены другие элементы, например в элемент Вложены элементы , и .

Написание Web-сервисов языком XML даёт немалые преимущества, включая:

• Структура и грамматика XML аналогична структуре остальных языков программирования, поэтому взаимодействующим с Web-сервисами программам нет надобности проводить структурный анализ файлов XML напрямую.
• Файлы XML текстовые, и их может прочитать человек (иными словами, зная язык XML, вы можете открыть файл XML в текстовом редакторе и понять его содержимое). Это может помочь при отладке.
• XML позволяет использовать в сообщениях любую стандартную кодировку, поэтому сообщения вы можете писать как на английском, так и на русском или японском языках.
• XML позволяет вам пользоваться так называемым пространством имен, в котором вы можете предопределить желаемую структуру файлового элемента с определённым именем. Например, вы можете определить элемент Price, который всегда должен быть числом с плавающей точкой, или PersonName, включающий в себя два строковых подэлемента FirstName и LastName.

  Кроме того, при необходимости пространства имен позволяют нескольким элементам с одинаковыми именами иметь разные определения. Например, элемент StockPrice в одном пространстве имен может включать в себя тикерный символ и цену, а в другом пространстве имен может состоять из тикерного символа, цены, дневных минимума и максимума и 12-месячного максимума.

Единственными недостатками XML, если это и в самом деле недостатки, являются:

• Язык XML жёсткий, поэтому любое неправильное форматирование сообщения XML приводит к сбою анализа всего сообщения (даже если проблему легко интерпретировать или пропустить). Однако если вы используете стандартную библиотеку для генерации файлов XML (что и делается при создании Web-сервисов), библиотека сама проверяет правильность форматирования.
• Сообщение XML хранится в обычном текстовом файле, а потому занимает больше места, чем его эквивалент в другом формате (в таких как разделённый, двоичный или "самодельный" формат).

Но эти проблемы не имеют значения по сравнению с преимуществами формата XML.

SOAP: отправляемые сообщения

Вы знаете, что общение Web-сервисов ведётся в формате XML, однако это решает лишь половину проблемы. Приложения могут разобрать сообщение, однако откуда им знать, что делать с полученным после анализа результатом?

Инструкция, описывающая правила форматирования сообщений XML для Web-сервисов известна как SOAP. В ней определена структура сообщений, благодаря чему программы знают, как отправлять и интерпретировать данные. Базовая структура сообщения SOAP показана на рисунке 2.

Рисунок 2. Базовая структура сообщения SOAP

На языке XML это будет выглядеть приблизительно так:

FOO

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

Инструкции SOAP

Хотя формат SOAP стандартен и имеет одинаковые инструкции, необходимо помнить что разные производители могут немного по разному воплощать эти инструкции. Например, структура именных пространств и XML в сообщении SOAP, сгенерированном Apache Axis может сильно отличаться от структуры, сгенерированной Microsoft .NET. Однако правильно написанный клиент или сервер может обработать любое правильно написанное в соответствии с инструкциями SOAP сообщение.

Кроме того, в инструкциях WSDL 1.1 и WSDL 2.0 есть некоторые важные различия. Хотя инструкция 2.0 на момент написания статьи ещё только на этапе завершения, вскоре она начнёт занимать место версии 1.1.

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

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

Протоколы: как отправляются сообщения

Мы ещё не касались вопроса, как же передаются все эти сообщения по SOAP?

А передаются они обычно по сети (и/или интернет) по протоколу HTTP, почти так же, как и страницы передаются с сервера на ваш браузер. HTTP используется не всегда (его главный конкурент - SMTP, однако он далеко позади). Используемый Web-сервисом протокол определён в файле WSDL.

Обычно в файле WSDL протокол, используемый для передачи сообщения SOAP, определён как HTTP. Клиент SOAP отправляет сообщения в соответствии с указанным протоколом.

Другие термины из области Web-сервисов, с которыми вы можете столкнуться

Мы уже разобрались с основными терминами, однако в разговоре о Web-сервисах вы можете услышать ещё некоторые.

Слабые связи

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

Жизненный пример слабых связей - это обед с друзьями. Несколько друзей как-то договариваются между собой (лично, по телефону, через электронную почту и т.д.). Каждый самостоятельно добирается до ресторана, и после обеда каждый сам оплачивает свою еду. Независимо от того как прошёл обед, конечный результат неизменен - это был дружеский обед.

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

UDDI

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

Хотя UDDI и довольно важный стандарт для определения Web-сервисов, его значительность сильно уменьшена за счёт того, что он является необязательным элементом Web-сервисов, а когда есть выбор, использовать или нет, многие решают не использовать.

Большинство организованных корпоративных сред с большим количеством внутренних Web-сервисов имеют реестры UDDI. Замечательно, когда есть корпоративный сайт UDDI, содержащий информацию о доступных в вашей компании Web-сервисах. Собирая вместе все сервисы, UDDI позволяет без проблем и незаметно менять их поставщиков. Если клиенты ищут сервисы через UDDI, то вызовы SOAP автоматически отправляются к новому поставщику.

Однако этот компонент не обязателен в архитектуре Web-сервисов.

Безопасность Web-сервисов

Читая про SOAP и WSDL, вы можете заметить, что не раскрыта тема безопасности. Как проводится аутентификация при вызовах сервисов, если поставщик работает с закрытой информацией? Ведь понятно, что не все Web-сервисы доступны широкой публике, не так ли?

Это важный вопрос, однозначно ответить на который непросто. Есть различные схемы, которые вы можете использовать, смотря по ситуации, например:

• Могут ли сообщения SOAP приходить в виде текста или они должны быть зашифрованы?
• Достаточно ли вам простой аутентификации по логину и паролю или же она должна быть устойчивой и маркерной?
• Если используются маркеры, необходимы ли на них подписи, и как правильно их включить в сообщение SOAP?
• А что если клиент отправляет сообщения SOAP не напрямую, а через какую-то промежуточную структуру, такую как очередь сообщений или через ещё какой-нибудь Web-сервис?

Кроме того, при обмене сообщениями не всегда может использоваться HTTP, поэтому у вас не выйдет попросту использовать системы безопасности Web-сервисов в дополнение к существующим системам безопасности HTTP.

Есть несколько инструкций, которые охватывают эти и прочие аспекты безопасности Web-сервисов: WS-Security, WS-Policy, WS-Trust и WS-Privacy. Некоторые производители ПО и комитеты работают над этими вопросами уже несколько лет. Хотя не все варианты реализации Web-сервисов поддерживают все инструкции безопасности, однако в имеющихся стандартах безопасности обычно реализовано хотя бы несколько основных путей обеспечения безопасности.

Промежуточное ПО и Enterprise Service Bus

Есть ещё один немаленький набор стандартов для Web-сервисов, собранных вместе в один довольно большой комок, которые обычно называются инструкциями WS-*. Вместе они затрагивают много проектировочных моментов, которые возникают, когда вы собираете много Web-сервисов в одну среду. Стандарты WS-* касаются таких вопросов, как:

• Безопасность
• Надёжность
• Обмен сообщениями
• Транзакции
• Качество обслуживания

Такое количество стандартов необходимо, потому что обмен сообщениями между клиентом Web-сервиса и сервером в промышленной среде может быть намного сложнее, чем просто запрос/ответ. Например, как убедиться, что сообщение дошло до поставщика и вернулось к клиенту? Что если запрос SOAP состоит из нескольких частей? Как управлять процессами, в которых участвуют Web-сервисы, обращающиеся к другим Web-сервисам? Что если программа посылает последовательность запросов с требованиями по срокам реагирования?

Для крупных производителей ПО работа с этими стандартами предоставляет как сложности, так и возможности. Некоторые производители представляют на рынке целые пакеты промежуточного ПО для работы с Web-сервисами, часто называемые Enterprise Service Bus, или ESB, которые позволяют разобраться сразу со всеми или по крайней мере некоторыми из вышеупомянутых задач. Эти ESB ценны ещё и потому, что могут связать вместе несколько Web-сервисов в рамках одной организации и обеспечить их функциональность, запись их действий и хранение сообщений в очередях.

Сервис-ориентированная архитектура

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

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

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

Почему это важно?

Теперь вы уже что-то знаете о том, как работают Web-сервисы - клиент читает файл WSDL поставщика, в соответствии с ним форматирует и отправляет сообщение SOAP и получает другое сообщение SOAP в ответ. Так почему ж это так важно? В чём дело?

Частично важность сервисов заключена в том, что они предоставляют стандартный путь для общения между программами, вне зависимости от языков, на которых они написаны и платформ, на которых они работают. Ранее нам приходилось работать с форматами данных, уникальными для разных программ, или же с функциями API-уровня, с которыми не могли работать программы на других языках. Из использования XML во всех стандартах Web-сервисов означает, что все сервисы доступны и понятно определены.

Фактически, это позволяет совсем разным программам легко общаться друг с другом на понятном им всем языке. Одной из главных сложностей при работе с разными технологиями от разных производителей всегда была необходимость заставить все эти разные программы общаться между собой и обмениваться данными. Теперь, когда все ваши приложения могут поставлять и/или использовать Web-сервисы, налаживать взаимодействие между ними невероятно упростилось.

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

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

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

Инструментальная панель превращается из большой программы в простой интерфейс. Желая добавить новые компоненты, мы просто обращаемся к дополнительным сервисам. Если нам нужен другой график, мы обращаемся к другому строящему графики сервису. Если нам нужна более интерактивная инструментальная панель, с возможностью обучения или сортировки, то панель может передавать сообщения от пользователя соответствующим сервисом. Мы можем даже полностью поменять вызываемые сервисы так, что пользователи этого и не заметят (пока не будет меняться файл WSDL), и панель останется прежней.

Будучи профессионалом в сфере IT вы можете заниматься как разработкой интерфейса, так и сервисов, или и тем и другим. Понимание того, как всё это работает вместе (или хотя бы знание, что это такое) важно для работы в подобном проекте.

Также хорошо, что есть много инструментов, котлорые помогут вам поставлять и использовать Web-сервисы и могут сделать за вас много тяжёлой работы. В последующих частях статьи мы разберёмся, как с использованием IBM Lotus Domino V7.0 вы сможете легко поставлять Web-сервисы клиентам или системам.

Валентин Колесов
разработчик красноярского отделения санкт-петербургской компании "Астрософт", сертифицированный специалист Microsoft (MCSD, MCSE, MCDBA)
[email protected]

Демонстрация работы SOAP на примере написания Web-сервера

Что такое SOAP

Широко распространенные в настоящее время технологии удаленного вызова методов (DCOM, CORBA/IIOP и RMI) довольно сложны в настройке и организации взаимодействия. Это влечет за собой трудности в эксплуатации и функционировании распределенных систем (проблемы безопасности, неудобства транспорта через брандмауэры и т. д.). Многие проблемы удалось решить благодаря созданию SOAP (Simple Object Access Protocol, простой протокол доступа к объектам), простого протокола, основанного на XML и служащего для обмена сообщениями в распределенных средах (WWW). Протокол предназначен для создания Web-сервисов и удаленного вызова методов. SOAP можно использовать в сочетании с разными транспортными протоколами, включая HTTP, SMTP и др.

Что такое Web-сервисы

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

Для демонстрации возможностей SOAP в статье использована недавно вышедшая реализация SOAP Toolkit версии 2.0 производства Microsoft. Следует заметить, что текущая версия Toolkit заметно отличается от предыдущей (Microsoft SOAP Toolkit for Visual Studio 6.0) и от бета-версии SOAP Toolkit 2.0.

Объектная модель SOAP Toolkit предоставляет как низкоуровневые, так и высокоуровневые интерфейсы (SOAPClient, SOAPServer), скрывающие от программиста всю "внутреннюю кухню" - разбор и формирование пакетов, вызов методов и т. п. С помощью этих интерфейсов можно весьма элегантным образом использовать Web-сервисы в разрабатываемых приложениях. Объект SOAPClient выступает в роли посредника (proxy), предоставляющего интерфейс Web-сервиса и позволяющего работать с ним как с обычным COM-объектом (рис. 1).

1. Клиентское приложение создает экземпляр объекта SOAPClient.
2. SOAPClient читает файлы описания методов Web-сервиса (на языках WSDL и Web Services Meta Language, WSML). Эти файлы могут храниться и на стороне клиента.
3. Клиентское приложение, используя возможности позднего связывания методов объекта SOAPClient, вызывает метод сервиса. SOAPClient формирует пакет запроса (SOAP Envelope) и отправляет его на сервер. Можно применить любой транспортный протокол, но, как правило, используется HTTP.
4. Серверное приложение Listener (это может быть ISAPI-приложение или ASP-страница) принимает пакет, создает объект SOAPServer и передает ему пакет запроса. Помимо этого Listener обрабатывает HTTP-пакеты от клиента, отправляет клиенту пакеты с результатом работы сервиса, обрабатывает ошибки и использует функциональность SOAP-объектов.
5. SOAPServer читает описание Web-сервиса, загружает описание и пакет запроса в деревья XML DOM.
6. SOAPServer вызывает метод объекта или приложения, реализующего сервис.
7. Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServer в пакет ответа и отправляются клиенту.
8. Объект SOAPClient проводит разбор принятого пакета и возвращает клиентскому приложению результаты работы сервиса или описание возникшей ошибки.

WSDL-файл - это документ в формате XML, описывающий методы, предоставляемые Web-сервисом, а также параметры методов, их типы, названия и местонахождение сервиса Listener. Мастер SOAP Toolkit автоматически генерирует этот документ, фрагмент которого приведен ниже:

Тег Envelope должен быть корневым элементом пакета. Элемент Header не обязателен, а Body должен присутствовать и быть прямым потомком элемента Envelope. В случае ошибки выполнения метода сервер формирует пакет, содержащий в теге Body элемент Fault, который содержит подробное описание ошибки.

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

Объектная модель SOAP Toolkit дает возможность работать с объектами низкоуровневого API:

• SoapConnector - обеспечивает работу с транспортным протоколом для обмена SOAP-пакетами.
• SoapConnectorFactory - обеспечивает метод создания коннектора для транспортного протокола, указанного в WSDL-файле (тег).
• SoapReader - читает SOAP-сообщения и строит деревья XML DOM.·
• SoapSerializer - содержит методы создания SOAP-сообщения.·
• IsoapTypeMapper, SoapTypeMapperFactory - интерфейсы, позволяющие работать со сложными типами данных.

С помощью объектов высокоуровневого API можно передавать данные только простых типов (int, string, float и т. п.), но спецификация SOAP 1.1 допускает работу с более сложными типами данных, например с массивами, структурами, списками и их комбинациями. Для работы с такими типами приходится использовать интерфейсы IsoapTypeMapper и SoapTypeMapperFactory.

Пример

Чтобы продемонстрировать работу SOAP, напишем несложный Web-сервис, который будет уметь складывать и вычитать числа. Для работы серверного приложения потребуется пакет IIS 5 в среде Windows 2000 или IIS4 на Windows NT 4.0 Service Pack 6, а также установленный SOAP Toolkit 2.0.

Требования клиентского приложения - ОС Microsoft Windows 98/Me или Windows NT 4.0 Service Pack 6/2000 Service Pack 1, а также установленный SOAP Toolkit 2.0.

Создание сервера

Откройте в VB новый проект ActiveX DLL. Измените название класса на SOAPClass, а имя проекта - на SOAPProj.

В классе создайте следующие методы:

В следующем окне Мастера можно выбрать методы, которые войдут в Web-сервис. В данном случае выберите все методы. Затем укажите, где будет находиться Web-приложение (например, http://wsd010/soap/), задайте тип приложения Listener (ASP или ISAPI), выберите ASP, формат схемы (по умолчанию). Укажите путь, где будут находиться файлы описания Web-сервиса, и кодировку. После окончания работы Мастера в Web-каталоге появятся файлы ASP, WSDL и WSML - это Listener для ASP и описания сервиса (см. листинги 1-3).

Осталось только настроить права доступа к Web-приложению - желательно установить NT Challenge/Response authentication. На этом работа по созданию сервера закончена.

Создание клиента

Откройте в VB новый проект Standard EXE. В меню Project/References сделайте ссылку на библиотеку Microsoft SOAP type library. Создайте на форме кнопку, в обработчике нажатия кнопки напишите следующий код:

Dim SoapClient As New SoapClient SoapClient.mssoapinit "http://wsd010/soap/SOAPService.wsdl" MsgBox SoapClient.AddNumbers(4, 3) MsgBox SoapClient.SubtractNumbers(3, 2)

Не забудьте изменить адрес Web-сервера и путь к WSDL-файлу во второй строке на адрес и путь к вашему Web-сервису.

После создания объекта SOAPClient его надо инициализировать - указать путь к документу описания Web-сервиса. После инициализации у объекта появятся методы Web-сервиса. С ними можно работать как с обычным COM-объектом.

С помощью замечательной утилиты MsSoapT.exe (Trace Utility), входящей в Toolkit, можно просматривать в режиме реального времени пакеты, идущие от клиента к серверу и обратно. Для этого надо в WSDL-файле найти тег и вместо строки типа http://wsd010/soap/SOAPService.ASP написать http://wsd010:8080/soap/SOAPService.ASP, то есть указать порт 8080. После этого нужно запустить утилиту трассирования и принять настройки по умолчанию, а затем создать новый объект Formatted Trace. Теперь все SOAP-пакеты работы с Web-сервисом доступны для оперативного просмотра. Если трассировщик не загружен, то в нужно убрать указание порта 8080. На рис. 4 приведено содержимое пакета запроса на выполнение метода SubstractNumbers.

А пакет ответа выглядит следующим образом:

1

Так выглядит пакет сервера, пришедший в ответ на запрос некорректного формата:

SOAP-ENV:Server Connector - Bad request to the server. -2146823238 800a13ba

Дополнительная информация по теме

http://msdn.microsoft.com/webservices/ и http://msdn.microsoft.com/soap/ - последние новости о SOAP и Web-сервисах от Microsoft. Там же можно найти свежие версии ПО.

http://www.vbxml.com/soap/ - много полезной информации для разработчиков. Есть презентации и учебники по SOAP.

http://www.w3.org/TR/SOAP/ - спецификация SOAP от W3C.

http://www.w3.org/TR/wsdl - сведения о стандарте Web Services Definition Language (WSDL) 1.1/

http://microsoft.public.xml.soap - в этой конференции специалисты помогут решить сложные проблемы программирования SOAP.

Листинг 1. Код Listener для ASP <%@ LANGUAGE=VBScript %> <% Option Explicit On Error Resume Next Response.ContentType = "text/xml" Dim SoapServer If Not Application("SoapServerInitialized") Then Application.Lock If Not Application("SoapServerInitialized") Then Dim WSDLFilePath Dim WSMLFilePath WSDLFilePath = Server.MapPath("SOAPService.wsdl") WSMLFilePath = Server.MapPath("SOAPService.wsml") Set SoapServer = Server.CreateObject("MSSOAP.SoapServer") If Err Then SendFault "Cannot create SoapServer object. " & Err.Description SoapServer.Init WSDLFilePath, WSMLFilePath If Err Then SendFault "SoapServer.Init failed. " & Err.Description Set Application("SOAPServiceServer") = SoapServer Application("SoapServerInitialized") = True End If Application.UnLock End If Set SoapServer = Application("SOAPServiceServer") SoapServer.SoapInvoke Request, Response, "" If Err Then SendFault "SoapServer.SoapInvoke failed. " & Err.Description Sub SendFault(ByVal LogMessage) Dim Serializer On Error Resume Next " "URI Query" logging must be enabled for AppendToLog to work Response.AppendToLog " SOAP ERROR: " & LogMessage Set Serializer = Server.CreateObject("MSSOAP.SoapSerializer") If Err Then Response.AppendToLog "Could not create SoapSerializer object. " & Err.Description Response.Status = "500 Internal Server Error" Else Serializer.Init Response If Err Then Response.AppendToLog "SoapSerializer.Init failed. " & Err.Description Response.Status = "500 Internal Server Error" Else Serializer.startEnvelope Serializer.startBody Serializer.startFault "Server", "The request could not be processed due to a problem in the server. Please contact the system administrator. " & LogMessage Serializer.endFault Serializer.endBody Serializer.endEnvelope If Err Then Response.AppendToLog "SoapSerializer failed. " & Err.Description Response.Status = "500 Internal Server Error" End If End If End If Response.End End Sub %>

Листинг 2. Код файла WSDL

Листинг 3. Код файла WSDL

Идея веб-сервисов была разработана такими гигантами компьютерной индустрии как Sun, Oracle, HP, Microsoft и IBM. В этой идее нет ничего нового, но это большой шаг вперед к упрощенному доступу к программам через сеть. Основываясь на стандартных форматах связи, веб-сервисы могут вообще поменять наше представление о том, как мы должны делать веб-сайты.

Что такое веб-сервис?

Благодаря веб-сервисам функции любой программы могут стать доступными через Интернет. Таким образом такие программы как PHP, ASP, JSP скрипты, JavaBeans, COM-объекты и все остальные наши любимые средства программирования могут теперь обращаться к какой-нибудь программе, работающей на другом сервере (т.е. к веб-свервису), и использовать ответ, полученный от нее на своем веб-сайте, или приложении.

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

Любой, кто хоть раз работал в последнее время с Hotmail, уже отчасти столкнулся с веб-сервисами: система аутентификации пользователей Passport - это один из сервисов, входящих в инициативу Microsoft .NET. пока он доступен бесплатно, так что создатели веб-сайтов могут запросто внедрить аутентификацию пользователей на своём сайте.

Основы

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

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

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

Стандарты в основе

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

До этого многие компании разрабатывали свои собственные закрытые стандарты и форматы. А сейчас нам для работы нужно знать всего лишь простой XML (eXtensible Markup Language), который передается по старому знакомому протоколу HTTP. Это значит, что информация о работе веб-сервисов доступна для всех, и веб-разработчики, которые по роду профессии знакомы с этими технологиями, могут начать играться с веб-сервисами уже сегодня.

Разница между веб-сервисами и другими технологиями, с которыми разработчикам приходилось сталкиваться (например, DCOM, именованные каналы - named pipes, RMI) в том, что веб-сервисы основаны на открытых стандартах, ими легко овладеть, и эти стандарты широко поддерживаются на всех платформах Unix и Windows.

Протокол Simple Object Access Protocol (SOAP) является стандартным протоколом, разработанным W3C. Он определяет формат запросов к веб-сервисам.

Сообщения между веб-сервисом и его пользователем пакуются в SOAP-конверты (SOAP envelopes). Сообщения содержат либо запрос на осуществление какого-либо действия, либо ответ - результат выполнения этого действия. Конверт и его содержимое закодировано языком XML, и его достаточно просто понять. Вот как выглядит простой SOAP-запрос, который отправляется через HTPP к веб-сервису:

Xmlns:env="http://www.w3.org/2001/06/soap-envelope">

xmlns:m="http://www.somesite.com/Postcode">
WC1A8GH
UK

Ключевые элементы SOAP-конверта узнать достаточно просто: это два параметра (("почтовый индекс") и ("страна")), которые содержатся внутри элемента под названием. Этот элемент является названием веб-сервиса, к которому мы обращаемся с запросом. Прочие данные в конверте, такие как кодировка текста и версия SOAP помогают веб-сервису правильно обработать запрос.

А ответ будет выглядеть вот так:

Xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

Env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
Yes

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

Теперь об UDDI

Даже при всей простоте протокола SOAP пользы в веб-сервисах было бы немного, если бы у нас не было никакой возможности их найти. К счастью IBM, Microsoft и компания Ariba выступили с инициативой и создали проект Universal Description, Discovery and Integration (UDDI), который, как они надеются, станет общим каталогом всех веб-сервисов в Web-е.

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

Как это все работает

Так как же мне найти нужный веб-сервис?

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

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

Вместо того, чтобы раскошеливаться на покупку базы данных, писать самому код, следить за целостностью и правильностью всех данных и отлаживать работу скриптов, я просто иду в каталог UDDI и ищу, нет ли там веб-сервиса, который мог бы сделать эту работу за меня. Придя на сайт www.uddi.org, я запускаю поиск и нахожу прекрасный сервис от компании XYZ Corp.

Я внимательно рассматриваю определение формата веб-сервиса (определение записано на языке WSDL (Web Services Description Language), убеждаюсь, что сервис делает именно то, что мне нужно. Затем справляюсь у своих коллег о репутации компании XYZ Corp., узнаю, что она солидная, и затем обращаюсь к компании XYZ с вопросом о цене. Если цена на доступ к сервису доступна для моего бюджета, я пишу простую JSP-страницу для своего сайта, который вызывает веб-сервис компании XYZ Corp, и опля, на сайте появляется моментальная проверка почтового индекса.

На это стоит потратить время

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

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

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

Разработка сервиса

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

Выбор инструментов для разработки веб-сервисов обширен. В него входят инструментарии таких компании как Sun (Open Net), Microsoft (.NET), HP (e-services), и IBM (Web Services). Существуют также инструментарии с открытыми исходными кодами (open source frameworks). Например, проект Mono Project стремится заменить собой инструментарий Microsoft .NET, предоставив систему компиляции (compilers), исполнения кода (runtime) и библиотек (libraries) для работы одних и тех же веб-сервисов на всех платформах, включая Unix.

Несмотря на многообразие серверов и средств разработки веб-сервисов, все они поддерживают один и тот же протокол SOAP, язык XML и систему UDDI.

Минусы

Прежде чем я полностью откажусь от карьеры программиста и посвящу себя использованию веб-сервисов, я должен задать себе вопрос: "Уж слишком розовая картинка. Что в ней не так?". К сожалению, за великий потенциал веб-сервисов приходится платить определенную цену:

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

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

Перевод: Александр Качанов (http://webmascon.com)

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

FTP (File Transfer Protocol)

FTP (англ. File Transfer Protocol — протокол передачи файлов) — стандартный протокол, предназначенный для передачи файлов по TCP-сетям (например, Интернет). FTP часто используется для загрузки сетевых страниц и других документов с частного устройства разработки на открытые сервера хостинга.

SSH (Secure Shell)

SSH (англ. Secure SHell — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов). Схож по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли. SSH допускает выбор различных алгоритмов шифрования. SSH-клиенты и SSH-серверы доступны для большинства сетевых операционных систем.

TELNET (англ. TErminaL NETwork) — сетевой протокол для реализации текстового интерфейса по сети (в современной форме — при помощи транспорта TCP). Название «telnet» имеют также некоторые утилиты, реализующие клиентскую часть протокола.

SMTP (Send Mail Transfer Protocol)

SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) — это широко используемый сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.

DNS (Domain Name Service)

DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).

DHCP (Dynamic Host Control Protocol)

DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической конфигурации узла) — это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к так называемому серверу DHCP, и получает от него нужные параметры. Сетевой администратор может задать диапазон адресов, распределяемых сервером среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. Протокол DHCP используется в большинстве сетей TCP/IP.

HTTP (HyperText Transfer Protocol)

HTTP (англ. HyperText Transfer Prоtocоl — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

POP3 (Post Office Protocol, version 3)

POP3 (англ. Post Office Protocol Version 3 — протокол почтового отделения, версия 3) — стандартный Интернет-протокол прикладного уровня, используемый клиентами электронной почты для извлечения электронного сообщения с удаленного сервера по TCP/IP-соединению.

SFTP (Secure File Transfer Protocol)

SFTP (англ. SSH File Transfer Protocol) — протокол прикладного уровня, предназначенный для копирования и выполнения других операций с файлами поверх надёжного и безопасного соединения. Протокол разработан группой IETF как расширение к SSH-2, однако SFTP допускает реализацию и с использованием иных протоколов сеансового уровня.

NNTP (Network New Transfer Protocol)

NNTP (англ. Network News Transfer Protocol) — представляет собой сетевой протокол, распространения, запрашивания, размещения и получения групп новостей при взаимодействии между сервером групп новостей и клиентом.

NTP (Network Time Protocol)

Network Time Protocol (NTP) — сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной латентностью.

NetBIOS (Network Basic Input/Output System) — протокол для работы в локальных сетях на персональных ЭВМ типа IBM/PC, разработан в виде интерфейса, который не зависит от фирмы-производителя. Был разработан фирмой Sytek Corporation по заказу IBM в 1983 году. Он включает в себя интерфейс сеансового уровня (англ. NetBIOS interface), в качестве транспортных протоколов использует TCP и UDP.

IMAP (Internet Message Access Protocol)

IMAP (англ. Internet Message Access Protocol) — протокол прикладного уровня для доступа к электронной почте.

SNMP (Simple Network Management Protocol)

SNMP (англ. Simple Network Management Protocol — простой протокол сетевого управления) — стандартный интернет-протокол для управления устройствами в IP-сетях на основе архитектур UDP/TCP. К поддерживающим SNMP устройствам относятся маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры, модемные стойки и другие. Протокол обычно используется в системах сетевого управления для контроля подключенных к сети устройств на предмет условий, которые требуют внимания администратора. SNMP определен Инженерным советом интернета (IETF) как компонент TCP/IP. Он состоит из набора стандартов для сетевого управления, включая протокол прикладного уровня, схему баз данных и набор объектов данных.

LDAP (Lightweight Directory Access Protocol)

LDAP (англ. Lightweight Directory Access Protocol — «облегчённый протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции авторизации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей.

SSL (Secure Socket Layer)

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

NFS (Network File System)

Network File System (NFS) — протокол сетевого доступа к файловым системам, первоначально разработан Sun Microsystems в 1984 году. Основан на протоколе вызова удалённых процедур. Позволяет подключать (монтировать) удалённые файловые системы через сеть.

MySQL — свободная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems, которая ранее приобрела шведскую компанию MySQL AB. Продукт распространяется как под GNU General Public License, так и под собственной коммерческой лицензией. Помимо этого разработчики создают функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

Virtual Network Computing (VNC) — система удалённого доступа к рабочему столу компьютера, использующая протокол RFB (англ. Remote FrameBuffer, удалённый кадровый буфер). Управление осуществляется путём передачи нажатий клавиш на клавиатуре и движений мыши с одного компьютера на другой и ретрансляции содержимого экрана через компьютерную сеть.