Техники за разработване на ASMX уеб услуги

техники
В тази статия ще говоря за различни техники за разработване на SOAP уеб услуги с помощта на технологията ASMX, както и за тази технология като цяло. В допълнение към SOAP ще бъде разгледано и внедряването на AJAX. Статията ще бъде полезна както за тези, които вече са запознати с нея, така и за тези, които тепърва ще създават своята първа уеб услуга. През 2002 г., като част от първата версия на ASP.NET 1.0, той въведе технологията ASMX (Active Server Method Extended), която позволи на разработчиците в най-новото Visual Studio 2002 лесно да създават и използват SOAP уеб услуги. Отбелязвам, че тази технология се нарича официално "XML Web Services" в MSDN. В онези години SOAP тъкмо правеше първите си сериозни стъпки в света на уеб разработката. W3C одобри SOAP 1.1 през 2000 г., SOAP 1.2 през 2003 г. (актуализиран през 2007 г.). Затова беше много важно технологията да бъде лесна за научаване и прилагане за новия стандарт. И тази цел беше постигната - за да работи с уеб услуги, разработчикът дори не трябваше да знае XML, SOAP и WSDL.В следващите години технологията ASMX стана много разпространена и призната. Освен това от самото начало Microsoft предостави добавката Web Services Enhancements (WSE) към него, което позволи прилагането на различни WS-* спецификации за сигурност, като напр.WS-Security, WS-Policy, WS-ReliableMessaging. Последната версия, WSE 3.0, беше пусната през 2005 г. И през 2007 г., като част от .NET 3.0, беше въведена технологията Windows Communication Foundation (WCF), която стана официален заместител на ASMX. Въпреки че технологията ASMX не се разработва дълго време, тя продължава да се използва широко и се поддържа от най-новите версии на .NET Framework.

ASMX и WCF Интересно е да се сравни колко уеб услуги от двата типа вижда Google: 314 000 ASMX и 6 280 WCF Защо ASMX все още е толкова популярен? Всичко е много просто: той е лесен за използване и перфектно решава проблема в повечето случаи. Предимството на WCF се проявява, например, в случаите, когато имате нужда от висока транспортна скорост, дуплекс, стрийминг, съответствие със съвременните стандарти за сигурност, REST. Между другото, ако имате нужда само от REST, тогава вместо WCF трябва да използвате технологията ASP.NET Web API.Изброяваме конкретно предимствата на всяка технология: Предимства на ASMX:

Лесен за разработка Лесен за научаване Без конфигуриране Плюсове на WCF: Много разнообразни и гъвкави възможности за транспортиране Текуща и развиваща се технология Различни опции за хостинг Възможност за внедряване на голямо разнообразие от WS-* стандарти И така, WCF е „швейцарският нож“ в областта на транспортирането на данни, а ASMX е „добра отвертка“. И най-хубавото, разбира се, е да можете да използвате и двата инструмента. Тъй като техниките за разработка на WCF са по-пълни и актуални в мрежата, реших, че трябва да напиша статия за ASMX, която ще бъде полезна за тези, които трябва да поддържат стари уеб услуги, и за тези, които продължават да използват тази технология, за да създават нови.

разработване
Въведение Тази статия описва 20 различни практики, които могат да се прилагат при разработване на уеб услуги с помощта на тази технология.Сценарият за примери ще бъде следният. Има редовно актуализирана база данни с финансови отчети. Необходимо е да се разработи универсален механизъм, чрез който различните клиенти винаги да разполагат с актуални данни за тези отчети. Решение: пишем SOAP уеб услуга с два метода: Първият метод приема период от време и връща идентификаторите на всички отчети, появили се през този период Вторият метод приема идентификатор на отчет и връща самите данни на отчета Потребителите на уеб услуги редовно изпращат заявки към първия метод, като посочват периода от последната им заявка, и ако има идентификатори в отговора, те изискват данни чрез втория метод, както е показано в примера „Прокси клас“.

