2653

Программирование в сетях

Конспект

Информатика, кибернетика и программирование

Программирование в сетях (курс лекций) Архитектуры информационных приложений. Общая классификация архитектур информационных приложений. Основные технологии построения современных распределенных систем. Технология построения систем...

Русский

2012-11-12

1007.68 KB

68 чел.

Программирование в сетях (курс лекций)

1. Введение. Архитектуры информационных приложений 3

1.1. Общая классификация архитектур информационных приложений 3

1.2. Основные технологии построения современных распределенных систем 18

1.3. Технология CORBA OMG 18

1.4. Технология J2EE Sun 21

1.5. Технология .NET 25

1.6. Сравнение CORBA, J2EE и .NET 28

2. Сетевое программирование и сетевые приложения 32

2.1. Обмен данными по сети 32

2.2. Обработка данных в системах клиент/сервер 32

2.3. Принципы обмена данными 32

2.4. Пример интерфейса прикладного программирования 33

2.5. Неформальное описание АРI-интерфейса 33

2.6. Определение АРI-интерфейса 34

2.7. Код приложения эхо-повтора 36

3. Взаимодействие типа «клиент-сервер» 41

3.1. Логическая трехзвенная модель Web-приложений 41

3.2. Различная физическая реализация логической модели 41

4. Интерфейс сокетов 45

4.1. Интерфейс прикладного программирования 45

4.2. АРI-интерфейс сокетов 45

4.3. Сокеты и библиотеки сокетов 46

4.4. Связь через сокеты и ввод/вывод в системе UNIX 46

4.5. Сокеты, дескрипторы и сетевой ввод/вывод 47

4.6. Параметры и АРI-интерфейс сокетов 47

5. Архитектура WWW 55

5.1. Общие сведения о протоколе HTTP 55

5.2. Формат HTTP-сообщения. 55

5.3. Клиентский запрос Client Request 57

5.4. Ответ сервера Server Response 59

6. Принципы гипертекстовой разметки. Структура документов HTML 61

6.1. Введение 61

6.2. Принципы гипертекстовой разметки. Структура документов 63

6.3. Использование таблиц в дизайне страницы 95

6.4. Фреймы 97

6.5. Формы 104

6.6. DHTML 106

7. Управление просмотром страниц Web-узла. JavaScript 118

7.1. Модель объектов JavaScript - объекты Navigator'а 118

7.2. Наследование кода скриптов различными страницами 124

7.3. Java, JavaScript и Plug-ins 125

7.4. Встраивание в HTML-документ 125

7.5. Примеры скриптов 127

8. Common Gateway Interface - средство расширения возможностей технологии World Wide Web 135

8.1. Механизмы обмена данными 135

8.2. Практика применения скриптов CGI 138

9. Технология ASP 140

9.1. Общее описание 140

9.2. Вывод 140

9.3. Ввод 140

9.4. Взаимосвязь между отдельными страницами 141

9.5. Управление приложением 142

9.6. Использование внешних компонент 142

9.7. Работа с базами данных 142

9.8. Методики программирования 143

10. Технология JSP 147

10.1. Обзор технологии 147

10.2. Преимущества сервлетов по сравнению с «традиционными» CGI 148

10.3. Страницы Java Server Pages 149

10.4. Преимущества JSP 150

11. Технология PHP 152

11.1. Введение в PHP 152

11.2. Возможности PHP3 152

12. Технология XML 156

12.1. Что такое XML-документ 156

12.2. Правила создания XML- документа 157

12.2. Просмотр XML - документов 160

12.3. Стилевые таблицы XSL 166

12.4. Documents Type Definitions (DTD) 177

12.5. Схемы данных 182

13. Технология ColdFusion 190

13.1. Введение 190

13.2. Возможности ColdFusion Server 191

13.3. ColdFusion Администратор 192

13.4. Возможности ColdFusion Studio 192

14. Web-сервисы 194

14.1. Общая характеристика технологии 194

14.2. Service-Oriented Architecture (SOA, сервисно-ориентированная архитектура) 196

14.3. Стек технологий веб-сервисов 200

14.4. Принципы взаимодействия веб-сервисов в рамках сервисно-ориентированной архитектуры 203

Приложение 1 206

Приложение 2 208

Приложение 3 210

Приложение 4 214

  1.  
    Введение. Архитектуры информационных приложений

1.1. Общая классификация архитектур информационных приложений

В данном разделе приводится классификация возможных архитектур информационных систем. Мы начинаем с традиционных архитектурных решений, основанных на использовании выделенных файл-серверов или серверов баз данных. Затем рассматриваются варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы основывается на концепции "склада данных" (DataWarehouse) - интегрированной информационной среды, включающей разнородные информационные ресурсы. Наконец, последняя выделяемая нами архитектура предназначена для построения глобальных распределенных информационных приложений с интеграцией информационно-вычислительных компонентов на основе объектно-ориентированного подхода.

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

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

1.2. Файл-серверные приложения

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

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

Конечно, основным достоинством является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде MS-DOS, Windows или какого-либо облегченного варианта Windows NT. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД. Но во многом эта простота является кажущейся. (Как гласит русская пословица, "Простота хуже воровства", а здесь мы, как правило, имеем простоту на основе воровства программных продуктов для PC.)

Рис. 1.1. Классическое представление информационной системы в архитектуре "файл-сервер"

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

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

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

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

Длинноезамечание: Для сохранения четкости дальнейшего изложения нам необходимо несколько уточнить терминологию. Мы недаром написали "сервер баз данных" в кавычках применительно к СУБД Informix SE. При использовании этой системы копия программного обеспечения СУБД поддерживалась для каждого инициированного пользователем сеанса работы с СУБД. Грубо говоря, для каждого пользовательского процесса, взаимодействующего с базой данных создавался служебный процесс СУБД, который выполнялся на том же процессоре, что и пользовательский процесс (т.е. на стороне клиента). Каждый из этих служебных процессов вел себя фактически так, как если бы был единственным представителем СУБД. Вся синхронизация возможной параллельной работы с базой данных производилась на уровне файлов внешней памяти, содержащих базу данных. Условимся впредь называть такие СУБД не серверами баз данных, а системами управления базами данных, основанными на файл-серверной архитектуре (СУБД-ФС).

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

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

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

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

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

Рис. 1.2. "Толстый" клиент и "тонкий" сервер в файл-серверной архитектуре

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

1.2. Клиент-серверные приложения

Под клиент-серверным приложением мы будем понимать информационную систему, основанную на использовании серверов баз данных (см. длинное замечание в конце раздела 1.1). Общее представление информационной системы в архитектуре "клиент-сервер" показано на рисунке 1.3.

  1.  На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты, выполняющие другие специфичные для приложения функции (пока нас не будет занимать, как строится код приложения).
  2.  Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения.

(Здесь опять проявляются недостатки в терминологии. Обычно, когда компания объявляет о выпуске очередного сервера баз данных, то неявно понимается, что имеется и клиентская составляющая этого продукта. Сочетание "клиентская часть сервера баз данных" кажется несколько странным, но нам придется пользоваться именно этим термином.)

Рис. 1.3. Общее представление информационной системы в архитектуре "клиент-сервер"

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

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

Здесь необходимо сделать еще два замечания.

  1.  Обычно компании, производящие развитые серверы баз данных, стремятся к тому, чтобы обеспечить возможность использования своих продуктов не только в стандартных на сегодняшний день TCP/IP-ориентированных сетях, но в сетях, основанных на других протоколах (например, SNA или IPX/SPX). Поэтому при организации сетевых взаимодействий между клиентской и серверной частями СУБД часто используются не стандартные средства высокого уровня (например, механизмы программных гнезд или вызовов удаленных процедур), а собственные функционально подобные средства, менее зависящие от особенностей сетевых транспортных протоколов.
  2.  Когда мы говорим об интерфейсе на основе языка SQL, нужно отдавать себе отчет в том, что несмотря на титанические усилия по стандартизации этого языка, нет такой реализации, в которой стандартные средства языка не были бы расширены. Необдуманное использование расширений языка приводит к полной зависимости приложения от конкретного производителя сервера баз данных.

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

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

  1.  Сервер производит компиляцию полученного оператора. Не будем здесь останавливаться на том, какой целевой язык используется конкретным компилятором; в разных реализациях применяются различные подходы (примеры см. в части 4). Главное, что в любом случае на основе информации, содержащейся в таблицах-каталогах базы данных производится преобразование непроцедурного представления оператора в некоторую процедуру его выполнения.
  2.  Далее (если компиляция завершилась успешно) происходит выполнение оператора. Мы снова не будем обсуждать технические детали, поскольку они различаются в реализациях. Рассмотрим возможные действия операторов SQL.
  3.  Оператор может относиться к классу операторов определения (или создания) объектов базы данных (точнее и правильнее было бы говорить про элементы схемы базы данных или про объекты метабазы данных). В частности, могут определяться домены, таблицы, ограничения целостности, триггеры, привилегии пользователей, хранимые процедуры. В любом случае, при выполнении оператора создания элемента схемы базы данных соответствующая информация помещается в таблицы-каталоги базы данных (в таблицы метабазы данных). Ограничения целостности обычно сохраняются в метабазе данных прямо в текстовом представлении. Для действий, определенных в триггерах, и хранимых процедур вырабатывается и сохраняется в таблицах-каталогах процедурный выполняемый код. Заметим, что ограничения целостности, триггеры и хранимые процедуры являются, в некотором смысле, представителями приложения в поддерживаемой сервером базе данных; они составляют основу серверной части приложения (см. ниже).
  4.  При выполнении операторов выборки данных на основе содержимого затрагиваемых запросом таблиц и, возможно, с использованием поддерживаемых в базе данных индексов формируется результирующий набор данных (мы намеренно не используем здесь термин "результирующая таблица", поскольку в зависимости от конкретного вида оператора результат может быть упорядоченным, а таблицы, т.е. отношения неупорядочены по определению). Серверная часть СУБД пересылает результат клиентской части, и окончательная обработка производится уже в клиентской части приложения.
  5.  При выполнении операторов модификации содержимого базы данных (INSERT, UPDATE, DELETE) проверяется, что не будут нарушены определенные к этому моменту ограничения целостности (те, которые относятся к классу немедленно проверяемых), после чего выполняется соответствующее действие (сопровождаемое модификацией всех соответствующих индексов и журнализацией изменений). Далее сервер проверяет, не затрагивает ли данное изменение условие срабатывания какого-либо триггера, и если такой триггер обнаруживается, выполняет процедуру его действия. Эта процедура может включать дополнительные операторы модификации базы данных, которые могут вызвать срабатывание других триггеров и т.д. Можно считать, что те действия, которые выполняются на сервере баз данных при проверке удовлетворенности ограничений целостности и при срабатывании триггеров, представляют собой действия серверной части приложения.
  6.  При выполнении операторов модификации схемы базы данных (добавления или удаления столбцов существующих таблиц, изменения типа данных существующего столбца существующей таблицы и т.д.) также могут срабатывать триггеры, т.е., другими словами, может выполняться серверная часть приложения.
  7.  Аналогично, триггеры могут срабатывать при уничтожении объектов схемы базы данных (доменов, таблиц, ограничений целостности и т.д.).
  8.  Особый класс операторов языка SQL составляют операторы вызова ранее определенных и сохраненных в базе данных хранимых процедур. Если хранимая процедура определяется с помощью достаточно развитого языка, включающего и непроцедурные операторы SQL, и чисто процедурные конструкции (например, языка PL/SQL компании Oracle), то в такую процедуру можно поместить серьезную часть приложения, которое при выполнении оператора вызова процедуры будет выполняться на стороне сервера, а не на стороне клиента.
  9.  При выполнении оператора завершения транзакции сервер должен проверить соблюдение всех, так называемых, отложенных ограничений целостности (к таким ограничениям относятся ограничения, накладываемые на содержимое таблицы базы целиком или на несколько таблиц одновременно; например, суммарная зарплата сотрудников отдела 999 не должна превышать 150 млн. руб.). Снова к проверке отложенных ограничений целостности можно относиться как к выполнению серверной части приложения.

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

Рис. 1.4. "Тонкий" клиент и "толстый" сервер в клиент-серверной архитектуре

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

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

Рис. 1.5. "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов

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

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

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

1.3. Intranet-приложения

Возникновение и внедрение в широкую практику высокоуровневых служб Всемирной Сети Сетей Internet (e-mail, ftp, telnet, Gopher, WWW и т.д.) естественным образом повлияли на технологию создания корпоративных информационных систем, породив направление, известное теперь под названием Intranet. По сути дела, информационная Intranet-система - это корпоративная система, в которой используются методы и средства Internet. Такая система может быть локальной, изолированной от остального мира Internet, или опираться на виртуальную корпоративную подсеть Internet. В последнем случае особенно важны средства защиты информации от несанкционированного доступа. Возможности и проблемы безопасных информационных Intranet-систем мы рассмотрим в пятой части курса.

Хотя в общем случае в Intranet-системе могут использоваться все возможные службы Internet, наибольшее внимание привлекает гипермедийная служба WWW (World Wide Web - Всемирная Паутина). Видимо, для этого имеются две основные причины. Во-первых, с использованием языка гипермедийной разметки документов HTML можно сравнительно просто разработать удобную для использования информационную структуру, которая в дальнейшем будет обслуживаться одним из готовых Web-серверов. Во-вторых, наличие нескольких готовых к использованию клиентских частей - браузеров, или "обходчиков" избавляет от необходимости создавать собственные интерфейсы с пользователями, предоставляя им удобные и развитые механизмы доступа к информации. В ряде случаев такая организация корпоративной информационной системы (рис. 1.6) оказывается достаточной для удовлетворения потребностей компании.

Рис. 1.6. Простая организация Intranet-системы с использованием средств WWW

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

На самом деле, все перечисленные трудности могут быть разрешены с использованием более развитых механизмов Web-технологии. Эти механизмы непрерывно совершенствуются, что одновременно и хорошо и плохо. Хорошо, потому что появляются новые возможности. Плохо, потому что отсутствует стандартизация.

Что касается логики приложения, то при применении Web-технологии существует возможность ее реализации на стороне Web-сервера. Для этого могут использоваться два подхода - CGI (Common Gateway Interface) и API (Application Programming Interface). Оба подхода основываются на наличии в языке HTML специальных конструкций, информирующих клиента-браузера, что ему следует послать Web-серверу специальное сообщение, при получении которого сервер должен вызвать соответствующую внешнюю процедуру, получить ее результаты и вернуть их клиенту в стандартном формате HTTP (рис. 1.7).

Рис. 1.7. Вызов внешней процедуры Web-сервера

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

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

Рис. 1.8. Доступ к базе данных в Intranet-системе

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

На принципах использования внешних процедур основывается также возможность модификации документов, поддерживаемых Web-сервером, а также создание временных "виртуальных" HTML-страниц.

Даже начальное введение в Intranet было бы неполным, если не упомянуть про возможности языка Java. Java - это интерпретируемый объектно-ориентированный язык программирования, созданный на основе языка Си++ с удалением из него таких "опасных" средств как адресная арифметика. Мобильные коды (апплеты), полученные в результате компиляции Java-программы, могут быть привязаны в HTML-документу. В этом случае они поступают на сторону клиента вместе с документом и выполняются либо автоматически, либо по явному указанию. Апплет может быть, в частности, специализирован как шлюз к серверу баз данных (или к какому-либо другому серверу). При применении подобной техники доступа к базам данных схема организации Intranet-системы становится такой как на рис. 1.9.

Рис. 1.9. Доступ к базе данных на стороне клиента Intranet-системы

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

1.4. Склады данных (DataWarehousing) и системы оперативной аналитической обработки данных

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

Прежде чем перейти к обсуждению технических аспектов, коротко обсудим проблемы терминологии. Поскольку термины, связанные со складами данных не так давно появились и на английском языке, и смысл их постоянно уточняется, трудно найти правильные русскоязычные эквиваленты. На сегодняшний день "datawarehouse" разными авторами переводится на русский язык как "хранилище данных", "информационное хранилище", "склад данных". Поскольку термин "хранилище" явно перегружен (он соответствует и английским терминам "storage" и "repository"), в этом курсе мы будем использовать термин "склад данных". Еще хуже дела обстоят с термином "data mart". В четвертом номере журнала "СУБД" за 1996 г. в напечатанных подряд двух статьях авторы переводят этот термин как "витрина данных" и "секция данных" соответственно. Однако в Оксфордском толковом словаре единственным подходящем по смыслу толкованием смысла слова "mart" является "market place". Чтобы не умножать число требуемых сущностей мы будем использовать термин "рынок данных" (обсуждение этого понятия отложим до пятой части курса). Конечно, постепенно терминология будет согласована, но это произойдет только тогда, когда склады данных будут активно использоваться в России.

В этом разделе мы не будем рассматривать возможные технологические приемы реализации складов данных, а обсудим соответствующие вопросы на концептуальном уровне. Начнем с того, что главным образом различает оперативные и аналитические информационные приложения с точки зрения обеспечения требуемых данных. Замечание: речь идет о так называемых OLAP-системах (от On-Line Analitical Processing), т.е. аналитических системах, помогающих принимать бизнес-решения за счет динамически производимых анализа, моделирования и/или прогнозирования данных.

  1.  Основным источником информации, поступающей в оперативную базу данных является деятельность корпорации. Для проведения анализа данных требуется привлечение внешних источников информации (например, статистических отчетов). Тем самым, склад данных должен включать как внутренние корпоративные данные, так и внешние данные, характеризующие рынок в целом.
  2.  Если для оперативной обработки, как правило, требуются свежие данные (обычно в оперативных базах данных информация сохраняется не более нескольких месяцев), то в складе данных нужно поддерживать хранение информации о деятельности корпорации и состоянии рынка на протяжении нескольких лет (для проведения достоверных анализа и прогнозирования). Как следствие, аналитические базы данных имеют объем как минимум на порядок больший, чем оперативные.
  3.  Во многих достаточно крупных корпорациях одновременно существуют несколько оперативных информационных систем с собственными базами данных (как мы уже отмечали в этом курсе, это не очень хорошо, но часто неизбежно по историческим причинам). Оперативные базы данных могут содержать семантически эквивалентную информацию, представленную в разных форматах, с разным указанием времени ее поступления, иногда даже противоречивую (например, из-за ошибок ввода данных). Склад данных корпорации должен содержать единообразно представленные данные из всех оперативных баз данных. Эта информация должна максимально полно соответствовать текущему содержанию оперативных баз данных и быть согласованной. Отсюда следует необходимость наличия компонента склада данных, извлекающего информацию из оперативных баз данных и "очищающего" эту информацию.
  4.  Оперативные информационные системы проектируются и разрабатываются в расчете на решение конкретных задач. Обычно набор запросов к оперативной базе данных становится известным уже на этапе проектирования системы. Информация из базы данных выбирается часто и небольшими порциями. Поэтому при проектировании оперативной базы данных можно и нужно учитывать этот заранее известный набор запросов (с известными оговорками в связи с возможными переделками информационной системы). Набор запросов к аналитической базе данных предсказать невозможно. Склады данных для того и существуют, чтобы отвечать на неожиданные (ad hoc) запросы аналитиков. Можно рассчитывать только на то, что запросы будут поступать не слишком часто и затрагивать большие объемы информации. Размеры аналитической базы данных стимулируют использование запросов с агрегатами (сумма, минимальное, максимальное, среднее значение и т.д.).
  5.  Оперативные базы данных по своей природе являются сильно изменчивыми. Это учитывается в используемых СУБД. В частности, распространенным механизмом индексации являются B-деревья, модификация которых выполняется достаточно быстро, а строки в таблицах хранятся неупорядоченно. Аналитические базы данных меняются только тогда, когда в них загружается оперативная или внешняя информация. В результате оказывается разумным использовать другие, более быстрые при выполнении операций массовой выборки методы индексации, поддерживать упорядоченность информационных массивов, сохранять заранее вычисленные значения агрегатных функций и т.д.
  6.  Если для оперативных информационных систем обычно хватает защиты информации на уровне таблиц (по правилам SQL-ориентированных баз данных), то информация аналитических баз данных настолько критична для корпорации, что для ее защиты требуются более тонкие приемы (например, при использовании реляционных баз данных установка индивидуальных привилегий доступа для индивидуальных строк и/или столбцов таблицы).

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

Рис. 1.10. Схематическое представление архитектуры аналитической информационной системы

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

  1.  Многомерное концептуальное представление данных. Это требование возникает по той причине, что бизнес-пользователь естественно представляет историю и деятельность своей корпорации многомерными (например, одно измерение - время, другое - заказчики, третье - производимая продукция и т.д.). OLAP-модели должны поддерживать это представление и, естественно, оно должно хотя бы в какой-то мере опираться на возможности аналитической базы данных.
  2.  Прозрачность. Для бизнес-пользователя не должно быть существенно, где конкретно расположены средства динамического анализа данных. При разработке OLAP-систем следует придерживаться подхода открытых систем, что позволит размещать средства анализа в любом узле корпоративной сети.
  3.  Доступность. Логическая схема, с которой работает OLAP-система, должна отображаться в схемы разнородных физических хранилищ данных. При доступе к данным должно поддерживаться их единое и согласованное представление.
  4.  Согласованная эффективность производства отчетов. Эта эффективность не должна деградировать при увеличении числа измерений.
  5.  Архитектура "клиент-сервер". Серверный компонент OLAP-системы должен быть достаточно развитым, чтобы разнообразные клиенты могли подключаться к нему с минимальными усилиями и затратами на дополнительное "интегрирующее" программирование.
  6.  Родовая многомерность. Структурные и операционные возможности работы с каждым измерением данных должны быть эквивалентны. Для всех измерений должна существовать только одна логическая структура. Любая функция, применимая к одному измерению, должна быть применима к любому другому измерению.
  7.  Управление динамическими разреженными матрицами. Сервер OLAP-системы должен уметь эффективно хранить и обрабатывать разреженные матрицы. Физические методы доступа должны быть разнообразны, включая прямое вычисление, B-деревья, хэширование или комбинации этих методов.
  8.  Поддержка многопользовательского режима. OLAP-система должна поддерживать многопользовательский доступ к данным (по выборке и изменению), обеспечивая целостность и безопасность данных.
  9.  Неограниченные операции между измерениями. При выполнении многомерного анализа данных все измерения создаются и обрабатываются единообразно. OLAP-система должна быть в состоянии выполнять соответствующие вычисления между измерениями.
  10.  Интуитивное манипулирование данными. Манипуляции, подобные смене пути анализа или уровня детализации, должны выполняться с помощью прямого воздействия на элементы OLAP-модели без потребности использовать меню или другие вспомогательные средства.
  11.  Гибкая система отчетов. Бизнес-пользователь должен иметь возможность манипулировать данными, анализировать и/или синтезировать, а также просматривать их таким образом, как ему захочется.
  12.  Неограниченное число измерений и уровней агрегации. OLAP-сервер должен поддерживать не менее 15 измерений для каждой аналитической модели. Для каждого измерения должно допускаться неограниченное число определяемых пользователями агрегатов.

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

1.5. Интегрированные распределенные приложения

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

Остановимся на некоторых факторах, стимулирующих использование методов интеграции разнородных информационных ресурсов (здесь используются материалы статьи Л.А.Калиниченко и др. из журнала "СУБД" N 4, 1995 г.).

  1.  Неоднородность, распределенность и автономность информационных ресурсов системы. Неоднородность ресурсов может быть синтаксической (при их представлении используются, например, разные модели данных) и/или семантической (используются разные виды семантических правил, детализируются и/или агрегируются разные аспекты предметной области). Возможна и чисто реализационная неоднородность информационных ресурсов, обусловленная использованием разных компьютерных платформ, операционных систем, систем управления базами данных, систем программирования и т.д.
  2.  Потребности в интеграционном комплексировании компонентов информационной системы. Очевидно, что наиболее естественным способом организации сложной информационной системы является ее иерархически-вложенное построение. Более сложные функционально-ориентированные компоненты строятся на основе более простых компонентов, которые могли проектироваться и разрабатываться независимо (что порождает неоднородность; ниже мы приведем примеры).
  3.  Реинжинерия системы. После создания начального варианта информационной системы неизбежно последует процесс ее непрерывных переделок (реинжинерии), обусловленный развитием и изменением соответствующих бизнес-процессов корпорации. Реконструкция системы не должна быть революционной. Все компоненты, не затрагиваемые процессом реинжиниринга, должны сохранять работоспособность.
  4.  Решение проблемы унаследованных (legacy) систем. Любая компьютерная система (надеюсь, что это не относится к открытым системам в теперешнем понимании; только надеюсь, поскольку неизвестно, как отнесутся к нашим взглядам будущие поколения) со временем становится бременем корпорации. Постоянно (и чем раньше, тем лучше) приходится решать задачу встраивания устаревших информационных компонентов в систему, основанную на новой технологии. Нужно, чтобы эта задача была разрешимой, т.е. чтобы компоненты унаследованных систем сохраняли интероперабельность.
  5.  Повторно используемые (reusable) ресурсы. Технология разработки информационных систем должна способствовать использованию уже существующих компонентов, что в конечном итоге должно перевести нас от экстенсивного ручного программистского труда к интенсивным методам сборки ориентированной на конкретную область применения информационной системы.
  6.  Продление жизненного цикла информационной системы. Чем дольше живет и приносит пользу информационная система, тем это выгоднее для корпорации. Естественно, что для этого должна существовать возможность добавления в нее компонентов, спроектированных и разработанных, вообще говоря, в другой технологии.

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

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

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

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

В базовом документе специфицируется эталонная модель архитектуры (OMA - Object Management Architecture) распределенной информационной системы (рис. 1.11).

Рис. 1.11. Эталонная модель OMA

Согласованная с архитектурой OMA прикладная информационная система представляется как совокупность классов и экземпляров объектов, которые взаимодействуют при поддержке брокера объектных заявок (ORB - Object Request Broker). ORB, общие средства (Common Facilities) и объектные службы (Object Services) относятся к категории промежуточного программного обеспечения (middleware) и должны поставляться вместе. Объектные службы представляют собой набор услуг (интерфейсов и объектов), которые обеспечивают выполнение базовых функций, требуемых для реализации прикладных объектов и объектов категории "общие средства" (например, специфицированы служба именования объектов, служба долговременного хранения объектов, служба управления транзакциями и т.д.). Общие средства содержат набор классов и экземпляров объектов, поддерживающих функции, полезные в разных прикладных областях (например, средства поддержки пользовательского интерфейса, средства управления информацией и т.д.).

В основе OMA лежит базовая объектная модель COM (Core Object Model), в которой специфицированы такие понятия, как объект, операция, тип, подтипизация, наследование, интерфейс. Определены также способы согласованного расширения COM в разных объектных службах.

Интерфейсы объекта-клиента и объекта-сервера должны быть определены на специальном языке IDL (Interface Definition Language), который очень напоминает компонент спецификации класса (без реализации) языка Си++. Обращения к ORB могут быть сгенерированы статически при компиляции спецификаций IDL или выполнены динамически с использованием специфицированного в документах OMG API брокера объектных заявок. Правила построения и использования ORB определены в документе OMG CORBA (Common Object Request Broker Architecture). 

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

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

