Asp microsoft windows distributed internet application architecture

Содержание

Установка и конфигурирование IIS

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

В этой и следующих статьях мы рассмотрим различные варианты развертывания. Однако во всех случаях основные предпосылки остаются неизменными. На рабочей станции имеется готовый веб-сайт, который нужно развернуть на сервере, чтобы он был доступен клиентам. Для ASP.NET таким сервером является , а его текущей версией — IIS 8. Когда он был впервые реализован, IIS представлял собой базовый веб-сервер. С годами IIS развился в сложный сервер приложений, предоставляющий широкое множество функциональных средств, наиболее важным из которых является поддержка хостинга приложений ASP.NET.

В этой статье основное внимание уделяется IIS 8. Хотя машина, на которой запущен IIS 8, здесь называется сервером, IIS можно запускать под управлением версий Windows как для рабочей станции, так и для сервера. На рабочих станциях доступны не все, но большинство функциональных возможностей, что позволяет размещать сложные веб-сайты. По возможности мы рекомендуем использовать Windows Server, однако недорогой альтернативой могут послужить Windows 7 или Windows 8.

В Microsoft привязывают выпуски IIS с выпусками Windows. В состав Windows Server 2008 и Windows Vista входит версия IIS 7.0, в состав Windows Server 2008 R2 и Windows 7 — версия IIS 7.5, а в состав Windows Server 2012 и Windows 8 — IIS 8. Версии — 7.0 и 7.5 — в Microsoft обобщенно называют IIS 7, что может вносить путаницу. Версию IIS, поддерживаемую операционной системой, изменить нельзя — Windows Server 2008 будет использовать только IIS 7.0. Например, модернизировать ее до версии IIS 7.5, используемой в Windows Server 2008 R2, не получится.

Установка IIS

Компонент IIS включен как часть установки Windows (как для сервера, так и для рабочих станций) и требует активизации и конфигурирования. Далее представлены три способа активации IIS для различных операционных систем.

Установка IIS на настольных версиях Windows (Windows Vista, Windows 7 и Windows 8)

Каждая версия операционной системы Windows предлагает свою версию IIS — IIS 8 (в Windows 8), IIS 7.5 (в Windows 7) или IIS 7 (в Windows Vista). Во всех этих версиях Windows, IIS включен, но изначально не установлен. Чтобы установить его, необходимо выполнить следующие действия:

Откройте панель управления.

Нажмите кнопку «Включение или отключение компонентов Windows». Теперь вам нужно подождать, пока Windows исследует вашу систему.

Найдите элемент Internet Information Services (Службы IIS) в верхней части списка и нажмите на галочку чтобы включить его:

Обратите внимание, что Windows позволяет включить множество компонентов IIS: поддержка FTP-сервера, дополнительные инструменты управления, службы обратной совместимости с IIS 6 и т.д.

Убедитесь, что вы выбрали поддержку ASP.NET. Для этого раскройте узел Службы Интернета Компоненты разработки приложений ASP.NET (Internet Information Services World Wide Web Services Application Development Features ASP.NET):

Если вы хотите использовать поддержку IIS в Visual Studio, которая позволяет вам создавать виртуальные каталоги IIS непосредственно в диалоговом окне New Web Site, вам нужно выбрать пункт «Совместимость управления IIS 6» в разделе «Средства управления веб-сайтом» (Web Management Tools IIS 6 Management Compatibility).

Как только вы выбрали нужные параметры IIS, нажмите кнопку OK для завершения установки.

Установка IIS в Windows Server 2008

Установка и настройка IIS одинакова для Windows Server 2008 и Windows Server 2008 R2. Необходимые шаги описаны ниже:

Запустите диспетчер сервера. Чтобы сделать это, нажмите кнопку Start и выберите All Programs Administrative Tools Server Manager.

Выберите узел Roles в дереве слева.

В правой части окна нажмите на ссылке Add Roles. Это открывает мастер, позволяющий добавить новую роль сервера.

Выполните необходимые действия в мастере. Вас вероятно попросят установить дополнительные необходимые роли — если это так, нужно просто принять операции и продолжить.

После установки вам будет предложено настроить веб-сервер. Как в настольных версиях Windows, вы можете выбрать специфические особенности IIS 7, которые должны быть включены.

Если вы работаете в ASP.NET с версией .NET Framework 4.5, то эту версию .NET Framework необходимо будет установить (центр разработчиков .NET Framework)

Установка IIS в Windows Server 2012

Процесс установки IIS в Windows Server 2012, по существу, такой же, как и в Windows Server 2008. Основное различие заключается в том, что пользовательский интерфейс несколько отличается. Подробное описание вы можете найти перейдя по ссылке Installing IIS 8 on Windows Server 2012.

Управление IIS

При установке IIS, он автоматически создает каталог с именем C:\inetpub\wwwroot, который представляет ваш веб-сайт. Все файлы в этом каталоге будет отображаться, как будто они находятся в корневом каталоге вашего веб-сервера.

Чтобы добавить дополнительные страницы на ваш веб-сервер, можно скопировать файлы HTML, ASP или ASP.NET напрямую в каталог C:\Inetpub\wwwroot. Например если добавить файл TestFile.html в этот каталог, вы можете запросить его в браузере через URL-адрес http://localhost/TestFile.html. Вы даже можете создавать вложенные папки для группирования связанных ресурсов. Например, вы можете получить доступ к C:\inetpub\wwwroot\MySite\MyFile.html через браузер, используя URL-адрес http://localhost/MySite/MyFile.html.

Каталог wwwroot удобен для запуска простых примеров и статичных страниц. Для правильного использования ASP.NET вы должны сделать свой собственный виртуальный каталог для каждого веб-приложения, которое вы создаете. Например, вы можете создать папку с любым именем на любом диске вашего компьютера и поместить ее в виртуальный каталог IIS как будто она расположена в каталоге C:\inetpub\wwwroot.

Прежде чем начать работу, вам нужно запустить диспетчер служб IIS. Его можно найти в меню Start (Пуск). Конкретное расположение может зависеть от используемой версии Windows (IIS Диспетчер служб IIS). Ярлык программы будет располагаться в разделе Programs (Программы) или Administrative Tools (Администрирование). Начальная страница IIS Manager показана на рисунке ниже:

Теперь нужно ознакомиться с рядом терминов, используемых в IIS. В левой части окна IIS Manager отображается запись с именем используемого сервера. Наш сервер имеет имя PROFESSORWEB, сгенерированное по умолчанию Windows 8, которое будет использоваться в большинстве примеров. В центральной области отображается представление сервера. Это представление отображает набор значков, которые позволяют конфигурировать параметры сервера. В правой части экрана расположен список доступных действий. Например, в этом представлении можно запускать, останавливать и перезапускать сервер.

Если развернуть элемент сервера в древовидном представлении в левой части экрана, отобразится элемент Sites (Сайты), содержащий единственную запись Default Web Site (Веб-сайт по умолчанию). Сайт — это коллекция файлов и каталогов, образующих веб-сайт. На одном сервере IIS может поддерживать несколько сайтов, как правило, на различных портах TCP/IP (по умолчанию используется порт 80). Сочетание имени сервера и порта сайта образует первую часть URL-адреса. Например, при использовании сервера mywebserver с сайтом, подключенным к порту 80, URL-адрес выглядит следующим образом:

Каждый сайт может содержать множество файлов и каталогов. Каждый из них образует часть URL-адреса. Так, URL-адрес статической страницы mypage.html, расположенной в каталоге myfiles, будет следующим:

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

Чтобы проверить работоспособность IIS выберите Default Web Site и в правой области диспетчера служб IIS выберите пункт «Запустить». После этого нажмите кнопку «Обзор *.80 (http)» чтобы открыть страницу сайта в браузере:

Как видите, в моем случае я поменял порт используемый по умолчанию (с 80 на 8080). Я сделал это, т.к. на 80-м у меня запущен локальный Apache-сервер. Если у вас возникает такая же проблема, то изменить порт можно щелкнув правой кнопкой мыши по сайту (Default Web Site) и выбрав в контекстном меню «Изменить привязки» (Bindings). После этого в диалоговом окне можно изменить порт, используемый по умолчанию.

Итак, каждый сервер может поддерживать множество сайтов, каждый из которых работает на другом порту или с другим IP-адресом. Каждый сайт может иметь множество файлов и каталогов, и сочетание этих элементов предоставляет информацию о URL-адресе. Мы вернемся к URL-адресам и использованию IIS Manager при рассмотрении каждого из подходов к развертыванию.

Asp microsoft windows distributed internet application architecture

Распределенная архитектура интернет-приложений

Компания Microsoft разработала технологию Windows Distributed interNet Application Architecture (Windows DNA, Распределенная архитектура интернет-приложений Windows), полностью интегрирующую многоуровневую модель разработки с веб-технологией. Технология Windows DNA определяет каркас для создания решений, которые удовлетворяют требованиям корпоративных вычислений, Интернета, интрасетей и глобальной электронной торговли, уменьшая при этом издержки на общую разработку и развертывание системы.
В архитектуре Windows DNA стандартные службы на базе Windows выполняют определенные задачи на каждом уровне в многоуровневом решении, обеспечивая интерфейс пользователя и навигацию, бизнес-логику и хранение данных. Различные службы интегрированы при помощи Common Object Model (COM, Общая объектная модель). Службы, используемые в Windows DNA, включают: Dynamic HTML (Динамический HTML), Active Server Pages (Активные серверные страницы, ASP), компоненты COM, Microsoft Transaction Server, службу Active Directory, службы безопасности Windows Server 2003, Microsoft Message Queue Services (MSMQ, Службы очереди сообщений) и компоненты доступа к данным Microsoft.
Архитектура Windows DNA создана с применением открытых протоколов и общедоступных интерфейсов, что облегчает организациям задачу интеграции новых систем с продуктами третьих фирм. Обеспечивая промышленные стандарты Интернета, Windows DNA упрощает работы по внедрению новых технологий для разработчиков. На рис. 16.2 представлена схема, которая иллюстрирует технологии — составные части Windows DNA.

Глава 22. Службы Интернета в Windows 2000

Internet Information Services (US) ≈ набор базовых служб Интернета, в состав которых входят: веб-сервер, FTP-сервер, SMTP-сервер, NNTP-сервер и ряд дополнительных служб. Службы IIS предоставляют множество новых возможностей, которые могут превратить систему Windows 2000 в мощную платформу для распределенных сетевых приложений. Службы IIS объединены при помощи стандартного интерфейса администрирования и общих методов управления.

В системе Windows 2000 аббревиатура «IIS» расшифровывается несколько иначе, чем в системах Windows NT, где она означала Internet Information Server. Теперь это Internet Information Services (Информационные службы Интернета). В первую очередь ≈ из-за того, что Интернет-службы стали стандартными компонентами операционной системы (хотя и не все службы обязательно инсталлировать), и их функциональные возможности были значительно расширены.

Службы Internet Information Services (IIS)

Службы Internet Information Services имеют ряд основных возможностей, которые кратко описаны ниже.

Службы IIS базируются на сетевых стандартах. В Microsoft Internet Information Services реализован стандарт протокола HTTP 1.1, включая возможность применения команд PUT и DELETE, настройки сообщений об ошибках HTTP и поддержку пользовательских заголовков HTTP. Также имеется поддержка заголовков, несущих информацию об узле, при помощи которой можно создать несколько веб-узлов на одном компьютере под управлением Windows 2000 с одним адресом IP. Это полезно для поставщиков услуг Интернета и для реализации узлов корпоративных интрасетей.

Динамическое содержание. В IIS можно создавать сценарии, выполняющиеся на стороне сервера, и использовать компоненты для создания динамического содержания, независимого от браузера. Активные серверные страницы ASP обеспечивают удобную для применения альтернативу CGI и ISAPI, позволяя разработчикам информационного содержимого узлов применять в страницах HTML любые языки сценариев ActiveX или серверные компоненты. ASP обеспечивает доступ ко всем потокам запросов и ответов HTTP, поддерживает стандартные методы доступа к базам данных и возможность настройки содержания для различных браузеров.

Централизованное администрирование. Службы IIS управляются с пбмощью консоли управления Microsoft (MMC). Управление службами возможно при помощи оснастки ММС, запущенной на компьютере с Windows 2000 (рис. 22.1).

Безопасность. Secure Sockets Layer (SSL, Уровень защищенных сокетов) версии 3.0 обеспечивает безопасный способ обмена информацией между клиентом и сервером. В дополнение к механизмам шифрования предыдущих реализаций SSL, SSL 3.0 обеспечивает способ аутентификации клиента без необходимости его регистрации (login) на сервере US.

Рис 22.1. Оснастка Internet Information Services

Рис 22.2. Управление с помощью браузера ≈ окно Internet Service Manager

В IIS клиентские сертификаты распространяются и на приложения ISAPI, и на страницы ASP таким образом, чтобы программисты могли отслеживать работу пользователей на узлах. В свою очередь, IIS может »отображать» клиентский сертификат на учетную запись пользователя Windows 2000 так, чтобы администратор мог управлять доступом к ресурсам системы, основываясь на клиентском сертификате.

Дополнительные средства администрирования. IIS содержат основанные на веб-интерфейсе инструменты администрирования, которые позволяют удаленно управлять сервером с помощью веб-браузера на различных платформах (рис. 22.2). В Windows 2000 пользовательским учетным записям можно давать ограниченные привилегии администрирования веб-узла, что помогает распределить административные задачи.

У веб-сервера, входящего в число служб IIS в Windows 2000, появилось много новых возможностей по сравнению с предыдущими версиями (Internet Information Server 4.0, входившим в состав Option Pack для Windows NT 4.0 и более ранними версиями IIS, поставлявшимися отдельно). Основные функциональные возможности, которые появились или были усовершенствованы в этой версии веб-сервера:

Публикация информации на сервере стала проще

Сжатие HTTP. Обеспечивает более компактную передачу страниц между веб-серверами и клиентами, которые поддерживают получение сжатой информации. Сжимает и кэширует статические файлы, и выполняет по требованию сжатие динамически сгенерированных файлов.

Распределенная поддержка авторских версий (Distributed Authoring and Versioning, DAV). Дает возможность авторам веб-страниц удаленно редактировать, перемещать или удалять файлы, изменять параметры файлов, каталоги и параметры каталогов на сервере при помощи административных утилит, работающих по протоколу HTTP.

Новые возможности ASP. В механизмах Active Server Pages (ASP, Активные серверные страницы) расширены старые возможности и появились новые которые повышают производительность и улучшают выполнение сценариев на стороне сервера (см. ниже).

Докачка по протоколу FTP. Теперь при получении файла по протоколу FTP можно производить повторную докачку с места, на котором был прерван предыдущий сеанс.

Мастер создания веб-узлов (New Web Site) и Мастер создания виртуальных каталогов (New Virtual Directory). Эти мастеры можно вызвать из оснастки управления IIS, они облегчают создание новых веб-узлов и виртуальных каталогов на сервере.

Улучшенная безопасность

Новые механизмы аутентификации. Предоставляют возможности по надежной аутентификации пользователей, подключенных через серверы-посредники (proxy) и брандмауэры (firewall).

Новые мастера безопасности, которые упрощают задачи администрирования сервера: ,.

  • Мастер сертификатов (Certificate Wizard). Упрощает задачи администрирования сертификатов ≈ создание запросов на получение сертификатов и управление циклом жизни сертификата.
  • Мастер разрешений (Permissions wizard). Позволяет облегчить редактирование и конфигурирование доступа к веб-узлу ≈ обеспечивает назначение политик доступа к виртуальным каталогам и файлам. Мастер разрешений может также отображать политику доступа к веб-узлу при помощи файловых разрешений NTFS.
  • Мастер CTL (CTL Wizard). Можно использовать этот мастер для настройки списков доверия сертификатов (Certificate Trust List, CTL).

CTL ≈ список центров авторизации или поставщиков сертификатов (Certificate Authorities, СА), получивших доверие, для заданного каталога. CTL особенно полезен для поставщиков услуг Интернета (ISP), которые держат на своем сервере много веб-узлов клиентов и должны хранить различные утвержденные списки центров авторизации для каждого узла.

Стандарт безопасности Fortezza- В службах IIS поддерживается американский правительственный стандарт безопасности, обычно называемый Fortezza. Этот стандарт удовлетворяет архитектуре безопасности Defence Messaging System (Система передачи сообщений Министерства обороны), поддерживая механизм шифрования, который обеспечивает конфиденциальность сообщений, целостность, аутентификацию и управление доступом к сообщениям, компонентам и системам. Эти возможности могут быть реализованы при помощи программного обеспечения сервера, браузера, либо при помощи аппаратных средств ≈ платы PCMCIA

Шлюзовое серверное шифрование (Server-Gated Cryptography, SGC). Это расширение протокола SSL, которое позволяет финансовым учреждениям, использующим службы IIS в экспортном варианте, применять мощное 128-разрядное шифрование. Возможности SGC встроены в службы IIS, однако, чтобы использовать SGC, требуется специальный сертификат SGC.

Безопасность Kerberos. Службы IIS полностью интегрированы с моделью безопасности Kerberos, реализованной в Microsoft Windows 2000.

Расширенные возможности администрирования

Учет процессов (process accounting). Предоставляет информацию о том, как веб-узлы расходуют ресурсы процессора сервера. Эта информация полезна для выявления узлов, непропорционально использующих ресурсы процессора (в том числе сценариев или процессов CGI, содержащих ошибки).

Ограничение процессов (process throttling). Ограничивается время, которое процессор тратит на обработку процессов ASP, приложений ISAPI или CGI для отдельных веб-узлов.

Возможности для разработчиков приложений доступа к данным. Автор сценария, проектировщик или разработчик приложений доступа к базам данных и файлам может использовать следующие функциональные возможности IIS:

Выполнение сценариев, включенных в веб-страницы. При помощи ASP-страниц можно внедрять сценарии в страницы HTML и применять серверные компоненты ActiveX, чтобы реализовывать динамическую бизнес-логику на базе веб. Сценарии могут быть написаны на языке Microsoft Visual Basic, Scripting Edition, или на Microsoft JScript, а также на любом другом языке создания сценариев ActiveX, для которого имеется соответствующая поддержка в US (engine).
Доступ к базам данных. Если создаются и исполняются программы для доступа к базам данных, можно сделать эти программы более дружественными и более эффективными при помощи Microsoft Data Access Components (MDAC, Компоненты доступа к данным Microsoft), набора методов баз данных, интегрированных с IIS. Компоненты MDAC включают Microsoft Remote Data Service (RDS, Служба удаленных данных, ранее называвшаяся ADC), Microsoft ActiveX Data Objects (ADO, Объекты данных ActiveX), OLE DB и Open Database Connectivity (ODBC, Интерфейс открытого взаимодействия с базами данных). Кроме того, при помощи службы СОМ+, которая теперь включает все функциональные возможности, ранее поддерживаемые MTS (Microsoft Transaction Server, сервер транзакций Microsoft), можно структурировать взаимодействие с базами данных при помощи транзакций.
Транзакции ≈ это действия, состоящие из нескольких шагов, которые выполняются как единое целое и могут либо успешно завершиться, либо «откатиться» к исходному состоянию.
Управление группами страниц. При помощи Microsoft FrontPage Server Extensions (Серверные расширения для FrontPage) можно легко управлять группами страниц веб-узла. Встроенный анализатор содержания позволяет просматривать карту сервера в удобном для понимания визуальном формате, который облегчает управление файлами и связями.
Предоставление возможностей поиска. При помощи Службы индексирования (Indexing Service) можно создавать настраиваемые формы, которые предоставляют возможность поиска информации на веб-страницах или в других файлах веб-узла. Служба индексирования индексирует текстовое содержимое документов, хранящихся на сервере, на котором работает IIS, а также их свойства. Пользователи могут посылать поисковые запросы из любого браузера, заполняя простую форму.

Возможности для администраторов. Для администраторов информационных служб HS обеспечивает эффективное выполнение следующих действий:

Эффективный поиск (см. выше).

Возможности для разработчиков сценариев. Службы IIS предоставляют разработчику сценариев (программисту) среду для разработки приложений, которая эффективно управляет потоками и процессами и обеспечивает высокую масштабируемость. Можно использовать следующие функциональные возможности IIS для того, чтобы обеспечить дополнительную поддержку сценариев, компонентов или распределенных приложений:

Установка веб- и FTP-узлов. Можно устанавливать, конфигурировать и управлять веб- и FTP-узлами средствами оснастки Internet Information Services, графического интерфейса для администрирования служб IIS. Можно конфигурировать каждый узел и каталог по-своему, даже в случае использования нескольких узлов на одном сервере; имеются средства установки некоторых конфигурационных параметров (например, разрешения доступа), которые применяются даже на уровне конкретных файлов.
Автоматизация типовых задач администрирования. Можно создавать сценарии для выполнения всех задач администрирования IIS, разделив их на более простые процедуры. Эти задачи включают добавление или изменение веб-узлов, добавление групп, изменение разрешений доступа и управление регистрацией.
Защита узла. Службы IIS позволяют настраивать ряд параметров безопасности, используя встроенные в Windows 2000 механизмы безопасности, например учетные записи пользователей и средства безопасности файловой системы NTFS 5.0. Службы IIS имеют дополнительные возможности по обеспечению безопасности, включая блокирование доступа (блокирование попыток, сделанных с заданных IP-адресов) и безопасную связь между компьютерами с помощью SSL. В поставку ‘Windows 2000 включен Сервер сертификатов (Microsoft Certificate Server), который может выдавать сертификаты серверу или клиенту.
Регистрация действий и настройка производительности сервера. Оснастки Системный монитор (System Monitor) и Просмотр событий (Event Viewer) .позволяют отслеживать работу сервера. Также в IIS используется собственное протоколирование, которое фиксирует все заданные действия. При помощи различных встроенных средств можно анализировать журналы и поведение сервера ■ принимать решения. Можно настраивать производительность сервера при помощи административных инструментов и установок IIS. Также можно улучшать производительность сервера, используя возможности, перечисленные ниже в разделе «Возможности для разработчиков сценариев» данной главы.
Поддержка диалоговой обработки запросов. При помощи технологий СОМ+ можно группировать компоненты (дискретные модули кода) в пакеты, которые используют специальную среду для выполнения в виде транзакций. В новой версии IIS внутри транзакций можно выполнять не только приложения, но и сценарии. Те функции, что ранее поддерживались MTS, теперь полностью интегрированы с СОМ+.
Возможность изолирования процессов. Можно настроить IIS таким образом, чтобы изолировать друг от друга приложения, выполняющиеся в контексте IIS, т. е. заставить их работать & отдельных областях памяти. Это означает, что если приложения функционируют неправильно, они не будут воздействовать на работу других приложений или сервера в целом.
Интеграция с технологиями доступа к данным. При создании и выполнении программ для доступа к базам данных можно использовать набор компонентов доступа к данным MDAC (см. выше).
Разработка надежных приложений с применением СОМ+. Можно выполнять сценарии или приложения внутри одной транзакции. Объекты активизируются по требованию и деактивизируются после использования. Это позволяет экономить ресурсы сервера и увеличить число пользователей, одновременно работающих с приложением.

