Комментарии 26
Мне пришлось написать генератор WSDL и свой парсер XML запросов вместо SOAPServer, чтобы 1с работал с моим веб-сервисом, на вход даешь такое:
class Test {
/**
*
* @var string
*/
var $single;
/**
* @minOccurs 0
* @maxOccurs unbounded
* @var string
*/
var $str;
}
/**
*
* @param Test $test
* @return Test
*/
function testFunction(Test $test) {
$test->str = array_reverse($test->str);
return $test;
}
$ws = new WS1c('http://fragster.ru/testservice', 'fragster');
$ws->methods[] = new ReflectionFunction('testFunction');
</code>
на выходе получаешь вот это: http://fragster.ru/tmp/test.php?wsdl (можно вызывать, работает)
0
Скажите, а почему именно SOAP? Почему например, ни json?
-3
Вы путаете понятия. JSON — транспорт, а не протокол.
Вообще, статья писалась для тех, кому интересна данная технология. В ней мы по шагам разбираем что такое SOAP и что его окружает. Т.к. в рунете очень мало материала на данную тему
Вообще, статья писалась для тех, кому интересна данная технология. В ней мы по шагам разбираем что такое SOAP и что его окружает. Т.к. в рунете очень мало материала на данную тему
+4
Не стоит кидаться в меня камнями. Я не говорю, что выбор решения неправильный, статья неинтересная или что-то в этом духе.
Мой вопрос был не совсем точен. Я хотел спросить, почему вы используете SOAP, а не любое другое решение, какие преимущества?
Работал с SOAP долгое время, трудозатраты достаточно большие на рутину.
Та же поддержка WSDL в актуальном состоянии.
А если WSDL генерить автоматом и оно будет меняться при любом изменении в коде, как сделал коллега из первого комментария, то какой в нем смысл? В этом случае проще упразднить WSDL и весь SOAP и перейти к чему-то более лёгкому.
Из-за высказанных проблем по трудозатратам в поддержке, решил отказаться в пользу более простого и легкого самодельного JSON-based протокола. SOAP использую только если есть необходимость в нём самом. Если же задача стоит в обеспечении взаимодействия, а выбор протокола на усмотрение, то я бы SOAP реализовывать не стал.
Стало интересно, каковы ньюансы протокола, из-за которых вы его выбрали и которые вы считаете достоинствами, о чем и был изначальный вопрос.
Мой вопрос был не совсем точен. Я хотел спросить, почему вы используете SOAP, а не любое другое решение, какие преимущества?
Работал с SOAP долгое время, трудозатраты достаточно большие на рутину.
Та же поддержка WSDL в актуальном состоянии.
А если WSDL генерить автоматом и оно будет меняться при любом изменении в коде, как сделал коллега из первого комментария, то какой в нем смысл? В этом случае проще упразднить WSDL и весь SOAP и перейти к чему-то более лёгкому.
Из-за высказанных проблем по трудозатратам в поддержке, решил отказаться в пользу более простого и легкого самодельного JSON-based протокола. SOAP использую только если есть необходимость в нём самом. Если же задача стоит в обеспечении взаимодействия, а выбор протокола на усмотрение, то я бы SOAP реализовывать не стал.
Стало интересно, каковы ньюансы протокола, из-за которых вы его выбрали и которые вы считаете достоинствами, о чем и был изначальный вопрос.
+3
С ним намного легче работать клиентам. Не надо заботиться о формировании запроса и использовать сторонние средства.
+1
Изначально из-за того, чтобы самостоятельно не заниматься валидацией приходящих данных. Написал один раз схему и дальше получаю удовольствие, т.к. мой валидатор на PHP врятли будет быстрей нативных методов PHP. Также, надеялся облегчить себе работу путем использования уже готовых классов (опять же нативных), с помощью которых можно реализовать клиент и сервер буквально в несколько строк кода.
Но по ходу ковыряния выяснилось о некоторых недочетах в работе встроенных классов.
Но по ходу ковыряния выяснилось о некоторых недочетах в работе встроенных классов.
+1
Вы ведь имели введу JSON-RPC 2.0?)
0
Насколько я помню, механизм аутентификации базируется на спецификации SOAP Message Security 1.0 (WS-Security 2004) docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
Т.е. вам нужно реализовать на клиенте возможность отправлять дополнительные заголовки в пакете, а сервер научить их правильно обрабатывать. Вероятно, сейчас в сети можно найти множество готовых решений.
Т.е. вам нужно реализовать на клиенте возможность отправлять дополнительные заголовки в пакете, а сервер научить их правильно обрабатывать. Вероятно, сейчас в сети можно найти множество готовых решений.
+1
Спасибо! Но я имел немного другое.
Если читать доки по SoapClient, то в них написано о том, что при создании нового объекта от данного класса, то мы можем в качестве параметров передавать на сервер некий login и password. Но когда я их добавляю в параметры, то в пришедшем на сервер конверте нет раздела Header с данными для авторизации.
Поэтому и был вопрос к знатокам. Можно ли посредством SoapClient передать авторизационные данные предусмотренные спецификацией протокола? И если можно, то как.
Если читать доки по SoapClient, то в них написано о том, что при создании нового объекта от данного класса, то мы можем в качестве параметров передавать на сервер некий login и password. Но когда я их добавляю в параметры, то в пришедшем на сервер конверте нет раздела Header с данными для авторизации.
Поэтому и был вопрос к знатокам. Можно ли посредством SoapClient передать авторизационные данные предусмотренные спецификацией протокола? И если можно, то как.
+1
Господи, спасибо тебе за WCF (а еще за Web API, если отвлечься от SOAP).
0
Библиотеку nusoap попробуйте, если так нужен SOAP. Она кривовата, но дело свое делает.
+1
Если честно, то данный пост имеет некоторый корыстный замысел.
Им я хотел обратить внимание разработчиков PHP (в особенности тех, которые делали модуль php-soap) на их детище и имеющиеся в нем недочеты. Я очень сильно надеюсь, что на хабре есть люди имеющие хотя бы отдаленное отношение к разработке PHP. И возможно, они как-то смогут поспособствовать в скорейшей доработке столь замечательного начинания!
Им я хотел обратить внимание разработчиков PHP (в особенности тех, которые делали модуль php-soap) на их детище и имеющиеся в нем недочеты. Я очень сильно надеюсь, что на хабре есть люди имеющие хотя бы отдаленное отношение к разработке PHP. И возможно, они как-то смогут поспособствовать в скорейшей доработке столь замечательного начинания!
+1
Для тех кому интересно — JDeveloper — хороший девелопер для написания как XML так и .WSDL. Еще для связки с БД рекомендовал бы изучить .XSD, который описывает схему
<?xml version= '1.0' encoding= 'UTF-8' ?>
<xs:schema elementFormDefault="qualified" targetNamespace="http://ib.pentegy.vab.ua/portmone" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://ib.pentegy.vab.ua/portmone">
<xs:import schemaLocation="ХХХХХ.xsd" namespace="http://ХХХХХ.ua"/>
<xs:element name="НалогНапример">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="request" nillable="true" type="q1:НалогНапримерRequest"
xmlns:q1="http://ХХХХХ.ua"/>
</xs:sequence>
</xs:complexType>
</xs:element>
.......
</xs:schema>
+1
wsdl схему можно генерировать с помощью zend framework. $class_name — класс, который надо описать в схеме
if (isset ( $_GET ['wsdl'] )) {
$soap = new Zend_Soap_AutoDiscover ();
} else {
$soap = new Zend_Soap_Server ( $url_to_wsdl );
}
$soap->setClass ( $class_name );
$soap->handle ();
0
Еще, в .WSDL можно импортировать что угодно:
Плюс в .wsdl можно добавить секьюрити, что безусловно тоже часто используется:
<wsdl:import namespace="http://Что-то" location="Здесь.wsdl"/>
<wsdl:types>
<xsd:schema targetNamespace="http://ИизЭтогоМеста/Imports">
<xsd:import schemaLocation="ClientService.xsd" namespace="http://Здесь/client"/>
<xsd:import schemaLocation="ClientService.xsd" namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
<xsd:import schemaLocation="ClientService.xsd" namespace="http://ХХХХХ.ua"/>
</xsd:schema>
Плюс в .wsdl можно добавить секьюрити, что безусловно тоже часто используется:
<wsp:Policy orawsp:provides="{http://docs.oasis-open.org/ns/opencsa/sca/200903}authentication, {http://docs.oasis-open.org/ns/opencsa/sca/200903}clientAuthentication, {http://docs.oasis-open.org/ns/opencsa/sca/200903}clientAuthentication.message, {http://schemas.oracle.com/ws/2006/01/policy}token.usernamePassword" wsu:Id="wss_username_token_service_policy">
<sp:SupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:Policy>
+1
Руками писать wsdl — моветон имхо. Каждое добавление/изменение метода — нужно править не очень интуитивный текст. Лучше определить фасад и по нему генерировать wsdl.
+2
Статья отличная, но я бы предпочел более строгую подачу материала, без «фамильярностей».
PS: правильно ли я понял что класс подгружаемый через setClass подгружается автолоадером, и там уже описана функция отправки?
PS: правильно ли я понял что класс подгружаемый через setClass подгружается автолоадером, и там уже описана функция отправки?
0
Да, вы все абсолютно правильно понимаете!
Еще мной был только-что обнаружен довольно досадный факт — оказывается, я забыл в тексте статьи привести листинг этого класса.
Но по этому поводу не стоит расстраиваться, т.к. весь используемый в топике набор скриптов лежит в моем репозитории на GitHub'е (включая класс SoapSmsGateWay). Ссылка на репозиторий расположена в последнем перечислении списка литературы.
Еще мной был только-что обнаружен довольно досадный факт — оказывается, я забыл в тексте статьи привести листинг этого класса.
Но по этому поводу не стоит расстраиваться, т.к. весь используемый в топике набор скриптов лежит в моем репозитории на GitHub'е (включая класс SoapSmsGateWay). Ссылка на репозиторий расположена в последнем перечислении списка литературы.
-1
Мы отказались в свое время от XML, объём данных слишком большой. Сначала поддерживали его, но когда траффик возрос до многих миллионов СМС — всё это обрабатывать оказалось накладно. Слишком много «лишних» данных в запросах-ответах клиент-сервер-клиент.
+1
Огромное спасибо автору за труд!
Статья очень помогла в понимании связки XML Schema, WSDL, SOAP
Сам приступил к изучению SOAP недавно, тема очень широкая.
P.S. Если кто вдруг не знает, есть отличный инструмент для тестирования SOAP сервисов SOAP UI. Он по WSDL генерирует стабы для запросов и тест-кейсов.
Я оценил
Статья очень помогла в понимании связки XML Schema, WSDL, SOAP
Сам приступил к изучению SOAP недавно, тема очень широкая.
P.S. Если кто вдруг не знает, есть отличный инструмент для тестирования SOAP сервисов SOAP UI. Он по WSDL генерирует стабы для запросов и тест-кейсов.
Я оценил
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Пишем SOAP клиент-серверное приложение на PHP