Системное администрирование – то, с чем мы часто сталкиваемся, но не всегда знаем, что с этим делать. Давайте разберемся с основами СА.

Урок 1 – Немного о железе

В первом уроке не просто ознакомительный материал, а настоящее развернутое введение. Автор объяснит, кто такой системный администратор , что входит в его обязанности и каков его карьерный рост. Грубо говоря, раскладывается системное администрирование. Но это не все. В уроке также затрагивается железо: оперативная память, платы, жесткие диски, RAID, процессоры и многоядерность. Видеоуроки продолжительные, поэтому не беспокойтесь: будет не только сухая терминология, но и вполне удобоваримые объяснения.

Урок 2 – Виртуализация

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

Урок 3 – Системное администрирование и основы сети

Стоит отдать должное автору: если он оговаривается, то обязательно указывает на ошибку в описании к видео. Это можно наблюдать под третьим видеоуроком. В остальном все подробно и понятно. Представлена модель OSI и разобраны все уровни. Объясняются стек TCP/IP, хабы, роутеры, рассказывается об IP-адресе, маске, шлюзе и выделении адреса подсети. Также есть таблица коммутации, и по-прежнему схемы дополняются устными и визуальными объяснениями автора.

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

Урок 4 – Сетевые сервисы

Углубление в сети и соответствующие сервисы. Объясняется выдача IP-адресов, демонстрируются DHCP, APIPA, схематически раскладывается Firewall, преобразование сетевых адресов (Network Address Translation или NAT) и разрешение имен (DNS, NETBIOS, etc). Полезно то, что в уроке звучит не только «можно», но и «что если»: создаются различные теоретические ситуации и связанные с ними ошибки, ограничения, объясняется, как этого избежать.

Урок 5 – Жесткий диск изнутри

Да, можно сказать, что такие нюансы программисту не нужны. Но давайте посмотрим на это иначе: если мы понимаем принцип работы нашего железа, нам легче понять и правила взаимодействия с ним. Теперь в схемах представлены не только таблицы и взаимосвязи, но и сама архитектура жесткого диска, его составляющие. Из пятого видеоурока вы узнаете о адресации на дисках, кластере файловой системы, разметках MBR и GPT, а также о типах дисков, которые используются в «Винде» (обычные, динамические). При этом все будет продемонстрировано через соответствующие панели и диспетчеры.

Урок 6 – RNAT, привязки веб-сайтов

Это микроурок между четвертым и пятым. В нем автор отвечает на 2 вопроса:

1. Что такое трансляция?
2. Как несколько web-сайтов может размещаться на одном IP-адресе?

Обязательно посмотрите, если не знаете ответов.

Урок 7 – Подключение хранилищ

Еще один микроурок, который следует за пятым. Здесь тоже ответы на вопросы. Рассказывается об интерфейсах и протоколах для подключения дисков (SATA, SAS, PATA (IDE), и т. д.).

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

И еще одно предварительное замечание, которое поможет вам легче понять и освоить принципы администрирования Linux: любые настройки этой ОС могут быть выполнены путем редактирования файлов сценариев (или скриптов) и конфигурационных файлов, которые читаются скриптами. Причем и те, и другие (т. е. и скрипты, и конфигурационные файлы) являются простыми текстовыми файлами. Конечно, в Linux существуют различные специальные утилиты конфигурирования и администрирования системы (типа linuxconf или printtool), однако результаты работы этих программ все равно записываются в тех же конфигурационных файлах. Образно выражаясь, про Linux (и UNIX вообще) можно сказать "это почти целиком обработчик текста". Если с самого начала помнить об этой особенности, можно значительно легче освоить вопросы системного администрирования Linux.

Кстати, если вы хотите облегчить себе работу по редактированию конфигурационных файлов, сразу после инсталляции ОС Linux установите программу Midnight Commander. Это существенно облегчит вам поиск и редактирование конфигурационных файлов, так как можно будет пользоваться встроенным редактором этой программы (не говоря уж о том, что поиск нужного файла тоже сильно облегчается).

Основные задачи системного администрирования. Процессы и их идентификаторы

К обязанностям системного администратора обычно относят следующие задачи:

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

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

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

