ТРАНСПОРТ ДАННЫХ

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

HTTP распространен практически повсеместно, он реализован во всех браузерах Web на каждой платформе. Кроме того, в наши дни практически любая ОС — как серверная, так и настольная — имеет сервер Web. Более того, практически всякое межсетевое устройство, сетевой принтер или другой управляемый объект, появившийся за последние два года, содержит встроенный сервер Web, благодаря которому конфигурация и мониторинг могут производиться непосредственно из браузера. По информации Rapid Logic, компании-разработчика инструментария для быстрой разработки встроенных управляющих приложений, необходимая для реализации демона HTTP, т. е. сервера Web, память в операционной системе реального времени не превышает 8 Кбайт.

HTTP хорошо знаком программистам. Многие из шероховатостей HTTP 1.0 были устранены в 1. 1.

Одной из важнейших разработок с точки зрения приложений для управления сетями и системами является создание Secure HTTP (HTTPS) и Secure Sockets Layer (SSL). Уязвимость до сих пор остающейся наиболее широко реализованной первой версии SNMP для любого злоумышленника, если он имеет возможность перехватить пакеты в управляемой сети, является самым застарелым недостатком в мире управления сетями и системами. Использование предназначенных для транзакций по кредитным картам возможностей защиты HTTP позволяет организовать защищенные сеансы управления между приложениями или между пользователем и управляемым объектом.

Объединение CIM, XML и HTTP в WBEM обещает наконец-то решить проблему управления гетерогенными сетевыми средами в эру Internet. Программы разбора XML, в составе браузеров и отдельные, существуют для многих платформ и на многих языках программирования.

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

Приложения, пользователи и устройства, клиенты и приложения могут обмениваться между собой структурированными управляющими данными независимо от ОС (будь то Windows, UNIX или Novell); независимо от языка программирования (будь то Perl, C++, Java или Visual Basic); независимо от объектной модели (будь то CORBA или COM) и независимо от установленной платформы управления (будь то OpenView, Unicenter TNG, Tivoli или Spectrum). Предоставляемые поставщиком усовершенствования и расширения могут быть быстро интегрированы и ассимилированы, когда приложение имеет возможность справиться об определении управляющих данных в централизованных постоянно обновляемых DTD.

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

Три реализации ICE

На ICE Summit в Чикаго в июле 1999 года было продемонстрировано три ICE-совместимых менеджера распространения новостей.

WebExpress

Arcadia Technology

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

ShiftKey Syndication System

ShiftKey Software

ShiftKey решила повысить ценность своего продукта за счет добавления поддержки ряда средств преобразования информационного наполнения после его поступления на сервер подписчика. В конце концов, ICE просто доставляет информационное наполнение в стандартном формате, а он ведь может и не подходить для прямого включения данных в Web-страницы подписчика. Один из поддерживаемых ShiftKey методов трансформации — Extensible StyleSheet Language (XSL), он определяет, как теги XML должны отображаться в браузере. Необходимые преобразования описывают таблицы стилей.

Что касается серверной стороны, ShiftKeySoftware на момент публикации статьи была единственной компанией, поддерживающей распространение по запросу подписчика (pull) и по каналам агентства (push) и предоставляющей сервер ICE, не привязанный к системе управления информационным наполнением.

Vignette Syndication Server

Vignette

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

Предложение Vignette тесно привязано к Vignette Story Server, системе управления информационным наполнением Web старшего класса, используемой такими издательскими гигантами, как Time Warner, Ziff-Davis и Chicago Tribune.

Управление

Управляющими элементами в WML являются элементы "select" и "input". У каждого есть несколько подэлементов, а также механизм группировки, для приведения нескольких относящихся друг к другу элемементов ввода к одной логике. Также тут присутствует атрибут tabindex. этот атрибут определяет последовательность в которой происходит передвижение по элементам.

Элемент

Select

Атрибуты

multiple - по умолчанию равно "off". При включении этого атрибута пользователь может выбрать несколько элементов из предложенного списка.

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

value - значение элемента по умолчанию.

iname - имя выбранного элемента(ов) списка. Значение "0" означает, что в списке нет элементов. Нумерация элементов списка начинается с "1" и постепенно увеличивается.

ivalue - имя переменной, в которой содержится значение(я) выбранных элементов списка. Несколько значений можно ввести, разделяя их ";", например (1;2) . Нельзя вводить пустое значение переменной. Так значение (1;;2) - неправильно.

title - заголовок. Указывается для того, что бы микроброузер определил тип навигационного элемента.

tabindex - очередь следования этого элемента относительно других. Реализация зависит от броузера.

Элемент:

Option

Атрибуты:

value - значение, присваемое переменной элемента select, в случае выбора этой опции

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

onpick - URL на который пойдет микроброузер, в случае выбора этой опции.

Элемент:

Optgroup

Атрибуты:

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

<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN""http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card> <p> Bogus: <select name="bogus"> <optgroup title="one"> <option value="uno">uno</option> <option value="eins">eins</option> </optgroup> <optgroup title="two"> <option value="dos">dos</option> <option value="zwei">zwei</option> </optgroup> </select> </p> </card> </wml> <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN""http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <template> <do type="options" label="Back"> <prev/> </do> </template> <card id="lists"> <p> <select title="Pick Lists"> <option onpick="#single">Single</option> <option onpick="#multiple">Multiple</option> </select> </p> </card> <card id="single"> <onevent type="onenterbackward"> <prev/> </onevent> <do type="accept"> <go href="#display_fav"/> </do> <p> Pick your fav Stooge: <select name="fav" title="Stooges"> <option value="Moe">Moe</option> <option value="Shemp">Shemp</option> <option value="Larry">Larry</option> <option value="Curley">Curley</option> <option value="Curley Joe">Curley Joe</option> </select> </p> </card> <card id="multiple"> <onevent type="onenterbackward"> <prev/> </onevent> <do type="accept"> <go href="#display_fav"/> </do> <p> Pick your fav Marx Bro. <select multiple="true" title="Marx Bros" name="fav" > <option value="Groucho">Groucho</option> <option value="Harpo">Harpo</option> <option value="Chico">Chico</option> <option value="Zeppo">Zeppo</option> </select> </p> </card> <card id="display_fav"> <p> Your fav was $fav. </p> </card> </wml>

Элемент:

Input

Атрибуты:

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

value - значение поля по-умолчанию.

type - имеет значение либо "text" либо "password". В зависимости от микроброузера поле типа "password" может отображаться на дисплее видимым текстом.

format - маска ввода.

A - Любая буква в верхнем регистре [A-Z]

a Любая буква в нижнем регистре и пунктуация [a-z]

N - любая цифра [0-9]

X - любой символ в верхнем регистре [A-Z,0-9]

x - любой символ в нижнем регистре [a-z,0-9]

M - любой символ

m - любой символ

*f - любое количество символов определенного формата, например *N -любое количество цифр

nf - "n" это целое число так например "3A" означает 3 буквы в верхнем регистре или пунктуации.

\c - символ ввода, так например "$3N$\ \3N\-4N" означает номер телефона с кодом местности в американском формате.

emptytok - разрешает пустой ввод

size - ширина поля ввода. Реализация зависит от броузера.

Maxlength - определяет максимальное количество вводимых.

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

Элемент:

Fieldset - Использование зависит от микроброузера.

Атрибуты:

title - Заголовок

<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN""http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <template> <do type="options" label="Back"> <prev/> </do> </template> <card id="fields"> <p> Field Type: <select title="Field type"> <option onpick="#nested">Nested</option> <option onpick="#password">Password</option> </select> </p> </card> <card id="nested"> <onevent type="onenterbackward"> <prev/> </onevent> <do type="accept" label="Done"> <go href="#done"/> </do> <p> First Name: <input title="First" name="fname"/> Last Name: <input title="Last" name="lname"/> Gender: <select title="Gender" name="gender"> <option value="male">Male</option> <option value="female">Female</option> </select> </p> </card> <card id="done"> <p> $fname $lname is a $gender. </p> </card> <card id="password"> <onevent type="onenterbackward"> <prev/> </onevent> <do type="accept" label="Done"> <go href="#passwd_done"/> </do> <p> Input a password:<br/> Min 3 chars. <input title="Password" name="passwd" type="password" format="*m"/> </p> </card> <card id="passwd_done"> <p> Password was $passwd. </p> </card> </wml>

Установка MySQL

Что ж, очень полезно... Даже чересчур.

Дмитрий Котеров

Сначала определимся: зачем же вообще нужны базы данных Web-программисту? Неужели не проще писать все самому? Ведь обычно объем данных не очень велик (если Вы только не пишите поисковую систему). Наш личный опыт таков: оказывается, стоит затратить какое-то время на изучение MySQL - это удивительно мощный инструмент, который сэкономит в будущем немало часов, потраченных на отладку "взбесившегося" скрипта.

Итак, Вы решили установить у себя на локальном Apache поддержку MySQL. Как ни странно, это даже во многом проще, чем заставить работать Perl. Прежде чем привести точные инструкции, хотелось бы уточнить два момента:

Эта статья не претендует ни в коей мере на то, чтобы быть учебником по MySQL. Предполагается, что Вы уже знаете, как работать с этой базой данных. Максимум, что здесь описывается - это то, как заставить MySQL работать под Window 95/98. В дальнейшем будем считать, что Apache у Вас установлен именно там, где это рекомендовалось выше.

Что ж, приступим.

Для начала запаситесь терпением и скачайте дистрибутив MySQL - . Как можно заметить, он довольно большой. Затем разверните его в любую удобную Вам директорию. Запустите setup.exe. Он спросит, действительно ли Вы хотите установить MySQL. После того, как Вы ответите утвердительно, файлы начнут копироваться в директорию c:/mysql, т.е. он даже не спросит Вас, куда устанавливать MySQL. Ничего страшного. Теперь, если Вы любите порядок, можете скопировать директорию c:/mysql в какое-нибудь более приличное место - например, f:/usr/local/. Только после этого строго следуйте указаниям в статье. Создайте в директории f:/usr/ такие два .bat-файла:

server.bat:

@echo off f:\usr\local\mysql\bin\mysqld.exe --basedir f:/usr/local/mysql f:\usr\local\apache\Apache.exe

shutdown.bat:

@echo off f:\usr\local\apache\Apache.exe -d f:\USR\LOCAL\APACHE -k shutdown "f:\usr\local\mysql\bin\mysqladmin.exe" -u root shutdown

Файл server.bat Вы будете запускать, когда захотите "включить" Apache и одновременно MySQL (ясно, что бессмысленно запускать MySQL без сервера), а shutdown.bat - для завершения работы Apache и MySQL. Очень важно завершать работу MySQL правильно - иначе могут быть испорчены таблицы баз данных.

Собственно, для этого мы и сделали эти два .bat-файла. (Кстати говоря, в отличие от Apache, у MySQL нет своего окна - ее процесс можно увидеть, лишь нажав Ctrl+Alt+Del. Это еще одна причина существования shutdown.bat).

Теперь для удобства можно создать ярлыки на Рабочем столе для этих файлов. Рекомендуем также назначить этим ярлыкам "горячие" клавиши: например, для запуска сервера - Ctrl+Alt+A, а для завершения работы - Ctrl+Alt+S. Кроме того, лучше поставить у этих ярлыков параметры "Запускать свернутыми в значок". Все это сильно упростит жизнь в дальнейшем.

Что ж, считайте, MySQL уже установлена. Осталось только создать базу данных. Для этого следует запустить f:/usr/local/mysql/bin/mysqladmin с ключем create имя_базы. Например, если мы хотим создать базу testbase, нужно ввести в окне Сеанса MS-DOS:

f: cd f:\usr\local\mysql\bin mysqladmin create testbase

Если Вы планируете использовать MySQL в скриптах на PHP, проверьте, раскомментирована ли в файле php3.ini (расположенном в директории с PHP и в c:\windows) следующая строка: extension=php3_mysql.dll

Если в ее начале стоит точка с запятой, уберите ее - иначе PHP не сможет опознавать функции для работы с MySQL

Поздравляем - теперь можно работать! Если хотите, можете проверить работоспособность MySQL следующим скриптом на PHP3 (скажем, расположенном в f:/www/test.php3):

<? Error_Reporting(1+2+4); define("DBName","testbase"); define("HostName","localhost"); define("UserName","root"); define("Password","");

if(!mysql_connect(HostName,UserName,Password)) { echo "Не могу соединиться с базой ".DBName."!<br>"; exit; }

// Создаем таблицу test. Если такая таблица уже есть, сообщение об ошибке будет // подавлено, т.к. используется "@" @mysql(DBName,"create table test(id int,a text)");

// Вставляем в таблицу 10 записей for($i=0; $i<10; $i++) { $id=time(); mysql(DBName,"insert into test(id,a) values($id,'Строка $i!')"); }

// Выводим все записи $r=mysql(DBName,"select * from test"); for($i=0; $i<mysql_numrows($r); $i++) { $f=mysql_fetch_array($r); echo "$f[id] -> $f[a]<br>\n"; }

?>

Обращаем Ваше внимание на макросы DBName, HostName, UserName и Password. DBName должен содержать имя базы данных. HostName - всегда localhost, ведь мы работаем на локальном компьютере. В макросе UserName проще всего подставлять root, который является собственником всех таблиц. При установке MySQL пользователю root не назначается пароль, так что макрос Password равен пустой строке.

Установка Perl

"Язык может считаться законченным только тогда, когда

в его синтаксисе используются все клавиши на клавиатуре"

Отец-основатель Perl

Это совсем просто, за исключением, может быть, выбора директории для Perl. А именно, Вы ДОЛЖНЫ разместить Perl в той же директории, в которой он находится на Вашем настоящем Web-сервере. Заметьте, что это очень важно, так как Perl требует, чтобы в каждом скрипте первой строкой стоял путь к Perl-интерпретатору; например, эта строка может выглядеть так: #!/usr/local/bin/perl

Эту же строку можно было бы написать и так: #!/usr/local/bin/perl.exe

или даже так: #!f:\usr\local\bin\perl.exe

Это заставляет искать Perl-интерпретатор в директории f:/usr/local/bin/ (если диск f: не указан, это означает, что он совпадает с диском, на котором расположен Apache). Ясно, что если Вы установите Perl не в такую же директорию, как на настоящем Web-сервере, Вам придется каждый раз менять эту самую первую строку во всех скриптах при закачке их на сервер. Итак, далее мы будем считать, что эта директория такова, как на большинстве Apache-серверов: f:/usr/local/bin

