Веб Дизайн - статьи

         

Оставляйте выбор за пользователем


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

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

has been designing Websites for over 6 years and has used his knowledge to create a HTML reference center for everyone's skill level. For information or HTML help contact:   or visit

Перевод - Webmasterpro.com.ua - вопросы веб-дизайна и оптимизации сайта в поисковых системах: статьи, советы, рекомендации.



От слов к делу - установка Apache


"У меня для вас две новости: плохая и хорошая. Плохая: мяса
мало, будем есть бизоний помет. И хорошая: его-то у нас много!.."

Из выступления вождя апачей

Итак, Вы решились установить на свой компьютер Apache для Windows 95/98. В таком случае Вам следует запастись терпением и для начала скачать дистрибутив сервера - файл с именем (3.061.629 байт). Скачали? Прекрасно. Теперь самое интересное - настройка Apache для Вашей системы.

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

Этап первый - установка

Определитесь с директорией, в которую Вы будите устанавливать Apache. Все дальнейшие рассуждения основаны на том, что Вы выбрали для этой цели такой каталог: f:\usr\local\apache Если диска F: у Вас нет, или если Вы не хотите его захламлять, советуем сделать одно из трех:

Создайте диск F: с помощью какой-нибудь программы для виртуальных разделов (например, с помощью встроенной в Windows 95/98 программы DriveSpace). Это самое лучшее решение, и с точки зрения экономии памяти, и с точки зрения быстродействия. Ведь что такое Web-сайт, как не набор очень небольших файлов? А DriveSpace как раз и оптимизирует работу с такими файлами. Сделайте виртуальный диск F:. Для этого создайте где-нибудь на любом диске директорию, которая в будущем будет являться корневой для диска F:. Предположим, Вы выбрали C:\INTERNET. Далее, в начале файла c:\autoexec.bat пропишите такую строку: subst f: C:\INTERNET

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

ВНИМАНИЕ: имеются сведения, что в Windows 95/98 есть ошибка, в результате которой иногда subst-пути "сами по себе" преобразуются в абсолютные. То есть, например, иногда в рассмотренном выше примере команды

f: cd \ cd \ dir

(а точнее, команда dir в своем заголовке) ошибочно выведут, что текущая директория C:\ (а не F:\, как это должно быть). Указанная ошибка чаще всего проявляется в неработоспособности Perl-транслятора.


Так что лично мы не рекомендуем Вам использовать subst. Вместо этого воспользуйтесь пунктом 1.



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

Рекомендуем все же разместить Apache в указанном в начале каталоге, так как он максимально соответствует каталогу для реального Web-сервера Интернета. Ведь чем ближе в плане конфигурации мы будем к такому серверу, тем лучше и эффективнее сможем работать.

Запустите только что скачанный файл. В появившемся диалоге нажмите кнопку Yes, а затем - кнопку Next. Теперь нажмите Browse. Вручную задайте директорию для установки: f:\usr\local\apache и нажмите кнопку OK. Выберите тип установки - Сustom и уберите флажок Source Code (если, конечно, не хотите посмотреть исходные тексты Apache). Этим Вы сэкономите себе 3 Мбайта. Нажмите Next и подождите, пока будут копироваться файлы Apache. На запрос о перезагрузке компьютера ответьте "Перезагрузить".

Поздравляем - Apache установлен! Теперь самое неприятное - его настройка.

Этап второй - настройка файла конфигурации Apache mime.types

Откройте директорию f:\usr\local\apache\conf. Откройте находящийся там файл mime.types. Найдите в нем такую строчку: text/html html htm

Измените ее на text/html html htm shtml shtm sht

Следует заметить, что если Вы по каким-то причинам не хотите портить файл mime.types, то можно вместо этого прописать в файле httpd.conf (см. ниже) строки вида AddType text/html html htm shtml shtm sht

Этап третий - настройка файла httpd.conf

Внимание! Это - самый ответственный момент установки. Просим соблюдать инструкции БУКВАЛЬНО.

Откройте директорию f:\usr\local\apache\conf Откройте находящийся там файл httpd.conf. Это - единственный файл, который Вам осталось настроить. Вам предстоит найти и изменить в нем некоторые строки, а именно те, о которых упоминается далее.


Во избежание недоразумений не трогайте все остальное. Следует заметить, что в нем каждый параметр сопровождается несколькими строками комментариев, разобраться в которых с первого раза довольно тяжело. Поэтому не обращайте на них внимание. В поле ServerAdmin укажите Ваш E-mail адрес, который будет показываться в сообщениях об ошибке сервера. Например: ServerAdmin my@email.com

В поле ServerName напишите любое слово - на работе это не сказывается, например: ServerName ApacheServer

Только не забудьте раскомментировать поле ServerName, то есть убрать символ "#" перед этим параметром (по умолчанию он закомментирован)!

В поле DocumentRoot укажите ту директорию, в которой будут храниться Ваши html-файлы, например: DocumentRoot f:/www

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

Найдите блок, начинающийся строкой <Directory /> и заканчивающийся </Directory> (вообще, такие блоки обозначают установки для заданной директории и всех ее поддиректорий). Его нужно изменить на: <Directory /> Options Indexes Includes AllowOverride All </Directory>

Таким образом, в этом блоке будут храниться установки для всех директорий по умолчанию (т.к. это - корневая директория).

Найдите аналогичный блок, начинающийся <Directory "f:/usr/local/apache/htdocs"> и заканчивающийся </Directory>. Там будет много комментариев, не обращайте на них внимание. Этот блок следует заменить на: <Directory "f:/www"> Options Indexes Includes AllowOverride All Order allow,deny Allow from all </Directory>

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

Идем дальше. Установите UserDir, например так: UserDir f:/home

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


ниже). Не забудьте также создать этот каталог.

Установите DirectoryIndex так: DirectoryIndex index.htm index.html

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

Найдите и пропишите такой параметр: ScriptAlias /cgi-bin/ "f:/cgi-bin/"

Да, именно так, с двумя слэшами. Это будет та директория, в которой должны храниться Ваши CGI-скрипты. Если хотите, можете задать другое имя, например: ScriptAlias /mycgi/ "f:/mycgidir/"

Подобный параметр говорит Apache о том, что, если будет указан путь вида http://localhost/cgi-bin, то на самом деле следует обратиться к директории f:/cgi-bin.

Теперь следует найти и настроить блок параметров, начинающийся с <Directory "f:/cgi-bin"> и заканчивающийся </Directory>. Это - установки для Вашей CGI-директории (если Вы установили для нее другое имя на предыдущем шаге, соответственно модифицируйте путь). Там должно быть: <Directory "f:/cgi-bin"> AllowOverride All Options ExecCGI </Directory>

Настройте следующий параметр: AddHandler cgi-script .bat .exe

Это говорит Apache о том, что файлы с расширением .exe и .bat

нужно рассматривать как CGI-скрипты.

И последнее - установите: AddHandler server-parsed .shtml .shtm .sht

Или, если Вы хотите, чтобы и обычные файлы html обрабатывались SSI, напишите так: AddHandler server-parsed .shtml .shtm .sht .html .htm

Поздравляем - Вы настроили свой Apache, и он должен уже работать! Для запуска сервера нажмите Пуск->Программы->Apache Web Server->Start Apache as console app, при этом появится окно, очень похожее на Сеанс MS-DOS, и ничего больше не произойдет. Не закрывайте его и не трогайте до конца работы с Apache.

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


Так что щелкните правой кнопкой на панели задач, в контекстном меню выберите Свойства, затем Настройка меню и кнопку Дополнительно. В открывшемся Проводнике назначьте ярлыку Start Apache as console app комбинацию Ctrl+Alt+A, а ярлыку Shutdown Apache as console app - Ctrl+Alt+S

Вот шаги, которые можно проделать для проверки работоспособности сервера:

Проверка html: в директории f:/www с html-документами Apache создайте файл index.html. Теперь запустите браузер и наберите:

http://localhost/index.html

или просто http://localhost/

Загрузится Ваш файл.

Проверка CGI: в директории f:/cgi-bin для CGI-скриптов создайте файл test.bat с таким содержанием:

@echo off echo Content-type: text/html echo. echo. dir

Теперь в браузере наберите: http://localhost/cgi-bin/test.bat

В окне отобразится результат команды DOS dir. (Хотелось бы отметить, что указанный тест работает не на всех версиях Windows: иногда вместо того, чтобы выполнить файл test.bat, Apache выводит в браузер его содержимое. С чем это связано - не совсем ясно, однако, кажется, можно избавиться от указанной ошибки путем манипулирования с Реестром. Если у Вас test.bat не запускается, не расстраивайтесь: вряд ли Вы когда-нибудь будете писать скрипты в виде bat-файлов, тем более, что это несовместимо с Unix.)

Проверка SSI: аналогична проверке html. Используйте, например, директиву <!--#include virtual="/cgi-bin/test.bat"-->

Если bat-файлы Ваш Apache запускать не хочет (см. выше), то дождитесь установки Perl или PHP.

Если что-то пошло не так, либо окно Apache открывается и тут же закрывается, значит, где-то произошла ошибка - скорее всего, в httpd.conf. За детальным разъяснением ее причин можно обратиться к log-файлам, расположенным в директории f:/usr/local/apache/logs.


ОТКАЗ ОТ DTD


В том, что касается отображения отраслевых данных, BizTalk исходит из бесперспективности определений типов документов (Document Type Definition, DTD). Вместо того чтобы поощрять разработку XML DTD, сторонники BizTalk описывают свои иерархии данных с помощью XML Schema (как предполагается, этот стандарт должен прийти на смену DTD). «DTD свойственны некоторые внутренние ограничения, — поясняет Шмидт. — Поэтому многие люди и группы предлагают свои решения».

В настоящее время W3C пытается согласовать различные подходы к схемам, но предложенная версия стандарта — XML Schema — дает достаточно ясное представление о том, как будет выглядеть замена DTD. XML Schema имеет значительно более широкие возможности, нежели DTD, причем описания даются с помощью непосредственно XML, без создания еще одной системы разметки, как того требует DTD (см. врезку «Новая схема»).

На общем уровне BizTalk Framework требует, чтобы издатели XML Schema придерживались определенных рекомендаций, большая часть которых основывается на общепринятой практике разработки программного обеспечения. Так, тегам предлагается давать осмысленные имена с понятным несокращенным написанием; эти имена должны соответствовать функциональному назначению информации, а не ее месту в частной структуре данных (например, “PartLocation” вместо “PartFieldFourteen”), а содержащаяся в теге информация не должна требовать специального, отличного от XML, декодирования (например, обозначение валюты денежной суммы должно храниться в виде элемента XML, а не присоединяться к сумме как в “$30US”). Эти рекомендации призваны облегчить жизнь тем, кто будет пытаться дешифровать конкретную схему.

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




Так что же делают эти теги? Один из них определяет код, с помощью которого принимающая данные в формате XML программа может установить, что за схема BizTalk используется. С помощью других тегов приложение может выяснить, кто является отправителем данных, что отправитель от него хочет и кому данные должны быть потом переданы. «Точно так же на основании информации на конверте почта определяет, как следует поступать с письмом, при этом ей нет никакого дела, что и в каком виде он содержит», — поясняет Шмидт.

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

<Route> <From locationID=”11111111” locationType=”DUNS” process=”” path=”” handle=”3”/> <To locationID=”222222222” locationType=”DUNS” process=”” path=”” handle=”23CF15”/> </Route>

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

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

Общий формат полного сообщения BizTalk показан во врезке «Анатомия сообщения BizTalk».


Относящиеся к XML стандарты и рекомендации

Hypertext Markup Language (HTML) Формализован в RFC 1866. См. .
Standard Generalized Markup Language (SGML) Стандарт ISO 8879 за 1986 год. См. .
Document Object Model (DOM) См. .
Extensible Stylesheet Language (XSL) Рабочий проект консорциума A World Wide Web (W3C). См. .
Extensible Markup Language (XML) Рекомендация W3C. См. .
Пространства имен Еще одна рекомендация W3C. См. .
Extensible Linking Language (XLL) Рабочий проект W3C (см. ), он описывает, как сделать ссылки многонаправленными, и определяется на уровне объектов, а не страниц.
Extensible HTML (XHTML) Переопределение HTML 4.0 в качестве приложения XML. Подробности см. в рабочем проекте W3C на .
Схемы XML Призваны заменить Document Type Definitions (DTDs). См. рабочий проект W3C на .



Параметр 'charset'


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

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

Дополнительно к предопределенным новые языковые кодировки могут быть зарегистрированы через IANA, хотя стандартизация их использования требует опробирования IESG (см. RFC-1340). Если используется 8-битная языковая кодировка (например, koi8 или cp866), то необходимо наличие поля заголовка Content-Transfer-Encoding для обеспечения передачи через ряд протоколов, в частности, SMTP.

