Asp разработка масштабируемых компонентов

Asp разработка масштабируемых компонентов

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

Для начала имеет смысл определиться с тем, о чем мы вообще будем говорить. В данном контексте перед веб-приложением ставятся три основные цели:

• масштабируемость — способность своевременно реагировать на непрерывный рост нагрузки и непредвиденные наплывы пользователей;
• доступность — предоставление доступа к приложению даже в случае чрезвычайных обстоятельств;
• производительность — даже малейшая задержка в загрузке страницы может оставить негативное впечатление у пользователя.

Основной темой разговора будет, как не трудно догадаться, масштабируемость, но и остальные цели не думаю, что останутся в стороне. Сразу хочется сказать пару слов про доступность, чтобы не возвращаться к этому позднее, подразумевая как «само собой разумеется»: любой сайт так или иначе стремится к тому, чтобы функционировать максимально стабильно, то есть быть доступным абсолютно всем своим потенциальным посетителям в абсолютно каждый момент времени, но порой случаются всякие непредвиденные ситуации, которые могут стать причиной временной недоступности. Для минимизации потенциального ущерба доступности приложения необходимо избегать наличия компонентов в системе, потенциальный сбой в которых привел бы к недоступности какой-либо функциональности или данных (или хотябы сайта в целом). Таким образом каждый сервер или любой другой компонент системы должен иметь хотябы одного дублера (не важно в каком режиме они будут работать: параллельно или один «подстраховывает» другой, находясь при этом в пассивном режиме), а данные должны быть реплицированы как минимум в двух экземплярах (причем желательно не на уровне RAID, а на разных физических машинах). Хранение нескольких резервных копий данных где-то отдельно от основной системы (например на специальных сервисах или на отдельном кластере) также поможет избежать многих проблем, если что-то пойдет не так. Не стоит забывать и о финансовой стороне вопроса: подстраховка на случай сбоев требует дополнительных существенных вложений в оборудование, которые имеет смысл стараться минимизировать.

Масштабируемость принято разделять на два направления:

Вертикальная масштабируемость Увеличение производительности каждого компонента системы c целью повышения общей производительности. Горизонтальная масштабируемость Разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (или их группам) и/или увеличение количества серверов параллельно выполняющих одну и ту же функцию.

Так или иначе, при разработке стратегии роста системы приходится искать компромис между ценой, временем разработки, итоговой производительность, стабильностью и еще массой других критериев. С финансовой точки зрения вертикальная масштабируемость является далеко не самым привлекательным решением, ведь цены на сервера с большим количеством процессоров всегда растут практически экспоненциально относительно количества процессоров. Именно по-этому наиболее интересен горизонтальный подход, так как именно он используется в большинстве случаев. Но и вертикальная масштабируемость порой имеет право на существование, особенно в ситуациях, когда основную роль играет время и скорость решения задачи, а не финансовый вопрос: ведь купить БОЛЬШОЙ сервер существенно быстрее, чем практически заново разрабатывать приложения, адаптируя его к работе на большом количестве параллельно работающих серверов.

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

Серверы приложений

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

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

Балансировка нагрузки

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

Оборудование Сетевое оборудование, позволяющее распределять нагрузку между несколькими серверами, обычно стоит достаточно внушительные суммы, но среди прочих вариантов обычно именно этот подход предлагает наивысшую производительность и стабильность (в основном благодаря качеству, плюс такое оборудование иногда поставляется парами, работающими по принципу HeartBeat). В этой индустрии достаточно много серьезных брендов, предлагающих свои решения — есть из чего выбрать: Cisco, Foundry, NetScalar и многие другие. Программное обеспечение В этой области еще большее разнообразие возможных вариантов. Получить программно производительность сопоставимую с аппаратными решениями не так-то просто, да и HeartBeat придется обеспечивать программно, но зато оборудование для функционирования такого решения представляет собой обычный сервер (возможно не один). Таких программных продуктов достаточно много, обычно они представляют собой просто HTTP-серверы, перенаправляющие запросы своим коллегам на других серверах вместо отправки напрямую на обработку интерпретатору языка программирования. Для примера можно упомянуть, скажем, nginx с mod_proxy . Помимо этого имеют место более экзотические варианты, основанные на DNS, то есть в процессе определения клиентом IP-адреса сервера с необходимым ему интернет-ресурсов адрес выдается с учетом нагрузки на доступные сервера, а также некоторых географических соображений.

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

Ресурсоемкие вычисления

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

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

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

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

Сессии

Практически все веб-приложения каким-либо образом взаимодействуют со своими посетителями и в подавляющем большинстве случаев в них присутствует необходимость отслеживать перемещения пользователей по страницам сайта. Для решения этой задачи обычно используется механизм сессий, который заключается в присвоении каждому посетителю уникального идентификационного номера, который ему передается для хранения в cookies или, в случае их отсутствия, для постоянного «таскания» за собой через GET. Получив от пользователя некий ID вместе с очередным HTTP-запросом сервер может посмотреть в список уже выданных номеров и однозначно определить кто его отправил. С каждым ID может ассоциироваться некий набор данных, который веб-приложение может использовать по своему усмотрению, эти данные обычно по-умолчанию хранятся в файле во временной директории на сервере.

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

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

Централизованное хранение сессий Идея проста: создать для всех серверов общую «копилку», куда они смогут складывать выданные ими сессии и узнавать о сессиях посетителей других серверов. В роли такой «копилки» теоретически может выступать и просто примонтированная по сети файловая система, но по некоторым причинам более перспективным выглядит использование какой-либо СУБД, так как это избавляет от массы проблем, связанных с хранением сессионных данных в файлах. Но в варианте с общей базой данных не стоит забывать, что нагрузка на него будет неуклонно расти с ростом количества посетителей, а также стоит заранее предусмотреть варианты выхода из проблематичных ситуаций, связанных с потенциальными сбоями в работе сервера с этой СУБД. Децентрализованное хранение сессий Наглядный пример — хранение сессий в memcached, изначально расчитанная на распределенное хранение данных в оперативной памяти система позволит получать всем серверам быстрый доступ к любым сессионным данным, но при этом (в отличии от предыдущего способа) какой-либо единый центр их хранения будет отсутствовать. Это позволит избежать узких мест с точек зрения производительности и стабильности в периоды повышенных нагрузок.

В качестве альтернативы сессиям иногда используют похожие по предназначению механизмы, построенные на cookies, то есть все необходимые приложению данные о пользователе хранятся на клиентской стороне (вероятно в зашифрованном виде) и запрашиваются по мере необходимости. Но помимо очевидных преимуществ, связанных с отсутствием необходимости хранить лишние данные на сервере, возникает ряд проблем с безопасностью. Данные, хранимые на стороне клиента даже в зашифрованном виде, представляют собой потенциальную угрозу для функционирования многих приложений, так как любой желающий может попытаться модифицировать их в своих интересах или с целью навредить приложению. Такой подход хорош только если есть уверенность, что абсолютно любые манипуляции с хранимые у пользователей данными безопасны. Но можно ли быть уверенными на 100%?

Статический контент

Пока объемы статических данных невелики — никто не мешает хранить их в локальной файловой системе и предоставлять доступ к ним просто через отдельный легковесный веб-сервер вроде lighttpd (я подразумеваю в основном разные формы медиа-данных), но рано или поздно лимит сервера по дисковому пространству или файловой системы по количеству файлов в одной директории будет достигнут, и придется думать о перераспределении контента. Временным решением может стать распределение данных по их типу на разные сервера, или, возможно, использование иерархической структуры каталогов.

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

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

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

Кэширование

Кэширование имеет смысл проводить на всех этапах обработки данных, но в разных типах приложений наиболее эффективными являются лишь некоторые методы кэширования.

СУБД Практически все современные СУБД предоставляют встроенные механизмы для кэширования результатов определенных запросов. Этот метод достаточно эффективен, если Ваша система регулярно делает одни и те же выборки данных, но также имеет ряд недостатков, основными из которых является инвалидация кэша всей таблицы при малейшем ее изменении, а также локальное расположение кэша, что неэффективно при наличии нескольких серверов в системе хранения данных. Приложение На уровне приложений обычно производится кэширование объектов любого языка программирования. Этот метод позволяет вовсе избежать существенной части запросов к СУБД, сильно снижая нагрузку на нее. Как и сами приложения такой кэш должен быть независим от конкретного запроса и сервера, на котором он выполняется, то есть быть доступным всем серверам приложений одновременно, а еще лучше — быть распределенным по нескольким машинам для более эффективной утилизации оперативной памяти. Лидером в этом аспекте кэширования по праву можно назвать memcached, о котором я в свое время уже успел подробно рассказать. HTTP-сервер Многие веб-серверы имеют модули для кэширования как статического контента, так и результатов работы скриптов. Если страница редко обновляется, то использование этого метода позволяет без каких-либо видимых для пользователя изменений избегать генерации страницы в ответ на достаточно большую часть запросов. Reverse proxy Поставив между пользователем и веб-сервером прозрачный прокси-сервер, можно выдавать пользователю данные из кэша прокси (который может быть как в оперативной памяти, так и дисковым), не доводя запросы даже до HTTP-серверов. В большинстве случаев этот подход актуален только для статического контента, в основном разных форм медиа-данных: изображений, видео и тому подобного. Это позволяет веб-серверам сосредоточиться только на работе с самими страницами.

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

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

Базы данных

На закуску я оставил самое интересное, ведь этот неотъемлемый компонент любого веб-приложения вызывает больше проблем при росте нагрузок, чем все остальные вместе взятые. Порой даже может показаться, что стоит вообще отказаться от горизонтального масштабирования системы хранения данных в пользу вертикального — просто купить тот самый БОЛЬШОЙ сервер за шести- или семизначную сумму не-рублей и не забивать себе голову лишними проблемами.

Но для многих проектов такое кардинальное решение (и то, по большому счету, временное) не подходит, а значит перед ними осталась лишь одна дорога — горизонтальное масштабирование. О ней и поговорим.

Путь практически любого веб проекта с точки зрения баз данных начинался с одного простого сервера, на котором работал весь проект целиком. Затем в один прекрасный момент наступает необходимость вынести СУБД на отдельный сервер, но и он со временем начинает не справляться с нагрузкой. Подробно останавливаться на этих двух этапах смысла особого нет — все относительно тривиально.

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

Временным решением этой проблемы, возможно, может стать замена master-сервера на более производительный, но так или иначе не выйдет бесконечно откладывать переход на следующий «уровень» развития системы хранения данных: «sharding», которому я совсем недавно посвятил отдельный пост «Сегментирование баз данных». Так что позволю себе остановиться на нем лишь вкратце: идея заключается в том, чтобы разделить все данные на части по какому-либо признаку и хранить каждую часть на отдельном сервере или кластере, такую часть данных в совокупности с системой хранения данных, в которой она находится, и называют сегментом или shard’ом. Такой подход позволяет избежать издержек, связанных с реплицированием данных (или сократить их во много раз), а значит и существенно увеличить общую производительность системы хранения данных. Но, к сожалению, переход к этой схеме организации данных требует массу издержек другого рода. Так как готового решения для ее реализации не существует, приходится модифицировать логику приложения или добавлять дополнительную «прослойку» между приложением и СУБД, причем все это чаще всего реализуется силами разработчиков проекта. Готовые продукты способны лишь облегчить их работу, предоставив некий каркас для построения основной архитектуры системы хранения данных и ее взаимодействия с остальными компонентами приложения.

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

Денормализация Запросы, комбинирующие данные из нескольких таблиц, обычно при прочих равных требуют большего процессорного времени для выполнения, чем запрос, затрагивающий лишь одну таблицу. А производительность, как уже упоминалось в начале повествования, чрезвычайно важна на просторах Сети. Логическое разбиение данных Если какая-то часть данных всегда используется отдельно от основной массы, то иногда имеет смысл выделить ее в отдельную независимую систему хранения данных. Низкоуровневая оптимизация запросов Ведя и анализируя логи запросов, можно определить наиболее медленные из них. Замена найденных запросов на более эффективные с той же функциональностью может помочь более рационально использовать вычислительные мощности.

В этом разделе стоит упомянуть еще один, более специфический, тип интернет-проектов. Такие проекты оперируют данными, не имеющими четко формализованную структуру, в таких ситуациях использование реляционных СУБД в качестве хранилища данных, мягко говоря, нецелесообразно. В этих случаях обычно используют менее строгие базы данных, с более примитивной функциональностью в плане обработки данных, но зато они способны обрабатывать огромные объемы информации не придираясь к его качеству и соответствию формату. В качестве основы для такого хранилища данных может служить кластерная файловая система, а для анализа же данных в таком случае используется механизм под названием MapReduce, принцип его работы я расскажу лишь вкратце, так как в полном своем масштабе он несколько выходит за рамки данного повествования.

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

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

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

Примером готового каркаса для реализации работы с данными по такому принципу служит opensource проект Apache Foundation под названием Hadoop, о котором я уже неоднократно рассказывал ранее, да и статейку в Википедию написал в свое время.

Вместо заключения

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

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

Масштабируемая Веб-архитектура и распределенные системы

1.3. Структурные компоненты быстрого и масштабируемого доступа к данным

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

Самые простые веб-приложения, например, приложения стека LAMP, схожи с изображением на рисунке 1.5.

Рисунок 1.5: Простые веб-приложения

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

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

Рисунок 1.6: Упрощенное веб-приложение

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

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

Рисунок 1.7: Доступ к определенным данным

