RSS

Компьютерная терминология    1_9  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  .....  A  Б  В  Г  Д  Ж  З  И  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч

.NET

.NET (произносится «дот нэт») - новая технология Microsoft, анонсированная сравнительно недавно. Что же кроется под этим модным сейчас логотипом? Действительно ли .NET является чем-то принципиально новым, или это очередной рекламный ход Microsoft?

Веб-сервисы

Технология .NET позволяет создавать и выполнять приложения любого типа. Но в центре внимания, прежде всего, веб-сервисы (web-services, веб-службы).

Microsoft считает, что в будущем повсеместно будет реализован принцип "программное обеспечение как сервис". Например, если вам понадобится создать электронную таблицу, то не придется покупать Excel (или другую аналогичную программу), вы сможете воспользоваться веб-сервисом, предоставляющим такую возможность, заплатив только за время его использования или за использованные функции.

Сохранить документ можно будет на сервере с помощью другого сервиса. Еще один сервис, такой, как Microsoft Passport, позаботится, чтобы в дальнейшем доступ к сохраненному документу имели вы и только вы.

Можно вообразить мир будущего, в котором простые карманные устройства, имеющие доступ в интернет, с помощью веб-сервисов будут предоставлять не меньше, а то и больше возможностей, чем нынешние персональные компьютеры.

Ведь если веб-сервисы будут достаточно распространены, то это откроет множество недоступных сейчас возможностей. Пример, который уже стал классическим, - поиск в незнакомом городе ближайшего ресторана или ближайшей автомастерской.

Веб-сервисы предоставляют доступ к приложениям, основываясь на единых стандартах, независимых от платформы. Напрямую веб-сервисы не используются, они лишь предоставляют определенные функции, им нужны приложения-клиенты. Клиентами могут быть пользовательские приложения, реализующие, в основном, интерфейс с пользователем, либо другие веб-сервисы.

 

Бесплатная консультация специалиста

Loading…
 
Представьте, что интернет вдруг стал огромным набором готовых к использованию программистами библиотек функций, и вы увидите будущее таким, каким его видит Microsoft.

Веб-сервисы можно было создавать и до .NET, но тогда мало кто за это брался. Одобрительные отзывы о веб-сервисах в .NET связаны с особенностями этой платформы, которые предоставили, прежде всего, легкость их создания и распространения. Создавать веб-сервисы в .NET очень легко, а еще легче устанавливать. Обычное копирование нескольких файлов, и все готово.

Такой процесс еще называют XCOPY - по названию одной из команд DOS. Благодаря легкости установки, можно ожидать распространения веб-сервисов как готовых к использованию компонентов, из-за чего все больше организаций будут их использовать и предоставлять.

Потенциал веб-сервисов огромен, и его не стоит недооценивать. Однако приложения .NET - это не только веб-сервисы, потому .NET уже сейчас можно использовать для более приземленных целей - например, изготавливать приложения с оконным интерфейсом или интернет-приложения.

.NET Framework

Для того, чтобы иметь возможность выполнять приложения .NET на конкретном устройстве, нужно установить .NET Framework.В будущих версиях Windows делать это будет уже не нужно, так как .NET Framework будет в их составе. Составляющими .NET Framework являются среда выполнения Common Language Runtime (CLR) и набор общих модулей, который называется Framework Class Library (FCL).

Мы добрались до очень важной и непростой части повествования о .NET. Любые .NET-приложения используют единую среду выполнения CLR и используют единую библиотеку FCL. К тому же, они компилируются не в машинный код, а в промежуточный язык Interme-diate Language.

Увидев Common Language Runtime и Intermediate Language, знатоки Java найдут аналогию с его виртуальной машиной и байт-кодом. И будут во многом правы. CLR вместе с промежуточным языком позволяет достигнуть нескольких основных целей. Во-первых, переносимость. Для поддержки существующими .NET-приложениями нового устройства или другой операционной системы обычно нужно изменить только некоторые части CLR.