1.2. Основные технологии построения современных распределенных систем

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

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

Раньше, как правило, предписывалось, какой из языков программирования использовать. Смена языка происходила крайне редко. Никакой из отдельно взятых языков не претендовал на звание технологии.

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

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

1.3. Технология CORBA OMG 

В 1989 году группа компаний, в которую входили HP, Sun, American Airlines, Canon и некоторые другие производители, а также — что очень важно — и потребители программных продуктов, организовала некоммерческое сообщество, которое назвали Object Management Group (OMG). Стратегическая задача, которую поставило перед собой это сообщество, состояла в создании технологии, позволяющей объединить программные приложения, выполняющиеся на различных программных и аппаратных платформах, взаимодействующие по различным протоколам, написанные на разных языках программирования, созданные в различных уголках мира совершенно разными группами разработчиков. При этом были сформулированы два важнейших концептуальных момента.

  1.  Результаты деятельности OMG должны представлять собой набор спецификаций, а не готовый продукт.
  2.  В качестве идеологии построения такой технологии решили использовать объектно-ориентированный подход.

Прежде всего, отметим, что это не первый подход к больной теме интеграции и унификации. Приведем в пример хотя бы попытку General Motors в начале 80-х создать однородный протокол для связи с полевым оборудованием. Забытый нынче MAP (Manufacturing Automation Protocol — протокол промышленной автоматики), представляющий собой стандартный коммуникационный стек для передачи сообщений в едином унифицированном формате, не нашел всеобщего признания, на которое рассчитывали его создатели. И это несмотря на вес GM на мировом рынке. Возможно, это произошло не только потому, что протокол очень сложен и требует больших вычислительных ресурсов. Мы также не будем останавливаться на технических преимуществах и недостатках ни этого протокола, ни других способов интеграции до-CORBA. Мы лишь хотим сказать несколько слов о пользе стандартизации.

1.3.1. Pro и contra стандартов

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

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

Именно поэтому OMG занимается только стандартами и принципиально не разрабатывает готовые продукты.

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

У OMG, конечно, нет возможности навязывать свои стандарты. Поэтому им пришлось сделать такой стандарт, который использовать выгодно. Примерно до 1998 года все публикации о CORBA, включая достаточно серьезные книги, повторяли вопрос: «Быть или не быть? Примут или не примут стандарт?» Пока этот вопрос зрел, OMG росла. Начавшись с 13 членов, сообщество сейчас насчитывает более 900 компаний, среди которых, кроме производителей и поставщиков программных решений и компьютерного оборудования, — крупные промышленные и финансовые предприятия, государственные и учебные организации, консалтинговые фирмы и системные интеграторы. Возможно, именно такая сила привела к тому, что с 1999 года уже не встречаются подобные сомнения.

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

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

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

Конечно, не все программные продукты, поддерживающие стандарт CORBA, одинаковы. Многие производители вносят что-то свое. Зачастую эти новаторские решения оказываются столь успешны, что попадают в основной стандарт. Так, на наших глазах это происходит с интерсепторами, которые придумала компания Borland. Разные реализации поддерживают разные версии стандарта, некоторые не поддерживают отдельные особенности. Разобраться в этом не так сложно, и здесь поможет страница сайта OMG http://www.corba.org/vendors/b.htm и технические описания этих продуктов.

Стандарт CORBA — это живой стандарт, чья третья версия появилась совсем недавно (в июне 2002 года), основой CORBA 3 является компонентная модель.

1.3.2. Философия CORBA и политика OMG

CORBA создавалась как технология, призванная объединить разрозненные сообщества компьютерных приложений. Архитектуру OMA, которая является основой CORBA, OMG назвала «архитектурой для объединения мира». С одной стороны, CORBA старается научить приложения общаться, причем не делает различия между «правоверными» объектно-ориентированными или «еретиками», написанными на Коболе. CORBA — демократическая технология и, несмотря на заведомую сложность (если не сказать — невыполнимость) подобной задачи, OMG всегда твердо стояла на своем:

1. Объединяются приложения как новые, так и наследуемые (legacy).

2. Эти приложения могут выполняться на различных операционных платформах (вплоть до самых экзотических, типа Open VMS, Digital UNIX или OS390).

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

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

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

В OMG входят сотни компаний. Но компании состоят из людей, и развитие OMG определяется добровольной и самоотверженной работой сотен и тысяч специалистов — как лидеров компьютерной науки, так и их добросовестных помощников. Мы надеемся, что по мере чтения этой книги вы увидите, какие полезные и передовые идеи открыла для нас OMG. Мы не будем перечислять имен из боязни кого-то пропустить, а всех перечислить просто невозможно. В следующих главах вам встретятся некоторые известные фамилии, другие вы можете увидеть на сайтах OMG http://www.omg.org, http://www.corba.org и на других сайтах по технологии CORBA.

Прямыми конкурентами CORBA являются технологии Java и .NET. Родители конкурентов также являются членами OMG. Sun Microsystems Inc. является одним из основателей сообщества, а Microsoft присоединилась к OMG в 1997 году. Это произошло после того, как в CORBA были стандартизованы мосты CORBA-COM и COM-CORBA. Вскоре появились и соответствующие программные продукты. Возможно, именно присоединение Microsoft помогло утверждению CORBA.

CORBA и Java тесно переплетены. Это и RMI поверх IIOP, о котором вы прочитаете в следующей главе и который нашел столь широкое применение. Это и симбиоз двух компонентных моделей — J2EE (Java 2 Enterprise Edition) и CСМ (CORBA Component Model).

На пути всеобщей интеграции OMG пришла к логической точке создания Model-Driven Architecture. Эта архитектура объединяет все вышеприведенные платформы под сенью очевидной идеи, что бизнес-логика программных приложений по большому счету не зависит от технологической основы. Поэтому первый этап моделирования приложений не должен учитывать специфику выбранной (а возможно, еще и не выбранной к этому моменту) платформы.

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

1.3.3. Область ответственности CORBA

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

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

В области EAI (Enterprise Application Integration) существуют два направления, которые по очереди одерживают верх друг над другом. В соответствии с первым из них интеграцией занимается отдельно выделенный функциональный элемент. Второе направление возлагает эту обязанность на программных агентов, расположенных на каждом узле системы. Первое — область интеграционных серверов, второе — CORBA. В реальной жизни обычно используют некоторую комбинацию обеих возможностей. В любом случае при выборе технологии надо исходить из конкретной задачи и имеющихся в наличии возможностей. К последним относится знание и опыт использования той или иной технологии.

1.4. Технология J2EE Sun 

Технология J2EE (Java 2 Enterprise Edition), формально объявленная в декабре 1999 года, представляет собой первый стандарт для создания корпоративных распределенных многозвенных приложений. Избежав обычно печальной участи «первого блина», J2EE получилась на редкость гармоничной, удобной и полезной. Впитав, как губка, другие стандарты, среди которых важнейшими являются CORBA и XML, J2EE позволяет существенно упростить труд системных архитекторов, проектировщиков и разработчиков, предлагая ясную и гибкую архитектуру и набор взаимосвязанных стандартов для использования важнейших системных сервисов. J2EE объединяет такие стандарты, как компонентная модель Enterprise JavaBeans, стандарты Web-приложений для формирования динамических откликов на действия пользователей — Java Servlets и JavaServer Pages, стандарт для доступа к базам данных JDBC.

1.4.1. Семейка Java

Не удивительно ли, что в последнее время совсем не появляется языков программирования в чистом виде? Собственно, совсем молодых два: C# и Java. Если первый представляет собой важный элемент машины под названием .NET, о которой мы поговорим в следующем разделе, то второй назвать языком просто нельзя.

Современное программирование давно перестало быть просто написанием кода (пусть даже довольно заковыристого). По оценкам экспертов сама функциональность занимает только около 20–30 % программного кода, а все остальное отводится системному хозяйству и поддерживает должное поведение программного обеспечения. И такой перевес нарастает. Действительно, современные приложения, на которых основывается производственная, финансовая и организационная деятельность предприятий, очень сильно отличаются от более старых собратьев. Они должны поддерживать одновременные обращения сотен и тысяч клиентов, функционировать в режиме on-line, предоставлять доступ в соответствии с определенными полномочиями, обеспечивать динамический и богатый интерфейс.

Все рассматриваемые в этой главе технологии стараются освободить разработчиков от этого бремени. И если в рамках CORBA описаны стандарты для 17 системных сервисов, то в этом отношении J2EE существенно скромнее.

Рис. 1.12. Стандартные сервисы J2EE

Стандартные сервисы, определяемые J2EE, вы можете увидеть на рис. 1.12. Некоторые из них:

  1.  Java Naming and Directory Service (JNDI), позволяющий компонентам J2EE отыскивать объекты в распределенной среде;
  2.  Java DataBase Connectivity (JDBC), занимающийся обеспечением доступа приложений к базам и репозитариям данных;
  3.  Java Transaction API и Java Transaction Service, поддерживающие порядок выполнения транзакций для компонентов J2EE;
  4.  Java Messaging Service, стандартизующий механизм обмена сообщениями.

Рис. 1.13. Общая архитектура прикладной модели J2EE

Прикладная модель J2EE (рис. 1.13) состоит из четырех слоев, каждый из которых может функционировать на одном или нескольких узлах распределенной системы. В отличие от традиционной трехзвенной архитектуры, появился слой Web-серверов, который занимается подготовкой презентационной части для клиентов. Модель состоит из четырех уровней:

  1.  уровень client-tier, объединяющий клиентские компоненты, выполняющиеся на клиентских компьютерах;
  2.  уровень web-tier, объединяющий Web-компоненты, выполняющиеся на Web-серверах;
  3.  уровень business-tier, объединяющий бизнес-компоненты, выполняющиеся на J2EE-серверах, которые называются серверами приложений;
  4.  уровень EIS-tier, объединяющий элементы информационных систем, выполняющиеся на EIS-серверах, обычно на серверах баз данных.

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

  1.  клиентские приложения и апплеты, которые выполняются на клиентских компьютерах;
  2.  сервлеты и Java Server Pages, которые представляют собой Web-компоненты и выполняются на Web-серверах;
  3.  Enterprise JavaBeans, которые являются бизнес-компонентами и выполняются на прикладных серверах.

Эти компоненты общаются с помощью различных средств: HTML, XML, RMI — и взаимодействуют через различные протоколы: HTTP, HTTPS, IIOP. Они устанавливаются и выполняются в специальной прикладной среде — контейнерах, которые берут на себя груз системной поддержки и переговоры с клиентами. Для взаимодействия с существующими приложениями в рамках J2EE стандартизована модель коннекторов.

Все компоненты J2EE имеют одно общее свойство: они должны быть написаны на языке Java. Исключением являются только клиентские приложения. Стандарт разрешает CORBA-клиентам взаимодействовать с серверными компонентами J2EE. Вместе с тем компоненты J2EE отличаются от других J2EE-приложений по нескольким параметрам:

  1.  они должны соответствовать спецификации J2EE;
  2.  они разворачиваются во время развертывания J2EE-приложений;
  3.  они управляются и поддерживаются серверами приложений.

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

  1.  динамических Web-страниц, написанных на языках разметки (XML, HTML и др.), которые генерируются Web-компонентами, выполняющимися на Web-серверах;
  2.  Web-браузеров, которые визуализируют эти страницы, получаемые от Web-серверов.

Мода на Web-клиентов вернула нас к тонким или даже сверхтонким клиентам.

Основным элементом J2EE, несомненно, является компонентная модель Enterprise JavaBeans. Можно сказать, что J2EE предоставляет стандартное API, инфраструктуру и набор типовых клиентов для EJB.

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

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

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

  1.  J2EE Product Provider — компания-разработчик, которая поставляет на рынок платформу J2EE, API и другие компоненты спецификации J2EE.
  2.  Tool Provider — компания-разработчик, которая создает средства разработки, сборки и упаковки для создания J2EE-приложений.
  3.  Application Component Provider — разработчики компонентов:
  4.  Enterprise Bean Developer — разработчики компонентов бизнес-логики, определяющие также структуру дескриптора развертывания для EJB и собирающие JAR-файл1;
  5.  Web Component Developer — разработчики Web-компонентов (сервлетов, апплетов, JSP- и HTML-страниц), которые также определяют дескриптор развертывания, только для сервлетов и JSP, и собирают WAR-файл2;
  6.  J2EE Application Client Developer — разработчики «толстых» клиентов, которые собирают JAR-файл для клиентской части;
  7.  Application Assembler — собирают из компонентов на основе предоставленных JAR- и WAR-файлов архивный EAR-файл приложения.
  8.  Application Deployer — конфигурируют и разворачивают приложение, устанавливая параметры дескрипторов развертывания.
  9.  Administrator — поддерживает работоспособность приложения, по необходимости изменяя установки.

1.4.2. Область применения J2EE

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

Сертификация программных продуктов (серверов приложений) по J2EE выполняется с помощью набора тестов, разработанных компанией Sun, — J2EE Compatibility Test Suite. Тесты включают проверку всех классов и методов, упоминаемых в спецификации J2EE, а также проверку взаимодействия всех компонентов спецификации. Программные продукты, выполняющиеся на программных продуктах (серверах приложений), сертифицированных на соответствие одному и тому же релизу, должны быть портируемыми. Это позволяет переносить приложения с одного сервера приложений на другой без изменения исходного кода. Список серверов приложений, прошедших тесты, можно найти на http://java.sun.com/j2ee/compatibility.html. 

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

1.5. Технология .NET 

1.5.1. Краткий обзор технологии .NET

Компонентная идея заразила Microsoft еще в начале 90-х годов. Как и другим компаниям, ей стало очевидно, что скорость создания программных систем существенно отстает от предъявляемых бизнесом требований. Вместе с тем, из программы в программу повторяются общие элементы, которые программисты исправно пишут, каждый раз изобретая велосипед. Во многом повторяя идеи, заложенные в CORBA (в частности, язык описания интерфейсов), Microsoft создала технологию COM, первая версия которой появилась в 1993 году. Однако не секрет, что COM имеет существенные недостатки. Прежде всего, COM поддерживает взаимоотношение приложений, выполняющихся на одном компьютере, что, согласитесь, в современном распределенном мире не всегда удобно. Попытки Microsoft устранить этот досадный недостаток с помощью DCOM (Distributed COM), как и всякое латание дыр, не привело к ожидаемым результатам, и тогда Microsoft приняла единственно верное решение. На базе COM и сервера транзакций Microsoft Transaction Server была разработана специальная технология .NET. Впрочем, процесс разработки .NET продолжается.

В соответствии с определением, Microsoft .NET — это среда выполнения Web-приложений в ОС Windows 2000. Цель создания .NET все та же — сократить и упростить разработку, внедрение и поддержку распределенных программных систем, в данном случае — функционирующих на платформах Windows. Среда .NET добавляет к операционной системе Windows такие важные функции, как автоматическая сборка мусора и простой доступ к базам данных и Интернету, и расширяет компонентную модель COM+. Она развивает среду ASP (Active Server Page), созданную Microsoft в 1997 году как элемент Internet Information Server, который входил в Windows NT 4 Option Pack.

Основная идея .NET заключается в понятии управляемого кода, который выполняется не просто на операционной системе Windows, а под управлением ее дополнительного элемента — среды CLR (Common Language Runtime) — общей среды выполнения для программных приложений, написанных на различных языках. CLR очень похожа на Java Runtime Environment (JRE). При этом программы (с помощью, например, Visual Sudio .NET) компилируются в код на специальном языке Microsoft Intermediate Language (MSIL, или IL). Среда CLR, в частности, освобождает программистов от сборки мусора не хуже, чем Java, проводя автоматическую чистку неиспользуемой памяти (garbage collection). На нее также возложено управление доступом к программному коду.

В настоящее время существует множество компиляторов программных языков в IL, в дополнение к предоставляемым Microsoft для Visual Basic, C#, JScript и C++. Такая унификация вынудила Microsoft сблизить языки, которые поддерживаются в Visual Studio .Net. Особенно это касается новой версии Visual Basic.

Для того чтобы выполняться на конкретной операционной платформе (которых в семействе Windows тоже предостаточно), код на IL должен быть обработан just-in-time-компилятором (JITter), после чего и получается соответствующий машинный код. В настоящее время существуют JITter для Windows 2000 и Windows XP.

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

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

Для динамического Web .NET предлагает модернизированную среду ASP .NET. В ней реализована идея отделения динамического кода от статического текста HTML-страниц, причем первый можно создавать и отлаживать в Visual Studio с помощью специальной модели Web Forms. Кроме того, ASP .NET выгодно отличается от просто ASP в возможностях сохранения состояния сессий. Конфигурационная информация Web-приложения хранится в специальном файле в формате XML, так же как и в J2EE.

Нельзя говорить о .NET и ни слова не сказать о Web-сервисах — новом направлении развития Интернета, которое по замыслу его создателей Microsoft и IBM позволит приложениям взаимодействовать, динамически отыскивая в глобальной сети необходимые сервисы и вызывая их по мере необходимости. Web-сервисы используют для передачи сообщений протокол SOAP (Simple Object Access Protocol), описываются на языке WSDL (Web Services Definition Language) и используют механизм UDDI (Universal Description, Discovery and Integration) для публикации и поиска сервисов. Все эти элементы представляют собой спецификации международной организации W3C и активно развиваются.

Для поддержки Web-сервисов Microsoft, опять же вместе с IBM, предложили новую архитектуру SOA (Service-Oriented Architecture), в основе которой лежит понятие сервиса как основы взаимоотношения приложений. Вокруг этого понятия можно очертить ролевой треугольник, в вершинах которого будут находиться Service requester (подписчик), запрашивающий сервис, Service provider, предоставляющий сервис, и Service broker, позволяющий подписчику найти провайдера.

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

  1.  Application Center 2000 (используется для развертывания и управления Web-приложениями);
  2.  BizTalk Server 2002 (служит для построения бизнес-процессов, объединяющих разные приложения и организации);
  3.  Commerce Server 2000 (предназначен для построения масштабируемых решений в области электронной коммерции);
  4.  Content Management Server 2001 (выполняет роль управления контентом для динамических Web-сайтов в области электронного бизнеса);
  5.  Exchange 2000 Server (используется для передачи сообщений и обеспечения совместной работы других серверов);
  6.  Host Integration Server 2000 (применяется для интеграции наследуемых (legacy) приложений, например выполняющихся на мэйнфреймах или миникомпьютерах);
  7.  Internet Security and Acceleration Server 2000 (его роль — организовать быстрый и безопасный доступ в Интернет);
  8.  Mobile Information 2001 Server (занимается поддержкой мобильных устройств, прежде всего мобильных телефонов);
  9.  SharePoint Portal Server 2001 (служит для поиска, распределения и публикации бизнес-информации);
  10.  SQL Server 2000 (используется для запоминания, хранения, извлечения и анализа структурированных XML-данных).

1.5.2. BizTalk, легкая интеграция приложений

BizTalk является развитием идей, заложенных Microsoft в Commerce Interchange Pipeline и Commerce Interchange Pipeline Manager (дополнительные элементы Site Server 3.0 Commerce Edition). BizTalk использует ту же самую библиотеку Pipecomplib.tlb.

Сервер BizTalk представляет собой интеграционный сервер и набор эффективных средств для построения и развертывания бизнес-процессов для осуществления транзакций в области EAI (Enterprise Application Integration) и B2B (Business-to-Business). Он поддерживает разнообразные протоколы, среди которых HTTP, HTTPS, SMTP, SSL, S/MIME (Secure Multipurpose Internet Mail Extensions) и SOAP.

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

BizTalk включает графические средства. Перечислим некоторые из них.

  1.  BizTalk Editor — средство создания спецификаций документов. Подобные спецификации представляют собой XML-файлы, которые определяют структуру, тип и версию документа.
  2.  BizTalk Mapper — графическое средство для преобразования XML-данных в различные структуры, такие как EDI (Electronic Data Interchange, например формата EDIFACT) или flat-файлы. Если формат, определенный BizTalk Editor, по каким-то причинам вас не устраивает, то вы можете использовать это средство для того, чтобы отобразить его в определенный вами формат.
  3.  BizTalk Messaging Manager — графический интерфейс, содержащий мастер (wizard) для создания портов и каналов, с помощью которых можно управлять обменом данными между приложениями. С помощью BizTalk Messaging Manager создается объектная спецификация документа, которая запоминается в базе данных MS SQL.
  4.  BizTalk Orchestration Designer — средство создания, развертывания и управления распределенными бизнес-процессами. Он основан на графическом интерфейсе Microsoft Visio. Музыкальное понятие «оркестровка» является аналогией между ролью BizTalk по отношению к бизнес-процессам и дирижером по отношению к оркестру. С помощью дизайнера создается специальное расписание на скриптовом языке, которое задает последовательность обработки бизнес-процессов.

Основными компонентами BizTalk являются Application Integration Component (AIC) и компоненты типа pipeline, которые напрямую происходят от pipeline component (типа Order Processing и Commerce Interchange) Microsoft Site Server 3.0. Другой важный элемент сервера — пользовательские препроцессоры, которые используются для предварительной обработки документов, если ее необходимо произвести до передачи документа BizTalk серверу.

BizTalk включает в себя так называемые сервисы передачи и обработки сообщений (Messaging Services), хотя в данном случае это касается не столько сообщений, сколько документов. Эти сервисы умеют:

  1.  получать входящий документ;
  2.  разбирать документ в соответствии с определенным для него форматом;
  3.  выделять ключевые идентификаторы и идентифицировать правила маршрутизации;
  4.  доставлять документ соответствующим адресатам;
  5.  отслеживать передачу документа;
  6.  связывать данные одного документа с данными другого;
  7.  поддерживать целостность документов и ограничения прав доступа.

Последняя версия BizTalk Server 2002 обладает рядом полезных особенностей. Для развертывания компонентов BizTalk используется Application Center 2000. Появился новый элемент — Windows Management Instrumentation (WMI), который позволяет управлять бизнес-процессами с помощью графического интерфейса. Новый сервер включает SOAP Toolkit 2.0, который может синхронизировать бизнес-процессы, включающие использование Web-сервисов.

В настоящее время уже создано некоторое количество адаптеров, позволяющих соединять BizTalk-сервер с различными корпоративными приложениями, например SAP, Oracle Financials, People Soft, Siebel, Remedy. Вы можете получить информацию о доступных адаптерах на странице www.microsoft.com/biztalk/evaluation/adapters.asp.

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

1.6. Сравнение CORBA, J2EE и .NET 

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

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

1.6.1. Сравнение идеологических подходов

Все три технологии представляют собой решение из области Enterprise Integration Application (EAI). Утвердившийся подход к интеграции приложений заключается в описании внешних интерфейсов, форматов сообщений и спецификаций, используемых для передачи этих сообщений. В процесс интеграции в современном понимании этой задачи также вовлечено понятие Quality-of-Service, в особенности все, что касается сервисов безопасности, надежности и транзакционной целостности. Но создатели всех трех технологий почувствовали, что этого недостаточно. Интеграция программных приложений, так же как и сами приложения, реализует потребности бизнеса, поэтому необходимо привлечь в интеграционную модель элементы описания бизнес-процессов. 

Пожалуй, как и во многих других случаях, первопроходцем выступило OMG, которое в конце 90-х годов выпустило несколько спецификаций, формализующих понятие бизнес-объекта, средств управления бизнес-объектами и среды их функционирования (Business Object Facility (BOF) и Business Object Component Architecture (BOCA)). Стандарты моделирования OMG (UML, MOF, MDA) также позволяют связать бизнес-модель распределенной системы с техническими средствами CORBA и ее компонентной модели.

Технология J2EE пока не стандартизовала средства моделирования и проектирования бизнес-процессов. Но в реальности большинство средств разработки содержат встроенные средства моделирования, которые позволяют автоматически генерировать компоненты J2EE на основе бизнес-моделей. Приведем в качестве примера JBuilder 6 Enterprise Edition компании Borland.

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

Еще одна важная особенность всех трех технологий связана с их местом в общей иерархии программного обеспечения. По сути, любая из рассмотренных нами сред представляет собой промежуточное программное обеспечение. Однако для всех трех (хотя для CORBA в меньшей степени) характерно постепенное сращивание с операционными платформами. И если .NET можно рассматривать как новую версию Windows 2000, то Sun One, недавно анонсированная Sun Microsystems, интегрирована и с аппаратной платформой.

В следующих главах книги вы познакомитесь с последовательностью создания современных распределенных программных приложений. Здесь все три технологии придерживаются одинаковых принципов и терминологии. Вы не найдете существенных отличий и в подходе к такому важному этапу, как сборка приложений: для всех трех технологий это объединение разнообразных файлов, составляющих приложение (естественно, типы фалов могут отличаться). Наконец, во всех трех технологиях присутствуют дескрипторы — XML-файлы, описывающие параметры, необходимые для выполнения приложений и определяющие настройки системных сервисов.

Вы можете увидеть отчетливую аналогию между ASP и JSP, недаром их названия настолько созвучны. Обе технологии: и J2EE, и .NET — придерживаются сходных подходов к созданию и обработке динамических Web-страниц. И это нас совершенно не удивляет.

Мы можем также проследить аналогию между другими Web-компонентами: сервлетами и Web Forms Server Control (серверные элементы управления динамическими страницами в ASP .NET). Но надеемся, что вы уже поняли, насколько схожи идеи, лежащие в основе соперничающих технологий.

1.6.2. Сравнение с точки зрения применения

Как же выбрать тогда технологию, наилучшим образом подходящую к решению конкретной задачи? Можно, конечно, обратиться к результатам тестов на производительность. В этом случае можем отослать вас к тестированию любимого примера Sun для J2EE, а именно магазина Pet Shop на платформе Oracle 9i Application Server. Результаты теста производительности приведены по адресу http://otn.oracle.com/tech/java/oc4j/content.html. Можно также попытаться оценить выбираемую стратегическую платформу по нескольким критериям. В качестве примера можем порекомендовать следующие:

  1.  необходимость портируемости приложения на различные платформы;
  2.  требуемые интеграционные свойства;
  3.  наличие квалифицированных разработчиков;
  4.  объем и сложность проекта.

Необходимо отметить, что по оценке Gartner Group по триаде «стоимость – риск – время на разработку» компонентная модель EJB уверенно побеждает COM. Gartner Group в отчете «Application Development Management Strategies» (декабрь 2001 г.) называют J2EE основной архитектурой для корпоративных приложений на ближайшие несколько лет. По их отзывам альтернативная технология Microsoft .NET и архитектура SOA (Service-Oriented Architecture) далеко еще не достигли ее уровня.

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