ВНИМАНИЕ: очень распространенной ошибкой является установка Perl не в ту директорию или не на тот диск. Еще раз обращаем внимание на то, где должен быть расположен транслятор. Если Вы все же по какой-то необъяснимой причине не придерживаетесь нашего совета, то проверьте первую строку в Вашем скрипте. Она должна указывать не на директорию с Perl, а на исполнимый файл perl.exe. Напоминаем, что #!/usr/local/bin/perl

заставляет искать Perl-интерпретатор perl.exe в директории f:/usr/local/bin/, а не f:/usr/local/bin/perl

Если Вы все же установите пути неправильно, Apache выдаст непонятное сообщение об ошибке, а в errors.log появится сообщение: couldn't spawn child process. В этом случае проверьте все еще раз. Если кажется, что все в порядке, то, возможно, имеет место описанная выше ошибка с программой subst.

Вот шаги, приводящие к цели:

Первым делом создайте директорию f:/usr/local/bin

AddHandler

Вот, собственно, и все. Можете пользоваться Perl-транслятором. Для проверки его работоспособности используйте такой скрипт (помещенный, разумеется, в директорию cgi-bin или аналогичную): #!/usr/local/bin/perl print "Content-type: text/html\n\n"; print "It works!<br>\n"; system("dir");

В отличие от установки Apache,

"- Больной, читайте первую строчку сверху!

- Ша, Бэ, Пэ Ха Пэ... Доктор, кодировочку-то пофиксите..."

Народный фольклор

В отличие от установки Apache, установка PHP короче, однако мы бы не сказали, что проще. Дело в том, что, во-первых, у PHP нет нормальной setup-программы, как у Apache, а во-вторых, при его установке необходимо также настраивать сервер.

Итак, прежде всего поговорим о каталоге, в котором у Вас будут находиться файлы PHP. В дистрибутиве по умолчанию стоит такой: f:/usr/local/php3

Если Вы физически не можете или просто не хотите иметь такой каталог (хотя, если Вы читали инструкцию по установке Apache, все должно быть в порядке), то Вы вольны установить PHP в другой каталог, но тогда Вам предстоит следующее: в файле php_iis_reg.inf из дистрибутива PHP найти ВСЕ строки "f:\usr\local\php3" (их там, кстати, 6 штук) и заменить их на тот каталог, где Вы предполагаете разместить PHP. Могу сразу сказать, что это не самое приятное провождение времени, но уж ничего не поделаешь, такова жизнь...

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

Установка PHP

Создайте директорию f:/usr/local/php3 (если хотите другое имя, см. рассуждения выше). Это - та директория, в которую будет установлен PHP. Скачайте дистрибутив PHP - файл с именем (1.970.356 байт), желательно в только что созданную директорию. Это саморазворачивающийся zip-архив, который Вы должны будете запустить, чтобы разархивировать. По умолчанию он развернется в текущую директорию, так что будьте внимательны. Еще раз напоминаем: если Вы решили установить PHP в другую директорию, Вам необходимо вручную отредактировать файл php_iis_reg.inf с целью замены в нем имен директории на нужную (см. выше). В файле php3.ini из дистрибутива есть закомментированные строки, выглядящие так: ;extension=имя_модуля.dll

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

Теперь в Проводнике Windows нажмите правой кнопкой мыши на файле php_iis_reg.inf и выберите в контекстном меню пункт Установить - этим Вы автоматически добавите в Реестр некоторые установки, касающиеся PHP. Скопируйте файл php3.ini в каталог с Windows (например, в c:/windows);

Настройка Apache

В файл конфигурации Apache conf/mime.types добавтьте такую строку: application/x-httpd-php3 phtml php3 php

Теперь откройте файл conf/httpd.conf и добавьте в его конец (но перед блоков виртуальных хостов, если они там есть) такие строки: <Directory "f:/usr/local/php3"> Options ExecCGI </Directory> ScriptAlias "/__php_dir__/" "f:/usr/local/php3/" Action application/x-httpd-php3 "/__php_dir__/php.exe"

Ну вот, пожалуй, и все. Если Вы все сделали правильно, то PHP установлен. Проверьте его работоспособность с помощью простого скрипта, например такого: <? echo "It works!<br>\n"; phpinfo(); ?>

Напоминаем, что php-скрипты - не то же самое, что cgi-скрипты. В частности, если cgi-скрипты обычно располагают в /cgi-bin/, то php-скрипт должен лежать в директории с документами. Иными словами, файл в этом примере должен называеться примерно так: f:/www/test.php3

Утилиты DARPA

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

Уведомления, управляемые событиями

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

Уведомления работают следующим образом:

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

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

Если обнаруживается запланированная проверка уведомления, то приложение тестирует все условия (бизнес-правила).

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

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

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

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

инвестору, если курс акций падает ниже определенного уровня;

торговому представителю, если предвидится хорошая сделка;

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

В результате активного развития

Несмотря на наличие ресурсов и риск убытков, сопровождающих их головокружительную рыночную капитализацию, некоторые из наиболее известных лидеров «Internet-экономики» столкнулись в последние месяцы с неожиданным ухудшением обслуживания и простоями. Недавние происшествия с MCI WorldCom и eBay свидетельствуют о фундаментальных трудностях управления распределенными сетями и системами. Charles Schwab, E*Trade, Excite@Home, AOL и AT&T в последние годы также испытывают значительные сложности в управлении.

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

Например, интерфейс управления настольными системами (Desktop Management Interface, DMI) широко реализуется в офисных настольных ПК и некоторой периферии, тогда как практически повсеместно применяемый на межсетевых устройствах SNMP менее широко распространен на серверах и, можно сказать, отсутствует в прикладном программном обеспечении. В некоторых частях мира управление сетью осуществляется в соответствии со стандартами CMIP, а в области связи используются свои особые протоколы для управления коммутаторами и другими устройствами. Ситуацию усугубляет то, что в наши дни новые продукты часто выпускаются вообще без поддержки какого-либо из перечисленных протоколов управления.

Идея корпоративного управления на базе Web (Web-based Enterprise Management, WBEM) возникла как реакция на отсутствие единой модели. Ее инициаторы — Microsoft, Cisco Systems, Compaq Computer, BMC Software и Intel — выдвинули план использовать стандартизованные технологии взаимодействия и защиты Web для управления системами и сетями. В 1998 году ответственность за разработку WBEM была передана рабочей группе по распределенному управлению (Distributed Management Task Force, DMTF, ранее Desktop Management Task Force).

По мере готовности WBEM стали вырисовываться три ее основных компонента: общая информационная модель (Common Information Model, CIM), набор объектно-ориентированных схем для управляющей информации; HTTP, универсальный транспортный протокол для передачи информации на базе Web; расширяемый язык разметки (Extensible Markup Language, XML), простой и в то же время мощный метод создания той полезной нагрузки, которую HTTP передает из одного приложения в другое, из браузера в приложение и из браузера в управляемый объект.

Ваш собственный Золотой Стандарт

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

Никто другой абсолютно аналогичным бизнесом не занимается.

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

Конвертируя в два этапа, вы устраните проблему N-квадрата. Для каждой новой системы или нового формата XML-сообщений останется построить одно преобразование (из общей логической модели), но не N!

Необходимые шаги:

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

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

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

Важнейшие факторы успеха

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

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

Распространение значимого материала, необходимого для принятия решений, в том числе и материалов «третьих сторон» (рисунков, документов Word, презентаций Power Point, отчетов, созданных как при помощи программных средств, приобретенных у различных поставщиков BI, так и старых (legacy) отчетных приложений). Доставка информации по различным каналам, таким как электронная почта, Web, факс, сетевой принтер и т.п.; передача информации на мобильные устройства.

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

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

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

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

Вид экрана

После установления связи и login, на РС будет эмулироваться терминал VT100. Он поддерживает 24 строки экрана. 25-я строка - это строка состояния, в которой указываются:

Слева:

на сером фоне: названия сессий (машин, с которыми осуществлена связь)

в углу квадратик: указывает на текущую сессию.

в углу * : Попытка установления (восстановления если подвисла) связи

/ или \ : Пишется текст в эту неактивную сессию.

Справа:

флаг открытия capture файла (куда записывается текущая сессия)

флаг режима прокрутки (scrollbackmode)

FTP статус

Время, в режиме clockmode

Виртуальные хосты Apache - как это настроить?

"Виртуальные хосты - хосты, имеющие уникальный адрес
в Интернет, эмулируемые и поддерживаемые сервером"

Древнее языческое заклинание

Итак, Вы установили Apache. Получили, таким образом, директорию f:/www для хранения документов и f:/cgi-bin для CGI. Но вот беда: в Интернете вы поддерживаете несколько серверов, а Apache создал для вас только один. Конечно, можно структуру этих несколькох серверов хранить на одном сервере, однако проще и удобнее было бы создать несколько виртуальных хостов с помощью Apache, например, один с именем serv1 и адресом 127.0.0.2, а другой - с именем serv2 и адресом 127.0.0.3. (Конечно, вместо "serv1" и "serv2" Вам нужно будет указать желаемые имена Ваших виртуальных хостов. Советуем назвать их так же, как и на Вашем настоящем Web-сервере - это может многое упростить при программировании скриптов.)

Как это принято в Unix, каждый сервер будет представлен своим каталогом в директории f:/home с именем, совпадающим с именем сервера. Например, сервер serv1 будет храниться в директории f:/home/serv1, которую Вам необходимо создать прямо сейчас. В этой директории будут находиться:

файл access.log с журналом доступа к виртуальному серверу. файл errors.log с журналом ошибок сервера. директория www, где будут храниться html-документы. директория cgi для хранения CGI-программ.

Последние две директории (www и cgi) Вам тоже необходимо создать прямо сейчас.

Далее, для установки виртуального хоста необходимо сделать некоторые изменеия в файле конфигурации Apache httpd.conf (см. выше), а также в некоторых файлах Windows. Вот необходимые действия:

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

Пропишите следующие строки в конце файла после всех комментариев:

#----serv1 <VirtualHost 127.0.0.2> ServerAdmin webmaster@serv1.ru ServerName serv1 DocumentRoot "f:/home/serv1/www" ScriptAlias /cgi/ "f:/home/serv1/cgi/" ErrorLog f:/home/serv1/error.log CustomLog f:/home/serv1/access.log common </VirtualHost>

При желании можно добавить и другие параметры (например, DirectoryIndex и т.д.) Вообще, не переопределенные параметры наследуются виртуальным хостом от главного.

Теперь надо немного подправить системный файл hosts, который находится в C:\WINDOWS\hosts (такого файла может не быть по умолчанию - в этом случае его надо создать). hosts (не путать с файлом hosts.sam!) - обычный текстовый файл, и в нем обычно заранее прописана только одна строка: 127.0.0.1 localhost

именно эта строка и задает соответствие имени localhost адресу 127.0.0.1. (Ради справедливости следует сказать, что имя localhost работает и без указанной выше строки. Ну и выдумщики же эти парни из компании Microsoft!) Для нашего виртуального хоста надо добавить соответствующую строчку, чтобы файл выглядел так: 127.0.0.1 localhost 127.0.0.2 serv1

Этим Вы создадите виртуальных хост со следующими свойствами:

Имя - serv1

Доступен по адресу http://serv1 (или http://127.0.0.2). Расположен, соответственно, в директории f:/home/serv1. Директория для хранения документов - f:/home/serv1/www, доступная по адресу http://serv1/. Директория для CGI - f:/home/serv1/cgi, доступная по адресу http://serv1/cgi/

Файлы журналов хранятся в f:/home/serv1

Ну вот, мы создали один виртуальный хост! Если будет необходимо сделать второй, нужно просто проделать аналогичные действия, заменив параметры, связанные с расположением хоста на диске. Главное, не забудьте в этом случае указать другой IP-адрес (лучше всего указывать их последовательно, начиная с 127.0.0.2, затем 127.0.0.3 и т.д. - в этом случае все работает корректно). Желательно также для этих целей не указывать IP-адрус http://127.0.0.1, так как это - адрес главного сервера.

Кстати, необходимо заметить, что главный хост (невиртуальный, тот, который мы создали в разделах 1 и 2) по-прежнему доступен по адресу http://127.0.0.1 или http://localhost. Более того, его директория cgi-bin "видна" всем созданным виртуальным хостам, так что Вы можете ее использовать.

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

Возможности NCSA Telnet

Эмуляция терминала VT100 на PC;

Поддержка локального принтера для VT100; (* не было опробовано)

Одновременный доступ к нескольким машинам (формально до 20 машин);

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

Использование цветов PC;

Topview/Windows совместимость; (* не удалось осуществить)

Эмуляция графического терминала Textronix 4014.

Добавочные приложения - утилиты подобные стандартным UNIX: FTP, rcp, lpr, lpq, lprm, rexec, rsh, finger, setclock.

Режим прокрутки сессии scrollback mode , в котором поддерживается мышь;

Возможность вырезки/вставки текста между сессиями;

Поддержка консоли сообщений;

Возможность печати экрана в файл PC или на принтер;

DOS SHELL ( Возможность временного выхода в DOS ).

Вступление

WML - язык разметки, основанный на XML (extensible Markup Language). Официальная спецификация WML разработана и поддерживается WAP Forum, производственным консорциумом, основанном Nokia, Phone.com, Motorola и Ericsson. Эта спецификация определяет синтаксис, переменные и элементы используемые в файлах WML. Последнее определение типа документа (Document Type Definition) для тех, кто знаком с XML, доступны по адресу:

Любой правильный XML-файл должен соответствовать этому DTD. В противном случае он не будет правильно обработан.

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

Современная динамика бизнеса, подталкиваемая развивающимися

