Wsdl описание веб сервиса vbs построение запроса. В чем разница между XSD и WSDL

Модули памяти характеризуются такими параметрами, как объем (16, 32, 64, 128, 256 или 512 Мбайт), число микросхем, паспортная частота (100 или 133 МГц), время доступа к данным (6 или 7 нс) и число контактов (72, 168 или 184).

Модули DIP. Микросхемы DRAM упаковываются в так называемый DIP-корпус, при этом DIP обозначает Dual In-line Package (корпус с двухрядным расположением выводов). Этот термин относится к корпусам памяти, у которых выводы (Pins) расположены по бокам (напоминают жука) - рис. 3.48, а. Сам кристалл, на котором размещены ячейки памяти, существенно меньше, чем корпус. Данная конструкция корпуса обусловлена такими требованиями, как удобство печатного монтажа и установки микросхемы в панельки на системной плате, а также соблюдение температурного режима работы элементов.

Большинство модулей DIP имеют интервалы между выводами в ряду 2,54 мм (0,1"), а расстояние между рядами - 7,62 мм (0,3" - «Skinny DIP», «Тощий DIP») или 15,24 мм (0,6"). Типичное число контактов равно 8 или любому другому четному числу от 14 до 24 (реже -28) для корпусов на 0,3" и 24, 28, 32 или 40 (реже 36, 48 или 52) для корпусов на 0,6". На территории бывшего СССР используются аналогичные корпуса, но с размерами, выдержанными в метрической системе мер (например, интервал выводов 2,5 мм вместо 2,54 мм/0, Г).

Известны различные варианты корпусов DIP, в основном различающиеся материалом изготовления:

• керамические (Ceramic Dual In-line Package - CERDIP);
• пластмассовые (Plastic Dual In-line Package - PDIP);
• пластмассовые уплотненные (Shrink Plastic Dual In-line Package - SPDIP) - уплотненная версия PDIP с интервалом выводов 1,778 мм (0,07").

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

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

Например, для микросхем фирмы Mostek первые две буквы МК являются обозначением фирмы, МКВ означает, что данная микросхема фирмы Mostek отбракована согласно военному стандарту (MIL STD-833), a MKI - что микросхема прошла отбраковку в соответствии с промышленным диапазоном температур. Цифра 4 говорит о том, что микросхема является элементом DRAM. Следующая за ней цифра обозначает количество инфор-

Рис. 3.48. Внешний вид модулей памяти: а - корпус DIP-14; б - модуль SIP; в - модуль ZIP; г - разъем ZIP; д - SIMM на 72 контакта; е -DDR2 (1 Гбайт, 533 МГц) с радиатором (184 контакта и один ключ); ж - DDR SO-DIMM (РС2700, 200 контактов); з - RDRAM-модуль со

встроенным радиатором

мационных разрядов: 1 - один разряд, 4 - четыре разряда. Группа цифр, следующая далее, обозначает количество информационных разрядов в килобитах (64 - 64 Кбит, 256 - 256 Кбит, 1000 - 1 Мбит). Далее буквой указывается тип корпуса (например, Р - пластмассовый, хотя тип может быть и не указан). Через дефис указывается время доступа в наносекундах. Таким образом, по обозначению МКВ44256-70 можно легко определить, что это микросхема фирмы Mostek, прошедшая отбраковку согласно военному стандарту, имеет емкость 4-го разряда по 256 Кбит каждый и время доступа 70 нс.

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

Технология, реализующая такую конструкцию элементов памяти, называется SMT (Surface Mounting Technology), дословно переводимая как «технология поверхностного монтажа». Благодаря ей совместимые элементы DRAM были установлены на одной плате, что, в первую очередь, означало экономию места.

В качестве реализации технологии SMT можно назвать так называемые SIP-модули с однорядным расположением выводов (Single In-line Package - SIP). SIP-модули представляют собой небольшую плату с установленными на ней совместимыми чипами DRAM (см. рис. 3.48). Такая плата имеет 30 выводов, размеры ее в длину около 8 см и в высоту около 1,7 см.

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

ZIP (Zig-zag In-line Package) - недолго просуществовавшая технология интегральных схем, в частности, чипов DRAM. Она была разработана для замены DIP. Интегральная схема ZIP заключается в пластиковый корпус, обычно размером 3 х 30 х 10 мм. Выводы устройства расположены в 2 ряда на одной из сторон корпуса. Эти ряды находятся на расстоянии 1,27 мм (0,05") друг от друга в шахматном порядке, что дает возможность их более компактного размещения, чем обычная прямоугольная решетка (рис. 3.48, в, г). Корпуса схем при этом могут располагаться на плате более плотно, нежели чем при схемотехнике DIP, при том же размере. ZIP были в дальнейшем вытеснены такими конфигурациями, как TSOP (thin small-outline packages), используемых в SIMM (single-in-line memory modules) и DIMM (dual-in-line memory modules).

SIMM-модули. Когда речь идет о SIMM-модуле, имеют в виду плату, которая по своим размерам примерно соответствует SIP-модулю. Различие, прежде всего, состоит в конструкции контактов. В отличие от SIP-модуля выводы для SIMM-модуля заменены так называемыми контактами типа PAD (вилка). Эти контакты выполнены печатным способом и находятся на одном краю платы. Именно этим краем SIMM-модули устанавливаются в специальные слоты на системной плате (рис. 3.48, d). Благодаря такой конструкции SIMM-модулей существенно повышается надежность электрического контакта в разъеме и механическая прочность модуля в целом, тем более что все контакты изготовлены из высококачественного материала и позолочены.

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

Кроме того, удобная конструкция SIMM-модулей позволяет пользователям самостоятельно менять и добавлять элементы памяти, не опасаясь повредить выводы.

SIMM-модули являются стандартом в современных вычислительных системах. SIMM-модули, оснащенные DRAM 41256, сегодня применяются относительно редко. Чаще SIMM-модули оборудованы микросхемами памяти общей емкостью 8, 16 и 32 Мбит. В дальнейшем на рынке появились SIMM-модули, имеющие емкость 120 Мбит и более.

В PC с CPU 80386 и ранних моделях с CPU 80486 использовались 30-контактные SIMM-модули памяти (DRAM), и число слотов на системной плате колебалось от 4 до 8. В настоящее время найти в продаже подобные модули весьма не просто. В более поздних моделях PC с CPU 80486 и Pentium стали использоваться 72-контактные SIMM-модули памяти (FPM DRAM).

DIMM-модули. В дальнейшем на многих системных платах появились слоты для 168-контактных модулей памяти DIMM (Dual In-line Memory Module). Модули DIMM обладают внутренней архитектурой, схожей с 72-контактными SIMM-модулями, но благодаря более широкой шине обеспечивают повышенную производительность подсистемы «CPU-RAM».

Для правильного позиционирования DIMM-модулей при установке в слоты на системной плате в их конструкции предусмотрены два ключа:

• первый ключ расположен между контактами 10 и 11 и служит для определения типа памяти модуля (FPM DRAM или SDRAM);
• второй ключ расположен между контактами 40 и 41 и служит для определения напряжения питания модуля (5 или 3,3 В).

DIMM-модули поддерживают, например, материнские платы на Chipset 82430VX, 82440FX, 83450KX/GX, 82430ТХ.

SO-DIMM (Small Outline Dual In-Line Memory Module) представляет собой тип интегральных схем оперативной памяти компьютера (рис. 3.48, ж).

SO-DIMM является малогабаритной альтернативой для DIMM и обычно занимают около половины пространства, требуемого для обычных модулей DIMM. В результате SO-DIMM в основном используются в таких устройствах, как ноутбуки, небольшие настольные ПК (с платами типа Mini-ITX), высококачественные принтеры и сетевое оборудование (например, маршрутизаторы).

Модули SO-DIMM могут иметь 72, 100, 144 или 200 контактов, поддерживая передачу данных, соответственно, по 32 бита (100) и 64 бита (144 и 200). Обычные DIMM имеют по 168, 184 или 240 и все поддерживают 64-битовую передачу данных.

Различные типы SO-DIMM распознаются по размещению «ключей» - модули на 100 контактов имеют два ключа, 144-контактный SO-DIMM имеет один ключ близко к центру корпуса, 200-контактный SO-DIMM - один ключ ближе к краю корпуса.

SO-DIMM примерно соответствуют (или меньше чем) по мощности DIMM, и обе технологии SO-DIMM и DIMM обеспечивают примерно равные скорости (тактовая частота, например, 400 МГц для РС3200 и латентность CAS величиной 2,0, 2,5 и 3,0) и емкость (512 Мбайт, 1 Гбайт и пр.). Более современные модули DDR2 SO-DIMM имеют частоту до 800 МГц РС6400 и предполагается, что достигнут частоты 1066 МГц РС8500.

RIMM. С появлением Direct RDRAM (DRDRAM) в 1999 г. появляется модуль RIMM (рис. 3.49) (название - не акроним, а торговая марка Rambus Inc). Разъемы RIMM имеют типоразмеры, подобные DIMM, и могут устанавливаться в пределах той же

Рис. 3.49.

самой области системной платы, как и DIMM. Они имеют 184 штырька по сравнению с 168 для DIMM, но используют ту же спецификацию гнезда, как и стандарт DIMM на 100 МГц. BIOS ПК способен определить, какая оперативная память установлена, так что SDRAM-модули на 100 МГц должны работать в RIMM-совместимой системе. Существуют также компактные модели памяти SO-RIMM, аналогичные SO-DIMM.

Главные элементы к подсистеме памяти Rambus включают основное устройство, которое содержит Rambus ASIC Cell (RAC) и контроллер памяти (Rambus Memory Controller RMC), тактовый генератор (Direct Rambus Clock Generator DRCG), разъемы RIMM, модули памяти RIММ и модули непрерывности RIMM, а также подсистему «последовательное устройство обнаружения присутствия» (Serial Presence Detect SPD ROM).

В конечном итоге, технологии DDR, развиваясь и становясь все дешевле, практически вытеснили RDRAM - в интервале 2002-2005 гг. рыночная доля RDRAM не превышала 5 %.

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

Архитектура Fully Buffered DIMM предусматривает промежуточный буфер (Advanced Memory Buffer - AM В), устанавливаемый между контроллером и модулем памяти (рис. 3.50). В отличие от параллельной шинной архитектуры для традиционных

Разъем DDR2 с уникальным ключом

До 8 модулей DIMM

«Южный путь» (10 бит)

Контроллер

Рис. 3.50. Архитектура памяти FB-DIMM

DRAM, FB-DIMM имеет последовательный интерфейс между контроллером и AM В. Это позволяет повысить разрядность памяти без увеличения количества линий контроллера памяти.

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

Существует стандарт (протокол JESD82-20), определяющий интерфейс АМВ с памятью DDR2. Канал FB-DIMM состоит из 14 битовых линий «Северного пути» («northbound»), по которым данные передаются из памяти на процессор, и 10 линий «Южного пути» («southbound»), передающих команды и данные из процессора.

Каждый бит передается на частоте, в 12 раз большей, чем базовая частота памяти (в 6 раз, если используется удвоенная скорость, DDR - DDR3). Например, для чипа DDR2-667 DRAM канал будет работать на частоте 667 х 12/2 =4000 МГц. Каждые 12 циклов образуют кадр: 168 бит «Северного пути» (144 бита данных, передаваемых 72-битовой DDR SDRAM плюс 24 бита для CRC-коррекции) и 120 бит «Южного» (98 полезных бит и 22 CRC-бита). Из 98 бит здесь 2 задают тип кадра, 24 - команда; в оставшихся битах могут содержаться (в зависимости от типа кадра) либо 72 бита записываемых данных, либо две или более 24-битовых команд, либо одна команда или более плюс 36 бит записываемых данных.

Поскольку записываемые данные подаются медленнее, чем это необходимо для ОП DDR, они накапливаются в AM В, а затем записываются в одном пакете (обычно по четыре кадра данных).

Команды соответствуют стандартным циклам доступа DRAM, например, выбор строки (/RAS), предвыборка, регенерация и пр. Команды чтения и записи содержат только адреса столбцов (/CAS) массива памяти. Все команды содержат 3-разрядные адреса FB-DIMM, что позволяет подключать до 8 модулей FB-DIMM на 1 канал.

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

Введение

Начать надо с того, для чего создавалась концепция веб-сервисов. К моменту появления этого понятия в мире уже существовали технологии, позволяющие приложениям взаимодействовать на расстоянии, где одна программа могла вызвать какой-нибудь метод в другой программе, которая при этом могла быть запущена на компьютере, расположенном в другом городе или даже стране. Все этого сокращенно называется 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.javarush.ru/" , "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.

WSDL (Web Services Description Language ) версии 1.1 был опубликован 15 марта 2001 года. WSDL - это формат, базирующийся на XML и использующийся для описания сетевых cервисов, при помощи сообщений, содержащих информация о том как осуществлять доступ к конкретному веб-сервису. WSDL расширяем, что позволяет описывать услуги (сервисы) и их сообщения независимо от того, какие форматы сообщений или сетевые протоколы используются для транспорта, однако, чаще всего используется WSDL 1.1 вместе с SOAP 1.1, HTTP GET/POST и MIME. Поскольку WSDL был разработан совместно с SOAP, в его разработке участвовали все те же фирмы Microsoft, Ariba и IBM. Если рассматривать документ WSDL интуитивно, то можно сказать, что он позволяет ответить на 4 вопроса :

1) что вы делаете? Ответ на этот вопрос дается в форме пригодной как для восприятия человеком так и форме воспринимаемой машиной. Ответ для чел-ка в тегах: <name />, <documentation />, для машины - <message />, <pointType >

2) на каком языке вы разговариваете? (какие типы вы используете?)Ответ в теге: <types />

3) как я буду с вами общаться? (как клиент будет обращаться к веб-службе?):HTTP или SMTP. Ответ находится в <binding />