Подведем некоторые итоги. На основе заключений экспертов, мнений пользователей и специалистов можно сделать некоторые выводы. Технология CORBA предоставляет уникальные возможности интеграции и поэтому должна применяться в сложных гетерогенных средах. Ее использование необходимо, например, при интеграции с legacy-приложениями. Технология .NET еще не окончательно доработана, поэтому применять ее надо осторожно, а лучше дождаться следующих версий. Добавим, что компонентная модель CORBA только-только появилась и поэтому никак не может конкурировать с компонентной моделью EJB, которая лежит в основе J2EE. Поэтому можно сделать вывод, что наиболее популярная, востребованная, используемая и доступная технология распределенных компонентных систем в настоящее время — это J2EE.

Основная претензия к технологии Java и, в частности, к J2EE — ее слабая производительность, которая особенно заметна на платформах Windows и вообще на любых платформах, отличных от Sun.

1.6.3. Взаимное влияние технологий

Мы уже много говорили о том, насколько похожи все три технологии. Мы с удивлением обнаружили в описании Web-сервисов от Microsoft упоминание протокола IIOP в одном ряду с DCOM и RMI. В рамках CORBA стандартизованы программные мосты CORBA-COM и COM-CORBA. J2EE активно использует стандарты CORBA, в частности IIOP (Internet Inter ORB Protocol) и системные сервисы. Как известно, в настоящее время CORBA-приложения и J2EE-приложения умеют взаимодействовать друг с другом практически в любой ситуации. Компонентная модель CORBA включает компоненты EJB как полноправные составляющие (причем как в качестве клиента, так и в качестве сервера).

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

Новый стандарт OMG — MDA (Model-Driven Architecture) объединяет под своим крылом все три технологии. Построение независимой от платформы бизнес-модели позволяет в дальнейшем портировать такую модель на различные платформы middleware. Автоматическая генерация большей части кода сможет существенно сократить труд разработчика и повысить качество создаваемых программных систем. MDA упростит также интеграцию программных систем, функционирующих на различных платформах, с помощью построения отображения сходных сущностей. В рамках MDA уже стандартизован профиль CORBA, ведется работа над созданием аналогичных профилей для J2EE и .NET.


2. Сетевое программирование и сетевые приложения

2.1. Обмен данными по сети

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

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

2.2. Обработка данных в системах клиент/сервер

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

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

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

Каким образом клиент указывает местонахождение сервера? В Интернете это местонахождение обозначается парой идентификаторов (computer, application)

Здесь computer обозначает компьютер, на котором выполняется серверная программа, а applicationконкретную прикладную программу на этом компьютере. При передаче по Интернету эти два значения представлены в виде двоичных чисел. Однако сами пользователи не имеют дела с двоичным представлением — они указывают нужные значения в символьном виде. Пользователи вводят имена и числа, а сетевое программное обеспечение вызывает на выполнение функции, преобразующие символьные значения в соответствующие двоичные значения автоматически.

2.3. Принципы обмена данными

В процессе обмена данными между большинством приложений Интернета выполняется одна и та же последовательность операций.

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

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

2.4. Пример интерфейса прикладного программирования

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

Для демонстрации принципов сетевого программирования мы разработали простой АРI-интерфейс для операций обмена данными по сети. После описания АРI-интерфейса рассмотрим приложения; в которых он используется. В табл. 2.1 перечислено семь функций, которые могут быть вызваны в приложении.

Таблица 2.1. Пример АРI-интерфейса включает семь операций. Этих семи функций достаточно для создания большинства сетевых приложений.

Операция

Описание

await_contact

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

make_contact

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

cname_to_comp

Используется для преобразования имени компьютера в эквивалентное внутреннее двоичное значение

appname_to_appmun

Используется для преобразования имени программы в эквивалентное внутреннее двоичное значение

send

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

recv

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

send_eof

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

2.5. Неформальное описание АРI-интерфейса

Сервер начинает свою работу с вызова функции Await_contact для перехода в режим ожидания запроса на установление соединения от клиента. Клиент начинает свою работу с вызова функции Make_contact для установления соединения.

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

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

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

Сервер

Клиент

await_contact 

make_contact 

recv 

send 

send 

send_eof

send_eof 

recv

Рис. 2.1. Последовательность вызовов функций АРI-интерфейса в простейшем сеансе обмена данными. Клиент посылает один запрос и получает один ответ.

2.6. Определение АРI-интерфейса

Чтобы АРI-интерфейс был независимым от конкретных операционных систем и сетевого программного обеспечения, для него определены три типа данных, которые используются во всем коде. В табл. 2.2 перечислены имена типов и указано их назначение.

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

Имя типа

Описание

Appnum

Двоичное значение, которое используется в качестве идентификатора приложения

Computer

Двоичное значение, которое используется в качестве идентификатора компьютера

connection

Значение, которое используется в качестве идентификатора соединения между клиентом и сервером

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

2.6.1. Функция await_contact

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

connection await_contact(аррnum а)

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

2.6.2. Функция make_contact

Клиент вызывает функцию make_contact для установления соединения с сервером.

connection make_contact (computer с, appnum а)

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

2.6.3. Функция аррname_to_аррnum

Клиент и сервер используют функцию аррname_to_аррnum для преобразования: имени службы, предназначенного для восприятия человеком, во внутреннее двоичное значение. Имена служб в Интернете стандартизированы (например, www означает службу World Wide Web).

аррnum_appname_to_appnum(char *a)

Этот вызов принимает один параметр строкового типа (в языке С объявление char * применяется для обозначения строки) и возвращает эквивалентное двоичное значение типа аррnum

2.6.4.Функция cname_to_comp

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

computer_cname(char *с)

Этот вызов принимает один параметр строкового типа (char *) и возвращает эквивалентное двоичное значение типа computer.

2.6.5. Функция send

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

int send(connention con, char *buffer, int length, int flags)

Этот вызов принимает четыре параметра. Первый параметр обозначает соединение, установленное ранее с помощью функции make_contact или await_contact, второй представляет собой адрес буфера, содержащего данные, предназначенные для передачи, третий параметр задает длину данных в байтах октетах), а четвертый при обычной передаче равен нулю. Функция send возвращает число переданных байтов или отрицательное значение, если возникла ошибка. См. также функцию send_eof, которая применяется для передачи признака конца файла после отправки всех данных.

2.6.6. Функции recv и recvln

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

int recv( connection соn, char *buffer, int length, int flags)

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

В этом примере кода применяется также библиотечная функция recvln, которая повторно вызывает функцию recv до тех пор, пока не будет получена целая строка текста. Определение функции recvln приведено ниже;

int recvln( connection соn, char *buffer, int length)

2.6.7. Функция send_eof

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

int send_еоf(сonnection сon)

Этот вызов принимает один параметр, который указывает соединение, ранее установленное с помощью функции await_contact или make_contact. Функция возвращает отрицательное значение для указания на то, что возникла ошибка; в ином случае — положительное значение или ноль.

2.6.8. Сводные данные по АРI-интерфейсу

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

Таблица 2.3. Сводные данные по типам параметров и возвращаемым значениям для примера АР1-интерфейса

Имя функции

Тип возвращаемого значения

Тип параметра 1

Тип параметра 2

Тип параметров З и 4

await_contact

connection

appnum

make_contact

connection

computer

appnum

aррname_to_аррnum

appnum

сhаг *

cname_to_comp

computer

сhаг *

send

int

connection

сhаг *

int

rесv

int

connection

сhаг *

int

send_eof

int

connection

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

2.7. Код приложения эхо-повтора

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

Рис. 2.2. Демонстрация работы приложения эхо-повтора, которое может использоваться на любых двух компьютерах, подключенных к Интернету. Клиентская программа работает на одном компьютере, а серверная — на другом.

Для вызова сервера пользователь должен выбрать номер приложения в диапазоне от 1 до 32767, который не используется другим приложением, и задать этот номер в качестве параметра командной строки. Предположим, что пользователь, работающий на компьютере lancelot.cs.purdue.edu выбрал в качестве номера приложения число 20000. Сервер вызывается командой:

echoserver 20000

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

После вызова на выполнение серверной программы вызывается клиентская программа с указанием имени компьютера, на котором работает сервер, и номера приложения, используемого сервером. Например, для доступа к серверу, описанному выше, пользователь может ввесги следующую команду echoclient lancelot.cs.purdue.edu 2000

2.7.1. Пример кода эхо-сервера

Код эхо-сервера содержится в файле echoserver.с.

/* echoserver.c */

#include <stdlib.h>

#include <stdio.h>

#include <cnaiapi.h>

#define BUFFSIZE 256

/*-----------------------------------------------------------------------

*

* Program: echoserver

* Purpose: wait for a connection from an echoclient and echo data

* Usage: echoserver <appnum>

*

*-----------------------------------------------------------------------

*/

int

main(int argc, char *argv[])

{

connection conn;

int len;

char buff[BUFFSIZE];

if (argc != 2) {

(void) fprintf(stderr, "usage: %s <appnum>\n", argv[0]);

exit(1);

}

/* wait for a connection from an echo client */

conn = await_contact((appnum) atoi(argv[1]));

if (conn < 0)

exit(1);

/* iterate, echoing all data received until end of file */

while((len = recv(conn, buff, BUFFSIZE, 0)) > 0)

(void) send(conn, buff, len, 0);

send_eof(conn);

return 0;

}

Как уже было сказано, сервер принимает один параметр командной строки, в котором задан применяемый номер приложения. В языке С параметры командной строки передаются программе в виде массива строк (argv), наряду с указанием количества параметров в виде целого числа (argc). В коде происходит выборка параметра командной строки из переменной argv[1], а затем вызывается стандартная функция atoi языка С для преобразования этого значения из кода ascii в двоичный код. Затем полученный результат передается в качестве параметра функции await_contact. После возврата управления из функции await_contact сервер повторно вызывает функцию recv для получения данных от клиента и функцию send для передачи назад тех же данных. Цикл завершается после того, как функция recv обнаруживает признак конца файла и возвращает нулевое значение. В этот момент сервер отправляет признак конца файла и завершает работу.

2.7.2. Пример кода клиента службы эхо-повтора

Код приложения клиента службы эхо-повтора приведен в файле echoclient.с.

/* echoclient.c */

#include <stdlib.h>

#include <stdio.h>

#include <cnaiapi.h>

#define BUFFSIZE 256

#define INPUT_PROMPT "Input > "

#define RECEIVED_PROMPT "Received> "

int readln(char *, int);

/*-----------------------------------------------------------------------

*

* Program: echoclient

* Purpose: contact echoserver, send user input and print server response

* Usage: echoclient <compname> [appnum]

* Note: Appnum is optional. If not specified the standard echo appnum

* (7) is used.

*

*-----------------------------------------------------------------------

*/

int

main(int argc, char *argv[])

{

computer comp;

appnum app;

connection conn;

char buff[BUFFSIZE];

int expect, received, len;

if (argc < 2 || argc > 3) {

(void) fprintf(stderr, "usage: %s <compname> [appnum]\n",

argv[0]);

exit(1);

}

/* convert the arguments to binary format comp and appnum */

comp = cname_to_comp(argv[1]);

if (comp == -1)

exit(1);

if (argc == 3)

app = (appnum) atoi(argv[2]);

else

if ((app = appname_to_appnum("echo")) == -1)

exit(1);

 

/* form a connection with the echoserver */

conn = make_contact(comp, app);

if (conn < 0)

exit(1);

(void) printf(INPUT_PROMPT);

(void) fflush(stdout);

/* iterate: read input from the user, send to the server, */

/* receive reply from the server, and display for user */

while((len = readln(buff, BUFFSIZE)) > 0) {

/* send the input to the echoserver */

(void) send(conn, buff, len, 0);

(void) printf(RECEIVED_PROMPT);

(void) fflush(stdout);

/* read and print same no. of bytes from echo server */

expect = len;

for (received = 0; received < expect;) {

len = recv(conn, buff, (expect - received) < BUFFSIZE ?

(expect - received) : BUFFSIZE, 0);

if (len < 0) {

send_eof(conn);

return 1;

}

(void) write(STDOUT_FILENO, buff, len);

received += len;

}

(void) printf("\n");

(void) printf(INPUT_PROMPT);

(void) fflush(stdout);

}

/* iteration ends when EOF found on stdin */

(void) send_eof(conn);

(void) printf("\n");

 return 0;

}

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

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

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

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

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


3. Взаимодействие типа «клиент-сервер»

3.1. Логическая трехзвенная модель Web-приложений

Presentation

Presentation

Business

Business

Data

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

Рис. 3.1. Логическая трехзвенная модель Web-приложений.

  1.  Представления данных (Presentation) – интерфейс взаимодействия пользователя и приложения:
  2.  Ввод данных пользователем;
  3.  Пересылка входных данных компонентам, которые работают с функциональной логикой приложения (business-objects);
  4.  Получение результирующих данных от бизнес объектов;
  5.  Представление этих результатов в требуемом виде.
  6.  Функциональная логика приложения (Business) – множество бизнес-объектов, которые выполняют требуемые операции над данными пользователя и местом их хранения (базой данных), т.е. которые реализуют функциональную часть приложения– часть, для которой создавалось приложение.
  7.  Хранилище (Data) – сохранение данных, выборка, вставка, удаление и возможная модификация, целостность, резервное копирование и.т.д.– например база данных.

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

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

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

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

3.2. Различная физическая реализация логической модели

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

  1.  Друзвенная система
    1.  

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

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

  1.  Трехзвенная система
    1.  

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

В трехзвенной системе, построенной с использованием web – технологий клиент взаимодействует напрямую с сервером, т.е. все особенности конкретной базы данных скрыты от него. Все компоненты доступа к БД располагаются на web-сервере.

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

Существует несколько вариантов реализации трехзвенной модели.

3.2.2.1. Тонкий клиент

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

Документы (страницы) генерируются на сервере либо посредством скриптовых языков (например, ASP) или посредством внешних по отношению к web-серверу программ (используя CGI). Все запросы и доступ к БД выполняются компонентами сервера или внешними программами.

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

Сегодня ведущие производители ПО сосредоточены на организации эффективного WWW-доступа к информационным хранилищам, построенным на основе их сервере БД. В такие пакеты включается обработка запросов от WWW-server к серверу БД и динамическая генерация гипертекстовых документов.

3.2.2.2. Толстый клиент

Этот клиент имеет очень богатый инструментарий, например, виртуальныу машину Java (JVM) и JDBC-клиент или другие специфичные для конкретной платформы средства, которые позволяют получить прямой доступ к БД. В этом случае как уровень представления, так и функциональная логика располагается на одном и том же клиенте.

ПРИМЕРЫ:

  1.  Java-апплет, загруженный с web-сервера на клиент (посредством ссылки в гипертекстовом документе) и выполняемый на клиенте. Java-апплет выполняет доступ к БД напрямую через специальный протокол JDBC, функциональная логика (формирование SQL-запросов и обработка результатов) содержится в том же Java-аппелете.
  2.  Решение для конкретных платформ, например, для платформы Microsoft Windows: OCX (OLE Custom Controls) в IE доступ к БД через RDС (RemoteData Controls).

3.2.3. Различные промежуточные варианты

Java-аппелты выполняются на клиенте, но они имеют доступ к хранилищу не напрямую, а через компоненты сервера.

Некоторые клиенты (DHTML, JavaScript) позволяют allow осуществлять проверку данных, введенных пользователем на клиенте без доступа к серверу.

3.2.3.1. Многозвенные системы

Многозвенные системы являются модификацией трехзвенных систем.

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

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

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

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

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

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

Простейшим примером решения, реализованном на базе ПО Microsoft, является Intranet-система, которая располагает клиентские части на базе Microsoft Internet Explorer, сервер приложений – на базе Microsoft Internet Information Server с использованием Microsoft Distributed Transaction Coordinator (возможно, Microsoft Transaction Server) и, наконец, сервер БД на базе Microsoft SQL Server.

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

Основными преимуществами таких систем являются:

  1.  Компонентная архитектура;
  2.  Функциональность на компонентном уровне;
  3.  Возможность повторного использования компонент;

  1.  Возможность одновременного использования компонент;

  1.  Упрощение модификации и масштабируемость;
  2.  Наличие потенциала для наращивания производительности;
  3.  Возможность независимой разработки компонент.


4. Интерфейс сокетов

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

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

4.1. Интерфейс прикладного программирования

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

Как было описано в разделе 2, интерфейс, используемый приложением при взаимодействии с программным обеспечением транспортного протокола, называется интерфейсом прикладного программирования (Application Programming Interface - АРI). Поскольку АРI-интерфейс определяет набор операций, которые могут быть выполнены приложением при взаимодействии с программным обеспечением протокола, АРI-интерфейс определяет также состав доступных функциональных средств. Кроме того, требуемые параметры указывают, что должно быть предусмотрено в программе для использования этих функциональных средств.

В большинстве систем программирования определен АРI-интерфейс, аналогичный тому, который показан в примере раздела 2. В определении интерфейса приведен перечень процедур, доступных для приложений, перечислены параметры, принимаемые каждой процедурой, и описаны типы данных. Обычно АРI-интерфейс включает отдельную процедуру для каждой логической функции. Например, АРI-интерфейс может содержать одну процедуру, применяемую для установления соединения, и другую — для передачи данных.

4.2. АРI-интерфейс сокетов

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

Хотя стандарты протоколов позволяют проектировщикам операционной системы выбрать любой АРI-интерфейс, во многих операционных системах принят АРI-интерфейс сокетов. АРI-интерфейс сокетов доступен для многих операционных систем, включая системы, используемые на персональных компьютерах (например, систему Windows компании Microsoft), а также во многих системах UNIX (например, в системе Solaris компании Sun Micrisystem).

АРI-интерфейс сокетов впервые был создан как часть операционной систем ВSD UNIX. Для финансирование работ по созданию этой операционной системы правительством США был выделен грант и составлен договор, в соответствии с которым Калифорнийский университет в Беркли должен был разработать и распространить версию UNIX, содержащую программное обеспечение протоколов объединенных сетей ТСР/IР. В дальнейшем, многие поставщики компьютеров; перенесли систему ВSD на свое аппаратное обеспечение и использовали ее как основу коммерческих продуктов операционных систем. Поэтому АРI-интерфейс сокетов фактически стал стандартом компьютерной индустрии.

4.3. Сокеты и библиотеки сокетов

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

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

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

4.4. Связь через сокеты и ввод/вывод в системе UNIX

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

Во всей системе ввода/вывода UNIX применяется принцип "ореп-read-write-с1оsе" (открытъ-читатъ-писатъ-закрытъ). Этот принцип получил свое название по именам основных операций ввода/вывода, которые применяются и к устройствам, и к файлам. Например, приложение должно вначале вызвать функцию open, чтобы подготовить файл для доступа. Затем приложение вызывает функцию read или write для выборки данных из файла или записи данных в файл. Закончив использовать файл, приложение вызывает функцию сlоsе.

Вызов процедуры open при открытии приложением файла или устройства возвращает дескриптор — небольшое целое число, которое обозначает файл; приложение должно указывать дескриптор при обращении к функциям передачи данных (т.е. дескриптор является параметром процедуры read или write). Например, если приложение вызывает процедуру open для доступа к файлу foobar, процедура open может вернуть дескриптор 4 Последующий вызов процедуры write, в котором будет задан дескриптор 4, вызовет запись данных в файл foobar; имя файла в вызове процедуры не используется.

4.5. Сокеты, дескрипторы и сетевой ввод/вывод 

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

В реализации UNIX сокеты неразрывно объединены с другими средствами ввода/вывода. В операционной системе предусмотрен единый набор дескрипторов для файлов, устройств, средств межпроцессного взаимодействия и средств сетевой связи. В результате такие процедуры, как read и write, становятся полностью универсальными: в приложении одна и та же процедура может иcпользоваться для передачи данных в другую программу, в файл или в другое приложение по сети. В соответствии с современной терминологией, дескриптор представляет объект, а процедура write — метод, применяемый к этому объекту. Способ применения метода определяет объект.

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

4.6. Параметры и АРI-интерфейс сокетов

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

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

4.7. Процедуры, которые реализуют АРI-интерфейс сокетов

4.7.1. Процедура socket

Процедура socket создает сокет и возвращает целочисленный дескриптор:

descriptor = socket(protofamily, type, protocol)

Параметр protofamily указывает, какое семейство протоколов будет использоваться с сокетом. Чаще всего применяется идентификатор PF_INET, который определяет набор протоколов ТСР/IР.

Параметр type указывает тип связи, который будет использоваться в сокете. Наиболее распространенными типами являются потоковая передача с установлением логического соединения (которая задается значением SOСК_SТRЕАМ) и блочная передача без установления логического соединения (которая задается значением SOСК_DGRАМ).

Параметр protocol задает конкретный транспортный протокол, используемый с сокетом. Поскольку в этой процедуре предусмотрен не только параметр type, но и параметр protocol, она позволяет включить в один набор два или несколько протоколов, которые предоставляют одну и ту же службу. Безусловно, значения, которые могут использоваться для параметра protocol, зависят от семейства протоколов. Например, хотя набор протоколов ТСР/1Р включает протокол ТСР, набор AppleTalk его не включает.

4.7.2. Процедура close

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

close(socket)

Здесь параметр socket: представляет собой дескриптор закрываемого сокета. Ecли в сокете используется транспортный протокол с установлением логического соединения, то процедура close разрывает соединение, не закрывая сокета. Закрытие сокета приводит к немедленному прекращению его использования; дескриптор сокета уничтожается, приложение лишается возможности передавать дополнительные данные, а транспортный протокол перестает принимать входищие сообщения, направленные в сокет, что исключает для приложения возможность получать дополнительные данные.

4.7.3. Процедура bindЯ

Сразу после создания сокет не имеет ни локального, ни удаленного адреса. В сервере для задания_номера порта протокола, через который сервер будет принимать запросы на установление соединения используется процедура bind. Процедура bind принимает три параметра:

bind(socket, localaddr, addrlen)

Параметр socket представляет собой дескриптор сокета, который был создан, но еще не связан с помощью процедуры bind; вызов этой процедуры представляет собой запрос назначить сокету конкретный номер порта протокола. Параметр localaddr обозначает структуру, которая задает локальный адрес, присваиваемый сокету, а параметр addrlen — это целое число, которое указывает длину адреса. Сокеты могут использоваться с любыми протоколами, поэтому формат адреса зависит от применяемого протокола. АРI-интерфейс сокетов определяет универсальную форму, используемую для представления адреса, и требует, чтобы в каждом семействе протоколов был указан способ применения универсальной формы в протокольных адресах этого семейства.

Универсальная форма представления адреса определена в виде структуры sockaddr. Хотя бьло выпущено несколько версий АРI-интерфейса сокетов, в новеqшей версии кода Berkeley определена структура sockaddr, состоящая из трех полей: Я

struct sockaddr {

u_char sa_len; /* Общая длина адреса */

u_char sa_fanilly; /* Семейство адреса */

u_char sa_data [14]; /* Сам адрес */

};

Поле sa_len состоит из одного октета, который задает длину адреса. Поле sa_family определяет семейство протоколов, к которому принадлежит адрес (для адресов ТСР/IР применяется символическая константа АF_INET). И наконец, поле sa_data содержит адрес. Я

Каждое семейство протоколов определяет точный формат адресов, используемых в поле sa_data структуры sockaddr. Например, в протоколах ТСР/IР Для определения адреса применяется структура sockaddr_in:

struct sockaddr_in {

u_char sin_len; /* общая длина адреса */

u_char sin_fanilly; /* Семейство адреса */

u_short sin_port; /* Номер порта протокола */

struct in_addr sin_addr;___ /* IP-адрес компьютера */

char sin_zero [8]; /* Не используется (устанавливается

равным нулю) */

};

Первые два поля структуры sockaddr_in точно соответствуют первым двум полям универсальной структуры sockaddr,. Последние три поля определяют точную форму адреса, ожидаемого протоколами ТСР/IР. Здесь уместно сделать два замечания. Во-первых, каждый адрес обозначает и компьютер, и конкретное приложение на компьютере. Поле sin_addr содержит IР-адрес компьютера, а поле sin_port -номер порта протокола, используемого приложением. Во-вторых, хотя в наборе протоколов ТСР/IР требуется только шесть октетов для хранения полного адреса, в универсальной структуре sockaddr зарезервировано четырнадцать октетов. Поэтому последнее поле в структуре sockaddr_in определяет восьмиоктетное поле нулей, которое дополняет структуру до размера, какой имеет sockaddr.

Как уже было сказано, сервер вызывает процедуру bind для указания номера порта протокола, через который сервер будет принимать запросы на установление соединения. Однако кроме номера порта протокола, структура sockaddr_in содержит поле для IР-адреса. Хотя в серверной программе при задании адреса может быть решено заполнить поле IР-адрееа, это может вызвать проблемы, если хост многоадресный, поскольку будет означать, что сервер принимает только те запросы, которые переданы по одному конкретному адресу. Чтобы дать возможность эксплуатировать сервер на многоадресном хосте, АРI-интерфейс сокетов включает специальную символическую константу INADDR_ANY, которая позволяет серверу использовать конкретный порт с любым из IР-адресов компьютера.

4.7.4. Процедура listen

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

listen(socket, queuesize)

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

использования службы.

4.7.5. Процедура ассерt

Работа всех серверов начинается с вызова процедуры socket для создания сокета и процедуры bind для задания номера порта протокола. После выполнения этих двух вызовов сервер, в котором используется транспортный протокол без установления логического соединения, готов к принятию сообщений. Однако сервер, в котором используется транспортный протокол с установлением логического соединения, должен вызвать процедуру listen для перевода сокета в пассивный режим, после чего принимать входящие запросы на установление соединения с помощью процедуры ассерt. Приняв запрос на установление соединения, сервер может использовать соединение для обмена данными с клиентом. Завершив обмен данными, сервер закрывает соединение.

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

newsock = accept(socket, caddress, caddresslen)

Параметр socket представляет собой дескриптор сокета, созданный сервером и привязанный к конкретному порту протокола. Параметр caddress — это адрес структуры типа sockaddr, а параметр caddresslen — указатель на целое число. Процедура ассерt заполняет поля в параметре caddress значениями которые соответствуют адресу клиента, сформировавшего запрос на установление соединения, и устанавливает в параметре caddresslen :длину адреса. И наконец процедура ассерt создает новый сокет для соединения и возвращает дескриптор нового сокета вызывающей процедуре. Сервер использует новый сокет для обмена данными с клиентом и закрывает сокет после завершения работы. Первоначальный сокет сервера остается неизменным: после завершения обмена данными с клиентом, сервер использует первоначальный сокет для приема следующего запроса на установление соединения от клиента.

4.7.6. Процедура соnnесt

В клиентских программах для установления соединения с конкретным сервером применяется процедура соnnесt. Вызов этой процедуры имеет форму:

connect(socket, saddress, saddresslen)

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

При использовании в транспортном протоколе с установлением логического соединения, наподобие ТСР, процедура соnnеct инициализирует соединение транспортного уровня с указанным сервером. По сути дела, соnnесt — это процедура, используемая клиентом для передачи запроса на установление соединения серверу, который вызвал процедуру ассерt.

Любопытно отметить, что клиент, в котором используется транспортный протокол без установления логического соединения, также может вызвать процедуру соnnесt:. Однако это не приводит к инициализации соединения и передаче пакетов по объединенной сети. Процедура соnnесt просто отмечает сокет как подключенный и регистрирует его адрес.

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