Необходимо заметить, что управляющие символы (0-31, 127), включая DEL, не имеют определенного значения за исключением последовательности CRLF (13,10), означающей конец строки. Два символа де-факто широко употребляются: FormFeed (12), означающий, что следующий за ним текст должен начинаться на новой странице; и TAB (9), часто, но не всегда означающий "перевести курсор на следующий ближайший столбец после данной позиции, где номер столбца кратен воьсми". Любое другое использование управляющих символов или DEL в теле должно быть в рамках частного соглашения между отправителем и получателем. Но такие соглашения крайне не рекомендуются и по возможности должны быть заменены другими возможностями MIME.

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

US-ASCII

ISO-8859-X -- где "X" - цифра от 1 до 9 включительно, означающая номер версии кодировки ISO-8859

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

Почтовое программное обеспечение должно руководствоваться принципом наименьшего набора символов, то есть, если письмо пишется как-бы в восьмибитной ISO-8859-1, но в письме используются символы лишь некоторого поднабора, например, семибитного US-ASCII, то почтовая программа должна автоматически определить имя символьной кодировки как US-ASCII. В этом случае уменьшится нагрузка в сети и увеличаися шансы, что получатель прочтет письмо без искажений.



Перегрузка системы


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

Для ускорения этого процесса созданы специальные решения, представляющие собой дополнительные модули для Web-сервера Apache — mod_fastcgi и mod_perl.

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

Модуль mod_perl позволяет загрузить Perl в оперативную память в то же адресное пространство, что и сам Web-сервер Apache, и оставить Perl в памяти до завершения работы последнего, не позволяя загружать очередную копию интерпретатора при обращении к CGI-программе. Этот модуль применяется чаще, чем FastCGI, поскольку не требует никаких изменений в программе.



ПЕРВЫЕ ПРИЛОЖЕНИЯ


Как только стало ясно, что XML хорошо подходят для CIM, а спецификации XML стали приобретать законченный вид, Manage.Com () удалось вырваться вперед и на голову опередить весь остальной рынок благодаря тому, что компания раньше всех решила реализовать продукты на базе CIM и XML. Frontline e.M, главный продукт компании, имеет клиент на базе браузера для мониторинга, контроля, конфигурации и диагностирования компонентов бизнес-процессов и транзакций, даже если они осуществляются через брандмауэр или VPN.

Серверное программное обеспечение e.M выполняется на сервере Web и способно автоматически обнаруживать сервисы, приложения и устройства IP. Оно контролирует, конфигурирует и сопоставляет данные от управляемых объектов. Кроме того, оно отвечает за извещение о проблемах, составление отчетов и реализацию правил. Управляемые объекты, информация об их взаимоотношениях и профили контроля доступа для пользователей хранятся в базе данных Frontline e.M (или в имеющейся базе данных организации).

Устройства и процессы, мониторинг и управление которыми следует реализовать, могут быть оснащены e.Agents — агентами на базе Java, распространяемыми защищенным образом с помощью SSL или по VPN. Сервер e.M также может запрашивать управляющие данные от SNMP и других источников.

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

Самым новаторским компонентом архитектуры Manage.com является e.Registry. Manage.com характеризует e.Registry как портал управления. e.Registry является хранилищем схем с описаниями управляемых объектов, правил конфигурации и информации о диагностике, производительности и загруженности сервисов (таких, как электронная почта), устройств (таких, как брандмауэр) и приложений (таких, как обработка заказов). Серверы e.M могут обновлять свои возможности регулярно или по требованию, потому что и e.M, и e.Registry базируются на CIM и потому, что благодаря XML они могут обмениваться структурированной информацией по Internet.


По сути, e. Registry представляет собой набор DTD, к которому может обращаться любой сервер e.M. После модификации старых элементов и добавления новых на сервере e.Registry компании Manage.Com пользователи могут загрузить и использовать их.

Хотя Frontline e.M способен выполнять многие из задач, решаемых традиционными продуктами для управления сетями и системами, Manage.Com не считает свой продукт панацеей от всех бед управления. Главная роль, на которую он предназначен, — это контроль за относительно небольшим числом критических бизнес-процессов, перебои в работе которых недопустимы, и управление ими из конца в конец, возможно, в соответствии с соглашениями об уровне сервиса. Frontline e.M не столь хорошо подходит на роль основного приложения для корпоративного центра управления сетью, как продукты наподобие HP OpenView, к тому же он не пригоден для выполнения таких задач, как распространение программного обеспечения или управление корпоративной системой хранения, как продукты наподобие CA Unicenter.

Хотя Frontline e.M и не претендует на место универсальной платформы управления, Manage.Com заключила партнерские соглашения с двумя другими компаниями, что увеличивает полезность модели CIM-XML-HTTP. Top Layer Networks () производит коммутатор с классификацией и приоритезацией трафика — AppSwitch 2000. Эта компания собирается использовать manageXML — расширенную инфраструктуру XML компании Manage.Com — в качестве базового транспорта управляющей информации. Таким образом, интерфейс управления для AppSwitch 2000 будет предоставляться Frontline e.M.

Пользователи AppSwitch 2000 — а они, как правило, принадлежат к IP-центрическому миру, для которого Manage.Com предназначает свои предложения, — могут получить обновленное программное обеспечение управления элементами через e.Registry, а устройства AppSwitch 2000 будут без труда интегрироваться в экосистему Frontline e.M/WBEM. Кроме того, пользователи AppSwitch 2000 получат в свое распоряжение функции автоматической диагностики Frontline e.M.



Другой партнер Manage.Com — компания Data Channel () — специализируется на инструментарии разработки, технологиях и обучении XML. Data Channel взяла на себя обязательство разработать экспертные методики, с помощью которых заказчики Manage.Com могли бы создавать документы manageXML, т. е. свои собственные расширения для среды Frontline e.M. Например, эксперты могли бы использоваться для контроля доступа пользователей, определения политики приоритетов и включения происходящих в компании событий в систему управления.

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

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

Стив Штайнке — главный редактор Network Magazine. С ним можно связаться по адресу: .


Почему была написана эта заметка


Internet Information Server ( IIS ) под Windows NT является сейчас вторым ( после Apache ) по популярности web-сервером. Можно привести ряд аргументов в пользу того или иного выбора - Apache или IIS - это предмет отдельного разговора, выходящего за рамки данной заметки. Так или иначе, я столкнулся с задачей установки PERL для IIS3 под Windows NT. Цель данной операции вполне понятна: PERL в настоящее время - наиболее популярный язык автоматизации web-сервера. На нем написана масса полезных скриптов, всевозможных счетчиков, программ приема заявок, и многое другое. Хотелось бы уметь адаптировать все это под IIS, да и свои скрипты хотелось бы уметь писать так, чтобы они с минимальными изменениями годились для любого web-сервера. Значит, их стоит писать не на BASIC, а скорее на PERL.

Итак, хорошо бы поставить PERL на IIS под NT. Лезем в Интернет, выясняется - это интересует многих, и это таки-можно сделать : есть кампания Active State ( www.activestate.com ), которая разработала поддержку PERL для IIS; все, что для этого требуется, можно с ее сервера бесплатно скачать. А в качестве руководства к действию - читайте FAQ , который поддерживает некто Evangelo Prodromou. Замечательно.

Теперь можно обяснить цель появления данной заметки. Как выяснилость на практике, указанный выше FAQ от Evangelo Prodromou , на который много ссылок в разных местах, весьма мало пригоден как начальное руководство к действию по установке PERL для IIS. В нем есть много полезных сведений, тонкостей, но вот простой и внятной инструкции : делай раз, делай два, делай три - и твой первый скрипт типа "Здравствуй, ПЕРЛ" заработает на IIS- там нет. Что и привело в нашем случае к изрядной потере времени.Именно попытка создания такой простой инструкции и есть предмет данной заметки.

То, о чем дальше будет говориться, проверено уже не один раз для IIS3. Вероятно, все это верно и для версий IIS4 и IIS2, но сам я этого не проверял.



Почему динамические сайты лучше


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



Почтовый стандарт MIME (RFC1521)


при поддержке

Документ предсталяет собой неполный русский перевод спецификации RFC 1521 "MIME - Multipurpose Internet Mail Extensions. Part one. Mechanismes for Specifying and Describing the Format of Internet Message Bodies".

Автор перевода: Антон Воронин

MIME означает "Multipurpose Internet Mail Extensions" (Многоцелевые расширения почтового стандарта Internet). Этот стандарт описывает как пересылать по электронной почте исполняемые, графические, мультимедийные, смешаные данные. Типичные применения MIME - пересылка графических изображений, аудио, документов Word, программ и даже просто текстовых файлов, то есть, когда важно, чтобы входе пересылки не производилось никаких преобразований над данными. MIME также позволяет размечать письмо на части различных типов так, чтобы получатель (почтовая программа) мог определить, что делать с каждой из частей письма.

Как читать письма в стандарте MIME? Т.к. MIME используется всего несколько лет, еще существуют старые почтовые программы, которые не понимают MIME. Однако, растет число почтовых программ, имеющих встроенную поддержку MIME (одна из самых популярных - "Pine", разработанная в Вашингтонском университете и реализованная для платформ UNIX, VMS, DOS, Windows). К тому же в некоторых почтовых системах имеются специальные шлюзы, обеспечивающие MIME-трансляцию. Но даже если у вас нет возможности использовать MIME-совместимую почтовую программу и нет доступа к подобному шлюзу, то можно также воспользоваться рядом программ, способных интерпретировать письма в MIME, сохраненные рпочтовой программой в файле. Например, програма "munpack", созданная в университете Carnegie Mellon. Существуют ее версии для Unix, PC, Macintosh, Amiga.

Долгое время для кодирования бинарных файлов в 7-битный формат (чтобы обеспечить их пересылку по почтовой системе Internet) использовалась кодировка UUENCODE, имеющая ряд технических ограничений. Стандарт MIME предполагает использовние более устойчивой кодировки "Base64", которая специально разработана для обеспечения сохранности данных, пересылаемых по email, при различных преобразованиях, имиеющих место в ходе прохождения почтовых шлюзов.

Стандарт MIME полностью описан в RFC-1521



Поддержка кросс-платформенности.


В ближайшем будущем Curl Corporation собирается адаптировать данную технологию под MacOS, а также поддерживать PDA, мобильные телефоны и любые устройства имеющие возможность подключения к Internet. Такой подход во многом облегчит создание ресурсов по принципу "однажды создав приложение, запускай его в не зависимости от той ОС на которой работает пользователь". Компания предоставляет Just-In-Time (JIT) компилятор с помощью которого формируется код, предоставляющий возможность клиентской платформе самой решать в каком виде и на каком устройстве отображать информацию. JIT компилятор интерпретирует код в то, что хочет достичь разработчик и производит необходимые уточнения приводя код в сответствие правилам стандарта.



Поддержка политики Open Source.


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



Поддержка XML.


В среду Surge встроен стандартный XML SAX интерпретатор, позволяющий клиентской части технологии работать как презентационному слою для XML данных совместимых с SAX 2.0 API. Поддержка интерпретатора DOM, так же как и других связанных с XML технологий, будет реализована в новых версиях среды.



Подготовка к работе


Для запуска Perl-программ понадобится интерпретатор Perl версии 5.005 или 5.6 дистрибутивов Perl Standard или ActiveState Perl для UNIX или Win32. Если вы будете заниматься разработкой приложений для функционирования под Win32, то пакет от ActiveState несколько удобнее в использовании, к тому же в него входит утилита PPM для установки дополнительных модулей.

Для организации взаимодействия наших Perl-программ с СУБД MySQL необходимо, чтобы в поставку Perl входил модуль DBI. Поскольку модуль в основном ничего сам не делает, а перекладывает все операции по взаимодействию с базами данных на соответствующий им драйвер, то требуется установка библиотеки DBD-Mysql (драйвер к БД MySQL для модуля DBI). Как заявил Тим Бьюнс (Tim Bunce), автор и разработчик указанного модуля, «DBI — это API-интерфейс для организации доступа к базам данных из Perl-программ. Спецификация DBI API определяет набор функций, переменных и правил, используемых для прозрачного интерфейса с базами данных».

Концепция драйверов баз данных весьма удобна, поскольку в своем Perl-приложении вы используете стандартные для DBI вызовы, которые затем переадресуются модули соответствующему драйверу, а тот, в свою очередь, уже напрямую будет взаимодействовать с БД, не требуя от вас изучения технических особенностей каждой конкретной СУБД. Таким образом, существуют драйверы DBD::Sybase, DBD::Oracle, DBD::Informix и т.д. (рис. 1, 2).

Рис. 1. Архитектура DBI

Рис. 2. Поток данных через интерфейс DBI