Новые возможности ASP

Active Server Pages ≈ основной механизм создания веб-ориентированных приложений для HS. ASP были расширены возможностями, которые делают более легким применение ASP для разработчиков сценариев и веб-приложений.

Новые возможности по управлению Потоком данных. Объект ASP Server имеет два новых метода, которые можно использовать для управления потоком данных из программы (Server.Transfer и Server.Execute). Эти методы действуют более эффективно, чем переназначение запросов, которое требует высокой производительности:сети при передаче данных клиенту и обратно; эти методы обеспечивают передачу запросов непосредственно файлу *.asp, при этом поток управления не покидает сервер.

Обработка ошибок. ASP-страницы содержат новую возможность обработки ошибок, которая осуществляет перехват ошибок при помощи ловушек (traps) и дает пользовательское сообщение об ошибке. При помощи нового метода, Server.GetLastError, можно отображать полезную информацию, например, описание ошибки или номер строки в файле *.asp, где произошла ошибка.

ASP без сценариев (scriptless ASP). Поскольку статическое содержание обычно обрабатывается быстрее, чем содержание, сгенерированное сервером динамически, было бы лучше заранее присваивать расширение asp только файлам, которые реально содержат функциональные возможности ASP. Всякий раз, когда требовалось добавить функциональные возможности ASP статическим файлам HTML, нужно было вручную присвоить файлу расширение asp и обновить связанные с ним гаперссылки. В новой версии файлы *.asp, которые не используют функциональных серверных возможностей, будут обработаны быстрее, чем ранее. Так, при создании веб-приложения, в котором файлы могут, в конечном счёте, требовать использования функциональных возможностей ASP, теперь можно назначать этим файлам расширение asp независимо от того, содержат ли они статическую информацию или серверные расширения.

Улучшенная производительность компонентов. В состав IIS включены расширенные версии наиболее часто используемых объектов ASP, которые обеспечивают повышенную производительность.

Интеграция с XML. Язык extensible Markup Language (XML, Расширяемый язык разметки) позволяет легко описывать сложные структуры данных и

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

Сервер скриптлетов. ASP поддерживает новую мощную технологию создания сценариев ≈ сервер скриптлетов (от «scriptlet» ≈ маленький сценарий). Теперь можно оформлять логические бизнес-правила сценариев в виде компонентов СОМ для многократного применения их в веб-приложениях, а также в других программах, поддерживающих СОМ.

Новый способ определять возможности браузера. ASP имеет новую возможность для определения точных возможностей браузера. Когда браузер посылает файл cookie с описанием своих возможностей (файл cookie может быть передан серверу при помощи простого сценария на стороне клиента), можно создать образец компонента возможностей браузера, который получает реквизиты браузера в том виде, в каком браузер вернул их в cookie. Так, прежде чем пользователь обратится к веб-приложению, мбжно выбрать этот путь, чтобы обнаружить возможности браузера и скорректировать поведение приложения.

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

Новая архитектура информационных систем

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

Представление данных
Бизнес-логика
Службы хранения данных

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

Службы хранения данных обеспечиваются различными структурированными хранилищами информации (серверами БД, например, Microsoft SQL Server, Oracle) или неструктурированными хранилищами (Microsoft Exchange, Microsoft Message Queue Services), которые управляют и обеспечивают доступ к данным из приложения. Отдельный запрос может потребовать использования одного или более хранилищ данных.

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

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

Рис 22.3. Архитектура трехуровневых систем на базе служб Microsoft

Распределенная архитектура Интернет-приложений. Компания Microsoft разработала технологию Windows Distributed interNet Application Architecture (Windows DNA, Распределенная архитектура Интернет-приложений Windows), полностью интегрирующую многоуровневую модель разработки с веб-технологией. Windows DNA определяет каркас для создания решений, которые удовлетворяют требованиям корпоративных вычислений, Интернета, интрасетей и глобальной электронной торговли, уменьшая при этом издержки на общую разработку и развертывание системы.

В архитектуре Windows DNA стандартные службы на базе Windows выполняют определенные задачи на каждом уровне в многоуровневом решении, обеспечивая интерфейс пользователя и навигацию, бизнес-логику и хранение данных. Различные службы интегрированы при помощи Common Object Model (COM, Общая объектная модель). Службы, используемые в Windows DNA, включают; Dynamic HTML (Динамический HTML), Active Server Pages (Активные серверные страницы, ASP), компоненты COM, Microsoft Transaction Server,, службу Active Directory, службы безопасности Windows 2000, Microsoft Message Queue Services (MSMQ, Службы очереди сообщений) и компоненты доступа к данным Microsoft.

Архитектура Windows DNA создана с применением открытых протоколов и общедоступных интерфейсов, что облегчает организациям задачу интеграции новых систем с продуктами третьих фирм. Обеспечивая промышленные стандарты Интернета, Windows DNA упрощает работы по внедрению новых технологий для разработчиков. На рис. 22.4 представлена схема, которая иллюстрирует технологии ≈ составные части Windows DNA.

Рис 22.4. Технологии Windows DNA

Установка и удаление служб IIS

Службы Internet Information Services устанавливаются на компьютере с Windows 2000 Server по умолчанию. Можно установить IIS, удалить или установить дополнительные компоненты, используя значок Установка и удаление программ (Add/Remove Programs) из панели управления.

Чтобы установить IIS, добавить или удалить компоненты:

1. Выберите команду Пуск (Start) | Настройка (Settings) | Панель управления (Control panel) и дважды щелкните на значке Установка и удаление программ (Add/Remove Programs).
2. В левом столбце диалогового окна Установка и удаление программ перейдите на вкладку Установка и удаление компонентов Windows (Add/Remove Windows Components).
3. Когда запустится Мастер компонентов Windows (Windows Components Wizard), нажмите кнопку Далее (Next).
4. В списке Компоненты (Windows Components) выберите Internet Information Services (IIS) (рис. 22.5).
5. Нажмите кнопку Далее и следуйте командам мастера.

Основные компоненты IIS

Основные компоненты IIS, которые можно удалить или установить из панели управления (рис. 22.6):

Общие файлы (Common Files)
Документация (Documentation)
FTP-сервер (File Transfer Protocol) (File Transfer Protocol (FTP) Server)
Серверные расширения для FrpntPage 2000 (FrontPage 2000 Server Extensions)
Объект IIS для консоли ММС (Internet Information Services Snap-In)
Диспетчер служб Интернета (HTML) (Internet Services Manager (HTML))
Служба NNTP (NNTP Service) П Служба SMTP (SMTP Service)
Поддержка удаленного развертывания Visual InterDev RAD (Visual InterDev RAD Remote Deployment Support)
Веб-сервер (World Wide Web Server)

Рис 22.5. Установка и удаление служб IIS

Рис 22.6. Компоненты служб IIS

Если ОС Windows 2000 устанавливалась поверх предыдущей версии Windows, IIS устанавливаются по умолчанию, только если веб-сервер (IIS) был установлен в предыдущей версии Windows.

Удаление служб IIS производится при помощи той же процедуры, что и установка. Для удаления IIS сбросьте флажок рядом с названием компонента Windows в списке компонентов.

Каталоги, содержащие пользовательские данные, остаются в системе после того, как IIS полностью удаляется:

\Inetpub
%SystemRoot%\Help\iisHelp
%SystemRoot%\system32\inetsrv

Администрирование служб IIS

Не всегда удобно администрировать службы IIS непосредственно на компьютере, где они установлены. Для решения проблем локального и удаленного администрирования есть два средства: если соединение с сервером устанавливается через Интернет или через прокси-сервер, можно использовать Диспетчер служб Интернета (HTML) (Internet Services Manager (HTML)), который доступен через веб-браузер и позволяет настраивать различные свойства узлов; если соединение с сервером устанавливается через интраееть, можно использовать или диспетчер служб Интернета (HTML), или оснастку Internet Information Services. Хотя диспетчер служб Интернета (HTML) и предоставляет большинство возможностей оснастки, однако изменение свойств, которое требует взаимодействия с утилитами Windows, не может быть выполнено с его помощью.

В предыдущей версии IIS оснастка для управления службами называлась Internet Services Manager. В Windows 2000 оснастка называется Internet Information Services, а ярлык в меню Пуск ≈ Диспетчер служб Интернета (Internet Services Manager).

Также для удаленного администрирования доступна онлайновая версия документации. Чтобы обратиться к документации, запустите браузер и введите в поле адреса URL http://имя_cepвepa/iishelp , где имя_сервера ≈ реальное доменное имя компьютера, на котором функционируют службы IIS.

Для удаленного управления IIS можно также использовать возможности служб терминалов (Terminal Services). Удаленное управление может производиться с компьютера под управлением любой ОС, для которой существует клиент служб терминалов Microsoft, при этом на удаленном компьютере не нужно устанавливать никакие средства администрирования IIS.

Оснастка Internet Information Services. Оснастка Internet Information Services (рис. 22.1) ≈ средство администрирования IIS, доступна из меню Пуск | Программы | Администрирование | Диспетчер служб Интернета (Start | Programs | Administrative Tools | Internet Services Manager). Также она включена в состав оснастки Управление компьютером (Computer Management).

Для запуска оснастки Internet Information Services:

1. Запустите оснастку Управление компьютером. Один из способов ≈ нажать кнопку Пуск (Start), а затем в меню выбрать команду Пуск | Программы | Администрирование | Управление компьютером (Programs | Administrative Tools | Computer Management).
2. В дереве в группе Службы и приложения (Services and Applications) найдите и разверните узел Internet Information Services.
Для удобства средство администрирования US (которое представляет собой оснастку Internet Information Services) будем также называть по имени ярлыка из меню Пуск (Start) ≈ Диспетчер служб Интернета

Диспетчер служб Интернета (HTML). Для управления свойствами IIS в диспетчере служб Интернета (HTML) 4 (рис. 22.2) используется узел, который в списке узлов отображается как Администрирование веб-узла (Administration Web Site). При установке IIS автоматически случайно выбирается номер порта в диапазоне от 2000 до 9999, который назначается этому веб-узлу. Узел отвечает на запросы веб-браузеров, независимо от того, к какому доменному имени (из связанных с данным компьютером) происходит обращение, при совпадении номера порта, который добавляется в конце к имени узла. Если используется базовая (basic) аутентификация, то от администратора при подключении к административному узлу будут запрошены имя пользователя и пароль. Только члены группы Windows Администраторы (Administrators) могут использовать этот административный узел. Также управлять узлом дистанционно могут Операторы узла (Web Site Operators). Хотя HTML-версия диспетчера служб Интернета реализует большинство функциональных возможностей оснастки IIS, версия с использованием HTML предназначена для удаленного управления по медленным коммутируемым линиям. В ней не поддерживается, например, щелчок правой кнопкой мыши. Многие из знакомых кнопок на панели или заголовки вкладок отображаются в виде гиперссылок в левой панели окна браузера.

Администрирование служб веб и FTP

Веб-узлы и FTP-узлы. В интрасетях и Интернете можно создавать несколько веб- и FTP-узлов (сайтов) на одном компьютере, который работает под управлением Windows 2000, одним из следующих способов:

При помощи разных номеров портов для одного адреса
Используя несколько IP-адресов, назначенных одному адаптеру
Используя несколько доменных имен для одного IP-адреса и одного сетевого адаптера

Предположим, что в корпоративной интрасети системный администратор установил на сервере компании систему Windows 2000 Server со службами IIS и создал единственный узел по умолчанию, который имеет адрес http://Information. Системный администратор может создать два дополнительных информационных узла, по одному для каждого отдела, например, для отдела продаж (Sales) и для отдела закупок (Purchase).

Хотя оба узла расположены на одном компьютере (Information), они являются автономно функционирующими узлами (сайтами). Эти узлы имеют раздельные настройки защиты, как если бы они находились на разных компьютерах, поскольку каждый узел имеет собственные параметры доступа и настройки разрешений по администрированию. Кроме того, административные задачи могут быть распределены между членами каждого отдела.

Свойства и наследование свойств. Свойства≈ параметры, которые могут быть настроены для конкретного узла. Например, можно использовать оснастку Internet Information Services, чтобы изменить порт TCP по умолчанию (80) для сервера на другой номер порта. Свойства узла видны в окнах свойств и хранятся в базе данных, которая называется метабазой (metabase).

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

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

Некоторые свойства имеют значение, которое представляет собой список. , Например, значение свойства «Документ, используемый по умолчанию» (Default Document) ≈ список документов, которые будут загружены, когда пользователь не задает файл в URL. Пользовательские сообщения об ошибках, управление доступом по TCP/IP, отображение MIME ≈- примеры свойств, которые хранятся в виде списка. Хотя эти списки состоят из нескольких записей, IIS рассматривает список целиком как единое целое. Если список редактируется для каталога, а затем производится глобальная замена на уровне узлов, список на уровне каталога полностью заменяется новым списком с уровня узла; списки не объединяются. Также свойства-списки отображаются в виде списка с составом только на верхнем уровне, управляющем, или на уровне узла или каталога, для которого значение по умолчанию было изменено. Значения-списки не отображаются, если они являются унаследованными значениями по умолчанию.

Фильтры отображаются в виде списка, но обрабатываются не как список. Если фильтры добавляются на уровне узлов, то новые фильтры объединяются со списком фильтров от управляющего уровня. Если два фильтра имеют одинаковые установки приоритетов, фильтр с управляющего уровня загружается перед фильтром с уровня узла.

Если создается несколько веб- или FTP-узлов, можно редактировать значения по умолчанию (рис. 22.7) таким образом, чтобы каждый узел, который создается, наследовал пользовательские значения узлов по умолчанию (Веб-узел по умолчанию и FTP-узел по умолчанию (Default Web Site и Default FTP Site)).

Рис 22.7. Свойства веб-узла по умолчанию

Операторы узла. Это специальная группа пользователей, которым предоставлены ограниченные административные привилегии для данного узла. Операторы могут управлять свойствами, имеющими отношение только к соответствующему узлу. Они не имеют доступа к свойствам, которые относятся к управлению IIS в целом, к управлению компьютером-сервером Windows или сетью.

Например, поставщик Интернет-услуг, поддерживающий узлы множества различных компаний, может делегировать полномочия на поддержку соответствующих узлов представителю каждой компании в качестве оператора узла. Этот метод распределенного администрирования сервера имеет следующие преимущества:

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

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

В IIS докачка по протоколу FTP невозможна в следующих случаях: при использовании запроса на получение файла по маске (МОЕТ), при передаче файлов на сервер (PUT) или при получении файлов размером более 4 Гбайт.

Сопоставление MIME. MIME (Multipurpose Internet Mail Extensions, Многоцелевые почтовые расширения Интернета) ≈ стандарт сети Интернет, который предоставляет возможность программам просмотра (браузерам) определять формат файла и корректно его отображать. Зарегистрированные типы файлов, которые установлены по умолчанию в Windows 2000, перечислены в окне Типы файла (File type), доступном на вкладке Internet Information Services в диалоговом окне свойств служб IIS данного компьютера (доступны для компьютера из контекстного меню корневого узла оснастки Internet Information Services).

Сопоставления (map) MIME могут быть настроены на уровне компьютера, на уровне узла, на уровне виртуального каталога, на уровне каталога или на уровне файлов. Чтобы настроить отображения MIME на уровне компьютера, необходимо перейти в диалоговое окно Свойства (Properties) служб IIS данного компьютера (в контекстном меню в оснастке IIS выбрать пункт меню Свойства). Чтобы настроить отображения MIME на других уровнях, нужно использовать вкладку Заголовки HTTP (HTTP Headers) диалогового окна свойств объекта соответствующего уровня.

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

Управление информационным наполнением

Необходимость в корректном управлении содержимым (наполнением, content) очевидна. Предположим, что создан сложный информационный сервер преуспевающей компании. На каком-то этапе был спроектирован дизайн сервера ≈ заголовки, подвалы и элементы оформления. Однако в самом конце выяснилось, что была допущена ошибка в логотипе компании, который расположен на всех многочисленных страницах узла. Возможны также неисправности в аппаратной части компьютера. При этом может понадобиться перенаправить всех пользователей узла на другой, резервный сервер, пока производится восстановление аппаратуры.

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

Начальные действия. Сначала нужно создать веб-узел и указать, в каких каталогах хранятся публикуемые документы. Веб-сервер не может опубликовать документы, которые находятся вне пределов указанных каталогов. Первым шагом в развертывании веб-узла является задание организационной структуры файлов. После этого, используя оснастку Internet Information Services, нужно задать, какие каталоги являются частью узла.

Если необходимо опубликовать информацию немедленно, не тратя время на создание структуры каталогов узла, и все файлы расположены на одном и том же жестком диске, можно просто скопировать публикуемые файлы в основной каталог по умолчанию, \InetPub\Wwwroot. (Для FTP-узла, нужно скопировать файлы в каталог \InetPub\Ftproot.) Пользователи сети смогут обращаться к этим файлам, вводя URL-адрес http://server/имя_файла

Задание домашних каталогов. Каждый веб-узел или FTP-узел должен иметь корневой (домашний) каталог. Домашний каталог ≈ отправная точка для организации информационной структуры публикуемых страниц. Он содержит домашнюю страницу или индексный файл, который является стартовой страницей узла и содержит ссылки на другие страницы на узле. Домашний каталог привязывается к имени домена узла или к имени сервера.

Например, если имя домена узла ≈ www.myfirm.com и корневой каталог ≈ \Webserver\MyFirm, то браузер, обращаясь по URL http://www.myfirm.com, получит файлы из корневого каталога. В интрасети, если имя сервера ≈ Infoserver, то браузер, обращаясь по URL http://Infoserver, получит доступ к файлам в корневом каталоге.

Корневой каталог по умолчанию создается при установке Internet Information Services, а также при создании нового веб-узла. Корневой каталог можно изменять (рис. 22.8).

Рис 22.8. Задание домашнего каталога

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

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

Предположим, что для публикации информации в сети установлен узел infoserver. В табл. 22.1 показано соответствие между физическим местоположением файлов и URL, по которому файлы доступны.

Таблица 22.1. Примеры соответствия между физическим местоположением, псевдонимом и URL-адресом

Физическое местоположение Псевдоним Путь URL
c:\wwwroot Домашний каталог (нет псевдонима) http:/flnfoserver
\\Server2\info\Data Data http://Sales/Data
c:\wwwroot\Schedule Нет httyj://infoserver/Schedule
c:\wwwroot\Products Нет http://infoserver/Schedule
d :\samples\documents Text http://infoserver/Schedule

Как виртуальные, так и физические каталоги (каталоги без псевдонима) видны в оснастке Internet Information Services. Виртуальный каталог обозначается в виде значка папки с глобусом в углу.

Для простого веб-узла не требуется создание виртуальных каталогов. Можно просто разместить все файлы в основном каталоге узла. Если нужно построить сложный узел или задать различные URL для различных частей узла, можно добавлять виртуальные каталоги по необходимости.

Переадресация запросов. Когда браузер запрашивает страницу с узла, веб-сервер ищет страницу по заданному URJL и возвращает ее браузеру. Когда страница перемещается внутри узла, не всегда можно исправить все связи, которые ссылаются на старый URL страницы. Чтобы удостовериться в том, что браузеры смогут найти страницу по новому URL, можно заставить веб-сервер предоставлять браузеру новый URL. Браузер использует новый URL, чтобы запросить эту страницу снова. Этот процесс называется переадресацией запроса браузера или переадресацией на другой URL. Переадресация запроса о получении страницы подобна переадресации в почтовой службе. Переадресация гарантирует, что письма и пакеты, отправленные по предыдущему адресу вашего проживания, будут доставлены по новому адресу.

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

Другие средства. Часто может потребоваться динамически изменять содержание узла после того, как содержание было затребовано, но до передачи его браузеру. IIS включает две возможности, которые обеспечивают эту функциональность ≈ серверные включения (Server-Side Includes, SSI) и Microsoft Active Server Pages (ASP) ≈ для создания сценариев-посредников.

Используя SSI, можно выполнять ряд действий ≈ от динамического отображения текущего времени на странице до выполнения заданных системных команд каждый раз, когда запрашивается данный ресурс (страница). SSI-команды, называемые директивами, включаются в страницы во времени разработки. Когда страница запрашивается, веб-сервер анализирует синтаксис всех директив на странице, а затем выполняет их. Наиболее часто используется директива включения, что позволяет включать содержимое файла внутрь страницы. Например, если требуется, чтобы в заголовок страницы вставлялась реклама, можно при помощи SSI включить исходный текст рекламы. Чтобы модифицировать рекламу, нужно изменить только файл, содержащий исходный текст рекламы. Для применения SSI не нужно знать язык создания сценариев ≈ синтаксис директив очень прост.

ASP-страницы ≈ серверная среда создания сценариев, позволяющая динамически изменять содержимое узла. Хотя технология ASP предназначена прежде всего для разработки веб-приложений, она предоставляет много возможностей для создания более простых в управлении узлов. Например, с помощью ASP можно отслеживать посещение узла пользователями (их атрибуты≈ IP-адрес, тип браузера, назначенные cookies и т. п.) или настраивать содержимое узла под возможности браузера. Однако, в отличие от SSI, ASP требует применения языка создания сценария, например VBScript или JScript.

Выбор инструмента для создания страниц. Феноменальный рост сети Интернет и развитие технологий интрасетей создали огромный спрос на специализированные средства создания узлов. Если пользователь плохо знаком с основами публикации в Интернете, выбрать надлежащий инструмент для создания узла может быть достаточно сложно. Мощного сервера, предназначенного для размещения готовых страниц, недостаточно для успешного пуска и эксплуатации информационного узла в Интернете. Вот инструменты создания и публикации узлов:

Microsoft FrontPage 2000. Удобный, простой и мощный инструмент создания страниц и публикации их в сети. Обладает возможностями WYSIWYG (What You See Is What You Get, принцип «что видишь ≈ то и получишь», т. е. визуальное создание с непосредственным отображением результата), тесно интегрирован с Microsoft Office 2000 и со службами IIS.
Преобразование в HTML. Привлекательная альтернатива созданию страниц ≈ преобразование существующих документов в документы HTML. Применяя к файлам текстового процессора и электронных таблиц конвертер, можно сразу помещать такого рода страницы в сети, на веб-сервере. Многие программы обработки текстов, например Microsoft Word 2000, имеют встроенные возможности для преобразования документов в формат HTML. Однако большинство конвертеров только добавляет тэги форматирования HTML к тексту, плохо сохраняя первоначальный вид документов. Конвертеры ≈ удобные средства, они особенно полезны, если планируется публиковать большую часть существующей документации, которая не нуждается в частом изменении.
Текстовый редактор. Страницы можно создавать почти в любом стандартном текстовом редакторе, например, в Блокноте (Notepad), вводя тэги HTML и содержимое страниц, сохраняя в файле, а затем открывая их в браузере для предварительного просмотра. Некоторые опытные пользователи предпочитают этот метод, потому что он обеспечивает более тонкий контроль форматирования страниц и позволяет применять последние технологические новшества Интернета.