Эти изменения будет производить сама Microsoft. Во-вторых, контроль над выполняемым кодом. Будь то опасные действия или просто конфликт версий, CLR позволяет избежать неприятного развития событий. Широко известно, что в .NET невозможно создать известный всем DLL Hell - явление, когда существующую общую библиотеку заменяют другой версией, и приложения, ее использующие, перестают правильно выполняться. В-третьих, контроль за памятью. Утечки памяти в .NET практически невозможны, сборщик мусора Garbage Collector сам собирает ненужные переменные, программисты избавлены от необходимости явно освобождать память.

Framework Class Library, с точки зрения пользователя, всего лишь набор файлов DLL. А для программиста FCL предоставляет огромное количество готовых к использованию классов. Что это дает пользователям? Да хотя бы то, что программы с использованием готовых библиотек будут функционально богаче, надежнее и иметь небольшой размер.

Приложения .NET: от и до

Давайте проследим путь приложения .NET от написания до выполнения. Единой средой разработки приложений для .NET является Visual Studio .NET. Но использовать ее необязательно, если программиста устроят консольные утилиты из бесплатного .NET Framework SDK. Язык программирования для написания .NET-программ не имеет значения.

Это очень важно! Программисты, подумайте только, для программирования любых приложений (от консольного до интернет-приложения) можно использовать любимый язык программирования, без проблем можно взаимодействовать с кодом, написанном на другом языке, и абсолютно на любом из поддерживаемых языков пользоваться единой Framework Class Library. Одинаковые возможности для всех языков программирования!

Такие преимущества достигаются единым подходом ко всем поддерживаемым языкам программирования. Это Common Language Specification и, прежде всего, Common Type System. Языки программирования адаптируются для соответствия спецификации, иногда разница с оригиналом очень существенна, попробуйте сравнить, например, VB и VB.NET.

Для .NET Microsoft поставляет компиляторы языка C# ("си-шарп"), VB.NET, J# и управляемого C++.

Как уже было сказано мной выше, приложения .NET компилируются в промежуточный язык Intermediate Language. Этот язык представляет собой инструкции некоего несуществующего процессора. После компиляции файлы имеют расширения EXE, DLL, NETMODULE. Они хранятся в формате Portable Executable (PE).

Самое интересное с приложением .NET происходит после запуска. Из формата PE Windows определяет приложение .NET, и в дело вступает CLR. Важный момент, который необходимо понять, - приложения .NET не интерпретируются! Ошибкой было бы так думать, хотя в некоторых статьях и даже книгах вы можете такую ошибку найти.

Интерпретация предполагает пошаговое выполнение инструкций, без предварительного их перемалывания в код, приемлемый для процессора и операционной системы, как это делается при компиляции. В .NET промежуточный язык не интерпретируется, а компилируется в код по мере необходимости, так что неиспользуемые функции при этом не будут даже скомпилированы. Процесс компиляции по мере необходимости называют компиляцией Just-in-time (JIT). Вместо этого приложение также может быть полностью скомпилировано при инсталляции, этот процесс называют preJIT.

Во время работы приложение не освобождает память самостоятельно. Этим занимается сборщик мусора Garbage Collector. А если запущены несколько копий одного и того же приложения, то CLR эффективно распределяет их общие части, значительно уменьшая занимаемую память.

Приложения .NET не используют реестр. Настройки приложения хранятся в файле формата XML с расширением CONFIG. Совершенно не нужен реестр и компонентам приложений - внутри они полностью содержат всю необходимую для их использования информацию. Так как реестр не используется, установка приложений .NET обычно происходит по принципу XCOPY.

Код, который воспринимается CLR, называется управляемым (managed). Остальной код, не написанный с учетом требований .NET, называется неуправляемым (unmanaged) или родным (native). Разработчики новой технологии понимали, что неуправляемый код будет существовать еще долго, потому добавили в .NET возможности по взаимодействию с ним. Программа для .NET даже может представлять собой смесь компонентов из управляемого и неуправляемого кода. Однако такой вариант, естественно, не рекомендуется - программа теряет переносимость и множество других преимуществ.

Все, сказанное выше, относится к любому виду приложений. В частности, и к интернет-приложениям. Теперь они не интерпретируются, что означает высокую скорость их выполнения. Для таких приложений теперь не нужны урезанные скриптовые языки, такие как VBScript, их пишут на полноценных языках программирования.