Немного выйдем за рамки тематики статьи. Допустим, что в поставку DBI не входит драйвер для специфической СУБД. В данном случае на помощь придет мост DBD-ODBC. Достаточно создать новый источник данных (Data Source Name) для драйвера ODBC (Open DataBase Connectivity), где нужно выбрать тип этой СУБД, адрес хоста, по которому надо установить соединение, имя базы данных и авторизационные данные, то есть имя пользователя и пароль (рис. 3). И затем, используя модуль DBI, взаимодействовать с базой данных. Кроме того, как правило, в стандартную поставку ActiveState Perl входит модуль Win32::ODBC (Win32-ODBC).


Работа с ним немного отличается от работы с DBI, но в целом очень похожа. Разница лишь в том, что Win32::ODBC — модуль только для Win32-систем и позволяет работать с «родными» функциями ODBC более эффективно, чем DBD::ODBC.



Рис. 3. Добавление нового источника данных через ODBC-администратор

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

Для установки DBI и DBD-Mysql, с помощью утилиты PPM в среде Win32 введите в командной строке:

ppm install DBI

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

ppm help install

Для пользователей UNIX-систем установка модуля DBI будет проходить практически так же, как и установка других Perl-модулей:

tar –zxvf DBI-1.06.tar.gz cd DBI-1.06/ perl Makefile.PL make make test make install

Можно также воспользоваться оболочкой CPAN. Если же на вашем компьютере установлена UNIX-версия пакета от ActiveState, то можно работать и с установочной утилитой PPM. Иногда бывает, что оболочки CPAN и PPM не функционируют, если в сети предприятия, к которой подключен ваш компьютер, установлен брандмауэр, или сетевой экран (firewall). В данном случае вам помогут только модули с исходными текстами, загруженные вручную. Для их установки и подключения к Perl или Apache потребуется интерпретатор Perl, компилятор C/C++ или GCC/PGCC и какая-либо из утилит-сборщиков make (из поставки одного из клонов UNIX, а также Microsoft Visual C++), nmake или dmake. Таким образом, процедура установки модулей несколько усложняется. Почти с каждым из них поставляется документация по «сборке», благодаря которой у вас не должно возникнуть особых трудностей.


Подтип 'Application/PostScript'


Тип "application/postscript" означает, что пересылается PostScript-документ и требует специальной программы для его обработки. В настоящий момент используются два языка - level 1 и более поздний - level 2.

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

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



Подтип 'Message/External-Body'


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

Письмо (часть письма) этого подтипа состоит из заголовка, двух последовательных концов строки и заголовка вложенного письма. Если встречается другая пара концов строки, она означает конец заголовка вложенного письма. Однако, поскольку тело вложенного письма является внешним, оно не следует за концом заголовка. Например, Content-type: message/external-body; access- type=local-file; name="/u/nsb/Me.gif" Content-type: image/gif Content-ID: <id42@guppylake.bellcore.com> Content-Transfer-Encoding: binary ТЕЛА НЕТ!

Область в конце, которую можно назвать "призрачным телом", игнорируется для большинства писем подтипа 'external-body'. Однако, в нее можно помещать дополнительную информацию, как например, в случае, когда параметр 'access-type' равен "mail-server". Во всех остальных случаях призрачное тело игнорируется.

Единственный всегда обязательный параметр для 'message/external-body' - "access-type". Остальные параметры могут быть или не быть обязательными в зависимости от значения параметра "access-type".

Значение этого параметра - слово, нечувствительное к регистру букв, означающее механизм доступа, с помощью которого файл или данные могут быть получены. Значения могут быть следующими (но не ограничиваются этим рядом): "FTP", "ANON-FTP", "TFTP", "AFS", "LOCAL-FILE" и "MAIL-SERVER". Будущие возможные значения, кроме экспериментальных, начинающихся с "X-", должны быть зарегистрированы в IANA.

Дополнительно, следующие три параметра являются необязательными для всех способов доступа:

EXPIRATION -- Дата (RFC 822 "date-time" синтаксис допускает 4 цифры в этом поле), после которой существование внешних данных не гарантируется.

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


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

PERMISSION -- нечувствительное к регистру букв поле, говорящее о том, ожидается или нет, что клиент может перезаписывать данные. По умолчанию или когда этот параметр имеет значение "read", полагается, что клиент не имеет на это права, и что если данные однажды считаны, то больше они не понадобятся. Если PERMISSION имеет значение "read-write", любая локальная копия может рассматриваться не более как кэш. "read" и "write" - единственные предопределенные значения для PERMISSION.

Вложенные заголовки во ВСЕХ телах типа message/external-body ДОЛЖНЫ включать поле заголовка Content-ID для задания уникального идентификатора, указывающего на внешние данные.

Обозначения, описывающие данные типа external-body, такие как имена файлов или команды mail-сервера, должны быть в символьном наборе US-ASCII.

Как и для типа message/partial, тело типа message/external-body должно иметь значение content-transfer-encoding "7-bit" (по умолчанию). В частности, даже в системах, поддержиавющих 8-битный транспорт, применение content-transfer-encoding "8-bit" и "binary" запрещено для данных типа message/external-body.


Подтип 'message/partial'


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

Для этого подтипа необходимо указание трех параметров:

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

"number" - целое число, означающее номер части послания.

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

Пример: часть 2 3-х частного послания имеет следующие варианты заголовка: Content-Type: Message/Partial; number=2; total=3; id="oc=jpbe0M2Yt4s@thumper.bellcore.com" Content-Type: Message/Partial; id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; number=2

Но часть 3 обязательно должна содержать параметр "total": Content-Type: Message/Partial; number=3; total=3; id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

Необходимо заметить, что нумирация частей начинается с 1, а не с 0.

Когда подобным образом разбитые части собираются вместе, они образуют полное MIME-письмо, содержимое которого может иметь любой другой тип и, соответственно, свое поле заголовка Content-Type, описывающее этот тип.

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

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

Все поля заголовка части 1, кроме начинающихся с "Content-" и специальных "Message-ID", "Encrypted" и "MIME-Version" должны быть скопированы в заголовок нового (общего) письма.




Только поля заголовка ВЛОЖЕННОГО письма, начинающиеся с "Content-", а также поля "Message-ID", "Encrypted" и "MIME-Version", должны быть добавлены к заголовку нового общего письма, все остальные поля должны игнорироваться.

Заголовки второй и последующих частей целиком игнорируются.

Например, если письмо с аудио-данными было разбито на две части, первая из них может выглядеть следующим образом: X-Weird-Header-1: Foo From: Bill@host.com To: joe@otherhost.com Subject: Audio mail Message-ID: <id1@host.com> MIME-Version: 1.0 Content-type: message/partial; id="ABC@host.com"; number=1; total=2 X-Weird-Header-1: Bar X-Weird-Header-2: Hello Message-ID: <anotherid@foo.com> MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64 ... здесь имеет место быть первая часть закодированных аудио-данных ...

А вторая может выглядеть так: From: Bill@host.com To: joe@otherhost.com Subject: Audio mail MIME-Version: 1.0 Message-ID: <id2@host.com> Content-type: message/partial; id="ABC@host.com"; number=2; total=2 ... здесь имеет место быть вторая часть закодированных аудио-данных ...

После того, как расколотое послание воссоздано заново для отображения получателю, оно должно выглядеть следующим образом: X-Weird-Header-1: Foo From: Bill@host.com To: joe@otherhost.com Subject: Audio mail Message-ID: <anotherid@foo.com> MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64 ... первая часть закодированных аудио-данных ... ... вторая часть закодированных аудио-данных ...

Замечание по кодированию тела MIME-письма, заключенного внутри тела message/partial: так как данные типа "message" никогда не могут быть кодированы в Base64 или Quoted-Printable, следующая проблема может возникнуть в случае, если тела писем типа message/partial созданы в системе, поддерживающей 8-битный транспорт. Двоичные данные будут разбиты на несколько message/partial-объектов, каждому из которых требуется транспортировка в двоичном виде.


Если бы таким объектам пришлось пройти через шлюз в 7-битную транспортную среду, их невозможно было бы перекодировать в сеимбитную форму без ожидания прибытия всех частей послания, собирания их воедино и затем кодирования целого послания в 7-битную кодировку (base64 или quoted-printable). Поскльку существует вероятность, что разные части пойдут разными путями (через различные шлюзы), то подобное решение не приемлимо. Поэтому MIME определяет, что письма типа message/partial должны иметь 7-битную кодировку и соответствующее ей значение поля content-transfer-encoding. Даже для систем с транспортом, поддерживающим "8-бит" и "binary", запрещается их использование для данных message/partial.

Многие почтовые агенты могут автоматически фрагментировать большие письма.

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

Поле заголовка "Encrypted" вышло из употребления, но вышеприведенные правила обеспечивают корректную его интерпретацию, если оно встречается при обработке фрагментов типа message/partial.


Подтип "multipart/alternative"


Этот подтип синтаксически идентичен предыдущему, но имеет несколько другую семантику.

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

Multipart/alternative может быть использована, к примеру, для пересылки текста в некотором гипотетическом формате: From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> Subject: Formatted text mail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=boundary42 --boundary42 Content-Type: text/plain; charset=us-ascii ... Здесь содержится версия простым текстом .... --boundary42 Content-Type: text/richtext .... Здесь содержится версия с разметкой RFC 1341 ... --boundary42 Content-Type: text/x-whatever .... Здесь содержится версия в гипотетическом формате ... --boundary42--

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

Обычно пользовательский агент, создающий письмо в multipart/alternative, должны располагать альтернативные части в порядке увеличения предпочтительности формата, то есть, предполагая, что наш гипотетический формат является самым удобным для конкретных данных (иначе зачем было бы его изобретать?), пользовательский агент должен располагать альтернативу в простейшем формате первой, а самую размеченную последней. Агент получателя должен отобразить последнюю из понимаемых им альтернатив. В случае, если одна из альтернатив сама имеет тип 'multipart' и содержит подчасти неизвестных типов, пользовательский агент может выбрать, показывать ли эту альтернативу, предыдущую или обе.




ЗАМЕЧАНИЕ: С точки зрения программиста, может показаться более удобным располагать альтернативы в обратном порядке, но данный порядок позволяет устаревшим не-MIME'овским почтовым программам отобразить в первую очередь наиболее понятный вариант.

ЗАМЕЧАНИЕ ПО СЕМАНТИКЕ ПОЛЯ 'CONTENT-ID' В ПИСЬМЕ MULTIPART/ALTERNATIVE: Рекомендуется, чтобы каждая часть имела уникальное значение поля Content-ID в случае, если содержимое этих частей не является идентичным. Однако, там, где содержащаяся информация идентична (например, если несколько частей типа "application/external- body" определяют альтернативные пути доступа к одним и тем же внешним по отношению к письму данным), должно использоваться одно и то же значение Content-ID, чтобы оптимизировать работу кэширующего механизма на системе получателя. Однако, не рекомендуется, чтобы значения Content-ID, использующиеся для частей, отличались от значения Content-ID, использующегося в заголовке верхнего уровня, если такое поле в нем присутствует.


Подтип "multipart/digest"


Этот подтип идентичен подтипу 'multipart/mixed', но имеет другую семантику. Например, для 'digest' значением по умолчанию является не "text/plane", а "message/rfc822".

В соответствии с этим подтипом, письмо-дайджест может выглядеть следующим образом: From: Moderator-Address To: Recipient-List MIME-Version: 1.0 Subject: Internet Digest, volume 42 Content-Type: multipart/digest; boundary="---- next message ----" ------ next message ---- From: someone-else Subject: my opinion ... тело вложенного письма ... ------ next message ---- From: someone-else-again Subject: my different opinion ... тело другого вложенного письма ... ------ next message ------



Подтип "multipart/parallel"


Отличие этого подтипа от "multipart/mixed", в частности, состоит в том, что порядок расположения частей письма не принципиален.

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



Подтип 'Text/plain'


Это основной подтип, соответствующий простому (неформатированному) тексту. Значение поля Content-Type для почты Internet по умолчанию - "text/plain; charset=us-ascii". Это тип данных, соответствующий RFC 822.

Других предопределенных подтипов для типа 'text' нет.

Формальный синтаксис для типа 'text': тип := "text" "/" подтип [";" "charset" "=" имя языковой кодировки] подтип := "plain" / расширение (не предопределенный подтип) имя языковой кодировки:= "us-ascii"/ "iso-8859-1"/ "iso-8859-2" / "iso-8859-3" / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6" / "iso-8859-7" / "iso-8859-8" / "iso-8859-9" / расширение (не предопределенная кодировка)



Поле заголовка Content-Transfer-Encoding


Многие типы данных, пересылаемых через email требуют "натурального" представления, то есть, 8-битный набор символов либо двоичный код (что для машины - одно и то же, только представимо для пользователя по-разному). В таком виде данные не могут быть пересланы по 7-битным почтовым протоколам, например, RFC 821, который, к тому же, ограничивает длину строки 1000 символами.

Стандартные механизмы конвертирования почты в 7-битный короткострочный формат, приемлимый для почтового транспорта, описывает поле заголовка Content-Transfer-Encoding.