4.7.7. Процедуры send, sendto и sendmsg

И клиенты, и серверы должны передавать информацию. Обычно клиент посылает запрос, а сервер возвращает ответ. Если сокет подключен, для передачи данных может применяться процедура send. Процедура send имеет четыре параметра:

send(socket, data, length, flags)

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

Процедуры sendto и sendnsg позволяют клиенту или серверу передавать сообщение с использованием неподключенного сокета; обе они требуют от вызывающей процедуры указывать адрес назначения. Процедура sendto принимает в качестве параметра адрес назначения. Она имеет следующую форму:

sendto(socket, data, length, flags, destaddress, addresslen)

Первые четыре параметра соответствуют четырем параметрам процедуры send. Последние два параметра задают адрес назначения и его длину. Адрес, задаваемый параметром destaddress, представляет собой структуру sockaddr, точнее, структуру sockaddr_in, при использовании с протоколами ТСР/IР).

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

sendmsg(socket, msgsrtuct, flags)

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

struct msgstruct { /* структура используемая в процедуре sendmsg */

struct sockaddr *m_saddr; /* Указатель на адрес назначения */

struct datavec *m_dvec; /* Указатель на сообщение (вектор) */

int m_dvlength; /* Число элементов в векторе */

struct access *mrigths; /* Указатель на список прав доступа */

int m_alength /* Число элементов в списке */

}

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

4.7.8. Процедуры recv, recvfrom и recvmsg

И клиент, и сервер должны получать данные, переданные другим участником соединения. В АРI-интерфейсе сокетов предусмотрено несколько процедур, которые могут использоваться для этой цели. Например, в; приложении может быть вызвана функция recv для получения данных из подключенного сокета. Эта процедура имеет следующую форму:

recv(socket, buffer, length, flags)

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

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

recvfrom(socket, buffer, length, flags, sndraddr, saddrlen)

Первые четыре параметра соответствуют параметрам процедуры recv; два дополнительных параметра sndraddr и saddrlen используются для регистрации IР-адреса отправителя. Параметр sndraddr представляет собой указатель на структуру sockaddr, в которой система записывает адрес отправителя, а параметр saddrlen задает указатель на целое число, применяемое системой для регистрации длины адреса. Процедура recvfrom регистрирует адрес отправители точно в такой же форме, в какой его принимает процедура sendto. Поэтому, если в приложении для получения входящего сообщения используется процедура rcvfrom, то передача ответа упрощается: в приложении можно просто воспользоваться зарегистрированным адресом как адресом назначения для ответа.

АРI-интерфейс сокетов включает процедуру ввода recvmsg, соответствующую процедуре вывода sendmsg. Процедура recvmsg функционирует аналогично процедуре recvfrom, но требует меньше параметров. Она имеет следующую форму:

recvmsg(socket, msgstruct, flags)

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

4.7.9. Чтение и запись с помощью сокетов

Как было описано выше, АРI-интерфейс сокетов был первоначально разработан для включения в состав операционной системы UNIX, в которой для выполнения операций ввода/вывода используются процедуры read и write. Поэтому сокеты также позволяют использовать в приложениях процедуры read и write для передачи данных. Как и процедуры send и recv, процедуры read и write не имеют параметров, которые позволяли бы указывать в вызывающей процедуре место назначения. Вместо этого в процедурах read и write имеются три параметра: дескриптор сокета, местонахождение буфера в памяти, используемого для хранения данных, и длина буфера. Поэтому процедуры read и write должны использоваться с подключенными сокетами.

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

4.7.10. Другие процедуры сокетов

АРI-интерфейс сокетов содержит и другие полезные процедуры. Например, после вызова сервером процедуры accept; для приёма входящего запроса на установление соединения сервер может вызвать процедуру getpeername для получения полного адреса удаленного клиента, который инициировал соединение. В клиентской или серверной программе можно также вызвать процедуру gethostname для зения информации о компьютере, на котором работает эта программа.

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

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

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

4.7.11. Сокеты, потоки и наследование

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

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

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

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

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

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


5. Архитектура WWW

В основе архитектуры WWW лежит модель «клиент-сервер». Эта модель базируется на двух взаимодействующих компонентах: клиенте и сервере. Клиент отвечает за взаимодействие и пользователем и посылает запросы серверу. Сервер обрабатывает запросы клиента.

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

5.1. Общие сведения о протоколе HTTP

HTTP (HyperText Transfer Protocol) — протокол прикладного уровня, разработанный для обмена гипертекстовой информацией в сети Internet, используется в Интернет с 1990 года. HTTP базируется на технологии «клиент-сервер». Запрашивающая программа (клиент) устанавливает соединение с сервисной программой (сервером) и посылает запрос (HTTP-запрос) серверу в следующей форме: request method, URL, protocol version, MIME-подобноесообщение, содержащее метаинформацию о запросе, информацию о клиенте и, возможно, тело сообщения.

Ответ сервера (HTTP-response) является сообщением, содержащим строку статусной информации о версии протокола и кода статуса (успех или ошибка) и MIME-подобное сообщение, содержащее информацию о сервере, метаинформацию о содержимом ответа и, возможно, тело ответа.

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

5.2. Формат HTTP-сообщения. 

Существует два различных HTTP-сообщения: запрос клиента и ответ сервера.

HTTP-message = HTTP-request | HTTP-response

Общая структура запросов и ответов сведущая:

General-Message = Start-Line

*( General-Message-Header CRLF)

CRLF[ Message-Body]

Start-Line = Request-Line | Status-Line

General-Message-Header = Field-Name ":" [ Field-Value ]

General-Message-Header = ( General-Header

Message-Header

Entity-Header )

Message-Header = Request-Header| Response-Header

Message-Body = Request-Entity | Response-Entity

Message-Body = *OCTET

Поле General-Header используется в HTTP-запросе и HTTP-ответе. Информация в этих полях применяется к передаваемому сообщению (но не к Message-Body):

General-Header = Cache-Control

| Connection

| Date

| Pragma

| Trailer

| Transfer-Encoding

| Upgrade

| Via

| Warning

Поле Entity-Header содержит необязательную метаинформацию о Entity-Request или Entity-Response. Entity-Header содержит информацию о запрошенном ресурсе, если отсутствует Message-Body (message – request или response).

Entity-Header = Allow

| Content-Encoding

| Content-Language

| Content-Length

| Content-Location

| Content-MD5

| Content-Range

| Content-Type

| Expires

| Last-Modified

| Extension-Header

Extension-Header = Field-Name “:” [Field-Value]

Ниже приводится смысл нескольких полей several Entity-Header.

Поле Allow entity-header перечисляет множество методов, поддерживаемых ресурсом, идентифицированным Request-URL. Целью этого поля является просто информировать получателя о правильных методах, ассоциированных с ресурсом. Поле Allow header должно присутствовать в ответе 405 (Method Not Allowed).

Формат:

Allow = "Allow" ":" #Method

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

Allow: GET, HEAD, PUT

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

Подполе Content-Length поля Entity-Header указывает размер entity-body в десятичном числе отктетов, посылаемых получателю или, в случае метода HEAD, размер entity-body, которое могло бы быть послано при запросе методом GET.

Формат:

Content-Length = "Content-Length" ":" 1*DIGIT

Пример:

Content-Length: 1234

Использование данного поля не обязательно, но рекомендуется использовать его для анализа размера передаваемого сообщения.

Поле Content-Type entity-header указывает тип entity-body, посылаемого получателю, или, в случае метода HEAD, тип медиа, которое могло бы быть послано при запросе методом GET.

Формат:

Content-Type = "Content-Type" ":" media-type

Типы медиа рассматриваются отдельно.

Пример:

Content-Type: text/html; charset=ISO-8859-4

Поле Content-Type не имеет значения по умолчанию.

Поле Last-Modified entity-header указывает дату и время, в которое документ был модифицирован в последний раз.

Если получатель имеет более старую копию ресурса, чем указано в поле, то копия рассматривается как просроченная.

Формат:

Last-Modified = "Last-Modified" ":" HTTP-date

Пример:

Last-Modified: Tue, 24 Jan 2001 13:00:06 GMT

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

Поле Message-Body ссылается на Request-Entity или Response-Entity. Если Message-Body существует, то оно посылается как HTTP/1.1 запрос или ответа форме и кодировке, которая определяется в Entity-Header: Message-Body = *OCTET (где OCTET - это любой 8-битовый символ)

5.3. Клиентский запрос Client Request 

Client Request - это сообщение, которое клиент посылает серверу. Сообщение запроса от клиента серверу включает в первой строке этого сообщения метод, применяемый к ресурсу, идентификатор ресурса и используемую версию протокола. Существует два типа HTTP-запросов для совместимости с протоколом HTTP/0.9:

Request = Little-Request | Full-Request

Little-Request = "GET" SP Requested-URL CRLF

Full-Request = Request-Line

*(( General-Header

Request-Header

Entity-Header ) CRLF)

CRLF

[ Request-Entity]

Если HTTP/1.0 – сервер получает Little-Request, он должен отвечать, используя HTTP/0.9 Little-Response. HTTP/1.0 - клиент способный обрабатывать Full-Response никогда не посылает Little-Request.

Поле Request-Line начинается с маркера метода, за которым следует Request-URI и версия протокола и который заканчивается CRLF. Элементы разделяются символами SP. Ни CR, ни LF не используются, за исключением в финальной последовательности CRLF.

Формат.

Request-Line = Method SP Requested-URL SP HTTP-Version CRLF

Request-Line является формой Little-Request источника, но в Request Line можно указать различные методы и после Requested-URL необходимо указать версию протокола. В качестве значения поля Method в настоящее время в WWW используются только три метода: POST, GET, HEAD

Метод GET – позволяет получать информацию определенную Request-URL. Существует два вида метода GET: GET и условный GET. Сервер отвечает на запрос только, если все условия выполнены. Условие указывается в поле “If-Modified-Since” заголовка Request-Header. Когда используется метод GET, запрашиваемая информация помещается в Message-Body (например HTML-документ).

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

Метод POST – этот метод был разработан для передачи большого количества информации серверу. Этот метод используется для посылки фрагментов данных одним блоком, например таких, как результаты заполнения форм обрабатывающему их процессу способом append. В отличие от GET и HEAD методов в методе POST тело передаваемого ресурса – это информация из полей формы или других вводимых ресурсов.

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

Поле request-header позволяет клиенту посылать дополнительную информацию о запросе и о самом клиенте серверу.

Request-Header = Accept

| Accept-Charset

| Accept-Encoding

| Accept-Language

| Authorization | Expect

| From | Host | If-Match

| If-Modified-Since

| If-None-Match | If-Range

| If-Unmodified-Since

| Max-Forwards

| Proxy-Authorization

| Range | Referer | TE

| User-Agent

Ниже приведено несколько наиболее значимых подполей поля Request-Header.

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

Синтаксис поля:

From = "From" ":" mailbox

Пример

From: example@w3.org

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

Значение If-Modified-Since используется с методом GET для того, чтобы сделать его условным: если запрашиваемый вариант не был модифицирован за указанное в этом поле время, сущность не будет передаваться от сервера, вместо этого будет возвращен ответ 304 (not modified) без тела-сообщения.

Формат.

If-Modified-Since = "If-Modified-Since" ":" HTTP-date

Пример

If-Modified-Since: Tue, 24 Jan 2001 13:00:06 GMT

Значение User-Agent содержит информацию о агенте-пользователе, инициировавшим запрос.

Формат

User-Agent = "User-Agent" ":" 1*( product | comment )

product = string[“/”product-version]

product-version = string

Пример

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

 

5.4. Ответ сервера Server Response

После того, как сервер получил и интерпретировал запрос, он посылает ответ в соответствии со следующей структурой:

Response = Little-Response |Full-Response

Little-Response = [ Response-Entity ]

Full-Response = Status-Line

*(( General-Header Response-Header Entity-Header) CRLF )

CRLF 

[ Response-Entity]

Первой строкой сообщения – ответа является строка Status-Line, состоящая из версии протокола, за которой следует код статута ответа и соответствующая ему фраза. Все элементы разделяются символом SP.

Формат:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Status-Line всегда начинается с верви протокола “HTTP/”1*DIGIT”.”1*DIGIT (например, HTTP/1.0). Эта часть строки рассматривается как основа для распознавания того есть ли это Little-Response или Full-Response.

Элемент Status-Code является трехзначным целым числом – кодом результата попытки распознавания и удовлетворения запроса. Эти коды полностью приведены ниже. Первая цифра кода Status-Code определяет класс ответа. Последние две цифры не имеют категорийной роли.. Есть пять значений первого числа:

1xx: Informational

Не используется, но получается в случае ошибки

2xх: Success

Запрос был успешно получен, понят и принят.

3xx: Redirection

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

4xx: Client Error

Запрос содержит синтаксическую ошибку или не может быть выполнен. Класс 4xx используется для случаев, когда ошибка произошла на стороне клиента. Если клиент еще не завершил запрос и получает ответ с кодом 4xx Status-Code, то он должен немедленно завершить передачу данных серверу.

5xx: Server Error

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

Индивидуальные значения кодов приведены ниже.

Status-Code =

"100" ; Continue

| "101" ; Switching Protocols

| "200" ; OK

| "201" ; Created

| "202" ; Accepted

| "203" ; Non-Authoritative Information

| "204" ; No Content

| "205" ; Reset Content

| "206" ; Partial Content

| "300" ; Multiple Choices

| "301" ; Moved Permanently

| "302" ; Found

| "303" ; See Other

| “304" ; Not Modified

| "305" ; Use Proxy

| "307" ; Temporary Redirect

| "400" ; Bad Request

| "401" ; Unauthorized

| "402" ; Payment Required

| "403" ; Forbidden

| "404" ; Not Found

| "405" ; Method Not Allowed

| "406" ; Not Acceptable

| "407" ; Proxy Authentication Required

| "408" ; Request Timeout

| "409" ; Conflict

| "410" ; Gone

| "411" ; Length Required

| "412" ; Precondition Failed

| "413" ; Request Entity Too Large

| "414" ; Request-URI Too Large

| "415" ; Unsupported Media Type

| "416" ; Requested range not satisfiable

| "417" ; Expectation Failed

| "500" ; Internal Server Error

| "501" ; Not Implemented

| "502" ; Bad Gateway

| "503" ; Service Unavailable

| "504" ; Gateway Timeout

| "505" ; HTTP Version not supported

Поле Reason-Phrase является коротким текстовым описанием Status-Code.

Формат поля:

Reason-Phrase = string *( SP string )

HTTP-приложения не должны интерпретировать эти коды. Однако, приложения должны понимать класс статуса кода и интерпретировать любой нераспознаваемый ответ как код класса x00.

Поле response-header позволяют серверу посылать дополнительную информацию об ответе, который не может быть приведен в строке Status-Line. Эти поля заголовка дают информацию о сервере и о дальнейшем доступе к ресурсам, идентифицированным Request-URL.

Response-Header = Accept-Ranges

| Age

| ETag

| Location

| Proxy-Authenticate

| Retry-After

| Server

| Vary 

| WWW-Authenticate

Если серверный Response-Header имеет поле Location, то это означает, что запрашиваемый ресурс находится по другому адресу и его надо запросить снова. Такие действия называются перенаправлением. Серверное имя и версия указываются в поле Server. В заголовке также вы можете найти поле WWW-Authenticate, которое определяет способ доступа к закрытым ресурсам.


6. Принципы гипертекстовой разметки. Структура документов HTML

6.1. Введение

Язык гипертекстовой разметки HTML (HyperText Markup Language) был предложен Тимом Бернерсом-Ли в 1989 году в качестве одного из компонентов технологии разработки распределенной гипертекстовой системы World Wide Web.

Когда Т. Бернерс-Ли предложил свою систему, в мире информационных технологий наблюдался повышенный интерес к новому и модному в то время направлению-гипертекстовым системам. Сама идея, но не термин, была введена В. Бушем в 1945 году в предложениях по созданию электромеханической информационной системы Меmех. Несмотря на то, что Буш был советником по науке президента Рузвельта, идея не была реализована. В 1965 году Т. Нельсон ввел в обращение сам термин "гипертекст", развил и даже реализовал некоторые идеи, связанные с работой с "нелинейными" текстами. В 1968 году изобретатель манипулятора "мышь" Д.Енжильбард продемонстрировал работу с системой, имеющей типичный гипертекстовый интерфейс, и, что интересно, проведена эта демонстрация была с использованием системы телекоммуникаций. Однако внятно описать свою систему он не смог. В 1975 году идея гипертекста нашла воплощение в информационной системе внутреннего распорядка атомного авианосца "Карл Винстон". Работы в этом направлении продолжались, и время от времени появлялись реализации типа НуреrСаrd фирмы Аррlе или НуреrNоdе фирмы Хеrох. В 1987 была проведена первая специализированная конференция Нуреrtехt'87, материалам которой был посвящен специальный выпуск журнала "Соmmunication АСМ".

Идея гипертекстовой информационной системы состоит в том, что пользователь имеет возможность просматривать документы (страницы текста) в том порядке, в котором ему это больше нравится, а не последовательно, как это принято при чтении книг. Поэтому Т.Нельсон и определил гипертекст как нелинейный текст. Достигается это путем создания специального механизма связи различных страниц текста при помощи гипертекстовых ссылок, т.е. у обычного текста есть ссылки типа "следующий-предыдущий", а у гипертекста можно построить еще сколь угодно много других ссылок. Любимыми примерами специалистов по гипертексту являются энциклопедии, Библия, системы типа "Неlр".

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

Разработчики HTML должны были решить две задачи:

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

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

К моменту создания HTML существовал стандарт языка разметки печатных документов SGML (Standard Generalised Markup Language), который и был взят в качестве основы HTML. Предполагалось, что такое решение поможет использовать существующее программное обеспечение для интерпретации нового языка. Однако, будучи доступным широкому кругу пользователей Internet, HTML зажил своей собственной жизнью. Вероятно, многие администраторы баз данных WWW и разработчики программного обеспечения для этой системы имеют довольно смутное представление о стандартном языке разметки SGML.

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

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

  1.  такой файл можно создать в любом текстовом редакторе на любой аппаратной платформе в среде любой операционной системы.
  2.  к моменту разработки HTML существовал американский стандарт для разработки сетевых информационных систем - Z39.50, в котором в качестве единицы хранения указывался простой текстовый файл в кодировке LATIN1, что соответствует US ASCII.

Таким образом, гипертекстовая база данных в концепции WWW - это набор текстовых файлов, размеченных на языке HTML, который определяет форму представления информации (разметка) и структуру связей этих файлов (гипертекстовые ссылки).

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

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

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

По сравнению с версией 2.0, HTML 3.2 позволяет реализовать отображение таблиц (контейнер <TABLE>...</TABLE>), выполнение мобильных кодов (<APPLET...>...</APPLET>), обтекание графики текстом, а также отображение верхних и нижних индексов (<SUP>...</SUP>; <SUB>...</SUB>).

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

  1.  разметка математических формул (HTML 3.0);
  2.  дополнительные контейнеры заголовка (HTML 3.0; Netscape Extensions; Microsoft Extensions);
  3.  дополнительные атрибуты стандартных контейнеров тела документа (ALIGN; BGCOLOR; TARGET и т.п.);
  4.  разбиение страницы на фреймы;
  5.  открытие дополнительных окон и др.

Сейчас World Wide Web Consortium (W3C) уже опубликовал рабочие материалы спецификации HTML 4.0. Кроме возможностей разметки текста, включения мультимедиа и формирования гипертекстовых связей уже существовавших в предыдущих версиях HTML, в версию 4.0 включены дополнительные средства работы с мультимедиа, языки программирования, таблицы стилей, упрощенные средства печати изображений и документов, которые становятся более доступными для всех пользователей HTML 4.0. Эти дополнения служат интернационализации WWW и распространению ее по всему миру. Кроме этого, для управления сценариями просмотра страниц Website (гипертекстовой базы данных, выполненной в технологии World Wide Web) можно использовать языки программирования этих сценариев типа JavaScript, Java и VBScript.

Прежде всего, рассмотрим структуру HTML-документов.

6.2. Принципы гипертекстовой разметки. Структура документов

За основу модели разметки документов в HTML принята таговая модель. Таговая модель описывает документ как совокупность контейнеров, каждый из которых начинается и заканчивается тагами. Т.е. документ НТМL представляет собой не что иное, как обычный АSСII-файл, с добавленными в него управляющими НТМL-кодами (тагами).

Таги НТМL-документов в большинстве своем просты для понимания и использования, ибо они образованы с помощью общеупотребительных слов английского языка, понятных сокращений и обозначений. НТМL-таг состоит из имени, за которым может следовать необязательный список атрибутов тага. Текст тага заключается в угловые скобки (< и >). Простейший вариант тага - имя, заключенное в угловые скобки, например <HEAD> или <i>. Для более сложных тагов характерно различие атрибутов, которые могут иметь конкретные значения, определенные автором для видоизменения функции тага.

Атрибуты тага следуют за именем и отделяются друг от друга одним или несколькими знаками табуляции, пробелами или символами возврата к началу строки. Порядок записи атрибутов в таге значения не имеет. Значение атрибута, если таковое имеется, следует за знаком равенства, стоящим после имени атрибута. Если значение атрибута - одно слово или число, то его можно просто указать после знака равенства, не выделяя дополнительно. Все остальные значения необходимо заключать в одинарные или двойные кавычки, особенно если они содержат несколько разделенных пробелами слов. Длина значения атрибута ограничена 1024 символами. Регистр символов в именах тагов и атрибутов не учитывается, чего нельзя сказать о значениях атрибутов. Например, особенно важно использовать нужный регистр при вводе URL других документов в качестве значения атрибута HREF.

Чаще всего НТМL-таги состоят из начального и конечного компонентов, между которыми размещаются текст и другие элементы документа. Имя конечного тага идентично имени начального, но перед именем конечного тага ставится косая черта (/) (например, для тага стиля шрифта - курсив <i> закрывающая пара представляет собой </i>, для тага заголовка <ТIТLЕ> закрывающей парой будет </ТIТLЕ>). Конечные таги никогда не содержат атрибутов. По своему значению таги близки к понятию скобок "begin/end" в универсальных языках программирования, которые задают области действия имен локальных переменных и т. п. Таги определяют область действия правил интерпретации текстовых тагов документа.

При использовании вложенных тагов в документе следует соблюдать особую аккуратность. Вложенные таги нужно закрывать, начиная с самого последнего и двигаясь к первому. Некоторые НТМL-таги не имеют конечного компонента, поскольку они являются автономными элементами. Например, таг изображения <IMG>, который служит для вставки в документ графического изображения, конечного компонента не требует. К автономным тагам также относятся разрыв строки (<BR>), горизонтальная линейка (<HR>) и таги, содержащие такую информацию о документе, которая не влияет на его отображаемое содержимое, например таги <META> и <BASE>.

В некоторых случаях конечные таги в документе можно опускать. Большинство броузеров реализованы так, что при обработке текста документа начальный таг воспринимается как конечный таг предыдущего. Самый распространенный таг такого типа - таг абзаца <Р>. Поскольку он используется в документе очень часто, то его обычно ставят только в начале каждого абзаца. Когда один абзац заканчивается, следуюший таг <Р> сигнализирует броузеру о том, что нужно завершить данный абзац и начать следующий. Большинство авторов тагом конца абзаца вообще не пользуются.

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

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

"контейнер" := <"имя тага" "список атрибутов">

содержание контейнера

</"имя тага">

6.2.1. Группы тагов НТМL 

Все таги НТМL по их назначению и области действия можно разделить на следующие основные группы

  1.  определяющие структуру документа;
  2.  оформление блоков гипертекста (параграфы, списки, таблицы, картинки);
  3.  гипертекстовые ссылки и закладки;
  4.  формы для организации диалога;
  5.  вызов программ.

Структура гипертекстовой сети задается гипертекстовыми ссылками. Гипертекстовая ссылка - это адрес другого HTML документа или информационного ресурса Internet, который тематически, логически или каким-либо другим способом связан с документом, в котором ссылка определена.

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

Этот текст содержит

 <A HREF="http://polyn.net.kiae.su/altai/index.html">

 гипертекстовую ссылку</A>

В приведенном выше примере таг "A", который в HTML называют якорем (anchor), использует атрибут "HREF", который обозначает гипертекстовую ссылку (Hypertext Reference), для записи этой ссылки в форме URL. Данная ссылка указывает на документ с именем "index.html" в директории "altai" на сервере "polyn.net.kiae.su", доступ к которому осуществляется по протоколу "http".

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

Структура HTML-документа позволяет использовать вложенные друг в друга контейнеры. Собственно, сам документ - это один большой контейнер который начинается с тага <HTML> и заканчивается тагом </HTML>:

<HTML> Содержание документа </HTML>

Контейнер HTML или гипертекстовый документ состоит из двух других вложенных контейнеров: заголовка документа (HEAD) и тела документа (BODY):

Рассмотрим простейший пример классического документа:

Пример 6.1

<HTML>

<HEAD>

<TITLE>Simple Document</TITLE>

</HEAD>

<BODY text=#0000ff BACKGROUND=#f0f0f0 >

 <H1>Пример простого документа</H1>

<HR>

Формы HTML-документов

<UL>

<LI>Классическая

<LI>Фреймовая

</UL>

<HR>

</BODY>

</HTML>

Рис. 6.1. Пример простого документа

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

Пример 6.2

<HTML>

<HEAD>

<TITLE>Frame Sample</TITLE>

</HEAD>

<FRAMESET COLS="30%,*">

<FRAME SRC=HTML-lecture.html NAME=LEFT>

<FRAME SRC=HTML-lec-1.html NAME=RIGHT>

 </FRAMESET>

</HTML>

Рис. 6.2. Пример документа с фреймами

6.2.2. Контейнеры HTML-документа

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

6.2.3. Контейнеры заголовка документа НТМL - HEAD

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

ТIТLЕ

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

ТIТLЕ имеет следующий синтаксис

<ТIТLЕ> Название документа </ТIТLЕ>

Содержание тага ТIТLЕ отображается в поле названия документа.

ВАSE

Таг ВАSЕ связан с формой представления гипертекстовой ссылки в форме URL. Дело в том, что спецификация URL определяет две формы адресации документов: полную и неполную. НТМL разрешает использовать как полную форму адреса URL, так и неполную. Но для того, чтобы использовать вторую форму спецификации, ее надо на чем-то базировать, т.е. задавать базовый адрес, который можно было бы использовать для формирования полной формы URL из неполной. Таг ВАSЕ позволяет определить эту базу. Так, например, если в заголовке будет задано:

 <BASE HREF="http://polyn.net.kiae.su/>,

гипертекстовая ссылка вида:

<A HREF="/altai/index.html">

будет расширена до

<A HREF= http://polyn.net.kiae.su/altai/index.html

Это же касается и других импортируемых в документ тагов. Графический образ, монтируемый в документ по команде:

 <IMG SRC="/gif/te t.gif">