Служба Microsoft NNTP проста в управлении, поскольку содержит удобные инструменты и поддерживает тесную интеграцию с Microsoft Windows 2000 Server. Вот основные возможности службы Microsoft NNTP:

Поддержка стандартов

Служба Microsoft NNTP поддерживает Network News Transport Protocol (NNTP, Протокол доставки сетевых новостей), который предназначен для связи клиента с сервером, а также для связи двух серверов. Служба Microsoft NNTP поддерживает популярные расширения NNTP и полностью совместима с другими клиентами и серверами NNTP.

Кроме того, служба Microsoft NNTP поддерживает многочисленные форматы, включая:

  • Multipurpose Internet Mail Extension (MIME)
  • Язык разметки гипертекста HTML
  • Формат изображений GIF
  • Формат изображений JPEG

Поддержка этих стандартов позволяет включать изображения и гипертекстовые ссылки в статьи новостей.

Простота администрирования

Служба Microsoft NNTP предлагает на выбор два графических инструмента для выполнения всех задач администрирования:

  • Оснастка Internet Information Services.С помощью этой оснастки управление службой Microsoft NNTP осуществляется в пределах одной ЛВС. Этот инструмент может управлять всеми компонентами IIS, используя единый интерфейс (рис. 22.9).
  • Диспетчер служб Интернета (HTML). При помощи веб-браузера, например Microsoft Internet Explorer, можно управлять службой Microsoft NNTP с любого компьютера локальной сети или из Интернета. Единственное требование для применения этого инструмента ≈ наличие любого веб-браузера на компьютере администратора.

Рис 22.9. Оснастка Internet Information Services ≈ управление службой Microsoft NNTP

Интеграция с Microsoft Windows 2000

Служба Microsoft NNTP полностью использует преимущества стандартных инструментов администрирования Windows 2000 для текущего контроля производительности и отслеживания событий. При инсталляции службы Microsoft NNTP устанавливается набор счетчиков для оснастки Системный монитор. Все состояния службы Microsoft NNTP и сообщения об ошибках записываются в журналы событий и могут просматриваться при помощи оснастки Просмотр событий. Служба Microsoft NNTP также включает поддержку SNMP.

Служба Microsoft NNTP управляет доступом к группам новостей, используя списки ACL Windows 2000. Устанавливая разрешения на каталог, который содержит группу новостей, можно управлять доступом к этой группе новостей. Можно также разрешить анонимный доступ, при этом доступ к группе новостей будет предоставлен всем.

Интеграция со службой индексирования

Служба Microsoft NNTP поддерживает полнотекстовое индексирование содержания и индексирование по свойствам групп новостей.

Улучшенная безопасность

Служба Microsoft NNTP поддерживает несколько вариантов безопасности, которые аутентифицируют пользователей групп новостей и защищают частную информацию:

  • Анонимный доступ (anonymous access). Разрешает любому пользователю доступ к группе новостей, не требует указания имени пользователя или пароля.
  • Стандартное расширение безопасности NNTP (Standard Secure NNTP extension). Требует, чтобы пользователь предоставил имя пользователя и пароль, которые посылаются по сети открытым текстом.
  • Протокол вызова/ответа Windows (Windows Challenge/Answer Protocol). Требует, чтобы пользователь предоставил имя пользователя и пароль, которые передаются в шифрованном виде для безопасной передачи по сети. Этот протокол требует использования клиентского программного обеспечения Microsoft Internet Mail and News (или Outlook Express).
  • Протокол SSL (Secure Sockets Layer). Чтобы защитить информацию, передаваемую через общую сеть, служба Microsoft NNTP поддерживает шифрование SSL, которое включает проверку подлинности клиентов и серверов.

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

Оснастка Internet Information Services может выполнять все задачи по администрированию, требует подключения через ЛВС. При ее использовании для управления службой NNTP нужно раскрыть узел Виртуальный NNTP-сервер по умолчанию.
Оснастку Internet Information Services можно использовать для управления виртуальным сервером NNTP и с удаленного компьютера, если он находится в той же ЛВС, что и Microsoft NNTP Service. Однако этот компьютер должен работать под управлением Microsoft Windows 2000, и на нем! должны быть установлены средства администрирования Windows 2000.
Виртуальный сервер, который создается по умолчанию на сервере после инсталляции службы, ≈ Виртуальный NNTP-сврвер по умолчанию (Default NNTP Virtual Server). Служба Microsoft NNTP может состоять из одного или большего количества виртуальных серверов NNTP.

Чтобы просмотреть или изменить свойства виртуального сервера NNTP:

1. Выберите в дереве нужный виртуальный сервер NNTP.
2. В меню Действие (Action) выберите команду Свойства (Properties).
3. Перейдите на нужную вкладку в диалоговом окне.
4. Измените любые опции по необходимости.
Диспетчер NNTP Service Manager (HTML) позволяет решать большинство задач, выполняемых в оснастке ММС. Преимущество NNTP Service Manager (HTML) в том, что через веб-браузер можно администрировать службу при помощи любого соединения через любую сеть, включая Интернет. Браузер может находиться на компьютере, на котором функционирует служба, или на любом другом компьютере, который может установить соединение по протоколу TCP/IP со службой Microsoft NNTP. В качестве браузера используйте Microsoft Internet Explorer версии 4.0 и старше или Netscape Navigator версии 4.0 и старше.

Для обращения к NNTP Service Manager (HTML) с компьютера, на котором функционирует служба Microsoft NNTP:

  • В строке адреса введите http://iocalhost/news/admin и перейдите к этому адресу

Для обращения к NNTP Service Manager (HTML) с удаленного компьютера:

  • В строке адреса введите http://имя_сервера/news/admin где имя_сервера ≈ компьютер, на котором функционирует служба Microsoft NNTP.
Предварительно следует удостовериться, что удаленный компьютер имеет необходимые разрешения для доступа к NNTP Service Manager (HTML).

При инсталляции службы Microsoft NNTP на компьютер устанавливаются оба средства администрирования. Для доступа к оснастке управления службой с удаленного компьютера нужен компьютер под управлением Microsoft Windows 2000; на удаленном компьютере должны быть установлены средства администрирования Windows 2000 (Windows 2000 Administrative Tools).

Функционирование службы NNTP

Служба Microsoft NNTP поддерживает протокол NNTP (Network News Transfer Protocol, Протокол передачи новостей Интернета), который является клиент-серверным протоколом. Служба Microsoft NNTP выступает в роли сервера, a Microsoft Outlook Express ≈ пример типичного клиента.

Клиенты подключаются к службе Microsoft NNTP по протоколу TCP/IP. Обычно по умолчанию при нормальном подключении используется TCP-порт 119, для шифрованных SSL-подключений ≈ TCP-порт 563.

Microsoft NNTP работает как служба на сервере Windows 2000 и стартует автоматически; ее имя в оснастке Службы (Services) ≈ Протокол Network News Transport Protocol (NNTP) (в англоязычной версии ≈ Network News Transfer Protocol (NNTP)).

Публикация статей. Для передачи статьи телеконференции через службу Microsoft NNTP следует использовать программу-клиент новостей, например Microsoft Outlook Express. Клиент подключается к NNTP и запрашивает публикацию переданной статьи в одной или более телеконференций. Служба NNTP устанавливает соединение, принимает запрос и проверяет права пользователя на публикацию статьи в указанных телеконференциях (рис. 22.10). Служба NNTP затем публикует статью в телеконференциях и модифицирует индекс телеконференции.

Рис 22.10. Публикация статей

Просмотр статей. Для просмотра статей в телеконференциях, опубликованных при помощи службы Microsoft NNTP, необходимо использовать программу-клиент чтения новостей, например Microsoft Outlook Express.

Первый шаг при просмотре статей в телеконференции ≈ получение списка доступных телеконференций (рис. 22.11). Клиент подключается к службе Microsoft NNTP и запрашивает список доступных телеконференций. Служба Microsoft NNTP принимает запрос, аутентифицирует пользователя, обращающегося к телеконференциям, проверяет его права, а затем посылает клиенту список всех доступных телеконференций.

Второй шаг ≈ выбор телеконференции, которую пользователь хочет просмотреть. Клиент запрашивает список статей в выбранной телеконференции. Служба Microsoft NNTP аутентифицирует пользователя, обращающегося к указанной телеконференции, проверяет его полномочия и посылает клиенту список всех статей в этой телеконференции. Затем пользователь выбирает статью, клиент запрашивает выбранную статью у службы Microsoft NNTP, а служба возвращает содержимое статьи.

Рис 22.11. Просмотр статей

Структуры данных службы Microsoft NNTP. Статьи телеконференций в службе Microsoft NNTP хранятся в одной или в нескольких группах иерархических каталогов. Каждая телеконференция имеет собственный каталог, а каждая статья хранится как файл в этом каталоге.

Основной каталог по умолчанию ≈ C:\Inetpub\Nntpfile\root, его можно переназначить на вкладке свойств основного каталога виртуального сервера NNTP. Можно создавать дополнительные иерархии каталогов на других дисках или на других компьютерах, создавая виртуальные каталоги.

Каталог телеконференции имеет то же имя, что и сама телеконференция. Служба Microsoft NNTP автоматически создает требуемые каталоги, когда создается новая телеконференция. Например, телеконференция, названная sample.test хранится в подкаталоге \sample\test относительно корневого каталога, то есть в каталоге C:\Inetpub\Nntpfile\root\sample\test. Все файлы статей телеконференций имеют расширение nws.

Служба Microsoft NNTP также создает файлы, в которых хранятся темы размещенных в телеконференции статей; эти файлы имеют расширение xix. Служба Microsoft NNTP создает один файл для каждых 128 статей в телеконференции.

Служба Microsoft NNTP также поддерживает множество внутренних файлов структуры данных с расширениями hsh, hdr, 1st и txt. Заданное по умолчанию расположение этих файлов ≈ C:\Inetpub\Nntpfile. Нельзя изменять или удалять эти файлы. Средства восстановления службы Microsoft NNTP исправляет эти файлы, если они были случайно удалены или повреждены.

Примеры использования сервера NNTP

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

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

Состав программного обеспечения: Microsoft Windows 2000 Server, Microsoft Internet Information Services (US), Microsoft Internet Mail and News или Microsoft Outlook Express.

Среда: Сеть на базе Microsoft Windows.

Установка: Установить службу Microsoft NNTP ≈ компонент US.

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

Функционирование: Выполнение функций поддержки несколько телеконференций в пределах организации потребует не очень больших ресурсов со стороны сервера. Можно использовать любой компьютер, работающий под управлением Windows 2000 Server. Поскольку служба Microsoft NNTP использует стандартный протокол NNTP, сотрудники могут иметь доступ к

телеконференциям, используя любое клиентское программное обеспечение, поддерживающее NNTP, однако предпочтительно работать с Microsoft Internet Mail and News и Outlook Express ≈ клиентами, которые обеспечивают дополнительные функции защиты, если есть потребность в таких функциях. Сервер и клиенты должны поддерживать TCP/IP.

URL для телеконференций будет иметь следующие форматы:

где сервер ≈ имя или IP-адрес сервера NNTP, телеконференция ≈ имя телеконференции, а статья ≈ необязательный идентификатор конкретной статьи.

В зависимости от того, насколько конфиденциальными будут статьи, можно настраивать параметры защиты для телеконференции. Если информация доступна любому в организации и сеть защищена брандмауэром, можно разрешить анонимный вход. Для большей защиты можно использовать штатные средства безопасности Windows 2000, которые применяются к каждому пользователю телеконференции. Можно ограничить доступ к каталогам телеконференций для определенных учетных записей. Служба Microsoft NNTP управляет защитой, используя учетные записи Windows 2000 и соответствующие разрешения.

Результат: Работа членов отдела упростится. Сотрудники смогут читать и публиковать статьи, содержащие информацию по проекту, на сервере новостей. Для обсуждения деталей проекта не потребуются личные встречи, отнимающие время.

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

Цель: Уменьшить затраты на поддержку пользователей и улучшить клиентскую службу, предоставив клиентам быстрый свободный доступ к информации и технической поддержке.

Программные компоненты: Microsoft Windows 2000 Server, Microsoft Internet Information Services (US), Microsoft Internet Mail and News или Microsoft Outlook Express.

Установка: Разрешить анонимный доступ; использовать DNS или WINS для разрешения имени; обеспечить доступ через брандмауэр (при его наличии).

Прочие аспекты: Необходимо рассмотреть возможность организации моде-рируемых (редактируемых специальноч назначенным человеком, так называемым «модератором») конференций, чтобы предотвратить публикацию не-

корректных, технически неправильных статей. Это может ограничить возможность клиентов помочь друг другу, если персонал поддержки не доступен в настоящий момент.

Функционирование: Если службы IIS уже используются, то для обеспечения технической поддержки через публикацию технической информации на веб-сервере можно просто добавить поддержку телеконференций на том же компьютере. Если планируется активно использовать сервер телеконференций, можно расположить службу Microsoft NNTP на отдельном компьютере.

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

URL-адреса для телеконференций будут иметь стандартные форматы (см. выше).

Чтобы обеспечить наискорейшую отдачу от телеконференций, персонал поддержки клиентов должен достаточно часто читать статьи в телеконференциях и быстро отвечать на вопросы. Одним из удобных средств может оказаться публикация часто задаваемых вопросов (Frequently Asked Questions, FAQ) и ответов на них.

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

Служба Microsoft SMTP имеет следующие особенности:

Поддержка стандартных протоколов Интернета. Служба Microsoft SMTP обеспечивает полную поддержку SMTP и совместима с почтовыми клиентами SMTP.
Масштабируемость. Служба Microsoft SMTP поддерживает сотни одновременных клиентских соединений при конфигурации с одним сервером. Можно также настроить использование множества доменов для одного сервера.
Простое администрирование и интеграция с Microsoft Windows 2000. Служба Microsoft SMTP управляется как через консоль ММС (рис. 22.12), так и с помощью веб-интерфейса.
Улучшенная безопасность. Служба Microsoft SMTP поддерживает протоколы безопасной передачи почты на транспортном уровне.
Прямая доставка и извлечение почты. Служба Microsoft SMTP поддерживает размещение всех входящих сообщений непосредственно в каталоге \Drop. Это позволяет использовать службу Microsoft SMTP для приема почты других приложений. В дополнение к передаче сообщений через порт TCP приложения могут использовать каталог \Pickup. После форматирования сообщения служба Microsoft SMTP осуществляет его доставку.

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

Служба Microsoft SMTP имеет стандартные средства управления:

Оснастка Internet Information Services, которая может выполнять все задачи по администрированию службы и требует подключения через ЛВС. В дереве консоли нужно развернуть узел Виртуальный NNTP-cepeep no умолчанию (рис. 22.12).

Виртуальный сервер, который создается при инсталляции службы, ≈ Виртуальный NNTP-cepeep no умолчанию (Default SMTP Virtual Server).

Рис 22.12. Управление SMTP-сервером с помощью оснастки Internet Information Services (в составе оснастки Управление компьютером)
Диспетчер SMTP Service Manager (HTML), с помощью которого можно выполнять большинство задач управления, которые могли бы быть выполнены с помощью оснастки IIS. Преимущество SMTP Service Manager (HTML) в том, что можно подключаться и управлять службой SMTP с использованием любой сети, включая Интернет.

Для управления службой веб-браузер можно запускать на компьютере, где установлена служба, или с любого другого компьютера, работающего по протоколу TCP/IP и доступного по сети (включая подключение через Интернет). Необходим браузер Microsoft Internet Explorer 4.0 или выше, либо Netscape Navigator 4.0 или выше.

Для того чтобы запустить SMTP Service Manager (HTML) с компьютера, на котором выполняется служба Microsoft SMTP (имя службы ≈ Протокол Simple Mail Transport Protocol (SMTP)):

  • В строке адреса браузера введите http://looalhost/mail/smtp/admin

Для того чтобы запустить SMTP Service Manager (HTML) с удаленного компьютера:

  • В строке адреса браузера введите http: //ceрвep/mail/smtp/admin

где сервер ≈ имя компьютера, на котором функционирует служба Microsoft SMTP.

Необходимо удостовериться, что удаленный компьютер имеет нужные разрешения для обращения к SMTP Service Manager (HTML).

Цвет значка виртуального сервера SMTP показывает состояние сервера: зеленый обозначает работающую службу, серый ≈ приостановленную, красный ≈ остановленную службу.

Оба административных средства установлены по умолчанию и функционируют на компьютере, на котором установлена служба SMTP фирмы Microsoft. Чтобы использовать управление через оснастку с удаленного компьютера, нужен компьютер под управлением Microsoft Windows 2000; на удаленном компьютере должны быть установлены средства администрирования Windows 2000 (Windows 2000 Administrative Tools).

Службы компонентов (Component Services) обеспечивают разработку и развертывание распределенных клиент-серверных приложений типа онлайновых бизнес-приложений и приложений электронной коммерции, имеющих веб-интерфейс. Службы компонентов используют технологию СОМ+ и обеспечивают такие функциональные возможности, как автоматическая поддержка целостности данных на основе транзакций, защита информации, основанная на ролях, доступ к различным СУБД, службам очередей сообщений (например, MSMQ) и другим приложениям.

Службы компонентов полностью интегрированы с другими компонентами и службами Windows 2000 Server. Интеграция со службами Internet Information Services и Active Server Pages упрощает создание приложений в среде Интернет/интрасети. Интеграция с кластерными службами повышает отказоустойчивость. Интеграция со службой обработки очередей сообщений (MSMQ) обеспечивает надежную, постоянную связь между приложениями.

Возможности Microsoft Transaction Server (MTS) были объединены с «классической» технологией СОМ и образовали технологию СОМ+, которая интегрирована в операционную систему Windows 2000. Оснастка ММС для управления СОМ+ ≈ Службы компонентов (Component Services) доступна из меню Администрирование (Пуск | Программы | Администрирование | Службы компонентов).

В состав служб компонентов входит переработанный инструмент управления, реализованный в виде оснастки ММС, с помощью которого можно устанавливать пакеты MTS в СОМ+ (рис. 22.13). Ранее для этого применялись специальные инструменты MTS. Сразу после установки пакета можно использовать такие новые возможности СОМ+, как базы данных, хранящиеся в оперативной памяти (In-Memory DataBase, IMDB), или новая система поддержки событий.

Рис 22.13. Оснастка управления СОМ+ ≈ Службы компонентов (Component Services)

Другие службы Интернета в Windows 2000

Назначение и основные возможности. Служба индексирования (Indexing Service) ≈ служба, входящая в поставку Windows 2000 всех модификаций (включая настольную версию Professional), которая индексирует файлы на локальном жестком диске и на общедоступных дисководах в сети. Выполнять поиск можно по индексу слова в содержании файлов или в свойствах файлов. Служба индексирования возвращает список всех документов, которые соответствуют критериям поиска.

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

Служба индексирования может индексировать:

Файлы HTML
Текстовые файлы
Файлы Microsoft Office
Файлы почты Интернета
Любые другие файлы, для которых имеется фильтр документа

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

Полный просмотр

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

Инкрементный просмотр

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

Инкрементный просмотр также выполняется, если система теряет уведомления об изменениях. Это может случиться, если изменилось большое количество документов, и буфер Windows 2000, используемый для получения уведомлений об изменениях, переполняется. Инкрементный просмотр, так же как и полный просмотр, можно принудительно запустить в любое время.

Для каждого документа, который будет проиндексирован, служба индексирования выполняет следующие действия:

1. Используя соответствующий документу фильтр, считывает документ, извлекает из него значения свойств документа и выделяет содержание. Сохраняет значения свойств документа и путь к документу в индексе.
2. Разбивает поток предложений на отдельные слова. Для того чтобы разбить текст на слова, служба индексирования использует процедуры, соответствующие языку документа ≈ английскому, немецкому, японскому и т. д.
3. Удаляет незначащие слова ≈ предлоги, междометия, вспомогательные глаголы и т. д.
4. Сохраняет оставшиеся слова и путь к документу в индексе.
5. Сохраняет значения выбранных свойств документа в кэше свойств.

Фильтры ≈ программные компоненты, которые «понимают» структуру файла соответствующего типа, например, документа Microsoft Word или HTML. Фильтр извлекает содержание и значения свойств и посылает их ядру индексации.

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

Требования к конфигурации компьютера. Минимальная аппаратная конфигурация для службы индексирования ≈ та же, что и для самих систем Microsoft Windows 2000. Однако индексация и работа механизмов поиска зависят от количества и размера документов, которые будут проиндексированы, интенсивности поступления поисковых запросов и сложности запросов. На работу службы также влияет мощность компьютера. Компьютер с минимальной, аппаратной конфигурацией для Windows 2000 Server хорошо обрабатывает запросы, если число одновременных запросов не слишком высоко. Для маленькой организации этого может оказаться достаточно, но для большой организации, обслуживающей много пользователей, рекомендуется более мощная конфигурация (табл. 22.2).

Таблица 22.2. Рекомендуемые конфигурации компьютера, в зависимости от числа индексируемых документов

Число индексируемых документов Минимальный объем оперативной памяти (Мбайт) Рекомендуемый объем оперативной памяти; (Мбайт)
Менее 100000 64 64
От 100 000 до 250 000 64 От 64 до 128
От 250 000 до 500 000 64 От 128 до 256
500 000 и более 128 От 256

Если документов много, а памяти для работы службы не хватает, производительность системы может серьезно понизиться. Если компьютер при функционировании службы работает медленно, можно попробовать настроить производительность службы (см. ниже). Можно улучшить производительность службы и компьютера в целом, увеличивая объем оперативной памяти и увеличивая объем памяти, выделенный для кэша свойств (property cache). Более быстрый процессор увеличивает скорость индексации и обработки запросов.

Полный объем документов, которые будут проиндексированы, и тип файловой системы также влияют на объем дискового пространства, требуемого для хранения данных службы индексирования. В файловой системе FAT пространство, необходимое для каталога, плюс временное рабочее пространство, приблизительно равно 30% объема индексируемого текста. В файловой системе NTFS требуется пространство, приблизительно равное 15% объема индексируемого текста,

Управление службой. В предыдущих версиях (входивших в состав Option Pack для Windows NT Server 4.0 иди поставлявшихся отдельно) управлять службой индексирования можно было как при помощи оснастки, так и с использованием HTML Интерфейса. В Windows 2000 оставлена только возможность управления службой индексирования с использованием оснастки (рис. 22.14).

Рис 22.14. Оснастка управления службой индексирования

Для управления службой индексирования:

1. Запустите оснастку Управление компьютером.
2. В дереве консоли разверните узел Службы и приложения | Служба индексирования (Services and Applications | Indexing Service).

Настройка производительности службы индексирования:

1. Запустите оснастку управления службой индексирования.
2. В меню Действие (Action) выберите пункт Стоп (Stop).
3. В меню Действие выберите пункт Все задачи | Настройка производительности (All Tasks | Tune Performance).
4. В диалоговом окне Применение службы индексирования (Indexing Service Usage) выберите вариант, который наиболее соответствует способу использования службы индексирования на данном компьютере.
5. Если выбран вариант Особым образом (Customize), нажмите кнопку Настроить (Customize) и перейдите к следующему шагу. Если выбран другой вариант, перейдите к шагу 9.
6. В диалоговом окне Производительность индексации (Desired Performance) переместите ползунок Построение индекса (Indexing) в сторону Отложенное (Lazy) для менее интенсивного индексирования или в сторону Немедленное (Instant) для скорейшего индексирования новых и измененных документов. Отложенное индексирование использует меньшее количество ресурсов компьютера; а немедленное ≈ столько ресурсов, сколько возможно.
7. Переместите ползунок Скорость обработки запросов (Querying) в сторону Низкая (Low load), если ожидается обработка малого количества запросов одновременно, или Высокая (High load), если ожидается обработка большого количества запросов одновременно. Обработка с низкой скоростью использует меньшее количество ресурсов; с высокой ≈ большее.
8. Закройте диалоговое окно Производительность индексации.
9. Закройте диалоговое окно Применение службы индексирования и запустите службу индексирования, выполнив команду Пуск (Start) меню Действие (Action).

Поиск информации с помощью службы индексирования. При поиске информации запрос посылается службе индексирования. Служба индексирования, просматривая индекс, ищет документы, соответствующие критериям запроса, и возвращает список соответствующих запросу документов пользователю (или приложению, пославшему запрос).

В дополнение к запросу по содержанию можно сделать запрос по свойствам файлов. Эти свойства включают: размер файла, даты создания и изменения, имя файла, авторов файла и т. д. Можно, например, сделать запрос по текстовым свойствам (имя файла и автор) и числовым свойствам (размер и дата изменения). Можно также сделать запрос по всем свойствам элементов ActiveX, включая пользовательские свойства документов Microsoft Office.

Поиск можно выполнять тремя способами:

С помощью команды Найти | Файлы и палки (Search | Files and Folders) меню Пуск (Start)

Можно искать любое слово (фразу), вводя это слово (фразу) в диалоговом окне Поиск файлов и папок, вызванном командой меню Пуск | Найти (рис. 22.15).

Рис 22.15. Поиск информации при помощи команды Пуск | Найти | Файлы и папки

Используя веб-страницу для передачи запроса на выполнение через Internet Information Services

Для веб-доступа владелец или администратор узла создает веб-страницу (документ HTML), из которой можно посылать на выполнение запросы. Страница может быть настроена для упрощения ввода и улучшения вида запросов и поиска информации по различным критериям. Автор страницы может также задавать отдельные индексы или части индексов, по которым нужно производить поиск. Результаты поиска возвращаются в виде веб-страницы.

При помощи оснастки

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