В отличие от типов содержимого, увеличение множества значений Content-Transfer-Encoding не является необходимым и даже нежелательно. Но установление единого механизма конвертирования не представляется возможным. Существует противоречие между желанием эффективно "ужать" бинарные данные и желанием трансформировать данные, которые, хотя бы частично являются 7-битным текстом, так, чтобы их все-таки можно было читать. По этой причине необходимы по крайней мере 2 механизма конвертации: "читабельный" и "плотно ужимающий".

Данное поле не было определено в предыдущих стандартах. Его значение должно быть строкой без пробелов, определяющей тип конвертации, как показано ниже: конвертация := "Content-Transfer-Encoding" ":" механизм механизм := "7bit" ; / "quoted-printable" / "base64" / "8bit" / "binary" / x-token

Значения не чувствительны к регистру букв, то есть, Base64, BASE64 и bAsE64 - одно и то же. Значение "7BIT" означает, что тело письма уже имеет 7-битный формат и не тренбует дополнительной обработки для пересылки по почте. Это значение полагается по умолчанию, если поле заголовка Content-Transfer-Encoding отсутствует.

Значения "8bit", "7bit" и "binary" означают, что никакой трансформации содержимого не производится. Однако, они сделаны различными для индикации того, что из себя представляет содержимое письма, и, соответственно, способа обработки, который может потребоваться для данной транспортной системы.


В частности:

"7bit" означает, что данные являются текстом, имеют короткие строки и языковую кодировку US-ASCII.

"8bit" означает короткие строки, но в них могут содержаться не-ASCII символы (128-255).

"Binary" означает, что тело письма может содержать не-ASCII символы, но строки могут быть произвольной длины, т.е. слишком длинными для SMTP-транспорта, и может несоблюдаться соглашение по признаку конца строки (CRLF), принятое в SMTP-транспорте.

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

Спецификация на почтовый транспорт для пересылки некодированных 8-битных данных дана в RFC-1426. Однако, нет стандартизованных транспортов рочты Internet, для которых является приемлимым включение в тело письма некодированных двоичных данных. Таким образом, значение "binary" фактически не является легальным в Internet. Но в соответствии с MIME, при использовании почтовой системой транспорта, умеющего работать с двоичными данными, в случае, когда необходимо послать двоичные данные по e-mail, необходимо указать это в заголовке в поле Content-Transfer-Encoding.

Пять значений, определенных для поля Content-Transfer-Encoding, ничего не говорят о типе содержимого кроме указания алгоритма кодирования либо требований к почтовому транспорту в случае некодированных данных.

Производители почтового ПО, если необходимо, могут определить новые значения поля Content-Transfer-Encoding, но эти значения должны иметь префикс "X-" ("x-"), чтобы подчеркнуть их нестандартный характер. Однако, в отличие от типов и подтипов поля Content-Type, введение новых значений Content-Transfer-Encoding настоятельно не рекомендуется, так как может оказаться помехой для взаимосовместимости почтовых систем.


Использование X- значений позволяется только как результат взаимосоглашения между взаимодействующими системами.

Если поле Content-Transfer-Encoding появляеися в заголовке тела какой-то части письма, оно применяется только к содержимому этой части. Если письмо (часть письма) имеет тип "multipart" или "message", то поле Content-Transfer-Encoding может иметь в качестве своего значения только длину символа ("7bit", "8bit" и т.д.) или "binary".

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

Все кодирующие механизмы, определенные в спецификации MIME, кодируют любые данные в символьную форму. Так, к примеру, полагая, что тело письма (части письма) имеет поля заголовка вроде: Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64

то это означает, что тело письма представляет собой ASCII-код base64 текстовых данных, которые в нормальном виде имеют языковую кодировку ISO-8859-1, и будут в этой языковой кодировке после декодирования.

Все множество определенных значений поля content-transfer-encoding кроме начинающихся с префикса "X-", зарезервировано в IANA для будущего использования. Частные соглашения по значениям content-transfer-encoding также настоятельно не рекомендуются.

Некоторые значения Content-transfer-encoding могут использоваться только с определенными типами (поле Content-Type). В частности, запрещено использовать любые значения кроме "7bit", "8bit", или "binary" с любым типом, рекурсивно включающим заголовки с полем Content-Type (как правило, это типы "multipart" и "message").


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

Замечания по ограничениям конвертации:

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

ЗАМЕЧАНИЕ ПО ПЕРЕВОДУ КОДОВ: Конверторы quoted-printable и base64 разработаны так, что данные после их применения легко взаимоконвертируемы. Единственный нюанс, возникающий в подобной ретрансляции - признак конца строки. При конвертации из quoted-printable в base64 перевод строки должен быть заменен последовательностью CRLF. Соответственно и наоборот, но ТОЛЬКО при конвертации текстовых данных.


Поле заголовка "Content-Type"


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

Данное поле включает в себя идентификаторы типа и подтипа, а также может содержать некоторую вспомогательную информацию, которая может потребоваться для конкретного типа данных. После идентификаторов типа и подтипа оставшаяся часть поля - просто набор парамеров, заданных в порядке "атрибут/значение". Набор параметров зависит от типа данных. (В частности, не может быть глобально-значимых параметров, справедливых сразу для всех типов содержимого ьела письма. Глобальные механизмы в MIME-модели реализованы с помощью введения дополнительных полей "Content-*"). Очередность параметров значения не имеет. В числе определенных параметров - "charset", декларирующий символьный набор (кодировку, кодовую страницу - это все синонимы) тела письма. Комментарии допускаются.

Вообще, поле Content-Type самого верхнего уровня используется для объявления общего типа данных, в то время как подтип определяет специальный формат для данных этого типа. Так, значение "image/xyz" поля Content-Type сообщает пользовательской программе, что данные являются графическим изображением (image), даже если эта почтовая программа не имеет понятия о специальном формате "xyz" этой картинки. Но эта информация может быть использована программой, например, чтобы решить, показывать ли пользователю строкоые данные неизвестного подтипа -- показ таких данных может быть оправдан для незнакомых подтипов текста, но не для незнакомых подтипов графики, аудио или видео. По этой причине, данные зарегистрированного подтипа аудио, графики, текста или видео не должны содержать внутри себя части другого подтипа - для содержания в письме данных одного типа, но разных подтипов следует использовать тип "multipart" или "application".




Хотя многие параметры ( модификаторы подтипов) имеют смысл лишь для конкретного типа, некоторые все же являются глобальными в том смысле. что они применимы ко всем типам (например, параметр "boundary" применим только с типом "multipart", а параметр "charset" может использоваться с несколькими типами).

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

Правильное заполнение поля Content-Type: содержимое := "Content-Type" ":" тип "/" подтип *(";" параметр) ; нечувствительное к регистру букв задание типа и подтипа тип := "application" / "audio" / "image" / "message" / "multipart" / "text" / "video" / признак нестандартного типа ; Все значения нечувствительны к регистру букв признак нестандартного типа := x- / iana- iana- := <общепринятый признак расширения, зарегистрированный соответ- ственно приложению "E" RFC 1521> x- := <Два последовательных символа "X-" или "x-", без пробела или другого символа между ними> подтип := слово ; регистр безразличен параметр := атрибут "=" значение атрибут := слово ; регистр безразличен значение := слово / строка в кавычках слово := любые ASCII-символы кроме пробелов, Ctrl-последова- тельностей и специальных символов Специальные символы:= "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> / "/" / "[" / "]" / "?" / "=" ; Эти символы используются в строке значений параметров



Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов "/", "?", "=" и отсутствием символа ".".

Указание подтипа в данном поле является обязательным, т.к. нет подтипов по умолчанию. В отличие от имен типов, подтипов и параметров, значения параметров в общем случае являются чувствительными к регистру букв, но могут быть и нечувствительными - в зависимости от параметра. Например, значения границ multipart-письма являются чувствительными, а значение "access-type" для message/External-body не является.

Существует два приемлимых механизма для введения новых подтипов для поля Content-Type:

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

Новые стандартные значения подтипов должны быть документированы, зарегистрированы и опробованы в IANA, как описано в приложении "E" RFC 1521. Если новй подтип предлагается для широкого использования, формат, описываемый им, должен быть описан в опубликованной спецификации и, возможно, предложен к стандартизации.

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

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

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



"mixed" - основной;

"alternative" - для представления одних и тех же данных в разных форматах;

"parallel" - если разные части документа должны просматриваться одновременно;

"digest" - если каждая из частей тела письма имеет тип "message".

message -- письмо в письме. Тело, содержащее данные типа "message", само является письмом или частью письма, полностью отформатированного в соответствии со стандартом RFC 822, которое, в свою очередь, может содержать свое собственное поле заголовка "Content-Type".

Подтипы:

"rfc822" - основной;

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

"External-body" - используется, чтобы указать, что тело письма очень большое и находится вне письма.

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

audio -- звуковая информация. Требует звуковое устройство (динамик или наушники) для вывода информации. Основной подтип - "basic".

video -- видео. Требует специальных аппаратных и программных возможностей для отображения видео-информации. Единстванный изначально определенный подтип - "mpeg".

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

Подтипы:

"octet-stream" - основной подтип; предназначен для неинтерпретируемых двоичных данных, для которых рекомендуемым действием является предложение пользователю сохранить в файл на диске.

"PostScript" - дополнительный подтип; применяется при пересылке PostScript-документов в теле письма.

По умолчанию, письма, как и в стандарте RFC 822 пишутся простым (неразмеченным) текстом в языковой кодировке US-ASCII, что по спецификации MIME может быть описано как "Content-type: text/plain; charset=us-ascii".


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

При отсутствии поля Content-type или поля MIME-Version в заголовке MIME-письма нельзя быть точно уверенным, что письмо имеет языковую кодировку именно US-ASCII, поскольку могут еще встречаться почтовые программы, не использующие соглашения MIME. Но хотя возможно, что письмо, не содержащее в заголовке полей MIME-Version и Content-Type, может содержать все, что угодно, например, юниксовский tar-архив, сжатый gzip'ом и обработаный uuencode, все же, создателям почтовых программ рекомендуется оставлять этот факт без внимания и ориентироваться на значение по умолчанию, т.е. "text/plain; charset=us-ascii".

Необходимо учесть, что в будущем ожидается заметное увеличение числа регистрированных типов и особенно подтипов содержимого писем. Если почтовая программа встретит неизвестное ей значение поля Content-type, она должна интерпретировать содержимое этого письма как "application/octet-stream" (см.выше).


Поле заголовка "MIME-Version"


Поскольку старый стандарт RFC 822 все еще используется, а MIME возможно, изменится и дополнится в будущем, почтовой программе необходимо знать, применен ли новый стандарт в конкретном письме или нет. Поэтому в заголовок ввелено новое поле "MIME-Version", объявляющее версию стандарта, в соответствии с которым написано данное письмо.

Все почтовые сообщения, составленные в соответствии с MIME-стандартом, должны иметь это поле в своем заголовке, напрмер: MIME-Version: 1.0

Так как возможно, в будущем формат заголовка письма может расшириться, формально содержание поля "MIME-version" дается следующим образом: версия := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

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

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

Не возможно полностью определить как почтовая программа, поддерживающая MIME, должна интерпретировать письмо, имеющее значение MIME-version, отличное от "1.0". Но, как минимум, почтовая программа должна предупредить пользователя о том, что письмо написано в незнакомом ей формате.

Все поля заголовка, включая MIME-Version, Content-type, и т.д., должны соответствовать общим синтаксическим правилам, определенным в RFC 822. В частности, допускается включение комментариев (т.е., следующие 2 примера эквивалентны): MIME-Version: 1.0 MIME-Version: 1.0 (Generated by GBD-killer 3.7)



Полоса новостей на php с использованием javascript и слоев.


Добрый день!

Решил написать статью о программировании на php на примере экспорта новостей с сайта . Но не в том виде, который они предлагают, а по-своему, компактно и интересно.

Такой пример вы можете увидеть на страницах сайтов http://www.czar.ru

или же http://www.russianjudo.ru.

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

Как же создать такую новостную полосу? Все довольно просто. Заходим на сайт и находим пункт "экспорт новостей". . Там нам предлагают экспортировать на свой сайт новостную полосу с их ресурса.

Мы радуемся и регистрируемся. Все абсолютно бесплатно и, главное, стабильно. Например (реальная регистрация, можете зайти и проверить, а также, можете там изменять рубрики, получаемые нами в новостной полосе), ввели имя news_list, пароль qwer мейл - ваш (реально, в этом примере - мой), адрес сайта любой, например - citforum.ru. Затем понадобится только лишь имя и пароль.

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

Первая полоса Полоса политики Полоса бизнеса Полоса культуры Полоса спорта Автомобильные новости Бизнес новости Спортивные новости Новостная лента Полоса International News in English Полоса общества Полоса финансов Полоса автомобилей Новость часа Молния

