Pull to refresh

Comments 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 (можно вызывать, работает)
Вы путаете понятия. JSON — транспорт, а не протокол.

Вообще, статья писалась для тех, кому интересна данная технология. В ней мы по шагам разбираем что такое SOAP и что его окружает. Т.к. в рунете очень мало материала на данную тему
Не стоит кидаться в меня камнями. Я не говорю, что выбор решения неправильный, статья неинтересная или что-то в этом духе.
Мой вопрос был не совсем точен. Я хотел спросить, почему вы используете SOAP, а не любое другое решение, какие преимущества?
Работал с SOAP долгое время, трудозатраты достаточно большие на рутину.
Та же поддержка WSDL в актуальном состоянии.
А если WSDL генерить автоматом и оно будет меняться при любом изменении в коде, как сделал коллега из первого комментария, то какой в нем смысл? В этом случае проще упразднить WSDL и весь SOAP и перейти к чему-то более лёгкому.
Из-за высказанных проблем по трудозатратам в поддержке, решил отказаться в пользу более простого и легкого самодельного JSON-based протокола. SOAP использую только если есть необходимость в нём самом. Если же задача стоит в обеспечении взаимодействия, а выбор протокола на усмотрение, то я бы SOAP реализовывать не стал.
Стало интересно, каковы ньюансы протокола, из-за которых вы его выбрали и которые вы считаете достоинствами, о чем и был изначальный вопрос.
С ним намного легче работать клиентам. Не надо заботиться о формировании запроса и использовать сторонние средства.
Изначально из-за того, чтобы самостоятельно не заниматься валидацией приходящих данных. Написал один раз схему и дальше получаю удовольствие, т.к. мой валидатор на PHP врятли будет быстрей нативных методов PHP. Также, надеялся облегчить себе работу путем использования уже готовых классов (опять же нативных), с помощью которых можно реализовать клиент и сервер буквально в несколько строк кода.
Но по ходу ковыряния выяснилось о некоторых недочетах в работе встроенных классов.
Само гонение XML по HTTP туды сюды не выходит шило на мыло с не нативными функциями по времени? Не знаю конечно как сравнивать… просто тут тоже надо сравнивать.
Вы ведь имели введу JSON-RPC 2.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
Т.е. вам нужно реализовать на клиенте возможность отправлять дополнительные заголовки в пакете, а сервер научить их правильно обрабатывать. Вероятно, сейчас в сети можно найти множество готовых решений.
Спасибо! Но я имел немного другое.
Если читать доки по SoapClient, то в них написано о том, что при создании нового объекта от данного класса, то мы можем в качестве параметров передавать на сервер некий login и password. Но когда я их добавляю в параметры, то в пришедшем на сервер конверте нет раздела Header с данными для авторизации.

Поэтому и был вопрос к знатокам. Можно ли посредством SoapClient передать авторизационные данные предусмотренные спецификацией протокола? И если можно, то как.
По всей видимости, это логин и пароль для HTTP аутентификации, т.е. BASIC или DIGEST. Тип аутентификации задается опцией authentication.
Господи, спасибо тебе за WCF (а еще за Web API, если отвлечься от SOAP).
Но знать как все это устроено не помешает. А так, ребята из Редмонда молодцы
Библиотеку nusoap попробуйте, если так нужен SOAP. Она кривовата, но дело свое делает.
Если честно, то данный пост имеет некоторый корыстный замысел.
Им я хотел обратить внимание разработчиков PHP (в особенности тех, которые делали модуль php-soap) на их детище и имеющиеся в нем недочеты. Я очень сильно надеюсь, что на хабре есть люди имеющие хотя бы отдаленное отношение к разработке PHP. И возможно, они как-то смогут поспособствовать в скорейшей доработке столь замечательного начинания!
Для тех кому интересно — 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>

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 ();
Более того, это нужно делать и не важно чем, а не руками набирать. Руками всё делать — прошлый век.
Еще, в .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>
Руками писать wsdl — моветон имхо. Каждое добавление/изменение метода — нужно править не очень интуитивный текст. Лучше определить фасад и по нему генерировать wsdl.
Статья отличная, но я бы предпочел более строгую подачу материала, без «фамильярностей».

PS: правильно ли я понял что класс подгружаемый через setClass подгружается автолоадером, и там уже описана функция отправки?
Да, вы все абсолютно правильно понимаете!
Еще мной был только-что обнаружен довольно досадный факт — оказывается, я забыл в тексте статьи привести листинг этого класса.
Но по этому поводу не стоит расстраиваться, т.к. весь используемый в топике набор скриптов лежит в моем репозитории на GitHub'е (включая класс SoapSmsGateWay). Ссылка на репозиторий расположена в последнем перечислении списка литературы.
Мы отказались в свое время от XML, объём данных слишком большой. Сначала поддерживали его, но когда траффик возрос до многих миллионов СМС — всё это обрабатывать оказалось накладно. Слишком много «лишних» данных в запросах-ответах клиент-сервер-клиент.
Если не секрет, то чем заменили XML в своей системе?
Перешли на JSON или что-то другое?
Да, JSON, секрета нет :)
Огромное спасибо автору за труд!
Статья очень помогла в понимании связки XML Schema, WSDL, SOAP
Сам приступил к изучению SOAP недавно, тема очень широкая.

P.S. Если кто вдруг не знает, есть отличный инструмент для тестирования SOAP сервисов SOAP UI. Он по WSDL генерирует стабы для запросов и тест-кейсов.
Я оценил
Only those users with full accounts are able to leave comments. Log in, please.