будет найден по адресу:

<IMG SRC=' http://polyn.net.kiae.su/gif/test.gif'>

Содержание тага ВАSЕ интерфейсом пользователя прямо не отображается.

ISINDEX

Возможность поиска НТМL-документа по ключевым словам определяется тагом ISINDEX заголовка документа. В первоначальной версии языка данный таг не имел дополнительных атрибутов. Если сервер мог выполнить запрос по ключевым словам, то он автоматически вставлял в заголовок таг ISINDEX. Список ключевых слов приписывался клиентом к адресу документа после символа "?". Понятно, что выполнить запрос мог сервер, который при наличии символа "?" превращался в поисковую машину. НТМL-документ мог быть сгенерирован "на лету" программой, тогда ключевые слова после "?" приписываются к адресу этой программы. В новой версии языка появилась возможность указать программу обработки запроса и задать фразу вместо стандартной "SЕАRСН ISINDEX":

 <ISINDEX HREF="http://polyn.net.kiae.su/cgi-bin/search"

PROMPT="Enter Keywords:">

В приведенном примере атрибут НREF определяет адрес программы обработки запроса, а атрибут РRОМРТ - содержание приглашения. Справедливости ради стоит отметить, что полностью новые возможности этого тага выполняет только один - Аrеnа. Такие популярные интерфейсы, как Моsaic и Netscape, данный таг интерпретируют по-старому.

МЕТА

Таг МЕТА предназначен для определения в заголовке документа конструкций, отсутствующих в спецификации НТМL. Имеет три атрибута: NAME, CONTENT, HTTP-EQUIV. Применение данного тага затруднено тем, что для интерпретации конструкций, которые вводятся через этот таг, необходимо, чтобы сервер или интерфейс пользователя могли эти конструкции расшифровать и применить. Для такого сорта работы программа должна иметь интерпретировать конструкции SGML, что практически не реализовано ни в одной интерфейсной программе. Единственным способом применения данного тага на практике является включение в заголовок отклика по протоколу НТТР информации, определенной через атрибут НТТР-ЕQUIV:

 <META HTTP-EQUIV="Keywords" CONTENT="Plsma, Nuclear Physics">

При таком использовании в заголовок НТТР-пакета будет включена строка: Keywords: Plasma, Nuclear Physics, что удобно при отправке почты, например.

Наиболее эффектное применение контейнера МЕТА для построения демонстрационных роликов. В этом случае изменение отображаемой страницы строится на параметре Rеfresh (т.е. времени обновления документа). В заголовок документа записывается контейнер МЕТА следующего вида:

<meta http-equiv = "Refresh": content = "0, URL=next.html">

такое предложение равносильно появлению в заголовке сообщения протокола НТТР предложения вида:

 Refresh = 0; URL=next.html <LF>

В свою очередь это означает замену документа сразу же после загрузки его браузером. При этом в качестве нового документа используется документ из параметра URL.

6.2.4. Контейнеры тела документа НТМL - BODY

Таги тела документа

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

  1.  иерархических контейнеров и заставок;
  2.  заголовков (от Н1 до Н6);
  3.  блоков (параграфы, списки, формы, таблицы, картинки и т.п.);
  4.  горизонтальных отчеркиваний и адресов;
  5.  текста, разбитого на области действия стилей (подчеркивание, выделение, курсив),
  6.  математических описаний, графики и гипертекстовых ссылок.

ВОDY

Описание тагов тела документа следует начать с тага ВОDY. В отличии от тага НEАD, таг ВОDY имеет атрибуты:

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

LANG - определяет язык документа в виде двухсимвольного кода ISO-639, за которым следует через точку необязательный код страны в формате ISO-3166. По замыслу разработчиков стандарта языка данный атрибут должен распознаваться программами интерпретации и управлять отображением многоязычных текстов. Однако даже Аrеnа, специально предназначенная для иллюстрации НТМL 3.0, не реализует этой возможности.

СLASS - иерархически организованное имя типа "ADDITION.FIRST". Предназначено для связывания тага текста с определенным стилем отображения. Реально пока не используется.

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

ВАСКGROUND - определяет фон, на котором отображается текст документа. В примере НТМL-документа в качестве фона был использован небольшой графический образ "bgr.gif.

<ВОDY ВАСКGROUND="bgr.gif">

Как видно из этого примера, в качестве значения данного атрибута используется адрес в сокращенной форме URL. В данном случае это адрес локального файла.

Следует заметить, что разные интерфейсы пользователя поддерживают различные дополнительные атрибуты для тага ВОDY.

Атрибут

Значение

ВАСКCOLOR=#FFFFFF

Цвет фона

ТЕХТ=#0000FF

Цвет текста

VLINK=#FF0000

Цвет пройденных гипертекстовых ссылок

LINK=#00FF00

Цвет гипертекстовой ссылки

В данной таблице строка #ХХХХХХ определяет цвет в терминах RGB в шестнадцатеричной нотации. Так, цвет текста определен как синий, фона - белый, пройденные ссылки красные, а новые ссылки зеленые. Если в качестве атрибутов тага ВОDY указать:

<ВОDY ВАСКCOLOR=#FFFFFF ТЕХТ=#0000FF VLINK=#FF0000 LINK=#00FF00>

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

6.2.5. Таги управления разметкой

Заголовки

Заголовки обозначают начала разделов документа. В стандарте определено 6 уровней заголовков: от Н1 до Н6. Текст, окруженный тагами <Н1></Н1>, получается большим - это основной заголовок. Если текст окружен тагами <Н2></Н2>, то он выглядит несколько меньше (подзаголовок); текст внутри <НЗ></НЗ> еще меньше и так далее до <Н6></ Нб>. Некоторые программы, позволяют использовать большее число заголовков, однако реально более трех уровней встречается редко, а более 5 - крайне редко.

Стандарт языка насчитывает 11 атрибутов у тага заглавие. Рассмотрим только АLIGN, т.к. остальные в большинстве программ интерпретаторов не реализованы.

Для разбиения текста на параграфы используется таг <Р> в нем используются те же атрибуты что и заголовках.

В качестве примера рассмотрим создание домашней страницы фирмы по продаже бытовой электроники.

Пример 6.3

<HTML>

<HEAD>

<TITLE> Главная страница</TITLE>

</HEAD>

<BODY>

Компания.

Открытое акционерное общество Компания основанная в 1996 году,

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

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

Компания ищет агентов по сбыту бытовой электроники.

Контактная информация

Telephone (123) 123-34-56

FAX (123) 123-34-56

Почтовый адрес 123456 г. Город, ул Лесная, 106

Электронная почта

Общая информация: abc@abc.su

Продажи: abc@abc.abc.su

 Copyright © 1997 Компания

 </BODY>

</HTML>

Рис. 6.3. Пример текста без разметки

Броузер покажет нам этот HTML-документ в виде непрерывного текста.

Атрибут АLIGN.

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

Следующая таблица определяет возможные значения атрибута АLIGN:

Значение

Описание применения

Left

Выравнивание по левому краю

Right

Выравнивание по правому краю

Justify

Выравнивание по левому и правому краям

Сеnter

Центрирование

Значение Justify реализовано не во всех программах интерпретации.

Выравнивание по левому краю 

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

Выравнивание по правому краю 

Текст, выровненный по правому краю и не выровненный по левому - концы строк находятся на одном уровне, а начало на разных, - часто применяется на практике, хотя бы с целью создать оригинальный дизайн. Этот эффект достигается заданием атрибута АLIGN=RIGHT в обычных тагах, например в таге <Р>.

Центрирование текста и графики 

Есть несколько способов отцентрировать текст или графику. В спецификациях HTML 3.0 предлагается пользоваться тагом <АLIGN=СЕNТЕR>. Однако этот таг применим не для всех объектов HTML-страницы, поэтому Netscape добавил таг <СЕNТЕR>, который центрирует любые объекты и поддерживается броузерами Netscape Navigator, Microsoft Explorer и некоторыми другими. К тагу <СЕNТЕR> нужно относиться с осторожностью. Какой-нибудь броузер может его вообще проигнорировать, и на странице окажется выровненный по левому краю текст.

Оборачивание

С помощью атрибута ALIGN= вы можете <обернуть> текст вокруг графического объекта. Для этого поместите таг <IMG SRC="/путь/файл.gif"> в том месте, где должен быть графический объект, и добавьте атрибут ALIGN=LEFT, ALIGN=RIGHT или АLIGN=CENTER. Кроме того, с помощью атрибутов НSPAСЕ= и VSPАСЕ= (они описываются ниже ) задается ширина горизонтальных и вертикальных полей, отделяющих изображение от текста. Можно также создать рамку вокруг картинки или обрамление таблицы текстом.

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

Значение

Назначение

left

Пропустить картинку, расположенную у левого края листа

right

Пропустить картинку или таблицу, расположенную у правого края листа

аll

Прервать отображение текста перед картинкой или таблицей и продолжить ниже

В атрибуте СLEAR можно указать и численные значения:

<Р СLEAR="100 рiх">

Данная запись означает пустое горизонтальное поле высотой в 100 пиксельных строк.

Расставим таги заголовков с атрибутами в нашем примере.

Пример 6.4

<HTML>

<HEAD>

<TITLE> Главная страница</TITLE>

 </HEAD>

<BODY>

<H1 ALIGN=CENTER>Компания.</H1>

 <H3 ALIGN=LEFT>Открытое акционерное общество Компания основанная в 1996 году, является одним из ведущих поставщиков бытовой электроники в России. </H3>

<H4 ALIGN=RIGHT>Основными направлениями деятельности Компании являются: реализация бытовой электроники ведущих фирм мира через сеть ма-газинов; создание сервисных центров по обслуживанию бытовой электроники; </H4>

<H3> Компания ищет агентов по сбыту бытовой электроники.</H3>

<H5 ALIGN=CENTER>Контактная информация

Telephone (123) 123-34-56

FAX (123) 123-34-56

Почтовый адрес 123456 г. Город, ул Лесная, 106

Электронная почта

Общая информация: abc@abc.su

Продажи: abc@abc.abc.su

Copyright © 1997 Компания</H5>

</BODY>

</HTML>

Рис. 6.4. Текст с использованием тагов заголовков

Таг <ВR>

Принудительный перевод строки используется для того, чтобы нарушить стандартный порядок отображения текста. При обычном режиме интерпретации программа интерфейса пользователя отображает текст в рабочем окне, автоматически разбивая его на строки. В этом режиме существующие в тексте концы строк игнорируются. Иногда для большей выразительности требуется начать печать с новой строки. Для этой цели и используется таг ВR. Атрибут СLЕАR= в таге <ВR> используется для того, чтобы остановить в указанной вами точке обтекание текстом объекта и затем продолжить текст в пустой области за объектом. Продолжающийся за объектом текст выравнивается в соответствии со значениями LEFT, RIGHT или АLL атрибута СLЕАR=:

<BR СLЕАR =LЕFТ>

Текст будет продолжен, начиная с ближайшего пустого левого поля

<BR СLЕАR =RIGHT>

Текст будет продолжен, начиная с ближайшего пустого правого поля

<BR СLЕАR=АLL>

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

Таг <NOВR>

Таг <NОВR> (Nо Вrеаk, без обрыва) дает команду броузеру отображать весь текст в одной строке, не обрывая ее. Если текст, заключенный в таги <NОВR>, не поместится на экране, броузер добавит в нижней части окна документа горизонтальную полосу прокрутки. Если вы хотите оборвать строку в определенном месте, поставьте там таг <ВR>.

6.2.6. Таги управления отображением символов

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

6.2.7. Таги, управляющие формой отображения

Курсив, усиление, подчеркивание, верхний индекс, нижний индекс, шрифт большой, маленький, красный, синий, различные комбинации - все это делает страницы интереснее и функциональнее. Microsoft Internet Explorer и Netscape Navigator позволяют определить шрифт с помощью атрибута FАСЕ=. Теперь можно объединять на одной странице несколько видов шрифтов, вне зависимости от того, какой из них задан по умолчанию в броузере пользователя.

6.2.8. Верхние и нижние индексы [НТМL 3.0]

С помощью тагов <SUР> и <SUВ> можно задавать верхние и нижние индексы, необходимые для записи торговых знаков, символов копирайта, ссылок и сносок. Рассматриваемые таги позволяют создать внутри текстовой области верхние или нижние индексы любого размера. Чтобы они казались меньше окружающего текста, можно использовать таги <SUР> и <SUВ> с атрибутом FONT SIZE=. 

Атрибут SIZE=

Атрибут SIZЕ= тага <FОNТ> позволяет задавать размер текста в данной области. Если вы не пользуетесь тагом <ВАSЕFОNТ SIZЕ=n> для задания определенного размера шрифта на всей странице, то по умолчанию принимается 3.

Некоторые броузеры не поддерживают таг <FONТ>, поэтому желательно употреблять его только внутри текстовой области. В других случаях лучше использовать таги <Н1>, <Н2>, <НЗ> и т. д. Главное преимущество тага <FONТ> состоит в том, что он после окончания своего действия не разбивает строку, как таги <Нn>. Поэтому таг <FONТ> бывает очень полезен для изменения размера шрифта в середине строки. 

Таги <ВIG> и <SMALL>

Текст, расположенный между тагами <ВIG></ВIG> или <SMALL></SMALL>, будет соответственно больше 

Атрибут СОLОR=хх

Если вы хотите сделать свою страницу более красочной, то можете воспользоваться атрибутом СОLОR= в таге FONТ, и тогда единственным ограничением будет цветовая палитра на компьютере пользователя. Пока только самые популярные броузеры отображают цвет шрифта.

Пользоваться тагом <FONТ СОLОR=> для смены цвета шрифта, так же как и большинством тагов НТМL, очень просто. Заключите текст в таги <FONТ СОLОR= RED></FONТ>. 

6.2.9. Таги, управляющие формой отображения

Таг

Значение

<I>.....</I>

Курсив (Italic)

<B>...</B>

Усиление ВОLD)

<ТТ>... </TТ>

Телетайп

<U>. </U>

Подчеркивание

<S>...</S>

Перечеркнутый текст

< BIG >... </ BIG >

Увеличенный фонт

< SMALL >...</ SMALL >

Уменьшенный фонт

< SUB >...</ SUB >

Подстрочные символы

< SUP >... </ SUР >

Надстрочные символы

6.2.10. Таги, характеризующие тип информации

Таг

Значение

<ЕМ>... </ЕМ>

Типографское усиление

<СIТЕ>...</СIТЕ>

Цитирование

< STRONG >.</ STRONG >

Усиление

<СODE>... </СОDE>

Отображает примеры кода (например, коды программ)

<SАМР>... </SАМР>

Последовательность литералов

<КВD>... </КВD>

Пример ввода символов с клавиатуры -

<VAR>...</VAR>

Переменная

<DFN>... </DFN>

Определение

<Q>- </Q>

Текст, заключенный в скобки

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

Пример 6.5. Использование тагов, управляющих формой отображения.

 <HTML>

<HEAD>

<TITLE> Главная страница</TITLE>

</HEAD>

<BODY>

<H1 ALIGN=CENTER>Компания.</H1>

 <H3 ALIGN=LEFT><I>Открытое акционерное общество Компания осно-ванная в 1996 году, является одним из ведущих поставщиков бытовой электроники в России.</I></H3>

<H3 ALIGN=RIGHT><B>Основными направлениями деятельности Компании

являются</B>:

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

<H3><U> Компания ищет агентов по сбыту бытовой электроники.</U></H3>

<H5 ALIGN=CENTER><TT>Контактная информация</TT>

<DL>Telephone (123) 123-34-56

<DL>FAX (123) 123-34-56

<DL>Почтовый адрес 123456 г. Город, ул Лесная, 106

Электронная почта

<DL>Общая информация: abc@abc.su

<DL>Продажи: abc@abc.abc.su</DL>

 Copyright © 1997 Компания</H5>

</BODY>

</HTML>

Рис. 6.5. Таги отображения стилей текста

Таг <DL>

Использование тага списка (Definition List: <DL>) напоминает применение отступов в обычных текстовых редакторах. Таг <DL> был создан для форматирования текста, определяющего какой-то термин. Определяемый термин записывается на одной строке, а его определение на следующей, с небольшим отступом вправо. Таг <DL> позволяет создавать отдельные абзацы с отступом без нумерации или маркеров. Отступ делается от левого края. Если у вас на странице несколько тагов <DL>, то текст постепенно сдвигается все больше вправо. В конце определения поместите закрывающий таг </DL>. Помните, что таг <DL> сдвигает только левую границу абзаца.

Таг <ВLОСKQUOTE>

Таг добавляет поля слева и справа от текста. Это полезный таг, поскольку он позволяет расположить текст компактно в центре страницы. При использовании < ВLОСKQUOTE > несколько раз текст все больше сжимается к центру.

Microsoft Internet Explorer и Netscape Navigator допускают применение атрибутов LEFTMARGIN=n и ТОРМАRGIN =n в таге <ВОDY>. Атрибут LEFTMARGIN = задает левое поле для всей страницы. ТОРМАRGIN= определяет верхнее поле. Число n показывает ширину поля в пикселях. Например, таг < ВОDY LEFTMARGIN ="40"> создаст на всей странице левое поле шириной 40 пикселей. При n, равном 0, левое поле отсутствует.

6.2.11. Табуляция

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

Самый простой - записать таг <ТАВ IDENT=n>, где n определяет число еn-пробелов перед новым абзацем. Еn-пробел - это типографская единица измерения, приблизительно равная ширине буквы n в том шрифте, который вы используете. Таким образом, таг <ТАВ IDENT=4> задает символ табуляции шириной в четыре еn-пробела.

Если вы хотите в нескольких местах применить символ табуляции заданной величины, то в том месте, где вы задаете его размер, поместите таг <ТАВ> с атрибутом ID=, например, таким образом:

<ТАВ ID="tabone" >

Теперь в любом месте страницы достаточно написать <ТАВ ТО="ТАВОNЕ">, и символы табуляции станут равными ТАВОNЕ. Соответственно можно аналогичным образом создать ТАВТWО, ТАВТНRЕЕ, ТАВFОUR и т. д.

Чтобы создать более сложный дизайн, можно применить с тагом <ТАВ> атрибут ALIGN=. При задании АLIGN=LЕFТ или ALIGN=RIGHT текст, следующий за тагом <ТАВ> (вплоть до ближайшего обрыва строки или тага), будет выровнен по левому или правому краю соответственно. При задании АLIGN=СЕNTER текст центрируется относительно табулятора на задаваемое тагом <ТАВ> число еn-пробелов.

Таг <ТАВ> можно применять для размещения и текста, и графики.

6.2.12. Списки

Списки являются важным средством структурирования текста и применяются во всех языках разметки. В НТМL имеются следующие виды списков: ненумерованный список (неупорядоченный), нумерованный список (упорядоченный) и список определений. Таги для ненумерованных (Unordered Lists <UL>) и нумерованных списков (Ordered Lists <OL>) - это основа HTML. HTML 3.0 добавляет несколько атрибутов к тагам списков для выбора разных типов маркеров в ненумерованных списках и разных схем нумерации в нумерованных. Можно включать такие атрибуты в сами таги <LI> (List Item), чтобы сменить тип маркера в середине списка. После появления нового атрибута все последующие маркеры в списке будут иметь такой же вид.

Таг <UL>

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

  1.  первый элемент списка
  2.  второй элемент списка
  3.  третий элемент списка

Записывается данный список в виде следующей последовательности:

<UL>

<LI> первый элемент списка

<LI> второй элемент списка

<LI> третий элемент списка

</UL>

Таги <UL> и </UL> - это таги начала и конца ненумерованного списка, таг <LI> (List Item) задает таг элемента списка. В дополнение к этим тагам существует таг, позволяющий именовать списки - LН (List Header). Приведем пример отображения ненумерованного списка следующего вида:

6.2.13. Атрибуты маркеров в ненумерованном списке 

Если вы не желаете применять одни и те же маркеры на разных уровнях вложенности, то используйте атрибут ТYРЕ=. Вы можете задать любой тип маркера в произвольном месте списка. Можно даже смешивать разные типы маркеров в одном списке. Ниже перечислены таги с атрибутами стандартных маркеров

<UL TYPE =DISK> Таг создает сплошные маркеры такого типа, как в списках первого уровня по умолчанию <UL TYPE =CIRCLE> Таг создает маркеры в виде окружностей <UL TYPE =SQUARE> Таг создает сплошные квадратные маркеры 

В HTML 3.0 вы можете вместо обычного маркера поместить GIF или специальный символ.

Атрибут РLАN= 

Атрибут РLAN= создает ненумерованные списки без маркеров. Разумеется, простейший способ это сделать - воспользоваться списком определений, но если вы все же захотите вставить в список один-два маркера, то лучше применяйте данный атрибут.

Атрибут SRС= 

Атрибут SRС= используется для того, чтобы задать GIF-файл вместо обычного маркера GIF, наиболее употребительный в HTML графический формат. Вместо того чтобы помещать GIF перед строкой с тегом <ВR> в конце, вы можете создать собственные изящные маркеры и затем использовать их в списке. В этом случае вы получите все преимущества ненумерованного списка и вдобавок симпатичные GIF-картинки в качестве маркеров. Атрибут SRC= можно задать в таге <UL>, определив сразу все маркеры списка, а можно указать разные GIF для разных пунктов списка, помещая атрибут SRC= в каждом таге <LI>. В любом случае для того чтобы атрибут SRС= работал с тагом <UL>, нужно задать атрибут РLAN=.

Атрибут SRС= для тагов списков очень нужен Web-разработчикам и способен сделать ваши страницы чрезвычайно привлекательными. Вместе с тем, его некорректное употребление приводит к исключительно уродливым страницам.

Атрибут DINGВАТ= [НТМL 3.0] 

Атрибут DINGВАТ= позволяет создавать специальные типографские символы dingbats, поддерживаемые броузером. Эти символы имеют вид картинок, которые используются в качестве маркеров в списках. Приведем список стандартных dingbats:

Text, Audio, Folder, Disc drive, Form, Home, Next.

Для задания dingsbat нужно указать его имя в таге <LI>. Например, для того чтобы задать home (домик), записывайте таг <LI DINGBAT="home" >.

Dingsbat можно также применять с тагом заголовка.

Таг <OL>

Нумерованные списки. Таг <OL> вместе с атрибутом ТYРЕ= в HTML 3.0 позволяет создать нумерованные списки, используя в качестве номеров не только обычные числа, но и строчные и прописные буквы, а также строчные и прописные римские цифры. При необходимости можно даже смешивать эти типы нумерации в одном списке.

<ОL ТYРЕ=1> Таг создает список с нумерацией в формате 1., 2., 3., 4. и т. д. <ОL ТYРЕ=A> Таг создает список с нумерацией в формате А., В., С., В. и т. д. <ОL ТYРЕ=a> Таг создает список с нумерацией в формате а., b., с., d. и т. д. <ОL ТYРЕ=I> Таг создает список с нумерацией в формате I., II., III., IV. и т. д.

Пример 6.6. Использования тагов различных списков.

 <HTML>

<HEAD>

<TITLE> Главная страница</TITLE>

</HEAD>

<BODY>

<H1 ALIGN=CENTER>Компания.</H1>

 <HR>

<H3 ALIGN=LEFT><I>Открытое акционерное общество Компания осно-ванная в

1996 году, является одним из ведущих поставщиков бытовой электроники в

России.</I></H3>

<HR>

<H3>Основными направлениями деятельности Компании являются:

<OL>

<LI>реализация бытовой электроники ведущих фирм мира через сеть магазинов;

<LI>создание сервисных центров по обслуживанию бытовой

электроники.</H3>

</OL>

<HR>

<H3><U><FONT COLOR=RED> Компания ищет агентов по сбыту бытовой

электроники.</FONT></U></H3>

<H5 ALIGN=CENTER>Контактная информация</H5>

 <UL>

<LI>Telephone (123) 12-34-56

<LI>FAX (123) 12-34-56

 <LI>Почтовый адрес 123456 г. Город, ул Лесная, 106

<UL TIPE=CIRCLE>Электронная почта<BR>

<LI>Общая информация: abc@abc.su

<LI>Продажи: abc@abc.abc.su</UL></UL>

 <BR><BLINK>Copyright</BLINK> © 1997 Компания

</BODY>

 </HTML>

Рис. 6.6. Использования тагов различных списков

Таг <НR>

Горизонтальное отчеркивание (horizontal rule) применяется для разделения документа на части. С помощью одного лишь тага <НR> можно придать странице совершенно необычный вид. Попробуйте поэкспериментировать с тагом <НR>и вы получите линии, совсем не похожие на те, которыми вы обычно пользуетесь.

Таг <РRЕ>

Отображение текста без форматирования.

Таг <BLINK>

Таг <BLINK> вызывает мерцание текста заключенного в него.

6.2.14. Гипертекстовые ссылки 

Все рассмотренные выше средства управления отображением текста являются безусловно важными, но только дополнительными к основному тагу документа - гипертекстовой ссылке. Для записи гипертекстовой ссылки используется контейнер <А...>......</А>, который называют "якорь" (аnchor). Якорь имеет несколько атрибутов, главным из которых является НREF (НуреrТехt Reference). Простую ссылку можно записать в виде:

<А НREF="http://роlyn.net.kiae.su/index.html">Индекс базы данных "Полынь" </А>

где значением атрибута HREF является адрес документа " index.html " на машине " роlyn.net.kiae.su ", доступ к которой осуществляется по протоколу НТТР. Форма записи этого адреса называется универсальным локатором ресурсов (Universe Resource Locator) и является составной частью технологии WWW.

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

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

Рассмотрим это на примере.

Одним из типичных приемов создания Web-сервера фирмы является представление на первой страницы перечня основных частей, в которые входят: Новости, Товары, Услуги, Контакты, Поиск.

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

Пример 6.7

<HTML>

<HEAD>

<TITLE> Главная страница</TITLE>

 </HEAD>

<BODY>

<H1 ALIGN=CENTER>Компания.</H1>

 <HR>

<H3 ALIGN=LEFT><I>Открытое акционерное общество Компания основанная в

1996 году, является одним из ведущих поставщиков бытовой электроники в России.</I></H3>

 <HR>

<p ALIGN=CENTER><font color="#400040" size="4">[ <a

href="news.html">Новости</a> |<a href="products.html">Товары</a> |

<a href="servis.html">Услуги</a> | <a href="contact.html">

 Контакты</a> | <a href="search.htm">Поиск</a> ] </font>

 <HR>

<H3>Основными направлениями деятельности Компании являются:

<OL>

<LI>реализация бытовой электроники ведущих фирм мира через сеть магазинов;

<LI>создание сервисных центров по обслуживанию бытовой электроники.</H3>

</OL>

<HR>

<H3><U><FONT COLOR=RED> Компания ищет агентов по сбыту бытовой

электроники.</FONT></U></H3>

<H5 ALIGN=CENTER>Контактная информация</H5>

 <UL>

<LI>Telephone (123) 12-34-56

<LI>FAX (123) 12-34-56

 <LI>Почтовый адрес 123456 г. Город, ул Лесная, 106

