Днес има две коренно различни начина за внедряване на уеб услуги на базата на HTTP, в Microsoft® .NET. Първата и най-ниско ниво на техниката е да се напише специален клас IHttpHandler, която се вмъква в веригата на .NET HTTP тръбопровод. Този подход изисква използване System.Web API за да обработва входящите съобщения HTTP и System.Xml API, за да се справят с обвивката на SOAP намира в тялото на HTTP. Когато пишете специален манипулатор така е необходимо да се създаде ръчно WSDL документ, който описва процеса на внедряване. За да направите всичко това правилно, имате нужда от по-дълбоко разбиране на XML спецификации, XSD, SOAP и WSDL, което е предпоставка за по-голямата смущаваща.
По-продуктивен начин за изпълнение на уеб услуги е да се използва обвивка WebMethods Microsoft ASP.NET. С ASP.NET идва IHttpHandler специален клас за .asmx (наречена WebServiceHandler), която предоставя набор от основни функции, които функционален XML, XSD, SOAP и WSDL. И както WebMethods черупка ви защитава от сложността на подлежащото XML технологията, можете бързо да се фокусира върху съществуващите проблеми на бизнес логиката.
Фигура 1. компромиси между гъвкавост и производителност
Изборът между техниките на реализация води до цялостно сравнение на печалбите и загубите между гъвкавост и ефективност, както е показано на фигура 1. Създаване на персонализиран IHttpHandler дава неограничена гъвкавост, но също така се нуждае от повече време, за да пиша, тестване и отстраняване на грешки кода си. WebMethods черупка улеснява организацията на вашия уеб сайт и скорост на развитие, но трябва да са ясно ограничени от черупката. Въпреки това, в случаите, когато WebMethods черупка не осигурява точно това, което ви трябва, има възможност да го разширят чрез добавяне на собствената си допълнителна функционалност.
WebMethods обвивка се занимава с трансформация на SOAP съобщения в методите на .NET клас. Това се прави най-вече посредством обозначаването на вашите методи приписват [WebMethod], разположен в имената на космически System.Web.Services. Например, следният клас .NET съдържа четири методи, две от които са обозначени с атрибут [WebMethod]:
За да използвате този клас с WebMethods обвивка, трябва да го събират в едно събрание и да копирате виртуална директория бин директория. В този пример, събиране и изваждане на методите могат да бъдат описани като операции уеб услуга, докато методите умножение и деление на това може да се направи (защото те не са били маркирани атрибут [WebMethod]).
Отваряш събиране и изваждане на операции като уеб услуга чрез .asmx файл. За да направите това, да създадете нов текстов файл Math.asmx, който съдържа следната проста описанието, и го поставете в една и съща виртуална директория, която съдържа събрание (имайте предвид: файла се поставя в самата виртуална директория, а не негово дъщерно директория бин):
Това е един от основните варианти за работа .asmx манипулатор. File .asmx описание обикновено съдържа само WebService, който се отнася до името на класа уеб услуга (както в примера, показан по-долу). Ето защо, в този случай, събранието трябва вече да се събере и постави в бин директория на виртуална директория. Процесор .asmx предвижда също JIT компилация от изходния код е в .asmx файл. Например, следващото изображение (наречена Mathjit.asmx) съдържа описание WebService заедно с оригиналната клас код, посочен.
Когато този файл dostupayutsya през HTTP за първи път, .asmx манипулатор компилира източника и поставете събрание правилно. Имайте предвид, че в WebService описанието също трябва да бъдат уточнени и език за програмиране да .asmx манипулатор може да избере правилното изпълнение компилатор. Ясен недостатък на този подход е, че не знам за компилация грешки, докато файла с контакти.
Фигура 2. Документация MathService
При създаване на нов проект Web услуга в Visual Studio® .NET, винаги да се използва техника на "две файлове", когато класът на файла източник е отделена от файла .asmx, че в нея е посочена. Интегрирана среда за разработка (IDE) добър в това се крие от теб, но ако кликнете върху Показване на всички файлове на лентата с инструменти към Solution Explorer, ще видите в проекта за двата файла за всеки клас уеб услуга. Между другото, Visual Studio .NET не поддържа за файл .asmx оцветяване на синтаксиса или IntelliSense®, така че можете да решите дали да се следват в тази посока. В Visual Web проекти Studio .NET също са загрижени за създаването на виртуална директория и автоматично съставяне на агрегата към бин виртуална директория.
Преди да се гмурне в детайлите на .asmx манипулатор работа, нека накратко обсъди как съобщения се обработват от Internet Information Server (IIS), най-вече в .asmx манипулатор. Когато входящо HTTP съобщение достига порт 80, за да се определи кои ISAPI DLL трябва да се използва, за да процес, IIS използва информацията за IIS метабазата. Монтаж .NET свързва с разширение .asmx Aspnet_isapi.dll, както е показано на фигура 3.
Фигура 3. Svyazyvaenie IIS и .asmx
Aspnet_isapi.dll - това е разширение на ISAPI на стандарта, предоставена от .NET Framework, която просто насочва искания HTTP в един работен процес, наречен Aspnet_wp.exe. Aspnet_wp.exe действа като домакин за общата езикова среда и .NET HTTP тръбопровод. След съобщение е включена в HTTP газопровода .NET, тръбопровод изглежда в конфигурационния файл, който клас IHttpHandler трябва да се използва за това разширение. Ако се вгледате в файловото Machine.config, ще видите, че тя съдържа httpHandler, свързани с .asmx разширение, както е показано тук:
Веднага след газопровода .NET HTTP кара .asmx манипулатор по чудо започва обработката на XML, XSD, SOAP и WSDL. Останалата функционалност условие манипулатор .asmx, те могат да бъдат разделени в три основни групи: 1), за да координират съобщителни 2) XML трансформация в обекти, и 3) автоматично генериране и WSDL документа. Да вземем всеки един от тези групи погледнем по-отблизо.
dispecherizacii мнения
Когато газопровода HTTP кара .asmx манипулатор търси описание WebService в .asmx файл, той определя дали да се използва .NET клас. След това той изглежда входящи HTTP съобщение за да се определи кой метод да се позове в този клас. За да се покаже операция за добавяне показано в предишните примери, входящи HTTP съобщение трябва да изглежда по следния начин:
В действителност, има две секции в входящо HTTP съобщение, което може да се използват за определяне на метода, който трябва да се нарича в класа: SOAPAction горен или на името на исканата вещ (т.е. името на елемент в рамките на елемента на сапун: Body). В този случай, най-малко един от тях определя името на метода, който иска да се обадите на подателя.
Можете да промените имената на пространство на уеб услуги, отбелязвайки клас атрибут на [WebService], както и точната стойност на SOAPAction, маркировка WebMethods атрибут [SoapDocumentMethod], както е показано по-долу:
Ако .asmx манипулатор не намерите SOAPAction, подходящ за входящо HTTP съобщение, той просто хвърля изключение (по-късно се помисли как се обработват изключения). Ако dispecherezatsii метод не използвате SOAPAction заглавна маркировка клас имот RoutingStyle атрибут [SoapDocumentService], можете да укажете името на водача .asmx т ползване заявка. Ако направите това, вие също трябва да се уточни, че WebMethods не се нуждаят от стойността SOAPAction, чрез определяне на техните стойности за празен низ, както е показано по-долу:
Така че, първото нещо, което прави .asmx манипулатор за входящо съобщение HTTP - тя определя как да се пренасочи съобщението на съответния WebMethod. Въпреки това, преди да може действително да се обадите на метода, трябва да конвертирате входящия XML в .NET обекти.
Конвертиране на XML за обекти
Веднага след като водачът WebMehod определи кой метод трябва да се обадите, тя трябва да десериализиране на XML съобщението в обектите .NET, които могат да бъдат предоставени по време на извикване на метода. Точно както в dispecherizacii манипулатор съобщение проверява класа използвайки размисъл, за да разбера как да се справят с входящ XML съобщението. Клас XmlSerializer извършва автоматично преобразуване между XML и обекти в имената пространство System.Xml.Serialization.
XmlSerializer дава възможност да се превърне всеки вид обществена .NET в XML Schema и вид, обаче, може да провежда автоматично преобразуване между обекти и .NET XML документи (вж. Фигура 4). XmlSerializer е ограничен до тези функции, които днес поддържа XML Schema, така че не може да работи с всички сложността на съвременните модели на обекти, като комплексът е не дървесни схеми на обекти, дублиращи указатели и т.н. Въпреки това, XmlSerializer може да се справи с най-сложните видове, използвани от разработчиците.
За горния пример Добави XmlSerializer преобразува х и у в .NET двойна стойност, която може да бъде представена в добавите повикване. Методът на Add връща на обаждащия се да двойна стойност, която трябва да бъде отново поредица в XML елемент в рамките на отговора на сапун.
Фигура 4. XML обекти преобразуване
Също XmlSerializer може автоматично да работят със сложни видове (с изключение на ограниченията, описани по-горе). Например, следния WebMethod изчислява разстоянието между двете структури Point:
SOAP съобщение със запитване за тази операция ще съдържа Разстояние елемент, който включва две дъщерни елементи, ориг и Цел и всеки от тези елементи трябва да съдържат елементи на деца х и у:
В този случай, съобщение отговор SOAP ще съдържа член DistanceResponse съдържащ двойно тип елемент DistanceResult:
Дали метода на XML преобразуване по подразбиране се използва името и името на елемента за заявка и имената на параметрите, както и имената на елементите на детето. Структурата на всеки параметър зависи от вида на структурата. Имена публични полета и свойства просто превърнати в дъщерни елементи, както в случая на х и у (в точка). Име на потребителя става отговор подразбиране името на искане елемент завършва с "Response" дума. отговорен елемент съдържа още и дъщерните елементи, наречени, както и елементи на искането, завършващи само думата "Резултат".
Възможно е да се отървете от стандартен XML преобразуване чрез използване на голям брой вградени преобразуване атрибути. Например, атрибутът [XmlType] може да се използва за преобразуване на името на този тип и пространство от имена. За да контролирате начина, по параметри са членове на клас или трансформиране на елементи или атрибути, можете да използвате атрибутите [XmlElement] и [XmlAttribute], съответно. И да се наблюдава как самият метод се превръща в имената на елементи в съобщението е заявка / отговор, можете да използвате атрибута [SoapDocumentMethod]. Например, прочетете следващата версия далечината, която използва различни атрибути:
В тази версия на разстояние се очаква, че входящата SOAP съобщение ще изглежда така:
И такова съобщение за SOAP се генерира отговор:
За да се приложи и да определят трансформацията на гореизложеното, по подразбиране, .asmx манипулатор използва документ / буквален SOAP стил. Това означава, че описание WSDL ще съдържа азбучен определение XML схема и заявки описват елементи и елементите на отговор, използвани в SOAP съобщения (SOAP т.е. правила за кодиране не се използва).
Допълнителната работа по deserialization параметри .asmx манипулатор може също десериализиране / Сериализирането сапун заглавки. SOAP заглавията не се обработват като параметри, тъй като те са по принцип се смята, че няма връзка информация без пряка връзка с конкретен метод. Следователно, обработката на глава обикновено се прави чрез нивата на прихващане, напълно защитна WebMethods от налага да се справят с обработката на заглавията.
Ако все пак искате да използвате информацията, с глава на WebMethod, трябва да се осигури .NET клас, който наследява от SoapHeader, което е XML Schema заглавията (след превръщането на препоръките, дадени по-горе). След това се определи вида на променливата член, изпълнявайки ролята на "заместител" например глава. И накрая, можете отбележат WebMethod всеки, е необходим достъп до титлата, като се посочва името на областта, в която искате да изпратите.
Например, заявка SOAP съдържащ UsernameToken глава за удостоверяване:
За да се даде възможност за .asmx манипулатор заглавна deserialization, първо трябва да се определи класа на .NET, която представлява предвидения тип XML Schema (забележка: ако действително има XML Schema за заглавната част, можете да генерирате клас използване xsd.exe / с) , В този случай, на съответния клас, е както следва:
Тогава просто трябва да дефинирате променлива член в клас WebMethod, да съхранява копие от заглавието на клас. и поясняват WebMethods атрибут [SoapHeader], както е показано по-долу:
.asmx манипулатор също така предвижда автоматични сериализация .NET извънредни ситуации. Всеки необработено изключение, прихванати .asmx манипулатор, се серийни номера автоматично в SOAP елемент Fault в отговора. Така например, в предишния пример, ако потребителското име не съвпада с паролата, нашият код хвърля изключение .NET. Тогава .asmx манипулатор ще го и серийни номера в SOAP отговор обработва, както е показано по-долу:
Клиентите трябва да знаят точно как трябва да изглежда като съобщение SOAP за да може успешно да работи с него. Безспорно е да представи описание на уеб услугата чрез WSDL (и вградени определения XSD). За тази .asmx манипулатор и автоматично генерира страница документация и описание WSDL, че точно да отразява интерфейс WebMethod. Ако сте приложили трансформация група атрибути на вашите WebMethods, те ще бъдат отразени в генерираната документация.
Ако погледнете .asmx файл, можете да видите на страницата на документация, както е показано на фигура 2. Това ръководство страница се генерира .aspx страница, наречена DefaultWsdlHelpGenerator.aspx (намира се в C: windowsMicrosoft.NETFramework v1.0.3705config). Ако отворите файла, ще видите, че това е само стандартна ASP.NET страница, която използва .NET размисъл за генериране на документация. Тази функция позволява на документи винаги отговарят на кода. Просто чрез модифициране на този файл, можете да модифицирате, генерирана документация.
Можете също да блокирате генериране на документация, въз основа на виртуалната директория, като се посочва друга документация файл във файла Web.config:
Ако клиентът попълва заявка за GET за .asmx символи "? WSDL" в низа на заявката, вместо .asmx манипулатор генерира описанието WSDL на документацията. Клиентите могат да използват описанието на WSDL за генериране на прокси класове, които автоматично ще знаят как да се комуникира с уеб услугата (т.е. използване Wsdl.exe в .NET).
Използването на две различни техники, можете напълно да блокират процеса на генериране на WSDL. На първо място, достъп до клиенти, можете да се осигури статичен документ WSDL във вашата виртуална директория, след което блокира генератор документация, да я извадите от вашия файл на web.config, както е показано по-долу:
WebMethods ASP.NET яке осигурява подход с висока производителност за изграждане на уеб услуги. WebMethods направи възможно да се използват традиционните методи като операции на .NET Web услуги, които поддържат HTTP, XML, XML Schema, SOAP и WSDL. Хендлър WebMethod (.asmx) автоматично определя как да изпращате входящи SOAP съобщенията на съответния метод, като на този етап той автоматично ще serializes входящи XML елементи към подходящите .NET обекти. И опростяване на живота на клиента, водача .asmx също така осигурява автоматична подкрепа за генериране на документация за лицето (HTML) и машина (WSDL).
Рейтинг: 2 от 5 Февруари
Свързани статии