Так как интернет-приложения могут запускаться тысячами копий одновременно, то благодаря названной уже возможности распределения памяти, для их работы потребуется значительно меньше памяти, чем раньше, а другие особенности CLR гарантируют еще большую производительность.

А еще интернет-приложения, использующие новую платформу, могут определять возможности браузера пользователя и подавать соответствующую этим возможностям версию страницы автоматически.

Особенно платформа .NET понравится программистам. Я уже говорил о некоторых преимуществах для них, теперь добавлю еще немного. Интернет-приложения (ASP.NET) строятся на событиях, код можно отделить от представления в отдельные файлы.

Все виды приложений могут использовать единую технологию доступа к базам данных ADO.NET, которая обладает значительными преимуществами, по сравнению со своей предшественницей ADO.

Программисты, использовавшие хоть раз COM, найдут аналогичные возможности в .NET очень простыми. Ну и, конечно, не может не понравиться Visual Studio .NET, которая является единым средством разработки всех видов приложений для всех языков.

.NET сегодня

.NET была анонсирована в июле 2000 года, релиз представлен в январе 2002.На сегодняшний день .NET еще не очень распространена, хотя эту платформу сейчас все больше используют для интернет приложений ASP.NET.В этом секторе велика конкуренция со стороны бесплатных и open-source-решений.Подает надежды проект Mono, разработчики которого создают альтернативу .NET с открытыми исходниками.Сама Microsoft пока не торопится делать Linux-версию .NET, хотя некоторые сдвиги в этом вопросе есть.Радуют факты, что Microsoft хоть и не открывает код, но все же строила .NET на открытых стандартах (XML, HTTP, SOAP), не делала секретов из форматов файлов, тщательно описала внутреннюю структуру .NET Framework, а также выдвинула части новой платформы для стандартизации в международные комитеты.Вспомним также, что .NET Framework и набор средств разработки .NET Framework SDK распространяются бесплатно.Также бесплатно распространяется прекрасный инструмент разработки ASP.NET Web Matrix, который, ко всему прочему, представляет собой пример полноценного .NET-приложения.Повсеместного использования приложений .NET можно ожидать при всеобщем переходе на будущие версии операционной системы Windows, начиная с системы Longhorn, ведь они будут содержать .NET Frame-work в своем составе.

Состав .NET

Обычно под .NET подразумевают .NET Framework, вольно используя их как синонимы.Однако Microsoft рассматривает .NET как платформу, состоящую из 4 групп программных продуктов.В первую группу входят средства разработки и языки программирования, а также собственно .NET Framework, то есть среда выполнения Common Language Runtime и библиотека классов Frame-work Class Library.Ко второй относят семейство серверов для особой функциональности, например, серверы работы с базами данных.Третья - набор веб-сервисов, среди которых Microsoft Passport. Четвертая - .NET-устройства, например, мобильные телефоны.Важным понятием в новой технологии является понятие сборки (assembly). Это модуль, имеющий версию и некоторые другие свойства. Обычно сборка - это просто файл EXE или DLL.Трудность понимания этого термина в том, что сборка может состоять из нескольких файлов, потому принято представлять сборку как "логический DLL".Например, сборка может состоять из нескольких файлов NETMODULE, содержащих доступные программисту функции, а также туда могут быть включены ресурсы, например, файлы BMP.Те атрибуты, которые скрепляют сборку в логический DLL (версия, имя сборки, список файлов), содержатся в манифесте.Манифест может быть отдельным файлом или содержаться внутри файлов DLL или EXE.Наличие манифеста - одна из причин, по которой приложения .NET не требуют использования реестра.

Что .NET грядущий нам готовит?

10.03.2003

Итак, .NET — это новая технология, в которой условно можно выделить web-сервисы XML и новую платформу разработки .NET Framework.

Сначала поговорим про web-сервисы XML. Программисты, пишущие программы для платформы Windows, должны быть знакомы с давно существующей технологией COM (Component Object Model). Это технология все той же Microsoft, которая позволяет приложениям, написанным на разных языках, взаимодействовать друг с другом. В итоге вы имеете две программы: COM-сервер и COM-клиент, где клиент может вызывать какие-либо функции сервера. И сервер, и клиент должны находиться на одном и том же компьютере.

