hats 23 июл 2013 в 09:09

Пишем SOAP клиент-серверное приложение на PHP

29 мин

241K

PHP *

Туториал

Из песочницы

+28

Комментарии 26

Fragster 23 июл 2013 в 10:17

Мне пришлось написать генератор 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 (можно вызывать, работает)

Rhaps107 23 июл 2013 в 10:29

Скажите, а почему именно SOAP? Почему например, ни json?

hats 23 июл 2013 в 11:03

Вы путаете понятия. JSON — транспорт, а не протокол.

Вообще, статья писалась для тех, кому интересна данная технология. В ней мы по шагам разбираем что такое SOAP и что его окружает. Т.к. в рунете очень мало материала на данную тему

Rhaps107 23 июл 2013 в 11:20

Не стоит кидаться в меня камнями. Я не говорю, что выбор решения неправильный, статья неинтересная или что-то в этом духе.
Мой вопрос был не совсем точен. Я хотел спросить, почему вы используете SOAP, а не любое другое решение, какие преимущества?
Работал с SOAP долгое время, трудозатраты достаточно большие на рутину.
Та же поддержка WSDL в актуальном состоянии.
А если WSDL генерить автоматом и оно будет меняться при любом изменении в коде, как сделал коллега из первого комментария, то какой в нем смысл? В этом случае проще упразднить WSDL и весь SOAP и перейти к чему-то более лёгкому.
Из-за высказанных проблем по трудозатратам в поддержке, решил отказаться в пользу более простого и легкого самодельного JSON-based протокола. SOAP использую только если есть необходимость в нём самом. Если же задача стоит в обеспечении взаимодействия, а выбор протокола на усмотрение, то я бы SOAP реализовывать не стал.
Стало интересно, каковы ньюансы протокола, из-за которых вы его выбрали и которые вы считаете достоинствами, о чем и был изначальный вопрос.

NeX 23 июл 2013 в 11:43

С ним намного легче работать клиентам. Не надо заботиться о формировании запроса и использовать сторонние средства.

hats 23 июл 2013 в 11:47

Изначально из-за того, чтобы самостоятельно не заниматься валидацией приходящих данных. Написал один раз схему и дальше получаю удовольствие, т.к. мой валидатор на PHP врятли будет быстрей нативных методов PHP. Также, надеялся облегчить себе работу путем использования уже готовых классов (опять же нативных), с помощью которых можно реализовать клиент и сервер буквально в несколько строк кода.
Но по ходу ковыряния выяснилось о некоторых недочетах в работе встроенных классов.

Alexufo 23 июл 2013 в 18:28

Само гонение XML по HTTP туды сюды не выходит шило на мыло с не нативными функциями по времени? Не знаю конечно как сравнивать… просто тут тоже надо сравнивать.

liaren 25 июл 2013 в 20:21

Вы ведь имели введу JSON-RPC 2.0?)

afi 23 июл 2013 в 10:31

Насколько я помню, механизм аутентификации базируется на спецификации SOAP Message Security 1.0 (WS-Security 2004) docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
Т.е. вам нужно реализовать на клиенте возможность отправлять дополнительные заголовки в пакете, а сервер научить их правильно обрабатывать. Вероятно, сейчас в сети можно найти множество готовых решений.

hats 23 июл 2013 в 11:12

Спасибо! Но я имел немного другое.
Если читать доки по SoapClient, то в них написано о том, что при создании нового объекта от данного класса, то мы можем в качестве параметров передавать на сервер некий login и password. Но когда я их добавляю в параметры, то в пришедшем на сервер конверте нет раздела Header с данными для авторизации.

Поэтому и был вопрос к знатокам. Можно ли посредством SoapClient передать авторизационные данные предусмотренные спецификацией протокола? И если можно, то как.

afi 23 июл 2013 в 13:01

По всей видимости, это логин и пароль для HTTP аутентификации, т.е. BASIC или DIGEST. Тип аутентификации задается опцией authentication.

Piskov 23 июл 2013 в 10:34

Господи, спасибо тебе за WCF (а еще за Web API, если отвлечься от SOAP).

hats 23 июл 2013 в 11:18

Но знать как все это устроено не помешает. А так, ребята из Редмонда молодцы

PsychodelEKS 23 июл 2013 в 10:35

Библиотеку nusoap попробуйте, если так нужен SOAP. Она кривовата, но дело свое делает.

hats 23 июл 2013 в 11:28

Если честно, то данный пост имеет некоторый корыстный замысел.
Им я хотел обратить внимание разработчиков PHP (в особенности тех, которые делали модуль php-soap) на их детище и имеющиеся в нем недочеты. Я очень сильно надеюсь, что на хабре есть люди имеющие хотя бы отдаленное отношение к разработке PHP. И возможно, они как-то смогут поспособствовать в скорейшей доработке столь замечательного начинания!

Tampllier 23 июл 2013 в 11:16

Для тех кому интересно — 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>

NeX 23 июл 2013 в 11:36

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 ();

kostyl 23 июл 2013 в 16:36

Более того, это нужно делать и не важно чем, а не руками набирать. Руками всё делать — прошлый век.

Tampllier 23 июл 2013 в 11:45

Еще, в .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>

kirksa 23 июл 2013 в 12:17

Руками писать wsdl — моветон имхо. Каждое добавление/изменение метода — нужно править не очень интуитивный текст. Лучше определить фасад и по нему генерировать wsdl.

dezconnect 23 июл 2013 в 12:36

Статья отличная, но я бы предпочел более строгую подачу материала, без «фамильярностей».

PS: правильно ли я понял что класс подгружаемый через setClass подгружается автолоадером, и там уже описана функция отправки?

hats 23 июл 2013 в 14:11

Да, вы все абсолютно правильно понимаете!
Еще мной был только-что обнаружен довольно досадный факт — оказывается, я забыл в тексте статьи привести листинг этого класса.
Но по этому поводу не стоит расстраиваться, т.к. весь используемый в топике набор скриптов лежит в моем репозитории на GitHub'е (включая класс SoapSmsGateWay). Ссылка на репозиторий расположена в последнем перечислении списка литературы.

DaFive 24 июл 2013 в 09:23

Мы отказались в свое время от XML, объём данных слишком большой. Сначала поддерживали его, но когда траффик возрос до многих миллионов СМС — всё это обрабатывать оказалось накладно. Слишком много «лишних» данных в запросах-ответах клиент-сервер-клиент.

Lion_son 4 мар 2015 в 04:31

Если не секрет, то чем заменили XML в своей системе?
Перешли на JSON или что-то другое?

DaFive 4 мар 2015 в 09:10

Да, JSON, секрета нет :)

Lion_son 3 мар 2015 в 15:19

Огромное спасибо автору за труд!
Статья очень помогла в понимании связки XML Schema, WSDL, SOAP
Сам приступил к изучению SOAP недавно, тема очень широкая.

P.S. Если кто вдруг не знает, есть отличный инструмент для тестирования SOAP сервисов SOAP UI. Он по WSDL генерирует стабы для запросов и тест-кейсов.
Я оценил

Зарегистрируйтесь на Хабре, чтобы оставить комментарий