1. Най-простият дизайн Нека започнем с описанието на най-простия дизайн на уеб услуга. Внимание, примерът е чисто теоретичен! Въпреки че е работник, никога не правете това на практика. Това е само демонстрация на простотата на самата технология ASMX.В Visual Studio създайте нов проект „ASP.NET Empty Web Application“ или „ASP.NET Web Service Application“ с име FinReportWebService. Добавете два файла към него: FinReport.asmx и FinReportService.cs и добавете FinReport.asmx като текстов файл, а не уеб услуга, така че да е един файл.

FinReportService.cs с помощта на System; използване на System.Web.Services; пространство от имена FinReportWebService

Натиснете F5, за да стартирате уеб сървъра и отворете FinReport.asmx в браузъра, трябва да видите

asmx

Готов. Сега нека го вземем по ред. Уеб услугата е представена от един обикновен клас със само една задължителна характеристика - някои от методите й са маркирани със специален атрибут[WebMethod]. Такива методи на клас стават методи на уеб услуга със съответния подпис на повикване. Този клас трябва да има конструктор по подразбиране. С всяка нова заявка IIS я инстанцира с конструктор по подразбиране и извиква подходящия метод.

Втората задължителна част от минималната конструкция е файл с разширение asmx, вътре в който трябва да бъде указан този клас.

Интересно е да се сравни този ръчно генериран asmx файл с този, който Visual Studio ще генерира. Да предположим, че искаме да направим друга уеб услуга, която връща обменния курс. Добавете файла ExchangeRate.asmx с типа уеб услуга чрез менюто Добавяне на нов елемент.

asmx

Като натиснете F7 веднъж или два пъти, можете да видите следното:

използване на системата; използване на System.Web.Services; използване на System.Xml.Serialization; пространство от имена FinReportWebService

Нека да разгледаме промените Атрибутът [WebServiceBinding (ConformsTo = WsiProfiles.BasicProfile1_1)] означава, че уеб услугата се проверява спрямо спецификацията WSI Basic Profile 1.1. Например, той забранява претоварването на името на операцията или използването на атрибута [SoapRpcMethod]. Такива нарушения ще доведат до грешка в уеб услугата „Услугата „FinReportWebService.FinReportService“ не отговаря на спецификацията на Simple SOAP Binding Profile Version 1.0.“. Без този атрибут нарушенията ще доведат само до предупреждение „Тази уеб услуга не отговаря на изискванията на WS-I Basic Profile v1.1.“ Като цяло се препоръчва да добавите този атрибут, който осигурява по-голяма оперативна съвместимост. Атрибутът [WebService (Description = "Financial Reports", Namespace = XmlNS)] има само три свойства:по подразбиране е името на класа)

Наследяването от класа WebService ви дава достъп до HttpContext, HttpSessionState и някои други обекти, които могат да бъдат полезни в някои случаи.

Атрибутът [WebMethod (Description = "Извличане на отчет по ID")] обикновено съдържа само Description, което описва уеб метода в браузъра, други свойства се използват рядко.

Аз лично препоръчвам капсулиране на входящи параметри и връщани стойности в специални класове. Например, аз ги извиквам, като добавям суфиксите -Arg и -Result към името на метода, което означава аргумент и резултат. В този пример за простота всички те са в един и същ файл FinReportService.cs, но в реални проекти поставям всеки от тях в отделен файл в специална папка от типа FinReportServiceTypes. Също така е удобно да се наследява от общи класове.

На теория за всички ваши собствени класове в уеб методи трябва да укажете атрибутите [Serializable] и [XmlType (Namespace = FinReportService.XmlNS)]. В този случай обаче не е необходимо. В края на краищата, ако се извършва само XML сериализация, тогава атрибутът [Serializable] не е необходим и пространството от имена на XML се взема от атрибута [WebService] по подразбиране. Отбелязвам, че за разлика от WCF, ASMX използва обикновен XmlSerializer, който ви позволява да контролирате широко сериализацията с помощта на стандартни атрибути като [XmlType], [XmlElement], [XmlIgnore] и т.н.