Это особенно трудно, потому что загрузка терабайтов данных в память может быть очень накладной и непосредственно влияет на количество дисковых операций ввода-вывода. Скорость чтения с диска в несколько раз ниже скорости чтения из оперативной памяти — можно сказать, что доступ к памяти с так же быстр, как Чак Норрис, тогда как доступ к диску медленнее очереди в поликлинике. Эта разность в скорости особенно ощутима для больших наборов данных; в сухих цифрах доступ к памяти 6 раз быстрее, чем чтение с диска для последовательных операций чтения, и в 100,000 раз — для чтений в случайном порядке (см. «Патологии Больших Данных», http://queue.acm.org/detail.cfm? >
К счастью существует много подходов, которые можно применить для упрощения, из них четыре наиболее важных подхода — это использование кэшей, прокси, индексов и балансировщиков нагрузки. В оставшейся части этого раздела обсуждается то, как каждое из этих понятий может быть использовано для того, чтобы сделать доступ к данным намного быстрее.

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

Каким же образом кэш может использоваться для ускорения доступа к данным в рамках нашего примера API? В этом случае существует несколько мест, подходящих размещения кэша. В качестве одного из возможных вариантов размещения можно выбрать узлы на уровне запроса, как показано на
рисунке 1.8.

Рисунок 1.8: Размещение кэша на узле уровня запроса

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

Рисунок 1.9: Системы кэшей

Что происходит, когда вы распространяете кеширование на множество узлов? Как Вы видите в рисунке 1.9, если уровень запроса будет включать множество узлов, то вполне вероятно, что каждый узел будет и свой собственный кэш. Однако, если ваш балансировщик нагрузки в произвольном порядке распределит запросы между узлами, то тот же запрос перейдет к различным узлам, таким образом увеличивая неудачные обращения в кэш. Двумя способами преодоления этого препятствия являются глобальные и распределенные кэши.

Глобальный кэш

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

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

Рисунок 1.10: Глобальный кэш, где кэш ответственен за извлечение

Рисунок 1.11: Глобальный кэш, где узлы запроса ответственны за извлечение
Большинство приложений, усиливающих глобальные кэши, склонно использовать первый тип, где сам кэш управляет замещением и данными выборки, чтобы предотвратить лавинную рассылку запросов на те же данные от клиентов. Однако, есть некоторые случаи, где вторая реализация имеет больше смысла. Например, если кэш используется для очень больших файлов, низкий процент удачного обращения в кэш приведет к перегрузке кэша буфера неудачными обращениями в кэш; в этой ситуации это помогает иметь большой процент общего набора данных (или горячего набора данных) в кэше. Другой пример — архитектура, где файлы, хранящиеся в кэше, статичны и не должны быть удалены. (Это может произойти из-за основных эксплуатационных характеристик касательно такой задержки данных — возможно, определенные части данных должны оказаться очень быстрыми для больших наборов данных — когда логика приложения понимает стратегию замещения или горячие точки лучше, чем кэш.)

Распределенный кэш

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

Недостаток распределенного кэширования — работа в условиях недостающих узлов. Некоторые распределенные кэши обходят эту проблему, храня избыточные копии данных на множестве узлов; однако, можно представить, насколько быстро логическая структура такого кэша может сложной, особенно в условиях добавления или удаления узлов из уровня запроса. Стоит отметить — даже если узел исчезает, и часть кэша будет потеряна, последствия необязательно окажутся катастрофическими — запросы просто получат данные непосредственно от источника!

Рисунок 1.12: Распределенный кэш.

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

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

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

Facebook использует несколько различных типов кэширования, чтобы добиться высокой производительности своего сайта (см., «Facebook: кэширование и производительность» ). Они используют $GLOBALS и APC, кэширующие на уровне языка (представленные в PHP за счет вызова функции), который способствует ускорению промежуточных вызовов функции и получению результатов. (Большинство языков оснащены этими типами библиотек для улучшения производительность веб-страницы, и они почти всегда должны использоваться.) Кроме того Facebook использует глобальный кэш, который распределен на множество серверов (см. » Масштабирование memcached в Facebook» ), таким образом, что один вызов функции, получающий доступ к кэшу, мог параллельно выполнить множество запросов для данных, хранящихся на различных серверах Memcached. Такой подход позволяет добиться намного более высокой производительности и пропускной способности для данных профиля пользователя, и создать централизованную архитектуру обновления данных. Это важно, так как, при наличии тысяч серверов, функции аннулирования и поддержания непротиворечивости кэша могут вызывать затруднение.

Далее речь пойдет об алгоритме действий в случае отсутствия данных в кэше.

Asp разработка масштабируемых компонентов

Как Создать Высоконагруженный Сайт и его Архитектуру

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

Full stack web developer

Содержание

Если вы решили создать крупный проект, перед началом проектирования подумайте о масштабировании. Это позволит избежать многих проблем. Английская версия статьи how build scalable web applications. Если вы планируете разработать крупный проект, тогда вам обязательно нужно подумать о правильном масштабировании. Этот вопрос лучше решать перед началом проектирования, так как изменения в уже готовом проекте потребует намного больше усилий.

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

Это позволит кратковременно решить проблему, но в глобальном смысле, этого недостаточно. Реконструкция существующего сайта требует много ресурсов и усилий, потому, компания Мерехеад, рекомендует перед началом разработки обдумать варианты масштабироваться. Это позволит построить стабильную и гибкое веб приложение. Каждый сайт имеет стандартную архитектура взаимодействия, но многие компании предпочитают разделять проект на несколько основных модулей. В основном это: front-end, back-end и database.

Вы хотите разработать проект?

Свяжитесь с нами и мы Вам поможем.

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

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

Масштабирование back-end

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

Если нагрузка временная, можно увеличить мощность сервера. В ином случае следует разделить back-end на несколько серверов. Достаточно перенести часть скриптов и модулей на второй сервер. После этого, необходимо распределить запросы равномерно между ними. Это даст возможность снять нагрузку с основного сервера и перенаправить на другие машины. В основном это делается на front-end стороне.

Масштабирование database

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

Распределение вычислительных процессов в базе данных

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

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

— Репликация. Позволяет делать изменения на одном «главном» сервере, после этого происходит автоматическое изменения на остальных серверах.

— Multi-master репликация. Очень похож на репликацию, только в этом случае скрипт может обращаться к любому серверу. Репликация будет распространена на остальные сервера.

Разделение базы данных

Если у Вас не много вычислений, но база данных состоит из множество записей (часто такие проблемы имеют крупные e-commerce сайты), в этом случае Вам нужно разделить базу данных на несколько серверов. Каждый сервер будет иметь часть данных и взаимодействовать с другими серверами. Существует несколько схем распределения данных:

—Вертикальное (vertical partitioning). Суть данной схемы заключается в том что некоторые таблицы перемещаются на другой сервер. В таком случае теряется гибкость, так как нет возможности сделать сложные SQL запросы. Если провести правильное и логическое разделение базы, этот недостаток можно свести к минимуму.

—Горизонтальное (horizontal partitioning). В данной схеме база данных хранить одну и туже таблицу, только с разными частями. Например, у Вас есть таблица с 100 миллионами записями пользователей. Мы ее раздели на 2 сервера, на одном сервере будут хранится записи только мужчины, а на втором – только женщины. В этом случае необходимо внести изменения в back-end чтобы правильно распределить запросы между серверами.

Распределение запросов между серверами

Как только ваша система будет имеет несколько серверов, перед Вами появится вопрос правильного распределение запросов между серверами. Существует два метода распределения запросов (балансировки):

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

—Балансировка на стороне клиента. Более безопасный и более гибкий метод распределения запросов между серверами. Идея заключается в получении параметров пользователя. После этого, на основе этих данных, происходит автоматическое распределение запросов. Очень часто для этого используются данные IP и страны пользователя. Зная это, происходит автоматическое взаимодействие пользователя с нужными серверами. Таким подходом пользуются крупные компании, например Facebook.

Вывод

Крупные проекты с большой нагрузкой требует определенных знаний и опыта. Масштабирование проекта это сложный процесс, который нужно учитывать перед началом проектирования. Это позволит сэкономить деньги и время в будущем. В целом существует много схем и методов масштабирования: front-end, back-end, database. Они дают возможность разработать структуру, которая выдержит сотни миллионов пользователей в месяц.

Чтобы получить качественный результат, необходимо разработать правильную архитектуру и использовать надежные сервера. Для масштабируемых проектов, мы рекомендуем использовать Amazon Elastic Compute Cloud (Amazon EC2). Наша компания, Merehead, имеет опыт разработки сложных масштабируемых проектов с высокой нагрузкой. Если у Вас возникли вопросы, Вы можете связаться с нами и мы будем рады Вам помочь.

Библиотека Интернет Индустрии I2R.ru

Малобюджетные сайты.

Продвижение веб-сайта.

Контент и авторское право.

Компоненты ASP. Службы COM+ в ASP-компонентах и ASP-приложениях

Создавать и успешно использовать ASP-компоненты можно и без прямого обращения к каким-либо службам COM+. Однако именно эти службы могут внести ту «изюминку», которая превратит просто удовлетворительно работающее ASP-приложение в хорошо масштабируемое и соответствующее предъявляемым ему требованиям, независимо от того, каковы эти требования.

Службы COM+, к которым, прежде всего, стоит обратиться в разработке ASP-компонентов, — это управление транзакциями (transaction management), активация по требованию (just-in-time activation, JIT) и резервирование (pooling). Кроме того, можно использовать новые интерфейсы, которые были созданы для поддержания большей части возможностей этих служб. Однако перед рассмотрением всех этих новшеств обратимся к применению компонентов в приложениях.

Разработка систем на основе компонентов

Именно система, построенная на основе компонентов, выделяет индивидуальные процессы в многократно используемые порции кода и данных, а затем использует один или несколько этих компонентов для сознания полноценных приложений. Среди нескольких типов приложений различают клиент-серверную (client/server), распределенную (distributed) и многоярусную (n-tier) системы. В клиент-серверной системе (client-server system) процессы распределяются между клиентом и сервером, причем клиент отвечает за все взаимодействия с пользователем, отображение данных и подтверждение полномочий клиента, а сервер обрабатывает большую часть обращений к базам данных, проверяет полномочия сервера и контролирует бизнес-правила. В распределенной системе (distributed system) компоненты приложений могут располагаться на разных машинах и географически находиться в разных местах. Кроме того, для обработки множественных запросов может быть создано несколько экземпляров одного и того же компонента, таким образом, появляется возможность предоставлять одну и ту же услугу сразу множеству клиентов. И наконец, многослойная система (n-tier system) объединяет в себе элементы как клиент-серверной, так и распределенной систем. Здесь, как и в клиент-серверной системе, присутствует иерархия компонентов, однако сами по себе компоненты могут дублироваться для распределения загрузки процессов, а также распределяться на большом количестве машин и мест, как это происходит в распределенной системе. Стандартная n-ярусная система может состоять из клиента, выполняющего все взаимодействия с пользователем, проверку полномочий клиента и отображение данных; бизнес-уровня, контролирующего бизнес-правила, общие вопросы управления транзакциями и проверку полномочий, и уровня данных, обрабатывающего все прямые обращения к данным.

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

Другим преимуществом компонентов является тот факт, что гораздо больше родовых функций (generic functions) может быть разделено на отдельные компоненты и, таким образом, использовано во всей системе. Кроме того, применение компонентов упрощает модель и конструкцию n-ярусной системы. В качестве примера можно привести систему, в которой интерфейсный компонент проверяет достоверность адресной информации. Проверка достоверности достаточно характерна: она просто подтверждает тот факт, что все необходимые поля, такие как «Город» или «Почтовый индекс», заполнены. Тогда бизнес-уровень сможет обрабатывать для приложения адресную информацию, исходя из типа бизнеса. На основе адресной информации бизнес-уровень может вести поиск, например, зон отгрузки для компонента с помощью соответствующего приложения или зон доставки для виртуальной системы заказов. Компонент может обратиться к уровню данных для сохранения адресной информации, извлечения дополнительной информации или даже для запуска других виртуальных бизнес-компонентов, выполняющих какую-либо еще обработку информации. Уровень данных сам по себе может быть разделен по отдельным машинам, отдельным базам данных или даже различным типам хранилищ данных, вместе с некоторой информацией, идущей на долговременное или кратковременное хранение (если информация может потребоваться лишь в некоторой специфической задаче, а затем должна быть удалена).

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

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

В Windows 2000 работа с компонентами существенно облегчается службами COM+, выполняющими для компонентов такие действия, как например резервирование и транзакции. Именно для реализации этих задач традиционные интерфейсы COM были дополнены совершенно новыми интерфейсами, о которых вы узнаете в следующем разделе.

Интерфейсы COM+

Большинство важнейших интерфейсов COM, таких как, например, IUnknown и IDispatch, с появлением среды COM+ не претерпело каких-либо изменений и по сию пору решает все те же знакомые нам задачи. Главное отличие между COM и COM+ состоит в том, что та функциональность, которая в Windows NT и Windows 98 выполнялась средствами MTS, нынче полностью интегрирована в архитектуру COM+. Такого рода интеграция не только принесла с собой новые возможности, предоставляемые службами COM+, но и позволила существенно улучшить характеристики компонентов.

Разумеется, разработчики COM+ не забыли о необходимости поддержки новых служб COM+, а также нескольких новых интерфейсов уже имеющимися средствами, реализованными в MTS. В следующих нескольких разделах нами будут рассмотрены несколько ключевых интерфейсов, без знания которых, как нам кажется, разработка ASP-компонентов была бы бессмысленна.

Интерфейс IObjectContext

В главе 4 мы обсуждали концепцию контекстов (contexts) как совокупностей объектов, отвечающих одинаковыми требованиями. Среди таких требований может быть, например, возможность резервирования (pooling) для компонентов или их совместное участие в транзакциях.

В Windows 2000 контекст компонентов представляет собой набор свойств времени выполнения (runtime properties), непосредственная работа с которым может вестись с помощью объекта ObjectContext, управляющего контекстной информацией для компонента. Для доступа к свойствам объекта ObjectContext используется интерфейс IObjectContext, доступный, в свою очередь, с помощью библиотеки типов служб COM+.

Ответ на вопрос о том, каким именно образом осуществляется доступ к объекту ObjectContext, зависит от того, каким языком программирования вы пользуетесь. Например, если взять Visual Basic, то здесь сначала производится импорт ссылки на библиотеку типов служб COM+ в рабочий проект, и только потом можно создать ссылку на объект ObjectContext и вызвать для создания экземпляра метод GetObjectContext:

Dim objContext As ObjectContext
Set objContext = GetObjectContext

В Visual С++ под Windows NT для доступа к объекту ObjectContext также можно применить метод GetObjectContext:

CComPtr m_spObjectContext;
hr = GetObjectContext(&m_spObjectContext);

В то же время, в Visual C++ под Windows 2000 для передачи интерфейсу идентификатора GUID уже используется метод CoGetObjectContext:

hr = CoGetObjectContext(IID_IObjectContextInfo,
(void **)&m_spObjectContext);

Независимо от того, применяется ли метод GetObjectContext или метод CoGetObjectContext, результаты будут одними и теми же, поскольку вызов метода CoGetObjectContext в COM+ является оболочкой для вызова метода GetObjectContext. В Visual С++ придется также добавить в путь библиотеки компонента ссылку на заголовочный файл comsvcs.h служб COM+ и ссылку на файл связанного объекта comsvcs.lib.

Получив ссылку на интерфейс IObjectContext, можно вызывать его методы, перечисленные в табл. 1.

табл. 1. Методы интерфейса IObjectContext

Интерфейс обладает следующими свойствами:

• ContextInfo — возвращает ссылку на объект контекстной информации, связанный с компонентом;
• Count — показывает число именованных свойств объекта;
• Item — содержит имена свойств;
• Security — возвращает ссылку на объект Security, связанный с объектом ObjectContext.

Интерфейс информации контекста IObjectContextInfo более подробно будет рассмотрен в следующем разделе. Для обращения к встроенным ASP-объектам применяется коллекция Item. Получить доступ к ней можно непосредственно из Visual Basic:

Dim oc As ObjectContext
Dim app As Application
Set oc = GetObjectConext
Set app = oc.Item(«Application»)

Получить доступ к ASP-объектам можно и через объект ObjectContext:

Set app = oc(«Application»)

Из других программных языков для обращения к объектам ASP придется применить другие технологии. В C++, например, для получения доступа к определенному ASP-объекту нужно послать запрос экземпляру интерфейса IGetContextProperties:

CComPtr pProps; //свойства контекста

//получение ObjectContext
hr = CoGetObjectContext(IID_IObjectContext,
(void **)&m_spObjectContext);
if (FAILED(hr)) return hr;

//получение свойств контекста
hr = m_spObjectContext ->
QueryInterface( IID_IGetContextProperties,
(void**)&pProps );
if (FAILED(hr)) return hr;

получение свойства Response
bstrProp = «Response»;
hr = pProps->GetProperty( bstrProp, &vt ) ;
if (FAILED(hr)) return hr;

p > hr = piDispatch->QueryInterface( IID_IResponse,
(void**)&m_piResponse );

В документации к интерфейсу IGetContextProperties сообщается, что он действует только в среде Windows NT, но и в Windows 2000 с его помощью также можно обращаться к встроенным ASP-объектам.

Интерфейс IObjectContextInfo

Интерфейс IObjectContextInfo служит для получения относящейся к текущему компоненту информации о транзакциях, активности и контексте. С помощью этого интерфейса можно получить доступ к указателю на интерфейс ITransaction. В табл. 2 приведены методы интерфейса IObjectContextInfo.

табл. 2. Методы интерфейса IObjectContextInfo

Если в компонентах COM+ осуществляется синхронизация (описываемая позже), метод GetActivityId возвращает идентификатор текущей активности, в противном случае будет возвращено значение Null.

Метод GetTransaction возвращает указатель на интерфейс ITransaction. С помощью этого интерфейса можно принять или прервать транзакцию, хотя реализуются эти функции с помощью объекта ObjectContext или интерфейса IContextState, рассматриваемых далее.

Интерфейс IContextState

Интерфейс IContextState предоставляет возможность более четкого управления транзакциями и активацией, чем это допустимо в интерфейсе IObjectContext. Например, в интерфейсе IObjectContext с помощью метода SetComplete можно отметить компонент, как завершивший работу и ожидающий принятия транзакции, а с помощью метода SetAbort отметить его как завершивший работу и ожидающий прерывания текущей транзакции.

На практике есть два условных бита, устанавливаемых при работе с методами SetComplete и SetAbort. Первый из их — бит завершения (done bit), его установка указывает COM+, что обработка компонента завершена. Второй — бит согласованности (consistency bit). Установка этого бита определяет, может ли быть транзакция принята или она должна быть прервана.

Оба метода, SetComplete и SetAbort, интерфейса IObjectContext одновременно устанавливают оба бита, причем оба устанавливают бит завершения в значение True, указывая, что обработка компонента завершена. В то же время, с помощью интерфейса IContextState можно идентифицировать факт окончания работы компонента отдельно от статуса транзакции.

В табл. 3 приведены четыре метода интерфейса IContextState.

табл. 3. Методы интерфейса IContextState

Бит завершения можно получать и устанавливать с помощью методов SetDeactivateOnReturn и GetDeactivateOnReturn. Компонент деактивируется по завершении методов только при значении бита завершения, установленном в True.

Чтобы убедиться во всех этих возможностях, создайте компонент Visual Basic, реализующий для перехвата событий JIT интерфейс IObjectControl. (Интерфейс IObjectControl подробно описывается в следующем разделе.) У этого метода будет два компонента, каждый из которых вызывает метод SetDeactivateOnReturn интерфейса IContextState. Первая функция будет вызывать метод, передавая логическое значение False, вторая — True.

Создайте проект Visual Basic и назовите его asp0501, а класс генерируемого компонента — done. Присоедините к проекту библиотеки типов служб COM+ и Microsoft Active Server Pages. Коль скоро библиотеки типов добавлены как ресурсы, реализуйте, как показано в листинге 5.1, JIT-методы Activate, Deactivate и CanBePooled интерфейса IObjectControl.

Листинг 1. Реализация JIT-функций интерфейса IObjectControl

Dim objResponse As Response

Private Sub ObjectControl_Activate()
Set objResponse = GetObjectContext().Item(«Response»)
objResponse.Write «

Активирован

Private Sub ObjectControl_Deactivate()
objResponse.Write «

Деактивирован

Private Function ObjectControl_CanBePooled() As Boolean
ObjectControl_CanBePooled = False
End Function

В методе Activate созданная ссылка на встроенный ASP-объект Response используется для отображения сообщения о том, что метод активирован. В методе Deactivate на web-страницу выводится сообщение о том, что компонент деактивирован.

Далее, добавьте две функции компонента, вызываемые ASP-страницей. Первая, под именем function1, обращается к интерфейсу IContextState и вызывает его метод SetDeactivateOnReturn, передавая значение False. Вторая функция, function2, также вызывает метод SetDeactivateOnReturn, но на сей раз передается значение True. В листинге 5.2 приведен программный код обеих функций, который и нужно добавить к нашему компоненту.

Листинг 2. Подпрограммы, вызывающие метод SetDeactivateOnReturn

Dim iCntxt As IContextState
Set iCntxt = GetObjectContext

iCntxt.SetDeactivateOnReturn False
End Sub

Dim iCntxt As IContextState
Set iCntxt = GetObjectContext

iCntxt.SetDeactivateOnReturn True
End Sub

После того как проект компонента скомпилирован и добавлен к приложению COM+, протестируйте новый компонент с помощью ASP-сценария примерно такого содержания (как в странице asp0501.asp):

Первой вызывается функция function2, деактивирующая компонент при возвращении значения функцией. Благодаря этому при обращении к функции компонента будет отображаться сообщение «Активирован», а при возвращении функцией значения будет отображаться сообщение «Деактивирован» еще до сообщения «Вызов function 1».

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

Наконец, при повторном вызове функции function2, должны быть отображены оба сообщения, «Активирован» и «Деактивирован», при этом генерируется web-страница со следующими сообщениями:

Вызов function 2

Вызов function 1

Вызов function 2

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

Интерфейс IObjectControl

В этом разделе показано, как можно управлять временем жизни (lifetime) компонента с помощью интерфейса IContextState. В примере также используется активация по требованию (just-in-time activation, JIT) — для управления созданием экземпляра компонента и записи на web-страницу с помощью методов Activate и Deactivate интерфейса IObjectControl сообщений об активации и деактивации компонента.

Разрешение активации по требованию компонента означает, что компонент активируется, только когда он реально требуется, а не при первоначальном создании на ASP-странице. Кроме того, компонент деактивируется, только когда он помечается как готовый к деактивации, удаляется внутри ASP-страницы (например, установлен в Nothing, если вы работаете с VBScript) или процесс выходит за пределы страницы.

Процесс активации и деактивации управляется COM+ с помощью программных ключей, указываемых разработчиками, как, например, тот, что показан в этом разделе для вызова метода SetDeactivateOnReturn интерфейса IContextState.

Как разработчик компонента, вы можете перехватывать моменты активации и деактивации компонента путем реализации методов Activate и Deactivate интерфейса IObjectControl. В этом случае вы не зависите от ресурсов (типа ссылки на объект Response в листинге 5.1) в период простоя компонента и ожидания вызова его методов.

При реализации интерфейса IObjectControl вы должны реализовать и методы Activate и Deactivate — а кроме того, еще и метод CanBePooled. Этот последний метод определяет, находится ли компонент в состоянии, когда он может быть резервирован (pooled). Позднее в этой главе при описании служб COM+ мы рассмотрим резервирование (pooling) компонентов более подробно.

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

Интерфейсы IObjectControl и IObjectContext были реализованы в Windows NT и управляются посредством MTS. Фактически же, ASP-компоненты, созданные для Windows NT, за исключением использующих специфические службы NT, можно без проблем перенести на Windows 2000 и COM+, что и обсуждается в следующем разделе.

ПРИМЕЧАНИЕ
В Windows NT приходилось избегать применения обработчиков событий Initialize и Terminate, поскольку они не позволяли обратиться к экземпляру объекта ObjectContext. Это ограничение в Windows 2000 снято. И все же, по-прежнему важно рассмотреть реализацию интерфейса IObjectControl и перехват (trapping) событий Activate и Deactivate для обеспечения доступа к глобальным ресурсам и их высвобождения.

Перенос пакетов MTS в приложения COM+

В Windows NT (or Windows 9x) компонентами можно было управлять как частью пакетов (packages) MTS. Будучи частью пакета MTS, компонент мог воспользоваться некоторыми возможностями MTS, например, выполнением транзакций и активацией по требованию. Те же и многие другие возможности доступны также и в COM+, и обратиться к ним из существующих компонентов можно, перенеся в новую среду пакеты MTS, компоненты или то и другое.

Для переноса существующего пакета MTS нужно, прежде всего, экспортировать пакет в файл с расширением .pak (файл пакета MTS). Это можно сделать, щелкнув правой кнопкой мыши на существующем приложении MTS и выбрав в меню команду Export (Экспорт). Далее нужно просто следовать указаниям по экспорту в файл пакета MTS, решив, в том числе, вопрос об экспорте ролей вместе с пакетом.

Можно относительно просто перенести пакеты MTS в COM+, создав с помощью консоли служб компонентов (Component Services Console) новое приложение COM+ и установив переключатель Install Pre-built Application(s) (Установить готовое приложение). Когда мастер установки приложения COM (COM Application Install Wizard) запросит имя существующего приложения, найдите или выберите созданный ранее PAK-файл.

При импорте существующего пакета MTS в новое приложение COM+ диспетчер служб компонентов (Component Services Manager) импортирует также роли (roles) и пытается сопоставить существующую функциональность MTS новой функциональности служб COM+ — включая настройки транзакций и активации по требованию.

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

В следующем разделе обсуждаются некоторые настройки приложений COM+, влияющие на ASP-приложения.

СОВЕТ
За дополнительной информацией о работе с консолью служб компонентов (Component Services Console) обратитесь к справочной системе Windows 2000.

Активация приложений COM+

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

ПРИМЕЧАНИЕ
В этом разделе рассмотрены не все возможные службы COM+, а лишь самые необходимые для разработки ASP-компонентов, например, безопасность, транзакции и объединение объектов. Активация по требованию подробно рассмотрена в разделе «Интерфейс IObjectControl».

Управлять безопасностью ASP-приложения на уровне страницы или ресурса можно с помощью средств безопасности NTFS или средств безопасности IIS. С помощью средств ролевой безопасности приложений COM+ можно добавить и еще один уровень безопасности.

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

Приложение COM+ можно создать по двум различным схемам активации: активации внутри клиентского процесса и активации в изолированном процессе.

Если приложение COM+ создано как серверное, обращение к компоненту с ASP-страницы генерирует отдельную программу dllhost.exe для этого компонента и любого другого, являющегося частью приложения COM+. Поскольку компонент находится в отдельном процессе, все вызовы компонента с ASP-страницы должны маршализироваться. Вместе с тем, если компонент некачественный и генерирует нечто опасное для программного обеспечения, это нечто останется внутри файла dllhost.exe и не сможет неблагоприятно повлиять на IIS или остальные ASP-приложения.

Если создать приложение COM+ как библиотечное, при обращении к компоненту с ASP-страницы экземпляр этого компонента (и любого другого внутри приложения COM+) создается внутри того же процесса, что и ASP-страница — если только поточная модель компонента совместима. Поскольку приложения COM+ допускают апартаментно-поточную, произвольно-поточную и нейтрально-поточную модели, экземпляр компонента приложения COM+ должен создаваться внутри процесса ASP-страницы, а все вызовы между сценарием страницы и компонентом должны выполняться в том же потоке.

Службы COM+

Компонент, с помощью диспетчера служб COM+ (COM+ Services Manager) установленный как часть приложения COM+, называется сконфигурированным компонентом (configured component). Такой компонент может воспользоваться преимуществами служб COM+, например, поддержкой транзакций и активацией по требованию. Компонент, не установленный как часть приложения COM+ и зарегистрированный с помощью инструментов разработки (например, VB) или утилиты regsvr32.exe, называется несконфигурированным компонентом (unconfigured component). Этот тип компонента использовать в ASP-приложениях можно, но реализовать интерфейс IObjectControl, воспользоваться преимуществами активации по требованию или применить объект ObjectContext для поддержки транзакций нельзя. Можно, однако, как и прежде, обратиться с помощью объекта ObjectContext к встроенным объектам ASP.

Одним из основных доводов в пользу добавления компонента в приложение COM+ является желание применить компонент в транзакциях. Это момент обсуждается в следующем разделе.

Поддержка транзакций

Одна из проблем при работе с компонентами, построенными на основе технологий COM/DCOM, состоит в том, что связь компонентов, особенно удаленная связь, весьма непроста. Выяснение того, успешно ли завершена обработка компонента, что делать дальше и как восстановить задачу, если один из компонентов не смог ее выполнить, а остальные — смогли, может превратить распределенную систему в плохо реализуемую и трудно управляемую.

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

Кроме того, MTS предоставляет менеджеров (managers) и диспетчеров (dispensers) ресурсов, которые управляют данными хранилищ, например, данными баз данных. По сути, любая система баз данных, поддерживающая транзакции OLE, скажем, SQL Server, может участвовать в транзакциях, управляемых MTS. Это означает, что если компонент, участвующий в транзакции, выполняется с ошибкой, то можно отозвать (вернуть к прежнему состоянию) не только его действия и действия других компонентов, но и любое действие, произведенное базой данных.

Все возможности MTS по работе с транзакциями реализованы в службах COM+ и доступны для сконфигурированных компонентов. Отличие состоит в том, что в COM+ (и Windows 2000) присутствует интерфейс IContextState, позволяющий отделить активацию компонента от управления транзакциями. Этот интерфейс способен сигнализировать, собирается ли компонент принять или прервать транзакцию, при этом компонент остается активированным, как было ранее показано в листинге 5.1.

Что такое транзакции?

Если вы имели опыт работы с коммерческими базами данных, например, с Oracle, Sybase и Microsoft SQL Server, то, возможно, знаете, что представляют собой транзакции. Транзакция (transaction) — это одна или несколько задач, некоторым образом логически сгруппированных, причем все задачи, объединенные в данную группу, либо все вместе успешно завершаются, либо все вместе не выполняются, если хотя бы одна из задач внутри транзакции не выполнена. Если транзакция не состоялась, никаких изменений данных, связанных с данной транзакцией, не делается. Если же выполнение транзакции происходит успешно, все изменения данных принимаются. В качестве примера транзакции с несколькими задачами можно привести перевод денег со сберегательного на расчетный счет. Хотя это и похоже на одну транзакцию, в действительности, происходят сразу две транзакции. Первая транзакция состоит в снятии ваших денег со сберегательного счета (то есть они дебетуются на счет), вторая транзакция заключается в переведении этих денег на расчетный счет (то есть они кредитуются на расчетный счет) . Если операция снятия денег со сберегательного счета прошла успешно, а операция по переводу денег на расчетный счет не была выполнена, вы, весьма вероятно, захотите, чтобы целиком вся транзакция была отозвана и начата заново. Транзакции очень существенны для систем, обновляющих несколько структур данных, например, баз данных. Такие обновления, даже основанные на одной операции, должны быть успешно завершены сразу для всех структур данных, именно для того, чтобы обеспечить успешное завершение одной этой операции.

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

Участие компонентов в транзакциях

Компонент может воспользоваться возможностями транзакций COM+, если он удовлетворяет следующим условиям. Во-первых, компонент должен быть внутрипроцессным сервером (то есть DLL). Во-вторых, он не должен быть свободно-поточным. Далее, если компонент создан в Visual С++, он должен реализовать фабрику классов (class factory) и использовать стандартную маршализацию. Кроме того, для компонента нужно будет создать библиотеку типов.

Если компонент удовлетворяет минимальным требованиям, чтобы получить поддержку транзакций, он должен быть зарегистрирован в COM+. В процессе регистрации тип транзакции, в которой участвует компонент, устанавливается в качестве свойства компонента. Например, на рис. 3 показано окно свойств компонента, для которого требуется транзакция, время ожидания завершения которой определено в 10 секунд.

Чтобы начать транзакцию на ASP-странице, поместите первой строкой страницы следующую директиву:

Для работы с транзакциями компонент должен ссылаться на экземпляр объекта ObjectContext (или интерфейса IObjectContext) или экземпляр интерфейса IContextState. Пометить компонент как готовый к принятию транзакции можно с помощью метода SetComplete объекта ObjectContext или метода SetMyTransactionVote интерфейса IContextState:

Пометить транзакцию для отзыва можно с помощью тех же интерфейсов:

Транзакции COM+ в действии показаны в примерах главы 9, посвященной созданию ASP-компонентов промежуточного слоя с помощью ADO. В этих примерах транзакции выполняются для обновления баз данных — и это их традиционное применение. Транзакции с базами данных можно выполнять непосредственно (не прибегая к транзакциям COM+) с помощью объекта ADO Connection. Тем не менее, примеры этой главы продемонстрируют, что гораздо удобней наладить взаимодействие компонентов и баз данных посредством транзакций COM+.

Транзакции COM+ можно также использовать для управления взаимодействием с другими ресурсами, например, с сообщениями в очереди сообщений. В главе 13, посвященной работе с компонентами MSMQ, транзакции управляют непрерывным удалением сообщений из очереди по мере получения к ним доступа.

Помимо поддержки транзакций и активации по требованию, службы COM+ могут также обеспечивать резервирование (pooling) компонентов.

Резервирование компонентов

Ранее уже отмечалось, что у интерфейса IObjectControl есть три метода: Activate, Deactivate и CanBePooled. У вас уже была возможность поработать с методами Activate и Deactivate, но для резервирования компонентов важен именно метод CanBePooled.

В случае резервирования объектов при пуске приложения COM+ создается минимальный резерв, или пул (pool), компонентов, и все запросы компонента обслуживаются из этого пула посредством менеджера пула (pool manager). Если менеджер получает запрос большего, чем имеется в пуле, числа экземпляров компонента, он создает другой экземпляр компонента, добавляя его в пул — до достижения максимального размера пула. Если же максимальный размер пула достигнут, запрос ставится в очередь до тех пор, пока компонент не станет доступным.

Компоненты, объединяемые в пул, должны соответствовать определенному набору условий. Во-первых, компонент не должен быть отдельно-поточным. Далее, компонент должен поддерживать агрегирование (aggregation), однако при этом свободно-поточный составитель (Free-Threaded Marshaler, FTM) использоваться не может.

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

Если компонент обращается к ресурсам, он должен реализовать три метода интерфейса IObjectControl — Activate, Deactivate и CanBePooled. Обратиться к ресурсу можно с помощью метода Activate (когда компонент создается на клиентской ASP-странице). Этот ресурс может быть высвобожден при высвобождении компонента клиентом (с помощью метода Deactivate). Кроме того, компонент обязан проверить, находятся ли его ресурсы в состоянии, когда их можно резервировать при деактивации компонента. Если резервирование возможно, метод компонента CanBePooled должен возвратить значение True, в противном случае, компонент должен возвратить значение False, чтобы предотвратить возврат компонента в пул.

Наконец, состояние компонента не должно зависеть от сеанса.

Создать резервируемый компонент можно с помощью Visual C++ (или любого другого языка, поддерживающего свободно-поточную или произвольно-поточную модели). Для демонстрации резервирования объектов создайте с помощью мастера ATL COM AppWizard новый проект Visual С++ и назовите его asp0502. Оставьте установленные по умолчанию параметры для MTS, MFC, заместителя (proxy) и исполнителя (stub).

После генерации файлов проекта добавьте новый компонент с помощью мастера ATL Object Wizard. (Подробно работа с этим мастером рассмотрена в главе 14.) Выберите тип Simple Object (Простой объект). Назовите компонент pooledComponent, на вкладке Attributes (Атрибуты) выберите произвольно-поточную модель и поддержку агрегирования (но не поддержку FTM).

Для поддержки интерфейса IObjectControl добавьте в определения класса в файле pooledComponent.h следующую строку:

Добавьте в данные COM ссылку на карту COM (COM map):

При работе с компонентом вам придется обращаться к интерфейсу IObjectContext и встроенному объекту ASP Response, поэтому добавьте в заголовочные файлы библиотеки типов службы COM+ и ASP следующее:

Следует также добавить прототипы метода интерфейса IObjectControl и ссылку на два закрытых (private) члена данных типа интерфейсов IObjectContext и IResponse (встроенного объекта ASP Response). Полный программный код заголовочного файла для резервируемого компонента показан в листинге 5.3.

Листинг 3. Заголовочный файл резервируемого компонента

// pooledComponent.h : объявление CpooledComponent

#ifndef __POOLEDCOMPONENT_H_
#define __POOLEDCOMPONENT_H_

#include «resource.h» // основные символы
#include
#include

/////////////////////////////////////////////////////////////////
// CpooledComponent
class ATL_NO_VTABLE CpooledComponent :
public CComObjectRootEx ,
public CComCoClass ,
public IObjectControl,
public IDispatchImpl
<
public:
CpooledComponent()
<
>

BEGIN_COM_MAP(CpooledComponent)
COM_INTERFACE_ENTRY(IpooledComponent)
COM_INTERFACE_ENTRY(IObjectControl)
COM_INTERFACE_ENTRY(IDispatch)
END_COM_MAP()

// IpooledComponent
public:
STDMETHOD(Activate)();
STDMETHOD_(BOOL, CanBePooled)();
STDMETHOD_(void, Deactivate)();

private: CComPtr m_spObjectContext;
CComPtr m_piResponse;
>;

Далее, с помощью вкладки Link (Связь) диалогового окна Project Settings (Настройки проекта) добавьте в список связанных библиотек проекта библиотеку служб COM+ (comsvcs.lib).

Вам придется реализовать три метода интерфейса IObjectControl. В CPP-файле компонента добавьте код, показанный в листинге 5.4. В этом коде экземпляры IObjectContext и IResponse создаются в методе Activate и высвобождаются в методе Deactivate. Кроме того, метод CanBePooled возвращает значение True и помечает, что компонент можно резервировать (помещать в пул).

Листинг 4. Реализация компонентом методов интерфейса IObjectControl

HRESULT CpooledComponent::Activate()
<
HRESULT hr;
CComBSTR bstrProp;
CComVariant vt;
CComPtr pProps; //Свойства контекста

// получение ObjectContext
hr = CoGetObjectContext(IID_IObjectContext,
(void **)&m_spObjectContext);

if (FAILED(hr)) return hr;

// получение ContextProperties
hr = m_spObjectContext
->QueryInterface( IID_IGetContextProperties,
(void**)&pProps );
if (FAILED(hr)) return hr;

// получение свойства Response
bstrProp = «Response»;
hr = pProps->GetProperty( bstrProp, &vt ) ;
if (FAILED(hr)) return hr;

p > hr = piDispatch->QueryInterface( IID_IResponse,
(void**)&m_piResponse );
return hr;
>

void CpooledComponent::Deactivate()
<
m_piResponse.Release();
m_spObjectContext.Release();
>

BOOL CpooledComponent::CanBePooled()
<
return TRUE;
>

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

С помощью вкладки ClassView (Просмотр классов) добавьте новому компоненту не принимающий никаких параметров метод testPooledComponent. Этот метод прост: он выдает с помощью объекта Response сообщение для web-страницы. Добавьте компоненту программный код метода, показанный в листинге 5.5.

Листинг 5. Единственный метод резервированного компонента

STDMETHODIMP CpooledComponent::testPooledComponent()
<
// печать сообщения
CComVariant vt(«Привет от резервированного компонента»); m_piResponse->Write(vt);

Чтобы воспользоваться резервированием компонентов, компонент нужно добавить в приложение COM+. Создайте новое приложение — с помощью консоли управления службами компонентов (Component Services Management Console) — или воспользуйтесь существующим приложением COM+ и добавьте компонент в приложение.

Добавив компонент в приложение COM+, откройте с помощью контекстного меню диалоговое окно Properties (Свойства) и перейдите на вкладку Activation (Активация). Установите флажок объединения компонентов, задайте минимальный размер пула 10, максимальный — 20.

При первом запуске приложение COM+ создает пул из 10 уже созданных компонентов. При обращении с ASP-страниц к этим компонентам они извлекаются из этого пула до тех пор, пока все не будут активированы. После этого все новые вызовы компонентов будут добавлять экземпляры этих компонентов в пул, пока не будет достигнут максимальный размер пула в 20 экземпляров.

Протестируйте компонент с помощью следующей тестовой ASP-страницы (asp0502.asp):

На этой странице создаются 20 экземпляров компонента и вызывается метод каждого из компонентов. Результатом обращения к этой ASP-странице будет список сообщений со строкой «Привет от резервированного компонента». Первые 10 экземпляров были созданы при запуске приложения COM+, а последние 10 — при обращении к ASP-странице.

Измените теперь число экземпляров на 21 и обратитесь к ASP-странице. Похоже, она виснет. Это происходит потому, что менеджер пула выдал все компоненты из доступного пула, вследствие чего достигнут максимальный размер пула. Запрос 21-го компонента ставится в очередь до тех пор, пока какой-нибудь компонент не освободится. Но поскольку до завершения страницы все компоненты остаются недоступными, а запрос компонента происходит на той же самой странице, экземпляр 21-го компонента не может быть создан, и страница зависает. Фактически страница будут продолжать висеть до истечения времени ожидания запроса компонента. После этого страница выведет следующее сообщение об ошибке («активация COM+ не удалась, поскольку она не может быть завершена в течение заданного времени»):

COM+ activation failed because the activation could not be
completed in the specified amount of time.

Как было показано, резервирование объектов может служить весьма мощным ускорителем производительности, но оно же может и ограничить масштабируемость (scalability) или истощить ресурсы (поскольку резервируемые компоненты удерживаются в памяти). Пользуйтесь этой службой COM+ с осторожностью.

Создание серверных компонентов для ASP-приложений

ASP (Active Server Pages) — технология создания Web-страниц, содержащих код, выполняемый Web-сервером (подробнее об истории и современном состоянии этой технологии см. в статье Алексея Федорова «Технология ASP+», № 9’2000, а о практических вопросах применения ASP см. в цикле статей Рубена Садояна , № 9-11’2000. — Прим. ред.). Современная версия данной технологии позволяет использовать в ASP-страницах сторонние серверные компоненты, созданию которых и посвящена данная статья.

В качестве средства разработки ASP-объектов будет использоваться Borland Delphi 5, Enterprise-версия которого позволяет это делать. К сожалению, в документации, поставляемой с Delphi 5, крайне скупо сказано о назначении, последовательности создания и тестирования серверных объектов ASP; кроме того в комплекте поставки Delphi 5 отсутствуют примеры работающих ASP-объектов. Настоящая публикация частично восполняет эти пробелы.

Клиентское приложение, использующее ASP-объекты, представляет собой HTML-документ (этот документ может также включать клиентский и серверный коды на скриптовых языках. — Прим. ред.), который в принципе можно прочесть с помощью любого Web-браузера. Обычно такие HTML-документы размещаются на каком-либо Web-сервере (как правило, это Microsoft Internet Information Server версии 3.0 и выше). Web-сервер, получив требование о предоставлении документа, считывает его из локального хранилища и передает клиенту, при этом часть информации вносится в документ Web-сервером динамически; сам же Web-сервер может обращаться к ASP-объектам, входящим в комплект поставки Internet Information Server или созданным сторонними разработчиками. Обычно Web-документы, содержащие обращения к ASP-объектам, имеют расширение *.asp. Примеры подобных документов можно найти в каталогах, создаваемых при установке Internet Information Server.

Некоторые Web-дизайнеры полагают, что технология ASP заключается, грубо говоря, в замене расширения *.htm в HTML-файле на расширение *.asp. Действительно, при работе с Internet Information Server изменение расширения файла позволит корректно отображать находящийся в нем HTML-документ. Однако на самом деле технология ASP — это обращение к методам специальных объектов, называемых ASP-объектами и представляющих собой COM-серверы. Типичный пример обращения к ASP-серверу из HTML-документа, представляющий собой фрагмент кода на языке VBScript, выглядит следующим образом:

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

Серверные объекты ASP выполняются в адресном пространстве Internet Information Server (Internet Information Services), работающего под управлением операционной системы Windows NT (Windows 2000) либо Windows 98.

По существу ASP-сервер представляет собой сервер автоматизации, в котором предопределено несколько интерфейсов; среди них — IRequest и IResponse. Интерфейс IRequest содержит методы, вызов которых позволяет передать параметры, введенные пользователем и заполненные на клиенте (об этом будет рассказано ниже). IResponse содержит методы, вызов которых приводит к формированию HTML-документа и передаче данного документа пользователю. Наличие этих признаков делает ASP-сервер похожим на CGI-приложения и ISAPI/NSAPI DLLl (далее — Web-приложения). Идеология выполнения методов в ASP-объекте и Web-приложениях также аналогична: сначала анализируется запрос клиента, затем динамически формируется отклик. Различие заключается в том, что Web-приложения формируют HTML-документ целиком, в то время как отклик ASP-объекта вставляется в исходную HTML-страницу. Например, если документ ASP представлен в виде:

и результат выполнения метода ScriptContent возвращает строку ‘First call to ASP server’, то пользователь, получивший данный документ, увидит следующее (рис. 1).

Иными словами, отклик ASP-объекта добавляется к HTML-документу. В одном документе допустимо обращение к нескольким ASP-объектам, и результат их отклика формируется в единый документ — этого невозможно достичь при использовании Web-приложений. Впрочем, имеется одно ограничение: набор ASP-серверов, к которым производится обращение из одного документа, должен быть зарегистрирован на одном и том же Internet Information Server — нельзя обращаться по различным адресам для формирования одного HTML-документа.

Как было сказано выше, Enterprise-версия Delphi 5 содержит эксперт для создания ASP-объектов. Для запуска этого эксперта следует выбрать пункт главного меню File|New среды разработки Delphi, а затем со страницы ActiveX репозитария объектов — пиктограмму Active Server Object.

ASP-сервер, содержащий ASP-объекты, реализуется в виде как исполняемых файлов *.exe, так и библиотек *.dll — это разрешается при создании серверов автоматизации. ASP-сервер, реализованный в виде исполняемого файла, запускается каждый раз в ответ на запрос клиента. При использовании внутренних (in-process) ASP-серверов, выполненных в виде динамически загружаемых библиотек, один экземпляр DLL, загруженный в адресное пространство Internet Information Server, способен обслуживать одновременно нескольких клиентов. При этом возможно либо создание отдельного экземпляра COM-объекта для каждого клиента, либо обслуживание нескольких клиентов единственным экземпляром COM-объекта. Это зависит от модели работы в потоках (Threading Model), выбранной при заполнении диалога, который появляется при запуске эксперта создания ASP-объектов.

Рассмотрим теперь, каким образом работает ASP-сервер на конкретном примере создания внутреннего (in-process) ASP-сервера. Для простоты ограничимся сервером, который выполняет один запрос. Итак, выберем пункт главного меню File|New среды разработки Delphi, со страницы ActiveX репозитария объектов — пиктограмму ActiveX Library и нажмем кнопку OK. В итоге получим новый проект, который сохраним, например, под именем ASP01. Теперь снова выберем пункт главного меню File|New среды разработки Delphi, со страницы ActiveX репозитария объектов — пиктограмму Active Server Object. В появившемся диалоге определим имя будущего COM-класса, например Test.

Поскольку мы создаем in-process-сервер, параметр Instancing не имеет значения — он важен только для исполняемых файлов. Зато в данном случае серьезную роль играет параметр Threading Model. При значении этого параметра равным Single работа сервера неэффективна, поскольку при одновременном обращении к нему нескольких клиентов сервер выполняет запросы последовательно, и если один из клиентов обращается с длительным запросом, то остальные вынуждены ожидать его окончания, даже если их запросы не требуют большого количества времени для выполнения. При этом у пользователей создается впечатление «зависания» браузера, что зачастую приводит к попыткам разными методами прервать задачу. Значение Apartment приводит к разделению запросов клиентов по потокам, причем для каждого клиента будет создан свой экземпляр COM-объекта, в данном примере — класса TTest. При этом при написании методов COM-класса не требуется защиты переменных класса внутри потоков — клиент может свободно модифицировать их, что упрощает разработку кода приложения. Недостаток данной модели состоит в следующем: проект оказывается ресурсоемким и переменные класса инициализируются при каждом обращении, что увеличивает время отклика на запрос. Этих недостатков лишена модель Free, в которой единственный экземпляр COM-объекта обслуживает нескольких клиентов. Однако возможность изменения данных внутри COM-объекта влечет за собой необходимость защиты общих переменных от их изменений из разных потоков, что существенно усложняет процедуру реализации кода приложения и является потенциальным источником трудноуловимых ошибок. Как правило, эту модель используют в ASP-серверах, которые только предоставляют данные, но не позволяют клиенту их модифицировать.

Группа элементов управления Active Server Type дает возможность выбрать назначение ASP-сервера. Если сервер планируется использовать под управлением Internet Information Server версий 3 или 4, то выбирается опция Page Level Events Methods. Объекты, созданные с применением этой опции, можно будет использовать и с Internet Information Services 5.0, но в этом случае опция Object Context позволит создать объект, работающий более эффективно. Эту же опцию следует выбирать, если работой ASP-сервера управляет Microsoft Transaction Server (Windows NT) или Component Services (Windows 2000). Фактически Internet Information Services 5.0 также управляет этим сервером при помощи Component Services, так как оба этих продукта тесно интегрированы.

Опцию Generate a Template Test Script for this object следует оставлять всегда включенной. В этом случае Delphi создаст небольшой HTML-документ, который можно использовать для тестирования ASP-сервера.

Заполнив опции диалога, необходимо нажать кнопку OK, после чего будет создан файл реализации интерфейсов Unit1.pas, который следует сохранить (например, под именем U1_01). Кроме того, будет создана библиотека типов, появятся ее редактор и файл, описывающий библиотеку типов, в данном примере — TEST_TLB.pas.

Если была выбрана опция Page Level Events Methods (как в нашем примере), то библиотека типов будет содержать два предопределенных метода — OnStartPage и OnEndPage. Также будет создан файл Test.asp, который содержит HTML-документ с заготовками на языке VBScript для тестирования сервера. Если заглянуть в файл реализации (U1_01.pas) , то можно увидеть, что класс ТТest является потомком класса TASPObject.

Если была выбрана опция Object Context, библиотека типов не будет содержать предопределенных методов, а сам класс Ttest будет являться потомком класса TASPMTSObject. Оба класса-предка TTest содержат абсолютно одинаковые методы и свойства, но класс TASPObject дополнительно содержит пару методов интерфейса IASPObject — OnStartPage и OnEndPage.

Далее создадим метод, который будет заполнять HTML-документ. Для этого в редакторе библиотеки типов (рис. 2) отметим интерфейс ITest и вызовем команду New Method нажатием кнопки 1.

Назовем вновь созданный метод ScriptContent, отредактировав его название, заданное по умолчанию. Данный метод не должен иметь параметров. Затем вызовем команду Refresh нажатием кнопки 2. После этого в модуле реализации (U1_01.pas) появится заготовка, где следует описать реализацию. Метод реализуем следующим образом:

В данном примере происходит обращение к методу Write интерфейса IResponse. Проверка Assigned(Response) гарантирует, что в момент записи сообщений имеется ссылка на интерфейс.

После этого следует модифицировать созданный Delphi HTML-документ для тестирования сервера, хранящегося в файле Test.asp. В этом документе имеется следующий фрагмент кода на языке VBScript:

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

Теперь наш проект необходимо скомпилировать, после чего можно приступить к тестированию созданного ASP-объекта. Для этого необходимо создать виртуальную директорию Internet Information Server, которая обязана иметь разрешение как на чтение (из нее будут читаться данные), так и на выполнениe (из нее будет загружена и запущена библиотека ASP01.dll). Альтернатива — разместить эти файлы в разных директориях, одна из которых имеет доступ Read, а вторая — Execute. Однако в любом случае выбранные директории должны быть доступны с помощью протокола HTTP. Поэтому в первую очередь необходимо обратиться к WWW-сервису Internet Information Server, посмотреть список доступных директорий и при необходимости создать новые с соответствующими правами доступа.

В нашем примере на компьютере, который имеет IP-адрес 10.10.10.65, была создана виртуальная директория /Test, имеющая права доступа Read и Execute и соответствующая физическому адресу на компьютере C:\ASPTest. В эту директорию были скопированы оба файла. Далее в Microsoft Internet Explorer в поле Address был введен следующий URL: HTTP://10.10.10.65/Test/Test.asp. Результат выполнения этого запроса показан на рис. 1. Видно, что скрипт (текст между ) был замещен результатом выполнения метода ScriptContent созданного нами ASP-объекта.

Теперь подробнее рассмотрим, каким образом выполняется скрипт на странице Test.asp. Internet Information Server, получающий запрос о показе этой страницы, считывает ее содержимое, находит скрипт и выполняет его. При этом запускается интерпретатор VBScript и вызывается команда CreateObject. В случае если ASP01.dll ранее не была загружена, происходит ее загрузка. Для данного запроса создается COM-объект — экземпляр класса TTest (он описан в модуле реализации, для данного примера — U1_01.pas). Ссылка на интерфейс IDispatch (он поддерживается в классе TTest) сохраняется в переменной DelphiASPObj.

При последующем написании кода после имени переменной, хранящей ссылку на интерфейс IDispatch, можно набирать практически любой текст. Интерпретатор VBScript использует текст, который содержится в скрипте и следует после имени переменной (в нашем примере: переменная — DelphiASPObj, метод — .ScriptContent), для того чтобы передать его ASP-серверу. Если ASP-сервер найдет метод с данным именем, он его выполнит. В противном случае генерируется исключение. Поэтому при написании скриптов для ASP-сервера следует быть внимательным в названиях методов и при наличии исключений в первую очередь проверить корректность имен методов. При вызове какого-либо метода ASP-серверу становятся доступными интерфейсы IRequest и IResponse.

А теперь рассмотрим пример создания более сложного ASP-сервера, где запрос клиента анализируется при помощи методов интерфейса IRequest. Задачу поставим следующим образом: дадим возможность клиенту найти запись по фрагменту поля ENAME таблицы EMP в базе данных ORCL, сгенерированной Oracle 8.0.4 при его установке. Для этого в каком-либо редакторе форм создадим форму, содержащую однострочный редактор текста и кнопку Submit. HTML-документ с такой формой выглядит следующим образом:

При реализации этой формы вместо IP-адреса 10.10.10.65 следует указать IP-адрес компьютера, на котором установлен ASP-сервер.

Поместим этот документ в директорию C:\ASPTest, которая имеет доступ на чтение и выполнение (см. выше) под именем Name.htm. Но прежде чем создавать модуль данных и обращаться к серверу баз данных, необходимо выяснить, каким образом анализируется запрос клиента в ASP-объекте.

Запрос клиента можно анализировать при помощи вызова методов интерфейса IRequest, ссылка на который находится в свойстве Request класса TASPObject — предка класса, где реализуется ASP-объект. Интерфейс IRequest предоставляет три свойства: QueryString, Form и Body, в которых находятся ссылки на интерфейс IRequestDictionary. QueryString содержит параметры запроса, Form — список элементов управления, предоставляемых клиенту, а Body — данные, которые клиент ввел в эти элементы управления. Нам потребуются данные, поэтому мы будем анализировать свойство Body, однако все сказанное ниже о методах IRequestDisctionary применимо и к любому другому свойству типа ICustomDictionary — QueryString и Form.

IRequestDictionary определен в модуле ASPTlb.pas следующим образом:

Документация о свойствах этого интерфейса в Delphi отсутствует, и остается только догадываться, каким образом из него можно извлечь параметры запроса, введенные пользователем. Привлекая документацию по компоненту TWebDispatcher, который используется при создании CGI-приложений и ISAPI DLL, где также можно анализировать параметры запроса пользователя, можно понять, что свойство Count содержит число элементов управления на форме — для формы, содержащейся в документе Name.htm, оно равно 2. Свойство Key содержит имена элементов управления; для формы, содержащейся в документе Name.htm, это имена T1 (текстовое поле) и B1 (кнопка). И наконец, свойство Item содержит введенные пользователем значения.

Свойство Count работает как положено, то есть возвращает двойку для примера, приведенного выше. При попытке же извлечь имена элементов управления обнаруживается неприятная особенность: в коллекции Key[] индексы начинаются с единицы, а не с нуля, как это принято в приложениях подобного типа. Но все же, обращаясь к коллекции Key с соответствующим индексом — 1 или 2 для нашего примера, можно получить названия элементов управления в виде строковых переменных.

Аналогичная попытка извлечь данные, введенные пользователем в элементы управления, ни к чему хорошему не приводит. Так, при присвоении строковой переменной значения из коллекции Item[] (которая объявлена аналогично коллекции Key[]) происходит исключение. При анализе значения, возвращаемого коллекцией Item[I], обнаруживается, что возвращается интерфейс — потомок IDispatch. Методы и свойства этого интерфейса также не описаны.

Отсутствие описания интерфейса, а также возврат ссылки на него в переменной типа OLEVariant (а не IDispatch) обычно характерно для продуктов, которые находятся в стадии разработки. В этом случае заголовки методов интерфейса, список параметров методов и их число постоянно меняются, а во избежание исключений в клиентских приложениях часто используется позднее связывание. Этот факт настораживает: не исключена возможность изменения методов интерфейса в будущем, что может привести к потере работоспособности созданных ранее ASP-серверов. Однако хочется надеяться, что данный интерфейс устоялся, а в Microsoft по какой-либо причине просто забыли внести изменения в интерфейсный модуль.

Интерфейс — потомок IDispatch имеет два свойства: Count, которое всегда возвращает 1, и Item[]-коллекцию, которая возвращает текст, введенный клиентом в элементах управления. Коллекция Item начинается с индекса 1.

Для понимания и тестирования запроса в ASP-объекте сделаем небольшое дополнение к проекту. Воспользовавшись редактором библиотек типов, создадим новый метод RequestProp, как это было описано ранее (см. рис. 2). Напишем следующий код для метода RequestProp:

Скомпилируем проект и в созданном ранее файле Test.asp изменим код на языке VBScript следующим образом: вместо строки DelphiASPObj.ScriptContent напишем строку DelphiASPObj. RequestProp. После этого в Internet Explorer необходимо обратиться к странице Name.htm командой http://10.10.10.65/Test/Name.htm, где вместо 10.10.10.65 следует набрать IP-адрес сервера.

В полученной форме (рис. 3) введем какое-либо значение в элемент управления для редактирования данных и нажмем кнопку Submit. В итоге имеем результат выполнения приведенного выше кода метода RequestProp:

Итак, для определения параметров, введенных клиентом в какой-либо элемент управления, необходимо просмотреть всю коллекцию Keys, найти индекс интересующего нас элемента управления (в нашем примере — это 1, что соответствует ключу T1) и извлечь значение, введенное клиентом, посредством вызова команды Request.Body.Item[Index].Item[1].

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

Модуль данных, в который можно помещать невизуальные компоненты, экспертом создания ASP-объекта не генерируется — его необходимо создавать отдельно. Поэтому выберем пункт File|New главного меню среды разработки и из репозитария объектов выберем пиктограмму Data Module. В результате к проекту будет добавлен модуль данных, который мы сохраним под именем U1_02.pas. В этот модуль данных будут помещены невизуальные компоненты доступа к данным (визуальные компоненты в ASP-объектах использовать нельзя).

Вообще говоря, в Web-приложениях (ASP, ISAPI/NSAPI, CGI) показ модальных форм с элементами управления (а диалоги — частный вид таких форм) ни к чему хорошему не приводит. При попытке показать диалог элементы управления на диалоге будут созданы, и приложение будет ожидать, когда диалог будет закрыт (нажатием кнопки OK или Cancel), чтобы продолжить свою работу. Особенность заключается в том, что диалог невидим. Поэтому его нельзя закрыть ни с помощью нажатия на кнопки (они не получают сообщения OnClick), ни с помощью клавиш-акселераторов (сигналы с клавиатуры не посылаются невидимым элементам управления). Визуально программист наблюдает следующее: приложение «висит», отклика от ASP-объекта клиент не получает, а для повторной компиляции проекта требуется перезапуск Internet Information Server либо перезагрузка операционной системы. Даже если команды показа диалогов в ASP-сервере отсутствуют, они могут быть показаны в процессе работы приложения — например, какая-либо из библиотек, используемых приложением, пришлет сообщение об ошибке. Данный факт надо принимать во внимание при написании кода, в котором следует тщательно проверять данные перед их использованием, чтобы внешние приложения или библиотеки не присылали сообщений об ошибках в виде диалогов.

Традиционно доступ к данным в Delphi оcуществляется с помощью механизма Borland Database Engine (BDE), при этом необходимо использовать компоненты TSession, TDatabase и TQuery. Однако при создании ASP-объектов для доступа к данным выяснилось, что в них нельзя использовать BDE для доступа к SQL-серверам — при попытке соединиться с базой данных после передачи параметров, содержащих имя пользователя и пароль, происходит исключение (данный факт был проверен для Oracle 8.0.4 и IB Database 5.5). Через BDE удалось получить доступ только к базе данных DBDEMOS, которая не требует аутентификации пользователя при обращении к данным. К сказанному следует добавить, что в Windows 2000 нельзя получить доступ к данным через BDE в традиционных Web-серверных приложениях ISAPI DLL и CGI, в отличие от предыдущих версий Windows (95/98/NT).

К счастью, в Delphi 5 имеется альтернативный способ доступа к данным — с помощью ADO (ActiveX Data Objects). Для работы с ADO прежде всего необходимо использовать компонент TADOConnection. Поместим его в модуль данных. В инспекторе объектов выберем свойство ConnectionString и вызовем диалог для создания строки. В предложенном диалоге выберем Microsoft OLE DB Provider for Oracle и нажмем кнопку Next (рис. 4).

На второй странице диалога необходимо указать имя сервера (в данном примере — beq-local) и параметры аутентификации: имя пользователя (SCOTT) и пароль (TIGER). Обязательно следует отметить опцию Allow Saving Password, иначе ASP-объект попытается показать диалог ввода имени пользователя и пароля. Протестировать соединение можно нажатием кнопки Test Connection — должно появиться сообщение об успешном соединении с сервером.

Далее в инспекторе объектов следует установить свойство LoginPromp равным False. При работе с другими примерами нужно также изменять свойство DefaultDatabase — имя базы данных, но для данного примера это не обязательно. Проверить правильность установок можно при помощи установления свойства Connected равным True, при этом не должны появляться ни диалог ввода имени пользователя и пароля, ни информация об исключении.

Поместим компонент TADOQuery в модуль данных и в его свойстве Connection сошлемся на определенный выше компонент ADOConnection1.

Следует учесть, что только что разработанный модуль данных автоматически при загрузке ASP-сервера или при обращении клиента к ASP-объекту создаваться не будет. Поэтому необходимо переписать конструктор и деструктор класса TTest, реализация которого находится в файле U1_01.pas. Сошлемся на модуль U1_02.pas в модуле U1_01.pas. В объявлении класса TTest в секции private определим переменную FData типа TDataModule1. В секции public объявим процедуры AfterConstruction и BeforeDesctruction c обязательной директивой override:

Реализуем процедуры AfterConstruction и BeforeDestruction в секции реализации:

Далее в библиотеке типов (см. рис. 2) следует создать новый метод, который назовем QueryResponse. Реализуем его следующим образом:

В данном методе динамически создается SQL-запрос, при этом используются параметры, введенные клиентом в форму на рис. 3. С этим запросом происходит обращение к серверу баз данных, и возвращаемые данные помещаются в HTML-документ. В созданном ранее файле Test.asp изменим код на VBScript следующим образом: вместо строки DelphiASPObj.ScriptContent напишем строку DelphiASPObj. QueryResponse. После этого запустим Microsoft Internet Explorer и снова обратимся к странице Name.htm. Результат выполнения запроса приведен на рис. 5.

При использовании ASP-объекта необходимые для его работы параметры можно поместить, в HTML-документ. Параметры могут редактироваться в документе, что позволит изменять опции для конкретного сайта. Это удобно при поставке ASP-сервера: купившая его компания может изменить начальные установки так, чтобы они соответствовали требованиям компании. Для этого достаточно отредактировать HTML-документ, что возможно даже силами специалистов низкой квалификации.

Пример проиллюстрируем следующим образом: определим в заголовке класса TTest (U1_01.pas) две переменные: FCompanyName:string и FCopyrightYear:string. Определим в библиотеке типов (см. рис. 2) два новых свойства: CompanyName:string и CopyrightYear:integer. В методах *Read и *Wirte для этих свойств определим чтение и возврат данных из описанных выше переменных. В библиотеку типов добавим новый метод ShowCopyright, который реализуем следующим образом:

В созданном ранее файле Test.asp изменим код на языке VBScript:

Результатом обращения к ASP-объекту при помощи команды http://10.10.10.65/Test/Test.asp (вместо 10.10.10.65 следует ввести IP-адрес вашего сервера) будет генерация следующей страницы (рис. 6).

Если в файле Test.asp изменить имя компании (а это можно сделать при помощи любого текстового редактора), соответствующие изменения отобразятся в HTML-документе.

При помощи ASP-объектов можно передавать не только текстовую информацию, но и двоичную, например графические изображения. Создадим обычную HTML-страницу следующего вида:

Файл Test1.asp выглядит следующим образом:

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

Метод GetPicture реализуем следующим образом:

Для передачи двоичных данных необходимо указать их тип в свойстве Response.ContentType и воспользоваться методом BinaryWrite объекта Response. В качестве параметра этого метода используется переменная типа OLEVariant. В этой переменной должны находиться двоичные данные в виде массива байтов. Этот массив передается как отклик. В результате обращения к исходному HTML-документу клиент получит отклик (рис. 7).

До сих пор мы рассматривали in-process-серверы, которые работают в адресном пространстве Internet Information Server и реализуются в динамически загружаемых библиотеках — DLL. В заключение следует сказать и о создании out-of-process ASP-серверов. Такие серверы реализуются в виде исполняемых файлов и работают в отдельном адресном пространстве.

Для создания out-of-process-сервера необходимо открыть готовый проект, компиляция которого приводит к созданию исполняемого файла, или создать новый проект с помощью пункта меню File|New Application. После этого следует выбрать пункт главного меню File|New среды разработки Delphi, а затем со страницы ActiveX репозитария объектов — пиктограмму Active Server Object. В результате будет сгенерирована библиотека типов, содержащая методы OnStartPage и OnEndPage. Все, что было сказано выше по поводу in-process-сервера, справедливо и в отношении out-of-process-сервера: разработка ASP-объекта заключается в создании новых методов, которые будут вызываться из VBScript-кода ASP-страницы.

Сложности возникают при попытке протестировать out-of-process-сервер. По умолчанию параметры настройки Internet Information Server таковы, что запуск им приложений запрещен, а разрешена только загрузка DLL. Более того, в администраторе Internet Information Server отсутствует опция, позволяющая разрешить или запретить использование приложений как ASP-серверов. Для разрешения запуска исполняемого файла как ASP-сервера необходимо выполнить следующий код:

Для выполнения данного скрипта необходимо, чтобы пользователь, инициирующий его выполнение, имел статус администратора. По этой причине данный скрипт бесполезно определять в HTML-документе и запускать его с использованием Internet Explorer, так как любой пользователь Internet имеет статус гостя (Guest), а не администратора. Скрипт необходимо поместить в обработчик какого-либо события в среде разработки Visual Basic или VBA и запустить его оттуда (либо использовать Windows Scripting Host. — Прим.ред.).

К сожалению, в Delphi отсутствует метод, аналогичный методу VBScript GetObject. Очевидно, что метод GetObject возвращает ссылку на интерфейс IDispatch Internet Information Server. Однако при этом в качестве параметра он использует строку, которая не является классовой (ее GUID отсутствует в системном реестре). В Delphi аналогичных методов нет, по крайней мере, в виде простых вспомогательных функций. Возможно, подобный метод станет доступным в следующих версиях Delphi.

Разработка элементов управления ASP.NET на примере навигационной панели (исходники)

Эта проблема стара, как само веб-программирование — даже на самом простом сайте нам нужна панель навигации (или меню). Ну да, та самая, где написано: «О компании», «Услуги», «Прайс-лист», «Сервис» и «Контакты».

Давным-давно я писал её на Perl и SSI, потом на PHP, потом на ASP, и конца этому не было, пока не вышла 2-ая версия ASP.NET.

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

Кроме того, мы получили компоненты для отображения структуры сайта: TreeView , Menu и SiteMapPath . Казалось бы — вот оно, счастье!

Однако нет. Я обнаружил, что простым сайтам нужна лёгкая линейная структура, и встроенные компоненты оказываются для этого случая слишком «громоздкими». Вроде всё хорошо, но не совсем понятно, стоит ли для пары-тройки ссылок подгружать столько кода на JavaScript.

С другой стороны, дизайнеры тоже не дремлют — иногда с ними можно договориться о цвете ссылок, но если речь идёт о навигации, они непреклонны. Хорошо, если ребята не настаивают на ручной отрисовке каждого пункта меню, но вот подложку и roll-over им надо сделать обязательно. И объяснить, что TreeView или Menu для этого не предназначены, чертовски сложно.

Единственное, что нам остаётся — написать подходящий компонент самостоятельно. Этим мы и займёмся.

Для примера возьмём самую простую структуру сайта:

xml version =»1.0″ encoding =»utf-8″ ? >
siteMap xmlns =»http://schemas.microsoft.com/AspNet/SiteMap-File-1.0″ >
siteMapNode url =»

/Default.aspx» title =»Главная страница» >
siteMapNode url =»

/Services.aspx» title =»Услуги и цены» />
siteMapNode url =»

/Contacts.aspx» title =»Контакты» />
siteMapNode >
siteMap >

Нам бы хотелось получить тривиальную панель навигации, например, вот такого вида:

/ Главная страница / Услуги и цены / Контакты /

Текущая страница должна выводиться простым текстом, а все остальные — ссылками.

В коде страницы мы хотим задействовать шаблоны (такие же, как и в компоненте Repeater):

binateq:NavigationPanel ID =»NavigationPanel1″
runat =»server» DataSourceID =»SiteMapDataSource1″ >
HeaderTemplate > / HeaderTemplate >
ItemTemplate >
a href =` ` > #Container.Title %> a > /
ItemTemplate >
SelectedItemTemplate >
span > #Container.Title %> span > /
SelectedItemTemplate >
binateq:NavigationPanel >
asp:SiteMapDataSource ID =»SiteMapDataSource1″ runat =»server» />

Если свести все требования воедино, нужно, чтобы компонент:

• Умел подключаться к SiteMapDataSource и разворачивал структуру сайта в линейный список.
• Использовал шаблоны, разные для текущей страницы и для всех остальных.

Нам «всего лишь» осталось реализовать два перечисленных выше пункта, и затем сделать так, чтобы у нас получился компонент, который можно подвесить на панель инструментов (Toolbox).

Подключение к SiteMapDataSource

Для того, чтобы наш компонент мог подключиться кSiteMapDataSource, мы должны унаследовать его от класса System.Web.UI.WebControls.HierarchicalDataBoundControl и переопределить виртуальный метод PerformDataBinding

public class NavigationPanel: HierarchicalDataBoundControl
<
protected override void PerformDataBinding()
<
base .PerformDataBinding();
nodes.Clear();

if (!IsBoundUsingDataSource >null ))
return ;