Современная динамика бизнеса, подталкиваемая развивающимися Internet-технологиями, привела к существенному росту объема данных, хранящихся в корпоративных системах.
Многие предприятия столкнулись с проблемой избытка информации. Системы обработки транзакций ежедневно генерируют отчеты. Сотнями способов c помощью Хранилищ данных и аналитических средств выполняются продольные и поперечные срезы информации (slice and dice). Инструменты для планирования ресурсов предприятия (Enterprise Resource Planning, ERP) собирают все данные компании. Средства оценки производительности и сведения, получаемые через Internet, еще больше усиливают информационную перегруженность.
Ситуация осложняется еще и тем, что современные предприятия функционируют на мировом рынке, а значит, их данные и приложения распределены географически, т.е. у каждого филиала своя программа и свое Хранилище. Инструменты планирования ресурсов внедряются на всех уровнях: создаются приложения для управления человеческими ресурсами, финансовые системы и ПО, ориентированное на процесс производства. Информация, используемая при работе с этими приложениями, хранится в разрозненных источниках (в разных реляционных базах, а также в файлах особых форматов и в многомерных выборках).
Сегодня многие компании теряют деньги и время, вручную распространяя информационные ресурсы. Согласно некоторым исследованиям, на создание и рассылку бумажных документов в среднем тратится около15% доходов. Так, по данным аналитической корпорации Gardner Group, корпоративные служащие тратят 10% своего времени на поиск информации, необходимой для выполнения некоторой задачи или для принятия решений, от 20% до 40% времени — на обработку уже готовых документов и 30% — на задачи связанные с документами, но не добавляющие ценности конечной услуге (продукту) компании.
Новая концепция, называемая «широким распространением информации» (information broadcasting) — это технология, которая делает возможной передачу персонализированных сообщений, необходимых для поддержки принятия решений, через Web, электронную почту, факс, пейджер, мобильный телефон сотням тысяч адресатов.
Автоматизация процесса рассылки информации может обеспечить пользователей своевременными данными, расширить возможности компании и предотвратить скопление ненужных данных.
Более того, интеллектуальные ресурсы предприятия, создаваемые с помощью BI-инструментов и аналитических пакетов, должны автоматически передаваться также и в приложения, которыми используются в операционных отделах для поддержки принятия решений.

в главное средство распространения информации.

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

Наконец, в качестве примера запроса, который вовлекает структуру страниц, рассмотрим запрос, в котором требуется найти все изображения, достижимые из корня Web-сайта CNN, используя пути, включающие не более пяти связей. Последний тип запросов особенно полезен для обнаружения нарушений ограничений целостности на Web-сайте или в совокупности Web-сайтов.
Выборка и интеграция информации: Некоторые Web-сайты могут рассматриваться на более тонком уровне гранулярности, чем страницы, как контейнеры структурированных данных (множеств кортежей, множеств объектов и т.д.). Например, сайт Internet Movie Database () может рассматриваться как внешний интерфейс базы данных о кинофильмах. В связи с ростом числа таких сайтов становятся актуальными две следующие задачи. Первая задача состоит в том, чтобы фактически осуществлять выборку данных, представленных в структурированном виде (например, множество кортежей) из HTML-страниц, их содержащих. Эта задача решается с помощью набора программ-оболочек (wrapper), создание и поддержка которых порождает ряд проблем. Если мы рассматриваем сайты такого рода как автономные неоднородные базы данных, возникает вторая задача - формулировка запросов, которые требуют интеграции данных. Вторая задача решается с помощью систем медиаторов (или систем интеграции данных).
Разработка и реструктуризация Web-сайтов: Другой аспект применения концепций и технологий баз данных - разработка и реструктуризация Web-сайтов, а также управление ими. В отличие от предыдущих двух классов задач, которые имеют дело с уже существующими Web-сайтами, здесь рассматривается процесс создания новых сайтов. Конструирование Web-сайтов может начинаться либо с некоторых исходных данных (хранимых в базах данных или в структурированных файлах), либо путем реструктуризации уже существующих Web-сайтов. Выполнение этой задачи требует использования каких-либо методов моделирования структуры Web-сайта и языков для реструктуризации данных таким образом, чтобы они соответствовали желаемой структуре.

Прежде, чем начать наш обзор, следует отметить, что мы не будем рассматривать в нем ряд вопросов, связанных с применением концепций баз данных к WWW, в частности, кэширование и тиражирование данных (см. о недавних разработках в этой области в работах [WWW98, GRC97]), обработка транзакций и безопасность в Web-средах (см., например, [Bil98]), вопросы эффективности, доступности и масштабируемости для Web-серверов (см., например, [CS98]), или, наконец, методы индексирования и технология "роботов" (crawler) (см., например, [CGMP98]). Кроме того, данную статью не следует рассматривать как обзор существующих программных продуктов, даже в тех областях, на которых мы концентрируем здесь наше внимание. Заметим, наконец, что имеется также несколько не затронутых здесь областей, которые не имеют прямого отношения к рассматриваемым системам, но в которых получены результаты, применимые к ним. К числу таких областей относятся системы управления коллекциями документов и классификации (ranking) документов (например, Harvest [BDH+95], Gloss [GGMT99]), а также гибкие системы ответов на запросы [BT98]. В заключение, нужно подчеркнуть, что сфера использования технологий баз данных в среде Web (Web/DB) очень динамична. Поэтому в нашей работе, без сомнения, есть какие-либо упущения, за которые мы заранее приносим свои извинения.
Обзор организован следующим образом. Раздел 2 мы начинаем с обсуждения основных проблем, которые возникают при разработке моделей данных для приложений Web/DB. Каждый из трех следующих разделов посвящен одному из упомянутых выше классов задач. Заключительный раздел 6 представляет перспективы и направления будущих исследований.

и обрабатывается внушительный объем разнообразной

Сегодня, в сфере бизнеса создается и обрабатывается внушительный объем разнообразной бумажной документации. Она включает в себя разные заказы на приобретение, счета, инвойсы, каталоги, отчеты, платежные поручения и т.д. Внедрение транспортных протоколов в конце 80-х годов XX века привело к стремительному развитию телекоммуникаций и дало возможность открытию ворот для электронной торговли и Электронного обмена данными (Electronic Data Interchange или EDI) Идея систем EDI заключается в стандартизации документов и представлении их в виде, удобном для компьютерной обработки.
К середине 1980-х годов в разработке стандарта EDI приняла участие Европейская экономическая комиссия ООН (UN/ECE) в лице Рабочей группы N4 по упрощению процедур международной торговли (the working Party for the Facilitation of International Trade Procedures - WP.4). И в 1987 году синтаксические правила нового языка были утверждены в виде международного стандарта ISO 9735, известного под аббревиатурой UN/EDIFACT.
Акроним UN/EDIFACT расшифровывается как "Правила ООН эелектронного обмена документами для гос. управления торговли и транспорта" (United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport).
Электронный обмен документами (EDI - Electronic Data Interchange) налагает три основные требования:
соблюдение единого синтаксиса обмена возможность выбора элементов данных единый формат, в котором эти элементы представлены при генерации сообщений и файлов для обмена.
Необходимо заметить, что отличие систем EDI от систем электронного документооборота состоит в том, что EDI системы - это межведомственные системы обмена (подачи) электронными документами, использующие строго стандартизированные правила составления электронных документов. Под системой электронного документооборота понимается системы, как правило, разрабатываемые в рамках одной корпорации или предприятия, обмен в которых осуществляется по средствам распределенных СУБД (RMDB).
Бурное развитие Internet-технологий за последнее пятилетие вовлекло в международную электронную паутину миллионы новых пользователей. Появились новые протоколы обмена, изменились требования и уже ранее внедренные EDI системы перестали удовлетворять многие группы пользователей.
В настоящее время организацией CEFACT (the United Nations Centre for the Facilitation of Procedures and Practices for Administration, Commerce and Transport - Центр по упрощению процедур и практики в управлении, торговле и на транспорте) при ООН реализуется проект ebXML - "Создание единого глобального электронного рынка", который поддерживается Организацией продвижения стандартов структурированной информации (the Organization for the Advancement of Structured Information Standards ) - OASIS. Акроним ebXML - XML for electronic bisiness т.е. XML для электронного бизнеса.

к базам данных из современного

Разумеется, что организовать доступ к базам данных из современного языка программирования в наше время не представляет никакой сложности. Более того, и сами языки программирования более всего оцениваются разработчиками по типу и возможностям заложенных в них средств доступа к базам данных, удобству и полноте интерфейсов. В этом смысле Java не представляет исключения. Уже в версии JDK1.1 появился пакет классов java.sql, обеспечивающий больщинство функций, известных к тому времени разработчикам ODBC-приложений. В этом пакете содержится ряд замечательных классов, например: java.sql.CallableStatement, который обеспечивает выполнение на Java хранимых процедур; java.sql.DatabaseMetaData, который исследует базу данных на предмет ее реляционной полноты и целостности с получением самых разнообразных данных о типах и содержимом таблиц, колонок, индексов, ключей и т.д.; наконец, - java.sql.ResultSetMetaData, с помощью которого можно выводить в удобном виде всю необходимую информацию из таблиц базы данных или печатать сами метаданные в виде названий таблиц и колонок.
Однако, коренное отличие Java от других традиционных языков программирования заключается в том, что одни и те же функции доступа к базам данных, с помощью универсальности и кроссплатформенности Java, можно организовать чрезвычайно гибко, используя все преимущества современных объектно-ориентированных технологий, WWW и Intranet/Internet. Рассмотрим по порядку все варианты использования Java-программ при взаимодействии с базами данных.

и полностью или частично внедрил

Со времени опубликования в 1982 г., стандарт RFC 822 определил и полностью или частично внедрил формат текстовых писем в почтовой системе Internet. Но с расширением его использования, обнаружился ряд ограничений, заметно ограничивающих удовлетворение пользовательских потребностей. В частности, возможность пересылки нетекстовых данных, например, аудио и графики, посто не была упомянута в RFC822, описывавшем лишь формат текстовых сообщеий. И даже в случае текста, RFC 822 обошел вниманием нужды пользователей, использующих расширенный набор символов, что характерно для азиатских и большинства европейских языков. Итак, требовалась дополнительная спецификация. Основное ограничение RFC822 - относительно короткие строки и 7-битная символьная таблица. Пользователям дляотправки нетекстовых данных приходилось конвертировать тело своего письма в 7-битную форму с помощью UUENCODE, BINHEX и др.
Более очевидными стали ограничения RFC 822 при разработке почтовых шлюзов между хостами, использующими стандарт RFC822 и хостами, использующими стандарт X.400. X.400 имеет механизмы для включения нетекстовых данных в тело письма. В настоящее время стандарты для перевода почтовых сообщений из X.400 в RFC822 предполагают, что нетекстовые части тела письма должны быть сконвертированы (но не закодированы) в ASCII формат, либо должны быть "выброшены" из письма с уведомлением об этом получателя. А потеря информации крайне не желательна для пользователя.
MIME разработан как расширяемый механизм с расчетом на то, что набор пар content-type/subtype будет расти со временем. Некоторые другие поля заголовка MIMЕ, включая имена наборов символов, также , вероятно, получат большее число возможных значений. С этой целью MIME определяет процесс регистрации через Internet Assigned Numbers Authority (IANA), как центр регистрации этих значений. Описание процесса регистрации можно найти в приложении E RFC 1521.

В недавнем прошлом главной задачей

В недавнем прошлом главной задачей информационных технологий (ИТ) являлась облегчение бизнес-процессов внутри компании. В настоящее время, благодаря появлению Интернет, ИТ становятся все более ориентированными на клиента компании. Хорошее обслуживание клиента означает не только предоставление действительно нужных ему продуктов, но также его поддержку в процедурах покупки, платежей и других существенных для него услугах. Такие виды деятельности все больше основываются на применении электронной обработки данных с помощью Интернет, играющего роль основной коммуникационной сети. Информация, описывающая клиентов, их требования, образцы товаров и способы выполнения заказов клиента, более не хранится в одном централизованном месте. Она сосредоточена в разных источниках, находящихся как внутри, так и вне компании, и должна быть доступна для своевременного выполнения заказа.
Представленная новая модель вычислительного процесса требует новый тип программного обеспечения: информационные серверы, ориентированные на Web, которые могут эффективно обрабатывать сложные информационные объекты, построенные из существующих источников, обеспечивая при этом высокую безотказность и масштабируемость. Software AG выпускает два ключевых продукта, реализующих стратегию компании в области электронного бизнеса: это информационный сервер Tamino и Bolero - "фабрика" приложений для электронного бизнеса.
Кстати, Tamino означает не только Архитектуру транзакций для диспетчирования объектов Интернет, но и одноименное действующее лицо оперы Моцарта "Волшебная флейта".

Введение в EDI

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

Американской фирмой IMC (International Marketing Company) были проведены исследования по изучению бумажных потоков подготовки и оформления документов участников международной торговли. В результате исследования оказалось, что в общей сложности все участники внешнеэкономической деятельности в рамках одной поставки (партии товаров) оформляют 40 документов-оригиналов и 360 копий.

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

Произвольное взаимодействие между двумя отдельными компьютерами, например по модему. Обязательное участие оператора на принимающей и передающей стороне. Возможен обмен в произвольном, но заранее оговоренном формате; Интерактивное удаленное взаимодействие компьютера с информационной системой, например по протоколу http. Оператор на передающей стороне. Как правило используется определенная форма HTML документа. Принимаемые документы обрабатываются автоматически; Контролируемая потоковая обработка, например прием по e-mail, файл содержащий HTML форму, запуск которой инициирует процесс обработки документа или прием оператором по e-mail электронных документов в оговоренном формате и далее запуск запуск программы обработки. Требует обязательный контроль оператора на принимаемой стороне; Полностью автоматизированный процесс приема и обработки электронных документов в оговоренном формате. Участие операторов не требуется.

В статье подробее будет сакцентированно внимание на создание и основные принцыпы организации последнего типа взаимодействия, называемого Электронным обменом данными (Electronic Data Interchange или EDI).

В чем же состоит преимущество систем EDI? Сегодня, большая часть данных, содержащихся в коммерческих документах, генерируется их существующих компьютерных прикладных программ. Типовая схема оформления торговых сделок предполагает следующие действия:
для осуществления торговых операций сформируется бумажный документ; данный документ передается по каналам факсимильной связи или дригим каналам передачи данных адресату; деловой партнер, получивший электронный документ электронным способом воспроизводит его на бумаге и использует в дальнейшем для отчета; с принятого бумажного носителя вручную осуществляет ввод необходимых данных в информационную систему своего ведомства; На основе принятой информации генерируются новые бумажные документы и передаются в иные ведомства.
По данным исследования IMC внедрение EDI-систем позволяет снизить расходы, связанные с составлением документов до 7-10% от общей стоимости сделки. Мировая практика электронной коммерции, основанной на системах-EDI осуществляется уже более 30 лет и представляет собой определенный стандарт выполнения торговых операций и представление структурированных деловых документов.
Коренное отличие систем EDI от систем электронного документооборота состоит в том, что EDI системы - это межведомственные системы обмена электронныими документами, использующие строго стандартизированные правила составления электронных документов. А система электронного документооборота - это системы, как правило, разрабатываемые в рамках одной кропорации или предприятия, обмен в которых осуществляется по средствам распределенных СУБД типа ORACLE или INFORMIX.
Существует много разных определений EDI, но мы привидем наиболее подходящее для наших целей: "передача между информационными системами электронным способом структурированных сообщений в согласованном стандарте".
При помощи технологии EDI данные из корпоративных компьютерных систем переводятся на понятный всем стандарт и передаются по надежным телекоммуникационным каналам, как правило, по корпаротивной сети передачи данных.

