XSD vs WSDL: What’s the difference?
XSD is a way to validate XML documents. WSDL is a way to describe web services using XML.
Updated: 14 July 2022
When you’re working with XML web services, you’ll often come across the terms WSDL and XSD. But do you know what they do, and what makes them different from each other? Read on to find out more.
What is XSD?
XSD, or XML Schema Definition, is a language for describing what an XML document should look like. XSD helps a computer system to validate an XML document.
The list of elements which are allowed in an XML document, and a description of each element
The order of those elements
What contents the elements can contain (e.g. string or date)
XSD can be used to validate any XML document – whether it’s received by email, file transfer, or a web service call. So it’s often used in backend processes to make sure that data is OK before processing it. If an XML document passes validation, it’s sometimes called schema-valid.
Validating an XML document with XML Schema
An XML Schema Definition is itself just an XML document 2 , so it looks like a regular XML file. When a document is written in XML Schema Definition language, it’s often saved with the extension .xsd .
XSD is a standard, agreed by the W3C. There are other ways to write rules for XML documents (like Document Type Definitions (DTDs), Relax-NG and Schematron) but XSD is probably the most popular way to validate an XML document.
What does it look like?
You begin an XSD document with the root element, schema . You define each tag in the XML document using the tag element . Each of these elements can contain simple content (which means something like a string or a date), or more complex data (like nested elements).
For example: You’re writing an XSD for an XML document to describe a Customer. In the XSD, you might declare that a Customer must have 1 Address, and that each Address must contain a State, but the Zip code is optional:
We have an XML document that we’d like to validate against this XSD:
We could now validate this with the xmllint tool on Linux:
xmllint --schema customer.xsd bob.xml If you try it yourself, you should see that the message “customer.xml validates”. Success!
What can you do with XSD?
So how is XSD used in the real world?
Write an XSD. You can create an XSD document and write rules in it, using a text editor, or specialised software like XMLSpy.
Validate with a command-line tool. You can use a tool like xmllint to validate XML documents using your XML Schema definition.
Validate in your code. Most programming languages have libraries to validate XML documents using XSD, so you can add validation to your own applications. For example, in Python you might use the xmlschema package.
Validation in another app. When a software application receives some data in XML format (e.g. from a business partner), it might use XSD to validate the incoming XML document.
What is WSDL?
WSDL, or Web Services Description Language, is an XML-based language for describing web services. 3
WSDL defines a standard set of XML elements, which describe all the features of a web service. You write a WSDL document, using these elements to describe your web service.
You can use WSDL to describe a web service, so that potential consumers of the service know how to use it. A WSDL document declares things like:
The operations you can call on the service
How the input and output messages should look
Which protocol or data format you should use to access the service
WSDL looks like a regular XML file, and it’s usually saved with the .wsdl extension.
WSDL is also a standard from the W3C. You don’t have to use WSDL, but since it documents a web service completely, it’s become a common way to share information about web services (especially SOAP web services). Because of its widespread adoption, there are many tools which can understand WSDL files and use them to connect to web services.
What does it look like?
A WSDL 1.1 document starts with the root element, definitions .
WSDL contains elements to define the web service operations, data types, protocol and data formats, and location of the service. Inside the WSDL document, you can use XML Schema (XSD) to define the messages which should be received and sent by the web service.
What can you do with WSDL?
Write a WSDL. You can write a WSDL document using any text editor. It’s written in XML.
Describe your web service. Inside the WSDL file you can describe all of the operations your web service has, and the structure of the input and output messages.
Generate a WSDL from code. In some programming languages, you can generate a WSDL document automatically from your code. This is much easier than writing a WSDL document manually.
For example… In Java, you can write code for a web service using the JAX-WS APIs, and add a library like CXF which implements the JAX-WS standard. When you deploy your code, a WSDL will be automatically generated.
Create a web service client. If a web service provides a WSDL, you can import the WSDL into your programming language, and use it to create a client. There are libraries to help you do this in most programming languages. It can save a lot of time and means you don’t have to write a bunch of XML yourself!
How is XSD related to WSDL?
WSDL describes the interface of a web service. One of the key things you need to know when connecting to a web service is how you should construct your request message. So, the WSDL defines what the input and output messages for the service should look like.
WSDL didn’t introduce a new language for describing these messages. Instead, it chose to adopt XML Schema Definition as its type system. 4 So WSDL uses the features of XSD to describe input and output messages – by defining the elements, their types, their sequence, and so on.
Most WSDL documents either include an XSD document, or they reference an XSD document located somewhere else.
So WSDL and XSD are closely related. You will often see XSD being used to describe the input and output messages of a web service.
Chains
Sometimes, you might also see a chain of documents, where a WSDL references an external XSD document, which itself references another XSD document.
You might see this when dealing with very complex web services, or many web services which share similar messages. So the messages might be defined in one place, and then referenced from many places.
Wrapping up
XML Schema Definition, or XSD, is almost the de facto way to write rules for your XML documents. An XSD document describes which elements should be present in an XML document. It can be used to validate XML.
WSDL, or Web Services Definition Language, is a way to describe web services. It’s also written in XML. Many WSDL documents use XML Schema to describe the types of messages that a web service either consumes or produces.
There are so many ways to create a web service. But now you’re familiar with XSD and WSDL, you’ll be on your way to creating and consuming XML-based web services!
By Tom Donohue, Editor | Twitter | LinkedIn
Tom is the founder of Tutorial Works. He’s an engineer and open source advocate. He uses the blog as a vehicle for sharing tutorials, writing about technology and talking about himself in the third person. His very first computer was an Acorn Electron.
Thanks for reading. Let’s stay in touch.
It took us this long to find each other. So before you close your browser and forget all about this article, shall we stay in touch?
Join our free members’ newsletter. We’ll email you our latest tutorials and guides, so you can read at your leisure! �� (No spam, unsubscribe whenever you want.)
Thank you!
We’ve sent you an email. Please check your email, and click the link inside to confirm your subscription.
Общие сведения об уровне модели службы
API модели службы WWSAPI моделирует обмен данными между клиентом и службой как вызовы методов, а не как сообщения данных. В отличие от уровня канала, который поддерживает более традиционные обмены сообщениями между клиентом и службой, модель службы автоматически управляет взаимодействием с помощью прокси-сервера службы на клиенте и узла службы в службе. Это означает, что клиент вызывает созданные функции, а сервер реализует обратные вызовы.
Например, рассмотрим службу калькулятора, которая выполняет сложение и вычитание двух чисел. Сложение и вычитание — это операции, естественно представленные в виде вызовов методов.
Модель службы представляет взаимодействие между клиентом и службой в виде объявленных вызовов методов и поэтому скрывает от приложения сведения о взаимодействии базового уровня канала, что упрощает реализацию службы.
Указание службы
Служба должна быть указана с точки зрения ее шаблонов обмена сообщениями, а также представления сетевых данных. Для служб эта спецификация обычно предоставляется в виде WSDL и документов схемы XML.
Документ WSDL — это XML-документ, содержащий привязку канала и шаблоны обмена сообщениями службы, тогда как документ схемы XML — это XML-документ, определяющий представление данных отдельных сообщений.
Для службы калькулятора и операций сложения и вычитания документ WSDL может выглядеть следующим образом:
Аналогичным образом, его xml-схему можно определить следующим образом:
Преобразование метаданных в код
Модель службы предоставляет WsUtil.exe в качестве инструмента для обработки этих документов метаданных, преобразуя WSDL-файл в файлы заголовка C и исходные файлы.
WsUtil.exe создает заголовок и источники для реализации службы, а также операции службы на стороне клиента для клиента .
Вызов службы калькулятора из клиента
Как и в случае с реализацией службы, клиент должен включать сгенерированные заголовки или заголовки.
#include "CalculatorProxyStub.h" Теперь клиентское приложение может создать и открыть прокси-сервер службы, чтобы начать взаимодействие со службой калькулятора.
WS_ENDPOINT_ADDRESS address = ; WS_STRING uri= WS_STRING_VALUE(L"http://localhost/example"); address.uri = uri; if (FAILED (hr = WsCreateServiceProxy(WS_CHANNEL_TYPE_REQUEST, WS_HTTP_CHANNEL_BINDING, NULL, NULL, 0, &serviceProxy, error))) goto Error; if (FAILED (hr = WsOpenServiceProxy(serviceProxy, &address, NULL, error))) goto Error; Приложение может вызвать операцию Add в службе калькулятора со следующим кодом:
if (FAILED (hr = DefaultBinding_ICalculator_Add(serviceProxy, heap, 1, 2, &result, NULL, 0, NULL, error))) goto Error; Сведения о полной реализации службы калькулятора см. в примере кода в httpCalculatorClientExample .
Компоненты модели службы
Взаимодействие отдельных компонентов модели службы WWSAPI в примере калькулятора выглядит следующим образом:
- Клиент создает прокси-сервер службы и открывает его.
- Клиент вызывает функцию Add службы и передает прокси-сервер службы.
- Сообщение сериализуется в соответствии с метаданными сериализации в файлах заголовка и исходных файлов, созданных средством метаданных (WsUtil.exe).
- Сообщение записывается в канал и передается по сети в службу.
- На стороне сервера служба размещается внутри узла службы и имеет конечную точку, прослушивающую контракт ICalculator.
- Используя метаданные модели службы в заглушку, служба десериализует сообщение от клиента и отправляет его в заглушку.
- Серверная служба вызывает метод Add, передавая ему контекст операции. Этот контекст операции содержит ссылку на входящее сообщение.
- Узел службы: размещает службу.
- Прокси-сервер службы. Определяет, как клиент взаимодействует со службой.
- Контекст: контейнер свойств для предоставления сведений о состоянии для операции службы.
- Contract: определение интерфейса службы. Например, ICalculator представляет контракт для службы калькулятора в нашем примере кода.
- WsUtil.exe: средство метаданных модели службы для создания прокси-серверов и заглушек.
в чем разница между XSD и WSDL
разница, которую я заметил, в том, что WSDL содержит XSD и WSDL мы можем объявлять операции, но не в XSD . Это верно?
автор: make
7 ответов
XSD определяет схему, которая является определением того, как XML-документ может быть структурирован. Вы можете использовать его, чтобы проверить, что данный XML-документ действителен и следует правилам, изложенным в схеме.
WSDL-это XML-документ, описывающий веб-сервис. Он показывает, какие операции доступны и как данные должны быть структурированы для отправки в эти операции.
документы WSDL имеют связанный XSD, который показывает, что допустимо поместить в документ WSDL.
автор: Paolo
WSDL (язык описания веб-служб) описывает вашу службу и ее операции — как называется Служба, какие методы она предлагает, какие параметры и возвращаемые значения имеют эти методы?
Это описание поведения сервиса — это функциональность.
xsd-схемы (определение схемы Xml) описывает статическую структуру сложных типов данных, которыми обмениваются эти методы службы. Он описывает типы, их поля, любые ограничения на эти поля (например, максимальная длина или шаблон регулярного выражения) и т. д.
Это описание типов данных и, следовательно, статических свойств сервиса-это данные.
автор: marc_s
XSD: определение схемы XML.
XML: расширяемый язык разметки.
WSDL: язык определения веб-службы.
Я не собираюсь отвечать в техническом плане. Я направляю это объяснение на начинающих.
нелегко общаться между двумя различными приложениями, которые разрабатываются с использованием двух разных технологий. Например, компания в Чикаго может разработать веб-приложение с использованием Java, а другая компания в Нью-Йорке может разработать приложение на C# , и когда эти две компании решили поделиться информацией, тогда XML входит в картину. Это помогает хранить и транспортировать данные между двумя различными приложениями, разработанными с использованием различных технологий. Примечание: это не ограничивается языком программирования, пожалуйста, сделайте исследование по транспортировке информации между двумя различными приложениями.
XSD-это определение схемы. Под этим я подразумеваю, что он говорит пользователям разрабатывать свой XML в таком схема. См. ниже изображения и внимательно следите за элементом «load-on-startup» и его типом, который является целочисленным. В изображении XSD вы можете видеть, что это должно быть целочисленное значение для «load-on-startup», и, следовательно, когда пользователь создал свой XML, они передали значение int этому конкретному элементу. Напомним, что XSD-это схема и стиль, а XML-это форма для взаимодействия с другим приложением или системой. Нужно видеть XSD и создавать XML таким образом, иначе он не будет взаимодействовать с другое приложение или система, которая была разработана с использованием другой технологии. Компания в Чикаго предоставляет шаблон XSD для компании в Техасе, чтобы написать или создать свой XML в данном формате XSD. Если компания в Техасе не смогла придерживаться этих правил или схемы, упомянутых в XSD, то невозможно ожидать правильной информации от компании в Чикаго. После вышеупомянутой истории так много нужно сделать, что любитель или новичок должен знать, кодируя что-то вроде Я сказал выше. Если вы действительно хотите знать, что произойдет позже, то лучше сидеть со старшими инженерами-программистами, которые на самом деле разработали веб-сервисы. Далее идет WSDL, пожалуйста, следуйте изображениям и попытайтесь выяснить, где WSDL будет вписываться.
***************========Ниже приведен частичный XML-образ ==========***************
Мне пришлось создать образец WSDL для веб-службы под названием Book. Обратите внимание, что это XSD, но вы должны назвать его WSDL (язык определения веб-службы), потому что он очень специфичен для веб-служб. Ниже WSDL (или, другими словами, XSD) создается для класса под названием Book.java и он создал SOAP-сервис. Как веб-служба SOAP создала другую тему. Нужно написать класс Java и перед его выполнением создать как веб-службу, пользователь должен убедиться, что AXIS2 API установлен и Tomcat для размещения веб-службы на месте.
Как сервисер (тот, кто позволяет другим (клиентам) получать доступ к информации или данным из своих систем ) фактически предоставляет клиенту (тому, кто должен использовать информацию или данные сервисера) полный доступ к данным через веб-службу, потому что ни одна компания на земля готова открыть свою базу данных для посторонних. Как и моя компания, решила предоставить некоторую информацию о продуктах через веб-сервисы, поэтому нам пришлось создать шаблон XSD и передать его немногим из наших клиентов, которые хотят работать с нами. Они должны написать некоторый код, чтобы полностью использовать данный XSD и совершать вызовы веб-служб для извлечения данных из servicer и преобразования данных, возвращенных в их подходящее требование, а затем отображать или публиковать данные или информацию о продукте на своих вебсайт. Простым примером может служить бронирование авиабилетов. Авиакомпания позволит третьим лицам использовать данные о рейсах на своем сайте для продажи билетов. Но опять же есть гораздо больше к нему, это просто не давая третьей стороне агент по продаже билетов, там будет синхронизация и безопасность на месте. Если нет синхронизации, то есть 100% вероятность того, что более 1 клиента могут купить один и тот же билет из разных источников.
Я надеюсь, что эксперты внесут свой вклад в мой ответ. Это очень трудно новичку или новичку понять XML, XSD, а затем работать с веб-службами.
SOAP-кодирование, типы WSDL и XML Schema
Использование Web-службы подразумевает обмен хотя бы одним XML-сообщением между отправителем и получателем. Формат сообщения должен быть определен так, чтобы отправитель мог формировать, а получатель обрабатывать сообщение. Формат любого сообщения включает общую структуру дерева (tree), локальное имя и имя пространства имен для элементов и атрибутов, используемых в этом дереве, а также типы этих элементов и атрибутов.
Имя и типы элементов и атрибутов, содержащихся в этом сообщении, могут быть определены в схеме. Именно так язык описания Web-служб (Web Services Description Language, сокр. WSDL) может использовать схему. Если описание Web-службы на WSDL располагается в начальной точке, формат сообщения известен еще до того, как написана хотя бы строчка кода. Однако, во многих случаях код, который будет использоваться как Web-служба, уже написан. Или же разработчики не торопятся начинать с WSDL, предпочитая программную структуру данных. Но даже в этих случаях для того, чтобы клиент правильно создавал запросы и деструктурировал ответы, необходимо некоторое описание Web-службы. В идеале им мог бы быть сам WSDL, поскольку в противном случае клиентам пришлось бы изучать и разбираться в многочисленных языках описания.
Таким образом, если схема или связанный с ней WSDL не располагаются в начальной точке, возникает вопрос: как же WSDL будет сгенерирован, и какой формат будет у XML-сообщения? Можно утверждать, что многие существующие реализации SOAP включат программный тип данных, а именно какое-нибудь описание класса, и запишут (serialize) этот тип в XML. Но если схема отсутствует, каким образом эти реализации определят, что использовать: элементы или атрибуты? По какому принципу они дадут имена этим конструкциям, и какой должна быть общая структура дерева? Ответы на эти вопросы могут быть найдены во второй части спецификации SOAP 1.2 (SOAP 1.2 specification, Part 2), в подразделе SOAP-кодирование (SOAP Encoding).
SOAP-кодирование
SOAP-кодирование устанавливает ряд правил преобразования программных типов в XML. Оно включает требования к преобразованию сложных структур данных, типов массивов и ссылочных типов. В отношении сложных структур данных применяемый подход оправданно прямолинеен; так, все данные записываются как элементы, а имя любого заданного элемента соответствует имени поля данных в программном типе. Например, при задании следующего класса Java,
class Person
String name;
float age;
>
поля name и age были бы записаны с использованием элементов, с локальными именами name и age, соответственно. Оба элемента были бы неквалифицированными, т.е., имя пространства имен было бы пустым. Для тех случаев, когда имя поля не было бы разрешенным XML-именем, в Приложении А (Appendix A) спецификации SOAP можно найти алгоритм преобразования.
Преобразование ссылочных типов — более сложная задача. Для этого потребуется преобразовать экземпляр (instance) и пометить его неквалифицированным атрибутом с локальным именем id . Значению href соответствует URI, который ссылается на соответствующий записанный экземпляр через его id -атрибут. Этот метод позволяет записывать в XML графы, включая циклические графы (cyclic graph).
Преобразование типов
SOAP-кодирование позволяет также преобразовывать программные типы данных в типы данных, описанные во второй части спецификации, «Типы данных» (XML Schema Part 2: Datatypes). Таким образом, при задании программной структуры могут быть определены имя и тип каждого элемента в записанном XML. Многие считают, что SOAP-кодирование в равной степени регламентирует как преобразование между системами типов, так и между форматами экземпляров.
Предположим, что Web-служба принимает структуры данных как входную информацию, возможно, чтобы добавить их в некий список людей, который она поддерживает. В этом случае SOAP-сообщение для этой Web-службы может выглядеть следующим способом:
«http://www.w3.org/2001/12/soap-envelope»>
Значение атрибута encodingStyle показывает, что запись данных выполнялась в соответствии с правилами SOAP-кодирования. Благодаря этому считыватель (deserializer) на другом конце «трубы» корректно расшифрует сообщение. С SOAP могут использоваться и другие стили кодирования, в этом случае атрибут encodingStyle имел бы другое значение URI.
Приведение типов
Стоит заметить, что вышеупомянутые сообщения несут достаточно информации для того, чтобы получатель определил типы всех элементов. Это объясняется тем, что тип привязан к имени элемента. И отправитель, и получатель знают эти имена элементов. Кроме того, им известны имена и типы полей в программном типе данных. При условии, что имя элемента так тесно привязано к имени поля, можно также определить тип элемента.
В некоторых случаях точная информация о типе может быть не известна вплоть до момента выполнения. Например, когда Web-служба принимает данные тем же способом, как VARIANT в COM, any в CORBA или Object в Java. Такая служба не определяет тип во время проектирования. Эта информация должна быть предоставлена во время выполнения. Подобные службы на самом деле не принимают абсолютно никакого типа, а работают на довольно маленьком подмножестве типов, генерируя ошибки при встрече с неизвестным типом.
Наконец, информация может отсутствовать, когда образуются дополнительные классы, например, RacingDriver и FootballPlayer из Person . Если бы Web-служба понимала эти классы, они могли бы войти в отправляемые запросы.
В обоих случаях: и «полностью» полиморфного элемента и в более специфичном случае явно производных типов, имени элемента уже недостаточно для того, чтобы полностью распознать тип элемента. Для этого требуется кое-что еще.
Правила SOAP-кодирования позволяют использовать атрибут type из пространства имен http://www.w3.org/2001/XMLSchema-instance , чтобы установить, что во время выполнения используется определенный тип. Тогда элемент person в сообщении будет выглядеть следующим образом:
Следует отметить, что атрибут xsi:type относится к классу QName . Следовательно, строго говоря, этот пример ссылается на неопределенный тип RacingDriver . На практике, чтобы избежать конфликта имен, пространству имен нужно назначить тип. Кроме того, атрибут xsi:type нужен только тогда, когда точный тип не известен до момента выполнения. В большинстве случаев, когда обе стороны заранее знают типы, xsi:type является избыточным.
Заключение
Когда бы ни посылались сообщения, все-таки некоторая информация о типах известна заранее. В одних случаях, досконально известны все типы, и тогда вполне достаточно знать имена элементов. В других случаях более конкретная информация о типах может быть передана во время выполнения. В таких случаях используется атрибут xsi:type , а типы должны быть соотнесены с пространствами имен.
Может показаться, что определив форматы сообщений для обмена заданной Web-службой, мы фактически определяем схему для этих форматов. Следовательно, SOAP-кодирование на самом деле осуществляет преобразование из систем программных типов в систему XML-типа, т.е., XML Schema. Часть типов преобразуется прекрасно; другая, например, ссылки, по причине древовидной природы XML преобразуются не столь хорошо. При условии, что формат преобразования — XML, а XML — дерево, необходимо серьезно задуматься над тем, стоит ли напрямую моделировать в SOAP более сложные конструкции, такие как ссылки. Если эти конструкции действительно нужны, необходимо вооружиться удобным подходом XML Schema.
Автор: Мартин Гуджин (Martin Gudgin), Тимоти Эуолд (Timothy Ewald)