В самом первом приближении можно считать, что процесс - это загруженная в оперативную память программа . Но это не совсем точно, правильнее было бы сказать, что "процесс выполняет программу". Дело в том, что в Linux вначале запускается процесс, который загружает в оперативную память программу из указанного ему файла и начинает ее выполнять. Это означает, что каждый процесс должен быть запущен (как говорят - "порожден") каким-то другим процессом. То есть для каждого процесса однозначно определен его "родитель" (или "предок"), для которого данный процесс является "дочерним" (или "потомком"). Если вы хотите увидеть " дерево " запущенных в вашей системе процессов, выполните команду pstree . Вывод этой команды позволяет увидеть, что "отцом" всех процессов в системе (или " корнем дерева процессов") является процесс init , который первым запускается после загрузки ядра.

Каждый процесс в системе имеет уникальный идентификатор - PID , назначаемый процессу при запуске. Процесс с идентификатором 1 выполняет программу init . Именно по этим идентификаторам система различает процессы. Каждый запущенный процесс в любой момент времени находится в одном из следующих состояний: активен (R), приостановлен (T) или "спит" (S). Текущее состояние процесса называют статусом процесса.

Кроме идентификатора и статуса для каждого процесса в специальных структурах ядра сохраняются следующие данные (приводимый ниже перечень является далеко не полным):

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

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

Пользователи могут "общаться" с процессами путем посылки им сигналов. Процессы тоже общаются друг с другом посредством сигналов. Когда мы нажимаем комбинацию клавиш +, чтобы завершить выполнение какой-то программы, мы фактически посылаем соответствующему процессу сигнал "Завершить работу". Завершаясь, процесс посылает родительскому процессу сигнал о своем завершении. Но бывают случаи, когда родительский процесс завершается раньше дочернего. Процессы, не имеющие родителя, называются "сиротами". "Сироты" автоматически усыновляются процессом init , который и принимает сигналы об их завершении. Если процесс-родитель по каким-то причинам не может принять сигнал о завершении дочернего процесса, то процесс- потомок превращается в "зомби" и получает статус Z. Процессы-зомби не занимают процессорного времени (т. е. их выполнение прекращается), но соответствующие им структуры ядра не освобождаются. Уничтожение таких процессов - одна из обязанностей системного администратора. Наконец, процесс может надолго "впасть в сон", прервать который не удается. Статус таких процессов обозначается символом D. Уничтожить их удается только при перезагрузке системы.

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

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

Приведенных данных о процессах нам пока достаточно (к рассмотрению процессов мы еще вернемся позже).

Элементы расширения связывания используются для указания конкретной грамматики для входящих (3) и исходящих (4) сообщений, сообщений об ошибках (5). Также может указываться информация уровня операции (2) и уровня связывания (1).

Элемент связывания operation содержит данные для одноимённой операции связанного типа порта. Однако имя операции в общем случае не является уникальным (пример: перегрузка методов / функций — использование одинаковых имён с различными сигнатурами), потому его может быть недостаточно для однозначного определения целевой операции типа порта. В таких случаях целевая операция адресуется с помощью дополнительного задания соответствующих имён элементов wsdl:input и wsdl:output с помощью атрибута name .

Связывание должно устанавливать только один протокол.

Связывание не должно содержать информации об адресе.

Порт

Порт определяет отдельную конечную точку посредством установки адреса для связывания.

1. <wsdl :definitions .... >
2. <wsdl :service .... > *
3. <wsdl :port name = "nmtoken" binding = "qname" > *
4. <-- extensibility element (1) -->
5. wsdl :port >
6. wsdl :service >
7. wsdl :definitions >

Атрибут name задаёт уникальное имя среди всех портов в рамках WSDL-документа. Атрибут binding типа QName содержит ссылку на связывание (см.).

Элементы расширения (1) используются для задания адреса.

Порт не должен задавать более одного адреса.

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

Служба

Служба объединяет вместе набор связанных портов.

1. <wsdl :definitions .... >
2. <wsdl :service name = "nmtoken" > *
3. <wsdl :port .... /> *
4. wsdl :service >
5. wsdl :definitions >

Атрибут name задаёт уникальное имя среди всех служб, определённых в рамках WSDL-документа.

Порты внутри службы связаны следующим образом:

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