В настоящее время в системах EDI широко используются около двенадцати стандартов, но наибольшую популярность прибрели два стандарта: UN/EDIFACT и ANSI X-12. Так например, в США оклоло 500 тыс. пользователей EDI обмена в формате UN/EDIFACT, и такое же количество пользователей формата ANSI X-12.
Для упорядочивания разностандартных EDI систем, в 1996 году Экономическим и Социальным советом ООН была выпущена Рекомендация №25 по использованию стандарта EDIFACT, в которой рекомендовано модернизировать существующие EDI-системы в системы, ориентированные на использование UN/EDIFACT, а вновь создоваемые системы изначально строить на основе использования UN/EDIFACT.
Акроним UN/EDIFACT расшифровывается как "Правила ООН эелектронного обмена документами для гос. управления торговли и транспорта" (United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport).
В настоящее время из-за отсутствия законодательного регулирования процессов электронного обмена документами полномасштабное развитие систем EDI в нашей стране затруднено. Но лавинообразное развитие в мире систем электронной коммерции раскачивает официальные органы и жизнь заставлляет использовать параллельно с бумажными документами и их электронный образ.
В качестве примера можно привести использование стандарта UN/EDIFACT в международных банковских системах обмена информацией SWIFT. Следующие примеры использования электронных документов в стандарте UN/EDIFACT: EDI-система контроля сопровождения груза из стран ЕС до терминала назначения в таможенных органах Российской Федерации.
Государственный таможенный комитет (ГТК РФ) реализует проект взаимодействия с информационной системой МПС (Министерства путей сообщения), где для обмена электронными документами используется стандарт UN/EDIFACT. В ГТК разрабатывается проект обмена электронными документами с информационными системами крупных портов мира стран Балтийского моря с таможней в морском порту Санкт Петербург и портов Тихого океана США (Сиетл и Сан-Франциско) с таможней в морском порта Находка и Владивосток.
В МПС реализован проект взаимодействие EDI-систем Октябрьской железной дороги и Финляндских государственных железных дорог (VR cargo).

Введение в XML/EDI

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

Сегодня, в сфере бизнеса создается и обрабатывается внушительный объем разнообразной бумажной документации. Она включает в себя заказы на приобретение, счета, каталоги, отчеты, платежные поручения и т.д. Бурное развитие телекоммуникаций в конце 80-х годов XX века открыло ворота для электронной торговли и Электронного обмена данными (Electronic Data Interchange или EDI)

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

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

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

Современные приложения требуют более гибкий протокол представления данных и механизмы, позволяющие определять структуру документа и описывать содержащие в нем элементы. Данным требованием удовлетворяет язык расширенной разметки - XML ("Extensible Markup Language"), спецификация которого была утверждена международной организацией я W3C в начале февраля 1998 г.

Сегодня создаются новые языки, в том числе и для ведения электронной коммерции, созданные на основе XML. В настоящее время разработана спецификация OTP - Открытого торгового протокола (Online Trading Protocol), являющейся спецификацией деловых транзакций на основе XML. Компаниями CheckFree, Intuil и Microsoft разработан язык OFX, позволяющий на основе XML безопасно проводить в WEB финансовые транзакции - Open Financial eXchange.

Основная идея создания XML/EDI систем заключается в дополнительном привлечение в электронную торговлю мелких и средних клиентов. Существующие сегодня EDI системы довольно дороги (от 10 до 100 тыс. дол. США) и многим мелким конечным пользователем, в связи с этим, недоступны.

Более подробную информацию о структуре систем XML/EDI и стандарте UN/EDIFACT можно найти в статье "Понятие XML/EDI" ()

Введение - зачем нужен домашний виртуальный сервер?

"Ну к чему все это, лучше бы водки выпили"
Из писем Белинского Гоголю

Если Вы читаете этот документ, а также если у Вас установлен Windows 95/98 (а наше личное мнение такое, что эта операционная система наиболее сбалансирована с точки зрения интерфейса и удобства работы), значит, Вы уже столкнулись с проблемой виртуального домашнего сервера, а точнее, с проблемой его отсутствия! Эта небольшая статья поможет Вам скачать и установить один из лучших серверов - Apache, а также те приложения, из-за отсутствия которых народ в бешенстве сметает все остальные сервера (например, Sambar Server) со своего многострадального жесткого диска и устанавливает Apache для Windows 95/98. Имеются в виду, конечно, Perl, PHP3 и MySQL, также работающие под Windows. Прочитав эту статью и скачав дистрибутивы, Вы будете вооружены всеми инструментами, которые так необходимы для профессиональной работы в Web!

Обращаем Ваше внимание: бытует мнение, что MySQL (а тем более для Windows 95/98) нельзя получить бесплатно, а можно только купить. Так вот, можете вздохнуть с облегчением: MySQL для Windows 95/98 существует, и ее установка не будет стоить Вам и копейки!

Если Вы - профессиональный Web-программист, то после внимательного ознакомления с этой (увы, ставшей некоторое время назад довольно объемистой) статьей Вы сможете на порядок упростить себе жизнь - точнее, ее часть, касающуюся написания и отладки скриптов. И это благодаря тому, что все описанное здесь почти на 100% совместимо с тем ПО, которое скорее всего установлено у Вашего хостера (а больше половины современных хостеров работают с Unix). Именно для этих, и никаких других, целей и была написана эта статья - помочь разработчику скриптов. Однако, если Вы собераетесь всерьез заняться хостингом на платформе Win32, то лучше будет использовать на Apache и PHP, а Microsoft IIS и ASP, и про это, я уверен, написано множество других статей.

Поговорим теперь с теми пользователями Windows 95/98, которые заглянули сюда из простого любопытства. Часто возникает ситуация, когда необходимо проверить полный вид html-страницы. Однако чаще всего это невозможно при работе дома - технологии SSI, CGI и, конечно, PHP, например, точно требуют сервера. Как же быть? Не стоит впадать в апатию - нужно просто установить на Ваш домашний компьютер (пусть даже и не подключенный к Интернет) специальную программу - Web-сервер. Вообще-то серверов существует множество - плохие и хорошие, медленные и быстрые... Мы же выбрали сервер, подходящий под последние две категории, - Apache. Самое главное то, что это чуть ли не единственный сервер, который позволяет работать в Windows 95/98 с технологиями PHP, CGI и Perl-скриптами одновременно так же просто и непринужденно, как будто у Вас стоит Unix.

Ввод пользователя

input select option optgroup fieldset

Анкоры, Картинки и Таймеры

a anchor img timer

Выражения

Теперь опишем выражения XQuery.

Основы. Подобно XML и XPath, в XQuery различаются прописные и строчные буквы, а все ключевые слова состоят из строчных букв. Подробные лексические и грамматические правила XQuery описаны в [7]. Символы, заключенные между и считаются комментариями и при обработке запроса игнорируются (конечно, кроме тех случаев, когда они входят в строку, заключенную в кавычки, и считаются частью этой строки).

Простейший вид выражения XQuery - литерал (literal), который представляет атомарное значение. 47 литерал типа integer

4.7 литерал типа decimal, поскольку он содержит десятичную точку 4.7E3 литерал типа double, поскольку он содержит экспоненту "47" литерал типа string (внутри строки, заключенной в двойные кавычки, разрешается помещать одинарные кавычки)

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

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

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

Переменная (variable) в XQuery - имя, начинающееся со знака доллара. Переменная может быть связана со значением и использоваться в выражении для представления этого значения. Один из способов связывания переменной состоит в использовании выражения LET, которое связывает одну или несколько переменных, а затем вычисляет внутреннее выражение. Значение выражения LET - результат вычисления внутреннего выражения со связанными переменными. Следующий пример иллюстрирует выражение LET, которое возвращает последовательность 1, 2, 3. let $start := 1, $stop := 3 return $start to $stop

Выражение LET - частный случай выражения FLWR (for, let, where, return), которое обеспечивает дополнительные способы связывания переменных.

Еще одна простая форма выражений XQuery - вызов функции (function call). XQuery предусматривает наличие базовой библиотеки функций, описанной в [11], и описываемый в следующем разделе механизм, позволяющий пользователям определять дополнительные функции. Вызовы функций в XQuery основаны на обычной нотации с заключением в скобки аргументов функции. В следующем примере вызывается функция базовой библиотеки substring, извлекающая из строки первые шесть символов. substring(, 1, 6)

Выражения пути. Выражения пути в XQuery базируются на синтаксисе XPath [4]. Выражение пути состоит из серии шагов, разделенных символом слэша (). Результат каждого шага - последовательность узлов. Значение выражения пути - последовательность узлов, которая формируется на последнем шаге.

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

В XPath определяются 13 осей, и часть из них или все будут поддерживаться и в XQuery. Пока планируется реализовать в XQuery поддержку шести осей: child, descendant, parent, attribute, self и descendant-or-self.

Выражения пути могут быть записаны в полном или в сокращенном синтаксисе. Полный синтаксис для осевого шага предусматривает указание оси и критерия выбора, разделенных парой двоеточий. Q1 иллюстрирует четырехшаговое выражение пути, оформленное в полном синтаксисе. На первом шаге вызывается встроенная функция document, которая возвращает узел-документ документа items.xml. Второй шаг - осевой шаг, который находит всех потомков узла-документа ( выбирает все узлы на данной оси; в данном случае будет выбран единственный узел-элемент с именем items). Третий шаг снова выполняет поиск вдоль оси child, чтобы найти на следующем уровне все элементы-потомки с именем item, которые, в свою очередь, имеют потомков с именем seller и значением . Результатом третьего шага является последовательность узлов-элементов item. Каждый из этих узлов item служит контекстным узлом для четвертого шага, который опять предусматривает поиск по оси child элементов description, являющихся потомками данного item. Окончательный результат выражения пути - результат четвертого шага: последовательность узлов-элементов description, перечисленных в порядке документа.

(Q1) Перечислить описания всех товаров, предлагаемых к продаже Смитом.

document("items.xml")/child::* /child::item [child::seller = "Smith"] /child::description