Чуть позже COM была доработана до технологии DCOM (Distributed COM), которая позволяла COM-серверу и COM-клиенту взаимодействовать друг с другом уже по сети. И вот пришел черед web-сервисов XML. Идея web-сервисов XML заключается в следующем. Предположим, где-то в сети существуют серверы, предоставляющие какие-либо сервисы (услуги), доступные для использования клиентскими компьютерами. Под сервисом подразумевается набор функций. Такими функциями могут быть, например, «Узнать текущий курс доллара» или «Заказать горячий борщ в офис». Т.е. технология web-сервисов чем-то сродни DCOM, только она уже не ограничена рамками локальной сети, а расширена до масштабов сети Интернет. Пример применения web-сервисов XML приведен ниже.

Обращение к web-сервису XML происходит следующим образом. Клиентская машина (относительно сервера) формирует специально сформатированный, содержащий параметры XML-запрос и посылает его серверу. Запрос посылается через Internet/Intranet, при этом используется, как правило, HTTP-протокол. Сервер обрабатывает XML-данные и возвращает клиенту ответ в виде того же XML. Такой обмен данными между клиентом и сервером в формате XML определяется протоколом SOAP (Simple Object Access Protocol).

Идея web-сервисов назревала давно. Причиной тому было все большее внедрение Интернета в нашу повседневную жизнь. В Microsoft считают, что будущее за продажей web-сервисов. Насколько это верно, покажет время. Подразумевается, что любая компания может написать web-сервис XML, а затем предоставлять его бесплатно или взимать за использование своего сервиса плату.

На данный момент уже существует несколько работающих web-сервисов XML, предоставленных самой Microsoft. Эти web-сервисы (.NET Calendar, .NET Documents, .NET Profile и др.) называются .NET My Services и ориентированы на конечного пользователя. Часть этих сервисов бесплатна.

Еще одной инициативой Microsoft была новая платформа .Net Framework. С ее помощью Microsoft попыталась убить сразу двух зайцев. Во-первых, преодолеть границы операционных систем, чтобы одна и та же программа могла выполняться на нескольких операционных системах сразу. А во-вторых, уменьшить количество ошибок в разрабатываемом программном обеспечении (ПО).

Раньше (до появления .NET Framework) процесс создания программы сводился к написанию исходного кода и его последующего компилирования. При компиляции исходный код программы преобразовывался в инструкции (команды) для конкретного процессора и конкретной операционной системы (ОС). Т.е. для другой ОС надо было перекомпилировать исходный код заново. А если компилятор не мог компилировать код для какой-либо ОС, то тут уже мало что помогало.

В середине 90-х годов компания Sun Microsystems предложила новую идеологию, воплотив ее в свой язык программирования Java. Предполагалось, что программа будет выполняться внутри виртуальной Java-машины. Т.е. стоит на любой ОС установить Java-машину, чтобы стало возможным выполнение Java-программ. Наверное, любой программист помнит лозунг: «Написанное однажды исполняется везде». Но Microsoft не была бы сама собой, если бы без боя отдала такое приоритетное направление своим конкурентам. Результатом стала платформа .Net Framework.

В основу этой платформы была положена концепция управляемого кода. Программа выполняется в т.н. общеязыковой выполняющей среде CLR (Common Language Runtime). Сама программа теперь представляет собой не инструкции для процессора, а содержит код на промежуточном языке IL (Intermediate Language). Т.е. результатом компиляции теперь являются не команды процессора, а IL-код. При запуске программы в среде CLR специальный компилятор компилирует этот IL-код в команды конкретного процессора. Этот компилятор называется компилятор времени исполнения, или JIT-компилятор (Just In Time).

Получается, что программа, скомпилированная любым компилятором, который способен создавать промежуточный IL-код, будет выполняться на любой ОС, где установлена среда CLR. Звучит восхитительно! Но у каждой медали есть две стороны. Сначала о минусах.

