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)
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.
XSD — умный XML
XSD — это язык описания структуры XML документа. Его также называют XML Schema. При использовании XML Schema XML парсер может проверить не только правильность синтаксиса XML документа, но также его структуру, модель содержания и типы данных.
Такой подход позволяет объектно-ориентированным языкам программирования легко создавать объекты в памяти, что, несомненно, удобнее, чем разбирать XML как обычный текстовый файл.
Кроме того, XSD расширяем, и позволяет подключать уже готовые словари для описания типовых задач, например веб-сервисов, таких как SOAP.
Стоит также упомянуть о том, что в XSD есть встроенные средства документирования, что позволяет создавать самодостаточные документы, не требующие дополнительного описания.
Рассмотрим в качестве примера XSD документ, описывающий часть структуры аккаунта на хабре.
Текст XSD схемы и XML документ, соответствующий этой схеме я не стал включать в статью из-за их размера.
Первая строчка схемы указывает, что документ является XML документом и использует кодировку UTF-8.
Со следующей строки начинается описания главного элемента документа — habra_user.
Строки, документирующие элемент:
< xs:annotation >
< xs:documentation >Главный элемент схемы. Описывает пользователя хабра
Тег описывает «сложный» тип данных user_name. При желании его можно вынести как отдельный тип данных, по аналогии с contact_info. Для этого, нужно блок перенести в и указать атрибут name, а элементу задать атрибут type.
Элементы user_name, first_name, last_name имеют строковый тип и описывают пользователя, имя и фамилию владельца аккаунта.
Элемент date_of_birth имеет тип данных «дата» и описывает дату рождения.
Дату регистрации описывает register_date, имеющий собственный тип данных customDateTime. Значение этого тега будет задаваться с помощью атрибута value. На это указывают строки.
При этом атрибут — обязательный. Чтобы значение соответствовало требованиям, опишем «проверки»:
В таком случае длина строки будет всегда 19, это задано тегом и само значение будет соответствовать шаблону, указанным в теге .
Элементы contact_info и blog — массивы, на это указывает атрибут maxOccurs=«unbounded».
Тег определяет то, что вложенным элементом будет один из элементов ICQ или linkedin.
Тег указывает на то, что вложенные элементы будут blog_name и blog_url именно в такой последовательности. Если последовательность не важна, то нужно использовать тег .
Дополнительно о XSD схемах можно почитать Wikipedia и W3C. Для создания макета была использована программа Altova XMLSpy.
Эндпойнт из XSD
Кулити работяги
Скажу сразу — я мега тупой, и ничего особо не шарю в айти .
В общем два вопроса:
1. Чем отличается WSDL от XSD?
2. Вот у меня есть XSD да, как узнать эндпойнт сервиса который там прописан?
Т.е мне нужно открыть SoapUI ввести эндпойнт веб-сервиса из XSD и дёрнуть его.
Пароли к WS у меня есть
Ну вы поняли типа
24 May 2023 в 18:23 #2
24 May 2023 в 18:25 #3
Александр сказал(а):↑
В некст раз делай так
Нажмите, чтобы раскрыть.
Оо спасибо, не знал что чатЖПТ так божит. Над зарегаться на него