На практике, выражения пути часто записываются с помощью сокращенного синтаксиса. Пожалуй, наиболее важным является то, что спецификатор оси может быть пропущен в том случае, когда используется ось child. Поскольку child является наиболее часто используемой осью, такое сокращение помогает сократить длину многих выражений пути. К примеру, Q1 можно сократить следующим образом: document("items.xml") /*/item[seller = "Smith"]/description

Разделение двух шагов двойным, а не одинарным слэшем означает, что второй шаг может выполнять поиск в нескольких уровнях иерархии, используя для этого ось descendants, а не одноуровневую ось child. Так, Q2 выполняет поиск элементов description, которые являются потомками (необязательно прямыми) корневого узла данного документа. Результат Q2 - это последовательность узлов-элементов, которые могут, в принципе, быть найдены на различных уровнях иерархии узлов (хотя в нашем примере все узлы description находятся на одном и том же уровне).

(Q2) Перечислить все элементы описания товаров, имеющиеся в документе items.xml.

document()//description

В выражении пути одинарная точка () указывает на контекстный узел, а две последовательные точки () - на предка контекстного узла. Эти нотации представляют собой сокращенное указание осей self и axes соответственно. Имена, присутствующие в выражениях пути, как правило, интерпретируются как имена узлов-элементов, однако если имя имеет префикс , оно интерпретируется как имя узла-атрибута. Это сокращение для шага, который выполняет поиск вдоль оси attribute. Эти аббревиатуры иллюстрируются в Q3, где поиск начинается с узла, связанного с переменной $description, вдоль оси parent к родительскому узлу item, а затем - вдоль оси attribute в поисках атрибута с именем status. Результатом Q3 является единственный узел-атрибут.

(Q3) Найти атрибут статуса для товара, который является предком данного описания товара.

$description/../@status

Предикаты. В XQuery предикат (predicate) - это заключенное в квадратные скобки выражение, которое используется для фильтрации последовательности значений. Предикаты часто применяются в шагах выражения пути. Например, в шаге item[seller = ] фраза seller = - это предикат, который применяется для выбора определенных узлов item и отбрасывания остальных. Будем называть объекты последовательности, фильтруемые с помощью предиката, объектами-кандидатами. Предикат вычисляется для каждого объекта-кандидата с использованием этого объекта-кандидата в качестве контекстного объекта для вычисления выражения предиката.

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

Если в результате вычисления предикатного выражения получается булевское значение, то объект-кандидат выбирается в том случае, если значение предикатного выражение равно true. Этот тип предиката иллюстрируется в примере, где выбираются узлы item, имеющие узел-потомок reserve-price, чье значение больше 1000: item [reserve-price > 1000]

Если результатом вычисления предикатного выражения является число, то объект-кандидат выбирается в том случае, если его порядковый номер в списке объектов-кандидатов равен этому числу. Такой тип предиката представлен в примере, где выбирается пятый узел item по оси child: item [5]

Если в результате вычисления предикатного выражения получается пустая последовательность, объект-кандидат отвергается. Однако если результат вычисления предикатного выражения представляет собой последовательность, содержащую хотя бы один узел, объект-кандидат выбирается. Такая форма предиката может применяться для проверки существования узла-потомка, удовлетворяющего некоторому условию. Это иллюстрирует пример, где выбираются узлы item, у которых имеется узел-потомок reserve-price, вне зависимости от его значения: item [reserve-price]

Внутри предикатов часто используется несколько видов операций и функций.

Операции сравнения значений (value comparison operator): eq, ne, lt, le, gt, ge. Эти операции могут сравнивать два скалярных значения, но порождают ошибку, если любой из операндов является последовательностью с длиной, большей единицы. Если один из операндов - узел, то прежде, чем выполнить сравнение, операция сравнения значений извлекает его значение. Например, item[reserve-price gt 1000] выбирает узел item только в том случае, если он имеет в точности один узел-потомок reserve-price со значением, большим 1000.

Общие операции сравнения (general comparison operator): =, !=, >, >=, <, <=. Эти операции могут работать с операндами, которые представляются собой последовательности, при условии неявного наличия семантики для обоих операндов. Как и операции сравнения значений, общие операции сравнения автоматически извлекают значения узлов. Например, item[reserve-price = 1000] выбирает узел item, если у него имеется хотя бы один узел-потомок со значением, большим 1000.

Операции сравнения узлов (node comparison operator): is и isnot. Эти операторы определяют идентичность двух узлов. Например, $node1 is $node2 принимает значение , если переменные $node1 и $node2 связаны с одним и тем же узлом (т. е. для обеих переменных узел один и тот же).

Операции сравнения порядка (order comparison operator). Эти операции сравнивают позиции двух узлов. Например, $node1 << $node2 принимает значенией true, если узел, связанный с $node1, в порядке документа встречается раньше, чем узел, связанный с $node2.

Логические операции (logical operator): and и or. Эти операции могут использоваться для объединения логических условий в предикате. Например, следующий предикат выбирает узлы item, имеющие ровно один элемент-потомок seller со значением , а также, по крайней мере, один элемент-потомок reserve-price с любым значением. item [seller eq and reserve-price].

Отрицание (negation): not. Это скорее функция, а не операция. Она служит для инвертирования булевых величин.

Во всех приведенных примерах имена элементов и атрибутов были простыми идентификаторами. Однако в соответствии с рекомендацией XML Namespace [19], элементами и атрибутам позволяется иметь имена, состоящие из двух частей, где первая часть - префикс пространства имен, за которым следует двоеточие. Имя, имеющее префикс пространства имен, называется QName. Каждый префикс пространства имен должен быть связан с URI (универсальный идентификатор ресурсов), который уникальным образом определяет пространство имен. Это соглашение позволяет каждому приложению определять имена в своем собственном пространстве, не опасаясь коллизий с именами, определенными другими приложениями, что дает возможность однозначно ссылаться на имена, указываемые в различных приложениях.

Если бы префикс auction был связан с URI пространства имен нашего приложения для проведения интерактивного аукциона, то шаг item [reserve-price > 1000] мог бы быть записан с помощью QName следующим образом: auction:item [auction:reserve-price > 1000]

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

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

Простейший конструктор элементов создает элемент в полном соответствии с синтаксисом XML. Например, следующее выражение конструирует элемент с именем highbid, имеющий атрибут status и два элемента-потомка с именами itemno и bid-amount.

<highbid status = "pending"> <itemno>4871</itemno> <bid-amount>250.00</bid-amount> </highbid>

В этом примере значения элементов и атрибутов - константы. Однако во многих случаях необходимо создавать элемент или атрибут, значением которых является вычисляемое выражение. Выражение, заключенное в фигурные скобки, необходимо вычислить, а не трактовать как символьный текст. В конструкторе элемента это выражение вычисляется и заменяется своим значением. В следующем примере значения элементов и атрибутов вычисляются. Переменные $s, $i и $bids, используемые в этих выражениях, должны быть связаны с некоторыми выражениями. <highbid status = "{$s}"> <itemno> {$i} </itemno> <bid-amount> {max($bids[itemno = $i]/bid-amount)} </bid-amount> </highbid>

В следующем примере конструктор элементов содержит выражение, заключенное в фигурные скобки, которое генерирует один атрибут и два подэлемента. Переменная $b должна быть связана с некоторым выражением. <highbid> { $b/@status $b/itemno $b/bid-amount } </highbid>

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

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

Чтобы привести пример использования вычисляемого конструктора, предположим, что переменная $e связана с элементом, имеющим числовое значение. Нам нужно сконструировать новый элемент, имеющий то же имя, что и $e, и те же атрибуты, что у $e, но его значение должно быть вдвое больше значения $e. Этого можно добиться с помощью выражения, в котором функция data используется для получения числового значения исходного узла. element {name($e)} {$e/@*, data($e)*2}

Подобно вычисляемому конструктору элемента, в XQuery обеспечивается вычисляемый конструктор атрибута (computed attribute constructor), состоит из ключевого слова attribute, за которым следуют два выражения в фигурных скобках - первое вычисляет имя атрибута, а второе - значение. Конструктор атрибута может использоваться везде, где допустим атрибут. Следующий конструктор атрибута на основе связанной переменной $p мог бы сгенерировать атрибут, который выглядит как father = или mother = .

attribute {if $p/sex = "M" then "father" else "mother"} {$p/name}

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

В наиболее простой форме итерация в XQuery задается оператором for, в котором указывается имя переменной и предоставляется последовательность значений, над которой переменная итерируется. Далее указывается оператор return, который содержит выражение, вычисляемое для каждого связывания переменной; см. ниже. for $n in (2, 3) return $n + 1

Результатом этого итеративного выражения будет последовательность (3, 4).

В операторе for можно указывать более одной переменной с последовательностью итерации для каждой из них. Такой оператор порождает кортежи связываний переменных, которые образуют декартово произведение итерационных последовательностей. Если не указано иное, кортежи связываний генерируются в порядке, сохраняющем порядок итерационных последовательностей, с использованием самой левой переменной как , а самую правую - как . В примере оператор for содержит две переменные и две итерационные последовательности. for $m in (2, 3), $n in (5, 10) return <fact>{$m} times {$n} is {$m * $n} </fact>

В результате получается следующая последовательность из четырех элементов. <fact>2 times 5 is 10 </fact> <fact>2 times 10 is 20 </fact> <fact>3 times 5 is 15 </fact> <fact>3 times 10 is 30 </fact>

Операторы for и let - частные случаи более общего выражения, называемого FLWR. В наболее общем виде выражение FLWR может иметь несколько операторов for, несколько операторов let, необязательный оператор where, а также оператор return. Функция операторов for и let - связывание переменных. Каждый из них содержит одну или несколько переменных и выражение, присваиваемое каждой переменной. Результатом вычисления выражений являются последовательности, и выражения могут содержать ссылки на переменные, для которых связывание было выполнено в предыдущих операторах.

Оператор for итерирует каждую переменную над ассоциированной с ней последовательностью, связывая переменную по очереди с каждым объектом последовательности, а как оператор let связывает каждую переменную сразу со всей ассоциированной последовательностью. Это различие иллюстрируется следующей парой операторов. for $i in (1 to 3) let $j := (1 to $i)

Эта пара операторов не является полным выражением FLWR, поскольку в нем отсутствует условие return. Операторы for и let просто порождают последовательность кортежей связываний. Приведенный выше пример порождает следующую последовательность из трех пар связываний. $i = 1, $j = 1 $i = 2, $j = (1,2) $i = 3, $j = (1,2,3)

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

Кортежи связывания, порожденные операторами for и let в FLWR-выражении, фильтруются в соответствии с необязательным условием where. Оператор where содержит выражение, которое вычисляется для каждого кортежа связывания. Если значением выражения where являются булевское значение true или непустая последовательность (), то кортеж связываний принимается; в противном случае он отвергается.

Затем в выражении FLWR вычисляется оператор return по очереди и по одному разу для каждого оставшегося после проверки условия where кортежа связывания. Результаты вычислений объединяется в последовательность, которая и является результатом выражения FLWR.

Возможности FLWR иллюстрируются в запросе к базе данных аукциона Q4.

(Q4) Для каждого товара, который имеет более десяти ставок, создать элемент popular-item, содержащий номер товара, описание и число ставок. for $i in document("items.xml")/*/item let $b := document("bids.xml") /*/ bid[itemno = $i/itemno] where count ($b) > 10 return <popular-item> { $i/itemno, $i/description, <bid-count> {count ($b)}</bid-count> } </popular-item>

Операторы for и let порождают пару связывания для каждого item в items.xml. В каждой паре связывания $i связан с товаром, а $b - с последовательностью, содержащей все ставки для этого товара. Оператор where оставляет только те связанные кортежи, в которых $b содержит более десяти ставок. Затем оператор return для каждого из этих связываний генерирует выходной элемент, содержащий номер товара, описание и число ставок.

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

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

Условие sortby часто полезно для переупорядочивания результатов выражения FLWR. Если необходимо отсортировать по убыванию bid-count элементы popular-item, сгенерированные в запросе Q4, то в конец Q4 можно добавить следующий оператор. sortby bid-count descending

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

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

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

Арифметика. В XQuery обеспечиваются обычные арифметические операции: +, - , *, div и mod, а также агрегатные функции sum, avg, count, max и min, которые применяются к последовательности чисел и возвращают числовой результат. Оператор деления в XQuery называется div, чтобы его можно было отличить от слэша. Если после оператора вычитания следует имя, перед ним должен стоять пробел, который позволяет отличить его от дефиса, поскольку в XML дефис - корректный символ для имени.

Арифметические операции определяются для числовых значений. К числовым значениям относятся значения типов integer, decimal, float, double или типов, производных от них. Если типы операндов арифметической операции различны, операнды приводятся к ближайшему общему типу в соответствии с иерархией приведения integer -> decimal -> float -> double. Если операнд арифметического оператора является узлом, то автоматически извлекается его типизированное значение.

Важный частный случай - применение арифметических операций к пустым последовательностям. В XQuery пустая последовательность иногда используется для представления отсутствующей или неизвестной информации, во многом подобно тому, как неопределенное значение используется в реляционных системах. По этой причине операции +, -, *, div и mod определяются таким образом, что они возвращают пустую последовательность, если любой из операндов - пустая последовательность. Для иллюстрации этого правила предположим, что переменная $emps связана с последовательностью элементов emp, каждый из которых представляет сотрудника и содержит элементы name и salary, а также дополнительные элементы comission и bonus. Выражение в Q5 преобразует эту последовательность в последовательность элементов emp, каждый из которых содержит элементы name и pay, причем значение pay равно полной заработной плате сотрудника. Для тех сотрудников, комисионные (commission) или премия (bonus) которых не заданы ($e/commission или $e/bonus - пустая последовательность), генерируемый элемент pay будет пустым.

(Q5) Задана последовательность элементов emp. Заменить их подэлементы salary, commission и bonus на новый элемент pay, содержащий сумму значений исходных элементов, а результирующую последовательность отсортировать по убыванию значений элемента pay.

for $e in $emps return <emp> { $e/name, <pay> {$e/salary + $e/commission + $e/bonus} </pay> } </emp> sortby (pay)

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

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

Операторы union, intersect и except возвращают последовательность узлов в порядке документа и удаляют дубликаты из получившихся последовательностей с учетом индивидуальности узлов. Запрос Q6 является примером использования оператора intersect.

(Q6) Создать новый элемент с именем recent-large-bids, содержащий копии всех элементов bid документа bids.xml, которые имеют bid-amount со значением больше 1000 и bid-date со значением позже 1 января 2002 года.

<recent-large-bids> document("bids.xml") /*/ bid [bid-amount > 1000.00] intersect document("bids.xml") /*/ bid [bid-date > date("2002-01-01")] </recent-large-bids>

Выражения, в которых используются операции union, intersect и except, часто можно представить в другом виде. Так, запросу Q6 эквивалентен следующий запрос. <recent-large-bids> document("bids.xml")/*/bid [bid-amount > 1000.00 and bid-date > date("2002-01-01")] </recent-large-bids>

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

Рассмотрим следующий запрос. document("items.xml")//itemno except document("bids.xml")//itemno

В этом запросе операция except применяется к двум последовательностям узлов itemno. Поскольку последовательности узлов выбираются из различных документов, ни один узел во второй последовательности не может быть идентичен узлу из первой последовательности. Результатом запроса будет последовательность всех узлов itemno документа items.xml. Если предполагалось с помощью этого запроса получить список элементов itemno для товаров, которые не имеют ставок, то можно добиться этого воспользовавшись библиотечной функцией empty, которая возвращает true, если ее операнд - пустая последовательность. for $i in document("items.xml")//item where empty(document("bids.xml") //bid [itemno eq $i/itemno]) return $i/itemno

В этом примере предикат itemno eq $i/itemno сравнивает два узла itemno, извлекая и сравнивая их содержимое, а не проверяя их идентичность.

Операция |, оставленная для совместимости с XPath 1.0, эквивалентна операции union. Эти операции иногда применяются в шагах выражения пути. Например, следующее выражение пути находит объединение всех потомков b и потомков c узлов в последовательности, связанной с $a; узлы в этом объединении затем используются в качестве контекстных узлов для следующего шага в пути. $a/(b | c)/d

Условные выражения. Условные выражения обеспечивают возможность выполнения одного из двух выражений в зависимости от значения третьего выражения. Это записывается в знакомом формате if...then...else, поддерживаемом во многих языках. Требуется наличие всех трех условий (if, then и else), а выражение в условии if должно быть заключено в скобки. Результат всего условного выражения зависит от значения выражения в условии if, называемого выражением проверки (test expression). Правила таковы.

Если значением выражения проверки являются булевское значение true или непустая последовательность (используемая как ), то выполняется оператор then.

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

В противном случае условное выражение возвращает значение ошибки.

Следующее простое условное выражение может быть использовано для получения стоимости товара, в зависимости от существования атрибута с именем discounted. if ($part/@discounted) then $part/wholesale else $part/retail

Q7, представленный на Рис. 3, - пример более сложного запроса, содержащего условное выражение. Этот запрос также иллюстрирует несколько уровней вложенности выражений FLWR и конструкторов элементов.

Рис.3.

Q7) Создать отчет, описывающий состояние ставок для различных товаров. Пометить каждую ставку статусом <OK,> <too small> или <too late>. Поместить отчет в элемент с именем bid-status-report.

<bid-status-report> for $i in document (<items.xml>)/*/item return <item> { $i/itemno, for $b in document (<bids.xml>)/*/bid[itemno = $i/itemno] return <bid> { $b/bidder, $b/bid-amount, <status> { if ($b/bid-date > $i/end-date) then <too late> else if ($b/bid-amount < $i/reserve-price) then <too small> else <OK> } </status> } </bid> } </item> </bid-status-report>

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

Как и FLWR-выражение, кванторное выражение позволяет переменной выполнять итерацию над объектами в последовательности; выполняется поочередное связывание этой переменной с каждым элементом последовательности. Для каждого связывания переменной вычисляется проверочное выражение. Кванторное выражение, которое начинается с some, возвращает значение true, если выражение проверки истинно для некоторого связывания переменной.some $n in (5,7,9,11) satisfies $n > 10

Кванторное выражение, начинающееся с every, возвращает значение true, если выражение проверки истинно для всех связываний переменной. Например, следующее кванторное выражение возвращает значение false, поскольку выражение проверки истинно не для всех связываний. every $n in (5,7,9,11) satisfies $n > 10

Использование кванторных выражений иллюстрируется запросом Q8.

(Q8) Найти товары в items.xml, для которых все полученные ставки более чем вдвое превысили начальную цену. Получить копии всех таких элементов item, и поместить их в новый элемент с именем underpriced-items.

