Уеб услуги с asp. Net
Изтегляне 0.86 Mb.
|
- Навигация на страницата:
- Принцип на действие на уеб услугите
- Пренос на SOAP съобщения по HTTP
- Инфраструктура на уеб услугите
- Директории за уеб услуги
- Universal Description, Discovery, and Integration (UDDI)
- Примери за UDDI директории
- DISCO (Discovery of Web Services)
- Структура на WSDL описанието
- SOAP – формат на заявките
- Структура на SOAP съобщенията
- Обмяна на SOAP съобщения – пример
- Протоколен стек на уеб услугите
Уеб услугиУеб услугите са нова ера в разработката на разпределени приложения. Те предоставят ново ниво на абстракция над вече съществуващите модели, което стои над езиците за програмиране, операционните системи и мрежовите комуникационни протоколи. Възползвайки се от вече изградените технологични модели в Интернет и базирайки се изцяло на отворени стандарти, уеб услугите се превръщат в основната инфраструктура, която свързва всички компютърни устройства. Преди да се спрем по-подробно на технологията на уеб услугите, нека първо обясним какво всъщност означава терминът “услуга”. Какво е услуга?В реалния живот услугата представлява единица работа извършена от доставчика на услуги. На всеки от нас му се случвало да му се развали телевизора или да му се запуши водопроводен канал. В такъв случай ние извикваме техник и той трябва да реши проблема, като представи пред нас желания резултат – поправен телевизор или отпушен канал. В описаните сценарии ние се явяваме клиенти на услугата, т.е. нейни консуматори, а фирмата, за която работи техникът, неин доставчик. Услугата има ясно дефинирани входни параметри и ясна цел (изходни резултати). Тя има различни качествени характеристики: цена на самата услуга, време за нейното извършване, коректност при изпълнението й и други. Услугата е лесна за използване – ние не се интересуваме по какъв начин нашият телевизор ще бъде поправен или колко усилия ще изразходва водопроводчикът за да отпуши канала – за нас е важно работата да бъде свършена. Услугата е и винаги достъпна при нужда от нея. Какво е уеб услуга?Уеб услугите не само наподобяват услугите от реалния живот, но и моделират тяхното поведение. Те представляват програмни компоненти (някаква специфична логика, изчислителен ресурс или определена информация), които са достъпни отдалечено през уеб. Уеб услугите са достъпни на практика от всеки клиент, който поддържа връзка с уеб, защото използват отворени Интернет стандарти за комуникация. Те са независими както от операционната система, така и от платформата и езиците за програмиране, на които се разработват. Архитектурно уеб услугите са функционално независими компоненти и са слабо обвързани с клиента, който ги използва (loosely coupled). Клиентът поръчва, услугата изпълнява поръчката и връща резултата обратно при клиента. Клиентът не се интересува как точно работи уеб услугата и за да я използва не трябва да знае нищо повече за нея освен какви входни данни да й подаде.
Уеб услугите използват утвърдения в Интернет и при уеб технологиите модел „заявка/отговор” (request/response), т. е. за всяка една отделна заявка към сървъра, той връща отделен отговор специално за нея. По същия модел работят и уеб приложенията [TODO: link] – уеб клиентът подава HTTP заявки, а уеб сървърът ги обработва и връща HTTP отговор. Пренос на SOAP съобщения по HTTPПри уеб услугите протоколът за пренос на заявките и отговорите по подразбиране е HTTP, но като такъв може да се използва и всеки друг протокол, който може да пренася XML данни. Следващата фигура илюстрира използването на HTTP за пренос на SOAP съобщения: 
HTTP заявката се състои от две части: хедър, който съдържа различни параметри на заявката (информация за самата заявка и за клиента, който я изпраща) и тяло, което съдържа SOAP съобщението. SOAP съобщението се състои също от две части: данни (SOAP body) и метаданни (SOAP header). В хедъра на HTTP заявката се посочва нейният вид. В примера е използвана HTTP-POST заявка по версия 1.1 на HTTP протокола. В хедъра се задава още типът на съдържанието (Content-Type), който трябва да е text/xml, тъй като SOAP съобщенията представляват XML. Заявката задължително трябва да съдържа и хедъра SOAPAction, дори и ако той е без съдържание. Неговото предназначение е да укаже същността на SOAP съобщението. След като получи така формираната заявка, сървърът изпраща отговор, който може да е или със статус 200 OK (успех), или статус 500 Internal Server Error (грешка). Грешка се връща, ако SOAP съобщението, изпратено като отговор, съдържа SOAP Fault, т. е. възникнал е проблем (изключение) при изпълнението на услугата. Инфраструктура на уеб услугитеСлед като проследихме в детайли как се транспортират SOAP заявките и съответните им отговори, сега ще разгледаме цялата инфраструктура на уеб услугите – съвкупността от стандартите, моделите и принципите, на които те се базират. 
Инфраструктурата на уеб услугите е изградена върху няколко основни принципа: тя прави услугите лесно достъпни, самоописващи се и използващи вече утвърдени и стандартизирани протоколи за комуникация. На схемата по-горе са представени отделните компоненти от цялостната инфраструктура на уеб услугите:
Всички тези компоненти са обвързани помежду си и изграждат цялостната инфраструктура на уеб услугите. Ще се спрем по-подробно на всеки един от тях. Директории за уеб услугиДиректориите за уеб услуги представляват единно място, където различни производители публикуват информация за услугите, който предлагат. Директориите са като уеб указател за услуги (каталог). Самите уеб услуги са организирани в различни категории, като по този начин е улеснено намирането на услуги за определена цел или поставена задача. Директориите предлагат търсене на услуги по зададени параметри (производител, категория, име). Публикуването и търсенето на информация за дадена уеб услуга става посредством UDDI стандарта. Universal Description, Discovery, and Integration (UDDI)UDDI представлява отворен XML базиран стандарт за регистриране, откриване и свързване към уеб услуги. Спецификацията му е разработена първоначално съвместно от Microsoft и IBM, а в момента се поддържа и развива от консорциума OASIS (Organization for the Advancement of Structured Information Standards). UDDI сам по себе си също е уеб услуга. Нейната функционалност включва регистрация и търсене на други услуги. Microsoft предлага набор от класове (UDDI SDK), чрез които могат да се разработват приложения, използващи цялата мощ и гъвкавост на UDDI. Тези класове напълно съвпадат с описаните в спецификацията на UDDI стандарта.
Забележка: в скоби са адресите, които могат да се използват за тестови цели или по-време на разработка. Ето как изглежда UDDI директорията на Microsoft: 
На картинката можем да видим, че сме намерили уеб услуга, която ще ни предостави информация какво е времето в голяма част от международните летища. Освен тази услуга компанията-производител (Cape Clear Software) предлага още няколко, които можем да видим в лявата част на прозореца. В детайлите за услугата се вижда и нейният Service Key. В UDDI регистрите при регистрирането на дадена уеб услуга, на нея й се дава уникален идентификатор – Service Key, който я прави уникална в глобалната мрежа. Този идентификатор след това може да се използва за динамичен достъп до услугата през UDDI. Откриване на уеб услугиРазгледахме какво представляват UDDI директориите за услуги, а сега ще проследим процеса на откриване на уеб услуги. Този процес има за цел локализация и извличане на описанията на уеб услуги, разположени върху даден сървър. За откриването на услугите се използва DISCO спецификацията. DISCO (Discovery of Web Services)DISCO спецификацията е разработена от Microsoft и името и идва от нейното предназначение. DISCO е също XML базиран стандарт и има изключително проста структура. Неговата цел е да посочи връзката към файла с описанието на уеб услугата, връзката към самата услуга и връзка към документация за услугата. Документите с DISCO описание се съхраняват във файл с разширение .disco. Ето пример за такъв файл:
Обикновено .disco файлът се разполага в главната директория на съответната уеб услуга. Например, ако услугата е разположена на уеб сървъра www.myserver.com и се казва math и главната й директория е със същото име, то пътят към .disco файла за тази услуга ще бъде http://www.myserver.com/math/math.disco. Уеб услугите, разработени с ASP.NET, връщат своя disco файл, когато са извикани с параметър ?disco, например http://www.myserver.com/Demo-5-Service-Types/TypesService.asmx?disco. UDDI и DISCOКакто вече разбрахме, и UDDI и DISCO ни предлагат начини за откриване на уеб услуги. А каква е разликата между двата стандарта? UDDI ни предоставя централизирано място регистриране на услуги, където те са разпределени в различни категории, спрямо някакви признаци. Ако искаме нашата уеб услуга да е обществено достъпна и лесно откриваема, трябва да я регистрираме в UDDI регистрите. Стандартът DISCO ни дава възможност за откриване на всички уеб услуги, разположени локално на конкретен сървър, поради което е много удобен в процеса на разработката на софтуер. DISCO е и тясно интегриран с Visual Studio .NET. Някои уеб услуги може да нямат DISCO описание, защото то не е задължителна, а само препоръчителна част от уеб услугите. WSDL описания на услугиСледващата важна част от инфраструктурата на уеб услугите е тяхното описание. За да можем да използваме дадена уеб услуга, трябва да знаем нейния интерфейс за достъп. Той представлява описание на методите, които уеб услугата предоставя, техните имена, входни и изходни параметри, използваните типове данни и други метаданни за самата услуга. За описанието на интерфейса и начина на достъп до уеб услуги се използва XML базираният език WSDL (Web Services Description Language), чете се „уиздъл”. Той също е отворен стандарт и с неговото развитие се занимава W3C (World Wide Web Consortium). Едно от предимствата на WSDL е, че той е разширяем във всяко едно отношение. Той нито ни обвързва с конкретен транспортен протокол, нито изисква определена схема, по която да описваме сложните типове, които използваме в нашите услуги. Така е възможно различни технологии да използват различни XML базирани описания на типовете данни, с които работят. Също както връщат своя disco файл, уеб услугите разработени с ASP.NET, връщат WSDL описанието си когато бъдат извикани със специалния параметър ?wsdl. Например: http://www.myserver.com/Demo-5-Service-Types/TypesService.asmx?wsdl WSDL описание – примерНека да разгледаме по-подробно WSDL описанието на една примерна уеб услуга – услугата TypesService.asmx (вж. примера от точка "Прехвърляне на типове"):
Структура на WSDL описаниетоWSDL изгражда едно абстрактно описание на услугата – поддържаните методи, използваните типове данни, начин за достъп до услугата, както и самият й адрес. По-важни елементи от WSDL описанието са:
Ето и диаграма, която представя описаните връзки между отделните елементи на WSDL описанието: 
SOAP – формат на заявкитеСлед като разгледахме как се откриват и описват уеб услугите, сега ще се спрем на най-важната част от тяхната инфраструктура, а именно как те се пренасят в хетерогенна среда каквато е Интернет. В ядрото на уеб услугите стои SOAP стандартът, благодарение на който клиентът и доставчикът на услуги обменят съобщения помежду си. SOAP (Simple Object Access Protocol) e XML базиран формат за обмяна на структурирана и типизирана информация в уеб пространството. При създаването на стандарта е спазван един основен принцип – той да не бъде усложняван допълнително (сложни архитектури като CORBA, вече са показали, че не са ефективни в Интернет), от тук идва и неговото име.
Предимства на SOAPНе само заради своята простота SOAP е получил подкрепата на Microsoft, IBM, Sun Microsystems, SAP и др. Ето някои други негови преимущества:
Развитието на SOAPВ началото на своето развитие (1998 г.) SOAP спецификацията се e свързвала главно с технологията на XML базираните отдалечени извиквания на методи – XML-RPC (Remote Procedure Call). Тя е описвала по свой собствен начин типовете, които са се предавали между клиента и сървъра. През 1999 г. създателите на SOAP залагат на XML Schema (XSD), чрез която да описват типовете, използвани в SOAP съобщението. По-късно, през 2001 г., XSD е приет официално от W3C като препоръчван стандарт за обмяна на XML съобщения. Постепенно SOAP набира популярност и получава подкрепата на Microsoft. Формира се версия 1.0 на стандарта. IBM и други софтуерни компании виждат преимуществата на SOAP и през пролетта на 2001 г. заедно с Microsoft изготвят версия 1.1. Промените спрямо версия 1.0 са незначителни, но по-важното е, че вече целта на SOAP не е единствено отдалеченото извикване на методи. SOAP сам по себе си вече представлява framework за обмяна на XML базирани съобщения. Тогава е предложена пред W3C и приета като официален стандарт спецификацията SOAP версия 1.1. В момента SOAP стандартът има версия 1.2, като промените спрямо 1.1 не са значителни (една от тях е, че SOAP вече не е акроним, а просто име). В .NET Framework 1.1 е реализиран SOAP версия 1.1.
На следващата фигура е показана структурата на едно просто SOAP съобщение. Можем да видим и пространството от имена, което в случая е http://schemas.xmlsoap.org/soap/envelope/ спрямо версия 1.1 на SOAP стандарта. Във версия 1.2 това пространство е сменено и неговият нов идентификатор в глобалната мрежа (URI – Uniform Resource Identifier) е: http://www.w3.org/2003/05/soap-envelope/. 
След като разгледахме примерното SOAP съобщение, сега ще се спрем по-подробно на основните негови елементи: хедър и тяло. SOAP хедърЕлементът хедър не е задължителен в едно SOAP съобщение, но ако той присъства задължително трябва да е преди тялото на съобщението. Неговата цел е да разшири самото съобщение като добави допълнителна мета информация (метаданни) извън тялото. Тази информация може да има различен характер. Ето и някои от най-честите приложения на SOAP хедъра:
SOAP тялоЗа разлика от хедъра SOAP тялото е задължителен елемент, защото в него е разположена същността на съобщението. Тялото може да съдържа какъвто и да е текст (в частност XML), стига неговата структура да не разваля тази на съобщението. Има два вида SOAP съобщения: процедурно-ориентирани (procedure-oriented) и документно-ориентирани (document-oriented). При документно-ориентираните съобщения всякакъв вид информация може да бъде кодирана (encoded) и изпратена до съответния получател. .NET Framework, например, ни дава възможността и да сериализираме даден обект чрез SoapFromatter (вж. темата "Сериализация на данни" [TODO: link]) и да го изпратим като SOAP съобщение. За разлика от документно-ориентирани съобщения при процедурно-ориентираните се осъществява двустранна комуникация между клиента и сървъра. Клиентът изпраща заявка към сървъра, като в тялото на съобщението указва, кой предоставен метод иска да извика и с какви параметри. Сървърът обработва заявката и връща отговор, съдържащ резултата от изпълнението на метода, обратно към клиента.
Всяка точка е представена като структура с две координати. Методът, който ще се извика на сървъра с параметри двете точки, е CalcDistance. Ето и отговорът, който ще се върне след неговото успешно изпълнение:
SOAP грешка (fault)Тялото на SOAP съобщението може да съдържа и информация за възникнали грешки или изключения при изпълнението на услугата. Информацията за грешката, ако има такава, се записва в елемента fault. Ето тялото на примерно SOAP съобщение със SOAP грешка, което е изпратено към клиента, защото на сървъра е хвърлено изключение:
SOAP fault може да съдържа няколко елемента. Ето по-важните от тях:
Протоколен стек на уеб услугитеУеб услугите, както вече може би сте се убедили, обединяват в себе си много технологии. За всяка отделна част от тяхната инфраструктура има отделен стандарт, който описва как се извършва взаимодействието с останалите части от инфраструктурата. За да изясним взаимоотношенията между отделните стандарти и протоколи, нека разгледаме следващата фигура, която описва отделните слоеве от комуникацията с уеб услугите: 
Ще започнем отдолу нагоре, като се движим от по-общите стандарти към тези, който са по-тясно свързани с уеб услугите. На ниво транспорт стои протоколът HTTP, който е в основата на WWW и уеб технологиите. Както вече знаем, HTTP реализира модела „заявка - отговор”, който се използва и при уеб услугите. Един от недостатъците на HTTP е, че не поддържа стандартно сесия, т. е. той е stateless (няма състояние). Всяка заявка е отделна за себе си и независима от останалите. По тази причина уеб услугите най-често реализират функционалност, при която не се пази състояние, но чрез специални техники, които ще разгледаме по-нататък, този проблем може да се преодолее. Основното предназначение на HTTP е да пренася данни от уеб сървъра към клиента. В случая на уеб услугите тези данни са под формата на XML. Със своята простота, мощ и разширяемост XML е най-универсалният начин за пренасяне на структурирана информация в глобалната мрежа. Именно поради това, XML е в основата на всички стандарти и протоколи, свързани с уеб услугите. Описанието на структурата и формата на предаваните във вид на XML данни се извършва чрез XSD схеми. Чрез XSD се описват типовете данни, пренасяни при извикването на уеб услуги. Чрез вече описаните типове се изгражда абстрактният програмен интерфейс на услугата чрез езика за описание на уеб услуги (WSDL). SOAP стандартът осигурява инфраструктура за изпращане и получаване на XML съобщения, чрез които се извикват предоставените методи от уеб услугата и се получава резултатът от тяхното изпълнение. Ето и една диаграма, която показва взаимовръзките между отделните протоколи и стандарти, разделени в три логически стека: стек за обмяна на съобщения, стек за описания и стек за откриване на уеб услуги: 
Каталог: dotnetcourse -> Beta1 Beta1 -> Изграждане на графичен потребителски интерфейс с Windows Forms Beta1 -> Асемблита и разпространение Beta1 -> Управление на паметта и ресурсите dotnetcourse -> Въпрос: Кога е нужно да слагам в класовете си свойства, и кога мога да слагам публични полета? Не е ли вторият вариант по-удобен, особено когато едно поле не се валидира по никакъв начин? Отговор Beta1 -> Отдалечени извиквания с. Net remoting Beta1 -> Сериализация на данни Изтегляне 0.86 Mb. Сподели с приятели:
|