Стопанска Академия
“Димитър Апостолов Ценов”
гр. Свищов
Тема:
Платформа Microsoft .NET
Изработил: Златка Юриева Маринова;
Специалност: Информатика - I I курс, 11 група.
Съдържание
1. Увод - 3 стр.
2. Основни Концепции - 3 стр.
2.1 История
2.2 Услуги на .NET
3. ADO.NET - 5 стр.
3.1 Управлявани доставчици
3.2 Множества за данни
4. ASP.NET - 7 стр.
4.1 Поддържане на компилирани езици
4.2 Разпределяне на кода от съдържанието
4.3 Контроли за Web
4.5 Интерактивен проект на графичен интерфейс
4.6 Конфигуриране на приложенията за Web
5.Услуги на .NET в Web - 10 стр.
5.1 Концепции
5.1.1 Основни положения
5.1.2 WSDL
5.1.3 Консумиращи услуги за Web
5.2 Изследване на услуга за Web
6.Дистанционна работа с .NET - 12 стр.
6.1Концепции
6.1.1Прокси (заместител)
7. Заключение - 14стр.
8. Използвана литература - 16стр.
1. Увод
Рамката .NET е средата за интерпретиране на програми написани на Visual Basic .NET, Visual C#, Visual C++ 7.0 и т.н. .NET въвежда някой фундаментално нови концепции в компютърната методология на Microsoft. Например, видяхме, че целият код на рамката .NET се изпълнява вътре в CLR, което наподобява виртуалната машина на JAVA интерпретиращи кода преди изпълнението му.
Многото промени в .NET са добре посрещнати допънения и към всички езиците за прогмиране на Microsoft, и към операционна система, в която работи той, но рамката е нещо повече от просто архитектурно допълнение към средата на Windows. За да оцените значението на Microsoft. За да оцените значението на .NET, трябва да се впуснем в изследване на света.
2. Основни Концепции
2.1 История
Ландшафтът на разработване се променя значително през последните 5 години. Едно от най-значимите нововъведения, които се появиха на последък е движението JAVA, ръководено от Sun Microsystems. Въпреки че идеите на “Отворената архитектура”, “Напиши еднократно, използваи произволна операционна система” и “виртуална машина, интерпретираща код” са известни сравнително отдавна, стремителното навлизане на Интернет създаде “Критичната маса”, необходима за вкореняването на тези идеи в основният поток на разработване.
Първата битка между Microsoft и Sun по отношение на компилираният спрямо интерпретирания код се проведе при броузърите, където Microsoft се противопостави на JAVA с ActiveX. ActiveX e традиционна, компилаторна технология, основана на COM (Component Object Model). Докато аплетите на JAVA се изтегляха в браузъра и се интерпретираха в реално време от Java Virtual Machine (VM), компилираните библиотеки за динамично свързване (DLL) на контролите на ActiveX се изтегляха във файловата система на клиента от браузъра, регистрираха се и се стартираха като компилиран код. Стратегията на ActiveX се използва рядко в основните сайтове в интернет, докато аплетите на JAVA са вездесъщи.
Втората битка на технологии се провежда сега и мястото и е не в браузърите, а в корпорациите. Бойното поле тук е сървърът, мястото, където в действителност се намират модерните приложения. В модерната софтуерна архитектура преминахме към малки клиенти на основата на браузър в предния край, а в тила се намира сървър за Web, който поделя средната част с някъква форма на сървър на приложения, съдържащ логиката на фирмата.
Може да се каже, че през последните години войната се водеше между сървъра за приложения на Microsoft, Microsoft Transaction Server (MTS) и J2EE на JAVA. MTS (COM+ в Windows 2000) помества компоненти, които пишете, ако сте ги компилирали в машинен код и се придържате към правилата на COM. J2EE осигурява средства за изавършване на същото (чрез нещо наречено Enterprise JavaBeans, или EJB), но тук съществуват много различни производители, осигуряващи сървъри за приложения, които да поместват вашите компоненти. MTS/COM+ работи само под операционните системи на Microsoft, но подържа компоненти, написани на множество програмни езици, ако те следват правилата на COM. Двойката J2EE/сървър на приложения би работила на произволна платформа, но единствения език позволен на от нея, е JAVA. Без значение колко теоритични са аргументите, те се свеждат до спора компилиране срещу интерпретиране. И така двата лагера се присъждат към техните традиционни сили .... докато не се появи .NET
2.2 Услуги на .NET
С .NET Microsoft в действителност изоставя традиционната си позиция в полза на компилираните компоненти и възприема технологията на интерпретирането. С въвеждането на Common Language RunTime, Microsoft може да предложи последователно множество от услуги на нивопредприятие на всеки, който използва рамката .NET.
Не е изненадващо, че .NET беше изградена като изцяло насочена към Интернет. XML се използва в рамката и като инструмент за съобщения, и за конфигурационни файлове. Един навлизащ в момента в момента конфигурационен портокол, наречен SOAP, позволява на компоненти да взаимодействат (да прехвърлят данни, да извършват обръщения RPC) чрез отворените стандарти на Интернет като XML и HTTP. ADO.NET, новата версия на ADO на Microsoft, е основан на разпределен модел на достъп без състояние, който е естествен за приложения за Web. Разработчиците за Интернет ще посрещнат добре и WebForms (част от ASP.NET), която придава традиционната лекота и гъвкавост на формите на Visual Basic на приложенията за Интернет. Накрая, Remoting на .NET позволява на обединенията плавно да комуникират по изградените портоколи като TCP/IP. В тази глава ще разгледаме различните узлуги на корпоративно ниво в рамката .NET.
3. ADO.NET
ADO.NET е новият модел за достъп до данни за рамката .NET. ADO.NET не е просто прехвърляне на популярния модел ADO в управляваната среда, а напълно ново понятие за достъп и управление на данни. ADO.NET беше проектиран изцяло, като се взе предвид разпределения модел на Интернет. Той беше изграден върху следните два основни принципа на проектиране:
Несвързани данни: В ADO.NET почти цялата обработка на данни се извършва извън контекста на отворена връзка към базата данни. Данните се четат в елемент, наречен Dataset (множество за данни), след което базата данни се затваря незабавно. Операции като актуализации, вмъквания и изтривания се извършват при необходимост върху множеството за данни. Когато базата данни е готова за актуализация, тя се отваря отново и данните се прехвърлят от множеството за данни. Този модел е подходящ за приложения за Web, тъй като те не са свързани непрекъснато с техните бази от данни.
Универсален обмен на данни по XML. Множествата за данни могат да бъдат управлявани и предавани чрез отворения стандарт XML. Поконкретно, едно множество за данни може да запише съдържанието си в XML. Значително ограничение на традиционния ADO беше факта, че той можеше да се използва само от клиенти, работещи с COM. Като се използва стандартният XML обаче, данните на ADO.NET могат лесно да се прехвърлят към клиенти, които не използват Windows, без поддържане на COM. Toва е особенно важно в хетерогенната среда на интернет, където може да е необходимо сътрудничество с машини без Windows, използващи UNIX или друга среда.
Като имаме предвид тези принципи, можем да разделим обектния модел на ADO.NET на два слоя, управляваният доставчик, който извършва действителната комуникация с базата от данни, и несвързаното множество за данни, което съхранява данните.
3.1 Управлявани доставчици
Управляваните доставчици са отговорни за комуникациите с базата от данни. Подобно на стандартите OLEDB и ODBC, концепцията за управлявания доставчик не е предназначена за конкретна система на база от данни. Вместо това управляваните доставчици са насочени към предлагането на общи характеристики на релационните системи за бази от данни чрез прост програмен интерфейс. Това се извършва със следните четири класа:
Connection. Много подобен на обекта Connection na ADO, използван за изграждане на връзка към база от данни.
Command. Използва се за изпълняване на запитвания към база от данни.
DataReader. Съхранява резултатите от запитване към база от данни. DataReader е много оптимизиран метод за преглед на данните в посока напред и само за четене.
DataAdapter.Посредникът между управлявания доставчик и несвързано множество за данни, DataAdapter използва командите Select, Insert, Update и Delete за достъп и промяна на съдържанието на база от данни.
В сърцевината на ADO.NET се намира обектът Dataset. С помоща на обекта DataAdapter може да запълвате множеството за данни със значещи данни. След това базата от данни се затваря и цялата информация се записва временно в Dataset. Промените в Dataset (вмъквания, актуализации и изтривания) не се извършват в базата от данни, а се извършват изцяло в паметта на DataSet. Единственият момент, когато се променя реалната база от данни е, когато явно DataAdapter за актуализацията й. Въз основа на инструкциите от Dataset, DataAdapter ще използва съответния управляван доставчик, за да наложи желаните модификации в дадената база от данни.
Несвързаният модел, който току-що обрисувахме, е предназначен за използване от приложения за Web, които по своята природа нямат състояние. Чрез извършването на по-голямата част от обработката на данни се пестят ресурси и се повишава производителността.
Рамката .NET се доставя с два оптимизирани управлявани доставчика в следните именни пространства:
System.Data.Oledb. Управляван доставчик OLEDB.
System.Data.SqlClient. Управляван доставчик за SQL сървър.
3.2 Множества за данни
Множество за данни е представяне на базата от данни вътре в паметта. Въпреки че е изкусително множеството за данни вътре в паметта. Въпреки че е изкусително множеството за данни да се разглежда като еквивалент на Recordset (множество за записи) на ADO, те в действителност са много различни. Множеството за записи на ADO беше основано върху единичен изглед на базата от данни. Обратно, множеството за данни може да съдържа множество таблици и отношенията към тях. Освен това, едно множество за данни може да подсили релационните ограничения във връзките между данните, съдържащи се в него. Следователно е по-добре множеството за данни да се разглежда като олекотена база от данни в паметта.
В по-предната част на доклада обясних, че DataAdapter се използва за запълване на множеството за данни с информация от базата от данни. Това обаче не е единственият метод за получаване на данни от множество за данни е във възможността му да получава, съхранява и предава информация или от база от данни, или от XML. Данните, записани в базата от данни, се означават като релационни данни, тъй като са разделени в таблици и с определени отношения между тях. От друга страна, данните записани в XML се наричат йерархични данни, основани на структурата на родословно дърво (елементи родител/дете/кръвни роднини). Тъй като множествата за данни могат да предават информация към и от релационен или йерархичен източник, разработчиците вече не са ограничени в използването на един модел за представяне на данните им.
Поддържането на XML от множество за данни е също така жизнено важно за поделянето на данните в приложенията за Web. На практика, приложенията за Web на .NET представят данните като XML към клиентите, тъй като не може да определите предварително с какъв програмен език е бил разработен клиентът или на каква платформа се разполага. Използването на отворен стандарт като XML гарантира, че голямото множество клиенти ще има достъп до данните от компонентите на .NET.
Едно пълно разглеждане на множествата за данни изисква въвеждането на теми като “силно типизиране” и отношения в XML чрез схеми и транзакции, които са извън обхвата на тази глава.
4. ASP.NET
ASP.NET е следващото поколение на технологията Active Server Pages (ASP), използвана за създаване на разпределени приложения за Web. ASP.NET беше разработен за решаване на някой от недостатъците на традиционния ASP и за вграждане на много нови свойства, отдавна изкани от разработчиците за Web. Тази част от темата ще разгледам накратко основните свойства на ASP.NET, включително поддържането за напълно компилирани езици, разделянето на кода от съдържанието, Web контроли и интуитивно проектиране на графичен потребителски интерфейс.
4.1 Поддържане на компилирани езици
Един от пороците на ASP беше в това, че той поддържаше само скриптови езици. Тези езици, например JavaScript или VBScript, обикновенно осигуряват само подмножество на функционалността, предлагана от завършените среди за разработване като JAVA или Visual Basic. Друг недостатък е в това, че скриптовите езици са слабо типизирани, което означава че всички променливи са от тип Variant или вътрешните типове. Това често води до податлив на грешки код, тъй като по време на проектирането не се извършва проверка на типовете.
ASP.NET се стреми да внесе мощността на традиционните настолни приложения в Web. Един от начините за реализация на това от ASP.NET е чрез добавянето на поддържане за напълно компилирани езици. Вместо използването на VBScript, ASP.NET ви позволява да използвате пълният език VB.NET. Това дава на разработчиците за Web достъп до традиционно недостъпни свойства като силно типизиране и обектно-ориентирано програмиране.
4.2 Разпределяне на кода от съдържанието
Ако някога сте работили с ASP, вероятно познавате слабостта на смесването на HTML с скриптов код. Това често води до неуправляван код и по дължина, и по стил, често означаван като код “спагети”. ASP.NET решава този проблем с дефинирането на ясно разграничаване между HTML интерфейса и обединенията на .NET, които обхващат работната логика. Това води не само до по-лесен за поддържане код, но и позволява на екипите по проектирането и разработването да работят заедно по-плавно върху приложенията за Web.
4.3 Контроли за Web
Кото следва принципите на обектно-ориентираното програмиране, страниците на ASP.NET използват контроли от сървъра, наречени контроли за Web. Тези контроли, които са пълноценни обекти, се намират изцяло на сървъра. Когато едно приложение за Web се зарежда, то определя възможностите на браузъра в заявилия го клиент. След това контролите за Web се визуализират в клиента като стандартен HTML или DHTML (ако последният се поддържа от браузъра). Тъй като контролите за Web се намират в сървъра и се визуализират като чист HTML, клиентите могат да получават достъп до страниците на ASP.NET без да ползват рамката .NET. Освен това, тъй като възможностите на браузъра се определят автоматично, усъвършенстваните браузъри получават усъвършенствани функции (рамки, DHTML и т.н.), докато по-примитивните браузъри все още имат възможност за достъп до приложенията.
ASP.NET се доставя с голямо разнообразие от контроли за Web, обхващащи функции, които преди това изисквали голямо количество код на HTML и скриптове за реализацията си. Те могат да бъдат разделени на следните категории:
Присъщи контроли. Тези контроли за Web обикновено обхващат стандартни елементи HTML в обектите (HTML текстови полета и бутони).
Обогатени контроли. ASP.NET в моментa се доставя с два обогатени обекта, по-точно AdRotator (за извеждане на рекламни лозунги в страница) и календарен контрол. Обогатените контроли са предназначени да обхващат усъвършенствани потребителски интерфейси на HTML и скриптов код в съответния Web обект.
Контроли за проверка. ASP.NET се доставя с множество контроли за Web, опростяващи процеса на проверка на въвеждането на потребителя. Например, има контроли, които гарантират, че дадено поле съдържа стойност, намира се в определен интервал от стойности, или съвпада с обичаен израз. Силата на тези контроли е във възможността им да се използват в комбинации, за да гарантират гъвкава проверка на входа.
Списъци и контроли за данни. Тези контроли за Web осигуряват гъвкави начини за извеждане на данни в разделен на елементи списък. Контролите са в интервала от прост Repeater (повторител, обикновено елементарен списък само за четене) до изключително “редактируемия” контрол DataGrid.
ASP.NET осигурява също така устойчиво множество от свойства за свързване на данните от база от данни или XML към почти всеки контрол на ASP.NET за потребителски интерфейс.
4.5 Интерактивен проект на графичен интерфейс
Благодарение на VS.NET, интерфайсите за Web на ASP.NET могат да се проектират със същата лекота, която това се прави и за формите на VB6.
4.6 Конфигуриране на приложенията за Web
Един от големите проблеми с ASP беше трудността, свързана с конфигурирането на приложения за Web. Конфигурацията на приложенията първо се записваше в елемент, наречен метабазата на IIS, който много трудно се преместваше на отделна машина. ASP.NET решева този проблем, като премества цялата конфигурация в гъвкъви конфигурационни файлове XML. За правилното разгръщане на приложенията за Web е важно правилното разбиране на конфигурационните файлове.
5.Услуги на .NET в Web
Услугите за Web са софтуерни компоненти, които се предлагат през отворените стандарти на Интернет HTTP и XML. Приложенията, работещи на отдалечени машини с потенциално различни платформи могат да имат достъп до тези компоненти, независимо от езика. Точката представя концептуален преглед на услугите за Web.
5.1 Концепции
5.1.1 Основни положения
Услугите за Web обикновено работят под покровителството на Internet Information Server (IIS) на Microsoft. Подобно на страниците на ASP.NET, услугите за Web са написани с напълно компилирани езици на .NET като VB.NET, Visual C++ и C#. Единствената разлика между обикновения компонент на .NET и услуга за Web е това, че някои методи са маркирани “с възможност за извикване по Web”. Това означава, че клиентите имат възможността за достъп до тези методи по Интернет.
Когато една услуга е заявена от клиент, IIS се грижи за инсталирането на компонента на услугата за Web и извикването на заявения метод. Услугите за Web не поддържат състояние между заявките за методите. Това означава, че всяко обръщение към услугата за Web води до инсталирането на нов компонент. Частните променливи от ниво клас следователно не поддължават съществуването си между заявките за методи. Следователно услугите за Web се използват обикновенно в ситуации, в които се извършва крайно количество работа, след което компонентът не е нужен повече. Например, компонент, които определя и връща текущата цена на борсови акции може да се реализира като узлуга за Web.
Услугите за Web имат предимства, тъй като до тях може да се извърши достъп от произволно място и от всеки, които разбира от HTTP и XML. Тъй като съобщенията към и от една услуга пътуват по HTTP, услугите за Web не се “спъват” от огнени стени. Това е особено важно при корпорациите, които биха искали да предложат обширна работна логика на клиентите си по Web, но не искат да нарушат защитата на собствените си мрежи.
5.1.2 WSDL
За да могат клиентите да използват една Web услуга, трябва да е напълно достъпно описание на методите и типовете, предлагани от услугата, както и конвенциите за обръщение. Услугите за Web публикуват предлаганите от тях методи и типове чрез документ, написан с граматика на XML, познат като Web Service Description Language (WSDL - език за описания на услугите за Web).
При запитване IIS автоматияно генерира документа WSDL за дадена услуга в Web. Разбирането на структурата на един документ WSDL е важно, когато се разработват клиенти, използващи тази услуга.
5.1.3 Консумиращи услуги за Web
След като е определил метода, предлаган от една услуга за Web с използването на WSDL, клиентът би могъл да го заяви. Припомнете си, че услугите за Web са достъпни на клиентите чрез HTTP или XML. В действителност съществуват три метода за комуникация с услуга за Web, по-точно това са: HTTP GET, HTTP POST и SOAP. Разликата между тези три протокола се крие в предаването на параметрите към услугата за Web. В случая на HTTP GET и HTTP POST, параметрите на метода на услугата за Web се предават като двойки име=стойност (например, х=0, у=1). При SOAP (Simple Object Access Portocol - прост портокол за достъп до обект) от другата страна, параметрите се предават като документ на XML, вграден в съобщението на HTTP.
Предимството на запитванията на SOAP е в това, че може да опишете сложни типове за данни (например множества за данни на ADO.NET) вместо прости двойки име=стойност. Разбира се, тази допълнителна гъвкавост е за сметка на производителността. Тъй като XML много по-многословен от двойките име=стойност, съобщенията на SOAP изискват повече време за предаване и интерпретиране от съобщенията HTTP GET / HTTP POST.
Запомнете, че за извикване на услуга за Web са необходими само HTTP и XML. Клиентите могат да бъдат в интервала от браузър за Web до приложение на Visual Basic 6.
5.2 Изследване на услуга за Web
Тъй като файлът WSDL описва методите и типовете, предлагани от една услуга за Web. Ако една компания иска да разгърне услуга за Web, достъпна за широка публика, трябва да съществува някакъв начин, по който клиентите да могат да намерят и получат документите WSDL. Това се извършва с друг тип документи на XML, познат като файл Web Service Discovery (или DISCO).
Когато един клиент заяви DISCO файл от определен Web сайт, IIS динамично определя услугите за Web, достъпни в този сайт. След това IIS връща файла DISCO на клиента, като той сочи към всички подходящи документи WSDL. Файлът DISCO може да се използва за създаване на клиент, който подходящо се обръща и интерпретира резултатите от една услуга за Web.
6.Дистанционна работа с .NET
Дистанционната работа с .NET позволява на обектите в различни домяйни за приложения, били те на една и съща или на различни машини, да комуникират едно с друго. Тъй като един домейн на приложение (AppDomain) e управляваната среда, създадена от CLR за поместване на приложение на .NET. Рамката за дистанционна работа осигурява гъвкаво множество от услуги за опростяване на процеса на пораждане, създаване на екземпляри, поместване и взаимодействие между отдалечени обекти.
Концептуално, дистанционната работа с .NET (.NET Remoting) e много подобна на рамката на услугите за Web - и двете ви позволяват да комуникирате с отдалечен обект. Разликата е в количеството гъвкавост в ръцете на разработчика. Докато услугите за Web поставят условие, че клиентът трябва да се намира в IIS и трябва да комуникира с използването на HTTP, дистанционната работа не налага тези ограничения.
Обектите за дистанционна работа не трябва да бъдат поставени под прякото наблюдение на огромен сървър за Web като IIS, нито пък трябва да се придържат към един комуникационнен портокол. Добавената гъвкавост, обаче е за сметка на сложността. Дистанционната работа с .NET може бързо да навлезе в трудните концепции за жизнен цикъл на обект, наемане и контекста на дистанционната работа.
6.1Концепции
6.1.1Прокси (заместител)
Дистанционната работа с .NET е основана на концепцията на обект-заместител. Когато вашето приложение клиент използва отдалечен обект (такъв на друга машина), то не говори директно с компонента. Вместо това то говори с обект-заместител, който предава обръщенията към действителния обект. Чрез тази илюзия заместителят работи като посредник между клиента и сървъра, като обхваща цялата логика, необходима за пакетиране и предаване на съобщенията между двата елемента.
Механизмът, използван от обект-заместител за комуникация с отдалечения обект, се нарича канал. Тъй като за Web услугите комуникират с клиенти, като използват XML по HTTP - познат по-точно като SOAP. Дистанционната работа дава на разработчика повече свобода при определянето на механизма за комуникация. Например, разработчиците могат да изберат между следните комуникационни портоколи, поддържани от рамката .NET:
HTTP. Подобен е на услугите за Web. Съобщенията между клиента и сървъра действат като стандартен HTTP, в повечето случаи през порт 80. Това е подходящо в случаите, когато клиентът е разделен от сървъра с “огнена стена” (fire wall).
TCP. В случаите, когато огнените стени не са проблем, каналът TCP предлага по-голяма производителност.
Може допълнително да настроите процеса на комуникация, като избирате формат за кодиране и декодиране на съобщенията към и от отдалечения обект. Рамката .NET се доставя с два стандартни формата, които вървят ръка за ръка със стандартните канали:
SOAP. Данните се предават като стандартни пакети на XML в съобщения HTTP.
Binary (двоично). Данните се пакетират в компактна (при това вътрешна) двоична система.
По подразбиране, каналът HTTP използва форматирането SOAP, за да кодира и декодира съобщения към и от отдалечен обект. Високопроизводителния канал TCP, от другата страна, използва двоичното форматиране по подразбиране. Забележете, че дистанционната работа с .NET е проектирана по екстензивен начин, така че да позволи на трети страни да направят собствена настройка или да проектират техни собствени канали и формати.
6.2Дистанционна работа
Припомнете си, че компонентите на услугите за Web не поддържат състояние между обръщенията към методите. Винаги, когато един клиент се обръща към услуга за Web, тя се създава, използва и разширява. Дистанционната работа с .NET е значително по-гъвкъва. В зависимост от изискванията ви, един отдалечен обект може да бъде конфигуриран по един от следните три начина:
Единично повикване. Отдалеченият обект се създава с единствената цел да отговори на едно запитване (един конкретен клиент), след което обектът се отстрънява.
Стек. Отдалеченият обект се създава за обслужване на запитванията от различни клиенти.
Активирани от клиента обекти. Както предполага името, този отдалечен обект се създава при запитване от клиент. Активираните от клиента обекти остават свързани с този специфичен клиент.
Конфигурирането на отдалечен обект като обект за единично повикване има смисъл, ако обектът се заявява от клиента за извършване на определено количество работа, след което обектът не е нужен повече. Например, един обект за единично повикване може да изчисли и върне стойност на лихва. Един обект стек, от друга страна, се използва в случаите, когато множеството клиенти разговарят едновременно с един и същи отдалечен обект и поделят данните помежду си. Сървърен обект-стек може, например, да обслужва машина за разговори. Накрая, активираните от клиента обекти работят отлично, когато един клиент се нуждае от достъп до отдалечения обект, при това постоянно извиква методи от обекта. В този случай поддържането на отдалечения обект за няколко запитвания намалява претоварването, свързано със създаването на екземпляри на компонентите.
6.3 Поместване на отдалечен обект
След като сте решили каква да бъде конфигурацията на отдалечения обект (единично повикване, стек или активиран от клиента), както и кой комуникационен канал ще се използва, следващата стъпка е отдалеченият обект да се помести на сървъра. Тъй като услугите за Web се поместваха от IIS. Когато за една услуга пристигне запитване SOAP, IIS се грижи за създаването на екземпляр и за насочването на обръщенията към методите към съответния компонент на .NET. Отдалечените компоненти също могат да бъдат поместени в ISS. На машините без ISS обаче, може също така да поместите и отдалечен обект в стандартен изпълним файл на .NET. И в двата случая, всичко, което е необходимо, е наличието на домейн на приложение, в който да се намира компонента. Освен това, разработчикът трябва да регистрира отдалечения компонент в рамката за дистанционна работа, като използва конфигурационните файлове за дистанционна работа.
7. Заключение
Рамката .NET не е просто нова работна среда на Visual Studio, a агресивна стратегия на Microsoft за разработване на софтуер и на ниво предприятие, и за лични нужди. Като определя, че всички приложения на .NET работят вътре в CLR, рамката .NET може да предложи устойчиво множество от инструменти за работа чрез Base Class Library.
ADO.NET e новата версия на ADO на Microsoft и се основава на несвързания модел за приложения за Web, които са вътрешно без състояние. Новата версия на ASP на Microsoft, наречена ASP.NET, придава традиционната лекота и гъвкавост на формулярите на Visual Basic на птиложенията за Интернет.
Две услуги в рамката .NET позволяват на клиентите да комуникират дистанционно с обекти. Услугите за Web предлагат обекти през отворените стандарти за Интернет като XML и HTTP. Обектите на услугите за Web се създават всеки път, когато бъдат извикани и, следователно са без състояние. Дистанционната работа с .NET позволява на клиентите да комуникират с обекти, като използват по-специализирани комуникационни механизми като TCP/IP. Отдалечените обекти могат да поддържат състояние и могат да се използват в области, в които допълнителните ресурси отделяни за HTTP от услугите за Web е съществено.
8. Използвана литература