Выбираем интересное и устанавливаем количество новостей в каждой рубрике.

Ниже выбираем кодировку новостей. Она должна совпадать с кодировкой вашего сайта. Например - win1251.

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

Верх и низ новостей оформлять не нужно.

Получаем строку, которую надо запомнить: <script language="javascript" src="http://www.gazeta.ru/cgi-bin/export/export.cgi?id=2743"></script>

Из нее извлекаем полезное: Адрес cgi-скрипта, который и формирует наши новости на gazeta.ru. Этот адрес: http://www.gazeta.ru/cgi-bin/export/export.cgi?id=2743

Таким образом, мы имеем страницу, с которой нам надо изъять код ссылок на новости gazeta.ru к себе. Она имеет приблизительно такой вид:

var news=""; news+="<a href=\"http://www.gazeta.ru/2001/10/07/400dnejsborn.shtml\">текст1</a><br>"; news+="<a href=\"http://www.gazeta.ru/2001/10/08/last32746.shtml\">текст2</a><br>";



Понимание WML


WML базируется на XML, языке разметки получившем невероятную поддержку благодаря своей способности описывать данные (HTML, кстати, используется для описания представления данных). HTML - предопределяет те тэги, которые могут быть использованы для описания страницы так, чтобы ее смог правильно понять и обработать броузер. XML, в свою очередь, позволяет создателю документа определять такой набор тэгов, которой он считает необходимым. Этот набор тэгов группируется затем в набор грамматических "правил", называемых по-другому Определение Типа Документа или проще DTD. Как уже упоминалось ранее, DTD, используемый для описания WML, расположен по адресу:

В телефоне или в любом другом коммуникационном устройстве, заявленном как WAP-совместимое, загружено специальное программное обеспечение (известное как микроброузер), которое полностью понимает, как обрабатывать все вариации WML 1.1 DTD.

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

Пролог выглядит следующим образом.

<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">

Следом за прологом, в каждом XML-документе содержится один единственный элемент, который содержит в себе остальные подэлементы и entities. Так же как и в HTML этими элементами являются угловые скобки: <> и </>. Например: <element>data</element>. В документе должен содержаться только один элемент описывающий сам документ. В WML этим элементом является <wml>. Все остальные элементы содержатся уже внутри него.

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

<!-- This is the Login Card --> <card id="LoginCard" title="Login"> Please select your user name. </card>

В этом примере элемент card содержит атрибуты id и title. Комментарий в WML, также как и в HTML заключается между тэгами <!-- и -->. В дальнейшем мы будем использовать элементы и их атрибуты для написания примеров.



Практикум


Теперь пора попробовать применить все эти теоретические сведения на практике. Давайте напишем для пробы небольшой HTML-файл, вызывающий один из органов управления ActiveX, разработанных фирмой Microsoft, - модуль для создания плавного перехода цветов (градиента). Заглянув в , мы узнаем соответствующий ему идентификатор CLSID и URL-адрес одной из его копий на сервере Microsoft, на которую можно будет сослаться. Кроме того, там же мы найдем список параметров и их значений, которые способен принимать этот орган управления, в частности:

StartColor и EndColor

Два цвета, плавный переход между которыми вы увидите на экране. Задаются в обычном для HTML виде "#rrggbb", где rr, gg и bb - шестнадцатеричные значения красной, зеленой и синей составляющих цвета.

Direction

Направление градиента: 0 - горизонтальное, 1 - вертикальное, 2 - радиальное от центра к краям, и т.д.

Теперь остается лишь заполнить атрибуты тега <OBJECT> и предусмотреть нужное количество тегов <PARAM>. Вот как выглядит полный текст нашего HTML-файла:

<HTML> <TITLE>Пример вызова органа управления ActiveX</TITLE> <BODY> Этот градиент на вид не отличишь от обычного графического файла: <OBJECT ID="grad1" CLASSID="clsid:017C99A0-8637-11CF-A3A9-00A0C9034920" CODEBASE="http://activex.microsoft.com/controls/iexplorer/ iegrad.ocx#Version=4,70,0,1161" WIDTH=200 HEIGHT=100 > <PARAM NAME="StartColor" VALUE="#ffffff"> <PARAM NAME="EndColor" VALUE="#000000"> <PARAM NAME="Direction" VALUE="0"> </OBJECT> </BODY> </HTML>

Открытие этого файла в броузере Internet Explorer приведет к довольно заметной паузе, во время которой в строке состояния будет видна надпись "Installing components..." В это время броузер связывается с сервером, указанным в атрибуте CODEBASE, и перекачивает с него файл, содержащий компонент ActiveX (перед проведением этого эксперимента нужно подключиться к сети).


Файл этот не слишком велик, но и не так чтобы очень мал - чуть больше 100 K (что, кстати, вполне можно принять за средний размер для не слишком сложных органов управления). То, что вы увидите на экране, когда инсталляция будет закончена, показано на рис. 2.



Рисунок 2. Пример вызова органа управления ActiveX

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

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

<OBJECT ID="grad1" CLASSID="clsid:017C99A0-8637-11CF-A3A9-00A0C9034920" CODEBASE="http://activex.microsoft.com/controls/iexplorer/ iegrad.ocx#Version=4,70,0,1161" WIDTH=25 HEIGHT=25 <!- прямоугольник 25 на 25 пикселов -> > <PARAM NAME="StartColor" VALUE="#888888"> <! - по краям - серый цвет -> <PARAM NAME="EndColor" VALUE="#000000"> <!- в середине - то черный, то белый -> <PARAM NAME="Direction" VALUE="2"> <!- направление - от центра к краям -> </OBJECT>

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

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


Согласно документации, этот орган управления имеет два параметра: параметр Interval, который задает промежуток времени между срабатываниями таймера, и параметр Enabled, позволяющий включать и выключать работу таймера. "Срабатывание" же таймера заключается в инициировании связанного с ним события, которое так и называется - Timer. Как выражаются программисты, мы должны теперь "повесить" функцию переключения градиента на это событие. Сначала заведем объект-таймер: <OBJECT ID="timer1" CLASSID="clsid:59CCB4A0-727D-11CF-AC36-00AA00A47DD2" CODEBASE="http://activex.microsoft.com/controls/iexplorer/ ietimer.ocx#Version=4,70,0,1161" > <PARAM NAME="Interval" VALUE="500"> <!- таймер срабатывает каждые 0,5 сек -> <PARAM NAME="Enabled" VALUE="True"> <!- таймер включен -> </OBJECT>

Теперь остается написать фрагмент сценария, у которого в открывающем теге <SCRIPT> указаны имя объекта-таймера и имя события, по наступлении которого этот фрагмент получит управление: <SCRIPT FOR="timer1" EVENT="Timer" LANGUAGE="JavaScript"> <!- // переключаем один из цветов градиента: if (grad1.EndColor == 0) // из черного grad1.EndColor = 0xffffff; // в белый else grad1.EndColor = 0; // и наоборот grad1.Repaint (); // перерисовываем градиент // -> </SCRIPT>

Как видно из этого примера, свойство EndColor может задаваться и изменяться как с помощью тега <PARAM> при создании объекта, так и впоследствии из сценария. Метод Repaint (хоть он и не указан в документации) имеется у всех органов управления, которые хоть что-нибудь рисуют на экране.

Итак, периодическое изменение и перерисовку градиента (объект grad1) с частотой два раза в секунду обеспечивает таймер (объект timer1). Теперь наш градиент будет мигать до тех пор, пока мы не уйдем с этой страницы; на прорисовку остальных частей страницы, ее прокрутку и просмотр это практически не влияет.


Снимок окна броузера с этой страницей приведен на рис. 3.



Рисунок 3. Динамическое изменение параметров органа управления

Если вы - поклонник визуального дизайна Web-страниц и не очень-то любите возиться с тегами и атрибутами, Microsoft имеет предложить вам специальную программу под названием ActiveX Control Pad. В ней вы сможете строить свою страницу и размещать на ней органы управления, по большей части лишь щелкая мышью (чем-то это похоже на среду разработки программ в Visual Basic). К сожалению, сценарии вам все равно придется писать "вручную"...

Напоследок - еще кое-какие полезные сведения для тех, кто не прочь покопаться во внутренностях системы ActiveX. OCX-файлы с органами управления, полученные из сети, складываются броузером в подкаталог OCCACHE в каталоге Windows 95; судя по названию, этот подкаталог должен рассматриваться как хранилище кэшируемых данных, хотя кэш этот в Internet Explorer 3.0 является постоянным - информация в нем никогда не стирается.

Сведения об установленных органах управления хранятся в реестре Windows в разделе \HKEY_CLASSES_ROOT\CLSID. Данные о каждом органе управления вы найдете в подразделе, имя которого совпадает с идентификатором класса этого органа управления. Кстати, заглянув в реестр, вы увидите, что с помощью этого же механизма Windows хранит информацию о множестве других своих компонентов, большинство из которых не имеют никакого отношения ни к ActiveX, ни вообще к Интернету.


Правильные WML элементы.


В WML описывается набор элементов, которые можно комбинировать для создания WML-документа. Эти элементы можно условно разделить на две группы: Элементы типа Deck/Card и элементы обработки событий.

Элементы типа Deck/Card

wml card template head access meta

Элементы обработки событий

do ontimer onenterforward onenterbackward onpick onevent postfield

Задачи

go prev refresh noop



Представление данных для задач Web/DB


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

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

Модели слабоструктурированных данных: Второй аспект моделирования данных для приложений Web заключается в том, что во многих случаях структура этих данных не является постоянной. При моделировании структуры Web-сайта мы не имеем какой-либо фиксированной схемы, которая была бы задана заранее. В случае моделирования данных, поступающих из множества источников, представления некоторых атрибутов (например, адресов) могут различаться для разных источников. Поэтому в некоторых проектах исследовались модели слабоструктурированных данных. Первоначальными стимулирующими причинами этой работы послужили существование и относительный успех в научном сообществе "разрешающих" (permissive) моделей данных, подобных [TMD92], необходимость обмена объектами между неоднородными источниками [PGMW95], а также задачи управления коллекциями документов [MP96].




Вообще говоря, слабоструктурированными называются данные, обладающие какими-либо из следующих характеристик:

Схема не задана заранее и может неявно содержаться в данных,

Схема сравнительно велика (в смысле объема данных) и может часто изменяться,

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

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

Модели слабоструктурированных данных были основаны на помеченных ориентированных графах [Abi97, Bun97]2. В модели слабоструктурированных данных не налагается какого-либо ограничения на множество дуг, которые исходят от данного узла в графе, или на типы значений атрибутов. В связи с упомянутыми выше характеристиками слабоструктурированных данных становится важной в этом контексте дополнительная возможность - запрашивать схему (т.е., метки дуг в графе). Эта возможность обеспечивается в языках запросов для слабоструктурированных данных благодаря переменным-дугам, которые связаны с метками дуг, но не с узлами графа.

Помимо разработки моделей и языков запросов для слабоструктурированных данных, нужно упомянуть также и недавно опубликованные довольно важные работы, посвященные некоторым вопросам управления слабоструктурированными данными, в частности, реконструкции структуры слабоструктурированных данных [NAM98], поддержке представлений [ZGM98, AMR+98], агрегированию (summarization) слабоструктурированных данных ([BDFS97, GW97]), а также рассуждениям относительно слабоструктурированных данных [CGL98, FFLS98]. Независимо от релевантности этих работ задачам, которые рассматриваются в этом обзоре, системы, основанные на предложенных в них методах, будут иметь особенно важное значение для управления большими объемами XML-данных [XML98].

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


Например, в некоторых моделях различаются унарное отношение, идентифицирующее страницы, и бинарное отношение для связей между страницами. Кроме того, мы можем различать связи внутри Web-сайта и внешние связи. Важная причина отличать отношение связей состоит в том, что они, вообще говоря, могут обходиться только в прямом направлении. К свойствам второго порядка, которыми различаются обсуждаемые здесь модели данных, можно отнести: (1) способность моделирования некоторого порядка на множестве элементов в базе данных, (2) моделирование вложенных структур данных и (3) поддержка типов коллекций (множества, мультимножества, массивы). Примером модели данных, которая включает явным образом специфические для Web конструкции (страницы и схемы страниц), вложенность и типы коллекций, является ADM - модель данных в проекте ARANEUS [AMM97b]. Следует отметить, что все модели, которые мы упоминаем в этой статье, позволяют представлять только статические структуры. Так, например, в работах по моделированию структуры Web-сайта не рассматриваются динамические страницы Web, созданные в результате ввода данных пользователем.

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



В Таблице 1 представлена сводка некоторых систем запросов для Web, рассматриваемых в этой работе. Более подробную версию этой таблицы, содержащую URL сайтов с доступными описаниями этих систем, можно найти в: . В последующих разделах нашего обзора мы подробно проиллюстрируем возможности языков запросов для Web, основанных на этих моделях.


Преимущества Tamino


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

