|
Технология .NET, все что вы хотели знать, но боялись спроситьОпубликовано в журнале "Компьютер Price" http://www.comprice.ru/ Иван Марциновский <zanzabuku@mail.ru> Алексей Смирнов < axells@mail.ru> .Net in the USSR boys
You don't know how luck you are boys. .Net is the US .NET is the US .NET is the USSR Песня ".Net in the USSR", Band on the Runtime, 2003 Презентация от MicrosoftВ последнее время все что-то дарят Петербургу и его жителям, и Microsoft тоже решила не оставлять петербуржцев без подарка. За пару недель до 300-летнего юбилея нашего славного города она провела у нас небольшое шоу с презентацией своих новых больших программных продуктов - Windows 2003 Server (который раньше носил гордое название Windows Server .NET) и Visual Studio .NET. Конечно, мероприятие не могло обойтись без подробного представления самой концепции Microsoft .NET (читается "Майкрософт" дот нэт или точка нэт), которая в ближайшем будущем будет оказывать существенное влияние не только на все новые программные продукты компании Microsoft, но, по заявлениям разработчиков, и на весь рынок ПО для персональных компьютеров (на рынок Windows-совместимых программ - это уж точно). С новыми предложениями от Microsoft гостей знакомили патриархи IT-технологий - Джордж Баллок, менеджер проектов корпорации Microsoft, Дэвид Чаппел, глава компании Chappell & Associates и Тэд Паттисон, руководитель отдела разработки компании Subliminal Systems. Сначала в полушутливой форме, посредством исполнения веселых песенок под блюзовые мотивы, а потом и в более серьезной, читая лекции и доклады. По их признанию, вместе их сплотила любовь к новой технологии .NET, а также желание рассказать как можно большему числу программистов о новых возможностях, которые она открывает посвященным. Зажигательное музыкальное трио, которое они составили, было названо ими "Band on the Runtime". Проблемы, стоящие перед программистами, не использующими .NETСовсем-совсем давно (по меркам развития компьютерных технологий, а на самом деле всего-то 10-15 лет назад) программы писались для настольных ПК, которые не были связаны ни в локальную сеть, ни тем более в глобальную систему. Программы были не очень большие, вопросы безопасности еще не стояли так остро, как сейчас (достаточно было запереть комнату, в которой находился компьютер, и уже никто не мог иметь доступ к вашим конфиденциальным данным), поэтому ПО разрабатывалось в приемлемые сроки, программист обычно писал код с "нуля". Максимум, что он мог себе позволить для облегчения своей участи, - это использовать исходный код библиотечных функций, разработанных сторонними производителями. Но время неумолимо бежало, и пользователи стали требовать все более сложные и громоздкие программы, которые должны были работать на нескольких машинах, связанных в единую сеть. Так зародилась идеология программирования клиент-сервер, и это послужило началом появления множества проблем и головных болей у программистов всего мира, которые во сто крат усилились, когда потребовалось реализовывать программы, функционирующие в Интернете (да-да, в этой открытой неконтролируемой сети, имеющей разнородную структуру). Подумайте, как просто (относительно) управлять автомобилем на учебной площадке и насколько это труднее сделать на переполненной транспортом автостраде. Тот же автомобиль, тот же водитель, но совершенно другое окружение. Теперь в каждое серверное приложение потребовалось вносить код, отвечающий за безопасность (выполняющий аутентификацию пользователей, решающий, имеет ли пользователь право делать то или это, шифрующий передаваемые через сеть и хранимые на сервере данные, предоставляющий удобные средства администрирования и так далее и тому подобное). Что самое главное, оказалось, что этот код, повторяющийся из приложения в приложение, писать в одиночку (одной небольшой компании) очень и очень тяжело. Вы либо не укладываетесь в необходимые сроки, либо ваши приложения получаются непомерно дорогими (естественно, ведь помимо программистов, разбирающихся в той отрасли, для которой предназначено ваше ПО, вам потребовалось бы нанять еще кучу высококлассных специалистов по безопасности). Одним из выходов из сложившейся ситуации на какое-то время служила технология COM (Component Object Model), появившаяся в 1993 году. Она позволяла программистам не писать весь код приложения "с нуля", напротив, можно было реализовывать прикладную логику ПО с помощью компонентов, купленных у сторонних поставщиков. Но у технологии COM существуют свои недостатки, например, все компоненты должны находиться на одном компьютере (хосте), иначе их использовать не удастся. Поэтому дальнейшим развитием идей COM стала концепция DCOM (Distributed COM), которая расширяла имеющиеся у ее предшественницы возможности, разрешая объектам находиться на различных компьютерах (например, внутри локальной сети). Предположим, вы все же написали свою программу, справившись со всеми описанными выше трудностями. При этом чудесным образом вам еще и удалось уложиться в бюджет. Теперь представим себе еще более невероятную вещь: приложение вышло удачным, и теперь его хотят купить буквально все. Но... эти "все" ограничены кругом пользователей Solaris, поскольку именно под нее делалась программа. Обидно, не правда ли? Особенно, если вспомнить, сколько сегодня пользователей у Solaris... Естественно, хочется, чтобы ваша программа работала абсолютно везде и для этого вам не пришлось бы переделывать ни строчки кода. К сожалению, сейчас существует просто устрашающее количество всевозможных железософтовых платформ, разобраться в которых не под силу никому. Конечно, лидирующее место занимает Wintel (что бы там ни говорили по этому поводу фанаты Unix), и под нее, собственно, пишется большинство ширпотребных программ и игрушек, но игнорировать все другие - не лучшее решение. Кроме того, если вы пишете веб-приложение, которое должно выводить результаты своей работы в виде интернет-страницы, доступной для просмотра любому жителю Интернета, не стоит забывать про проблему отображения HTML-кода. В старые добрые времена HTML был простым и одинаково выглядел во всех броузерах. А теперь? Internet Explorer, Netscape, Opera, Mozilla - все они по-разному отображают контент сайтов. Некоторые вообще не поддерживают скрипты, а другие и помыслить страницу без них не могут. Что уж говорить про владельцев различных мобильных устройств, которые при помощи своих маленьких друзей лезут в www, как мухи на варенье? Тут, наверное, и комментировать ничего не нужно - разное ПО, разные физические размеры экрана - проблем выше крыши! И приходится писать для разных обозревателей разные странички. Конечно, можно оставаться в рамках HTML-тэгов, которые поддерживаются ВСЕМИ платформами (да-да, есть пара-тройка таких тэгов, которые везде отображаются одинаково, что, право, иногда даже удивляет), но тогда кроме слабо форматированного текста вам ничего пользователю показать не удастся. Текст без графики - в начале XXI века это звучит слишком грустно, согласитесь. Поэтому мы считаем, что это не самый удачный подход. Другая серьезная проблема, появившаяся вместе с распространением Интернета, - неизвестное происхождение устанавливаемого ПО. Раньше (по крайней мере, во всем цивилизованном мире, а не в России) весь софт приобретался в магазинах, и покупатель мог быть почти на 100% уверен, что купленный им Doom произведен действительно ID Software. Теперь же производители любят распространять ПО через Web, поскольку это дешевле, проще и удобнее для потребителя, чем торговля через розничную сеть. Сегодня во многих странах больше половины всех устанавливаемых на ПК программ скачиваются из сети, не говоря уже о том, что огромное количество людей ежедневно посещает Web-страницы, которые могут содержать различные сценарии, и порой весьма зловредные. Даже документы MS Office могут нести в себе небезобидные макросы. Возникает желание опробовать ПО, полученное от компаний, про которые мы никогда раньше и не слышали, как-нибудь так, чтобы можно было не опасаться за безопасность хранящихся на компьютере данных. Это можно сделать по-разному. Например, фирма Sun предложила выполнять программы, написанные на придуманном ею языке Java в специальной среде - Virtual Java Machine, которая изолирует их от всей остальной системы. Но такой подход имеет некоторые ограничения, да и приложения будут выполняться довольно медленно. Что же предлагает Microsoft? Попробуем ответить на этот вопрос, хотя вы, наверное, уже догадались, что ее ответ - это .NET, которая поможет решить все возникающие проблемы. Концепция .NETКак уже упоминалось, Microsoft возлагает на нее огромные надежды и пророчит, что эта технология радикально изменит процесс программирования и разработки ПО. Причем программирования не только настольных, но и интернет-приложений, и даже целых порталов. Основная идея такова: не нужно компилировать исходный код программы сразу в машинные команды, вначале нужно просто записать программу на каком-нибудь промежуточном языке, для которого будет существовать свой компилятор у каждой аппаратной платформы и любой программной среды выполнения (под словом "любой" подразумевается, что если таких платформ будет хотя бы 90% из всех существующих, это уже будет колоссальное достижение.) Этот язык получил название Microsoft Intermediate Language, или MSIL. Большинство программ и компонентов будут храниться на компьютере не в виде готового к исполнению машинного кода, который можно сразу отображать в память, а в виде PE-файла (Portable Executable File), который содержит CLR-заголовок, блок метаданных и блок IL. Такой файл будет компилироваться по требованию среды выполнения только в момент запуска приложения. Таким образом, мы получаем ответ на один из вопросов, описанных в начале статьи. Теперь можно сделать так, чтобы одна и та же программа работала на нескольких платформах. Цена за такую универсальность - более медленное выполнение приложения и необходимость устанавливать некую надстройку над операционной системой, которая будет предоставлять приложению необходимые интерфейсы и управлять выполняемым кодом, такая среда была названа Common Language Runtime (CLR). В операционных системах от Microsoft CLR будет предоставлять пакет .NET Framework, который по желанию может установить себе каждый. В Windows 2003 Server эта среда является неотъемлемой частью ОС, и избавиться от ее присутствия практически невозможно (скажем честно, нам сделать это не удалось, если вы знаете, как выполнить подобный фокус, то обязательно поделитесь своими знаниями с нами). Но и это еще не все! Microsoft решила, что пора бы ей взяться и за Интернет. Перед web-программистами, которые сегодня пытаются создавать конкурентно-способные продукты, стоит серьезная проблема. Все больше интерфейсы сайтов становятся похожими на обычные диалоговые окна какой-нибудь графической операционной системы. Оформление запроса, составление заказа, регистрация - все это достаточно сложно и долго реализовывать при помощи обычного HTML и скриптов. Кроме того, теперь страницы должны отображать не статическую, как было раньше, а динамическую информацию (состав вашей корзины, количество денег на счету, результат обработки какого-либо запроса и так далее). Конечно, это хорошо, что взаимодействие становится интерактивным, но не нужно забывать, что изначально Интернет был очень плохо подготовлен к диалогу, и сегодня за это расплачивается огромная армия web-программистов, тратя значительное время на написание стандартных интерфейсов. Возможный выход из создавшегося положения - использование сценариев, выполняющихся на стороне сервера и генерирующих HTML-странички, которые потом отсылаются клиенту. У Microsoft есть свое собственное решение такого рода - Active Server Pages (ASP), это среда периода выполнения, входящая в состав IIS. Для реализации идей .NET пришлось ASP немного переработать, и получилась ASP.NET, которая очень похожа на оригинальную ASP. Сходство настолько близкое, что большая часть написанного ранее кода может быть переведена на нее практически без изменений. Но внутренняя реализация ASP.NET полностью переделана, с тем чтобы задействовать возможности .NET Framework. Кроме того, ASP.NET позволяет отделять HTML-код от алгоритмов сценариев, создавая так называемый фоновый код (code-behind), что весьма удобно. Вместо того чтобы перемешивать HTML с кодом, вы пишете код в отдельном файле, на который есть ссылка на ASP-странице. На радость web-программистам в ASP.NET включена поддержка Web Forms, что позволяет разрабатывать web-приложение подобно обычному приложению для Windows. То есть теперь можно написать целый сайт прямо в Visual Basic'е или в C#. Web Forms - это удобный инструмент, позволяющий визуально проектировать внешний вид вашей странички, помещая нужные элементы в нужном месте простым Drag&Drop и легко устанавливая связи между ними. Если вы когда-нибудь программировали в Visual Basic'e, то, должно быть, помните, как это делается. Можно комбинировать HTML-код и алгоритмы, написанные на другом языке для ASP. Как видите, Microsoft сделала все, чтобы разработчикам было удобно писать свои программы, более того, утверждается, что среди всех платформ для интернет-программирования в .NET нужно написать меньше всего кода, чтобы получить необходимый (не важно какой) продукт. Сборки и управление версиями в .NETЕсли вы решитесь программировать с использованием платформы .NET, то почти сразу встретите понятие сборки (Assemblies), да это и не удивительно, так как в .NET они применяются почти везде. Сборки - это то, что предлагает Microsoft для управления развертыванием приложений и их безопасностью, а в конечном счете - для упрощения администрирования. Грубо говоря, сборка - это логический набор, состоящий из одного или нескольких файлов. Внутри сборки могут храниться исполняемый код, связанные с ним ресурсы, а также декларация (manifest) - метаданные, описывающие входящие в сборку ресурсы и код. Для чего же нужны сборки? По мнению Microsoft, использование сборок позволит решить вопросы управления версиями и разделение пространств имен. Когда происходило становление Windows - первые окошки и совсем старомодный дизайн - ребята из Microsoft предложили использовать везде, где это только возможно, библиотеки динамической компоновки - это все те файлы, расширение которых заканчивается на DLL (Dynamic Link Library). Мало кто кроме программистов знает, что DLL - это, по сути, те же исполняемые exe-файлы, их отличие состоит в том, что в них собраны не специфичные для каждого отдельного приложения объекты и алгоритмы, а, наоборот, самые общие, используемые всеми программами. К одной и той же библиотеке могут обращаться разные приложения, при этом экономится много места и на жестком диске и в памяти, поскольку вместо нескольких копий одного и того же кода хранится только одна, к которой все и обращаются. Но при этом возникает серьезная проблема, известная как "Ад DLL": если у вас имелась программа, и она использовала некоторую библиотеку, скажем, версии 4.0, а потом вы поставили другую программу, которая эту библиотеку обновила до версии 5.01, то вовсе не обязательно, что ваша старая программа будет после этого работать (хотя все поставщики и поют дифирамбы совместимости снизу вверх). Отчасти из-за этих сложностей, а отчасти из-за проблем управления безопасностью, Microsoft снова выдвинула отличающуюся необыкновенной новизной идею о том, что библиотекам самое место в каталоге приложения, то есть к каждой сборке должен относиться свой экземпляр библиотеки, пусть он будет хоть трижды такой же, как в соседнем каталоге. В ответ на подобные заявления почтовые ящики Microsoft были завалены справедливыми замечаниями о том, что винчестер, извините, не резиновый, и при таком подходе в какой-то мере теряется смысл использования ДИНАМИЧЕСКИХ библиотек, ведь код можно подключать и статически. Конечно, можно рассуждать так: кто же их считает-то, эти гигабайты, пошел в магазин и купил себе еще парочку жестких дисков, стоят-то они, не в пример образцам 90-х, по сто долларов за 50 Гб, но ни к чему хорошему подобные рассуждения не приведут. Это поняли и в Microsoft, создав глобальный кэш сборок GAC (Global Assembly Cache) - звучит грозно, не правда ли? Итак, отныне порешили, что сборки должны быть двух типов: закрытые (private) и разделяемые (shared). Закрытые сборки используются только ОДНИМ приложением и, по идее, должны функционировать бесконечно долго, пока вы сами ее не уничтожите, или пока не сломается какая-нибудь железяка в вашем компьютере. Это, наверное, хорошее решение для особенно важных и близких вашему сердцу программ - Quake, Diablo и Doom III. Другие, менее нужные приложения, например "Офис" и "1С Бухгалтерию", могут использовать разделяемые сборки, которые помещаются в специальную область (каталог WinNT\assembly в Windows 2000), отводимую для сборок с совместным использованием, эта область и есть GAC. В GAC на уровне операционной системы реализована служба управления версиями, цель которой - не допустить замены необходимой вашему приложению компоненты более ранней или более поздней ее версией, если только это не оговорено особо в самом приложении. В GAC одновременно могут храниться разные версии одной и той же сборки, при этом каждое приложение будет обращаться именно к той сборке, для работы с которой оно рассчитано. При этом вы сталкиваетесь с проблемой конфликта имен (разные версии одной сборки имеют одинаковые имена файлов!), чтобы разрешить ее, нужен какой-то способ присвоения гарантированно уникальных имен всем программным файлам, живущим в GAC. Это делается с помощью строгого имени (strong name) или совместно используемого имени (shared name). В декларации совместно используемой сборки содержится открытый ключ из пары открытого и закрытого ключей. Строгое имя формируется в результате комбинирования имени файла и части этого открытого ключа. К сожалению, использование GAC - это слишком обширная тема, а мы вынуждены себя ограничить лишь кратким обзором .NET. Потому всех, кого сборки и управление версиями заинтересовали, мы отправляем получать всеобъемлющую информацию либо в MSDN.NET, либо на сайте Microsoft. Сбор мусора и .NETКак известно, в Windows реализовано динамическое выделение памяти приложениям, поэтому если какой-то программе нужна память, она обращается к системе и получает ее, когда память уже не используется приложением, оно должно вернуть ее операционной системе. Это очень удобно, и такой возможностью пользуются, наверное, все программы для Windows, написанные за последние 8 лет. Но за все нужно платить, и в этом случае платой за гибкость и удобство стала проблема утечки памяти. И если для настольного приложения, работающего, от силы, несколько дней, это не так уж страшно, то для сервера, который должен, по идее, работать годами, утечка памяти становится настоящей бедой. Попробуем объяснить сказанное на примере. Представьте себе, что вы открыли PhotoShop. Пока программа не знает, что вы будете делать дальше - пойдете пить кофе, или тут же ее закроете, или откроете в ней рисунок. Поэтому она просит у Windows ровно столько памяти, сколько нужно, чтобы загрузиться и вывести пустое окно и панели инструментов. Предположим, что вы после этого открываете в PhotoShop рисунок. Программа узнает его размер, количество слоев и другие характеристики только в момент открытия, и сразу же запрашивает у операционной системы необходимое количество памяти. Память выделяется из так называемой "кучи" - области, где создаются временные объекты. Когда вы закрываете рисунок, PhotoShop должен вернуть освободившуюся память ОС. Теперь, внимание! Забота о выделении и возвращении памяти целиком лежит на плечах программиста, который может и "забыть" реализовать в программе эту возможность. Как такое может произойти - очень просто, в нашем примере освобождение памяти должно происходить при нажатии на кнопку закрытия рисунка, так оно и происходит. Но предположим, вы открыли поврежденный файл, при этом вначале PhotoShop выделит под него память, и только потом обнаружит, что файл поврежден. Из-за этого закрыть его стандартным образом вы не сможете, и если процедура высвобождения памяти не будет реализована еще и при обработке исключения, возникающего при открытии поврежденного файла, то мегабайты оперативки уйдут в мусор. Это простейший пример, но если вы представите, сколько различных объектов использует современное сложное приложение, сколько внештатных ситуаций и исключений ему приходится обрабатывать, то поймете, что такие вещи случаются сплошь и рядом, и порой их бывает очень сложно обнаружить. Поэтому существование утечек памяти в достаточно больших приложениях нужно воспринимать как неизбежное, как аксиому, знаете ли. От умения программистов зависит только то, насколько большими будут эти утечки и как часто они будут происходить. Вы спросите: неужели человек, который пишет программу, не может ее сделать такой, какой она должна быть? Без всяких там утечек и протечек? Да, может, конечно. Но стоимость того же PhotoShop'а тогда возрастет в 1000 раз, не говоря уже о том, во сколько раз возрастет время, потраченное на его разработку. Что же делать? Для борьбы с утечками памяти в большие программы обычно включают специальный менеджер памяти, который следит за всеми динамическими объектами и удаляет их, как только они становятся ненужными. Такой модуль называется "сборщик мусора", то есть он собирает и удаляет ненужные, уже не используемые объекты. Это конечно здорово, но чтобы написать такой менеджер, нужно быть профессионалом высокого класса, а нанять такого программиста (хотя бы одного) по карману далеко не каждой фирме. Взвесив все "за" и "против", Microsoft решила включить сборщик мусора в саму среду CLR, так что теперь любая программа, запускаемая в ней, будет автоматически обслуживаться этой утилитой, и ссылки на неиспользуемые объекты будут удаляться. Мало того, что у пользователей теперь не будет засоряться оперативная память ненужным мусором, так и разработчики выиграют от этого! Теперь при создании объекта вы просто пишете оператор new, и все, никаких проблем! Не нужно запоминать область видимости объекта, не нужно беспокоиться о том, что с ним случится, если до места удаления будет сгенерировано исключение. Среда выполнения все берет на себя. Как всегда, встает вопрос о цене, которую мы за это платим. А это такты процессора, потраченные CLR на просмотр всех объектов кучи с целью найти мусор, и на дефрагментацию кучи. Но, по всей видимости, в этом случае жертвы оправданны, кроме того, частоту запуска автоматического сборщика можно настраивать. Вы можете запускать его каждые 2-3 секунды, а можете и раз в день. Взаимодействие с COMКак уже говорилось, при создании платформы .NET разработчики учли, что сегодня огромное количество кода написано с использованием технологии COM, а значит, нужно было бы обеспечить взаимодействие .NET с приложениями, использующими COM, и наоборот, сделать объекты COM доступными в приложениях, выполненных с использованием технологии .NET (хотя последний вариант, на наш взгляд, слишком уж экзотичен). Это было сделано, объекты COM могут выступать по отношению к объектам .NET в качестве как серверов, так и клиентов. Когда объект .NET вызывает COM в качестве сервера, он делает это через вызываемую оболочку периода выполнения (runtime callable wrapper, RCW), она выступает в качестве "обертки" для COM-объекта. Оболочка позволяет клиентам .NET рассматривать COM-объект как простой объект .NET, а сервер в свою очередь думает, что клиент - это обычный клиент COM. Таким образом, все взаимодействие клиент-сервер происходит через RCW. RCW управляется средой выполнения CLR, поэтому вам не придется беспокоиться о сборке мусора после его использования. Немного сложнее обстоит дело, когда .NET вызывается клиентом COM. В этом случае также вызывается специальная оболочка COM callable wrapper (CCW), но теперь уже для .NET-объекта. Она формируется на основе информации о типе объекта, прочитанной в метаданных той сборки, к которой относится данный объект .NET. Как и в случае с RCW, CCW выступает в качестве Proxy, обеспечивающего бесшовное взаимодействие между двумя объектами. Для работы с CCW сборка компонента .NET должна быть подписана строгим именем. В противном случае среда CLR не сможет однозначно идентифицировать ее. Кроме того, сборка должна находиться в GAC или, что менее характерно, в подкаталогах клиентского приложения. Чтобы клиент COM нашел .NET объект, нужно не забыть создать в реестре записи для COM. Это позволяет сделать утилита RegAsm.exe из .NET SDK. Вместо послесловияСледует заметить, что такое количество новшеств не могло не изменить реализацию очень многих программных продуктов Microsoft, и это действительно так. Конечно, включена поддержка .NET приложений в саму Windows, существенные изменения претерпел Visual Studio. Появилась новая среда выполнения - .NET Framework, которая ставится поверх операционной системы, специально чтобы обеспечить выполнение программ на MSIL, также подвергся изменению Internet Information Server (IIS), вернее, часть его, поддерживающая обслуживание страниц на фирменном языке Microsoft - ASP. Все эти изменения не могли не отразиться на идеологии разработки ПО, его внедрения и администрирования. Для того чтобы IT-специалисты попривыкли к .NET,
понадобится какое-то время, что же касается обычных пользователей
(тех, которые самостоятельно не администрируют свои ПК), то их
произведенные изменения почти не
затронут.
|
Copyright © <LMTH>. Все материалы являются собственностью их авторов.
При перепечатывании ссылка на http://www.magaz.org/ как на источник информации обязательна. Правила использования материалов журнала |