Фон:
Я создаю сайт webservices, который будет предоставлять множество типов простых сервисов поверх SOAP и, возможно, других протоколов. Цель состоит в том, чтобы упростить работу, например, конверсии, синтаксический анализ RSS, проверки спама и многие другие виды работы. Сайт будет ориентирован в основном на начинающих разработчиков.
Моя проблема:
Я никогда не разрабатывал ни С#, ни.NET. Я несколько лет назад взломал несколько VB6, но это так. Теперь мне нужно несколько примеров выполнения RPC-вызовов через SOAP в С# . Я попытался найти в Интернете и Stack Overflow, чтобы найти это, но не нашел много ресурсов, и я понятия не имею, как ранжировать ресурсы (которые являются старыми?, которые являются неправильными? И т.д.).
Я создал простую примерную службу, которая в PHP называется так:
getCurrentYear(); //This method returns an integer, called "year" ?>
Теперь я хочу называть этот метод как можно проще на С#. Все ссылки и примеры очень приветствуются. С чего бы мне начать? Какие классы/модули/что я могу использовать?
Решение не обязательно должно включать SOAP вообще, если есть лучшие коммуникационные рамки (задняя часть предназначена для расширения), но обратите внимание, что серверная сторона реализована в PHP на Unix, поэтому запатентованные решения Microsoft из вопрос на стороне сервера.
Обратите внимание, что мне это нужно, поэтому я могу написать документацию, возможную для J. Random Web Developer, чтобы следовать (даже если они находятся на общедоступном веб-хостинге). Поэтому я считаю, что лучший подход должен заключаться в том, чтобы делать это только в коде, но даже другие способы сделать это, конечно, приветствуются.
6 ответов
Как я понимаю, вы хотите вызвать свой веб-сервис из клиентского приложения С#. У вас уже есть служба и опубликованный файл WSDL (исправьте меня, если я ошибаюсь). Теперь самый простой способ - создать прокси-классы в приложении С# (этот процесс называется добавлением служебной ссылки). Есть два основных способа сделать это:.NET предоставляет службы ASP.NET, который является старым способом SOA и WCF, как предложил Джон, который является последней средой от MS и предоставляет множество протоколов, включая открытые и MS-приложения.
Теперь достаточно теории и давайте делать это шаг за шагом
Service1Client service = new Service1Client();
int year = service.getCurrentYear();
Надеюсь, что это поможет, если вы столкнетесь с какой-либо проблемой, сообщите нам.
Я сделал довольно много того, о чем вы говорите, и SOAP-совместимость между платформами имеет одно основное правило: CONTRACT FIRST. Не выводите WSDL из кода, а затем пытайтесь создать клиент на другой платформе. Все, что больше, чем функции типа "Hello World", скорее всего, не сгенерирует код, не сможет говорить во время выполнения или (мой любимый), не сможет правильно отправить или получить все данные без повышения ошибки.
Тем не менее, WSDL - это сложный, неприятный материал, и я избегаю писать его с нуля, когда это возможно. Ниже приведены некоторые рекомендации по надежному взаимодействию служб (с использованием веб-ссылок, WCF, Axis2/Java, WS02, Ruby, Python и т.д.):
Если вы можете заставить его работать в браузере, то что-то простое, как это работает
Var webRequest = WebRequest.Create(@"http://webservi.se/year/getCurrentYear"); using (var response = webRequest.GetResponse()) { using (var rd = new StreamReader(response.GetResponseStream())) { var soapResult = rd.ReadToEnd(); } }
Посмотрите также на NuSOAP. Если вы сейчас , это инструментарий, позволяющий вам подключаться из PHP к службе WCF.
Я привык писать PHP-код, но не часто использую объектно-ориентированное кодирование. Теперь мне нужно взаимодействовать с SOAP (как клиент), и я не могу правильно получить синтаксис. У меня есть файл WSDL, который позволяет мне правильно настроить новое соединение с использованием класса SoapClient. Тем не менее, я не могу сделать правильный звонок и вернуть данные. Мне нужно отправить следующие (упрощенные) данные:
В документе WSDL есть две функции, но мне нужен только один («FirstFunction» ниже). Вот сценарий, который я запускаю, чтобы получить информацию о доступных функциях и типах:
$client = new SoapClient("http://example.com/webservices?wsdl"); var_dump($client->__getFunctions()); var_dump($client->__getTypes());
И вот результат, который он генерирует:
Array( => "FirstFunction Function1(FirstFunction $parameters)", => "SecondFunction Function2(SecondFunction $parameters)",); array( => struct Contact { id id; name name; } => string "string description" => string "int amount" }
Скажем, я хочу позвонить в FirstFunction с данными:
Какой будет правильный синтаксис? Я пробовал всевозможные варианты, но кажется, что мыльная структура довольно гибкая, поэтому есть очень много способов сделать это. Не удалось понять это из руководства...
ОБНОВЛЕНИЕ 1: опробованный образец из MMK:
$client = new SoapClient("http://example.com/webservices?wsdl"); $params = array("id" => 100, "name" => "John", "description" => "Barrel of Oil", "amount" => 500,); $response = $client->__soapCall("Function1", array($params));
Но я получаю этот ответ: у Object has no "Contact" property . Как вы можете видеть на выходе getTypes() , существует struct называемая Contact , поэтому, я думаю, мне почему-то нужно уточнить, что мои параметры включают данные Contact, но вопрос в следующем: как?
ОБНОВЛЕНИЕ 2: Я также пробовал эти структуры, такую же ошибку.
$params = array(array("id" => 100, "name" => "John",), "Barrel of Oil", 500,);
Так же как:
$params = array("Contact" => array("id" => 100, "name" => "John",), "description" => "Barrel of Oil", "amount" => 500,);
Ошибка в обоих случаях: объект не имеет свойства «Контакт»
Это то, что вам нужно сделать на стороне PHP :
(Протестировано и работает)
id = $id; $this->name = $name; } } /* Initialize webservice with your WSDL */ $client = new SoapClient("http://localhost:10139/Service1.asmx?wsdl"); /* Fill your Contact Object */ $contact = new Contact(100, "John"); /* Set your parameters for the request */ $params = array("Contact" => $contact, "description" => "Barrel of Oil", "amount" => 500,); /* Invoke webservice method with your parameters, in this case: Function1 */ $response = $client->__soapCall("Function1", array($params)); /* Print webservice response */ var_dump($response); ?>
Array ( => Contact Object ( => 100 => John) => Barrel of Oil => 500)
(Как вы можете видеть, Contact объект не является нулевым, а также другими параметрами, что означает, что ваш запрос был успешно выполнен с PHP-стороны).
object (stdClass) public "Function1Result" => string "Подробная информация о вашем запросе! id: 100, имя: John, описание: Barrel of Oil, количество: 500 "(длина = 98)
Надеюсь это поможет:-)
например:
Require_once "WSDLInterpreter-v1.0.0/WSDLInterpreter.php";
$wsdlLocation = "
Я не знаю, почему мой веб-сервис имеет одинаковую структуру с вами, но ему не нужен класс для параметра, просто массив.
Например: - Мой WSDL:
Var_dump($client->getFunctions()); var_dump($client->getTypes());
Вот результат:
Array 0 => string "OrderConfirmation createOrder(OrderRequest $createOrder)" (length=56) array 0 => string "struct OrderRequest { Identification identification; Delivery delivery; Parcel parcel; Receiver receiver; string reference; }" (length=130) 1 => string "struct Identification { string sender; string hash; string originator; }" (length=75) 2 => string "struct Delivery { Node from; Node to; }" (length=41) 3 => string "struct Node { string country; string node; }" (length=46) 4 => string "struct Parcel { string description; decimal weight; string orderNumber; date orderDate; }" (length=93) 5 => string "struct Receiver { string firstName; string surname; Address address; string email; string language; }" (length=106) 6 => string "struct Address { string line1; string line2; string postalCode; string city; string country; }" (length=99) 7 => string "struct OrderConfirmation { string trackingNumber; string reference; }" (length=71) 8 => string "struct OrderServiceException { string code; OrderServiceException faultInfo; string message; }" (length=97)
Так в моем коде:
$client = new SoapClient("http://packandship-ws.kiala.com/psws/order?wsdl"); $params = array("reference" => $orderId, "identification" => array("sender" => param("kiala", "sender_id"), "hash" => hash("sha512", $orderId . param("kiala", "sender_id") . param("kiala", "password")), "originator" => null,), "delivery" => array("from" => array("country" => "es", "node" => "",), "to" => array("country" => "es", "node" => "0299"),), "parcel" => array("description" => "Description", "weight" => 0.200, "orderNumber" => $orderId, "orderDate" => date("Y-m-d")), "receiver" => array("firstName" => "Customer First Name", "surname" => "Customer Sur Name", "address" => array("line1" => "Line 1 Adress", "line2" => "Line 2 Adress", "postalCode" => 28006, "city" => "Madrid", "country" => "es",), "email" => " ", "language" => "es")); $result = $client->createOrder($params); var_dump($result);
но это успешно!
Вы также можете использовать SOAP-сервисы:
"Spain", "CityName" => "Alicante"); $response = $soapclient->getWeather($params); var_dump($response); // Get the Cities By Country $param = array("CountryName" => "Spain"); $response = $soapclient->getCitiesByCountry($param); var_dump($response);
Это пример с реальным сервисом, и он работает.
Надеюсь это поможет.
Сначала инициализируйте веб-службы:
$client = new SoapClient("http://example.com/webservices?wsdl");
Затем установите и передайте параметры:
$params = array ("arg0" => $contactid, "arg1" => $desc, "arg2" => $contactname); $response = $client->__soapCall("methodname", array($params));
Обратите внимание, что имя метода доступно в WSDL в качестве имени операции, например:
Вам нужен многомерный массив, вы можете попробовать следующее:
$params = array(array("id" => 100, "name" => "John",), "Barrel of Oil", 500);
в PHP массив является структурой и очень гибким. Обычно с вызовами мыла я использую оболочку XML так неуверенно, если она будет работать.
То, что вы, возможно, захотите попробовать, это создать json-запрос для отправки или использования этого для создания xml-покупки, следующего за тем, что находится на этой странице: http://onwebdev.blogspot.com/2011/08/php-converting-rss-to-json.html
Вам нужно объявить договор класса
Class Contract { public $id; public $name; } $contract = new Contract(); $contract->id = 100; $contract->name = "John"; $params = array("Contact" => $contract, "description" => "Barrel of Oil", "amount" => 500,);
$params = array($contract, "description" => "Barrel of Oil", "amount" => 500,);
$response = $client->__soapCall("Function1", array("FirstFunction" => $params));
$response = $client->__soapCall("Function1", $params);
Большой вопрос, потому что многие разработчики, даже опытные, смущены тем, как PHP обрабатывает массивы в циклах foreach. В стандартном цикле foreach PHP создает копию массива, который используется в цикле. Копия отбрасывается сразу же после завершения цикла. Это прозрачно в работе простого цикла foreach. Например:
$set = array("apple", "banana", "coconut"); foreach ($set AS $item) { echo "{$item}\n"; }
Эти результаты:
Apple banana coconut
Таким образом, копия создается, но разработчик не замечает, потому что исходный массив не ссылается в цикле или после завершения цикла. Однако, когда вы пытаетесь изменить элементы в цикле, вы обнаружите, что они не изменены при завершении:
$set = array("apple", "banana", "coconut"); foreach ($set AS $item) { $item = strrev ($item); } print_r($set);
Эти результаты:
Array ( => apple => banana => coconut)
Любые изменения от оригинала не могут быть отмечены, на самом деле никаких изменений с оригиналом не происходит, даже если вы явно присвоили значение $ item. Это связано с тем, что вы работаете над $ item, поскольку он отображается в копии $ set, над которым работает. Вы можете переопределить это, захватив $ item по ссылке, например:
$set = array("apple", "banana", "coconut"); foreach ($set AS &$item) { $item = strrev($item); } print_r($set);
Эти результаты:
Array ( => elppa => ananab => tunococ)
Таким образом, это очевидно и наблюдаемо, когда $ item работает по ссылке, изменения, внесенные в $ item, производятся членам исходного набора $ set. Использование $ item по ссылке также не позволяет PHP создавать копию массива. Чтобы проверить это, сначала мы покажем быстрый скрипт, демонстрирующий копию:
$set = array("apple", "banana", "coconut"); foreach ($set AS $item) { $set = ucfirst($item); } print_r($set);
Эти результаты:
Array ( => apple => banana => coconut => Apple => Banana => Coconut)
Как показано в примере, PHP скопировал $ set и использовал его для перебора, но когда в цикле был использован $ set, PHP добавил переменные в исходный массив, а не в скопированный массив. В принципе, PHP использует только скопированный массив для выполнения цикла и назначения $ item. Из-за этого цикл выше выполняется только 3 раза и каждый раз добавляет другое значение в конец исходного набора $, оставляя исходный $ set с 6 элементами, но никогда не вступая в бесконечный цикл.
Однако, что, если бы мы использовали $ item по ссылке, как я уже упоминал ранее? Один символ добавлен к вышеуказанному тесту:
$set = array("apple", "banana", "coconut"); foreach ($set AS &$item) { $set = ucfirst($item); } print_r($set);
Результаты в бесконечном цикле. Обратите внимание, что это фактически бесконечный цикл, вам придется либо убить сценарий самостоятельно, либо дождаться завершения работы вашей ОС. Я добавил следующую строку в мой скрипт, поэтому у PHP будет очень быстро закончиться память, я предлагаю вам сделать то же самое, если вы собираетесь запускать эти бесконечные тесты цикла:
Ini_set("memory_limit","1M");
Итак, в этом предыдущем примере с бесконечным циклом мы видим причину, по которой PHP был написан, чтобы создать копию массива для перебора. Когда копия создается и используется только по структуре самой конструкции цикла, массив остается статичным во время выполнения цикла, поэтому вы никогда не столкнетесь с проблемами.
Всем привет!
Так случилось, что в последнее время я стал заниматься разработкой веб-сервисов. Но сегодня топик не обо мне, а о том, как нам написать свой XML Web Service основанный на протоколе SOAP 1.2.
Я надеюсь, что после прочтения топика вы сможете самостоятельно:
И все же, я что-то забыл! Если еще немного порефлексировать, то стоит отметить, что клиент за раз может отправить на сервер как одно sms-сообщение, так и некоторое их количество. Другими словами, в одном пакете данных может быть от одного до бесконечности сообщений.
В результате мы получаем, что для отправки sms-сообщения нам необходимы следующие данные:
На первый вопрос мы ответили, теперь необходимо ответить на второй вопрос. И пожалуй, я позволю себе немного с халтурить. Поэтому, с сервера мы будем присылать только булевы данные, значение которых имеет следующий смысл:
На этом мы закончили описание постановки задачи! И наконец-то приступим к самому интересному – будем разбираться что за диковинный зверь этот SOAP!
И начну я свое повествование с того, что данный протокол обмена данными относится к подмножеству протоколов основанных на так называемой парадигме RPC (Remote Procedure Call, удалённый вызов процедур) антиподом которой является REST (Representational State Transfer, передача репрезентативного состояния). Более подробно об этом можно прочесть в Wikipedia, ссылки на статьи находятся в самом конце топика. Из этих статей нам надо уяснить следующее: «Подход RPC позволяет использовать небольшое количество сетевых ресурсов с большим количеством методов и сложным протоколом. При подходе REST количество методов и сложность протокола строго ограничены, из-за чего количество отдельных ресурсов может быть большим». Т.е., применительно к нам это означает, что на сайте в случае RPC подхода будет всегда один вход (ссылка) на сервис и какую процедуру вызывать для обработки поступающих данных мы передаем вместе с данными, в то время как при REST подходе на нашем сайте есть много входов (ссылок), каждая из которых принимает и обрабатывает только определенные данные. Если кто-то из читающих знает, как еще проще объяснить различие в данных подходах, то обязательно пишите в комментариях!
Следующее, что нам надо узнать про SOAP – данный протокол в качестве транспорта использует тот самый XML, что с одной стороны очень хорошо, т.к. сразу же в наш арсенал попадает вся мощь стека технологий основанных на данном языке разметки, а именно XML-Schema – язык описания структуры XML-документа (спасибо Wikipedia!), который позволяет производит автоматическую валидацию поступающих на сервер данных от клиентов.
И так, теперь мы знаем, что SOAP – протокол используемый для реализации удаленного вызова процедур и в качестве транспорта он использует XML! Если почитать статью на Wikipedia, то оттуда можно узнать еще и о том, что он может использоваться поверх любого протокола прикладного уровня, а не только в паре с HTTP (к сожалению, в данном топике мы будем рассматривать только SOAP поверх HTTP). И знаете, что мне во всем этом больше всего нравится? Если нет никаких догадок, то я дам подсказку – SOAP!… Всеравно не появилось догадок?… Вы точно прочли статью на Wikipedia?… В общем, не буду вас дальше мучить. Поэтому, сразу перейду к ответу: «SOAP (от англ. Simple Object Access Protocol - простой протокол доступа к объектам; вплоть до спецификации 1.2 )». Самое примечательное в этой строчке выделено курсивом! Я не знаю какие выводы сделали вы из всего этого, но мне видится следующее – поскольку данный протокол ну никак нельзя назвать «простым» (и видимо с этим согласны даже в w3), то с версии 1.2 он вообще перестал как-то расшифровываться! И стал называться SOAP, просто SOAP и точка.
Ну да ладно, прошу меня извинить, занесло немного в сторону. Как я писал ранее, в качестве транспорта используется XML, а пакеты, которые курсируют между клиентом и сервером называются SOAP-конвертами. Если рассматривать обобщенную структуру конверта, то он вам покажется очень знакомым, т.к. напоминает структуру HTML-страницы. В нем есть основной раздел – Envelop
, который включает разделы Header
и Body
, либо Fault
. В Body
передаются данные и он является обязательным разделом конверта, в то время как Header
является опциональным. В Header
может передаваться авторизация, либо какие-либо иные данные, которые на прямую не относятся к входным данным процедур веб-сервиса. Про Fault
особо рассказывать нечего, кроме того, что он приходит в клиент с сервера в случае возникновения каких-либо ошибок.
На этом мой обзорный рассказ про протокол SOAP заканчивается (более детально сами конверты и их структуру мы рассмотрим когда наши клиент и сервер наконец-то научатся запускать их друг в друга) и начинается новый – про компаньона SOAP под названием WSDL (Web Services Description Language). Да-да, это та самая штука, которая отпугивает большинство из нас от самой попытки взять и реализовать свое API на данном протоколе. В результате чего, мы обычно изобретаем свой велосипед с JSON в качестве транспорта. И так, что такое WSDL? WSDL – язык описания веб-сервисов и доступа к ним, основанный на языке XML (с) Wikipedia. Если из этого определения вам не становится понятным весь сакральный смысл данной технологии, то я попытаюсь описать его своими словами!
WSDL предназначен для того, чтобы наши клиенты могли нормально общаться с сервером. Для этого в файле с расширением «*.wsdl» описывается следующая информация:
Основная задачи схемы – описать структуру данных которые мы собираемся обрабатывать. Все данные в XML-схемах делятся на простые (скалярные) и коплексные (структуры) типы. К простым типам относятся такие типы как:
Предлагаю далеко не ходить и написать XML-схему для нашего sms-сообщения! Ниже представлено xml-описание sms-сообщения:
Схема нашего комплексного типа будет выглядеть следующим образом:
Эта запись читается следующим образом: у нас есть переменная «message
» типа «Message
» и есть комплексный тип с именем «Message
», который состоит из последовательного набора элементов «phone
» типа string
, «text
» типа string
, «date
» типа dateTime
, «type
» типа decimal
. Эти типы простые и уже определены в описании схемы. Поздравляю! Мы только что написали нашу первую XML-схему!
Думаю, что значение элементов «element » и «complexType » вам стало все более-менее понятно, поэтому не будем на них больше заострять внимание и переключимся сразу же на элемент-композитор «sequence ». Когда мы используем элемент-композитор «sequence » мы сообщаем о том, что элементы включенные в него должны всегда располагаться в указанной в схеме последовательности, а также все из них являются обязательными. Но не стоит отчаиваться! В XML-схемах есть еще два элемента-композитора: «choice » и «all ». Композитор «choice » сообщает о том, что должен быть какой-то один из перечисленных в нем элементов, а композитор «all » – любая комбинация перечисленных элементов.
Как вы помните, то в первом разделе топика мы договорились о том, что в пакете может передаваться от одного до бесконечности sms-сообщений. Поэтому предлагаю разобраться как такие данные декларируются в XML-схеме. Общая структура пакета может выглядеть следующим образом:
Схема для такого комплексного типа будет выглядеть так:
В первом блоке идет знакомое нам декларирование комплексного типа «Message
». Если вы заметили, то в каждом простом типе, входящем в «Message
», были добавлены новые уточняющие атрибуты «minOccurs
» и «maxOccurs
». Как не трудно догадаться из названия, первый (minOccurs
) сообщает о том, что в данной последовательности должно быть минимум по одному элементу типа «phone
», «text
», «date
» и «type
», в то время как следующий (maxOccurs
) атрибут нам декларирует, что таких элементов в нашей последовательности максимум по-одному. В результате, когда мы пишем свои схемы для каких-либо данных, нам предоставляется широчайший выбор по их настройке!
Второй блок схемы декларирует элемент «messageList » типа «MessageList ». Видно, что «MessageList » представляет собой комплексный тип, который включает минимум один элемент «message », но максимальное число таких элементов не ограничено!
Вообще, для того, чтобы у нас все работало правильно нам надо передавать клиенту WSDL-файл с правильным MIME-типом. Для этого необходимо настроить ваш веб-сервер соответствующим образом, а именно – установить для файлов с расширением «*.wsdl» MIME-тип равный следующей строке:
Application/wsdl+xml
Но на практике, я обычно отправлял посредством PHP HTTP-заголовок«text/xml
»:
Header("Content-Type: text/xml; charset=utf-8");
и все прекрасно работало!
Хочу сразу предупредить, наш простенький веб-сервис будет иметь довольно внушительное описание, поэтому не пугайтесь, т.к. большая часть текста является обязательной водой и написав ее один раз можно постоянно копировать от одного веб-сервиса к другому!
Поскольку WSDL – это XML, то в самой первой строке необходимо прямо об этом и написать. Корневой элемент файла всегда должен называться «definitions »:
Обычно, WSDL состоит из 4-5 основных блоков. Самый первый блок – определение веб-сервиса или другими словами – точки входа.
Здесь написано, что у нас есть сервис, который называется – «SmsService
». В принципе, все имена в WSDL-файле могут быть вами изменены на какие только пожелаете, т.к. они не играют абсолютно никакой роли.
После этого мы объявляем о том, что в нашем веб-сервисе «SmsService » есть точка входа («port»), которая называется «SmsServicePort ». Именно в эту точку входа и будут отправляться все запросы от клиентов к серверу. И указываем в элементе «address » ссылку на файл-обработчик, который будет принимать запросы.
После того, как мы определили веб-сервис и указали для него точку входа – необходимо привязать к нему поддерживаемые процедуры:
Для этого перечисляется какие операции и в каком виде у будут вызываться. Т.е. для порта «SmsServicePort
» определена привязка под именем «SmsServiceBinding
», которая имеет тип вызова «rpc
» и в качестве протокола передачи (транспорта) используется HTTP. Т.о., мы здесь указали, что будем осуществлять RPC вызов поверх HTTP. После этого мы описываем какие процедуры (operation
) поддерживаются в веб-сервисе. Мы будем поддерживать всего одну процедуру – «sendSms
». Через эту процедуру будут отправляться на сервер наши замечательные сообщения! После того, как была объявлена процедура, необходимо указать в каком виде будут передаваться данные. В данном случае указано, что будут использоваться стандартные SOAP-конверты.
После этого нам необходимо привязать процедуру к сообщениям:
Для этого мы указываем, что наша привязка («binding») имеет тип «SmsServicePortType
» и в элементе «portType
» с одноименным типу именем указываем привязку процедур к сообщениям. И так, входящее сообщение (от клиента к серверу) будет называться «sendSmsRequest
», а исходящее (от сервера к клиенту) «sendSmsResponse
». Как и все имена в WSDL, имена входящих и исходящих сообщения – произвольные.
Теперь нам необходимо описать сами сообщения, т.е. входящие и исходящие:
Для этого мы добавляем элементы «message
» с именами «sendSmsRequest
» и «sendSmsResponse
» соответственно. В них мы указываем, что на вход должен прийти конверт, структура которого соответствует типу данных «Request
». После чего с сервера возвращается конверт содержащий тип данных – «Response
».
Теперь надо сделать самую малость – добавить описание данных типов в наш WSDL-файл! И как вы думаете, как описываются в WSDL входящие и исходящие данные? Думаю, что вы уже все давно поняли и сказали сами себе, что при помощи XML-схем! И вы будете абсолютно правы!
Можно нас поздравить! Наш первый WSDL был написан! И мы еще на один шаг приблизились к достижению поставленной цели.
Далее мы разберемся с тем, что нам предоставляет PHP для разработки собственных распределенных приложений.
После того, как все было установлено и настроено нам необходимо будет создать в корневой папке вашего хостинга файл «smsservice.php » со следующим содержанием:
setClass("SoapSmsGateWay");
//Запускаем сервер
$server->handle();
То, что находится выше строчки с функцией «ini_set», надеюсь, что объяснять не надо. Т.к. там определяется какие HTTP-заголовки мы будем отправлять с сервера клиенту и настраивается окружение. В строчке с «ini_set» мы отключаем кеширование WSDL-файла для того, чтобы наши изменения в нем сразу же вступали в действие на клиенте.
Теперь мы подошли к серверу! Как видим, весь SOAP-сервер занимает всего лишь три строки! В первой строке мы создаем новый экземпляр объекта SoapServer и передаем ему в конструктор адрес нашего WSDL-описания веб-сервиса. Теперь мы знаем, что он будет располагаться в корне хостинга в файле с говорящим именем «smsservice.wsdl.php ». Во второй строке мы сообщаем SOAP-серверу какой класс необходимо дергать для того, чтобы обработать поступивший с клиента конверт и вернуть конверт с ответом. Как вы могли догадаться, именно в этом классе будет описан наш единственный метод sendSms . В третьей строке мы запускаем сервер! Все, наш сервер готов! С чем я нас всех и поздравляю!
Теперь нам необходимо создать WSDL-файл. Для этого можно либо просто скопировать его содержимое из предыдущего раздела, либо позволить себе вольности и немного его «шаблонизировать»:
";
?>
На этом этапе получившийся сервер нас должен устроить полностью, т.к. поступающие к нему конверты мы можем логировать и потом спокойно анализировать приходящие данные. Для того, чтобы мы могли что-либо получать на сервер, нам необходим клиент. Поэтому давайте им и займемся!
messageList = new MessageList();
$req->messageList->message = new Message();
$req->messageList->message->phone = "79871234567";
$req->messageList->message->text = "Тестовое сообщение 1";
$req->messageList->message->date = "2013-07-21T15:00:00.26";
$req->messageList->message->type = 15;
$client = new SoapClient("http://{$_SERVER["HTTP_HOST"]}/smsservice.wsdl.php",
array("soap_version" => SOAP_1_2));
var_dump($client->sendSms($req));
Опишем наши объекты. Когда мы писали WSDL в нем для входящего на сервер конверта описывались три сущности: Request
, MessageList
и Message
. Соответственно классы Request
, MessageList
и Message
являются отражениями этих сущностей в нашем PHP-скрипте.
После того, как мы определили объекты, нам необходимо создать объект ($req
), который будем отправлять на сервер. После чего идут две самые заветные для нас строки! Наш SOAP-клиент! Верите или нет, но этого достаточно для того, чтобы на наш сервер начали сыпаться сообщения от клиента, а также для того, чтобы наш сервер успешно их принимал и обрабатывал! В первой из них мы создаем экземпляр класса SoapClient и передаем в его конструктор адрес расположения WSDL-файла, а в параметрах явно указываем, что работать мы будем по протоколу SOAP версии 1.2. В следующей строке мы вызываем метод sendSms
объекта $client
и сразу же выводим в браузере результат.
Давайте запусти и посмотрим что-же у нас наконец-то получилось!
Мне с сервера вернулся следующий объект:
Object(stdClass)
public "status" => boolean true
И это замечательно, т.к. теперь мы точно знаем о том, что наш сервер работает и не просто работает, но еще и может возвращать на клиент какие-то значения!
Теперь посмотрим на лог, который мы предусмотрительно ведем на серверной стороне! В первой его части мы видим необработанные данные, которые поступили на сервер:
Это и есть конверт. Теперь вы знаете как он выглядит! Но постоянно на него любоваться нам вряд ли будет интересно, поэтому давайте десереализуем объект из лог-файла и посмотрим все ли у нас хорошо:
Object(stdClass)
public "messageList" =>
object(stdClass)
public "message" =>
object(stdClass)
public "phone" => string "79871234567" (length=11)
public "text" => string "Тестовое сообщение 1" (length=37)
public "date" => string "2013-07-21T15:00:00.26" (length=22)
public "type" => string "15" (length=2)
Как видим, объект десериализовался правильно, с чем я нас всех хочу поздравить! Далее нас ждет что-то более интересно! А именно – мы будем отправлять клиентом на сервер не одно sms-сообщение, а целую пачку (если быть точнее, то целых три)!
// создаем объект для отправки на сервер
$req = new Request();
$req->messageList = new MessageList();
$msg1 = new Message();
$msg1->phone = "79871234567";
$msg1->text = "Тестовое сообщение 1";
$msg1->date = "2013-07-21T15:00:00.26";
$msg1->type = 15;
$msg2 = new Message();
$msg2->phone = "79871234567";
$msg2->text = "Тестовое сообщение 2";
$msg2->date = "2014-08-22T16:01:10";
$msg2->type = 16;
$msg3 = new Message();
$msg3->phone = "79871234567";
$msg3->text = "Тестовое сообщение 3";
$msg3->date = "2014-08-22T16:01:10";
$msg3->type = 17;
$req->messageList->message = $msg1;
$req->messageList->message = $msg2;
$req->messageList->message = $msg3;
В наших логах числится, что пришел следующий пакет от клиента:
Что за ерунда, скажете вы? И будете правы в некотором смысле, т.к. только что мы узнали о том, что какой объект ушел от клиента, то абсолютно в том же виде он пришел к нам на сервер в виде конверта. Правда, sms-сообщения сериализовались в XML не так, как нам было необходимо – они должны были быть обернуты в элементы message
, а не в Struct
. Теперь посмотрим в каком виде приходит такой объект в метод sendSms
:
Object(stdClass)
public "messageList" =>
object(stdClass)
public "message" =>
object(stdClass)
public "Struct" =>
array (size=3)
0 =>
object(stdClass)
public "phone" => string "79871234567" (length=11)
public "text" => string "Тестовое сообщение 1" (length=37)
public "date" => string "2013-07-21T15:00:00.26" (length=22)
public "type" => string "15" (length=2)
1 =>
object(stdClass)
public "phone" => string "79871234567" (length=11)
public "text" => string "Тестовое сообщение 2" (length=37)
public "date" => string "2014-08-22T16:01:10" (length=19)
public "type" => string "16" (length=2)
2 =>
object(stdClass)
public "phone" => string "79871234567" (length=11)
public "text" => string "Тестовое сообщение 3" (length=37)
public "date" => string "2014-08-22T16:01:10" (length=19)
public "type" => string "17" (length=2)
Что нам дает это знание? Только то, что выбранный нами путь не является верным и мы не получили ответа на вопрос – «Как нам на сервере получить правильную структуру данных?». Но я предлагаю не отчаиваться и попробовать привести наш массив к типу объект
:
$req->messageList->message = (object)$req->messageList->message;
В этом случае, нам придет уже другой конверт:
Пришедший в метод sendSms
объект имеет следующую структуру:
Object(stdClass)
public "messageList" =>
object(stdClass)
public "message" =>
object(stdClass)
public "BOGUS" =>
array (size=3)
0 =>
object(stdClass)
public "phone" => string "79871234567" (length=11)
public "text" => string "Тестовое сообщение 1" (length=37)
public "date" => string "2013-07-21T15:00:00.26" (length=22)
public "type" => string "15" (length=2)
1 =>
object(stdClass)
public "phone" => string "79871234567" (length=11)
public "text" => string "Тестовое сообщение 2" (length=37)
public "date" => string "2014-08-22T16:01:10" (length=19)
public "type" => string "16" (length=2)
2 =>
object(stdClass)
public "phone" => string "79871234567" (length=11)
public "text" => string "Тестовое сообщение 3" (length=37)
public "date" => string "2014-08-22T16:01:10" (length=19)
public "type" => string "17" (length=2)
Как по мне, то «от перемены мест слагаемых – сумма не меняется» (с). Что BOGUS
, что Struct
– цель нами до сих пор не достигнута! А для ее достижения нам необходимо сделать так, чтобы вместо этих непонятных названий отображалось наше родное message
. Но как этого добиться, автору пока не известно. Поэтому единственное, что мы можем сделать – избавить от лишнего контейнера. Другими словами, мы сейчас сделаем так, чтобы вместо message
стал BOGUS
! Для этого изменим объект следующим образом:
// создаем объект для отправки на сервер
$req = new Request();
$msg1 = new Message();
$msg1->phone = "79871234567";
$msg1->text = "Тестовое сообщение 1";
$msg1->date = "2013-07-21T15:00:00.26";
$msg1->type = 15;
$msg2 = new Message();
$msg2->phone = "79871234567";
$msg2->text = "Тестовое сообщение 2";
$msg2->date = "2014-08-22T16:01:10";
$msg2->type = 16;
$msg3 = new Message();
$msg3->phone = "79871234567";
$msg3->text = "Тестовое сообщение 3";
$msg3->date = "2014-08-22T16:01:10";
$msg3->type = 17;
$req->messageList = $msg1;
$req->messageList = $msg2;
$req->messageList = $msg3;
$req->messageList = (object)$req->messageList;
Вдруг нам повезет и из схемы подтянется правильное название? Для этого посмотрим на пришедший конверт:
Да, чуда не произошло! BOGUS
– не победим! Пришедший в sendSms
объект в этом случае будет выглядеть следующим образом:
Object(stdClass)
public "messageList" =>
object(stdClass)
public "BOGUS" =>
array (size=3)
0 =>
object(stdClass)
public "phone" => string "79871234567" (length=11)
public "text" => string "Тестовое сообщение 1" (length=37)
public "date" => string "2013-07-21T15:00:00.26" (length=22)
public "type" => string "15" (length=2)
1 =>
object(stdClass)
public "phone" => string "79871234567" (length=11)
public "text" => string "Тестовое сообщение 2" (length=37)
public "date" => string "2014-08-22T16:01:10" (length=19)
public "type" => string "16" (length=2)
2 =>
object(stdClass)
public "phone" => string "79871234567" (length=11)
public "text" => string "Тестовое сообщение 3" (length=37)
public "date" => string "2014-08-22T16:01:10" (length=19)
public "type" => string "17" (length=2)
Как говорится – «Почти»! На этой (немного печальной) ноте предлагаю потихонечку закругляться и сделать некоторые для себя выводы.
In this example we will see an example of a SOAP client communicating with a server. SOAP is one of many web service protocol definition. A web service is a technology that uses a protocol (SOAP in this example) for exchanging data between applications over the network.
If we are developing a client for consuming a web service, we have to look at the protocol that the service is using. This example is for looking at the resources provided by PHP for developing a client for a web service implementing the SOAP protocol.
For this example, we will use:
Below, commands to install Apache and PHP are shown:
Sudo apt-get update sudo apt-get install apache2 php5 libapache2-mod-php5 sudo service apache2 restart
Even if it’s not necessary, is recommendable to disable the SOAP WSDL cache for development environments. In /etc/php5/apache2/php.ini file, set the soap.wsdl_cache_enabled directive to 0:
php.ini
Soap.wsdl_cache_enabled=0
Don’t forget to restart Apache after doing any change.
Note: if you want to use Windows, installing XAMPP is the fastest and easiest way to install a complete web server that meets the prerequisites.
SOAP (Simple Object Access Protocol) is a standard protocol that defines how two different objects in different processes can communicate each other, through data exchange in XML format. Is one of the widest protocols used in web services.
In other words, this protocol allows to call method of objects that are defined in remote machines.
The server offering their SOAP services can define them in two different ways:
From the client point of view, there are very few differences, but let’s see how to proceed for each one.
We will consider the following scenario, which is quite typical: a web service that inserts and reads from a database (simulated with a plain text file), for which we will develop a client.
Is responsibility of the server offering the service to let know the protocol used, as same as the available method definitions, in order to let the clients know how to deal with the service.
Even if this tutorial is about the client itself, we will see also the server side, in order to test that the client is actually working.
For this example, we will use the following structure:
Php_soapclient_example/ ├── simple_soap_client_class.php ├── simple_soap_server_class.php ├── handle_soap_request.php ├── no_wsdl │ └── server_endpoint.php └── wsdl ├── server_endpoint.php └── simple_service_definition.wsdl
Where the root directory, php_soapclient_example , will be in the web server’s root directory, which is /var/www/html/ by default.
Briefly explained each file:
Note: the WSDL mode needs a .wsdl file, where the web service is defined. We are not going to see it in this example, since the aim is not to see how to build a WSDL definition file, but it’s also available to download in the last section of the example.
As said, our server will read and write data into a text file. Let’s see it:
simple_soap_server_class.php
", FILE_APPEND); if ($writtenBytes) { $response = "$writtenBytes bytes have been inserted."; } else { $response = "Error inserted data."; } return $response; } /** * Reads data. Invoked remotely from SOAP client. * * @return Data of file. */ public function readData() { $contents = file_get_contents(self::FILENAME); return $contents; } }
So simple, about reading and writing into a text file.
Note the functions this server implements, in lines 16 and 33. This functions will be those invoked by the client.
As we said above, depending of the mode (WSDL or not WSDL), the client has to handle the connection in a different way but, once stablished, the procedure is the same. So, let’s code a class that works for both modes, handling the SoapClient class instantiation accordingly to the mode:
simple_soap_client_class.php
initializeClient($soapMode, $serverLocation); } /** * Instantiates the SoapClient, depending on the specified mode. * * For WSDL, it just has to be instantiated with the location of the service, which actually has to be the * .wsdl location. * * For non-WSDL, the first parameter of the constructor has to be null; and the second, an array specifying * both location and URI (which can be the same, the important parameter is the location). */ protected function initializeClient($soapMode, $serverLocation) { switch ($soapMode) { case self::MODE_WSDL: $this->client = new SoapClient($serverLocation); break; case self::MODE_NO_WSDL: $options = array("location" => $serverLocation, "uri" => $serverLocation); $this->client = new SoapClient(NULL, $options); break; default: throw new Exception("Error: invalid SOAP mode provided."); break; } } /** * Inserts data remotely into the SOAP service. * * @param $data Data to insert remotely. * @return Response from remote service. */ public function insertData($data) { $response = $this->client->insertData($data); return $response; } /** * Reads data from SOAP service. * * @return Data received from remote service. */ public function readData() { return $this->client->readData(); } }
The lines 35 and 45 instantiate the SoapClient class, depending on the $mode received. This is how it works for each mode:
After the instantiation, the communication with the service is pretty simple. We have just to call the methods that we saw defined in SimpleSoapServer class, in simple_soap_client_class.php , through the SoapClient class instance. As we said before, we are calling methods that are defined in other place. What PHP SoapClient does, is to provide us those methods defined by the web service, and, when we call them, it will execute them in the server through the SOAP protocol that it has already implemented, with no needing to care about how it works. Seems magic, doesn’t it?
If you don’t believe it, let’s see a script to use this client.
The following script allows us to use the client to communicate with the service, through GET parameters. These are the parameters available:
handle_soap_request.php
getMessage());
}
return $soapClient;
}
// Flow starts here.
checkGETParametersOrDie(["mode", "action"]);
$mode = $_GET["mode"];
$action = $_GET["action"];
$soapClient = instantiateSoapClient($mode);
switch($action) {
case ACTION_INSERT:
checkGETParametersOrDie();
$value = $_GET;
try {
$response = $soapClient->insertData($value);
echo "Response from SOAP service: $response
";
} catch (Exception $exception) {
die("Error inserting into SOAP service: " . $exception->getMessage());
}
break;
case ACTION_READ:
try {
$data = $soapClient->readData();
echo "Received data from SOAP service:
";
echo $data;
} catch (Exception $exception) {
die("Error reading from SOAP service: " . $exception->getMessage());
}
break;
default:
die("Invalid "action" specified.");
break;
}
If we enter in the browser http://127.0.0.1/php_soapclient_example/handle_soap_request.php?mode=no_wsdl&action=insert&value=testing_no_wsdl , the service will create a no_wsdl/data.txt file (if not exists already), writing the provided value "testing_no_wsdl" , and the following will be printed:
Response from SOAP service: 19 bytes have been inserted.
(The 4 bytes extra correspond to additional
characters inserted into the file).
The service offers a method to reading all the data, so, if we enter in the browser http://127.0.0.1/php_soapclient_example/handle_soap_request.php?mode=no_wsdl&action=read , the following will be printed:
Received data from SOAP service:
testing_no_wsdl
We can check it also for WSDL mode, setting mode=wsdl in the parameters.
As said in section 3, when we are developing a web service client (no matter if SOAP, REST, etc.), the service provider has to provide also documentation about the available methods; we need to know the definition of these: which parameters is expecting, af if it returns something. Because of that, the most usual way to develop a SOAP web service is using WSDL files, to provide documentation of the available methods. In any case, the SoapClient has a method to get the available methods, for debugging purposes, named __getFunctions() . So, we could see the offered methods by the service with the following:
Var_dump($soapClient->__getFunctions())
Assuming that $soapClient has been instanced properly.
Also note that, if the service does not offer an encrypted connection, the communication between the client and the server will be made in plain text. So, if we have to develop a client that has to deal with sensible information, we should ensure that the communication with the server can be considered safe.
We have seen how to develop a client for a SOAP web service using PHP’s SoapClient class. The server may offer the service using WSDL, or not, something to take into account when we are instantiating the SoapClient class. Then, to use the methods provided by the service, we just have to call those methods in SoapClient instance, as they were ours.
Мне нужно подключиться к одному веб-сервису, и это все, что у меня есть:
Пример вызова:
Я знаю, что эта функция возвращает строку;
Это то, что я сделал до сих пор:
Создал Service Reference, добавив только адрес WSDL, указанный в пункте 1.
Создал экземпляр webservice и вызвал функцию со всем необходимым параметром, но не пользователем и паролем для заголовка.
Как мне продолжить? Заранее спасибо.
1 ответ
Это может быть хорошим местом для начала, если вам нужно добавить свои учетные данные; я думаю, вам, возможно, придется, так как вы получили их как-то. Часть, где вы добавляете свои учетные данные, указана ниже:
UsernameToken userToken = new UsernameToken(userName, password, PasswordOption.SendHashed); Service1 serviceProxy = new Service1(); SoapContext requestContext = serviceProxy.RequestSoapContext; requestContext.Security.Tokens.Add(userToken);
Кроме того, я думаю, вы могли бы пропустить часть "? Wsdl" в адресе, поскольку она относится к спецификации веб-сервиса. Как только это будет сделано, вы можете попытаться вызвать функцию и посмотреть, как все это получится: если функция должна что-то вернуть, проверьте, что вы ожидали.