Tamino является быстродействующим, надежным и масштабируемым информационным сервером. Поскольку Tamino ориентирован на хранение XML-документов в их оригинальном виде, он легко превзойдет реляционные СУБД и объектно-ориентированные СУБД, оснащенные XML-преобразователем. Tamino может работать на широком диапазоне программно-технических средств, начиная от Windows NT, Unix, вплоть до OS/390, предоставляя возможность достаточно гибкого управления пропускной способностью серверов Интернет.

Полнотекстовая поисковая машина

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

Минимизация затрат на обслуживание

Tamino построен на концепции "нулевого администрирования". С помощью диспетчера Tamino пользователь может с одного рабочего места обозревать всю систему, включая внешние источники данных, доступные через X-Node. При этом, рабочее место администратора Tamino может находиться в среде Интернет и быть доступно с помощью любого соединения, поддерживаемого протоколом HTTP.

Встроенные средства разграничения доступа

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

Управление транзакциями

Протокол HTTP не обеспечивает хранение состояния сеанса, что приводит к потере Интернет-сервером содержания HTML-страницы после ее передачи клиенту. Вместе с тем, Tamino ориентирован на выполнение бизнес-приложений, требующих надежного выполнения транзакций в среде Интернет. Tamino поддерживает механизм выполнения классических транзакций, удовлетворяющих требованиям ACID (Atomic, Consistent, Isolated, Durable) на уровне объектов.


Tamino поддерживает механизм блокировки доступа к изменяемым данным на уровне объекта. Блокировка доступа устанавливается в начале транзации и снимается при выполнении команд End Transaction или Backout Transaction. В сочетании с Bolero - фабрикой приложений для электронного бизнеса, Tamino поддерживает не только классические транзакции, но и так называемые "длинные транзакции", охватывающие сложные бизнес-процессы.

Ведение журналов

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

Интеграция информационных технологий

Tamino может играть роль интегратора информационных технологий. С помощью компонентов Data Map, X-Node и X-port Tamino позволяет не трогать существующие базы данных, делая их доступными Интернет и приложениям бизнес-бизнес.

Tamino и Adabas

С помощью компонента Tamino Data Map и X-Node можно легко обеспечить доступ к данным СУБД Adabas. При этом, логическая структрура файла интерпретируется как соответствующая структура XML, запись файла - как конкретный экземпляр XML-документа.

Tamino и EntireX

С помощью EntireX можно взаимодействовать с существующими программными системами, такими как SAP, PeopleSoft, Baan, по протоколу DCOM. Поскольку Tamino имеет доступ к объектам DCOM, появляется возможность интеграции существующего программного обеспечения с новыми приложениями XML.

Tamino и Natural

С помощью Natural можно получать доступ как к объектам XML, так и к SQL-данным, хранящимся в Tamino. В свою очередь, Tamino может взаимодействовать с объектами Natural с помощью комбинации продуктов EntireX и NaturalX.

Tamino и Bolero

Bolero - фабрика приложений для электронного бизнеса, работает в среде Java Virtual Machine (JVM). Вследствие этого, приложения Bolero могут выполняться на любой платформе, имеющей сертифицированную JVM.

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


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

Данная уникальная комбинация позволяет Tamino:

Хранить любые типы объектов Интернет, такие как страницы XML или HTML. Реализовать концепцию безопасного выполнения транзакций бизнес-приложений в среде Интернет. Обеспечить пользователя средствами эффективного и избирательного поиска и отображения комплексных информационных объектов и структурированных данных. Хранить любые типы документов стандартных приложений, такие как письма, факсы, электронные таблицы. Хранить любые типы сложных информационных объектов, таких как мультимедиа или биометрические данные. Хранить традиционные данные, представленные в реляционной структуре, такие как тексты и числа. Обеспечить доступ к существующей информации, хранящейся во внешних базах данных, таких как Adabas или РСУБД.

Платформы

В настоящее время информационный сервер Tamino выпускается на платформе Windows NT. В течение следующего года предполагается выпуск продукта на платформах Unix, включая Sun Solaris, AIX, Linux и др., а также OS/390.

Требования к программно-технической платформе:

ПК: INTEL PentiumT II Processor от 300 Мгц; HDD: > 150 MB (NTFS); RAM: 128 MB; Windows NT 4.0 SP5; Microsoft IIS 3 и выше; или Apache WS 1.3.3, 1.3.4, 1.3.6 или 1.3.9; или IBM HTTP Server 1.3.6 и выше.

Лицензирование

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



Преимущества технологии Curl.


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

Предоставляя конечному пользователю более богатый интерфейс, интерактивную и улучшенную скорость передачи информации, технология Curl безусловно обогатит опыт пользователя в сети. С помощью программной платформы Surge, которая включает в себя и plug-in модуль, на своем компьютере пользователь сможет работать гораздо быстрее и эффективнее с помощью использования содержимого Web страниц написанных на Curl. Не рабочие задачи, такие как сбор и поиск информации или игры, станут приносить гораздо больше удовольствия. Что же касается электронной коммерции, то пользователь откроет для себя более динамичный процесс совершения покупок, быстрый и безопасный расчет. Все эти преимущества пользователь получает без всяких дополнительных устройств или ОС, но исключительно с помощью среды Surge и ее компонентов.

Технология Curl освобождает разработчиков от компромиссных решений для содержания и скорости отклика Web-страниц и приложений, а также значительно снижают усилия, стоимость и время требуемое на разработку и поддержку содержания Web-страниц. Используя Surge Lab IDE, разработчики смогут создавать Web-проекты, качество представления содержимого которых будет равняться скорости их загрузки. Они смогут создавать проекты, используя преимущества работы в общей, унифицированной среде разработки, которая может сочетать в себе функциональность HTML с функциональностью скриптов и концепциями ООП.

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




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

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

Технология Curl позволяет решить эти проблемы с помощью компактного, самоописывающегося языка программирования, использующего вычисления на стороне конечного пользователя:

Интеграция программного кода и данных - как и любая программа, Web приложение состоит из программной части и некоего набора данных. HTML технология позволяет только представлять, отображать информацию, но не расчитывать ее или формировать. Технология Curl позволяет не чуствовать разницы между программой и интерактивным документом. Одна общая среда разработки - технология Curl является в равной степени форматом представления информации, таким, как HTML, и языком программирования с элементами ООП, таким как Java, Visual Basic, C++. Дизайнер или программист, использующий Curl, может объединять информацию по форматированию и расположению инфомации и объектно-ориентированный интерфейс в одном общем формате, без труда интерпретируемым с помощью среды Surge. Причем интерактивность и вычисления будут выполняться на клиентском ПК. Маленький размер - при использовании технологии Curl, информация, посланная на ПК пользователя, сразу содержит код, который "знает" как интерпретировать данные.Таким образом количество передаваемой информации будет меньшим, чем при использовании традиционных технологий.


Преобразование Бизнес Модель в Модель сообщений


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

Правило 1. Классы сообщений должны быть структурно иерархически взаимосвязаны. Корневой класс всегда должен быть определен. Создавая корневой класс предпочтительно ему дать имя БМ сообщения, например при моделировании EDIFACT сообщения CusDec (таможенная декларация), классу предпочтительно дать имя CustomDeclaration. Ниже изображен формальный UML класс - CustomDeclaration

Секции и подсекции в БМ могут быть разделены на категории по:

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

Ниже приведен пример создания корневой секции сообщения CusDec. В таблице приняты следующие сокращения:

O = Optional / Необязательный DE = элемент данных справочника UN/EDIFACT

R = Requred / Обязательный CL = значение из списка кодов справочника

D = Dependent / Зависимый

Секция А - Message Information (информация о сообщении)

Наименование терма, ссылка на Элемент данныхO/R/DЗначение клалификатора, примечаниеЭлемент данных клалификатор
А 1 идентификация документа&nbsp 
A1-1 Document type codedR"914" = Customs declarationCL 1001 - 335
A1-2 Document issue dateR CL 2005 - 137
A1-3 Customs procedureR1 - export, 2 -importCL 8323
A1-4 Customs Declaration numberR CL 3035 - CM
A1-5 Carrier booking numberDPrimary key, if not CUCL 1153 - BN
A1-6 Invoice reference numberD CL 1101- 935
A1-7 Consignor reference numberDPrimary key, If not BNCL 1153 - CU
A1-8 Reference to previous messageD CL 1153 - ACW
A1-9 Message senderOFor return purposesCL 3035 - MS
A1-10 Message receiverOFor on-distributionCL 3035 - MR
A2 функции сообщения  DE 1225
A2-1 OriginalD CL 1225 - 9
A2-2 ReplaceD CL 1225 - 5
A2-3 CancellationD CL 1225 - 1
A3 идентификация Edifact   
A3-1 Message typeOFixed "CUSDEC"DE 0065
A3-2 Message type versionOFixed " D"DE 0052
A3-3 Message type releaseOFixed "98A"DE 0054
A3-4 Controlling agencyOFixed "UN"DE 0051
A3-5 MIG identityOFixed "SE0023"DE 0057
A3-6 Message reference numberO DE 0062



Таблица 2

Аналогичным образом строятся остальные секции БМ.

Правило 2. Создать класс сообщений для каждой необязательной секции. Имя класса сообщений должно быть эквивалентно имени секции.

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

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

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

максимальное кол-во соответствий = 1 (не повторяющихся), и существует только одна родительская ассоциация.

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

Правило 4. Создание единственной ассоциации (соответствия).

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



"Соответствие" в сообщение имеет только одно направление - от родительского класса к дочернему. Возможно представления множественных соответствий. Множественные соответствия записываются как Min..Max Например по одной таможенной декларации возможно провести от одного до : (десяти) контейнеров. В этом случае соответствия представится как 0..9. Множественность должна описываться в конце дочерней секции.

Правило 5. Создание множественного соответствия.

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



Каждое множественное соответствие дает свое имя роли. Имя роли определяется как имя терма данных в подсекции категории списка ролей. Каждое имя роли будет заменено дочерним именем класса, сгенерированным в XML/DTD или схемы XML. Использование нотации UML "+" показывает, что имя роли имеет атрибут "public".


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



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

Данные термов в секции могут быть категоризированны как: необязательный терм данных, имя роли и значение кода (см таблицу 2). Возращаясь к примеру в таблице 2 значение терма (терм кодов) A1-3 (Customs procedure ) в справочнике кодов 8323 имеет значение 1- export и 2- import, значение CU для роли A1-7 (Consignor reference number ) по справочнику кодов 1153 , а значение для данных A1-2 (Document issue date ) является датой принятия документа (например 12/12/2000).

Правило 5. Создание атрибутов для термов данных и кодов значений.

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



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

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

Тип данных используется в создании XML схемы и может иметь допустимые значения соответствующие определению схемы XML.

Множественность - используется в создании XML/DTD или схемы XML. Допускаются следующие два значения:

0..1 - для необязательных (optional) атрибутов

1..1 - для обязательных (mandatory) атрибутов

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

Таможенный режим TypeDeclaration - 1 "export" , 2 "import" Вид перевозки EquipmentType - CN - контейнер, PL - паллеты;

Эти значения всегда используются при создании XML/DTD или схемы XML.



Бизнес правила могут быть определены для более сложных зависимостей в БМ. Хотя бизнес правила не используются при создании XML/DTD или XML схемы.

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

Стандартные ссылки представляют уникальный идентификатор какточеку определения стандартного атрибута т.е. номер тага элемента данных UN/EDIFACT. Они могут быть использованы для документирования, а также и при создании XML/DTD и схемы XML как альтернативных атрибут имени.

Ниже на рис. 4 приведена диаграма классов UML бизнес модели сообщения CusDec:



Рис. 4

При автоматической генерации из БМ в XML/DTD или XML схема используется формальный алгоритм преобразования. Правила преобразования UML модели в XML/DTD или схеме XML осуществляюстя в соответсвии следующими правилами:
Модель сообщения XML/DTD XML Sсhema
Имя класса корневого сообщения Имя корневого элемента Имя типа корневого элемента
Имя роли Имя элемента Имя типа элемента
Множественное соответствие ?, *, +, (empty) Соответствие min и max
Имя атрибута Имя элемента Имя типа элемента
Тип данных атрибута - Тип данных или макс. длинна
Атрибут множественности ?, (empty) Соответствие min и max
Значение атрибутов допустимый список значений Допустимый список значений
При создании XML/DTD или схемы XML БМ специфицируется последовательно по секциям, начиная с корневой, и далее с подсекции и термов данных и должны быть сохранены в модели сообщения. Соответствия и атрибуты должны быть смоделированы в некоторой последовательности. Это возможно только для атрибутов, исключая соответствия. Ниже приведен пример XML/DTD, полученный в результате моделирования секции сообщения Customs.

