С развитието на Интернет се появи необходимост от създаване на разпределени приложения. Приложенията, инсталирани на компютър, обикновено използват библиотеките, хоствани на него. Една библиотека може да се използва от няколко програми. Възможно ли е да се хостват аналози на библиотеки в мрежата, така че различните сайтове да могат да ги извикват? Оказва се, че да.
Фирмите предоставят разнообразна информация на своите страници. Например от своя уебсайт http://www.Ford.com компанията Ford публикува информация за модели и цени. Търговецът на тази компания би искал да има тази информация на своя уебсайт. Уеб услуга позволява на потребителски сайт да извлича информация от сайт на доставчик. Потребителският сайт показва тази информация на своите страници. Кодът за генериране на тази информация е написан веднъж, но може да се използва от много потребители. Данните са представени в обикновен текст, така че могат да се използват независимо от платформата.
Уеб услугите се използват широко както в настолни, така и в интернет приложения. Те не са приложения сами по себе си, а източници на данни за приложения. Липсват им потребителски интерфейс. Уеб услугите не трябва да се използват в мрежата - те могат да бъдат част от проекта, в който се използват.
Уеб услугите са функционалност и данни, предоставени за използване от външни приложения, които взаимодействат с услугите чрез стандартни протоколи и формати на данни. Уеб услугите са напълно независими от езика и платформата на внедряване. Технологията за уеб услуги е крайъгълният камък на модела за програмиране на Microsoft. NET.
Това по-нататъчно развитие компонентно програмиране CORBA и DCOM. Въпреки това, за да използвате такива компоненти, е необходимо да ги регистрирате в системата на потребителя. Това не се изисква за уеб услуги. Компонентите работят добре в локални мрежи. HTTP протоколът не е подходящ за отдалечени извиквания на процедури (RPC). Дори в рамките на една и съща организация, различни операционна система, който може да комуникира само през HTTP.
Бяха направени няколко опита за създаване на език за комуникация между хетерогенни системи - DCOM, CORBA, RMI, IIOP. Те не получиха общо признание, тъй като всеки беше популяризиран от различен производител и следователно беше обвързан с технологията на конкретен производител. Никой не искаше да приеме нечий друг стандарт. За да разрешат тази дилема, няколко компании се съгласиха да разработят независим от доставчика стандарт за съобщения през HTTP. През май 2000 г. IBM, Microsoft, HP, Lotus, SAP, UserLand и други се обърнаха към W3C и предложиха SOAP като кандидат за такъв стандарт. SOAP революционизира разработването на приложения чрез сливане на два интернет стандарта, HTTP и XML.
САПУН
SOAP протоколът, базиран на XML, се използва за взаимодействие с уеб услуги. Би било възможно да се използва само XML, но това е твърде свободен формат, в който всеки документ всъщност създава свой собствен език. САПУНе конвенция за формата на XML документ, за наличието на определени елементи и пространства от имена в него.
SOAP ви позволява да публикувате и консумирате сложни структури от данни като DataSet. В същото време е лесно да се научи. Сегашна версия SOAP-1.2.
SOAP е прост протокол за достъп до обекти. SOAP е проектиран да улесни комуникацията на приложенията през HTTP. Това е специален независим от платформата формат за интернет съобщения. SOAP съобщението е просто обикновен XML документ. Стандартно
Лирическа част.
Представете си, че сте внедрили или внедрявате определена система, която трябва да е достъпна отвън. Тези. има определен сървър, с който трябва да комуникирате. Например уеб сървър.
Този сървър може да извършва много действия, да работи с базата данни, да изпълнява някои заявки на трети страни към други сървъри, да прави някои изчисления и т.н. да живее и евентуално да се развива по неговия добре познат сценарий (т.е. според сценария на разработчиците). За човек не е интересно да общува с такъв сървър, защото може да не може/не иска да дава красиви страници със снимки и друго удобно за потребителя съдържание. Той е написан и работи, за да работи и да издава данни към заявки за него, без да се интересува, че са четими от човека, клиентът сам ще се справи с тях.
Други системи, които имат достъп до този сървър, вече могат да се разпореждат с получените от този сървър данни по своя преценка - обработват, натрупват, издават на своите клиенти и т.н.
Е, една от опциите за комуникация с такива сървъри е SOAP. SOAP XML протокол за съобщения.
Практическа част.
Уеб услуга (това предоставя сървърът и това, което клиентите използват) прави възможно комуникацията със сървъра в добре структурирани съобщения. Факт е, че уеб услугата не приема никакви данни. Всяко съобщение, което не отговаря на правилата, ще бъде върнато от уеб услугата с грешка. Грешката ще бъде, между другото, също под формата на xml с ясна структура (което не може да се каже вярно за текста на съобщението).
WSDL (език за описание на уеб услугите). Правилата, по които се съставят съобщенията за уеб услугата, са описани по същия начин с използвайки xmlи също имат ясна структура. Тези. ако уеб услуга предоставя възможност за извикване на метод, тя трябва да позволи на клиентите да разберат какви параметри се използват за този метод. Ако уеб услугата очаква низ за метода Method1 като параметър и низът трябва да бъде наречен Param1, тогава тези правила ще бъдат посочени в описанието на уеб услугата.
Като параметри могат да се предават не само прости типове, но и обекти, колекции от обекти. Описанието на обекта се свежда до описанието на всеки компонент на обекта. Ако обектът се състои от няколко полета, тогава всяко поле се описва, какъв тип има, името (какви са възможните стойности). Полетата могат да бъдат и от сложен тип и така нататък, докато описанието на типовете завърши с прости - низ, булево, число, дата... Някои специфични типове обаче може да се окажат прости, важно е, че клиентите могат да разберат какви ценности могат да се съдържат в тях.
За клиентите е достатъчно да знаят URL адреса на уеб услугата, wsdl винаги ще бъде наблизо, чрез което можете да получите представа за методите и техните параметри, които предоставя тази уеб услуга.
Какви са предимствата на всички тези камбани и свирки:
- В повечето системи декларирането на методи и типове се извършва в автоматичен режим. Тези. достатъчно е програмистът на сървъра да каже това този методможе да бъде извикан чрез уеб услуга и wsdl описанието ще бъде генерирано автоматично.
Автоматично валидиране.
- xml валидиране. xml трябва да е добре оформен. невалиден xml - веднага грешка на клиента, нека го разбере.
- валидиране на схема. xml трябва да има определена структура. xml не съответства на схемата - веднага грешка на клиента, нека го разбере.
- валидирането на данните се извършва от сървъра за сапун, така че типовете данни и ограниченията да съответстват на описанието.
- Упълномощаване и удостоверяване могат да бъдат приложени отделен метод. нативно. или чрез http оторизация.
- Уеб услугите могат да работят както през сапунен протокол, така и през http, тоест чрез заявки за получаване. Тоест, ако като параметри се използват прости данни (без структура), тогава можете просто да извикате обичайния get www.site.com/users.asmx/GetUser?Name=Vasia или post. Това обаче не винаги и навсякъде.
- ... вижте уикипедия
Описание, което има ясна структура, може да се чете от всеки сапунен клиент. Тези. каквато и да е уеб услугата, клиентът ще разбере какви данни приема уеб услугата. Според това описание клиентът може да изгради своя вътрешна структура от класове на обекти, т.нар. binding" и. В резултат на това програмистът, използващ уеб услугата, трябва да напише нещо като (псевдокод):
NewUser:=TSoapUser.Create("Vasya","Pupkin","admin"); soap.AddUser(NewUser);
Има и много минуси:
- Неоправдано голям размер на съобщението. Е, тук самата природа на xml е такава, че форматът е излишен, колкото повече тагове, толкова по-безполезна информация. Плюс сапунът допринася за излишността му. За интранет системите проблемът с трафика е по-малко остър, отколкото за интернет, така че сапун за локални мрежипо-търсен, по-специално Sharepoint има сапунена уеб услуга, с която можете да общувате с успех (и някои ограничения).
- Автоматичната промяна на описанието на уеб услугата може да счупи всички клиенти. Е, това е като за всяка система, така че ако обратната съвместимост със старите методи не се поддържа, всичко ще падне ...
- Не минус, а недостатък. Всички действия за извикване на метод трябва да бъдат атомарни. Например, когато работим с subd, можем да стартираме транзакция, да изпълним няколко заявки, след което да върнем назад или да извършим ангажимент. Няма транзакции със сапун. Една молба, един отговор, разговорът приключи.
- Справянето с описанието на това, което е от страна на сървъра (всичко правилно ли е описано от мен?), Какво е на клиента (какво ми беше написано тук?) Може да бъде доста трудно. Имаше няколко пъти, когато трябваше да се справя с клиентската страна и да убедя сървърния програмист, че неправилно е описал данните, но той изобщо не можеше да разбере нищо в тях, защото автоматично генериране и той, като че ли, не трябва да, това е въпрос на софтуер. И грешката естествено беше в кода на метода, програмистът просто не я видя.
- Практиката показва, че разработчиците на уеб услуги са страшно далеч от хората, които използват тези уеб услуги. В отговор на всяка заявка (валидна отвън) може да се появи неразбираема грешка „Грешка 5. Всичко е лошо“. Всичко зависи от съвестта на разработчиците :)
- Сигурен съм, че не запомних нищо...
Като пример има отворена уеб услуга на belavia:
- http://86.57.245.235/TimeTable/Service.asmx - входна точка, има и текстово описание на методите за разработчици на трети страни.
- http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl описание на методите и видовете получени и върнати данни.
- http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - описание на конкретен метод с пример за типа xml заявка и xml отговор.
Можете ръчно да създадете и изпратите заявка като:
POST /TimeTable/Service.asmx HTTP/1.1 Хост: 86.57.245.235 Content-Type: text/xml; charset=utf-8 Content-Length: дължина SOAPAction: "http://webservices.belavia.by/GetAirportsList"
отговорът ще бъде:
HTTP/1.1 200 OK Дата: понеделник, 30 септември 2013 г. 00:06:44 GMT Сървър: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-версия: 4.0.30319 Кеш-контрол: частен, макс. -age=0 Тип на съдържанието: текст/xml; charset=utf-8 Дължина на съдържанието: 2940
ZY По-рано беше отворена уеб услугата на Aeroflot, но след като 1C добави поддръжка за сапун в 8ku, куп 1c бета тестери я инсталираха успешно. Сега нещо се промени там (не знам адреса, можете да потърсите, ако се интересувате).
ZZY Отказ от отговорност. Говореше на ниво домакинство. Можете да пиете.
Опровержение:На тази тема са написани много статии и, както разбира се, се досещате, това е друга. Може би ще научите нещо ново от него, но тук не е описано нищо строго секретно, което не бихте могли да намерите в Google. Само бележки от личен опит.
Въведение
Ще разгледаме само ситуацията, когато има уеб услуга на трета страна и задачата е да се установи обмен на данни.
Структурата на услугата е описана във файла WSDL(инж. Web Services Description Language)
Достъпът до файла най-често се осъществява чрез връзка, където се намира входната точка към самата уеб услуга. Писах "най-често", защото има изключения. Например, уеб услуга, базирана на SAP, не публикува wsdl и може да бъде извлечена само от самото приложение.
И така, имаме описание на уеб услугата, вход, парола. Да се свържем.
// Определете настройките на ServiceNamespace URL = "http://Somesite.ru"; Потребителско име = "TestUser"; Парола = "q1w2e3"; LocationWSDL = "https://Somesite.ru/WebService/Some?wsdl"; ServiceName = "SomeServiceName"; ConnectionPointName = "SomeService_Port"; // Създаване на SSL връзка = New SecureConnectionOpenSSL(); WSDefinition = Нова WSDefinition(LocationWSDL,SSL); WSProxy = Нов WSProxy(WSDefinition, ServiceNamespace URL, ServiceName, ConnectionPointName, SSL); WSProxy.User = Потребителско име; WSProxy.Password = Парола;
Глоба! Свързахме се с уеб услугата! На теория това е в основата на всяка опция за обмен, тъй като ви позволява да създавате обект структура на даннибазиран на wsdl и работата с такъв обект е удоволствие.
Помислете за XML, който SoapUI ни дава
Сега нека го опишем програмно
// Създайте обект и го попълнете с данни OwnXDTOFactory = WSDefinition.XDTOFactory; RootType = OwnFactoryXDTO.Type(URLServiceNamespace, "SUBMISSION"); RootObject = OwnFactoryXDTO.Create(RootType); RootObject.ID = "4356"; ClientType = OwnFactoryXDTO.Type(URLServiceNamespace, "КЛИЕНТ"); ClientObject = OwnFactoryXDTO.Create(ClientType); ClientObject.CLIENT_ID = "121212"; ClientObject.SEX = "M"; // F - женски, M - мъжки ClientObject.CLIENT_BIRTHDAY = "19900111"; // Клиентски автомобили AutoType = CustomFactoryXDTO.Type(URLServiceNamespace, "CARS"); AutoObject = OwnFactoryXDTO.Create(AutoType); AutoObject.CLASS = "Мерцедес"; AutoObject.MODEL = "GLS"; ClientObject.CARS.Add(AutoObject); AutoObject = OwnFactoryXDTO.Create(AutoType); AutoObject.CLASS = "Audi"; AutoObject.MODEL = "TT"; ClientObject.CARS.Add(AutoObject); RootObject.CUSTOMER.Add(ClientObject);
Данните са завършени успешно. Сега трябва да ги изпратим.
Точно в този момент възникват много нюанси. Нека се опитаме да разгледаме всеки.
Рецепта 1. Изпращане на целия XDTO обект
Резултат = WSProxy.AddCustomers(RootObject);
Остава само да обработим резултата, който услугата ни върна и това е всичко. Съгласете се, че е много удобно!
Но на практика това не винаги е така. Например, 1c не се разбира с префикса на определени тагове в xml, когато пространството от имена на основния маркер се различава от това на дъщерните тагове. В такива случаи трябва да събирате сапун ръчно. Трябваше да се справя и с уеб услуги, които очакват чист xml като параметър. Лудост, но все пак не е твърде трудно да се направи.
Рецепта 2. Изпращане на чист xml като параметър
XMLRecordParameters = NewXMLRecordParameters("UTF-8", "1.0", True); MyXML = Нов XMLWriter; MyXML.SetString(XMLRecordParameters); MyXML.WriteDeclarationXML(); CustomXDTOFactory.WriteXML(MyXML, RootObject); StringXML = MyXML.Close(); Ако DeleteNamespaceDescription Тогава AttemptFirstTagInString = StrGetString(XMLString,2); RootTagName = RootObject.Type().Име; XMLString = StrReplace(XMLString, FirstTagInString, "<"+ИмяКорневогоТэга+">"); Изключение //ErrorDescription() EndTry; EndIf; Резултат = WSProxy.AddCustomers(XML String);
Ако не премахнете пространството от имена, което 1s добавя по подразбиране, то се е превърнало в повече от само 5 реда код. През повечето време обвивам xml трансформацията във функция, тъй като обикновено извикваме повече от един метод.
Рецепта 3. Изпращане чрез нативна HTTP заявка.
SOAP низ = "В тази опция ще трябва да изградим сапун ръчно. По същество ние просто увиваме xml-а от рецепта 2 в сапунена опаковка, където, в зависимост от изискванията на уеб услугата, можем да променим нашия сапун според желанието си.
След това описваме заглавките според документацията. Някои услуги лесно ще сдъвчат нашата заявка без заглавки, тук трябва да разгледате конкретен случай. Ако не знаете какви заглавки да предпишете, тогава най-лесният начин е да погледнете заявката в SoapUI, като преминете към раздела RAW.
Функцията за получаване на низа Base64 изглежда така (надникна):
Функция GetBase64AuthorizationHeader(Потребителско име, Парола) FileEncoding = TextEncoding.UTF8; TempFile = GetTemporaryFileName(); Запис = New TextWrite(TemporaryFile, FileEncoding); Write.Write(Потребителско име+":"+Парола); Запис.Затваряне(); BinData = New BinaryData(TempFile); Резултат = Base64String(DvData); DeleteFiles(TempFile); Резултат = Ср.(Резултат,5); Връщане на резултат; Крайни функции
Има един важен момент. Когато работите с HTTPConnection, посочете адреса, без да посочвате протоколите "http://" и "https://", в противен случай рискувате да загубите време в търсене на неочевидна грешка.
Рецепта 4. Изпращане чрез WinHttpRequest
WinHttp = Нов COMObject("WinHttp.WinHttpRequest.5.1"); WinHttp.Опция(2,"UTF-8"); WinHttp.Option(4, 13056); //intSslErrorIgnoreFlag WinHttp.Option(6, true); //blnEnableRedirects WinHttp.Option(12, true); //blnEnableHttpsToHttpRedirects WinHttp.Open("POST", "https://Somesite.ru/WebService/Some/GetCustomer", 0); WinHttp.SetRequestHeader("Content-type", "text/xml"); WinHttp.SetCredentials(Потребителско име, Парола, 0); WinHttp.Send(SOAP низ); WinHttp.WaitForResponse(15); XMLResponse = WinHttp.ResponseText();Тук всъщност е същото като в предишната версия, но работим с COMObject. Посочваме низа за връзка изцяло, заедно с протокола. Специално внимание трябва да се обърне само на флаговете за игнориране на грешки в SSL сертификатите. Те са необходими, ако работим през SSL, но без конкретен сертификат, тъй като в тази опция не е възможно да се създаде нова защитена връзка (или не знам как). Останалата част от механизма е подобна на предишния.
Освен това, в допълнение към "WinHttp.WinHttpRequest.5.1", можете да използвате "Microsoft.XMLHTTP", "Msxml2.XMLHTTP", "Msxml2.XMLHTTP.3.0", "Msxml2.XMLHTTP.6.0", ако изведнъж не отнеме изключен на WinHttp. Методите са почти еднакви, само броят на параметрите е различен. Подозирам, че една от тези опции е свързана вътре в обекта 1c HTTPRequest.
В момента това са всички рецепти, които имам. Ако попадна на нови, определено ще допълня статията.
Обработка на резултата
В рецепта 1 най-често получаваме готов XDTO обект и работим с него като структура. Във всички останали случаи можете да конвертирате xml отговора в XDTO
Ако Result.StatusCode = 200 Тогава XMLReader = Нов XMLReader; ReadingXML.SetString(Result.GetBodyAsString()); ResponseObject = OwnFactoryXDTO.ReadXML(ReadingXML); Доклад (ObjectResponse.Body.Response.RESPONSE_ID); Доклад (ObjectResponse.Body.Response.RESPONSE_TEXT); EndIf;
Тук всичко е просто.
Вместо заключение
1. Започнете да работите с уеб услуги с програмата SoapUI. Той е предназначен за такава работа и ще ви позволи бързо да разберете как работи определена услуга. Има статия за учене
2. Ако обменяте с услуга чрез несигурен http канал и възниква въпросът какво точно изпраща 1s във вашите съобщения, тогава можете да използвате снифери за трафик като Wireshark, Fiddler и други. Проблемът възниква само ако използвате ssl връзка.
3. Ако все пак уеб услугата комуникира чрез https, тогава ние инсталираме сървъра Nginx на отдалечена машина (всякаква, най-важното, не на наша собствена), с която ще се свържем, а тя от своя страна ще опакова всичко в https и го изпратете на правилното място (обратно прокси ) и добавете към стандартната конфигурация:
Сървър ( слушайте 0.0.0.0:8080; име на сървъра MyServer; местоположение ~ .* ( proxy_pass https://Somesite.ru:8001; proxy_set_header Хост $host; proxy_set_header Упълномощаване "Основно
5. Ако удостоверяването включва използването на бисквитки, тогава е намерено следното
P.S. Ако имате въпроси, предложения за подобряване на кода, имате свои собствени рецепти, които се различават от описаните, откривате грешки или смятате, че авторът е "грешен" и той "не е на мястото на 1s", тогава пишете коментари и ние ще обсъдим всичко.
Заглавието на темата наистина е въпрос, т.к Самият аз не знам какво е и за първи път ще се опитам да работя с него в рамките на тази статия. Единственото, което мога да гарантирам е, че кодът по-долу ще работи, но моите фрази ще бъдат само предположения и предположения за това как аз самият разбирам всичко това. Така че да тръгваме...
Въведение
Трябва да започнем с това за какво е създадена концепцията за уеб услуги. По времето, когато се появи тази концепция, в света вече са съществували технологии, които позволяват на приложенията да взаимодействат от разстояние, при което една програма може да извика някакъв метод в друга програма, която след това може да бъде стартирана на компютър, разположен в друг град или дори държава. Всичко това е съкратено като RPC (Remote Procedure Calling - дистанционно извикване на процедура). Примерите включват технологиите CORBA, а за Java - RMI (Remote Method Invoking - дистанционно извикване на метод). И май всичко е добре в тях, особено в CORBA, т.к можете да работите с него на всеки език за програмиране, но нещо все още липсваше. Вярвам, че недостатъкът на CORBA е, че работи чрез някои свои собствени мрежови протоколивместо обикновен HTTP, който ще премине през всяка защитна стена. Идеята на уеб услугата беше да се създаде такъв RPC, който да се изтласква в HTTP пакети. Така започна разработването на стандарта. Кои са основните концепции на този стандарт:- САПУН. Преди да извикате отдалечена процедура, трябва да опишете това повикване XML файл e SOAP формат. SOAP е само една от многото XML маркировки, използвани в уеб услугите. Всичко, което искаме да изпратим някъде чрез HTTP, първо се превръща в XML SOAP описание, след което се поставя в HTTP пакет и се изпраща на друг компютър в мрежата чрез TCP / IP.
- WSDL. Има уеб услуга, т.е. програма, чиито методи могат да бъдат извикани дистанционно. Но стандартът изисква към тази програма да бъде приложено описание, което казва, че „да, не сте се объркали - това наистина е уеб услуга и можете да извикате такива и такива методи от нея. Това описание е представено от друг XML файл, който има различен формат, а именно WSDL. Тези. WSDL е просто XML файл, описващ уеб услуга и нищо друго.
Общ подход
Уеб услугите винаги имат клиент и сървър. Сървърът е нашата уеб услуга и понякога се нарича крайна точка (като крайната точка, до която достигат SOAP съобщенията от клиента). Трябва да направим следното:- Опишете интерфейса на нашата уеб услуга
- Приложете този интерфейс
- Стартирайте нашата уеб услуга
- Напишете клиент и дистанционно се обадете на желания метод за уеб услуга
Сървър
Стартирайте IDEA и създайте нов проект Създаване на нов проект. Посочете име hellowebserviceи натиснете бутона Следващия, след това бутона завършек. В папката srcсъздайте пакет en.javarush.ws. В този пакет ще създадем интерфейса HelloWebService: package ru. javarush. ws; // това са анотации, т.е. начин да маркираме нашите класове и методи, // във връзка с технологията на уеб услугитеимпортиране на javax. jws. WebMethod; импортиране на javax. jws. Уеб сервиз; импортиране на javax. jws. сапун. SOAPBinding; // казваме, че нашият интерфейс ще работи като уеб услуга@Уеб сервиз // казваме, че уеб услугата ще се използва за извикване на методи@SOAPBinding(style = SOAPBinding.Style.RPC) публичен интерфейс HelloWebService( // казваме, че този метод може да бъде извикан дистанционно@WebMethod публичен низ getHelloString(име на низ) ; ) В този код класовете WebService и WebMethod са така наречените анотации и не правят нищо друго, освен да маркират нашия интерфейс и неговия метод като уеб услуга. Същото важи и за класа SOAPBinding. Единствената разлика е, че SOAPBinding е анотация с параметри. V този случайпараметърът style се използва със стойност, показваща, че уеб услугата ще работи не чрез съобщения на документи, а като класически RPC, т.е. за да извикате метода. Нека внедрим нашата интерфейсна логика и да създадем клас HelloWebServiceImpl в нашия пакет. Между другото, отбелязвам, че класът, завършващ с Impl, е конвенция в Java, според която реализацията на интерфейси е така обозначена (Impl - от думата implementation, т.е. реализация). Това не е изискване и вие сте свободни да назовете класа каквото искате, но добрите обноски го изискват: package ru. javarush. ws; // същата анотация като за описанието на интерфейса,импортиране на javax. jws. Уеб сервиз; // но тук се използва с параметъра endpointInterface, // посочва пълното име на класа на интерфейса на нашата уеб услуга@WebService(endpointInterface= "en.javarush.ws.HelloWebService") публичният клас HelloWebServiceImpl реализира HelloWebService ( @Override public String getHelloString (име на низ) ( // просто върнете поздрава return "Здравей, " + име + "!" ; ) ) Нека стартираме нашата уеб услуга като самостоятелен сървър, т.е. без участието на никакви Tomcat и сървъри на приложения (това е тема за отделна дискусия). За да направите това, в структурата на проекта в папката srcнека създадем пакет ru.javarush.endpoint и в него ще създадем клас HelloWebServicePublisher с метода main: package ru. javarush. крайна точка; // клас за стартиране на уеб сървър с уеб услугиимпортиране на javax. xml. ws. крайна точка; // клас на нашата уеб услугаимпортиране en. javarush. ws. hellowebserviceimpl; публичен клас HelloWebServicePublisher( public static void main(String. . . args)( // стартиране на уеб сървър на порт 1986 // и на адреса, посочен в първия аргумент, // стартиране на уеб услугата, подадена във втория аргументкрайна точка. публикувам ( "http://localhost:1986/wss/hello", нов HelloWebServiceImpl ()); ) ) Сега стартирайте този клас, като щракнете Shift+F10. Нищо няма да се появи в конзолата, но сървърът работи. Можете да потвърдите това, като напишете http://localhost:1986/wss/hello?wsdl във вашия браузър. Отворената страница, от една страна, доказва, че имаме уеб сървър (http://), работещ на порт 1986 на нашия компютър (localhost), и, от друга страна, показва WSDL описанието на нашата уеб услуга. Ако спрете приложението, описанието ще стане недостъпно, както и самата уеб услуга, така че няма да правим това, а ще преминем към писане на клиента.Клиент
В папката на проекта srcнека създадем пакет ru.javarush.client и в него класа HelloWebServiceClient с основния метод: package ru. javarush. клиент; // необходими за получаване на wsdl описание и чрез него // достигане до самата уеб услугаимпортиране на java. нето. URL; // такова изключение ще възникне при работа с URL обектаимпортиране на java. нето. MalformedURLEException; // класове за анализиране на xml с wsdl описание // и посегнете към сервизния маркер в негоимпортиране на javax. xml. пространство от имена. Qname; импортиране на javax. xml. ws. обслужване; // интерфейс на нашата уеб услуга (нуждаем се от повече)импортиране en. javarush. ws. hellowebservice; публичен клас HelloWebServiceClient( public static void main(String args) хвърля MalformedURLException( // създаване на връзка към wsdl описанието url= нов URL адрес ( "http://localhost:1986/wss/hello?wsdl") ; // Разглеждаме параметрите на следващия конструктор в първия таг за описание на WSDL - дефиниции // погледнете 1-вия аргумент в атрибута targetNamespace // 2-ри аргумент погледнете в атрибута name QName qname = ново QName ("http://ws.site/" , "HelloWebServiceImplService") ; // Сега можем да достигнем до сервизния маркер в описанието на wsdl, Сервизно обслужване= услуга. създаване (url, qname) ; // и след това към порт тага, вложен в него, така че // получаваме препратка към обект на уеб услуга, отдалечен от нас HelloWebService здравей = услуга. getPort(HelloWebService.class) ; // Ура! Сега можете да извикате отдалечения методСистема. навън. println(здравей. getHelloString("JavaRush") ) ; ) ) Дадох максимум коментари за кода в обявата. Нямам какво да добавя, така че стартирайте (Shift + F10). Трябва да видим текста в конзолата: Здравей, JavaRush! Ако не сте го видели, вероятно сте забравили да стартирате уеб услугата.Заключение
В тази тема беше представена кратка екскурзия в уеб услугите. Още веднъж, голяма част от това, което написах, е мое предположение за това как работи и затова не трябва да ми се вярва твърде много. Ще съм благодарен ако знаещи хораЩе ме поправят, защото тогава ще науча нещо. UPD.Алексей Бойко
SOAP и XML уеб услуги в .Net
XML уеб услугите предлагат ниво на оперативна съвместимост и оперативна съвместимост по отношение на операционните системи,
платформи и езици, които преди това просто не са били налични.
Андрю Троелсен (Най-ценният професионалист в Microsoft MVP)
Ако все още не сте работили с XML уеб услуги, вероятно сте чували думата "SOAP". Време е да се заемем с тези понятия.
въведение
Ако се интересувате от интернет или по-малки мрежи, има вероятност рано или късно да попаднете на XML уеб услуги. XML уеб услугата е повече от просто уеб приложение, способно да показва информация в браузър. По-скоро това е отдалечена технология, която ви позволява да извиквате методи и свойства на обект в мрежата, използвайки стандартни HTTP заявки.
На практика това означава, че клиентите на такава услуга могат да бъдат написани на различни езици и за различни операционни системи.
Като информационен "транспорт" между услугата и клиента можете да използвате методите GET или POST HTTP.
И можете да „наложите“ друг протокол отгоре - SOAP (Simple Object Access Protocol). Това обикновено се прави, тъй като в този случай е възможно да се предават сложни типове (включително дефинирани от потребителя). А класическите методи GET и POST поддържат само списъци, прости масиви и низове.
Пример за SOAP комуникация
SOAP съобщението е XML документ, поставен в тялото на HTTP заявка.
Листинг 1. Структура на SOAP съобщение
Взаимодействието между клиента и услугата е както следва:
- клиентът формира SOAP заявка и я изпраща до услугата;
- услуга включена отдалечен компютъризпълнява процедурата и изпраща SOAP отговор.
Например, SOAP заявка, извикваща метода HelloWorld() на отдалечена XML уеб услуга, може да изглежда така:
Листинг 2. Примерна SOAP заявка
Методът HelloWorld(), както се очаква, връща низа "Здравей, свят!":
Листинг 3. Примерен SOAP отговор
Xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
Създаване на XML уеб услуга в .NET 2.0
Можете да създадете услуга различни начини, ще използваме Visual Studio 2005. Щракнете върху "Файл -> Нов -> Уеб сайт", в прозореца, който се отваря, изберете "ASP.NET уеб услуга". На посочения при създаването адрес ще намерите следните файлове и директории (вижте фиг. 1).
По принцип една услуга може да съдържа само един файл *.asmx. (Разширението *.asmx се използва за обозначаване на .Net уеб услуги.) В този случай това не е така, вижте съдържанието на файла Service.asmx:
Листинг 4. Service.asmx дефинира външен файлподдържа
<%@ WebService Language="C#" CodeBehind="~/App_Code/Service.cs" class="Service" %>
Атрибутът CodeBehind посочва външен файл, разположен в папката App_Code, който съдържа програмния код, който реализира метода HelloWorld():
Листинг 5. Service.cs файл, внедряващ метода HelloWorld().
използване на системата;
използване на System.Web;
използване на System.Web.Services;
обществена услуга ()
Върнете "Здравей свят";
Възможно е да създадете един файл Service.asmx без код за поддръжка, който има същата функционалност:
Листинг 6. Service.asmx без външен код за поддръжка
<%@ WebService Language="C#" class="Service" %>
използване на системата;
използване на System.Web;
използване на System.Web.Services;
използване на System.Web.Services.Protocols;
услуга от публичен клас: System.Web.Services.WebService
обществена услуга ()
Публичен низ HelloWorld() (
Върнете "Здравей свят";
Нямаме нужда от това и няма да го направим.
Както можете да видите, единственият метод на нашата уеб услуга е маркиран с атрибута, информиращ средата за изпълнение на ASP.NET, че този метод е наличен за входящи HTTP заявки. Членовете, които не са маркирани с този атрибут, няма да бъдат достъпни за клиентските програми.
Такава проста услуга е доста подходяща за нашите експерименти, остава само да я публикуваме.
Публикуване на XML уеб услуга с помощта на IIS
Няма да става дума за публикуване в Интернет, а за създаване на условия за тестване на нашата услуга на локален компютър.
Първо, инсталирайте IIS (Internet Information Server). За да направите това, отворете прозореца „Добавяне или премахване на програми“ и изберете „Инсталиране Компоненти на Windows". (Някои Версии на Windowsне изискват инсталиране на IIS, като Windows XP Home Edition.)
Забележка: IIS сървърпо-добре е да инсталирате по-рано от .Net Framework, в противен случай ще трябва да конфигурирате IIS да поддържа .Net приложения, като стартирате помощната програма командна линия aspnet_regiis.exe (с флага /i).
Създайте виртуална директория. Ако използвате Windows XP Pro, отидете на "Контролен панел -> Административни инструменти -> Интернет информационни услуги". В прозореца, който се отваря, изберете "Действие -> Създаване -> Виртуална директория".
Съветникът за създаване на виртуална директория ще стартира. Посочете Soap1 като псевдоним и задайте пътя до директорията, където искате да поставите услугата, например C:\Soap1. Сега копирайте съдържанието на нашата уеб услуга там.
Въведете http://localhost/soap1/Service.asmx в адресната лента на вашия браузър и трябва да видите страницата за тестване на услугата (вижте фигура 2).
Преглед на SOAP съобщения
Тестовата страница не позволява изпращане и четене на SOAP съобщения. Поради тази причина ще трябва да използвате разработка на трети страни, препоръчвам да използвате soapUI. (Това е безплатен продукт, достъпен на http://www.soapui.org.)
След като soapUI бъде инсталиран, създайте нов проект, наречен soap1, оставяйки полето Initial WSDL празно (вижте фигура 3).
Щракнете с десния бутон върху новосъздадения проект и изберете "Добавяне на WSDL от URL". В диалоговия прозорец, който се отваря, въведете http://localhost/soap1/Service.asmx?wsdl. Вече имаме възможността да изпращаме SOAP заявки до нашата услуга и да преглеждаме получените отговори. (Заявките ще се генерират автоматично от soapUI.)
Какво е това WSDL? WSDL документът описва как клиентите могат да взаимодействат с уеб услуга. Той описва кои методи на услугата са налични за външно обаждане, какви параметри приемат и какво връщат, както и друга информация, необходима за отдалечаване. Такъв документ може да бъде компилиран ръчно или можете да поверите генерирането му на сървъра, за това е достатъчно да добавите суфикса ?wsdl към URL адреса, сочещ към файла *.asmx.
За да видите WSDL документа за нашата услуга, въведете http://localhost/soap1/Service.asmx?wsdl във вашия браузър. Информацията от този документ се използва от soapUI за автоматично генериране на SOAP заявки.
SOAP разширения
Както може би сте забелязали, за да създадете XML уеб услуга (като клиент), не е нужно да се притеснявате за формата на SOAP съобщенията. Достатъчно е да маркирате желаните методи с атрибута и средата за изпълнение на ASP.NET сама ще състави пакетите от желания формат.
На фиг. Фигура 4 показва заявка за уеб услуга и отговор, получени с помощта на програмата soapUI.
Нека го повторим отново. Заявката се генерира от soapUI - когато създавате реални клиенти за услугата, също не е необходимо ръчно да форматирате SOAP пакети. Ние също не участвахме пряко в създаването на отговора на услугата. Всичко това се случва автоматично.
Въпреки това, вероятно ще трябва да промените тези пакети сами. Например за компресиране или криптиране на предадените данни. Това е целта на SOAP разширенията.
SOAP Extensions е механизъм, който ви позволява да променяте произволно получените и изпратените SOAP съобщения.
Пътят на SOAP съобщение
За да започнем програмирането, трябва да вземем предвид пътя, който минава SOAP съобщението, преди да бъде получено и обработено по подходящия метод (виж Фигура 5).
SOAP съобщението може да се разглежда като XML документ, който описва обект, предаван по мрежата. Преди да може да се използва обект, прехвърлен по този начин, той трябва да бъде възстановен (или, ако предпочитате, сглобен) от това описание. XML сериализатор служи за тази цел.
Входящите пакети се десериализират (възстановяване на обекта от XML описанието), а изпратените пакети се сериализират (създавайки XML описанието на обекта).
На фиг. Фигура 5 показва четири точки (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize), където можем да прихванем SOAP съобщение с помощта на SOAP разширения. Променете го и го изпратете.
Внедряване на SOAP разширение
Първо, нека дефинираме задачата: да кажем, че искаме да променим SOAP пакетите, изпратени от уеб услугата, както е показано в листинг 7:
Листинг 7. „Стари“ и нови отговори на XML уеб услуга
Xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
Xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> Шифрен текст
План за действие за внедряване на SOAP разширение:
- Създаваме dll с клас, който наследява от SoapExtension.
- Добавяме папката bin към нашата уеб услуга и поставяме създадения dll там.
- Добавете файл web.config към услугата и направете необходимите промени в него.
Ролята на папката bin и файла web.config ще бъде обсъдена по-късно.
Създаване на DLL със SOAP разширение
Създайте нов проект "Библиотека на класа", наречен SoapExtensionLib. Този проект ще трябва да приложи само един клас, който ще извърши модификациите на SOAP пакетите, от които се нуждаем. Този клас трябва да бъде извлечен от класа SoapExtension.
Листинг 8. Създаване на клас, който наследява от SoapExtension
използване на системата;
използване на System.Web.Services;
използване на System.Web.Services.Protocols;
използване на System.IO;
използване на System.Net;
с помощта на System.Xml;
Всяко SOAP разширение получава като параметър поток, съдържащ обект, предаван по мрежата (преди или след сериализация). И трябва да върне потока.
SOAP разширението може да се разглежда като "странична лента", която може да бъде поставена в една или всички от четирите точки (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize), показани на фигура 2. 5. Във всяка точка може да има произволен брой такива "вложки" (виж фиг. 6).
За да получите тези потоци, използвайте метода ChainStream.
Листинг 9. Реализация на метода ChainStream
публичен клас TraceExtension: SoapExtension
Поток wireStream;
Поточно приложениеStream;
// метод като входен параметър
// получава потока, съдържащ предадения обект
Публично отменяне на поток ChainStream (поток на поток)
WireStream = поток;
AppStream = нов MemoryStream();
върнете appStream;
…
В точката BeforeDeserialize, wireStream съдържа SOAP заявката, получена от мрежата. Тази SOAP заявка трябва да бъде предадена на потока на приложението (потокът appStream).
И в точката AfterSerialize, трябва да предадете на wireStream SOAP отговора, изпратен до мрежата, който ще бъде поставен в appStream.
За да работите с нишки във всяка от четирите точки, трябва да приложите метода ProcessMessage.
Листинг 10. Внедряване на метода ProcessMessage, който не променя SOAP съобщенията
// ProcessMessage, който прави задължително копие
// потоци в две точки (BeforeDeserialize и AfterSerialize)
Превключвател(съобщение.Етап)
// в точката BeforeDeserialize трябва да се подаде
// SOAP заявка от мрежов поток (wireStream)
// към потока на приложението (appStream)
Case SoapMessageStage.BeforeDeserialize:
Копиране(wireStream, appStream);
AppStream.Position = 0;
прекъсване;
// в точката AfterSerialize трябва да се подаде
// SOAP отговор от нишка на приложение към мрежова нишка
AppStream.Position = 0;
прекъсване;
void Copy (Поток от, Поток към)
Четец на TextReader = нов StreamReader(от);
TextWriter writer = нов StreamWriter(to);
Writer.WriteLine(reader.ReadToEnd());
Writer.Flush();
Списък 10 може да се приеме като празен за по-нататъшни експерименти. Тази реализация на метода ProcessMessage няма смисъл - изходящият SOAP отговор не се променя по никакъв начин. Нека поправим това:
Листинг 11. Внедряване на метода ProcessMessage, който модифицира SOAP отговора
публично замяна на void ProcessMessage(SoapMessage съобщение)
Превключвател(съобщение.Етап)
Case SoapMessageStage.AfterSerialize:
WriteOutput(съобщение);
прекъсване;
// част от кода се изрязва, за да се спести място
// пренаписваме SOAP отговора
public void WriteOutput(SoapMessage съобщение)
AppStream.Position = 0;
// създаване на XML документ от потока
XmlDocument документ = нов XmlDocument();
Document.Load(appStream);
// За да използвате XPath, трябва да дефинирате
// Мениджър на пространство на имена
XmlNamespaceManager nsmgr = нов XmlNamespaceManager(document.NameTable);
Nsmgr.AddNamespace("сапун", "http://schemas.xmlsoap.org/soap/envelope/");
XmlNode ResultNode = document.SelectSingleNode("//сапун:Тяло", nsmgr);
// заменя съдържанието на възела
ResultNode.InnerText = "шифрован текст";
// изчистете потока и напишете нов SOAP отговор към него
AppStream.SetLength(0);
AppStream.Position = 0;
Document.Save(appStream);
// ИЗИСКВАНО ДЕЙСТВИЕ
// предава SOAP отговора от потока на приложението (appStream)
// в мрежовия поток (wireStream)
AppStream.Position = 0;
Копиране(appStream, wireStream);
След това трябва да дефинираме два метода (единият от които е претоварен, тоест може да бъде извикан с различни набори от параметри), които не са необходими в нашия случай. Трябва обаче да ги дефинираме според правилата за наследяване от класа SoapExtension.
Листинг 12. Други задължителни методи
// В съответствие с правилата за наследяване, ние трябва
// дефинираме тези методи, но ние не ги използваме по никакъв начин
публичен обект за отмяна?
GetInitializer(LogicalMethodInfo methodInfo, атрибут SoapExtensionAttribute)
връщане на нула;
публичен обект за замяна GetInitializer(Type WebServiceType)
връщане на нула;
public override void Initialize (инициализатор на обект)
връщане;
Всичко, компилираме проекта. Най-накрая получихме SOAP Extension dll. Пълен списък на SoapExtensionLib.dll е достъпен на уебсайта на списанието в раздела Изходен код.
Конфигуриране на уеб услуга за работа със SOAP разширение
Отворете нашия проект за XML уеб услуга отново с Visual Studio. Щракнете върху "WebSite -> Add Reference" и изберете SoapExtensionLib.dll, който сте създали по-рано.
Папката Bin автоматично ще бъде добавена към проекта. Файловете *.dll, намиращи се в папката Bin, се препращат автоматично от приложението.
Сега поставете файла Web.Config в директорията на уеб услугите със следното съдържание:
Листинг 13. Файл Web.Config
Приоритет = "1" Група = "0" />
Сега структурата на нашата услуга изглежда така, както е показано на фиг. 7. Използвайки файла Web.Config, ние информираме средата ASP.NET, че сме добавили към уеб услугата XML Soap Extension, внедрена в класа TraceExtension, разположен във файла SoapExtensionLi.dll. Листинг 14. Секцията webServices във файла Web.Config Приоритет = "1" Група = "0" />
Както вече знаете, можете да направите множество SOAP разширения и потокът, носещ предадения обект (преди или след сериализация), ще премине през всяко от тях. Редът, в който потокът преминава през различните SOAP разширения, се посочва с помощта на атрибутите приоритет и група. Струва си да се отбележи, че конфигурирайки Web.Config по този начин, ние информираме средата, че нашето SOAP разширение ще бъде извикано за всеки метод на услугата, маркиран с атрибута. Възможно е да създадете свой собствен атрибут и да маркирате с него само онези методи, за които трябва да извикате SOAP разширението. Листинг 15. Пример за персонализиран атрибут публичен низ HelloWorld() ( Върнете "Здравей свят"; За да направите това, добавете клас, наследен от SoapExtensionAttribute, към SoapExtensionLi.dll (вижте фигура 8). Заключение Тази статия отразява основните точки на изграждане и функциониране на XML уеб услуги на платформата .Net. Надявам се, че представеният материал ще бъде напълно достатъчен, за да можете, ако е необходимо, да направите по-задълбочено проучване на темата. Във връзка с
