Уеб услуги с asp. Net
Сценарии за използване на уеб услугите
Изтегляне 0.86 Mb.
|
- Навигация на страницата:
- Услуги към клиентски приложения
- Интеграция на приложения
- Връзка между отделните компоненти на Enterprise приложения
- Кои приложения са Enterprise
- .NET Enterprise приложения
- Бизнес логика в уеб услуги
- Разпределени приложения (Distributed Applications)
Сценарии за използване на уеб услугитеСлед като се запознахме с архитектурата и инфраструктурата на уеб услугите, сега нека разгледаме различни сценарии, в които можем да използваме уеб услуги. Уеб услугите намират все по-голямо приложение при изграждането на разпределени системи, защото са слабо обвързани с клиента, използват отворени стандарти и на практика са „почти” универсални. Ето някои от най-често срещаните сценарии, в които уеб услугите играят важна роля. Доставяне на данниЕдно от най-честите приложения на уеб услугите е за реализиране на достъпа до база данни (или информация съхранена на отдалечено място). Единствената роля на уеб услугата в този случай е да се свържи с доставчика на данните, да ги извлече и после да ги предостави на клиента. Следната диаграма илюстрира този сценарий: 
Услуги към клиентски приложенияС нарастване на употребата на уеб услугите, много приложения (в това число и MS Office) предоставят възможност за използване и консумиране на услуги директно. По този начин се избягва изграждането на междинен слой между услугата и клиентското приложение, а това подобрява вътрешната структура на приложението. С масовата употреба на уеб услуги, на която сме свидетели, се очаква все повече настолни и сървърни приложения да се възползват от тяхната мощ. Интеграция на приложенияДруг много често срещан сценарий за използването на уеб услуги е за интеграция между различни приложения. Самата интеграция може да е:
В ролята на адаптериПри някои приложения уеб услугите могат да влизат в ролята на адаптери, т. е. да трансформират по зададени правила и схеми входящото съобщение и да го препращат по веригата към неговия получател. 
Такова приложение на уеб услугите не е масово разпространено, но успешно се използва в редица големи софтуерни проекти. Използването на уеб услугите като трансформиращи адаптери е концепция, успешно имплементирана в Microsoft BizTalk Server, където има отделен framework за разработка на адаптери. Връзка между отделните компоненти на Enterprise приложенияВ последните години се налага тенденцията различните компоненти на едно Enterprise приложение (ще разгледаме по-подробно Enterprise приложенията след малко) да комуникират помежду си чрез уеб услуги. Голяма част от новите продукти на Microsoft освен стандартен потребителски интерфейс (уеб приложение или Windows desktop приложение) предлагат и уеб услуга, чрез която разработчиците могат да използват и надграждат приложението (уеб услугата представлява API за достъп до основната функционалност). Следващата картинка илюстрира използването на услуга за връзка към базата данни в трислойно приложение. В него чрез класовете от ADO.NET за достъп до базата данни се извличат данните под формата на DataSet обекти. Уеб услугата обработва тези данни и от създава бизнес обекти, които се изпращат към клиента чрез SOAP съобщения:
Enterprise приложенияСлед като разгледахме най-честите приложения на уеб услугите, сега ще се спрем по-подробно на Enterprise приложенията и ще видим защо уеб услугите играят ключова роля при тяхното изграждане. Кои приложения са Enterprise?"Enterprise приложенията" означава многослойни разпределени приложения, които отговарят на изискванията на големите корпоративни клиенти. Те се състоят от множество компоненти, които са интегрирани помежду си и работят като едно цяло. За да отговарят на съвременните бизнес изисквания и стандарти, тези разпределени приложения трябва да имат следните характеристики:
.NET Enterprise приложенияПо-принцип Enterprise приложенията са многослойни, но класическата архитектура за тях си остава трислойната: слой за данните, бизнес слой и презентационен слой. Няма да се спираме подробно на тази архитектура, защото подробно вече разгледахме нейните характеристики в темата "Достъп до данни с ADO.NET" [TODO: link]. Ще разгледаме само изграждането на бизнес слоя чрез уеб услуги. Бизнес логика в уеб услугиВ съвременните системи все по-често цялата бизнес логика на приложението бива изнесена в уеб услуги. Това е така, защото уеб услугите са лесно достъпни през Интернет и осигуряват възможност за междуплатформена комуникация, т. е. техните консуматори може да са много различни: уеб приложения, Windows Forms клиенти, мобилни устройства, както и други смарт клиенти (smart clients). [TODO: да се добави препратка към темата "Архитектура на платформата .NET и .NET Framework"] Уеб услугите отварят системата към взаимодействие с различни крайни клиенти, реализирани върху различни платформи. На следващата диаграма е показана схематично класическата трислойна архитектура, реализирана със средствата на .NET платформата с използването на уеб услуги: 
Разпределени приложения (Distributed Applications)Както вече знаем, многослойните разпределени приложения също спадат към групата на Enterprise приложенията. Многослойните приложения са по-комплексни от трислойните, но при тях скалируемостта е по-голяма, защото отделните компоненти могат да се разположат на различни сървъри и да се оптимизират поотделно (разпределянето, върху няколко сървъра, на отделни уеб услуги или компоненти от едно приложение, се нарича "уеб ферма" – web farm). Следващата диаграма показва визията на Microsoft за изграждането на разпределени приложения: 
Да започнем разглеждането на диаграмата отгоре надолу. Най-отгоре стои потребителят, който вижда единствено потребителския интерфейс за работа с приложението. Той не се интересува нито каква база от данни използваме, нито от колко слоя е изградена архитектурата; за него е важно колко е бързо и надеждно е приложението. Препоръчва се да няма никаква вградена (hard-coded) информация в компоненти, който осъществяват UI (User Interface), а всякаква логика по навигацията да се изнесе в отделни компоненти (UI Process Components). Следва бизнес слоят, който е разделен на четири компонента:
На най-ниско ниво са разположени компонентите за достъп до базата (Data Access Logic Components) и компонентите, които указват как външни услуги могат да използват тези предоставени от системата. Паралелно с цялата тази структура върви и предоставената ни от .NET Framework богата функционалност за управление на сигурността и изключенията. Каталог: dotnetcourse -> Beta1 Beta1 -> Изграждане на графичен потребителски интерфейс с Windows Forms Beta1 -> Асемблита и разпространение Beta1 -> Управление на паметта и ресурсите dotnetcourse -> Въпрос: Кога е нужно да слагам в класовете си свойства, и кога мога да слагам публични полета? Не е ли вторият вариант по-удобен, особено когато едно поле не се валидира по никакъв начин? Отговор Beta1 -> Отдалечени извиквания с. Net remoting Beta1 -> Сериализация на данни Изтегляне 0.86 Mb. Сподели с приятели:
|