1. Это вольный, частичный, дополненный перевод документа Web Services Description Language (WSDL) 1.1 от 15 Марта 2001
2. Несклоняемыми написанными латиницей терминами оперировать крайне неудобно, к тому же они однозначно переводятся. Поэтому исходное имя даётся только при введении нового термина, а далее по тексту используется русский перевод.

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

Введение

Начать надо с того, для чего создавалась концепция веб-сервисов. К моменту появления этого понятия в мире уже существовали технологии, позволяющие приложениям взаимодействовать на расстоянии, где одна программа могла вызвать какой-нибудь метод в другой программе, которая при этом могла быть запущена на компьютере, расположенном в другом городе или даже стране. Все этого сокращенно называется RPC (Remote Procedure Calling – удаленный вызов процедур). В качестве примеров можно привести технологии CORBA, а для Java – RMI (Remote Method Invoking – удаленный вызов методов). И все вроде в них хорошо, особенно в CORBA, т.к. с ней можно работать на любом языке программирования, но чего-то все же не хватало. Полагаю, что минусом CORBA является то, что она работает через какие-то свои сетевые протоколы вместо простого HTTP, который пролезет через любой firewall. Идея веб-сервиса заключалась в создании такого RPC, который будет засовываться в HTTP пакеты. Так началась разработка стандарта. Какие у этого стандарта базовые понятия:

1. SOAP . Прежде чем вызвать удаленную процедуру, нужно этот вызов описать в XML файле формата SOAP. SOAP – это просто одна из многочисленных XML разметок, которая используется в веб-сервисах. Все, что мы хотим куда-то отправить через HTTP, сначала превращается в XML описание SOAP, потом засовывается в HTTP пакет и посылается на другой компьютер в сети по TCP/IP.
2. WSDL . Есть веб-сервис, т.е. программа, методы которой можно удаленно вызывать. Но стандарт требует, чтобы к этой программе прилагалось описание, в котором сказано, что «да, вы не ошиблись – это действительно веб-сервис и можно у него вызвать такие-то такие-то методы». Такое описание представляется еще одним файлом XML, который имеет другой формат, а именно WSDL. Т.е. WSDL – это просто XML файл описания веб-сервиса и больше ничего.

Почему так кратко спросите вы? А по подробней нельзя? Наверное можно, но для этого придется обратиться к таким книгам как Машнин Т. «Web-сервисы Java». Там на протяжении первых 200 страниц идет подробнейшее описание каждого тега стандартов SOAP и WSDL. Стоит ли это делать? На мой взгляд нет, т.к. все это на Java создается автоматически, а вам нужно лишь написать содержимое методов, которые предполагается удалено вызывать. Так вот, в Java появился такой API, как JAX-RPC. Если кто не знает, когда говорят, что в Java есть такой-то API, это означает, что есть пакет с набором классов, которые инкапсулируют рассматриваемую технологию. JAX-RPC долго развивался от версии к версии и в конечном итоге превратился в JAX-WS. WS, очевидно, означает WebService и можно подумать, что это простое переименование RPC в популярное нынче словечко. Это не так, т.к. теперь веб-сервисы отошли от первоначальной задумки и позволяют не просто вызывать удаленные методы, но и просто посылать сообщения-документы в формате SOAP. Зачем это нужно я пока не знаю, вряд ли ответ здесь будет «на всякий случай, вдруг понадобится». Сам бы хотел узнать от более опытных товарищей. Ну и последнее, далее появился еще JAX-RS для так называемых RESTful веб-сервисов, но это тема отдельной статьи. На этом введение можно заканчивать, т.к. далее мы будем учиться работать с JAX-WS.

Общий подход

В веб-сервисах всегда есть клиент и сервер. Сервер – это и есть наш веб-сервис и иногда его называют endpoint (типа как, конечная точка, куда доходят SOAP сообщения от клиента). Нам нужно сделать следующее:

1. Описать интерфейс нашего веб-сервиса
2. Реализовать этот интерфейс
3. Запустить наш веб-сервис
4. Написать клиента и удаленно вызвать нужный метод веб-сервиса

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

Сервер