<underpriced items> for $i in document("items.xml") where every $b in document("bids.xml") /*/bid [itemno = $i/itemno] satisfies $b/bid-amount > 2 * $i/reserve-price return $i </underpriced-items>

Вырезка/вставка текста между сессиями

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

- Пометить текст в режиме Scrollback можно с помощью Space bar (пробела) или с помощью правой кнопки мыши.

- Alt+C скопирует отмеченный текст в буфер. (Левая, затем правая кнопка мыши и обе отпустить одновременно)

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

- Alt+V вставляет содержимое буфера в текст текущей сессии. (Правая, левая кнопки мыши и вместе отпустить)

(* При попытке копирования/вставки текста были замечены сбои памяти терминала)

Вывод списка статей

Теперь, когда у вас есть работающая база данных с пресс-релизами, можно без особых проблем подключить ее к Web-странице. Начнем с создания простейшей страницы, которая отображает список всех имеющихся пресс-релизов. Заметьте, что по умолчанию Web-сервер Apache «думаеть», что все ваши документы должны находится в его директории htdocs, а исполняемые файлы — в cgi-bin. Следовательно, необходимо поместить все файлы с расширением .pl в каталог cgi-bin. В свою очередь, создаваемые файлы HTML-шаблонов нужно разместить в каталоге tpl. Иерархия каталогов будет выглядеть следующим образом: / (корень любого диска) /local /local/usr /local/usr/bin /local/usr/cgi-bin /local/usr/htdocs /local/usr/tpl

Для систем DOS/Windows путь к cgi-bin может выглядеть так:

c:\local\usr\cgi-bin

Шаг 1

Используя свой любимый текстовый редактор, создайте файл pr-list-tpl.htm:

15. <html> 16. <head> 17. <title>Пресс-релизы 2001</title> 18. </head> 19. <body> 20. @BLOCK@ 21. </body> 22. </html>

Этот файл предназначен для отображения списка всех доступных пресс-релизов.

Шаг 2

Создайте файл pr-list-block-tpl.htm, который будет отображать каждый блок с найденным пресс-релизом в виде таблицы:

23. <table border="1" width="400" cellpadding= _ "2" cellspacing="1"> 24. <tr><td width="400"><a href= _ "/cgi-bin/@READ@?id=@NUMBER@">@TITLE@</a></td></tr> 25. <tr><td width="400"><i><b>@AUTHOR@</b>, _ @DATE@</i></td></tr> 26. </table>

Шаг 3

Создайте файл pr-content-tpl.htm, который будет отображать содержание пресс-релиза:

27. <html> 28. <head> 29. <title>Press-releases 2001: @TITLE@</title> 30. </head> 31. <body> 32. <h2>@TITLE@</h2> 33. <table> 34. <tr><th align="left">@TITLE@</th></tr> 35. <tr><td><i>Author: <b>@AUTHOR@</b> Date: @DATE@</i></td></tr> 36. <tr><td>@BODY@</td></tr> 37. </table> 38. <a href="/cgi-bin/@LIST@">Show the list of press-releases..</a> 39. </body> 40. </html>

Шаг 4
Создайте Perl-скрипт pr-list-dbi.pl, который будет читать данные из базы данных db_website и, используя шаблонные HTML-файлы, отображать список пресс-релизов (текст этого скрипта вы сможете найти на нашем компакт-диске).
А теперь пройдемся по листингу кода и рассмотрим, как работает программа вывода списка пресс-релизов.
Строки 1-9 представляют собой как бы инициализирующий блок, в котором объявляются все глобальные переменные и константы:
41. #!/local/usr/bin/perl 42. 43. use DBI; 44. $dbh = DBI->connect(‘dbi:mysql:db_website’,’root’,’’); 45. $path = "/local/usr/tpl"; 46. $TPL_LIST = "$path/pr-list-tpl.htm"; 47. $TPL_LIST_BLOCK = "$path/pr-list-block-tpl.htm"; 48. 49. print "Content-type:text/html\n\n";
Сперва мы сообщаем Web-серверу Apache путь, указывающий, где находится интерпретатор Perl, который запускается при запросе скрипта, проверяет его на ошибки и затем выполняет его. Далее мы объявляем модуль DBI (DataBase Interface), методы которого будут использоваться в программе для взаимодействия с базой данных (строка 3). Затем мы устанавливаем соединение с нашей базой данных db_website (4), указывая в качестве входного имени пользователя root (администратор), а в качестве пароля пустую строку (значение, принятое по умолчанию). В переменной $path указываем путь, по которому находятся файлы HTML-шаблонов (5). В переменных $TPL_LIST и $TPL_LIST_BLOCK соответственно указываем их имена (6, 7). Потом, сообщаем Web-серверу, что все исходящие данные должны представляться в MIME-формате text/html для вывода HTML-потока в пользовательский браузер (9).
Строки 11-22 представляют собой тело программы:
50. 51. open (L, "$TPL_LIST"); 52. while ($line1=<L>) { 53. chomp($line1); 54. if ($line1=~/\@BLOCK\@/) { 55. read_db(); 56. ins_data(); 57. } else { 58. print "$line1\n"; 59. } 60. } 61. close(L); 62. 63. $dbh->disconnect;
Открываем файл-шаблон pr-list-tpl.htm (11) и в цикле (12-20) просматриваем его, записывая каждую считанную строку в переменную $line.

Во время каждой итерации производим проверку на наличие в этой строке ключевого слова @BLOCK@ (14-19), означающего, что в данном месте надо вставить блок с пресс-релизом. Как только оно найдено, вызываем процедуры read_db() и ins_data().
Строки 26-39 — тело процедуры read_db(), предназначенной для считывания содержимого таблицы tbl_news_items, в которой хранятся наши пресс-релизы:
64. 65. 66. sub read_db { 67. $c=0; 68. my($sql) = "SELECT * FROM tbl_news_items"; 69. $rs = $dbh->prepare($sql); 70. $rs->execute; 71. while (my $ref = $rs->fetchrow_hashref()) { 72. $id[$c] = "$ref->{‘col_id’}"; 73. $title[$c] = "$ref->{‘col_title’}"; 74. $author[$c] = "$ref->{‘col_author’}"; 75. $date[$c] = "$ref->{‘col_date’}"; 76. $c++; 77. } 78. $rs->finish(); 79. }
Инициализируем счетчик $c=0, составляем запрос выборки всех данных из таблицы (28), выполняем запрос (29, 30) и получаем данные в рекордсет (recordset — набор записей) $rs. Затем в цикле (31-37) извлекаем данные из рекордсета, используя метод fetshrow_hashref и возвращая ссылку на ассоциативный массив %ref (31), содержащий имена и значения полей текущей записи. Записываем извлеченные данные (32-35) в соответствующие их типам обычные массивы @id, @title, @author и @date. Закрываем рекордсет (38).
Строки 41-53 — тело процедуры ins_data(), реализующей вставку извлеченных из БД данных в исходящий поток данных; строки 55-63 — тело процедуры pr_block(), вызываемой в цикле из процедуры ins_data():
80. 81. sub ins_data { 82. $toread = "pr-read-dbi.pl"; 83. for ($i=0; $i<$c; $i++) { 84. $line = &pr_block; 85. 86. $line =~ s/\@NUMBER\@/$id[$i]/; 87. $line =~ s/\@TITLE\@/$title[$i]/; 88. $line =~ s/\@AUTHOR\@/$author[$i]/; 89. $line =~ s/\@DATE\@/$date[$i]/; 90. $line =~ s/\@READ\@/$toread/; 91. print "$line"; 92. } 93. } 94. 95. sub pr_block { 96. my($block) = ‘’; 97. open (B, "$TPL_LIST_BLOCK"); 98. while ($line=<B>) { 99. $block = $block.$line; 100. } 101.close(B); 102. return ($block); 103. }
Итак, получив в результате выполнения процедуры read_db() максимальное значение счетчика $c, в цикле (43-52) мы запускаем процедуру pr_block(), которая читает содержимое HTML-шаблона pr-list-block-tpl.htm и записывает его в переменную $block (59), значение которой затем возвращается (62) в переменную $line (44) процедуры ins_data(). Далее в этом же цикле мы заменяем (46-50) найденные в исходящем потоке $line ключевые слова @NUMBER@, @TITLE@, @AUTHOR@, @DATE@, @READ@ на соответствующие данной итерации цикла ($i) значения массивов @id, @title, @author, @date и переменной $toread.

Вывод текста пресс-релиза

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

Рис. 4.

Новый скрипт pr-read-dbi.pl будет незначительно отличаться от уже созданного нами pr-list-dbi.pl.

Данный листинг на 98% походит на листинг 1, хотя, имеет некоторые незначительные отличия:

подключена библиотека CGI для считывания параметра id (9) из строки запроса (например, http://localhost/cgi-bin/pr-content-dbi.pl?id=1);

применяется всего один HTML-шаблон (pr-content-tpl.htm);

запрос к базе данных дополнен условным SQL-оператором WHERE для выборки всех данных, соответствующих определенному пресс-релизу по идентификатору col_id;

из БД также считывается поле col_body с текстом выбранного пресс-релиза.

в терминах модели данных, основанной

XQuery определяется в терминах модели данных, основанной на неоднородных последовательностях узлов и атомарных значениях. Экземпляр этой модели данных может содержать один или несколько документов или фрагментов документов XML. Запрос обеспечивает отображение одного экземпляра модели данных на другой экземпляр. Запрос состоит из пролога, который устанавливает среду обработки, и выражения, которое генерирует результат запроса.
В настоящее время XQuery определен на уровне предварительных рабочих документов; созданием языка продолжает заниматься W3C XML Query Working Group. Эта рабочая группа активно обсуждает систему типов XQuery и вопрос о взаимном отображении этой системы типов и системы типов XML Schema. Также обсуждаются функции полнотекстового поиска, сериализация результатов запроса, обработка ошибок и ряд других вопросов. Скорее всего, окончательная спецификация XQuery будет включать в себя несколько уровней соответствия; например, в ней может быть определено, как следует производить статическую проверку типов, но не будет требоваться, чтобы она выполнялась в каждой реализации, соответствующей спецификации. Также ожидается, что подмножество XQuery будет объявлено как XPath версии 2.0, и станет возможным встраивание этого подмножества в другие языки, такие как XSLT [5].
Более полное описание XQuery и его грамматику в форме Бекуса-Науэра можно найти в [7]. Язык продолжает развиваться, поэтому спецификация XQuery может измениться.
Подобно тому, как XML применяется в качестве универсального формата обмена информацией в Сети, XQuery призван служить в качестве универсального формата обмена запросами. Если XQuery получит признание в качестве стандартного средства извлечения информации из источников XML-данных, это поможет реализовать потенциал XML.

Выводы, перспективы и будущие разработки

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

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

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

Фактически, некоторые разработанные концепции такого рода уже адаптируются к контексту XML [DFF+98, GMW98]. Другие проекты, которые осуществляются в настоящее время в сообществе баз данных в области архитектур и языков метаданных (например, [MRT98, KMSS98]), также должны, вероятно, воспользоваться преимуществами XML и обеспечить интеграцию со средой XML.
Вторая тенденция, которая будет воздействовать на возможность применения технологий баз данных для запросов в Web - это рост так называемого скрытого Web. Скрытым Web называется совокупность страниц Web, которые генерируются программами, определяемыми введенными пользователем данными, и, следовательно, не доступны для индексирования поисковыми роботами Web. В недавней статье [LG98] утверждается, что скрытый Web уже содержит примерно 80% Web. Если наши инструментальные средства должны быть способными извлекать пользу из данных в скрытом Web, то мы должны разработать методы для идентификации сайтов, которые генерируют страницы Web, классифицировать их и автоматически создавать для них интерфейсы запросов.
В рассматриваемой области нет недостатка в возможных направлениях будущих исследований. В прошлом большая часть работ была сосредоточена на логическом уровне и была посвящена разработке соответствующих моделей данных, языков запросов и методов описания различных аспектов Web-источников. Напротив, проблемам оптимизации запросов и исполнения запросов уделялось относительно небольшое внимание в сообществе специалистов по базам данных, и их исследование становится одной из наиболее важных задач для дальнейшей работы. Некоторые из важных направлений предусматривают обогащение моделей данных и языков запросов благодаря использованию различных форм метаданных об источниках (например, вероятностной информации) и основанных на строгих принципах комбинаций возможностей для запросов структурированных и неструктурированных источников данных в WWW.
Мы попытались привести в этой статье представительный список публикаций по вопросу о Web и базах данных.Помимо включенных в него работ читатели могут обратиться к материалам недавно проведенных симпозиумов, связанных с темой данного обзора [SSD97, Web98, AII98].

Вызов скрипта.

Без возможности производить различные операции с информацией на сервере, WML остался бы просто средством форматированного вывода текста. Добавление такой возможности, напротив, открывает любому WAP-совместимому устройству пути передачи сообщений через Интернет, промышленному использованию на предприятии и электронной коммерции. WAP-совместимое устройство взаимодействуют с подобными источниками информации через WAP-шлюз. Этот шлюз должен уметь взаимодействовать с различными стандартами сотовой связи, такими как CDMA, GSM или GPRS. Однако, вполне возможно установить тестовый шлюз в сочетании с популярными веб-серверами (такими как MS IIS или Apache) прямо в вашей локальной сети. Мы не будем тут сильно вдаваться в детали процесса установки шлюза, однако нельзя не предостеречь вас от самой распространенной ошибки. Вам обязательно необходимо добавить определения следующих типов в конфигурацию веб-сервера.

WML text/vnd.wap.wml wml WMLScript text/vnd.wap.wmlscript wmls

Теперь мы рассмотрим небольшой примерчик в котором пользователю будет предложено сделать выбор какой-то одной опции а затем на основе этого выбора с сервера будет загружена определенная информация. Для этого примера мы используем ASP. С тем же успехом мы могли написать скрипт использую Javascript, Servlets, Perl или любой другой язык. В следующем листинге приведен исходный код для нашей новой деки. В ней содержится всего один элемент <select>, который предлагает пользователю выбор из нескольких опций. Элемент <go> вызывает серверный скрипт с определенными параметрами.

<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card id="Order" title="Query Inventory"> <p> <select name="Items" title="Items"> <option value="Books">Books</option> <option value="Music">Music</option> <option value="Video">Video</option> <option value="Software">Software</option> </select> </p> <do type="accept" label="Query"> <go href="http://127.0.0.1/WML/Inventory.asp" method="post"> <postfield name="Items" value="$(Items)"/> </go> </do> </card> </wml>

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

<% Dim Body If Request.Form("Items") = "Books" Then Body = "You selected Books!" ElseIf Request.Form("Items") = "Video" Then Body = "You selected Video!" ElseIf Request.Form("Items") = "Software" Then Body = "You selected Software!" ElseIf Request.Form("Items") = "Music" Then Body = "You selected Music!" End If Response.ContentType = "text/vnd.wap.wml"%> <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card> <p> <%Response.write(Body)%> </p> </card> </wml>

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

.wml text/vnd.wap.wml .wmls text/vnd.wap.wmlscript

Если вы хотите использовать картинки (WBMP) вам также необходимо добавить и этот MIME-тип:

.wbmp image/vnd.wap.wbmp

XML

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

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

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

Как можно видеть из других статей на данную тему в этом номере журнала, применение XML в задачах распределенных вычислений не ограничивается управлением сетями и системами. Всякая структура данных — от относительно простых форм печатных документов, стимулировавших появление языков разметки, таких, как стандартный обобщенный язык разметки (Standard Generalized Markup Language, SGML), до типографских представлений математических формул и, наконец, полномасштабных функций корпоративного планирования ресурсов (Enterprise Resource Planning, ERP) — может быть представлена с помощью документов XML и определений типов документов (Document Type Definition, DTD).

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

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

Помимо грамматики документы XML также отдают «на откуп» характеристики отображения. Стандартом на таблицы стилей для SGML является язык спецификации семантики и стилей документов (Document Style and Semantics Specification Language, DSSSL). Кроме того, документы XML могут форматироваться и отображаться с помощью каскадируемых таблиц стилей (Cascading Style Sheet, CSS), однако, к сожалению, реализации последних в стандартных браузерах не согласуются между собой. Ожидаемый новый стандарт на расширяемый язык стилей (Extensible Style Language, XSL) должен вобрать в себя многие лучшие черты DSSSL и CSS, к тому же он будет написан на XML.

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

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

Xml_011pic.shtml

Архитектура CIM. Данная диаграмма иллюстрирует структуру CIM Device Schema. Голубые стрелки указывают на наследование, красные линии означают ассоциации, а зеленые линии соответствуют объединению, специальному виду ассоциаций для отношений между целым и его частями.

XML через призму программирования

Журнал , #09-10/1999

Павел Храмцов

Прикладное программирование для Web начиналось с обработки запросов пользователя и динамической генерации страниц на стороне сервера. Эта же тенденция получила развитие и в языках программирования вставок в HTML-документы. Затем появились языки программирования элементов HTML-документов на стороне клиента. И те, и другие привязаны к модели данных HTML. Сегодня, когда Web мигрирует к стеку спецификаций XML, разработчики средств программирования должны это учесть и правильно отреагировать, позволив, например, манипулировать элементами XML-разметки. Стандарт, призванный обозначить и решить эту задачу, получил название Document Object Model - DOM.

Как известно, все начиналось с SGML [1], породившего HTML [2], а когда возможности последнего были исчерпаны, произошел частичный откат к SGML. В результате появился новый язык - XML (eXtensible Markup Language) или, более точно, стек спецификаций языков разметки различного назначения, которые базируются на общих синтаксических правилах [4]. Возникновение XML было обусловлено, в частности, стремлением разработчиков унифицировать форму хранения документов для различных носителей информации. Не последнюю роль сыграла и необходимость развития и унификации формата хранения метаданных, а также преобразования документов в процессе их отображения и просмотра.

Параллельно с процессом развития формального статического описания содержания документа развивались и способы его изменения. Первоначально они были обозначены в JavaScript, затем язык программирования Java позволил размещать внутри документа и видоизменять информацию любого типа. Появление VBScript и JScript означало, что Microsoft движется в том же направлении. Постепенно технология Java опустилась до уровня средств разработки приложений Web, а сценарное направление оформилось в концепцию DHTML (Dynamic HTML).

И XML, и DHTML, и Java в конечном итоге замкнулись на модель данных Web, множество страниц Web, которые, с точки зрения разработчиков поисковых языков XML, представляют собой сплошной поток разнотипных данных [5].

Один документ (страница) - это подмножество всех документов (страниц) Web. Модель данных Web определяют в виде графа - "лес" из деревьев.

Рис.1. Графическое представление структуры HTML-документа

Чтобы представить предмет нашего обсуждения в более простом виде, возьмем HTML-документ и "препарируем" его с точки зрения такой графовой модели данных (рис. 1). Весь документ - это один большой элемент разметки HTML. При этом документ является блочным элементом, который не может пересекаться с другими документами, однако может содержать блоки, например, HEAD и BODY. В свою очередь HEAD и BODY тоже могут включать другие блоки. При этом элемент BODY в своих атрибутах способен определить свойства всего отображаемого тела документа, например, цвет текста, цвет фона или, скажем, цвет гипертекстовых ссылок. Если двигаться еще дальше внутрь BODY, то с очень большой вероятностью в типичном HTML-документе можно встретить элемент разметки IMG, у которого есть свои свойства.

Теперь назовем узлы графа объектами, а программам разрешим изменять свойства этих объектов. Скажем, значение атрибута SRC у объекта, который соответствует элементу разметки IMG. При этом выполнять такие изменения можно, используя метод из набора стандартных методов, общих как для сценариев языков, так и для Java. Все это образует концепцию DOM - Document Object Model. Собственно DOM - это интерфейс прикладного программирования в рамках модели данных Web или, другими словами, набор стандартных методов объектов Web. Если нужно вывести текст в тело документа, это можно сделать на любом языке программирования, который поддерживает DOM: document.write(<kuku>);

Здесь задействован стандартный метод write объекта document. Имя метода, значение, которое он возвращает, аргументы метода и их типы - все стандартизовано в DOM.

Таким образом, путь развития Web-технологии пролегает от статической HTML-разметки через скриптовые языки, Java и DHTML к спецификациям XML и DOM. Остановимся на этапах этого пути подробнее.

XML- ловушки

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

Чтобы осознавать влияние XML на будущее, необходимо понимать влияние реляционных баз данных в прошлом и в настоящем. РБД оказались много лучше, чем то, что было до них - проще, мощнее и доступнее - и когда они появились в 1980-х, закрутилось массированное строительство новых баз данных. Новые приложения новых БД роились, росли и были необходимы своим создателям. А потом мы увидели, что создали информационный хаос.

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

Проблему межсистемных обменов данными РБД можно выразить так: если у вас N баз, то сочетания по обмену данными растут как N-квадрат. То есть, уже при 30 БД (а у многих компаний намного больше) это уже почти 1000 сочетаний. И даже если вы строите, сопровождаете и вникаете лишь в часть интерфейсов, суммарная сложность становится неуправляемой. Многие компании уже проиграли эту борьбу со сложностью и сейчас тяжко расплачиваются. Вот уже двадцать лет мы в "реляционной" эре, но все никак не справимся с проблемой информационной сложности, в которую она нас погрузила.

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

Впервые входящим в e-business компаниям это не кажется серьезной проблемой. Разве, считают они, так сложно выбрать один из новых XML-стандартов, к примеру, FIN-XML для банковских транзакций или C-XML для e-бизнеса, и написать интерфейс с ним для нашей главной системы? Однако любой из этих стандартов электронной торговли не менее сложен, чем РБД-схема уровня выше среднего. Разработка интерфейса между одним из стандартов и крупной ИС вашей компании - вполне выполнимая, однако, серьезнейшая работа.

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

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

Эта капкан сложности не менее реален и опасен, чем капкан кучи РБД.За истекшие 20 лет мы так и не смогли справиться с проблемой сложности РБД. Как избежать намного большего капкана сложности, сопутствующего XML ?

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

XML- надежды

Индикатор перемен сегодняшнего бизнеса - ворвавшаяся в Internet электронная коммерция. Ожидается, что эта революция окажет в ближайшее время наибольшее влияние на транзакции типа business-to-business. Анонсы Ford и General Motors о том, что они намерены подключить e-business для всех своих продаж (а для Ford это $80 млрд. в год) отмечались комментаторами как знамение, что эпоха электронного бизнеса пришла.

Для обмена транзакциями электронной коммерции необходим общий язык, с помощью которого компании могли бы обмениваться структурированными данными между своими разнотипными компьютерами. Язык Internet первого поколения, HTML, не годится для этой цели - он описывает форматирование информации, но не ее смысл. И вот появился XML - Extensible Markup Language. Как и HTML, он содержит текст, размеченный тегами и легко "переносится" по Internet. Но теги в XML описывают уже и смысл и структуру информации, позволяя напрямую обрабатывать ее программными средствами.

И законодатели IT, и пользователи, встретили XML с распростертыми объятиями - появления стандарта и быстрое его признание последние два года были главной темой информационных технологий. Все промышленные конкуренты, IBM, Microsoft, Sun и Oracle, взяв за основу стандарт XML 1.0, разрабатывают сейчас на его основе свои продукты и сотрудничают в создании сопутствующих стандартов. XML сегодня - мировая стандартная платформа для электронной коммерции. Однако для конкретного бизнес-приложения сам по себе XML еще не ответ - он лишь основа, на которой этот ответ можно построить. В отсутствии каких-либо предписаний кроются и сильные, и слабые стороны XML для электронной коммерции.

XML ПОВЕРХ ICE

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

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

До появления ICE всякий раз, когда «Рейтер» заключало соглашение с каким-либо сервером Web о включении своего информационного наполнения, обеим сторонам приходилось прибегать к дополнительному программированию, чтобы заголовки и блоки новостей могли быть интегрированы в целевой узел Web.

Учитывая то, что основные затраты на распространение новостей, таким образом, приходились на переопределение соединений и преобразования, несколько игроков на рынке объединились для создания ICE — протокола базового механизма регулярной рассылки новостей. В июле 1999 года представители инициативной группы разработчиков продуктов для ICE, агентств новостей и их подписчиков собрались в Чикаго на ICE Summit. Эта встреча была организована Исследовательским институтом Ассоциации графических коммуникаций.

ICEберг. Пакет (или полезная нагрузка, как называется полное сообщение) Internet Content Exchange (ICE) содержит главным образом один или несколько тегов элементов ICE, а те, в свою очередь, могут включать текстовое наполнение в формате XML, двоичные данные в кодировке base64 или URL, указывающий на хранящийся в Web файл, который следует загрузить и включить как часть полезной нагрузки.

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

врезку «Три реализации ICE»). Это не тот протокол, где переопределяется все устройство вселенной (его претензии гораздо скромнее), но он удовлетворяет вполне определенные потребности бизнеса и делает свое дело с учетом всех тонкостей решаемой задачи, избегая при этом всяких излишеств. Спецификация ICE содержит DTD, определяющие, какими должны быть сообщения с различными запросами и ответами как при переговорах о новой подписке, так и при предоставлении информационного наполнения. (Пока что инициативная группа избегает использования XML Schema, поскольку та еще должна быть доработана и принята W3C.) ICE отличается от типичного приложения XML тем, что в нем XML применяется для форматирования сообщений внутри протокола, а не для определения более традиционных документов. Кроме того, в то время как XML чаще всего служит для предоставления размеченных документов клиенту (обычно браузеру Web, выполняемому на машине конечного пользователя), ICE предназначен преимущественно для межсерверных коммуникаций, где необходимость в визуальном представлении данных (и участии человека) отсутствует.

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

Таким способом ICE позволяет согласовать следующие два аспекта подписки: во-первых, как будет доставляться подписка — по запросу подписчика (pull) или по каналам агентства (push); во-вторых, каким будет график доставки.

На ICE Summit Рик Левин, архитектор Web в Sun Microsystems, отметил, что серверы согласуют только техническую, а не финансовую или информационную сторону соглашения.

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

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

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

Сама полезная нагрузка также формализуется с помощью тегов XML. Кроме того, контроль над тем, как обрабатываются элементы, описываются в полезной нагрузке с помощью свойств соответствующих тегов XML. Сила протокола, по сравнению с более ранним и тривиальным форматом определения канала (Microsoft Channel Definition Format), состоит в том, что ICE вводит постоянные элементы подписки. Например, новость всегда должна иметь заголовок. Содержание заголовка может меняться, но ему отводится определенное место, где его всегда можно найти.

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

XML превосходит самое себя

Роберт Ричардсон

LAN/ЖУРНАЛ СЕТЕВЫХ РЕШЕНИЙ #11/99

Применение XML для решения практических задач предполагает улучшение описания документов и выход в мир обмена сообщениями.

Предположим, что вас убедили в ценности расширяемого языка разметки (Extensible Markup Language, XML). Что дальше? Купить редактор XML и ждать, пока все станет на свои места? Каждый ли, кто натолкнется на ваши документы, поймет ваш язык, ведь XML является самодокументируемым форматом разметки?

Без сомнения, все документы, которые иначе были бы созданы на HTML, можно хранить как XML вместе с соcтавленными вами самими пояснительными тегами. На данном этапе развития Web вам придется использовать сервер для преобразования XML в HTML, если вы хотите, чтобы любой желающий мог просматривать документы XML как страницы Web, но это незначительное неудобство сохранится лишь до тех пор, пока все браузеры в мире не станут понимать XML. Вероятно, еще до этого момента вы сможете извлечь преимущества из следования правильной практике кодирования, в частности инструментарий поиска сможет различать разные теги, например то, что <publication> Network </publication> имеет иной смысл, нежели <marketing-strategy> Network </marketing-strategy>.

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

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

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

Кроме того, XML выходит за первоначально отводимые ему пределы; он больше не ограничивается исключительно автономными документами с информационным наполнением. В настоящее время многочисленные работы ведутся над использованием XML для определения последовательностей сообщений, составленных на XML. Их результаты можно найти и в BizTalk, но, возможно, наиболее зрелым примером является протокол обмена информационным наполнением Internet (Internet Content Exchange, ICE). ICE служит отличным примером того, как отрасль может решать свои проблемы с помощью обмена сообщениями на базе XML.

XML ПРИСТУПАЕТ К РАБОТЕ

XML будет пользоваться все возрастающей популярностью как открытый и эффективный стандарт для сотрудничества между компаниями и электронной коммерции. Данные XML будут перемещаться преимущественно с помощью HTTP, но они могут также распространяться с помощью технологий организации очередей сообщений, таких, как MQSeries компании IBM или Message Queue Server компании Microsoft.

Однако для того, чтобы это стало возможным, требуется определить и согласованно внедрить специфические схемы. W3C совершенно правильно решил, что он не должен в это вмешиваться; в результате десятки отраслевых организаций по стандартизации занимаются определением XML, DTD и схем. Среди них RosettaNet (ориентированная на поставки в области ИТ — см. подробности на ), CommerceNet (), XML/EDI Group (), Open Applications Group (), XML.ORG () и BizTalk ().

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

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

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

XML пришел всерьез и надолго — и он обладает массой достоинств. Кстати, как утверждают в W3C, под маской недавно принятого «бостонского» дополнения к Synchronized Multimedia Integration Language (SMIL), XML может стать ключевым элементом цифрового телевизионного вещания.

Возможно, пока еще рано полностью переделывать свой сервер Web под XML. Однако начинать работать с ним уже пора, тем более что необходимый инструментарий уже имеется. С точки зрения конечного пользователя, Internet Explorer 5.0 компании Microsoft поддерживает XML, XSL, DTD и схемы XML, а Netscape Navigator/Mozilla 5.х будет это делать после своего выхода.

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

XML-стандарты для e-коммерции: надежды и капканы

"XML E-Business Standards: Promises and Pitfalls" by Robert Worden

Перевод с авторского сайта

XML: время пришло

Джонатан Эйнджел

LAN/ЖУРНАЛ СЕТЕВЫХ РЕШЕНИЙ #11/99

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

Если вы являетесь разработчиком для Web, то вам приходится иметь дело со множеством технологий — подключаемые модули Netscape, элементы управления ActiveX, Dynamic HTML, Cascading Style Sheets (CSS) и т. д. — для расширения, как утверждается, возможностей ваших страниц. В немногих случаях вы действительно получали обещанное, но в основном эти технологии только серьезно усложняли вам жизнь из-за их несогласованного поведения в разных браузерах.

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

Однако расширяемый язык разметки (Extensible Markup Language, XML) — это совсем иное дело. Хотя, как и любая новая технология, он требует освоения, это не должно вызывать у вас мигрень. XML пришел всерьез и надолго. Главное же, он должен сделать вашу жизнь легче, а не тяжелее.

Наиболее важная особенность XML и сопутствующей ему технологии расширяемого языка таблицы стилей (Extensible Stylesheet Language, XSL) состоит в отделении форматирования от информационного наполнения. Это может показаться знакомым всем, кому приходилось работать с CSS или таблицами стилей в Microsoft Word. Однако если стандартный HTML уподобить фотоснимку здания, то CSS будут соответствовать инструкциям для фотолаборатории о том, как следует обрабатывать фотографию. Все двери можно сделать красными, все стены — розовыми, а крышу — серой. Однако без доступа к светокопии здания никаких фундаментальных изменений внести нельзя. XML, в отличие от HTML, позволяет экспонировать данные и манипулировать ими.

XQuery: язык запросов XML

Дон Чемберлин

#01/2003

Консорциум World Wide Web Consortium (W3C) образовал рабочую группу для разработки языка запросов к источникам данных, представленных на языке XML. Этот язык запросов, получивший название XQuery, развивается до сих пор и описан в серии предварительных документов. XQuery - функциональный язык, состоящий из нескольких видов выражений, которые могут использоваться в разных сочетаниях. Язык базируется на системе типов XML Schema и совместим с другими стандартами, связанными с XML. В статье объясняются причины создания языка запросов XML, предлагается вводное описание XQuery и приводится несколько примеров его использования.

Язык XML [1] все чаще применяется в качестве формата для обмена информацией между разными приложениями в Internet. Популярность XML во многом объясняется его гибкостью при представлении разных видов информации. Применение тегов делает XML-данные самоописываемыми, а расширяемая природа XML позволяет определять новые виды специализированных документов. По мере роста значимости XML создается целая серия стандартов, многие из которых были подготовлены консорциумом W3C [2]. Так, XML Schema [3] обеспечивает нотацию для определения новых типов элементов и документов; XML Path Language (XPath) [4] - нотацию для выбора элементов в документе XML; Extensible Stylesheet Language Transformations (XSLT) [5] - нотацию для преобразования документов XML из одного представления в другое.

XML позволяет приложениям обмениваться данными в стандартном формате, не зависящем от способа их хранения. Скажем, одно приложение может использовать естественный для XML формат хранения, а другое - хранить данные в реляционной базе данных. Поскольку XML все больше утверждается в роли стандарта для обмена данными, естественно, что запросы, поступающие от приложений, должны быть выражены как запросы к данным в формате XML. Это вызывает потребность в языке запросов, явно ориентированном на источники XML-данных. В октябре 1999 года W3C образовал рабочую группу XML Query Working Group [6] с целью разработки такого языка запросов, получившего название XQuery.

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

Разработка XQuery все еще продолжается. XML Query Working Group опубликовала предварительные рабочие версии нескольких документов, описывающие существующее состояние разработки. Возможно, наиболее важным из них является документ XQuery 1.0: An XMLQuery Language [7], содержащий синтаксис и неформальное описание языка. Кроме того, рабочая группа опубликовала список требований [8], описание модели данных, положенной в основу языка [9], формальное описание семантики [10], список функций и операторов [11], а также примеры, иллюстрирующие применение этого языка [12]. Каждый из этих документов обновляется по мере дальнейшего развития XQuery. Данная статья опирается на самую последнюю к моменту публикации версию языка.

На разработку XQuery влияет целый ряд факторов. Возможно, важнее всего совместимость с существующими стандартами W3C, в том числе, XML Schema, XSLT, XPath и сам XML. В частности, язык XPath настолько тесно связан с XQuery, что XQuery определяется как надмножество XPath. Общая структура XQuery базируется на предварительной версии языка, получившей название Quilt [13]. В свою очередь, на создание Quilt оказали влияние функциональный подход языка OQL (Object Query Language) [14], синтаксис на основе ключевых слов языка SQL [15] и предыдущие предварительные версии языка запросов XML, в том числе XQL [16], XML-QL [17] и Lorel [18].

Цель XML Query Working Group - определение двух видов синтаксиса XQuery: один из них выражается на XML, а другой оптимизирован для восприятия человеком.

В этой статье описывается только вариант XQuery.

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

В данной статье описывается модель данных, на которой основан XQuery, а затем представляется обзор языка XQuery в виде серии примеров. Синтаксис XQuery и более полное описание самого языка можно найти в [7].

Модель данных

Формально входные и выходные данные XQuery определяются в терминах модели данных, описанной в [9]. модель данных обеспечивает абстрактное представление одного или нескольких документах или фрагментов XML-документов. Модель данных опирается на понятие последовательности. Последовательность (sequence) - это упорядоченный набор нулевого или большего числа объектов. Объект (item) может быть узлом или атомарным значением. Атомарное значение (atomic value) - экземпляр одного из встроенных типов данных, определенных в XML Schema, таких как строки, целые и десятичные числа, даты. Узел (node) соответствует одному из семи видов: элементы, атрибуты, тексты, документы, комментарии, команды обработки и пространства имен. Узел может иметь другие узлы в качестве потомков, что позволяет образовывать одну или несколько иерархий узлов. Некоторые виды узлов, такие как элементы и атрибуты, имеют имена или типизированные значения, либо и то, и другое. Типизированное значение (typed value) - это последовательность из нуля или большего числа атомарных значений. Узлы индивидуальны (т. е. два узла можно различить, даже если они имеют одинаковые имена и значения), но атомарные величины такой индивидуальностью не обладают. Для всех узлов иерархии имеется полный порядок, называемый порядком документа (document order), в соответствии с которым каждый узел предшествует своему потомку. Порядок документа соответствует порядку, в котором следовали бы узлы, если бы иерархия узлов представлялась в формате XML.

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

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

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

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

Входные XML-документы могут быть преобразованы в запросную модель данных с помощью процесса, называемого проверкой корректности по схеме (schema validation). Этот процесс выполняет грамматический разбор документа, проверяет его корректность в соответствии с некоторой схемой и представляет документ в виде иерархии узлов и атомарных значений, помеченных типом полученным из схемы [3]. Если входной документ не имеет схемы, проверка его корректности выполняется в соответствии с используемой по умолчанию рекомендательной схемой, которая присваивает родовые типы - узлы маркируются как anyType, а атомарные величины - как anySimpleType.

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

В WML определяется девять типов,

Элемент:
Do
Атрибуты:
type - указывает микроброузеру назначение кнопки. В WML определяется девять типов, но в подавляющем большинстве случаев используются "accept" и "options".
label - значение этого атрибута используется для замены названия кнопки. Это помогает кастомизировать приложения. Количество символов на кнопке ограничено возможностями устройства.
name - установка этого атрибута дает возможность разработчику воспользоваться преимуществами иерархической структуры WML-документа. Элемент "do" с именем "one" унаследует свойства определенные элементу с таким же именем в элементе "template" этой деки.
optional - указывает микроброузеру на необязательность показа этой кнопки в случае если атрибуту присвоено значение true.
Элемент
Go
Атрибуты:
href - URL.
sendreferer - этот атрибут необходим серверу в списках контроля доступа. Его значение указывает броузеру на то, что необходимо отослать на сервер URL минимально возможной длины.
method - может принимать значение либо "post" либо "get". Значение аналогично HTML.
accept-charset - указывает кодировку, в которой микроброузер должен посылать ссылку.
Небольшой пример простейшей навигации. <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.com/DTD/wml_1.1.xml"> <wml> <card id="Start"> <do type="accept"> <go href="#nextCard"/> </do> <p>Hello World!</p> </card> <card id="nextCard"> <do type="options"> <prev/> </do> <p>Next Card!</p> </card> </wml>
Элемент
Setvar
Атрибуты:
name - имя, присваемое переменной. Переменная так же может выполнять эту функцию, например: <setvar name=$bogus value=$bear>.
value - значение, присваемое переменной.
Элемент
Postfield
Атрибут:
name имя, присваемое переменной. Переменная так же может выполнять эту функцию, например:

<postfield name=$bogus value=$bear>.
value - значение, присваемое переменной. <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.com/DTD/wml_1.1.xml"> <wml> <card id="Start" label="Bob's CGI"> <do type="accept"> <setvar name="lastExecuted" value="bob.cgi"/> <go href="bob.cgi" method="post"> <postfield name="one" value="one one"/>  <postfield name="one" value="one"/> <postfield name="two" value="two two"/> </do> <p>Hello World!</p> </card> </wml>
Элемент
Anchor
Атрибуты:
title - имя элемента. Микроброузер может воспользоваться этим атрибутом по своему усмотрению. При перемещении курсора на анкор, микроброузер может вывести его имя в софт-кнопке.
Элемент
A
Атрибут:
href - URL на который ссылается анкор. У этого элемента нет дополнительных атрибутов позволяющих указать статус ссылки или ее метод. Если необходимы эти опции можно воспользоваться элементом "anchor" с внедренным в него элементом "go":
<anchor> click me <go href="#clickedMe"/> </anchor> <a href="#clickedMe">click me</a>

и высокая конкуренция на рынке

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

в коем случае не претендует

Данный обзор не в коем случае не претендует на полноту описания всех возможностей языка Curl. В нем я постарался описать основные конструкции языка, которые касаются исключительно отображения данных в броузере, и которые можно сравнивать с конструкциями языка HTML и его расширения CSS. В данном обзоре не затрагивались такие возможности языка как, например, работа со стандартными средствами программирования (циклы, условные и безусловные переходы), работа с классами, обработчиками ошибок, библиотеками 2D и 3D графики, анимацией, интеграцией с XML и многим другим.
На мой взгляд, Curl является той средой, которая объединяет вместе все популярные на сегодняшний день WEB технологии - HTML, CSS, JavaScript - в единое целое и дает возможность удобно работать в единой среде разработки. Исполнение же документа через plugin на компьютере пользователя это не что иное как отображение любой из стандартных технологий броузером. Т.о. популярность данного языка напрямую зависит от того, насколько скоро появятся броузеры со встроенной поддержкой этого нового стандарта.

в данной статье описана небольшая

Хочется отметить, что в данной статье описана небольшая часть проекта ebXML, касающееся теме моделирования сообщения. Что касательно материала, то планируется продолжить данную тему, описав систему управления сообщениями. Более подробная информация о проекте, включая основные требования к разработкe и проекты спецификаций можно найти на сайте .
По официальным данным CEFACT финансируется для работы над проектом ebXML до середины 2002 года. К этому моменту должны быть разработаны все спецификации и поданы предложения в группу стандартизации (ISO) при ООН.
В настоящее время в рабочей EDI-группой в вычислительного центра таможенных органов (ГНИВЦ ГТК) ведется проект по приему электронных документов в стандарте UN/EDIFACT (дополнительно вместе с бумажными документами) в качестве транзитных таможенных деклараций (Документа контроля доставки), а также исследуется возможность обмена XML сообщениями, т.к. у многих участников ВЭД не имеется собственной EDI-системы. В этом направлении разработок проект ebXML является некием ориентиром для организации обмена.
Автор будет очень благодарен за отзывы об актуальности темы, общем содержании, виде и стиле изложения, а также всем остальным комментариям, которые помогут в дальнейшем улучшить качество написания сборника статей и выпуску книги освещающую тему использования электронных документов.
Также автору будет интересно узнать пожелания читателей об освещении смежных тем, связанных с использованием электронных документов и электронной коммерции. Свои комментарии и пожелания просьба направлять на Автор постарается ответить на вопросы, связанные с изложенным материалом или осветить их в будущем.

Перечисленные методы не исчепывают возможности

Перечисленные методы не исчепывают возможности использования Java-программ при работе с базами данных. Следует учесть, что технологии постоянно развиваются, совершенствуются и пополняются новыми стандартами. Совсем недавно Microsoft объявила о создании новых стандартов RDO, ADO и OLE DB. Эти разработки, также как JDBC движутся в направлении объектно-ориентированных технологий и основаны на классах, которые могут быть применены в JDBC. В то же время и JDBC развивается и в скором времени появится язык JSQL, который уже анонсировали некоторые компании. В этом случае, SQL операторы можно будет встраивать в Java программы, а не передавать их как строковые переменные в Java-методы. Встроенный SQL-препроцессор позволит программистам использовать Java-переменные в SQL операторах.
Сергей Борисович Дунаев, Ивановский государственный энергетический университет.

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

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

Замечания, соглашения и обобщения

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

Замена графического текста

По возможности, используйте форматированный текст вместо графического. Если необходимо изменить размеры и цвет текста, воспользуйтесь <b <font color=> <font size=> или <h>.

Запланированные отчеты

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

Запуск NCSA Telnet из DOS

telnet [options] [machine machine ....]

где options:

-? Подсказка Usage.

-c colorcode Установка цвета по умолчанию.

-h Ставится перед указанием пути к конфигурационному файлу.

-s Вход в режим сервера (открывается экран консоли) PC ждет внешних FTP или rcp запросов. Таким образом открывается доступ к файлам PC с удаленной машины. (* не работает)

-t Опция BIOS, позволяет сделать Telnet совместимым с Windows и Topview, но замедляет скорость вывода на экран. (* не удалось проверить.)