HierarchicalDataSourceView view = GetData( string .Empty);

if (view != null )
<
IHierarchicalEnumerable enumerable = view.Select();

RecurseDataBind(enumerable, 1);
>
>
>
Для начала мы должны убедиться, что программист установил одно из свойств DataSource или DataSourceID . Если панель навигации не подключена к SiteMapDataSource (то есть ни одно из свойств не установлено), посетитель сайта увидит содержимое шаблона EmptyTemplate .

Обратите внимание, что DataSource мы проверяем сами, а вот для ревизии DataSourceID необходимо обратиться к свойству IsBoundUsingDataSourceID .

Непосредственный доступ к данным возможен через представление (класс HierarchicalDataSourceView ), то есть тем же способом, каким мы работаем с любым источником данных в .NET, будь то SqlDataSource или XmlDataSource .

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

Всю работу по извлечению данных выполняет наш метод RecurseDataBind , который рекурсивно вызывает сам себя:

private void RecurseDataBind(IHierarchicalEnumerable enumerable, int level)
<
foreach ( object item in enumerable)
<
IHierarchyData hierarchyData = enumerable.GetHierarchyData(item);
SiteMapNode siteMapNode = hierarchyData as SiteMapNode;

if (siteMapNode != null )
<
if ( HttpContext .Current == null //
siteMapNode.IsAccessibleToUser( HttpContext .Current))
<
bool isSelected =
(siteMapNode.Prov >null ) ?
false :
(siteMapNode.Prov >
nodes.Add(
new Node(
ToAbsolute(siteMapNode.Url),
siteMapNode.Title,
siteMapNode.Description,
level,
isSelected
)
);
>

if (hierarchyData.HasChildren)
<
IHierarchicalEnumerable recurseEnumerable =
hierarchyData.GetChildren();

if (recurseEnumerable != null )
RecurseDataBind(recurseEnumerable, level + 1);
>
>
>
>

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

С помощью вызова IsAccessibleToUser мы прячем от неавторизованного посетителя недоступные страницы. Авторизация работает только во время исполнения, когда установлено свойство HttpContext.Current , поэтому при настройке компонента в Visual Studio (design mode) все страницы видимы.

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

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

Функция ToAbsolute переводит виртуальные пути (

/Default.aspx ) в абсолютные ( /Default.aspx ). Фактически, она вызывает VirtualPathUtility.ToAbsolute , но кроме того, обрабатывает ситуации, когда в качестве пути заданы полные URI ( http://domain.tld/path/filename.ext ).

Результатом работы метода RecurseDataBind становится список объектов класса Node, который мы обсудим позднее.

Для того, чтобы наш класс понимал шаблоны, мы должны описать свойства класса ITemplate и установить для них несколько атрибутов:

private ITemplate headerTemplate = null ;
private ITemplate footerTemplate = null ;
private ITemplate itemTemplate = null ;
private ITemplate selectedItemTemplate = null ;
private ITemplate emptyTemplate = null ;
…
[Browsable( false )]
[PersistenceMode(PersistenceMode.InnerProperty)]
[DefaultValue( typeof (ITemplate), «» )]
[TemplateContainer( typeof (Node))]
public virtual ITemplate HeaderTemplate
<
get < return headerTemplate; >
set < headerTemplate = value ; >
>

В целях экономии места, я опустил описание свойств FooterTemplate , ItemTemplate , SelectedItemTemplate и EmptyTemplate , которые полностью идентичны описанию HeaderTemplate .

С помощью атрибутов мы указываем визуальному редактору (т.е. Visual Studio), как обрабатывать эти свойства:

• Browsable(false)
  Свойства-шаблоны недоступны на панели Properties во время редактирования. Такое же поведение характерно для «родных» компонентов ASP.NET.
• PersistentMode(PersistentMode.InnerProperty)
  Шаблоны в коде странице представлены не в виде атрибутов, а в виде вложенных тегов. Пользуясь этой подсказкой, в Visual Studio работает IntelliSense.
• DefaultValue(typeof(ITemplate), «»)
  Значением по умолчанию является пустой шаблон (без текста и вложенных тегов). Этот атрибут позволяет перевести значение свойства в исходное состояние.
• TemplateContainer(typeof(Node))
  Одно из самых важных свойств, которое обеспечивает привязку к данным (data binding). О подробностях мы поговорим ниже.

Генерация кода страницы выполняется в методе CreateChildControls :

protected override void CreateChildControls()
<
Controls.Clear();

if (nodes.Count > 0)
<
InstantiateTemplate(headerTemplate);

foreach (Node node in nodes)
<
if (node.IsSelected)
InstantiateNodeTemplate(selectedItemTemplate, node);
else
InstantiateNodeTemplate(itemTemplate, node);
>

InstantiateTemplate(footerTemplate);
>
else
InstantiateTemplate(emptyTemplate);
>

Два вспомогательных метода InstantiateTemplate и InstantiateNodeTemplate я написал, чтобы упростить CreateChildControls :

private void InstantiateTemplate(ITemplate template)
<
if (template != null )
<
Control templateHolder = new Control();
template.InstantiateIn(templateHolder);
Controls.Add(templateHolder);
>
>

private void InstantiateNodeTemplate(ITemplate template, Node node)
<
if (template != null )
<
template.InstantiateIn(node);
Controls.Add(node);
node.DataBind();
>
>

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

Эту работу выполняет метод InstantiateIn , которому требуется родительский объект Control , где и будут созданы дочерние элементы управления. Если программист определил шаблон в коде страницы, ASP.NET создаёт для нас объект, реализующий интерфейс ITemplate , в том числе и этот метод.

В методе InstantiateNodeTemplate мы пользуемся уже готовым объектом класса Node , который также является наследником Control . Для того чтобы в код шаблона попали значения выражений вида , мы вызываем метод DataBind .

Давайте подробнее остановимся на том, как происходит связывание с данными (data binding):

• Данные нужно сначала получить, а затем вставить в Control . Метод InstantiateIn устроен так, что получение данных и отображение выполняется через один и тот же объект, поэтому наш класс Node с одной стороны содержит свойства Url , Title , Description , а с другой — наследует классу Control и используется для отображения шаблона. Такой подход снижает зацепление , т.е. класс выполняет действия, которые никак друг с другом не связаны, и делать так не рекомендуется. Что ж, это тот самый случай, когда мы ничего не можем исправить.
• Если мы используем внутри шаблона элементы управления, у которых установлен атрибут ID , он будет дублироваться у повторяющихся шаблонов, что приведёт к ошибке. Речь идёт о таких конструкциях, как:

ItemTemplate >
asp:LinkButton ID =» LB » runat =» server » Text =» Container . Title %>» OnClick =» LB_Click » />
ItemTemplate >

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

public override void DataBind()
<
base .DataBind();
CreateChildControls();
ChildControlsCreated = true ;
>

Метод base.DataBind среди прочего вызывает PerformDataBinding , и сразу после этого мы создаём дочерние компоненты на базе шаблонов.

Доводим компонент до ума

Поддержка ViewState и сериализация

Для того чтобы на странице автоматически работали такие компоненты, как GridView и Repeater , ASP.NET вызывает метод DataBind при первой загрузке страницы. Метод вызывается рекурсивно для всех компонентов страницы, они получают данные и сохраняют их в ViewState. При повторных запросах POST данные не считываются до тех пор, пока мы сами этого не сделаем.

Мы должны обеспечить такое же поведение для класса Node , иначе навигационная панель будет «пропадать» со страницы при запросах POST.

Технически, это делается в два этапа:

• Мы переопределяем методы SaveViewState и LoadViewState у класса NavigationPanel .
• Мы делаем класс Node сериализуемым.

Код методов SaveViewState и LoadViewState достаточно прост, поэтому я не буду останавливаться на нём подробно:

protected override object SaveViewState()
<
object [] currentStates = new object [nodes.Count + 1];
currentStates[0] = base .SaveViewState();

for ( int i = 0; i return ( object )currentStates;
>

protected override void LoadViewState( object savedState)
<
if (savedState != null )
<
object [] currentStates = ( object [])savedState;

Оба метода предполагают, что объекты класса Node умеют себя сохранять (сериализовывать) и восстанавливать (десериализовывать). В простейших случаях, когда речь идёт о сохранении/восстановлении публичных свойств, достаточно пометить класс атрибутом Serializable , и .NET сам сможет выполнить необходимую работу.

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

Чтобы её решить, мы должны реализовать в классе Node интерфейс ISerializable , то есть один-единственный метод GetObjectData :

[SecurityPermission(SecurityAction.LinkDemand, Flags =
SecurityPermissionFlag.SerializationFormatter)]
public void GetObjectData(SerializationInfo info, StreamingContext context)
<
info.AddValue( «Url» , url);
info.AddValue( «Title» , title);
info.AddValue( «Description» , description);
info.AddValue( «Level» , level);
info.AddValue( «IsSelected» , isSelected);
>

Кроме того, мы должны добавить в класс защищённый конструктор, который создаёт объект из сохранённых ранее значений:

protected Node(SerializationInfo info, StreamingContext context)
<
url = info.GetString( «Url» );
title = info.GetString( «Title» );
description = info.GetString( «Description» );
level = info.GetInt32( «Level» );
isSelected = info.GetBoolean( «IsSelected» );
>

Узлы дерева мы храним в закрытом поле nodes :

Родительский блок DIV

Компонент NavigationPanel является наследником WebControl , который требует, чтобы содержимое компонента размещалось внутри одного из HTML-тегов. По умолчанию в качестве родительского тега используется SPAN , но нам больше подошёл бы тег DIV . Чтобы этого добиться, достаточно переопределить защищённое свойство TagKey :

При описании компонента NavigationPanel мы должны установить несколько атрибутов, чтобы Visual Studio могла правильно работать с ним в коде страницы:

[assembly:TagPrefix( «Binateq.Web.Controls» , «binateq» )]
namespace Binateq.Web.Controls
<
[AspNetHostingPermission(SecurityAction.Demand, Level = AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.InheritanceDemand, Level =
AspNetHostingPermissionLevel.Minimal)]
[ParseChildren( true )]
[ToolboxData(
» »
)]
public class NavigationPanel: HierarchicalDataBoundControl
<
…
>
>

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

В свойстве assembly:TagPrefix задаётся префикс для компонентов, который будет использован Visual Studio. Обычно она сама генерирует их (uc1, uc2 и т.д.), но такие названия бессмысленны, поэтому я предпочитаю указать префикс при написании компонента.

Атрибут ParseChildren указывает Visual Studio на то, что теги внутри трактуются как значения свойств, то есть содержимое тега HeaderTemplate будет присвоено свойству NavigationPanel.HeaderTemplate .

Атрибут ToolBoxData подсказывает Visual Studio, что именно нужно вставить в код страницы при добавлении компонента. Вместо <0>будет вставлен префикс, в нашем случае binateq.

Помимо основного файла NavigationPanel.cs вы найдёте там вспомогательный — Utilities.cs , в котором собраны методы для корректного преобразования виртуальных, абсолютных и относительных путей (тот самый метод ToAbsolute , про который я не стал писать в статье).

Можно подключить компонент к панели инструментов Visual Studio. Для этого распахните Toolbox , щёлкните правой кнопкой мыши внутри закладки General и выберите пункт Choose Items . В открывшемся диалоге нажмите кнопку Browse и загрузите Binateq.Controls.dll .

После этого навигационную панель можно будет перетаскивать с панели инструментов в код страницы. Visual Studio автоматически вставит в начало страницы строку , и добавит в проект ссылку (reference) на Binateq.Controls.dll .

При выводе структуры сайта мы можем исключить корневую страницу, установив SiteMapDataSource.ShowStartingNode в false . Мы также можем выводить многоуровневую структуру, воспользовавшись свойством Container.Level :

ItemTemplate >
div class =»level » >
a href =` ` > #Container.Title %> a >
div >
ItemTemplate >
SelectedItemTemplate >
div class =»level » >
#Container.Title %>
div >
SelectedItemTemplate >

Определив в таблице стилей классы div.level1 , div.level2 , div.level3 , мы можем с помощью отступов отразить древовидную структуру сайта. Существующий компонент не умеет ограничивать количество уровней вложенности, и за этим придётся следить самостоятельно. Вы можете внести в код компонента необходимые изменения, добавив свойство, например, MaxLevel , и заменив в коде RecourseDataBind

if (hierarchyData.HasChildren && (maxLevel == 0 // maxLevel > level))

Если MaxLevel будет равен 0, то компонент будет показывать все уровни, а если, например, 5, то только первые 5.

Дипломная работа: Разработка информационной системы для предприятия по установке газового оборудования

Дипломный проект содержит 112 страниц, 45 рисунков, 15 таблица, 46 источников, 6 приложения.

ИНФОРМАЦИОННАЯ СИСТЕМА, РАБОТА С ДАННЫМИ, ИНТЕФЕЙС, ТРЕБОВАНИЯ, МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА, МОДЕЛИРОВАНИЕ, ПРОЕКТИРОВАНИЕ, РЕАЛИЗАЦИЯ, ФИЗИЧЕСКАЯ МОДЕЛЬ СТРУКТУРЫ ДАННЫХ, БАЗА ДАННЫХ, ТЕСТИРОВАНИЕ.

Темой дипломного проекта является «Разработка информационной системы предприятия по установке газового оборудования».

В качестве информационного обеспечения используется база данных под управлением СУБД Microsoft SQL Server 2005 Enterprise Edition.

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

Конечным результатом дипломного проекта является программный комплекс «Информационная система предприятия» внедренный и успешно применяемый в данном предприятии.

The diploma project includes 112 pages of explanatory note, 45 pictures, 15 tables, 46 literary sources, 6 attachments.

THE INFORMATION SYSTEM, WORKING WITH DATA, INTERFACE, REQUIREMENTS, THE PRODUCT LIFE CYCLE MODEL, MODELLING, DESIGNING, REALIZATION, PHYSICAL MODEL OF DATA STRUCTURE, THE DATABASE, TESTING.

The title of the diploma project is «Designing of the Information System for the Gas Fitting Enterprise».

As an information source of the application, the database under control of DBMS Microsoft SQL Server 2005 Enterprise Edition is used.

The sources of the data for the diploma project were books, periodicals, electronic resources, documents of the organization that were used as theoretical basis for solving the problem. The literary sources were also used as manuals for the project realisation.

The end product of the diploma project is a software package called «the Information System of the Enterprise» implemented and successfully applied in this gas fitting enterprise.

1. Разработка требований к программному обеспечению

1.1 Анализ предметной области

1.2 Анализ существующих решений по автоматизации предметной области

1.3 Выбор методологии проектирования информационной системы

1.4 Сбор требований

1.5 Спецификация требований

1.6 Анализ и моделирование требований

1.7 Аттестация требований

2 Проектирование информационной системы

2.1 Архитектурное проектирование

2.2 Проектирование пользовательского интерфейса

2.3 Проектирование базы данных

2. 4Обоснование выбора платформы создания информационной системы

3 Реализация и аттестация информационной системы

3.1 Реализация приложения

3.2 Взаимодействие приложения с источниками данных

3.3 Тестирование приложения

3.4Методика развертывания приложения

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

4.1 Выбор жизненного цикла разработки информационной системы

4.2 Определение цели и области действия программного проекта

4.3 Создание структуры пооперационного перечня работ

4.4 Идентификация задач и действий

4.5 Оценка размера и возможности повторного использования ПО

4.6 Оценка длительности и стоимости разработки проекта

4.7 Распределение ресурсов проекта

4.8 Оценка экономической эффективности проекта

Список используемых источников

Приложение А – спецификация требований к программному обеспечению

Приложение Б – Атрибуты управляющих таблиц проектируемой ИС

Приложение В – Скрипт базы данных информационной системы

Приложение Г — Фрагмент исходного кода программы

Приложение Д − Обоснование выбора модели жизненного цикла

Приложение Е – Диаграмма ганта

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

Рассматриваемая дипломная работа написана на базе предприятия по установке газового оборудования ИП Попов Г.В. «ДонГаз» г. Донецк.

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

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

Программа должна обеспечивать:

— работу с входными данными;

— получение выходных документов;

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

Для достижения вышеуказанной цели необходимо решить следующие задачи:

— осуществить бизнес-моделирование процессов предприятия, для разрабатываемой информационной системы;

— провести анализ требований к системе и ее проектирование;

— разработать концептуальную и физическую модели данных;

— провести оценку эффективности технологии разработки.

1.1Анализ предметной области

Целью программного комплекса, разработанного в рамках дипломного проекта, является автоматизация деятельности предприятия по установки газового оборудования «ДонГАЗ».

Для того чтобы внести ясность в понятия газификации, воспользуемся определениями, данными в Федеральном законе от 31.03.1999 N69 ФЗ «О ГАЗОСНАБЖЕНИИ В РОССИЙСКОЙ ФЕДЕРАЦИИ» [45].

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

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

Основами создания и развития единого рынка газа на территории Российской Федерации являются:

— формирование круга потребителей газа на основе широкого внедрения газа как энергетического и топливного ресурса в производство и быт на территориях субъектов Российской Федерации — развитие газификации;

— создание экономически взаимовыгодных отношений потребителей и поставщиков газа;

— создание условий надежного обеспечения газом потребителей различных категорий;

— проведение государственной политики ценообразования, направленной на развитие единого рынка газа.

Для того чтобы более четко разобраться с предметной областью [36] и понять, что требуется от проектируемой информационной системы далее приводится описание существующих бизнес-процессов [4], которые подлежат автоматизации.

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

Бизнес актер (business actor) – индивидуум, группа, организация, компания или система, которые взаимодействуют с моделируемой бизнес – системой, но не входят в неё, т.е. не являются частью моделируемой системы.

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

Сотрудник (business worker) – индивидуум, который действует внутри моделируемой бизнес системы, взаимодействует с другими сотрудниками и является участником бизнес – процесса моделируемой системы.

Примерами сотрудников являются менеджеры, администраторы, кассиры, инженеры. Общее свойство сотрудников заключается в том, что они являются субъектами и входят в состав моделируемой системы.

Бизнес — вариант использования (business use case) – вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес – процесса.

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

Применение этих элементов графической нотации позволяет разработать адекватную модель бизнес – процессов организации.

На рисунке 1.1 представлена схема бизнес-процесса по формированию заказа клиента.

Рисунок 1.1 – Бизнес-процесс «Формирование заказа клиента»

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

На рисунке 1.2 представлена схема бизнес-процесса расчет с клиентом.

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

На рисунке 1.3 представлена схема бизнес-процесса контроль по срокам гарантии.

Рисунок 1.3 – Бизнес-процесс «Контроль по срокам гарантии»

Целью данного бизнес-процесса является контроль по срокам гарантии установленного оборудования. Этот бизнес-процесс является неотъемлемой частью взаимодействия с клиентом.

На рисунке 1.4 представлена схема бизнес-процесса формирование заказа на оборудование.

Рисунок 1.4 – Бизнес-процесс «Формирование заказа на оборудование»

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

На рисунке 1.5 представлена схема бизнес-процесса формирование прайса оборудования.

Рисунок 1.5 – Бизнес-процесс «Формирование прайса оборудования»

Для того чтобы сотруднику было проще составлять заказы для этого он формирует прайс оборудования предоставляемого поставщиками. На рисунке 1.6 представлена схема бизнес-процесса составление плана работ.

Рисунок 1.6 – Бизнес-процесс «Составление плана работ»

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

На рисунке 1.7 представлена схема бизнес-процесса составление индивидуального плана работ для внештатных сотрудников.

Рисунок 1.7 – Бизнес-процесс «Составление индивидуального плана работ для внештатных сотрудников»

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

На рисунке 1.8 представлена схема бизнес-процесса составление акта о выполненной работе.

Рисунок 1.8 – Бизнес-процесс «Составление акта о выполненной работе»

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

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

На рисунке 1.9 представлены объекты, составляющие бюджетную классификацию Российской федерации. В таблице 1.1 представлена расшифровка объектов представленных на рисунке 1.9.

Рисунок 1.9 — Объекты и сущности предметной области

Таблица 1.1 — Объекты и сущности предметной области

процентная наценка на оборудование

менеджер по работе с клиентами

заказ на оборудование

начальник отдела по установке оборудования

акт о выполненной работе

список внештатных сотрудников

сотрудник отдела по установке оборудования

1.2Анализ существующих решений по автоматизации предметной области

Среди существующих программных решений по автоматизации следует отметить автоматизированную информационную систему «Информационная система предприятия» Разработчик: «ИНФОРЕСУРС», на платформе «1С:Предприятие 8». Конфигурация имеет сертификат «Совместимо! Система программ 1С:Предприятие» и позволяет эффективно организовать работу с документами в электронной форме.

Основные возможности программы:

— единый архив документов и справочной информации;

— ведение справочников, хранящих контактную и другую информацию об организации, сотрудниках, контрагентах и физических лицах;

— предопределенный набор типовых видов документов, отражающих предметную область, возможность расширения состава документов;

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

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

— регистрация первичных документов и хранение их электронных копий;

— формирование реестров документов;

— формирование заданий на исполнение, контроль исполнения документов, отчеты по исполнительской дисциплине;

— учет важных документов по местам хранения;

— работа со списками документов — группировки документов в дела;

— все документы системы включены в систему документооборота;

— схемы обработки (маршруты движения) документов доступны для редактирования и настройки под особенности работы;

— организация очередей обработки документов.

— оперативный журнал событий, заданий;

— пообъектный учет (управленческий учет ОС, учет библиотечного фонда, учет оборудования в разработке, в комплекте с проектной документацией и т.п.);

— аудит действий пользователя в системе;

— средства совместной работы над документами — блокировки, удостоверение содержания;

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

Технические особенности реализации: Конфигурация для своей работы требует установленную программную оболочку «1С:Предприятие 8», не защищена аппаратным ключом и поставляется с исходными текстами модулей. Фрагменты конфигурации, отвечающие за использования внешних справочников через Интернет, обмен документами, поставляются без исходных текстов и не могут быть изменены. В конфигурации предусмотрена возможность локализации и работа пользователей на нескольких языках в рамках одной информационной базы. Особенности лицензирования: Основная поставка дает право на работу с одной информационной базой (информационная база может быть распределенной) и не ограничивает пользователя рамками локальной сети. Дополнительная лицензия позволяет работать одновременно с любым количеством поставок.

1.3 Выбор методологии проектирования информационной системы

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

Существует две основных методологии проектирования:

— методология структурного проектирования;

— методология объектно-ориентированного проектирования.

Структурный подход. Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов [37].

Все компоненты информационной системы взаимосвязаны, система разрабатывается сверху — вниз. При разработке системы снизу – вверх целостность теряется, возникают проблемы состыковки компонентов.

Наиболее распространенные модели структурного подхода:

SADT – Structured Analysis and Design Techniques – описывает модели и функциональные диаграммы;

DFD – Data Flow Diagrams – диаграммы потоков данных;

ERD – Entity Relationship Diagrams – диаграммы «сущность – связь».

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм [38].

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

Объектно-ориентированный подход. Центральным понятием объектно-ориентированного подхода к проектированию является класс. Класс – это выделение из окружающего мира некой сущности, для которой определены атрибуты (свойства) и операции (действия, которые сущность производит над окружающими объектами).

Объект – это конкретная реализация некоторой сущности. В объекте инкапсулируется некоторая часть приложения, которая может представлять собой процесс, группу данных или какую-либо более сложную сущность [6].

Для реализации проекта был выбран объектно-ориентированный подход в силу следующих факторов:

— возможность повторного использования кода;

— повышение безопасности кода за счет инкапсуляции;

— гибкость при модификации и расширении системы;

— отсутствие необходимости разработки классов с нуля, за счет наследования;

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

1.4Сбор требований

Основная цель рабочего процесса определения требований состоит в том, чтобы направить процесс разработки на получение правильной системы. А правильная система – это система, которая делает то, что необходимо и ничего более. Требование — это характеристика или условие, которому должна удовлетворять система [40].

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

Сбор требований – это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований [9].

На этапе формирования и анализа требований в соответствии с технологией разработки программного обеспечения Microsoft Solution Framework (MSF):

— осуществляется сбор требований;

— составляются профили заинтересованных лиц;

— разрабатываются варианты использования.

Сбор требований осуществлялся на основе использовании метода интервьюирования.

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

— система должна охватывать основные бизнес-процессы предприятия;

— система должна обеспечивать защиту информационной базы данных от несанкционированного доступа;

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

— система должна иметь возможность наращивания в программной части;

— система должна позволять экспорт выходных документов

1.5 Спецификация требований

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

Спецификация требований — процесс документирования системы в структурированном, доступном всем и управляемом формате. Спецификация требований (Software Requirements Specification, SRS) используется для текущего сопровождения проекта и представления требований, сформулированных по отношению к проекту. SRS позволяет определить предметную область программного продукта, рассматриваемого относительно трех его основных составляющих: данных, процесса и поведения. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом, приемке проекта и связанных с проектом функциях [42, 9]. SRS имеет ключевое значение для всего жизненного цикла разработки программного продукта. Это не только производный документ, в котором определены спецификации программного проекта, но и основной документ, применяемый с целью проведения аттестационных и приемочных испытаний.

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

Благодаря спецификации SRS облегчается передача программного продукта новым пользователям, а также его установка на других компьютерах. Таким образом, заказчикам становится проще переносить программный продукт в другие подразделения организации, а разработчикам — передавать другим заказчикам [3].

Разработанная спецификация для информационной системы представлена в приложении А.

1.6 Анализ и моделирование требований

Для того чтобы определить функциональные требования, предъявляемые к системе, необходимо, прежде всего, выявить лиц заинтересованных в этой системе, а затем определить тот функционал, который им требуется для осуществления своей профессиональной деятельности [2, 42].

Заинтересованные в системе пользователи, которые были выявлены в процессе исследования бизнес-процессов и предпроектного обследования предприятия, представлены на рисунке 1.10

Рисунок 1.10 – Пользователи системы

На данной схеме изображены основные пользователи информационной системы предприятия.

Дадим краткую характеристику каждому классу пользователей системы.

Менеджер по работе с клиентами – сотрудник занимающийся приемом заказов и последующей работе с клиентами.

Начальник отдела по установки оборудования – сотрудник занимающийся закупкой оборудования, поддержкой связи с поставщиками и планированием работ.

Сотрудник отдела по установке оборудования – занимается внештатными сотрудниками, также принимает участие в составление плана работ.

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

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

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

В процессе выполнения прецедента «Формирование заказа» пользователь выполняет поэтапное формирование заказа, последовательно вводя данные о клиенте.

В процессе выполнения прецедента «Утверждение заказа» в системе фиксируется состояние заказа, и дальнейшая его модификации.

В процессе выполнения прецедента «Передача заказа в отдел по установки оборудования» происходит передача заказа для дальнейшего его выполнения.

Рисунок 1.11– Варианты использования системы менеджером по работе с клиентами

В процессе выполнения прецедента «Внесение изменений» пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т.е. если не выполнялся прецедент «Утверждение заказа».

В процессе выполнения прецедента «Контроль по срокам гарантии» пользователь следит за сроками гарантии на оборудование.

В процессе выполнения прецедента «Расчет с клиентом» пользователь формирует счет.

На рисунке 1.12 представлены варианты использования системы начальником отдела по установки оборудования.

В процессе выполнения прецедента «Формирование заказа поставщикам» пользователь выполняет поэтапное формирование заказа поставщикам.

В процессе выполнения прецедента «Утверждение заказа поставщикам» в системе фиксируется состояние заказа, и дальнейшая его модификации.

В процессе выполнения прецедента «Внесение изменений в заказ поставщикам» пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т.е. если не выполнялся прецедент «Утверждение заказа поставщикам».

В процессе выполнения прецедента «Составление акта о выполненной работе» пользователь составляет акт о проделанной работе.

В процессе выполнения прецедента «Составление плана работ» пользователь составляет план работ в соответствии с принятым заказом.

В процессе выполнения прецедента «Формирование прайса» пользователь формирует прайс, следит за ценами, обновляет их.

Рисунок 1.12 – Варианты использования системы менеджером по персоналу

На рисунке 1.13 представлены варианты использования системы сотрудником отдела по установки оборудования.

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

В процессе выполнения прецедента «Формирование заказа поставщикам» пользователь выполняет поэтапное формирование заказа поставщикам.

В процессе выполнения прецедента «Внесение изменений в заказ поставщикам» пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т.е. если не выполнялся прецедент «Утверждение заказа поставщикам».

В процессе выполнения прецедента «Составление плана для сотрудников» пользователь составляет план работ в соответствии с принятым заказом для каждого внештатного сотрудника в отдельности.

В процессе выполнения прецедента «Определение коэффициента участия сотрудников» пользователь определяет степень участия сотрудника.

В процессе выполнения прецедента «Формирование списка внештатных сотрудников» пользователь формирует список сотрудников для выполнения работ.

На рисунке 1.14 представлены варианты использования системы администратора автоматизированной системы.

В процессе выполнения прецедента «Регистрация пользователя» администратор регистрирует в системе новую учетную запись.

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

Рисунок 1.14 – Варианты использования системы специалистом администратором

В процессе выполнения прецедента «Удаление пользователя» администратор удаляет учетную запись пользователя и списка зарегистрированных в системе.

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

1.7 Аттестация требований

Аттестация требований – процесс проверки требований на достоверность, непротиворечивость, полноту и выполнимость.

Существует набор методов аттестации, которые можно использовать как вместе, так и по отдельности:

— обзор требований – процесс просмотра системной спецификации на предмет неточных описаний и ошибок;

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

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

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

Выводы к разделу

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

В качестве методологии проектирования обосновано применение объектно-ориентированного подхода.

1.8 Архитектурное проектирование

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

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

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

— соответствие с миссией организации;

— определенность в требованиях;

— направленность в разработке;

— возможность к адаптации;

Соблюдение всех этих условий позволяет разработать архитектуру информационной системы организации более совершенной и эффективной [12].

Программные архитектуры, используемые в настоящее время:

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

Клиент-сервер. В основе этой концепции лежит идея о том, что помимо хранения файлов базы данных, центральный сервер должен выполнять основную часть обработки данных. Пользователи обращаются к центральному серверу с помощью специального языка структурированных запросов (SQL, Structured Query Language), на котором описывается список задач, выполняемых сервером. Запросы пользователей принимаются сервером и порождают в нем процессы обработки данных. В ответ пользователь получает уже обработанный набор данных. Между клиентом и сервером передается не весь набор данных, как это происходит в технологии файл-сервер, а только данные, которые необходимы клиенту. Запрос пользователя длиной всего в несколько строк способен породить процесс обработки данных, затрагивающий множество таблиц и миллионы строк. В ответ клиент может получить лишь несколько чисел.

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

На рисунке 2.1 представлена схема клиент-серверной архитектуры.

Рисунок 2.1 – Клиент-серверная архитектура.

Архитектура приложения, разделяющая пользовательские и прикладные сервисы и сервисы данных. Другое название — трехуровневая архитектура, однако термин «многоуровневая» корректнее, поскольку он предполагает, что при логическом проектировании может возникнуть более трех уровней сервисов. Многоуровневая архитектура приложения (multi-tiered architecture), способ организации взаимодействия программ или компонентов программы. Как правило, Многоуровневая архитектура приложения используется в распределенных приложениях, компоненты которых выполняются на разных компьютерах. Частным случаем, Многоуровневая архитектура приложения является архитектура клиент-сервер. В последнее время в информационных системах получила распространение архитектура, в которой распределенное приложение состоит из компонентов трех уровней:

— компонент, ответственный за управление данными, выполняется на сервере баз данных;

— компонент, выполняющий обработку данных, выполняется на сервере приложений;

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

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

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

Диаграмма компонентов системы представлена на рисунке 2.2.

Рисунок 2.2 – Диаграмма компонентов информационной системы.

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

Диаграмма развертывания, как и диаграмма компонентов, составляется на завершающем этапе проектирования. Когда уже определена логическая структура функционирования системы [21]. Диаграммы развертывания могут применяться и на этапе анализа. Например, при анализе уже существующей системы, можно строить диаграмму развертывания. Это облегчит понимание физического устройства системы и позволит в дальнейшем ее модифицировать.

1.9 Проектирование пользовательского интерфейса

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

Пользовательский интерфейс клиентской части приложения выполнен в виде Windows-приложения.

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

Пользовательская среда информационной системы предприятия состоит из следующих частей:

— главное меню приложения;

Главное меню приложения служит для доступа ко всем функциям системы.

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

Таблица 2.1. – Структура Главного меню

Войти в систему

Позволяет пользователю войти в систему

Выйти в системы

Позволяет пользователю выйти из системы

Выход из приложения

Позволяет отменить последнее произведенное пользователем действие

Позволяет повторить отмененное ранее действие

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

Позволяет вырезать данные в буфер обмена

Позволяет вырезать данные в буфер обмена

Позволяет создавать новый заказ

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

Просмотреть все заказы

Позволяет просмотреть все созданные заказы

Позволяет просмотреть прайс оборудования

Позволяет формировать новый план работ

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

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

Позволяет создать новый акт

Позволяет просмотреть все выставленные акты

Позволяет упорядочить открытые формы

Список открытых форм

Позволяет переключаться между открытыми формами

Открывать справку по информационной системе предприятия

Выводит информации о разработчиках и версии программы

1.9 Проектирование базы данных

Основными целями проектирования базы данных являются:

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

— создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;

— разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы — например, ко времени реакции системы.

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

Реляционная модель данных в подавляющем большинстве случаев вполне достаточна для моделирования любых данных [17, 18, 26]. Однако проектирование базы данных в терминах схемы отношений на практике может вызвать большие затруднения, т.к. в этой модели изначально не предусмотрены механизмы описания семантики предметной области. С этим связано появление семантических моделей данных, которые позволяют описать конкретную предметную область гораздо ближе к интуитивному пониманию и, в то же время, достаточно формальным образом.

Концептуальное проектирование — сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:

— обследование предметной области, изучение ее информационной структуры;

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

— моделирование и интеграция всех представлений;

По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели «сущность-связь».

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

Рисунок 2.4 — Концептуальная модель данных

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

Логический уровень – это абстрактный взгляд на данные, на этом уровне данные представляются так же, как выглядят в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логический уровень модели данных является универсальным и никак не связан с конкретной реализацией СУБД. При проектировании базы данных было создано несколько таблиц для хранения используемой в системе информации.

Рисунок 2.5 – Логическая модель данных

На основе логической модели данных составляется физическая модель данных. Физический уровень модели данных, в отличие от логического уровня, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физическом уровне модели содержится информация о всех объектах базы данных. Поскольку стандартов на объекты базы данных не существует, физический уровень модели зависит от конкретной реализации СУБД. Физический уровень модели данных изображен на рисунке 2.6.

Рисунок 2.6 — Физическая модель данных

В процессе физического проектирования базы данных в среде MS SQL Server 2005 была создана база данных is_enterprises, состоящая из файлов данных is_enterprises.mdf и файлов журналов транзакций is_enterprises _log.ldf. Принцип отдельного хранения данных и журналов транзакций, а также разбиение этих двух групп информации на различные файлы в SQL Server 2005 необходим для повышения надежности системы.

Листинг SQL-скриптов, создающих информационные структуры сервера баз данных приведен в приложении В.

Перед тем как создавать физическую модель данных необходимо определиться с СУБД, в которой эту модель планируется реализовать.

Одним из требований заказчика является реализация информационного обеспечения на основе Microsoft SQL Server 2005 Enterprise Edition. Построенные на сильных сторонах SQL Server 2000, SQL Server 2005 представляет собой интегрированное решение по управлению и анализу данных, которое поможет организациям различного масштаба:

— строить, развертывать и управлять промышленными приложениями, которые являются более безопасными, масштабируемыми и надежными;

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

— разделять данные между платформами, приложениями и устройствами для облегчения соединения внутренних и внешних систем;

SQL Server является всеобъемлющим, интегрированным сквозным решением, которое наделяет пользователей вашей организации безопасной, надежной, и продуктивной платформой для обработки промышленной информации и приложений, касающихся интеллектуальных ресурсов предприятия. SQL Server 2005 предоставляет мощные, знакомые инструменты для профессионалов информационных технологий так же, как и для работников информационной сферы, уменьшая сложность создания, развёртывания, управления и использования, данных предприятия и аналитических приложений на платформах от мобильных устройств до информационных систем предприятия. Благодаря исчерпывающему набору функций, взаимодействию с существующими системами и автоматизации типовых задач, SQL Server 2005 предоставляет полное решение в области хранения данных для предприятий всех масштабов.

Платформа данных SQL Server 2005 предоставляет организациям всех размеров следующие преимущества:

— использовать активы данных: в дополнение к поставке безопасной, надёжной базы данных для отраслей промышленности и аналитических приложений, SQL Server 2005 позволяет заказчикам получать больше выгоды от их данных включением встроенных функций, таких как отчётность, анализ и извлечение информации;

— увеличить продуктивность благодаря всеобъемлющим возможностям интеллектуальных ресурсов предприятия и интеграции со знакомыми инструментами, такими, как Microsoft Office System, SQL Server 2005 предоставляет работникам информационной сферы вашего предприятия важную, своевременную информацию, приспособленную для их конкретных нужд. Цель — сделать BI доступными для всех пользователей организации и, конечном счёте, позволить пользователям на всех уровнях организации принимать лучшие бизнес решения, основанные на одном из самых ценных активов — их данных;

— уменьшить сложность информационной технологии: SQL Server 2005 упрощает разработку, внедрение и управление отраслями промышленности и аналитическими приложениями, предоставляя программистам гибкую среду разработки и интегрированные, автоматизированные инструменты управления администраторам баз данных;

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

SQL Server 2005 состоит из ряда компонентов, таких, как Integration Services, Analysis Services, Reporting Services, Интеграция с Microsoft Office System.

Reporting Services расширяют платформу Microsoft BI для достижения информационного работника, оценивающего бизнес данные. Reporting Services являются серверной отчётной средой предприятия, управляемой при помощи Web служб. Отчёты могут доставляться во множестве форматов, с диапазоном интерактивных опций и опций печати. Сложный анализ может достичь широкой аудитории посредством распространения отчётов в качестве источника данных для потребителей нижнего уровня.

Построитель Отчётов, новый компонент Reporting Services SQL Server 2005, позволяет пользователям создавать свои собственные отчёты на основе дружественной модели данных. Построитель Отчётов использует платформу Reporting Services для создания специальных отчётов конечных пользователей. Пользователи создают и редактируют отчёты при помощи клиентского приложения Построителя Отчётов. Пользовательский интерфейс Построителя Отчётов создан на основе знакомых парадигм Microsoft Office, таких как Excel и PowerPoint.

Отчёты, которые обслуживаются Сервером Отчётов в Reporting Services, могут выполняться в контексте Microsoft SharePoint® Portal Server и приложений Microsoft Office System, таких как Microsoft Word и Microsoft Excel. Можно использовать функции SharePoint для подписки на отчёты, создания новых версий отчётов и распространения отчётов. Также можно открыть отчёты в Word или Excel для просмотра HTML версии.

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

SQL Server 2005 и Visual Studio 2005 вместе предоставляют более глубокие уровни интеграции между базой данных и средой разработки приложений, чем это было возможно ранее. Разработчики теперь могут создавать управляемые хранимые процедуры, функции, пользовательские типы и пользовательские агрегаты непосредственно из среды Visual Studio. Они также могут развёртывать эти новые объекты базы данных непосредственно из Visual Studio без переключения в другие инструменты. Visual Studio 2005 непосредственно поддерживает все новые типы данных SQL Server, такие как встроенный XML. Также существует возможность добавить все управляемые объекты базы данных в ту же систему контроля версий, которая используется для проектов Visual Studio, что позволяет ещё теснее интегрировать и сделать более безопасным процесс разработки [1].

1.10 Обоснование выбора платформы создания информационной системы

В настоящее время обязательной возможностью считается визуальное проектирование, когда программист строит свои приложения, используя готовые модули. Примером могут служить все современные пакеты для разработчиков – Borland Delphi, ,Microsoft Visual Studio 2005 и т.д.

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

В .NET Framework поддерживается прямая и обратная совместимость. В контексте .NET Framework обратная совместимость означает, что любое приложение, созданное в .NET Framework более ранней версии, будет выполняться и в более поздней версии. Прямая совместимость означает возможность выполнения приложения, созданного в более поздней версии .NET Framework SDK v 2.0, в .NET Framework более ранней версии.

Классы ADO.NET были разработаны для поддержки возможностей новой модели программирования: интеграции с XML, единого представления данных с возможностью комбинирования данных из различных источников, а также средств оптимизации взаимодействия с базой данных, представленных в .NET Framework.

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

.NET представляет собой совершенно новый способ создания распределенных настольных и встроенных приложений. Для типов .NET не нужны ни фабрики классов, ни поддержка Unknown, ни регистрация в системном реестре. Эти основные элементы СОМ не скрыты – их просто больше нет.

Специально для новой платформы Microsoft разработала новый язык программирования – С#, который впитал в себя многое из того лучшего, что есть в самых разных языках программирования, и так же является составной частью Microsoft Visual Studio 2005.

Платформа .NET является полностью независимой от используемых языков программирования. Можно использовать несколько .NET-совместимых языков программирования даже в рамках одного проекта.

Основные возможности .NET следующие:

— полные возможности взаимодействия с существующим кодом;

— полное и абсолютное межъязыковое взаимодействие, межъязыковая обработка исключений и межъязыковая отладка;

— общая среда выполнения для любых приложений .NET, вне зависимости от того, на каких языках они были созданы. Один из важных моментов при этом – то, что для всех языков используется один и тот же набор встроенных типов данных;

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

— отсутствует сложность СОМ;

— действительное упрощение процесса развертывания приложения.

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

Microsoft Visual Studio 2005 продолжает поддерживать технологии Microsoft .NET Framework уже в версии Microsoft .NET Framework SDK v2.0, которые предоставляют общеязыковую среду выполнения и унифицированные классы программирования. Также в Visual Studio включена библиотека MSDN, содержащая документацию по данным инструментам разработки.

Платформа Microsoft.NET для отображения данных на компьютере конечного пользователя и его интерактивного взаимодействия с системой. предоставляет класс System.Windows.Forms.Form и большое разнообразие классов элементов управления, дочерних от класса Control. Функциональность уровня представления во многом определяется составом элементов управления, входящих в коллекцию Controls для конкретной формы.

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

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

Бизнес-логика описывается набором методов, реализующих бизнес-транзакцию. Для платформы Microsoft.NET это типовое решение сценарий транзакций использует прямой доступ к базе данных и базируется на использовании объектов классов DataCommand и DataReader технологии ADO.NET, а так же используя bindingSource, TableAdapter, DataSet . Класс, реализующий сценарий транзакций, обеспечивает прямой доступ к источнику данных и необходимую функциональность бизнес-логики. Для данного типового решения все обязанности по реализации бизнес-логики возлагаются на методы сценария транзакций.

Для разрабатываемой информационной системы выбрана платформа Microsoft Visual Studio 2005. В качестве языка реализации приложения выбран C#.

Выводы к разделу

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

На основании концептуальной модели данных для Microsoft SQL Server 2000 разработана физическая модель данных.

В качестве СУБД обосновано применение Microsoft SQL Server 2005 Enterprise Edition. Для разрабатываемой информационной системы была выбрана платформа Microsoft Visual Studio 2005. В качестве языка реализации приложения выбран C#.

2 Р еализация и аттестация информационной системы

2.1 Реализация приложения

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

В качестве базовой платформы для разработки приложения планируется использовать .Net Framework 2.0 [2, 24, 19].

.NET Framework — это управляемая среда для разработки и исполнения приложений, обеспечивающая контроль типов. Эта среда управляет выполнением программы: она выделяет память под данные и команды, назначает разрешения программе или отказывает в их предоставлении, начинает исполнение приложения и управляет его ходом, а также отвечает за освобождение и повторное использование памяти, занятой ресурсами, более ненужными программе. .NET Framework состоит из двух основных компонентов: общеязыковой исполняющей среды (CLR) и библиотеки классов .NET Framework.

Реализация программного обеспечения – это процесс перевода системной спецификации в работоспособную систему. Разработка приложений подсистемы осуществлялась на языке C# с использованием платформы .Net Framework и входящих в нее библиотек.

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

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

Рисунок 3.1 – Пространство имен

Входящий в состав Microsoft .NET Framework SDK v2.0, в данном проекте использовалось следующее пространственное имя для подключения к базе данных (рисунок 3.2)

Рисунок 3.2 – Пространственное имя для подключения к базе данных

Разработка форм осуществляется с использованием специализированных мастеров Visual Studio .NET. Интегрированная среда разработки Visual Studio .NET позволяет создавать элементы в режиме визуальной разработки, где можно перетаскивать элементы прямо на форму.

В результате работы мастера проекта реализуется каркас формы являющийся экземпляром классов, унаследованного от System.Windows.Forms.Form. При отображении формы во время выполнения программы, этот класс будет использоваться как шаблон для отображения окна. Файлы С# имеют расширение «.cs». Код главной формы изображен на рисунке 3.3. Данная форма является диспетчерской, запускающей дочерние окна данного модуля.

Рисунок 3.3 – Инициализация компонентов формы «Start.cs»

2.2 Взаимодействие приложения с источниками данных

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

Рисунок 3.4 – Пример обращения к базе данных

SQL используется для реализации всех функциональных возможностей, которые СУБД предоставляют пользователю:

— совместное использование данных;

Взаимодействие приложения с источником данных осуществляется при помощи запросов языка SQL. SQL является инструментом для выборки и обработки информации, содержащейся в базе данных. SQL является языком программирования, который применяется для организации взаимодействия пользователя с базой данных [31]. Если пользователю необходимо получить информацию из базы данных, он запрашивает её у СУБД при помощи SQL. СУБД обрабатывает запрос, находит требуемые данные и посылает их пользователю [32]. Процесс запрашивания данных и получения результата называется запросом к базе данных.

На рисунке 3.5 представлен sql-запрос по составлению об установленном оборудовании.

Рисунок 3.5 -Пример sql-запрос

На рисунке 3.6 показан результат выполнения предыдущего sql-запроса.

Рисунок 3.6 – Результат sql-запрос

Также для взаимодействия с источником данных используются хранимые процедуры, написанные на Transact-SQL – это диалект языка SQL, разработанный компанией Microsoft для использования в СУБД Microsoft SQL Server.

Использование хранимых процедур дает несколько очевидных преимуществ:

— сценарии выполнения хранимых процедур кэшируются на сервере, что дает ощутимый прирост в скорости при повторном вызове процедур;

— дополнительный уровень абстракции – дает возможность изменить логику работы хранимой процедуры без необходимости вносить изменения в приложение (но при этом нельзя изменять сигнатуру хранимой процедуры);

— часть бизнес-логики приложения выполняется на сервере;

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

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

Рисунок 3.7 – Код сценария создания хранимой процедуры
Report_order_client

Рисунок 3.8 – Внешний вид отчета Форма принятия заказа

При проектировании блока взаимодействия с базой данных был использован подход, который заключается в следующем. Формируется класс MsSqlDataAdapter, который отвечает за соединение с БД и формирование набора данных. В функциональность класса закладываются такие возможности как формирование результирующей выборки по sql-запросу, а возможности, позволяющие выполнять запуск хранимых процедур на сервере на усмотрение разработчика.

На рисунке 3.9 представлен класс MsSQLDataAdapter.

Рисунок 3. 9 – Класс «MsSqlDataAdapter»

Функции CreateConnection() , OpenConnection(), CloseConnection() создают, открывают и закрывают соединение с сервером соответственно. Функции CreateCommand(), CreateParametrizedCommand() предназначены для создания параметризованных и обычных sql-команд. Для параметризованной команды необходимы параметры, которые создаются функциями CreateSqlParameter().

Рисунок 3 .10 – Класс «UserGateWay»

Класс UserGateWay содержит специализированные функции. Например, функция GetUser() определяет идентификатор пользователя по логину и паролю, используется для проверки данных о пользователе при попытке авторизации. Функция GetStatusModules() получает список модулей, к которым разрешен доступ для пользователя с определенным статусом. Функция GetUserName() возвращает данные пользователя по его идентификатору. Функция GetPasswordHash() возвращает хэшированную строку пароля.

2.3 Тестирование приложения

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

Тестирование – это проверка работы программ с данными, подобным реальным, которые будут обрабатываться в процессе эксплуатации системы. Процесс тестирования программного обеспечения осуществляется на основе фактических или смоделированных входных данных (как стандартных, так и не стандартных) при определённых контролируемых условиях.

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

Процесс тестирования представляет собой эксплуатацию приложения в контролируемых условиях и изучение полученных результатов [39]. При этом проверяется работа приложения с нормальными и ошибочными данными и событиями. Следует изучить и реакцию на неожиданные ситуации.

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

Для тестирования разрабатываемого проекта была выбрана методика тестирования «черного ящика». Эта методика применяется в качестве средства тестирования функционала разрабатываемого программного обеспечения.

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

При таком подходе система представляется неким черным ящиком, у которого имеется вход и выход. На входе мы имеем входные данные, на выходе – переработанные системой данные

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

Таблица 3.1 наращиваемый подход к тестированию

Ввести информацию о поставщиках

Внесенная информация о поставщиках

Внесенная информация о поставщиках

Внесение изменений в заказ

Заказ с изменениями

Заказ с изменениями

Составить план работ

Составленный план работ

Составленный план работ

Утвердить план работ

Утвержденный план работ

Утвержденный план работ

Составить акт о выполненной работе

Рисунок 3.11 – Ошибка приложения при составлении акта

Для наибольшего избегания ошибок в составлении запросов используются инструменты SQL Server. Первоначально запрос создается в SQL Server, там же тестируется (рисунок. 3.12).

Рисунок 3.12 Составление sql — запроса

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

2.4 Методика развертывания приложения

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

Цели этапа развертывания:

— перенести решение в промышленную среду;

— признание заказчиком факта завершения проекта.

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

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

Для развертывания разрабатываемой системы был составлен план действий, который приведен в таблице 3.2.

Таблица 3.2 – План развертывания приложения

1. Резервное копирование

Производится резервное копирование данных пользователя при его участии и согласовании путем переноса информации на сменные носители (СD, DVD)

2. Установка базовых компонентов решения

Применение технологий, обеспечивающих работу решения. В данном случае – установка компонента .NET Framework 2.0

3. Установка клиентского приложения

Перенос на компьютер пользователя и установка окончательного варианта разработанной ИС и базы данных

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

5. Передача базы знаний проекта клиенту

Заказчику передаётся вся проектная документация

6. Закрытие проекта

Составляется отчёт о закрытии проекта. Заказчик подписывает акт приёмки.

Для создания установочного файла setup.exe была использована программа CreateInstall.

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

Рисунок 3.13 – Рабочее пространство программы

Для нормального функционирования АРМ требуется операционная система Microsoft Windows XP, а также система управления базами данных MS SQL Server 2005. Платформа .NET Framework должна быть установлена до установки приложения. Для развертывания приложения необходимо, чтобы на жестком диске объем свободного места был не менее 20 Мб. Для установки приложения был создан файл setup, автоматически сгенерировавший инсталляционный пакет проекта. Для установки системы достаточно запустить файл setup.exe, и далее следовать инструкциям мастера установки.

Рисунок 3.14 – Окно мастера установки

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

Рисунок 3.15 — Окно мастера установки, запрашивающее путь для установки

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

Рисунок 3.16 – Процесс установки

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

Выводы к разделу

В третьем разделе дипломного проекта приведено описание разработки компонента и основных методов его тестирования и отладки.

В качестве базовой платформы для разработки приложения использована платформа .Net Framework 2.0, которая является управляемой средой для разработки и исполнения приложений.

Продемонстрирована реализация взаимодействия компонента с СУБД. Описана методика развертывания приложения средствами программы CreateInstall.

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

3.1 Выбор жизненного цикла разработки инф ормационной системы

Жизненный цикл информационной системы — период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из эксплуатации [13].

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

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

V-образная модель была предложена именно для того, чтобы устранить недостатки каскадной модели. Область применения V-образной модели – когда информация о требованиях достаточно полная. Модифицированная V-образная модель включает в себя итерационные циклы внесения изменений в требования. V-образная модель дала возможность значительно повысить качество ПО за счет своей ориентации на тестирование, а также во многом разрешила проблему соответствия созданного продукта выдвигаемым требованиям благодаря процедурам верификации и аттестации на ранних стадиях разработки [15].

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

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

Период итерации, как правило, 60 дней. Обязательным является применение CASE-технологий.

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

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

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

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

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

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

Таблица 4.1 – Результаты выбора приемлемой модели жизненного цикла разработки программного обеспечения.

LAV_ СИТспец_маг2014-15 / Модуль1_2013-14 / Web-приложения ASP_NET

Разработка Web-приложений ASP .NET с использованием Visual Studio .NET

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

Основы работы в Visial Studio .NET

Основы Web-программирования с использованием ASP.NET

Принципы разработки пользовательского интерфейса интернет-приложения

Использование Master Page и навигация при построении интернет-приложений

Навигация по Web-приложению

Использование тем при оформлении Web-приложения

Использование кэширования в Web-приложениях

Использование баз данных в приложениях ASP.NET

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

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

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

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

Рис. 1.1. Архитектура Web-приложения

Отображением результатов запросов, а также приемом данных от клиента и их передачей на сервер обычно занимается специальное приложение — браузер (Internet Expolrer, 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-приложениями, относятся:

прием данных от пользователя и сохранение их на сервере;

выполнение различных действий по запросу пользователя: извлечение данных из базы данных (БД), добавление, удаление, изменение данных в БД, проведение сложных вычислений;

аутентифицирование пользователя и отображение интерфейса системы, соответствующего данному пользователю;

отображение постоянно изменяющейся оперативной информации и т. д.

Краткое описание архитектуры ASP.NET и .NET Framework

ASP.NET — это платформа для создания Web-приложений и Web-сервисов, работающих под управлением IIS. Сегодня существуют другие технологии, позволяющие создавать Web-приложения. К ним относятся прежде всего, очень популярные сегодня языки PHP и PERL, более старая и менее популярная технология CGI и т. д. Однако ASP.NET отличается от них высокой степенью интеграции с серверными продуктами, а также с инструментами Microsoft для разработки доступа к данным и обеспечения безопасности. Кроме того, ASP.NET позволяет разрабатывать Web- и Windows-приложения, используя очень похожие технологические цепочки, одинаковые языки программирования, технологии доступа к данным и т. д. Более того, базовые языки программирования, с помощью которых сегодня возможна разработка Web-приложений, являются полностью объектно-ориентированными, что делает разработку исполнимой части, а также ее модификацию, обслуживание, отладку и повторное использование гораздо более простым занятием, чем в других технологиях. Существует достаточно большой перечень сильных сторон использования ASP.NET для создания сложных Web-приложений. Целью данного курса не является описание всех сильных и слабых сторон этой платформы.

Заметим лишь, что ASP.NET функционирует исключительно на серверах Windows, так как требует наличия IIS. Для создания Web-приложений, не требующих IIS, а использующих, например, Web-сервер Apache и работающих на серверах под управлением операционных систем, отличных от Windows, применяются другие технологии.

Важным моментом в понимании архитектуры ASP.NET является тот факт, что она является частью инфраструктуры .NET Framework. Более подробно об архитектуре и принципах работы .NET Framework можно узнать в [2]. Так как эта тема является слишком объемной и выходит за рамки данного курса, ограничимся лишь кратким описанием инфраструктуры .NET Framework.

Архитектура .NET Framework

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

набор языков, куда входят С# и Visual Basic .NET; набор инструментальных средств разработки, в том числе Visual Studio .NET; обширная библиотека классов для построения Web-служб и приложений, работающих в Windows и в Интернете; а также среда выполнения программ CLR (Common Language Runtime — общеязыковая среда выполнения), в которой выполняются объекты, построенные на этой платформе;

набор серверов .NET Enterprise Servers, ранее известных под именами SQL Server 2000, Exchange 2000, BizTalk 2000 и др., которые предоставляют специализированные функциональные возможности для обращения к реляционным базам данных, использования электронной почты, оказания коммерческих услуг «бизнес-бизнес» (В2В) и т. д.;

богатый выбор коммерческих Web-служб, называемых .Net My Services. За умеренную плату разработчики могут пользоваться этими службами при построении приложений, требующих идентификации личности пользователя и других данных;

новые некомпьютерные устройства, поддерживающие средства .NET, — от сотовых телефонов до игровых приставок.

Microsoft .NET поддерживает не только языковую независимость, но и языковую интеграцию. Это означает, что разработчик может наследовать от классов, обрабатывать исключения и использовать преимущества полиморфизма при одновременной работе с несколькими языками. Платформа .NET Framework предоставляет такую возможность с помощью спецификации CTS (Common Type System — общая система типов), которая полностью описывает все типы данных, поддерживаемые средой выполнения, определяет, как одни типы данных могут взаимодействовать с другими и как они будут представлены в формате метаданных .NET. Например, в .NET любая сущность является объектом какого-нибудь класса, производного от корневого класса System.Object. Спецификация CTS поддерживает такие общие понятия, как классы, делегаты (с поддержкой обратных вызовов), ссылочные и размерные типы.

Важно понимать, что не во всех языках программирования .NET обязательно должны поддерживаться все типы данных, которые определены в CTS. Спецификация CLS (Common Language Specification — общая языковая спецификация) устанавливает основные правила, определяющие законы, которым должны следовать все языки: ключевые слова, типы, примитивные типы, перегрузки методов и т. п. Спецификация CLS определяет минимальные требования, предъявляемые к языку платформы .NET. Компиляторы, удовлетворяющие этой спецификации, создают объекты, способные взаимодействовать друг с другом. Любой язык, соответствующий требованиям CLS, может использовать все возможности библиотеки FCL (Framework Class Library — библиотека классов платформы). CLS позволяет и разработчикам, и поставщикам, и производителям программного обеспечения не выходить за пределы общего набора правил для языков, компиляторов и типов данных.

Платформа .NET Framework является надстройкой над операционной системой, в качестве которой может выступать любая версия Windows 1) . На сегодняшний день платформа .NET Framework включает в себя:

четыре официальных языка: С#, VB.NET, Managed C++ (управляемый C++) и JScript .NET;

объектно-ориентированную среду CLR (Common Language Runtime), совместно используемую этими языками для создания приложений под Windows и для Internet;

ряд связанных между собой библиотек классов под общим именем FCL (Framework Class Library).

Отношения архитектурных компонентов платформы .NET Framework с концептуальной точки зрения представлены на рис.1.2.

Рис. 1.2. Архитектура .NET Framework

Самым важным компонентом платформы .NET Framework является CLR (Common Language Runtime), предоставляющая среду, в которой выполняются программы. Главная ее роль заключается в том, чтобы обнаруживать и загружать типы .NET и производить управление ими в соответствии с полученными командами. CLR включает в себя виртуальную машину, во многих отношениях аналогичную виртуальной машине Java. На верхнем уровне среда активизирует объекты, производит проверку безопасности, размещает объекты в памяти, выполняет их, а также запускает сборщик мусора.

Под сборкой мусора понимается освобождение памяти, занятой объектами, которые стали бесполезными и не используются в дальнейшей работе приложения. В ряде языков программирования (например, C/C++) память освобождает сам программист, в явной форме отдавая команды как на создание, так и на удаление объекта. В этом есть своя логика — «я тебя породил, я тебя и убью». Однако в CLR задача сборки мусора (и другие вопросы, связанные с использованием памяти) решается в нужное время и в нужном месте исполнительной средой, ответственной за выполнение вычислений.

На на рис.1.2. над уровнем CLR находится набор базовых классов платформы, над ним расположены слой классов данных и XML, а также слой классов для создания Web-служб (Web Services), Web- и Windows-приложений (Web Forms и Windows Forms). Собранные воедино, эти классы известны под общим именем FCL (Framework Class Library). Это одна из самых больших библиотек классов в истории программирования. Она открывает доступ к системным функциям, включая и те, что прежде были доступны только через API Windows, а также к прикладным функциям для Web-разработки (ASP.NET), доступа к данным (ADO.NET), обеспечения безопасности и удаленного управления. Имея в своем составе более 4000 классов, библиотека FCL способствует быстрой разработке настольных, клиент-серверных и других приложений и Web-служб.

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

Над этим уровнем находится уровень классов, которые расширяют базовые классы с целью обеспечения управления данными и XML. Классы данных позволяют реализовать управление информацией, хранящейся в серверных базах данных. В число этих классов входят классы SQL (Structured Query Language, язык структурированных запросов), дающие программисту возможность обращаться к долговременным хранилищам данных через стандартный интерфейс SQL. Кроме того, набор классов, называемый ADO.NET, позволяет оперировать постоянными данными. Платформа .NET Framework поддерживает также целый ряд классов, позволяющих манипулировать XML-данными и выполнять поиск и преобразования XML.

Базовые классы, классы данных и XML расширяются классами, предназначенными для построения приложений на основе трех различных технологий: Web Services (Web-службы), Web Forms (Web-формы) и Windows Forms (Windows-формы). Web-службы включают в себя ряд классов, поддерживающих разработку облегченных распределяемых компонентов, которые могут работать даже с брандмауэрами и программами трансляции сетевых адресов (NAT). Поскольку Web-службы применяют в качестве базовых протоколов связи стандартные протоколы HTTP и SOAP, эти компоненты поддерживают в киберпространстве подход «Plug & Play».

Инструментальные средства Web Forms и Windows Forms позволяют применять технику RAD (Rapid Application Development — быстрая разработка приложений) для построения Web- и Windows-приложений. Эта техника сводится к перетаскиванию элементов управления с панели инструментов на форму, двойному щелчку по элементу и написанию кода, который обрабатывает события, связанные с этим элементом.

Компиляция и язык MSIL

.NET-приложения исполняются иначе, чем традиционные Windows-приложения. Такие программы компилируются фактически в два этапа. На первом этапе исходный код компилируется во время построения проекта и вместо исполняемого файла с машинными кодами получается сборка 2) (assembly), содержащая команды промежуточного языка MSIL (Microsoft Intermediate Language — промежуточный язык Microsoft). Код IL сохраняется в файле на диске. При этом файлы MSIL (сокращенно IL), генерируемые компилятором, например, С#, идентичны IL-файлам, генерируемым компиляторами с других языков .NET. В этом смысле платформа остается в неведении относительно языка. Самой важной характеристикой среды CLR является то, что она общая; одна среда выполняет как программы, написанные на С#, так и программы на языке VB.NET.

Второй этап компиляции наступает непосредственно перед фактическим выполнением страницы. На этом этапе CLR транслирует промежуточный код IL в низкоуровневый собственный машинный код, выполняемый процессором. Процесс происходит следующим образом: при выполнении .NET-программы системы CLR активизирует JIT-компилятор, который затем превращает MSIL во внутренний код процессора. Этот этап известен как оперативная компиляция «точно к нужному моменту» (Just-In-Time) или JIT-компиляция (JIT’ing), и он проходит одинаково для всех приложений .NET (включая, например, приложения Windows). При исполнении программы CLR берет на себя управление памятью, контроль типов и решает за приложение ряд других задач. На рис.1.3. показан этот двухэтапный процесс компиляции.

Рис. 1.3. Схема компиляции .NET-приложения

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

Спецификация CLS подразумевает, что все языки платформы .NET генерируют очень похожий IL-код. Кроме того, при компилировании программы в дополнение к MSIL формируется еще один компонент — метаданные. Они описывают данные, используемые программой, и это позволяет коду взаимодействовать с другим кодом. В результате объекты, созданные на одном языке, доступны и могут наследоваться на другом. То есть можно создать базовый класс на языке VB.NET, а производный от него класс — на языке С#.

В целом при написании приложения создается так называемый управляемый код (managed code), который выполняется под контролем среды исполнения CLR-приложения, не зависящей от языка. Поскольку приложение запускается под контролем CLR, управляемый код должен соответствовать определенным требованиям (т. е. компилятор должен создать MSIL-файл, предназначенный для CLR, а также использовать библиотеки .Net Framework 3) ), при выполнении которых он получает множество преимуществ, включая современное управление памятью, способность совмещать языки, высокий уровень безопасности передачи данных, поддержку контроля версии и понятный способ взаимодействия компонентов программного обеспечения 4) .

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

Конечно, компиляция не будет столь полезна, если ее выполнение будет необходимо каждый раз при запросе пользователем Web-страницы. К счастью, приложения ASP.NET не нужно компилировать всякий раз при запросе Web-страницы или Web-службы. Вместо этого код IL создается один раз и повторно генерируется только при изменении исходного кода. Подобным образом файлы собственного машинного кода кэшируются в системном каталоге с путем вроде С:\[WinDir]\Microsoft.NET\ Framework\[Version]\Temporary ASP.NET Files, где WinDir является каталогом Windows, a Version — номером установленной в данный момент версии .NET.

Каждое Web-приложение, разрабатываемое на основе ASP.NET состоит из информационной части, программного кода и сведений о конфигурации.

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

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

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

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

На рис.1.4. представлен пример простейшей страницы Web-приложения, содержащего всего лишь один элемент — кнопку. Как видно из рисунка, основой страницы является тело стандартного HTML-документа, внутри которого находится элемент form, а также кнопка button. Кроме того, в начале документа здесь присутствуют некоторые дополнительные элементы, которые будут рассмотрены позднее.

Рис. 1.4. Пример простейшей страницы Web-приложения

При запуске приложения данная страница отображается в окне браузера и выглядит следующим образом (рис.1.5.).

Рис. 1.5. Отображение страницы Web-приложения в окне браузера

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

Рис. 1.6. Файл, содержащий программный код Web-страницы

На самом деле при разработке Web-приложений на основе ASP.NET возможны два варианта организации Web-форм.

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

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

В примере, рассмотренном ранее, Web-страница разделена на две части, при этом форма и программный код хранятся в разных файлах.

В следующем примере, изображенном на рис.1.7., показана аналогичная предыдущей Web-страница, в которой форма и программный код объединены в одном файле.

Рис. 1.7. Пример Web-формы, содержащей описание формы и программный код в одном файле

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

Рис. 1.8. Типовой сценарий взаимодействия элементов Web-приложения с клиентом

Как видно из рис.1.8, при обращении клиента к Web-приложению последнее запускается на сервере IIS. Запущенное приложение формирует отклик. Для этого на сервере создается экземпляр запрошенной Web-формы, она генерирует HTML-текст отклика, который и передается браузеру клиента. Сразу после этого экземпляр Web-формы уничтожается. Пользователь, получив HTML-страницу, сгенерированную приложением, имеет возможность заполнять различные поля формы (тестовые поля, переключатели и т. п.). После заполнения всех необходимых полей формы пользователь инициирует отправку данных, введенных им в страницу, обратно на сервер. Это происходит за счет использования технологии обратной отсылки, которая вызывается при выполнении определенных действий (например, нажатия на кнопку). Получив данные от пользователя, сервер создает новый экземпляр Web-формы, заполняет его полученными данными и обрабатывает все необходимые события. По окончании обработки сервер формирует HTML-код ответа и отправляет его клиенту, а затем уничтожает экземпляр Web-формы. Более подробно описанный сценарий изображен на рис. 1.9 и 1.10

Рис. 1.9. Подробный сценарий взаимодействия элементов Web-приложения с клиентом при первом запросе

Рис. 1.10. Подробный сценарий взаимодействия элементов Web-приложения с клиентом при запросе обратной отсылки

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

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

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

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

После этого инициируется событие Page_Load. Большинство Web-страниц используют это событие для выполнения инициализации, например, заполнения полей данными, установки начальных значений для элементов управления и т. д. Кроме того, в процедуре обработки данного события возможно определение того, была ли загружена страница впервые или обращение к ней осуществляется повторно в рамках технологии обратной отсылки, произошедшей в результате нажатия пользователем кнопки либо другого элемента управления, размещенного на странице. В английской терминологии обратная отсылка данных на сервер называется post back. Для определения текущего состояния страницы необходимо проверить свойство Page.IsPostBack, которое будет иметь значение false при первом запуске страницы. Определение того, производится ли первое обращение к данной странице либо повторное, важно, так как позволяет производить инициализацию только в том случае, когда страница запрашивается впервые. Так, например, при обратной отсылке данных на сервер не только нет необходимости производить инициализацию, устанавливая начальные значения элементов управления, но это даже может быть ошибкой, так как эти элементы управления должны получить значения, переданные им от пользователя. В дальнейшем, в случае, если для страницы была произведена обратная отсылка, вызываются события элементов управления, размещенных на странице. Эти события запоминаются в тот момент, когда пользователь производил действия с элементами управления в окне браузера, а при передаче данных на сервер исполняются по порядку.

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

Следующим шагом обработки Web-формы является обработка всех событий, инициированных пользователем с момента последней обратной отсылки. Для иллюстрации этого приведем пример.

Пусть у нас существует страница с кнопкой (Button) «Отправить» и текстовым полем (TextBox) без автоматической обратной отсылки. При изменении текста в текстовом поле и щелчке на кнопке «Отправить» инициируется обратная отправка данных страницы на сервер (этого не произошло при изменении текста в текстовом поле, так как соответствующая опция этого элемента управления AutoPostBack установлена в false). В момент обратной отправки страницы на сервер ASP.NET запускает следующие события:

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

Описанная последовательность событий позволяет создать описание жизненного цикла Web-страницы, изображенного на рис 1.11.

Рис. 1.11. Жизненный цикл страницы ASP.NET

Вернемся, однако, к проблеме сохранения данных страницы в промежутке между обращениями к ней. Для реализации этого механизма в ASP.NET используются состояния отображения (view state). Состояние отображения Web-формы доступно только внутри этой Web-формы. Если необходимо сделать данные, введенные в Web-форму, доступными другим Web-формам одного и того же приложения, эти данные необходимо сохранить в объектах с более глобальной областью видимости, которые называют переменными состояния. Объектов переменных состояний два: Application и Session. Переменные состояния Application доступны всем пользователям приложения и могут рассматриваться как глобальные переменные, обращение к которым возможно из любых сеансов. Переменные состояния Session доступны только в рамках одного сеанса, и поэтому они оказываются доступными только одному пользователю. В переменных состояния можно хранить данные любого типа. В силу того, что переменные состояния фактически являются глобальными переменными, для работы с ними желательно выработать стратегию их использования в приложении.

Более подробно работа с состояниями отображения и переменными состояния будет рассмотрена в разделе «Класс Page» в лекции 2.

Web-приложения представляют собой особый тип программ, основанных на архитектуре «клиент-сервер». Web-приложение располагается и исполняется на сервере, получая от клиента исходные данные для работы, а также передавая ему результаты работы в виде HTML-кода, отображаемого в браузере.

Существует несколько технологий разработки информационных систем, ориентированных на Интернет. Одной из наиболее мощных технологий является ASP.NET. Web-приложения, разработанные на основе ASP.NET работают исключительно в среде IIS платформы Windows. ASP.NET является частью инфраструктуры .NET Framework. Данная архитектура является основой для построения современных приложений, ориентированных на работу в среде Windows, и может использовать любой из совместимых языков программирования для написания программного кода. Особенностью .NET Framework является то, что различные модули одной и той же программной системы могут быть написаны на различных языках программирования. Одним из важнейших элементов данной архитектуры является наличие сборщика мусора, осуществляющего очистку неиспользуемых областей памяти и избавляющего программиста от проблемы «утечки памяти».

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

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

1) Благодаря архитектуре среды CLR в качестве операционной системы может выступать любая версия Unix и вообще любая ОС. 2) Сборка (assembly) – это коллекция файлов, которая предстает перед программистом в виде единой библиотеки динамической компоновки (DLL) или исполняемого файла (EXE). В технологии .NET сборка является базовой единицей для повторного использования, контроля версий, защиты и развертывания. Среда CLR представляет программисту ряд классов, позволяющих манипулировать сборками. 3) Библиотека классов .NET открывает доступ ко всем возможностям CLR. Классы, составляющие эту библиотеку, организованы при помощи пространств имен. Каждое пространство имен заключает в себе классы, выполняющие близкие функции. 4) Альтернативой управляемому коду является неуправляемый код, который не выполняется CLR. Однако до появления .NET Framework все Windows-программы использовали именно неуправляемый код.

Разработка на ASP.NET. MasterPage, динамические компоненты, AJAX, ASP.NET MVC

7.7. ASP.NET MVC

7.7.1. Общие сведения

В.NET Framework 3.5 появилась новая технология – ASP.NET MVC . Ее отличие от обычного ASP.NET заключается в том, что за основу взят не шаблон проектирования PageController , когда создается множество страниц (часто для любого действия создается своя страница), а FrontController , когда создается небольшое количество классов, способных обрабатывать запросы и генерировать разметку страницы (или при использовании AJAX части страницы) исходя из переданных данных [16, 17, 18].

ASP.NET MVC является реализаций шаблона Model-View-Controller под платформу .NET. Рассмотрим основные принципы его работы.

Архитектурный шаблон Model-View-Controller подразумевает под собой разделение приложения на три основных компонента: Model , View и Controller . Каждый из этих компонентов отвечает за свои задачи:

• Model – это бизнес-логика разрабатываемого приложения. В ней находятся классы, которые отвечают за данные, манипуляцию данными, а так же за взаимодействие между самими сущностями. Если приложение небольшое, то работа с данными проводится обычно здесь. Если же проект достаточно крупный, содержит много логики, то работа с данными и бизнес-логика разносятся по отдельным проектам.
• View отвечает за взаимодействие с пользователем (UI). Посредством этого компонента будут выводиться данные клиенту, реализовываться интерфейс для их редактирования и т.п.
• Controller – это связующее звено между первыми двумя компонентами. Controller получает данные о запросе к серверу, обрабатывает эти данные (например, получает значения из отправленной формы) и передает их в Model . После обработки или получения данных он выбирает, каким же именно способом отобразить данные клиенту (нужный View ).

В результате получается полный контроль над выводимым HTML и более «легкие» приложения. Также значительно упрощается тестирование приложений, так как теперь можно легко писать Unit Test ‘ы для модели и контроллера.

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

Также стоит отметить, что в таком подходе отсутствует ViewState , так как больше нет необходимости хранить состояния страниц, чтобы их повторно воссоздавать на сервере. Нет обработчиков событий, нет ViewState , нет Drag’n’Drop контролов на форму.

Еще одна полезная особенность – нет необходимости реализовывать URL-Rewriting (использования «дружественных» и удобных ссылок, так как, например, на сайте lenta.ru: http://lenta.ru/news/2010/03/07/vision/). Для ASP.NET MVC такой подход является стандартным – весь путь определяет контроллер, который необходимо использовать на сервере (при этом последний уровень определят имя контроллера, а остальные – его месторасположение), а параметры передаются через HTTP POST.

MVC делит пользовательский интерфейс на три разных объекта: контроллер получает входные данные и обрабатывает их, модель содержит логику домена, представление оформляет полученный результат [19]. В контексте Веб-приложений входные данные – это HTTP-запрос. Ход обработки запросов показан на рис. 7.17.

В ASP.NET этот процесс выглядит иначе. Там входные данные отправляются на страницу (в представление). Представление отвечает и за обработку входных данных, и за отображение результата. В MVC эти обязанности разделяются.

Продемонстрируем особенности ASP.NET MVC на небольшом примере.

7.7.2. «Hello World» на ASP.NET MVC

Создадим новый проект ASP.NET MVC . Для этого понадобится установить для Visual Studio 2008 дополнение:

В папке Controllers располагается ряд контроллеров. Если кликнуть правой клавишей мыши по этой папке, то в контекстном меню можно будет выбрать пункт Add New Item -> Controller. Добавим новый контроллер HelloController . Сразу после добавления будет сгененрирован примерно следующий код:

Метод Index определяет действие контроллера (действия отмечаются как методы, возвращающие объект ActionResult ). В данном случае это метод, который вызывается по умолчанию, когда пользователь обращается по адресу /Hello . В этом случае будет отображен вид по умолчанию. Добавим еще одно действие в контроллер:

Чтобы обратиться к этому действию, пользователь должен уже будет набрать /Hello/HiThere в адресной строке браузера. Это действие помещает переданные ему данные в коллекцию ViewData , которая будет доступна на странице View .

Теперь необходимо создать отображение для этого действия. Самый простой способ это сделать – нажать правой клавишей мыши по действию и в контекстном окне выбрать Add View (рис. 7.19).

Доработаем созданное представление следующим образом, чтобы оно выдавало приветствие пользователю:

Теперь, если пользователь с именем Alex обратится по адресу: /Hello/HiThere/Alex он увидит страницу приветствия, показанную на рис. 7.20.

7.8. Ключевые термины

ASP.NET , Мастер страницы , GridView , DataList , Пользовательский серверный компонент , AJAX , ASP.NET MVC .

7.9. Краткие итоги

Мастер страницы ASP.NET (master pages) реализуют простую модель создания шаблонов форм с возможностью их повторного использования.

ASP.NET имеет возможность динамического создания и отображения на странице элементов управления.

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

Элемент Menu предназначен для вывода элементов структуры приложения на экран.

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

Элемент управления GridView можно использовать для выполнения следующих задач:

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

Серверный веб-элемент управления DataList отображает данные базы данных в настраиваемом формате.

Для разработки и повторного использования собственных компонент используются файлы с расширением ascx .

Технология AJAX в ASP.NET включает библиотеку функций клиентских сценариев, привнося многие из преимуществ объектно-ориентированного программирования и модели ASP.NET в клиентские сценарии.

Архитектура AJAX в ASP.NET состоит из двух частей: библиотек клиентских сценариев и серверных компонентов.

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

Технология активных серверных страниц ASP

ASP (англ. Active Server Pages — «активные серверные страницы») — технология, предложенная компанией Microsoft для создания Web-приложений в 1996 году вместо провалившегося проекта Dynamic HTML, в котором была сделана попытка «динамизировать» web-страницы за счет модернизации HTML, внедрением в него «динамических тэгов», то есть тэгов, имеющих алгоритмические свойства наподобие объектов в ООП. Но появление JavaScript от корпорации Netscape сделало это бессмысленным.

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

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

Для реализации приложений ASP используются языки сценариев (VBScript или JScript). Также допускается применение COM-компонентов.

Технология ASP разработана для операционных систем из семейства Windows NT/Server и функционирует под управлением веб-сервера Microsoft IIS.

Технология ASP получила своё развитие в виде ASP.NET — технологии создания веб-приложений, основанной уже на платформе Microsoft .NET.

Синтаксис

Страница на ASP — это обычная страница HTML, со вставками, обозначенными ограничителями :

То что находится внутри ограничителей — это текст программы, интерпретируемый при запросе страницы. VBScript является языком по умолчанию, хотя возможно использование и JScript[источник не указан 1108 дней] (или любого другого языка, если установлен соответствующий интерпретатор):

Версии

ASP в своём развитии прошёл через несколько версий:

• ASP 1.0 (распространяется с IIS 3.0) в декабре 1996 года.
• ASP 2.0 (распространяется с IIS 4.0) в сентябре 1997 года.
• ASP 3.0 (распространяется с IIS 5.0) в ноябре 2000 года.

Apache::ASP

Apache::ASP (англ.) предоставляет функциональность ASP на основе веб-сервера Apache, со скриптами на основе Perl.

ASP в Sambar Server

На сервере Sambar Server используется функциональность ASP, которая использует язык CScript в качестве основного языка программных вставок.

Обзор технологии Active Server Pages (ASP)

Сергей Верязов, Microsoft Special Interest Group «Neva»

Active Server Pages это среда программирования, которая обеспечивает возможность комбинирования HTML, скриптов и компонент для создания динамических Web-приложений. Возможность встраивания в Web-страницы скриптов (кода, написанного на языке программирования, например, VBScript или JScript) позволяет логичным образом объединить оформление с данными, полученными из различных источников, например, из БД.

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

Принципы функционирования

Использование Active Server Pages как бы не требует специфичных браузеров, но требует включения небезопасного ActiveX. Все ASP-скрипты запускаются и выполняются на Web-сервере, причем брaузер получает только результирующие HTML-файлы. Microsoft Internet Information Server, начиная с версии 3.0, поддерживает Active Server Pages.
Рассмотрим последовательность функционирования ASP. Клиент запрашивает ASP-страницу на Web-сервере. Сервер принимает запрос и начинает его обрабатывать. По расширению файла (.asp) определяет, что данный файл содержит ASP-скрипт, и начинает анализировать его содержимое, последовательно интерпретируя и выполняя вставки ASP-кода. ASP-код, в свою очередь, может содержать обращения к различным источникам данных, осуществлять обработку полученных данных и добавлять содержимое генерируемой страницы. В результате формируется обычная HTML-страница (уже не содержащая ASP-кода), которая и отправляется обратно клиенту.

Внешне ASP функционирует также, как CGI. Аналогичным образом передаются параметры (формат-строки запроса) и осуществляется вывод результатов. Однако производительность ASP оказывается гораздо выше, т. к. при каждом запросе не происходит отдельной загрузки ASP-интерпретатора. Использование компонент ActiveX также значительно повышает производительность Web-сервера.

Описание синтаксиса

ASP-код, который нужно выполнить на сервере, размещается внутри специальных тегов . Так как данный код обрабатывается на сервере, он не доступен пользователю. Сам код может быть написан с использованием Visual Basic Scripting Edition (VBScript) или JScript (JavaScript). Технология ASP позволяет использовать и другие языки программирования. По сути, нужно говорить не о синтаксисе ASP, а о том языке, который используется для написания ASP-кода. Синтаксис VBScript намного проще других языков, поэтому новичку будет легко в нем разобраться.

Объекты и компоненты

VBScript не является полнофункциональным языком программирования и использования встроенных в него средств явно недостаточно. Поэтому в ASP-страницах используются специальные объекты и компоненты ActiveX.

Существует набор встроенных объектов, которые инициализируются и предоставляются ASP-скрипту автоматически при начале обработки. Эти объекты обеспечивают доступ к основным жизненно важным функциям:

• Объект Application позволяет создавать переменные, доступные всем пользователям Web-приложения.
• Объект Session позволяет сохранять данные, связанные с отдельным пользователем.
• Объект Request предоставляет параметры CGI-запроса, отправленные методом POST 99или GET.
• Объект Response предоставляет методы для добавления информации, а также для формирования заголовков страницы ответа Web-сервера.
• Объект Server содержит множество различных методов, одним из которых является метод CreateObject, позволяющий создавать экземпляры компонент ActiveX.

В отличие от встроенных ASP-объектов, ASP-компоненты явно необходимо создавать в коде скрипта. Существует огромное количество ActiveX-компонент, которые можно использовать в ASP-страницах, причем большинство из них распространяются бесплатно. Более того, разработчик может сам создавать ActiveX-компоненты в любой среде программирования, поддерживающей COM-технологию, например, Visual C++ или Visual Basic.

Следует уделить особое внимание объектам ADO (ActiveX Data Objects), которые представляют собой мощные интегрированные средства для создания приложений для работы с БД. Компоненты ADO обеспечивают быстрый и удобный интерфейс к БД на самом высоком уровне, при этом сохраняется переносимость разрабатываемых приложений для работы с другими БД. Использование компонент ADO значительно упрощает работу программиста, ему остается лишь правильно составить SQL-запросы к БД и позаботиться о выводе результатов.

В рамках функционирования Web-приложения существует возможность создания обработчиков основных событий, таких как запуск и остановка Web-приложения, а также открытие и закрытие пользовательской сессии. Эти события описываются в специальном ASP-файле global.asa. Обработчики данных событий можно использовать для инициализации объектов или установки значений глобальных переменных.

Средства разработки

Создавать ASP-страницы можно в любом текстовом редакторе, но это далеко не всегда удобно. Помимо написания кода на VBScript, необходимо осуществлять его отладку, что возможно только на функционирующем Web-сервере (IIS) и при наличии специальных средств.

Microsoft Visual InterDev 6.0 (входящий в состав Microsoft Visual Studio) является одним из лучших средств, которое позволяет не только быстро и эффективно создавать ASP-код, но и осуществлять расширенную отладку кода. Основные особенности этого продукта:

• Просмотр списка используемых объектов, и возможность быстрого написания кода.
• Подсветка синтаксиса кода (VBScript и JScript).
• Автоматическое формирование содержимого global.asa.
• При запуске в режиме отладки InterDev автоматически настраивает Web-сервер (IIS) в нужный режим, а по окончании отладки восстанавливает настройки.
• Возможность установки точек прерывания (breakpoints).
• Просмотр значений переменных (watches) и списка вызванных процедур (call stack).

Существуют также и другие специализированные редакторы, позволяющие разрабатывать ASP-приложения, например, Home Site 4.5, Macromedia UltraDev 4.0 или ASP Express. Однако эти средства не полностью охватывают возможности Visual InterDev.

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

Последняя версия Web-сервера Internet Information Server (IIS) 5.0 значительно усовершенствована, благодаря чему повышена надежность и производительность ASP-приложений. Встроенные объекты ASP в Windows 2000 обладают новыми методами, которые расширяют возможности разработчика.
Появились новые средства обработки ошибок. С помощью нового объекта AppError теперь можно получать сведения об ошибках, происходящих как на стадии выполнения, так и на стадии разбора страницы.

В новой версии ядра управления сценариями Script Engine из состава Windows 2000 появились новые мощные средства поддержки языков VBScript и JScript. В сценариях на VBScript теперь можно пользоваться средствами проверки и разбора сложных выражений, а также создавать классы.
Средства доступа к данным также претерпели значительные изменения теперь в составе ОС поставляется ядро MDAC 2.5, которое, в частности, обеспечивает интеграцию со средствами XML.

Поддержка других языков программирования

Наравне с Visual Basic Scripting Edition (VBScript), IIS поддерживает обработку JScript (JavaScript). Вы можете использовать все те же объекты, при этом меняется только синтаксис связующих конструкций.
Преимущество технологии ASP в том, что она позволяет использовать и другие языки программирования. Для их поддержки необходимо установить соответствующие модули Script Engine. Например, поддержку языка Perl (а точнее ActivePerl) можно осуществить с помощью модуля от компании ActiveState (http://www.activestate.com/). Также существуют модули для поддержки REXX и Python.
Существуют продукты сторонних компаний, поддерживающие технологию ASP на других платформах. Например, Chili!Soft ASP, компании Chili!Soft, Inc., (http://www.chilisoft.com/) обеспечивает поддержку ASP на множестве Web-серверов, таких как: Apache, Lotus, Netscape, OReilly, которые могут функционировать под управлением различных ОС.

Достоинства и недостатки

Язык VBScript, обычно используемый в ASP, имеет менее удобный синтаксис, чем другие языки, например язык PHP. Однако основной недостаток VBScript — неприемлемо снижающаяся безопасность клиента, а в связке с ActiveX — практически нулевая. Не является компенсацией этого и то, что производительность интерпретатора VBScript значительно выше, чем PHP.

JScript от Microsoft лишен этого недостатка, но имеет другой, более серьёзный — неприятную обработку типов данных OLE Automation, что приводит к скрытым, трудным в обнаружении ошибкам.

ASP может использовать очень довольно набор классов для работы с SQL базами данных — ADO, который примерно аналогичен Perl DBI и лучше, чем вызовы mysql_xxx в PHP. Однако технология ADO тоже устарела.

ASP поддерживает объекты Session и Application, с которыми в PHP/Apache традиционно есть огромные сложности, связанные с архитектурой процессов Apache 1.x (а она восходит к нелюбви к потокам в мире UNIX и использованию fork() вместо них везде, где возможно).

Однако, так как объект Session ныне считается совершенно не удовлетворяющим требованиям безопасности, и зачастую вместо него все его содержимое помещают в один огромный cookie, и передают туда-обратно между клиентом и сервером. Такое легко реализуемо в PHP, этим пользуются, например, phpBB и его коммерческий дериватив vBulletin.

Замена ASP

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

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

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

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

Вам также может быть интересно

Обучение программированию

Эффективный копирайтинг, как писать копирайтинг

Как написать эффективный продающий текст. Часть первая. Подготовка Грамотно написанный продающий текст позволяет превращать

Обучение программированию

Язык xml просмотр xml документов

Чем открыть XML Web — это место, где миллионы людей ежедневно связываются друг с

Обучение программированию

Эффективный способ применения интерфейсов в mdi приложениях

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

Обучение программированию

Язык xml стилевые таблицы xsl

Отображение XML с использованием XSLT При помощи XSLT вы можете преобразовывать XML документ в

Обучение программированию

Эффекты с изображениями

Как сделать — визуальные эффекты изображениям Узнайте, как добавить визуальные эффекты к изображениям. Фильтры

Обучение программированию

Язык xml схемы данных

Понимание XML Узнайте, как Расширяемый язык разметки (Extensible Markup Language — XML) облегчает универсальный

Обучение программированию

Юмор пиво для программиста

ХАЙФХАК: ПРОГРАММИСТ ВЗЛОМАЛ СИСТЕМУ, ЧТОБЫ ПОПИТЬ ПИВО БЕСПЛАТНО / пиво :: geek новости ::

Обучение программированию

Язык обработки данных awk

Примеры команды AWK в Linux Введение AWK назван в честь фамилии его авторов: Альфред

Обучение программированию

Я загружаю timagelist динамически как сделать картинки из timagelist прозрачными

Я загружаю timagelist динамически как сделать картинки из timagelist прозрачными? Элемент управления ImageList содержит

Обучение программированию

Язык преобразований xsl (xslt)

Введение в XSLT XSLT представляет собой способ для XML-документов в другие XML или документы

Обучение программированию

Является ли указанная страница — домашней (IE)

Является ли указанная страница — домашней? (IE) При создании новой вкладки (about:Tabs) в IE9

Обучение программированию

Язык преобразований XSLT

Справочник по интерфейсу администратора Ссылки Назад «> Вверх Вперед Опубликованные SQL View > XSLT

Обучение программированию

Ядро и процессы

Что такое ядро в биологии? Строение и функции ядра В каждой живой клетке протекает

Обучение программированию

Язык программирования alfa

Язык программирования alfa По питанию контроллеры делятся на два типа: с питанием 220 В

Обучение программированию

Язык cc

C++ — Базовый синтаксис Когда мы рассматриваем программу на C ++, ее можно определить

Обучение программированию

Язык рефал

Язык рефал Ура! Сегодня, 30.05.2005, наконец появилась адаптированная к современным платформам Windows-(95/98/ME/NT/2000/XP) и UNIX

Обучение программированию

Эффект pазвивающегося флага

Scrontch’s Flag Designer Design Your Flag! Generates Scalable Vector Graphics (SVG). This App requires

Обучение программированию

Язык sql

SQL-Урок 1. Язык SQL. Основные понятия. Для того, чтобы начать изучать SQL нам нужно

Обучение программированию

Язык с

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

Обучение программированию

Эффект горящей надписи

Простой огненный текст в Фотошопе Конечный результат: Ресурсы урока: Шаг 1 Создайте новый документ

Обучение программированию

Язык xml documents type definitions (dtd)

Язык XML — практическое введение . Documents Type Definitions (DTD) В XML- документах DTD

Обучение программированию

Языки и грамматики простейший компилятор

ГРАММАТИКА ЯЗЫКОВ ПРОГРАММИРОВАНИЯ Описанию грамматики языка предшествует описание его алфавита. Алфавит любого языка состоит

Обучение программированию

Эффект ледяной надписи

Ледяной текст в Фотошопе Конечный результат: Ресурсы урока: 1. Создание фона Шаг 1 Создайте

Обучение программированию

Язык xml dom совместимые анализаторы

XML-анализаторы в java XML как набор байт в памяти, запись в базе или текстовый