Web Service - XML теория, что нужно знать …

Начнем с начала, с xml документов, прежде всего любой xml  документ начинается с объявления, есть три свойства которые вы можете встретить в объявлении, это: version, encoding, standalone.  Version устанавливает номер версии xml, на данный момент мне известна только одна версия “1.0”, encoding – кодировка в которой сохранен файл, standalone - когда xml  документ, обрабатывают сторонние “редакторы-обработчики”, то это свойство подсказывает если ли у документа другие части которые должны быть подгружены, для того что бы иметь целостный xml документ для обработки.   Если атрибут standalone равен значению yes, то xml файл состоит из одной части – тела файла, если no, то должны быть еще какие-то части документа, которые нам нужно подгрузить.  Пример:

<?xml version="1.0" encoding="UTF-8" standalone=”yes” ?>

XML документ состоит из элементов, ещё их называют тегами, у тегов могут быть атрибуты, каждый файл имеет корневой тег. Каждый тег, должен открываться начальным тегом и заканчиваться конечным, между ними находится значение тега. Комментарии в файле, не несут ни какой смысловой нагрузки, теги и атрибуты регистро зависимые,  то есть если вы используете в начальном теге верхний регистр символов, то и конечный тег должен совпадать по регистру. Значение атрибутов всегда должны быть заключены в кавычки.  Важную роль играет понятие  пространство имен (namespace), помогает избежать конфликта имен в тегах,  если в документе могут встретиться одинаковые теги, но разные по логике применения.  Описание пространства имен происходит посредством атрибута xmlns:имя_простраства_имен=”URI”.  Имя_простраства_имен может быть произвольным, URI – универсальный идентификатор ресурса, это строка символов, которая уникальным образом должна идентифицировать пространство имен, обычно многие пространства имен имеют URL,  который указывает на документ в сети интернет. Когда мы ввели в наш xml  документ пространство имен, мы  к тегам которые находятся в этом пространстве имен, должны добавлять префикс имя_простраства_имен и через знак “:” название тега -  <имя_простраства_имен:имя_тега>. Для того что бы, не добавлять постоянно этот префикс, можно объявить пространство имен по умолчанию, происходит это посредством атрибута  xmlns =”URI”, просто уже нет объявления имя_простраства_имен. Посмотрите на кусок xml документа, желтым цветом помечены фрагменты кода, которые приводятся для закрепления теории которую я описал выше:

<?xml version='1.0' encoding='UTF-8'?>

<wsdl:definitions name="OrderProcessService" targetNamespace="http://order.demo/" xmlns:ns1="http://schemas.xmlsoap.org/soap/http" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://order.demo/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

                <wsdl:types>

                               <xs:schema attributeFormDefault="unqualified" elementFormDefault="unqualified" targetNamespace="http://order.demo/" xmlns:tns="http://order.demo/" xmlns:xs="http://www.w3.org/2001/XMLSchema">

                                               <xs:element name="processOrder" type="tns:processOrder" />

                                               <xs:element name="processOrderResponse" type="tns:processOrderResponse" />

                                               <xs:complexType name="processOrder">

                                                               <xs:sequence> <!--  это коментарий -->

                                                                              <xs:element minOccurs="0" name="arg0" type="tns:order" />

                                                               </xs:sequence>

                                               </xs:complexType>

                                               <xs:complexType name="order">

                                                               <xs:sequence>

                                                                              <xs:element minOccurs="0" name="customerID" type="xs:string" />

                                                                              <xs:element minOccurs="0" name="itemID" type="xs:string" />

                                                                              <xs:element name="price" type="xs:double" />

                                                                              <xs:element name="qty" type="xs:int" />

                                                               </xs:sequence>

                                               </xs:complexType>

                                               <xs:complexType name="processOrderResponse">

                                                               <xs:sequence>

                                                                              <xs:element minOccurs="0" name="return" type="xs:string" />

                                                               </xs:sequence>

                                               </xs:complexType>

                               </xs:schema>

                </wsdl:types>

….

</wsdl:definitions>

Когда мы обмениваемся xml документами, для нас важно что  бы отправитель и получатель документа имели одинаковые “ожидания” от содержимого, одинаково могли интерпретировать документ, его значения.  С помощью xml схем создатель документа может описать как должен, обрабатываться, какие типы данных использовать при обработке, что очень облегчает жизнь клиенту, когда он работает с документом. Для примера,  разделитель дробной части в разных странах разный у кого точка, у кого запятая, значения даты по-разному, могут интерпретироваться в разных странах, точнее их позиции, а если у нас есть типы данных элементов, то мы вряд ли ошибемся с интерпретацией xml документа.   Если вернутся к нашему примеру тег  <xs:schema … задает схему, где мы можем описать типы данных нашего документа. Простые элементы определяются так <xs:element name="имя" type="тип данных" />,   например <xs:element name="qty" type="xs:int" /> сложные элементы составляются из простых элементов так:

 <xs:complexType name="имя">

                                                               <xs:sequence>

                                                                              ….

                                                                              <xs:element name="имя" type="тип данных" />

                                                               </xs:sequence>

                                               </xs:complexType>