<UL TIPE=CIRCLE>Электронная почта

<LI>Общая информация: abc@abc.su

<LI>Продажи: abc@abc.abc.su</UL></UL>

 <BR><BLINK>Copyright</BLINK> © 1997 Компания

</BODY>

 </HTML>

На экране это будет выглядеть следующим образом. При нажатии на ссылку "Товары" в окно броузера будет загружен новый документ.

Рис. 6.7. Гипертекстовые ссылки

Рис. 6.8. Новый документ

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

<А NАМЕ= роint">

Для ссылки на такую точку используют следующую форму URL:

<А НREF=" http://роlyn.net.kiae.su/index.html #роint">

Ссылка на точку "роint" в документе "index.html"</А>

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

 

6.2.15. Графика

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

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

  1.  логотип компании на деловой странице;
  2.  графика для рекламного объявления;
  3.  различные рисунки;
  4.  диаграммы и графики;
  5.  художественные шрифты;
  6.  подпись автора страницы;
  7.  применение графической строки в качестве горизонтальной разделительной линии;
  8.  применение графических маркеров для создания красивых маркированных списков.

Теперь рассмотрим как вставить изображение в страницу Web. Тагом НТМL, который заставляет броузер выводить изображение, является <IMG> со следующим общим форматом:

 <IMG SRC="picture.gif">

Пример 6.8

<HTML>

<HEAD>

<TITLE> Товары</TITLE>

</HEAD>

<BODY>

<H1 ALIGN=CENTER>Компания.</H1>

<HR>

<p ALIGN=CENTER><font color="#400040" size="4">

[ <a href="news.html">Новости</a> |

<a href="products.html">Товары</a> |

<a href="servis.html">Услуги</a> |

<a href="contact.html">Контакты</a> |

<a href="search.htm">Поиск</a> ] </font>

<HR>

<H3 ALIGN=CENTER> Телевизор

<BR>СS-7272РТR/ 6272РТR </H3>

<br><img src="cs727.jpg" align=left hspace=20 vspace=20 ALT="Телевизор">

 <UL>

<LI>Суперплоский кинескоп с диагональю 29/25 дюймов (72/62 см)

<LI>Биокерамическое покрытие кинескопа

<LI>Мультисистемный (РАL/SЕСАМ/NTSC)

<LI>Звуковая мощность 2х30 Вт МРО

<LI>Стерео (А2)

<LI>Усилитель слабого сигнала (LNА)

<LI>Функция "Картинка в картинке"

<LI>Возможность настройки на 100 каналов

<LI>Русский телетекст

<LI>Экранное меню на нескольких языках

<LI>Таймер включения/выключения

<LI>Замок от детей

<LI>Режим демонстрации

</UL>

<HR>

<H3 ALIGN=CENTER>Контактная информация</H3>

 <UL>

<LI>Telephone (123) 12-34-56

<LI>FAX (123) 12-34-56

<LI>Почтовый адрес 123456 г. Город, ул Лесная, 106

<UL TIPE=CIRCLE>Электронная почта

<BR><LI>Общая информация: abc@abc.su

<LI>Продажи: abc@abc.abc.su

 </UL>

</UL>

<BR>

<BLINK>Copyright</BLINK> © 1997 Компания

</BODY>

 </HTML>

Рис. 6.9. Вставленное в текст изображение

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

Изображения на странице Web могут быть использованы и в качестве гипертекстовых ссылок, как и обычный текст. Читатель страницы щелкает на изображении и отправляется на другую страницу или изображение. Для обозначения изображения как гипертекстовой метки используется тот же таг <А>, что и для текста, но между <А> и </А> вставляется таг изображения <IMG>:

<А НREF="адрес файла или изображения"><IMG SRC="picture.gif"></А>

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

Ограничивающие прямоугольники и атрибуты АLТ=

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

Как задать размеры графики

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

 <IMG SRC="picture.gif" WIDTH=413 НЕIGНТ=356>

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

Атрибут АLТ= 

Атрибут АLТ= тага IMG позволяет пользователям, броузеры которых смотрят только текст (или если в броузере отключен режим графики), получить представление о том, что за графика расположена на странице или каковы ее цели. Micrisoft Internet Explorer показывает текст из атрибута АLТ= в ограничивающем прямоугольнике, пока изображение загружается. Netscape Navigator выводит этот текст в том случае, если режим Auto Load Image выключен.

Таг <IMG> с атрибутом АLТ= будет выглядеть следующим образом:

<IMG SRC="pic.gif " НЕIGHТ=50 WIDTH=100 АLТ="Picture">

Активные изображения

Активные изображения (image maps), или изображения, чувствующие щелчки мыши, позволят вам создать на своем узле графические меню произвольной формы. Пользуясь таким меню, читатели смогут путешествовать по всем закоулкам и проспектам вашего Web-узла. Активное изображение - это просто картинка с так называемыми активными областями (hot spots), которые ссылаются на URL других страниц или узлов. Работает такое изображение следующим образом: когда пользователь щелкает мышкой на картинке, определенной как активное изображение с помощью атрибута ISМАР в таге IMG, координаты щелчка передаются на Web-сервер. Сервер ищет в карте (mapfile) активную область, содержащую переданные координаты. Если такая область находится, заданный в карте URL активируется, и броузер пользователя переходит на новую страницу.

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

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

Где помещать активное изображение: на сервере или у клиента?

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

Активные изображения, работающие у клиента, имеют несколько преимуществ. Во-первых, страницы с ними можно перенести на другой сервер. Во-вторых, серверу не приходится выполнять лишнюю работу (например, просматривать всю информацию об активных областях), то есть нагрузка на сервер уменьшается. При использовании работающих на сервере активных изображений в каталоге сgi-bin сервера должен быть соответствующий сценарий. По соображениям безопасности многие системные администраторы не любят разрешать людям толпиться вокруг сервера, записывая сценарии в каталог сgi-bin. Если вы арендуете сервер или просто используете место на чьем-то чужом сервере, вам, возможно, придется кого-то долго обхаживать, пока удастся записать сценарии. Недостаток активных изображений, работающих на клиентской машине, состоит в том, что обращаться с ними умеют только броузеры, поддерживающие HTML 3.0. Если у пользователя другой броузер, на вашей странице появится обычное графическое изображение, не чувствующее мышь. Так что у вас есть три возможности: сделать активное изображение на стороне клиента, что может отвратить от вас инертных людей, не спешащих менять свои броузеры; поместить его на сервере, и тогда им смогут воспользоваться практически все; применить оба вида изображений на одной странице. Последний вариант, видимо, наилучший, потому что вы попрактикуетесь в новейших средствах НТМ~ 3.0, и в то же время ваши страницы будут доступны для просмотра старыми броузерами.

Как сделать активное изображение

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

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

Границы активных областей задаются координатами углов прямоугольника и многоугольника или центра и радиуса круга. Эти параметры записываются в карту (МАР-файл)

Закончив создание активного изображения, вы можете сохранить полученный файл в формате NCSA или СЕRN, если оно будет работать на сервере, или в формате СSIМ, если оно функционирует на клиентской машине. Всю остальную работу выполняет программа МарEdit. Она создает карту на сервере или встраивает карту на стороне клиента в указанный вами файл HTML. Если вы решили делать активное изображение у клиента, Мар Edit поставляет данные только для тагов <МАР>. Вам придется самому задать таг изображения с атрибутом USЕМАР и поместить его после тага </МАР>. Не забудьте перед именем карты в атрибуте USЕМАР записать символ # следующим образом:

 <IMG SRC="mymap.gif " USЕМАР="#sitemap">

Как поместить активное изображение на НТМL-страницу

Когда изображение стало активным и для каждой активной области определен URL, его нужно поместить на HTML-страницу. Это можно сделать несколькими способами, в зависимости от того, какое изображение вы делаете: на сервере или у клиента.

Активные изображения на сервере

Старый испытанный способ создания активных изображений (для HTML 2.0) требует использования атрибута ISМАР в таге IMG. Таг IMG относится к изображению, и его надо поместить между начальным и конечным тагами ссылки на файл-карту. Вам нужно занести в HTML-файл приблизительно такую строку:

<А НREF="path/somemap.map"><IMG SRC="path/somemap.map" ISМАР></А>

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

 http:/www.my.com/path/somemap.map?300,20

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

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

 http:/www.my.com/cgi-bin/imagemap/path/somemap.map?300,20

В данном случае сервер для обработки активного изображения используется программой под названием imagemap, находящейся в каталоге сgi-bin. Чтобы ваши изображения заработали, вам придется выяснить у своего системного администратора, что в точности нужно серверу. В зависимости от программного обеспечения сервера запись об активных изображениях в НТМL-файле будет выглядеть либо так:

 <А НREF="somemap.map">

<IMG SRC="somemap.gif" ISМАР>

</А>,

либо так 

<А НREF="sgi-bin/imagemap/somemap.map">

<IMG SRC="somemap.gif" IS-МАР></А>,

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

Активные изображения у клиента

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

Пример 6.9

<HTML>

<HEAD>

<TITLE> Товары</TITLE>

</HEAD>

<BODY>

<H1 ALIGN="CENTER">Компания.</H1>

<HR>

<p ALIGN="CENTER"><font color="#400040" size="4">[

<a href="news.html">Новости</a> |

<a href="products.html">Товары</a> |

<a href="servis.html">Услуги</a> |

<a href="contact.html">Контакты</a> |

<a href="search.htm">Поиск</a> ] </font>

 <HR>

<H3 ALIGN=CENTER>Виды бытовой электроники предлагаемые Компани-ей </H3>

 <IMG SRC="catal2.jpg" usemap="#catal2" ALIGN=MIDDLE>

<map name="catal2">

<area shape="rect" coords="8,5,128,134" href="tv.html">

<area shape="default" nohref>

</map>

 <HR>

<H3 ALIGN="CENTER">Контактная информация</H3>

 <UL>

<LI>Telephone (123) 12-34-56

<LI>FAX (123) 12-34-56

 <LI>Почтовый адрес 123456 г. Город, ул Лесная, 106

<UL TIPE="CIRCLE">Электронная почта<BR>

<LI>Общая информация: abc@abc.su

<LI>Продажи: abc@abc.abc.su

 </UL>

</UL>

<BR><BLINK>Copyright</BLINK> © 1997 Компания

 </BODY>

</HTML>

Рис. 6.10. Пример активного изображения

Имейте в виду, что если опустить атрибут SНАРЕ=, будет задано SНАРЕ="RЕСТ". Атрибут СООRDS= описывает координаты формы, используя пиксели в качестве единиц измерения. Атрибут USЕМАР= в таге <IMG> действует как ссылка <переход на>. Если перед именем файла карты помещен символ #, то атрибут USЕМАР= считает, что активное изображение находится в файле, описанном в таге <IMG>. Не пугайтесь координат. Точкой отсчета является левый верхний угол.

Активные изображения, работающие и на сервере, и у клиента

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

После того, как вы создадите активные изображения на сервере и у клиента, соединить их в один HTML-файл нетрудно. Для этого нужно внести в документ HTML ту же запись, которую вы сделали бы для активного изображения на сервере. Не забудьте только добавить в таг IMG атрибут USЕМАР=. Атрибут USЕМАР= имеет более высокий приоритет, чем таг ISМАР, и если броузер поддерживает активные изображения, работающие у клиента, он распознает этот атрибут. Броузер, не знающий о таких изображениях, проигнорирует атрибут USЕМАР=.

Изображения в миниатюре

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

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

6.3. Средства описания таблиц в HTML

По мере роста системы WWW стало ясно, что средств, которые заложены в НТМL, не достаточно для качественного отображения различного типа документов. Недостатком НТМL было отсутствие в его составе средств отображения таблиц. Для этой цели обычно использовался предформатированный текст (таг <PRE>), в котором таблица обрисовывалась символами АSСII. Но такая форма представления таблиц была недостаточно высокого качества и выделялась из общего стиля документа.

Таг <ТАВLЕ>

Для описания таблиц служит таг <ТАВLЕ>. Таг <ТАВLЕ>, как и многие другие, автоматически переводит строку до и после таблицы.

Таг <ТR>

Таг <ТR> (сокращение от Таble Row - строка таблицы) создает строку таблицы. Если в таблице содержится два набора тагов <ТR></ТR>, в ней будут две строки. Весь текст, другие таги и атрибуты, которые вы хотите поместить в одну строку, должны быть помещены между тагами <ТR></ТR>.

Пример 6.10

<HTML>

<BODY>

<H1 ALIGN=CENTER>Таблица</H1>

 <CENTER>

<TABLE BORDER>

<TR>

<TD COLSPAN=3>Если в таблице два тага <TR> то в ней две строки.</TD>

</TR>

<TR>

<TD>Если в стоке три тага <TD> </TD>

<TD>то в ней </TD>

<TD>три столбца.</TD>

</TR>

 </TABLE>

</CENTER>

</BODY>

</HTML>

Таг <ТD>

Внутри строки таблицы обычно размещаются ячейки с данными, Каждая ячейка, содержащая текст или изображение, должна быть окружена тагами <ТD></ТD>. Число тагов <ТD></ТD> в строке определяет число ячеек. Строка с пятью парами тагов <ТD></ТD> будет состоять из пяти ячеек.

Пример 6.11

HTML>

<BODY>

<TABLE BORDER>

 <TR>

<TD>В</TD>

<TD>этой</TD>

<TD>строке</TD>

<TD>пять</TD>

<TD>столбцов</TD>

</TR>

<TR>

<TD>а в этой</TD>

<TD>только</TD>

<TD>три.</TD>

 </TR>

</TABLE>

</BODY>

</HTML>

Таг <ТН>

При задании заголовков для столбцов и строк таблицы используются таг заголовка <ТН></ТН> (Таblе Неаder, заголовок таблицы). Эти таги аналогичны <ТD></ТD>. Отличие состоит в том, что текст, заключенный между тагами <ТН></ТН>, автоматически записывается жирным шрифтом и по умолчанию располагается посередине ячейки. Центрирование можно отменить и выровнять текст по левому или правому краю. Если воспользоваться <ТD></ТD> с тагом <В> и атрибутом <АLIGN=CENTER>, текст тоже будет выглядеть как заголовок. Однако, следует иметь в виду, что не все броузеры поддерживают жирный шрифт в таблицах, поэтому лучше задавать заголовки таблиц с помощью <ТН>.

Пример 6.12

<HTML>

<BODY>

<TABLE BORDER>

<TR>

<TH>Заголовок центрирован по умолчанию</TH>

<TH COLSPAN=2>Заголовок может объединять столбцы</TH>

</TR>

<TR>

<TH>Заголовок может быть расположен перед столбцами</TH>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

</TR>

<TR>

<TH ROWSPAN=3> Заголовок может объединять строки</TH>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

</TR>

<TR>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

</TR>

<TR>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

 </TR>

</TABLE>

</BODY>

</HTML>

Таг <САРТIОN>

<CAPTION> позволяет создавать заголовки таблицы. По умолчанию заголовки центрируются и размещаются либо над (<САРТION АLIGN=ТОР>), либо под таблицей (<САРТION ALIGN=ВОТТОМ>). Заголовок может состоять из любого текста и изображений. Текст будет разбит на строки, соответствующие ширине таблицы. Иногда таг <САРТION> используется для подписи под рисунком. Для этого достаточно описать таблицу без границ.

Заголовок может состоять из любого текста и изображений. Текст будет разбит на строки, соответствующие ширине таблицы. Иногда таг <САРТION> используется для подписи под рисунком. Для этого достаточно описать таблицу без границ.

Пример 6.13

<HTML>

<BODY>

<TABLE BORDER>

<CAPTION ALIGN=TOP>Заголовок над таблицей</CAPTION>

<TR>

 <TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

 </TR>

</TABLE>

<TABLE BORDER>

<CAPTION ALIGN=BOTTOM>Заголовок под таблицей</CAPTION>

 <TR>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

 </TR>

</TABLE>

</BODY>

</HTML>

Атрибут NOWRAP 

Обычно любой текст в таблице, не помещающийся в одну строку ячейки, переходит на следующую строку. Однако, при использовании атрибута NOWARP с тагами <ТН> или <ТD> длина ячейки расширяется на столько, чтобы, заключенный в ней текст поместился в одну строку.

Атрибут СОLSPAN=

Таги <ТD> и <ТН> модифицируются с помощью атрибута СОLSPAN= (Column Span, соединение столбцов). Если вы хотите сделать какую-нибудь ячейку шире, чем верхняя или нижняя, можно воспользоваться атрибутом СОLSPAN=, чтобы растянуть ее над любым количеством обычных ячеек.

Пример 6.14

<HTML>

<BODY>

<CENTER>

<TABLE BORDER=3>

 <TR>

<TD>

Если вы хотите сделать какую-нибудь ячейку шире, чем верхняя или нижняя,

</TD>

<TD>

можно воспользоваться атрибутом СОLSPAN=,

 </TD>

</TR>

<TR>

<TD BGCOLOR=WHITE COLSPAN=2>

 чтобы растянуть ее над любым количеством обычных ячеек.

 </TD>

</TR>

</TABLE>

</CENTER>

</BODY>

 </HTML>

Атрибут ROWSPAN= 

Атрибут ROWSPAN=, используемый в тагах <ТD> и <ТН>, аналогичен атрибуту СОLSPAN=, только он задает число строк, на которые растягивается ячейка. Если вы указали в атрибуте ROWSPAN= число, большее единицы, то соответствующее количество строк должно находиться под растягиваемой ячейкой. Нельзя поместить ее внизу таблицы.

Атрибут WIDТН=

Атрибут WIDТН= применяется в двух случаях. Можно поместить его в таг <ТАВLЕ> для задания ширины всей таблицы, а можно использовать в тагах <ТR> или <ТН> для задания ширины ячейки или группы ячеек. Ширину можно указывать в пикселях или в процентах. Например, если вы задали в таге <ТАВLЕ> WIDTH=250, вы получите таблицу шириной 250 пикселей независимо от размера страницы на мониторе. При задании WIDТН=50% в таге <ТАВLЕ> таблица будет занимать половину ширины страницы при любом размере изображения на экране. Так что, указывая ширину таблицы в пикселях имейте в виду, что если у вашего читателя узкая область просмотра, ваша страница может выглядеть несколько странно. Если вы пользуетесь пикселями и таблица оказывается шире области просмотра, внизу появится полоса прокрутки для перемещения вправо и влево по странице. В зависимости от поставленных задач и тот, и другой способ задания ширины таблицы могут оказаться полезными.

Пример 6.15

<HTML>

<BODY>

<TABLE BORDER WIDTH=100%>

 <TR>

<TD ALIGN=CENTER>Текст или данные - ширина 100%

 </TR>

</TABLE>

или

<TABLE BORDER WIDTH=50%>

 <TR>

<TD ALIGN=CENTER>Текст или данные - ширина 50%</TD>

 </TR>

</TABLE>

или

<TABLE BORDER WIDTH=200>

 <TR>

<TD ALIGN=CENTER>Текст или данные - ширина 200 пикселей</TD>

 </TR>

</TABLE>

или

<TABLE BORDER WIDTH=100>

 <TR>

<TD ALIGN=CENTER>Текст или данные - ширина 100 пикселей</TD>

 </TR>

</TABLE>

</BODY>

</HTML>

Атрибут UNIТ= 

Атрибут UNIT= тага <ТАВLЕ> определяет единицы измерения, используемые при указании размеров как всей таблицы, так и ее отдельных столбцов. Атрибут UNIТ= может принимать три значения:

UNIТ=ЕN - это значение присваивается по умолчанию и задает единицу измерения, равную еn-пробелу. Еn-пробел - это типографская единица измерения, равная ширине буквы <n>. Реальный размер пробела зависит от выбранного шрифта: для крупного шрифта еn-пробел больше, чем для мелкого. Обычно еn-пробел равен половине размера шрифта. Например, при использовании 12-пунктового шрифта ширина еn-пробела будет 6 пунктов. Для 8-пунктового шрифта еn-пробел занимает 4 пункта.

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

UNIТ=РIXELS - это значение применяется, когда вам нужно точно знать ширину столбца на экране. В этом случае лучше всего задать ее в пикселях. Например, таг <ТАВLЕ UNIТ=РIXELS WIDTH=340> сформирует таблицу шириной 340 пикселей.

Атрибут СОLSРЕС= 

Атрибут СОLSРЕС=, используемый с атрибутом UNIТ=, определяет, сколько места занимает каждый столбец таблицы и как в нем выравниваются данные. Применяется только в таге<ТАВLЕ>.

СОLSРЕС= перечисляет все столбцы и для каждого из них задает выравнивание и размер. Для столбца (или ячейки) существует пять способов выравнивания: L - по левому краю, С - по центру, R - по правому краю, J - по правому и левому краю и D - по десятичной запятой. Если у вас пять столбцов, вы можете определить ширину и выравнивание каждого из них следующим образом:

<ТАВLЕ UNIТ=РIХЕLS СОLSРЕС="L10 С15 J25 D30">

Вы описали таблицу, в которой первый столбец имеет ширину 10 пикселей и его содержимое выравнивается по левому краю, второй столбец, шириной 15 пикселей, с выравниванием по центру, третий, шириной 20 пикселей, выровнен по правому краю, четвертый, шириной 25 пикселей, выровнен с двух сторон, а пятый, шириной 30 пикселей, выравнивается по десятичным запятым.

Атрибут DР= 

Атрибут DР= (Decimal Point, десятичный знак) определяет символ, используемый для отделения целой части десятичной дроби. DР="." (по умолчанию) указывает на точку в качестве десятичного символа. DР="," задает запятую.

Пустые ячейки 

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

Атрибут СЕLLРАDDING=

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

Пример 6.16

<HTML>

<BODY>

<CENTER>

<TABLE BORDER CELLPADDING=20>

 <TR>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

</TR>

<TR>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

 </TR>

</TABLE>

<BR>

<TABLE BORDER CELLPADDING=O>

 <TR>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

</TR>

<TR>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

 </TR>

</TABLE>

</CENTER>

</BODY>

</HTML>

Атрибуты АLIGN= и VALIGN=

Таги <ТR>, <ТD> и <ТН> можно модифицировать с помощью атрибутов ALIGN= и VALIGN=. Атрибут АLIGN определяет выравнивание текста и графики по горизонтали, то есть по левому или правому краю, либо по центру, как видно из рис. . Горизонтальное выравнивание может быть задано несколькими способами:

ALIGNLЕЕDLEFT Прижимает содержимое ячейки вплотную к левому краю. ALIGN=LEFT Выравнивает содержимое ячейки по левому краю с учетом отступа, заданного атрибутом СЕLLPADDING=. АLIGN=СЕNTER Располагает содержимое ячейки по центру. АLIGN=RIGHT Выравнивает содержимое ячейки по правому краю с учетом отступа, заданного атрибутом СЕLLPADDING=.

Пример 6.17

<HTML>

<BODY>

<TABLE BORDER WIDTH=100%>

 <TR>

<TD ALIGN=LEFT>Текст или данные</TD>

<TD ALlGN=CENTER>Текст или данные</TD>

<TD ALIGN=RIGHT>Текст или данные</TD>

</TR>

<TR>

<TD ALIGN=RIGHT>Текст или данные</TD>

<TD ALIGN=CENTER>Текст или данные</TD>

<TD ALIGN=LEFT>Текст или данные</TD>

</TR>

<TR>

<TD ALIGN=RIGHT>Текст или данные</TD>

<TD ALIGN=RIGHT>Текст или данные</TD>

<TD ALIGN=RIGHT>Текст или данные</TD>

</TR>

<TR>

<TD ALIGN=CENTER>Текст или данные</TD>

<TD ALIGN=CENTER>Текст или данные</TD>

<TD ALIGN=CENTER>Текст или данные</TD>

</TR>

<TR>

<TD ALIGN=LEFT>Текст или данные</TD>

<TD ALIGN=LEFT>Текст или данные</TD>

<TD ALIGN=LEFT>Текст или данные</TD>

</TR>

</TABLE>

</BODY>

</HTML>

Атрибут VALIGN= осуществляет выравнивание текста и графики внутри ячейки по вертикали. . Вертикальное выравнивание может быть задано несколькими способами: VALIGN=ТОР Выравнивает содержимое ячейки по ее верхней границе.

VALIMG=МIDDLE Центрирует содержимое ячейки по вертикали. VALIGN=ВОТТОМ Выравнивает содержимое ячейки по ее нижней границе.

Пример 6.18

<HTML>

<BODY>

<CENTER>

<TABLE BORDER WIDTH=90%>

 <TR>

<TD WIDTH=100> Атрибут VALIGN= осуществляет выравнивание текста и

графики внутри ячейки по вертикали.

 </TD>

<TD VALIGN=TOP>верх,</TD>

<TD VALIGN=MIDDLE>середина,</TD>

<TD VALIGN=BOTTOM>низ.</TD>

 </TR>

<TR VALIGN=TOP>

<TD> VALIGN=ТОР Выравнивает содержимое ячейки по ее верхней границе.

</TD>

<TD>верх,</TD>

<TD>верх,</TD>

 <TD>верх.</TD>

</TR>

<TR VALIGN=middle>

 <TD> VALIGN=МIDDLE Центрирует содержимое ячейки по вертикали.

</TD>

<TD>середина,</TD>

<TD>середина,</TD>

 <TD>середина.</TD>

</TR>

<TR VALIGN=bottom>

 <TD> VALIGN=ВОТТОМ Выравнивает содержимое ячейки по ее нижней границе.

</TD>

<TD>низ,</TD>

<TD>низ,</TD>

 <TD>низ.</TD>

</TR>

</TABLE>

</CENTER>

</BODY>

</HTML>

Атрибут ВОRDER= 

В таге <ТАВLЕ> часто определяют, как будут выглядеть рамки, то есть линии, окружающие ячейки таблицы и саму таблицу. Если вы не зададите рамку, то получите таблицу без линий, но пустое пространство для них будет отведено. Того же результата можно добиться, задав <ТАВLЕ ВОRDER=0>. Иногда хочется сделать границу потолще, чтобы она лучше выделялась. Можно для привлечения внимания к рисунку или тексту задать исключительно жирные границы. При создании вложенных таблиц приходится делать границы различной толщины для разных таблиц, чтобы их легче было различать.

Атрибут СЕLLSPACING=

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

Пример 6.19

<HTML>

<BODY>

<CENTER>

<TABLE BORDER CELLSPACING=20>

 <TR>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

</TR>

<TR>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

 </TR>

</TABLE>

<TABLE CELLSPACING=20>

<TR>

 <TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

</TR>

<TR>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

 </TR>

</TABLE>

<TABLE CELLSPACING=0>

<TR>

 <TD>Текст или данные</TD>

<TD>Текст или данные</TD>

<TD>Текст или данные</TD>

</TR>

<TR>

<TD>Текст или данные</TD>

<TD></TD>

<TD>Текст или данные</TD>

</TR>

</TABLE>

</CENTER>

</BODY>

</HTML

6.3. Использование таблиц в дизайне страницы