<?xml version="1.0"> <!- section B 4 Customs --> <!ELEMENT Customs (CustomsIdentification, CustomsDetails) > <!ELEMENT CustomsIdentification (CustomsID ; код таможни CustomsRegion?, ; регион деятельности таможни CustomsType?, ; тип таможни CustomsPostName, ; наименование тамж.


Поста Address?)> ; адрес поста <!ELEMENT CustomsID (#PCDATA)> <!ELEMENT CustomsRegion (#PCDATA)> <!ELEMENT CustomsIype (#PCDATA)> ; "destination", "departure","border" <!ELEMENT CustomsPostName (#PCDATA)> <!ELEMENT CustomsDetalies (DataTimeRegistration, ; дата и время оформления TypeExamination?, ; вид досмотра SealExamination?, ; номер печати после досмотра InspectorName, ; ФИО инспектора SealNumber, ; номер личной печати TextDetalies?) > ; примечание <!ELEMENT DataTimeRegistration (Date, ; дата оформления Time?) ; время оформления <!ELEMENT TypeExamination (#PCDATA)> <!ELEMENT SealExamination (#PCDATA)> <!ELEMENT InspectorName (#PCDATA)> <!ELEMENT SealNumber (#PCDATA)> <!ELEMENT TextDetalies (#PCDATA) > <!ELEMENT Address (Province?, ; регион City, ; город Street?, ; улица HomeNumber?, ; номер дома OfficeNumber?, ; номер офиса Zip?)> ; почтовый индекс <!ELEMENT Date (#PCDATA) > <!ELEMENT Time (#PCDATA) > <!ELEMENT Province (#PCDATA) > <!ELEMENT City (#PCDATA) > <!ELEMENT Street (#PCDATA) > <!ELEMENT HomeNumber (#PCDATA) > <!ELEMENT OfficeNumber (#PCDATA) > <!ELEMENT Zip (#PCDATA) >


Проблема кнопки "Back" и проблема кнопки "Refresh"


Филипп Зуев, Ирина Пономарева, Владимир Якименко

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

Также существует кнопка "Refresh", которая позволяет "обновить" страницу, которую пользователь просматривает.

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

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

Страницы бывают двух видов: статические и динамические (последние еще иногда называют скриптами). Статическая страница всегда выглядит для пользователя одинаково. Динамическая страница, как правило, выглядит по-разному в зависимости от того, какие данные были переданы от браузера серверу. Мы поговорим о том, как эти данные передаются, когда будем рассказывать об отличии методов GET и POST.

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

адрес страницы (который ещё называют Universal Resource Locator - URL), зарезервированное слово HTTP-протокола (GET или POST), которое сообщает серверу, что именно пользователь браузера хочет сделать со страницей. Дело в том, что некоторые браузеры позволяют своим пользователям не только просматривать страницы с сервера, но и заменять их другими страницами по своему усмотрению или даже удалять. Разумеется, сервер не каждому пользователю позволит изменять или удалять страницы. Это зарезервированное слово называется "метод" или "метод протокола http". Методы GET и POST используются для получения страницы с сервера, при этом они могут посылать серверу дополнительные данные, которые сервер может использовать для формирования страницы. Метод GET показывает эти данные в адресной строке браузера.

Проверка корректности


Процесс проверки корректности по схеме определен в [3]. Она может выполняться применительно к документу XML или к части документа, например, отдельному элементу.

В запросной модели данных с каждым узлом-элементом ассоциируется аннотация типа. Аннотация типа свидетельствует о том, что данный элемент прошел проверку на соответствие определенному заявленному типу. Элементы, которые не прошли проверку или не соответствуют заявленному типу, получают аннотацию родового типа anyType. Например, элемент, создаваемый конструктором элементов, имеет аннотацию anyType до тех пор, пока не получит более конкретный тип с помощью выражения validate. Ниже конструируется элемент и проверяется в соответствии со схемой (схемами), которые указываются в прологе запроса. validate {<shipto> <street>123 Elm St. </street> <city>Elko, NV</city> <zipcode>85039</zipcode> </shipto>}

Аннотация типа используется в выражениях, проверяющих тип элемента, таких как instance of и typeswitch, и в выражениях, требующих элемента конкретного типа, таких как вызовы функций. Так, проверка элемента shipto может присвоить ему аннотацию типа USAddress, которая может позволить использовать его в качестве аргумента вызова функции, типом параметра которой является element of type USAddress.



ПРОВОЗГЛАШЕНИЕ СТРУКТУРЫ ДОКУМЕНТА


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

Для этого вам придется использовать определения типов документов (Document Type Definition, DTD). Хранимые в начале файла XML или внешним образом в виде файла *.DTD, эти определения описывают информационную структуру документа. DTD перечисляют возможные имена элементов, определяют имеющиеся атрибуты для каждого типа элементов и описывают сочетаемость одних элементов с другими.

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

<!ELEMENT имя_элемента (тип_данных)>

Например, декларация определяет элемент с именем publication, содержащий символьные данные (т. е. текст). Декларация определяет элемент с именем special_report, содержащий подэлементы article_1, article_2 и article_3 в указанном порядке, например:

<special_report> <article_1>XML: время пришло</article_1> <article_2>XML превосходит самое себя</article_2> <article_3>Управление сетями и системами с помощью XML</article_3> </special_report>

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


Например, следующая команда устанавливает соответствие между атрибутом manufacturer и элементом car, причем первый из них может принимать одно из указанных значений: <!ATTLIST car manufacturer (AudiлVolvoлVolkswagen)>

!ATTLIST позволяет управлять атрибутами и многими другими способами: задавать значения по умолчанию, подавлять пробелы и т. д. DTD могут также содержать декларации !ENTITY, где определяются ссылки на объекты, а также декларации !NOTATION, указывающие, что делать с двоичными файлами не в формате XML.

Серьезное и несколько удивительное ограничение DTD состоит в том, что они не допускают типизации данных, т. е. ограничивают данные конкретным форматом (таким, как дата, целое число или число с плавающей точкой). Как вы, вероятно, уже заметили, DTD используют иной синтаксис, нежели XML, и не очень-то интуитивно понятны. По названным причинам DTD будут, видимо, заменены на более мощные и простые в использовании схемы XML, работа над которыми ведется в настоящее время. Дополнительную информацию о схемах XML можно почерпнуть из рабочего проекта, ссылка на который приведена в Таблице, и из врезки «Что в имени твоем?».

Возможно, вам приходилось слышать определения «правильно составленный» (well-formed) и «действительный» (valid) применительно к документам XML. Документ является правильно составленным, если для каждого открывающего тега имеется соответствующий закрывающий тег, а накладывающиеся теги отсутствуют. (Таким образом, большая часть документов HTML составлена неправильно.) Документ является действительным, если он содержит DTD и соответствует его правилам.


Распространение информации среди пользователей BI-инструментов


Подготовлено: по материалам зарубежных сайтов
Перевод:
Авторские права:



Разбиение отчетов


Разбиение отчетов автоматизирует ручной процесс «проталкивания документов» («paper pushing»), в результате удается существенно сократить административные расходы и время обработки. Например, представим отчет, в котором содержится информация об отработанных и о пропущенных по болезни днях по каждому сотруднику. Страницы этого отчета можно автоматически разбить и направить в электронной форме каждому служащему, при этом будут сэкономлены многие и многие часы работы отдела кадров.



Разделить страницу на несколько частей


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



РАЗГОВОРЫ О BIZTALK


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

<book> <author>Джон Милтон</author> <title>Потерянный рай</title> </book>

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

Но реальная жизнь намного сложнее, даже если вы ограничиваетесь достаточно предсказуемым понятием книги. Традиционно автором «Тома Сойера» считается Марк Твен, но реальный человек получал гонорары под именем Самуэль Клеменс. Должны ли вы создать другой тег для псевдонимов? Или же использовать тег <author> с атрибутом nametype=pseudonym? Как различать разные издания? Будут ли данные об авторских правах описываться с помощью атрибутов тега <copyright> или каждый их элемент будет иметь отдельный тег внутри элемента <copyright>? Если два книжных магазина реализуют свои собственные приложения и затем решат обмениваться данными из своих каталогов, то кто будет проверять правильность соответствия?

За исключением пары случаев, не имеющих отношения к бизнесу, Консорциум World Wide Web (W3C, ) четко обозначил свою позицию: он не собирается давать свое благословение каким бы то ни было приложениям XML (в терминологии XML «приложением» называется описание отраслевых терминов с помощью некоторого набора тегов XML, это не имеет никакого отношения к программным пакетам). Другими словами, конкретные вертикальные рынки должны самостоятельно согласовать внутри отрасли имена для своих объектов. Дабы способствовать открытости и предсказуемости при составлении схем XML в вертикальных отраслях, Microsoft выдвинула инициативу, названную BizTalk. По состоянию на август 1999 года эту инициативу поддержало свыше 25 компаний.



Разработка модели базы данных


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

Шаг 1

Нам нужно как-то назвать базу данных. Назовем ее db_website.

Шаг 2

Необходимо определить, что именно будут содержать таблицы базы данных. В БД могут входить сотни таблиц. Сначала нам потребуется всего одна таблица для хранения наших пресс-релизов. Назовем ее tbl_news_items.

Шаг 3

Следует определить поля, которые будет содержать наша таблица. Эти поля будут являть собой все элементы пресс-релиза. В нашем примере используются пять полей: col_id (числовой идентификатор пресс-релиза), col_title (название), col_date (дата публикации), col_fullstory (содержимое), col_author (имя автора). Поле col_id будет содержать уникальный идентификатор, по которому пользователь сможет запрашивать содержимое определенного пресс-релиза.



Развитие технологии составления документов


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

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

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

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


Вставка внешнего файла в HTML-страницу - это самый простой способ применения SSI: <html> <head> ... </head> <body> ... <!-#include virtual= <file.htm> -> ... <!-#include file= <file.htm> -> ... </body> </html>

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

Вставка в документ результатов исполнения программ открывает гораздо больше возможностей. Такие вставки тоже могут быть двух типов: <html> <head> ... </head> <body> ... <!-#exec cmd= <date> -> ... <!-#exec cgi = <my_prog.cgi> -> ... </body> </html>

Конструкция <exec cmd=> дает возможность вставить в документ результат выполнения внешней программы, например, date (вставка текущей даты). Вариант <exec cgi=> позволяет вставить в документ результат выполнения cgi-сценария. Это очень мощное средство проектирования страниц узла, которое позволяет через механизм CGI принимать запросы от браузеров и генерировать страницы с учетом результатов выполнения этих запросов. Именно таким способом первоначально реализовывались системы поиска в базах данных, а позднее и системы поиска информации по ключевым словам.

Порядок обработки запроса от браузера на получение документа со вставками (Server Parsed Document) следующий:

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

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

начать поиск и интерпретацию директив SSI в документе, а также модификацию содержания страницы за счет подстановок;

сформировать отклик и отправить его браузеру.

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

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


Кроме того, были разработаны расширенные языки SSI. Наиболее известными продолжениями данного подхода с определенными оговорками можно считать пакет PHP, чрезвычайно популярный среди разработчиков узлов под управлением сервера Apache, а также механизм ASP, который был реализован в IISt. Но главную роль в развитии технологии программирования составных документов сыграл механизм LiveWare, впервые реализованный в 1995 году в серверах компании Netscape Communications. Благодаря SSI документ стал составным на стороне сервера. Но Web-технология имеет архитектуру клиент-сервер, поэтому необходимо было реализовать такие же возможности формирования документа и на стороне клиента.

Для большинства разработчиков Web программирование в рамках спецификации LiveWare связано с JavaScript. Этот простой объектно-ориентированный язык программирования на стороне браузера позволил "оживить" Web-страницы. Примечательно, что практически все учебники по JavaScript начинаются с описания элемента разметки SCRIPT. В этом легко усматривается традиция SSI. Дело в том, что JavaScript предполагает четыре способа размещения программного кода на HTML-странице и передачи управления интерпретатору для выполнения этого кода. Элемент разметки SCRIPT - только один из них. При этом методологически правильнее начать изучение языка с URL-схемы javascript, позволяющей программировать гипертекстовые переходы, или с обработчиков событий, программирование которых позволяет заменять правила реакции браузера на действия пользователя по умолчанию.

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

Остановимся теперь на технологии, которая стала, с одной стороны, развитием HTML-разметки, а с другой - следующим шагом по направлению к XML.


Речь идет о каскадных таблицах стилей, Cascading Style Sheets (CSS), патентом на спецификацию которых владеет Microsoft. Но спецификация относится к категории открытых стандартов и может использоваться всеми разработчиками ПО для Web. Основная идея CSS состоит в том, чтобы отделить логическую структуру документа от формы его представления (способа форматирования изображения на носителе).

С появлением CSS в HTML стало возможным использование двух обобщенных элементов разметки: DIV (обобщенный блок) и SPAN (обобщенный строчный элемент разметки). Теперь можно составлять логическую структуру документов, а затем определять формат ее отображения.

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

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

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

Первоначально в Java не предполагалось осуществлять манипулирование объектами HTML-страницы и, хотя Duke бегал по границе экрана браузера Sun, реально Java внедрился в документ только в виде элемента разметки applet. Как универсальный язык программирования интерфейсов, главным образом графических, Java поддерживал более абстрактные типы данных и объекты, чем это требовалось для программирования HTML-страниц.

Сейчас ситуация изменилась. На Java написаны браузеры и серверы. При этом Java-код являетя изначально интерпретируемым.Следовательно, на Java можно писать SSI и изменять содержание документа на стороне браузера. Но возможности Java сегодня используются прежде всего для преодоления негативных особенностей HTTP-обмена (поддержка постоянных TCP-соединений) и вывода динамически изменяемой графики. Следует отметить, что протокол HTTP версии 1.1 [6] позволяет компоновать документ из различных частей, которые могут располагаться на разных серверах. Это не установка нового соединения для подкачки картинки при разборе HTML-документа, а список заголовков HTTP-отклика, в которых указывается URL. Таким образом, HTTP модифицирован для поддержки составных документов.


Rcp


Команда rcp копирует файлы в или из других систем, которые поддерживаются BSD-сетью. Доступ к файлам на удаленной системе контролируются тем же способом, что и при использовании команды rlogin . Использовать rcp вы сможете в том случае, если у вас есть разрешение использовать rlogin для связи с удаленной машиной без подтверждения пароля.

Чтобы скопировать файл groucho из вашей home -директории удаленной машины harpo в локальный файл chico , вы должны ввести следующую командную последовательность:

rcp harpo:groucho chico

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

rcp chico harpo:groucho

Можно скопировать сразу всю директорию, указав опцию -r . Команда

rcp -r tuna_fish harpo:big_store

скопирует содержимое локальной директории tuna_fish в директорию с именем big_store на удаленной машине harpo . При этом, если такой директории на удаленной машине не существует, то она создастся. Можно копировать файлы, используя шаблон. Например вы хотите скопировать все фортрановские программы из локальной директории в директорию на удаленной машине harpo :

rcp *.f harpo:fortran_dir

Чтобы скопировать все фортрановские программы из директории fortran_dir на удаленной машине harpo в локальную директорию local_dir , нужно ввести:

rcp harpo:fortran_dir/\*.f local_dir

Если же имя host а и имена файлов заключить в кавычки, то тогда не нужно использовать символа \\everb :

\bverb rcp 'harpo:fortran_dir/*.f' local_dir

Если вы работаете на локальной машине aries под пользовательским именем jones и хотите скопировать файл chico в файл group на удаленной машине harpo , на которой вы работаете под именем boby (т.е. имена пользователей отличаются), то вам необходимо ввести следующую команду:

rcp chico boby@harpo:group



Rdist


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

Выполнить rdist команды можно из командной строки или из командного файла. По умолчанию, rdist будет искать командный файл под именем `` distfile ", затем под именем `` Distfile ".

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

var_n = name_l

или

[label:] source_l -&gt dest_l

command_list

где

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

name_l - Список файлов, директорий или машин.

label - Метка для дальнейших ссылок.

source_l - Список файлов или директорий на локальной машине, которые будут выступать как главные копии.

dest_l - Список машин, на которых главные копии будут устанавливаться.

command_list - Команды программы rdist.

Например, команда

FILES = (.login .cshrc .mailrc .logout .rhosts )

назначает переменной FILES список файлов, указанных в скобках. А команда

HOSTS = ( aries gemini libra pisces )

назначает переменной HOSTS список имен машин. А затем эти переменные можно использовать в подкомандах программы rdist. Последовательность команд:

dotfiles: ${FILES} -&gt ${HOSTS}

install -y;

установит копии, определенные переменной FILES на удаленные машины, заданные переменной HOSTS . Опция `` -y " предотвращает обновление удаленных файлов, которые модифицировались позднее, чем соответствующие исходные файлы на локальной машине.

Программа rdist может быть также использована для копирования файлов с одной системы на другие, причем ее использовать предпочтительнее, чем команду rcp , поскольку rdist сохраняет режимы доступа владельца и группы, а также время последней модификации. Для таких целей rdist используется с ключом -c . Например, скопировать содержимое директории tuna_fish в директорию big_store на удаленной машине с именем harpo:

rdist -c tuna_fish harpo:big_store



Ресурсы Internet


Тим Брей, соредактор спецификации Extensible Markup Language (XML) 1.0, написал отличное введение в XML «XML и второе поколение Web» для Scientific American. Его можно прочитать на . Его же статью «Расширение концепции документа» можно найти на сервере журнала Web Techniques по адресу: .

Домашняя страница XML консорциума World Wide Web со ссылками на ознакомительные статьи, ответы на вопросы и соответствующие стандарты расположена по адресу: .

Страница Мариуса Гаршола с бесплатным программным обеспечением XML находится на .

Привлекательную информационную страницу «Что такое XML можно найти на .

Страница «Как овладеть XML» компании Washington Technology содержит 10 различных ссылок, в том числе ответы на вопросы, с помощью которых вы сможете быстро овладеть XML. См. .

Пользователям Internet Explorer 5 любопытная демонстрация на позволяет интерактивным образом изменять представление файла XML посредством применения различных таблиц стилей.

Если вы хотите быть в курсе событий в области XML, то посетите , публикуемый Seybold Publications и O-Reilly.



Ресурсы Internet


Вся информация о BizTalk, в том числе полная спецификация тегов BizTalk, имеется на .

Полная спецификация Internet Content Exchange (ICE) доступна интерактивным образом на .

Дополнительную информацию о XML Schema можно найти на .



Ресурсы Internet


Наилучшей исходной точкой для более подробного знакомства с WBEM является сервер DMTF с адресом . Там вы найдете спецификации для всех схем Common Information Model (CIM), а также Extensible Markup Language (XML), Document Type Definition (DTD) для CIM, таблиц стилей для Cascading Style Sheet (CSS) и Extensible Style Language (XSL), реализации CIM поверх HTTP и кодирования XML для CIM Schema.

Программное обеспечение Solaris WBEM Services и комплект для разработки программного обеспечения Sun WBEM можно бесплатно загрузить с .

Microsoft имеет большие планы в отношении применения XML для разных задач, а не только управления сетями и системами. Подробную же информацию о Windows Management Instrumentation (WMI), Win32 CIM Object Manager можно найти на .



Революция в ИТ


Х-фаза Интернет

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

Вместе с тем, существенный рост Интернет выявил все недостатки технологий, основанных на языке HTML. HTML (HyperText Markuo Language) был разработан для решения задачи отображения содержимого (некоторые эксперты превратили его применение в искусство) и для ручного поиска информации. Однако, HTML не подходит для автоматической обработки информации. Например, наш браузер "знает", что конструкция <h1>Sun</h1> появится на экране как заголовок. Но какой смысл несет содержимое? Одна из звезд нашей галактики? Имя джазового музыканта? Название компьютерной компании? Мы можем только догадаться по контексту, а компьютер - нет.

В 1996 году группа экспертов, возглавленная Йоном Босаком (Jon Bosac) из компании Sun Microsystems и поддержанная консорциумом World Wide Web (W3C) начала разработку нового стандарта. Этот новый стандарт должен был бы быть простым, расширяемым и читаемым (понятным) как людьми, так и компьютерами. В феврале 1998 года этот стандарт обрел имя: XML - eXtensible Markup Language (расширяемый язык разметки). В этот же год он начал применяться в электронной торговле. По данным агентства Zona Research уже в третьем квартале по сравнению со вторым процент компаний, использующих XML, вырос с 1-го до 16. Новый стандарт был быстро одобрен и принят такими лидерами индустрии как Sun, Microsoft, DataChannel, NetScape, IBM, SAP Adobe и Software AG. За это же время с помощью XML разработаны десятки "вертикальных" стандартов, таких как: CDF (Channel Definition Format), OSD (Open Software Description), и т.п., что делает XML для Интернет действительно lingua galactica.

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

Какие же свойства XML делают его столь привлекательным?




Простота

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

Открытость

Язык XML является стандартом W3C. По сути, когда говорим об XML, мы понимаем совокупность трех тесно связанных стандартов: собственно XML - как средство описания структуры документов, XSL - как средство преобразования XML-документа в HTML-документ или в другую среду отображения; и XLL - расширяемый (или открытый) язык связывания документов, аналогичный применяемому в HTML, но имеющему возможность, например, устанавливать многонаправленные ссылки, ссылаться не на весь документ, а на конкретный его элемент, и т.д. Кроме того, для разработчиков приложений предоставляется возможность использовать программный интерфейс XML OM, реализованный, в частности Microsoft в виде DOM (Document Object Model).

Расширяемость

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

Само-определенность

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

Идентификация автора и версий документа на уровне элемента XML.

Любой элемент XML может иметь неограниченное число свойств, таких как автор или номер версии.

Машинно-читаемый контекст

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



Разделение содержания документа от формы его представления

Тэги XML описывают значение, а не представление выделяемой ими части документа. Девиз HTML: "Я знаю, как это выглядит". Девиз XML: "Я знаю, что это значит, а ты можешь мне сказать, как это должно выглядеть ". Собственно форма представления документа в формате XML может управляться с помощью расширяемых стилей (XSL - eXtensible Stylesheets Language), позволяющих менять внешний вид документа, не затрагивая его содержание. Одно и то же содержание может быть легко представлено в нескольких видах.

Поддержка многоязыковых документов и Unicode

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

Сравнение и агрегация данных

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

Разные типы данных

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

Работа с существующими данными

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

Взгляд на распределенные данные с одного сервера

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

Быстрое одобрение индустрией программного обеспечения

Такие компании как Software AG, IBM, Sun, Microsoft, SAP, NetScape, DataChannel и многие другие уже объявили о поддержке XML. Microsoft будет применять XML в качестве формата обмена в Microsoft Office, а также в IE5. SAP объявила о поддержке XML в составе SAP Business Connector with R/3, Software AG поддерживает XML в линии продуктов Bolero и Natural и выпускает Tamino как информационный XML-сервер.


Режим прокрутки Scrollback mode


Клавиша Scroll Lock устанавливает сессию в режим обратной прокрутки. При этом в 25й строке экрана загорается соответствующий флаг. Режим прокрутки позволяет с помощью курсора (клавиши PgUp, PgDn, стрелки вверх и вниз) или мыши перемещаться по всему тексту текущей сессии, просматривая ее содержание.

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

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



Rlogin


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

Формат команды:

rlogin hostname

где hostname это логическое имя удаленной машины.( Отметим, что ВСЕГДА вместо логических номеров машины вы можете использовать IP-адрес.) Например,

rlogin aries

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

Команда rlogin может применяться последовательно, что дает возможность входить на удаленную машину через ряд промежуточных. Так, предположим, что между вашей машиной и машиной aries нет прямого соединения. Тогда команда rlogin aries , естественно, не будет выполнена успешно. Однако если вы имеете соединение, скажем, с машиной hydra , и знаете, что эта с этой машины доступна aries , вы последовательно выполняете две команды rlogin :

rlogin hydra и

rlogin aries

(по ходу дела вводя пароли)

Выход из сетевого соединения с удаленной машиной осуществляется командой exit . Отметим, что в последнем примере после выполнения команды exit вы окажетесь в операционной среде машины hydra. И чтобы перейти на локальную машину вам придется ввести еще одну команду exit . Более простой способ закрыть все сетевые соединения и вернуться на локальную машину-это ввести последовательность `` ~. ''. Последовательность `` Ctrl-Z '' приостанавливает работу на удаленной машине и позволяет оказаться на командном уровне вашей локальной машины. Команда fg возобновляет работу на удаленной машине.

Если вы выполняете rlogin на удаленную машину, в которой у вас нет home -директории, то система выведет на экран сообщение об ошибке и назначит вам, по умолчанию, home-директорию " / ".

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

rlogin aries -l jones .

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

unknown host данная удаленная машина не определена в базе данных для имен host'ов

Connection refused удаленная машина существует в базе данных host имен, но она посылает сообщение, что отказывается от связи

Network unreachable нет маршрутной карты для данной удаленной машины

Connection timed out удаленная машина не отвечает на требование связаться, это сообщение обычно указывает на то, что удаленная машина выключена



Rsh


Команда rsh используется для выполнения команд через сеть. Например, вы хотите скомпилировать фортрановскую программу cad.f на удаленной машине gemini . Для этого введите

rsh gemini fc cad.f

Если вы используете другое login имя (например, boby ) на удаленной машине, то используйте опцию -l также, как в случае команды rlogin :

rsh gemini -l boby fc cad.f

Доступ к удаленным системам по команде rsh контролируется также, как для команды rlogin . Чтобы воспользоваться командой rsh , вам должно быть разрешено выполнять команду rlogin для доступа к удаленной системе без подтверждения пароля. Команда rsh не позволяет выполнять интерактивные команды.