4) где мне вас найти? (где я могу найти эту веб-службу или какой у нее URL?). Ответ находится: <service />

Структура:

Каждый документ WSDL можно разбить на три логические части:

1. определение типов данных - определение вида отправляемых и получаемых сервисом XML сообщений

2. абстрактные операции - список операций, которые могут быть выполнены с сообщениями

3. связывание сервисов - способ, которым сообщение будет доставлено

Документы WSDL можно создавать вручную, однако строгая формализация языка WSDL позволяет автоматизировать процесс написания WSDL -документов. Многие интсрументальные средства создания Web-служб содержат утилиты, которые автоматичеки создают WSDL -файлы, описывающие готовые Web-службы. Например средство создания Web-служб Apache Axis содержит в своем составе класс Java2WSDL , создающий WSDL -файл по классу или интерфейсу Java, описывающему Web-службу. Пакет IBM WSTK, в состав которого входит Axis , содержит утилиту java2wsdl , создающую и запускающую объект из этого класса. Она работает из командной строки.

Элементы WSDL-документа

Опишем наиболее часто употребляемые теги WSDL:

Тег – это корневой тег всех WSDL-документов. Он определяет несколько пространств имен:

1)target Name space – это пространство имен нашей веб-службы

2)xmlns – стандартное пространство имен документа WSDL