Запустим IDEA и создадим новый проект Create New Project . Укажем имя HelloWebService и нажмем кнопку Next , далее кнопку Finish . В папке src создадим пакет ru.javarush.ws . В этом пакете создадим интерфейс HelloWebService: package ru. javarush. ws; // это аннотации, т.е. способ отметить наши классы и методы, // как связанные с веб-сервисной технологией import javax. jws. WebMethod; import javax. jws. WebService; import javax. jws. soap. SOAPBinding; // говорим, что наш интерфейс будет работать как веб-сервис @WebService // говорим, что веб-сервис будет использоваться для вызова методов @SOAPBinding (style = SOAPBinding. Style. RPC) public interface HelloWebService { // говорим, что этот метод можно вызывать удаленно @WebMethod public String getHelloString (String name) ; } В этом коде классы WebService и WebMethod являются так называемыми аннотациям и ничего не делают, кроме как помечают наш интерфейс и его метод, как веб-сервис. Это же относится и к классу SOAPBinding . Разница лишь в том, что SOAPBinding – это аннотация с параметрами. В данном случае используется параметр style со значением, говорящим, что веб-сервис будет работать не через сообщения-документы, а как классический RPC, т.е. для вызова метода. Давайте реализуем логику нашего интерфейса и создадим в нашем пакете класс HelloWebServiceImpl . Кстати, замечу, что окончание класса на Impl – это соглашение в Java, по которому так обозначают реализацию интерфейсов (Impl – от слова implementation, т.е. реализация). Это не требование и вы вольны назвать класс как хотите, но правила хорошего тона того требуют: package ru. javarush. ws; // таже аннотация, что и при описании интерфейса, import javax. jws. WebService; // но здесь используется с параметром endpointInterface, // указывающим полное имя класса интерфейса нашего веб-сервиса @WebService (endpointInterface = "ru.javarush.ws.HelloWebService" ) public class HelloWebServiceImpl implements HelloWebService { @Override public String getHelloString (String name) { // просто возвращаем приветствие return "Hello, " + name + "!" ; } } Запустим наш веб-сервис как самостоятельный сервер, т.е. без участия всяких Tomcat и серверов приложений (это тема отдельного разговора). Для этого в структуре проекта в папке src создадим пакет ru.javarush.endpoint , а в нем создадим класс HelloWebServicePublisher с методом main: package ru. javarush. endpoint; // класс, для запуска веб-сервера с веб-сервисами import javax. xml. ws. Endpoint; // класс нашего веб-сервиса import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher { public static void main (String. . . args) { // запускаем веб-сервер на порту 1986 // и по адресу, указанному в первом аргументе, // запускаем веб-сервис, передаваемый во втором аргументе Endpoint. publish ("http://localhost:1986/wss/hello" , new HelloWebServiceImpl () ) ; } } Теперь запустим этот класс, нажав Shift+F10 . В консоли ничего не появится, но сервер запущен. В этом можно убедиться набрав в браузере строку http://localhost:1986/wss/hello?wsdl . Открывшаяся страница, с одной стороны, доказывает, что у нас на компьютере (localhost) запустился веб-сервер (http://) на порту 1986, а, с другой стороны, показывает WSDL описание нашего веб-сервиса. Если вы остановите приложение, то описание станет недоступно, как и сам веб-сервис, поэтому делать этого не будем, а перейдем к написанию клиента.

Клиент

В папке проекта src создадим пакет ru.javarush.client , а в нем класс HelloWebServiceClient с методом main: package ru. javarush. client; // нужно, чтобы получить wsdl описание и через него // дотянуться до самого веб-сервиса import java. net. URL; // такой эксепшн возникнет при работе с объектом URL import java. net. MalformedURLException; // классы, чтобы пропарсить xml-ку c wsdl описанием // и дотянуться до тега service в нем import javax. xml. namespace. QName; import javax. xml. ws. Service; // интерфейс нашего веб-сервиса (нам больше и нужно) import ru. javarush. ws. HelloWebService; public class HelloWebServiceClient { public static void main (String args) throws MalformedURLException { // создаем ссылку на wsdl описание URL url = new URL ("http://localhost:1986/wss/hello?wsdl" ) ; // Параметры следующего конструктора смотрим в самом первом теге WSDL описания - definitions // 1-ый аргумент смотрим в атрибуте targetNamespace // 2-ой аргумент смотрим в атрибуте name QName qname = new QName ("http://ws.сайт/" , "HelloWebServiceImplService" ) ; // Теперь мы можем дотянуться до тега service в wsdl описании, Service service = Service. create (url, qname) ; // а далее и до вложенного в него тега port, чтобы // получить ссылку на удаленный от нас объект веб-сервиса HelloWebService hello = service. getPort (HelloWebService. class ) ; // Ура! Теперь можно вызывать удаленный метод System. out. println (hello. getHelloString ("JavaRush" ) ) ; } } Максимум комментариев по коду я дал в листинге. Добавить мне нечего, поэтому запускаем (Shift+F10). Мы должны в консоли увидеть текст: Hello, JavaRush! Если не увидели, то видимо забыли запустить веб-сервис.

