Позиционирование платформы .Net смещается в сторону Web-служб
Дэвид Тредвелл: «Работая над проектом Whidbey, мы имеем возможность реализовать все то, на что раньше не хватало времени»

Какое будущее ждет архитектуру .Net и как оно согласуется с проектом по разработке операционной системы под кодовым названием Longhorn? Эти вопросы сейчас занимают многих. Возможно, с перспективами .Net и Longhorn нам поможет разобраться Дэвид Тредвелл, генеральный менеджер подразделения Microsoft .Net Platform Developer Division, который ответил на несколько вопросов Джона Уделла, редактора еженедельника InfoWorld.

Когда произошло переименование Windows .Net Server в Windows Server 2003, возник естественный вопрос о том, в какой степени Microsoft связывает свое будущее с .Net как с платформой.

Мы понимали, что и .Net, и Windows — по сути платформенные решения, и при выборе названия для Windows-сервера сознательно остановились на том, чтобы в нем присутствовало только слово Windows. Архитектура WinFX (она в сущности является набором технологий Longhorn), представляет собой некую надстройку над .Net. Но и ее мы теперь рассматриваем как часть Windows. Что же касается .Net, то позиционирование этой платформы мы сейчас смещаем больше в сторону Web-служб, не выделяя ее как полномасштабное и всеобъемлющее решение.

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

Эта работа займет несколько лет. Вспомните, ведь переход от Win16 к Win32 тоже длился довольно долго. Разрабатывая .Net Framework 1.0, а затем и 1.1, мы затратили много усилий на создание интерфейсов. Однако при этом мы упустили несколько важных моментов. К примеру, мы решили вообще не создавать классы последовательного ввода/вывода, и это было только одной из ошибок.

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

Почему технология No-Touch Deployment не оправдала возлагавшиеся на нее надежды? Каким образом ClickOnce сможет исправить ситуацию?

Технология No-Touch Deployment была слишком сырой. В ней отсутствовала, к примеру, инфраструктура автоматического обновления. Все хотят иметь возможность установки программ с минимальными усилиями и без изменения конфигурации машины. А уже имея некий набор установленных программ, пользователи, естественно, хотят проверять наличие обновлений и «освежать» свои приложения в автоматическом режиме. Однако соответствующей инфраструктуры для этого сформировано не было. Технология ClickOnce, которую мы разрабатываем параллельно проекту Whidbey, в этом смысле должна оказаться лучше.

Какие практические преимущества дает сегодня использование архитектуры информационной безопасности платформы .Net?

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

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