Для выполнения программы, содержащей IL-код, необходима общеязыковая выполняющая среда CLR. Эта среда пока не встроена ни в одну настольную ОС — ее нужно доустанавливать. Если вы работаете в Windows, то необходимо установить .NET Framework, в которую входит среда CLR. .NET Framework бесплатна и доступна для скачивания на сайтах Microsoft. Также существует проект поддержки среды CLR для операционных систем *NIX.

Последняя из версий Windows — Windows XP, немного адаптирована для выполнения программ, содержащих промежуточный IL-код, но все равно требуется установка .NET Framework. Правда, Microsoft уже объявила, что следующая пользовательская версия Windows уже будет содержать в себе общеязыковую выполняющую среду CLR.

Как было сказано выше, при выполнении IL-программа сначала компилируется «на лету» JIT-компилятором, а уже потом выполняется. Очевидно, что эта самая компиляция «на лету» занимает какое-то время. «На глаз» задержка компиляции заметна только при старте программы, т.к. основная JIT-компиляция происходит при старте программы, а потом выполняется уже откомпилированный код.

По сути дела, для конечного пользователя платформа .NET Framework абсолютно прозрачна, т.е. каких-либо визуальных изменений, как это было при переходе с MS-DOS на Windows 3.11, а потом на Windows 95, пользователь не увидит. Основные изменения коснутся программистов. Программирование Windows-программ уже не основано на WinAPI, как раньше. Это и логично, ведь программы должны выполняться под любой ОС, содержащей CLR, а не только под Windows. Теперь программирование строится на основе библиотеки классов, входящей в .NET Framework — FCL (Framework Class Library). Т.е. программистам придется изучать FCL-классы. Классов FCL очень много, но при этом они пока не полностью покрывают функциональность WinAPI. Ввиду этого предусмотрена возможность вызова WinAPI-функций напрямую. Но и тут Microsoft обещает в следующих версиях .NET Framework заменить всю функциональность WinAPI соответствующими FCL-классами.

Про минусы поговорили — их пока хватает. Но зато сколько новая платформа .NET Framework дает плюсов!

Появились понятия «управляемый»/«неуправляемый» и «безопасный»/«небезопасный» код. За выполнение программы теперь отвечает среда CLR. Т.е. программа выполняется как бы в песочнице. Программа, написанная только с использованием FCL-типов, содержит «управляемый» и «безопасный» код. Программы старого вида, представляющие собой команды процессора, называются «неуправляемым» кодом.

При выполнении программы в среде CLR происходит проверка ее исходного кода на «безопасность». Иначе говоря, проверяется безопасность типов и предотвращается любая попытка некорректного обращения к типам. Например, при вызове метода какого-либо типа проверяется корректность передаваемых ему параметров. Такая проверка уменьшает количество возможных ошибок в коде программы. Также «безопасный» код не может содержать нетипизированные указатели. Применение таких указателей часто приводило к возникновению ошибок, и от них решили отказаться в пользу устойчивости работы программ. При желании, конечно, программа может содержать нетипизированный указатель, но тогда она не будет считаться «безопасной».

В свое время модель COM позволила программам, написанным на разных языках программирования, взаимодействовать друг с другом. Платформа .NET Framework позволяет разным языкам программирования интегрироваться — например, одному языку использовать типы, созданные на других языках. Можно создать C#-класс, производный от класса, написанного на C++. Чтобы создать тип, доступный из других языков, придется задействовать лишь те возможности языка, которые гарантированно доступны и в других языках. Для такой совместимости языков Microsoft определила общеязыковую спецификацию CLS (Common Language Specification). Данная спецификация описывает минимальный набор возможностей, который должен быть реализован производителями компиляторов, чтобы их продукты работали в CLR. Говоря простым языком, CLS — это минимальный набор функций, который должен поддерживать язык.

Из языков программирования, с помощью которых можно создавать программы для .NET Framework, могу назвать C#, Visual Basic .NET, Visual C++ с управляемыми расширениями. Причем, Microsoft C++ сам по себе является уникальным компилятором, позволяющем создавать как обычные программы с неуправляемым кодом, так и программы для .NET Framework. В качестве основного языка для платформы .NET Framework Microsoft выбрала C# (произносится как «си шарп»). Именно в этот язык Microsoft вложила «душу» своей новой технологии .NET Framework. Это новый абсолютно объектно-ориентированный язык программирования, который вобрал в себя все лучшие качества современных языков. Эдакий конгломерат Java, Delphi и C++. Также должен сказать, что главный конкурент Microsoft по компиляторам, фирма Borland, тоже не топчется на месте, а выпустила компилятор Delphi for .NET Preview, который позволяет создавать программу, содержащую IL-код.