Заключение

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

Страница 2 из 3

Описание с помощью WSDL

SOAP работает очень хорошо, если о Web-службе все известно. Однако это не всегда так. Средством описания интерфейса для доступа к Web-службе является язык WSDL (Web Services Description Language - язык описания Web-служб). Этот стандарт совместно разработан компаниями IBM, Microsoft и webMethods. У каждой из этих трех компаний был собственный подход к разработке стандарта для описания Web-служб: IBM создала NASSL, Microsoft разработала SCL, а компания webMethods придумала WIDL.

Результатом их сотрудничества стала версия 1.1 языка WSDL, По поводу W3C следует отметить, что так же как и с SOAP, консорциум W3C на основе версии 1.1 разработал версию WSDL 1.2, которая теперь является рекомендацией W3C. WSDL-описание Web-службы содержит всю необходимую для использования этой службы информацию, включая доступные методы и их параметры. Эта информация содержится в следующих пяти элементах:

• - поддерживаемые протоколы.
• - сообщения Web-службы (запрос, ответ).
• Все доступные методы.
• - URI службы.
• - используемые типы данных.

Вся эта информация хранится в корневом элементе WSDL-описания , В листинге ниже представлен пример WSDL-описания Web-службы.

WSDL-описание Web-службы

Да уж... без стаканА не разберёшся, а ведь это один из самых простеньких(!) WSDL файлов. К сожалению, один из недостатков SOAP-расширения для РНР 5 связан с тем, что в отличие от других реализаций SOAP, оно не позволяет создавать WSDL-описания автоматически (во всяком случае, пока что). Наверняка этот недостаток исправят в будущих версиях РНР.

Кстати!

Для автоматического создания WSDL-описания вы можете использовать альтернативные реализации протокола SOAP в РНР:

Поиск в справочнике с помощью UDDI

Теперь, после того как мы знаем, как получать информацию о Web-службе и как ее запрашивать, нужно научиться находить такую службу. Для этой цели существует нечто похожее на "Желтые страницы", а именно - реестры UBR (Universal Business Registries - универсальные бизнес-реестры) - справочники Web-служб.

Существует несколько таких реестров, среди которых реестры компаний IBM, Microsoft, NTT-Com и SAP. Эти реестры синхронизируют свои данные, поэтому можно пользоваться любым из них. Текущей версией стандарта UDDI является версия UDDI 3.0, хотя большинство реализаций используют версию 2. Среди разработчиков этого стандарта такие компании-гиганты, как HP, Intel, Microsoft и Sun.

Для взаимодействия с UBR существует два типа API-интерфейсов: Inquiry API и Publish API . Интерфейс Inquiry API (Запрос) предназначен для запроса служб в реестрах UBR, а интерфейс Publish API (Публикация) позволяет разработчикам регистрировать свои службы . Похоже, что заполнение содержимого реестров спамом - это только вопрос времени:)

Кстати!

Существуют тестовые реестры, предназначенные для тестирования регистрации служб перед их размещением в "настоящих" реестрах.

Так выглядит запрос Web-службы:

sortByNameAsc sortByDateDesc %guid%

В примере выше видно, что UDDI-запрос инкапсулирован в SOAP-сообщение, поэтому выглядит он довольно знакомым. Ответом на запрос является также SOAP-документ, показанный ниже:

Web Services Guided Tour Sample Web services for Guided Tourbook Guided Tour StockQuote Service

Установка

Установить SOAP-расширение для PHP5 довольно легко. В Windows этот модуль находится в подкаталоге ext каталога установки РНР. Для его использования необходимо в файл php.ini добавить следующую строку: extension=php_soap.dll Для работы этому модулю требуется, которая включена в РНР 5 по умолчанию, по крайней мере, в Windows-версии.