Пример сложного элемента можете посмотреть опять же в предыдущем примере. Простые элементы, используют встроенные типы, приведу наиболее часто встречающиеся из них: xs:string,  xs:int, xs:double, xs:date, xs:boolean. Важно, на значения типов элементов можно накладывать ограничения, которые придают новые свойства простым типам. Например, нам нужно ограничить простой тип xs:int минимальным значением от 16 и старше. Это делается при помощи служебного тега <xs:restriction>:

<xs:element name=’age’>

<xs:simpletype>                                              

<xs:restriction base=’xs:int’>

<xs:minInclusive value=’16’/>

</xs:restriction>

</xs:simpletype>

</xs:element>

Для того что бы хорошо разбираться в web сервисах, нужно хорошо оперировать с xml  файлами, нужно очень хорошо знать, что такое xml файл и что такое схема xml  документа.
Next

Web Service теория

Веб сервисы (web service) - это процедуры которые объединены в сервисы, которые вызываются удаленно на распределенных системах. Для чего они нужны, в мире разработок довольно давно применяют термин SOA, основная идея, которой заключается в том, что бы концентрировать бизнес логику в одном месте посредством веб служб.  А многочисленным программам давать использовать эти веб службы в место того, что бы внедрять один и тот же код во множество программ. Представьте такую ситуацию, что выявлена ошибка в коде процедуры, она используется в 100 различных  программах, нам придется обновить процедуру в каждой программе. Т. е. дать задание на доработку 100 программ, 100 программистам исправить 100 процедур, 100 раз протестировать программу,  накладные расходы возрастают минимум в 100 раз на поддержку программ, по сравнению с тем, если бы у нас была только одна процедура, которая бы вызывалась через веб сервис удаленно, поправили процедуру, входящую в веб сервис и нет больше проблем. Для взаимодействия между программами был придуман протокол SOAP, который позволяет писать веб службы на любом языке программирования, а так же клиентов на  языке программирования который вы предпочитаете использовать. И так мы поняли что, взаимодействовать будут между собой программы и веб сервисы посредством протокола soap отправляя друг другу сообщения.  Отсюда следует, что нам еще нужен для доставки пакетов, какой-либо транспортный протокол. В теории говорится, что таким  протоколом может быть любой транспортный протокол, но на практике привязка делается к самому распространённому web  протоколу, HTTP.  Посмотрим на пример ответа по протоколу HTTP, сначала идет заголовок http ответа, потом идет сам soap  ответ, он представлен как xml  документ:

HTTP/1.1 200 OK

Content-Type: application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

   <soap:Body>

     <getProductDetails xmlns="http://vit.example.com/ws">

       <productID>12</productID>

     </getProductDetails>

   </soap:Body>

</soap:Envelope>

И так, если у нас есть xml документ, должны быть правила по которым он составляется, для этого был введен дополнительный язык описания веб сервисов, WSDL. Wsdl описывает типы данных отправляемых и принимаемых сообщений, операции которые могут быть выполнены, привязку сервисов, описание ошибок, способы привязки сервиса к протоколам доставки и т.д. Если у нас есть wsdl файл, то используя его описание, мы можем написать клиентское приложение которое будет работать с веб сервисом. И так что нам нужно для создания веб сервиса, описать wsdl файл, создать веб сервис на языке программирования, который удовлетворяет всем его требованиям, написать клиента, используя wsdl файл. При этом нам потребуется работать с xml документами создавая вручную, soap запросы и ответы  веб сервиса, такой подход, к написанию веб служб называется “contract-first”. И так, что бы, не возится с описанием запросов и ответов soap веб служб, призвали на помощь технологию преобразования xml  документа в  bean объекты и обратно – JAXB.  Но для некоторых по-прежнему было сложно реализовывать такой подход, с начала xml файлы потом java классы.  Придумали технологию JAX-WS,  которая позволяет нам идти от обратного, при помощи аннотаций превращать наш класс в веб службу, а потом автоматически  генерировать и получить wsdl файл настройки, soap запросы и ответы, такой метод разработки принято называть “contract-last”. Но у него есть один недостаток, если мы изменим существенно реализацию нашего класса, то мы можем подложить свинью, всем нашим клиентам, которые до этого работали с нашей веб службой, и они не смогут больше работать с нашей веб службой, реализация изменилась,  изменилась веб служба, изменился wsdl файл, а клиенты нет. Решением этой проблемы является, появление нескольких версий веб служб, которые придется поддерживать, что чревато накладными расходами, но за удобство приходится платить такой ценой.  Но самая интересная технология это JAX-RS или как её еще называют RESTful веб сервисы, разрабатывается по технологии “contract-last”.   Java классы, описываются так же с помощью аннотаций, веб сервисы представляются как ресурсы HTTP, уникально идентифицированные с помощью URI. Запросы делаются с помощью  протокола HTTP посредством служебных слов POST, GET, HEAD, PUT, DELETE.  JAX-RS может использовать для обмена данными не только xml формат, но и  JSON, что делает его более интересным и привлекательным с точки зрения веб разработчиков. Ну вот так в целом обстоят дела с языком  java и веб сервисами. следующая теория Web Service - XML теория, что нужно знать …