Приятное свойство таблиц состоит в том, что если вы захотите, то можете сделать их границы невидимыми. Это позволяет с помощью тага <ТАВLЕ> красиво размещать на странице текст и графику. До сих пор таг <ТАВLЕ> остается единственным мощным средством форматирования в HTML. Дизайнеры Web-страниц сейчас обладают практически такой же свободой использования <пустого пространства>, что и создатели печатных страниц. Таблицы в большей мере, чем что-либо другое, помогают отойти от иерархического размещения текста на Web-страницах.

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

Пример 6.20

<HTML>

<BODY>

<CENTER>

<TABLE CELLPADDING=10 CELLSPACING=0 BORDER=16>

<TR>

<TD ALIGN=CENTER>

<H1>ПЕРФОРАТОР</H1>

<H3>Только сегодня!</H3>

<TABLE BORDER WIDTH=100%>

<TR><TD ALIGN=CENTER><I>Почти бесплатно!</I></TD>

</TR>

</TABLE>

</TD>

</TR >

</TABLE>

</CENTER >

</BODY>

</HTML>

Рис. 6.11. Создание выпуклых элементов

Создание разноцветных таблиц

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

Цветные границы в Netscape Navigator

Вы не только можете окружить таблицу красивой рамкой, но еще и задать для нее цвет, отличный от цветов текста и фона. Создайте простой серый GIF (или любой GIF, который вы хотели бы иметь в качестве фона) и определите его в таге <ВODY> как фон страницы. Затем задайте цвет фона страницы. В результате ваш таг <ВОDY> будет выглядеть примерно так:

 <BODY ВАСКGROUND="сооlbg.gif" ВGCOLOR=" # FF0000">

Вы создали двойной фон - GIF и заданный цвет. В результате фоновый цвет будет виден на всех границах таблиц и горизонтальных линиях (<НR>). Вне зависимости от того, является ли ваш фоновый GIF серым или нет, цветные линии и границы таблиц будут заметно выделяться. Если фоновый GIF не слишком сложно устроен, время загрузки страницы лишь немного возрастет. На приведенном ниже примере показано какие, широкие возможности дает использование цвета в HTML и в частности в таблицах.

Пример 6.21

<HTML>

<BODY BACKGROUND="bgr.gif" BGCOLOR="YELLOW" >

<CENTER>

<TABLE BORDER=3 CELLPADDING=20>

<CAPTION ALIGN=TOP><H2>Как просверлить бетонную стену</H2></CAPTION>

<TR>

<TD BGCOLOR=GRAY>

<TABLE CELLPADDING=10 CELLSPACING=0 BORDER=16>

<TD BGCOLOR=RED ALIGN=CENTER>

 <H1>ПЕРФОРАТОР</H1>

<H3>Только сегодня!</H3>

 <TABLE BORDER WIDTH=100%>

<TR>

<TD BGCOLOR=AQUA ALIGN=CENTER><I>Почти бесплатно!</I></TD>

</TR>

</TABLE>

</TABLE>

<TD WIDTH=50% BGCOLOR=BROWN ALIGN=CENTER>

<IMG SRC="perfor1.gif" WIDTH=200 HEIGHT=150>

</TD>

</TR>

<TR>

<TD BGCOLOR=PINK>

<FONT SIZE=6 COLOR=BLUE>От 6 до 20 мм</FONT>

</TD>

<TD BGCOLOR=BLUE>

<FONT SIZE=6 COLOR=PINK>Просверлим все</FONT>

</TD>

</TR>

</TABLE>

</CENTER >

</BODY>

</HTML>

Рис. 6.12. Пример разноцветной таблицы

6.4. Фреймы 

Что такое фрейм? 

В каком-то смысле фрейм - это именно то, что означает данное слово: рамка вокруг картинки, окошко или страница. Вводя таг <FRAME>, дизайнер НТМL-страницы разделяет экран броузера на части. В результате человек, просматривающий страницу, может изучать одну часть страницы независимо от остальной части. Фактически броузер, распознающий фреймы, загружает разные страницы в разные секции, или фреймы, экрана. Например, вы можете построить страницу таким образом, что фирменный знак будет зафиксирован в верхней части экрана, в то время как остальную часть страницы пользователь пролистывает обычным способом. Можно расположить сбоку кнопки навигации, которые не перемещаются, когда читатель щелкает их мышкой, так что изменяется только часть экрана, а сама полоска навигации остается неподвижной.

Для чего можно использовать фреймы

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

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

Как работают фреймы

На первый взгляд, фреймы - это нечто сложное, но их легче понять, если провести аналогию с ячейками таблицы. Расположение фреймов на экране задается почти так же, как ячеек в таблице: таги и атрибуты работают так же, как их табличные родственники. Однако, хотя аналогия между единичным фреймом на странице и ячейкой таблицы полезна, нужно помнить, что есть и отличия. Содержимое ячейки задано в коде HTML-страницы с таблицей. Текст или графика, составляющие содержимое таблицы, фактически вводятся на той же самой странице HTML, что и таг или атрибут, описывающие таблицу. Напротив, экран с фреймами описывается в НТМL-странице, называемой (frameset ). Содержимое же фрейма - это отдельная HTML-страница, которая может находиться где угодно - в другом каталоге, на локальном сервере или на удаленном узле где-то в сети. Фреймовая структура определяет только способ организации экрана с фреймами и указывает, где находится начальное содержимое каждого фрейма. Для всех фреймов задаются URL, описывающие местонахождение их данных. Как правило, на странице с фреймовой структурой нет содержимого фреймов. Такая страница обычно невелика - она описывает только кадровую структуру экрана. Когда документ загружается в фрейм, вы можете щелкать мышкой на ссылке в этом документе, что вызовет появление связанных документов в других кадрах, заданных в фреймовой структуре.

Создание простой страницы с фреймами

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

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

Задание фреймовой структуры

Для начала мы должны представить себе общий вид страницы - где и какого размера будут фреймы. Затем можно подумать об их содержании. Ниже приводится код простой фреймовой структуры с использованием тага <FRAMESET>. Обратите внимание: страница с фреймовой структурой не содержит тага <ВОDY>.

Пример 6.22

<HTML>

<HEAD>

<TITLE>Пример фреймов</TITLE>

</HEAD>

<FRAMESET COLS="25%, 75%"

<FRAME SRC="a.html">

<FRAME SRC="b.html" NAME="main">

 </FRAMESET>

<NOFRAMES>

Вы видите эту страницу броузером не поддерживающим фреймы.

</NOFRAMES>

</HTML>

Вот и весь код, необходимый для задания фреймовой структуры. Обратите внимание на таг <NOFRAMES>. Через несколько минут мы к нему вернемся. В результате мы получили экран, разделенный на два окна. Левое окно занимает 25 процентов экрана и содержит страницу с названием a.html. Окно справа займет 75 процентов и вначале покажет файл b.html. Пока у нас их нет, так что вы увидите страницу с двумя пустыми фреймами. Прежде чем она появится, нам придется пару раз щелкнуть мышкой в ответ на сообщения об ошибках, потому что броузер будет пытаться найти несуществующие страницы. Заметьте, что правую страницу мы назвали <main > ( <главная>) с помощью строки:

 <FRAME SRC="b.html" NAMЕ="main">

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

Подготовка содержимого фрейма

Теперь давайте загрузим фреймы с содержимым. Зададим страницу menu.html в левом фрейме, где мы собираемся щелкать мышью, переключаясь между двумя страницами в правом фрейме. Файл menu.html - это обычная НТМL-страница, построенная как оглавление. На самом деле мы можем взять готовую страницу с оглавлением и использовать ее. Имейте в виду, что этот фрейм узкий и высокий, так что страница, которая будет в него загружаться, должна быть соответствующим образом спроектирована. Теперь мы должны определить, где будут появляться другие страницы при щелчке мышкой на ссылке. Поскольку мы хотим, чтобы они отображались в правом фрейме, добавим атрибут ТАRGET= (TARGЕТ="main") в таг ссылки. Это означает, что когда пользователь щелкает на ссылке, вызываемая страница появляется в фрейме main. Мы отображаем все страницы в фрейме main, поэтому давайте добавим атрибут ТАRGЕТ="main" во все таги ссылок в оглавлении. Если мы не определим атрибут ТАRGЕТ, то страница появится там, где мы щелкнули мышкой, - в левом фрейме, что нас не устраивает, хотя в какой-нибудь другой ситуации подобное поведение было бы очень кстати. Например, вы можете добавить ссылку <Другие пункты оглавления>, которая будет просто выводить следующие ссылки. Имеет смысл сделать оглавление подлиннее, чтобы читатели видели как можно больше ссылок. Но сейчас давайте ограничимся простым примером. Ниже приведен код для левого фрейма menu.html.

Пример 6.23

<HTML>

<HEAD>

<TITLE> Меню</TITLE>

</HEAD>

<BODY>

<H3 ALIGN=CENTER>Компания.</H3>

<HR>

<UL><font color="#400040" size="4">

<LI><a href="html-pr2-4.html" ТАRGЕТ="main">Главная</a>

<LI><a href="news.html" ТАRGЕТ="main">Новости</a>

<LI><a href="products.html" ТАRGЕТ="main">Товары</a>

<LI><a href="servis.html" ТАRGЕТ="main">Услуги</a>

<LI><a href="contact.html" ТАRGЕТ="main">Контакты</a>

<LI><a href="search.htm" ТАRGЕТ="main">Поиск</a>

 </UL>

</font>

</BODY>

</HTML>

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

Подготовка фрейма main

Правый фрейм main будет содержать сами HTML-страницы. Ваша задача так их спроектировать, чтобы они хорошо смотрелись в меньшем, чем обычно, окне, потому что часть экрана будет занята левым кадром оглавления. Но больше эти страницы ничем не примечательны. Ниже приводится код для страницы, упомянутой первой в оглавлении ( html-pr2-4.html).

Пример 6.24

<HTML>

<HEAD>

<TITLE> Главная страница</TITLE>

 </HEAD>

<BODY>

<H1 ALIGN=CENTER>Компания.</H1>

 <HR>

<H3 ALIGN=LEFT><I>Открытое акционерное общество Компания основанная

в 1996 году, является одним из ведущих поставщиков бытовой электроники

в России.</I></H3>

<HR>

<H3>Основными направлениями деятельности Компании являются:

<OL>

<LI>реализация бытовой электроники ведущих фирм мира через сеть магазинов;

<LI>создание сервисных центров по обслуживанию бытовой

электроники.</H3>

</OL>

<HR>

<H3><U><FONT COLOR=RED> Компания ищет агентов по сбыту бытовой

электроники.</FONT></U></H3>

<H5 ALIGN=CENTER>Контактная информация</H5>

 <UL>

<LI>Telephone (123) 12-34-56

<LI>FAX (123) 12-34-56

 <LI>Почтовый адрес 123456 г. Город, ул Лесная, 106

<UL TIPE=CIRCLE>Электронная почта<BR>

<LI>Общая информация: abc@abc.su

<LI>Продажи: abc@abc.abc.su

 </UL>

</UL>

<BR><BLINK>Copyright</BLINK> © 1997 Компания

 </BODY>

</HTML>

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

Использование тага <NOFRAMES>

У многих ваших посетителей еще остались броузеры, не умеющие обращаться с фреймами. По этим причинам разумно предоставить доступ к версии ваших основных страниц без фреймов. Если читатель с устаревшим броузером окажется на вашей странице с фреймовой структурой, все, что находится на ней между тагами < NOFRAMES > и </ NOFRAMES >, будет выглядеть отлично - броузер просто проигнорирует фреймы. Вот почему обязательно нужно использовать таги <ВODY></ВОDY>. Возможно, вам придется иначе организовать экран без фреймов.

Можно поместить на страницу с фреймами кнопку No Frames (Без фреймов). Ее назначение очевидно. Такой вариант достаточно разумен и легко осуществим.

На тот случай, если вы неуверенно чувствуете себя при использовании <NOFRAMES >, ниже приведен пример страницы с фреймовой структурой с добавленным в конце разделом < NOFRAMES >.

Пример 6.25

<HTML>

<HEAD>

<TITLE> Пример фрейма</TITLE>

</HEAD>

<FRAMESET COLS="25%, 75%"

<FRAME SRC="html-pr5-2.html">

<FRAME SRC="html-pr2-3.html" NAME="main">

 </FRAMESET>

<NOFRAMES>

Вы видите эту страницу броузером не поддерживающим фреймы.

Броузер поддерживающий фреймы не видит этот текст.

</NOFRAMES>

</HTML>

Имейте в виду, что поддерживающий фреймы броузер проигнорирует все, что находится между тагами < NOFRAMES > и </ NOFRAMES >. И наоборот, не поддерживающий фреймы броузер проигнорирует все, что находится между тегами <FRAMESET> и </FRAMESET>. Код без фреймов можно поместить и в начало, и в конец страницы.

Специфические таги и атрибуты фреймов

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

Таг <FRAMESET>

Таги <FRAMESET> обрамляют текст, описывающий компоновку фреймов. Здесь размещается информация о числе фреймов, их размерах и ориентации (горизонтальной или вертикальной). У тага <FRAMESET> только два возможных атрибута: ROW=, задающий число строк, и СОLS=, задающий число столбцов. Между тагами <FRAMESET> не требуется указания тага <ВОDY>, но его можно поместить между тагами <NOFRAME> в конце фреймовой структуры. Между тагами <FRAMESET> не должно быть никаких тегов или атрибутов, которые обычно используются между тагами <ВОDY>. Единственными тагами, которые могут находиться между тагами <FRAMESET> и </FRAMESET>, являются таги <FRAME>, <FRAMESET> и < NOFRAME>. Это упрощает задачу. В основном все связано с тагами <FRАМЕ> и их атрибутами. Если же вы хотите поэкспериментировать, можно сделать вложенные друг в друга таги <FRAMESET> аналогично тагам <ТАВLЕ>.

Атрибуты ROW= и СОLS= похожи. Имейте в виду, что для каждой строки и столбца, упомянутых в таге <FRAMESET>, должен быть свой набор тагов <FRАМЕ>.

Атрибут ROW=

Атрибут ROW= тага < FRAMESET > задает число и размер строк на странице. Количество тагов <FRАМЕ> должно соответствовать указанному числу строк. Справа от знака = можно определить размер каждой строки в пикселях, процентах от высоты экрана или в относительных величинах (обычно это указание занять оставшуюся часть места). Не забывайте пользоваться кавычками и запятыми и оставлять пробелы между значениями атрибутов. Например, следующая запись формирует экран, состоящий из трех строк: высота верхней равна 20 пикселей, средней - 80 пикселей, нижней - 20 пикселей:

Следующий таг < FRAMESET > создает экран, на котором верхняя строка занимает 10% высоты экрана, средняя - 60%, а нижняя - оставшиеся 30%.

<FRAMESET ROW="10%, 60%, 30%->

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

< FRAMESET ROW="20, 80, *" >

А можно сделать так:

< FRAMESET ROW="20, 2*, *" >

Число перед знаком ' показывает, что соответствующая строка (в данном случае - средняя) занимает в два раза больше оставшегося на экране места, чем нижняя. Не забывайте, что значения относительны (они зависят от размера экрана). Это часто бывает удобно, ведь вы не всегда знаете, какой у вашего пользователя монитор и какое разрешение он использует.

Атрибут СOLS= 

Столбцы задаются так же, как строки. Для них применимы те же атрибуты.

Таг <FRАМЕ> 

Таг <FRАМЕ> определяет внешний вид и поведение фрейма. Этот таг не имеет закрывающего тага, поскольку в нем ничего не содержится. Вся суть тага <FRАМЕ> в его атрибутах. Их шесть: NАМЕ=, MARGINWITH=, MARGINHEIGHT=, SCROLLING=, NORESIZE= и SRC=.

Атрибут NАМЕ= 

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

<FRАМЕ SRC="my.html" NАМЕ="main">

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

Атрибут МАRGINWITH= 

Атрибут МАRGINWITH = действует аналогично атрибуту таблиц CELLPADDING=. Он задает горизонтальный отступ между содержимым кадра и его границами. Наименьшее значение этого атрибута равно 1. Нельзя указать 0. Можно ничего не присваивать - по умолчанию атрибут равен б.

Атрибут МАRGINHEIGHT= 

Атрибут МАRGINHEIGHT= действует так же, как и МАRGINWITH =. Он задает поля в верхней и нижней части фрейма.

Атрибут SCROLLING= 

Хотите ли вы, чтобы ваши читатели пользовались прокруткой в фрейме? Иногда бывает разумно лишить их этого удовольствия. Возможные варианты: SCROLLING =YES, SCROLLING =NО, SCROLLINGUТО. SCROLLING =YES означает, что в фрейме всегда будут полосы прокрутки, даже если это не нужно. При задании SCROLLING =NО полос прокрутки не будет, даже если они необходимы. Если документ слишком большой, а вы задали режим без прокрутки, то документ просто будет обрезан. Атрибут SCROLLING =АUТО предоставляет броузеру самому решать, требуются ли полосы прокрутки или нет. Если атрибут SCROLLING= отсутствует, результат будет таким же, как и при задании SCROLLING =АUТО.

Атрибут NORESIZE 

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

Атрибут SRС= 

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

Атрибут ТАRGЕТ= 

Чтобы разобраться с атрибутом ТАRGЕТ=, давайте вернемся к нашему простому примеру с кадром оглавления. Когда пользователь щелкает мышкой на одной из ссылок в левом фрейме, соответствующая страница должна появиться в правом фрейме, а оглавление остается неизменным. Чтобы этого добиться, нужно определить целевой фрейм ТАRGЕТ, в котором будет отображаться страница для каждого пункта оглавления. Задание целевых фреймов осуществляется в ссылках левого фрейма. Вот зачем всем кадрам в фреймовой структуре были присвоены имена. Правый фрейм называется main, так что нужно в каждой ссылке добавить атрибут ТАRGЕТ="main", в результате чего соответствующая страница появится в фрейме main. Обратите внимание: каждая ссылка содержит атрибут ТАRGЕТ="main", который в ответ на щелчок мышью отображает страницу в фрейме main.

Атрибут ТАRGЕТ= можно задавать для нескольких различных тагов. При использовании в таге <ВАSЕ> он направляет все ссылки в определенный целевой фрейм, если в дальнейшем особо не оговорено другое. Можно задать атрибут ТАRGЕТ= в таге <АRЕА> в активном изображении или в таге <FОRМ>. Фреймы полезны для организации форм. Пользователи будут видеть одновременно и форму, и результат своего выбора. Обычно при щелчке мышью кнопки Submit форма исчезает и возникает страница с результатами выбора. Сочетание форм и фреймов может оказаться удобным средством навигации.

"Волшебные" целевые фреймы

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

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

Фрейм "blank"

Если атрибут ТАRGЕТ= ссылается на " blank", то документ всегда будет появляться в новом пустом окне.

Фрейм "self"

Имя "self" указывает на то, что выбранная страница загружается в тот же фрейм, где была активирована ссылка. Если вы щелкнете мышкой на ссылке в фрейме оглавления, выбранная страница окажется в том же самом фрейме. Если вы задали фрейм для всего документа в атрибуте ВАSЕ=, то "self" помогает нейтрализовать ссылку в ВАSЕ=.

Фрейм "раrent"

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

Фрейм "top"

При указании ссылки "tор" документы появляются в отдельном окне вне фрейма. Независимо от вашего желания броузер откроет новое окно просмотра.

Вложенные и множественные кадровые структуры

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

В основном вложенные фреймы действуют так же, как вложенные таблицы. Задайте кадровую структуру, а внутри какого-нибудь фрейма в ней еще одну структуру. Помните, что таг <FRАМЕ> не имеет закрывающего тага. Вы, наверное, заметили, что при работе с фреймами не используются таги <СОLSРАN> и <ROWSРАN>. Их роль играют множественные, или вложенные, фреймы. Задав внутри одной объемлющей фреймовой структуры две независимых подструктуры, можно поместить в левой части экрана столбец из двух, а в правой - из трех фреймов.

6.5. Формы 

Интерактивные формы позволяют читателям Web-страниц легко общаться с их владельцами. Благодаря простоте использования тага <mailto:> и форм стал возможен двусторонний диалог между владельцами Web-узлов и их читателями. Это открывает для Web-навигаторов увлекательные перспективы и коммерческие возможности. К сожалению, многие старые броузеры не поддерживают таг <mailto:>.

Как сделать так, чтобы ваша форма хорошо смотрелась

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

Пример 6.26

<HTML>

<HEAD>

<TITLE>Коментарии</TITLE>

 </HEAD>

<BODY>

<H1>Коментарии</H1>

 <BR>Пожалуйста сообщите нам, что вы думаете о нашем web сайте, компании,

продукции, или услугах. Если вы сообщите нам свою контактную информацию,

у нас будет возможность связаться с вами и ответить на ваши вопросы.</p>

 <FORM METHOD="POST" action="mailto: yourname@your.email.address">

 <H3>Контактная информация</H3>

<TABLE BORDER="0">

 <TR>

<TD ALIGN="right"><em>Имя</em></td>

<TD><input type="text" size="35" name="Name"></td>

</TR>

<TR>

<TD ALIGN="right"><em>Тема</em></td>

<TD><input type="text" size="35" name="Title"></td>

</TR>

<TR>

<TD ALIGN="right"><em>Компания</em></td>

<TD><input type="text" size="35" name="Company"></td>

</TR>

<TR>

<TD ALIGN ="right"><em>Адрес</em></td>

<TD><input type="text" size="35" name="Address"></td>

</TR>

<TR>

<TD ALIGN ="right"><em>Телефон</em></td>

<TD><input type="text" size="35" name="Telephone"></td>

</TR>

<TR>

<TD ALIGN ="right"><em>Факс</em></td>

<TD><input type="text" size="35" name="FAX"></td>

</TR>

<TR>

<TD ALIGN ="right"><em>E-mail</em></td>

<TD><input type="text" size="35" name="Email"></td>

</TR>

</TABLE>

<p> 

<input type="reset" value="Очистить форму"> </p>

</FORM>

</BODY>

</HTML>

Рис 6.17. Вид формы на экране

6.5.1. Как заставить формы работать

Возможно, это именно тот раздел, которого вы ждете - как сделать так, чтобы формы отсылали на сервер введенные данные. На самом деле заставить форму пересылать данные довольно просто. Главная проблема - понять, куда их пересылать. Формально вы просто пишете в таге <FORM> атрибут АСТION= и задаете ссылку на URL программы, которая может обработать входные данные и сделать с ними что-нибудь полезное.

6.6. DHTML

DHTML (Dynamic HTML) представляет собой технологию написания HTML-страниц с динамически изменяемым содержимым. Реализация DHTML базируется на трех основных компонент:

  1.  HTML;
  2.  Cascade Style Sheets (CSS);
  3.  Language of scripts (VBScript or JavaScript).

Эти три компоненты DHTML связаны между собой посредством Document Object Model (DOM),которая по своей сути является прикладным программным интерфейсом (API). DOM связывает вместе три перечисленные компоненты, добавляя простому HTML документу новое качество— возможность динамического изменения своего содержимого без перезагрузки страницы.

Cascade style sheets можно сравнить с файлом стилей некоторого текстового редактора. С его помощью может быть определено появление высвечиваемого HTML-документа: цвет шрифта и фона документа, шрифт font и пр. Для каждого элемента, устанавливая некоторые HTML тэги, можно определить стиль отображения в окне броузера.

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

Не все броузеры поддерживают Document Object Model и Style Sheets. Однако, DHTML использует стандартные HTML тэги и поэтому пользователи броузеров, которые не поддерживают DOM, увидят практически все, что задумывалось при разработке динамических страниц, но только в статическом виде.

6.6.1. DOM

 Document Object Model является интерфейсом между исходным текстом HTML страницы и программой броузера, которая создает окно и заполняет его элементами, определенными на странице. Физически DOM может быть представлена как часть ПО броузера. DOM есть представление объектов, методов, свойств и событий, которые присутствуют и случаются в ПО броузера в той форме, в которой это удобно для работы с ними в HTML коде и скриптовым тексте на странице. DOM похволяет броузеру выполнять встроенные скрипты, обрабатывать пользовательские инструкции и динамически изменять содержимое документа без его перезагрузки 

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

Основное назначение реализации DOM состоит в получении возможности доступа и манипуляции элементами документа из программы с помощью объектов, представленных в иерархической структуре, а также в предоставлении интеракивного механизма между объектами. Поэтому любая реализация модели включает также управление событиями, представленными так же как объекты. Иерархическая структура объектов DOM, представленная на рис. 6.18, похожа на иерархическую структуру объектовis JavaScript, но вдобавок позволяет получить доступ и определять свойства Cascade Style Sheets.

Как можно увидеть из схемы DOM, наверху иерархии объектов расположен объект Window. Он является контейнером для следующих объектов: History, Location, Navigator, Document, Event, Screen. Объект Event создается автоматически при наступлении события и содержит всю необходимую информацию о событии. Объект Document является основой DOM, т.к. большая часть этих объектов. Некоторые объекты DOM комбинируются в коллекции (collections), которые представляют собой структуры, подобные массивам. Одним из объектов коллекции Document является коллекция "all", содержащая ссылки на все элементы основной части документа. Имя элемента HTML, на который возможно ссылаться в скрипте, специфицируется либо в ID- параметре, либо в параметре NAME тэга элемента. Например, на первый параграф документа

< P ID = 'P1' > The paragraph... < /P >

Вы можете сослаться следующим образом:

Document.all [0]

Document.all ['P1']

Document.all. P1

Рис. 6.18. Document Object Model

6.6.2. Cascade Style Sheets

Cascade Style Sheets является технологией определения и связи стилей с HTML документами.

Каскадные таблицы стилей были предложены w3c (WWW Consorcium) в рамках разработки спецификации HTML 3.0. Однако, реализованы в реально действующих навигаторах они были только в 1997 году. Фактически, в качестве применяемой HTML-разметки они стали доступны только с версий Netscape Navigator 4.0 и Internet Explorer 4.0.

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

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

Таблица стилей (style sheet) в действительности является шаблоном, который управляет форматированием HTML тэгов в web-документе. По определенным правилам броузер определяет приоритет применения нескольких таблиц стилей, представленных в виде «каскада».

Правила Cascade Style Sheets состоят из двух частей: селектор и определитель. Селектор может быть представлен тэгом HTML, для которого определитель устанавливает как его форматировать. Определитель, в свою очередь, состоит из двух частей: свойств и их изначений, разделенных двоеточием (:). Дадим пример правил:

H1 {color: blue; font-size: 16pt}

 В данном правиле селектор – это элемент H1 и определение, записанное в фигурных скобках устанавливает значения двух свойств заголовка первого уровня: цвет шрифта (правильно "color") определенного как голубой (значение "blue") и размер шрифта (правильно "font-size") определенного как 16 (значение "16pt"). В одном правиле возможно установить несколько определений, разделенных символом точко с запятой (;), как продемонстрировано в примере.

Обычно стиль описывается внутри контейнера STYLE:

 <style type="text/css">

 <!-- Описание стилей -->