3. Прокси клас, използващ wsdl.exe Помощната програма wsdl.exe е подходящата asmx техника за използване на SOAP уеб услуги. Въз основа на wsdl файл или връзка, той генерира прокси клас - специален клас, който улеснява максимално достъпа до тази уеб услуга. Разбира се, няма значение на каква технология е реализирана самата уеб услуга, тя може да бъде всяка - ASMX, WCF, JAX-WS или NuSOAP. Между другото, WCFподобна помощна програма се нарича SvcUtil.exe , Помощната програма се намира в папката C:\Program Files (x86)\Microsoft SDKs\Windows, освен това е представена там в различни версии, в зависимост от версията .net, битовата дълбочина, версията на Windows и визуалното студио.

asmx

wsdl http://192.168.1.101:8080/SomeDir/SomeService? wsdlwsdl HabraService.wsdl

Нека направим клиент за FinReportWebService. В текущото или ново решение създайте нов проект на Windows Forms FinReportWebServiceClient. Добавете папката ProxyClass в нея, копирайте помощната програма wsdl.exe в нея и създайте пакетния файл GenProxyClass.bat в нея: wsdl /n: FinReportWebServiceClient.ProxyClass http://localhost:3500/FinReport.asmx? wsdlpause

С аргумента /n: FinReportWebServiceClient.Proxy />

Добавете бутон във формуляра и следните три метода в изходния код на формуляра:

Най-важните свойства на прокси класа са Url и Timeout, където времето за изчакване е посочено в милисекунди и 100 секунди е стойността му по подразбиране. Сега можете да ги използвате, за да тествате уеб услугата. Демонстрация на работата на допълнителни трикове ще бъде показана чрез извикване на метода GetReport и попълване на полето result.Report.Info.Ако е създаден прокси клас от wsdl файл, който препраща към външни xsd схеми, всички тези схеми трябва да бъдат изброени в командата:

wsdl /n: MyNamespace HabraService.wsdl Data.xsd Common.xsd Schema.xsd

Въпреки това, в допълнение към ръчното създаване на прокси клас, Visual Studio ви позволява да го създадете автоматично. Елементът „Добавяне на справка за услугата“ ви позволява да създадете прокси клас с помощта на технологията WCF, а там в „Разширени“ има бутон „Добавяне на уеб справка“, който го създава вече с помощта на технологията ASMX.4. Клас на сървъра според този wsdl Както знаете, wsdl описанието на уеб услуга в технологията ASMX се генерираавтоматично. Понякога обаче възниква обратната задача: да се разработи уеб услуга, съответстваща на този wsdl файл. Решава се с помощта на същата помощна програма wsdl.exe. Той може да създаде необходимия скелет от класовете и ще трябва само да внедрите програмната логика на уеб методите.Нека вземем wsdl на нашата уеб услуга като пример. Запазете го от браузъра като файл FinReport.wsdl или копирайте от тук:

FinReport.wsdl отчети Получаване на списък с идентификатори на отчети по период Получаване на отчет по ID Фин. доклади

Създайте нов празен уеб проект в решението с име FinReportWebServiceByWsdl. Добавете папката ServerClass към нея и копирайте файловете FinReport.wsdl и wsdl.exe в нея. Създайте пакетен файл GenServerClass.bat в него: wsdl /server /n: FinReportWebServiceByWsdl.ServerClass FinReport.wsdlpause

Като го стартирате, трябва да получите файла FinReportService.cs. Включете и четирите файла в решението.

asmx

И така, както можете да видите, единствената разлика от генерирането на прокси клас е атрибутът на сървъра. Това създава абстрактен клас, наследен от WebService с абстрактно описани уеб методи. Можете да наследите от него, но все пак трябва да копирате всички атрибути, така че предлагам да го направите по следния начин. Копирайте дефиницията на класа в нов файл и пространство от имена, премахнете думата abstract и напишете изпълнението на методите. След като форматирах кода, получих следния файл