Читать онлайн «Программирование мобильных устройств на платформе .NET Compact Framework». Страница 22

Элементы, отсутствующие в первой версии .NET Compact Framework 

Концепция явной проверки полномочий являлась центральной при проектировании общеязыковой среды выполнения (Common Language Runtime), лежащей в основе как .NET Framework, так и NET Compact Framework. Другим распространенным на званием этой концепции является безопасность доступа кода. 

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

■ Полные доверительные отношения. Код выполняется в системе на уровне полных доверительных отношений и может делать все то, что могло бы делать собственное приложение. 

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

■ Ограниченный доступ к пользовательскому интерфейсу. Возможность вызова пользовательских интерфейсов может быть разрешена или запрещена компонентам. 

■ Сетевой доступ. Возможность доступа к сети может быть разрешена или запрещена компонентам. 

■ Доступ к собственному коду. Возможность осуществления вызовов собственных кодов может быть разрешена или запрещена компонентам.

В варианте .NET Framework, ориентированном на настольные компьютеры и серверы, доступны не только эти, но и многие другие разрешения, которые могут определяться в качестве политик. По данному вопросу имеется обширная литература и документация.

.NET Compact Framework проектировалась с учетом поддержки описанной модели безопасности, основанной на политиках. Однако в первом выпуске .NET Compact Framework политика безопасности определялась очень просто: "Весь код пользуется полными доверительными отношениями". Это означает, что приложения, предназначенные для .NET Compact Framework v1.1, выполняющейся на устройстве, будут выполняться в этой среде с тем же набором разрешений, с которым на устройстве выполняются собственные коды.

Решение о закреплении разрешенных полномочий на уровне "выполнения в условиях полных доверительных отношений" для первого выпуска .NET Compact Framework было продиктовано исключительно прагматическими соображениями. В ходе обсуждений, сопровождавших ранние опыты внедрения данного продукта, стало очевидным, что первая волна конкурентоспособных приложений для мобильных устройств будет, скорее всего, представлена приложениями, которые явным образом устанавливаются на устройствах пользователями или администраторами, а не загружаются и выполняются на лету. Подобные виды приложений начали уже в заметной степени вытеснять традиционные приложения для устройств на основе собственных кодов, и поэтому использование аналогичной модели полномочий вполне соответствовало сложившейся ситуации. Если бы мы располагали неограниченным временем для проектирования, построения, тестирования и окончательного уточнения политик безопасности на основании откликов пользователей, то модель, используемая в первой версии, была бы проработана более тщательно. Однако в результате многочисленных дискуссий мы поняли, что не это требование будет определять успешность выполнения приложений в нашей первой версии продукта. В силу этого создание более совершенного механизма политик безопасности было отложено до следующего выпуска, что дало возможность сконцентрировать усилия на разработке других средств, вошедших в первую версию. Это решение далось нелегко, однако, по прошествии уже достаточно большого времени, мы по-прежнему убеждены в его правильности. Следует отметить, что на некоторых из устройств, пользующихся массовым спросом, например, на некоторых смартфонах, эксплуатируются политики безопасности, требующие, чтобы приложения, основанные на собственных кодах, были снабжены криптографическими подписями; в случае таких устройств в отношении приложений, основанных на управляемом коде, действуют те же политики.

В дальнейшем желательно внедрить модель безопасности, поддерживающую загрузку кода на лету и присвоение полномочий на основе подтверждений, предоставляемых кодом. Поэтому весьма вероятно, что в будущих версиях .NET Compact Framework будет предусмотрено несколько различных уровней доверительности и полномочий, охватывающих интервал от "полного доверия" на основе предоставляемых подтверждений до весьма ограниченных возможностей для кода, пользующегося низким уровнем доверительности. Кроме того, различные типы мобильных устройств будут, вероятно, характеризоваться заданием на них различных политик. На некоторых устройствах политики будут определяться конечными пользователями, на других — администраторами, изготовителями оборудования или же сетевыми операторами, обслуживающими то или иное устройство. Поддержка этих возможностей будет осуществляться встроенной моделью обеспечения безопасности доступа.

Еще одной областью, от явной поддержки которой в первом выпуске .NET Compact Framework мы решили отказаться, является работа с мультимедийной информацией. Это, например, означает, что разработчики, желающие воспроизводить звуки или показывать видео, должны использовать для этой цели собственные коды. Как и в предыдущем случае, если бы для разработки, тестирования и доработки этих средств у нас было больше времени, то их поддержка была бы обеспечена уже в первом выпуске .NET Compact Framework. Анализ отзывов, полученных нами от лиц, проводивших первые испытания этого продукта, позволил сделать вывод, что применительно к тем видам приложений, в создании которых в настоящее время существует потребность, поддержка данных возможностей не являлась критическим фактором успешности. По всей вероятности, в будущих версиях .NET Compact Framework поддержка мультимедийной информации будут более интенсивной.

Оглядываясь назад, мы можем констатировать, что принятое нами решение было правильным.

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

1. Загружается управляемое приложение. Двоичный заголовок приложения указывает операционной системе на то, что оно не является приложением в собственных кодах. Вместо того чтобы просто предоставить возможность выполняться инструкциям кода, загружается исполнительный механизм .NET Compact Framework, которому сообщается о том, что он должен запустить приложение на выполнение.

2. Исполнительный механизм находит класс, содержащий "главную" точку входа "main", с которой должно начинаться выполнение приложения. Таковым является класс с сигнатурой функции, соответствующей виду static void Main(). В случае обнаружения типа с такой сигнатурой происходит загрузка класса и производится попытка выполнения "главной" процедуры (шаги 3 и 4).

3. Загружается класс. Информация о классе загружается и верифицируется с той целью, чтобы убедиться в корректности и согласованности определения класса. Все методы (то есть точки входа исполняемого кода) класса обозначаются как "некомпилированные".

4. Исполнительный механизм пытается выполнить указанную процедуру. Если уже имеется откомпилированный код, связанный с процедурой, осуществляется выполнение этого кода.

5. Если исполнительный механизм обнаруживает, что свойство или метод, которые требуется запустить на выполнение, не откомпилированы, они компилируются по требованию. Производится загрузка содержащейся в классе информации, которая необходима методу. Код верифицируется для гарантии того, что он содержит безопасные, допустимые и корректно сформированные IL-инструкции, а затем подвергается JIT-компиляции. Если метод ссылается на другие типы, которые еще не были загружены, осуществляется необходимая загрузка определений соответствующих классов и типов. Методы, содержащиеся в классах, не компилируются до тех пор, пока в этом не возникнет необходимости; именно в этом и состоит смысл JIT-компиляции.