Уеб услуги с ASP.NET Автори
Деян Варчев, Стефан Добрев
Необходими знания -
Базови познания за .NET Framework
-
Базови познания за езика C#
-
Базови познания за ASP.NET
-
Начални умения за работа с Visual Studio .NET
-
Познания по XML
-
Атрибути
Съдържание -
Инфраструктурата на уеб услугите
-
Разпределени приложения
-
Нуждата от уеб услуги
-
Услуги и уеб услуги
-
UDDI директории за уеб услуги
-
Откриване на уеб услуги (DISCO)
-
WSDL описания на услуги
-
SOAP – формат на заявките
-
Протоколен стек на уеб услугите
-
Сценарии за използване на уеб услуги
-
.NET Enterprise приложения
-
Уеб услугите в ASP.NET
-
Архитектура
-
Създаване и публикуване на уеб услуги
-
Използване на уеб услуги. Генериране на междинен (прокси) клас
-
Уеб услугите и VS.NET – създаване и консумиране
-
Атрибути за уеб услугите – [WebService], [WebMethod]
-
Прехвърляне на типове (type marshalling)
-
Разгръщане (deployment) на уеб услуги върху IIS
-
Дебъгване на уеб услуги
-
Моделът на изпълнение на уеб услугите в ASP.NET
-
Асинхронно извикване
-
Уеб услуги и работа с данни
-
Поддръжка на сесии
-
Сигурност на уеб услугите. Сигурност чрез сесии
-
Изключенията в уеб услугите
В тази тема ...
В настоящата тема ще разгледаме уеб услугите и работата с тях чрез средствата на .NET Framework и ASP.NET. Ще изясним концепциите и стандартите, които стоят в основата на уеб услугите, и ще обясним защо те са се превърнали в стандарт за интеграция и междуплатформена комуникация. Ще се запознаем с различни сценарии за използването им. Ще разгледаме приложението на уеб услугите за изграждане на многослойни .NET Enterprise приложения. Ще разгледаме програмния модел за уеб услуги в ASP.NET и средствата за тяхното изграждане, изпълнение и разгръщане (deployment). Ще се спрем и на някои често срещани проблеми и утвърдени практики при разработката на уеб услуги чрез .NET Framework и ASP.NET.
Възникването на уеб услугите
В зората на Интернет основна цел е била да се направят публично достъпни определени документи, статии и други ресурси за хора, които са били заинтересовани от тяхното съдържание. С бързото развитие на Интернет технологиите в края на 90-те години Интернет става място не само за уеб страници, но и единно място за обмяна на съобщения и информация между различни приложения. Липсата на единен стандарт за описанието и разпространението им, както и нуждата от адаптери за интеграция на вече съществуващите технологии, пораждат изграждането на нов независим (както от самото приложение така и от платформата, на която е разположен) стандарт – SOAP (Simple Object Access Protocol). Днес работата на всяко уеб базирано приложение, което е отворено към света, е немислима без уеб услугите, защото те са се превърнали в стандарт за междуплатформена комуникация и интеграция и се основават на вече утвърдили се в глобалната мрежа модели и стандарти.
Разпределени приложения
В днешно време повечето приложения се състоят от няколко отделни компонента, които взаимодействат помежду си, и заедно решават една обща задача. Чрез разделянето на няколко съставни части, логиката на самото приложение се разпределя между отделните му компоненти, всеки от които е логически обособен, има ясна отговорност и може да е разположен физически на отделен компютър. Оттук идва и името на самите приложения – разпределени. Основен принцип при съставянето на всеки компонент е той да изпълнява добре дефинирана задача (strong cohesion) и да е логически независим (loosely coupled) от останалите компоненти.
Модели за разпределени приложения
С годините еволюцията на софтуерните технологии е преминала през различни модели на разпределени приложения, всеки от които има своите силни и слаби страни. Да разгледаме някой от тях:
-
Модел „Клиент/Сървър” – при този модел приложението е двуслойно. На сървъра са разположени данните за системата и общата за всички логика, а при клиента стои приложение, което взаимодейства с потребителите и комуникира със сървъра. Типичен случай на такава система е сървър с база от данни и множество клиенти, които работят с общите данни от сървъра.
-
Модел „Разпределени обекти” – този модел предоставя възможност за отдалечен достъп до обекти, като позволява създаване на обекти върху отдалечен сървър и извикване техни методи. Ето някои архитектури, които използват този модел:
-
DCOM (Distributed Component Object Model) – представлява разширение на COM модела в Windows операционни системи, което позволява COM компоненти, инсталирани на отдалечени една от друга машини, да комуникират помежду си. COM/DCOM архитектурата е разработена от Microsoft и въпреки, че е пренесена и върху други платформи, нейното основно предназначение си остава най-вече за операционните системи на Microsoft Windows.
-
CORBA (Common Object Request Broker Architecture) – представлява отворен стандарт за комуникация между обекти, разположени върху отдалечени една от друга машини. Стандартът е разработен от консорциума OMG (Object Management Group). Въпреки, че прави комуникацията независима както от езика, на който са написани приложенията, така и от операционната система, върху която се изпълняват, CORBA не е набрал популярност заради голямата си сложност и трудността за имплементация.
-
Java RMI (Remote Method Invocation) – представлява стандарт за разпределени приложения, разработен от Sun, и базиран на Java платформата. Позволява комуникация между отдалечени обекти, разработени на Java, чрез отдалечено извикване на методите им. За разлика от CORBA и DCOM, RMI е значително по-опростен, но работи само с Java обекти.
-
.NET Remoting [TODO: link] – представлява технология, използвана в .NET Framework, която осигурява лесен и прозрачен достъп до отдалечени .NET обекти. Работи само с .NET обекти.
-
Модел „Уеб услуги” – базиран е изцяло на отворени стандарти за отдалечени извиквания, в чиято основа стои XML. Най-често за комуникацията се използват HTTP протоколът и моделът заявка-отговор, което прави Интернет и WWW идеални за преносна среда на уеб услугите, а от там идва и името им. Уеб услугите се самоописват чрез езика WSDL и това значително опростява използването им.
Уеб услугите са настоящето и бъдещето на разпределените приложения. В самата си същност те представляват функционално независими програмни компоненти и извеждат междуплатформената комуникация на ново ниво на абстракция, което е зависимо от компанията-производител, използвания програмен език или софтуерна платформа.
Нуждата от уеб услуги
Вече разгледахме някои от вече съществуващите модели за разпределени приложения и изтъкнахме част от недостатъците им. Сега ще се спрем по-подробно на нуждата от уеб услуги и ще изясним защо се е стигнало до тяхното създаване.
Недостатъци на модела „Клиент/сървър”
Моделът клиент-сървър (двуслойна архитектура) не пасва добре на идеята за разпределените приложения, защото с нарастване на сложността им нараства и нуждата от създаването на повече от два слоя.
Остава възможността да се използва модел за отдалечена комуникация, които позволява изграждането на многослойни разпределени приложения. Двата най-често използвани подхода за това са "Разпределени обекти" и "Уеб услуги".
Недостатъци на модела „Разпределени обекти”
С широкото навлизане на Интернет и неговото масово използване се е зародила нуждата от разпределени приложения, които да комуникират помежду си посредством глобалната мрежа.
Моделът „Разпределени обекти” не е създаден с презумпцията, че трябва да използва Интернет като преносна среда. Всеки един от разгледаните разновидности на модела е разчитал на свой собствен протокол за пренасяне на информацията. Добавяйки наличието на защитни стени (firewalls) в Интернет пространството, комуникацията между отделните приложения става силно затруднена.
Основен проблем при технологиите тип "Разпределени обекти" са липсата на междуплатформена съвместимост (interoperability) и трудностите при изграждането на хетерогенна инфраструктура за предоставената услуга. Използването на отдалечен обект или негов метод изисква, при клиента да е имплементирана същата архитектура, каквато и на сървъра, а това води до силна технологична обвързаност между доставчика на услугата и нейните консуматори.
Още един проблем на разглеждания модел е поддръжката на различни версии и настройки на приложението. За да може клиентът да използва даден отдалечен обект, той трябва да е съобразен с версия на приложението, което е разположено на отдалечената машина, както да използва и идентични настройки с него.
Изисквания за съвременните разпределени приложения
Недостатъците на модела „Разпределени обекти” формират изисквания, на които трябва да отговаря съвременната архитектура за разпределени приложения. Някои от тях са следните:
-
Междуплатформена комуникация – отдалечените програмни компоненти трябва да са достъпни за клиенти с различни операционни системи, изградени върху различни софтуерни платформи и с различни езици за програмиране.
-
Базирана на отворени Интернет стандарти и технологии – различните компоненти на разпределените приложения трябва да са лесно достъпни през Интернет и да се възползват изцяло от предимствата на глобалната мрежа. Те трябва да не са технологично обвързани с даден доставчик.
-
Самоописание – архитектурата за разпределени приложения трябва да предоставя възможност за самоописание на програмните компоненти, което да позволява тяхното използване без да е необходимо предварително познаване на структурата им и интерфейсът за достъп до тях.
Уеб услугите решават всички тези проблеми, а освен това откриват и нови хоризонти пред разработчиците на разпределени приложения. Нека ги разгледаме в детайли.
Сподели с приятели: |