</style>

Начнем с простого примера. Нужно описать стили отображения текста в параграфе и заглавии документа:

Пример 6.28

<html>

<head>

style type="text/css">

p {color:blue; font-family: times; font-size:10pt;}

h1 {color:black; font-size:12pt; font-style:Arial; text-align: center;}

</style>

</head>

<body>

<h1>Test Style Sheets in Communicator</h1>

<p> This is a first part of the document

 </body>

</html>

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

Новые HTML-контейнеры

С появлением таблиц стилей в языке появилось три новых контейнера: STYLE, LINK, SPAN. Вообще говоря, LINK - это не новый таг, а новое применение старого тага.

Контейнер STYLE (<style type="...">......</style>) служит для определения таблицы описания стилей. Хотя в спецификации CSS прямо не говорится, в каком контейнере документа следует применять STYLE, тем не менее, в примерах чаще всего приводится этот контейнер внутри контейнера HEAD.

Контейнер LINK в контексте описателей стилей применяется для определения внешнего файла с описаниями стилей для данного документа. Например, внешний файл может содержать следующее описание стилей:

 /* contents of the external style sheets file css.htm*/

p {color:blue; font-family: times; font-size:10pt;}

h1 {color:black; font-size:12pt; font-style:Arial; text-align: center;}

/* the end of style sheets definition */

Для применения этого описателя стилей в заголовок документа необходимо включить следующий таг:

Пример 6.30

<html>

<head>

<link REL=STYLESHEET TYPE="text/css" HREF=http://localhost/css.htm>

</head>

<body>

The body of the document should be here.

 </body>

</html>

Из данного примера видно, что писание стилей в фале css.htm полностью совпадает с описанием в контейнере STYLE. В тексте файла описания стилей не нужно указывать таги контейнера STYLE.

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

Пример 6.31

<HTML>

<!--

Author: Paul Khramtsov

Date: September 19, 1997

URL: http://polyn.kiae.su/Internet/intro.html

-->

<HEAD>

<style TYPE="text/css">

FS.all { color:red; font-size: 24pt; font-family: times;}

H1 {color:navy; text-transform: uppercase;font-size: 18pt;

font-weight: bold; font-family: times;}

H2 {color:navy; font-size: 14pt; font-weight: bold; font-style: italic;

font-family: times;}

H3 {color:navy; font-size: 10pt; font-weight: bold; font-family: times;}

P {color:navy; font-size: 12pt; font-family: times; text-align: justify}

P.HELP {color:darkgreen; font-size: 10pt; font-family: times;

text-align: justify;}

P.LEFT {color:navy; font-size: 12pt; font-family: times; text-align: right;}

</style>

</HEAD>

<BODY bgcolor=lightyellow>

 <center>

<h3>Центр информационных технологий</h3>

<h1>Информационные Ресурсы Internet</h1>

<h3>(Учебное пособие для компьютерных непрофессионалов)</h3>

<h3>Храмцов П.Б.</h2>

<h3>Москва, 1997</h2>

<hr>

</center>

<p><span class=FS>C</span>обществу глобальных компьютерных сетей Internet в 1995 году исполнилось 25 лет. На настоящий момент, это самый большой информационный ресурс мира. Одновременно Internet - это самая популярная и массовая компьютерная сеть планеты. По оценкам международного центра координации сетевой деятельности в рамках Internet(Internic-Internet Information Center) на 1997 год в сети насчитывалось несколько десятков миллионов постоянно арегистрированных компьютеров-серверов, которые откликаются на запросы пользователей 365 дней в году и 24 часа в сутки. Этот огромный информационный ресурс полностью децентрализован и не подчиняется ни одному правительству или крупной финансовой компании мира.

</BODY>

</HTML>

В данном примере, контейнер SPAN применен сразу после тага начала параграфа <p>, что позволяет выделить первую букву в отображаемом абзаце:

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

Новые свойства контейнеров HTML

Перечень новых атрибутов у тагов HTML следует начать с атрибута STYLE. Этот атрибут используется для определения стиля отображаемого контейнера непосредственно внутри тага начала контейнера:

<h3 style="line-hieght:24pt; font-weight:bold; color: blue">The blue text

<h3 style="lineHeight='24pt'; fontWeght='bold'; color='blue'">The blue text

Можно также определить класс стилей и использовать его при помощи атрибута CLASS:

 <style type="text/css">

h3.class1 {font-size:12pt;color=blue}

</style>

.....

<h3 class="class1">This is a blue text

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

 <style type="text/css">

all.class1 {font-size:12pt;color=blue}

</style>

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

 <style type="text/css">

all.class1 {font-size:12pt;color=blue}

#C1 { font-size: 20;}

</style>

....

<h3 class="class1">This is a blue text

<h3 class="class1" id="C1">This is a blue text

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

Свойства контейнеров, управляемые описателями стилей

Первую группу свойств составляют свойства шрифтов:

font-size, font-family, font-weight, font-style.

Вторую группу свойств составляют свойства текста:

line-height, text-decoration, text-transform, text-align, text-indent.

Третью группу свойств составляют свойства блоков текста:

margin-left, margin-right, margin-top, margin-bottom, margin, padding-top, padding-right, padding-bottom, padding-left, paddings, border-top-width, border-bottom-width, border-left-width, border-right-width, border-width, border-style, border-color

Четвертую группу составляют описатели цвета фона и цвета текста:

color, background-image, background-color.

Кроме того, существуют свойства определяющие тип пульки у элементов списка и ряд других свойств элементов HTML-разметки.

Способ связывания документа и стилевой таблицы

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

  1.  binding — позволяет пользователю использовать одну стилевую таблицу для форматирования многих HTML страниц;
  2.  implantation — позволяет устанавливать все правила таблицы стилей прямо в документе;
  3.  importing — позволяет встраивать в документ стилевую таблицу, расположенную на сервере;
  4.  embedding в тэти документа— позволяет изменять конкретные элементы страницы.

Мы рассмотрим только binding и implantation.

Bbinding позволяет хранить таблицу стилей в отдельном файле и связывать его с документами при помощи тэга <LINK>, который устанавливается в секции <HEAD>:

< LINK REL = " stylesheet " TYPE = " text/css " HREF = " mystyles.css " >

 Связанный файл, который содкржит множество CSS-правил Cascade, должен иметь расширение CSS.

Implantation стилевой таблицы в документ осуществляется с помощью тэга <STYLE TYPE = “ text/css ”> и </STYLE>, который следует помещать в секции <HEAD> документа:

<HEAD> < STYLE TYPE = " text/css " >

<! --

B {text-transform: uppercase;)

P {background-color: lightgrey;

text-align:center;}

— >

</STYLE> </HEAD>

В этом примере встроенная таблица стилей определяет отображение параграфов документа (элемент P) на сером фоне с центрирование строк. Жирность текста определена другим элементом (тэгом <B>) документа, который будет всегда отображаться заглавными буквами.

Группирование и наследование

Правила Cascade Style Sheets состоят из селектора и определителя. Для сокращения размеров таблиц стилей можно группировать различные селекторы в список элементов HTML страницы, разделенных запятыми, если для них было установлено одно правило.. Например, следующие правила:

H1 {font-family: Arial}

H2 {font-family: Arial}

НЗ {font-family: Arial}

Можно группировать и установить как одно правило с списком селекторов:

H1, H2, НЗ {font-family: Arial}

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

H1 (font-weight: bold) H1 (font-size: 14pt} H1 (font-family: Arial}

Можно установить как одно правило группировнаием определеителей:

H1 {font-weight: bold;

font-size: 14pt;

font-family: Arial;} 

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

Мы сконцентрировали внимание на основных аспектах каскадных таблиц. Рассмотрим пример применения CSS:

<HTML>

<HEAD><TITLE>Example</title>

</head>

<STYLE>

P {font-family:"Impact, sans-serif"; font-size:66; color:red}

P.highlight {color:silver}

P.shadow {color:darkred}

</style>

<BODY BGCOLOR=#408080>

<DIV STYLE="position:absolute; top:5; left:5; width:600; height:100; margin:10">

<P Class=shadow> Effect of the three-dimensional text </p>

</div>

<DIV STYLE="position:absolute; top:0; left:0; width:600; height:100; margin:10">

<P Class=highlight> Effect of the three-dimensional text </p>

</div>

<DIV STYLE="position:absolute; top:2; left:2; width:600; height:100; margin:10">

<P> Effect of the three-dimensional text </p>

</div>

</body>

</html>

6.6.3. JavaScriptJavaScript

Скриптовые языки (JavaScript и VBScript) с помощью Document Object Model позволяют получить доступ и управление всем содержимым HTML страницы. При загрузке HTML страницы в броузер интерпритатор последовательно сверху донизу просматривает страницу и создает объекты со свойствами, определенными значениями параметров тэгов страницы. Созданные объекты существуют в форме иерархической структуры, отражающей структуру HTML страницы. 

Язык скриптов JavaScript был разработан корпорацией Netscape и впервые появился в ее броузере Navigator 2.0. Он появлялся во всех последующих броузерах от Netscape и во всех броузерах от Microsoft начиная с Internet Explorer 3.0 (реалихация этого языка для броузнра Microsoft Internet Explorer называется JScript). В ноябре 1996 началось развитие стандарта ECMAScript. Этот стандарт ECMA базируется на технологиях JavaScript и JScript. Первая редакция стандарта ECMA была принята Генеральной ассамблеей ECMA в июне 1997, вторая – в июне 1998. Существует третья редакция стандарта, который включает мощные регулярные выражения, лучшую обработку строк, новые управляющие предложения, обработку исключительных ситуаций try/catch, более точное определение ошибок, форматирование числового вывода и зеркалированные изменения в приспособливании служб интернационализации и будущему росту языков. Работа над языком еще не завершена. Техническиц комитет работает над сзначительными улучшениями, включая механизмы для скриптов, создаваемыми и используемыми в Интернете и более тесную координацию с другими стандартизирующими коллективами, такими как группы внутри консорциума World Wide Web и Wireless Application Protocol Forum. 

JavaScript это объектно-ориентированный язык развития встроенных приложений, выполняемых как на стороне клиента, так и на стороне сервера. Основные области его использования при создании интерактивных HTML страниц:

  1.  Динамическое создание документа с помощью скрипта (например, идентификация типа и версии броузера для правильного отображения HTML страницы);
  2.  Проверка правильности полей HTML форм, заполненных пользователем, перед передачей их на сервер;
  3.  Создание динамических HTML страниц с использованием Cascade Style Sheets и Document Object Model;
  4.  Взаимодействие с пользователем при решении «локальных» задач, решаемых приложением JavaScript, встроенным в HTML страницу.

6.6.4. Встрооенные сомпоненты: applets и ActiveX

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

Java апплеты

Язык Java позволяет создавать специальные программные компоненты — апплеты, которые предназначены для внедрения в HTML страницы и передаче их на компьютер пользователя, где они выполняются в специальном режиме специальной часть броузера. Апплеты отличаются от скриптов. Апплет есть нечто среднее между программным и машинным кодом. Java – технология имеет мредства промежуточной компиляции в байт-код (некоторое абстрактное предстваление, которое не зависит от архитектуры конкретного компьютера), который комбинирует преимущества объектно-ориентированного языка и независимость от архитектуры. Только этот байт-код записывается в апплет. На основе байт-кода броузер формирует программу для конкретного компьютера.

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

Active X

Элементы управления ActiveX формируются на основе COM - технологиии и представляют собой независимые программные единицы, которые выполняются в определенной среде — в среде программного контейнера. Возможность внедрения их в HTML страницы поддерживантся броузером (Internet Explorer) или специальным модулем к нему (как в Netscape Navigator).

Развитый инструментарий позволяет использовать знакомые програмные системы Microsoft и других производителей для создания компонент ActiveX. Среди них прогаммные средства Visual Basic, Visual C++, Borland Delphi, Sybase, и пр..

Основное отличие ActiveX от скриптовых языков и Java-апплетов состоит в том, что во-первых, компоненты ActiveX выполняются в контексте операционной системы (Windows) и имеют све права пользователяЮ который их запустил.. Во-вторых, компоненты ActiveX устанавливаются на компьютер пользователя только однажды, в то время как Java апплеты загружаются с сервера на клиентский компьютер при каждом авзоае содержащей его HTML страницы.

Внедрение в HTML страницу

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

<OBJECT

ACCESSKEY=key

ALIGN=ABSBOTTOM|ABSMIDDLE|BASELINE|

BOTTOM|LEFT|MIDDLE|RIGHT|TEXTTOP|TOP

BORDER=number

CLASS=class_name

CLASSID=object_ID

CODE=file_name

CODEBASE=URL

CODETYPE=MIME-type

DATA=URL

HEIGHT= number

HSPACE= number

ID=ID

LANG=language

LANGUAGE=JAVASCRIPT | JSCRIPT | VBSCRIPT

NAME=ID

STANDBY=text

STYLE=CSS_rules

TYPE=MIME-type

USEMAP=URL

VSPACE= number

WIDTH= number >

</OBJECT>

Параметры CLASSID (обязательные для элементов управления ActiveX) и CODEBASE напряму касаются ActiveX. Значением CLASSID является уникальный ID встроенного элемента управления ActiveX. При загрузке страницы броузнр проверяет, установлен ли элумент управления на компьютере пользователя, выполняя поиск в системном реестре по данному ID. В случае отсутствия записи в реестре броузер автоматически запускает процедуру загрузки элемента ActiveX с сервера, URL адресс которого указан в парметре CODEBASE parameter тэга <OBJECT>.

Каждая компонета ActiveX открывает свойства и методы для программного контейнера. При включении элемента управления ActiveX в HTML страницу вы можете установить значения его параметров в тэге <PARAM>. Имя свойства и его значение определеяются параметрами NAME и VALUE тэга <PARAM>. 

ПРИМЕР

<OBJECT ID=“MyActiveX” WIDTH=32 HEIGHT=32>

CLASSID=“CLSID:12D3959D-5048-11D3-A272-8C0305C10000”

CODEBASE=“http://someserver.ru/ActiveX/advert32.cab

#version=1,0,0,0”>

<PARAM NAME=“Value” VALUE=“Text”>

<PARAM NAME=“TextColor” VALUE=“green”>

</OBJECT>

Для определения процедуры обработки событий элемента управления ActiveX следует использовать тэг <SCRIPT> с параметрами FOR и EVENT:

<SCRIPT FOR=element_name EVENT= Event LANGUAGE=[JavaScript | VBScript]>

function_of_processing_event

</SCRIPT>

Для внедрения апплетов в HTML документ возможно использование двух тэгов –контейнеров : <APPLET> или <OBJECT>. В HTML спецификации 4.0 название тэга <APPLET> исключено, и рекомедовано использовать более общий тэг <OBJECT>, однако тэг <APPLET> iостается все еще широко распространенным.

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

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

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

6.6.5. Использование апплетов 

Для встраивания вызовов апплетов в текст НТМL-документа и отведения места для отображаемой апплетом информации в НТМL был введен контейнер АРРLЕТ, который начинается тагом <аррlet> и кончается тагом </аррlet>. В общем виде документ, содержащий ссылки на апплеты, будет выглядеть так, как это представлено в примере.

В данном примере после заглавия документа (таг H1) и горизонтальной черты начинается поле апплета шириной 200 пикселей и высотой 100 пикселей. В данное поле загружается аррlet с именем hello (файл hello.class). Текст между тагами начала и конца контейнера аррlet используется для размещения встраиваемых контейнеров и текста, который отображается броузерами, не позволяющими использовать Java.

Пример 6.27

<HTML>

<HEAD>

<TITLE>Документ со встроенной ссылкой на applet.</TITLE>

 </HEAD>

<BODY bgcolor=#FFFFFF>

<CENTER>

 <H1>Документ со встроенным апплетом hello Java</H1>

 <HR>

<APPLET CODE=hello width=200 height=100>

 Аррlet будет отображаться в этом месте, если Ваш браузер интерпретирует Java 

</APPLET>

<HR>

</BODY)

</HTML>

В результате ссылки на такой документ сначала будет загружен текст документа. За тем будет обнаружен контейнер аррlet, и произойдет загрузка кода апплета. Файл hello.class должен в этом случае находиться там же, где и НТМL-файл, в котором есть на него ссылка. После приема апплета браузер отведет под него место в своей рабочей области и только после этого начнет его исполнение.

В общем случае контейнер АРРLЕТ имеет следующий вид:

 <applet

[codebase = codebase url]

code = applet.class

[alt = text]

[name= applet name]

width = number of pixels

height = number of pixels

[align = alignment]

[vspace=number of picsels]

[hspace=number of pixels]

[<param name=param name value=param value>]

 [HTML text]

</applet>

Параметр

соdebase - задает базу для поиска кода апплета,

соdе - это имя файла апплета, которое должно иметь расширение сlass,

аlt - альтернативный текст - отображается в том случае когда выполнение апплета запрещено, name - имя контейнера аррlet, используется для ссылки на контейнер,

widthт - ширина области отображения апплета,

height - высота области отображения апплета,

аlign - управляет выравниванием области отображения апплета внутри рабочей области браузера,

vspase и hspase - указывают на отступ от текста НТМL-документа (вертикальный и горизонтальный, соответственно).

Использование контейнера РАRАМ позволяет передавать параметры внутрь апплета и НТМL-документа. Это аналогично вызову команды с различными аргументами командной строки. Для того, чтобы получить эти параметры внутри апплета, следует использовать метод getParametr ().

Из атрибутов контейнера АРРLЕТ обязательными являются только соdе, width и height Все остальные атрибуты (они заключены в квадратные скобки "[ ]") можно опускать. Большинство систем разработки Java-программ сами генерируют НТМL-документ, точнее его макет, для тестирования Java-апплетов. Так поступают, например, в АDК (Аррlet Development Kit) компании IВМ.

Для получения URL документа, из которого вызван аррlet можно использовать метод getDocumentBase и getCodeBase. Первый определяет базу адреса для документа, в то врeмя как второй определяет базу самого апплета. Применение этих методов необходимо для обращения за данными (текст или графика), которые могут храниться там жe, где и документ аррlet.


7. Управление просмотром страниц Web-узла. JavaScript

Современные гипертекстовые информационные системы условно можно представить в виде совокупности нескольких компонентов: системы хранения гипертекстовых объектов, системы отображения гипертекстовых объектов, системы подготовки гипертекстовых объектов и системы программирования просмотра совокупности гипертекстовых объектов. С этой точки зрения технология World Wide Web только к 1996 году получила законченный, функционально полный вид. Первыми были разработаны системы хранения и просмотра (1989-1991 г.г.), которые продолжают развиваться и в настоящее время. После 1990 года стали появляться первые системы подготовки документов. Наконец, в 1995 году были предложены первые языки управления сценариями просмотра.

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

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

Программы просмотра гипертекстовых страниц традиционно называют скриптами (scripts) по аналогии с исполняемыми файлами, написанными для командных интерпретаторов типа sh. Собственно как это было и раньше в локальных системах, в программировании просмотра гипертекстовых документов World Wide Web существуют два подхода: создание интерпретируемых программой просмотра скриптов или компиляция байт-кода. Первый подход следует традиции World Wide Web, согласно которой для разработки гипертекстовой страницы нужен только обычный текстовый редактор и сам гипертекстовый документ должен легко читаться человеком-оператором. Второй подход позволяет повысить эффективность исполнения программы и защищенность кода от несанкционированных модификаций. Как первый, так и второй способ опираются на объектно-ориентированный подход к программированию. Рассмотрим скрипты, написанные на языке JavaScript.

7.1. Модель объектов JavaScript - объекты Navigator'а

Идея JavaScript очень проста. Все операции, которые можно исполнять в программе на JavaScript, описывают действия над хорошо известными и понятными объектами, которыми являются элементы рабочей области программы Netscape Navigator и контейнеры языка HTML. Собственно объектная ориентированность JavaScript на этом и кончается. Есть только объекты с набором свойств и набор функций над объектами. Последние называются методами. Кроме методов существуют и другие функции, которые больше похожи на функции из традиционных языков программирования и позволяют работать со стандартными математическими типами или управлять процессом выполнения программы. Еще в JavaScript есть события - аналог программных прерываний. Эти события также ориентированы на работу в World Wide Web, например, загрузка страницы в рабочую область Navigator'a или выбор гипертекстовой ссылки. Используя события, автор гипертекстовой страницы и программы ее отображающей может организовать просмотр динамических объектов, например, бегущая строка, или управление многооконным интерфейсом.

7.1.1. Описание иерархии классов

Все встроенные объекты JavaScript берут свое начало от рабочей области Netscape, и их можно представить в виде следующей иерархии (рис. 7.1.).

Рис. 7.1. Иерархия объектов JavaScript.

Кроме этих классов объектов пользователь может создавать и свои собственные. Но обычно большинство программ используют эту систему классов и не создают новых.

7.1.2. Методы объектов и свойства объектов. Управление потоком вычислений

Каждый из этих классов имеет функции управления объектами класса - методы. Самыми главными их этих методов являются те, которые позволяют переназначать значения объектов. Делается это обычно по операции присваивания. Вообще, все типы операторов, которые поддерживаются обычными языками программирования, реализованы JavaScript (+,-,*, /, %, >>,<<, +=, -=, ...). При этом оператор сложения "+" при работе со строками означает конкатенацию последних, т.е. добавление в конец строки новую строку:

 s = "string1"+"string2"

Кроме операций с числами и описаний стандартных классов в JavaScript есть команды управления потоком вычислений:

break - принудительный выход из цикла;

 while(i &lt 6)

{

if(i==3) break;

 }

continue - переход в конец цикла;

 while(i &lt 6)

{

if(i==3) continue;

}

for - цикл;

for(i=0;i<9;i++)

 {

...

}

for - цикл свойств объекта (переменных определенных в классе);

 for(i in obj)

{

str = obj[i]

 }

if..else - условный оператор;

 if(i>0)

{

...

}

 else

{

...

}

wile - условный цикл;

 wile(j==k)

{

 j++;

 k--;

}

var - оператор объявления переменной.

 var kuku = "kuku"

Тип переменной определяется по присвоенному ей значению.

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

7.1. 3. События

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

Не будем перечислять все события, но упомянем о наиболее часто используемых:

  1.  onLoad - выполнение скрипта или функции при загрузке;
  2.  onChange - порождается при изменении значения элемента формы;
  3.  onClick - порождается при выборе объекта (button, checkbox и т.п.);
  4.  onSelect - порождается при выборе текстового объекта (text, textarea);
  5.  onSubmit - при нажатии на кнопку Submit;
  6.  onUnload - при переходе к другой странице.

В новой версии языка JavaScript были введены: возможность взаимодействия JavaScript и Java, определение установленных plug-ins, определены новые типы объектов (Area, Function, Image) и ряд других особенностей, которые, по мнению разработчиков, должны повысить мощь программирования на JavaScript.

7.1. 4. Массивы

Первый тип новых объектов, которые мы рассмотрим, являются массивы. Тип "Array" введен в JavaScript 1.1 для возможности манипулирования самыми разными объектами, которые отображаются Navigator'ом. Это - список всех гипертекстовых ссылок данной страницы Website, список всех картинок на данной странице, список всех applet'ов данной страницы, список всех элементов формы и т.п. Пользователь может создать и свой собственный массив, используя конструктор Array(). Делается это следующим образом:

new_array = new Array()

new_array5 = new Array(5)

colors = new Array ("red","white","blue")

Размерность массива может динамически изменяться. Можно сначала определить массив, а потом присвоить одному из его элементов значение. Как только это значение будет присвоено, изменится и размерность массива:

 colors = new Array()

colors[5] = "red"

В данном случае массив будет состоять из 6 элементов, т.к. первым элементом массива считается элемент с индексом 0. Для массивов определены три метода: join, reverse, sort. Join объединяет элементы массива в строку символов, в качестве аргумента в этом методе задается разделитель:

 colors = new Array("red","white","blue")

string = acolors.join("+")

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

 string = "red + white + blue"

Другой метод, reverse, изменяет порядок элементов массива на обратный, а метод sort отсортировывает их в порядке возрастания. У массивов есть два свойства: length и prototype. Length определяет число элементов массива. Если нужно выполнить некоторую рутинную операцию над всеми элементами массива, то можно воспользоваться циклом типа:

 color = new Array("red","white","blue")

n = 0

while(n != colors.length)

 {.... операторы тела цикла ...}

Свойство prototype позволяет добавить свойства к объектам массива. Однако наиболее часто, в программе на JavaScript используются встроенные массивы, главным образом графические образы (Images) и гипертекстовые ссылки (Links).

7.1.5. Графика

До Navigator 3.0 в JavaScript использовались только встроенные объекты типа Image. В новой версии языка появился конструктор для этого типа объектов:

 new_image = new Image()

new_image = new Image (width,height)

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

 img_array = new Array()

img_array[0] = new Image(50,100)

img_array[1] = new Image(50,100)

....

img_array[99] = new Image(50,100)

У объекта Image существует 10 свойств, из которых, пожалуй, самым важным является src. Так, для присваивания конкретных картинок элементам массива img_array следует воспользоваться следующей последовательностью команд:

 img_array[0].src = "image1.gif"

img_array[1].src = "image2.gif"

...

img_array[99].src = "image100.gif"

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

<img name=car src=car.gif> <--- Встроенный в документ объект

 document.car.src = "car1.gif"

 

<form name=kuku>

<img name=car src=car.gif> <-- Встроенный в форму окумент.

</form>

document.kuku.car.src = "car1.gif"

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

 document.images[1].src = "car1.gif"

Расширяя наш пример с массивом Image, построим теперь документ, в котором будет встроена мультипликация, определенная нашим массивом:

Пример 7.1

<HTML>

<HEAD>

<SCRIPT>

function multi_pulti()

{

img_array = new Array()

img_array[0] = new Image(50,100)

....

img_array[99] = new Image(50,100)

img_array[0].src = "image1.gif"

...

img_array[99].src = "image100.gif"

n=0

while(n==0)

{

document.images[0].src = img_array[0].src

...

}

}

</SCRIPT>

</head>

<body onLoad="multi_pulti()">

<img src=image1.gif>

 </body>

</html>

Довольно часто используют не мультипликацию, а выбор картинки через OPTION, другой новый объект JavaScript. При этом можно через поле формы SELECT менять не только саму картинку, но и гипертекстовую ссылку, которая может быть связана с этой картинкой. На гипертекстовую ссылку также можно ссылаться по индексу:

 document.links[index].href = kuku.html

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

7.1.6. Стеки гипертекстовых ссылок

Не обошли своим внимание авторы JavaScript и стеки гипертекстовых ссылок. В язык теперь введен новый тип объектов типа Area. Area - это элемент контейнера MAP, который определяет client-site imagemap. Собственно, главное достоинство такого объекта состоит в том, что гипертекстовые ссылки, которые определены в AREA, стали доступны для переопределения. Они появляются в массиве обычных ссылок страницы, и можно как получить значение URL, так и переопределить его. К объекту AREA нельзя обратиться по имени. Можно использовать то