3)xmlns: SOAP_ENC – пространство имен используемое для описания кодировки SOAP

4)xmlns: impl и intf – пространство имен реализации и определения нашей веб-службы

· Документ для определения веб-службы

· Документ для реализации веб-службы

Для простоты, как правило, используют 1 файл, который содержит всю информацию

Элемент - предоставляет информацию о данных, которые передаются от одной конечной точки к другой.

Для описания вызова RPC необходимо создать входной сообщение и выходное сообщение.

В рамках этого элемента можно указать параметры метода с помощью элемента

Элемент описывает и определяет операции или методы поддерживаемые веб-службой

Операции могут иметь входные сообщения, а также сообщения об ошибках.

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

Элемент - указывает где найти веб службу

Элемент import . Очень часто элемент service выделяется в свой wsdl документ из соображений практичности.

Для того, чтобы позволить собрать из нескольких wsdl документов один используется элемент import. Он позволяет включать один wsdl документ в другой.

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

WSDL поддерживает 4 режима операций:

· операции типа one-way или односторонние операции. Сообщение посылается конечной точке службы. В этом случае операция описывается только одним входным сообщением.

· Request-Response – режим запрос-ответ. Этот режим операции является наиболее общим. В этом режиме описание операции содержит входное и выходное сообщение и необязательное сообщение об ошибке.

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

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