Наверняка многие из вас сталкивались с ситуацией, когда после инсталляции какой-либо программы другие программы переставали запускаться. Это происходит из-за того, что все системные библиотеки (DLL) в Windows хранятся в одном месте. И любая программа при инсталляции может затереть жизненно-важную библиотеку другой версией. Это явление у программистов получило название «ад DLL». В .NET Framework подобных ситуаций происходить не будет. Записать системную библиотеку поверх другой версии этой же библиотеки просто невозможно. Теперь появилось понятие «контроль версий».

Без преувеличения можно сказать, что появление платформы .NET является историческим событием, причем не менее важным, чем, скажем, появление Windows 95.

Изучать новую платформу .NET Framework — это дело, конечно, ваше. Но, зная целеустремленность Microsoft, можно ожидать, что она не зря тратит сейчас миллионы на раскрутку своей новой технологии. И что спустя какое-то время при написании программ будет использоваться только FCL, а WinAPI попадет в историю и займет место рядом с прерываниями MS-DOS. И, наверное, правильней поставить вопрос не «изучать или не изучать?», а «когда начать изучать?».

И напоследок, чтобы не быть голословным, приведу пример кода на C#. Если Вы программист, то Вам наверняка не терпится посмотреть какой-нибудь простенький пример для платформы .NET Framework. По традиции приведу пример консольного приложения, написанного на C# и выводящего банальную строку «Hello World»:

Для программиста, который уже имел дело с другими языками, нет ничего сложного в понимании вышеприведенного кода. Тут все прозрачно и просто. Если у вас установлена .NET Framework, то можно откомпилировать вышеприведенный пример, т.к. в инсталляцию .NET Framework входит компилятор для C# — csc.exe. Сохраните пример в файле HelloWorld.cs и откомпилируйте его:

Результатом будет работоспособная программа .NET Framework. Можно смело запускать ее. Забегая вперед, скажу, что в МК планируется цикл статей по C#.

Проблемы, стоящие перед программистами, не использующими .NET

17.06.2003

Совсем-совсем давно (по меркам развития компьютерных технологий, а на самом деле всего-то 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, понадобится какое-то время, что же касается обычных пользователей (тех, которые самостоятельно не администрируют свои ПК), то их произведенные изменения почти не затронут.

seo & website usability inet os faq hardware faq memory video cpu hdd mainboard faq printer & scaner modem mobiles hackzone

Технологии поискового маркетинга
Практика поискового маркетинга
Flash
Тэги
XML
DHTML
PHP
MySQL
WebMail
.NET
VBScript
CGI
Графические форматы Интернета
WEB-сайт шаг за шагом
CMS faq
FRAME faq
CSS faq
SSI faq
RSS faq
WAP faq
Web-Designed
Webhints
Файл настроек .htaccess
Настройка robots.txt
Windows 10 | Registry Windows 10 | Windows7: Общие настройки | Windows7: Реестр | Windows7: Реестр faq | Windows7: Настроки сети | Windows7: Безопасность | Windows7: Брандмауэр | Windows7: Режим совместимости | Windows7: Пароль администратора |  часы luminox по минимальным ценам  |  |  |  | Память | SDRAM | DDR2 | DDR3 | Quad Band Memory (QBM) | SRAM | FeRAM | Словарь терминов | Video | nVIDIA faq | ATI faq  | Интегрированное видео faq | TV tuners faq | Терминология | Форматы графических файлов | Работа с цифровым видео(faq) | Кодеки faq | DVD faq | DigitalVideo faq | Video faq (Архив) | CPU | HDD & Flash faq | Как уберечь винчестер | HDD faq | Cable faq | SCSI адаптеры & faq | SSD | Mainboard faq | Printer & Scaner | Горячая линия бесплатной юридической консультации | Благотворительность

На главную | Cookie policy | Sitemap

 ©  2004