1. Запустите оснастку Управление компьютером.
2. В дереве консоли разверните узлы Управление компьютером | Службы и приложения | Служба индексирования | Требуемый каталог (Опрос

каталога (Computer Management | Services and Applications [Indexing Service | Требуемый каталог \ Query the Catalog).

Форма запроса появится в правом подокне (рис. 22.16).

Рис 22.16. Поиск информации с использованием оснастки службы индексирования

Формы запросов. Служба индексирования поддерживает полную и краткую формы запросов. Запросы в полной форме создаются с использованием тэгов начала и окончания запроса, которые обозначаются фигурными скобками (<>). Тэги запроса служат для открытия и закрытия предложения запроса. Тэги запроса могут также включать уточняющие атрибуты или параметры.

Длинная форма и краткие запросы

Большинство операторов в языке запросов имеет полную форму и соответствующую краткую. Например, edocauthor ≈ краткое имя свойства Author, в то время как ≈ длинная форма.

Символы режима в кратких запросах

В кратких запросах следующие символы указывают режим (табл. 22;3).

Таблица 22.3. Режим запроса в краткой форме

Символ Режим
@ Запрос на поиск фразы (эквивалент )
# Запрос с регулярным выражением (эквивалент )
$ Свободно текстовый запрос (эквивалент )

Правила составления запросов. Имеются пять видов запросов:

Свободные текстовые запросы
Запросы-фразы
Запросы сопоставления с образцом
Относительные запросы
Векторно-пространственные запросы

Правила, относящиеся к запросам всех видов

  • В запросах не различаются строчные и прописные буквы.
  • Можно искать любое слово, если оно не содержится в списке исключений (рис. 22.17).
  • Для того чтобы использовать специальные символы в запросе (типа &, |, # и $), нужно заключить запрос в кавычки.
  • Значения даты и времени имеют одну из двух форм:

Первые два символа года и полного времени могут быть опущены. Если опускаются первые два символа года, дата интерпретируется как находящаяся в интервале между 1930 и 2029 гг. Трехзначное число миллисекунд может быть задано после секунд. Все даты и времена задаются в UTC (Universal Coordinated Time[ME1], Скоординированное всемирное время). Пример задания времени: 1993/11/7 12:04:23:123.

Рис 22.17. Список слов-исключений для американского английского языка
Дата и время относительно текущей даты и времени могут быть выражены со знаком «минус» (-), за которым следует одна или более пар «целое число-единица». Единицы задаются так: у ≈ число лет, q ≈ число кварталов (три месяца), m ≈ число месяцев, w ≈ число недель, d ≈ число дней, h ≈ число часов, п ≈ число минут и s ≈ число секунд. Числовые значения могут быть заданы в десятичном или в шестнадцатеричном виде. Шестнадцатеричные значения предваряются символами «Ох».

Оператор contains. Для поиска слова или фразы в заданном свойстве можно использовать оператор contains. Если оператор не задан, по умолчанию считается заданным оператор contains. Следующие запросы эквивалентны:

@DocTitle «Что-то важное»

@DocTitle CONTAINS «Что-то важное»

Булевы операторы. Можно использовать булевы операторы and, or и мот как в запросах на вхождение в содержимое, так и в запросах по свойствам. Оператор near может применяться только в запросах по содержимому документов. Операторы в запросах могут быть записаны как в полной, так и в краткой форме (табл. 22.4).

Таблица 22.4. Полная и краткая формы операторов

Оператор Длинная форма Краткая форма
AND AND &
OR OR I
NOT AND NOT &!
NEAR NEAR Near,
∙ Булевы операторы доступны только в английском написании.
∙ Булевы операторы рассматриваются в следующем порядке : not, and и NEAR, OR.

Текстовые запросы. Для свободных текстовых запросов можно указывать группу слов или законченное предложение. Служба индексирования находит документы, которые лучше всего соответствуют словам и фразам в свободно текстовом запросе. Булевы операторы и подстановочные символы в таком запросе игнорируются.

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

Запросы сопоставления с образцом. Для запросов сопоставления с образцом служба индексирования выбирает документы, соответствующие образцу, который задается пользователем.

В такого рода запросах используются маски (wildcards), запросы, задающие словоформы, регулярные выражения и операторы отношений.

Относительные запросы. В таких запросах для поиска документов, свойства которых лежат в некотором диапазоне, можно использовать операторы отношения: больше, меньше, равно, не равно и т. п.

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

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

Примеры запросов. В табл. 22.5 приведены примеры разнообразных запросов.

Таблица 22.5. Примеры запросов

Документы, измененные после 18 июля 1999 года, в11:05ло1ЯС

Чтобы найти Полная форма Краткая форма Результат
Заданное значение = Иван Иванов @DocAuthor = Иван Иванов Документы, созданные Иваном Ивановым
Значение, начинающееся с заданного префикса <гедех>Иван * Документы, чье свойство «автор» начинается с «Иван»
Файлы с расширением из числа заданных < regex >* . | (doc | , txt | , wri | ) < /regex > < /prop > #filename *. | (doc|, txt |, wri| ) Файлы с расширениями doc, txt или wri
Документы, измененные после некоторой даты > 99/7/18 11:05:00 @write > 99/7/18 11:05:00
Документы, измененные после относительной даты > -2d4h @write > -2d4h Документы, измененные в пределах последних 52 часов

Службы очереди сообщений

Службы очереди сообщений (Microsoft Message Queuing Services, MSMQ) ≈ сервис, входящий в стандартную поставку Microsoft Windows 2000 Server. С помощью MSMQ приложения, работающие в разное время, могут связываться через разнородные сети и системы, способные временно работать автономно. Приложения посылают сообщения MSMQ и используют очереди MSMQ ≈ это позволяет быть уверенным, что сообщение рано или поздно достигнет адресата. MSMQ обеспечивает гарантированную доставку сообщений, интеллектуальную маршрутизацию, защиту и передачу сообщений, основанную на приоритетах.

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

Программные продукты с такими возможностями часто называют программным обеспечением поддержки очередей сообщений, программным обеспечением с промежуточным накоплением или средствами среднего уровня, ориентированными на сообщения (MOM, Message-Oriented Middleware).

Особенности и возможности службы MSMQ: .

Интеграция с Windows 2000 Server. Поддерживается служба Active Directory, в которой хранятся отдельные объекты MSMQ.
Работа в смешанном режиме. MSMQ может функционировать в смешанных сетевых средах, состоящих из серверов и клиентов на базе как Windows NT 4.0, так и Windows 2000.
Совместимость сверху вниз. Служба MSMQ полностью совместима с MSMQ версии 1.0.
Передача сообщений без установления логического соединения. Поскольку MSMQ использует бессеансовую модель на прикладном уровне, отправитель и получатель не обязаны применять один и тот же протокол. MSMQ поддерживает протоколы IP и IPX.
Поддержка приоритетов трафика. Приоритеты сообщений позволяют срочному или важному трафику вытеснять менее важный, что гарантирует адекватное время ответа критическим приложениям за счет менее важных приложений.
Гарантированная доставка. Сообщения помещаются в хранящуюся на диске очередь, что обеспечивает гарантированную доставку сообщений.
Транзакции. Имеется возможность использования транзакций MSMQ, т. е. можно объединить несколько действий MSMQ в транзакцию и обеспечить гарантированную доставку сообщений, а также то, что они будут доставлены не более одного раза или что доставленные сообщения будут успешно извлечены из очереди адресатом.
Динамические очереди. Администраторы могут изменять свойства очередей без воздействия на приложения передачи сообщений.
Маршрутизация. MSMQ поддерживает интеллектуальную маршрутизацию, которая основана на физической топологии сети, группировке сеансов и на обеспечении транспортной связности. Группировка сеансов облегчает эффективное использование медленных линий.
Безопасность. MSMQ поддерживает механизмы безопасности: управление доступом, аудит, шифрование и аутентификацию. Управление доступом реализовано с применением системы безопасности Windows 2000 и цифровых подписей. Аудит реализован при помощи службы регистрации событий Windows 2000. Шифрование и аутентификация (использование цифровых подписей) обеспечиваются при помощи механизмов открытых и закрытых ключей.
Широкая интеграция систем. Приложения MSMQ могут выполняться на целом ряде аппаратных платформ, использующих продукты для обеспечения связи со службой MSMQ, поставляемые фирмой Level 8 Systems, партнером Microsoft, Исходно MSMQ поддерживает Windows NT, Windows 95 и Windows 98. Поддержка остальных систем поставляется фирмой Level 8 Systems.
Среда программирования MSMQ.. Прикладной интерфейс MSMQ позволяет разрабатывать приложения MSMQ на языке С или C++. MSMQ также включает элементы управления СОМ, которые можно применять для создания приложений MSMQ в Microsoft Visual Java (VJ), Visual Basic (VB) или любых других приложений-контейнеров СОМ (например, Microsoft Access или Borland/Inprise Delphi). При помощи Microsoft ASP и Microsoft US можно интегрировать MSMQ-приложение с веб-страницами и формами, использующими элементы управления СОМ. При помощи MAPI Transport Provider и Exchange Connector можно интегрировать приложение MSMQ с формами Exchange и клиентами MAPI. Транспорт MSMQ

RPC можно использовать для создания надежных приложений, использующих вызовы RPC.

Установка MSMQ. Чтобы добавить или удалить службу:

1. В меню Пуск (Start) выберите команду Настройка (Settings) | Панель управления (Control panel) | Установка/удаление программ (Add/Remove Programs).
2. В левой панели диалогового окна Установка/удаление программ выберите вкладку Добавление/удаление компонентов Windows.
3. Откроется окно Мастер компонентов Windows (Windows Components Wizard). В списке Компоненты Windows (Windows Components) выберите опцию Службы очереди сообщений (Message Queuing Services) (рис. 22.18).
4. Нажмите кнопку Далее (Next) и следуйте командам мастера.

Рис 22.18. Установка служб очереди сообщений

Сначала нужно установить сервер MSMQ на контроллере домена Windows 2000 (в группе серверов, объединенных территориально), а затем можно устанавливать программное обеспечение MSMQ на других компьютерах. Сервер MSMQ не может быть установлен на компьютерах, работающих под управлением Windows 2000 Professional.

Служба MSMQ в Windows NT 4.0 и Windows 2000. Перечислим общие задачи управления службой MSMQ. Интерфейс пользователя для выполнения этих задач отличается в Windows 2000 от интерфейса в Windows NT 4.0.

В табл. 22.6 перечислены отличия в терминологии и в архитектуре предыдущих версий от текущей версии MSMQ.

Таблица 22.6. Управление службой MSMQ в Windows 2000 и в Windows NT 4.0

Необходимое действие Windows NT 4.0 Windows 2000
Управление доступом, установка аудита или изменение владельца для Message Queuing MSMQ Explorer Оснастка Active Directory- пользователи и компьютеры (Active Directory Users and Computers)
Изменение учетной записи для службы MSMQ Значок Services на панели управления Оснастка Управление компьютером (Computer Management)
Настройка параметров маршрутизации MSMQ Explorer Оснастка Active Directory — пользователи и компьютеры
Создание внешних (foreign) узлов или добавление внешних компьютеров MSMQ Explorer Оснастка Active Directory-пользователи и компьютеры
Добавление, удаление и настройка компьютеров MSMQ; установка квот для компьютеров или изменение свойств MSMQ Explorer Оснастка Active Directory — пользователи и компьютеры
Установка параметров IPX/SPX для компьютеров MSMQ Значок Network на панели управления Значок Сеть и удаленный доступ к сети (Network arid Dialup Connections) на панели управления
Создание, удаление и настройка очередей; установка квот очереди или изменение свойств MSMQ Explorer Оснастка Active Directory — пользователи и компьютеры
Просмотр и удаление сообщений; просмотр свойств сообщений MSMQ Explorer Оснастка Active Directory — пользователи и компьютеры

Управление службой MSMQ. Управление MSMQ на локальном компьютере осуществляется при помощи оснастки Управление компьютером ≈ узел Службы и приложения | Очередь сообщений. Основное управление объектами MSMQ в организации осуществляется с применением оснастки Active Directory ≈ пользователи и компьютеры. Для управления MSMQ в организации:

1. Запустите оснастку Active Directory ≈ пользователи и компьютеры.
2. В дереве консоли разверните узел Active Directory ≈ пользователи и компьютеры.
3. В меню Вид (View) выберите пункт Пользователи, группы и компьютеры как контейнеры (Users, Groups and Computers as Containers), а затем в том же меню выберите пункт Дополнительные функции (Advanced Features).
4. В дереве консоли найдите нужный домен, затем подразделение, наконец нужный компьютер, на котором установлена MSMQ, щелкните правой кнопкой мыши на узле msmq и в контекстном меню выберите пункт Свойства (Properties).

Службы Windows Media

Службы Windows Media в составе Microsoft Windows 2000 ≈ это группа служб, которые предназначены для передачи клиентам аудио- и видеоинформации при помощи одноадресного и группового вещания. Службы Windows Media используются также для передачи файлов клиентам. Поставляемое содержимое может быть создано, приобретено у поставщика или передаваться с телевизионных камер и микрофонов. В последнем случае его называют живым потоком (live stream).

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

На рис. 22.20 будет представлена схема, которая иллюстрирует общую технологию доставки клиентам файлов типа Advanced Streaming File (ASF, Усовершенствованный потоковый файл).

Как показано на схеме, для создания содержимого файлов ASF применяются средства Media Services ≈ Windows Media Author, VidToASF и WavToASF.

Для передачи живого потока можно использовать Кодировщик Windows Media (Windows Media Encoder) вместе с видеокамерой и микрофоном, чтобы кодировать содержимое в поток ASF, который службы Windows Media могут передавать пользователям. Кодировщик также может записывать поток ASF, который он кодирует в файл ASF для дальнейшего воспроизведения.

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

Новые возможности. Потоковые мультимедийные службы в составе Microsoft Windows 2000 предоставляют многочисленные новые возможности для доставки потокового аудио- и видео-содержимого:

Улучшенное качество
Расширенный набор серверных компонентов
Программное обеспечение для кодирования информации
Большее количество инструментов
Поддержка в Проигрывателе Windows Media (Windows Media Player)
Большее количество сервисных возможностей

Состав служб Windows Media. Службы Windows Media собтоят из служб-компонентов и административной утилиты ≈ Администратор Windows Media (Windows Media Administrator).

Службы Windows Media. Windows Media ≈ набор служб, работающих под управлением Microsoft Windows 2000 Server. Эти службы предназначены для передачи звуковой и видеоинформации при помощи одноадресного и группового вещания клиентам.
Администратор Windows Media. Администратор Windows Media ≈ набор веб-страниц, который функционирует в окне браузера Microsoft Internet Explorer версии 5.0 и управляет службами-компонентами Windows Media. При помощи администратора Windows Media можно управлять локальным сервером или одними или несколькими удаленными серверами Windows Media. Чтобы управлять несколькими серверами, нужно добавить серверы в список серверов, а затем соединиться с сервером, которым не обходимо управлять.

Администратор Windows Media (рис. 22.19) может функционировать (помимо Windows 2000) на Microsoft Windows 98 или Microsoft Windows NT 4.0 с установленными Service Pack 4 (SP4) и Microsoft Internet Explorer 5.0. Администратор Windows Media также работает и с Internet Explorer 4.01 или под Microsoft Windows 95, но эти платформы официально не поддерживаются.

Вот основные процедуры, которые обычно выполняются при работе с Администратором Windows Media:

Чтобы запустить Администратор Windows Media:

Нажмите кнопку Пуск (Start) и выберите команду Программы | Администрирование | Windows Media (Programs | Administrative Tools | Windows Media).

Чтобы соединиться с сервером Windows Media:

В окне Администратор Windows Media в списке выберите сервер, который необходимо администрировать.

Если сервер, который нужно администрировать, не виден в списке серверов или список серверов вообще пуст, необходимо добавить сервер в список сервeров.
Чтобы добавить сервер к списку серверов:

В окне Администратор Windows Media нажмите кнопку Добавить сервер

(Add Server), а затем введите имя сервера в поле Сервер (Server).

Чтобы удалить сервер из списка серверов:

Выберите имя сервера в списке и нажмите кнопку Удалить сервер (Remove Server). Администратор Windows Media отключается от сервера, а имя сервера удаляется из списка серверов.

Рис 22.19. Администратор Windows Media

Клиентское программное обеспечение. Программный клиент, получающий данные с сервера Windows Media, называется Проигрыватель Windows Media (Windows Media Player) (рис. 22.20). Службы Windows Media используют Проигрыватель Windows Media, чтобы воспроизводить потоки ASP, которые могут включать видеоинформацию, звук, изображения, URL и сценарии.

Средства Windows Media. Следующие инструменты и утилиты предназначены для служб Windows Media, чтобы создавать и модифицировать данные, которые публикуются при помощи сервера Windows Media:

Кодировщик Windows Media (Windows Media Encoder) ≈ средство, которое может преобразовывать как «живую», так и сохраненную звуковую и видео — информацию в поток ASF, который передается при помощи сервера Windows Media. Для добавления специальных возможностей к потоку данных можно использовать язык сценариев. Команды сценария позволяют выполнить синхронный переход к заданному веб-узлу, отображение и пролистывание страниц, предоставить оценочную информацию или создать сообщение электронной почты. Как только поток создан, он может быть записан в файл *.asf для дальнейшего проигрывания:
Windows Media Author ≈ инструмент, разработанный Microsoft совместно с компанией Digital Renaissance, Inc. Этот инструмент служит для трансляции, синхронизации и сжатия звуковых данных и картинок в единый файл *.asf. Информация Windows Media, которая создается при помощи этого инструмента, называется иллюстрированным звуком, поскольку содержит слайды, связанные со звуковой дорожкой. Windows Media Author также может добавлять команды сценариев и URL к файлам *.asf.
Windows Media ASF Indexer ≈ инструмент, который редактирует время начала и остановки файлов *.asf и индексирует их. Он также служит для создания маркеров, свойств и команд сценариев для файла *.asf.
VidToAsfu WavToAsf≈ утилиты преобразования, работающие из командной строки сервера. Служат для конвертирования существующих аудио-и видеофайлов в формат ASF.

Рис 22.20. Проигрыватель Windows Media в качестве клиента служб Windows Media

ASFCheck ASFChop и ASX3TEST — файловые утилиты, работающие из командной строки на сервере. ASFCheck служит для проверки формата файла *.asf и восстановления файла, если это возможно. С помощью ASFChop можно добавить свойства, маркеры, индексы и команды сценариев к файлу *.asf и удалять отрезки времени из файла *.asf. С помощью ASX3Test можно проверить синтаксис файла *.asx, созданного в текстовом редакторе.

Форматы. Службы Windows Media предоставляют возможность доставки мультимедийной информации большому количеству клиентов, использующих форматы ASF, WMA и WAV.

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

Службы Windows Media используют формат ASF ≈ открытый стандарт, который поддерживает доставку данных поверх многих сетей и протоколов. ASF служит для упорядочения* организации и синхронизации мультимедиа-данных для передачи при помощи потока по сети. ASF ≈ формат файлов; однако он может также обеспечить передачу живой трансляции. Формат ASF оптимизирован для передачи потоков мультимедиа по сетям, но oн подходит и для хранения записей.

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

Звуковой файл Windows Media, имеющий расщирение wma, является файлом *.asf, содержащим только звук, сжатий при помощи Micresoft Audio Codec. Этот тип отличается от файлов *.asf только по расширению. Сервер Windows Media может передавать файлы * .wma. Можно публиковать файлы *.wma при помощи файлов *.wax с использованием диспетчера программ. Компания Microsoft создала файлы *.wma для пользователей, которые могут проигрывать только звук.

Предоставление данных по требованию

Это один из способов, при помощи которых пользователь может получать потоковую информацию с сервера Windows Media. Coединение по требованию — активное соединение между клиентом и сервером При соединении по требованию пользователь инициализирует клиентское соединение с сервером, выбирая соответствующий ресурс. Содержание передается с сервера клиенту в потоке ASF. Если файл индексирован, пользователь может запустить, остановить, перемотать назад или вперед или приостановить поток. Соединения по требованию предоставляют большие возможности по управлению потоком, но они могут быстро исчерпать полосу пропускания сети, поскольку каждый клиент устанавливает свое собственное соединение с сервером.

Протоколы. На рис. 22.21 представлена диаграмма использования протоколов для организации взаимодействия между компонентами системы Windows Media.

Рис 22.21. Протоколы передачи потоков мультимедийных данных

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

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

Протокол MMS

Протокол MMS (Microsoft Media Stream) предназначен для обращения к одноадресным ресурсам Windows Media. MMS используется по умолчанию для соединения с одноадресными службами Windows Media. Вводя в программе Проигрыватель Windows Media URL-адрес ресурса, к которому необходимо присоединиться, нужно указать протокол MMS и ссылку на нужный поток. При соединении с точкой публикации (publishing point) по протоколу MMS для выбора оптимального соединения используется просмотр (rollover) протоколов. Просмотр протоколов начинается с попытки установления соединения с сервером через MMSU. MMSU — протокол MMS, объединенный с UDP-транспортом данных. Если соединение MMSU потерпело неудачу, сервер пытается использовать MMST. MMST — протокол MMS, объединенный с TCP-транспортом данных.

Если при воспроизведении (проигрывании) индексированного файла *.asf требуются возможности ускоренной перемотки вперед, перемотки, паузы, запуска и остановки потока, необходимо применять протокол MMS. Ускоренная перемотка вперед и назад при использовании UNC-пугей недоступна. Когда устанавливается соединение с точкой публикации при помощи автономного проигрывателя Windows Media, нужно определить URL, указывающий на источник потока: rams: //Mediaserver/exantple.asf

где Mediаserver≈ имя сервера Windows Media, a example.asf≈ имя файла *.asf, который требуется проиграть.

Протокол MSBD

Протокол MSBD служит для распределения потоков между кодировщиком Windows Media и компонентами сервера Windows Media и передачи потоков между серверами. MSBD ≈ ориентированный на соединение протокол, оптимизированный для использования с потоками данных. MSBD нужен при испытании соединения между клиентом и сервером и для проверки качества потока ASF, но он не должен применяться в качестве основного метода приема данных ASF. Кодировщик Windows Media может поддерживать максимум 15 клиентов MSBD; сервер Windows Media может поддерживать максимум 5 клиентов MSBD.

Протокол HTTP

Если нужно передавать поток данных через брандмауэр (межсетевой экран) или другой фильтр трафика, который разрешает передачу только протокола HTTP, можно передавать потоковые данные по этому протоколу. Потоковый HTTP можно использовать для передачи потока от Кодировщика Windows Media до межсетевого фильтра на сервер Windows Media, а также чтобы подключаться к серверам Windows Media, которые отделены брандмауэром.

Применение потокового HTTP. Потоковый HTTP полезен для доставки потока через устройства обеспечения безопасности сети, поскольку потоковый HTTP обычно использует порт 80, а большинство брандмауэров не запрещает это. Компоненты сервера Windows Media по умолчанию настроены для применения потокового протокола MMS. Однако можно настроить компоненты сервера Windows Media, чтобы вместо MMS использовать потоковый HTTP. Потоковый HTTP ≈ рекомендуемый вариант передачи потокового содержимого ASF через сетевые экраны.

В состав компонентов сервера Windows Media включены два типа служб ≈ Одноадресная служба Windows Media (Windows Media Unicast Service) и Служба станции Windows Media (Windows Media Station Service). Следует выбрать, какой из компонентов сервера Windows Media будет использовать потоковый HTTP, поскольку оба они не могут одновременно работать с потоковым HTTP, т. к. не могут быть связаны с одним портом. Одноадресная служба Windows Media по умолчанию связана с портом 1755, а служба станции Windows Media ≈ с портом 7007.

Чтобы редактировать порт, который служба использует для потокового HTTP:

1. Запустите редактор системного реестра.
2. В окне редактора реестра с помощью дерева реестра разверните ключ:
3. Выберите ключ HTTPPort и дважды щелкните левой кнопкой мыши. Откроется окно Изменение параметра DWORD (DWORD Editor).
4. Выберите опцию Десятичная (Decimal). Данные в поле должны быть равны 80.
5. Введите нужный номер порта для потокового протокола HTTP.

Изменение порта, с которым связана служба HTTP. Служба HTTP в IIS по умолчанию связана с портом 80. Если компоненты сервера Windows Media работают совместно на компьютере, на котором установлена веб-служба, и для Windows Media разрешена поддержка потокового HTTP, то такое совместное использование веб-сервера и Windows Media может привести к конфликту при привязке обеих служб к TCP-порту 80.

Изменение порта, к которому привязана служба HTTP, может разрешить конфликты портов, но также может привести к некорректной работе службы HTTP. Большинство входящих соединений по протоколу HTTP происходит через порт 80. Если порт 80 невозможно использовать, то клиентский браузер покажет сообщение об ошибке, что приведет к невозможности просмотра содержимого веб-сервера.

Для изменения порта; выделенного службе Windows Media для потокового HTTP:

1. Запустите редактор системного реестра.
2. В окне редактора реестра с помощью дерева реестра разверните ключ: HKEY_mCAL_MACHINE\System\CurrentControlSet\Services\nsstatipn \Parameters\
3. Выберите ключ HTTPPort и выполните двойной щелчок. Откроется окно Изменение параметра DWORD (DWORD Editor).
4. Выберите опцию Десятичная (Decimal). Поле данных должно содержать число 80.
5. Введите нужный номер порта для потокового HTTP.
Право на внесение изменений в системном реестре при помощи редактора системного реестра зависит от разрешений доступа. Неправильное редактиррг вание системного реестра может нарушить работоспособность системы. Перед внесением изменений в системном реестре сделайте резервные копии всех ценных данных на этом компьютере.

Работа служб Windows Media и IIS на одном сервере. Компоненты сервера Windows Media и службы Microsoft Internet Information Services (IIS) могут сосуществовать на компьютере, когда используются значения по умолчанию по привязке к портам (одноадресная служба Windows Media связана с портом 1755, служба станции Windows Media ≈ с портом 7007, a IIS ≈ с портом 80).

Одноадресная служба Windows Media и служба станции Windows Media должны иметь доступные IP-адреса со свободным портом 80 для передачи потоковых данных ASF через протокол HTTP. Чтобы использовать потоковый HTTP, когда компоненты сервера Windows Media и IIS установлены на том же самом компьютере, требуются следующие условия:

По крайней мере два IP-адрееа, связанных с сетевой платой
Уникальная ресурсная запись типа А на сервере DNS для IP-адреса сервера Windows Media и IP-адреса сервера IIS

Чтобы разрешить потоковый протокол HTTP для компонентов сервера, которые работают на том же компьютере, что и IIS:

1. Назначьте IP-адрес веб-узлу в IIS:
2. Разрешите протокол потоковый HTTP для компонентов сервера Windows Media. Можете разрешить потоковый HTTP для одноадреснрй службы либо для службы группового вещания.
3. Отредактируйте системный реестр, чтобы службы компонентов Windows Media зависели от службы веб-публикации.

Чтобы назначить IP-адрес веб-узлу в IIS:

1. В окне оснастки управления IIS выберите компьютер, на котором установлены службы Windows Media.
2. В контекстном меню узла Веб-узел по умолчанию (Default Web site) выберите пункт Свойства (Properties). Откроется диалоговое окно свойств.
3. Перейдите на вкладку Веб-сайт (Web site).
4. На вкладке в поле IP-адрес (IP address) введите значение IP-адреса, которое должен использовать IIS.
5. Повторите шаги 2 до 4 для любых дополнительных веб-узлов, которые установлены в IIS, включая административный узел.

Чтобы отредактировать системный реестр так, чтобы одноадресная служба Windows Media или служба станции Windows Media зависели (запускались после другой службы) от веб-сервера:

1. Запустите редактор системного реестра.
2. Чтобы изменить настройки одноадресной службы Windows Media, в окне редактора реестра с помощью дерева реестра разверните ключ:

Или, чтобы изменить настройки службы станции Windows Media, в окне редактора реестра с помощью дерева реестра разверните ключ:

3. Дважды щелкните на ключе DependOnService. Откроется окно многострочного редактора,
4. В конце списка служб введите vosvc. vbsvc ≈ установка, которая делает компоненты сервера Windows Media зависящими от сервера IIS.
5. Перезапустите компьютер.

Определение типа MIME для служб Windows Media в IIS. На веб-сервере должны быть заданы типы MIME (Multipurpose Internet Mail Extensions), чтобы сервер имел информацию о том, что делать в случае получения запроса на доступ к ресурсу с неизвестным расширением файла, например asf и asx. Без этой записи веб-сервер не сможет интерпретировать файл.

Лекция 1. Что такое ASP.NET. Инсталляция и тестовый проект.

Введение

Microsoft .NET Framework — это платформа для создания, развертывания и запуска Web-сервисов и приложений. Она предоставляет высокопроизводительную, основанную на стандартах, многоязыковую среду, которая позволяет интегрировать существующие приложения с приложениями и сервисами следующего поколения, а также решать задачи развертывания и использования интернет-приложений. .NET Framework состоит из трех основных частей — общеязыковой среды выполнения (common language runtime), иерархического множества унифицированных библиотек классов и компонентной версии ASP, называемую ASP.NET.

ASP.NET – это часть технологии .NET, используемая для написания мощных клиент-серверных интернет приложений. Она позволяет создавать динамические страницы HTML. ASP.NET возникла в результате объединения более старой технологии ASP (активные серверные страницы) и .NET Framework. Она содержит множество готовых элементов управления, используя которые можно быстро создавать интерактивные web-сайты. Вы также можете использовать сервисы, предоставляемые другими сайтами, прозрачно для пользователей вашего сайта. В общем, возможности ASP.NET ограничены только вашим воображением.

Давайте обсудим, что такое динамические страницы HTML и чем они отличаются от статических. Статическая страница содержит код на языке гипертекстовой разметки HTML. Когда автор страницы пишет ее, он определяет, как будет выглядеть страница для всех пользователей страницы. Содержание страницы будет всегда одинаковым независимо от того, кто и когда решит ее просмотреть. Языка HTML вполне достаточно для отображения информации, которая редко изменяется и не зависит от того, кто ее просматривает. Страница HTML — простой ASCII-текст, следовательно, клиент может работать в любой операционной системе.

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

Но что, если мы хотим отобразить на странице текущий курс евро или прогноз погоды? Если мы написали страницу HTML вчера, сегодня она уже устареет. Следовательно, мы должны уметь создавать динамические страницы. Динамическое наполнение страницы – это информация, содержание которой определяется тем, кому она предназначена, и которая отличается от просмотра к просмотру. Оно позволяет обеспечить двусторонний обмен информацией – от клиента к серверу и обратно.

Динамическими принято называть web-страницы, которые перед отправкой клиенту проходят цикл обработки на сервере. В самом простом случае это может быть некоторая программа, которая модифицирует запрашиваемые клиентом статические страницы, используя параметры полученного запроса и некоторое хранилище данных. Даже при такой примитивной организации «неразрешимая» задача из предыдущего абзаца обретает очевидное решение: достаточно подготовить всего одну статическую страницу – шаблон – и перед отправкой страницы программно подставлять в него значение, полученное сегодня из банка или метеобюро.

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

Существуют языки, способные динамически изменять содержимое веб-страницы. С одной стороны, это языки скриптов, выполняющиеся непосредственно у клиента. Примеры скриптовых языков — JavaScript и VBScript. Скрипты на этих языках встроены в код HTML, который сервер посылает браузеру. Сценарии, выполняемые на стороне клиента, выделяются тегами и . Браузер интерпретирует этот код и показывает пользователю результат. Сам код можно просмотреть через View Source браузера. Естественно, эти программы не могут быть большими. Например, если нужно выполнить поиск в базе данных, мы не может отправить пользователю все ее содержимое. Но скрипты могут проверить правильность запроса, введенного в форму, тогда не придется перезагружать сервер обработкой неправильных запросов. Некоторые программисты создают на JavaScript анимационные эффекты. Одна студентка intuit.ru желала найти скрипт, который бы отправлял SMS-сообщения. Увы, это невозможно. Выполняемых на стороне клиента сценариев недостаточно для создания полноценных динамических страниц. Даже если на странице используется JavaScript, анимированные картинки .gif, она называется статической.

Динамическая веб-странице должна быть создана «на лету» программой, исполняющейся на интернет-сервере. Широко применяются механизм шлюзов CGI(Common Gateway Interface). Вначале пользователь получает статическую страницу с формой. Вам известно, что в теге FORM существует атрибут ACTION. Именно он задает адрес (URL) исполняемого приложения. На сервере находятся исполняемые файлы программ, написанных, например на C/С++ или Дельфи, которые по протоколу HTTP принимают данные из входного потока или из переменных окружения и записывают в стандартный выходной поток готовую страницу.

Пользователю в ответ на запрос посылается HTML код, который был специально сгенерирован для него. Это может быть, например, результат поиска в поисковой системе. CGI -скрипты могут быть написаны на интерпретируемом языке (Perl) или даже скрипте командной строки. Входной и выходной потоки переназначаются. На вход интернет-сервер принимает данные, введенные пользователем. После обработки полученных данных, пользователю возвращается результирующая страница. При исполнении cgi-программа загружается в память сервера, а при завершении – удаляется. Когда 100 клиентов одновременно обращаются к серверу, в памяти создаются 100 процессов, для размещения кода каждого из которых нужна память. Это отрицательно сказывается на масштабируемости. Напомним, что масштабируемость — это возможность плавного роста времени ответа программной системы на запрос с ростом числа одновременно работающих пользователей.

Для решения это проблемы Microsoft была предложена альтернатива – ISAPI(Internet Server Application Programming Interface)-расширения и фильтры. Вместо исполняемых файлов используются DLL – библиотеки. Код DLL находится в памяти все время и для каждого запроса создает не процессы, а нити исполнения. Все нити используют один и тот же программный код. ISAPI –приложение выполняется в процессе IIS-сервера. Это позволяет повысить производительность и масштабируемость.

ISAPI-расширения можно создавать в Visual Studio C++ 6.0, пользуясь мастером.

У ISAPI тоже есть недостатки, относящиеся к разработке. Если мы меняем исходный код dll, мы должны его откомпилировать и поместить в исполняемую директорию сервера. Но так как предыдущий вариант dll находится в памяти, необходимо остановить сервер, чтобы получить доступ на изменение файла. В это время клиенты не смогут получить в сервера ни один документ, и, конечно, будут не удовлетворены.

Скриптовые языки, исполняющиеся на стороне сервера – php и asp. Технология asp была разработана Microsoft в 90-х годах.

Выполнение кода asp поддерживается ISAPI-расширением сервера. В диалоге конфигурации сервера IIS определяются способы обработки файлов с различными расширениями. Для обработки URL-адреса с расширением в установках сервера определен файл asp.dll. Файлы asp отправляются к нему на обработку. На вход поступает asp, а на выходе имеем поток HTML-кода.

Пример файла asp:

Тег сигнализирует asp, что в нем находится код, который он должен обрабатывать на сервере. Выполняется скрипт на языке, который указан в директиве Language. Оператор Response.Write записывает текст в выходной поток сервера, таким образом, он становится частью HTML-страницы, отправленной пользователю.

Технология asp была ограничена по своим возможностям. Он использовал скриптовые языки, которые имеют меньше возможностей, чем полнофункциональные языки программирования. Код asp был встроен в HTML в виде специальных тегов, что создавало путаницу. Кусочки asp были разбросаны по нему, как изюм в булке. Но HTML код обычно создают дизайнеры, которые умеют «делать красиво», а asp – программисты, которые заставляют все это работать. В ASP.NET вы можете держать код asp и HTML в разных файлах.

Скриптовые языки не поддерживают строгую типизацию. Что это значит? Вы можете не описывать переменную до ее использования и можете присваивать ей значения разных типов. Это удобно, но создает почву для ошибок. Например, у вас есть переменная x1, и вы присваиваете ей значение 1, но вы сделали опечатку и по ошибке написали x2=1. Будет создана новая переменная x2, а значение x1 не изменится. В языке со строгой типизацией компилятор заметит, что переменная x2 не описывалась, и выдаст ошибку.

В 2000 году на конференции разработчиков в качестве части новой технологии .NET Microsoft представила ASP+. С выходом .NET Framework 1.0 она стала называться ASP.NET.

ASP.NET — это не продолжение ASP. Это концептуально новая технология Microsoft, созданная в рамках идеологии .NET. В ASP.NET заложено все, для того, чтобы сделать весь цикл разработки веб-приложения более быстрым, а поддержку более простой. ASP.NET основана на объектно-ориентированной технологии, но сохранила модель разработки asp: вы создаете программу и помещаете ее в директорию, выделенную сервером, и она будет работать. В ASP.NET появилось много новых функций, а существовавшие в asp значительно усовершенствованы.

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

Компиляция происходит на сервере в момент первого обращения пользователя к странице. Если программист изменил текст страницы, программа перекомпилируется автоматически. При написании кода можно использовать набор компонентов, поставляемых с .NET.

Платформа .NET Framework предоставляет приложениям среду выполнения, сама непосредственно взаимодействуя с операционной системой. Выше лежит интерфейс ASP.NET приложений, на котором в свою очередь базируются веб-формы (ASP.NET страницы) и веб-сервисы. Интерфейс .NET Framework позволяет стандартизировать обращение к системным вызовам и предоставляет среду для более быстрой и удобной разработки. CLR обеспечивает единый набор сервисов для всех языков.

ASP.NET использует технологию доступа к данным ADO.NET, которая обеспечивает единый интерфейс для доступа к базам данных SQL Server и файлам XML. Кроме того, усиленная модель безопасности позволяет обеспечивать защиту клиента и сервера от несанкционированного доступа.

В 2004 году появилась версия ASP.NET 2.0(бета-версия, окончательный выход – конец 2005-начало 2006). Как утверждается, эта версия позволяет сократить объем кодирования на 70%. Новые возможности версии 2.0 – например, использование шаблонов дизайна страниц(Master Page), упрощенная локализация Web-приложений, более 50 новых серверных элементов управления. Цели, которые преследовали разработчики новой версии – повысить скорость разработки сайтов, масштабируемость, легкость поддержки и администрирования сайтов, скорость работы сервера. Появилась панель остнастки MMC (консоль управления Microsoft), предоставляющая графический интерфейс для управления настройками ASP.NET. Изменять настройки проекта теперь можно и через web-интерфейс. ASP.NET 2.0 поддерживает работу на 64-битных процессорах. Сервис персонализации (personalization) предоставляет готовое решение для хранения персональных данных, непосредственно характеризующих пользователя сайта, так называемого профиля пользователя (Profile).

Шаблоны дизайна, темы и скины позволяют независимо дизайн всего сайта отдельно от его функциональности, темы включают графику и каскадные таблицы стилей.

Предыдущие версии Visual Studio для проектов ASP.NET требовали наличия на машине разработчика сервера IIS. Теперь сервер встроен в среду разработки.

ASP.NET 2.0 и Visual Studio 2005 предоставляют инструменты для легкого построения локализируемых сайтов, которые определяют предпочитаемый язык пользователя и посылают ему страницы на его языке.

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

В ASP.NET 2.0 встроена технология автоматического обновления кэширования баз данных. Данные, полученные из базы, хранятся на сервере и он не обращается к базе для обработки повторного запроса. При изменении базы данных кэш обновляет свое содержимое.

ASP.NET — это технология, а не язык, и позволяет программировать на разных языках – С#, Visual Basic, J#. В платформе .NET все языки равны, но некоторые равнее(Дж. Оруэлл). Вот таким языком и является С#, потому что он был специально создан для этой платформы. Программирование C# позволяет в полной мере использовать концепции, методы и паттерны объектно-ориентированной разработки. Язык Visual Basic 8.0 наделен почти теми же возможностями. Чтобы научиться ASP.NET, вам нужно знать основы HTML, а знание asp не обязательно. Оно может даже помешать, так как придется менять образ мышления. Также для понимания многих желательно знать CSS и JavaScript.

Процесс инсталляции

ASP .NET 2.0 можно установить на компьютерах с ОС Windows 2000 с Service Pack 4, Windows XP с Service Pack 2 и более поздними версиями Windows. Готовые сайты предпочтительно устанавливать на Windows Server 2003.

Для разработки приложения можно использовать любую среду разработки или даже текстовый редактор, при условии, что у вас есть доступ к IIS. Если же вы хотите воспользоваться всей мощью Microsoft .NET Framework и ASP.NET и при этом, затратить как можно меньше усилий, то нужно воспользоваться средой разработки, специально разработанной для программирования ASP.NET 2.0.

Если вы приобретете Visual Studio .NET 2005, то для работы достаточно будет только его. .NET Framework содержится на дисках. В его состав входит Visual Web Developer, который позволяет создавать профессиональные веб-приложения, а также desktop-приложения на разных языках программирования. Продукты Microsoft выпускаются на DVD, но есть набор из двух CD от «Мегасофт». Visual Studio .NET 2005 требует около 2 Гигабайт дискового пространства. При этом инсталлируется ASP.NET 2.0, среда разработки, SQL Server Express, встроенный веб-сервер, Crystal Reports со специальными элементами управления для ASP.NET 2.0.
Бесплатно распространяемое программное обеспечение.

Visual Web Developer 2005 Express Edition – свободно распространяемая среда предназначенный для новичков и студентов, доступная по адресу http://msdn.microsoft.com/vstudio/express/vwd/. Список отличий VWD от Visual Studio.NET 2005 невелик и для начинающих несущественен, он приведен здесь: http://msdn.microsoft.com/vstudio/products/compare/default.aspx

Инсталлятор VWD имеет объем 2,8 Мб, но в процессе инсталляции он загрузит еще 40 Мб и 80 Мб, если захотите установить документацию. При этом также будет установлен .NET Framework с ASP.NET 2.0.

Системные требования – процессор с минимальной скоростью 600 МГц, 128 МБ памяти и 1.3 ГБ дискового пространства. После инсталляции нужно будет зарегистрировать свою установку, это совершенно бесплатно.

В качестве среды разработки вы можете выбрать WebMatrix. Эта программа совмещает в себе редактор и http-сервер. Ее можно загрузить на http://www.asp.net/WebMatrix.

У WebMatrix инсталлятор размером всего 1.2 Мб, но у него меньше возможностей, чем у VWD. Но, в общем, эти среды разработки похожи. У WebMatrix есть неприятная особенность – она дает запрос на сохранение во время закрытия файлов, которые не редактировались. VWD Express позволяет одним нажатием кнопки открыть Web-интерфейс конфигурирования проекта. В VWD работает технология IntelliSense, которая автоматически предлагает возможные в данном месте элементы кода.

Если вы решили работать с WebMatrix, вы должны установить на своей машине .NET Framework 2.0 и ASP.NET 2.0.

Если у вас операционная система Windows Server 2003, то .NET Framework уже предустановлен. Вы можете проверить, есть ли вас директория %WINSDIR%Microsoft.NETFramework. Если нет, вы можете ее загрузить на сайте Microsoft. Последние версии находятся по адресу http://msdn.microsoft.com/netframework/downloads/updates

На данный момент это .NET Framework 2.0, но к моменту, когда вы будете читать эту лекцию, могут появиться более новые версии. Вы можете скачать новую версию, даже если у вас уже есть другая. Они будут существовать на компьютере одновременно в поддиректориях %WINSDIR%Microsoft.NETFramework, с именем, соответствующим номеру версии. Можно сказать, что каждая версия представляет собой сборку. Система версий поддерживается для всех приложений, созданных с использованием .NET Framework.

Там вы увидите ссылки на .NET Framework для разных архитектур компьютера.

При желании загрузите .NET Framework Version 2.0 SDK, которая содержит наряду с .NET Framework Version 2.0 SDK документацию и примеры, которые могут оказаться полезными.

По адресу http://asp.net/default.aspx можно найти много полезных для разработчиков программных продуктов, примеров кода и статей.

IIS(Internet Information Server) находится на инсталляционном диске Windows 2000/XP, но предустановлен только на серверах. Его можно установить, зайдя в Control Panel->Add or Remove Programs->Add/Remove Windows Components. Компьютер попросит вас вставить инсталляционный диск.

IIS может понадобиться, если вам нужен полноценный сервер для работы в интернет, а не просто на своем компьютере или в локальной сети или вы решили набирать текст в обычном редакторе. Для работы на своем компьютере во все эти среды разработки встроен сервер Cassini, который первоначально появился как часть WebMatrix. Символ WebMatrix – планета Сатурн, а Кассини — известный исследователь Сатурна. Предыдущие версии Visual Studio требовали наличия IIS, но теперь Cassini встроен и в Visual Studio 2005, что позволяет работать даже в Windows XP Home Edition.

Примеры будут даваться как для WebMatrix, так и Visual Studio. Некоторые примеры требуют VWD Express или Visual Studio.
Сообщества разработчиков.

Через меню помощи Visual Web Developer Express можно зайти на сайты форума по ASP.NET. А вот адреса сайтов на русском языке:

* http://www.aspnetmania.com
* http://www.gotdotnet.ru/
* http://www.sql.ru/
* http://dotsite.ru/
* http://www.rsdn.ru/

Вы можете завести пробный хостинг на http://europe.webmatrixhosting.net/russia/default.aspx.

Первый проект

Вначале решите, в какой директории будете создавать страницы. Все файлы, находящиеся в одной директории, считаются единым проектом.Запустите выбранную вами среду разработки. Выберите пункт меню File-New-Website. Появится диалоговое окно. Назначьте в нем имя проекта и выберите язык программирования С#.

По умолчанию проект создается в файловой системе. По желанию его можно создать на HTTP или FTP-сервере. Из файловой системы проект всегда можно скопировать на сервер нажатием одной кнопки в заголовке Solution Explorer.

В проекте будет создана страница default.aspx. Выберите ее, и появится окно редактирования с закладками Design и Source. Не меняя ничего, щелкните на кнопке со стрелкой, чтобы просмотреть страницу в браузере. Появится окно, котором спрашивается, нужно ли добавить в файл web.config возможность отладки. Нажмите OK. На панели задач должен появиться значок веб-сервера. Откроется браузер, показывающий страницу по адресу http://localhost:номерпорта/Website1/default.aspx. localhost обозначает сервер, работающий на вашем компьютере. Встроенный сервер Cassini сам назначает себе номер порта – для каждого проекта он разный. Сервер IIS обычно работает через порт 80(или 8080, если тот занят), и для него номер порта указывать не нужно. При этом ваша страница будет скомпилирована.

Пока что страница в бразере пустая.

Но исходный код этой страницы не пустой. Программа сгенерировала код для вас.

Asp microsoft windows distributed internet application architecture

The concepts associated with Enterprise Templates are based on and built around a general distributed application architecture Microsoft developed in recent years to reduce the complexity associated with applications within the enterprise space.

This model is sometimes referred to as «multitier» because it can be most easily understood in terms of logical groupings. Because you are working with a template, some decisions are made for you before you even open a project. The advantage is in reducing your workload and planning time but it also means you yield some amount of control. One of those places is in the choice of where you choose to implement additional services.

The various distributed-application templates provide a standard way of developing an application that uses a distributed architecture. By using the templates, you are choosing to implement services in a standard location. You are not required to implement all of the layers. The template assumes for those pieces implemented, that they will be implemented within the layers consistent with the Distributed Application architecture. For example, if you want an XML Web service, implement it within the Web Service Projects layer, rather than add it to the client or the business logic layer.

Within each major group, additional categories exist to supply the complete range of services the application must provide. In Visual Studio’s Distributed Application Templates, these logical divisions can be viewed in the following way:

  • User Services refers, primarily, to the type of client implementation.
  • Business Services is made up of more than one layer, typically, and provide server-side services related to a wide range of business functions.
  • Data Access and Persistence Services include the physical database storing the distributed application’s data and the interface to the data contained in the database.

Within and between each of these levels, key Visual Studio .NET and Windows technologies are used to provide security, scalability, performance, and so on. Notably, within each of these categories (or layers), certain fundamental elements and components recur in a wide range of Enterprise applications.

The operating system also provides infrastructure and a variety of services that fill in capabilities not present in the underlying operating system or language services. This layer allows the user to separate out this functionality into one or more outputs, such as DLLs.

Enterprise Templates and the Multitier Distributed Application

Enterprise Template architecture is designed to be consistent with the multitier distributed application commonly used in the Enterprise computing development space. The following shows the corresponding layers:

Layer Functionality
User Services WinUI and/or WebUI, WebServices
Business Services BusinessFacade, BusinessRules
Data Access and Persistence DataAccess
Other SystemFrameworks

For a discussion of distributed application architecture in working sample applications, see Architecture of Fitch and Mather 7.0 and Architecture of Duwamish 7.0.

Distributed Application Architecture: Architecture and Design

This section lays a foundation for application design. I’m not going to show you any code in it, but I talk about distributed application architecture, sometimes known as enterprise application architecture . You need a solid understanding of this to get a good feeling for how all the pieces of the book fit together.

The term distributed is used throughout this chapter, and then a good bit in the rest of the book. What I’m referring to is a system of disparately located resources ”for example, a server in New York is part of an application that is based in Los Angeles. It interoperates just as if it were in the same building. This notion of distant interoperation is also know as location transparency .

Only a short time ago, developers talked about Distributed Internet Architecture (DNA). It was one of the hot buzzwords . DNA was about creating scalable and robust applications that ran within a distributed Microsoft environment, or more often, within a browser via the Internet (or an intranet). In its never-ending quest for improvements, though, Microsoft now is delivering the next generation technology for building distributed applications. It is known as the .NET platform, or the .NET framework.

The .NET platform includes technologies such as Visual C++, Visual C# (Microsoft’s new object-oriented language), ASP.NET, COM+, ADO.NET, and XML. This near seamless integration comes in the form of Visual Studio.NET.

Convergence

The Internet is rapidly becoming the platform of choice for all new development. But what about all existing programming models, skills, and software code? Convergence with the Internet is imminent. By encapsulating legacy code in components and using the .NET platform to guide new development, it is possible to take the best of the client/server world (multiple tiers, distributed work, transaction processing, queuing) and add Internet elements (scripting, a ubiquitous platform, and reusable components ) to create a robust framework that can accommodate virtually all existing technologies. This enables an enterprise to gradually build out legacy systems and replace them with scalable, reusable, and reliable ones.

The .NET platform is an abstraction. There is no specification for building these applications such as there is for COM/DCOM/COM+, and there are no logo requirements or rules for regulating .NET compliance. Microsoft, however, does promote .NET as a robust framework for building scalable, multitiered Internet applications.

The Core of Distributed Applications

There are usually three tiers or layers of services. Each is bounded by well-defined interfaces that export public behavior only. They are user interface and navigation, business processes, and integrated storage.

User Interface and Navigation

Development tools, such as Visual C++, reside at the user-interface level because they are so popular for creating graphical interaction environments with rich controls (combo boxes, buttons , scrollbars, and so on).

Scripting technologies, such as ASP.NET, VB, C#, or JavaScript, are popular because of their simplified syntax and user friendliness. In the context of the ASP.NET runtime, these scripts are no longer interpreted and slow as they are with ASP. They are now compiled and their performance is adequate.

Business Processes

This is the heart or hot zone of distributed applications. Herein live the core server-side products that enable developers to focus on the solution and not the implementation details. Most of the plumbing required for managing transactions, for example, is provided by COM+. If queuing services are required, COM+ exports a very simple interface to make this happen with minimal development and configuration effort. Finally, to connect the application to the Internet, an HTTP server, such as Microsoft’s IIS, must exist. IIS does a lot more than interpret HTTP.

The application also must be capable of providing a solution, so the necessary logic and rules are present in this tier . Encapsulating the rules in components is preferable, but not required. Components allow for reusability and interoperability across platforms, but as long as the business rules can be activated and information passed back and forth between tiers, any programming technology can be used.

Integrated Storage

Not all storage must be tied to a database. Many forms of physical storage are acceptable and sometimes required. With the strong ties to the Internet, e-mail or multimedia binary streams (such as audio or video) are strong contenders for primary data sources or sinks. A file system also can be used as storage when relational data is not required. Log files, for example, are typically text files stored on the file system that are incrementally built as an application runs.

When data must be associated with other data, a relational database such as SQL Server 2000 can be used through Microsoft’s Universal Data Access mechanisms. Active Data Objects (ADO.NET) are perfect for distributed applications because of their component nature. Other methods of storage, such as collaboration streams, can exist, too.

Evolving Your Applications

It is possible that your current applications are not yet ready to be taken to the level of full-scale Web-enabled applications with all the tiers represented. A typical corporation experiments first, manages the risks, and lets new applications evolve gradually in phases.

Even Fortune 500 companies first take a static approach to the Web by publishing simple-marketing content on their Web sites. With time and competition, their sites begin to incorporate interactive and dynamic elements: a search option here, a page counter there, maybe a form-based e-mail contact page. As traffic on the Web site grows, equipment must be upgraded, security considered , and a new strategy planned.

Unfortunately, this is an expensive endeavor, and many companies are skeptical of the benefits of getting on the Internet. Skilled professionals in this area are not abundant ( especially for dynamic Web content and component programming), and new Internet frameworks (such as .NET) are emerging every day. A corporation faces definite risks in choosing tools to develop, build, and deploy a Web solution. All kinds of incompatibilities can arise when one particular technology is chosen over another (such as VBScript over JavaScript), because browsers are not standard beyond HTML interpretation.

A wait-and-see approach doesn’t work because the pressure to give customers what they want is real and constant. Eventually, with more and more people wanting more and more interaction with a Web site, a Web application must evolve and begin incorporating the new technologies to accomplish this.

Producing successful Web applications becomes more manageable and cost effective if the process of achieving a distributed application is handled in phases.

A Functional Overview of Distributed Applications

Having discussed the general .NET framework and some of the tools and products it encompasses, you can dive into more detail with a specific (but strictly hypothetical) example.

The Browser

You begin the journey into an application with a browser. For the .NET platform, a browser usually means Microsoft Internet Explorer (IE). Microsoft has ported IE to many platforms, such as Macintosh, Windows , Solaris, and SunOS, with others in the works. IE is the ideal target browser because of its wide platform support, its integration with COM+ (ActiveX), and its relentless pursuit of world dominance in the browser wars.

Internet Information Server (IIS)

The next point of contact is Microsoft’s Internet Information Server (IIS), a critical server-side product that makes the .NET platform possible. One of its main goals is to serve HTML pages over the HTTP protocol efficiently and reliably. IIS is not the only HTTP server out there. Competitors such as Apache and Netscape have long been in the server business and have produced commendable, inexpensive (or free) HTTP servers, but their main focus has been to serve static content as fast as possible. With IIS, however, you get much more than an optimized content server.

ASP.NET adds dynamics to HTML, a static markup language that by itself does not accommodate interaction with a user. In the past, HTML relied on external server-side Common Gateway Interface (CGI) programs or Perl scripts that would generate HTML based on some input. This gave the illusion of interaction, but at the cost of user- observed latency because many round trips were required.

This was the situation circa 1995. Since then, a whole slew of new technologies have changed the way developers write HTML-based applications. It now is possible to execute code based on user input on the client itself, without having to repeatedly query a server. This increases reliability and performance but adds coupling to the application.

ASP.NET encapsulates the complicated task of trying to create the illusion of a dynamic, user-driven application when only static, canned data exists. ASP.NET enables a Web application to create individual environments controlled by the user. This is not a new concept. CGI has been around since HTML and has provided a limited form of dynamic Web content. If you’ve ever programmed with CGI, you are aware of its delicate and awkward user interface. While ASP took CGI to a new level, ASP.NET takes ASP to the next level and creates an easy-to-program bridge between Web users and server components.

The addition of ASP.NET has provided an even easier level of control of Internet applications. Internet applications are virtually indistinguishable in functionality from their Win32 or similar GUI counterparts. Consider the following ASP.NET code, which creates a COM object, locates an interface, calls a method, and stores a result in a variable, all with only two lines of code:

COM+ Transaction Management

Below IIS live the COM+ transaction services (built on Microsoft Transaction Server, or MTS). With this technology, a client will never see beyond ASP.NET, so the COM+ transaction services are playing a role strictly behind the scenes. And the COM+ transaction services do much more than their name implies. They certainly do a great job of automatically coordinating transactions within and across components and databases, but they also manage the caching and pooling of resources, producing scalability as a free side effect.

COM+ transaction services normally are used as a container for components in the .NET framework.

COM+ Messaging and SQL Server

If your application must asynchronously communicate with another application or data store over a high-latency network, the COM+ messaging services (built on Microsoft Message Queue ”MSMQ) can be of tremendous help. These services coordinate the complex interactions involved in the delivery, reception , and acknowledgment of synchronous or asynchronous messages. Components themselves can be messages and can be automatically managed. The developer need only provide the necessary implementation for the COM+ IPersist interfaces and let the messaging services take over in a reliable and fault-tolerant manner.

For distributed applications that must communicate with each other remotely, or even within a local machine, COM+ messaging services relieves the COM+ programmer from the burden of low-level communication details such as WinSock, spawning threads, and concurrency control.

XML is a way of representing data. It’s platform independent, and provides several other advantages, such as being easy to send as a payload to remote servers. This book teaches you about XML, and in the chapters that show you how to build full applications, you’ll use it as the data exchange medium.

Visual Studio.NET

So, where does Visual Studio fit into the .NET platform? It provides a very rich set of tools that work together in the development of distributed applications. This book covers XML, COM+, and ASP.NET. Specifically, I’ll talk about creating and using XML documents, creating and using COM+ components, and creating and using ASP.NET. These three technologies work well to form the basis for distributed applications.

Designing Distributed Applications

Although XML, COM+, and ASP.NET are groundbreaking new technologies that surely will change the way software is developed in the near future, it is no silver bullet. The technologies by themselves do not guarantee robust and reliable architectures ”or even ones that work, for that matter. Good design principles are critical for any software system, regardless of the model or framework on which it is based. It is essential that developers spend sufficient time analyzing the problem to be solved (the what), and then more time designing a working solution (the how).

The analysis and requirement-gathering phases of software engineering, albeit critical, are not related to programming, so they are not covered in this book. Design, however, does impact .NET components and merits a section of its own. If a solid foundation is not created during the design phase of an application’s development, the application is unlikely to be successful over time. When it comes time to modify or augment the application, the lack of design will be evident, and the application likely will need a rewrite.

The section titled «Ad-Hoc Design» lays the groundwork on which all .NET programming should stand.

So far, this chapter has already laid down a road map. The task now at hand is to correctly follow this map and build reliable, maintainable , and scalable applications with it. The design principles discussed in the following sections add value to all .NET solutions.

An emphasis is placed on multitiered design for both its success in software design in general and for its seamless adaptation to .NET solutions. Traditional design methods are covered first, then three-tiered models, and finally multiple tiers in the sections that follow.

Ad-Hoc Design

In general, trial-and-error or nonexistent design techniques are likely to fail when you are developing software. Surprisingly, even when lack of design has been proven to cause late and over-budget projects that do not work or are never delivered, software developers continue to ignore this part of the development cycle. It seems as if there are never enough resources or days in the week for this seemingly empty and intangible phase.

A flawed design becomes much more apparent as the application evolves. Although it is true that there are great benefits to component-based software, all advantages quickly disappear if components are assembled into monolithic, rigid structures. It is very difficult (and indeed, sometimes impossible ) to scale or upgrade components without a rewrite unless they have been properly designed. Add to that the training investment that programming distributed applications requires, and the pressure rises even higher. A failed component-based project will not be as forgiving as a traditional monolithic application. It’s easier to fix a monolithic application, so other developers who have to fix problems with your project in the future will have an easier time of it. With all of its complexity, .NET might seem shrouded in mystery to the uninitiated. It is very easy to blame .NET technology in general when an ill-designed project fails.

Even when the technology is used correctly, components themselves don’t solve all known software problems; in fact, they introduce a few of their own. If you’ve ever worked with DCOM, you can probably attest to this statement. XML, COM+, and ASP.NET take time to learn. They require that you invest time in a considerable setup and configuration phase not normally associated with other programming paradigms or languages. Their benefits, however, surpass all these costs with intangible rewards such as reusability, maintainability, and scalability.

Fundamental Application Boundaries: Presentation, Logic, and Data Services

Designing software with components is slightly different from designing with other traditional methods. First, components are inherently independent, standalone entities. Components communicate with each other only through known public interfaces. A process of discovery reliably tests what a component can and cannot do.

If components are grouped into one monolithic, tightly coupled pile, they lose all their intrinsic benefits and add maintenance complexity. You must view components as heterogeneous sets of tiers or layers, where each component has something in common with the other but solves a different problem.

The idea of partitioning the work is not new. One highly successful model is known as the three-tiered model in the client/server community. You learn it here as a primary design guideline for all distributed programming.

Coupling

When I say a system is tightly coupled, I am referring to its interdependencies.

A coupled architecture is rigid and inflexible , but easy to design and implement. Coupled architectures are synonymous to monoliths because they are regarded as single entities with little or no interchangeable objects or components ”very much like huge blocks of granite.

Tightly coupled applications are difficult to maintain. When it is time to modify a monolithic system, the development team might find they are painted into a corner. Any modification to the system, however minor, is risky. A single change in a line of code in one function in one module can have a domino effect that causes another function in a separate module to break, causing the entire system to fail in strange and unpredictable ways.

Coupling can be divided into many forms. The most important are architectural, intra-procedural, inter-procedural, and inter-modular. They are listed here in order of greater impact on the system:

Architectural coupling ties the presentation (or GUI) code to the data and logic rules of the application, or vice versa. When the presentation code of an application (the code in charge of communicating with a user through buttons, windows, events, and so on) knows about and assumes the existence of a vendor-specific database and uses that database’s proprietary API, it becomes very difficult to change the application in the future when a new presentation technology (such as a Web browser) or database emerge.

Intra-procedural coupling tangles the control flow within a procedure or function. This form of coupling, the hardest of all coupling types to remove, is achieved by the frequent use of GOTO and GOSUB commands within a procedure, which quickly yields spaghetti code that is almost impossible to follow and maintain. This practice usually requires a rewrite of the procedure when a new developer must make a change.

Inter-procedural coupling ties together functions or procedures within a module through global memory sharing. Global variables and constants form the two-edged sword of software development. They make programming very easy and quick, but in the face of change can create bug-inducing side effects that are very difficult and sometimes impossible to locate. Because the global variables are anonymous, they can be modified by anyone within the program, producing a chaotic , disorganized runtime.

Inter-modular coupling creates dependencies across modules. Most monolithic applications rely on a few commonly used modules or libraries. This can be a problem because a change in any of the library files requires a recompilation of the entire application. This is important when considering remote deployment of the application. Contrast this with COM+, which does not require its clients to recompile or be aware that any changes were made. COM+ interfaces should be eternal.

A loosely coupled architecture, on the other hand, is one composed of independent, inter-operable components or objects. Changes to the architecture are isolated to one component at a time. The probability of a domino effect as described earlier is almost zero. However, loosely coupled architectures incur a performance and development time tradeoff . They take considerably more effort to design, significant communication overhead is introduced by the components, and in general they are harder to implement.

Nonetheless, the benefits of loosely coupled systems far outweigh their cost.

Three-Tiered Design

One of the most successful models to emerge from the client/server world has been the three-tiered model. A tier, or layer, is a collection or set of independent homogenous objects (each solving a small problem) that together solve a larger but common problem.

Consider a typical PC application today. It is likely to interact with a user, process some data, and perhaps persist its state somewhere ”hence three tiers.

The three tiers are generally known as presentation , business logic , and data services .

Monolithic Versus Three-Tiered Design

You are very likely to encounter the three-tiered design model under different names at different times (integrated storage rather than data services, or navigation rather than presentation, for example), but the concept in any case is the same. Within each tier live components that in turn contain public interfaces to the private functions or methods that do the actual work.

The underlying principle of COM+ is having rigid implementation boundaries encapsulated by well-known public interfaces. Tiers are no different. The interfaces for a tier are more general and at a coarser level of granularity than those for a component, but encapsulation is still the foundation.

A particular tier should know nothing whatsoever about its adjacent tiers other than their exposed public interfaces. From a procedural standpoint, this indifference seems like a restriction, but it’s really a liberating mechanism. Herein lies the strength of the model: Changes in one tier have minimal impact on the others. This rule puts the architecture in a comfortable position to be easily expanded and freely upgraded with time.

Communication across tiers should exist only through public interfaces in a well-designed three-tiered architecture. When tiers are loosely coupled, it is very simple to swap out components (or entire tiers) to adapt to changing requirements without demanding a rewrite or system retest. For this reason, tiers should be completely unaware and carefree about the implementation of adjacent layers. A tier should see only the public interfaces of its immediate neighbors.

This highly effective and universal model has been around for years but is surprisingly uncommon outside the client/server world (one machine stores data, another reports it). With the advent of COM+ (interface-driven) and .NET, the three-tiered model is seeing even greater use.

The main tiers in the three-tiered model can be described as follows :

Presentation ” The presentation tier involves all interaction with the user. Specific GUI-only operations such as repainting a window, capturing mouse-up clicks, text input, and so on, live here. The model does not allow interaction with the user at any other tier. Doing so would couple the lower layers with this responsibility and render the model inflexible with time.

Minimal validation of data can be done at this layer, but validation is better suited for the adjacent business tier. The presentation tier does not know about any particular data store technology (if one exists) or where its data originates. The presentation tier has a defined set of interfaces that enable it to communicate to the business layer, and that’s the only capability it has.

Business Logic ” Next is the middle, or business logic tier, where most of the processing is carried out. All business-specific rules are grouped into this tier. This is the part of the application that actually solves the problem. It is the middleware between the user and any physical data storage. Like its parent tier, the business logic tier should not know the specific details of the data services tier below, nor the type of presentation used above. It should only process data, not store it or present it.

Data Services ” Data services is in charge of any physical persistence the application requires. Specific data services mechanisms, such as low-level database access or SQL, should go here. When the time comes to upgrade or change physical stores, nothing but this layer is affected, and nothing else breaks or requires extensive retesting. Typical client/server three-tiered models involve a structured relational database storage of some type (such as Oracle or SQL Server), but this is not the case in newer three-tiered designs.

An application does not require a database to benefit from a three-tiered model. Any kind of persistent storage can be placed here (file systems, e-mail, multimedia streams, and so on), away from the presentation and logic layers, so as to increase the potential for maintainability and evolution of the system in the future.

Keeping Tiers Balanced

Imagine a well-balanced three-tiered architecture sitting atop a delicate fulcrum. On the left rests all the presentation code, in the middle the business logic, and on the right any data services.

The business logic middle tier is likely to carry most of the weight in a system, but placing too much weight on either extreme can be disastrous for future evolution. Putting too much weight on either side tilts the balanced objects and causes the application to collapse.

On the presentation side, this could mean adding data-aware or data-bound controls that talk directly to the data-access tier. In turn, relying heavily on database-specific logic mechanisms, such as stored procedures or triggers, on the data services tier has the opposite effect, tipping the balance to the data services side.

A Solid, Robust Design

Now consider a solid three-tiered design that rests on an immovable foundation of logic, thereby eliminating the fulcrum and the chance of disturbing the balance. A square represents a rigid foundation, unshaken by future upgrades or modifications to any tier. This rigid foundation is achieved by the clear separation of presentation and data logic from the business rules. As long as the problems the application is trying to solve are oblivious to where the data (if any) comes from, or how it is presented, the application will remain scalable and robust with time.

The three-tiered architecture is not just for client/server environments. Virtually all applications can be divided into at least three tiers as described. (As an exception, however, consider device drivers and other low-level hardware manipulation programs where the extra three-tiered design effort can be counter-productive.)

Whether you are building a small Win32-based application or a full-blown, Web-enabled e-commerce system, these principles are applied equally. No matter how complex the problem, software always deals with data in some form (or there would be no work to do) and can always be separated by behavior into distinctive layers.

Multitiered Design

As applications evolve and become more complex, sometimes it is necessary to break one particular tier into two or more. This results in multitiered, or n-tiered, architectures. Although the fundamental interaction with a user might be the same (present data, gather data, and store data), it is sometimes easier to break the three basic tiers into several pieces.

For large complex applications with dozens of developers, it is much easier to work with an n-tiered architecture than a three-tiered one because the work can be carried out separately in finer granularity.

You might be asking yourself, «Why not keep one tier, as before, and two components that handle HTML and Win32, respectively, adding interfaces and methods as required?» The answer is that Win32 can be so complex that doing so would require a large set of homogenous Win32 components to coexist with another large set of homogenous HTML components. Win32 is inherently different from HTML processing (linear and event-driven rather than non-linear and static).

As you might recall, a tier is defined as a collection of independent homogenous objects that work together to solve a common goal. By breaking down the tiers, and thus the number of components in each tier, you can greatly reduce the development and testing complexity of an application in a team environment. Independently developing and maintaining 5 components is much easier than doing so with 20.

The more components you have in a tier, the more the tier approaches a monolithic model (too much coupling), defeating the purpose of tiered architectures. In the case of HTML and Win32 as presentation choices, separating them into two tiers is a sound logical choice.

It is essential to set a threshold for the minimum number of components a tier should contain. If you were to make each component its own tier, you would be back where you started (all components, no homogeneous organization). When designing an application, use tiers to your advantage but be frugal in their quantity.

Moving down from the top presentation tiers are four separate tiers that normally would be contained in the business tier. If you break them apart according to general functional goals, it is much easier to understand what the application is doing: validating data, crunching data, securing data (encryption, authentication, and so on), and transacting data. Each of these actions certainly could be contained in a single tier, but doing so would crowd the tier and render it unmanageable ”a contradiction of the model’s main purpose.

A Data Validation/Shaping tier contains many different, but functionally similar, components. Each one solves a different problem within the validation domain of the application. Although validation can be considered a business-tier functionality, the validation components have little or no relation to crunching the data itself.

The next section talks about where your tiers should be physically placed in a deployment configuration.

Local or Distributed?

Do not be fooled by the apparent distribution of the disconnected layers in a multitiered architecture. Programming with tiers does not imply a distributed relationship or even the presence of a database. It is a road map to follow and can be used for any application. Some applications do not even require a presentation layer. They can be services, for example, such as listening for non-interactive requests . Likewise, a data services tier can be absent if the application doesn’t involve persistence (as in the calculator usually found under the Accessories menu in Windows).

Good Design Techniques

Fortunately, sound design principles are very easy to apply to component-based software. This book does not examine the more involved object-oriented approaches that exist, but instead covers tried-and-true techniques for designing multitiered architectures. In order of importance, they are as follows:

Abstract the application into heterogeneous functional tiers.

Identify components to carry out finely grained behaviors.

Create interfaces or glue between the layers.

Implement the component interfaces and their methods.

From these techniques or principles, you probably can see an inductive approach. It is extremely valuable to start from the general and narrow down into the details.

Abstract the Application into Tiers

All useful software is created to solve one or more problems, which can always be divided or separated into subproblems. With components, it is important to split large and sophisticated problems into smaller, more manageable ones. By using this divide-and-conquer approach, you ensure that the problem as a whole will be solved, and you also create a robust and easily maintainable architecture. It is much easier to modify and upgrade a single subproblem component than it is to try to tackle an entire monolithic problem, with the usual retesting and debugging.

Identify Components

This phase is a little more challenging and requires foresight (and hindsight!). It’s probably the most fun and creative phase of all because it brings together past experiences, current technology, and analytical problem solving. Again, although not all applications can seamlessly fit the three-tiered model, they can always be logically separated into this abstraction at some level.

Start with presentation. Will the application interact with a user through a graphic interface or is it a service that fulfills requests blindly? Creating intuitive and user-friendly GUIs is not a trivial task. All too often you see GUIs that are plagued with inconsistencies from screen to screen or are too busy. This only compounds the problems when you are working with browsers and their lack of rich control sets or state.

You won’t learn GUI design in this book, but it is worth mentioning that it should not be taken lightly. Remember that although the presentation tier is just the tip of the iceberg, it is the one and only communication link between a user and what constitutes the application.

The tiny presentation tier can be sitting on the shoulders of a huge sophisticated business tier, but if it’s not exporting a user-friendly working environment, or is inconsistent, the user might dismiss the entire application.

After you have decided what visual or nonvisual technology to use (Win32, browser, console, and so on), separate the presentation into functional units. One component could handle menu options, another tabs, and yet another ToolTips. Or in a browser, one component can be delegated to track context menus that change from page to page, whereas others can be in charge of tracking combo and text boxes. The more you separate your presentation into standalone objects, the easier it is to maintain and upgrade.

From my own experience, I think it is safe to say that the presentation tier undergoes the most changes. It is impossible to satisfy all users on how interaction should occur, but you can find common ground that satisfies the majority of users and reaches a compromise.

The other two tiers should follow the same idea. The business tier is in charge of validating and processing. That’s two components. A validation component can be in charge of filtering any data before it is passed on for processing. The processing component, in turn, does not have to worry about bad data because it has already been validated . This arrangement removes the burden of having to carry out both actions simultaneously , which can cause errors.

If your application requires data access, then the third (but by no means final) tier can be in charge of all data access. If your application communicates with a typical relational database, you can have two components: query and update, for example, each with its set of interfaces for carrying out vendor-specific SQL commands. Avoid using stored procedures whenever possible. They couple the underlying physical database with the rest of the application at the sometimes negligible reward of increased performance. If you offset stored procedures into components instead, the processing is generic and can be applied to any database technology in the future.

Create Interfaces

Interfaces are at the heart of COM+. They are powerful abstractions that enable you to separate advertised behavior from internal implementation. An interface should describe only what public services an object offers. The private state of an object should never be disclosed through public interfaces.

An interface in COM+ is the binding contract between a component and its clients. At its core, an interface is a collection of semantically similar methods or functions accessed through a vtable pointer at runtime.

An interface itself does not have any functionality. It merely points to the implementation. Interfaces can be reused (polymorphically or with inheritance) across components and upgraded. New methods can be added, but old ones should always remain.

When designing interfaces, keep in mind that all the methods contained in an interface should have something in common. There is no limit to how many methods an interface supports, but a good rule of thumb is to keep the number below 10. This keeps the interface from becoming unmanageable and monolithic, defeating the purpose of COM+.

Implement the Components

Finally, after you have created a conceptual model separated across tiers and interfaces, it is time to implement the behavior. Depending on the complexity of the application, this can be the quickest part of all. With the interfaces serving as a blueprint, and with the confidence of a sound design architecture, the requirements of the application can be implemented in code.

Design Constraints

In applications, be they multitiered or monolithic, a whole slew of requirements impose constraints on the finished product. Sometimes, the requirements are conflicting or require bargaining tradeoffs. Size versus speed, for example, has historically been a major tradeoff facing software architects . With memory prices constantly dropping, this particular tradeoff is not as relevant today as it was a decade ago. Many new tradeoffs have emerged to take its place. These are discussed next.

Many real and measurable forces act on the overall shape of the any modern-day multitiered architecture. The following are some of the most important:

Leveraging existing technology and skills

It is unrealistic to assume new projects will use all the latest high-tech tools, programming languages, and server-side products, setting aside all existing technology investments. In the real world, significant resources have been invested into software development; hardware, software, training, and skyrocketing IS salaries all add up to a huge expense for any corporation.

Fortunately, programming with the .NET platform does not require a major IS overhaul . It is possible to develop successful .NET-based applications inexpensively and without having to throw in all the bells and whistles Microsoft has to offer. For example, expensive database products such as SQL Server 2000 might not be necessary if a corporation already owns another database.

Software projects are consistently late and over budget. There are many reasons for this, but implementation and integration issues always seem to emerge as primary culprits. I’m not offering any solutions, I’m actually looking for them. If I find them, I’ll broadcast them loud and clear.

Design Goals

In today’s world of distributed computing and Internet applications, memory is cheap. Reliability, not size, matters. But reliability alone is not sufficient to justify an application to a modern user. As a developer, you must aim for several key intangibles. The following list includes the most important ones:

Locality (distributed or local; ties closely with performance)

How effective is a software system if it cannot be upgraded or evolved over time? If there is one lesson we have learned from the Y2K problem, it is that computer programmers should be more judicious and critical of the assumptions they make about the future. Foresight and flexibility during design and implementation will be greatly rewarded. A narrow and specific solution usually must be rewritten several times as new features are requested and unexpected requirements arise.

Rather than attack the problem in the particular, strive to solve the problem in general with additional rules for the specific problem at hand. All too often, developers come back to old code and wish they’d put a little extra effort into decoupling a large procedure or function. Having to spend valuable time in a partial or complete rewrite is no fun.

Active Server Page

Download as PDF

About this page

Learn more about Active Server Page

Introducing ASP.NET

Mesbah Ahmed, . Jonothon Ortiz, in ASP .NET Web Developer’s Guide , 2002

Why ASP Was Not Originally Embraced

Active Server Pages was not an overnight success, though understandably it did capture the imagination of a large sector of the development community, particularly those already well versed in Visual Basic programming or Visual Basic for applications scripting.

Others who did not have an investment in Visual Basic knowledge found the limitations of Visual Basic, and by extension Visual Basic Scripting, reasons to avoid the technology. Faults included poor memory management, the lack of strong string management abilities, such as Regular Expressions, found in other established languages. When compared to CGI with Perl, ASP was found lacking.

At that time, Internet Information Server was in its infancy, and take-up was low, despite Microsoft’s public relations juggernaut going into full flow after the company’s much-reported dramatic turnaround. In comparison to current versions of the software it seems very poor, but it was still competitive on performance.

Until 1997, back-end Web programming was pretty much owned by CGI and Perl. High-performance Web sites usually had a mix of C-compiled programs for the real business engine, and Perl for the more lightweight form processing.

There was a fair amount of doubt and suspicion around Microsoft’s Internet efforts, including IIS and Internet Explorer, and ISAPI had not done all that much to bring across a huge sector of the development community. Despite this uncertain atmosphere, Microsoft saw many Windows NT 4 licenses being bought specifically for Web hosting and development increasing. Third-party support for anything other than small components was initially slow, but, as with all Microsoft products, after the first couple of releases they usually get things right, and ASP was no exception.

Whereas Perl had a huge community of developers led by the heroic figure of Larry Wall, the ASP developer was not yet well supported. A Perl programmer was encouraged from the top to share and make his or her code open, so the community thrived, with every conceivable solution or library just a few clicks away at the Comprehensive Perl Archive Network (CPAN) site, or at one of the many other Web sites and news groups. Contrast this with the ingrained competitive and financially led philosophies of the third-party component vendors in the Windows Distributed Internet Applications (DNA) world. Of course, it did not take the ASP community long to grow to be the loving, sharing success it is now.

WMI Security Scripting

4.3 WMI and Active Server Page (ASP)

Most of the scripting techniques we learned in previous chapters are applicable to Active Server Page (ASP) scripts. However, to run a WMI script from an Active Server Page (ASP) script, it is important to note two important points, where security is the main aspect to consider when developing WMI-ASP solutions. This is why we cover this information in this chapter. The two points to remember are:

The asynchronous scripting technique cannot be used within an ASP script, because the VBScript CreateObject statement does not support the connection to a sink routine, such as the CreateObject statement used with WSH (i.e., Wscript.CreateObject statement).

Regarding the security settings: Some parameters must be carefully considered regarding the platform the ASP script is run from.

4.3.1 Authentication settings

Authentication settings are as follows:

Security configuration under Windows NT 4.0: To run a WMI-ASP script under the Windows NT 4.0 platform, a registry key must be modified to grant the Scripting API all of the permissions of the account running Internet Information Services (IIS). If not, then the browser client must contain the necessary permissions and security settings. The registry key to be modified is located in the HKLM\Software\Microsoft\WBEM\Scripting registry hive, where the DWORD value Enable for ASP must be set to 1 (see Figure 4.2 ). Of course, changing this registry key is granting all privileges to the account running IIS, which represents some danger, since you will be granting all privileges without any further considerations. We will see later in this section that different approaches can be used to minimize such a risk.

Figure 4.2 . Granting all Scripting API permissions to the IIS account.

Security configuration under Windows 2000 and above: Under Windows 2000 and above, there are several ways to customize the IIS security. Of course, since a WMI-ASP script can perform some critical tasks, it is important to request the user to authenticate. Therefore, the recommended approach is to disable the anonymous access for the authentication protocol used. As we will see, the authentication method used will impact the WMI security configuration. Under Windows 2000 and above, you have a choice: ▪

The Windows Integrated Authentication: As we can see in Figure 4.3 , the Windows Integrated Authentication (WIA) is enabled for ASP, while the anonymous access is disabled. This security setting doesn’t require any specific WMI security configuration. Enabling the Windows Integrated Authentication implies the use of Kerberos or NTLM.

Figure 4.3 . Setting the Windows Integrated Authentication.

Passport or digest authentication: The passport or digest authentications (see Figure 4.4 ) require that the CIM repository namespace Remote Enable privilege be granted to accounts authenticated by one of these protocols, since the user access is treated as a remote user access. For instance, creating a Windows Security Global Group and including the users authorized to remote access a selected namespace is a good practice (see Figure 4.5 ). Note that with the digest authentication, passwords are still wrapped in a password encryption key, but they are not hashed.

Figure 4.4 . Setting the passport or digest authentication.

Figure 4.5 . Enabling remote access for remote users.

Anonymous and basic authentications: For obvious security reasons, it is recommended not using the anonymous and basic authentications, which are a clear-text authentication without encryption. Obviously, anonymous basically means “no authentication,” which is not a recommended approach. However, the Remote Enable privilege is not required for these two authentication methods if they are used.

4.3.2 Customizing IIS 5.0 and above

Regarding the security configuration under Internet Information Server (IIS) 5.0 and above, the authentication settings previously reviewed are not the only things to consider when setting up an IIS server running WMI-ASP scripts. Actually, the location of the authentication-level definitions is also very important. IIS can enforce the authentication at the Web Server level, the virtual directory, or the file level (see Figure 4.6 ).

Figure 4.6 . The three IIS locations where authentication can be defined.

Moreover, for WMI-dedicated security, it is a good practice to create an independent directory structure, which contains all HTML pages and WMI-ASP scripts (see Figure 4.7 ). This organization allows you to customize specific security settings independently from the rest of the server security. For example, Figure 4.7 shows that the WMI-ASP Script folder is not under the WWWRoot folder, which allows the creation of specific access rights on the file system to access the WMI-ASP scripts.

Figure 4.7 . The isolated file system directory from the WWWRoot folder.

In order to increase the WMI-ASF script security, it is a good idea to disable the anonymous access and enable the Windows Integrated Authentication (WIA), as shown in Figure 4.3 .

However, there are some situations where anonymous access is required. By default, Web clients accessing IIS are using the IIS logon identity (i.e., IUSR_ ). Therefore, it is a good > appropriate password in the authentication methods user interface, as shown in Figure 4.8 .

Figure 4.8 . Enabling anonymous access with IIS.

Note that to secure applications, IIS 5.0 also has the ability to isolate applications in different security contexts. IIS 6.0 uses the concept of application pools to implement the same functionality. You can refer to the IIS documentation for more information about these security features.

Of course, since a different user account for the virtual Web site identity is used, you must make sure that this user account has access to the CIM repository accessed by the WMI-ASP script. For instance, if the WMI-ASP script uses the Win32_Service class located in the Root\CIMv2 namespace, the WMI-ASP-Script user must be enabled and have remote access granted on that namespace. Even if everything is executed locally, the remote access must be granted, since the user account is treated by IIS as a remote user access (see Figure 4.9 ).

Figure 4.9 . Ensuring WMI CIM repository access for the WMI-ASP dedicated account.

From a scripting point of view, developing WMI logics in ASP pages is the same as developing WMI logics in WSH (the exception, as mentioned in the beginning of this section, is that asynchronous calls are not supported). Of course, since the scripting environment is different, the output of information must be handled in respect to the ASP context and must make use of HTML tags.

Sample 4.1 shows an example of an ASP script listing the state of all Windows services in an HTML page (see Figure 4.10 ). To get this ASP script running, make sure that the IIS security settings are set accordingly, as explained previously, in regard to the operating system and IIS version used.

Sample 4.1 . Viewing all Win32_Service instances with their status from a WMI-ASP script

Figure 4.10 . Viewing all Win32_Service instance states from the Web.

Reviewing Code for SQL Injection

Microsoft Source Code Analyzer for SQL Injection

The Microsoft Source Code Analyzer for SQL Injection tool is a static code analysis tool that you can use to find SQL injection vulnerabilities in Active Server Pages (ASP) code. The tool is for ASP classic and not .NET code. In addition, the tool understands only classic ASP code that is written in VBScript. It does not analyze server-side code that is written in any other languages, such as JScript.

Language: ASP classic (VBScript)

Reviewing Code for SQL Injection

Microsoft Source Code Analyzer for SQL Injection

The Microsoft Source Code Analyzer for SQL Injection tool is a static code analysis tool that you can use to find SQL injection vulnerabilities in Active Server Pages (ASP) code. The tool is for ASP classic and not .NET code. In addition, the tool understands only classic ASP codes that are written in VBScript. It does not analyze server-side codes that are written in any other languages, such as JScript:

URL: http://support.microsoft.com/kb/954476

Language: ASP classic (VBScript)

Platform: Windows

Price: Free

USB-Based Virus/Malicious Code Launch

Brian Anderson, Barbara Anderson, in Seven Deadliest USB Attacks , 2010

Java Applets

Created by Sun, Java applets are a type of program developers add to Web pages to prov >Active Server Page or a Windows Scripting Host containing these modules can be extremely hazardous. These can allow unrestricted access to computer resources, which include the file system, registry, and applications.

While most are legit, some hostile applets exist, which can take command of the operating system, alter system files, or prevent the use of specific applications. Their popularity among Web developers is largely attributed to the cross-platform support of different operating systems and Web browsers. This also entices the hacking community because they have the ability to automatically execute when a user visits a Web site. In the time it takes a browser to render the page, the applet is loaded and the malicious code is run on the machine. These applets are sometimes planted by malicious authors, but taking control of existing applets is possible and is usually the result of poor coding. Since loading applets is a normal activity while surfing the Web, these attacks are rarely detected by standard security measures. Java applet attacks can deceive even the most savvy computer user.

Getting Started with IIS 7.0

Worker Processes

One of the most important changes in the core of IIS 6.0 was the use of worker processes (w3wp.exe ) . These processes acted liked processing hosts for user-developed code. They could each host ISAPI extensions and filters, as well as Active Server Pages (ASP) applications and static content. Figure 1.5 shows the inside of a worker process (w3wp.exe) .

Figure 1.5 . Inside a Worker Process (W3WP.EXE)

With ISAPI, developers could create filters to access the core server. ISAPI filters are used to preprocess and post-process HTTP requests. ISAPI filters are driven by Web server events, not client requests. An ISAPI filter could be notified when a Read or Write event occurs and then modify the data that is to be returned to the client. ISAPI extensions are sometimes referred to as ISAPI applications, and can be called from any Web page to perform dynamic and interactive functions such as validating a form or accessing a database. ISAPI extensions and filters are written in C or C++ and are quite cumbersome to create and deploy. The deployment of ISAPI extensions and filters required server administrator rights.

By examining Figure 1.5 , you see that requests can be handled by mapping them to the static file handler (default), the Common Gateway Interface (CGI) handler, or through an ISAPI extension. In Figure 1.6 , requests using managed code (as shown with the solid lines) must first go through the IIS pipeline and then through an ISAPI filter before it even reaches the ASP.NET pipeline. The response (depicted as the dotted lines) then goes through the same pipeline but in reverse.

Figure 1.6 . Request Going to ASP.NET Pipeline

Also at issue was ISAPI deployment. In IIS 6.0 this was also cumbersome. Unfortunately, ISAPI deployment wasn’t as easy as using FTP to copy the binary file to the server and have it work. To deploy ISAPI filters or extensions to the appropriate configuration for your site or application, as mentioned earlier, you had to have administrative rights on that local server and then restart the worker process that it resided in. Microsoft has resolved these issues in IIS 7.0 by making managed code a priority and allowing easier deployments of both native modules and managed code.

Configuring Web Application Services

Differences in Windows Editions

IIS is available in all editions and installations of Windows Server 2008. With Windows Server 2008 you can install IIS on a Server Core installation. There are some role services, however, that will not be available on Server Core:

IIS Management Console

IIS Management Service

IIS 6 Management Console

Although these differences exist in this release, this still leaves you the ability to serve static, >Active Server Pages (ASP), and Common Gateway Interface-based dynamic content (e.g., PHP, Perl, and Python).

Typical Deployment Scenarios

Depending on your business needs there are a number of scenarios in which IIS can be deployed.

Simple Web Server

Delivering one or more Web applications to a small number of users is the least complex scenario (see Figure 11.2 ). With this release of IIS the number of concurrent users that can be served continues to grow. IIS takes full advantage of 32-bit and 64-bit hardware to allow you to do more with less hardware.

Figure 11.2 . Simple Web Server

Small Web Farms

As you grow you can scale out to add additional Web servers to a farm using software-based load balancing. In this configuration you will split any database components off to a dedicated database server (see Figure 11.3 ).

Figure 11.3 . Small Web Farm

Large Web Farms

At a point in your growth it will be advantageous to use dedicated devices to provide load balancing, offloaded transport security, centralized storage, and application optimization. These devices are tuned to the specific tasks and can execute it more efficiently leaving your Web servers to focus on dynamic content assembly and delivery (see Figure 11.4 ).

Figure 11.4 . Large Web Farm

Advances in User-Session-Based Testing of Web Applications

Sreedevi Sampath, in Advances in Computers , 2012

2.1 Web Applications

A web application consists of a set of pages that are accessible by users through a browser and are transmitted to the end-user over a network. A web page can be static—where content is constant for all users, or dynamic—where content changes with user input. In web applications user input (navigation and data input) affects the state of the system. An application’s client pages are typically written in HTML with embedded Javascript or VBscript and rendered by the web browser on the client s >Active Server Pages , Java Server Pages, or servlets that are executed by the web server on the server side and provide information to clients. A component can be an HTML template, Java applet, an ActiveX control, a Java Bean, or any program module that interacts with the client pages, server pages, or other components. Even a simple web application can be written using multiple programming languages, e.g., HTML and Javascript for the front-end, Java or JSP for the middle tier, and MySQL as the back-end language.

Web applications exhibit characteristics of traditional applications, graphical user interfaces (GUIs), database, and distributed applications. GUIs and database applications are similar to web applications with respect to their event-driven nature. User input can result in unexpected change in control/data flow in the application. Web applications are similar to distributed applications since they are essentially programs operating and communicating over a network. In addition, web applications possess numerous technologies and components. Their distributed and heterogenous nature makes testing web applications a challenge. Eaton and Memon [10] describe the challenges of web testing, in general. This chapter differs from Eaton and Memon’s study on web testing because we focus on user-session-based testing whereas Eaton and Memon studied the different model-based testing approaches for web application testing.

SQL Server 2000 Overview and Migration Strategies

The Future of Windows DNA: Microsoft.NET

In 1997, Microsoft announced the Windows Distributed interNet Applications (DNA) Architecture Model, which la >Active Server Pages (ASP), standard Web browser software such as Internet Explorer or Netscape Navigator, protocols including HyperText Transfer Protocol (HTTP), and enabling technologies such as Component Object Model (COM) and Data Access (ActiveX Data Objects, OLE DB). Via standard Web browser software, users are allowed access to DNA applications with little if any need for configuration of the client. Application services are centrally managed and delivered from the enterprise for enhanced reliability, scalability, and performance. This popular application architecture model accounted for roughly 40 percent of all secure, transacted Web-based applications built by the end of 1999.

The DNA Architecture Model is logically divided into three layers: Presentation Services, Business Services, and Data Services. Each layer plays a specific role in the application, as depicted in Figure 1.1 .

Figure 1.1 . The DNA Architecture Model.

The Presentation Services layer encompasses the Web browser and client-side services such as HyperText Markup Language (HTML) to interpret and display Web pages, VBScript, and JavaScript for user input validation, Dynamic HTML (DHTML) for interface enhancements, and Java Applets or ActiveX Components for enhanced client-side functionality. The Business Services layer is responsible for much of the “work” in the application and handles tasks such as processing user input, applying business rules and application logic, validating data in and out of the Data Services layer, and delivering the application to the Presentation Services layer. The third layer of the DNA model is Data Services, which is responsible for storing and managing all types of information, including databases, document storage, e-mail, and directory services data.

Now that you have a basic idea of the principles behind the DNA Model, we can discuss the Windows DNA Platform. The DNA Platform is the collection of software products, technologies, and tools that are used to physically build, host, and manage DNA applications. Having a conceptual model makes the theory of scalable, reliable, Web-based applications understandable, but to make it a reality, you need to be able to actually construct the layers to form your application. The Windows DNA Platform has continued to evolve as Microsoft releases new versions of existing products and adds entirely new product lines to the server, technology, and tools families. Today, the DNA Platform is made up of:

Microsoft Windows NT 4.0/2000 Server ■

Internet Information Server/Services (IIS4/IIS5)

Message Queue Server (MSMQ)

Data Access (ActiveX Data Objects, OLE-DB, ODBC)

Network Load Balancing

Microsoft SQL Server 7.0

Microsoft Exchange Server 5.5

Microsoft SNA Server 4.0

Microsoft Site Server 3.0 Commerce Edition

Microsoft Visual Studio 6.0

Before we get into reviewing the responsibilities of each of these components, we should clarify how Windows DNA 2000 fits into all this. Windows DNA 2000 is the short-lived name for what is now called the Microsoft.NET Enterprise Servers. As Windows DNA evolves in to Microsoft.NET as the architecture model for scalable, reliable, Web-based applications and services, the Windows DNA Platform evolves into the .NET Enterprise Servers. The line of .NET Enterprise Servers consists of:

Microsoft Windows 2000 Server Prov > ■

Active Directory Services

Internet Information Services (IIS)

Active Server Pages + (with the release of .NET)

Message Queue Server (MSMQ)

Data Access (ActiveX Data Objects +, OLE-DB, ODBC)

Network Load Balancing

Microsoft SQL Server 2000 RDBMS offers data storage, management, and analysis services. Provides XML support and Active Directory integration.

Microsoft Exchange Server 2000 Provides messaging and collaboration services such as e-mail, videoconferencing, and instant messaging. Provides Active Directory integration.

Microsoft Host Integration Server 2000 Offers access to legacy systems for information exchange, allowing integration with new technologies.

Microsoft Commerce Server 2000 Provides the services for implementing and managing electronic commerce Web sites on the Microsoft platform.

Microsoft BizTalk Server 2000 Offers the frameworks necessary to facilitate data communications between heterogeneous systems using standards-based formats such as XML.

Microsoft Application Center 2000 Provides the centralized management of distributed applications across multiple servers for scalability and reliability.

Microsoft Internet Security and Acceleration Server 2000 Provides enterprise-class firewall and Web cache for enterprise security and Web access performance.

Microsoft Mobile Information Server 2001 Although not scheduled to be available until 2001, Mobile Information Server supports delivering Wireless Application Protocol (WAP) and HTML to portable devices such as cellular phones and personal digital assistants (PDAs).

Microsoft Visual Studio.NET Provides the tools and languages necessary to build applications using the .NET architecture components. The .NET programming architecture supported by Visual Studio.NET includes VB.NET, Active Server Pages +, ActiveX Data Objects +, and C# as well as C++. Missing from Visual Studio.NET is Visual InterDev. Microsoft Visual Studio.NET will incorporate a cross-language development environment with Web application integration throughout all Microsoft technologies, so the dedicated role of Visual InterDev is no longer necessary for Web programming.

Each of these server applications, technologies, and development tools plays a key role in delivering applications based on .NET. Microsoft has officially labeled .NET its vision for the next-generation Internet. What does all this mean for DNA developers and solutions built on the DNA platform? It means many exciting technology advancements and extensions to the original DNA architecture model.

What .NET is not is a replacement or shift away from the practiced and sound foundations of the DNA Architecture Model. .NET offers enhancements in many of the technologies with which developers currently work within their applications, including new versions of Active Server Pages, called ASP + or Web Forms, and ActiveX Data Objects, called ADO +. Web Forms offer long-overdue validation services and advanced, server-side controls supporting events for building rich HTML-compliant application interfaces. Page logic is now separated from the HTML and compiled for better performance, and a common language runtime will allow developers to choose and mix their preferred languages with complete compatibility. Microsoft’s commitment to Win32 applications continues with Win Forms, the Win32 counterpart to Web Forms. Although the object models between the two are not the same, this unique approach to offering a comparable design model between Web applications and Windows applications will allow developers to migrate between platforms with a comfortable approach to writing code that has a higher level of productivity and developer availability.

All these enhancements are exciting for Web application designers and developers, but there is even more to .NET than the next version of these existing technologies. One of the core principles of .NET is the delivery of Web services to rapidly create powerful applications by integrating available services from within the organization and throughout the Internet. This web of interconnected applications and services is the core of .NET. To accomplish this web, .NET implements abundant use of XML and Simple Object Access Protocol (SOAP). SOAP and XML are both industry-standard technologies, which open the door for heterogeneous system communications. These new services can exist and run on any platform and be used by any application running on the platform of the developer’s choice. Figure 1.2 illustrates the new vision in .NET.

Figure 1.2 . The .NET Framework Model.

The .NET Frameworks example extends the principles of DNA by prov > development and management time. Features such as Common Language Runtime leverage the broad range of developer skill sets, allowing complete support for mixed-language environments. Exchange of information with business partners and other organizations is possible using industry-standard technologies, XML, and SOAP. The ability even exists to expose and share components of the application with other organizations through Web services. Components such as order entry or product information are made available for integration into business partner systems and remote applications. .NET represents the next generation in distributed, reusable, and shared application architecture models.

So where does this leave SQL Server 2000 in the .NET world? As in nearly all applications, data storage and management are central to application functionality and availability. SQL Server 2000 offers these traditional services and adds compelling new features such as native support for using and delivering XML documents, support for standard Internet protocols such as HTTP and Secure Sockets Layer (SSL) for secure Web access to SQL databases, and OLAP services, along with numerous scalability and performance enhancements. All these together make SQL Server 2000 the sole container of information in your existing DNA and future .NET applications.

Distributed File System (Microsoft)

Distributed File System (DFS) is a set of client and server services that allow an organization using Microsoft Windows servers to organize many distributed SMB file shares into a distributed file system. DFS provides location transparency and redundancy to improve data availability in the face of failure or heavy load by allowing shares in multiple different locations to be logically grouped under one folder, or DFS root.

Microsoft’s DFS is referred to interchangeably as ‘DFS’ and ‘Dfs’ by Microsoft and is unrelated to the DCE Distributed File System, which held the ‘DFS’ trademark [1] but was discontinued in 2005. [2]

It is called «SMB/CIFS» in some contexts, such as the Open Source OpenSolaris kernel space project [3] . It is also called «MS-DFS» or «MSDFS» in other contexts, e.g. in the Samba user space project.

Overview

DFS has two major logical components. Firstly, DFS namespaces provide an abstraction layer for SMB network file shares, allowing one logical network path to be served by multiple physical file servers. Secondly, DFS supports the replication of data between the servers, using File Replication Service (FRS) in server versions up to Server 2003, and using «DFS Replication» (DFSR) in Server 2003 R2, Server 2008, and later versions.

There is no requirement to use the two components of DFS together; it is perfectly possible to use the logical namespace component without using DFS file replication, and it is perfectly possible to use file replication between servers without combining them into one namespace.

A DFS root can only exist on a server version of Windows (from Windows NT 4.0 and up) and OpenSolaris [4] (in kernel space) or a computer running Samba (in user space.) The Enterprise and Datacenter Editions of Windows Server can host multiple DFS roots on the same server. OpenSolaris intends on supporting multiple DFS roots in «a future project based on Active Directory (AD) domain-based DFS namespaces». [5]

There are two ways of implementing DFS on a server:

  • Standalone DFS roots allow for a DFS root that exists only on the local computer, and thus does not use Active Directory. A Standalone DFS can only be accessed on the computer on which it is created. It doesn’t offer any fault tolerance and cannot be linked to any other DFS. This is the only option available on Windows NT 4.0 Server systems. Standalone DFS roots are somewhat rarely encountered because of their limited utility.
  • Domain-based DFS roots exist within Active Directory and can have their information distributed to other domain controllers within the domain — this prov > DFS Namespaces

Traditional file shares, associated with a single server, have SMB paths of the form \\ \

\ . Domain-based DFS file share paths are distinguished by using the domain name in place of the server name, in the form \\ \ \

. When a user access such a share, either directly or by mapping a drive, their computer will access one of the available servers associated with that share, following rules which can be configured by the network administrator. For example, the default behavior is that users will access the closest server to them; but this can be overridden to prefer a particular server.

If a server fails, the client can select a different server transparently to the user. One major caveat regarding this flexibility is that currently-open files will potentially become unusable, as open files cannot be failed-over.

DFS Replication

Early versions of DFS used FRS which provides basic file replication capability between servers. FRS identifies changed or new files, and copies the latest version of the entire file to all servers.

Windows Server 2003 R2 introduced «DFS Replication» (DFSR) which improves on FRS by only copying those parts of files which have changed, by using data compression to reduce network traffic, and by allowing administrators flexible configuration options for limiting network traffic with a weekly schedule.

History

The server component of Distributed File System was first introduced as an add-on to Windows NT 4.0 Server, called «DFS 4.1», [6] and was later included as a standard component of all editions of Windows 2000 Server. Windows NT 4.0 and later include client-s >[7] of the Linux kernel come with an SMB client VFS called «cifs» that supports DFS.

Установка и конфигурирование IIS

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

В этой и следующих статьях мы рассмотрим различные варианты развертывания. Однако во всех случаях основные предпосылки остаются неизменными. На рабочей станции имеется готовый веб-сайт, который нужно развернуть на сервере, чтобы он был доступен клиентам. Для ASP.NET таким сервером является , а его текущей версией — IIS 8. Когда он был впервые реализован, IIS представлял собой базовый веб-сервер. С годами IIS развился в сложный сервер приложений, предоставляющий широкое множество функциональных средств, наиболее важным из которых является поддержка хостинга приложений ASP.NET.

В этой статье основное внимание уделяется IIS 8. Хотя машина, на которой запущен IIS 8, здесь называется сервером, IIS можно запускать под управлением версий Windows как для рабочей станции, так и для сервера. На рабочих станциях доступны не все, но большинство функциональных возможностей, что позволяет размещать сложные веб-сайты. По возможности мы рекомендуем использовать Windows Server, однако недорогой альтернативой могут послужить Windows 7 или Windows 8.

В Microsoft привязывают выпуски IIS с выпусками Windows. В состав Windows Server 2008 и Windows Vista входит версия IIS 7.0, в состав Windows Server 2008 R2 и Windows 7 — версия IIS 7.5, а в состав Windows Server 2012 и Windows 8 — IIS 8. Версии — 7.0 и 7.5 — в Microsoft обобщенно называют IIS 7, что может вносить путаницу. Версию IIS, поддерживаемую операционной системой, изменить нельзя — Windows Server 2008 будет использовать только IIS 7.0. Например, модернизировать ее до версии IIS 7.5, используемой в Windows Server 2008 R2, не получится.

Установка IIS

Компонент IIS включен как часть установки Windows (как для сервера, так и для рабочих станций) и требует активизации и конфигурирования. Далее представлены три способа активации IIS для различных операционных систем.

Установка IIS на настольных версиях Windows (Windows Vista, Windows 7 и Windows 8)

Каждая версия операционной системы Windows предлагает свою версию IIS — IIS 8 (в Windows 8), IIS 7.5 (в Windows 7) или IIS 7 (в Windows Vista). Во всех этих версиях Windows, IIS включен, но изначально не установлен. Чтобы установить его, необходимо выполнить следующие действия:

Откройте панель управления.

Нажмите кнопку «Включение или отключение компонентов Windows». Теперь вам нужно подождать, пока Windows исследует вашу систему.

Найдите элемент Internet Information Services (Службы IIS) в верхней части списка и нажмите на галочку чтобы включить его:

Обратите внимание, что Windows позволяет включить множество компонентов IIS: поддержка FTP-сервера, дополнительные инструменты управления, службы обратной совместимости с IIS 6 и т.д.

Убедитесь, что вы выбрали поддержку ASP.NET. Для этого раскройте узел Службы Интернета Компоненты разработки приложений ASP.NET (Internet Information Services World Wide Web Services Application Development Features ASP.NET):

Если вы хотите использовать поддержку IIS в Visual Studio, которая позволяет вам создавать виртуальные каталоги IIS непосредственно в диалоговом окне New Web Site, вам нужно выбрать пункт «Совместимость управления IIS 6» в разделе «Средства управления веб-сайтом» (Web Management Tools IIS 6 Management Compatibility).

Как только вы выбрали нужные параметры IIS, нажмите кнопку OK для завершения установки.

Установка IIS в Windows Server 2008

Установка и настройка IIS одинакова для Windows Server 2008 и Windows Server 2008 R2. Необходимые шаги описаны ниже:

Запустите диспетчер сервера. Чтобы сделать это, нажмите кнопку Start и выберите All Programs Administrative Tools Server Manager.

Выберите узел Roles в дереве слева.

В правой части окна нажмите на ссылке Add Roles. Это открывает мастер, позволяющий добавить новую роль сервера.

Выполните необходимые действия в мастере. Вас вероятно попросят установить дополнительные необходимые роли — если это так, нужно просто принять операции и продолжить.

После установки вам будет предложено настроить веб-сервер. Как в настольных версиях Windows, вы можете выбрать специфические особенности IIS 7, которые должны быть включены.

Если вы работаете в ASP.NET с версией .NET Framework 4.5, то эту версию .NET Framework необходимо будет установить (центр разработчиков .NET Framework)

Установка IIS в Windows Server 2012

Процесс установки IIS в Windows Server 2012, по существу, такой же, как и в Windows Server 2008. Основное различие заключается в том, что пользовательский интерфейс несколько отличается. Подробное описание вы можете найти перейдя по ссылке Installing IIS 8 on Windows Server 2012.

Управление IIS

При установке IIS, он автоматически создает каталог с именем C:\inetpub\wwwroot, который представляет ваш веб-сайт. Все файлы в этом каталоге будет отображаться, как будто они находятся в корневом каталоге вашего веб-сервера.

Чтобы добавить дополнительные страницы на ваш веб-сервер, можно скопировать файлы HTML, ASP или ASP.NET напрямую в каталог C:\Inetpub\wwwroot. Например если добавить файл TestFile.html в этот каталог, вы можете запросить его в браузере через URL-адрес http://localhost/TestFile.html. Вы даже можете создавать вложенные папки для группирования связанных ресурсов. Например, вы можете получить доступ к C:\inetpub\wwwroot\MySite\MyFile.html через браузер, используя URL-адрес http://localhost/MySite/MyFile.html.

Каталог wwwroot удобен для запуска простых примеров и статичных страниц. Для правильного использования ASP.NET вы должны сделать свой собственный виртуальный каталог для каждого веб-приложения, которое вы создаете. Например, вы можете создать папку с любым именем на любом диске вашего компьютера и поместить ее в виртуальный каталог IIS как будто она расположена в каталоге C:\inetpub\wwwroot.

Прежде чем начать работу, вам нужно запустить диспетчер служб IIS. Его можно найти в меню Start (Пуск). Конкретное расположение может зависеть от используемой версии Windows (IIS Диспетчер служб IIS). Ярлык программы будет располагаться в разделе Programs (Программы) или Administrative Tools (Администрирование). Начальная страница IIS Manager показана на рисунке ниже:

Теперь нужно ознакомиться с рядом терминов, используемых в IIS. В левой части окна IIS Manager отображается запись с именем используемого сервера. Наш сервер имеет имя PROFESSORWEB, сгенерированное по умолчанию Windows 8, которое будет использоваться в большинстве примеров. В центральной области отображается представление сервера. Это представление отображает набор значков, которые позволяют конфигурировать параметры сервера. В правой части экрана расположен список доступных действий. Например, в этом представлении можно запускать, останавливать и перезапускать сервер.

Если развернуть элемент сервера в древовидном представлении в левой части экрана, отобразится элемент Sites (Сайты), содержащий единственную запись Default Web Site (Веб-сайт по умолчанию). Сайт — это коллекция файлов и каталогов, образующих веб-сайт. На одном сервере IIS может поддерживать несколько сайтов, как правило, на различных портах TCP/IP (по умолчанию используется порт 80). Сочетание имени сервера и порта сайта образует первую часть URL-адреса. Например, при использовании сервера mywebserver с сайтом, подключенным к порту 80, URL-адрес выглядит следующим образом:

Каждый сайт может содержать множество файлов и каталогов. Каждый из них образует часть URL-адреса. Так, URL-адрес статической страницы mypage.html, расположенной в каталоге myfiles, будет следующим:

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

Чтобы проверить работоспособность IIS выберите Default Web Site и в правой области диспетчера служб IIS выберите пункт «Запустить». После этого нажмите кнопку «Обзор *.80 (http)» чтобы открыть страницу сайта в браузере:

Как видите, в моем случае я поменял порт используемый по умолчанию (с 80 на 8080). Я сделал это, т.к. на 80-м у меня запущен локальный Apache-сервер. Если у вас возникает такая же проблема, то изменить порт можно щелкнув правой кнопкой мыши по сайту (Default Web Site) и выбрав в контекстном меню «Изменить привязки» (Bindings). После этого в диалоговом окне можно изменить порт, используемый по умолчанию.

Итак, каждый сервер может поддерживать множество сайтов, каждый из которых работает на другом порту или с другим IP-адресом. Каждый сайт может иметь множество файлов и каталогов, и сочетание этих элементов предоставляет информацию о URL-адресе. Мы вернемся к URL-адресам и использованию IIS Manager при рассмотрении каждого из подходов к развертыванию.

Принципы работы и структура Web-приложений на основе ASP.NET

Цель лекции: познакомиться с архитектурой и особенностями организации Web-приложений, особенностями архитектуры ASP . NET и . NET Framework, принципами взаимодействия клиента и сервера при выполнении Web-приложения на основе ASP . NET .

Архитектура Web-приложений

Web-приложения представляют собой особый тип программ, построенных по архитектуре «клиент- сервер «. Особенность их заключается в том, что само Web- приложение находится и выполняется на сервере — клиент при этом получает только результаты работы. Работа приложения основывается на получении запросов от пользователя (клиента), их обработке и выдачи результата. Передача запросов и результатов их обработки происходит через Интернет ( рис. 1.1).

Отображением результатов запросов, а также приемом данных от клиента и их передачей на сервер обычно занимается специальное приложение — браузер ( Internet Explorer, Mozilla, Opera и т. д.). Как известно, одной из функций браузера является отображение данных, полученных из Интернета, в виде страницы, описанной на языке HTML , следовательно, результат, передаваемый сервером клиенту, должен быть представлен на этом языке.

На стороне сервера Web- приложение выполняется специальным программным обеспечением (Web-сервером), который и принимает запросы клиентов, обрабатывает их, формирует ответ в виде страницы, описанной на языке HTML , и передает его клиенту. Одним из таких Web-серверов является Internet Information Services ( IIS ) компании Microsoft. Это единственный Web- сервер , который способен выполнять Web-приложения, созданные с использованием технологии ASP . NET .

В процессе обработки запроса пользователя Web- приложение компонует ответ на основе исполнения программного кода, работающего на стороне сервера, Web-формы, страницы HTML , другого содержимого, включая графические файлы. В результате, как уже было сказано, формируется HTML -страница, которая и отправляется клиенту. Получается, что результат работы Web-приложения идентичен результату запроса к традиционному Web-сайту, однако, в отличие от него, Web- приложение генерирует HTML -код в зависимости от запроса пользователя, а не просто передает его клиенту в том виде, в котором этот код хранится в файле на стороне сервера. То есть Web- приложение динамически формирует ответ с помощью исполняемого кода — так называемой исполняемой части.

За счет наличия исполняемой части, Web-приложения способны выполнять практически те же операции , что и обычные Windows -приложения, с тем лишь ограничением, что код исполняется на сервере, в качестве интерфейса системы выступает браузер , а в качестве среды, посредством которой происходит обмен данными , — Интернет . К наиболее типичным операциям, выполняемым Web-приложениями, относятся:

Илон Маск рекомендует:  Как программно вставить изображение в excel
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL