Что такое XLink?
Атрибут xlink:actuate
Атрибут xlink:actuate может принимать одно из следующих значений:
onRequest;
onLoad;
other;
none.
Значение onRequest указывает, что связь должна обходиться только тогда, когда пользователь запросил ее и если он это сделал. (Это поведение обычной связи HTML.) Например, приведенная ниже связь выполняет переход в книжный магазин FatBrain только в том случае, если пользователь потребует это действие:
Buy from FatBrain
С другой стороны, если атрибут xlink:actuate связующего элемента равен onLoad, эта связь прослеживается, как только загружен документ, содержащий эту связь. Например, вы можете установить этот атрибут, равным onLoad, чтобы изображение или другие части внешнего содержания были встроены в связывающий документ. В этом случае пользователю не нужно щелкать мышкой на связи, чтобы проследовать по ней. Такой код мог бы выглядеть следующим образом:
Если значение xlink:actuate равно other, то приложение должно искать в документе другую разметку, не описанную с помощью XLink, чтобы решить, когда обходить эту связь. Например, браузер мог бы определить элемент PRELOAD, как указание на то, что на этой странице документ или изображение пока не применяются, но скоро, вероятно, будут использоваться.
Следовательно, если браузер располагает дополнительной доступной пропускной способностью, он должен, пока пользователь читает эту страницу, загрузить документ и кэшировать его. В противном случае, приложение будет ожидать, пока пользователь не активизирует связь.
Приложения, которые не распознают элемент PRELOAD, будут просто игнорировать его. (Необходимо помнить, что это исключительно теоретический пример!)
Наконец, присвоение атрибуту xlink:actuate значения none, означает, что приложение будет самостоятельно решать, обходить ли и, если да, то когда обходить эту связь.
Атрибут xlink:show
Атрибут xlink:show может принимать одно из следующих значений:
replace;
new;
embed;
other;
none.
Если значение xlink:show равно replace, то при активизации связи (как правило, посредством щелчка мышкой по этой связи, по крайней мере, в GUI-браузерах) адресат связи заменяет текущий документ в том же самом окне. (Это поведение является действием по умолчанию для связей HTML.) Например:
Beth Anderson
Если значение xlink:show равно new, то активизация связи вызывает открытие нового окна, в котором отображается адресуемый ресурс. Это похоже на поведение связей HTML, когда атрибуту target присвоено значение blank. Например:
Check this out, but don't leave our site completely!
Если значение xlink:show равно embed, то при активизации связи адресуемый ресурс вставляется в существующий документ. Что именно это означает - зависит от приложения. Обычно предполагается, что приложение должно каким-то образом изобразить связываемое содержание и показать его как часть заключительного документа. В качестве примера приведем фрагмент кода, в котором этот атрибут используется для того, чтобы указать, что изображение JPEG должно быть встроено в этот документ:
Если значение xlink:show равно other, то предполагается, что приложение будет искать другую разметку в документе, которая объяснит, что делать. Как правило, это могло бы использоваться, чтобы отдельное приложение XML использовало другие, отличные от XLink элементы для описания поведения связи. Например, у многих Web-страниц в заголовке находится элемент LINK, который указывает таблицу стилей (style sheet) и может выглядеть следующим образом:
Это связь, но то, что находится в ее конце, не заменяет текущий документ, не встраивается в него и не отображается в новом окне. Для XML-документов вы могли бы условиться, что такое поведение предполагается всякий раз, как встречается элемент STYLESHEET. Поскольку это поведение не является ни одним из трех предопределённых поведений связей, необходимо присвоить xlink:show значение other.
Наконец, атрибуту xlink:show может быть присвоено значение none, чтобы показать, что документ не содержит никакой информации, которая могла бы помочь приложению решить, что, если уж на то пошло, делать со связью. В этом случае все зависит только от приложения.
Независимо от того, какое поведение атрибут xlink:show предлагает, браузер или иное приложение, читающее документ, при активизации связи может делать все, что угодно, в том числе и ничего. Например, браузер, у которого отключена автоматическая загрузка изображений, может решить проигнорировать xlink:show="embed".
Атрибут xlink:type
Как было указано выше, с помощью атрибута XLink xlink:type используемые элементы могут быть определены как связующие. Этот атрибут может иметь одно из следующих значений:
simple: простая связь;
extended: расширенная, возможно, многоресурсная связь;
locator: указатель на внешний ресурс;
resource: внутренний ресурс;
arc: правило обхода между ресурсами;
title: описательный заголовок для другого связующего элемента;
none: элемент не имеет смысла, определяемого XLink.
Префикс xlink должен быть привязан к универсальному идентификатору ресурса (URI) пространства имен :
...
Как обычно, этот префикс может меняться, при условии, что URI остается прежним. Префикс xlink является привычным и должен использоваться, если у вас нет действительно веских причин, чтобы его изменить.
Что такое XLink?
Непременное условие успеха технологии Web лежит в ее способности связывать ресурсы. То, что "Всемирная паутина" опирается на признанный гоферовский протокол, может быть объяснено хотя бы тем, что HTML позволяет вставлять в документы ссылки гипертекста. С их помощью можно помещать изображения на страницы документов, а также переходить от одного документа к другому или же от одной его части к другой. С учетом того, что XML может быть преобразован в HTML для последующего просмотра, синтаксис, который, используется в HTML для задания связей, может быть перенесен и в XML.
Однако, связывание в HTML имеет ряд ограничений. Универсальные локаторы ресурсов (URL) указывают только на один документ. Большая глубина детализации, например, третье предложение в семнадцатом параграфе, невозможно, если, конечно, в рассматриваемом документе заранее не расставлены поименованные указатели (anchor). Но для этого необходимо иметь доступ к документу, на который требуется указывать.
XLink - это технология, которая позволяет решить указанные проблемы и установить более сложные связи между документами. XLink предназначена исключительно для работы с документами XML.
Связывание в XML состоит из двух частей: XLink и XPointers. XLink (XML Linking Language, Расширяемый язык соединений) определяет, как один документ связывается с другим. XPointers (XML Pointer Language, Расширяемый язык указателей) описывает, как общаются отдельные части документов. XLink указывает на универсальный локатор ресурса (URI), который устанавливает отдельный ресурс.
Глобальные атрибуты
Помимо указанного атрибута type XLink предоставляет ряд атрибутов, называемых глобальными, которые позволяют установить, является ли рассматриваемый элемент связующим, а также определить многие его свойства (например, когда загружать связанные ресурсы, как их увидеть, если они загружены, и так далее). В приведенной ниже таблице перечислены глобальные атрибуты, поддерживаемые XLink:
Таблица 1. Глобальные атрибуты
Атрибут определения типа
type
Атрибут локатор
href
Семантический атрибут
role, arcrole, title
Атрибут поведения
show, actuate
Атрибут обхода
label, from, to
Важное замечание . Согласно принятой терминологии, если элемент включает атрибут type со значением V, этот элемент именуется как элемент типа V, каким бы ни было его действительное имя.
Отношение элемента к определенному типу XLink накладывает на использование элементов следующие ограничения:
Для элемента данного типа только элементы определенных типов являются релевантными как подэлементы Xlink:
... никакой другой
элемент xlink здесь ни к чему...
Для элемента данного типа используются только некоторые атрибуты Xlink:
В приведенных ниже таблицах перечислены ограничения, накладываемые на применение атрибутов и подэлементов каждого типа. В таблице 2 приняты следующие обозначения: "R" означает "обязательный", а "O" - "факультативный". Пробел означает недопустимое сочетание.
В таблице 3 показано, для каких элементов XLink какие подэлементы XLink являются допустимыми.
Таблица 2. Правила использования атрибутов (в соответствии с рекомендацией консорциума W3C)
Атрибут
simple
extended
locator
arc
resource
title
type
R
R
R
R
R
R
href
O
R
role
O
O
O
O
arcrole
O
O
title
O
O
O
O
O
show
O
0
actuate
O
O
label
0
0
from
0
to
O
Таблица 3. Значимые типы потомка (в соответствии с рекомендацией консорциума W3C)
Тип предка
Значимые типы элемента потомка
simple
-
extended
locator, arc, resource, title
locator
title
arc
title
resource
-
title
-
Описание удаленного ресурса
Связующий элемент также включает факультативные атрибуты xlink:role и xlink:title, которые описывают удаленный ресурс: документ или другой ресурс, на который указывает эта связь. Атрибут xlink:title содержит простой текст, который характеризует этот ресурс. Атрибут xlink:role содержит URI, указывающий на документ, который более подробно описывает ресурс. Например, атрибут xlink:title может определять, что страница делает, а атрибут xlink:role может указывать на справочную страницу для этой страницы:
Search the Web with Google
И xlink:role и xlink:title описывают удаленный ресурс, а не локальный элемент. Удаленный ресурс в этом примере - это документ в . Не является исключением, хотя вовсе не обязательно, если содержание xlink:title будет таким же, как и у элемента TITLE страницы, с которой вы связываетесь.
Необходимо помнить, что XLink не определяет интерфейса, посредством которого атрибуты xlink:role и xlink:title представляются пользователю. Как и будет ли приложение применять эти атрибуты, целиком и полностью зависит от самого приложения.
Постановка задачи
Предположим, что вы хотите выразить на XML отношение между художником и окружающей его обстановкой. Это подразумевает создание связей между этим творческим работником и его наследием, а также задание связи к описанию исторических событий, имевших место на протяжении его жизни. Данные о художнике могут быть записаны в следующем файле: Modigliani Amadeo July 12, 1884 January 24, 1920 In 1906, Modigliani settled in Paris, where ...
Помимо этого, в отдельные файлы включаются описания периодов, на которые можно условно разбить его творчество:
Paris France Paris in the early 20th century (up to the twenties) Amadeo During this period, Russian, Italian, ...
Выполнение поставленного выше задания (то есть создание файла, который устанавливает связь между художником и его творческим наследием и этапами творческого пути) является задачей, которую невозможно решить с помощью "HTML-ных" тегов и атрибутов "img". Это объясняется целым рядом причин:
Отдельный художник оставил после себя не одно "наследие" (такие связи направляются от одного ресурса к нескольким).
Творческий путь отдельного художника распадается на несколько этапов.
Сама ссылка должна быть семантически значимой. (Творческое наследие не есть то же самое, что и характеристика определенного периода, и мы хотим выразить в нашем документе это различие!)
Простые связи
Рассмотрим следующий пример: Beth Anderson 7
В этом примере элементы имеют семантические имена, которые описывают их содержание, а не то, как они себя ведут. Информация о том, что эти элементы - связи, присутствует в атрибутах, но не в именах элементов. Атрибуты же определяют поведение связывания.
В самом первом элементе COMPOSER атрибут xlink:href определяет адресат связи. Значение атрибута - абсолютный URL http://www.users.interport.net/~beand/. Этот связующий элемент описывает соединение элемента COMPOSER текущего документа, содержание которого "Beth Anderson", с удаленным документом в . Если бы мы включили этот элемент в документ XML и загрузили его в Web-браузер, поддерживающий XLink, как, например, Mozilla or Netscape 6, браузер подчеркнул бы эту связь, окрасив ее в синий цвет, и при нажатии на нее открыл страницу .
Однако, данную ссылку можно интерпретировать более абстрактно: как просто определение однонаправленного соединения от одного ресурса, элемента COMPOSER, к другому ресурсу, Web-странице в . На рисунке 1 показано это соединение. При этом оно на самом деле не подразумевает какой-либо особой семантики или поведения. Что эта абстрактная связь означает - решать приложению, которое читает этот документ.
Рис. 1.
В элементе FOOTNOTE значение атрибута xlink:href - это относительный URL footnote7.xml. Этот связующий элемент описывает соединение элемента FOOTNOTE текущего документа, содержание которого "7", с документом с именем footnote7.xml, находящемся на том же сервере, в том же каталоге, что и документ, в котором появляется эта связь.
Наконец, в третьем элементе IMAGE значение атрибута xlink:href - это относительный универсальный локатор ресурса logo.gif. И снова протокол, хост и каталог этого документа берется из протокола, хоста и каталога документа, в котором появляется эта связь. Однако, этот элемент требует немного отличного поведения. Вместо ожидания, пока пользователь активизирует связь, атрибут xlink:actuate просит, чтобы связь была активизирована автоматически, как только этот документ загрузится. Атрибут xlink:show требует, чтобы результат был встроен в текущий документ, а не заменял его.
Следующий подраздел посвящен этим двум атрибутам: xlink:actuate и xlink:show.
Решение с помощью XLink
В XLink используются два типа связующих элементов (linking elements): simple (простой) - подобный "a" и "img" в HTML - и extended (расширенный). Однако, XLink не требует задания какого-либо определенного "корректного" имени для связей; наоборот, эта технология позволяет решить, какие элементы будут использоваться в качестве связей. Достигается это с помощью атрибута XLink type (тип). Приведенный ниже фрагмент иллюстрирует сказанное:
После того, как мы объявили расширенную связь, необходимо указать задействованные ресурсы. Поскольку информация о художнике и его жизни хранится вне нашего документа (и, следовательно, мы не можем ею управлять), чтобы ссылаться на нее, воспользуемся элементами XLink, атрибуты которых имеют значение locator. Напомним еще раз, что подход заключается не в задании имени тега, а в том, чтобы с помощью атрибутов XLink позволить помечать элементы как элементы типа locator:
В этом примере упущен только один момент: необходимо указать, как ресурсы относятся друг к другу. Для этого используются атрибуты, значения которых равны arc:
Нетрудно видеть, что использование XLink позволяет упростить нашу задачу и свести ее к созданию файла XML, содержащего элементы, подобные приведенным выше, где ясно и четко указаны все ресурсы и их отношения. Перейдем теперь к детальному рассмотрению механизма связывания XLink: атрибутов, их значений и правил их использования.
Связи поведения
Как было сказано выше, связующие элементы могут включать два факультативных атрибута, которые предоставляют приложениям информацию о том, как связь ведет себя при активизации.
Атрибут xlink:show рекомендует, как следует отображать содержание, когда связь активизирована, например, должно ли открываться новое окно, чтобы показать адресуемое содержание, либо это содержание должно загружаеться непосредственно в текущее окно.
Атрибут xlink:actuate позволяет определить, когда активизировать связь, например, сразу после загрузки документа или исключительно после запроса пользователя.
Важно отметить, что хотя указанные поведения являются независимыми от приложений, программы могут игнорировать рекомендации этих атрибутов.
Веб-хостинг: кто, где, когда и почему
По материалам
Что такое веб-хостинг? Нужен ли мне платный веб-хостинг или ограничиться бесплатным? Употребляемые термины могут быть непонятны тем, кто не имеет представление о том, что такое хостинг.
Что такое веб-хостинг?
Веб-хостинг - это способ размещения сайта в сети интернет. Как только вы разместили свой сайт на сервере - кто угодно может получить доступ к нему, набрав доменное имя в строке броузера. Доступ к сайту возможен 24 часа в сутки, 7 дней в неделю, 365 дней в год.
Для того, чтобы разместить свой веб-сайт в сети, необходимо:
- прежде всего, иметь собственный веб-сайт. Нужно иметь копию сайта на локальном компьютере (в html-файлах), или же готовые материалы + скрипт, который позволял бы создать веб-сайт непосредственно на сервере.
- доменное имя. Нужно найти и приобрести доменное имя сайта. Желательно, чтобы имя говорило о тематике сайта, и было легко запоминающимся. Доменное имя может быть в любой, на ваш выбор, доменной зоне, например: .com .net .org .ru и т.д. При выборе доменной зоны руководствуйтесь данными о тематиках доменов. Домены .com , например, предназначены для сайтов коммерческой направленности, .org - государственных учреждений и общественных организаций. Региональные домены говорят о принадлежности сайта какому-либо региону. Это необязательное правило, но стоит об этом помнить.
- заказать один из хостинг-планов в компании, осуществляющей услуги хостинга. Выбор тарифного плана является отдельной темой для разговора, поэтому в данной статье мы не будем ее обсуждать.
Что такое сервер?
Это компьютер, размещенный у провайдера интернет и подключенный во всемирную сеть, на котором хранится копия веб-сайта. Как правило, один сервер вмещает достаточно много веб-сайтов, за счет большого дискового пространства. Но в целом, это не имеет значения. Важен не объем сервера, а его вычислительные мощности и пропускная способность интернет-каналов провайдера.
С помощью любого веб-броузера (программы для просмотра сайтов в интернет) вы можете получить доступ к своему веб-сайту, набрав в строке адрес сайта.
Веб-хостинг можно сравнить с арендой недвижимости. Множество компаний готовы предложить хостинг за умеренную плату, однако не многие могут обеспечить хостингом должного качества. Говоря о стоимости хостинга, нужно отметить, что для большинства веб-сайтов стоимость платы в месяц может не превышать 10 долларов США. В пределах этой стоимости можно найти хостинг-компанию, предоставляющую около 300 мегабайт дискового пространства на сервере и всевозможные функции, такие как: установка и запуск скриптов, поддержка баз данных, административная панель (т.е. ваша панель управления) веб-сайта, где производятся настройки не только сайта, но и электронной почты.
Если вы планируете открыть представительство в сети, нужно не только решить, какого уровня будет веб-сайт, но и правильно определиться с выбором провайдера хостинга. Статистически, более 70% владельцев веб-сайтов переходили с одного хостинга на другой хотя бы один раз. Перевод к другому провайдеру был вызван неудовлетворенностью качеством предоставляемых услуг хостинга.
Действительно, любой провайдер говорит о том, что он самый лучший, и у него самые низкие цены и т.д. и т.п. А потом оказывается, что служба поддержки не отвечает, или отвечает, но с задержкой, сервера временами "зависают" из-за большой нагрузки. Подобная неосторожность в выборе провайдера может принести большие потери. Представьте себе, что означает отсутствие доступа к сайту фирмы, где каждые полчаса обновляется важная информация для сотрудников, находящихся в удаленных филиалах компании. Представьте, что потенциальные клиенты фирмы не могут узнать контактный телефон или электронный адрес, потому что не могут попасть на сайт. Возможно, через полчаса они уже не сделают второй попытки зайти на сайт. Возможно, через полчаса они найдут другую конкурирующую фирму. Ущерб от зависающих серверов может быть огромным.
Чтобы не совершить ошибок в выборе хостинга, необходимо посетить форумы и рейтинговые сайты, где обсуждаются хостеры. Внимательно почитать мнения клиентов о разных хостинг-провайдерах.
Время, потраченное на изучение форумов и чтение отзывов, окупится стабильностью работы веб-сайта.
Далее, какой тарифный план выбрать?
Тарифные планы, как правило, отличаются размером дискового пространства, возможным количеством поддоменов сайта, ограничением по исходящему траффику. Безусловно, после того, как вы отобрали несколько наиболее авторитетных хостинговых компаний, необходимо сравнить их тарифные планы. При сравнении необходимо помнить о том, каким требованиям должен удовлетворять тарифный план. Нужно принять во внимание:
- размер предоставляемого дискового пространства
- возможность иметь множество почтовых адресов
- установка и запуск приложений (cgi, php, MySQL)
- доступ к сайту по FTP
- административную панель, с помощью которой осуществлять контроль и управление сайтом (очень важно: качественная административная панель, где все функции удобно "разложены по полочкам" сэкономит вам массу времени)
- уровень оплаченного исходящего траффика
Разберем по порядку
Если ваш первый веб-сайт будет состоять из нескольких страниц и логотипа, то вполне подойдет тарифный план, где размер дискового пространства будет от 100 до 300 мегабайт. Этого более чем достаточно. Меньше 100 мегабайт дискового пространства уже не предоставляет практически ни один хостинг-провайдер.
С почтовыми адресами проще - практически все провайдеры дают в распоряжение неограниченное число адресов в пределах одного домена. Ограничение может быть только по числу отдельных POP3 и SMTP аккаунтов. Это означает, что, несмотря на разные адреса, вы имеете ограниченное число отдельных соединений с помощью почтовой программы.
Установка и запуск скриптов необходим, если сайт будет построен на динамических страницах, или же необходимо реализовать функцию поиска внутри сайта. Если же сайт будет полностью построен на статистических html-страницах, то запуск скриптов имеет второстепенное значение.
Доступ к сайту по FTP необходим. Без него вы ничего и не сделаете. FTP доступ предоставляет любой провайдер, на этом этапе все просто и понятно.
Административная панель, на первый взгляд не имеет высокой значимости. Но когда дело доходит до практического обслуживания сайта - качественная админ-панель просто незаменима. С помощью админ панели вы можете не только устанавливать настройки сайта, но и получать статистическую информацию о сайте, например: сколько дискового пространства используется/свободно, каков показатель исходящего траффика за этот месяц (как правило, все провайдеры устанавливают лимит по исходящему траффику). Если в тарифном плане указано "неограниченно" - не верьте, скорее всего это не очень хороший хостер, который всеми путями пытается заманить клиентов). С помощью админ панели легко оперировать с настройками сайта и электронной почты: создавать новые почтовые адреса, настраивать переадресацию почты, управлять папками и фалами (устанавливать права доступа к файлам, пароли к директориям).
Оплаченный исходящий траффик имеет большое значение. Если вы не рассчитаете, сколько информации в килобайтах будет отправлено с сайта на компьютеры пользователей, возможно, вам придется доплатить хостинг-провайдеру за превышение лимита по исходящему траффику. Посчитать средний уровень исходящего траффика достаточно несложно. Посчитайте объем средней страницы сайта, включая графические элементы, которые на ней расположены. Помните о том, что при загрузке других страниц, где используется ранее загруженный рисунок, повторно он берется не с вашего сайта, а с кэша компьютера пользователя. теперь спрогнозируйте, сколько страниц в среднем может просмотреть пользователь, и прикиньте среднее число пользователей в сутки. Теперь умножьте объем страницы на число страниц и на число пользователей в сутки. Вы получите приблизительный объем исходящего траффика в сутки. Умножаем число на 30 дней - вы получаете приблизительный объем траффика в месяц.
Если цифра получилась достаточно большой, не расстраивайтесь, ведь это только ваши предположения. Может быть, у вас будет намного меньше посетителей, чем вы думаете, и каждый из них будет посещать меньшее число страниц, причем треть из посетителей сайта отключат в браузере загрузку графики (всего этого я вам не желаю!)
Продолжение следует.
По материалам
Оптимизация соединения с Интернет
Повременная оплата соединения с Интернет горячо любима всеми нерадивыми провайдерами, кривые руки которых не могут как следует отстроить свое хозяйство и обеспечить надлежащую скорость обмена. Клиент получает меньшее количество информации за то же время и, в результате, дольше торчит в Сети. А время – деньги. В самом, что ни на есть, прямом смысле этого слова. Вот если бы оплата шла за каждый скаченный мегабайт… будьте cпокойны – все бы летало как реактивный бомбардировщик с ракетой класса "Буш – Саддам Хусейн", но многие ли провайдеры поддерживают такой тарифный план?
Ладно бы, все злоключения ограничивались одной скоростью (в смысле полным отсутствуем таковой). Так нет же – соединение может быть нестабильным, часто обрываться, а то и не работать совсем – некоторые сайты могут не грузиться, ругаясь на загадочную ошибку "TTL Bug", закачка по ftp может вообще не "фэтэпить"… да разве ж перечислишь все злоключения, терзающие интернетчика!
Конечно, радикальнее всего – сменить провайдера, но это не всегда возможно. В больших городах счет провайдеров идет на десятки, а в провинциях он, монополист окаянный, нередко бывает в единичном экземпляре, что вдвойне хуже: монополисту незачем заботиться о своих клиентах – все равно они никуда не убегут, каким бы скверным качество обслуживания ни было. Да и куда бежать-то?
Впрочем, в клинических случаях стоит задуматься о поиске провайдера в соседнем городе. Как ни парадоксально, но даже с учетом междугородней оплаты за телефон, иногда это выходит в несколько раз дешевле . Правда-правда! Именно так и приходится поступать автору этой статьи.
Менее радикальная мера – настроить параметры TCP/IP-соединения на максимальную производительность, что дает прирост скорости обмена от 30% до 200% и избавляет от большей части разрывов. Остаются лишь фатальные сбои и зависания самого провайдера, побороть которые с клиентской стороны принципиально невозможно.
Существует множество программ, например, , как раз и предназначенных для этой цели.
Одна беда – ни одна из них не работает в полностью автоматическом режиме – все они всего лишь оболочки над системным реестром Windows – так сказать, комфортный инструмент внесения в него изменений. Но легко сказать "вносить"! А как? Множество малопонятных и ничего не говорящих параметров, порой, вообще без каких либо пояснений. Попытки же разобраться во всем "методом тыка" скорее еще больше снизят скорость, чем ее увеличат. Тут без хорошего руководства не обойтись!
Первое, чем мы займемся – попытаемся устранить разрывы TCP-соединений (не путать с разрывами модемных соединений!). Они довольно многочисленны и разнообразны, а причиной их возникновения может быть и провайдер, и один из маршрутизаторов в длинной цепочке передачи пакетов, и сам удаленный сервер, с которым, собственно, и установлено соединение, и… да мало ли еще что!
Начнем с провайдера. Итак, представим себе следующую картину (маслом по дереву): модем не бросает трубку, но все установленные соединения вдруг обрываются и после этого ни к одному серверу подключиться не удается. Положение спасает лишь реконнект – отключение от Интернет и повторный вход вновь. Мало того, что это медленно, к тому же есть риск нарваться на глухую "бизю", если освободившийся телефонный номер мгновенно займет другой клиент (особенно если у провайдера острый недостаток входных номеров). Такие разрывы могут происходить и эпизодически, и по несколько раз в час, а то и в минуту, представляя собой настоящую пытку.
Причина их возникновения, скорее всего, в том, что у провайдера неправильно настроен DHCP-сервер. Тот самый, что выдает пользователям IP-адреса. Как и любой собственник, он выдает их не насовсем, а на некоторое, подчас весьма непродолжительное время. Если клиент (точнее его операционная система) по каким-то там причинам (сеть тормознула, крыша поехала, пакет кто-то прибил) не успеет продлить срок аренды, его IP-адрес будет безжалостно отнят. А когда же, наконец, клиент "проснется" и пошлет петицию DHCP-серверу, тот смилостивится и отпустит с барского плеча еще один IP-адрес, типа: на, пользуйся на здоровье! И вроде бы все ничего, да вот не понимает "народная" Windows 95\98 таких извращений! Она ожидает получения IP-адреса всего лишь один раз – на стадии подключения к провайдеру.
Вернее, получить-то IP- адрес она получает, но вот включить его в таблицу маршрутизации "забывает", и ни один отправляемый пакет не может уйти дальше своего компьютера. Приходится, взяв инициативу в свои руки, исправлять положение самостоятельно.
Прежде необходимо в сеансе MS-DOS запустить утилиту ipconfig (входит в штатную поставку Windows) и посмотреть какой у нас IP-адрес. Если он выглядит как "0.0.0.0" – значит, DHCP-сервер флиртует с операционной системой (в смысле – висит глухо). Если же IP равен "127.0.0.1" – сети напрочь нет и тут что-то серьезное. А вот любое другое значение указывает на верный IP-адрес, который необходимо добавить в голову таблицы маршрутизации, передав его утилите route из штатной поставки Windows следующим образом: "route.exe ADD 0.0.0.0 MASK 0.0.0.0 Ваш IP METRIC 1". Попробуйте установить соединение с каким-нибудь сервером, – теперь все должно заработать.
Работает? Вот и славненько! Однако восстановить соединение без реконнекта – это только полдела. Хорошо бы устранить и причину этих разрывов – ведь не все же сервера поддерживают докачку, а частые разрывы создают большие проблемы.
В идеальном случае следовало бы взять провайдера за ухо и с помощь дяди прокурора ткнуть носом в DCHP-сервер, объясняя ему, что клиент не должен оплачивать некомпетентность инженерного персонала поставщика сетевых услуг за свой счет. Да только в нашей стране такой прием вряд ли возымеет действие… Приходится выкручиваться самостоятельно, но на клиентской стороне очень мало, что можно сделать, да и то, только программистам. Единственное доступное "простым смертным" решение – перейти на Windows 2000 – с этой проблемой она справляется на раз!
Второй по счету источник неприятностей – эта пресловутая ошибка "TTL bug", приводящая к невозможности установки соединения. Дело в том, что во избежание засорения сети "Летучими Голландцами", то есть, попросту говоря, зацикленными пакетами, каждый из них имеет ограниченный срок существования, указанный в заголовке и измеряемый количеством промежуточных узлов, которые может посетить пакет.
Если пакет не будет доставлен за это время, он "прибивается" очередным маршрутизатором c посылкой отправителю соответствующего "похоронного" уведомления.
Чем больше транзитных узлов расположено между отправителем и получателем, тем дольше пакеты добираются из одного конца в другой. К счастью, время жизни пакета (аббревиатура TTL так и расшифровывается T ime T o L ive – время жизни) очень легко изменить: запустите Редактор Реестра, предварительно зарезервировав сам реестр, и откройте ветвь HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ DefaultTTL для ОС Windows NT\2000 и HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ VxD \ MSTCP \ DefaultTTL для Windows 9x, – она-то и управляет сроком жизни пакетов. По умолчанию он равен 32 узлам, но, как показывает практика, в некоторых случаях этого явно недостаточно и стоит увеличить его, по крайней мере, вдвое. (Можно и больше – но от этого лучше не станет, хотя и хуже – тоже). После внесения изменений в реестр следует перезагрузиться, заново войти в сеть и проверить, возымело ли это какое-то действие.
Возымело? Так... Cоединение с ftp-сервером установить удается, но вот закачка не работает, хоть убей: сколько ни жди, а индикатор прогресса издевательски остается на нуле процентов. Абыдно, понимашь! Что ж, будем лечить! Попробуйте для начала включить опцию с интригующим названием Распознавание Черной Дыры – "Black Hole Detect ".
Зачем она нужна? А вот зачем – хитрая Windows, стремясь увеличить скорость передачи данных, пытается вычислить максимальный размер пакета, который бы обрабатывался пересылающими его маршрутизаторами без разрезания. Разрезание (или, говоря профессиональным языком, фрагментация ) ощутимо снижает скорость соединения, особенно если пакет дробится на две неравные половины. Например, пусть компьютер клиента пытается передать пакет размером в 576 байт, но один из маршрутизаторов в цепочке "умеет считать" только до 512, и разрезает пакет на два, причем во второй попадает "хвостик" из 64 байт, плюс… заголовок, занимающий от 40 и более байт.
В итоге – КПД второго пакета составит всего лишь 50%, что очень нехорошо!
Если Windows видит, что избежать фрагментации не удастся, она уменьшает размер пакета так, чтобы он без проблем прошел сквозь все маршрутизаторы одним куском. Но не проще было бы сразу задать минимальный размер? Нет, и вот почему: чем меньше пакет, тем выше накладные расходы на его пересылку (заголовок тоже ведь занимает место) и тем больше пакетов требуется переслать для передачи того же объема информации.
Умение Windows подбирать максимальный размер нефрагментируемого пакета всем хорошо известно, да вот беда – не всегда это работает. Некоторые, не слишком демократичные маршрутизаторы, получив слишком длинный (по их мнению) пакет с пометкой "не фрагментировать", прибивают его на месте безо всяких уведомлений! Windows же, не подозревая, что посланный ею пакет погиб, ждет отклика от сервера. Долго ждет… А затем, так и не дождавшись, вновь посылает тот же самый пакет. И все повторяется! Вот этот-то недемократичный маршрутизатор и называется "Черной дырой"!
Включение опции "Black Hole Detect" активирует хитроумный алгоритм распознания "Черных Дыр" для обхода их стороной. Но за все приходится платить, и такое детектирование несколько снижает общую производительность. Несильно – но все ж таки! Поэтому прибегать к нему следует только в крайних случаях, когда действительно что-то не работает: соединение есть, а трансфер (передача данных) на нуле.
Запустите "Редактор Реестра" и откройте ветвь HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ VxD \ MSTCP для Windows 95\98 и HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters для Windows NT\2000. Найдите или при необходимости создайте двоичный параметр PMTUBlackHoleDetect для Windows 95\98 и EnablePMTUBHDetect для Windows NT\2000. Теперь присвойте ему значение "1" и перезагрузитесь.
Что? Все равно не работает? Хм… Боги, боги, зачем вы так несправедливы?! Ничего не остается, как расстаться с надеждой пересылки пакетов максимального размера и перейти на размер, обязательный (ну, формально обязательный) для всех маршрутизаторов – 576 байт.
Для этого в той же самой ветке реестра найдите (создайте) двоичный параметр PMTUDiscovery для Windows 95\98, а для Windows NT\2000 – EnablePMTUDiscovery , и присвойте ему значение "0". Перезагрузитесь. Ну, должно же это, наконец, заработать!
Кстати, с типом двух этих ключей творится что-то непонятное. Документация от Microsoft утверждает, что он (тип, в смысле) должен представлять собой двойное слово, то бишь, по-английски DWORD. Однако у автора под Windows 2000 закачка по ftp начинает работать только после создания указанных ключей типа одиночного слова (WORD), а DWORD-ключи операционная система упорно игнорирует. Мистика какая-то…
Теперь поговорим об оптимизации соединения. Оптимизация – дело непростое. Это не то что: работает система или нет. Работать-то она работает, вот только как ? Тривиальным измерением скорости скачиваемого файла ничего выяснить не удастся. График скорости только в исключительных случаях (и на хороших каналах) представляется прямой линией. Гораздо чаще он напоминает трассу Урюпинск – Ханты-Мансийск: сплошные бугры, колдобины, ямы… словом, крайне испещренная местность. Говорить о средней скорости можно только в переносном смысле, тем паче, что она может сильно варьироваться в зависимости от времени суток, сервера, с которым установлено соединение, количества осадков, выпавших в Африке, да мало ли еще от чего!
До начала экспериментов потребуется собрать статистику работы сети за некоторое время, скажем, за неделю. В этом поможет программа Net Medic () или любая другая, аналогичная ей. Затем, после внесения изменений в настройки системы, собирается другая статистика, опять-таки на протяжении семи-десяти дней, и сравнивается с предыдущей: изменилось ли что и если да, то в какую сторону?
Дело это, конечно, медленное, но иного способа тонкой настройки нет. Необходимо убедиться в увеличении скорости обмена со всеми серверами и во все времена суток, то есть, найти компромиссный оптимум. Не все, что хорошо для одного случая, так же хорошо подходит для другого.
Взять ту же фрагментацию уже рассмотренную выше. Автоматическое определение подходящего размера пакета не всегда увеличивает скорость соединения, нередко оно ее уменьшает, подчас весьма значительно, – автоматическое определение занимает какое-то время, увеличивая накладные расходы и снижая КПД. Имеет смысл попробовать найти оптимальное значение вручную.
Первым делом необходимо указать Windows, что требуется использовать не максимально возможный, а заранее оговоренный размер пакета. Для этого установите значение ключа PMTUDiscovery (EnablePMTUDiscovery) в ноль. Затем задайте желаемый размер пакета. По умолчанию он равен 576 байтам – это значение по стандарту должны поддерживать все маршрутизаторы, – да только кто эти стандарты соблюдает? Вот и встречаются узлы, обрабатывающие пакеты размером не более 512, 522, 556,… байт. В принципе, можно поставить 500 и не мучаться проблемой выбора, но так неинтересно. Разве не заманчиво методичным подбором байтов оптимизировать соединение до конца?
Размер пакетов для Windows 95\98 задается ключом MaxMTU , находящимся в той же самой ветке реестра, что и предыдущие ключи. С Windows NT\2000 посложнее: чтобы выяснить местоположение ключа MTU необходимо определить идентификатор используемого адаптера. Перечень всех адаптеров компьютера содержится в ключе Adapters ветки HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters. Как правило, большинство персональных компьютеров обходятся лишь одним адаптером – контроллером удаленного доступа (нет, это не плата расширения, это драйвер такой) и буридановой проблемы выбора нужного идентификатора не стоит. Идентификатор же, – это такое длинное малопонятное число, например: 20692835-7194-467A-A2DC-0FAE23F0A70D.
Запоминаем (записываем) его и открываем ветку HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ ИдентификаторАдаптера \ Parameters \ Tcpip (В Windows 2000 – HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Parameters \ Tcpip \ Interfaces \ ИдентификаторАдаптера )
Среди прочего хлама здесь должен находиться только что запомненный идентификатор адаптера, а в нем – ключ MTU , содержащий в себе максимальный размер пакета в байтах. Если такого ключа нет, его необходимо создать. Тип ключа MTU в обоих случаях соответствует двойному слову (DWORD).
Второй бастион оптимизации – размер TCP-окна. Чем "шире" окно, тем выше производительность, но, в то же время, больше издержки на повторные пересылки: случись какой сбой, – не до конца заполненное окно очистится и придется его "набивать" с самого начала. К тому же, баловство с неумеренно широкими окнами часто приводит к образованию заторов в сети: промежуточные узлы не успевают обрабатывать сыплющийся на них поток пакетов и начинают жутко тормозить. Причем, не только у виновника несчастья, но и у других ни в чем не повинных пользователей.
Ширина TCP-окна должна быть кратна размеру пакета за вычетом длины заголовка и превосходить его по крайне мере в четыре-шесть раз. В некоторых случаях наивысшая производительность достигается при ширине окна в 10х-12х (где х – размер пакета без заголовка, называемый так же "квиком"), а то и больше. Некоторые отчаянные головы пробуют даже бoльшие значения и утверждают, что все работает "на ура!", но у автора такие значения не показывают чудес производительности, поэтому подтвердить сказанное он не берется. Размер заголовка непостоянен и варьируется от 40 до 60 байт, – не забывайте об этом при поиске оптимальной ширины окна!
Для изменения размеров окна откройте ветвь реестра HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ VxD \ MSTCP для Windows 95\98 и HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters для Windows NT\2000. Найдите или при необходимости создайте двоичный параметр (двойное слово, DWORD) DefaultRcvWindow для Windows 95\98 и TcpWindowSize для Windows NT\2000. Присвойте ему желаемое значение (например "3680", если размер пакета, заданный ключом MTU, равен 500 байт: (500 – 40) * 8 = 3/600) и перезагрузитесь.
Оцените, как изменилась скорость соединения. Если она возросла, увеличьте ширину окна еще на один квик (не байт!), если уменьшилась, – сузьте окно, а если осталась без изменений, – расширьте окно на пару квиков. Так, в конце концов, будет найдено оптимальное значение. Интернет-гуру утверждают, что оптимум ширины окна зависит от загруженности провайдера и сильно колеблется в течение суток. При максимальной загруженности в "час пик" окно лучше прикрывать, оставляя лишь узкую щель (3х-4х), а ночью, когда все нормальные юзеры давно баиньки, и канал полностью свободен – широко распахивать обе створки (10x и выше). Никаких суточных вариаций у своих провайдеров автор не замечал, но готов поверить, что в некоторых случаях они могут иметь место, и гуру не врут.
Помимо вышеупомянутых опций реестр Windows содержит множество других значений, относящихся к TCP/IP, но рассказывать о каждом из них было бы слишком утомительно, да и нецелесообразно, – для этого пришлось бы написать отдельную книгу, страниц эдак на пятьсот.
Что такое ping и для чего он нужен?
Что такое ping и для чего он нужен?
Ping – эта такая утилита для проверки работоспособности сети. Принцип ее работы в общих чертах заключается в посылке узлу эхо-запроса и ожидании от него эхо-ответа. Каждый узел сети Интернет должен уметь принимать эхо-запросы и возвращать эхо-ответы, разумеется, если он подсоединен к сети и работает.
Отсутствие эхо-ответа от сервера обозначает: либо сервер "висит", либо имеется неустранимое повреждение сети на участке клиент-сервер, обойти в "обход", которое невозможно.
Это свойство делает ping удобным инструментом проверки работоспособности узла и целостности соединения. Впрочем, отрицательный результат работы ping не всегда свидетельствует о наличии какой-либо проблемы (см. ).
Где я могу достать ping?
В штатный комплект поставки Windows входит консольная версия утилиты ping, вполне удовлетворяющая запросы непритязательного пользователя. Ping в графическом исполнении можно обнаружить в составе практически любого пакета сетевых утилит (NetInfo, CyberKit и т.д.).
Комплект разработчика Windows-приложений (SDK), входящий, в частности, в поставку компилятора Microsoft Visual Studio, содержит исходные тексты программы ping с достаточно подробными комментариями, что легко позволяет адаптировать ее к собственным нуждам и перекроить под собственный вкус.
Каково назначение ключей утилиты ping?
Несмотря на свою простоту, утилита ping из штатной поставки Windows принимает достаточно большое количество ключей командной строки, более чем поверхностно описанных в прилагаемой документации. Неудивительно, что многие возможности ping ускользают не только от начинающих, но и от умудренных жизнью пользователей!
Ключ -w используется для задания интервала ожидания эхо-ответа в миллисекундах (по умолчанию 20 секунд). Если отклик от сервера не будет получен в течение указанного времени, утилита ping сообщит "Превышен интервал ожидания для запроса", намекая на неработоспособность сервера или повреждение сети. На загруженных каналах медленных провайдеров ответ может прийти и через 30, и даже через 60 секунд, поэтому интервал ожидания приходится увеличивать, например, так:C:\>ping www.nastyhost.fu
Обмен пакетами с www.nastyhost.fu [195.2.70.38] по 32 байт:
Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса.
Статистика Ping для 195.2.70.38: Пакетов: отправлено = 4, получено = 0, потеряно = 4 (100% потерь), Приблизительное время передачи и приема: наименьшее = 0мс, наибольшее = 0мс, среднее = 0мс
C:\>ping www.nastyhost.fu –w 60000
Обмен пакетами с www.nastyhost.fu [195.2.70.38] по 32 байт:
Ответ от 195.2.70.38: число байт=32 время=34100мс TTL=117 Ответ от 195.2.70.38: число байт=32 время=38310мс TTL=117 Ответ от 195.2.70.38: число байт=32 время=39001мс TTL=117 Ответ от 195.2.70.38: число байт=32 время=10220мс TTL=117
Статистика Ping для 195.2.70.38: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь), Приблизительное время передачи и приема: наименьшее = 10220мс, наибольшее = 39001мс, среднее = 30408мс
Ключ -n задает количество отправляемых эхо-запросов (по умолчанию 4). Увеличение количества запросов бывает необходимо для контроля надежности и устойчивости работы сервера. Чем выше качество канала, тем меньше разброс по времени ответов.
Ключ –t заставляет утилиту ping посылать запросы в бесконечном цикле до ее прерывания нажатием комбинации клавиш . Внимание: не прерывает процесс, а выводит текущую статистику! Этот ключ очень удобен для ожидания момента пробуждения некстати зависшего сервера: запустил "ping www.hover-server.fu –t " и жди появления сообщения "Host Alive" или что-то в этом роде.
Ключ –l задает размер дейтаграммы без учета длины заголовка (28 байт), посылаемой в эхо-запросе. Допустимыми являются значения от 0 до 65.500, включительно. По умолчанию размер дейтаграммы составляет 32 байта. Манипулируя этим значением, можно выяснить зависимость: скорость доставки– размер дейтаграммы. Если размер дейтаграммы превысит некоторую критическую величину (определяемую каждым промежуточным узлом самостоятельно), дейтаграмма разрезается на несколько пакетов подходящего размера, каждый из которых добирается до конечной точки маршрута самостоятельно, а на узле назначения они вновь собираются в исходную дейтаграмму.
Ключ –f устанавливает на дейтаграмме специальную пометку, запрещающую ее разрезание (то есть, говоря техническим языком, фрагментацию ). Если хотя бы один из промежуточных узлов не может обрабатывать пакеты таких размеров, он прибивает дейтаграмму и посылает отправителю уведомление, объясняя причину смерти тем, что требуется фрагментация, но установлена пометка, ее запрещающая. Впрочем, некоторые узлы не посылают такого уведомления, молчаливо отправляя пакет на тот свет или же разрезают дейтаграмму вопреки запрету (впрочем, последнее встречается редко). Вкупе с ключом –l, задающим длину дейтаграммы, запрет фрагментации ключом –f, позволяет определить максимальный размер нефрагментируемых пакетов.
Ключ –i задает время жизни (сокращенно TTL – T ime T o L ive) пакета посылаемых дейтаграмм, измеряемое количеством узлов, которые может посетить пакет (по умолчанию 128). Каждый промежуточный узел уменьшает значение TTL на единицу и, когда оно достигает нуля, пакет уничтожается с посылкой отправителю соответствующего уведомления.
Это обстоятельство позволяет отслеживать маршрут путешествия пакетов, используя ping вместо утилиты tracert, что будет нелишним в тех ситуациях, когда tracert нет под рукой.
Для контроля выясним маршрут к некоторому узлу с помощью tracert, входящей в штатную поставку Windows:
Трассировка маршрута к aport.ru [194.67.18.8] с максимальным числом прыжков 30: C:\>tracert www.aport.ru 1 150 ms 130 ms 131 ms nas.itech.ru [195.151.210.36] 2 140 ms 141 ms 150 ms ns.itech.ru [195.151.210.33] 3 221 ms 180 ms 220 ms gw.itech.ru [195.151.210.29] 4 310 ms 401 ms 330 ms 195.151.200.90 5 300 ms 341 ms 270 ms krd-gw.mtt.ru [195.151.52.41]
А теперь вызовем ping, задав значение TTL равное одному. Первый же маршрутизатор, уменьшив его на единицу, обнаружит, что оно равно нулю, и пошлет нам соответствующее уведомление. Итак…
C:\>ping www.aport.ru -i 1
Обмен пакетами с aport.ru [194.67.18.8] по 32 байт: Ответ от 195.151.210.36: Превышен срок жизни (TTL) при передаче пакета.
И в самом деле, получен ответ от узла 195.151.210.36, – первого маршрутизатора в цепочке, как это видно по протоколу работы tracert.
Теперь увеличим значение TTL до двух и повторим процедуру: C:\>ping www.aport.ru –i 2 Обмен пакетами с aport.ru [194.67.18.8] по 32 байт: Ответ от 195.151.210.33: Превышен срок жизни (TTL) при передаче пакета.
Действительно, теперь найден второй маршрутизатор в цепочке! Увеличиваем значение TTL еще на единицу…
C:\>ping www.aport.ru –i 3 Обмен пакетами с aport.ru [194.67.18.8] по 32 байт: Ответ от 195.151.210.29: Превышен срок жизни (TTL) при передаче пакета.
В самом деле, этот прием работает! Правда, уж очень утомительно перебирать пакеты вручную. Но работу легко оптимизировать командным файлом следующего содержания: FOR /L (%%I) IN (1,1,30) DO ping %1 –i %%I, вызываемым с аргументом – доменным именем или IP-адресом трассируемого узла, и он самостоятельно начнет перебирать все значения TTL от 1 до 30.
Ключ –v задает значения поля типа службы (TOS – T ype O f S ervice).
Тип сервиса с помощью некоторых абстрактных параметров указывает предпочтительный вид обслуживания – минимальная задержка, максимальная пропускная способность, максимальная надежность, минимальные издержки на пересылку или обычная, неприоритетная, пересылка. Предпочтение может быть отдано только одному типу приоритета, – нельзя одновременно требовать молниеносной скорости пересылки пакета вкупе с соломоновой надежностью его доставки. Выбирайте уж что-то одно!
Тип сервиса задается одним из следующих десятичных чисел (См. таблицу 1). Как легко увидеть, каждому значению соответствует свой бит:
Таблица 1. Допустимые типы сервиса в поле TOS
Код сервиса
Пояснение
2
минимальные издержки на пересылку
4
максимальная надежность доставки
8
максимальная пропускная способность
16
минимальная задержка
Не все маршрутизаторы анализируют поле TOS, многие из них его напрочь игнорируют, что и подтверждает следующий эксперимент:
C:\>ping www.itech.ru –v 0x2 Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт: Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254
C:\>ping www.itech.ru –v 0x4 –n 1 Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт: Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254
C:\>ping www.itech.ru –v 0x8 –n 1 Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт: Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254
C:\>ping www.itech.ru –v 16 Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт: Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254
Независимо от типа сервиса, время отклика всегда составляло 130 мс, и быстроты пересылки при TOS, равном 16, не наблюдалось. А вот пример сети, поддерживающей TOS:
C:\>ping www.krintel.ru –v 2 Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт: Ответ от 195.161.42.218: число байт=32 время=2143мс TTL=127
C:\>ping www.krintel.ru –w 10000 –v 4 Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт: Ответ от 195.161.42.218: число байт=32 время=1763мс TTL=127
C:\>ping www.krintel.ru –v 8 Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт: Превышен интервал ожидания для запроса. Ответ от 195.161.42.218: число байт=32 время=1332мс TTL=127
C:\>ping www.krintel.ru –v 16 Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт: Ответ от 195.161.42.218: число байт=32 время=1092мс TTL=127
Наибольшая задержка наблюдалась при TOS, равном 2 (минимальные издержки на пересылку), а наименьшая – при TOS, равном 16 (минимальная задержка), и чуть менее быстрыми оказались посылки с TOS, равном 8.
Какую пользу из этого можно извлечь? А вот какую – прикладные программы могут манипулировать полем TOS по своему усмотрению, выбирая значение, соответствующее специфике своей работы. Например, telnet-клиенты, ICQ и чаты очень чувствительны к задержкам, ftp клиентам задержки не страшны, – была бы хорошей пропускная способность, и т.д. Разумеется, если промежуточные узлы игнорируют содержимое поля TOS, никакого выигрыша не получается и высокоприоритетные пакеты (например, от ICQ) обрабатываются с той же скоростью, что и пакеты, скажем, от почтового сервера, не критичные к скорости доставки. Использование ping с ключом –v позволяет выяснить, поддерживается ли TOS на данном маршруте и, если имеется несколько альтернативных маршрутов, выбрать из них наиболее подходящий.
Ключ –r заставляет промежуточные узлы записывать в заголовок отправляемых эхо-запросов свои IP-адреса. Не все маршртузаторы поддерживают такую возможность, но очень многие. Ping, вызванная с ключом –r, позволяет отслеживать маршрут пересылки пакетов и могла бы полностью заменить собой утилиту tracert, если бы не ограничения, налагаемые размером IP-заголовка на максимальное количество запоминаемых адресов – их умещается всего девять, и более длинные пути отслеживать этим способом невозможно.
Ключ –s похож на ключ –r, но заставляет промежуточные узлы вносить в заголовок не свои адреса, а временную метку (или "штамп времени" в плохом русском переводе).
По общепринятым соглашениям временная метка представляет собой четырехбайтовое поле, содержащее число миллисекунд, истекших с начала полуночи всеобщего скоординированного времени, однако на практике это соглашение мало кто соблюдает, и многие маршрутизаторы заполняют это поле всякой отсебятиной, интерпретируемой только одним им известным способом.
На количество запоминаемых временных меток наложены те же самые ограничения, что и на количество запоминаемых IP-адресов, за одним небольшим исключением – временная метка, вставленная неизвестно каким маршрутизатором, бесполезна (разве что маршрут путешествия пакетов заведомо не меняется с течением времени и может быть предварительно выявлен трассировкой). По умолчанию утилита ping автоматически запоминает IP-адреса узлов при записи временных меток, таких пар в заголовок пакета может вместиться только четыре.
Временная метка выгодно отличается тем, что позволяет вычислять точную скорость пересылки пакета, поскольку содержит в себе не общий интервал задержки (от пересылки в оба конца), а время пересылки на заданный узел. По непонятным причинам штатная (да и большинство остальных) реализация утилиты ping не позволяет задавать запись временной метки для произвольного узла в цепочке (хотя, в принципе, это возможно), чем полностью обесценивает ключ –s - ну право же, редкий сервер отделен от клиента менее чем четырьмя промежуточными узлами!
Пример вызова ping с ключом –s приведен ниже. Обратите внимание на временную метку: похоже, она представляет собой ни что иное, как случайное число.
C:\>ping www.itech.ru –s 2
Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:
Ответ от 195.151.210.34: число байт=32 время=151мс TTL=254 Штамп времени: 195.151.210.36 : 3658968578 –>
195.151.210.34 : 2275040770 Ответ от 195.151.210.34: число байт=32 время=140мс TTL=254 Штамп времени: 195.151.210.36 : 3357240834 –>
195.151.210.34 : 1956535810 Ответ от 195.151.210.34: число байт=32 время=141мс TTL=254 Штамп времени: 195.151.210.36 : 3122621954 –>
195.151.210.34 : 1738694146 Ответ от 195.151.210.34: число байт=32 время=140мс TTL=254 Штамп времени: 195.151.210.36 : 2888003074 –>
195.151.210.34 : 1504075266
Статистика Ping для 195.151.210.34: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь), Приблизительное время передачи и приема: наименьшее = 140мс, наибольшее = 151мс, среднее = 143мс
Ключ -j задает список узлов для свободной маршрутизации от клиента и аналогичен одноименному ключу утилиты tracert.
Ключ -k похож на ключ -j, но задает список узлов для жесткой маршрутизации, т.е. пакет передается из рук в руки строго по перечню перечисленных узлов, и ни один их них не может позволить себе воспользоваться услугами "собственного" маршрутизатора для передачи пакета следующему узлу. Если узел не может передать пакет напрямую, он уничтожает его и посылает отправителю соответствующее уведомление: дескать, такая маршрутизация от источника невозможна. Существует очень мало причин, требующих применения свободной, а тем более жесткой маршрутизации. Все это пережиток старых времен, современные сети самостоятельно решают проблемы маршрутизации пакетов, и пытаться помочь им, право, не стоит – они и без того справляются со своей задачей слишком хорошо.
Ключ -a задает определение имен узлов по их IP-адресам. Так, во всяком случае, сказано в документации. Смысл этого неясен: такое определение и без того происходит автоматически независимо от наличия (отсутствия) ключа "-a".
Почему ping не проходит, а сайт сервера нормально работает и открывается?
Бывает, ping к некоторому серверу упорно не проходит, какая бы задержка ни была выбрана, но все сервисы (будь то почта или web) работают нормально. Почему? Все объясняется очень просто – администратор сервера защитил его межсетевым экраном, блокирующим либо эхо-запросы, либо эхо-отклики, либо и те, и другие вместе. А может запрет эхо-откликов наложен на сам узел. Все эти меры предосторожности объясняются тем, что эхо-посылки имеют более высокий приоритет по сравнению с обычными пакетами (иначе бы эха век не дождаться), и злоумышленники могут перегрузить сервер, направив на него штурм эхо-запросов. "Упасть", правда, сервер не упадет, но вот общая производительность несколько снизится. Хуже, если направить шторм эхо-запросов от имени жертвы, выходящей в Интернет по модему: на нее обрушится сокрушительная лавина эхо-ответов от быстродействующего сервера (хорошо, если одного), плотно забивающая канал…
Вот поэтому-то для заблаговременного предотвращения возможности атаки, эхо-посылки и запрещаются, делая работу ping невозможной, но все службы сервера продолжают, как ни в чем не бывало, работать!
1 работает только под Windows 2000 или выше
2 К слову сказать, далеко не все приложения устанавливают поле TOS в соответствующее значение, оставляя его по умолчанию.
Учимся регулярно выражаться
Чтение и написание регулярных выражений
Проговаривание вслух и запись правил - основная проблема, возникающая при освоении техники разбора текста с помощью регулярных выражений. При отсутствии опыта трудно сформулировать словесную запись правил. Тем не менее - это наиболее эффективный путь составления регулярных выражений.
Основным правилом при составлении регулярных выражений является их запись в развёрнутом виде на листе бумаги или на экране. Так легче всего определить, насколько верно будет обработан текст. Другое правило заключается в составлении выражения от общего к частному. При его соблюдении значительно сокращается время написания выражения и количество ошибок.
Сформулируем условия для успешного составления регулярного выражения
У выражения должна быть «литературная» форма.
Словесное описание должно быть логичным.
Составление выражения должно идти:
от простого к сложному.
от общего к частному.
Несмотря на трудоёмкость подобной записи, она повышает скорость разработки и отладки правил разбора текстов и эффективность их применения.
Финальное выражение
#<(p|li)\s+[^>]*?class\s*=\s*(['"])content\2[^>]*>((?:(?!\1>).)*)\1>#is
Как видите, эта задача решается достаточно просто. При написании статьи я её выбрал потому, что на форумах очень часто задают вопрос «как выбрать содержимое определённого тега» и «как разобрать HTML разметку». Решение перед вами.
Модификаторы
Информацию по всем модификаторам поиска я советую смотреть в специальной справочной литературе, например, в документации по PHP и Perl. Здесь же мы используем i - поиск без учёта регистра и s - режим совпадения символа «.» с переводами строк.
Ограничители
Практически во всех языках, где имеется поддержка регулярных выражений, возможно выбрать ограничители выражения. Самые распространённые это: / / и # # . В принципе, можно использовать практически любые пары символов, если это поддерживается интерпретатором. При выборе ограничителей лучше исходить из того, какие символы присутствуют в регулярном выражении. Выбирать лучше те, которых в выражении нет. В противном случае придётся экранировать эти символы, что сделает выражение более запутанным. В нашем случае стандартные / / не подходят, поскольку они есть внутри регулярного выражения. Поэтому я предлагаю использовать ограничители # # .
Полезные ссылки
- большое количество информации по регам, их реализации в разных языках программирования.
- отличный плагин для работы с регами в .
- мощная программа для визуализации регулярных выражений с поддержкой огромного количества диалектов.
Последовательность решения
Составим регулярное выражение для выделения всех тегов.
Дополним его для выделения только парных тегов.
Дополним его для выделения только заданных тегов.
Напишем выражение для поиска пар 'имя_атрибута = «значение»'.
Дополним основное выражение для выделения заданных тегов с определёнными атрибутами.
Добавим модификаторы поиска.
Обычно начинают одновременно производить все 6 шагов что вызывает серьезные проблемы при отладке. Я предлагаю действовать постепенно. Шаг за шагом.
Приведу решение сразу:
#<(p|li)\s+[^>]*?class\s*=\s*(['"])content\2[^>]*>((?:(?!\1>).)*)\1>#is
Согласитесь, выглядит оно почище «китайской грамоты». Тем не менее, следуя описанию, Вы увидите, что всё не так уж и сложно.
Итак, начнём:
Выделение всех тегов
Запишем правила разбора по-русски:
Найдём подстроку '<'
Начнём захватывать символы в последовательность
Захватим одну или более букву алфавита
Завершим захватывать совпадения
Захватим 0 или более символов, не совпадающих с набором символов '>'
Захватим подстроку '>'
Начнём захватывать символы в последовательность
Захватим 0 или более символов, не совпадающих с набором символов '>'
Завершим захватывать совпадения
Теперь, когда задача точно описана, можно приступить к записи её в виде регулярного выражения:
<
(
\w+
)
[^>]*
>
(
[^<]*
)
У нас получилось следующее выражение:
<(\w+)[^>]*>([^<]*)
Оно имеет 2 недостатка:
захватывает все теги, а не только парные.
некорректно отрабатывает вложенные теги.
Выделение парных тегов
Запишем правила разбора формальным языком:
Найдём подстроку '<'
Начнём захватывать символы в последовательность
Захватим одну или более букву алфавита
Завершим захватывать совпадения
Захватим 0 или более символов, не совпадающих с набором символов '>'
Захватим подстроку '>'
Начнём захватывать символы в последовательность
Начнём захватывать символы в несохраняющую последовательность
Начнём проверку на отсутствие удачного совпадения справа последовательности из
''
совпадение найденное на шагах 2-3 (ссылка на последовательность 1)
'>'
Завершим проверку.
Захватим любой символ
Завершим захватывать совпадения.
Произведём захват 0 или более раз
Завершим захватывать совпадения.
Захватим подстроку ''
Захватим совпадение найденное на шагах 2-3 (ссылка на последовательность 1)
Захватим подстроку '>'
Теперь, когда задача точно описана, можно приступить к записи её в виде регулярного выражения:
<
(
\w+
)
[^>]*
>
(
(?:
(?!
\1
>
)
.
)
*
)
\1
>
Итак, у нас получилось следующее выражение:
<(\w+)[^>]*>((?:(?!\1>).)*))\1>
Оно захватывает любые парные теги вместе с содержимым.
Выделение требуемых тегов
Используя регулярное выражение, полученное на предыдущем шаге, мы можем выделить из текста сразу несколько типов тегов, используя конструкцию «альтернативная последовательность при отсутствии совпадения слева». В описании используем термин «альтернативная последовательность».
Добавим выделение из текста всего содержимого абзацев и пунктов списка:
Найдём подстроку '<'
Начнём захватывать символы в последовательность
подстроку 'p'
Добавим альтернативную последовательность
подстроку 'li'
Завершим захватывать совпадения
Произведём проверку на удачное совпадение справа набора символов '\s>'
Захватим 0 или более символов, не совпадающих с набором символов '>'
Захватим подстроку '>'
Начнём захватывать символы в последовательность
Начнём захватывать символы в несохраняющую последовательность
Начнём проверку на отсутствие удачного совпадения справа последовательности из
''
совпадение найденное на шагах 2-3 (ссылка на последовательность 1)
'>'
Завершим проверку
Захватим любой символ
Завершим захватывать совпадения
Захватим последовательность 0 или более раз
Завершим захватывать совпадения
Захватим подстроку ''
Захватим совпадение найденное на шагах 2-3 (ссылка на последовательность 1)
Захватим подстроку '>'
Пункты 7 и 8 были добавлены для того, чтобы выражение не захватывало теги, начало которых совпадает с выделяемыми тегами. Например, чтобы при поиске тега не были захвачены теги .
Переводим её в операторы регулярного выражения:
<
(
p
|
li
)
(?=[\s>])
[^>]*
>
(
(?:
(?!
\1
>
)
.
)
*
)
\1
>
Новое регулярное выражение:
<(p|li)(?=[\s>])[^>\w]*>((?:(?!\1>).)*))\1>
Теперь в тексте будут выделены только теги p и li и всё их содержимое.
Добавим в основное выражение проверку на определённые атрибуты
Опишем задачу формальным языком:
Найдём подстроку '<'
Начнём захватывать символы в последовательность
Захватим подстроку 'p'
Добавим альтернативную последовательность
Захватим подстроку 'li'
Завершим захватывать совпадения
Захватим 1 или больше символов \s
Захватим минимальные 0 или больше символов, не совпадающих с набором символов '>'
Добавим регулярное выражение с шага 4: class\s*=\s*(['»])content\1
Захватим 0 или более символов, не совпадающих с набором символов '>'
Захватим подстроку '>'
Начнём захватывать символы в последовательность
Начнём захватывать символы в несохраняющую последовательность
Начнём проверку на отсутствие удачного совпадения справа последовательности из
''
совпадение, найденное на шагах 2-3 (ссылка на последовательность 1)
'>'
Завершим проверку
Захватим любой символ
Завершим захватывать совпадения
Захватим последовательность 0 или более раз
Завершим захватывать совпадения
Захватим подстроку ''
Захватим совпадение, найденное на шагах 2-3 (ссылка на последовательность 1)
Захватим подстроку '>'
Переводим её в операторы регулярного выражения:
<
(
p
|
li
)
\s+
[^>]*?
class\s*=\s*(['»])content\2
[^>]*
>
(
(?:
(?!
\1
>
)
.
)
*
)
\1
>
Результирующее выражение:
<(p|li)\s+[^>]*?class\s*=\s*(['"])content\2[^>]*>((?:(?!\1>).)*)\1>
Словарь операторов
символы
<символ> – печатный символ: буквы, цифры, знаки препинания и т.д.
. – произвольный символ
подстрока – литеральный (такой, в котором нет ) набор символов.
управление совпадением (квантификаторы)
* – ноль или больше последовательных совпадений
+ – одно или больше последовательных совпадений
? – ноль или одно совпадение
*? – не жадные ноль или больше последовательных совпадений
+? – не жадные одно или больше последовательных совпадений
*+ – захватывающие ноль или больше последовательных совпадений
++ – захватывающие одно или больше последовательных совпадений
{n1,n2} – от n1 до n2 последовательных совпадений
{n} – ровно n совпадений
формирование последовательности – совпасть может только вся последовательность
( – начнём захватывать совпадения в последовательность и сохраним её в памяти (сохраняющие скобки)
(?: – начнём захватывать совпадения в последовательность, но не сохраняем её (несохраняющие скобки)
) – завершим захватывать совпадения.
| – альтернативная последовательность при отсутствии совпадения с последовательностью слева
наборы символов – совпадает любой из символов
[ – откроем набор символов
] – закроем набор символов
- – укажем диапазон символов
^ – набор содержит все символы, кроме перечисленных
позиционная проверка
(?= – начнём проверку на наличие совпадения справа
(?! – начнём проверку на отсутствие совпадения справа
(?< = – начнём проверку на наличие совпадения слева
(? – начнём проверку на отсутствие совпадения слева
) – завершим проверку
ссылки на предыдущие совпадения
\0..\9 – порядковый номер последовательности в сохраняющих скобках
Так выглядит перевод конструкций регулярных выражений на «человеческий» язык. В дальнейшем, при разборе примеров, я дам им развернутое описание.
Термины
оператор – символы, используемые в регулярных выражениях; они управляют поиском, но не участвуют в совпадении.
совпадение – один или больше символов и операторов регулярного выражения, которые совпали с проверяемым текстом.
квантификатор – оператор регулярного выражения, определяющий количество экземпляров повторяющегося совпадения.
жадный (другое определение - «максимальный») – захватывает все доступные совпадения, после чего может их возвратить, если потребуется операторам справа. По умолчанию, все квантификаторы - «жадные».
не жадный (другое определение - «минимальный») – захватывает совпадение только в том случае, если нет совпадения справа.
захватывающий – жадный, никогда не возвращает захваченные совпадения.
последовательное совпадение – последовательность одинаковых совпадений.
Требования к выражению
справа от имени атрибута должен быть пробел
слева от значения должен быть пробел или закрывающая тег скобка
значение должно быть заключено в одинарные или двойные кавычки
между знаком равенства, именем атрибута и его значением могут быть пробелы
Опишем задачу формальным языком:
Найдём 1 или больше символов \s
Захватим 1 или больше символов \w
Захватим 0 или больше символов \s
Захватим подстроку '='
Захватим 0 или больше символов \s
Начнём захватывать символы в последовательность
Захватим подстроку из набора '»'
Завершим захватывать совпадения.
Захватим 0 или больше символов, не входящих в набор символов, найденный на шагах 6-7 (ссылка на последовательность 1)
Захватим символ, найденный на шагах 6-7 (ссылка на последовательность 1)
Переводим в операторы регулярного выражения:
\s+
\w+
\s*
=
\s*
(
['»]
)
[^\1]*
\1
Получается следующее регулярное выражение:
\s+\w+\s*=\s*(['"])[^\1]*\1
Модифицируем его, чтобы выражение совпадало только с именем атрибута 'class' и его значением 'content':
\s+class\s*=\s*(['"])content\1
Учимся регулярно выражаться
Илья Лебедев, Debugger.ru
Примечание редакции. Существует много диалектов языка регулярных выражений. Выражения из этой статьи используют синтаксис, принятый в Perl, в том числе недоступные в других диалектах функции. Похожий диалект вне языка Perl известен как "Perl-совместимые регулярные выражения" (PCRE, Perl-Compatible Regular Expressions).
В большинстве текстовых редакторов можно провести поиск по слову, его части и учитывать регистр. Чаще всего, этих возможностей достаточно, поскольку приходится обрабатывать относительно простые тексты - мозг человека сразу оценивает полученное совпадение и принимает решения.
Рано или поздно наступает момент, когда человеческих ресурсов не хватает для обработки всей поступающей информации, или требуется ввести полностью автоматизированную обработку данных, например, для публикации новостей из разных источников на своём сайте. Здесь вступают в работу автоматизированные системы, в которых нашли широкое применение регулярные выражения. Их использование позволяет в десятки раз уменьшить объём кода, необходимого для обработки текстов. При первом знакомстве регулярные выражения вызывают самые различные реакции, но общее в них то, что человека отталкивает сложность понимания смысла этих «высказываний». Данная статья призвана объяснить, как прочитать выражение и понять его смысл.
в HTML разметке содержимое определённых
Выделить в HTML разметке содержимое определённых блоков с установленными атрибутами:
абзац (тег ) с CSS классом content
элемент списка (тег ) с CSS классом content
Абзац 1 Абзац 2
Элемент 1 Элемент 2 Абзац 2
Элемент 2
Библиотека Watir
Библиотека Watir
Для управления браузером библиотека Watir использует протокол OLE. Это накладывает определенные ограничения как на выбор платформы, так и на выбор браузера. Так, на момент написания этих строк Watir работает только под Windows и только с Internet Explorer. Не отчаивайтесь раньше времени если у вас другая система или вы пользуетесь другим браузером! Существуют версии Watir для Firefox и для Safari:
- работает с Firefox под Linux, Windows и Mac;
- работает с Safari под Mac.
В перспективе разработчики планируют объединить все три версии в один проект. Отмечу, что аналоги Watir есть и для других языков программирования:
- версия Watir для Java;
- версия Watir для .Net;
- еще одна версия Watir для .Net.
Очень подробный каталог инструментов, аналогичных Watir можно найти . Почти наверняка вы найдете подходящее решение для вашей платформы и языка программирования. В этой же статье речь пойдет только об оригинальной версии Watir.
Что дальше
В этой статье мы познакомились с библиотекой Watir. Это очень мощный и гибкий инструмент с помощью которого можно автоматизировать тестирование любого web-приложения. За время существования проекта вокруг него сформировалось внушительное сообщество пользователей. На можно найти статьи, обзоры, учебники, FAQ, спецификации и другую полезную информацию по Watir. Заходите и учитесь!
IE Developer Toolbar
Неоценимую помощь в написании тестовых сценариев оказывает IE Developer Toolbar - специальная отладочная панель для Internet Explorer. С ее помощью можно без труда просмотреть атрибуты любого элемента на странице:
Скачать IE Developer Toolbar можно (~ 700 Kb). В качестве альтернативы можно также попробовать другую панель - .
Интерактивная консоль Ruby
Если при написании тестового сценария вы зашли в тупик, например, не можете найти элемент, генерируемый автоматически при помощи JavaScript, попробуйте irb - интерактивную консоль Ruby. Это незаменимый и универсальный инструмент Ruby-разработчика на все случаи жизни. Продемонстрируем методику использования irb на простом примере:
irb(main):001:0> require 'watir'
=> true
irb(main):002:0> ie = Watir::IE.new
=> #
irb(main):003:0> ie.goto "http://www.google.ru/"
=> 1.015
irb(main):004:0> ie.show_all_objects
-----------Objects in page ------------- ... hidden name=hl id= value=ru alt= src= text name=q id= value= alt= src= submit name=btnG id= value=Поиск в Google alt= src= submit name=btnI id= value=Мне повезёт! alt= src= radio name=lr id=all value= alt= src= radio name=lr id=il value=lang_ru alt= src= hidden name=aq id= value=f alt= src= hidden name=oq id= value= alt= src= ... => nil
irb(main):005:0> ie.button(:name, "btnG").flash
=> nil
irb(main):006:0>
В этом примере мы загрузили библиотеку Watir, открыли новое окно, перешли на сайт Google и попросили вывести все доступные на данной странице объекты. В этом списке имеются две кнопки: btnG и btnI. Последняя команда заставляет кнопку "Поиск в Google" мерцать желтым цветом некоторое время. Этот прием удобно использовать для поиска элементов.
Следующий пример демонстрирует базовые принципы
Следующий пример демонстрирует базовые принципы работы с библиотекой Watir. Сохраните этот код в файле и запустите его на выполнение. Со стороны будет казаться, что браузер делает все сам: загружает страницы, заполняет формы, нажимает на кнопки и т.д. Для удобства, активный элемент подсвечивается желтым цветом. # # simple_example.rb # # Александр Симаков, # http://alexander-simakov.blogspot.com/ #
# Подключаем библиотеку Watir require 'watir'
# Открываем новое окно IE ie = Watir::IE.new
# Переходим на страницу Google ie.goto "http://www.google.ru/"
# Заполняем поисковый запрос ie.text_field(:name, "q").set "Watir home page"
# Нажимаем на кнопку "Мне повезет!" ie.button(:name, "btnI").click
# Проверяем, есть ли на странице указанный текст if ie.text.include? "Web App Testing in Ruby" puts "Yes!" end
Итак, давайте разберемся как работает эта программа. В начале мы открываем новое окно Internet Explorer. Отмечу, что Watir также позволяет подключаться и к уже открытым окнам. Нужное окно при этом можно найти либо по ссылке, которая указана в адресной строке, либо по заголовку окна.
Далее мы переходим на сайт Google. На главной странице имеется поле для ввода запроса и две кнопки. Watir позволяет искать элементы расположенные на странице по многим параметрам: по атрибутам id, name, class, по заголовку, по ссылке, по порядковому номеру, по выражению xpath и т.д. В зависимости от типа элемента к которому вы хотите обратиться этот список может несколько отличаться. Так в строке 18 листинга мы обращаемся к текстовому полю у которого атрибут name имеет значение q. Если такой элемент существует, то Watir вернет объект класса TextField. В этом классе определен метод set, который заполняет текстовое поле: мы хотим найти домашнюю страницу Watir.
Теперь нажмем на кнопку "Мне повезет!". В отличие от обычного поиска мы автоматически перейдем по самой релевантной ссылке. Поскольку наш запрос достаточно точен мы с очень высокой долей вероятности попадем на домашнюю страницу проекта Watir.
Отмечу, что библиотека Watir позволяет не только находить объекты по различным критериям и манипулировать ими, но и анализировать результат. Так в строке 24 листинга мы проверяем содержит ли страница на которую мы перешли строку "Web App Testing in Ruby". Эту возможность можно использовать для написания модульных тестов.
Установка
Если вы подключены к интернету напрямую, то для установки Watir достаточно всего одной команды:
gem install watir
Bulk updating Gem source index for: http://gems.rubyforge.org Install required dependency win32-process? [Yn] Y Install required dependency windows-pr? [Yn] Y Install required dependency windows-api? [Yn] Y Install required dependency win32-api? [Yn] Y Select which gem to install for your platform (i386-mswin32) 1. win32-api 1.2.0 (ruby) 2. win32-api 1.2.0 (x86-mswin32-60) 3. win32-api 1.1.0 (x86-mswin32-60) 4. win32-api 1.1.0 (ruby) 5. Skip this gem 6. Cancel installation > 2 Install required dependency win32-api? [Yn] Y Select which gem to install for your platform (i386-mswin32) 1. win32-api 1.2.0 (x86-mswin32-60) 2. win32-api 1.2.0 (ruby) 3. Skip this gem 4. Cancel installation > 1 Install required dependency activesupport? [Yn] Y Successfully installed watir-1.5.6 Successfully installed win32-process-0.5.9 Successfully installed windows-pr-0.9.4 Successfully installed windows-api-0.2.4 Successfully installed win32-api-1.2.0-x86-mswin32-60 Successfully installed win32-api-1.2.0-x86-mswin32-60 Successfully installed activesupport-2.1.1 Installing ri documentation for watir-1.5.6... Installing ri documentation for win32-process-0.5.9... Installing ri documentation for windows-pr-0.9.4... Installing ri documentation for windows-api-0.2.4... Installing ri documentation for win32-api-1.2.0-x86-mswin32-60... Installing ri documentation for win32-api-1.2.0-x86-mswin32-60... Installing ri documentation for activesupport-2.1.1... Installing RDoc documentation for watir-1.5.6... Installing RDoc documentation for win32-process-0.5.9... Installing RDoc documentation for windows-pr-0.9.4... Installing RDoc documentation for windows-api-0.2.4... Installing RDoc documentation for win32-api-1.2.0-x86-mswin32-60... Installing RDoc documentation for win32-api-1.2.0-x86-mswin32-60... Installing RDoc documentation for activesupport-2.1.1... Если вы подключены через прокси, то перед инсталляцией потребуется задать переменную окружения http_proxy в следующем виде:
http://user:password@host:port Для установки переменной окружения выберите "Мой компьютер" -> "Свойства" -> "Дополнительно" -> "Переменные среды"-> "Создать".
После установки запустите интерактивную консоль Ruby irb и наберите:
irb(main):001:0> require 'watir'
=> true
irb(main):002:0> Если при загрузке модуля watir не возникло ошибок, значит установка прошла успешно.
Подключение к веб-сервису
Как это работает
Итак, давайте разберемся как работает эта программа. Нам известно, что метод getCursOnDateXML получает на вход дату и возвращает информацию о курсе валют. Но каким образом передать методу аргумент и как интерпретировать полученный ответ? Для начала, откроем файл defaultDriver.rb и найдем в нем название интересующего нас метода: require 'default.rb' require 'defaultMappingRegistry.rb' require 'soap/rpc/driver'
class DailyInfoSoap < ::SOAP::RPC::Driver DefaultEndpointUrl = "http://www.cbr.ru/DailyInfoWebServ/DailyInfo.asmx"
Methods = [ ... [ "http://web.cbr.ru/GetCursOnDateXML", "getCursOnDateXML", [ ["in", "parameters", ["::SOAP::SOAPElement", "http://web.cbr.ru/", "GetCursOnDateXML"]], ["out", "parameters", ["::SOAP::SOAPElement", "http://web.cbr.ru/", "GetCursOnDateXMLResponse"]] ], { :request_style => :document, :request_use => :literal, :response_style => :document, :response_use => :literal, :faults => {} } ], ... end end
Видно, что на вход поступает объект класса GetCursOnDateXML, а на выходе мы получаем объект класса GetCursOnDateXMLResponse. Определение этих классов находится в файле default.rb: require 'xsd/qname'
...
# {http://web.cbr.ru/}GetCursOnDateXML # on_date - SOAP::SOAPDateTime class GetCursOnDateXML attr_accessor :on_date
def initialize(on_date = nil) @on_date = on_date end end
# {http://web.cbr.ru/}GetCursOnDateXMLResponse # getCursOnDateXMLResult - # GetCursOnDateXMLResponse::GetCursOnDateXMLResult class GetCursOnDateXMLResponse
# inner class for member: GetCursOnDateXMLResult # {http://web.cbr.ru/}GetCursOnDateXMLResult class GetCursOnDateXMLResult attr_reader :__xmlele_any
def set_any(elements) @__xmlele_any = elements end
def initialize @__xmlele_any = nil end end
attr_accessor :getCursOnDateXMLResult
def initialize(getCursOnDateXMLResult = nil) @getCursOnDateXMLResult = getCursOnDateXMLResult end end
...
С классом GetCursOnDateXML все достаточно очевидно. В его конструктор достаточно передать дату, что мы и делаем в строке 26 листинга get_curs.rb. Класс GetCursOnDateXMLResponse выглядит несколько сложнее. В нем определен метод getCursOnDateXMLResult который, судя по всему, и возвращает результат. Но в каком формате? Давайте заглянем в WSDL-файл и найдем там описание типа GetCursOnDateXMLResult: ... ... Из этого фрагмента можно заключить, что GetCursOnDateXMLResult - это список "чего угодно" (s:any). В таких ситуациях на помощь приходит включение отладочного вывода (см. строку 23 листинга get_curs.rb) и irb - интерактивная консоль Ruby. При помощи irb можно наблюдать как исполняется код по мере его написания.
Итак, запускаем irb (из директории где находятся наши файлы), загружаем библиотеку SOAP4R и клиентские заглушки:
$ irb irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require_gem 'soap4r'
=> true
irb(main):003:0> require 'defaultDriver.rb'
=> true
irb(main):004:0> Создаем объект-драйвер для работы с веб-сервисом и включаем отладочный вывод:
irb(main):004:0> serv = DailyInfoSoap.new
=> #>
irb(main):005:0> serv.wiredump_dev = STDERR
=> #
irb(main):006:0> Далее создаем запрос с текущей датой и отправляем его на сервер:
irb(main):006:0> request = GetCursOnDateXML.new(DateTime.now)
=> #>
irb(main):007:0> response = serv.getCursOnDateXML(request)
Wire dump:
= Request
! CONNECT TO www.cbr.ru:80 ! CONNECTION ESTABLISHED POST /DailyInfoWebServ/DailyInfo.asmx HTTP/1.1 SOAPAction: "http://web.cbr.ru/GetCursOnDateXML" Content-Type: text/xml; charset=utf-8 User-Agent: SOAP4R/1.5.8 (/187, ruby 1.8.6 (2007-03-13) [i586-linux-gnu]) Date: Tue, 09 Sep 2008 19:36:45 GMT Content-Length: 405 Host: www.cbr.ru
2008-09-09T23:36:35.390913+04:00
= Response
HTTP/1. 1 200 OK Date: Tue, 09 Sep 2008 19:40:34 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Cache-Control: no-cache Pragma: no-cache Expires: -1 Content-Type: text/xml; charset=utf-8 Content-Length: 7601
Австралийский доллар 1 21.0261 36 AUD Фунт стерлингов Соединенного королевства 1 44.9826 826 GBP Белорусский рубль 1000 11.9615 974 BYR Датская крона 10 48.5829 208 DKK Доллар США 1 25.2626 840 USD Евро 1 36.2670 978 EUR Исландская крона 100 28.8435 352 ISK Казахский тенге 100 21.1120 398 KZT Канадский доллар 1 23.8642 124 CAD Китайский юань Жэньминьби 10 36.9304 156 CNY Норвежская крона 10 45.2719 578 NOK СДР (специальные права заимствования) 1 39.0691 960 XDR Сингапурский доллар 1 17.7668 702 SGD Новая турецкая лира 1 20.7564 949 TRY Украинская гривна 10 53.5225 980 UAH Шведская крона 10 38.3377 752 SEK Швейцарский франк 1 22.5962 756 CHF Японская иена 100 23.2653 392 JPY => #
В отладочном выводе хорошо видно как вызов метода трансформируется в SOAP-сообщение. Ответ также очень наглядный: мы видим последовательность вложенных тегов: GetCursOnDateXMLResponse, GetCursOnDateXMLResult и ValuteData. Внутри ValuteData находится список тегов ValuteCursOnDate по одному на каждую валюту. Названия атрибутов также вполне ожидаемые - Vname, Vnom, Vcurs, Vcode и VchCode. Но как нам получить доступ к этим данным из кода Ruby? Для ответа на этот вопрос давайте выведем имена всех доступных методов объекта response в алфавитном порядке:
irb(main):008:0> response.methods.sort
=> ["==", "===", "=~", "__id__", "__send__", "class", "clone", "dclone", "display", "dup", "eql?", "equal?", "extend", "freeze", "frozen?", "gem", "getCursOnDateXMLResult" , "getCursOnDateXMLResult=", "hash", "id", "inspect", "instance_eval", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "is_a?", "kind_of?", "method", "methods", "nil?", "object_id", "private_methods", "protected_methods", "public_methods", "require", "require_gem", "respond_to?", "send", "singleton_methods", "taint", "tainted?", "to_a", "to_s", "type", "untaint"]
irb(main):009:0> Обратите внимание на метод getCursOnDateXMLResult. Посмотрим, что он возвращает:
irb(main):009:0> response.getCursOnDateXMLResult.methods.sort
=> ["==", "===", "=~", "__id__", "__send__", "__xmlele_any", "class", "clone", "dclone", "display", "dup", "eql?", "equal?", "extend", "freeze", "frozen?", "gem", "hash", "id", "inspect", "instance_eval", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "is_a?", "kind_of?", "method", "methods", "nil?", "object_id", "private_methods", "protected_methods", "public_methods", "require", "require_gem", "respond_to?", "send", "set_any", "singleton_methods", "taint", "tainted?", "to_a", "to_s", "type", "untaint", "valuteData" ,"valuteData="]
irb(main):010:0> В списке имеется метод valuteData. Посмотрим что внутри:
irb(main):010:0> response.getCursOnDateXMLResult.valuteData.methods.sort
=> ["==", "===", "=~", "[]", "[]=", "__add_xmlele_value", "__id__", "__send__", "__xmlattr", "__xmlele", "class", "clone", "dclone", "display", "dup", "eql?", "equal?", "extend", "freeze", "frozen?", "gem", "hash", "id", "inspect", "instance_eval", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "is_a?", "kind_of?", "marshal_dump", "marshal_load", "method", "methods", "nil?", "object_id", "private_methods", "protected_methods", "public_methods", "require", "require_gem", "respond_to?", "send", "singleton_methods", "taint", "tainted?", "to_a", "to_s", "type", "untaint", "valuteCursOnDate" ,"valuteCursOnDate="] irb(main):011:0> Мы почти у цели. Посмотрим, какой объект возвращает метод valuteCursOnDate:
irb(main):011:0> response.getCursOnDateXMLResult.valuteData.valuteCursOnDate.class
=> Array
irb(main):012:0> response.getCursOnDateXMLResult.valuteData.valuteCursOnDate.length
=> 18 irb(main):013:0> Ага! Этот метод возвращает массив из 18 элементов. По всей видимости это и есть список валют. Для проверки нашей догадки, возьмем какой-нибудь элемент массива и посмотрим как он выглядит:
irb(main):013:0> response.getCursOnDateXMLResult.valuteData.valuteCursOnDate[4].methods.sort
=> ["==", "===", "=~", "[]" , "[]=", "__add_xmlele_value", "__id__", "__send__", "__xmlattr", "__xmlele", "class", "clone", "dclone", "display", "dup", "eql?", "equal?", "extend", "freeze", "frozen?", "gem", "hash", "id", "inspect", "instance_eval", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "is_a?", "kind_of?", "marshal_dump", "marshal_load", "method", "methods", "nil?", "object_id", "private_methods", "protected_methods", "public_methods", "require", "require_gem", "respond_to?", "send", "singleton_methods", "taint", "tainted?", "to_a", "to_s", "type", "untaint", "vchCode" , "vchCode=", "vcode" , "vcode=", "vcurs" , "vcurs=", "vname" , "vname=", "vnom" , "vnom="]
irb(main):014:0> response.getCursOnDateXMLResult.valuteData.valuteCursOnDate[4].vchCode
=> "USD"
irb(main):015:0> response.getCursOnDateXMLResult.valuteData.valuteCursOnDate[4]['VchCode']
=> "USD" irb(main):016:0> Действительно, каждый элемент массива соответствует определенной валюте. К атрибутам можно обратиться либо при помощи методов vname, vnom, vcurs, vcode, vchCode либо как к элементам хеша. Названия ключей при этом совпадают с названиями тегов в ответном XML-файле: Vname, Vnom, Vcurs, Vcode и VchCode. Теперь код тестовой программы становится очевидным: мы формируем запрос, отправляем его на сервер, получаем ссылку на массив валют, а затем бежим по этому массиву и выводим значения атрибутов. Вот и все!
Отмечу, что в более сложных ситуациях неоценимую помощь оказывают инструменты для отладки веб-сервисов, например, . При помощи этой программы можно вручную формировать SOAP-запросы и анализировать ответ от сервера.
Подключение к веб-сервису
Описание веб-сервиса, к которому мы собираемся подключаться, расположено по адресу . Описание задается на языке WSDL - Web Service Description Language. Фактически, это XML-документ определенной структуры.
В описании указывается какие методы предоставляет веб-сервис и как их следует вызывать. Нас интересует метод getCursOnDateXML. Он принимает в качестве аргумента дату и возвращает массив записей следующего вида:
Название валюты (Vname);
Номинал (Vnom);
Курс (Vcurs);
Цифровой код валюты (Vcode);
Символьный код валюты (VchCode).
Для того чтобы воспользоваться веб-сервисом нам необходимо сгенерировать клиентские заглушки (stubs). Эта процедура выполняется при помощи программы wsdl2ruby.rb, которая входит в состав библиотеки SOAP4R:
wsdl2ruby.rb --wsdl http://www.cbr.ru/DailyInfoWebServ/DailyInfo.asmx?WSDL --type client
ignored element: {http://schemas.xmlsoap.org/wsdl/soap12/}binding ignored element: {http://schemas.xmlsoap.org/wsdl/soap12/}operation ignored element: {http://schemas.xmlsoap.org/wsdl/soap12/}body ignored element: {http://schemas.xmlsoap.org/wsdl/soap12/}address I, [2008-09-07T00:04:04.847391 #5995] INFO -- app: Creating class definition. I, [2008-09-07T00:04:04.847750 #5995] INFO -- app: Creates file 'default.rb'. I, [2008-09-07T00:04:05.060365 #5995] INFO -- app: Creating mapping registry definition. I, [2008-09-07T00:04:05.060776 #5995] INFO -- app: Creates file 'defaultMappingRegistry.rb'. I, [2008-09-07T00:04:05.119316 #5995] INFO -- app: Creating driver. I, [2008-09-07T00:04:05.119752 #5995] INFO -- app: Creates file 'defaultDriver.rb'. I, [2008-09-07T00:04:05.219052 #5995] INFO -- app: Creating client skelton. I, [2008-09-07T00:04:05.219560 #5995] INFO -- app: Creates file 'DailyInfoClient.rb'. I, [2008-09-07T00:04:05.319125 #5995] INFO -- app: End of app. (status: 0) Как видно из отладочного вывода, программа сгенерировала четыре файла:
default.rb;
defaultMappingRegistry.rb;
defaultDriver.rb;
DailyInfoClient.rb.
Для работы с веб-сервисом необходимы первые три.
Последний файл не обязателен. Это пример клиентского кода. Итак, теперь все готово для написания тестового приложения: #!/usr/bin/ruby
# # get_curs.rb # # Александр Симаков, # http://alexander-simakov.blogspot.com/ #
# Подключаем библиотеку SOAP4R require 'rubygems' require_gem 'soap4r'
# Подключаем клиентские заглушки require 'defaultDriver.rb'
# При помощи этого объекта мы будем вызывать # методы веб-сервиса serv = DailyInfoSoap.new
# Выводить отладочную информацию если ruby # был запущен с ключом -d serv.wiredump_dev = STDERR if $DEBUG
# Формируем запрос request = GetCursOnDateXML.new(DateTime.now)
# Отправляем запрос на сервер и получаем ответ response = serv.getCursOnDateXML(request)
# Анализируем ответ и выводим результат items = response.getCursOnDateXMLResult.valuteData.valuteCursOnDate
items.each do |item| puts "---------------------------------" puts "Название: " + item['Vname'].strip puts "Числовой код: " + item['Vcode'] puts "Символьный код: " + item['VchCode'] puts "Номинал: " + item['Vnom'] puts "Курс: " + item['Vcurs'] end
Сохраните этот файл в той же директории и запустите его на выполнение. Вот как выглядел результат на момент написания статьи:
--------------------------------- Название: Австралийский доллар Числовой код: 36 Символьный код: AUD Номинал: 1 Курс: 21.0261 --------------------------------- Название: Фунт стерлингов Соединенного королевства Числовой код: 826 Символьный код: GBP Номинал: 1 Курс: 44.9826 --------------------------------- Название: Белорусский рубль Числовой код: 974 Символьный код: BYR Номинал: 1000 Курс: 11.9615 --------------------------------- Название: Датская крона Числовой код: 208 Символьный код: DKK Номинал: 10 Курс: 48.5829 --------------------------------- Название: Доллар США Числовой код: 840 Символьный код: USD Номинал: 1 Курс: 25.2626 --------------------------------- Название: Евро Числовой код: 978 Символьный код: EUR Номинал: 1 Курс: 36.2670 --------------------------------- Название: Исландская крона Числовой код: 352 Символьный код: ISK Номинал: 100 Курс: 28.8435 --------------------------------- Название: Казахский тенге Числовой код: 398 Символьный код: KZT Номинал: 100 Курс: 21.1120 --------------------------------- Название: Канадский доллар Числовой код: 124 Символьный код: CAD Номинал: 1 Курс: 23.8642 --------------------------------- Название: Китайский юань Жэньминьби Числовой код: 156 Символьный код: CNY Номинал: 10 Курс: 36.9304 --------------------------------- Название: Норвежская крона Числовой код: 578 Символьный код: NOK Номинал: 10 Курс: 45.2719 --------------------------------- Название: СДР (специальные права заимствования) Числовой код: 960 Символьный код: XDR Номинал: 1 Курс: 39.0691 --------------------------------- Название: Сингапурский доллар Числовой код: 702 Символьный код: SGD Номинал: 1 Курс: 17.7668 --------------------------------- Название: Новая турецкая лира Числовой код: 949 Символьный код: TRY Номинал: 1 Курс: 20.7564 --------------------------------- Название: Украинская гривна Числовой код: 980 Символьный код: UAH Номинал: 10 Курс: 53.5225 --------------------------------- Название: Шведская крона Числовой код: 752 Символьный код: SEK Номинал: 10 Курс: 38.3377 --------------------------------- Название: Швейцарский франк Числовой код: 756 Символьный код: CHF Номинал: 1 Курс: 22.5962 --------------------------------- Название: Японская иена Числовой код: 392 Символьный код: JPY Номинал: 100 Курс: 23.2653 Отмечу, что данные возвращаются в кодировке UTF-8.Таким образом, если на вашем компьютере используется другая кодировка, то названия валют будут нечитаемыми. В этом случае придется конвертировать данные вручную.
Установка
Для работы с веб-сервисами потребуется библиотека . Не смотря на то, что облегченная версия этой библиотеки уже включена в стандартную поставку Ruby, настоятельно рекомендуется установить полную версию. Если вы подключены к интернету напрямую, то достаточно всего одной команды:
# gem install soap4r
Bulk updating Gem source index for: http://gems.rubyforge.org Install required dependency httpclient? [Yn] Y Successfully installed soap4r-1.5.8 Successfully installed httpclient-2.1.2 Installing ri documentation for httpclient-2.1.2... Installing RDoc documentation for httpclient-2.1.2... Если вы подключены через прокси, то перед инсталляцией потребуется задать переменную окружения http_proxy. В Линуксе это можно сделать следующим образом:
export http_proxy=http://user:password@host:port Для установки переменной окружения под Windows выберите "Мой компьютер" -> "Свойства" -> "Дополнительно" -> "Переменные среды"-> "Создать".
Если при работе через прокси-сервер вы столкнетесь с ошибкой "407 Proxy Authentication Required", прочитайте . Там описывается решение проблемы.
это идеальное решение для интеграции
Веб-сервисы - это идеальное решение для интеграции программных систем. По сути, это единый язык на котором могут говорить приложения, написанные разными людьми на разных языках программирования и работающих на разных программно-аппаратных платформах. Сама технология базируется на открытых стандартах и имеет хорошую поддержку во всех современных языках программирования. Не исключение и Ruby. Как мы смогли убедиться, код на Ruby получается очень простым, компактным и выразительным.
Дистрибутивы и ссылки
Типы доступа "ftp" и "tftp"
Тип доступа по FTP или TFTP означает, что тело сообщения доступно как внешний файл по протоколу FTP [RFC-959] или TFTP [RFC-783] соответственно. Для этих типов доступа обязательны следующие дополнительные параметры:
NAME -- Имя файла, содержащего данные тела письма.
SITE -- Полный доменный адрес или псевдоним компьютера, с которого файл может быть получен по указанному протоколу.
Перед тем, как начнется считывание данных по FTP, пользователь обычно должен быть спрошен на предмет логина и пароля для машины, указанной в параметре 'site'. По причинам безопасности логин и пароль не указываются как параметры Content-Type и должны быть получены от получателя письма.
Дополнительно определены следующие необязательные параметры:
DIRECTORY -- каталог, содержащий тело письма на удаленной машине.
MODE -- Нечувствительное к регистру букв строка, указывающая режим передачи данных. Допустимые эначения для типа доступа TFTP:
NETASCII, OCTET и MAIL. Для типа доступа FTP: ASCII, EBCDIC, IMAGE и LOCALn , где n - десятичное целое число, обычно 8. Эти значения соответствуют типам представления A, E, I и Ln, определенным FTP-протоколом. Заметьте, что "BINARY" и "TENEX" не являются допустимыми значениями для параметра MODE. Вместо них должны использоваться "OCTET", "IMAGE" или "LOCAL8". Если параметр MODE отсутствует, значением по умолчанию является "NETASCII" для TFTP и "ASCII" для FTP.
Способ досупа "anon-ftp"
Этот способ доступа идентичен "ftp", за исключением того, что пользователю не требуется указывать свой логин и пароль для удаленной машины. FTP-протокол будет использоваться с логином "anonymous" и email-адресом получателя вместо пароля.
Способы доступа "local-file" и "afs"
Способ доступа "local-file" означает, что тело письма доступно как файл на локальной машине. "afs" означает, что тело доступно как файл через общую файловую систему AFS. В обоих случаях требуется единственный обязательный параметр:
NAME -- Имя файла, содержащего данные тела письма.
Следующий необязательный параметр может быть использован для локализации ссылки на файл и содержит адрес сайта или сайтов, на которых данный файл виден:
SITE -- Доменный адрес машины или машин, на которых возможен доступ к файлу данных. Допускаются маски с использованием звездочки вместо части доменного имени, например, "*.bellcore.com", для обозначения набора машин, на которых файл виден напрямую. Единственная звездочка вместо всего доменного имени может означать, что файл, где би он ни был, виден через глобальную файловую систему.
Способ доступа "mail-server"
Применяется, когда тело письма доступно через почтовый сервер. Обязательный параметр для этого способа доступа:
SERVER -- email-адрес mail-сервера, с которого могут быть запрошены данные тела письма.
Так как почтовые серверы предполагают множество различных синтаксисов, некоторые из них могут быть многострочными, полная команда, которую нужно послать на mail-сервер, не включается как параметр в однострочное поле 'content-type'. Вместо этого она помещается в мнимое тело, когда значением поля 'content-type' является 'message/external-body', и параметр 'access-tyoe' имеет значение 'mail-server'.
Необязательный параметр для этого способа доступа:
SUBJECT -- Subject, который будет использован в заголовке письма-запроса, которое почторый клиент получателя пошлет на указанный почтовый сервер для получения данных тела письма. Заметьте, что помещение адреса сервера в subject не рекомендуется, однако, известны mail-серверы, требующие этого.
MIME -стандарт не определяет синтаксиса обращения к почтовому серверу. Поэтому он допускает включение полной команды для mail-сервера в мнимое тело.
В отличие от других способов доступа, доступ через mail-сервер не синхронен, и данные могут быть получены в непредсказуемый момент в будущем. По этой причине важно иметь механизм, обеспечивающий вставку полученных от mail-сервера данных в исходное письмо. Mail-сервер при отправке запрошенных данных должен использовать то же самое значение поля Content-ID в заголовке письма с возвращаемыми данными, какое было в первоначальном "бестелесном" письме, чтобы облегчить работу этого механизма.
Примеры и дополнительные пояснения
С появлением возможности очень широких (протяженных) файловых систем стало непредсказуемым, на каком наборе машин файловой системы данный файл будет доступен напрямую, а на каком - нет. Поэтому, имеет смысл указывать как имя файла, так и сетевой адрес (адреса) машин, на которых файл доступен.
Если внешнее тела письма доступно посредством нескольких различных механизмов, отправитель может включить несколько частей типа message/external-body в письмо типа multipart/alternative.
Однако, механизм external-body не должен быть ограничен получением удаленных файлов. Например, можно представить использование видеосервера с внешними ссылками на видеофрагменты.
Если письмо / часть письма имеет тип "message/external-body", то оно / она будет содержать поля заголовка вложенного письма. Тело само по себе неходится где-либо во вне. Это значит, что если тело типа "message/external-body" содержит два последовательных конца строки (CRLF), то все, что идет далее, не является чстью сообщения и просто должно игнорироваться. Однако, этот "хвост" - удобное место для каких-либо дополнительных данных, которые не могут быть помещены в поле заголовка Content-Type. В частности, если значение "access-type" есть "mail-server", то "хвост" может содержать команды, посылаемые затем mail-серверу по адресу, на который указывает параметр SERVER.
Поля заголовка вложенного письма, которые на самом деле являются телом общего письма типа "message/external-body", должны нести информацию о типе содержимого внешнего (удаленного) тела, если оно не является простым ASCII-текстом (что подразумевается по умолчанию), поскольку эти внешние данные сами по себе не имеют заголовка, опрпеделяющего их тип. Также, необходимо указывать Content-transfer-encoding, если он имеет значение, отличное от "7-bit". Так, полное письмо типа message/external-body, ссылающееся на документ в формате PostScript, может выглядеть следующим образом: From: Whomever To: Someone Subject: whatever MIME-Version: 1.0 Message-ID: Content-Type: multipart/alternative; boundary=42 Content-ID: --42 Content-Type: message/external-body; name="BodyFormats.ps"; site="thumper.bellcore.com"; access-type=ANON-FTP; directory="pub"; mode="image"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: --42 Content-Type: message/external-body; name="/u/nsb/writing/rfcs/RFC-MIME.ps"; site="thumper.bellcore.com"; access-type=AFS expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: --42 Content-Type: message/external-body; access-type=mail-server server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: get RFC-MIME.DOC --42--
В приведенных примерах значение Content-transfer-encoding для внешних данных в формате postscript полагается по умолчанию как "7bit".
Заголовки общего и вложенного(их) писем (имеющих внешнее тело) должны удовлетворять тем же правилам, что и для типа message/partial во избежание путаницы.
Поскольку внешнее тело не пересылается в виде почты, то оно не обязано удовлетворять требованиям длины строк и иметь 7-битную форму, оно может быть просто бинарным файлом. Поэтому поле Content-Transfer-Encoding не является необходимым, хотя его наличие допускается.
Тело письма типа "message/external-body" обрабатывается в сответствии с основным синтаксисом стандарта RFC 822, в частности, все, что идет до первой последовательной пары концов строки (CRLF), является заголовком письма, а все, что идет после, является "мнимым" телом письма, которое игнорируется для большинства типов доступа.
Формальный синтаксис поля заголовка 'content-type' для данных типа 'message' - следующий: message_тип := "message" "/" message_подтип message_подтип := "rfc822" / "partial" 2-3 partial_параметра / "external-body" 1 external_параметр / расширение (не предопределенный подтип) partial_параметр := (";" "id" "=" значение) / (";" "number" "=" 1*ЦИФРА) / (";" "total" "=" 1*ЦИФРА) ; id и number требуются всегда; total требуется для последнего фрагмен- ; та послания. external_параметр := (";" "access-type" "=" тип_доступа) / (";" "expiration" "=" дата-время) ; Дата-время должны быть экранированы кавычками / (";" "size" "=" 1*Цифра) / (";" "permission" "=" ("read" / "read-write")) ; Значение permission нечувствительно к регистру букв / (";" "name" "=" значение) / (";" "site" "=" значение) / (";" "dir" "=" значение) / (";" "mode" "=" значение) / (";" "server" "=" значение) / (";" "subject" "=" значение) ; access-type требуется всегда; все остальное - в зависимости от значе- ; ния access-type тип_доступа := "ftp" / "anon-ftp" / "tftp" / "local-file" / "afs" / "mail-server" / / расширение (непредопределенный параметр) ; Нечувствителен к регистру букв
А как же Netscape Navigator?
Конечно, фирма Netscape не может совсем уж игнорировать технологию ActiveX, хотя и преисполнена по отношению к ней здоровым скептицизмом. Если вы не хотите расставаться со старым добрым Netscape Navigator, то для вас единственный способ познакомиться с этой новинкой - особый , разработанный фирмой NCompass Labs. Этот модуль умеет запускать органы управления ActiveX и даже обеспечивает их поддержку из сценариев.
По отзывам пользователей, модуль этот (называемый ScriptActive) работает вполне прилично и иногда даже обгоняет по скорости работы органов управления ActiveX сам Internet Explorer. К сожалению, надежность его вызывает нарекания (официально он все еще находится в стадии бета-тестирования). Если достаточно долго и интенсивно работать со страницами, насыщенными компонентами ActiveX, то в конце концов почти неизбежно нарвешься на ошибку, приводящую к зависанию Netscape. Это вполне объяснимо - ActiveX и вообще OLE для Netscape Navigator не является чем-то столь же родным и естественным, как для Internet Explorer, и трудности сочетания в одной программе двух очень разных программных идеологий неизбежно дают себя знать.
С этим, однако, вполне можно было бы мириться, если бы не одна техническая трудность. Netscape Navigator не распознает тег - и потому, даже с подключенным модулем ScriptActive, не может вызывать органы управления, вводимые этим тегом. Как известно, вызов подключаемых модулей Netscape производится с помощью тега . Это значит, что авторы, которые хотят, чтобы органы управления на их страницах работали в обоих броузерах, должны продублировать информацию тега в теге . А чтобы заставить Internet Explorer не обращать внимания на этот лишний для него (как вы знаете, Internet Explorer поддерживает этот тег и даже способен работать с подключаемыми модулями Netscape), этот тег помещают внутрь соответствующей пары тегов ... .
Такой выход из положения применяется в HTML довольно часто - пользуясь каким-нибудь новым тегом, автор в целях совместимости помещает между этим тегом и парным ему закрывающим что-нибудь, что будет видно только старым броузерам, игнорирующим новый тег; новый же броузер, распознающий этот тег, наоборот, обязан игнорировать все, что расположено внутри парного тега. (Надо признаться, что Netscape Navigator едва ли не первый раз в своей жизни оказывается в роли "старого броузера".) Вот как выглядит тег , информация которого повторена во вложенном теге : LocalButtons=0 Delay=1 >
Для атрибута CLASSID тег не имеет соответствующего элемента, поэтому броузеру (точнее, подключаемому модулю) приходится извлекать идентификатор класса из самого файла с органом управления. Разумеется, присутствие тега - в любом случае не более чем следствие предусмотрительности автора страницы (и его вежливости по отношению к пользователям Netscape Navigator); к примеру, на сервере использовать этот тег как-то не принято.
Администрирование.
Выводим на экран форму с паролем pass. В окне вводятся: номера названия ссылки Затем, после нажатия на кнопку и проверки пароля, записываем новый список в файл.
admin weather
После ввода информации в файл в виде, получаем:
50
Ларнака
http://weather.yahoo.com/forecast/Larnaca_CY_f.html
51
Пафос
http://weather.yahoo.com/forecast/Paphos_CY_f.html
"44" - номер города.
"Ларнака" - название города.
"http://weather.yahoo.com/forecast/Larnaca_CY_f.html" - ссылка на погоду в городе Ларнака на Яхе.
Ссылки на города организовываются по принципу:
Ларнака
Анатомия сообщения BizTalk
Принимающее приложение узнает о том, что это сообщение BizTalk, на основании конверта (он сообщает конкретную схему, использованную для формулирования данного документа). Оно понимает формат ваших специфических данных, потому что тег указывает на схему, которую вы используете внутри для форматирования своих данных:
Теги маршрута
Ваш документ
Аннотация
Электронный бизнес приводит к изменению устоявшихся подходов применения информационных технологий. Информационные системы, работающие в среде Интернет и обслуживающие неограниченное число пользователей, требуют появления новых, масштабируемых систем, обладающих свойствами высокой пропускной способности и скорости выполнения транзакций. Информация, обрабатываемая такими системами, по своей сути является разнородной и может храниться в разных частях света. Появление таких новых возможностей обработки информации стало возможным благодаря открытым стандартам коммуникаций, таким как: HTTP, TCP/IP, HTML и XML.
Компания Software AG полагает, что недавно появившийся стандарт XML (eXtensible Markup Language) приведет не только к революционным изменениям в Интернет, но и, в свою очередь, к таким же изменениям всей палитры информационных технологий. XML, предлагая средства для самоописания структуры документов, и поддержанный тесно связанными стандартами XQL - языка выборки данных и XSL - форматирования документов, преобразует Интернет из среды информационной сети в интегрированную глобальную вычислительную систему, обладающую неограниченной базой знаний, и имеющей мощные ресурсы для электронного бизнеса. Все это позволит объединить Интернет и традиционные информационные технологии, превращая их в интегрированные системы электронного бизнеса.
Вместе с тем, реализация данной концепции требует создания информационного сервера нового типа, обладающего свойствами масштабирования, безотказности работы, открытого с точки зрения модели данных и обрабатываемых источников информации.
Tamino (Transaction Architecture for the Management of INternet Objects) - информационный сервер, выпущенный компанией Software AG, удовлетворяет данным требованиям. Tamino является первым в мире информационным XML-сервером, функционально полной системой управления данными, предназначенной для обмена данными и интеграции приложений; технологией превращения данных, обрабатываемых существующими приложениями, в объекты Интернет.
Tamino устанавливает высоконадежную, масштабируемую и открытую среду, обеспечивающую возможность выполнения транзакций в Интернет.
Крупные предприятия эксплуатируют разнородную смесь платформ программно-технических средств, баз данных и прикладного программного обеспечения. Процесс развития бизнеса, приводящий к установлению партнерских отношений между разными компаниями, их слиянию или купле-продаже, приводит к невозможности хранения данных предприятий в одном месте. Технология Tamino, использующая XML, позволяет соединить данные, распределенные по предприятию (или между бизнес-партнерами). Результатом является полная и побуждающая к действию информация, позволяющая компаниям реализовать бизнес, действительно ориентированный на клиента. Таким образом, Tamino, играя роль интегратора и поставщика информации в Интернет, меняет способ ведения бизнеса.
Tamino основывается на почти 30-летнем опыте, накопленном Software AG в области разработки баз данных. Технологии баз данных Software AG, характеризуемые высокой степенью гибкости и масштабирования, поддерживают несколько моделей данных, включая чисто реляционную, реляционную со вложенными структурами данных, фактографические и текстовые данные. Будучи доработанной для обеспечения высокой производительности, доступности (непрерывной эксплуатации) и масштабирования, данная технология является идеальной для построения жизненно важных приложений уровня предприятия, требующих круглосуточного доступа к данным. Все это, с учетом низкой стоимости владения (TCO - total cost of ownership), представляет большую ценность СУБД для электронного бизнеса.
Берклевские утилиты сетевой коммуникации
В данной главе будет кратко описаны команды, созданные для ``общения" между собой UNIX-машин. В их число входят: rlogin, rcp, rsh, rwho, rdist, ruptime.
Библиография
[AAB+98] Jos Luis Ambite, Naveen Ashish, Greg Barish, Craig A. Knoblock, Steven Minton, Pragnesh J. Modi, Ion Muslea, Andrew Philpot, and Sheila Tejada. ARIADNE: A system for constructing mediators for internet sources (system demonstration). In Proc. of ACM SIGMOD Conf. on Management of Data, Seattle, WA, 1998.
[Abi97] Serge Abiteboul. Querying semi-structured data. In Proc. of the Int. Conf. on Database Theory (ICDT), Delphi, Greece, 1997.
[ACM93] Serge Abiteboul, Sophie Cluet, and Tova Milo. Querying and updating the file. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), Dublin, Ireland, 1993.
[ACPS96] S. Adali, K. Candan, Y. Papakonstantinou, and V.S. Subrahmanian. Query caching and optimization in distributed mediator systems. In Proc. of ACM SIGMOD Conf. on Management of Data, Montreal, Canada, 1996.
[AD98] S. Abiteboul and O. Duschka. Complexity of answering queries using materialized views. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), Seattle, WA, 1998.
[AFT98] Laurent Amsaleg, Michael Franklin, and Anthony Tomasic. Dynamic query operator scheduling for wide-area remote access. Distributed and Parallel Databases, 6(3):217-246, July 1998.
[AII98] Proceedings of the AAAI Workshop on Intelligent Data Integration, Madison, Wisconsin, July 1998.
[AK97] Naveen Ashish and Craig A. Knoblock. Wrapper generation for semi-structured internet sources. SIGMOD Record, 26(4):8-15, 1997.
[AKS96] Yigal Arens, Craig A. Knoblock, and Wei-Min Shen. Query reformulation for dynamic information integration. International Journal on Intelligent and Cooperative Information Systems, (6) 2/3:99-130, June 1996.
[AM98] Gustavo Arocena and Alberto Mendelzon. WebOQL: Restructuring documents, databases and webs. In Proc. of Int. Conf. on Data Engineering (ICDE), Orlando, Florida, 1998.
[AMM97a] Gustavo O. Arocena, Alberto O. Mendelzon, and George A. Mihaila. Applications of a web query language. In Proc. of the Int. WWW Conf., April 1997.
[AMM97b] Paolo Atzeni, Giansalvatore Mecca, and Paolo Merialdo. To weave the web. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), 1997.
[AMM98] Paolo Atzeni, Giansalvatore Mecca, and Paolo Merialdo. Design and maintenance of dataintensive web sites. In Proc. of the Conf. on Extending Database Technology (EDBT), Valencia, Spain, 1998.
[AMR+98] Serge Abiteboul, Jason McHugh, Michael Rys, Vasilis Vassalos, and Janet Weiner. Incremental maintenance for materialized views over semistructured data. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), New York City, USA, 1998.
[AQM+97] Serge Abiteboul, Dallan Quass, Jason McHugh, Jennifer Widom, and Janet Wiener. The Lorel query language for semistructured data. International Journal on Digital Libraries, 1(1):68-88, April 1997.
[Aro97] Gustavo Arocena. WebOQL: Exploiting document structure in web queries. Master's thesis, University of Toronto, 1997.
[AV97a] S. Abiteboul and V. Vianu. Queries and computation on the Web. In Proc. of the Int. Conf. on Database Theory (ICDT), Delphi, Greece, 1997.
[AV97b] Serge Abiteboul and Victor Vianu. Regular path queries with constraints. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), Tucson, Arizona, May 1997.
[BBH+98] Krisha Bharat, Andrei Broder, Monika Henzinger, Puneet Kumar, and Suresh Venkatasubramanian. The connectivity server: fast access to linkage information on the web. In Proc. of the Int. WWW Conf., April 1998.
[BBMR89] Alex Borgida, Ronald Brachman, Deborah McGuinness, and Lori Resnick. CLASSIC: A structural data model for objects. In Proc. of ACM SIGMOD Conf. on Management of Data, pages 59-67, Portland, Oregon, 1989.
[BDFS97] Peter Buneman, Susan Davidson, Mary Fernandez, and Dan Suciu. Adding structure to unstructured data. In Proc. of the Int. Conf. on Database Theory (ICDT), Delphi, Greece, 1997.
[BDH+95] C. M. Bowman, Peter B. Danzig, Darren R. Hardy, Udi Manber, and Michael F. Schwartz. The harvest information discovery and access system.
Computer Networks and ISDN Systems, 28(1-2):119-125, December 1995.
[BDHS96] P. Buneman, S. Davidson, G. Hillebrand, and D. Suciu. A query language and optimization techniques for unstructured data. In Proc. of ACM SIGMOD Conf. on Management of Data, pages 505-516, Montreal, Canada, 1996.
[BEM+98] C. Beeri, G. Elber, T. Milo, Y. Sagiv, O. Shmueli, N. Tishby, Y. Kogan, D. Konopnicki, P. Mogilevski, and N. Slonim. Websuite - a tool suite for harnessing web data. In Proceedings of the International Workshop on the Web and Databases, Valencia, Spain, 1998.
[BH98] Krishna Bharat and Monika Henzinger. Improved algorithms for topic distillation in hyperlinked environments. In Proc. 21st Int'l ACM SIGIR Conference, 1998.
[Bil98] David Billard. Transactional services for the web. In Proceedings of the International Workshop on the Web and Databases, pages 11-17, Valencia, Spain, 1998.
[BK90] C. Beeri and Y. Kornatzky. A logical query language for hypertext systems. In Proc. of the European Conference on Hypertest, pages 67-80. Cambridge University Press, 1990.
[Bla96] Jose A. Blakeley. Data access for the masses through OLE DB. In Proc. of ACM SIGMOD Conf. on Management of Data, pages 161-172, Montreal, Canada, 1996.
[BP98] Sergey Brin and Lawrence Page. The anatomy of a large-scale hypertextual web search engine. In Proc. of the Int. WWW Conf., April 1998.
[BT98] Philippe Bonnet and Anthony Tomasic. Partial answers for unavailable data sources. In Proceedings of the 1998 Workshop on Flexible Query-Answering Systems (FQAS'98), pages 43-54. Department of Computer Science, Roskilde University, 1998.
[Bun97] Peter Buneman. Semistructured data. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), pages 117-121, Tucson, Arizona, 1997.
[CACS94] V. Christophides, S. Abiteboul, S. Cluet, and M. Scholl. From structured documents to novel query facilities. In Proc. of ACM SIGMOD Conf. on Management of Data, pages 313-324, Minneapolis, Minnesota, 1994.
[CDF+98] Mark Craven, Dan DiPasquo, Dayne Freitag, Andrew McCallum, Tom Mitchell, Kamal Nigam, and Sean Slattery. Learning to extract symbolic knowledge from the world-wide web. In Proceedings of the AAAI Fifteenth National Conference on Artificial Intelligence, 1998.
[CDRR98] Soumen Chakrabarti, Byron Dom, Prabhakar Raghavan, and Sridhar Rajagopalan. Automatic resource compilation by analyzing hyperlink structure and associated text. In Proc. of the Int. WWW Goof., April 1998.
[CDSS98] Sophie Cluet, Claude Delobel, Jerome Simeon, and Katarzyna Smaga. Your mediators need data conversion. In Proc. of ACM SIGMOD Conf. on Management of Data, Seattle, WA, 1998.
[CGL98] Diego Calvanese, Giuseppe De Giacomo, and Maurizio Lenzerini. What can knowledge representation do for semi-structured data? In Proceedings of the AAAI Fifteenth National Conference on Artificial Intelligence, 1998.
[CGMP98] Junghoo Cho, Hector Garcia-Molina, and Lawrence Page. Efficient crawling through url ordering. In Proc. of the Int. WWW Conf., April 1998.
[CK98] J. Carriere and R. Kazman. Webquery: Searching and visualizing the web through connectivity. In Proc. of the Int. WWW Conf., April 1998.
[CKPS95] Surajit Chaudhuri, Ravi Krishnamurthy, Spyros Potamianos, and Kyuseok Shim. Optimizing queries with materialized views. In Proc. of Int. Conf. on Data Engineering (ICDE), Taipei, Taiwan, 1995.
[CM89] Mariano P. Consens and Alberto O. Mendelzon. Expressing structural hypertext queries in graphlog. In Proc. 2nd. ACM Conference on Hypertext, pages 269-292, Pittsburgh, November 1989.
[CM90] Mariano Consens and Alberto Mendelzon. GraphLog: a visual formalism for real life recursion. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), pages 404-416, Atlantic City, NJ, 1990.
[CMW87] Isabel F. Cruz, Alberto O. Mendelzon, and Peter T. Wood. A graphical query language supporting recursion. In Proc. of ACM SIGMOD Conf. on Management of Data, pages 323-330, San Francisco, CA, 1987.
[CMW88] I.F. Cruz, A.0. Mendelzon, and P.T. Wood. G+: Recursive queries without recursion. In Proceedings of the Second International Conference on Expert Database Systems, pages 355-368, 1988.
[Coh98] William Cohen. Integration of heterogeneous databases without common domains using queries based on textual similarity. In Proc. of ACM SIGMOD Conf. on Management of Data, Seattle, WA, 1998.
[CS98] Pei Cao and Sekhar Sarukkai, editors. Proceedings of Workshop on Internet Server Performance, Madison, Wisconsin, 1998. .
[DEW97] B. Doorenbos, O. Etzioni, and D. Weld. Scalable comparison-shopping agent for the world-wide web. In Proceedings of the International Conference on Autonomous Agents, February 1997.
[DFF+98] Alin Deutsch, Mary Fernandez, Daniela Florescu, Alon Levy, and Dan Suciu. A query language for XML. , 1998.
[DG97a] Oliver M. Duschka and Michael R. Genesereth. Answering recursive queries using views. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), Tucson, Arizona, 1997.
[DG97b] Oliver M. Duschka and Michael R. Genesereth. Query planning in infomaster. In Proceedings of the ACM Symposium on Applied Computing, San Jose, CA, 1997.
[Dus97] Oliver Duschka. Query optimization using local completeness. In Proceedings of the AAAI Fourteenth National Conference on Artificial Intelligence, 1997.
[EGW94] Oren Etzioni, Keith Golden, and Daniel Weld. Tractable closed world reasoning with updates. In Proceedings of the Conference on Principles of Knowledge Representation and Reasoning, KR-94, 1994. Extended version to appear in Artificial Intelligence.
[EW94] Oren Etzioni and Dan Weld. A softbot-based interface to the internet. CACM, 37(7):72-76, 1994.
[FFK+98] Mary Fernandez, Daniela Florescu, Jaewoo Kang, Alon Levy, and Dan Suciu. Catching the boat with Strudel: Experiences with a web-site management system. In Proc. of ACM SICMOD Conf. on Management of Data, Seattle, WA, 1998.
[FFLS97] Mary Fernandez, Daniela Florescu, Alon Levy, and Dan Suciu.
A query language for a web- site management system. SIGMOD Record, 26(3):4-11, September 1997.
[FFLS98] Mary Fernandez, Daniela Florescu, Alon Levy, and Dan Suciu. Reasoning about web-sites. In Working notes of the AAAI-98 Workshop on Artificial Intelligence and Data Integration. American Association of Artificial Intelligence, 1998.
[FHM94] Douglas Fang, Joachim Hammer, and Dennis McLeod. The identification and resolution of semantic heterogeneity in multidatabase systems. In Multidatabase Systems: An Advanced Solution for Global Information Sharing, pages 52-60. IEEE Computer Society Press, Los Alamitos, California, 1994.
[FKL97] Daniela Florescu, Daphne Koller, and Alon Levy. Using probabilistic information in data integration. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), pages 216-225, Athens, Greece, 1997.
[FLS98] Daniela Florescu, Alon Levy, and Dan Suciu. Query containment for conjunctive queries with regular expressions. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), Seattle, WA, 1998.
[FRV96] Daniela Florescu, Louiqa Raschid, and Patrick Valduriez. A methodology for query reformulation in cis using semantic knowledge. Int. Journal of Intelligent & Cooperative Information Systems, special issue on Formal Methods in Cooperative Information Systems, 5(4), 1996.
[FW97] M. Friedman and D. Weld. Efficient execution of information gathering plans. In Proceedings of the International Joint Conference on Artificial Intelligence, Nagoya, Japan, 1997.
[GC94] G. Graefe and R. Cole. Optimization of dynamic query evaluation plans. In Proc. of ACM SIGMOD Conf. on Management of Data, Minneapolis, Minnesota, 1994.
[GGMT99] Luis Gravano, Hector Garcia-Molina, and Anthony Tomasic. GlOSS: Text-source discovery over the internet. ACM Transactions on Database Systems (to appear), 1999.
[GMPQ+97] H. Garcia-Molina, Y. Papakonstantinou, D. Quass, A. Rajaraman, Y. Sagiv, J. Ullman, and J. Widom. The TSIMMIS project: Integration of heterogenous information sources, March 1997.
[GMW98] R. Goldman, J. McHugh, and J. Widom. Lore: A database management system for XML. Presentation, Stanford University Database Group, 1998.
[GRC97] S. Gadde, M. Rabinovich, and J. Chase. Reduce, reuse, recycle: An approach to building large internet caches. In Proceedings of the Workshop on Hot Topics in Operating Systems (HotOS), May 1997.
[GRVB98] Jean-Robert Gruser, Louiqa Raschid, Maria Esther Vidal, and Laura Bright. Wrapper generation for web accessible data sources. In Proceedings of the CoopIS, 1998.
[GW97] Roy Goldman and Jennifer Widom. Dataguides: Enabling query formulation and optimization in semistructured databases. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), Athens, Greece, 1997.
[GW98] Roy Goldman and Jennifer Widom. Interactive query and search in semistructured databases. In Proceedings of the International Workshop on the Web and Databases, pages 42-48, Valencia, Spain, 1998.
[GZC89] Ralf Hartmut Guting, Roberto Zicari, and David M. Choy. An algebra for structured office documents. ACM TOIS, 7(2):123-157, 1989.
[Hal88] Frank G. Halasz. Reflections on Notecards: Seven issues for the next generation of hypermedia systems. Comm. of the ACM, 31(7):836-852, 1988.
[Har94] Coleman Harrison. Aql: An adaptive query language. Technical Report NU-CCS-94-19, Northeastern University, October 1994. Master's Thesis.
[HGMN+98] Joachim Hammer, Hector Garcia-Molina, Svetlozar Nestorov, Ramana Yerneni, Markus M. Breunig, and Vasilis Vassalos. Template-based wrappers in the TSIMMIS system (system demonstration). In Proc. of ACM SIGMOD Conf. on Management of Data, Tucson, Arizona, 1997.
[HKWY97] Laura Haas, Donald Kossmann, Edward Wimmers, and Jun Yang. Optimizing queries across diverse data sources. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), Athens, Greece, 1997.
[HLLS97] Rainer Himmeroder, Georg Lausen, Bertram Ludascher, and Christian Schlepphorst. On a declarative semantics for web queries. In Proc. of the Int. Conf.
on Deductive and Object-Oriented Databases (DOOD), pages 386-398, Singapore, December 1997. Springer.
[HML+98] Kyoji Hirata, Sougata Mukherjea, Wen- Syan Li, Yusaku Okamura, and Yoshinori Hara. Facilitating object-based navigation through multimedia web databases. TAPOS, 4{4), 1998. In press.
[Hul97] Richard Hull. Managing semantic heterogeneity in databases: A theoretical perspective. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), pages 51-61, Tucson, Arizona, 1997.
[HZ96] Richard Hull and Gang Zhou. A framework for supporting data integration using the materialized and virtual approaches. In Proc. of ACM SIGMOD Conf. on Management of Data, pages 481-492, Montreal, Canada, 1996.
[Jan98] , 1998.
[JB97] R. Jakobovits and J. F. Brinkley. Managing medical research data with a web-interfacing repository manager. In American Medical Informatics Association Fall Symposium, pages 454-458, Nashville, Oct. 1997.
[Jun98] , 1998.
[KD98] Navin Kabra and David J. DeWitt. Efficient mid-query re-optimization of sub-optimal query execution plans. In Proc. of ACM SIGMOD Conf. on Management of Data, pages 106-117, Seattle, WA, 1998.
[KDW97] N. Kushmerick, R. Doorenbos, and D. Weld. Wrapper induction for information extraction. In Proceedings of the 15th International Joint Conference on Artificial Intelligence, 1997.
[Kle98] Jon Kleinberg. Authoritative sources in a hyperlinked environment. In Proceedings of 9th ACM-SIAM Symposium on Discrete Algorithms, 1998.
[KLW95] M. Kifer, G. Lausen, and J. Wu. Logical foundations of object-oriented and frame-based languages. J. ACM, 42{4):741-843, 1995.
[KMSS98] Y. Kogan, D. Michaeli, Y. Sagiv, and O. Shmueli. Utilizing the multiple facets of www contents. Data and Knowledge Engineering, 1998. In press.
[KS95] D. Konopnicki and O. Shmueli. W3QS: A query system for the World Wide Web. In Proc. of the Int. Conf, on Very Large Data Bases (VLDB), pages 54-65, Zurich, Switzerland, 1995.
[KS98] David Konopnicki and Oded Shmueli.
Bringing database functionality to the WWW. In Proceedings of the International Workshop on the Web and Databases, Valencia, Spain, pages 49-55, 1998.
[KW96] Chung T. Kwok and Daniel S. Weld. Planning to gather information. In Proceedings of the AAAI Thirteenth National Conference on Artificial Intelligence, 1996.
[Lev96] Alon Y. Levy. Obtaining complete answers from incomplete databases. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), Bombay, India, 1996.
[LG98] S. Lawrence and C.L. Giles. Searching the world wide web. Science, 280(4):98-100, 1998.
[LHL+98] Bertram Ludascher, Rainer Himmeroder, Georg Lausen, Wolfgang May, and Christian Schlepphorst. Managing semistructured data with FLORID: A deductive object-oriented perspective. Information Systems, 23(8), 1998. to appear.
[LMSS95] Alon Y. Levy, Alberto O. Mendelzon, Yehoshua Sagiv, and Divesh Srivastava. Answering queries using views. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), San Jose, CA, 1995.
[LRO96] Alon Y. Levy, Anand Rajaraman, and Joann J. Ordille. Querying heterogeneous information sources using source descriptions. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), Bombay, India, 1996.
[LRU96] Alon Y. Levy, Anand Rajaraman, and Jeffrey D. Ullman. Answering queries using limited external processors. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), Montreal, Canada, 1996.
[LSB+98] T. Lee, L. Sheng, T. Bozkaya, N.H. Balkir, Z.M. Ozsoyoglu, and G. Ozsoyoglu. Querying multimedia presentations based on content. to appear in IEEE Trans. on Know. and Data Engineering, 1998.
[LSCH98] Wen-Syan Li, Junho Shim, K. Selcuk Canadan, and Yoshinori Hara. WebDB: A web query system and its modeling, language, and implementation. In Proc. IEEE Advances in Digital Libraries'98, 1998.
[LSS96] Laks V. S. Lakshmanan, Fereidoon Sadri, and Iyer N. Subramanian. A declarative language for querying and restructuring the Web.
In Proc. of 6th. International Workshop on Research Issues in Data Engineering, RIDE'96, New Orleans, February 1996.
[MM97] Alberto O. Mendelzon and Tova Milo. Formal models of web queries. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), pages 134-143, Tucson, Arizona, May 1997.
[MMM97] A. Mendelzon, G. Mihaila, and T. Milo. Querying the world wide web. International Journal on Digital Libraries, 1(1):54-67, April 1997.
[MMM98] Giansalvatore Mecca, Alberto O. Mendelzon, and Paolo Merialdo. Efficient queries over web views. In Proc. of the Conf. on Extending Database Technology (EDBT), Valencia, Spain, 1998.
[Mot89] Amihai Motro. Integrity = validity + completeness. ACM Transactions on Database Systems, 14(4):480-502, December 1989.
[MP96] Kenneth Moore and Michelle Peterson. A groupware benchmark based on Lotus Notes. In Proc. of Int. Conf. on Data Engineering (ICDE), 1996.
[MPP+93] Bernhard Mitschang, Hamid Pirahesh, Peter Pistor, Bruce G. Lindsay, and Norbert Sdkamp. Sql/xnf - processing composite objects as abstractions over relational data. In Proc. of Int. Conf. on Data Engineering (ICDE), pages 272-282, Vienna, Austria, 1993.
[MRT98] George A. Mihaila, Louiqa Raschid, and Anthony Tomasic. Equal time for data on the internet with websemantics. In Proc. of the Conf. on Extending Database Technology (EDBT), Valencia, Spain, 1998.
[MZ98] Tova Milo and Sagit Zohar. Using schema matching to simplify heterogeneous data translation. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), New York City, USA, 1998.
[NAM98] Svetlozar Nestorov, Serge Abiteboul, and Rajeev Motwani. Extracting schema from semistructured data. In Proc. of ACM SIGMOD Conf. on Management of Data, Seattle, WA, 1998.
[NGT98] Hubert Naacke, Georges Gardarin, and Anthony Tomasic. Leveraging mediator cost models with heterogeneous data sources. In Proc. of Int. Conf. on Data Engineering (ICDE), Orlando, Florida, 1998.
[NS96] Tam Nguyen and V.
Srinivasan. Accessing relational databases from the world wide web. In Proc. of ACM SIGMOD Conf. on Management of Data, Montreal, Canada, 1996.
[PAGM96] Y. Papakonstantinou, S. Abiteboul, and H. Garcia-Molina. Object fusion in mediator systems. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), Bombay, India, 1996.
[PdBA+92] Jan Paredaens, Jan Van den Bussche, Mare Andries, Marc Gemis and Marc Gyssens, Inge Thyssens, Dirk Van Gucht, Vijay Sarathy, and Lawre nce V. Saxton. An overview of GOOD. SIGMOD Record, 21(1):25-31, 1992.
[PE95] Mike Perkowitz and Oren Etzioni. Category translation: Learning to understand information on the internet. In Working Notes of the AAAI Spring Symposium on Information Gathering from Heterogeneous Distributed Environments. American Association for Artificial Intelligence, 1995.
[PE97] Mike Perkowitz and Oren Etzioni. Adaptive web sites: an AI challenge. In Proceedings of the 15th International Joint Conference on Artificial Intelligence, 1997.
[PF98] P. Paolini and P. Fraternali. A conceptual model and a tool environment for developing more scalable, dynamic, and customizable web applications. In Proc. of the Conf. on Extending Database Technology (EDBT), Valencia, Spain, 1998.
[PGGMU95] Yannis Papakonstantinou, Ashish Gupta, Hector Garcia-Molina, and Jeffrey Ullman. A query translation scheme for rapid implementation of wrappers. In Proc. of the Int. Conf. on Deductive and Object-Oriented Databases (DOOD), 1995.
[PGMW95] Yannis Papakonstantinou, Hector Garcia-Molina, and Jennifer Widom. Object exchange across heterogeneous information sources. In Proc. of Int. Conf. on Data Engineering (ICDE), pages 251-260, Taipei, Taiwan, 1995.
[PMSL94] Hamid Pirahesh, Bernhard Mitschang, Norbert Sdkamp, and Bruce G. Lindsay. Composite-object views in relational dbms: an implementation perspective. Information Systems, IS 19(1):69-88, 1994.
[PPR96] P. Pirolli, J. Pitkow, and R. Rao. Silk from a sow's ear: Extracting usable structures from the web.
In Proc. ACM SIGCHI Conference, 1996.
[RSU95] Anand Rajaraman, Yehoshua Sagiv, and Jeffrey D. Ullman. Answering queries using templates with binding patterns. In Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), San Jose, CA, 1995.
[Spe97] Ellen Spertus. ParaSite: Mining structural information on the web. In Proc. of the Int. WWW Conf., April 1997.
[SSD97] Proceedings of Workshop on Management of Semistructured Data, Tucson, Arizona, May 1997.
[TMD92] J. Thierry-Mieg and R. Durbin. A C.elegans database: syntactic definitions for the ACEDB data base manager, 1992.
[TN98] Motomichi Toyama and T. Nagafuji. Dynamic and structured presentation of database contents on the web. In Proc. of the Gonf. on Extending Database Technology (EDBT), Valencia, Spain, 1998.
[TRV98] A. Tomasic, L. Raschid, and P. Valduriez. Scaling access to distributed heterogeneous data sources with Disco. IEEE Transactions On Knowledge and Data Engineering (to appear), 1998.
[TSI96] Odysseas G. Tsatalos, Marvin H. Solomon, and Yannis E. Ioannidis. The GMAP: A versatile tool for physical data independence. VLDB Journal, 5(2):101-118, 1996.
[UFA98] Tolga Urhan, Michael J. Franklin, and Laurent Amsaleg. Cost based query scrambling for initial delays. In Proc. of ACM SIGMOD Conf. on Management of Data, pages 130-141, Seattle, WA, 1998.
[Ull97] Jeffrey D. Ullman. Information integration using logical views. In Proc. of the Int. Conf. on Database Theory (ICDT), Delphi, Greece, 1997.
[VP97a] Vasilis Vassalos and Yannis Papakonstantinou. Describing and using the query capabilities of heterogeneous sources. In Proc. of the Int. Conf, on Very Large Data Bases (VLDB), Athens, Greece, 1997.
[VP97b] Anne-Marie Vercoustre and Francois Paradis. A descriptive language for information object reuse through virtual documents. In Proceedings of the 4th International Conference on Object-Oriented Information Systems (OOIS'97), Brisbane, Australia, November 1997.
[WAC+93] Darrel Woelk, Paul Attie, Phil Cannata, Greg Meredith, Amit Seth, Munindar Sing, and Christine Tomlinson.
Task scheduling using intertask dependencies in Carnot. In Proc. of ACM SIGMOD Conf. on Management of Data, pages 491-494, 1993.
[WBJ+95] Darrell Woelk, Bill Bohrer, Nigel Jacobs, K. Ong, Christine Tomlinson, and C. Unnikrishnan. Carnot and infosleuth: Database technology and the world wide web. In Proc. of ACM SIGMOD Conf. on Management of Data, pages 443-444, San Jose, CA, 1995.
[Web98] Proceedings of the International Workshop on the Web and Databases, Valencia, Spain, March 1998.
[WWW98] Proceedings of 3d WWW Caching Workshop (Manchester, England), June 1998.
[XML98] , 1998.
[YL87] H. Z. Yang and P. A. Larson. Query transformation for PSJ-queries. In Proc. of the Int. Conf. on Very Large Data Bases (VLDB), pages 245-254, Brighton, England, 1987.
[YPAGM98] Ramana Yerneni, Yannis Papakonstantinou, Serge Abiteboul, and Hector Garcia-Molina. Fusion queries over internet databases. In Proc. of the Conf. on Extending Database Technology (EDBT), pages 57-71, Valencia, Spain, 1998.
[ZGM98] Yue Zhuge and Hector Garcia-Molina. Graph structured views and their incremental maintenance. In Proc. of Int. Conf. on Data Engineering (ICDE), Orlando, Florida, February 1998.
БИЗНЕС-МОДЕЛЬ BIZTALK
Учитывая, что эти спецификации документов являются общедоступными и любой желающий может использовать схемы BizTalk бесплатно, вы можете резонно спросить, как Microsoft собирается извлекать прибыль с помощью XML? Ответ прост — за счет продажи инструментария XML.
Как считает Шмидт, главным источником прибыли для Microsoft должен стать серверный продукт для регулирования обмена BizTalk-совместимыми сообщениями XML между партнерами по бизнесу. По его словам, бета-версия этого продукта должна появиться в конце осени 1999 года; готовый же продукт должен выйти после Windows 2000.
Возможно также, что одним из источников прибыли могут стать ориентированные на конкретные рынки оперативные службы (на таких узлах, как Microsoft MSN), где BizTalk будет использоваться производителями для сообщения рыночной службе о предложении новых продуктов и специальных скидок.
Как поясняет Шмидт, если такая оперативная служба появится, то она не будет базироваться на сервере BizTalk, поскольку он предназначен исключительно для целей создания библиотеки и общественного центра, где бы компании и разработчики могли свободно обмениваться идеями. «Мы не рассматриваем biztalk.org в качестве портала для организации сделок между компаниями», — уверяет Шмидт. В настоящее же время основные усилия BizTalk сосредоточены на том, чтобы отраслевые группы приняли BizTalk Framework в качестве общего знаменателя их усилий в области XML.
BizTalk - спасательный круг?
Инициатива BizTalk Framework, продвигаемая Microsoft с партнерами, имеет целью, чтобы отдельные компании, избрав комплект, наиболее подходящий по их задачам и приложениям, смогли без труда "смешивать и фильтровать" XML-сообщения от разных производителей в форматах разных линеек XML-стандартов.
Для этого в BizTalk есть три вещи. Во-первых, можно работать с любой частной группой форматов в "каноническом виде". Во-вторых, по адресу организован общий репозитарий, где линейки совместимых с BizTalk форматов можно проверить на правильность, поместить на хранение, получить и свободно пользоваться. В-третьих, создателей совместимых с BizTalk стандартов поощряют сдавать туда и XSLT-конверторы между своими форматами и форматами других.
Идея здесь в следующем: пусть ваша компания подписана на стандарт, совместимый с BizTalk (A). Вы создаете интерфейсы между своими системами и A. Ваш бизнес-партнер подписан на другой стандарт (B), так же совместимый с Biztalk. Пользуясь XSL-конвертором a2b (доступным в репозитарии Biztalk), вы отправляете XML-сообщения в стандарте A, который ваш партнер конвертирует для "понимания" в B. И если "под зонтиком" BizTalk окажется достаточное число стандартов, вы сможете свободно обмениваться сообщениями с произвольными партнерами.
Путеводная ли это звезда для вашей компании? Можно ли ставить на то, что мощь Microsoft сотоварищи тот гарант, что вы получите полное комплексное решение, необходимое вам и вашим партнерам для работы под зонтиком BizTalk? Можно ли надеяться, что стоит преобразовать сообщения в любой из форматов BizTalk, как BizTalk-конверторы сделают все остальное?
История реляционных БД дает очевидный ответ - "нет", ибо BizTalk-трансляции не решают проблемы "n-квадрата". Аналогично БД, для N форматов "стандартных" сообщений в идеале требуется N(N-1) конверторов. Число стандартов XML-сообщений (N), предложенных для бизнеса, уже более 100 и продолжает расти. Будь вы создателем одного из таких стандартов, стали бы вы тратить время на другие стандарты (конкурентов) с достаточной степенью вникания, чтобы разбираться во всех нужных преобразованиях? Да вы и так завалены работой по сопровождению и адаптации собственных XML-форматов к изменяющимся требованиям бизнеса. А поддерживать еще 30-50 XSLT конверторов - огромная дополнительная нагрузка при минимальной отдаче.
По этой простой причине, не стоит "разевать рот" на plug-and-play совместимость приложений через BizTalk-XML. И строить корпоративную IT- стратегию в расчете на BizTalk не стоит. Решение, позволяющее избежать ловушки N-трансляций несовместимых форматов и устарелых систем - это решение - внутри вашей собственной компании.
Часто задаваемые вопросы
"А здесь - Ваша цитата"
Бьерн Страуструп
Эта глава содержит ответы на самые распространенные вопросы, возникающи при установке описанного программного обеспечения. Пожалуйста, ознакомьтесь с ней.
Q: Apache установился и запускается нормально, но при попытке открытия какой-нибудь страницы Internet Explorer настоятельно предлагает подключиться к Сети.
A: На вкладке "Соединение " (или "Подключение ") в Свойствах IE установите флажок "Использовать локальную сеть ", даже если ее у Вас нет.
Q: При запуске окно Apache открывается и тут же закрывается, сервер из браузера "не виден".
A: Скорее всего, синтаксическая ошибка в httpd.conf. Посмотрите, что пишется в файле f:/usr/local/apache/logs/error.log - скорее всего, там будет указана строка, в которой произошла ошибка.
Q: Ни один скрипт не работает - при запуске открывается маленькое окошко MS-DOS, в нем быстро пробегают строки, и потом оно закрывается.
A: Эта ошибка часто возникает при использовании различных некорректно написанных резидентных антивирусных сторожей (например, SpiderGuard от Dr.Web ). Боюсь, Вам придется от них отказаться.
Q: Виртуальные хосты (а иногда и обычный, основной хост) из браузера недоступны ни по имени, ни по ip-адресу.
A: Эта проблема часто возникает на компьютерах, объединенных в локальную сеть и совместно использующих одно подключение к Интернету. Обычно в таких случаях используется WinGate - программа, обеспечивающая этот совместный доступ. В ней-то и заключена вся проблема. Сделайте следующее: выберите какой-нибудь браузер, которым Вы реже всего пользуетесь (например, Netscape ), и поставьте в настройках WinGate для его запускаемого файла (в нашем примере - netscape.exe) режим локального доступа. В этом случае Вы сможете работать с локальным Apache через этот (и только этот) браузер. Это не очень приятно, но, боюсь, другого решения для WinGate не существует...
Q: Меня не устраивает указанная в статье версия Perl - уж очень древний...
A: Не проблема установить новый, если Вы уже настроили старый. Для этого проделайте следующее:
Скачайте с MS Installer (он лежит в разделе Downloads , рядом с самым свежим Перлом) и запустите его.
Скачайте оттуда же perlxxxx.msi (xxxx зависит от версии Perl, рекомендую Вам поставить самую наисвежайшую).
"Снесите под корень" старый Перл.
Запустите "start perlxxxx.msi" из окна DOS.
Выберите полную установку, и директорию - f:/usr/local (без bin!), и пусть он пропишет в autoexec.bat то, что хочет.
В дистрибутив включена полная документация, включая описания стандартных пакетов.
Q: Никак не могу установить поддержку MySQL в Perl...
A: Проделайте следующее:
Установте самый свежий Perl, как это было только что описано.
Подключитесь к Интернету и запустите ppm.bat из директории с Perl.
Наберите help. Наберите "install DBI" Наберите "install DBD::Mysql"
Q: А как бы мне поставить PHP4?
A: Боюсь, это очень сложная задача. Насколько нам известно, пока не существует такой версии PHP4, которая бы так же легко, как PHP3, установилась под Windows. Впрочем, можем дать один совет: поставьте сначала PHP3, а уж затем поверх - PHP4 (в ту же самую директорию), и молитесь...
Q: Я сделал все, как описано в статье, но...
A: .
3 ноября 2000, 17:21
, ©2000
Что скачивать
Итак, залезаем на , Perl for Win32, скачиваем Pw32i316.exe (примерно 1,5 Мб; 316 - номер версии, в дальнейшем вероятно, появится 317 и т.д. ). Cкачиваем там же PIISi316.exe (примерно 80 Кб; 316 - опять номер версии; он должен быть у обоих файлов одинаков)- это Perl for ISAPI.
Что такое динамический Web-сайт?
Каждая отображаемая страница динамических Web-сайтов основана на шаблонной странице, в которую вставляется постоянно меняющееся информационное наполнение, которое обычно хранится в базе данных. Когда пользователь запрашивает страницу, соответствующая информация извлекается из базы, вставляется в шаблон, образуя новую Web-страницу, и пересылается Web-сервером в пользовательский браузер, который и отображает ее должным образом. Кроме информационного наполнения, динамически могут создаваться также и элементы навигации по Web-сайту. Таким образом, если вам нужно обновить содержимое своего сайта, вы просто добавляете текст для новой страницы, который затем вставляется в базу данных с помощью определенного механизма. В результате получается, что Web-сайт как бы сам себя обновляет.
Что такое статический Web-сайт?
Перед тем, как погрузиться в разработку динамического Web-сайта, важно понять, что представляют собой статический Web-сайт и статические Web-страницы, составляющие его основу. Статические Web-страницы создаются вручную, потом сохраняются и загружаются на сайт. Всякий раз, когда требуется изменить содержимое такой страницы, пользователь модифицирует ее на своем рабочем компьютере, применяя, как правило, HTML-редактор, сохраняет ее и затем заново загружает на Web-сайт. Внимательно присмотревшись к какому-нибудь порталу, допустим к CNN.com или BBC.co.uk, можно подумать, что для обновления содержимого своих сайтов эти компании привлекают армию верстальщиков. На самом же деле существует лучший способ — использование концепции динамического Web-сайта.
Что такое технология Curl?
Технология Curl позволяет разрабатывать и интегрировать новое поколение Web страниц и приложений, предоставляя функциональность и возможности полноценной программы. Сердцем технологии является язык представляния содержимого, специально разработанный для использования в Web, предоставляющий функциональность написания скриптов, объектно-ориентированную модель программы и функиональность интерфейса в одной интегрированной среде разработки. Curl может использоваться также с уже существующими технологиями, такими как HTML, CGI и средствами мультимедиа анимации. Поскольку интернет эволюционирует, он должен становится все более и более интерактивным, так же как и приложения на ПК. До текущего момента технологии в этой области развивались практически только в области технологий, исполняемых на Web серверах. Технология же Curl была создана непосредственно для Web приложений, исполняющихся на клиентских ПК.
Curl Corporation предлагает альтернативный подход, когда Web приложение взаимодействует с Web не с помощью статичного документа, но с использованием среды приложений на стороне устройства клиента, например, такого как ПК. Такой подход не нуждается в обращениях к Web серверу. Текст, графика, программный код и элементы ООП объединены и унифицированы, что позволяет минимизировать обращения к содержимому Web и, тем самым, повысить "отклик" на обращения к интерфейсу. Как это происходит? Во-первых, через создание полноценного содержимого Web. Во-вторых, с помощью использования вычислительных ресурсов клиента, который как правило 90% времени проводит в ожидании "отклика" от интернет ресурса.
Что в имени твоем?
Расширяемый язык разметки (Extensible Markup Language, XML) позволяет вам создавать свои собственные теги, документировать их с помощью определений типов документов (Document Type Definition, DTD) или схемы XML и затем без проблем обмениваться данными с другими источниками. Все это хорошо, но может оказаться, что другие используют те же самые, что и вы, имена для элементов и атрибутов, но при этом опираются на иные DTD.
Обращаясь к популярному примеру с книжным магазином, почти наверняка и Know Knew Books, и Amazon.com будут использовать теги с такими именами, как author (автор), title (название), isdn и price (цена). В то же время маловероятно, что они станут использовать те же самые DTD. Это прямой путь к проблемам.
Во избежание подобных конфликтов W3C разработал концепцию пространств имен и ключевого слова xmlns. Благодаря им в одном документе могут использоваться имена элементов и атрибутов, которые иначе вступили бы в конфликт друг с другом. Теперь же они различаются разными префиксами пространства имен и определяются по различным DTD или схемам.
Вот, например, фрагмент кода XML с использованием пространств имен:
Network Magazine
В определении DTD магазина А название книги является подэлементом журнала. В схеме магазина Б название является атрибутом журнала.
Благодаря различению имен с помощью разных префиксов пространств имен они могут применяться вместе. Местонахождение DTD и схемы указывается в данном примере с помощью URL, но оно может также определяться с помощью Uniform Resource Name (URN, см. RFC 2141) или Uniform Resource Identifier (URI, см. RFC 2396).
CIM
Цель CIM — в описании управляющих данных стандартным образом. Она позволяет отображать другие схемы управления, в том числе базы управляющей информации SNMP, форма-ты управляющей информации DMI и базы управляющей информации CMIP, на свои структуры данных. CIM можно рассматривать как своего рода словарь данных для управления системами и сетями, предоставляющий пометы для объектов, атрибутов, взаимоотношений и действий и документирующий, как эти свойства соотносятся друг с другом.
CIM состоит из спецификации CIM и схемы CIM. CIM Specification содержит соглашения об именовании, методы отображения и метасхему, устанавливающую правила определения схем. CIM Schema имеет три уровня: базовая схема (Core Schema), общие схемы (Common Schema) и расширяющие схемы (Extension Schema).
Core Schema содержит наиболее общие элементы всех видов управляемых объектов, а Common Schema наследует все элементы Core Schema. Общих схем всего пять: Application, System, Device, Physical и Network.
Допускаемые спецификацией CIM схемы Extension Schema не являются, строго говоря, частью CIM Schema. Они, однако, наследуют элементы общих схем и, как следствие, базовой схемы.
Как считают в DMTF, базовая схема вряд ли в дальнейшем будет подвергаться каким-либо изменениям, тогда как общие схемы вполне могут редактироваться для внесения в них усовершенствований. Иерархическая и наследуемая структура CIM Schema гарантирует упорядоченность расширений и обеспечивает обратную совместимость с более ранними реализациями CIM.
CIM — это модель данных. Она не привязана к какому-либо конкретному языку программирования или протоколу, тем более — к какому-либо поставщику. Одной из ее наиболее сильных сторон как раз и является то, что практически все поставщики сетевых устройств, серверов, офисных настольных систем, ОС, периферии и управляющих приложений своей поддержкой DMTF поддерживают и CIM. Схемы CIM могут быть представлены в виде текстовых файлов, структурированных в соответствии с форматом управляемых объектов (Managed Object Format, MOF), и графически в файлах Visio (или любой другой графической программы, если она в состоянии отобразить файлы MOF на устройства и связующие линии).
Пример представления схемы можно увидеть на
Ключевым фактором для реализации управляющих приложений с использованием данных CIM является менеджер объектов CIM (CIM Object Manager, CIMOM). CIMOM — это своего рода центральный диспетчерский и вспомогательный процесс, он служит посредником между управляющими приложениями или консолями, хранилищем данных и индивидуальными источниками данных. Скорее всего, CIMOM будет зависим от конкретной ОС в целях достижения наивысшей производительности и удобства доступа к низкоуровневым событиям. Однако менеджеры CIMOM будут доступны программистам с помощью различных языков, а кроме того, они смогут поддерживать различные модели объектов, если так решит разработчик.
Первым доступным для разработчиков управляющих приложений менеджером стал CIMOM для 32-разрядных сред Windows — Windows 95, Windows NT 4.0 и Windows 2000. В этом нет ничего удивительного, поскольку Microsoft была инициатором проекта CIM.
Windows Management Instrumentation (WMI) состоит из CIMOM, хранилища объектов CIM и интерфейса с различными провайдерами объектов — посредниками между источниками управляющих данных и CIMOM. WMI поставляется с провайдерами объектов для SNMP, Windows Registry, Windows Event Log, Win32 Driver Model и др. Управляющие приложения и Microsoft Management Console могут обращаться к CIMOM с помощью объектной модели COM+, но Microsoft обещает реализовать доступ и с помощью других объектных моделей.
Прежде чем вы решите, что CIM — это часть всемирного заговора Microsoft, я спешу сообщить, что Sun Microsystems представила CIMOM для Solaris — для платформ SPARC и Intel. В ее поддержке CIM также нет ничего удивительного, так как Sun находится среди активных членов DMTF.
Программное обеспечение Solaris WBEM Services включает CIMOM; компилятор MOF, способный производить грамматический разбор операторов ASCII MOF и добавлять объектные классы и экземпляры в хранилище CIM; Solaris Schema, состоящую из классов Java, описывающих управляемые объекты в Solaris Operating Environment; Solaris Provider, обеспечивающий взаимодействие с Solaris Operating Environment и CIMOM.Sun также представила комплект для разработки программного обеспечения Sun WBEM, предоставляющий клиентские и провайдерские API, образцы исходного кода, приложение CIM Workshop на базе Java и документацию.
Данные для примеров
Чтобы проиллюстрировать запросную модель данных и обеспечить основу для последующих примеров, рассмотрим небольшую базу данных, содержащую данные интерактивного аукциона и основанную на Use Case R [12]. Эта база данных содержит два XML-документа с именами items.xml и bids.xml .
Документ items.xml содержит корневой элемент с именем items , который, в свою очередь, содержит элемент item для каждого из товаров, предложенных к продаже на аукционе. Каждый элемент item имеет атрибут status и подэлементы с именами itemno, seller, description, reserve-price и end-date . Элемент reserve-price указывает минимальную продажную цену, установленную владельцем товара, а end-date определяет дату окончания торгов.
Документ bids.xml содержит корневой элемент с именем bids , который, в свою очередь, содержит элемент bid для каждой ставки, которая предлагается за товар. Каждый элемент bid имеет подэлементы с именами itemno , bidder , bid-amount и bid-date .
Рис. 1. Представление модели данных из items.xml
На рис. 1 и 2 показаны модельные представления документов items.xml и bids.xml соответственно (включающие только образцы товара и ставки). Круги, помеченные буквами D, E, A и T, обозначают узлы документов, элементов, атрибутов и тестов соответственно.
Рис. 2. Представление модели данных из bids.xml
Динамический Web-сайт
КомпьютерПресс 6'2001
Изо дня в день работая над обновлением содержимого своего Web-сайта, насыщая его интересными материалами, вы, вероятно, задумываетесь о том, что ежедневно создаются сотни новых Web-сайтов, которые также ежедневно пополняются сотнями новых документов. Как создаются все эти новые массивы страниц и каким образом они так быстро обновляются? Все это не так сложно, как кажется на первый взгляд, поскольку здесь используется концепция динамических Web-страниц.
В этой статье мы рассмотрим этапы создания механизма публикации на Web-сайте пресс-релизов. Наш сайт будет соединять «на лету» пресс-релизы, хранящиеся в базе данных, с шаблонными Web-страницами. Мы не ставили целью ознакомить читателей с основами средств разработки Web-сайтов, поскольку об этом написано множество книг и статей. Данная статья предназначена в основном для тех пользователей, которые уже имеют опыт создания Web-страниц и простых сайтов. Наша главная цель — показать, как начать разрабатывать свой первый динамический Web-сайт. Для понимания статьи желательно иметь базовые знания об архитектурах информационных систем, о языке разметки гипертекста (HTML) и языке программирования Perl . Для создания этого сайта мы воспользуемся тремя мощными открытыми технологиями: Apache, MySQL и Perl/DBI.
Дистрибутивы и ссылки
"А не послать ли нам гонца?.."
Кинорежиссер
Вот программы, на которые ссылается данная статья:
Возможно, Вас не устроят версии некоторых из этих дистрибутивов. Поэтому я привожу список ссылок на сайты, на которых всегда можно найти самые свежие версии программных продуктов. Однако прежде дам совет: не гонитесь за новизной, часто она бывает избыточна и привносит только новые ошибки и проблемы. Прежде чем ставить что-то более новое, рекомендую (особенно начинающим) проделать описанные в статье действия для указанных в ней дистрибутивов. Итак:
Официальный сайт Apache: Официальный сайт PHP: Официальный сайт Active Perl: Официальный сайт MySQL:
И еще несколько ссылок:
Полезная информация об Apache: Всероссийский клуб вебмастеров: Клуб разработчиков PHP: Ну и, конечно, Лаборатория dk:
Дизайн оптимизированных страниц
William Richard
Если у вас не соединение Т1, то, наверняка, вы знаете, что такое сайт, который, кажется, будет загружаться вечно. Вебмастеру сайта необходимо позаботиться о скорости загрузки страницы даже при плохом соединении. Красота страницы не имеет смысла, если пользователь десятками секунд ждет ее загрузки.
Можно предпринять ряд мер по уменьшению размера страницы:
Добавление функциональности
Не представляет особых сложностей добавление функциональных возможностей к механизму публикации пресс-релизов. Можно отсортировать ссылки на доступные в базе данных пресс-релизы по дате или названию, группируя их по годам. Или, например, вы захотите отобразить случайный пресс-релиз на вашей Web-странице, время от времени предоставляя его информацию посетителям независимо от того, когда он был реально опубликован. Но скорее всего самой важной и полезной функциональностью будет добавление HTML-формы для ввода содержимого пресс-релиза и разработки CGI-программы на Perl в целях обработки этой формы и последующего размещения документа в базе данных. Напомним, что CGI (Common Gateway Interface) — протокол, механизм, или формальное соглашение между Web-сервером и отдельной программой. Сервер кодирует входные данные, например HTML-формы, а программа CGI декодирует их и генерирует поток выходных данных. В спецификации протокола ничего не сказано о каком-либо определенном языке программирования. Поэтому программы, соответствующие этому протоколу, могут быть написаны практически на любом языке — на C, C++, Visual Basic, Delphi, Tcl, Python или, как в нашем случае, на Perl.
Подведем некоторые итоги. Надеемся, что эта статья поможет вам оценить преимущества концепции динамических Web-страниц перед статическими. Применение данной концепции приведет к сокращению ручной работы, поможет распределить рабочую нагрузку сервера и позволит быстро увеличить количество информационного наполнения сайта. Комбинация из Apache, MySQL и Perl предоставит практически бесплатную, простую в использовании, гибкую в установке и настройке кросс-платформенную и масштабируемую среду разработки. Здесь мы не будем рассматривать особенности их установки, так как, во-первых, на это попросту не хватит места, отведенного для данной статьи, а во-вторых, каждое из этих средств поставляется вместе с весьма подробной документацией.
Дополнительная информаци
Apache
Apache позиционируется на рынке как мощный и гибкий Web-сервер, совместимый со стандартом HTTP/1.1. Примерно 60% всех Web-серверов в Интернете функционируют под управлением Apache. Функциональность Apache можно легко увеличить, установив свободно распространяемые модули расширения. Исходные коды этого Web-сервера доступны практически для любой платформы. Еще одной его полезной особенностью является тот факт, что Apache позволяет работать с множеством языков программирования, а также загружать некоторые из них в свое адресное пространство, увеличивая таким образом скорость взаимодействия Интернет-пользователя с системой.
MySQL
MySQL — кросс-платформенная система управления реляционными базами данных (RDBMS, Relational DataBase Management System) с использованием языка запросов SQL (Structured Query Language). Сначала MySQL, как и Apache и даже Perl, выпускалась только в версии для UNIX-систем, поэтому до сих пор сохраняет интерфейс командной строки. Однако за последнее время выпущено огромное количество графических менеджеров, которые облегчают задачи администрирования. Кроме того, в поставку MySQL для Linux и Windows входит менеджер, графический интерфейс которого схож с тем, что использует оконный менеджер KDE в оболочке X Window ОС Linux.
Perl, или PERL
PERL (Practical Extraction and Report Language) — язык, который был разработан главным образом для синтаксической обработки текста. Однако в последние несколько лет благодаря новым и модулям расширения, он применяется не только как текстовый обработчик, но и как мощный инструмент разработки Интернет/Интранет-приложений и Web-роботов. Интерпретатор Perl поставляется, как правило, вместе с исходными кодами, которые могут быть скомпилированы практически на любой платформе — DOS, OS/2, UNIX или Windows.
Полезные ссылки
Apache:
MySQL:
Perl:
Web-сайт автора:
Исходные тексты к статье с примерами использования библиотек DBI и Win32::ODBC и шаблонные HTML-страницы:
Дорога к храму
Инициатива BizTalk - не единственная в попытках навести порядок среди множащихся XML-приложений промышленного сектора. Другие проекты, типа или , тоже предлагают общие репозитарии с описаниями XML-форматов - с желанием свести все в общий бизнес-словарь, дабы нивелировать N-квадратную сложность проблемы конвертирований.
Каждая из этих "над-стандартных" инициатив имеет целью справиться со сложностью множества XML-диалектов. Однако, аналогично шансам самих диалектов, сейчас трудно прогнозировать шансы конкретных инициатив вырваться вперед или одержать победу на финише. Ни один репозитарий не сможет решить проблему N-квадратных конвертирований для всех сфер деятельности, пока в нем не будет общей модели всех бизнес-данных (согласованной с участниками), играющей роль общего эсперанто. Однако шансы на создание такой мощной информационной модели, непротиворечивой и полной, согласованной по странам и промышленным секторам, и чтобы она затем эффективно поддерживалась, крайне малы.
Потому можно не возлагать особых надежд на успех всех этих кросс-промышленных инициатив. Вместо этого, любой компании по силам разработать свою собственную информационную бизнес-модель на основе специфики своего бизнеса, чтобы проводить через нее все XML-трансляции. Это вполне по плечу, а отдача придет уже через месяц-другой. Такая модель резко упростит ваш интерфейс с изменчивым и непредсказуемым внешним миром. В то же время, этот "course of action" ни в коей мере не препятствует использованию BizTalk или любого другого XML-репозитария, когда (и если вдруг) он окажется победителем.
Об авторе: Robert Worden - консультант по архитектуре информационных систем и е-бизнесу в Charteris Ltd, London
Доступ к базам данных из Java-программ и проблемы русификации
С. Б. Дунаев
Статья написана автором в октябре 1997 г и опубликована в ж-ле СУБД №1-1 1998
Другие подтипы типа Application
Ожидается, что многие подтипы типа 'Application' будут введены в будущем. MIME-совместимые почтовые программы должны интерпретировать любой незнакомый им подтип как эквивалент 'application/octet-stream'.
Формальный синтаксис дла поля 'content-type' для данных типа 'application' дается следующим образом. application_тип := "application" "/" application_подтип application_подтип := ("octet-stream" *stream_параметр) / "postscript" / расширение (непредопределенный под- тип) stream_параметр := (";" "type" "=" значение) / (";" "padding" "=" число_дополняющих_битов) число_дополняющих_битов := "0" / "1" / "2" / "3" / "4" / "5" / "6" / / "7"
Другие подтипы типа "multipart"
В будущем ожидается введение новых подтипов. Программистам рекомендуется интерпретировать незнакомые подтипы типа 'multipart' аналогично "multipart/mixed".
Формальный синтаксис поля Content-Type для данных типа "multipart": multipart-тип := "multipart" "/" multipart-подтип ";" "boundary" "=" метка_границы multipart-подтип := "mixed" / "parallel" / "digest" / "alternative" / подтип-расширение
Полный пример Multipart-письма
Данный пример иллюстрирует письмо из пяти частей: две - простой текст, одна - вложенное multipart-письмо, одна - размеченный текст и одна - вложенное письмо, содержащее текст в не-US-ASCII языковой кодировке. Третья часть (вложенное multipart-письмо) состоит из двух частей, требующих параллельного представления пользователю, - графическое изображение и звуковой фрагмент. MIME-Version: 1.0 From: Nathaniel Borenstein To: Ned Freed Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1 Это область преамбулы multipart-письма. Почтовые программы, понимающие формат multipart, должны игнорировать все, что в ней находится. Если же вы при получении подобного письма видите этот текст на экране, вам следует сменить почтовую программу. --unique-boundary-1 ...Здесь находится некоторый текст... [Обратите внимание, что предшествующая пустая строка означает, что поля заголовка не были заданы, и это - простой текст в языковой кодировке US ASCII.] --unique-boundary-1 Content-type: text/plain; charset=US-ASCII Это часть предыдущей части, но иллюстрирующая ясную, а не подразумеваемую типизацию содержимого. --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64 ... кодированный в base64 одноканальный звуковой фрагмент для час- тоты 8000 Hz в формате mu-law.... --unique-boundary-2 Content-Type: image/gif Content-Transfer-Encoding: base64 ... здесь находится кодированное в base64 графическое изображение.... --unique-boundary-2-- --unique-boundary-1 Content-type: text/richtext Это текст с разметкой в соответствии с определением RFC 1341 Неправда ли, он крут? --unique-boundary-1 Content-Type: message/rfc822 From: (имя отправителя в US-ASCII) To: (адрес в US-ASCII) Subject: (subject в US-ASCII) Content-Type: Text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable ... Некоторый текст в ISO-8859-1 ... --unique-boundary-1--
Двухступенчатое преобразование XML-документа
В предыдущей главе рассказывалось об одном из способов организации состава клиентской части XML/EDI. Основным недостатком построения клиентской части по схеме одноступенчатого преобразования является "мануальностью" системы, т.е. система является не автоматической: Пользователь из Компании 1 (см. рис 5) должен взять из информационной системы своей компании информацию и в ручную заполнить форму Браузера, которая формирует XML документ (На рис. 5 для наглядности изображено два разных компьютера, один из которых является частью Intranet компании, и другой, который посредством WEB browser формирует XML документ).
Рис. 5
Компания 2, где расположена серверная часть, осуществляет автоматическую обработку XML-документа, без непосредственного участия человека. Было бы целесообразно, организовать обмен электронными документами таким же образом и на отправляемой стороне, т.е. чтоб человек мог только контролировать передачу документов, не осуществляя каких-либо ручных операций по заполнению HTML-форм.
Так на рис. 5, изображена топология внутреннего взаимодействия в Компании 3, где оператор со своего рабочего места вносит необходимые данные в информационную систему своей компании, которая автоматически, при определенных условиях, формирует XML-документ и отправляет его адресату.
Такая организация передачи электронных документов возможна разными способами: использование встроенных в HTML файл объектов ActiveX или написание специальных Java программ, которые реализовывали бы серверные обмены.
Другой из возможных вариантов построения системы XML/EDI - является использование двухступенчатого формирования электронного документа. На рис. 6 представлена схема двухступенчатого преобразования XML документа в EDI-сообщение.
Рис.6
На первом этапе, осуществляется преобразование XML-источника, используя XSL-преобразование стандартным XSL-анализатором, в формат метаданных XEDI.. По своей сути, формат метаданных XEDI - является своего рода новым языком, описанного языком разметки.
Второй этап заключается в прямом преобразовании метаданных XEDI транслятором XML/EDI непосредственно в EDI-сообщение. Аналогичный процесс, но уже в обратном порядке, происходит при конвертации EDI-сообщения в XML-документ.
Преимущество идеи двухступенчатого преобразования в том, что метаданные XEDI описывают любые виды EDI-сообщений в соответствии с XEDI синтаксисом. Одноступенчатое преобразование применяется в основном в системах, использующих один тип сообщения.
Ниже будут изложены предложения XML-EDI Group, заложенные в преобразование метаданных.
Сообщение UN/EDIFACT можно разобрать на следующие самостоятельные единицы, вложенные друг в друга:
Сообщение Группа сегментов Сегмент Группа Элементов данных Элемент данных или Квалификатор
Каждой самостоятельной единице будет соответствовать свой элемент XML (элемент метаданных XEDI). Можно выделить следующее соответствие EDI-XML:
Сообщение
Группа сегментов
Сегмент
Группа Элементов данных
Элемент данных Квалификатор
Каждый элемент XML имеет определенный набор параметров, которые содержат информацию. Возвращаясь к нашему примеру, Все содержание EDI-сообщения INVOICE будет обрамлено следующими тагами:
<Message Name="INVOICE">
..... сегменты и группы сегментов, составляющие сообщение ...
Message >
Значение атрибута Name для тага представляет имя EDI-сообщения. Для упрощения синтаксического анализа и сохранения наглядности документа вводится таг , который обрамляет повторяющиеся группы сегментов:
<Message Name="INVOICE"> <Segment Name="UNH"> Segment >
<Segment Name="BGM"> Segment >
<Segment Group> <Segment Name="LIN"> Segment > <Segment Name="IMD"> Segment > Segment Group> Message >
Каждый сегмент содержит группу элементов данных, в соответствии со справочником сегментов EDSD, который входит в набор стандартов UN/EDIFACT. Например, в соответствии со справочником EDSD, сегмент NAD (имя и адрес) имеет следующие описание:
№ группы Код справочника Описание данных Усл/обяз формат
010 3035 КВАЛИФИКАТОР УЧАСТНИКА M an..3
020 C082 ОСОБЕННОСТИ ИДЕНТИФИКАЦИИ УЧАСТНИКОВ C
3039 Идентификация участников M an..35
1131 Квалификатор контролирующего органа C an..3
3055 Код контролирующего органа C an..3
030 C058 НАЗВАНИЕ И АДРЕС С
3124 Строка имени (названия) и адреса M an..35
3124 Строка имени (названия) и адреса C an..35
040 C080 НАЗВАНИЕ УЧАСТНИКА С
3036 Название участника M an..35
3036 Название участника C an..35
3045 Код названия участника C an..3
050 С059 УЛИЦА C
3042 Улица и номер п.я. C an..35
3042 Улица и номер п.я. C an..35
060 3164 НАЗВАНИЕ ГОРОДА C an..35
070 3229 ИДЕНТИФИКАЦИЯ РЕГИОНА C an..9
080 3251 ИДЕНТИФИКАЦИЯ ПОЧТОВОГО КОДА C an..9
090 3207 КОД СТРАНЫ C an..3
Возвращаясь к нашему примеру, кодировка в UN/EDIFACT NAD+SE+++OY Valio++ Helsinki++Box 789+Fi' будет преобразована в:
<Segment Name ="NAD"> id=10 dic=3035> SE
id=40> OY Valio
id=60> Y=Helsinki
id=80> Box 789
id=90 dic=3207> FI
Атрибутом тага id - является номер группы в справочнике элементов данных, а атрибут dic - номер справочника, по которому определяется квалификатор.
Элементы данных могут быть простыми и составными, состоящими из компонентов. Составные элементы данных объединяются тагами . Например, сегмент цена: PRI+INV:180' содержит составной элемент данных, включающий квалификатор INV (цена по инвойсу) и значение цены - 180:
="PRI"> id=10> id=1 dic=5125> INV
id=2 dic=5118> 180
В данном примере таг имеет аттрибут id , который имеет значение положения составного элемента по справочнику EDCD. Значения id тага представляет относительное месторасположение в справочнике сегментов.
Преобразование XML документа в метаданные осуществляется посредством обработки XQL-запросов анализатором XSL. Ниже представлен текст запроса для преобразования EDIFACT элемента PRI (таг ) в XEDI метаданные:
xsl:for-each select="//Price"> ="PRI"> id=10> id=1 dic=5125> INV
id=2 dic=5118> select="//Price"/>
Таг определяет область действия шаблона XSL фильтра, а таг определяет область шаблона, на которую распространяется данный запрос. Параметр select определяет область действия запроса в соответствии с синтаксисом запроса. Таг осуществляет подстановку результата.
Синтаксис строки запроса схож с обычным способом определения пути к ресурсу- список узлов дерева, разделенных символом /.
Для выделения всех дочерних элементов - используется символ "*", для выделения элемента, расположенного просто "ниже" по дереву(на любом уровне вложенности) символ - "//". Условие на значение в запросе должно заключаться в символы "[" и "]". Для выбора значения атрибута в условии указывается символ @.
Примеры простых шаблонов:
" Transaction/" возвращает дочерние элементы для элемента Transaction
"Consignor//" список всех элементов, вложенных в Consignor
"SegmentName[@Id]" список элементов SegmentName, в котором определен атрибут Id
"SegmentName [@Id=2]" поиск всех тагов, которые имеют значение атрибута id равное 2
При формировании ответа на сообщение обратное преобразование из метаданных в XML-документ, осуществляется с помощью следующего шаблона:
xsl:for-each select="//Segment/"> select=" Segment[@Name="PRI"]/DataElement[@Id="2"]"/>
Данный запрос интерпретируется как: выбрать все значения из тагов ;, имеющие значение параметра Id="2", и которые имеют вхождение в таги со значением параметра Name="PRI".
Выполнение более сложных запросов, например, при формировании метаданных для сегмента NAD осуществляется, учитывая уровни вложенности:
xsl:for-each select="//Consignor"> ="NAD"> id=10 dic=3035> SE
id=40> select="//Consignor/ConsignorName"/>
id=50> select="//Consignor/Address/Street"/>
id=60> select="//Consignor/Address/City"/>
id=80> select="//Consignor/Address/Zip"/>
id=90 dic=3207> select="//Consignor/Address/Country"/>
В заключение хочется отметить, что предлагаемый способ формирования XEDI метаданных находится на стадии утверждения. В настоящее время в XML-EDI Group находится на рассмотрении предложения по комбинированному формированию метаданных, при котором используется конверсия не только стандарта UN/EDIFACT, но и не менее популярного в США и Германии стандарта формирования электронных документов ANSI X12.
Автор будет очень благодарен за отзывы об актуальности темы, общем содержании, виде и стиле изложения, а также всем остальным комментариям, которые помогут в дальнейшем улучшить качество написания сборника статей и выпуску книги освещающую тему использования электронных документов. Также автору будет интересно узнать пожелания читателей об освещении смежных тем, связанных с использованием электронных документов и электронной коммерции. Свои комментарии и пожелания просьба направлять на Автор постарается ответить на вопросы, связанной с изложенным материалом или осветить их в будущем.
Форматирование текста
br p table tr td
Каждый из этих элементов может быть использован в документе используя следующий синтаксис.
<элемент> значение элемента элемент>
Если элемент не содержит внутри себя какую либо информацию (обычно такое случается с элементом форматирования ), вы можете использовать тэг с добавленным к нему "/" (например ).
Ftp
Команда ftp позволяет переносить файлы с локального компьютера на удаленный и обратно. Формат команды:
ftp [ remote_host ]
После установления соединения вы получаете приглашение ftp> , означающее, что система ждет команды ftp. В ответ вы можете ввести команды для работы с файловыми системами локального или удаленного компьютера, или изменить настроечные параметры утилиты ftp.
ftp> ?
Commands may be abbreviated. Commands are:
! delete mdelete proxy runique
$ debug mdir sendport send
account dir mget put size
append disconnect mkdir pwd status
ascii form mls quit struct
bell get mode quote system
binary glob modtime recv sunique
bye hash mput remotehelp tenex
case help nmap rstatus type
cd image nlist rhelp user
cdup lcd ntrans rename verbose
close ls open reset ?
cr macdef prompt rmdir bsize
ftp> quit
%
Функции
В XQuery предусмотрена библиотека предопределенных функций [11], а также предоставляется возможность определения пользователями их собственных функций. При вызове аргументы связываются с параметрами функции, и выполняется ее тело, порождая результат вызова функции. Если тип параметра функции не указан, этот параметр может принимать значения любого типа. Если не указан тип результата функции, то функция может возвращать значение любого типа.
В следующем примере определена функция с именем highbid , в качестве параметра использующая узел-элемент и возвращающая десятичное значение. Функция интерпретирует свой параметр как элемент item и извлекает номер товара. Затем она находит и возвращает самую крупную ставку (bid-amount ), которая была зафиксирована для товара с этим номером. define function highbid(element $item) returns decimal { max(document("bids.xml") //bid [itemno = $item/itemno]/bid-amount) } highbid(document("items.xml") //item [itemno = "1234"])
Типы, используемые при объявлении типов аргументов и результата в определении функции, могут быть простыми, как decimal , или более сложными типами, например, элементами или атрибутами.
В XQuery не поддерживается перегрузка функций, определенных пользователем, т. е. не допускается наличие двух функций с одинаковыми именами. Тем не менее, некоторые встроенные функции являются перегруженными. Например, функция string может преобразовывать в строку аргумент почти любого типа.
Аргументы при вызове функции должны соответствовать объявленным типам параметров функции. С этой целью аргумент функции числового типа может быть приведен к объявленному типу параметра с помощью иерархии приведения integer -> decimal -> float -> double . Аргумент также считается удовлетворяющим условию вызова, если тип этого аргумента является производным типом (т.е. подтипом) объявленного типа параметра. Если функция, ожидающая атомарное значение в качестве параметра, вызывается с аргументом, являющимся элементом, то до передачи аргумента функции из него извлекается типизированное значение элемента и проверяется на совместимость с ожидаемым типом параметра.
Значение, производимое телом функции, должно также соответствовать возвращаемому типу, объявленному в определении; используются обычные правила проверки соответствия типов параметров.
Следующий пример иллюстрирует, как пользователь может написать функцию, которая предоставляет значение по умолчанию для отсутствующих данных. Функция с именем defaulted принимает два параметра: узел-элемент (возможно, отсутствующий) и значение по умолчанию. Если элемент присутствует и имеет непустое значение, функция возвращает это значение. Если же элемент отсутствует или пуст, функция возвращает значение по умолчанию. define function defaulted (element? $e, anySimpleType $d) returns anySimpleType { if (empty($e))then $d else if (empty($e/_)then $d else data($e) }
С помощь этой функции запрос Q5 можно переписать (здесь отсутствующие или пустые элементы commission и bonus считаются равными нулю). for $e in $emps return { $e/name, | {$e/salary + defaulted ($e/commission,0) + defaulted ($e/bonus,0)} } sortby(pay)
Функция, в теле которой присутствует вызов самой себя, называется рекурсивной (recursive), и две функции, в теле каждой из которых присутствует вызов другой функции пары, называются взаимно рекурсивными (mutually recursive). В следующем примере рекурсивная функция depth может быть вызвана для элемента и возвращает глубину элемента в иерархии, начинающейся с аргумента вызова. Если у элемент-аргумента отсутствуют потомки, глубина иерархии равна единице. Иначе глубина иерархии на единицу больше максимального значения глубины всех иерархий, корнем которых является потомок элемента-аргумента. Это значение вычисляется путем рекурсивного вызова функции depth . define function depth(element $e) returns integer { if (empty($e/*)) then 1 else 1 + max (for $c in $e/* return depth($c)) } depth(document("bids.xml"))
Где их взять?
Самое авторитетное собрание ссылок и информации об органах управления ActiveX - это уже упоминавшаяся "". Однако же галерея - это все-таки не справочник, и энциклопедического охвата ожидать от нее не приходится: из более чем двух тысяч органов управления ActiveX, созданных разными фирмами, в этой галерее представлено всего несколько десятков, из которых большую часть составляют компоненты, авторство которых принадлежит самой корпорации Microsoft.
С другой стороны, именно органы управления, предлагаемые Microsoft, покрывают значительную часть нужд рядового Web-дизайнера, и более чем вероятно, что они будут среди первых по популярности. Поэтому я решил привести здесь их краткие описания.
Animated Button
("Кнопка с мультипликацией")
Воспроизводит определенные фрагменты предусмотренного автором страницы AVI-файла (видеофрагмента) в разные моменты - при нажатии и отпускании кнопки мыши, при прохождении курсора мыши над кнопкой и т.д., а также инициирует соответствующие события.
Chart
("Диаграмма")
Рисует разные виды диаграмм (круговую, гистограмму, график и т.п.) по данным из отдельного файла, предусмотренного автором страницы.
Gradient
("Градиент")
Рисует прямоугольник, заполненный плавным переходом из одного цвета в другой, позволяет задавать направление и конфигурацию перехода.
Label
("Надпись")
Выводит текстовую надпись, позволяет задавать цвет текста и фона, угол базовой линии надписи и даже располагать надпись вдоль произвольной кривой.
Marquee
("Бегущая строка")
В отличие от тега , который поддерживался броузером еще в прошлых версиях, этот орган управления способен прокручивать в отведенном ему прямоугольнике не только отдельные строки, но и целые HTML-файлы - с заданной скоростью, причем как по горизонтали, так и по вертикали. Единственный из всех перечисленных, этот орган управления поставляется вместе с самим броузером Internet Explorer.
Menu
("Меню")
Позволяет размещать в HTML-документе особого вида кнопки, нажатие которых раскрывает меню с заказанными автором командами.
Выбор пользователем одной из команд инициирует соответствующее событие.
Popup Menu
("Всплывающее меню")
Один из методов этого органа управления выводит в любой точке окна всплывающее меню с заказанными автором командами. Обычно всплывающее меню используется в сочетании с другими элементами - например, какой-нибудь орган управления, перехватив щелчок правой кнопки мыши в отведенном ему прямоугольнике, обращается к объекту этого типа, чтобы вывести в точке нажатия контекстное меню.
Popup Window
("Всплывающее окно")
Подобно предыдущему, этот орган управления содержит метод, выводящий на экран всплывающее окно, содержимым которого может быть любой документ с известным URL-адресом. Как и всплывающие окна в системе справки Windows, это окно уничтожается простым щелчком мыши.
Preloader
("Загрузчик")
Этот орган управления, ничего не выводя на экран, занимается тем, что во время бездействия броузера заставляет его перекачивать из сети и сохранять в кэше документ по адресу, указанному автором страницы. Это имеет смысл делать для тех документов, на которые есть ссылки с данной страницы - когда читатель захочет перейти по одной из этих ссылок, он сможет сделать это почти мгновенно, так как нужный документ будет уже дожидаться его в кэше.
Stock Ticker
("Информационное табло")
Предназначен для динамического отслеживания информации. С некоторой периодичностью скачивает информацию из файла, расположенного по заказанному адресу, и выводит ее на экран в виде бегущей строки.
Timer
("Таймер")
С заданной периодичностью инициирует событие, которым могут пользоваться другие объекты или сценарии для выполнения повторяющихся действий.
View Tracker
("Индикатор видимости")
Этот орган управления, который может быть представлен на странице любым - по выбору автора - изображением, инициирует особые события в те моменты, когда из-за прокрутки содержимого окна он выходит из поля зрения и когда он снова становится видимым. Если же органов управления из этого небольшого набора вам будет недостаточно, то весьма представительную базу данных с возможностью поиска и информацией о почти всех существующих на данный момент компонентах ActiveX вы найдете по адресу . Там же хранится множество статей независимых экспертов, справочной информации и полезных ссылок по ActiveX, Java и другим интернетовским технологиям.
Если же вы хотите попробовать силы в программировании своих собственных органов управления ActiveX, то вы можете либо дождаться выхода версии 5.0 языка Visual Basic, в которой фирма Microsoft обещает ввести поддержку этого стандарта, либо вооружиться компилятором Visual C++ и скачать для него (ActiveX SDK).
Графическое меню
По Alt+G пользователю предлагается следующее графическое меню: \hrule
F1 - Записать постскрипт в файл: ps.out
F2 - Изменить выходное имя постскрипт файла.
F3 - Записать код HPGL в файл: hp.out
F4 - Изменить выходное имя файла с кодом HPGL.
F5 - Записать код Textronix 4014 в файл: tek.out
F6 - Изменить выходное имя Textronix файла.
Область видимости сейчас: 0,0,4095,3119
F7 - Установить новую область видимости (* Практически ZOOM)
RETURN - Рисовать графический образ на экране (в текущем увеличении) \hrule
Всю красоту XML можно понять только при сравнении его с HTML. Формализованный в RFC 1866 в 1995 году (хотя, естественно, использоваться он начал раньше), HTML является наиболее популярным языком разметки во всем мире. Термин «разметка» применительно к документу означает обычно все, что не относится к его информационному наполнению. Например, когда эта статья готовилась к печати, редакторы Network Magazine размечали ее (с помощью старой доброй «аналоговой» красной авторучки), вставляя замечания для автора и инструкции для верстальщиков о том, как следует форматировать различные элементы.
Наверняка всем пользователям Web приходилось видеть файл HTML в его исходном виде, где теги форматирования перемешаны с обычным текстом. (Возможно, некоторые из вас вспомнят в этой связи о WordStar, где также использовались в основном парные теги. В дни текстовых мониторов документ мог быть запросто испорчен, когда, вставив открывающий тег для перехода к жирному шрифту или подчеркиванию, вы потом забывали выключить его посредством вставки закрывающего тега в конце слова.)
Главной особенностью разметки HTML является, конечно, возможность вставки ссылок на внешние документы или на внутренние разделы того же самого документа. Стоит заметить, что, хотя HTML чаще всего предоставляется серверами по HTTP, он также может использоваться на CD-ROM или в локальной сети. Универсальные языки разметки не привязаны к какому-либо конкретному транспорту.
HTML преуспел не только как адаптируемый язык разметки, но и в качестве промежуточного программного обеспечения (см. статью Д. Эйнджела «Промежуточное программное обеспечение» в этом номере LAN). Благодаря своей дешевизне и распространенности браузеры Web представляют собой отличных клиентов; при посредничестве HTML они могут общаться с самыми разнообразными серверами.
Однако HTML столкнулся с определенными трудностями. Его ограниченные возможности форматирования пытались преодолеть с помощью CSS, инициативы TrueDoc от Bitstream и конечно же множества специфических расширений для браузера; а его ограниченные возможности в качестве промежуточного ПО — с помощью Java, ActiveX и т. п. Тем не менее все это не устраняет его фундаментальные недостатки.
Имена и адреса машин в сети Internet
Для идентификации машин в сети Internet используются два способа:
Доменное имя машины (хоста), например: vasya или vms.cuny.edu
Интернетовский адрес машины ( IP-address ), например: 194.12.96.11
Первичным способом адресации является способ 2, причем IP-адрес машины является уникальным для всей глобальной сети Internet (они выдаются специальной службой сети, которая и обеспечивает уникальность). Далее, каждая машина имеет свое имя. Узнать имя вашей машины проще всего выдав команду hostname. Ответом будет имя машины. Имя представляет собой либо простое слово, состоящее из не более чем восьми букв (пример: vasya), или ``доменное" имя, состоящее из слов-доменов, разделенных точками (пример: vasya.cuny.edu).
Соответствие между доменным именем и интернетовским адресом машины задается в специальном файле /etc/hosts, который имеет примерно такую структуру:
# file: /etc/hosts
#
#
#
127.0.0.1 loopback # local host
#
#
194.12.96.11 vasya # local host
194.12.96.12 sasha # remote host
194.12.96.13 hydra # remote host
194.12.96.15 hy.cuny.edu # remote host
Итак, если вам требуется указать адрес машины вы вольны оперировать любым из способов адресации. Если вы пользуетесь логическим именем, то машина автоматически преобразует его в IP-формат, пользуясь информацией из /etc/hosts. Отметим следующее важное различие между способами адресации: если вы знаете IP-адрес удаленной машины, то компьютер попытается установить соединение с этим компьютером независимо от того есть такой адрес в /etc/hosts или нет (технически это делается с помощью ``широковещательного" запроса по всей сети). Если вы пользуетесь логическим именем, то оно должно быть описано в /etc/hosts. Из этого правила есть одно исключение: если ваш компьютер обслуживается системой DNS (Domain Name Service), то запрос на ``расшифровку" адреса будет передан DNS-серверу (который, в свою очередь может передать запрос серверу высшего уровня). Для того, чтобы сработала служба DNS необходимо, чтобы логический адрес имел доменную форму (пример: hy.cuny.edu).
Такая система адресации также является уникальной, поскольку полное логическое имя машины образуется из имени локального хоста и имени домена, в котором находится данный хост. Например hy.cuny.edu есть машина с именем hy в домене cuny.edu Нью-Йоркского университета. Таким образом, логическая доменная адресация образует иерархическую структуру, обеспечивающую уникальность каждого такого адреса.
Команды для работы в сети делятся на две группы: утилиты сети DARPA и Берклевские утилиты (которые также называют r -командами). Сие деление вызвано чисто историческими причинами и по функциональным возможностям обе группы команд примерно эквивалентны. Дело в том, что первая группа утилит была создана разработчиками американской военной сети DARPA (из которой со временем и образовалась глобальная сеть Internet). Впоследствии, когда сеть ARPA была передана университетским организациям США, эти утилиты вошли в стандартную поставку сетевого мат. обеспечения TCP/IP. Утилиты второй группы созданы разработчиками самой операционной системы в университете Беркли и могут отсутствовать в других версиях операционных систем.
Итак, если вы знаете имя (адрес) своей машины и адрес машины, с которой вы хотите общаться, вы можете установить сетевое соединение и работать в сети. Однако надо иметь в виду, что, вообще говоря, обе машины должны вас ``знать", то есть вы должны иметь пользовательский доступ к локальной и удаленной машине. Ниже мы подробно обсудим средства сетевой коммуникации.
Интеграция информации
Как утверждалось ранее, WWW содержит все возрастающее число информационных источников, которые могут просматриваться как контейнеры множеств кортежей. Эти "кортежи" могут быть либо встроенными в HTML-страницы, либо быть скрытыми за интерфейсами форм. Благодаря написанию специальных программ, называемых оболочками (wrapper), можно создать иллюзию, что данный Web-сайт обслуживает множества кортежей. Будем называть комбинацию такого Web-сайта и ассоциированной с ним оболочки Web-источником.
Задача системы интеграции информации, поддерживаемой средствами Web, состоит в том, чтобы отвечать на запросы, которые могут потребовать извлечения и комбинирования данных из множества Web-источников. Например, рассмотрим такую предметную область, как кино. Сайт Internet Movie Database содержит исчерпывающие данные о кинофильмах, составе исполнителей ролей, жанрах и руководителях съемки. Во множестве других Web-источников (например, на Web-сайтах большинства газет) могут быть найдены также рецензии на кинофильмы, а некоторые Web-источники предоставляют расписания показа кинофильмов. Комбинируя данные из этих источников мы можем отвечать на запросы типа: выдать мне какой-либо фильм с Фрэнком Синатрой в главной роли, который можно посмотреть сегодня вечером в Париже, время сеанса и рецензии на него.
Для ответов на запросы с использованием множества Web-источников был создан целый ряд систем [GMPQ+97, EW94, WBJ+95, LRO96, FW97, DG97b, AKS96, Coh98, AAB+98, BEM+98]. Многие из проблем, с которыми пришлось столкнуться при их разработке, аналогичны проблемам, связанным с созданием неоднородных систем базы данных [ACPS96, WAC+93, HZ96, TRV98, FRV96, Bla96, HKWY97]. Наряду с этим, системы интеграции данных Web должны иметь дело с: (1) с большим и развивающимся количеством Web-источников, (2) немногими метаданными, характеризующими источники, и (3) большой степенью автономности источников.
Важные различия при построении систем интеграции данных, а, следовательно, и систем интеграции данных Web, возникают в связи с тем, принимается ли подход, основанный на хранилищах данных, или виртуальный подход (см.
для сравнения [HZ96, Hul97]). В случае использования первого подхода данные из множества Web-источников загружаются в хранилище данных, и далее все запросы будут обращены к этому хранилищу данных. В таком случае необходимо, чтобы при изменении данных в источниках обновлялось и хранилище данных. Однако преимущество состоит в том, что может быть гарантирована адекватная эффективность на стадии обработки запроса. При виртуальном подходе данные остаются в Web-источниках, и запросы к системе интеграции данных декомпозируются на стадии исполнения на запросы к отдельным источникам. При таком подходе данные не тиражируются, и тем самым гарантируется их актуальность на стадии обработки запросов. С другой стороны, поскольку Web-источники автономны, для обеспечения адекватной эффективности необходимы более изощренные техника оптимизации запросов и исполнения. Виртуальный подход более уместен при построении таких систем, где число источников велико, данные изменяются часто, и имеется слабый контроль над Web-источниками. По этим причинам большинство исследований недавнего времени было сосредоточено на виртуальном подходе, и поэтому им прежде всего будет посвящено наше дальнейшее обсуждение. Нужно, однако, подчеркнуть, что многие проблемы, которые возникают при виртуальном подходе, возникают также и при использовании хранилищ данных (хотя зачастую и в несколько иной форме). Следовательно, наше обсуждение имеет отношение к обоим указанным случаям. Прежде чем перейти непосредственно к обсуждению, нам хотелось бы обратить внимание читателей на два коммерческих приложения систем интеграции данных Web, в одном из которых был принят подход с хранилищем данных [Jun98], а в другом - виртуальный подход [Jan98].
Архитектура прототипа системы виртуальной интеграции данных показана на рис. 2. Имеется две главных особенности, отличающие такую систему от традиционной системы базы данных:
Как уже говорилось ранее, система не взаимодействует непосредственно с локальными менеджерами хранения данных.
Вместо этого для получения данных механизмы исполнения запросов взаимодействуют с множеством оболочек (wrapper). Оболочка - это специфическая для каждого Web-сайта программа, задачей которой является трансляция данных Web-сайта в форму, позволяющую осуществлять дальнейшую их обработку средствами системы интеграции данных. Например, оболочка может извлекать множество кортежей из HTML-файла. Необходимо подчеркнуть, что оболочка обеспечивает только интерфейс к данным, обслуживаемым рассматриваемым Web-сайтом. Поэтому, если Web-сайт предоставляет только ограниченный доступ к данным (например, через интерфейс формы, который требует от пользователя некоторого ввода), то и связанная с ним оболочка может поддерживать лишь ограниченные виды доступа к данным.
Второе отличие от традиционных систем заключается в том, что пользователь не формулирует запросы непосредственно в терминах той схемы, в соответствии с которой хранятся данные. Такой подход продиктован тем, что одной из важнейших целей систем интеграции данных является стремление к освобождению пользователя от необходимости знания специфических особенностей источников данных и взаимодействия с каждым из них. Вместо этого пользователь формулирует запросы в терминах промежуточной (mediate) схемы. Промежуточная схема - это множество виртуальных отношений, которое проектируется для каждого конкретного приложения системы интеграции данных. Отношения промежуточной схемы фактически нигде не хранятся. В связи с этим система интеграции данных должна прежде всего переформулировать запрос пользователя в такие запросы, которые обращены непосредственно к схемам в источниках. Для выполнения шага переформулирования запроса системе интеграции данных необходимо множество описаний источников. Описание источника информации специфицирует его содержание (например, указывает, что он содержит фильмы), атрибуты, которые могут быть найдены в источнике (например, жанр, состав актеров), ограничения на содержание источника (например, содержит только американские фильмы), полноту и надежность источника, и, наконец, возможности обработки запросов этого источника (например, может выполнять только выборку данных или может отвечать на произвольные запросы SQL).
Рассмотрим теперь основные проблемы, которые исследуются в работах, связанных с созданием систем интеграции данных Web.
Спецификация промежуточной схемы и переформулирование запросов: Промежуточная схема в системе интеграции данных представляет собой совокупность наборов имен атрибутов, которые используются для формулировки запросов. Для обработки запроса система интеграции данных должна транслировать его формулировку в терминах промежуточной схемы в запросы к источникам данных, которые имеют их собственные локальные схемы. Чтобы сделать это, системе необходимо множество описаний источников. Несколько недавних исследований было посвящено проблемам определения принципов спецификации описаний источников и их использования для переформулирования запросов. Вообще говоря, было предложено два общих подхода: Глобальная схема как представление (Global as View, GAV) [GMPQ+97, PAGM96, ACPS96, HKWY97, FRV96, TRV98] и Локальная схема как представление (Local as View, LAV) [LRO96, KW96, DG97a, DG97b, FW97]. Детальное сопоставление этих подходов можно найти в [Ull97].
При подходе GAV для каждого отношения R в промежуточной схеме, мы записываем запрос над отношениями источников, которые определяют, каким образом можно получить кортежи R из источников. Подход LAV является противоположным. Для каждого источника информации S мы записываем запрос над отношениями в промежуточной схеме, который описывает, какие кортежи находятся в S. Главное преимущество подхода GAV состоит в том, что переформулирование запросов является очень простым, поскольку оно сводится к развертыванию представлений. Напротив, при подходе LAV можно более просто добавлять или удалять источники, так как описания источников не должны принимать во внимание возможные взаимодействия с другими источниками, как в случае подхода GAV. В случае LAV, кроме того, более просто описываются ограничения на содержание источников. Проблема переформулирования запросов становится некоторым вариантом проблемы ответа на запросы с использованием представлений [YL87, TSI96, LMSS95, CKPS95, RSU95, DG97b].
Полнота данных в Web-источниках: Вообще говоря, источники, которые мы находим на WWW, не обязательно являются достаточно полными в той предметной области, к которой они относятся. Например, маловероятно, что некоторый источник библиографии в полной мере представляет область информатики. Однако, в некоторых случаях, мы можем высказывать определенные утверждения о степени полноты источников. Например, база данных DB&LP *3) содержит полную подборку работ, опубликованных в трудах наиболее важных конференций по базам данных. Знания о полноте Web-источника могут помочь системе интеграции данных несколькими способами. Наиболее важно, что отрицательный ответ от полного источника является значимым, поскольку он позволяет исключить бессмысленные обращения системы интеграции данных к другим источникам. Проблема описания полноты Web-источников и использования этой информации для обработки запросов исследуется в работах [Mot89, EGW94, Lev96, Dus97, AD98, FW97]. В работе [FKL97] предлагается вероятностный формализм для описания содержания и перекрытий источников информации, а также приводятся алгоритмы оптимального выбора источников.
Различие возможностей обработки запросов: В аспекте систем интеграции данных Web, Web-источники имеют, как представляется, в значительной степени различные потенциальные возможности обработки запросов. Главные причины таких различий заключаются в том, что: (1) внутренние данные источников могут фактически храниться в структурированных файлах или в унаследованной системе, и в таких случаях интерфейс к этим данным, естественно, ограничен, и (2) даже если данные хранятся в традиционной системе базы данных, Web-сайт может обеспечить лишь ограниченные возможности доступа по причинам безопасности или эффективности.
Для создания эффективной системы интеграции данных эти возможности должны явным образом описываться для системы, строго учитываться и в максимально возможной степени использоваться для повышения эффективности. Будем различать два типа возможностей: отрицательные возможности, которые ограничивают способы доступа к данным, и положительные возможности, когда источник способен выполнять некоторые алгебраические действия в дополнение к простым выборкам данных.
Основная форма отрицательных возможностей - ограничения на способы связывания (binding patterns), которые могут использоваться в запросах, адресованных источнику. Например, обращаясь к сайту Internet Movie Database, невозможно запросить выборку всех фильмов с их актерскими составами. Вместо этого имеется возможность запросить сведения об актерах данного фильма или о множестве фильмов, в которых играет данный конкретный актер. Проблема ответа на запросы при наличии ограничений на способы связывания рассматривается в работах [RSU95, KW96, LRO96, FW97].
Положительные возможности порождают дополнительное требование к системе интеграции данных. Если источник данных обладает способностью выполнять такие операции, как селекция и соединение, мы хотели бы в максимально возможной степени перенести обработку на источник, сокращая тем самым объем локальной обработки и количество данных, передаваемых по сети. Проблема описания вычислительных возможностей источников данных и их использования для создания планов исполнения запросов рассматривается в [PGGMU95, TRV98, LRU96, HKWY97, VP97a].
Оптимизация запросов: Во многих работах по системам интеграции данных Web исследовались проблемы выбора минимального набора Web-источников, к которым необходимо осуществить доступ для обработки заданного запроса, и определения минимального запроса, который должен быть адресован каждому из них. Однако проблема выбора оптимального плана исполнения запроса для доступа к Web-источникам до сих пор не привлекала достаточного внимания. Поэтому она мало отражена в литературе по интеграции данных [HKWY97] и остается активной областью исследований. Дополнительные трудности, связанные с оптимизацией запросов для источников в среде WWW, состоят в том, что мы имеем незначительную статистику по данным в источниках, и, следовательно, мало информации для оценки стоимости планов исполнения запросов. В работе [NGT98] рассматривается проблема калибровки модели стоимости для планов исполнения запросов в этом контексте.
В [YPAGM98] обсуждается проблема оптимизации запросов слияния (fusion query), которые являются специальным классом запросов на интеграцию данных, предусматривающих выборку различных атрибутов данного объекта из множественных источников. Мы полагаем, что обработка запросов в системах интеграции данных - это область, где можно было бы извлечь пользу из таких идей, как перемежающиеся планирование и исполнение, а также вычисление условных планов [GC94, KD98].
Механизмы исполнения запросов: Еще меньше внимания было уделено проблеме разработки механизмов исполнения запросов, предназначенных для интеграции данных Web. Необходимость создания таких механизмов вызвана автономностью источников данных и непредсказуемостью пропускной способности сети. В частности, при доступе к Web-источникам могут иметь место начальные задержки, прежде чем данные начинают передаваться, и даже если это случается, поступление данных может быть очень интенсивным. В работах [AFT98, UFA98] рассматривается проблема адаптации планов исполнения запросов к начальным задержкам в поступлении данных.
Создание оболочек: Напомним, что роль оболочки (wrapper) заключается в обеспечении выборки данных из Web-сайта в форме, которая дает возможность манипулировать ими системе интеграции данных. Например, задача оболочки может состоять в формулировании запроса к Web-источнику c использованием интерфейса в виде формы и выборке множества кортежей ответа из результирующей HTML-страницы. Трудность создания оболочек заключается в том, что HTML-страница обычно разрабатывается для просмотра человеком, а не для выборки данных программами. По этой причине данные часто оказываются встроенными в тексты на естественном языке или скрытыми в примитивах графического представления. Кроме того, форма HTML-страниц часто изменяется, что создает трудности для поддержки оболочек. Несколько работ было посвящено проблеме конструирования инструментальных средств для быстрого создания оболочек. Один из классов таких инструментальных средств (см., например, [HGMN+98, GRVB98]) основан на специализированных грамматиках, позволяющих специфицировать, каким образом данные размещаются на HTML-странице, и, тем самым, как извлекать требуемые данные.
Второй класс средств основан на применении методов индуктивного обучения для автоматического обучения оболочки. Используя алгоритмы, базирующиеся на таких методах, мы сначала задаем системе набор HTML-страниц таких, что содержащиеся в них данные помечены. На основе этих обучающих примеров автоматически строится грамматика, с помощью которой может осуществляться выборка данных из последующих страниц. Конечно, чем большее число примеров мы задаем системе, тем более точной будет порождаемая в результате грамматика, и задача состоит в том, чтобы найти такие языки для оболочек, которые можно обучить с помощью малого числа примеров. Впервые идея конструирования оболочки на основе индуктивного обучения и набор алгоритмов для обучения простых классов оболочек были преложены в [KDW97]. Алгоритм, описанный в [AK97], использует специфические эвристические подходы для общепринятых применений HTML с тем, чтобы добиться быстрого обучения. Следует также отметить, что методы машинного обучения также использовались для изучения отображения между схемами источников и промежуточными схемами [PE95, DEW97]. Работа [CDF+98) представляет собой первый шаг в попытке ликвидировать существующий разрыв между подходами к проблеме создания оболочек, основанными на машинном обучении и на обработке естественного языка. В заключение, нужно отметить, что появление языка XML может обеспечить разработчикам Web-сайтов возможности для экспортирования данных, содержащихся на их сайтах, в машиночитаемой форме, тем самым значительно упрощая создание оболочек.
Соответствие объектов на множестве источников: Одна из наиболее трудных проблем, связанных с получением ответов на запросы над множеством источников, заключается в выявлении ситуации, когда два объекта, упомянутые в двух различных источниках, представляют один и тот же объект в реальном мире. Эта проблема возникает потому, что каждый источник использует свои собственные соглашения об именовании и обозначениях. В большинстве систем эта проблема решается благодаря использованию специфических для предметной области эвристических подходов (как, например, в [FHM94]).В системе WHIRL [Coh98] соответствие объектов на множестве источников поддерживается с помощью методов из области информационного поиска. Кроме того, соответствующие объекты изящно интегрируются в новом алгоритме исполнения запросов.
Использование единого набора графики
Если использовать одни и те же навигационные кнопки и фон страницы на всем сайте, при каждой повторной загрузке они будут загружаться из кэша броузера. Это значит, что реальная скорость загрузки увеличится за счет "сэкономленной" графики. Также, единая графическая структура сайта придаст ему устойчивый внешний вид, что очень немаловажно с точки зрения usability.
Использование переменных
Поскольку, как мы говорили ранее, в одной деке может содержаться несколько карт, нам потребуется механизм хранения информации из одной карты для ее последующего использования в другой. Этот механизм обеспечивается переменными. Переменные могут быть созданы и определены, используя несколько различных методов.
Используя элемент в качестве результата выполнения пользователем определенных действий. Кроме того, этот элемент может быть использован для определения переменной внутри следующих элементов: , , . Следующий элемент создает переменную x и присваивает ей значение "123".
Переменным также присваивается значение через использование элементов , , и других. При этом автоматически создается переменная с именем этого элемента. По окончании ввода, ей присваивается значение соответствующее выбору пользователя. Например следующий элемент создаст переменную с именем "x"
Несмотря на то, что мы не описывает WMLScript, следует отметить, что WML и WMLScript используют одни и те же переменные в рамках одной деки.
Избавиться от тяжелой графики
Чаще всего именно графика становится причиной затяжной загрузки. Можно убрать лишние графические кнопки, заменив их на текстовые. Также, можно заменить или удалить графические элементы, не несущие смысловой нагрузки.
Если на сайте присутствует анимированная графика, она должна быть обоснована с точки зрения информационной ценности.
Изменить размеры
Я имею в виду 1)физические размеры и 2)объем графического файла на сервере. Чем меньше у рисунка ширина и высота (тэги width и height), тем лучше. Можете сократить размеры, но в разумных пределах, чтобы не заставлять пользователей надевать очки.
Теперь касательно размера файла на сервере. Можно оптимизировать глубину цветов рисунка, например до 256 цветов без видимого отличия оригинала от копии. Удобно заниматься оптимизацией графики с помощью NetMechanic (http://www.netmechanic.com/)
Java, инкапсулированная в СУБД
Java может быть встроена в СУБД множеством различных способов и при этом всегда достигается решение сразу нескольких задач:
Применение полноценного языка программирования для написания хранимых процедур. В сервер встраивается виртуальная машина Java и внутренний интерфейс JDBC. Встраивание мощного и безопасного языка программирования позволяет обойти ограничения хранимых процедур на языке SQL. Расширение объектных типов данных. Объекты, написанные на языке Java могут храниться в виде значений в реляционной таблице. Это позволяет создавать и использовать произвольные типы данных. Java-класс может быть использован в качестве типа данных для столбца таблицы. Каждое поле такой записи становится экземпляром соответствующего Java-класса. В качестве примера возьмем простой класс на языке Java, хранящий адреса. Прикладной код может быть включен в методы класса. Например, строковые данные могут содержаться только в полях Street и Postal Code(почтовый код), а значение поля City может вычисляться на основе почтового индекса. Более того, можно использовать наследование классов и методов. При этом допускается перегрузка методов в зависимости от используемого класса. Так можно создать классы US_Address и Rus_Address, унаследованные от базового класса Address. В каждом таком классе могут быть разные методы определения городов по почтовому индексу и методы проверки его значений, естественно разные для России и США. Даже сам SQL может использоваться для доступа к Java-объектам, как это уже сделано в Sybase Adaptive Server.
Следующий пример вставляет новую запись в таблицу: INSERT INTO employees (id, name, Address) VALUES(1789, _Serg Dunaev_, new Rus_Address(_58 Gagarin Street_, _153038_) )
Следующий запрос с использованием Java-объектов возвращает список сотрудников, живущих на указанной улице: SELECT name FROM employees WHERE Rus_Address.street="Gagarin Street"
Единая программная модель. Впервые прикладные программные компоненты можно будет перемещать между клиентскими программами, серверами приложений и СУБД. Разработчики смогут использовать единую программную модель на всех уровнях информационной системы. Произвольная программа на Java состоит из набора классов. Для их использования необходимо провести инсталляцию Java-классов в СУБД. Классы должны быть откомпилированы в байт-код и тем самым, готовы для использования в любой виртуальной машине. В связи с использованием виртуальной машины для исполнения методов на Java и встроенной поддержке интерфейса JDBC, один и тот же объект на языке Java может быть использован как внутри, так и вне СУБД.
Java-программы и апплеты с интерфейсом JDBC-ODBC
JDBC (Java Database Connectivity) является не протоколом, а интерфейсом и основан на спецификациях SAG CLI (SQL Access Group Call Level Interface - интерфейс уровня вызова группы доступа SQL).
Сам по себе JDBC работать не может и использует основные абстракции и методы ODBC. Хотя в стандарте JDBC API и предусмотрена возможность работы не только через ODBC, а и через использование прямых линков к базам данных по двух- или трех-звенной схеме (см. Рис.1), эту схему используют гораздо реже, чем повсеместно используемый JDBC-ODBC-Bridge занимающий центральное место в общей схеме взаимодействия интерфейсов (см. Рис. 2)
Рис. 1. Непосредственный доступ к базе данных по 3-х-звенной схеме.
Рис. 2. Схема взаимодействия интерфейсов.
Даже беглого взгляда на Рис. 2 вполне достаточно, чтобы понять - общая схема взаимодействия интерфейсов в Java удивительным образом напоминает столь всем знакомую схему ODBC с ее гениальным изобретением драйвер-менеджера к различным СУБД и единого универсального пользовательского интерфейса. JDBC Driver Manager - это основной ствол JDBC-архитектуры. Его первичные функции очень просты - соединить Java-программу и соответствующий JDBC драйвер и затем выйти из игры. Естественно, что ODBC был взят в качестве основы JDBC из-за его популярности среди независимых поставщиков программного обеспечения и пользователей. Но тогда возникает законный вопрос - а зачем вообще нужен JDBC и не легче ли было организовать интерфейсный доступ к ODBC-драйверам непосредственно из Java? Ответом на этот вопрос может быть только однозначное нет. Путь через JDBC-ODBC-Bridge, как ни странно, может оказаться гораздо короче.
ODBC нельзя использовать непосредственно из Java, поскольку он основан на C-интерфейсе. Вызов из Java C-кода нарушает целостную концепцию Java, пробивает брешь в защите и делает программу трудно-переносимой. Перенос ODBC C-API в Java-API нежелателен. К примеру, Java не имеет указателей, в то время как в ODBC они используются. ODBC слишком сложен для понимания.
В нем смешаны простые и сложные вещи, причем сложные опции иногда применяются для самых простых запросов. Java-API необходим, чтобы добиться абсолютно чистых Java решений. Когда ODBC используется, то ODBC-драйвер и ODBC менеджер должны быть инсталлированы на каждой клиентской машине. В то же время, JDBC драйвер написан полностью на Java и может быть легко переносим на любые платформы от сетевых компьютеров до мэйнфреймов.
JDBC API - это естественный Java-интерфейс к базовым SQL абстракциям и, восприняв дух и основные абстракции концепции ODBC, он реализован, все-таки, как настоящий Java-интерфейс, согласующийся с остальными частями системы Java.
В отличие от интерфейса ODBC, JDBC организован намного проще. Главной его частью является драйвер, поставляемый фирмой JavaSoft для доступа из JDBC к источникам данных. Этот драйвер является самым верхним в иерархии классов JDBC и называется DriverManager. Согласно, установившимся правилам Internet, база данных и средства ее обслуживания идентифируются при помощи URL. jdbc::
где под понимается имя конкретного драйвера, или некоего механизма установления соединения с базой данных, например, ODBC. В случае применения ODBC, в URL-строку подставляется именно эта аббревиатура, а в качестве используется обычный DSN (Data Source Name), т.е. имя ODBC-источника из ODBC.INI файла. Например: jdbc:odbc:dBase
В некоторых случаях вместо ODBC может быть использовано имя прямого сетевого сервиса к базе данных, например: jdbc:dcenaming:accounts-payable,
или jdbc:dbnet://ultra1:1789/state
В последнем случае часть URL //ultra1:1789/state представляет собой и описывает имя хоста, порт и соответствующий идентификатор для доступа к соответствующей базе данных.
Однако, как уже говорилось выше, чаще всего, все-таки используется механизм ODBC благодаря его универсальности и доступности. Программа взаимодействия между драйвером JDBC и ODBC разработана фирмой JavaSoft в сотрудничестве с InterSolv и называется JDBC-ODBC-Bridge. Она реализована в виде JdbcOdbc.class (для платформы Windows JdbcOdbc.dll) и входит в поставку JDK1.1.
Помимо JdbcOdbc- библиотек должны существовать специальные драйвера (библиотеки), которые реализуют непосредственный доступ к базам данных через стандартный интерфейс ODBC. Как правило эти библиотеки описываются в файле ODBC.INI. На внутреннем уровне JDBC-ODBC-Bridge отображает медоды Java в вызовы ODBC и тем самым позволяет использовать любые существующие драйверы ODBC, которых к настоящему времени накоплено в изобилии.
Рассмотрим типичное приложение на Java c доступом к типичному реляционному серверу или даже к обычной dBase-таблице.
// Следующий код на Java используется как пример. Простой подстановкой // соответствующих значений url, login, и password, и, затем подстановкой // SQL операторов вы можете посылать их в базу данных. //-------------------------------------- // // Module: SimpleSelect.java // // Описание: Эта программа для ODBC API интерфейса. Java-приложение // будет присоединяться к JDBC драйверу, посылать select оператор // и показывать результаты в таблице // // Продукт: JDBC к ODBC Мост // // Автор: Karl Moss (С.Дунаев модификация для работы с кириллицей) // // Дата: Апрель 1997 // // Copyright: 1990-1996 INTERSOLV, Inc. // This software contains confidential and proprietary // information of INTERSOLV, Inc. //-------------------------------------- import java.net.URL; import java.sql.*; import java.io.*; class SimpleSelect { public static void main (String args[]) { String url = _jdbc:odbc:dBase_; String query = _SELECT * FROM my_table_; try { // Загрузка jdbc-odbc-bridge драйвера Class.forName (_sun.jdbc.odbc.JdbcOdbcDriver_); DriverManager.setLogStream(System.out); // Попытка соединения с драйвером. Каждый из // зарегистрированных драйверов будет загружаться, пока // не будет найден тот, который сможет обработать этот URL Connection con = DriverManager.getConnection ( url, __, __); // Если не можете соединиться, то произойдет exception // (исключительная ситуация). Однако, если вы попадете // в следующую строку программы, значит вы успешно соединились с URL // Проверки и печать сообщения об успешном соединении // checkForWarning (con.getWarnings ()); // Получить DatabaseMetaData объект и показать // информацию о соединении DatabaseMetaData dma = con.getMetaData (); //System.out.println(_\nConnected to _ + dma.getURL()); //System.out.println(_Driver _ + //dma.getDriverName()); //System.out.println(_Version _ + //dma.getDriverVersion()); //System.out.println(__); // Создать Оператор-объект для посылки // SQL операторов в драйвер Statement stmt = con.createStatement (); // Образовать запрос, путем создания ResultSet объекта ResultSet rs = stmt.executeQuery (query); // Показать все колонки и ряды из набора результатов dispResultSet (rs); // Закрыть результирующий набор rs.close(); // Закрыть оператор stmt.close(); // Закрыть соединение con.close(); } catch (SQLException ex) { // Случилось SQLException.
Перехватим и // покажем информацию об ошибке. Заметим, что это // может быть множество ошибок, связанных вместе // //System.out.println (_\n*** SQLException caught ***\n_); while (ex != null) { //System.out.println (_SQLState: _ + // ex.getSQLState ()); //System.out.println (_Message: _ + ex.getMessage ()); //System.out.println (_Vendor: _ + //ex.getErrorCode ()); ex = ex.getNextException (); //System.out.println (__); } } catch (java.lang.Exception ex) { // Получив некоторые другие типы exception, распечатаем их. ex.printStackTrace (); } } //---------------------------------- // checkForWarning // Проверка и распечатка предупреждений. Возврат true если // предупреждение существует //---------------------------------- private static boolean checkForWarning (SQLWarning warn) throws SQLException { boolean rc = false; // Если SQLWarning объект был получен, показать // предупреждающее сообщение. if (warn != null) { System.out.println (_\n *** Warning ***\n_); rc = true; while (warn != null) { //System.out.println (_SQLState: _ + //warn.getSQLState ()); //System.out.println (_Message: _ + //warn.getMessage ()); //System.out.println (_Vendor: _ + //warn.getErrorCode ()); //System.out.println (__); warn = warn.getNextWarning (); } } return rc; } //---------------------------------- // dispResultSet // Показать таблицу полученных результатов //---------------------------------- private static void dispResultSet (ResultSet rs) throws SQLException, IOException { // Объявление необходимых переменных и // константы для желаемой таблицы перекодировки данных int i, length, j; String cp1 = new String(_Cp1251_); // Получить the ResultSetMetaData. Они будут использованы // для печати заголовков ResultSetMetaData rsmd = rs.getMetaData (); // Получить номер столбца в результирующем наборе int numCols = rsmd.getColumnCount (); // Показать заголовок столбца for (i=1; i<=numCols; i++) { if (i > 1) System.out.print(_,_); //System.out.print(rsmd.getColumnLabel(i)); } System.out.println(__); // Показать данные, загружая их до тех пор, пока не исчерпается // результирующий набор boolean more = rs.next (); while (more) { // Цикл по столбцам for (i=1; i<=numCols; i++) { // Следующая группа операторов реализует функции перекодировки // строк из таблицы базы данных в желаемый формат, потому что в // различных базах символы могут быть закодированы произвольным // образом.
Если использовать стандартный метод - getString - на выходе // получается абракадабра. Строки нужно сначала перевести в Unicode, // затем конвертировать в строку Windows и убрать лидирующие нули InputStream str1 = rs.getUnicodeStream(i); byte str2[]; byte str3[]; int sizeCol = rsmd.getColumnDisplaySize(i); str2 = new byte[sizeCol+sizeCol]; str3 = new byte[sizeCol+sizeCol]; length = str1.read(str2); // Здесь нужно убрать нули из строки, которые предваряют каждый // перекодированный символ k=1; for (j=1; j
В этой простой программе, приводимой во множестве руководств, мною произведено одно небольшое изменение, позволяющее использовать ее для работы с различными базами данных, содержащих таблицы с полями в кириллической кодировке. Дело в том, что хотя Java автоматически производит преобразования из Unicode и обратно в соответствии с установленными на вашей машине языковыми спецификациями (так называемые locale), эти преобразования не всегда действуют по отношению к кириллическим фонтам, особенно, когда кириллические строки прописаны не непосредственно в Java-программе, а передаются из внешних источников, например из баз данных через несколько промежуточных слоев. Та же проблема, как мы увидим далее, возникает и при использовании сервлетов, работающих в тесной взаимоувязке с Web-серверами.
Java-сервлеты
Если апплеты расширяют функциональность Web-браузеров, то сервлеты расширяют функциональность Web-серверов и являются мощным средством программирования. В последнее время многие предпочитают обыкновенным апплетам, загружаемым локально или удаленно, именно сервлеты, которые не нужно никуда загружать и, которые всегда выполняются в контексте Web-сервера, обеспечивая, в отличие от обычных CGI-процессов или скриптов, куда более развитые возможности.
Язык STRUQL
STRUQL - это язык запросов системы управления Web-сайтами STRUDEL, описываемой ниже в разделе 5. Хотя STRUQL был разработан в контексте специфического приложения Web, он является универсальным языком запросов для слабоструктурированных данных, основанным на модели данных помеченных ориентированных графов. Кроме того, модель данных STRUDEL включает именованные коллекции и поддерживает несколько атомарных типов, которые обычно появляются на страницах Web, таких как URL и Postscript, текст, изображение и HTML-файлы. Результат запроса в STRUQL представляет собой граф в той же самой модели данных, что и входные графы. В системе STRUDEL язык STRUQL использовался для решения двух задач: для запросов к неоднородным источникам с тем, чтобы интегрировать их в граф данных сайта, и для запросов к этому графу данных с целью продуцирования графа сайта.
Запрос в STRUQL представляет собой набор, возможно, вложенных блоков следующего вида:
[where C1,...,Ck] [create N1,...,Nn] [link L1,...,Lp] [collect G1,...,Gq].
Фраза where может включать либо условия принадлежности множеству, либо условия, налагаемые на пары узлов, выражающие используемые правильные выражения путей. Фраза where продуцирует все связывания bindings) переменных-узлов и переменных-дуг со значениями из исходного графа. Оставшиеся фразы используют функции Сколема для построения нового графа из этих связываний.
Для иллюстрации возможностей STRUQL приведем запрос, определяющий некоторый Web-сайт, начиная с библиографического файла Bibtex, моделируемого как помеченный граф. Рассматриваемый Web-сайт будет состоять из страниц трех видов: страницы PaperPresentation для каждого источника в библиографии, страницы Year для каждого года, указывающей все статьи, опубликованные в этом году, и, наконец, страницы Root, указывающей на все страницы Year. После того, как будет приведен запрос в STRUQL, мы покажем, как он представляется в WebOQL. Это позволит почувствовать различия между данными языками.
Запись указанного запроса в STRUQL имеет следующий вид:
// Создать страницу Root create RootPage() // Создать представление для каждой // публикации x where Publications(x), x -> 1 -> v create PaperPresentation(x) link PaperPresentation(x) -> 1 -> v { // Создать страницу для каждого года where 1 = create YearPage(v) link YearPage(v) -> -> u YearPage(v) -> ->PaperPresentation(x), // Связать корневую страницу с каждой // страницей года RootPage() -> -> YearPage(v) }
Здесь выражение Publications(x) во фразе where обозначает, что x принадлежит совокупности публикаций Publications. В свою очередь, атом x -> 1 -> v обозначает, что существует связь в графе от x к v, и метка соответствующей дуги - 1. Такая же нотация используется во фразе link для того, чтобы специфицировать вновь созданные ребра в результирующем графе. После создания корневой страницы Root первый оператор create генерирует страницу для каждой публикации, обозначенную функцией Сколема PaperPresentation. Второй оператор create, вложенный во внешний запрос, генерирует страницу Year для каждого года и связывает ее со страницей Root, а также со страницами PaperPresentation тех публикаций, которые относятся к этому году. Отметим, что функция Сколема YearPage обеспечивает, чтобы страница Year для конкретного года создавалась только один раз, независимо от того, сколько статей было опубликовано в этом году.
Теперь приведем запись того же самого запроса в WebOQL:
select unique [Url: x.year, Label:>YearPage>] as , [label: / x] as x.year from x in browse() | select [year: y.url] + y as y.url from y in
Запрос в WebOQL состоит из двух подзапросов. Полученная в результате первого из них подструктура Web поступает в качестве исходных данных во второй запрос, что достигается с помощью использования оператора <|>. Первый подзапрос строит страницы Root, Paper и Year, а второй переопределяет каждую страницу Year, добавляя к ней поле .
Язык WebOQL
Основная структура данных в WebOQL - гипердерево. Гипердеревья - это упорядоченные деревья с помеченными дугами, причем имеется два типа дуг - внутренние и внешние. Внутренние дуги используются для представления структурированных объектов, а внешние - для представления связей (обычно гиперссылок) между объектами. Дуги снабжаются метками, в качестве которых используются записи. На рис. 1, заимствованном из [Aro97], показано гипердерево, содержащее описания публикаций нескольких исследовательских групп. Такое дерево можно было бы легко построить, например, из HTML-файла, используя обобщенную HTML-оболочку (wrapper).
Web представляет собой множество взаимосвязанных гипердеревьев. Язык WebOQL позволяет манипулировать как отдельными гипердеревьями, так и Web в целом, и они (гипердеревья и Web) могут создаваться в результате обработки запроса.
WebOQL - функциональный язык, но запросы формулируются в знакомой форме select-from-where. Предположим, например, что база данных документов на рис. 1 имеет имя СтатьиПоИнформатике и что мы хотим осуществить из нее выборку названия и URL полных текстов статей Смита. Тогда нужно использовать следующий запрос:
select [y.Название, y'.Url] from x in СтатьиПоИнформатике, y in x' where y.Авторы ~ "Смит"
В этом запросе переменная x определена на множестве простых деревьев базы данных СтатьиПоИнформатике (соответствующих исследовательским группам), а при заданном значении x переменная y, в свою очередь, принимает значения на множестве простых деревьев x'. Переменная x' обозначает результат применения к дереву x прим-оператора ('), который возвращает первое поддерево его параметра. Тот же самый оператор используется для извлечения из дерева y его первого поддерева в y'.Url. Квадратные скобки обозначают оператор Hang. Этот оператор строит дугу, которая помечена записью, образуемой аргументом (в приведенном примере предполагается, что запись включает поля с указанными именами). Наконец, тильда (~) представляет собой предикат сопоставления со строковым образцом: его левый аргумент - строка, а правый - образец.
Создание Web: Рассмотренные выше запросы отображают гипердерево в другое гипердерево, или, если говорить в более общих терминах, запрос - это функция, которая отображает один Web в другой. Например, следующий запрос создает новую страницу для каждой исследовательской группы (использующей имя группы как URL). Каждая страница содержит публикации соответствующей группы.
select x' as x.Группа from x in СтатьиПоИнформатике
В общем случае фраза select имеет вид: 'select q1 as s1, q2 as s2, ..., qm as sm', где каждое qi - это запрос, а каждое из si - или запрос строки или схема. Фразы "as" создают URL s1, s2,... , sm, которые присваиваются новым страницам, полученным в результате выполнения каждого из запросов qi.
Шаблоны навигации: Шаблоны навигации - это правильные выражения в алфавите предикатов, определенных над записями. Они позволяют специфицировать структуру путей, по которым необходимо следовать для того, чтобы найти значения переменных.
Шаблоны навигации полезны, главным образом, для двух целей. Первая из них - извлечение поддеревьев из деревьев, структура которых достаточно детально нам неизвестна или содержит неправильности (irregularities). Вторая цель - выполнение повторяющихся операций над деревьями, соединенными внешними дугами. Фактически, возможность различать внутренние и внешние дуги в гипердеревьях становится действительно полезной, когда мы используем шаблоны навигации, которые позволяют обходить внешние дуги. Предположим, что мы имеем некоторый программный продукт, документация к которому представлена в формате HTML, и мы хотим сформировать полнотекстовый индекс для нее. Такие документы образуют сложный гипертекст, но можно просматривать их и последовательно, следуя по связям, помеченным меткой "Следующий". Для формирования полнотекстового индекса нам необходимо снабдить индексатор текстом каждого документа и его URL. Мы можем получить эту информацию, используя следующий запрос:
select [ x.Url, x.Текст ] from x in browse() via (^*[Текст ~ <Следующий>]>)*
Экран помощи
По Alt+H всегда может быть вызвана подсказка с возможными командами NCSA Telnet следующего вида: \hrule
Использование клавиш в NCSA TELNET:
Alt-A - Добавить сессию (установить связь с еще одной машиной)
Alt-N - Следующая сессия (переключение установленных связей)
Alt-D - Копия экрана в Capture файл
Alt-M - Использование мыши (переключатель)
Alt-E - Выход в DOS Shell
Alt-G - Графическое меню
Alt-C - Capture ON/OFF (переключатель)
Alt-R - Переустановить (обновить) терминал VT102
Alt-H - Помощь (Этот экран)
ScrLock - Вход/Выход в режим прокрутки; - Пауза/восстановл. работы экрана
Alt-Z - Экран сообщений
Alt-F - Запуск FTP для передачи файлов (= ftp [internet address]) \break (* Все попытки связи по FTP с Персональным компьютером (DOS) не удались.)
Alt-I - Выдать в сессию (на экран) свой (PC) internet address
Alt-S - В режиме прокрутки: "прыгнуть вперед" (в конец буфера) (* не удалось)
Alt-P - Экран изменения параметров (цвета, Capture файла, имени сессии, типа экрана)
Alt-X - Закрыть связь
Ctrl-Shift-F3 - Прерывание работы программы (всех сессий). (Рекомендуется использовать в самом крайнем случае)
Alt-Y - Прервать процесс
Alt-B - Предыдущая сессия (переключение установленных связей)
Alt-O - Прекратить output
Alt-Q - Вы здесь? (Проверка связи)
Alt-U - Удалить строку
Alt-K - Удалить символ
Alt-V - Вставить Capture в сессию
HOME - Выход из графического режима
Ctrl-HOME - Очистка/Вход в граф. режим \hrule
Экспериментальные значения поля 'Content-Type'
Значение типа, начинающееся с "X-", считается частным, предназначенным для использования по договоренности между двумя или более почтовыми системами. Публично определенные (регестрированные) значения никогда не должны начинаться с префикса "X-".
В общем, использование X-типов верхнего уровня не рекомендуется. Производители почтового ПО должны по возможности обходиться использованием X-подтипов для предопределенных типов. Во многих случаях использование экспериментального подтипа более приемлимо, нежели типа верхнего уровня.
Все определенные на сегодняшний день типы и подтипы
ТИППОДТИП
text plain
richtext
enriched
tab-separated-values
multipart mixed
alternative
digest
parallel
appledouble
header-set
message rfc822
partial
external-body
news
application octet-stream
postscript
oda
atomicmail
andrew-inset
slate
wita
dec-dx
dca-rft
activemessage
rtf
applefile
mac-binhex40
news-message-id
news-transmission
wordperfect5.1
pdf
zip
macwriteii
msword
remote-printing
image jpeg
gif
ief
tiff
audio basic
video mpeg
quicktime
Значения полей Content-Type и subtype, а также другие параметры заголовка являются чувствительными к регистру букв, если только не оговорены исключения для конкретного значения параметра.
Электронная доставка отчетов
По оценкам Gardner Group, в среднем каждый документ копируется 9–11 раз. Рассылка и доставка твердых копий— это довольно трудоемкая процедура, включающая в себя отправку факсов и электронных писем, либо доставку вручную. Эта проблема практически полностью снимается при использовании электронных отчетов: снижается не только потребление бумаги, но и прочие расходы и, главное, существенно сокращается время выполнения этой работы.
Программное обеспечение, предназначенное для распространения информации, автоматически пересылает данные тем, кто в них заинтересован. Такой интеллектуальный метод распространения еще сильнее сокращает трудозатраты, характерные для ручной обработки документов. Пользователю уже не нужно искать информацию, она автоматически присылается в его почтовый ящик.
Установка графического терминала и возврат к текстовому терминалу:
Автоматический переход к графическому терминалу осуществляется при вызове программы, которая выполняет графические команды терминала Textronix 4014.
По Ctrl+Home происходит установка/очистка графического терминала.
Вызов на экран последнего графического образа (осуществляется через графическое меню) приводит к установке графического терминала.
По Home происходит переход обратно к текстовому терминалу.
По Alt+R отовсюду осуществляется переустановка терминала VT100.
Как проверить
Ну например : test1.pl - работает при помощи perl.exe и выводит на экран фразу "Hello, Perl !".
print "Content-type: text/html\n\n"; print ""; print ""; print ("Hello, Perl !"); print ""; print "";
А вот test2.plx использует perlis.dll и пишет на экране "Здравствуй, ПЕРЛ !". Обратите внимание : начальная строчка здесь другая, чем в test1.pl - именно так требуется для perlis.dll.
print "HTTP/1.0 200 OK \r\n"; print << "END"; Content-Type text/html
Здравствуй, ПЕРЛ ! END
И наконец, test3.stm выдает на экран ваш IP-адрес используя скрипт test3.pl и SSI.
Ваш IP-адрес
А соответствующий скрипт test3.pl состоит всего из одной строки :
print $ENV{'REMOTE_ADDR'};
Как устанавливать
а) Выбираем директорию под файлы PERL, например C:\PERL - ни в коем случае не внутри директории web, а то получим большую дыру в системе безопасности.
в) Разархивируем скачанные архивы в выбранную директорию ( например, при помощи WinZip - важно, чтобы длинные имена файлов сохранились).
c) Устанавливаем модуль "Perl for Win32" : в возникшей директории BIN находим и запускаем perlw32-install.bat. Соглашаемся со всем, что предлагается.
d) Устанавливаем модуль "Perl for ISAPI" : в возникшей директории BIN находим и запускаем perlis-install.bat. Соглашаемся со всем, что предлагается, НО : расширение под файлы, которые система будет ассоциировать с perlis.dll лучше сменить с предлагаемого .PL на .PLX, или что нибуть в этом роде : по традиции .PL обычно резервируется под файлы, обрабатываемые perl.exe - главным файлом "Perl for Win32".
e) Еще одно действие понадобится для тех случаев, когда желательно непосредственно применять perl.exe - главный файл "Perl for Win32". ( Напомним, что теоретически perlis.dll делает все то же самое, что и perl.exe, но только быстрее. Практически, однако, нам не удалось заставить его корректно работать с SSI- Server Side Include. А это ключевой элемент для счетчиков или , скажем, вставления часов на страницу. Есть и другие тонкости. Так что пожалуй, лучше сразу сделать - ну хотя бы для того, чтобы реально сравнить по скорости perl.exe и perlis.dll. ) Итак, нужно добавить в Registry запись, ассоциирующую файлы с расширением .PL с perl.exe. Любопытно : то же для perlis.dll инсталляционная программа сделала автоматически, а для perl.exe - нет.
Вызываем winnt/system32/regedt32 и находим HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services \W3SVC\Parameters\ScriptMap
Там уже должна быть запись
.plx:REG_SZ: c:\perl\bin\PerlIS.dll
( предполагается, что директория, выбранная в пункте а) - c:\perl ). После этой записи надо добавить
.pl:REG_SZ: c:\perl\bin\Perl.exe %s %s
Любопытно, что вот про эти %s %s - в FAQ от Evangelo Prodromou - ни слова, а без них все как настоящее, но не работает.
f) Если потребуется SSI ( а наверняка потребуется ), то ровно в том же месте Registry, прямо под двумя предыдущими записями делаем еще одну :
.stm:REG_SZ: C:\WINNT\system32\inetsrv\Ssinc.dll
-мы ассоциируем файлы с расширением .stm с отвечающим за SSI .dll. Это .dll из комплекта IIS и никак с perl не связан. Расширение можно, видимо, при желании изменить, но это не может быть .htm . Разумеется, если вы при инсталляции выбрали другое название для директории с файлами IIS - его и проставьте.
g) Теперь кладем наши скрипты в какую-нибуть директорию внутри web и при помощи Microsoft Internet Service Manager ( Inetmngr ) прописываем ее как директорию web с правами Access : Read Execute. Те же права нужны кстати и для SSI.
h) Все. Перегружаем NT ( именно NT перегружаем, а не только web - иначе записи в Registry не вступят в силу )
КОЛЛЕКТИВНАЯ МУДРОСТЬ
Отчасти BizTalk представляет собой не что иное, как общественный сервер Web (http://www.biztalk.org), где публикуются все схемы, предложенные для использования в различных отраслях. Маркус Шмидт, менеджер по работе с компаниями, специализирующимися в области поставок, говорит, что Microsoft и другие члены Инициативной группы BizTalk работают над рекомендациями и тегами XML для придания некоторого однообразия использованию XML в бизнесе. Однако BizTalk не ставит своей целью объединить все отрасли в попытке составить одну гигантскую схему для всех используемых в каком бы то ни было бизнесе данных. «Мы очень хорошо понимаем, что никогда не сможем заставить различные отрасли прийти к согласию даже по поводу фундаментальных вещей, например в отношении определения заказчика, так как каждой из них требуется своя информация о заказчике. Мы пытаемся добиться того, чтобы, когда производитель решит составить свою собственную схему, он имел как можно более высокие шансы, что его схема будет совместима с чьей-либо еще, если он станет следовать нашим рекомендациям и если другие будут иметь возможность без труда получить его схему, чтобы они могли установить соответствие между своей и его схемой».
В целом, как объясняет Шмидт, BizTalk состоит из трех отдельных элементов. Во-первых, это хранилище на сервере Web вместе с рекомендациями и тегами XML, используемыми для добавления новых схем в хранилище. Во-вторых, это разработка программного продукта, сервера BizTalk. И в-третьих, это будут интерактивные услуги на базе технологии BizTalk.
определяют массив названий групп,
Строки 3-5: подключение модулей
Строка 7: Адрес news-сервера можно конечно же поменять.
Строки 12- 22 определяют массив названий групп, в длинной форме - для сервера и в короткой - для человека. Длинное имя можно получить, например, так - $groups[2][0], а короткое - $groups[2][1]
В строке 24 создается CGI-объект $Q. Входные данные скрипт может получать из командной строки, через переменную окружения и из стандартного потока ввода.
Строка 25 позволяет получитьURL скрипта, который используется в дальнейшем.
В 27 строке проверяется входной параметр 'group'. И если его нет - то выводится полный список групп. Строки 28-44 создают страничку со списком доступных групп на основе массива @groups 28-29 строки создают переменную $links, содержащую ссылки на группы в виде:
Doonesbury Где SOMEWHERE - это как раз URL скрипта.
Строки с 32 по 40 выводят результат - заголовок, начало HTML-документа, список ссылок и конец HTML-документа. Конструкция @{[thing]} - это вывод 'thing' в списковом контексте. Можно было вместо этого просто разбить оператор print на несколько операторов print.
Строка 46: проверка на наличие входного параметра article.
Строки с 47 по 65 выводят список сообщений в выбранной группе.
Строка 47: установление соединения с news-сервером (порт 119 - стандартный)
Строки с 48 по 51: вывод тем всех сообщений в данной конференции. Выражение в строке 48 возвращает массив строк, где символом табуляции разделены номер и тема сообщения. 49 строка разбивает строки, а 50тая - создает строку со списком уже в HTML-виде, где на каждое сообщение - своя ссылка:
Doonesbury 950101
Строки 52-60: вывод результатов
Строка 69 начинает часть скрипта, которая непосредственно выдает картинки, содержащиеся в отдельных сообщениях. Снова устанавливается соединение с news-сервером, и забирается уже конкретное сообщение.
Строка 71: сообщение укладывается в массив @art
Строка 72: так как важна только та часть сообщения, которая начинается с Content-type, то все остальные строки можно выкинуть. При этом сохраняется тип картинки (строка 73).
Строки 74-75: Пустая строка после Content-type пропускается
Строка 76: непосредственно декодирование из base64
Строки 77-78: вывод картинки браузеру
Концепция проекта
При разработке проекта ebXML использовались следующие основные принципы:
простое, единое и повсеместное использование ebXML в электронном бизнесе; использование спецификаций XML в максимально возможных пределах; обеспечение открытыми стандартами электронной торговли: B2B (business to business) и ВС (business to Customer); объединение структуры и содержания компонентов расходящихся XML инициатив в единый XML бизнес стандарт; Минимизация затрат при обмене приложение-приложение; обеспечение мультиязыковой поддержки; учитывание национальных и международных правил торговли; учитывание традициональных принципов EDI на основе стандарта UN/EDIFACT.
Рабочая группа создания глобального электронного рынка - ebXML работает в следующих направлениях, которые выделены как самостоятельные проекты:
Разработка общей методологии и основных компонентов; Разработка спецификаций технической архитектуры; Разработка спецификаций для Репоситориев (Центр электронного бизнеса) Разработка спецификаций пакетов и маршрутизации; Моделирование бизнесс процесов и создание службы сообщений;
На рис.1 представлено взаимодействие основных компонентов ebXML при осуществлении бизнес-транзакций.
Рис 1.
Некая Компания Х (Interprise Systems) ведет электронный обмен с другой Компанией Y через Центр электронного бизнеса - Репоситорий (Repository). Электронный бизнес осуществляется путем обмена между компаниями электронными бизнесс-документами.
Правила обмена при проведении бизнес операций контролируются специальной службой сообщений, которые строятся в соответствии с методологией бизнесс процессов. В качестве независимого арбитра используются Центр электронного бизнеса, который является сердцем инфраструктуры и представляет Репоситорий (хранилище) и Регистр. Посредством Регистра определяется отношение участников обмена к бизнес объектам и метаданным.
Регистр должен иметь совместимый механизм запросов к индексу Репоситария посредством API. В Репоситории хранятся совместно используемые в Интернете общедоступные словари, метаданные об участниках информационного обмена и сценарии обмена.
На рис.2 представлен один из вариантов обмена Электронными документами для компаний X и Y.
Рис 2.
Конфигурация
Стандартная конфигурация NCSA Telnet включает 3 необходимые файла:
TELNET.BAT - Файл запуска. Содержит пути к остальным двум файлам.
TELBIN.EXE - Собственно исполнимый файл NCSA Telnet.
CONFIG.TEL - Файл конфигурации, к которому обращается Telbin.exe. Он содержит всю информацию о сети.
Файл конфигурации программы Config.tel может быть переименован следующим образом. В файле Autoexec.bat должна быть помещена строка типа:
SET CONFIG.TEL=C:\TELNET\TELNET.CFG
где, Telnet.cfg - новое имя файла конфигурации. \break \break Пример строки запуска в файле Telnet.bat:
c:\telnet\telbin -h c:\telnet\config.tel %1 %2 ...
1 2 3 4
1 - Указывается путь к исполняемому файлу
2 - Опция, сообщающая, что дальше будет путь к файлу конфигурации
3 - Путь к файлу конфигурации
4 - Параметрами .bat файла должны быть машины с которыми будет устанавливаться связь.
Кратко о PERL-модулях от Active State
Active State - на сегодняшний день основной поставщик модулей PERL для IIS. Для начала вполне достаточно того, что можно скачать у нее. ( Впрочем, если вас интересуют именно все возможные варианты или история вопроса - читайте указанный выше FAQ ). Кстати, в этом FAQ Active State называется свом старым именем - Active Ware.
Cушествует не один, а несколько модулей от Active State для разных аспектов поддержки PERL для IIS. Есть модуль "Perl for Win32" - это exe-файл,буквальный аналог соответствующего исполняемого perl-модуля под Unix. Однако специфика архитектуры Windows NT такова, что написанный специально под нее модуль- DLL, выполняя то же самое, будет работать быстрее ( не будем здесь вдаваться в объяснения - почему ). Этот модуль-DLL носит название "Perl for ISAPI". Двух указанных модулей - "Perl for Win32" и "Perl for ISAPI" хватает для решения большинства простейших задач с применением PERL. Их установку и использование мы и рассмотрим в данной заметке. ( Для многих задач хватило бы и одного "Perl for ISAPI", но технически его нельзя установить без "Perl for Win32" ).
А еще есть модуль "PerlScript", который глубже интегрирован в IIS - модуль для ASP ( Active Server Pages, особенность IIS начиная с IIS3, использующая Microsoft Active X.) Еще есть модуль "PerlEx" для ускорения работы CGI-скриптов ( еще раз ускорения, но уже за деньги) . И, наконец, графический Perl Debugger - тоже не бесплатный, бесплатна только версия на неделю.
Листинг:
=1= #!/usr/bin/perl -w =2= use strict; =3= $|++; =4= =5= ## config =6= =7= my @URL = qw(http://www.stonehenge.Xcom/); =8= =9= sub OK_TO_FOLLOW { =10= my $uri = shift; # URI object, known to be http only =11= for ($uri->host) { =12= return 0 unless /\.stonehenge\.Xcom$/i; =13= } =14= for ($uri->query) { =15= return 0 if defined $_ and length; =16= } =17= for ($uri->path) { =18= return 0 if /^\/(cgi|fors|-)/; =19= return 0 if /col\d\d|index/; =20= return 0 if /Pictures/; =21= return 0 unless /(\.html?|\/)$/; =22= } =23= return 1; =24= } =25= =26= ## end config =27= =28= use WWW::Robot; =29= use LWP::UserAgent; =30= use CGI::Pretty qw(-no_debug :html); =31= use HTML::Entities; =32= =33= my %description; =34= my %keywords; =35= my %keyword_caps; =36= =37= my $robot = WWW::Robot->new =38= ( =39= NAME => 'MetaBot', =40= VERSION => '0.15', =41= EMAIL => 'merlyn@stonehenge.Xcom', =42= USERAGENT => LWP::UserAgent->new, =43= CHECK_MIME_TYPES => 0, =44= ## VERBOSE => 1, =45= ); =46= =47= $robot->env_proxy; =48= =49= $robot->addHook =50= ("follow-url-test" => sub { =51= my ($robot, $hook, $url) = @_; =52= return 0 unless $url->scheme eq 'http'; =53= OK_TO_FOLLOW($url); =54= }); =55= $robot->addHook =56= ("invoke-on-contents" => sub { =57= my ($robot, $hook, $url, $response, $structure) = @_; =58= my %meta = map { =59= my $header = $response->header("X-Meta-$_"); =60= defined $header ? ($_, $header) : (); =61= } qw(Description Keywords); =62= return unless %meta; =63= if (exists $meta{Description}) { =64= $_ = $meta{Description}; =65= tr/ \t\n/ /s; =66= $description{$url} = $_; =67= } =68= if (exists $meta{Keywords}) { =69= for (split /,/, $meta{Keywords}) { =70= s/^\s+//; =71= s/\s+$//; =72= $keywords{lc $_}{$url}++; =73= $keyword_caps{lc $_} = $_; =74= } =75= } =76= }); =77= $robot->run(@URL); =78= =79= my %seen_letter; =80= =81= print =82= table({ Cellspacing => 0, Cellpadding => 10, Border => 2 }, =83= do { =84= my %letters; =85= @letters{map /^([a-z])/, keys %keywords} = (); =86= %letters ? =87= Tr(td({Colspan => 3}, =88= p("Jump to:", =89= map a({Href => "#index_$_"}, uc $_), sort keys %letters))) =90= : 0; =91= }, =92= map { =93= my $key = $_; =94= my @value = =95= map { =96= my $url = $_; =97= my $text = exists $description{$url} ? =98= $description{$url} : "(no description provided)"; =99= =100= [a({Href => encode_entities($url)}, encode_entities($url)), =101= encode_entities($text), =102= ]; =103= } sort keys %{$keywords{$key}}; =104= my $key_text = $keyword_caps{$key}; =105= if ($key =~ /^([a-z])/ and not $seen_letter{$1}++ ) { =106= $key_text = a({ Name => "index_$1" }, $key_text); =107= } =108= =109= map { =110= Tr(($_ > 0 ? () : td({Rowspan => scalar @value}, $key_text)), =111= td($value[$_])); =112= } 0..$#value; =113= } sort keys %keywords =114= );
Local или Remote echo mode
При работе в сессии существуют два Эхо режима: Режим локального (Local, Line) эха или Режим удаленного (Remote, Character) эха. При Remote echo mode каждый набранный символ сразу передается на удаленную машину и затем отображается на экране сессии. Такой режим является не очень удобным, если время передачи велико. В этом случае используют Local echo mode, при котором строка набираемых символов запоминается (отображаясь на экране) в буфере локальной машины и по ENTER целиком передается на удаленную машину.
При Local, Line echo mode:
Ctrl-U - Уничтожает локальный буфер
BackSpace (Ctrl-H) - Уничтожает последний набранный символ в лок. буфере
Tab (Ctrl-I), все управляющие ASCII символы и символы, начинающиеся с ^ - Посылают содержимое локального буфера на удаленную машину вместе с этим символом.
Alt - [символ] - Не действуют (отображаются) в Local echo mode.
Remote echo mode используется при полноэкранном редактировании.
Существуют некоторые особенности передачи кодов некоторых клавиш, связанные с обеспечением совместимости.
Логическая структура документа
DTD HTML определяет правила построения HTML-документа, синтаксис элементов разметки и их возможное взаимное расположение. Если взглянуть на документ как на множество объектов, которые ассоциируются с элементами разметки, то DTD будет задавать иерархию классов этих объектов.
Логическая структура документа определяет отношения объектов между собой. Существует, по крайней мере, две модели объектов документа: модель JavaScript и DOM. Первая поддерживается, с некоторыми оговорками, практически всеми наиболее популярными браузерами. Вторая только претендует на роль стандарта и должна в будущем поддерживаться всеми браузерами.
Отношения отдельных объектов между собой сводятся, главным образом, к отношениям типа "часть-целое", а структура документа представляет собой дерево. В роли остова выступает дерево блочных элементов разметки документа. Затем на этот остов накладываются строчные элементы и стили. Кроме того, у документа существует поддерево классов объектов документа, определяемое в DTD. Изменение свойств класса приводит к изменению свойств всех объектов данного класса (рис. 2).
Рис. 2. Логическая структура документа.
Следует отметить, что логическая структура на рис. 2 гораздо ближе к модели данных Internet Explore, чем к JavaScript. Тем не менее, IE поддерживает модель JavaScript за исключением слоев, а в новой версии Netscape Navigator обещана поддержка DOM, которая совпадает с моделью IE.
Машины, с которыми осуществляется связь
NCSA Telnet может осуществлять соединение только с компьютерами, которые имеют IP адрес. Под host1, host2 .. в строке вызова Telnet понимает адреса (имена) машин в сети. Это может быть:
Любое имя, указанное в конфигурационном файле.
Если Telnet сконфигурирован с использованием основанного на доменах name-сервера, то любое имя с доменом может быть использовано.
Полный IP - адрес. (Например: 192.17.22.20)
Если машины в одной и той же Ethernet, то можно указать #, а за ним номер машины в локальной сети.
После IP адреса можно указать #, и затем, порт соединения.
Этот алгоритм разработан для представления
Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлит встроенного "чистого" текста.
Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ "=" используется для обозначения функции спец. обработки).
ПРИМЕЧАНИЕ: этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 - часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.
Процесс кодирования преобразует 3 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.
Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта (".", CR, LF) и для синтаксиса вложенных тел MIME ("-").
Таблица 1: Алфавит Base64
Значение КодЗначение КодЗначениеКодЗначениеКод
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w = (заполнитель)
15 P 32 g 49 x
16 Q 33 h 50 y
Выходной поток ( закодированные бфайты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.
Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель '='. Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи: (1) входной поток как раз оканчивается 24-битной группой. В таком случае, выходной поток будет оканчиваться четырьмя символами Base64 без символа '='; (2) хвост входного потока имеет длину 8 бит. Тогда в конце выходного кода быдут два символа Base64, с добавлением двух символов '='; (3) хвост входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ '='.
Т.к. символ '=' является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но такой гарантии нет, если число переданных битов кратно 24.
Любые бессмысленные последовательности в коде Base64 вроде "=====" должны быть игнорированы.
Если кодируемый текст не находится в канонической форме. то перед конвертацией в Base64 необходимо сначала все концы строк заменить стандартной последовательностью CRLF. Предпочтительнее эту функцию встроить в кодировщик Base64, нежели заставлять пользователя производить предварительную канонизацию текста другими средствами.
Нет нужды экранировать вложенные тела внутри многочастного тела (multipart) при кодировании его в Base64, так как в коде Base64 отсутствует символ '-'.
Механизм конвертации "Quoted-Printable"
Этот механизм предназначен для представления данных, в основном состоящих из байтов, соответствующих символам, имеющим изображение в символьном наборе ASCII. В результате данного кодирования все байты будут иметь такие значения, гарантированные от дальнейшей модификации почтовым транспортом. Если конвертируемые данные в основном представляют собой ASCII-текст, то конечная их форма остается узнаваемой и читаемой для человека. Тело, полностью состоящее из ASCII-символов, также может быть конвертироавано в Quoted-Printable, что гарантирует его содержимому целостность при прохождении через всякие шлюзы, в которых происходит языковая перекодировка символов или преобразование концов строк и т.д.
В Quoted-Printable байты должны быть рпедставлены в соответствии со следующими правилами:
ПРАВИЛО #1: (обычное 8-битное представление). Каждый байт, кроме тех, которые используются для обозначения конца строки, может быть представлен с помощью двух шестнадцатиричных цифр, предворяемых знаком "=". При написании шестнадцатиричных цифр с A по F должны использоваться заглавные буквы. Кроме тех случаев, когда нижеследующие правила позволяют альтернативное кодирование, данное правило является обязательным.
ПРАВИЛО #2: (Буквенное представление). Байты с десятичным значением с 33 по 60 и с 62 по 126 МОГУТ быть представлены ASCII-символами, соответствующими этим значениям (с '!' по '<' и с '>' по '~').
ПРАВИЛО #3: (Пробелы): Байты со значениями 9 и 32 МОГУТ быть представлены как ASCII-символы "Табуляция" и "Пробел", но НЕ ДОЛЖНЫ быть представлены так в конце строки. Везде, где они представлены соответствующими ASCII-символами, за ними должен следовать символ, имеющий графическое изображение (печатный символ). В конце же строки символы табуляции и пробела должны быть представлены в соответствии с правилом #1, так как некоторые почтовые транспорты могут убирать пробелы в конце строки.
ПРАВИЛО #4: (Конец строки): Конец строки в тексте письма должен быть представлен (в соответствии с RFC 822) последовательностью CRLF.
Так как в каноническом представлении текста не требуется визуального отображения символов конца строки, в Quoted-Printable не используется видимых символов для обозначения конца строки. Для представления бинарных данных более предпочтительной является кодировка base64.
Необходимо заметить, что многие реализации почтовых программ могут кодировать по-своему. В частности, при представлеии текста в системах, использующих другие соглашения по обозначению конца строки (отличные от CRLF). Такие реализации недопустимы, и генерация концов строки должна быть стандартизована везде, чтобы не требовалось распознавать, используется ли какое-либо альтернативное представление.
ПРАВИЛО #5: (Мягкий конец строки): В соответствии с Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется 'мягкий' перевод строки, представимый знаком равенства. Например, если исходная строка имела вид: Now's the time for all folk to come to the aid of their country.
то в Quoted-Printable encoding он может быть представлена следующим образом: Now's the time = for all folk to come= to the aid of their country.
Это обеспечивает механизм восстановления исходной длины строки пользовательским почтовыи агентом.
Поскольку символ дефиса ("-") представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов "=_", которая никогда не появляется в теле, закодированном в Quoted-Printable. См. определение многочастного письма далее.)
ЗАМЕЧАНИЕ: Quoted-Printable представляет собой нечто вроде компромисса между читабельностью и сохранностью при пересылке. Тела в Quoted-Printable будут надежно защищены при прохождении многих почтовых шлюзов, но могут быть не очень хорошо переданы через некоторые шлюзы, использующие трансляцию в EBCDIC. (Теоретически, EBCDIC-шлюз должен кодировать тело из quoted-printable в base64 и затем декодировать обратно, но таких шлюзов пока не существует).
Единственный способ добится действительно надежной транспортировки через EBCDIC-шлюз - экранировать ASCII-символы !"#$@[\]^`{|}~
в соответствии с правилом #1.
Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.
Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как "=0D=0A", в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.
Синтаксис данных в quoted-printable описывается следующим образом: quoted-printable := ([*(простой текст / ПРОБЕЛ / ТАБУЛЯЦИЯ) простой текст] ["="] CRLF) ; Максимальная длина строки - 76 символов, включая CRLF простой текст := байт /<любой ASCII-символ "=", ПРОБЕЛ или ТАБУЛЯЦИЯ> ; символы, не перечисленные в приложении B к RFC 1521 как безопас- ; ные для почты, также не рекомендуются к использованию байт := "=" 2(ФИФРА / "A" / "B" / "C" / "D" / "E" / "F") ; байт используется для символов > 127, =, ПРОБЕЛ, или ТАБУЛЯЦИЯ, ; и рекомендуется для представления любых символов, не перечислен- ; ных в приложении B к RFC 1521 как безопасные для почты
Меню параметров NCSA Telnet
Все параметры работы NCSA Telnet обычно устанавливаются в файле конфигурации config.tel. Просмотреть некоторые параметры и/или изменить их не прерывая работу в NCSA Telnet можно через меню параметров, вызываемому по Alt+P. Например, это меню предлагает установить цвета для каждой сессии и имя Capture файла, одно для всех сессий. Вид меню параметров следующий: \hrule
Нормальный цвет символов (nfcolor)
Нормальный цвет фона (nbcolor)
Реверсный цвет символов (rfcolor)
Реверсный цвет фона (rbcolor)
Цвет подчеркивания символов(ufcolor)
Цвет подчеркивания фона (ubcolor)
** Local или Remote echo mode... (Line или Character echo mode
Backspace значение .................... Delete (Устанавливается, если возникают проблемы с удаленной машиной)
Имя сессии ............................ **> (Имя удаленной машины)
**Тип терминала ....................... VT102 и Textronix 4014 (обычно)
Перенос строк ............................ Wrapping ON
Output Mapping ........................... Mapping OFF \hrule Параметры, общие для всех сессий \hrule Имя Capture файла ....................... **> capfile
** Тип экрана (BIOS совместимость).. Direct to Screen (прямо на экран)
Передача файлов (FTP) ....................... Enabled (Разрешена)
Удаленное копирование (rcp) ............. Disabled (Не разрешено)
Часы ...................................................... Enabled (Установлены) \hrule
Microsoft + Internet = ActiveX
, "Мир Internet", ноябрь 1996 г.
В моей смерти прошу винить Билла Г.
(из сетевого юмора)
Программисты и дизайнеры World Wide Web не успели еще прийти в себя после сокрушающей лавины нововведений, обрушенной на их головы фирмой Netscape меньше года назад. Индустрия подключаемых модулей (plug-ins) для броузера Netscape Navigator едва-едва успела окрепнуть, а программисты-любители еще только вошли во вкус новых языков Java и JavaScript. В то же время поразительно единодушие, с которым именно этот набор технологий признавался единственно возможным фундаментом для построения интерактивного, динамичного и безопасного Интернета XXI века - века, когда нынешние ограничения пропускной способности каналов и мощности компьютеров уйдут наконец в прошлое.
Как вдруг... Постойте, но что же произошло? Чем объяснить появление и триумфальное шествие еще одного новшества в этой и без того перенаселенной и бурно развивающейся отрасли? Что представляет собой технология ActiveX, дебютировавшая вместе с версией 3.0 броузера Microsoft Internet Explorer? Новая ли это, быстропроходящая мода, очередная ли попытка корпорации Microsoft изобрести дудочку, под которую будет плясать весь Интернет, или действительно нечто, что изменит жизнь всех Web-дизайнеров?
Если быть предельно кратким, ActiveX - это старая добрая технология OLE (Object Linking and Embedding, "связывание и встраивание объектов"), появившаяся впервые вместе с Windows 3.1 еще в 1991 году. Сейчас Microsoft пытается приспособить OLE для наполнения WWW интерактивным содержимым, а тем самым - и для тесной, но максимально прозрачной для пользователя интеграции сетевых ресурсов с операционной системой Windows. Те, кого больше интересует мир UNIX, дальше могут не читать - ни OLE, ни ActiveX для UNIX пока не существует, и хотя Microsoft и собирается проталкивать свою новую технологию в этом направлении, никаких конкретных обещаний или тем более сроков не называется.
Как и OLE, ActiveX представляет собой довольно пестрый набор разнородных технологий, объединенных скорее общей идеологией, чем каким-то единым стандартом. Для начального ознакомления принято разделять букет ActiveX на три части - органы управления (ActiveX controls), сценарии (ActiveX scripts) и документы (ActiveX documents). Вероятно, опытного Web-дизайнера, уже знакомого с Java и JavaScript, в первую очередь заинтересуют органы управления ActiveX, которым и посвящена большая часть этой статьи.
Мифы и реальности XML
Сергей Кузнецов
ИСП РАН, Центр информационных технологий
Людям свойственно верить в философский камень. Вот-вот кто-то его изобретет, и вся жизнь изменится. Так происходит и в мире информационных технологий. Вспомним, например, краткую, но яркую историю Java-технологий. В 1995 г. мне довелось присутствовать на двухдневной конференции, организованной компанией Sun Microsystems специально для журналистов. Формально конференция посвящалась выпуску первого микропроцессора серии UltraSparc. Фактически большую часть времени заняло представление нового объектно-ориентированного языка Java. Тогда меня потрясло выступление Билла Джоя, который сказал, что создание этого языка является главным достижением в его жизни, и что наконец-то открываются реальные возможности организации и доступа в Internet мультимедийной информации. Наверное, все помнят, сколько сил и средств затратила Sun, чтобы убедить разработчиков программного обеспечения полностью перейти на использование языка Java.
Сегодня уже понятно, что Java-технологии (в частности, JavaBeans и Jini) являются еще одним набором информационных технологий, который пригоден и выгоден для использования в одних ситуациях и не приносит успеха в других случаях. Более того, мне неизвестны случаи, когда серьезные информационные системы создавались бы на основе только этих технологий без привлечения существовавших ранее или возникших параллельно (чтобы больше не отвлекаться от темы, не буду приводить конкретные примеры).
Теперь многим кажется, что XML спасет мир и приведет к новой эпохе информационного благоденствия. Возможно, оно и так, но что-то я в этом сомневаюсь. Перечислю некоторые мифы, возникшие вокруг XML:
Миф первый . XML полностью изменит жизнь в Internet, обеспечив, наконец, единое мировое информационное пространство.
Миф второй . XML станет единым общепринятым стандартом представления информации в системах электронного бизнеса (как B2C, так и B2B).
Миф третий . Основанные на XML системы баз данных за счет своей большей гибкости вытеснят реляционные и другие системы.
Этот список имеющихся мифов можно продолжать, но для наших целей их хватит. В мифы хочется верить. Но что-то редко встречаются случаи, когда слепая вера давала хорошие результаты. С другой стороны, в каждом мифе есть доля реальности. Обсудим, почему мифичны приведенные выше высказывания и какова их реальная составляющая.
Миф первый (опровержение). Что нас сегодня не устраивает в Internet? (Я не буду говорить о технических трудностях.) Фактически, сегодня Всемирная Паутина напоминает джунгли, где, конечно, можно пробраться от любого заданного места к любому другому, но если целью похода в джунгли является поиск конкретного вида орхидей, то далеко не факт, что путешествие завершится успешно. Конечно, помимо явной навигации по гиперссылкам (лианам, охватывающим все джунгли) в Internet имеется ряд поисковых машин (не знаю прямого аналога в джунглях). Но все знают, что все мы имеем право искать в Internet, но не имеем гарантий того, что найдем желаемое (даже если оно реально существует).
Миф состоит в том, что если перейти от плоских файлов HTML к полуструктурированным файлам XML, то возможности релевантного поиска резко улучшатся. За каждым мифом стоит реальность. Действительно, полностью переделав весь Internet на XML, решив массу проблем унифицированного представления метаинформации, создав принципиально новые поисковые машины, можно теоретически принципиально улучшить жизнь в Internet. Но все-таки это миф. Миф, потому что подавляющее большинство поставщиков информации в Internet не заинтересовано в том, чтобы эта информация легко находилась через универсальные поисковые машины. Реальность состоит в том, что в Internet появятся тематически ориентированные островки, зная про которые, вы действительно можете найти любую информацию по данной тематике. Но даже эта реальность - это не реальность сегодняшнего дня. Но я в нее верю.
Миф второй (опровержение). Если первый миф свойственен несчастным пользователям Internet, то второй очень сильно раздувается за счет усилий отделов маркетинга производителей аппаратуры и программного обеспечения.
Посмотрите, как здорово вышло. Почти одновременно возникли два непонятных, но заманчивых термина - "электронный бизнес" и "XML". И солидные компании говорят вам, что электронный бизнес гарантирует вашей собственной компании абсолютное процветание, но этот бизнес можно основывать только на продуктах, базирующихся на XML. Хороший маркетинговый ход, мне он и самому нравится. Но в чем состоит реальность?
А она состоит в том, что для достижения реального успеха в электронном бизнесе при создании соответствующей системы требуется решить массу задач, не имеющих никакого отношения к XML. XML не может претендовать даже на роль стандарта представления информации, поскольку почти всегда наряду с наличием новых XML-баз данных разумно допустить существование традиционных структурированных баз данных. Так в чем же состоит реальность? Она состоит в том, что в электронного бизнеса как правило действительно требуется возможность хранения и выбирки данных, которые не являются полностью структурированными. Да, на сегодня наилучшим кандидатом для представления данных является XML, но имеется множество нерешенных (или решенных плохо) проблем, мешающих использованию этого языка.
Миф третий (опровержение). Давайте вспомним, откуда есть пошли базы данных. А оттуда, что при наличии только файловых систем (с которых и началось управление данными во внешней памяти) структуру данных (бухгалтерских, банковских, систем резервирования и т.д.) приходилось поддерживать в прикладной программе. А если их больше одной? Как контролировать согласованность? Я ж не буду говорить про целостность данных, возможность многопользовательского доступа, транзакционное управление, журнализация изменений и восстановление после сбоев и т.д. Мифичность того, что базы данных, основанные на XML, вытеснят традиционные базы данных, для меня очевидна. Имеется масса прикладных областей, в которых нужны именно структурированные, а не полуструктурированные данные. Для них нужны и будут нужны традиционные базы данных со структурированной схемой.
Реальность состоит в том, что имеется множество информационных приложений, для которых данные не укладываются естественным образом в традиционные модели. Для них XML может быть весьма полезен. Но замечу, что при наличии нескольких коммерческих серверов XML-баз данных, ни в одном из них пока не решены в полном объеме те задачи, с решением которых успешно справляются традиционные СУБД.
Хочу ужесточить свою позицию и заявить о том, что, по моему мнению, разумно использовать любую технологию, связанную с XML, можно только в комбинации с другими технологиями. Приведу несколько примеров.
В некотором смысле XML аналогичен языку ассемблера. Предположим, что нам требуется спроектировать некоторую XML-базу данных. (Если вы думаете, что для таких баз данных фаза проектирования не требуется, то глубоко ошибаетесь.) Один из подходов состоит в использовании UML (Unified Modeling Language). Существует де-факто стандарт отображения UML в XML. Имеется соответствующая промышленная поддержка.
Когда мне говорят, что MS Explorer теперь поддерживает XML, я громко смеюсь. Очевидно, что стандартный браузер понимает только подмножество XML, а определенные пользователями теги просто игнорирует. Насколько я понимаю, возможны два решения для обеспечения адекватного восприятия XML-документов на стороне пользователя. Первый (очевидный) подход - создание специализированных браузеров, понимающих смысл DTD заданного набора XML-документов. Второй подход состоит в использовании Java-апплетов. Он универсален и обеспечивает возможность правильной работы с XML-документами с любого стандартного браузера.
Если возникает желание создать на основе XML распределенную информационную систему, то, конечно, потребуется использование дополнительного программного обеспечения промежуточного уровня (middleware). Для меня предпочтительнее была бы CORBA, но возможны решения и на основе COM/DCOM или RMI.
Наконец, я глубоко уверен, что какие бы новые языки запросов не были придуманы для XML-баз данных, будет жить язык SQL.Рано или поздно понадобится реализовать SQL для работы с XML-базами данных, обладающими реляционной структурой. Тогда и пригодится инженерия традиционных SQL-ориентированных СУБД.
Я далеко не пессимист и надеюсь, что появление XML-технологий и стандартов реально позволит улучшить информационную технологию в целом, хотя и не произведет революционного переворота.
Модель объектов JavaScript
В модели JavaScript самым старшим объектом является объект window - считается, что все происходящее с документом вложено в окно. У окна имеется несколько объектов-свойств: location, history, document, navigator. Это не полный перечень объектов окна, но для иллюстрации модели данных JavaScript он достаточен.
Объект location ассоциируется с полем location браузера, где отображается URL загруженного в окно документа. У location есть свойства и методы. При изменении значения свойства location или при вызове метода происходит перезагрузка документа. При перезагрузке может пополняться защищенный массив объекта history - множество URL, которые посещал пользователь. Основным способом использование history являются методы window.history.back(), window.history.forward() и window.history.go(-1).
Объект navigator позволяет отображать документ в соответствии с требованиями браузера и его настройками. Подчинение этого объекта window выглядит несколько нелогично: несмотря на множество обслуживаемых окон программа браузера одна. Наиболее полезны свойства объекта navigator, например, фрагмент кода позволяет загрузить страницы по типу навигатора.
...
Если необходимо проверить исполняемость Java-кода на стороне браузера, например, для загрузки страницы с апплетом или без него, то это можно сделать, применив соответствующий метод объекта navigator.
Объект document ассоциирован с телом документа и включает в себя другие объекты, которые могут быть поименованы, как, например, объекты IMG или FORM, а также могут входить во встроенный массив, как, например, гипертекстовые ссылки (links[] ).
Первоначально в JavaScript особое внимание уделялось формам. По этой причине к формам относится наибольшее число классов объектов документа. Это и сама форма объект FORM, и элементы формы: поля ввода (input) различных типов, меню (select) и его составляющие (options), поля ввода больших блоков текста (textarea).
У каждого из этих объектов достаточно большое количество свойств и методов.
Наибольших визуальных эффектов достигают за счет изменения свойства src объекта IMG, который может быть поименованным объектом документа. Он также входит во встроенный массив document.images[].
В JavaScript можно изменять значения гипертекстовых ссылок, а также указывать JavaScript-код вместо гипертекстовой ссылки, используя схему URL javascript. Это позволяет, в частности, отказаться от кнопок в формах и отправлять данные формы, нажимая на гипертекстовую ссылку.
Таким образом, видно, что модель данных JavaScript - это дерево. К его объектам принято обращаться по составным именам, например: window.document.cookie - строка ассоциативный массив "волшебных ключиков", window.document.forms.length - число форм в документе, window.document.images[0].src - URL первой картинки документа, window.location.href - URL загруженного в данный момент документа, window.frames.length - число фреймов в документе.
Сам объект при этом рассматривается как тройка: свойства, методы, события. Свойства - это скалярные характеристики объекта, методы - это функции, которые могут изменять свойства. События это внешние воздействия на объект, для которых можно написать функцию-обработчик события. Именно с программированием событий связаны различные эффекты типа расцвечивания черно-белых картинок или изменения картинки при прохождении курсора мыши через гипертекстовую ссылку.
Особенность модели событий в JavaScript заключается в том, что события жестко привязаны к объекту. Например, у гипертекстовой ссылки у элемента ... может быть событие onMouseover, а у элемента IMG такого события, а, следовательно, и обработчика этого события, быть не может. Логика в этом есть: IMG - это пассивный объект. В него никто не будет тыкать курсором мыши и по умолчанию при проходе курсора над IMG информация на экране не меняется. У пассивного объекта нет функций обработчиков событий, которые можно было бы заменить JavaScript-кодом.
Другое дело гипертекстовая ссылка. При проходе курсора мыши над ней в строке статуса отображается URL, при выборе мышью ссылки происходит переход на другую страницу - по крайней мере, три стандартных обработчика событий у гипертекстовой ссылки имеется.
Кстати сказать, для свойств объектов в модели JavaScript определены свои правила инициализации. Например, размер картинки, если он только не указан явно в элементе разметки IMG, будет определяться первой картинкой. Все остальные картинки будут масштабироваться в этот размер независимо от их реальных линейных размеров. Аналогичное "поведение" характерно и для кнопок. Их размер определяется первой надписью, значение атрибута value элемента разметки INPUT. Это сделано для того, чтобы не переформатировать загруженный документ.
С точки зрения традиционного программирования наличие стандартных обработчиков событий и возможность изменения свойств - это вопрос инициализации данных и резервирования места под код и значения переменных. В JavaScript он решается в момент загрузки документа, когда создаются все встроенные объекты документа. После того, как произошло событие Load (обработчик onLoad элемента разметки BODY), встроенные объекты больше не создаются. По этой же причине при использовании метода
Моделирование Элементов данных для Бизнес объектов.
Основой введения электронного бизнеса являются обмен электронными сообщениями, на основании которых осуществляются принятие решения по проведению операций при торговых сделках. В качестве базовой структуры сообщения используется опыт при создании сообщений стандарта UN/EDIFACT. В итоге моделирования необходимо получить описания структуры сообщения в виде структуры XML/DTD или XML-схемы.
На рис 3. изображена трехступенчатая схема реализации модели сообщения.
Рис 3.
Шаг 1 - ручное преобразование в Бизнес модель (БМ) на основе использования Руководства по разработки сообщений EDIFACT. При этом преобразовании имеется в виду перенос синтаксиса элементов EDIFACT всех спецификаций и выделение функциональной спецификации на содержание информации и ее структуры.
Шаг 2 - преобразование БМ в UML Модель сообщений. Преобразование поддерживается программным комплексом моделирования UML, используются такой аппарат как класс диаграмм, класс списка атрибутов и т.д.
Шаг 3 - создание соответствия Бизнес модели XML/DTD и XML-схемы. Данное преобразование осуществляется специально разработанным программным обеспечением.
Шаг 4 - (необязательный) Возможность запомнить образ UML Модели сообщения и создание домена транспортной модели для использования накопленного опыта при разработке других типов сообщения.
Точное отражение EDIFACT структуры включает имена сегментов, составных и отдельных элементов данных.
Сообщение UN/EDIFACT можно разобрать на следующие самостоятельные единицы, вложенные друг в друга:
Сообщение Сегмент Элемент данных Клалификатор
Осуществление ручного переноса (шаг 1) структуры сегмента сообщения в термины описания XML/DTD требует хорошего понимания структуры сообщения и знания стандарта UN/EDIFACT. Ниже приведен пример преобразования в DTD начального сегмента сообщения - BGM.
Структура сегмента BGM в соответствии со спецификацией :
#гр.эл. #спр описание элемента данных обяз/необ формат даннных M/C данных ____________________________________________________________________________ 010 C002 DOCUMENT/MESSAGE NAME C 1001 Document/message name, coded C an..3 1131 Code list qualifier C an..3 3055 Code list responsible agency, coded C an..3 1000 Document/message name C an..35 020 C106 DOCUMENT/MESSAGE IDENTIFICATION C 1004 Document/message number C an..35 1056 Version C an..9 1060 Revision number C an..6 030 1225 MESSAGE FUNCTION, CODED C an..3 040 4343 RESPONSE TYPE, CODED C an..3 ____________________________________________________________________________
Таблица 1
Преобразовывая сегмент сообщения BGM, опуская неиспользуемые клалификаторы, мы получим следующий вид DTD:
____________________________________________________________________________ ____________________________________________________________________________
Подходя комплексно к моделированию всего сообщения, используются как информация из базовых сегментов, таких как NAD, RFF, DOC и пр., так и учитывается их семантика и месторасположение.
При создании Бизнес модели используются следующие принципы:
Бизнес модель разделена на следующие секции: реквизиты сообщения, стороны, таможенные отметки, упаковка, товары, документы, коды; основные сегментные группы или сегменты корневого уровня должны соответствовать секции БМ. термины данных БМ могут порождаться из других элементов данных EDIFACT или из значения кодов для определенных элементов данных; подсекции бизнес модели должны быть основаны в соответствии с надобностями, понимания бизнес операций. Это не обязательные предлагаемые структуры составных элементов данных или группы сегментов; Использование термина данных в БМ на уровне кодов данных сслылается на свю "концепцию кода" имена БМ должны быть специфицированы достаточным для понимания; в БМ использовать смысловую семантику, так например таг, описывающий перевозимые товары может именоваться GoodItems дублирование имен недопустимо.
Моделирование Web и запросы
Если Web рассматривается как большая, графового типа база данных, естественно формулировать запросы, которые выходят за рамки основной парадигмы информационного поиска, поддерживаемой современными механизмами поиска, и принимают во внимание структуру. Имеется в виду не только внутренняя структура страниц Web, но и внешняя структура связей, которые их соединяют. В часто цитируемой статье об ограничениях гипертекстовых систем [Hal88] Халаш говорит:
"Поиск по содержанию игнорирует структуру гипермедийной сети. Напротив, при структурном поиске в гипермедийной структуре осуществляется поиск таких подсетей, которые соответствуют заданному шаблону" и приводит примеры, где такие запросы оказываются полезными.
3.1. Структурный информационный поиск
Первыми инструментальными средствами для обработки запросов в Web, были известные поисковые машины, которые теперь широко развернуты и активно используются. Они основаны на поисковых индексах слов и фраз, встречающихся в документах, обнаруженных "роботами" (crawler) Web. Совсем недавно были предприняты усилия, направленные на преодоление ограничений этой парадигмы за счет использования в запросах структуры связей. Например, в [Kle98], [BH98] и [CDRR98] предлагается использовать структуру Web для анализа многочисленных сайтов, выдаваемых поисковой машиной в качестве релевантных запросу, с тем, чтобы выделить из них те, которые, вероятно, являются авторитетными источниками по интересующему вопросу. Для того, чтобы поддержать анализ связности (connectivity) для этого и других приложений (например, для эффективных реализаций языков запросов, описанных ниже), быстрый доступ к структурной информации обеспечивается сервером связности [BBH+98]. Прототип поисковой машины Web следующего поколения Google [BP98] интенсивно использует структуру Web для повышения производительности функционирования "робота" и индексирования. Другие методы, опирающиеся на использование структуры связей, предлагаются в [PPR96, CK98].
В этих работах структурная информация обычно используется "за сценой" для повышения качества ответов на запросы, которые в чистом виде ориентированы на содержание. Спертус [Spe97] указывает много полезных приложений, связанных с обработкой запросов, которые в явном виде принимают во внимание структуру связей.
3.2. Родственные парадигмы запросов
В этом подразделе мы кратко опишем несколько семейств языков запросов, которые не разрабатывались специально для использования в среде Web. Однако поскольку концепции, на которых они основаны, по своему духу подобны концепциям языков запросов Web, которые мы здесь обсуждаем, эти языки могут быть также полезными для приложений Web.
Гипертекстовые/документальные языки запросов: Ряд моделей и языков запросов для структурированных документов и гипертекстов был предложен еще в период, предшествующий появлению Web. Так, Абитебул и др. [ACM93] и Кристофидес и др. [CACS94] отображают документы в объекты объектно-ориентированной базы данных посредством семантических действий, присоединенных к грамматике. Далее можно делать запросы относительно такого представления базы данных с использованием языка запросов базы данных. Новый аспект этого подхода заключается в возможности производить запросы относительно структуры с помощью переменных-путей. Гутинг и др. [GZC89] моделируют документы, использующие вложенные упорядоченные отношения и используют некоторое обобщение алгебры вложенных отношений как язык запросов. Бири и Корнацкий [BK90] предлагают логику, формулы которой специфицируют шаблоны на графе гипертекста.
Графовые языки запросов: Исследования, связанные с использованием графов для моделирования баз данных, которые были стимулированы такими приложениями, как разработка программного обеспечения и управление компьютерными сетями, привели к созданию языков целого ряда языков, например, G, G+ и GraphLog [CMW87, CMW88, CM90], основанных на графах. В частности, G и G+ основаны на помеченных графах. Они поддерживают использование в запросах правильных выражений путей и графовых конструкций.
Язык GraphLog, семантика которого основана на Datalog, был применен в [CM89] для гипертекстовых запросов. Переденс и др. [PdBA+92] разработали графовый язык запросов для объектно-ориентированных баз данных.
Языки запросов для слабоструктурированных данных: Такие языки запросов для слабоструктурированных данных, как Lorel [AQM+97], UnQL [BDHS96] и STRUDQL [FFLS97], также используют помеченные графы как гибкую модель данных. В отличие от графовых языков запросов, они делают акцент на возможности запрашивать схему и приспосабливаться к нерегулярностям в данных, таких, например, как опущенные или повторяющиеся поля, неоднородные записи. В аналогичной работе из области объектно-ориентированных систем [Har94] предложены модели и запросы с "недостаточной схемой" (schema-shy) для управления информацией относительно артефактов разработки программного обеспечения.
Как уже говорилось, эти языки не были разработаны специально для Web, и в них не делается различия, например, между дугами графа, которые представляют соединения между документом и одной из его частей, и дугами, представляющими гиперссылки из одного документа Web на другой. Их модели данных, хотя они и элегантны, не слишком богаты, поскольку в них испытывается недостаток таких важных средств, как записи и упорядоченные коллекции.
3.3. Языки запросов первого поколения для Web
Авторы языков запросов первого поколения для Web стремились сочетать в них возможности запросов, основанных на содержании, присущие поисковым машинам Web, с возможностями запросов, основанных на структуре, подобными тем, которые характерны для систем баз данных. Такие языки, к числу которых относятся W3QL [KS95], WebSQL [MMM97, AMM97a] и WebLog [LSS96], сочетают в себе условия, налагаемые на образцы текста, появляющиеся в документах, с графовыми шаблонами, описывающими структуру связей. Далее мы будем использовать WebSQL для демонстрации примеров запросов, возможных в языках такого рода.
Язык WebSQL: В языке WebSQL предлагается моделировать Web как реляционную базу данных, состоящую из двух (виртуальных) отношений: Документ и Якорь.
Отношение Документ содержит по одному кортежу для каждого документа из Web, а отношение Якорь - по одному кортежу для каждого якоря в каждом документе из Web. Такая реляционная абстракция Web позволяет нам использовать для формулировки запросов язык, подобный SQL.
Если бы Документ и Якорь были фактическими отношениями, мы могли бы просто использовать SQL, чтобы записывать на нем запросы. Но поскольку эти отношения являются полностью виртуальными и не имеется какого-либо способа производить над ними вычисления, мы не можем оперировать ими непосредственно. Семантика WebSQL зависит от материализации частей этих отношений путем спецификации представляющих интерес документов во фразе FROM запроса. Основным способом материализации части Web является навигация из известных URL. Для описания такой навигации используются правильные выражения путей. Атом такого правильного выражения может иметь форму d1 = > d2, означающую, что документ d1 указывает на d2, и d2 хранится на ином сервере, чем d1. Он может иметь также форму d1 - > d2, которая, в свою очередь, означает, что d1 указывает на d2, и d2 хранится на том же самом сервере, что и d1.
Предположим, например, что мы хотим найти список триплетов вида (d1, d2, метка), где d1 - документ, хранимый на нашем локальном сайте, d2 - документ, хранимый где-либо еще, и d1 указывает на d2 с помощью связи, помеченной меткой. Допустим также, что все наши локальные документы достижимы из www.mysite.start. Тогда указанную задачу можно решить с помощью запроса:
SELECT d.url, e.url, a.label FROM Document d SUCH THAT -> d, Document e SUCH THAT d => e, Anchor a SUCH THAT a.base = d.url WHERE a.href = e.url
Предложение FROM порождает экземпляры двух переменных, определенных на отношении Документ, - d и e, и одной переменной a - на отношении Якорь. Области определения переменной d принадлежит каждый локальный документ, достижимый из начального документа, а e принимает значения на множестве всех не локальных документов, достижимых непосредственно из d.
В свою очередь, значением переменной a может являться каждая связь, которая исходит из документа d. Дополнительное условие, предписывающее, чтобы целевым документом связи a был документ e, задается предложением WHERE. Другим способом материализации части отношений Документ и Якорь является использование условий, налагаемых на содержание (content condition). Например, если для нас представляли интерес только документы, которые содержат строку "база данных", мы могли бы добавить в предложение FROM условие: d MENTIONS "база данных". В этом случае в реализации использовались бы поисковые машины для генерации возможных документов, удовлетворяющих условию NENTION.
Другие языки: Язык W3QL [KS95] подобен, по существу, WebSQL, с некоторыми значительными различиями: он использует внешние программы (аналогично определяемым пользователем функциям в объектно-реляционных языках) для спецификации условий, налагаемых на содержание файлов, а не формирование условий в синтаксисе языка, и это обеспечивает механизмы для обработки форм, встречающихся в процессе навигации. В работе [KS98] Конопницкий и Шмуэли описывают планируемые расширения, позволяющие превратить W3QL в то, что мы называем теперь языками второго поколения. Эти расширения предусматривают моделирование внутренней структуры документов, иерархическое моделирование Web, в котором явно фигурирует понятие Web-сайта, а также отказ от использования метода внешних программ для спецификации в пользу обобщенного расширяемого метода, основанного на стандарте MIME.
WebLog [LSS96] отличается от рассмотренных выше языков использованием дедуктивных правил вместо SQL-подобного синтаксиса (см. описание FLORID ниже).
WQL, язык запросов проекта WebDB [LSCH98], подобен WebSQL, но он в большей мере поддерживает функциональные возможности SQL, допуская, например, агрегацию и группирование, и, кроме того, обеспечивает ограниченную поддержку запросов внутридокументной структуры. Это обстоятельство позволяет отнести его к классу языков, обсуждаемых в следующем подразделе.
3.4. Второе поколение: Языки манипулирования данными Web
Рассмотренные выше языки интерпретируют страницы Web как атомарные объекты с двумя свойствами: они могут содержать или не содержать некоторые текстовые образцы и они могут указывать на другие объекты. Опыт использования таких языков показывает, что имеется две основные области приложений, для которых они могут быть полезны. Одна из них, рассматриваемая в разделе 4, - создание оболочек (wrapping) для данных, трансформация и реструктуризация данных. Вторая из этих областей - создание и реструктуризация Web-сайтов - обсуждается в разделе 5. В обеих этих областях приложений часто оказывается существенной возможность иметь доступ к внутренней структуре страниц Web из языка запросов, если мы хотим, чтобы декларативные запросы могли оперировать большой частью задачи. Например, задача извлечения множества кортежей из HTML-страниц сайта Internet Movie Database требует синтаксического анализа HTML-страниц и избирательного доступа к некоторым поддеревьям в дереве синтаксического анализа.
В этом подразделе мы опишем языки запросов второго поколения для Web, которые мы называем "языками манипулирования данными Web". Эти языки превосходят языки первого поколения в двух важных аспектах. Прежде всего, они обеспечивают доступ к структуре объектов Web, которыми они манипулируют. В отличие от языков первого поколения, они моделируют внутреннюю структуру документов Web, а также внешние связи, которые их соединяют. Они поддерживают связи для моделирования гиперссылок, а некоторые из них поддерживают также упорядоченные совокупности записей для более естественного представления данных. Во-вторых, эти языки обеспечивают возможности создания новых сложных структур в результате запроса. Поскольку данные в Web обычно являются слабоструктурированными, в этих языках придается особое значение поддержке возможностей для работы со слабоструктурированными данными. Далее кратко описываются три языка этого класса: WebOQL [AM98], STRUQL [FFLS97] и FLORID [HLLS97].
Multipart: общий синтаксис
Поле Content-Type многочастного письма требует одного параметра, "boundary", который определяет границы вложения. Границей является строка, состоящая из двух символов "-" (десятичный код 45) и значения параметра 'boundary' из поля заголовка Content-Type.
ЗАМЕЧАНИЕ: Два символа "-" используются для совместимости с более ранним методом вложения писем, описанным в RFC 934 и для облегчения поиска границ. Однако, многочастные письма MIME не полностью совместимы с RFC 934; в частности, они не подчиняются соглашению RFC 934 по экранированию строк символом "-", так как с каждым новым уровнем экранирования длина строк увеличивается. А поскольку SMTP-транспорты часто обрезают длинные строки, этот механизм становится неприменимым в случае многоуровневой структуры письма типа 'multipart'.
ВНИМАНИЮ ПРОИЗВОДИТЕЛЕЙ ПО: синтаксис параметров поля Content-Type таков, что зачастую необходимо значения границ в параметре 'boundary' заключать в кавычки. Это не всегда требуется, но никогда не повредит. Программистам следует изучить синтаксис внимательно, чтобы не допустить ошибок в поле Content-Type. Типичное поле Content-Type для типа 'multipart' может выглядеть следующим образом: Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p
Но в следующем примере содержится ошибка: Content-Type: multipart/mixed; boundary=gc0p4Jq0M:2Yt08jU534c0p
(из-за двоеточия), которая может быть исправлена следующим образом: Content-Type: multipart/mixed; boundary="gc0p4Jq0M:2Yt08jU534c0p"
Это означает, что тело письма состоит из нескольких частей, каждая из которых соответствует синтаксису письма RFC 822, за исключением того. что область заголовка может быть абсолютно пустой и начальная граница каждой части отмечена последовательностью: --gc0p4Jq0M:2Yt08jU534c0p
Нужно обратить внимание, что метка границы части письма должна располагаться в начале строки, то есть, сразу же после признака конца строки CRLF. Причем, последовательность CRLF полагается элементом метки границы, а не последним элементом тела предыдущей части (так как тело предыдущей части может неоканчиваться концом строки, что принципиально важно в случае бинарных данных.
Если же тело предыдущей части оканчивается концом строки, то метке границы соответственно должны предшествовать два конца строки). Сразу за меткой границы должен следовать конец строки (CRLF), или при отсутствии заголовка следующей части письма, два конца строки.
Метка границы не должна иметь длину более 70 символов, не считая два начальных дефиса.
Метка границы, следующая за последней частью письма, должна отличаться от предыдущих меток, чтобы показать, что далее не последует другой части письма. Отличие последней метки состоит в добавлении двух дефисов в конец: --gc0p4Jq0M2Yt08jU534c0p--
Обычно оставляется пространство для дополнительной информации перед первой меткой границы и после последней. Обычно его следует оставлять пустым, и обработчики почты должны игнорировать все, что в этом пространстве содержится.
ЗАМЕЧАНИЕ: Эти области приамбулы и эпилога обычно не используются из-за отсутствия точной семантики для обработки этих областей почтовыми шлюзами, однако, многие программные MIME-продукты считают удобным помещать туда пояснительную информацию для получателей, которые пользуются до-MIME'овским ПО. По этой причине, MIME-совместимые программы должны игнорировать эти области.
ЗАМЕЧАНИЕ: Поскольку метки границы не должны появляться внутри тел частей письма, почтовая программа, создающая письмо, должна иметь алгоритм, позволяющий автоматически подобрать уникальную последовательность, не встречающуюся в теле ни одной из частей, либо имеющую минимальную вероятность появления, если данные предварительно не сканируются на наличие таковой.
В качестве простого примера предлагается двухчастное письмо, вторая часть которого оканчивается признаком конца строки, а первая нет: From: Nathaniel Borenstein To: Ned Freed Subject: Sample message MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary" Это приамбула. Должна быть игнорирована --simple boundary Это простой ASCII-текст. Он НЕ оканчивается признаком конца строки. --simple boundary Content-type: text/plain; charset=us-ascii Это простой ASCII-текст.
Он оканчивается признаком конца строки. --simple boundary-- Это эпилог. Тоже должен игнорироваться MIME-программами.
Часть письма, в свою очередь, также может иметь тип 'multipart', то есть. быть многочастным телом, но при этом метки границ, использующиеся во внешнем и во внутреннем multipart-телах, должны отличаться друг от друга.
Использование типа 'multipart' в одночастном письме может быть полезно в некоторых контекстах и не запрещено.
Единственным обязательным параметром для типа 'multipart' является параметр 'boundary', состоящий из 1-70 символов без хвостовых пробелов (которые могут быть удалены в процессе пересылки, и тогда почтовая программа получателя не сможет разделить вложенные части). граница := 0*69<символов границы> символ_границы_кроме_пробела символ границы := символ_границы_кроме_пробела / " " символ_границы_кроме_пробела := ЦИФРА / БУКВА ЛАТИНСКОГО АЛФАВИТА / "'" / "(" / ")" / "+" /"_" / "," / "-" / "." / "/" / ":" / "=" / "?"
Общий вид многочастного тела - следующий: многочастное тело := приамбула вложения признак_конца эпилог вложение := разделитель часть_тела CRLF разделитель := "--" метка_границы CRLF ; метка границы должна браться из поля Content-Type. ; Не должно быть пробелов между "--" и меткой границы. признак конца := "--" метка_границы "--" CRLF ; Опять, без пробела перед "--", приамбула := игнорируемый текст эпилог := игнорируемый текст игнорируемый текст := *(*текст CRLF) часть_тела := <письмо RFC 822, со всеми необязательными полями заголовка>
ЗАМЕЧАННИЕ: В некоторых транспортах такие ограничения RFC 822, как использование тольеко печатных символов в теле, могут не действовать. Ослабления таких ограничений должны быть истолкованы как локальные расширения определения тела письма настолько, насколько они поддерживаются почтовым транспортом и адекватно документированы в поле заголовка Content-Transfer-Encoding.Однако, ни при каких обстоятельствах в заголовках как письма, так и его частей, не должно содержаться каких-либо символов, кроме US-ASCII.
На примере прогнозов погоды с Yahoo.com
Тотоев Александр,
,
Добре, господа!
Пример предназначен для тех, кто начинает работать с php, и не только для них.
Результатом работы программы(скрипта) является прогноз погоды на 5 дней для любого, интересующего Вас города, выводимый в виде, который нравится именно Вам, а не дизайнерам сайта-донора.
Информация в таких случаях берется с известных серверов прогноза погоды (где не пишут фразу "запрещено использование информации" и т.п.). В данном случае используется сервер http://weather.yahoo.com , на котором есть страницы с погодой для довольно большого количества городов, и практически всегда можно найти если не интересующий Вас город, то ближайший ему и идентичный по погодным условиям.
Это законченный проект, работающий на сайте .
Единственным недостатком является лишь то, что админу приходится вводить в текстовый файл (возможен вариант с mysql, но в том случае мне было проще сделать в файле) название населенного пункта на родном языке и ссылку на страницу с прогнозом погоды на него на сервере Яхо. Но никто за Вас этого делать не будет.
Посему, скрипт состоит из 2-х частей:
Файл с администрированием (вводится в первую строку название города, на следующей строке - ссылка). Разбирать работу данной части, думаю, не стоит, комментариев более чем достаточно. Файл с самой программой. Работа программы будет подробно описана ниже.
На распутье
Как известно, корпорация Microsoft всерьез заинтересовалась Интернетом с большим опозданием. Тем больше людских, финансовых и рекламных ресурсов этой империи брошено сейчас на завоевание нового континента. Microsoft прекрасно знает, что выигрывает всегда тот, кто диктует правила игры. Поэтому нет ничего удивительного в том, что борьба сейчас идет не за создание особо качественного продукта (да это и невозможно при той скорости, с которой Netscape и Microsoft выбрасывают на рынок все новые и новые версии своих броузеров) и даже не за завоевание симпатий максимального количества пользователей, а в первую очередь за признание и бесповоротное утверждение новых стандартов. Нынешнее отношение Microsoft к Интернету лучше всего передается словосочетанием, встретившимся в одной из официальных публикаций корпорации на эту тему - agressive embrace, "агрессивное объятие"...
Что же делать в этой ситуации нам - простым смертным, развлекающимся время от времени рисованием страничек для World Wide Web? На кого держать равнение? Имеет ли смысл менять свои привычки так же часто, как меняется мода в компьютерном мире? Большинство, вероятно, ответят на этот вопрос пожиманием плечами - и в самом деле, немало страниц в Web вполне прилично выглядят даже в броузере Lynx, так что моральное устарение им совершенно не грозит (как известно, старомодным может выглядеть только то, что когда-то было модным).
Однако всем, кого любопытство или жажда самовыражения выводят за рамки двух десятков базовых тегов HTML, жить теперь станет куда сложнее - хотя, наверно, и интереснее. Даже если вы не собираетесь пользоваться ActiveX, теперь, когда Internet Explorer почти не уступает Netscape Navigator по набору возможностей, особенно остро встает вопрос о совместимости всех нестандартных компонентов с обоими этими броузерами. Я уверен, что уже в самое ближайшее время умение создавать такие страницы, которые выглядят более-менее одинаково в двух главных броузерах Интернета, перейдет в разряд жизненно необходимых.
Впрочем, если вся эта суета вам не по душе, вы можете попробовать переждать период бурь и войн - вероятно, рано или поздно кто-то один выйдет из схватки победителем... или же (что куда менее вероятно) все станут настолько совместимы друг с другом, что проблемы отпадут сами собой. Когда это будет? Если вспомнить, что еще два года назад индустрии броузеров попросту не существовало, - вероятно, ждать осталось не так уж и долго. Вместо этого планы Microsoft дали повод острословам придумать новое словечко - "Winternet", эдакий гибрид "Windows" и "Internet"... или, попросту говоря, такой Интернет, каким Microsoft видит его в своих мечтах.
НАЗЫВАТЬ ВЕЩИ СВОИМИ ИМЕНАМИ
Не ограничивая автора каким-либо фиксированным набором тегов, XML позволяет ему вводить любые имена, представляющиеся полезными. Эта возможность является ключевой для активного манипулирования данными. В качестве примера я приведу для сравнения то, как список имен и адресов выглядит на HTML, и то, как он будет представлен на XML. Вот фрагмент HTML:
Еditor Сontacts Имя: Джонатан Эйнджел Должность: старший редактор Издание: Network Magazine Улица и дом: Гариссона, 600 Город: Сан-Франциско Штат: Калифорния Индекс: 94107 Электронная почта: jangel@mfi.com
Теги размещают данные на экране, но ничего не сообщают об их структуре. Конечно, вы можете сами домыслить их структуру и даже вставить длинный список записей в электронную таблицу, но что произойдет, если одна из записей не будет содержать строки с адресом электронной почты или название улицы и города окажутся перепутаны местами? В случае XML тот же самый фрагмент будет представлен следующим образом (и сохранен в файле EDITORS.XML).
Джонатан Эйнджел старший редактор Network Magazine Гариссона, 600 Сан-Франциско Калифорния 94107 jangel@mfi.com
XML, лишь несколько более «многословный», чем HTML, намного упрощает определение того, что собой представляют и где находятся поля данных. В XML теги не могут накладываться, как в HTML (что не поощряется, но допускается большинством программ разбора HTML). Однако они могут быть вложены в друг друга.
На самом деле, вложение даже поощряется как способ создания иерархии данных (подчиненные или равноправные отношения). Как видно из приведенного примера, такие элементы, как и , содержат данные, в то время как другие () присутствуют только в целях структурирования. Теги начала и конца элемента являются основными используемыми в XML разметками, но ими дело не исчерпывается. Например, элементам могут быть присвоены атрибуты. Эта возможность аналогична имеющейся в HTML, где, например, элементу может быть присвоен атрибут align=”center”. В XML элемент может иметь один или более связанных с ним атрибутов, причем при составлении документа вы можете выдумать их столько, сколько пожелаете, например . Документы XML могут содержать ссылки на другие объекты. Ссылки представляют собой строку, начинающуюся с амперсанта и заканчивающуюся точкой с запятой. Эти ссылки позволяют, в частности, вставить в документ специальные символы, включение которых самих по себе могло бы сбить с толку программу разбора. Например, чтобы поместить в документ знак «меньше, чем» (<) вы должны вставить ссылку <, а чтобы вставить сам амперсант — ссылку &, и т. д. До сих пор все так же, как и в HTML. Однако ссылки XML на объекты предоставляют гораздо больше возможностей, так как они могут ссылаться на определенные автором разделы текста в том же самом или в другом документе. Например, ссылки на объекты позволяют применить объектно-ориентированный подход при создании журнальной статьи:
&introduction; &body; &sidebar; &conclusion; &resources;
Другими видами разметки XML являются комментарии (они выделяются точно так же, как в HTML) и инструкции по обработке. Инструкциям по обработке предшествует знак вопроса. Они описывают, что именно программа разбора должна использовать для интерпретации конкретного документа или его раздела.Например, инструкция сообщает программе разбора XML, что обрабатываемый документ действительно составлен с помощью XML. С другой стороны, инструкция служит для вызова программы разбора RTF и вставки символа конца страницы. Наконец, разделы символьных данных — это части документа, рассматриваемые исключительно как символьные данные, не подвергающиеся разбору. Они выглядят следующим образом:
Этот текст, даже если он содержит элементы кода HTML, такие, как жирныйшрифт или заголовок , не подвергается грамматическому разбору. Вместо этого он отображается как есть.
]]>
NCSA Telnet
NCSA Telnet версии 2.3 для PC обеспечивает интерактивный доступ с IBM PC к машинам, объединенным TCP/IP сетью. NCSA Telnet представляет собой стандартный Telnet DARPA с добавлением некоторых особенностей, использующих преимущества PC.
NCSA утилиты
Все перечисленные утилиты являются стандартными под UNIX. Их подробное описание имеется в UNIX Manual Pages.
finger - выдает информацию о пользователях;
ftp - представляет собой минимальный стандарт FTP (File Transfer Protocol) сервера, подобного 4.2 BSD UNIX. Поддерживает:
- передачу текстовой (ASCII) и бинарной (IMAGE) информации;
- изменение, создание и удаление директорий;
- печать текущей директории;
- выдачу списка файлов текущей директории согласно спецификациям, установленным по шаблону;
- прием/передачу множества файлов с помощью одной команды и с использованием шаблонов;
- удаление файлов.
Передача текстовой (ASCII) информации между машиной под UNIX и PC под DOS происходит с автоматическим преобразованием формата файлов UNIX-DOS и наоборот.
rcp - Berkeley UNIX утилита в оригинале предназначенная для обмена информацией между машинами: UNIX - UNIX. В случае связи UNIX - DOS используется для передачи бинарных файлов. Для текстовых файлов не поддерживает преобразования форматов. (* отсутствует)
lpq - Выдает информацию о заданиях, находящихся в очереди на печать.
lpr - Посылает задание на печать.
lprm - Посылает множество заданий на печать.
net14 - Утилита, позволяющая программам, использующим 14h прерывание перенаправлять output от MS-Kermit в TCP/IP. (* не опробовано)
rsh - Удаленная оболочка: позволяет выполнять команды shell на удаленной машине. (то же самое что и rexec) (* после использования PC как правило зависает)
setclock - Устанавливает часы PC в соответствии с одним из сетевых серверов.
Некоторые примеры синтаксиса языка Curl.
Язык Curl сочетает в себе возможности форматирования текста, сходные с использованием тагов HTML, и программную функциональность. Правила форматирование текста могут определяться как в самом документе, так и быть загружены или импортированы из внешних файлов.
Команды форматирования текста в языке Curl подразделяются на следующие категории:
форматирования символов и фрагментов текста; форматирование параграфов; включение в текст изображений и объектов и выравнивание текста
Рассмотрим небольшой пример форматирования текста:
{curl 1.6 applet} Заголовок текста {title font-family="Times New Roman", font-size=24pt, color="green", Заглавие текста} Первый параграф {paragraph Первый параграф Первый параграф Первый параграф } Заголовок, с размером по умолчанию. {heading font-size=14pt, color="green", Заголовок 1} {paragraph Второй параграф Второй параграф Второй параграф } Заголовок, с размером 2 {heading level=2, font-size=10pt, color="olive", Заголовок 2} {paragraph Третий параграф Третий параграф Третий параграф }
{curl 1.6 applet} - определитель языка Curl, который указывает на то, что файл содержит апплет, написанный на API 1.6, который может исполняться на Surge plug-in версии 1.1.
- оператор комментария, данный оператор ставится в начале строки; текст который стоит после него, но до конца строки является комментарием.
{title font-family="Font name", font-size=Npt, color="color", text } - оператор описывающий заглавие текста, где font-family - имя шрифта, font-size - размер шрифта, color - цвет текста, text - текст заглавия; определители font-family, font-size и color являются необязательными и если они неописаны, то будут приняты значения текста по умолчанию.
{paragraph font-style="style", text} - оператор описывающий параграф текста, где font-style - стиль шрифта, text - текст заглавия. Может использоваться со следующими операторами text, italic, bold, itemize.
{heading level = N, font-family="Font name", font-size=Npt, color="color", text } - оператор для описания заголовков, где level - предустановленный тип заголовка, font-family - имя шрифта, font-size - размер шрифта, color - цвет текста, text - текст заглавия.
Ниже представлен результат работы вышеприведенного примера:
{italic text} - оператор, устанавливающий на текст атрибут курсива.
{bold text} - оператор, устанавливающий на текст атрибут увеличинной толщины символов.
{text font-style="style" text} - оператор, устанавливающий на текст определенный стиль.
{itemize {item text1} {item text2} {item text3}} - оператор, позволяющий отформатировать текст как список.
{center object} - оператор, выравнивающий объект по центру документа.
{image source={url "image.jpg"}, width=Nin, height=Min} - оператор, включающий в документ файлы с изображениями.
{hrule color="color", height=Npt} - оператор, отображающий в документе горизонтальный разделитель
При форматировании документов можно использовать специальный оператор {set-document-properties margin=Npt, background={url "image.jpg"}, border-width=Mpt, border-color="color"} , где margin - отступ слева, backgroud - фон документа (вместо файла с изображением как параметр может использоваться и цвет фона), border-width - ширина обрамления документа, border-color - цвет обрамления документа.
{curl 1.6 applet} {set-document-properties margin=0.2in, background="beige", border-width=5pt, border-color="olive" } {title font-family="Times New Roman", font-size=24pt, color="green", Документ} {paragraph Определение: от латинского documentum - свидетельство. } {text } {paragraph {text font-size=8pt, {itemize {item Документ - материальный носитель данных с записанной на нем информацией, предназначенной для ее передачи во времени и пространстве.} {item Документы могут содержать тексты, изображения, звуки и т.д. В узком смысле - деловая бумага, юридически подтверждающая какой-либо факт или право на что-то.} } } } {hrule color="olive", height=2pt} {center {italic Статья из \"Советского Энциклопедического Словаря\"}
Результат работы примера:
Для форматирования документа можно также использовать специальные предопределенные стили.
Данная операция производится с помощью оператора {document-style style} . Этот оператор должен предшествовать оператору {set-document-properties ...} . В качестве значений параметра style могут выступать DefaultDocument - содержимое документа отображается на простой странице с белым фоном, этот же стиль применяется по умолчанию, если данный оператор не задан, TocDocument - задает вид страницы с автоматически сгенерированным окном содержания документа, PlainDocument - отображает один объект в отдельную область (Frame) без линеек прокрутки, дополнительные объекты вызывают ошибку, а текст самого вернего уровны игнорируется; данный стиль нужен для отображения графики.
Если вы создаете простой документ, то обычным является перезначение стилей в начале файла, иначе правильным будет создание внешнего файла со стилями и подключения его к документу. Создание стиля осуществляется с помощью оператора {define-text-format ...} .
{define-text-format H1 as heading with level = 1, font-size = 14pt, color = "olive" }
Если нам необходимо подключить внешний файл со стилями, то это можно осуществить с помощью оператора {include ...} до объявления {document-style ...} и {set-document-properties ...} .
Рассмотрим возможности среды Curl по форматированию текста. Эти возможности можно подразделить на следующие категории: работа с символами, работа с параграфами, работа с таблицами и работа с ссылками и изображениями. Основным оператором форматирования для символов является оператор {text ...} , а для параграфов - {paragraph ...} . Приведем небольшой пример использования этих операторов.
{paragraph Я не хочу форматировать весь текст; {text color = "green" только этот текст будет выделен зеленым цветом,} а этот уже не будет. }
Я не хочу форматировать весь текст; только этот текст будет выделен зеленым цветом, а этот уже не будет.
Каждый из этих операторов имеет свой собственный синтаксис, который приведен в данной таблице. В некоторых случаях атрибуту оператора может соответствовать предопределенный оператор-эквивалент.
Например, оператору {bold ...} соответствует {text font-weight = "bold" ...} .
Форматирование текста {text ...} Color Цвет
Font-family Шрифт
Font-size Размер шрифта
Font-style Стиль шрифта
Font-weight Ширина символа
Text-underline? Текст подчеркнут
Text-line-through? Текст зачеркнут
Text-vertical-align Расположение текста
Text-breakable? Одной строкой?
Text-preserve-whitespace? Работа с пробелами
Форматирование параграфа {paragraph ...} Paragraph-first-line-indent Отступ для 1-й строки
Paragraph-justify Выравнивание
Paragraph-line-spacing Межстрочное расстояние
Paragraph-left-indent Левый отступ
Paragraph-right-indent Правый отступ
Paragraph-after-spacing Отступ до параграфа
Paragraph-before-spacing Отступ после параграфа
Форматирование таблиц {table ...} Cell-border-width Ширина рамки ячейки
Cell-margin Отступ до содержимого ячейки
Cell-border-color Цвет рамки ячейки
Cell-border-style Стиль рамки ячейки
Форматирование изображений Border-width Ширина рамки
Border-style Стиль рамки
Border-color Цвет рамки
Width Ширина
Height Высота
Margin Отступ
Background Фон
Halign Выравнивание по горизонтали
Valign Выравнивание по вертикали
К операторам, форматирующим текст, также относят следующие операторы:
{trademark} - символ TM.
{registered-trademark} - символ ®.
{copyright} - символ ©.
{degrees} - символ .
{em-dash} - символ —.
{en-dash} - символ –.
{bullet} - символ .
{br} - оператор принудительного переноса текста на следующую строку.
{page-break} - оператор принудительного переноса текста на следующую страницу.
Предопределенные операторы-эквиваленты стандартному оператору {paragraph ...} :
{left-justify ...} - выравнивание по левому краю.
{right-justify ...} - выравнивание по правому краю.
{center ...} - выравнивание по центру.
{blockquote ...} - одинаковые отступы по правому и левому краям.
{pre ...} - вывод блока тескста шрифтом фиксированной ширины.
{heading ...} - заголовок.
{numbered-heading ...} - заголовок с соответствующим номером.
{itemize ...} - ненумерованное перечисление.
{enumerate ...} - нумерованное перечисление.
{item ...} - элемент перечисления.
{definition ...} - элемент описания.
Рассмотрим специальные операторы форматирования:
{title ...} - установка названия документа в окне броузера.
{link [target = browser-string, ] href = {url destination-string}, link-display} - оператор, описывающий ссылку, где browser-string - окно броузера куда будет загружен ресурс загруженный по ссылке, destination-string - адрес ссылки в формате URL, link-display - текст, к которому будет "привязана" ссылка.
{destination name = name-string, [, display]} - оператор, описывающий имя ресурса, на который можно сослаться с помощью оператора {link ...} , где name-string - название ресурса, display - текст.
{link source = {url image-file-string}, [width = width,] [height = height]} - оператор, описывающий изображение, где image-file-string - адрес изображения в формате URL, height и width - высота и ширина изображения.
{hrule [height = distance-value,] [color = color-value]} - оператор, отображающий горизонтальную линию в документе.
Рассмотрим операторы, работающие с таблицами - {table ...} , {row...} , {cell ...} . Структура вложенности этих операторов эквивалента аналогичным тэгам языка HTML.
{table ... {row ... {cell ...} {cell ...} } {row ... {cell ...} {cell ...} } }
{table ...} - оператор, задающий таблицу.
{row ... [colspan = n]} - оператор, задающий столбец таблицы, где colspan - команда слияния n строк.
{cell ... [rowspan = n]} - оператор, задающий строку таблицы, где rowspan - команда слияния n столбцов.
Приведем пример работы данной группы операторов:
{table background="beige", margin=1cm, border-color="red", border-width=2pt, cell-margin=0.5cm, cell-border-width=4pt, cell-border-color="brown", {row cell-margin=0.5cm, {cell color="magenta", I don't really garden} {cell color="purple", I putt around} } {row color="green", cell-margin=0.5cm, {cell I don't use a table saw} {cell I use my teeth} } }
Необязательное поле Content-Description
Возможность ассоциировать некоторую описательную информацию с данными часто очень желательна. например, может быть полезным описать тело, содержащее графическое изображение, как "a picture of the Space Shuttle Endeavor." Этот текст и может быть помещен в поле заголовка Content-Description. описание := "Content-Description" ":" *текст
Описание должно иметь языковую кодировку US-ASCII, хотя механизм, определенный в RFC-1522 может быть использован для не-US-ASCII значений.
Необязательное поле Content-ID
При создании почтового агента верхнего уровня может быть желательно позволить одному телу иметь ссылку на другое. Для этого поля могут быть помечены с помощью поля заголовка "Content-ID", синтаксически идентичного полю "Message-ID": идентификатор := "Content-ID" ":" идентификатор письма
Как и значения поля Message-ID, значения поля Content-ID должны быть абсолютно уникальными (для всего мира).
Такой идентификатор может быть использован для идентификации тела письма (части письма) в нескольких контекстах, в часности, для кэширования данных, указываемых с помощью механизма message/external-body. Хотя поле Content-ID является необязательным в общем случае, его использование необходимо в реализациях, генерирующих данные, имеющие дополнительный тип "message/external-body" (поле Content-type). Каждое тело такого типа должно обязательно иметь в своем заголовке поле Content-ID для обеспечения ссылки на такие данные.
Значение поля Content-ID имеет специальную семантику в случае типа multipart/alternative. (См. соотв. пункт).
Новая схема
Хотя практически в любом обзоре XML (не исключая и статью «XML: время пришло») говорится, что грамматика и синтаксис правильно составленного документа XML определяются DTD, скорее всего, дни DTD уже сочтены. На смену DTD должен прийти новый стандарт — XML Schema.
DTD вполне достаточно для базового определения документа, но они имеют несколько недостатков. Во-первых, они даются не на XML. Учитывая высокую степень адаптируемости и расширяемость XML, наличие еще одного формата для определения документов представляется излишним.
Во-вторых, элементы DTD внутри документа XML требуют полного определения всего, что находится внутри этих элементов. Другими словами, никакие подэлементы «на перспективу» не допускаются — если таковые будут присутствовать в документе, то, по определению, документ не будет являться правильно составленным. Между тем определения XML Schema используют модель открытого информационного наполнения, в которой неопределенные элементы вполне допустимы.
В-третьих, DTD ограничиваются только грамматикой и синтаксисом (т. е. отношением одного элемента к другому), тогда как XML Schema может также задавать непосредственные ограничения на тип данных, которые элемент может содержать. Это значительно упрощает реализацию передачи данных приложения по сравнению с более традиционным текстовым документом. Например, точно так же, как это делают разработчики в языках программирования, вы можете явным образом указать, что данная область хранения может содержать только целочисленные данные. Наконец, разработчикам, работающим в средах Wintel, будет весьма удобно то обстоятельство, что XML Schema легко отображается на Microsoft Document Object Model. Таким образом, работающая с документами XML программа может запросить у соответствующей схемы имеющееся определение для элемента документа по своему выбору. Код выглядит следующим образом:
var bookNode = doc.documentElement
Однако как же будет выглядеть сам содержащий схему документ изнутри? Во-первых, он будет содержать теги XML, объявляющие, что это схема, наподобие:
... содержание схемы
Каждый пункт внутри схемы объявляется затем индивидуально, причем особенности каждого элемента расшифровываются с помощью вложенных тегов, например:
определяет элемент как могущий содержать только текстовые данные.
Подобные схемы могут оказаться весьма трудны для чтения, но они легко поддаются разбору с помощью инструментов XML. Другими словами, вам не потребуется специальный редактор для работы с документом XML Schema, как в случае DTD.
Отмечу также, что в случае правил на базе XML для форматов коммерческих данных вы можете использовать для отображения одной схемы на другую встроенные функциональные возможности преобразования XML — расширяемый язык таблиц стилей (Extensible Stylesheet Language, XSL).
в тех случаях, когда организации
Это утверждение справедливо, например, в тех случаях, когда организации получают бизнес-информацию из внешних источников, внутренних офисов, программного обеспечения коллективного пользования и с Web-серверов.
Чтобы помочь пользователям применить этот широкий спектр бизнес данных (как для нерегламентируемого доступа, так и для автономной доставки), используется вторая технология — корпоративные информационные порталы.
При публикации корпоративной информации на портале используются метаданные о местоположении тех или иных сведений, а также о методах их извлечения. Когда сотрудник делает необходимый запрос, портал считывает соответствующие метаданные и, используя средства доступа и доставки, выбирает нужную информацию.
Эффективная работа достигается только при правильном совместном использовании информации, в противном случае сотрудники дублируют деятельность друг друга и не добиваются взаимопонимания. Таким образом, портал становится основой, гарантирующей свободное разделение данных.
Новые Технологии распространения информации
В последние годы основным средством распространения информации становится Web, поскольку при его использовании:
улучшается доступ к бизнес-информации и увеличивается число пользователей, которые могут с ней работать;
предоставляется удобный интерфейс для поиска и навигации;
становится возможным доступ к различным типам данных, расположенных в разных источниках (как внутри, так и вне организации);
за счет технологии «тонкого клиента» снижаются требования к аппаратному и программному обеспечению и сокращаются расходы на поддержку клиентского места;
обеспечивается возможность использования независимого от платформы программного обеспечения(Java) и системы представления данных (XML);
информация для сотрудников, партнеров и заказчиков может распространяться через Intranet/Extranet и Internet. За счет этого расширяется пространство доступа к информации и открываются новые пути ведения бизнеса.
В результате информация, необходимая для принятия решений, может передаваться пользователям и приложениям с использованием двух основных технологий:
Web-ориентированных средств Business Intelligence (инструментов для создания отчетов, выполнения OLAP-анализа и data mining), а также пакетов аналитических приложений для Web;
корпоративных Информационных порталов и серверов рассылки.
Важно отметить, что эти технологии не взаимозаменяемы: для максимального эффекта их надо использовать совместно.
Web-ориентированные BI-инструменты и пакеты аналитических приложений распространяют информацию и результаты аналитических операций посредством стандартных графических и Web-интерфейсов. Многие из этих продуктов также поддерживают планируемую и управляемую событиями доставку информации Web-серверам и почтовым системам, тем самым, используя все возможности основных сетевых средств.
По мере роста объемов бизнес-информации, обрабатываемой в системе принятия решений, растет вероятность того, что данные будут распространяться внутри целой серии информационных хранилищ, расположенных на разных серверах.
Общая информация о работе с NCSA Telnet
Если запуск Telnet осуществляется так:
telnet host1 host2 ..
то пользователю будет предложен login последовательно на каждую из перечисленных машин. Переход к каждой следующей сессии происходит по Alt+N. Открыть новую сессию, с новой машиной можно по Alt+A. После чего появится login на новую сессию. Время соединения с новой машиной может варьироваться от мгновения до нескольких минут, в зависимости от удаленной машины.
Обзор стандарта UN/EDIFACT
При разработке стандартов электронного документооборота была проведена работа по исследованию использования всех данных "бумажных" документов, используемых во внешнеэкономической деятельности. Как выяснилось, большинство документов содержат повторяющиеся данные, и даже целые группы данных.
Например, название и адрес фирмы отправителя встречается как в счете-фактуре, транспортно-сопроводительных документах - CMR, так и в таможенной декларации.
Было предложено выделить наиболее повторяющиеся группы данных, и в них выделить соответствующие поля данных. В последствии оказалось, что данные так часто повторяются, что для их заполнения было разработано более 200 специальных кодировочных таблиц - называемых справочники данных.
Часть справочников (такие как трехзначные коды стран мира, коды валют) использовались до появления стандартов UN/EDIFACT. Эти справочники были пересмотрены и скорректированы с точки зрения использования их в новых стандартах.
В основу стандарта UN/EDIFACT положены следующие принципиальные идеи:
Обмен осуществляется сообщениями; Стандартизация по типу используемого документа на уровне сообщений; Сообщение имеет иерархическую структуру и состоит из сегментов; Стандартизация данных на уровне сегментов и элементов данных; Сегменты могут групироваться по некоторому признаку; Незаполненные (пустые) сегменты могут опускаться; Типовые поля записываются в виде кода; Состав и наполнение справочников стандартизуется на трех уровнях - международном, национальном и корпаротивном; Независимость стандартов от языка, используемого для общения.
Группа сегментов кроме типовых сегментов данных может содержать другие группы сегментов.
Сегменты в группе сообщений могут повторяться некоторое количество раз. Также незаполненные (пустые) сегменты могут опускаться.
Стандартом предусмотрено около 200 различных типов сегментов, из которых составляется сообщение.
На рис. 1 Представлен фрагмент структуры сообщения, на котором видно, как объеденены в группу SG. 8 сегменты TDT-LOC и MEA-EQN которые в свою очередь объединены в группу SG.9 В группе, порядок следования сегментов строго упорядочен, но они могут повторяться, например:
TDT- LOC MEA-EQN MEA-EQN TDT- LOC MEA-EQN
Первый раз, в группе SG.9 сегменты MEA- EQN повторяются два раза, второй раз - один. В группе SG.8 - сегменты TDT- LOC повторяются - два раза.
Сегменты данных состоят из элементов данных, которые могут быть простыми (аналогом является поле данных) и составными (обычно 2-3 поля данных).
На конец 1999 года разработано более 170 стандартных сообщений. Стандартом предусмотрено, что каждое сообщение имеет уникальный 6-значный код из заглавных букв, а каждый сегмент данных имеет 3-значныный код из заглавных букв.
По правилам UN/EDIFACT не предусмотрено использование символов перевода строки и возврата каретки, но для наглядности на каждой строчке расположен отдельный сегмент. Ниже, для примера, показано разобранное на сегменты сообщение ORDERS в стандарте UN/EDIFACT.
UNH+000002+ORDERS:D:96A:UN:EAN008' Заголовок Сообщения
BGM+220+B00002+9' Номер заказа
DTM+137:19940202:102' дата отправки сообщения
NAD+BY+++Stadt- und Universitaetsbibliothek Имя и адрес покупателя
:Frankfurt+Bockenheimer Landstr. 134-13 8+Frankfurt++60325' RFF+API:DE1141110388' Идентификатор покупателя
NAD+SU+++DREIER' Наименование поставщика
CUX+2:DEM:9' Валюта оплаты
LIN+1' Позиция заказа 1
PIA+5+3772815359:IB' Идентификатор ISBN заказа
IMD+F+050+:::Die "Jahrbuecher fuer wissensc
haftl:iche Kritik"'
IMD+F+060+:::Hegels Berliner Gegenakademie'
IMD+F+065+:::Hrsg. von Christoph Jamme'
IMD+F+110+:::Stuttgart-Bad Cannstadt'
IMD+F+120+:::Frommann-Holzboog'
IMD+F+170+:::1994'
IMD+F+190+:::Spekulation und Erfahrung'
IMD+F+191+:::Abt. 2'
IMD+F+192+:::Untersuchungen'
IMD+F+194+:::Bd. 27'
IMD+F+220+:::Gewebe' Подробности описания товара
QTY+21:1' кол-во копий заказа
PRI+AAE:295:CA' Цена заказа в Нем. марках
UNS+S' Разделительный сегмент
CNT+2:1' Общее кол-во позиций - 1
UNT+25+000002' Общее кол-во сегментов = 25
Сегменты, составляющие сообщение, начинаются с трехбуквенного имени, например UNA, UNH, BGM, DTM и т.д. Оканчивается сегмент символом окончания сегмента - в данном примере апострофом.
Ниже приведены названия некоторых сегментов:
BGM BEGINNING OF MESSAGE НАЧАЛО СООБЩЕНИЯ
CUX CURRENCIES ВАЛЮТА
DTM DATE/TIME/PERIOD ДАТА/ВРЕМЯ/ПЕРИОД
IDM ITEM DESCRIPTION ОПИСАНИЕ ПУНКТА
Каждый сегмент состоит из элементов данных. В отличие от имени сегмента, имя элементов данных не указывается в сообщении. Элементы данных разделены разделителями которым является символ "плюс". Так, например сегмент NAD+BY+++Stadtund Universitaets bibliothek:Frankfurt+Bockenheimer.Landstr.134 -138+Frankfurt++ 60325'
Состоит из следующих элементов данных:
Первый элемент BY
Четвертый элемент Stadt-und Universitaetsbibliothek:Frankfurt
Пятый элемент Bockenheimer.Landstr.134-138
Шестой элемент Frankfurt
Восьмой элемент 60325
Каждый из элементов данных занимает свое определенное место в сегменте. Если какой-либо из элементов данных не требуется, то для его пропуска повторяют разделитель элементов данных (см. в примере - между первым и четвертым элементом расположено три разделителя). Назначение того или иного элемента данных определяется справочником сегментов EDSD, который входит в набор стандартов UN/EDIFACT.
Элементы данных могут быть простыми и составными, состоящими из компонентов. Для составных элементов данных предусмотрен еще один разделитель - в данном случае "двоеточие". Четвертый элементы данных в вышеприведенном примере, являются составными, части которого разделены символом ":" Последовательность элементов данных в сегменте регламентируется справочником элементов данных и строго определена.
Обзор технологий безопасности.
В сравнении с технологиями безопасности, применяемых в Java и HTML, язык Curl является более гибким, простым и защищенным:
простота в использовании - конечному пользователю не надо настраивать политики безопасности; большая гибкость - непривилегированные апплеты, написанные на Curl, являются более функциональными и безопасными, чем апплеты, написанные на Java; более защищенный, чем Java - привилегированные апплеты должны использоваться как можно реже; более защищенный, чем HTML - Curl предлагает безопасность для решения проблем идентификации пользователя.
Одноступенчатое формирование XML-документа
Развитие новых тенденций объединения технологий XML и EDI обеспечивает динамичный процесс формирования электронных документов и взаимодействия между информационными системами. Тенденция объединения XML и EDI является наиболее перспективным направлениям в использование электронных документов.
Рис. 1
На рис.1 представлена схема вариантов обмена Электронными документами для разных (мелких и крупных) компаний. Крупные компании продолжают использовать уже имеющие EDI-системы через VAN сеть (сеть с добавленной стоимостью, т.е. предоставление за плату добавочных услуг). Провайдеры предоставляют такую услугу, как подготовка и обмен EDI-сообщениями по средствам корпоративных сетей. Более мелкие компании, используя технологию XML/EDI осуществляют обмен через Internet.
Один из самых простых вариантов обмена используя XML/EDI технологию - это подготовка XML-докуамента на стороне клиента и отправка на XML-сервер компании, где документ проверяется и преобразуется в стандартное EDI - сообщение и будет передан по Intranet на EDI-сервер компании.
Рис. 2
На рис.2 представлена схема формирования XML документа на клиентской стороне. В ходе начала обмена, клиент принимает от XML сервера шаблон (формально назовем XML шаблон). Текст простого шаблона на примере XML документа "инвойс" может иметь следующий вид:
3
Элемент включает атрибут id , указывающий номер транзакции имеющий значение "768765324" . Элемент описывает количество "пунктов" инвойса, т.е. количество наименований перевозимого товара. Далее, используя язык описания стилей XSL, генерируется HTML форма, которая заполняется данными об отправителе и получателе груза, а также о самом грузе.
Внешнее представление сгенерированной формы принципиального значения не имеет и может быть разработано получателем документа самостоятельно. Также, возможно использование заранее подготовленной HTML формы с параметром id тага Transaction.
Рис. 3
Упрощенный вид генерируемой HTML формы представлен на рис. 3. После инициации события OnClick кнопки "Передача" (SUBMIT) происходит генерация следующего XML документа:
12345 20000105
OY Valio Helsinki Box 789 FI АО Северная столица Санкт-Петербург Невский 176 194376 RU
-
Сыр 200 AAI 300 Price> FIM -
Масло 150 AAU 500 Price> FIM -
Варенье 100 AAU 180 Price> FIM
Данный документ принимается XML сервером, который генерирует следующее EDI - сообщение:
UNH+768765324+INVOIC:D:96A:UN:EAN002'
BGM+380+12345+9+NA'
DTM+3:20000105:102'
NAD+SE+++OY Valio++Helsinki++Box 789+Fi'
NAD+By+++АО Северная столица ++Saint-Peterburg+Невский 176 + +RU'
Заголовок Сообщения
Номер транзакции 768765324
Номер инвойса 12345
Дата выдачи 5.01.2000
Поставщик Valio
Адр: Helsinki Box 789 FI
Получатель "АО Северная столица" Адр: С-Петербург Пр. Невский 176 Россия
LIN+1'
IMD+F+011+:::Сыр'
MEA+AAI'
QTY+92:200'
PRI+INV:300'
CUX+2:USD'
Первая позиция
Наим. Сыр
Ед.изм- кг
Кол-во 200 кг
Цена 300 за кг
Валюта - USD
LIN+2'
IMD+F+011+:::Масло'
MEA+AAU'
QTY+92:150'
PRI+INV:500'
CUX+2:USD'
Вторая позиция
Наим. Масло
Ед.изм- упак
Кол-во 150 упак
Цена за упак - 500
Валюта - USD
LIN+3'
IMD+F+011+:::Варенье'
MEA+AAU'
QTY+92:100'
PRI+INV:180'
CUX+2:USD'
Третья позиция
Наим. Варенье
Ед.изм- упак
Кол-во 100 упак
Цена 180 за упак
Валюта - USD
UNS+S'
CNT+4:3'
UNT+26+12345'
Контрольная секция
Общее кол-во позиций- 3
Кол-во сегментов - 26 и Номер сообщения - 12345
Особой задачей для семантической проверки и разбора XML документа и формирования EDIFACT сообщения является разработка Таблицы определения данных - DTD. При разработке DTD, учитывая иерархическую структуру EDIFACT сообщения, разрабатывается объектная модель документа - DOM. На рис 3 представлена иерархическая схема сообщения INVOICE.
В рассматриваемом EDIFACT сообщении INVOICE можно выделить сегменты и сопоставить их с объектами ELEMENT объектной модели. В левой части таблицы представлены DOM элементы, а в правой соответствующие им сегменты или части сегментов. Значок # указывает, что в данном месте должно находится значение из соответствующего элемента DOM.
Корневой элемент
Name= "Transaction"
Attr "id = #"
Сегмент UNH
UNH +#+INVOIC:D:96A:UN:EAN002'
Элементы:
Name ="InvoiceNum"
Value = #
Сегмент BGM
BGM+380+#+9+NA'
Name ="Consignor " Сегмент NAD
NAD+SE+++#01++#02'
Дочерние элементы "Consignor "
Name = "ConsignorName"
Value = #01
Name ="Addsress"
Value = #02
Name ="Consignee "
Дочерние элементы "Consignee "
Name ="ConsigneeName "
Value = #01
Name ="Addsress"
Value = #02 NAD+BY+++#01++#02'
Name ="Addsress"
Дочерние элементы "Addsress"
Name ="City "
Value = #01
Name ="Street"
Value = #02
Name ="Zip"
Value= #03
Name ="Country"
Value= #04 Часть Сегмента NAD
#01+#02+#03+#04
Name ="Goods"
Дочерние элементы "Goods"
Name ="Item "
Идентификатор группы сегментов:
LIN-IMD-QTY-MEA-PTI-CUX
Name ="Item"
Attr "id = #"
Дочерние элементы "Item"
Name ="Name"
Name ="Qulity"
Name ="TypeEQU"
Name ="Price "
Name ="TypeCur"
Сегмент LIN
LIN+#'
Name ="Name" Value = # Сегмент IMD IMD+F+011+:::#'
Name ="Qulity" Value = # Сегмент QTY QTY+92:#'
Name ="TypeEQU " Value= # Сегмент MEA MEA+#'
Name ="Price" Value= # Сегмент PRI PRI+INV:#'
Name ="TypeCur" Value= # Сегмент CUX CUX+2:#'
<
Интерпретация содержания сегмента осуществляется следующим образом: значение тага из текста нашего XML документа ( 12345 ) будет преобразовано в BGM+380+12345+9+NA' , что соответствует записи в левой части таблицы объкта Element ( Name ="InvoiceNum" Value = # ) и BGM+380+#+9+NA' в правой. Если какой либо сегмент содержит информацию из нескольких родственных (Sublin) тагов, то указывается номер вхождения:
Пример : Сегмент NAD содержит информацию из элемента "ConsigneeName" - вхождение #01 и элемента "Addsress" - вхождение #02:
Соответственно информация из элемента "Addsress" извлекается из дочерних элементов ( "City ", "Street" и "Country" ), которые имеют свою часть вхождения в сегмент NAD:
При генерации EDI-сообщения, необходимая информация извлекается из значений атрибутов, которые описываются как константы элементов DTD. Каждый элемент, информация из которого имеет вхождение в сегмент сообщения, имеет атрибуты:
EDI-Prefics - информация (статическая часть текста сегмента) предшествующая вхождению переменной; EDI-Suffics - статическая часть текста сегмента после вхождения переменной.
Так для тага атрибутом является:
EDI-Prefics - "BGM+380+"
EDI-Suffics - "+9+NA' ".
Для тегов, которые используют информацию при вводе из поля данных, используются атрибуты Title и Size.
Ниже представлена часть таблицы определения данных, которая иллюстрирует основы построения DTD для XML/EDI.
]>
EDI- сообщение специальным модулем генерируется на серверной стороне извлекая динамическую информацию из XML документа и статическую из DTD. Далее сгенерированное сообщение передается в EDI-систему, где и происходит обработка сообщения.
Окончание работы
Для нормального завершения работы сессии нужно выполнить logout на удаленной машине. (Обычно Ctrl+D) Чтобы закончить работу с NCSA Telnet следует выполнить logout для всех сессий.
Если ломается удаленная машина и/или подвисает (не отвечает) сессия, то по Alt+X - будет произведена попытка закрыть сессию с сохранением остальных сессий.
Ctrl+Shift+F3 - принудительное прерывание работы всей программы NCSA Telnet. Рекомендуется использовать только в самом крайнем случае, когда все остальные средства исчерпаны, т.к. ведет к закрытию всех сессий с возможной потерей данных. (* Это средство, на самом деле, тоже не всегда помогает, чаще спасает только Ctrl+Alt+Del)
Ctrl+C или Ctrl+Break - не имеют эффекта при попытке спасти сессию.
Описание тегов (переведено из документации Motorola SDK) :
Деки.
Дека определяется элементом wml
Hello World!
Органы управления (controls)
ActiveX - это ответ Microsoft на вопрос, на который ответов уже предложено едва ли не больше, чем хотелось бы: как преодолеть ограничения языка HTML и сделать Web-страницу не менее разнообразно оформленной и интерактивной, чем какое-нибудь мультимедийное приложение? Решение, предложенное корпорацией Netscape, известно довольно давно: это, с одной стороны, апплеты (небольшие специализированные программы на языке Java), а с другой - подключаемые модули (plug-ins), которые, будучи почти самостоятельными приложениями, способны реализовать любую функцию интерфейса или обработки данных.
Технология ActiveX вместо всего этого предлагает органы управления - по многим параметрам, нечто среднее между апплетами и подключаемыми модулями. Орган управления - это небольшая программа, которой броузер выделяет на странице определенный участок прямоугольной формы. В пределах своего участка орган управления полностью отвечает за перерисовку экрана и взаимодействие с пользователем. Например, "орган управления" в строгом смысле этого слова может реализовать что-нибудь вроде движка прокрутки или выпадающего меню, которых сам HTML создать не может; другие модули могут принимать от пользователя, обрабатывать и выводить данные, строя динамически меняющиеся диаграммы или даже ведя небольшую электронную таблицу прямо в окне броузера; наконец, органы управления еще одного типа решают чисто оформительские задачи - скажем, покрывают выделенный им участок узором, плавным переходом цветов, движущимся текстом или изображением.
От модулей Netscape Navigator органы управления ActiveX отличаются более узкой и дробной специализацией, меньшими размерами передаваемых по сети файлов, а главное - полностью автоматизированной установкой. Встретив в HTML ссылку на некий орган управления, броузер сначала проверяет, нет ли его уже на компьютере пользователя (то есть не использовался ли он раньше). Если орган управления найден, броузер запускает его, передает ему нужные для работы данные и, таким образом, обходится без лишнего выхода в сеть.
Если же этого компонента на компьютере еще нет, броузер обращается к серверу, адрес которого указан в теле HTML-документа, и, перекачав с него файл, устанавливает и регистрирует новый орган управления в Windows. В принципе, после этого органом управления может пользоваться не только броузер, но и любое приложение, способное работать с так называемыми "нестандартными органами управления OLE" ("OLE Custom Controls", OCX).
Однако самые важные достоинства и недостатки органов управления ActiveX нагляднее всего показывает сравнение их с Java-апплетами. Первый бросающийся в глаза недостаток всей системы ActiveX - ее жесткая привязка к конкретной операционной системе (Windows 95/NT). Поскольку значительную часть поддержки ActiveX и взаимодействия компонентов OLE обеспечивает сама операционная система, то перенести все это хозяйство, к примеру, на UNIX будет очень и очень непросто.
Второй, очень серьезный недостаток - безопасность. Файл с расширением .ocx, в котором содержится компонент системы ActiveX, получает управление практически так же, как и любой другой исполняемый файл в Windows, и обладает теми же правами - например, правом бесконтрольной записи на диск (под Windows NT эти права могут быть ограничены уровнем привилегий пользователя, запустившего данный компонент). Очевидно, что здесь открываются широкие перспективы для деятельности авторов вирусов и прочих зловредных программ, для которых ActiveX может стать весьма комфортной питательной средой.
Как известно, разработчики языка Java решили эту проблему, заключив апплеты в непроницаемую капсулу виртуальной машины, из которой они не смогут нанести никакого вреда компьютеру. Фирма Microsoft пошла по другому пути и разработала систему электронных подписей, которыми разработчики должны удостоверять подлинность всех созданных ими компонентов ActiveX. Предполагается, что каждый пользователь составит для себя список тех компаний, которым он согласен доверять с закрытыми глазами, после чего броузер будет устанавливать на компьютер и запускать органы управления этих фирм без лишних вопросов.
Если же броузеру встретится ссылка на файл, подписанный неизвестно кем или не подписанный вообще, то решение о том, брать ли на себя риск связываться с этим компонентом, придется принимать пользователю (рис. 1).
Рисунок 1. Этот орган управления не подписан. Что одержит верх - любопытство или осторожность?
Подобную систему безопасности, конечно же, есть за что покритиковать. Прежде всего, невозможность подделать электронную подпись - это, если можно так выразиться, невозможность гораздо меньшего порядка, чем неспособность Java-апплета выпрыгнуть из своей виртуальной машины. Можно не сомневаться, что множество предприимчивых компьютерных взломщиков уже засели за решение этой задачи. Однако, на мой взгляд, гораздо хуже то, что эта система лишает возможности попробовать свои силы в программировании собственных органов управления множество мелких фирм и программистов-любителей - никому не известные, они смогут похвастаться своими безродными творениями разве что перед друзьями.
Справедливость, однако, требует признать, что система ActiveX и реализованный в ней механизм безопасности кое в чем заметно удобнее использования языка Java. Во-первых, отсутствие защитной оболочки виртуальной машины позволяет расширить функциональность компонентов ActiveX - им доступен такой прямой и эффективный контроль над компьютером, о котором Java-апплеты не могут и мечтать. Но главный плюс технологии ActiveX, благодаря которому она так резко стартовала и так быстро завоевала признание, - это то, что программистам, желающим заняться разработкой компонентов ActiveX, почти не приходится переучиваться. OCX-модули впервые появились вместе с версией 4.0 языка Visual Basic и очень многое унаследовали от еще более старого стандарта VBX ("Visual Basic Controls"). Именно органы управления VBX в свое время и стимулировали развитие целой индустрии программных модулей, которые любой программист может купить и использовать в своих разработках. Переделать же OCX-модуль в компонент ActiveX даже проще, чем старый VBX в OCX. Более того - в броузере Internet Explorer технология ActiveX является не одним из усовершенствований, а буквально фундаментом всей программы. При запуске броузера управление получает миниатюрный контейнер, сразу же вызывающий специальный OCX-модуль, - в котором, собственно, и заключены все функции броузера. Любой программист может, таким образом, без труда встроить в свою программу полнофункциональный броузер WWW, написав всего лишь небольшую функцию для вызова этого модуля и обмена данными с ним. Отдельные функциональные блоки броузера - виртуальная машина Java, интерпретатор HTML и даже сам блок взаимодействия с органами управления ActiveX, - все они реализованы в виде OCX-модулей. Как заметил один программист, "Похоже, ребята в Microsoft сейчас только тем и занимаются, что берут все свои программы по очереди и распиливают их на OLE-компоненты".
Основной подтип 'Application/Octet-Stream'
Используется для обозначения того, что тело содержит бинарные данные. Набор возможных параметров включает следующие (но не ограничивается ими):
TYPE -- обобщенный тип или категория двоичных данных, эта информация больше предназначена для получателя, чем для автоматической обработки.
PADDING -- число заполняющих битов, добавленных к битовому потоку, содержащему данные, для формирования байтно-ориентированных данных. Полезно при заключении в тело битового потока, когда общее число битов не кратно восьми, то есть, размеру байта.
Дополнительный параметр, "conversions", определенный в [RFC-1341], был исключен в последствии.
В RFC 1341 также определен параметр "NAME", указывающего имя файла, которое должно быть использовано при сохранении данных на диск. Но он опять же был отменен в ожидании введения отдельного поля заголовка Content-Disposition, которое будет определено в ближайшем будущем.
Рекомендуемое действие для почтовой программы, получившей почту типа application/octet-stream, - просто предложить записать данные в файл без какого-либо преобразования, или. возможно, произвести его в соответствии с указанием пользователя.
Для уменьшения опасности передачи вирусных и других намеренно разрушающих систему программ по почте, строго рекомендуется, чтобы почтовая программа получателя не производила запуск программы, заданной в параметре поля "Content-Type" (например, в параметре "interpreter="), использующей в качестве входных данных тело письма.
Основной подтип 'message/rfc822'
Этот подтип указывает, что тело письма содержит вложенное письмо в стандарте RFC 822, однако, в отличие от заголовка RFC 822 верхнего уровня, для каждой части, являющейся письмом RFC 822, не требуется наличия полей "From", "Subject" и, по крайней мере, одного поля "To".
Не смотря на использование числа "822", тело, имеющее подтип 'message/rfc822', может включать дополнительную информацию в соответствии со стандартом MIME. Другими словами, письмо 'message/rfc822' может быть MIME-письмом.
Основной подтип "multipart/mixed"
Это основной подтип для типа 'multipart', он предназначен для случая, когда части письма взаимонезависимы. Любые новые подтипы, неизвестные почтовой программе, должны быть истолкованы аналогично подтипу 'mixed'.
Основы XML и объектная модель представления данных
Бурное развитие Интернет технологий вовлекло в международную паутину миллионы пользователей. Требования к электронному обмену возросли, и уже существующий протокол HTML многие группы пользователей перестал удовлетворять.
В начале февраля 1998 г международная организация W3C утвердила спецификацию "Extensible Markup Language(XML) 1.0". Уже сегодня появляются новые языки, созданные на основе XML. Возникают многочисленные Web-сервера, использующие и технологию XML для организации хранящейся на них информации.
Современные приложения требуют не только более гибкий протокол представления данных, но и механизм, позволяющий определить структуру документа и описывать содержащие в нем элементы.
Язык XML предназначен для создания новых языков разметки. С его помощью можно описать целый класс объектов данных, называемых XML - документами, ориентированными на конкретную предметную область. XML позволяет определить допустимый набор тэгов, их атрибуты и внутреннюю структуру документа. Тэги (подобно тэгам в HTML) представляют специальные инструкции, предназначенные для формирования в документах определенной структуры и четких отношений между различными элементами этой структуры.
Можно выделить следующий круг задач, связанных с созданием и обработкой структурированной информации, для решения которых может использоваться XML:
Разработка сложных информационных систем, с большим количеством приложений, связанных потоками информации самой различной структуры. XML - документы выполняют роль универсального формата для обмена информацией между отдельными компонентами большой программы. XML является базовым стандартом для нового языка описания ресурсов, RDF, позволяющего упростить многие проблемы в Web, связанные с поиском нужной информации, обеспечением контроля за содержимым сетевых ресурсов, создания электронных библиотек и т.д. XML может использоваться в обычных приложениях для хранения и обработки структурированных данных в едином формате. XML позволяет описывать данные произвольного типа и используется для представления специализированной информации. XML может служить мощным дополнением к HTML для распространения в Web "нестандартной" структуированой информации XML-документы могут использоваться в качестве промежуточного формата данных в трехзвенных системах при поиске информации в удаленных базах данных.
Сегодня на рассмотрение W3C предложена спецификация нового языка запросов к базам данных XQL. Информация, содержащаяся в XML-документах, может изменяться, передаваться на машину клиента и обновляться по частям. Разрабатываемые спецификации XLink и Xpointer позволятют ссылаться на отдельные элементы документа, c учетом их вложенности и значений атрибутов. Использование стилевых таблиц (XSL) позволяет обеспечить независимое от конкретного устройства вывода отображение XML- документов и фильтрацию данных.
Тэги языка кодируются и выделяются относительно основного содержимого документа и служат в качестве инструкций для программы, производящей действия над содержимым документа на стороне клиента.
Исторически сложилось таким образом, что в системах для обозначения этих команд использовались символы "<" и ">", внутри которых помещались названия инструкций и их параметры. Сейчас такой способ обозначения тэгов является стандартным.
Например, для создания элемента Ivanov в имене заказчика используется тэг . В программе это выглядит следующим образом: Ivanov
Определения тэгов может легко расширяться. Так для указания более полных реквизитов заказчика можно определить тег , в который включено не только имя, телефон заказчика, но и адрес компании.
Ivanov 312-12-13 Bussines Trade Consulti
Можно создать массив заказчиков, определив тег :
Ivanov 312-12-13 Bussines Trade Consulti Petrov 315-15-16 Trade Forest Company ......
Из приведенного примера видно, что XML - документы подлежат четкой структуризации и имеют четкую иерархическую структуру следования элементов. Элементы имеют своих родителей - корневые элементы и наследников - дочерние элементы.
Документ XML состоит из элементов. Элемент - это структурная единица XML- документа. Заключая данные об имени заказчика в тэги , XML-процессор определит как элемент. Содержимым элемента CustumerName является значение. В нашем примере имеется два значения (Ivanov и Petrov) элемента CustumerName.
Контроль за правильностью использования порядка использования элементов осуществляется при помощи специального набора правил, называемых DTD (Document Type Definition)- описаниями, которые используются программой клиента при анализе документа.
Производя в последствии поиск в XML документе, программа клиента будет опираться на информацию, заложенную в его структуру - используя элементы документа, определенные в DTD.
В общем случае XML- документы должны удовлетворять следующим синктатическим правилам:
В заголовке документа помещается объявление XML, в котором указывается язык разметки документа, номер его версии и дополнительная информация; Каждый открывающий тэг, определяющий некоторую область данных в документе обязательно должен иметь парный закрывающий тэг; XML учитывает регистр символов; Все значения атрибутов, используемых в определении тэгов, должны быть заключены в кавычки; Вложенность тэгов в XML строго контролируется, поэтому необходимо следить за порядком следования открывающих и закрывающих тэгов; Вся информация, располагающаяся между начальным и конечными тэгами, рассматривается в XML как данные и поэтому учитываются все символы форматирования ( пробелы, переводы строк, табуляции не игнорируются)
В случае, если элемент не содержит данных, т.е. является пустым, то начальный и конечные тэги такого элемента можно объединить в один. При этом не обязательно ставить косую черту перед закрывающей угловой скобкой (например, в вышеприведеном примере отсутствие факса в компании пару тэгов можно заменить на ;)
При необходимости, каждому элементу можно задать параметры, уточняющие его характеристики. При этом используются атрибуты эдлемента. Атрибут - это пара "название" = "значение", которую необходимо задавать при определении элемента в начальном тэге. Пример:
123456 двадцати футофый контейнер 654321 тридцати футофый контейнер
Просмотр XML документов осуществляется специальной программой анализатором. На сегодняшний день разработано около десятка подобных анализаторов. В своем новом броузере Internet Explorer 5 фирма Microsoft уже предусмотрела анализ XML документов.
Анализ документа в Internet Explorer 5 осуществляется тремя вариантами: просмотр аналогично HTML документу, форматирование документа с использованием специальных стилевых таблиц - XSL и анализ с помощью сценариев, написанных на Java Script ил VBScript.
Поиск нужного элемента или поддерева осуществляется при помощи XQL запроса. XQL является частью XML и переволится как язык запросов для XML (XML Query Language). Идет дисскусия об утверждении языка запросов в качестве общепринятого стандарта, который может заменить SQL.
Синтаксис языка запросов очень гибок и позволяет осуществлять поиск элемента как по названию, значению атрибутов, содержанию, так и учитывать вложенность и положение в дереве элементов. При помощи запросов мы можем выделять из общего дерева необходимые нам элементы и применять к ним необходимые инструкции. Запрос возможно применять как к самому XML документу, так и к ссылкам URL.
Язык запросов напоминает обычный способ определения пути к ресурсу- список узлов дерева, разделенных символом "/". Для указания на текущий элемент используется символ "." , на родительский - "..", для выделения всех дочерних элементов - символ "*", для выделения элемента, расположенного просто "ниже" по дереву(не важно на каком уровне вложенности) - "//".
Условие на значение в запросе должно заключаться в символы "[" и "]". Для выбора значения атрибута в условии указывается символ @.
Примеры простых XQL шаблонов:
"/Customer " корневой элемент
"Customers/" возвращает дочерние элементы для элемента Customers
"Customers //" список всех элементов, вложенных в Customers
"container[@Type]" список элементов container, в котором определен атрибут Type
"container[@Type =20f]" поиск всех двадцатифутовых контейнеров, т.е. элементов container, в котором значение атрибута Type равно "20f"
"Customers[address]" список элементов Customers, которые содержат хотя бы один элемент address, выражение в квадратных скобках может быть составным.
Как мы видим, XML документ в отличие от EDIFACT сообщения позволяет более наглядно представить объектную модель данных. Использование языка описания XML запросов - XQL позволяет адекватно формализовать любой из существующих "бизнес" запросов (оформленных в виде стандартных документов) для информационных систем.
Разбор XML документов в отличие от EDI-систем возможен стандартными анализаторами, что значительно удешевляет разработку новых информационных систем. Использование встроенных транспортных протоколов делает эти системы полностью совместимыми с существующими программными средствами и WEB технологиями.
Оставляйте выбор за пользователем
Если на сйте в обязательном порядке предусмотрено наличие "крупногабаритной" графики или аудио-видеофайлов, разместите каждый элемент в отдельной странице. Например, на основной странице ставьте ссылку "чтобы посмотреть фотографию, нажмите здесь". Пользователь, не желающий смотреть фотографии, будет просто счастлив.
Надеюсь, вы нашли 1-2 новых способа оптимизации скорости загрузки страниц.
has been designing Websites for over 6 years and has used his knowledge to create a HTML reference center for everyone's skill level. For information or HTML help contact: or visit
Перевод - Webmasterpro.com.ua - вопросы веб-дизайна и оптимизации сайта в поисковых системах: статьи, советы, рекомендации.
От слов к делу - установка Apache
"У меня для вас две новости: плохая и хорошая. Плохая: мяса мало, будем есть бизоний помет. И хорошая: его-то у нас много!.."
Из выступления вождя апачей
Итак, Вы решились установить на свой компьютер Apache для Windows 95/98. В таком случае Вам следует запастись терпением и для начала скачать дистрибутив сервера - файл с именем (3.061.629 байт). Скачали? Прекрасно. Теперь самое интересное - настройка Apache для Вашей системы.
Важно: мы попросим Вас в точности выполнять перечисленные ниже шаги, не пропуская и не откладывая ни одного. В этом случае все заработает - это проверено.
Этап первый - установка
Определитесь с директорией, в которую Вы будите устанавливать Apache. Все дальнейшие рассуждения основаны на том, что Вы выбрали для этой цели такой каталог: f:\usr\local\apache Если диска F: у Вас нет, или если Вы не хотите его захламлять, советуем сделать одно из трех:
Создайте диск F: с помощью какой-нибудь программы для виртуальных разделов (например, с помощью встроенной в Windows 95/98 программы DriveSpace). Это самое лучшее решение, и с точки зрения экономии памяти, и с точки зрения быстродействия. Ведь что такое Web-сайт, как не набор очень небольших файлов? А DriveSpace как раз и оптимизирует работу с такими файлами. Сделайте виртуальный диск F:. Для этого создайте где-нибудь на любом диске директорию, которая в будущем будет являться корневой для диска F:. Предположим, Вы выбрали C:\INTERNET. Далее, в начале файла c:\autoexec.bat пропишите такую строку: subst f: C:\INTERNET
и перезагрузите компьютер. У вас должен появиться виртуальный пустой диск F:.
ВНИМАНИЕ : имеются сведения, что в Windows 95/98 есть ошибка, в результате которой иногда subst-пути "сами по себе" преобразуются в абсолютные. То есть, например, иногда в рассмотренном выше примере команды
f: cd \ cd \ dir
(а точнее, команда dir в своем заголовке) ошибочно выведут, что текущая директория C:\ (а не F:\, как это должно быть). Указанная ошибка чаще всего проявляется в неработоспособности Perl-транслятора.
Так что лично мы не рекомендуем Вам использовать subst. Вместо этого воспользуйтесь пунктом 1 .
Наконец, Вы можете всего этого не делать и поставить Apache на любой другой диск, только тогда Вам придется немного тяжелее при выполнении всех остальных действий. Нужно будет все указываемые пути заменять на Ваши собственные, а это крайне неприятно. Еще раз настоятельно рекомендуем воспользоваться диском F:.
Рекомендуем все же разместить Apache в указанном в начале каталоге, так как он максимально соответствует каталогу для реального Web-сервера Интернета. Ведь чем ближе в плане конфигурации мы будем к такому серверу, тем лучше и эффективнее сможем работать.
Запустите только что скачанный файл. В появившемся диалоге нажмите кнопку Yes , а затем - кнопку Next . Теперь нажмите Browse . Вручную задайте директорию для установки: f:\usr\local\apache и нажмите кнопку OK . Выберите тип установки - Сustom и уберите флажок Source Code (если, конечно, не хотите посмотреть исходные тексты Apache). Этим Вы сэкономите себе 3 Мбайта. Нажмите Next и подождите, пока будут копироваться файлы Apache. На запрос о перезагрузке компьютера ответьте "Перезагрузить".
Поздравляем - Apache установлен! Теперь самое неприятное - его настройка.
Этап второй - настройка файла конфигурации Apache mime.types
Откройте директорию f:\usr\local\apache\conf. Откройте находящийся там файл mime.types. Найдите в нем такую строчку: text/html html htm
Измените ее на text/html html htm shtml shtm sht
Следует заметить, что если Вы по каким-то причинам не хотите портить файл mime.types, то можно вместо этого прописать в файле httpd.conf (см. ниже) строки вида AddType text/html html htm shtml shtm sht
Этап третий - настройка файла httpd.conf
Внимание! Это - самый ответственный момент установки. Просим соблюдать инструкции БУКВАЛЬНО.
Откройте директорию f:\usr\local\apache\conf Откройте находящийся там файл httpd.conf. Это - единственный файл, который Вам осталось настроить. Вам предстоит найти и изменить в нем некоторые строки, а именно те, о которых упоминается далее.
Во избежание недоразумений не трогайте все остальное. Следует заметить, что в нем каждый параметр сопровождается несколькими строками комментариев, разобраться в которых с первого раза довольно тяжело. Поэтому не обращайте на них внимание. В поле ServerAdmin укажите Ваш E-mail адрес, который будет показываться в сообщениях об ошибке сервера. Например: ServerAdmin my@email.com
В поле ServerName напишите любое слово - на работе это не сказывается, например: ServerName ApacheServer
Только не забудьте раскомментировать поле ServerName , то есть убрать символ "#" перед этим параметром (по умолчанию он закомментирован)!
В поле DocumentRoot укажите ту директорию, в которой будут храниться Ваши html-файлы, например: DocumentRoot f:/www
Разумеется, можете указать и любую другую директорию, если хотите. В любом случае, не забудьте ее создать, лучше сделайте это прямо сейчас!
Найдите блок, начинающийся строкой и заканчивающийся (вообще, такие блоки обозначают установки для заданной директории и всех ее поддиректорий). Его нужно изменить на: Options Indexes Includes AllowOverride All
Таким образом, в этом блоке будут храниться установки для всех директорий по умолчанию (т.к. это - корневая директория).
Найдите аналогичный блок, начинающийся и заканчивающийся . Там будет много комментариев, не обращайте на них внимание. Этот блок следует заменить на: Options Indexes Includes AllowOverride All Order allow,deny Allow from all
Это - установки для директории с Вашими html-документами. Если хотите, можете установить другую директорию, главное, чтобы она совпадала с той, которая прописана в параметре DocumentRoot
Идем дальше. Установите UserDir , например так: UserDir f:/home
Это будет директория, в которой хранились бы домашние страницы пользователей, если бы это был настоящий Web-сервер, а также корневые каталоги виртуальных хостов (см.
ниже). Не забудьте также создать этот каталог.
Установите DirectoryIndex так: DirectoryIndex index.htm index.html
Это - так называемые файлы индекса, которые автоматически выдаются сервером при обращении к какой-либо директории, если не указано имя html-документа. В принципе, можно добавить сюда и другие имена, например, index.phtml, если Вы будите работать с PHP и т.д.
Найдите и пропишите такой параметр: ScriptAlias /cgi-bin/ "f:/cgi-bin/"
Да, именно так, с двумя слэшами. Это будет та директория, в которой должны храниться Ваши CGI-скрипты. Если хотите, можете задать другое имя, например: ScriptAlias /mycgi/ "f:/mycgidir/"
Подобный параметр говорит Apache о том, что, если будет указан путь вида http://localhost/cgi-bin, то на самом деле следует обратиться к директории f:/cgi-bin.
Теперь следует найти и настроить блок параметров, начинающийся с и заканчивающийся . Это - установки для Вашей CGI-директории (если Вы установили для нее другое имя на предыдущем шаге, соответственно модифицируйте путь). Там должно быть: AllowOverride All Options ExecCGI
Настройте следующий параметр: AddHandler cgi-script .bat .exe
Это говорит Apache о том, что файлы с расширением .exe и .bat
нужно рассматривать как CGI-скрипты.
И последнее - установите: AddHandler server-parsed .shtml .shtm .sht
Или, если Вы хотите, чтобы и обычные файлы html обрабатывались SSI, напишите так: AddHandler server-parsed .shtml .shtm .sht .html .htm
Поздравляем - Вы настроили свой Apache, и он должен уже работать! Для запуска сервера нажмите Пуск->Программы->Apache Web Server->Start Apache as console app , при этом появится окно, очень похожее на Сеанс MS-DOS, и ничего больше не произойдет. Не закрывайте его и не трогайте до конца работы с Apache.
Несколько слов о том, как можно упростить запуск и завершение сервера. В Windows можно назначить любому ярлыку функциональную комбинацию клавиш, нажав которые, Вы запустите этот ярлык.
Так что щелкните правой кнопкой на панели задач, в контекстном меню выберите Свойства , затем Настройка меню и кнопку Дополнительно . В открывшемся Проводнике назначьте ярлыку Start Apache as console app комбинацию Ctrl+Alt+A , а ярлыку Shutdown Apache as console app - Ctrl+Alt+S
Вот шаги, которые можно проделать для проверки работоспособности сервера:
Проверка html : в директории f:/www с html-документами Apache создайте файл index.html. Теперь запустите браузер и наберите:
http://localhost/index.html
или просто http://localhost/
Загрузится Ваш файл.
Проверка CGI: в директории f:/cgi-bin для CGI-скриптов создайте файл test.bat с таким содержанием:
@echo off echo Content-type: text/html echo. echo. dir
Теперь в браузере наберите: http://localhost/cgi-bin/test.bat
В окне отобразится результат команды DOS dir. (Хотелось бы отметить, что указанный тест работает не на всех версиях Windows: иногда вместо того, чтобы выполнить файл test.bat, Apache выводит в браузер его содержимое. С чем это связано - не совсем ясно, однако, кажется, можно избавиться от указанной ошибки путем манипулирования с Реестром. Если у Вас test.bat не запускается, не расстраивайтесь: вряд ли Вы когда-нибудь будете писать скрипты в виде bat-файлов, тем более, что это несовместимо с Unix.)
Проверка SSI: аналогична проверке html. Используйте, например, директиву [an error occurred while processing this directive]
Если bat -файлы Ваш Apache запускать не хочет (см. выше), то дождитесь установки Perl или PHP.
Если что-то пошло не так, либо окно Apache открывается и тут же закрывается, значит, где-то произошла ошибка - скорее всего, в httpd.conf. За детальным разъяснением ее причин можно обратиться к log-файлам, расположенным в директории f:/usr/local/apache/logs.
ОТКАЗ ОТ DTD
В том, что касается отображения отраслевых данных, BizTalk исходит из бесперспективности определений типов документов (Document Type Definition, DTD). Вместо того чтобы поощрять разработку XML DTD, сторонники BizTalk описывают свои иерархии данных с помощью XML Schema (как предполагается, этот стандарт должен прийти на смену DTD). «DTD свойственны некоторые внутренние ограничения, — поясняет Шмидт. — Поэтому многие люди и группы предлагают свои решения».
В настоящее время W3C пытается согласовать различные подходы к схемам, но предложенная версия стандарта — XML Schema — дает достаточно ясное представление о том, как будет выглядеть замена DTD. XML Schema имеет значительно более широкие возможности, нежели DTD, причем описания даются с помощью непосредственно XML, без создания еще одной системы разметки, как того требует DTD (см. врезку «Новая схема»).
На общем уровне BizTalk Framework требует, чтобы издатели XML Schema придерживались определенных рекомендаций, большая часть которых основывается на общепринятой практике разработки программного обеспечения. Так, тегам предлагается давать осмысленные имена с понятным несокращенным написанием; эти имена должны соответствовать функциональному назначению информации, а не ее месту в частной структуре данных (например, “PartLocation” вместо “PartFieldFourteen”), а содержащаяся в теге информация не должна требовать специального, отличного от XML, декодирования (например, обозначение валюты денежной суммы должно храниться в виде элемента XML, а не присоединяться к сумме как в “$30US”). Эти рекомендации призваны облегчить жизнь тем, кто будет пытаться дешифровать конкретную схему.
Необходимыми составляющими BizTalk Framework являются специальные, общие для всех отраслей теги XML. Эти теги призваны освободить разработчиков от забот по поводу трех важнейших проблем взаимодействия приложений. Во-первых, от того, как данные передаются из одного приложения в другое; во-вторых, от того, как «вызвать» другое приложение — отправки приложению данных в формате XML должно быть достаточно; в-третьих, от того, в каком порядке должны следовать элементы данных.
Так что же делают эти теги? Один из них определяет код, с помощью которого принимающая данные в формате XML программа может установить, что за схема BizTalk используется. С помощью других тегов приложение может выяснить, кто является отправителем данных, что отправитель от него хочет и кому данные должны быть потом переданы. «Точно так же на основании информации на конверте почта определяет, как следует поступать с письмом, при этом ей нет никакого дела, что и в каком виде он содержит», — поясняет Шмидт.
Для обеспечения совместимости документ BizTalk должен начинаться и, соответственно, заканчиваться тегом BizTalk, чтобы получатель знал, что он вступил в сектор BizTalk. Тег MsgType задает пространство имен XML (вашу конкретную схему), определяющее допустимые элементы документа. Так как ваша схема использует формат данных XML (как описывается во врезке «Новая схема»), то тип данных, которыми вы наполняете свой документ, будет легко установить. Наконец, вы можете также вставить блок маршрутных документов, например:
BizTalk Framework ничего не говорит о том, какие данные должны входить в четыре атрибута тегов и , она просто устанавливает назначение каждого из них. Теги location идентифицируют сетевой узел (возможно, с помощью URL), куда направляется документ, в то время как теги process и handle определяют приложение и конкретный экземпляр (например, номер транзакции), к которому данные относятся.
Тег path служит своего рода вместилищем, где промежуточные серверы могут хранить сведения о дате и другую информацию, чтобы маршрут (и с помощью расширения обратный маршрут) был виден всем серверам вдоль пути.
Общий формат полного сообщения BizTalk показан во врезке «Анатомия сообщения BizTalk».
Относящиеся к XML стандарты и рекомендации
Hypertext Markup Language (HTML)
Формализован в RFC 1866. См. .
Standard Generalized Markup Language (SGML)
Стандарт ISO 8879 за 1986 год. См. .
Document Object Model (DOM)
См. .
Extensible Stylesheet Language (XSL)
Рабочий проект консорциума A World Wide Web (W3C). См. .
Extensible Markup Language (XML)
Рекомендация W3C. См. .
Пространства имен
Еще одна рекомендация W3C. См. .
Extensible Linking Language (XLL)
Рабочий проект W3C (см. ), он описывает, как сделать ссылки многонаправленными, и определяется на уровне объектов, а не страниц.
Extensible HTML (XHTML)
Переопределение HTML 4.0 в качестве приложения XML. Подробности см. в рабочем проекте W3C на .
Схемы XML
Призваны заменить Document Type Definitions (DTDs). См. рабочий проект W3C на .
Параметр 'charset'
В отличие от других значений, значения этого параметра не являются чувствительными к регистру букв.
Спецификации любых новых подтипов типа 'text' должны определять, будет ли этот новый подтип использовать параметр "charset" либо наоборот, будет запрещать его использование. Любое тело, не содержащее внутри себя других, должно целиеом быть в одной языковой кодировке. В частности, создатели новых подтипов должны уделить внимание многбайтным символьным наборам.
Дополнительно к предопределенным новые языковые кодировки могут быть зарегистрированы через IANA, хотя стандартизация их использования требует опробирования IESG (см. RFC-1340). Если используется 8-битная языковая кодировка (например, koi8 или cp866), то необходимо наличие поля заголовка Content-Transfer-Encoding для обеспечения передачи через ряд протоколов, в частности, SMTP.
Необходимо заметить, что управляющие символы (0-31, 127), включая DEL, не имеют определенного значения за исключением последовательности CRLF (13,10), означающей конец строки. Два символа де-факто широко употребляются: FormFeed (12), означающий, что следующий за ним текст должен начинаться на новой странице; и TAB (9), часто, но не всегда означающий "перевести курсор на следующий ближайший столбец после данной позиции, где номер столбца кратен воьсми". Любое другое использование управляющих символов или DEL в теле должно быть в рамках частного соглашения между отправителем и получателем. Но такие соглашения крайне не рекомендуются и по возможности должны быть заменены другими возможностями MIME.
Существует огромное количество языковых кодировок, что не является положительным фактом. В дальнейшем предполагается ввести универсальную многобитную языковую кодировку, поддерживающую все языки мира. К сожалению, существующая практика говорит о том, что возможно, еще долгое время электронной почте придется иметь дело с многими кодировками. По этой причине предопределены имена для наиболее распространенных языковых кодировок:
US-ASCII
ISO-8859-X -- где "X" - цифра от 1 до 9 включительно, означающая номер версии кодировки ISO-8859
Параметр "charset" был определен в основном для текстовых данных, но возможно, для бинарных данных тоже может потребоваться указать языковую кодировку, в этом случае должен использоваться тот же синтаксис те же значения.
Почтовое программное обеспечение должно руководствоваться принципом наименьшего набора символов, то есть, если письмо пишется как-бы в восьмибитной ISO-8859-1, но в письме используются символы лишь некоторого поднабора, например, семибитного US-ASCII, то почтовая программа должна автоматически определить имя символьной кодировки как US-ASCII. В этом случае уменьшится нагрузка в сети и увеличаися шансы, что получатель прочтет письмо без искажений.
Перегрузка системы
Поскольку вы разрабатываете динамический Web-сайт, то соответственно количество информации на нем может расти весьма быстро. Кроме того, по мере роста популярности вашего ресурса растет и число его посетителей, что может привести к перегрузкам сервера, то есть к понижению производительности системы. Перед тем как начать поиски путей увеличения мощности аппаратных средств и пытаться найти конфигурацию новой системы, можно попробовать устранить одну из возможных причин чрезмерного потребления оперативной памяти. Виновником может оказаться тот же Perl. Дело в том, что каждый раз при обращении к тому или иному Perl-скрипту, Web-сервер загружает интерпретатор в оперативную память (он занимает от 500-1000 Кбайт на жестком диске), а последний разбирает программу от начала до конца в поисках синтаксических ошибок. После этого он вновь читает ее, инициализируя переменные и функции, считывает вводимые данные (параметры), обрабатывает и возвращает результаты. Представляете, что происходит, если одновременно пресс-релизы хотят просмотреть сотни посетителей вашего сайта?
Для ускорения этого процесса созданы специальные решения, представляющие собой дополнительные модули для Web-сервера Apache — mod_fastcgi и mod_perl.
Модуль FastCGI (mod_fastcgi) предполагает широкое применение средств обмена данными между работающими процессами (задачами) операционной системы. В начале своей работы Web-сервер активирует CGI-программу и оставляет эту программу и несколько ее копий работающими в фоновом режиме. Любые запросы к программе будут просто переданы уже активным копиям, что избавит сервер от дополнительной нагрузки, связанной с повторной активацией процесса.
Модуль mod_perl позволяет загрузить Perl в оперативную память в то же адресное пространство, что и сам Web-сервер Apache, и оставить Perl в памяти до завершения работы последнего, не позволяя загружать очередную копию интерпретатора при обращении к CGI-программе. Этот модуль применяется чаще, чем FastCGI, поскольку не требует никаких изменений в программе.
ПЕРВЫЕ ПРИЛОЖЕНИЯ
Как только стало ясно, что XML хорошо подходят для CIM, а спецификации XML стали приобретать законченный вид, Manage.Com () удалось вырваться вперед и на голову опередить весь остальной рынок благодаря тому, что компания раньше всех решила реализовать продукты на базе CIM и XML. Frontline e.M, главный продукт компании, имеет клиент на базе браузера для мониторинга, контроля, конфигурации и диагностирования компонентов бизнес-процессов и транзакций, даже если они осуществляются через брандмауэр или VPN.
Серверное программное обеспечение e.M выполняется на сервере Web и способно автоматически обнаруживать сервисы, приложения и устройства IP. Оно контролирует, конфигурирует и сопоставляет данные от управляемых объектов. Кроме того, оно отвечает за извещение о проблемах, составление отчетов и реализацию правил. Управляемые объекты, информация об их взаимоотношениях и профили контроля доступа для пользователей хранятся в базе данных Frontline e.M (или в имеющейся базе данных организации).
Устройства и процессы, мониторинг и управление которыми следует реализовать, могут быть оснащены e.Agents — агентами на базе Java, распространяемыми защищенным образом с помощью SSL или по VPN. Сервер e.M также может запрашивать управляющие данные от SNMP и других источников.
Так называемые e.Bots представляют собой агенты по типу сценариев или макросов, способные выполнять ряд задач на периодической основе или при наступлении определенных условий. Например, e.Bot может перевести пользователей на другой сервер, когда свободное место на диске будет меньше предопределенного порога.
Самым новаторским компонентом архитектуры Manage.com является e.Registry. Manage.com характеризует e.Registry как портал управления. e.Registry является хранилищем схем с описаниями управляемых объектов, правил конфигурации и информации о диагностике, производительности и загруженности сервисов (таких, как электронная почта), устройств (таких, как брандмауэр) и приложений (таких, как обработка заказов). Серверы e.M могут обновлять свои возможности регулярно или по требованию, потому что и e.M, и e.Registry базируются на CIM и потому, что благодаря XML они могут обмениваться структурированной информацией по Internet.
По сути, e. Registry представляет собой набор DTD, к которому может обращаться любой сервер e.M. После модификации старых элементов и добавления новых на сервере e.Registry компании Manage.Com пользователи могут загрузить и использовать их.
Хотя Frontline e.M способен выполнять многие из задач, решаемых традиционными продуктами для управления сетями и системами, Manage.Com не считает свой продукт панацеей от всех бед управления. Главная роль, на которую он предназначен, — это контроль за относительно небольшим числом критических бизнес-процессов, перебои в работе которых недопустимы, и управление ими из конца в конец, возможно, в соответствии с соглашениями об уровне сервиса. Frontline e.M не столь хорошо подходит на роль основного приложения для корпоративного центра управления сетью, как продукты наподобие HP OpenView, к тому же он не пригоден для выполнения таких задач, как распространение программного обеспечения или управление корпоративной системой хранения, как продукты наподобие CA Unicenter.
Хотя Frontline e.M и не претендует на место универсальной платформы управления, Manage.Com заключила партнерские соглашения с двумя другими компаниями, что увеличивает полезность модели CIM-XML-HTTP. Top Layer Networks () производит коммутатор с классификацией и приоритезацией трафика — AppSwitch 2000. Эта компания собирается использовать manageXML — расширенную инфраструктуру XML компании Manage.Com — в качестве базового транспорта управляющей информации. Таким образом, интерфейс управления для AppSwitch 2000 будет предоставляться Frontline e.M.
Пользователи AppSwitch 2000 — а они, как правило, принадлежат к IP-центрическому миру, для которого Manage.Com предназначает свои предложения, — могут получить обновленное программное обеспечение управления элементами через e.Registry, а устройства AppSwitch 2000 будут без труда интегрироваться в экосистему Frontline e.M/WBEM. Кроме того, пользователи AppSwitch 2000 получат в свое распоряжение функции автоматической диагностики Frontline e.M.
Другой партнер Manage.Com — компания Data Channel () — специализируется на инструментарии разработки, технологиях и обучении XML. Data Channel взяла на себя обязательство разработать экспертные методики, с помощью которых заказчики Manage.Com могли бы создавать документы manageXML, т. е. свои собственные расширения для среды Frontline e.M. Например, эксперты могли бы использоваться для контроля доступа пользователей, определения политики приоритетов и включения происходящих в компании событий в систему управления.
XML и его спутники в проекте WBEM дают новую надежду сообществу пользователей и специалистов по управлению сетями и системами, тем более что последние несколько лет эта отрасль следовала накатанной колеей. Тонкости XML, DTD и объектных моделей будут скрыты от администраторов сетей, так что они могут не опасаться ожидаемого уже в ближайшее время появления множества приложений на базе этих стандартных технологий.
WBEM очень кстати решает проблему гетерогенных систем, предоставляя пользователям большую гибкость в выборе средств. Кроме того, оно снижает стоимость владения для предприятий и делает важный шаг на пути к самовосстанавливающимся сетям, давней цели систем управления. Новая роль HTTP как транспортного протокола для управляющей информации означает, что управляющие приложения получат более надежную защиту, что удаленное управление станет намного проще и что разработка средств управления будет производиться по часам Internet, а не мэйнфреймов.
Стив Штайнке — главный редактор Network Magazine. С ним можно связаться по адресу: .
Почему была написана эта заметка
Internet Information Server ( IIS ) под Windows NT является сейчас вторым ( после Apache ) по популярности web-сервером. Можно привести ряд аргументов в пользу того или иного выбора - Apache или IIS - это предмет отдельного разговора, выходящего за рамки данной заметки. Так или иначе, я столкнулся с задачей установки PERL для IIS3 под Windows NT. Цель данной операции вполне понятна: PERL в настоящее время - наиболее популярный язык автоматизации web-сервера. На нем написана масса полезных скриптов, всевозможных счетчиков, программ приема заявок, и многое другое. Хотелось бы уметь адаптировать все это под IIS, да и свои скрипты хотелось бы уметь писать так, чтобы они с минимальными изменениями годились для любого web-сервера. Значит, их стоит писать не на BASIC, а скорее на PERL.
Итак, хорошо бы поставить PERL на IIS под NT. Лезем в Интернет, выясняется - это интересует многих, и это таки-можно сделать : есть кампания Active State ( www.activestate.com ), которая разработала поддержку PERL для IIS; все, что для этого требуется, можно с ее сервера бесплатно скачать. А в качестве руководства к действию - читайте FAQ , который поддерживает некто Evangelo Prodromou. Замечательно.
Теперь можно обяснить цель появления данной заметки. Как выяснилость на практике, указанный выше FAQ от Evangelo Prodromou , на который много ссылок в разных местах, весьма мало пригоден как начальное руководство к действию по установке PERL для IIS. В нем есть много полезных сведений, тонкостей, но вот простой и внятной инструкции : делай раз, делай два, делай три - и твой первый скрипт типа "Здравствуй, ПЕРЛ" заработает на IIS- там нет. Что и привело в нашем случае к изрядной потере времени.Именно попытка создания такой простой инструкции и есть предмет данной заметки.
То, о чем дальше будет говориться, проверено уже не один раз для IIS3. Вероятно, все это верно и для версий IIS4 и IIS2, но сам я этого не проверял.
Почему динамические сайты лучше
Сразу после того как динамический сайт создан и запущен в работу, начинают проявляться его преимущества. Теперь в вашем распоряжении имеется сравнительно небольшое количество шаблонных страниц, с помощью которых генерируются сотни, а может быть, и тысячи Web-страниц. Вид (дизайн) сайта может быть легко изменен с помощью модификации этих шаблонов. Изменение содержимого базы данных можно производить через Web-интерфейс с использованием HTML-формы, не вторгаясь при этом в технические детали каждой специфической СУБД.
Почтовый стандарт MIME (RFC1521)
при поддержке
Документ предсталяет собой неполный русский перевод спецификации RFC 1521 "MIME - Multipurpose Internet Mail Extensions. Part one. Mechanismes for Specifying and Describing the Format of Internet Message Bodies".
Автор перевода: Антон Воронин
MIME означает "Multipurpose Internet Mail Extensions" (Многоцелевые расширения почтового стандарта Internet). Этот стандарт описывает как пересылать по электронной почте исполняемые, графические, мультимедийные, смешаные данные. Типичные применения MIME - пересылка графических изображений, аудио, документов Word, программ и даже просто текстовых файлов, то есть, когда важно, чтобы входе пересылки не производилось никаких преобразований над данными. MIME также позволяет размечать письмо на части различных типов так, чтобы получатель (почтовая программа) мог определить, что делать с каждой из частей письма.
Как читать письма в стандарте MIME? Т.к. MIME используется всего несколько лет, еще существуют старые почтовые программы, которые не понимают MIME. Однако, растет число почтовых программ, имеющих встроенную поддержку MIME (одна из самых популярных - "Pine", разработанная в Вашингтонском университете и реализованная для платформ UNIX, VMS, DOS, Windows). К тому же в некоторых почтовых системах имеются специальные шлюзы, обеспечивающие MIME-трансляцию. Но даже если у вас нет возможности использовать MIME-совместимую почтовую программу и нет доступа к подобному шлюзу, то можно также воспользоваться рядом программ, способных интерпретировать письма в MIME, сохраненные рпочтовой программой в файле. Например, програма "munpack", созданная в университете Carnegie Mellon. Существуют ее версии для Unix, PC, Macintosh, Amiga.
Долгое время для кодирования бинарных файлов в 7-битный формат (чтобы обеспечить их пересылку по почтовой системе Internet) использовалась кодировка UUENCODE, имеющая ряд технических ограничений. Стандарт MIME предполагает использовние более устойчивой кодировки "Base64", которая специально разработана для обеспечения сохранности данных, пересылаемых по email, при различных преобразованиях, имиеющих место в ходе прохождения почтовых шлюзов.
Стандарт MIME полностью описан в RFC-1521
Поддержка кросс-платформенности.
В ближайшем будущем Curl Corporation собирается адаптировать данную технологию под MacOS, а также поддерживать PDA, мобильные телефоны и любые устройства имеющие возможность подключения к Internet. Такой подход во многом облегчит создание ресурсов по принципу "однажды создав приложение, запускай его в не зависимости от той ОС на которой работает пользователь". Компания предоставляет Just-In-Time (JIT) компилятор с помощью которого формируется код, предоставляющий возможность клиентской платформе самой решать в каком виде и на каком устройстве отображать информацию. JIT компилятор интерпретирует код в то, что хочет достичь разработчик и производит необходимые уточнения приводя код в сответствие правилам стандарта.
Поддержка политики Open Source.
Curl Corporation приветствует начинания политики Open Source (открытого кода) и стратегию совместного создания ПО. Однако, Curl Corporation оставляет себе контроль за той частью ПО, которая гарантирует переносимость, устойчивость и стабильность разработки программных проектов.
Поддержка XML.
В среду Surge встроен стандартный XML SAX интерпретатор, позволяющий клиентской части технологии работать как презентационному слою для XML данных совместимых с SAX 2.0 API. Поддержка интерпретатора DOM, так же как и других связанных с XML технологий, будет реализована в новых версиях среды.
Подготовка к работе
Для запуска Perl-программ понадобится интерпретатор Perl версии 5.005 или 5.6 дистрибутивов Perl Standard или ActiveState Perl для UNIX или Win32. Если вы будете заниматься разработкой приложений для функционирования под Win32, то пакет от ActiveState несколько удобнее в использовании, к тому же в него входит утилита PPM для установки дополнительных модулей.
Для организации взаимодействия наших Perl-программ с СУБД MySQL необходимо, чтобы в поставку Perl входил модуль DBI. Поскольку модуль в основном ничего сам не делает, а перекладывает все операции по взаимодействию с базами данных на соответствующий им драйвер, то требуется установка библиотеки DBD-Mysql (драйвер к БД MySQL для модуля DBI). Как заявил Тим Бьюнс (Tim Bunce), автор и разработчик указанного модуля, «DBI — это API-интерфейс для организации доступа к базам данных из Perl-программ. Спецификация DBI API определяет набор функций, переменных и правил, используемых для прозрачного интерфейса с базами данных».
Концепция драйверов баз данных весьма удобна, поскольку в своем Perl-приложении вы используете стандартные для DBI вызовы, которые затем переадресуются модули соответствующему драйверу, а тот, в свою очередь, уже напрямую будет взаимодействовать с БД, не требуя от вас изучения технических особенностей каждой конкретной СУБД. Таким образом, существуют драйверы DBD::Sybase, DBD::Oracle, DBD::Informix и т.д. (рис. 1, 2).
Рис. 1. Архитектура DBI
Рис. 2. Поток данных через интерфейс DBI
Немного выйдем за рамки тематики статьи. Допустим, что в поставку DBI не входит драйвер для специфической СУБД. В данном случае на помощь придет мост DBD-ODBC. Достаточно создать новый источник данных (Data Source Name) для драйвера ODBC (Open DataBase Connectivity), где нужно выбрать тип этой СУБД, адрес хоста, по которому надо установить соединение, имя базы данных и авторизационные данные, то есть имя пользователя и пароль (рис. 3). И затем, используя модуль DBI, взаимодействовать с базой данных. Кроме того, как правило, в стандартную поставку ActiveState Perl входит модуль Win32::ODBC (Win32-ODBC).
Работа с ним немного отличается от работы с DBI, но в целом очень похожа. Разница лишь в том, что Win32::ODBC — модуль только для Win32-систем и позволяет работать с «родными» функциями ODBC более эффективно, чем DBD::ODBC.
Рис. 3. Добавление нового источника данных через ODBC-администратор
Между ODBC и DBI можно провести параллель. DBI — это аналог ODBC Administrator (менеджера драйверов баз данных). Каждый DBD-драйвер по своим функциям соответствует ODBC-драйверу. Может смутить лишь тот факт, что существует, как говорилось выше, драйвер DBD::ODBC. Но он всего лишь позволяет установить связь DBI с ODBC-драйверами.
Для установки DBI и DBD-Mysql, с помощью утилиты PPM в среде Win32 введите в командной строке:
ppm install DBI
Обратите внимание, что в этот момент ваш компьютер должен быть подключен к Интернету. Если же соответствующий модуль имеется у вас на локальном диске, воспользуйтесь справочной информацией, введя команду:
ppm help install
Для пользователей UNIX-систем установка модуля DBI будет проходить практически так же, как и установка других Perl-модулей:
tar –zxvf DBI-1.06.tar.gz cd DBI-1.06/ perl Makefile.PL make make test make install
Можно также воспользоваться оболочкой CPAN. Если же на вашем компьютере установлена UNIX-версия пакета от ActiveState, то можно работать и с установочной утилитой PPM. Иногда бывает, что оболочки CPAN и PPM не функционируют, если в сети предприятия, к которой подключен ваш компьютер, установлен брандмауэр, или сетевой экран (firewall). В данном случае вам помогут только модули с исходными текстами, загруженные вручную. Для их установки и подключения к Perl или Apache потребуется интерпретатор Perl, компилятор C/C++ или GCC/PGCC и какая-либо из утилит-сборщиков make (из поставки одного из клонов UNIX, а также Microsoft Visual C++), nmake или dmake. Таким образом, процедура установки модулей несколько усложняется. Почти с каждым из них поставляется документация по «сборке», благодаря которой у вас не должно возникнуть особых трудностей.
Подтип 'Application/PostScript'
Тип "application/postscript" означает, что пересылается PostScript-документ и требует специальной программы для его обработки. В настоящий момент используются два языка - level 1 и более поздний - level 2.
PostScript-документы представляют собой интерпретируемые программы, которые могут содержать операторы обращения к диску и действий с файлами. Поэтому PostScript-документы представляют потенциальную опасность для системы получателя.
В некоторых интерпретаторах PostScript могут иметь место ошибки, которые могут быть использованы хакерами для несанкционированного доступа к системе получателя, и нельзя предложить какого-либо специфического действия для предотвращения подобной возможности, кроме исправления со временем подобных ошибок (если они, конечно, есть) производителями соответствующего ПО.
Подтип 'Message/External-Body'
Этот подтип указывает на то, что тело не содержится в самом письме, а на него есть ссылка. Параметры подтипа описывают способ доступа к данным тела письма.
Письмо (часть письма) этого подтипа состоит из заголовка, двух последовательных концов строки и заголовка вложенного письма. Если встречается другая пара концов строки, она означает конец заголовка вложенного письма. Однако, поскольку тело вложенного письма является внешним, оно не следует за концом заголовка. Например, Content-type: message/external-body; access- type=local-file; name="/u/nsb/Me.gif" Content-type: image/gif Content-ID: Content-Transfer-Encoding: binary ТЕЛА НЕТ!
Область в конце, которую можно назвать "призрачным телом", игнорируется для большинства писем подтипа 'external-body'. Однако, в нее можно помещать дополнительную информацию, как например, в случае, когда параметр 'access-type' равен "mail-server". Во всех остальных случаях призрачное тело игнорируется.
Единственный всегда обязательный параметр для 'message/external-body' - "access-type". Остальные параметры могут быть или не быть обязательными в зависимости от значения параметра "access-type".
Значение этого параметра - слово, нечувствительное к регистру букв, означающее механизм доступа, с помощью которого файл или данные могут быть получены. Значения могут быть следующими (но не ограничиваются этим рядом): "FTP", "ANON-FTP", "TFTP", "AFS", "LOCAL-FILE" и "MAIL-SERVER". Будущие возможные значения, кроме экспериментальных, начинающихся с "X-", должны быть зарегистрированы в IANA.
Дополнительно, следующие три параметра являются необязательными для всех способов доступа:
EXPIRATION -- Дата (RFC 822 "date-time" синтаксис допускает 4 цифры в этом поле), после которой существование внешних данных не гарантируется.
SIZE -- размер (в байтах) данных. Позволяет получателю решить, расходовать ли ресурсы на считывание внешних данных.
Размер указывается для канонической формы данных (то есть, до применения каких-либо преобразований).
PERMISSION -- нечувствительное к регистру букв поле, говорящее о том, ожидается или нет, что клиент может перезаписывать данные. По умолчанию или когда этот параметр имеет значение "read", полагается, что клиент не имеет на это права, и что если данные однажды считаны, то больше они не понадобятся. Если PERMISSION имеет значение "read-write", любая локальная копия может рассматриваться не более как кэш. "read" и "write" - единственные предопределенные значения для PERMISSION.
Вложенные заголовки во ВСЕХ телах типа message/external-body ДОЛЖНЫ включать поле заголовка Content-ID для задания уникального идентификатора, указывающего на внешние данные.
Обозначения, описывающие данные типа external-body, такие как имена файлов или команды mail-сервера, должны быть в символьном наборе US-ASCII.
Как и для типа message/partial, тело типа message/external-body должно иметь значение content-transfer-encoding "7-bit" (по умолчанию). В частности, даже в системах, поддержиавющих 8-битный транспорт, применение content-transfer-encoding "8-bit" и "binary" запрещено для данных типа message/external-body.
Подтип 'message/partial'
Этот подтип определен с целью обеспечения возможности пересылки очень больших объектов в виде нескольких раздельных частей, автоматичски "склеиваемых" почтовой программой получателя. Этот механизм может пригодиться, когда промежуточные почтовые шлюзы ограничивают индивидуальный размер пересылаемых писем. Т.о., этот подтип говорит о том, что письмо содержит лишь часть большого послания.
Для этого подтипа необходимо указание трех параметров:
"id" - уникальный идентификатор, позволяющий обнаружить остальные части послания.
"number" - целое число, означающее номер части послания.
"total" - целое число, означающее общее количество частей. Требуется лишь в последней части и не обязателен (хотя рекомендуется) для предыдущих частей. Эти параметры могут следовать в произвольном порядке.
Пример: часть 2 3-х частного послания имеет следующие варианты заголовка: Content-Type: Message/Partial; number=2; total=3; id="oc=jpbe0M2Yt4s@thumper.bellcore.com" Content-Type: Message/Partial; id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; number=2
Но часть 3 обязательно должна содержать параметр "total": Content-Type: Message/Partial; number=3; total=3; id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
Необходимо заметить, что нумирация частей начинается с 1, а не с 0.
Когда подобным образом разбитые части собираются вместе, они образуют полное MIME-письмо, содержимое которого может иметь любой другой тип и, соответственно, свое поле заголовка Content-Type, описывающее этот тип.
Семантика partial-письма должна быть та же, как в обычном письме с содержимым данного типа, а не как в письме, содержащем "внутреннее" письмо. Это позволяет, например, переслать большой аудио-файл ввиде нескольких более мелких, остающихся, тем не менее, видимыми получателю как обычные аудио-письма, а не как вложенные аудио-письма.
При "сборке" таких посланий в пункте назначения должны учитываться следующие правила:
Все поля заголовка части 1, кроме начинающихся с "Content-" и специальных "Message-ID", "Encrypted" и "MIME-Version" должны быть скопированы в заголовок нового (общего) письма.
Только поля заголовка ВЛОЖЕННОГО письма, начинающиеся с "Content-", а также поля "Message-ID", "Encrypted" и "MIME-Version", должны быть добавлены к заголовку нового общего письма, все остальные поля должны игнорироваться.
Заголовки второй и последующих частей целиком игнорируются.
Например, если письмо с аудио-данными было разбито на две части, первая из них может выглядеть следующим образом: X-Weird-Header-1: Foo From: Bill@host.com To: joe@otherhost.com Subject: Audio mail Message-ID: MIME-Version: 1.0 Content-type: message/partial; id="ABC@host.com"; number=1; total=2 X-Weird-Header-1: Bar X-Weird-Header-2: Hello Message-ID: MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64 ... здесь имеет место быть первая часть закодированных аудио-данных ...
А вторая может выглядеть так: From: Bill@host.com To: joe@otherhost.com Subject: Audio mail MIME-Version: 1.0 Message-ID: Content-type: message/partial; id="ABC@host.com"; number=2; total=2 ... здесь имеет место быть вторая часть закодированных аудио-данных ...
После того, как расколотое послание воссоздано заново для отображения получателю, оно должно выглядеть следующим образом: X-Weird-Header-1: Foo From: Bill@host.com To: joe@otherhost.com Subject: Audio mail Message-ID: MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64 ... первая часть закодированных аудио-данных ... ... вторая часть закодированных аудио-данных ...
Замечание по кодированию тела MIME-письма, заключенного внутри тела message/partial: так как данные типа "message" никогда не могут быть кодированы в Base64 или Quoted-Printable, следующая проблема может возникнуть в случае, если тела писем типа message/partial созданы в системе, поддерживающей 8-битный транспорт. Двоичные данные будут разбиты на несколько message/partial-объектов, каждому из которых требуется транспортировка в двоичном виде.
Если бы таким объектам пришлось пройти через шлюз в 7-битную транспортную среду, их невозможно было бы перекодировать в сеимбитную форму без ожидания прибытия всех частей послания, собирания их воедино и затем кодирования целого послания в 7-битную кодировку (base64 или quoted-printable). Поскльку существует вероятность, что разные части пойдут разными путями (через различные шлюзы), то подобное решение не приемлимо. Поэтому MIME определяет, что письма типа message/partial должны иметь 7-битную кодировку и соответствующее ей значение поля content-transfer-encoding. Даже для систем с транспортом, поддерживающим "8-бит" и "binary", запрещается их использование для данных message/partial.
Многие почтовые агенты могут автоматически фрагментировать большие письма.
Включение поля "References" в заголовки второй и последующих частей, ссылающегося на идентификатор предыдущей части, может оказаться полезным для почтовых программ, понимающих и обрабатывающих ссылки. Однако, наличие этого поля не обязательно.
Поле заголовка "Encrypted" вышло из употребления, но вышеприведенные правила обеспечивают корректную его интерпретацию, если оно встречается при обработке фрагментов типа message/partial.
Подтип "multipart/alternative"
Этот подтип синтаксически идентичен предыдущему, но имеет несколько другую семантику.
Почтовые системы должны распознавать, что данные из разных частей взаимозаменяемы. Системы должны выбрать наиболее подходящий вариант для локальной платформы и других условий, в некоторых случаях, с согласия пользователя. Как и в предыдущем случае, порядок частей в письме существенен. В этом случае альтернативы располагаются в порядке уменьшения отличия от оригинала. Обычно, выбирается последняя часть (альтернатива) из тех, которые имеют тип, поддерживаемый локальной системой получателя.
Multipart/alternative может быть использована, к примеру, для пересылки текста в некотором гипотетическом формате: From: Nathaniel Borenstein To: Ned Freed Subject: Formatted text mail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=boundary42 --boundary42 Content-Type: text/plain; charset=us-ascii ... Здесь содержится версия простым текстом .... --boundary42 Content-Type: text/richtext .... Здесь содержится версия с разметкой RFC 1341 ... --boundary42 Content-Type: text/x-whatever .... Здесь содержится версия в гипотетическом формате ... --boundary42--
В этом примере пользователь, чья система понимает этот гипотетический формат, увидят именно эту версию, в то время как остальные будут видеть размеченный либо простой текст в зависимости от возможностей их системы.
Обычно пользовательский агент, создающий письмо в multipart/alternative, должны располагать альтернативные части в порядке увеличения предпочтительности формата, то есть, предполагая, что наш гипотетический формат является самым удобным для конкретных данных (иначе зачем было бы его изобретать?), пользовательский агент должен располагать альтернативу в простейшем формате первой, а самую размеченную последней. Агент получателя должен отобразить последнюю из понимаемых им альтернатив. В случае, если одна из альтернатив сама имеет тип 'multipart' и содержит подчасти неизвестных типов, пользовательский агент может выбрать, показывать ли эту альтернативу, предыдущую или обе.
ЗАМЕЧАНИЕ: С точки зрения программиста, может показаться более удобным располагать альтернативы в обратном порядке, но данный порядок позволяет устаревшим не-MIME'овским почтовым программам отобразить в первую очередь наиболее понятный вариант.
ЗАМЕЧАНИЕ ПО СЕМАНТИКЕ ПОЛЯ 'CONTENT-ID' В ПИСЬМЕ MULTIPART/ALTERNATIVE: Рекомендуется, чтобы каждая часть имела уникальное значение поля Content-ID в случае, если содержимое этих частей не является идентичным. Однако, там, где содержащаяся информация идентична (например, если несколько частей типа "application/external- body" определяют альтернативные пути доступа к одним и тем же внешним по отношению к письму данным), должно использоваться одно и то же значение Content-ID, чтобы оптимизировать работу кэширующего механизма на системе получателя. Однако, не рекомендуется, чтобы значения Content-ID, использующиеся для частей, отличались от значения Content-ID, использующегося в заголовке верхнего уровня, если такое поле в нем присутствует.
Подтип "multipart/digest"
Этот подтип идентичен подтипу 'multipart/mixed', но имеет другую семантику. Например, для 'digest' значением по умолчанию является не "text/plane", а "message/rfc822".
В соответствии с этим подтипом, письмо-дайджест может выглядеть следующим образом: From: Moderator-Address To: Recipient-List MIME-Version: 1.0 Subject: Internet Digest, volume 42 Content-Type: multipart/digest; boundary="---- next message ----" ------ next message ---- From: someone-else Subject: my opinion ... тело вложенного письма ... ------ next message ---- From: someone-else-again Subject: my different opinion ... тело другого вложенного письма ... ------ next message ------
Подтип "multipart/parallel"
Отличие этого подтипа от "multipart/mixed", в частности, состоит в том, что порядок расположения частей письма не принципиален.
Данные этого подтипа должны отображаться одновременно, если платформа получателя обладает соответствующими возможностями. Однако, почтовый агент отправителя должен сознавать, что программа получателя может не иметь подобных возможностей и отобразить все части письма последовательно.
Подтип 'Text/plain'
Это основной подтип, соответствующий простому (неформатированному) тексту. Значение поля Content-Type для почты Internet по умолчанию - "text/plain; charset=us-ascii". Это тип данных, соответствующий RFC 822.
Других предопределенных подтипов для типа 'text' нет.
Формальный синтаксис для типа 'text': тип := "text" "/" подтип [";" "charset" "=" имя языковой кодировки] подтип := "plain" / расширение (не предопределенный подтип) имя языковой кодировки:= "us-ascii"/ "iso-8859-1"/ "iso-8859-2" / "iso-8859-3" / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6" / "iso-8859-7" / "iso-8859-8" / "iso-8859-9" / расширение (не предопределенная кодировка)
Поле заголовка Content-Transfer-Encoding
Многие типы данных, пересылаемых через email требуют "натурального" представления, то есть, 8-битный набор символов либо двоичный код (что для машины - одно и то же, только представимо для пользователя по-разному). В таком виде данные не могут быть пересланы по 7-битным почтовым протоколам, например, RFC 821, который, к тому же, ограничивает длину строки 1000 символами.
Стандартные механизмы конвертирования почты в 7-битный короткострочный формат, приемлимый для почтового транспорта, описывает поле заголовка Content-Transfer-Encoding.
В отличие от типов содержимого, увеличение множества значений Content-Transfer-Encoding не является необходимым и даже нежелательно. Но установление единого механизма конвертирования не представляется возможным. Существует противоречие между желанием эффективно "ужать" бинарные данные и желанием трансформировать данные, которые, хотя бы частично являются 7-битным текстом, так, чтобы их все-таки можно было читать. По этой причине необходимы по крайней мере 2 механизма конвертации: "читабельный" и "плотно ужимающий".
Данное поле не было определено в предыдущих стандартах. Его значение должно быть строкой без пробелов, определяющей тип конвертации, как показано ниже: конвертация := "Content-Transfer-Encoding" ":" механизм механизм := "7bit" ; / "quoted-printable" / "base64" / "8bit" / "binary" / x-token
Значения не чувствительны к регистру букв, то есть, Base64, BASE64 и bAsE64 - одно и то же. Значение "7BIT" означает, что тело письма уже имеет 7-битный формат и не тренбует дополнительной обработки для пересылки по почте. Это значение полагается по умолчанию, если поле заголовка Content-Transfer-Encoding отсутствует.
Значения "8bit", "7bit" и "binary" означают, что никакой трансформации содержимого не производится. Однако, они сделаны различными для индикации того, что из себя представляет содержимое письма, и, соответственно, способа обработки, который может потребоваться для данной транспортной системы.
В частности:
"7bit" означает, что данные являются текстом, имеют короткие строки и языковую кодировку US-ASCII.
"8bit" означает короткие строки, но в них могут содержаться не-ASCII символы (128-255).
"Binary" означает, что тело письма может содержать не-ASCII символы, но строки могут быть произвольной длины, т.е. слишком длинными для SMTP-транспорта, и может несоблюдаться соглашение по признаку конца строки (CRLF), принятое в SMTP-транспорте.
Хотя на первый взгляд разница в значениях Content-Transfer-Encoding может показатся неважной - ведь все они означают, что никакого преобразования нет, но четкая разметка важна для почтовых шлюзов между разными почтовыми системами, имеющими разные возможности и особенности работы, число которых со временем растет.
Спецификация на почтовый транспорт для пересылки некодированных 8-битных данных дана в RFC-1426. Однако, нет стандартизованных транспортов рочты Internet, для которых является приемлимым включение в тело письма некодированных двоичных данных. Таким образом, значение "binary" фактически не является легальным в Internet. Но в соответствии с MIME, при использовании почтовой системой транспорта, умеющего работать с двоичными данными, в случае, когда необходимо послать двоичные данные по e-mail, необходимо указать это в заголовке в поле Content-Transfer-Encoding.
Пять значений, определенных для поля Content-Transfer-Encoding, ничего не говорят о типе содержимого кроме указания алгоритма кодирования либо требований к почтовому транспорту в случае некодированных данных.
Производители почтового ПО, если необходимо, могут определить новые значения поля Content-Transfer-Encoding, но эти значения должны иметь префикс "X-" ("x-"), чтобы подчеркнуть их нестандартный характер. Однако, в отличие от типов и подтипов поля Content-Type, введение новых значений Content-Transfer-Encoding настоятельно не рекомендуется, так как может оказаться помехой для взаимосовместимости почтовых систем.
Использование X- значений позволяется только как результат взаимосоглашения между взаимодействующими системами.
Если поле Content-Transfer-Encoding появляеися в заголовке тела какой-то части письма, оно применяется только к содержимому этой части. Если письмо (часть письма) имеет тип "multipart" или "message", то поле Content-Transfer-Encoding может иметь в качестве своего значения только длину символа ("7bit", "8bit" и т.д.) или "binary".
Необходимо заметить. что электронная почта является символьно-ориентированной, так что механизмы конвертации работают с данными как с потоком символов, а не битов. Если битовый поток должен быть кодирован посредством какого-либо из этих механизмов, сначала он должен быть конвертирован в 8-битный поток байтов, используя порядок битов, стандартный для сетей (старшие разряды в конце). То есть, передние биты в потоке становятся битами высшего порядка в байте. Если битовый поток оканчивается неполным байтом, недостающие разряды заполняются нулями.
Все кодирующие механизмы, определенные в спецификации MIME, кодируют любые данные в символьную форму. Так, к примеру, полагая, что тело письма (части письма) имеет поля заголовка вроде: Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64
то это означает, что тело письма представляет собой ASCII-код base64 текстовых данных, которые в нормальном виде имеют языковую кодировку ISO-8859-1, и будут в этой языковой кодировке после декодирования.
Все множество определенных значений поля content-transfer-encoding кроме начинающихся с префикса "X-", зарезервировано в IANA для будущего использования. Частные соглашения по значениям content-transfer-encoding также настоятельно не рекомендуются.
Некоторые значения Content-transfer-encoding могут использоваться только с определенными типами (поле Content-Type). В частности, запрещено использовать любые значения кроме "7bit", "8bit", или "binary" с любым типом, рекурсивно включающим заголовки с полем Content-Type (как правило, это типы "multipart" и "message").
Все кодирования, необходимые для содержимого тел многочастного письма должны быть произведены на более низком уровне.
Замечания по ограничениям конвертации:
Необходимо предотвращать случаи вложенного кодирования, когда данные проходят через алгоритм конвертации несколько раз и должны столько же раз быть декодированы, чтобы быть читаемыми. Вложенное кодирование добавляет сложностей пользовательским почтовым программам: кроме очевидных проблем с множественной конвертацией, они могут скрыть основную структуру письма. В частности, они могут привести к тому, что несколько операций по декодированию могут потребоваться только для того, чтобы определить, объекты каких типов находятся в письме. Запрещение вложенного кодирования может осложнить работу некоторых почтовых шлюзов, но это будет меньшей проблемой по сравнению с трудностями для пользовательских почтовых программ.
ЗАМЕЧАНИЕ ПО ПЕРЕВОДУ КОДОВ: Конверторы quoted-printable и base64 разработаны так, что данные после их применения легко взаимоконвертируемы. Единственный нюанс, возникающий в подобной ретрансляции - признак конца строки. При конвертации из quoted-printable в base64 перевод строки должен быть заменен последовательностью CRLF. Соответственно и наоборот, но ТОЛЬКО при конвертации текстовых данных.
Поле заголовка "Content-Type"
Назначение этого поля - наиболее полное описание данных, содержащихся в теле, с тем, чтобы почтовый агент (программа) получателя могла выбрать соответствующий механизм для их обаботки. Впервые это поле было определено в RFC 1049, но имело более простой синтаксис.
Данное поле включает в себя идентификаторы типа и подтипа, а также может содержать некоторую вспомогательную информацию, которая может потребоваться для конкретного типа данных. После идентификаторов типа и подтипа оставшаяся часть поля - просто набор парамеров, заданных в порядке "атрибут/значение". Набор параметров зависит от типа данных. (В частности, не может быть глобально-значимых параметров, справедливых сразу для всех типов содержимого ьела письма. Глобальные механизмы в MIME-модели реализованы с помощью введения дополнительных полей "Content-*"). Очередность параметров значения не имеет. В числе определенных параметров - "charset", декларирующий символьный набор (кодировку, кодовую страницу - это все синонимы) тела письма. Комментарии допускаются.
Вообще, поле Content-Type самого верхнего уровня используется для объявления общего типа данных, в то время как подтип определяет специальный формат для данных этого типа. Так, значение "image/xyz" поля Content-Type сообщает пользовательской программе, что данные являются графическим изображением (image), даже если эта почтовая программа не имеет понятия о специальном формате "xyz" этой картинки. Но эта информация может быть использована программой, например, чтобы решить, показывать ли пользователю строкоые данные неизвестного подтипа -- показ таких данных может быть оправдан для незнакомых подтипов текста, но не для незнакомых подтипов графики, аудио или видео. По этой причине, данные зарегистрированного подтипа аудио, графики, текста или видео не должны содержать внутри себя части другого подтипа - для содержания в письме данных одного типа, но разных подтипов следует использовать тип "multipart" или "application".
Хотя многие параметры ( модификаторы подтипов) имеют смысл лишь для конкретного типа, некоторые все же являются глобальными в том смысле. что они применимы ко всем типам (например, параметр "boundary" применим только с типом "multipart", а параметр "charset" может использоваться с несколькими типами).
Пока имен типов только семь, и пока этого достаточно. Кроме того, предполагается, что расширение существующего набора поддерживаемых типов данных будет производиться засчет введения новых подтипов этих изначально определенных типов данных. В будущем добавление имен типов верхнего уровня может быть произведено только при принятии новой версии стандарта MIME. Если по какой-либо другой причине в существующей версии используется незарегестрированный тип содежимого, ему должно быть дано имя, начинающееся с "X-", чтобы подчеркнуть его нестандартный статус и заранее предупредить конфликт с официальным именем типа, которое может быть введено позднее.
Правильное заполнение поля Content-Type: содержимое := "Content-Type" ":" тип "/" подтип *(";" параметр) ; нечувствительное к регистру букв задание типа и подтипа тип := "application" / "audio" / "image" / "message" / "multipart" / "text" / "video" / признак нестандартного типа ; Все значения нечувствительны к регистру букв признак нестандартного типа := x- / iana- iana- := <общепринятый признак расширения, зарегистрированный соответ- ственно приложению "E" RFC 1521> x- := <Два последовательных символа "X-" или "x-", без пробела или другого символа между ними> подтип := слово ; регистр безразличен параметр := атрибут "=" значение атрибут := слово ; регистр безразличен значение := слово / строка в кавычках слово := любые ASCII-символы кроме пробелов, Ctrl-последова- тельностей и специальных символов Специальные символы:= "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> / "/" / "[" / "]" / "?" / "=" ; Эти символы используются в строке значений параметров
Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов "/", "?", "=" и отсутствием символа ".".
Указание подтипа в данном поле является обязательным, т.к. нет подтипов по умолчанию. В отличие от имен типов, подтипов и параметров, значения параметров в общем случае являются чувствительными к регистру букв, но могут быть и нечувствительными - в зависимости от параметра. Например, значения границ multipart-письма являются чувствительными, а значение "access-type" для message/External-body не является.
Существует два приемлимых механизма для введения новых подтипов для поля Content-Type:
Нестандартные значения (начинающиеся с "X-") могут быть опредлены по договоренности для двух или более общающихся друг с другом почтовых агентов (программ) без какой-либо внешней регистрации и стандартизации.
Новые стандартные значения подтипов должны быть документированы, зарегистрированы и опробованы в IANA, как описано в приложении "E" RFC 1521. Если новй подтип предлагается для широкого использования, формат, описываемый им, должен быть описан в опубликованной спецификации и, возможно, предложен к стандартизации.
Семь предопределенных типов верхнего уровня, более детально, представляют собой следующее:
text -- текстовая информация. Основой подтип - "plain" - соответствует обычному неформатировнному тексту и не требует специального программного обеспечения для отображения этого текста за исключением поддержки национальных кодировок. Другие подтипы используются в случае размеченного текста, когда с помощью специальной программы можно улучшить его визуалзацию, но для понимания идеи содержания можно обойтись и без дполнительного ПО. Возможные подтипы могут описывать легкочитаемые форматы различных текстовых процессоров.
multipart -- содержимое письма состоит из некоторого множества частей, содержащих данные различных взаимонезависимых типов. Изначально определено четыре подтипа:
"mixed" - основной;
"alternative" - для представления одних и тех же данных в разных форматах;
"parallel" - если разные части документа должны просматриваться одновременно;
"digest" - если каждая из частей тела письма имеет тип "message".
message -- письмо в письме. Тело, содержащее данные типа "message", само является письмом или частью письма, полностью отформатированного в соответствии со стандартом RFC 822, которое, в свою очередь, может содержать свое собственное поле заголовка "Content-Type".
Подтипы:
"rfc822" - основной;
"partial" - определен для частично-цитируемых писем для предотвращения фрагментирования тел содержащихся писем в случае слишком большой их общей длины для возможностей почтового транспорта;
"External-body" - используется, чтобы указать, что тело письма очень большое и находится вне письма.
image -- графические данные. Графика требует соответствующего устройства вывода (графический дисплей, принтер, факс) для отображения своей информации. Изначально определены два подтипа для наиболее распространенных графических форматов - jpeg и gif.
audio -- звуковая информация. Требует звуковое устройство (динамик или наушники) для вывода информации. Основной подтип - "basic".
video -- видео. Требует специальных аппаратных и программных возможностей для отображения видео-информации. Единстванный изначально определенный подтип - "mpeg".
application -- как правило, неинтерпретируемый двоичный код либо информация, предназначенная для обработки почтовой программой.
Подтипы:
"octet-stream" - основной подтип; предназначен для неинтерпретируемых двоичных данных, для которых рекомендуемым действием является предложение пользователю сохранить в файл на диске.
"PostScript" - дополнительный подтип; применяется при пересылке PostScript-документов в теле письма.
По умолчанию, письма, как и в стандарте RFC 822 пишутся простым (неразмеченным) текстом в языковой кодировке US-ASCII, что по спецификации MIME может быть описано как "Content-type: text/plain; charset=us-ascii".
Это значение полагается, если поле Content-type не определено. Поэтому почтовая программа получателя может неверно истолковать содержимое письма, если при отправке не было указано поле Content-type, но на самом деле текст письма имеет другую кодировку или даже тип.
При отсутствии поля Content-type или поля MIME-Version в заголовке MIME-письма нельзя быть точно уверенным, что письмо имеет языковую кодировку именно US-ASCII, поскольку могут еще встречаться почтовые программы, не использующие соглашения MIME. Но хотя возможно, что письмо, не содержащее в заголовке полей MIME-Version и Content-Type, может содержать все, что угодно, например, юниксовский tar-архив, сжатый gzip'ом и обработаный uuencode, все же, создателям почтовых программ рекомендуется оставлять этот факт без внимания и ориентироваться на значение по умолчанию, т.е. "text/plain; charset=us-ascii".
Необходимо учесть, что в будущем ожидается заметное увеличение числа регистрированных типов и особенно подтипов содержимого писем. Если почтовая программа встретит неизвестное ей значение поля Content-type, она должна интерпретировать содержимое этого письма как "application/octet-stream" (см.выше).
Поле заголовка "MIME-Version"
Поскольку старый стандарт RFC 822 все еще используется, а MIME возможно, изменится и дополнится в будущем, почтовой программе необходимо знать, применен ли новый стандарт в конкретном письме или нет. Поэтому в заголовок ввелено новое поле "MIME-Version", объявляющее версию стандарта, в соответствии с которым написано данное письмо.
Все почтовые сообщения, составленные в соответствии с MIME-стандартом, должны иметь это поле в своем заголовке, напрмер: MIME-Version: 1.0
Так как возможно, в будущем формат заголовка письма может расшириться, формально содержание поля "MIME-version" дается следующим образом: версия := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
Т.о., будущие значения версии формата, коорые могут заменить "1.0", должны быть целыми числами, разделенными точкой. Если письмо получено со значением версии MIME, отличным от "1.0", оно не будет рассматриваться почтовой программой, как соответствующее данной спецификации.
Важно, что поле заголовка "MIME-Version", должно располагаться в самам начале письма. Это не обязательно для каждой из частей тела письма в случае многочастевого письма, но обязательно для заголовков частей типа "message", если и только если эта часть сама по себе декларирована как соответствующая спецификации MIME.
Не возможно полностью определить как почтовая программа, поддерживающая MIME, должна интерпретировать письмо, имеющее значение MIME-version, отличное от "1.0". Но, как минимум, почтовая программа должна предупредить пользователя о том, что письмо написано в незнакомом ей формате.
Все поля заголовка, включая MIME-Version, Content-type, и т.д., должны соответствовать общим синтаксическим правилам, определенным в RFC 822. В частности, допускается включение комментариев (т.е., следующие 2 примера эквивалентны): MIME-Version: 1.0 MIME-Version: 1.0 (Generated by GBD-killer 3.7)
Полоса новостей на php с использованием javascript и слоев.
Добрый день!
Решил написать статью о программировании на php на примере экспорта новостей с сайта . Но не в том виде, который они предлагают, а по-своему, компактно и интересно.
Такой пример вы можете увидеть на страницах сайтов http://www.czar.ru
или же http://www.russianjudo.ru.
Если вместо новостей пусто или сообщение об ошибке (зависит от настроек сервера), это значит, что сервер gazeta.ru сильно занят и не может обслужить всех желающих получить новости. Можно конечно брать новости и с других серверов, но так как мы рассматриваем реально работающий пример программирования, то будем работать с ним.
Как же создать такую новостную полосу? Все довольно просто. Заходим на сайт и находим пункт "экспорт новостей". . Там нам предлагают экспортировать на свой сайт новостную полосу с их ресурса.
Мы радуемся и регистрируемся. Все абсолютно бесплатно и, главное, стабильно. Например (реальная регистрация, можете зайти и проверить, а также, можете там изменять рубрики, получаемые нами в новостной полосе), ввели имя news_list, пароль qwer мейл - ваш (реально, в этом примере - мой), адрес сайта любой, например - citforum.ru. Затем понадобится только лишь имя и пароль.
Теперь заходим и смотрим, чтоже они нам предлагают. С удовольствием отмечаем довольно широкий спектр новостей.
Первая полоса Полоса политики Полоса бизнеса Полоса культуры Полоса спорта Автомобильные новости Бизнес новости Спортивные новости Новостная лента Полоса International News in English Полоса общества Полоса финансов Полоса автомобилей Новость часа Молния
Выбираем интересное и устанавливаем количество новостей в каждой рубрике.
Ниже выбираем кодировку новостей. Она должна совпадать с кодировкой вашего сайта. Например - win1251.
Затем выбираем вид новостей (с датой, с временем и без них). Проще выбрать пустую новость. Хотя программа будет работать в любом случае.
Верх и низ новостей оформлять не нужно.
Получаем строку, которую надо запомнить:
Из нее извлекаем полезное: Адрес cgi-скрипта, который и формирует наши новости на gazeta.ru. Этот адрес: http://www.gazeta.ru/cgi-bin/export/export.cgi?id=2743
Таким образом, мы имеем страницу, с которой нам надо изъять код ссылок на новости gazeta.ru к себе. Она имеет приблизительно такой вид:
var news=""; news+="текст1 "; news+="текст2 ";
Понимание WML
WML базируется на XML, языке разметки получившем невероятную поддержку благодаря своей способности описывать данные (HTML, кстати, используется для описания представления данных). HTML - предопределяет те тэги, которые могут быть использованы для описания страницы так, чтобы ее смог правильно понять и обработать броузер. XML, в свою очередь, позволяет создателю документа определять такой набор тэгов, которой он считает необходимым. Этот набор тэгов группируется затем в набор грамматических "правил", называемых по-другому Определение Типа Документа или проще DTD. Как уже упоминалось ранее, DTD, используемый для описания WML, расположен по адресу:
В телефоне или в любом другом коммуникационном устройстве, заявленном как WAP-совместимое, загружено специальное программное обеспечение (известное как микроброузер), которое полностью понимает, как обрабатывать все вариации WML 1.1 DTD.
Самая первая фраза внутри любого XML-документа называется пролог. Поскольку стандартен, он содержит две строчки кода: определение версии XML и DTD (указатель на файл, содержащий DTD)
Пролог выглядит следующим образом.
Следом за прологом, в каждом XML-документе содержится один единственный элемент, который содержит в себе остальные подэлементы и entities. Так же как и в HTML этими элементами являются угловые скобки: <> и >. Например: data . В документе должен содержаться только один элемент описывающий сам документ. В WML этим элементом является . Все остальные элементы содержатся уже внутри него.
Два самых распространенных способа хранения информации внутри XML-документа это элементы и их атрибуты. Элементы определяют структурную разметку внутри документа открытием и закрытием определенных тэгов. Элементы, в свою очередь могут содержать подэлементы. Атрибуты в основном используются для описания элементов. В качестве примера можно привести следующий кусочек кода:
Please select your user name.
В этом примере элемент card содержит атрибуты id и title. Комментарий в WML, также как и в HTML заключается между тэгами . В дальнейшем мы будем использовать элементы и их атрибуты для написания примеров.
Практикум
Теперь пора попробовать применить все эти теоретические сведения на практике. Давайте напишем для пробы небольшой HTML-файл, вызывающий один из органов управления ActiveX, разработанных фирмой Microsoft, - модуль для создания плавного перехода цветов (градиента). Заглянув в , мы узнаем соответствующий ему идентификатор CLSID и URL-адрес одной из его копий на сервере Microsoft, на которую можно будет сослаться. Кроме того, там же мы найдем список параметров и их значений, которые способен принимать этот орган управления, в частности:
StartColor и EndColor
Два цвета, плавный переход между которыми вы увидите на экране. Задаются в обычном для HTML виде "#rrggbb", где rr, gg и bb - шестнадцатеричные значения красной, зеленой и синей составляющих цвета.
Direction
Направление градиента: 0 - горизонтальное, 1 - вертикальное, 2 - радиальное от центра к краям, и т.д.
Теперь остается лишь заполнить атрибуты тега и предусмотреть нужное количество тегов . Вот как выглядит полный текст нашего HTML-файла:
Пример вызова органа управления ActiveX Этот градиент на вид не отличишь от обычного графического файла:
Открытие этого файла в броузере Internet Explorer приведет к довольно заметной паузе, во время которой в строке состояния будет видна надпись "Installing components..." В это время броузер связывается с сервером, указанным в атрибуте CODEBASE, и перекачивает с него файл, содержащий компонент ActiveX (перед проведением этого эксперимента нужно подключиться к сети).
Файл этот не слишком велик, но и не так чтобы очень мал - чуть больше 100 K (что, кстати, вполне можно принять за средний размер для не слишком сложных органов управления). То, что вы увидите на экране, когда инсталляция будет закончена, показано на рис. 2.
Рисунок 2. Пример вызова органа управления ActiveX
Конечно, для простого статичного градиента вполне можно было бы обойтись обычным gif-файлом, не прибегая к ActiveX. Главное преимущество органов управления - это их интерактивность и возможность динамически изменять их параметры. Давайте попробуем оживить наш градиент, а заодно попрактикуемся в организации взаимодействия между органами управления и сценариями.
Выделим на странице небольшую квадратную область и заполним ее градиентом типа "от центра к краям". Цвет краев выберем серым, а цвет центра будем динамически менять из черного в белый и обратно, создавая эффект "мигающей лампочки". Вызов градиента в этом примере запишем так:
>
(Градиент больших размеров, чем 25 на 25 пикселов, перерисовывается слишком долго.) Если вы выполнили предыдущий пример и теперь этот орган управления загружен и установлен на ваш компьютер, атрибут CODEBASE можно опустить.
Теперь нужно обеспечить периодический вызов функции, которая меняла бы одно из свойств нашего градиента - цвет центральной точки. Для этого воспользуемся еще одним органом управления под названием Timer.
Согласно документации, этот орган управления имеет два параметра: параметр Interval, который задает промежуток времени между срабатываниями таймера, и параметр Enabled, позволяющий включать и выключать работу таймера. "Срабатывание" же таймера заключается в инициировании связанного с ним события, которое так и называется - Timer. Как выражаются программисты, мы должны теперь "повесить" функцию переключения градиента на это событие. Сначала заведем объект-таймер:
Теперь остается написать фрагмент сценария, у которого в открывающем теге
Как видно из этого примера, свойство EndColor может задаваться и изменяться как с помощью тега при создании объекта, так и впоследствии из сценария. Метод Repaint (хоть он и не указан в документации) имеется у всех органов управления, которые хоть что-нибудь рисуют на экране.
Итак, периодическое изменение и перерисовку градиента (объект grad1) с частотой два раза в секунду обеспечивает таймер (объект timer1). Теперь наш градиент будет мигать до тех пор, пока мы не уйдем с этой страницы; на прорисовку остальных частей страницы, ее прокрутку и просмотр это практически не влияет.
Снимок окна броузера с этой страницей приведен на рис. 3.
Рисунок 3. Динамическое изменение параметров органа управления
Если вы - поклонник визуального дизайна Web-страниц и не очень-то любите возиться с тегами и атрибутами, Microsoft имеет предложить вам специальную программу под названием ActiveX Control Pad. В ней вы сможете строить свою страницу и размещать на ней органы управления, по большей части лишь щелкая мышью (чем-то это похоже на среду разработки программ в Visual Basic). К сожалению, сценарии вам все равно придется писать "вручную"...
Напоследок - еще кое-какие полезные сведения для тех, кто не прочь покопаться во внутренностях системы ActiveX. OCX-файлы с органами управления, полученные из сети, складываются броузером в подкаталог OCCACHE в каталоге Windows 95; судя по названию, этот подкаталог должен рассматриваться как хранилище кэшируемых данных, хотя кэш этот в Internet Explorer 3.0 является постоянным - информация в нем никогда не стирается.
Сведения об установленных органах управления хранятся в реестре Windows в разделе \HKEY_CLASSES_ROOT\CLSID. Данные о каждом органе управления вы найдете в подразделе, имя которого совпадает с идентификатором класса этого органа управления. Кстати, заглянув в реестр, вы увидите, что с помощью этого же механизма Windows хранит информацию о множестве других своих компонентов, большинство из которых не имеют никакого отношения ни к ActiveX, ни вообще к Интернету.
Правильные WML элементы.
В WML описывается набор элементов, которые можно комбинировать для создания WML-документа. Эти элементы можно условно разделить на две группы: Элементы типа Deck/Card и элементы обработки событий.
Элементы типа Deck/Card
wml card template head access meta
Элементы обработки событий
do ontimer onenterforward onenterbackward onpick onevent postfield
Задачи
go prev refresh noop
Представление данных для задач Web/DB
Создание систем для решения любой из указанных выше задач требует, чтобы мы выбрали какой-либо метод для моделирования ее предметной области. В частности, нам необходимо в этих задачах моделировать сам Web, структуру Web-сайтов, внутреннюю структуру страниц Web, и, наконец, содержание сайтов с более тонкой степенью гранулярности. В этом разделе мы обсудим главные факторы, характеризующие модели данных, используемые в приложениях Web.
Графовые модели данных: Как отмечалось выше, для некоторых из обсуждаемых здесь приложений необходимо моделировать множество страниц Web, а также связи между ними. Эти страницы могут полностью находится на нескольких сайтах либо на единственном сайте. Следовательно, естественный способ моделирования этих данных основан на модели данных помеченных графов. В этой модели узлы представляют страницы Web (или внутренние компоненты страниц), а дуги - связи между страницами. Метки на дугах могут рассматриваться как имена атрибутов. Наряду с моделью помеченных графов было разработано несколько языков запросов. Одной из центральных возможностей, общей для этих языков является способность формулировать над заданным графом запросы, основанные на правильных выражениях путей (regular path expression). Правильные выражения путей дают возможность формулировать навигационные запросы над структурой этого графа.
Модели слабоструктурированных данных: Второй аспект моделирования данных для приложений Web заключается в том, что во многих случаях структура этих данных не является постоянной. При моделировании структуры Web-сайта мы не имеем какой-либо фиксированной схемы, которая была бы задана заранее. В случае моделирования данных, поступающих из множества источников, представления некоторых атрибутов (например, адресов) могут различаться для разных источников. Поэтому в некоторых проектах исследовались модели слабоструктурированных данных. Первоначальными стимулирующими причинами этой работы послужили существование и относительный успех в научном сообществе "разрешающих" (permissive) моделей данных, подобных [TMD92], необходимость обмена объектами между неоднородными источниками [PGMW95], а также задачи управления коллекциями документов [MP96].
Вообще говоря, слабоструктурированными называются данные, обладающие какими-либо из следующих характеристик:
Схема не задана заранее и может неявно содержаться в данных,
Схема сравнительно велика (в смысле объема данных) и может часто изменяться,
Схема является описательной, а не предписывающей, т.е., она описывает текущее состояние данных, но нарушения этой схемы все же допускаются,
Данные не являются строго типизированными, т.е., для различных объектов значения одного и того же атрибута могут иметь различные типы.
Модели слабоструктурированных данных были основаны на помеченных ориентированных графах [Abi97, Bun97]2. В модели слабоструктурированных данных не налагается какого-либо ограничения на множество дуг, которые исходят от данного узла в графе, или на типы значений атрибутов. В связи с упомянутыми выше характеристиками слабоструктурированных данных становится важной в этом контексте дополнительная возможность - запрашивать схему (т.е., метки дуг в графе). Эта возможность обеспечивается в языках запросов для слабоструктурированных данных благодаря переменным-дугам, которые связаны с метками дуг, но не с узлами графа.
Помимо разработки моделей и языков запросов для слабоструктурированных данных, нужно упомянуть также и недавно опубликованные довольно важные работы, посвященные некоторым вопросам управления слабоструктурированными данными, в частности, реконструкции структуры слабоструктурированных данных [NAM98], поддержке представлений [ZGM98, AMR+98], агрегированию (summarization) слабоструктурированных данных ([BDFS97, GW97]), а также рассуждениям относительно слабоструктурированных данных [CGL98, FFLS98]. Независимо от релевантности этих работ задачам, которые рассматриваются в этом обзоре, системы, основанные на предложенных в них методах, будут иметь особенно важное значение для управления большими объемами XML-данных [XML98].
Другие характеристики моделей данных Web: Другая отличительная черта моделей, используемых в приложениях Web/DB - присутствие специфических для Web конструкций в представлении данных.
Например, в некоторых моделях различаются унарное отношение, идентифицирующее страницы, и бинарное отношение для связей между страницами. Кроме того, мы можем различать связи внутри Web-сайта и внешние связи. Важная причина отличать отношение связей состоит в том, что они, вообще говоря, могут обходиться только в прямом направлении. К свойствам второго порядка, которыми различаются обсуждаемые здесь модели данных, можно отнести: (1) способность моделирования некоторого порядка на множестве элементов в базе данных, (2) моделирование вложенных структур данных и (3) поддержка типов коллекций (множества, мультимножества, массивы). Примером модели данных, которая включает явным образом специфические для Web конструкции (страницы и схемы страниц), вложенность и типы коллекций, является ADM - модель данных в проекте ARANEUS [AMM97b]. Следует отметить, что все модели, которые мы упоминаем в этой статье, позволяют представлять только статические структуры. Так, например, в работах по моделированию структуры Web-сайта не рассматриваются динамические страницы Web, созданные в результате ввода данных пользователем.
Важный аспект языков запросов данных в приложениях Web - необходимость генерировать сложные структуры в результате обработки запроса. Например, результат некоторого запроса в системе управления Web-сайтом может представлять собой граф, моделирующий этот Web-сайт. Следовательно, фундаментальная характеристика многих из языков, которые мы обсуждаем в этой статье, состоит в том, что их выражения запросов содержат компонент структурирования наряду с традиционным компонентом фильтрации данных.
В Таблице 1 представлена сводка некоторых систем запросов для Web, рассматриваемых в этой работе. Более подробную версию этой таблицы, содержащую URL сайтов с доступными описаниями этих систем, можно найти в: . В последующих разделах нашего обзора мы подробно проиллюстрируем возможности языков запросов для Web, основанных на этих моделях.
Преимущества Tamino
Высокая производительность
Tamino является быстродействующим, надежным и масштабируемым информационным сервером. Поскольку Tamino ориентирован на хранение XML-документов в их оригинальном виде, он легко превзойдет реляционные СУБД и объектно-ориентированные СУБД, оснащенные XML-преобразователем. Tamino может работать на широком диапазоне программно-технических средств, начиная от Windows NT, Unix, вплоть до OS/390, предоставляя возможность достаточно гибкого управления пропускной способностью серверов Интернет.
Полнотекстовая поисковая машина
Реализованные в ядре Tamino средства полнотекстовой поисковой машины позволяют легко создавать интеллектуальные поисковые машины, обеспечивающие поиск с учетом структуры документа.
Минимизация затрат на обслуживание
Tamino построен на концепции "нулевого администрирования". С помощью диспетчера Tamino пользователь может с одного рабочего места обозревать всю систему, включая внешние источники данных, доступные через X-Node. При этом, рабочее место администратора Tamino может находиться в среде Интернет и быть доступно с помощью любого соединения, поддерживаемого протоколом HTTP.
Встроенные средства разграничения доступа
Tamino поддерживает достаточно гибкую концепцию разграничения доступа на разных уровнях системы, например, на уровне транспорта и прикладной системы, как в среде Интранет, так и Экстранет. Tamino поддерживает интерфейсы к стандартным промышленным системам разграничения доступа, а также методы проверки аутентичности пользователя и шифрации данных, применяемые в RACF, NTLM, Kerberos и др.
Управление транзакциями
Протокол HTTP не обеспечивает хранение состояния сеанса, что приводит к потере Интернет-сервером содержания HTML-страницы после ее передачи клиенту. Вместе с тем, Tamino ориентирован на выполнение бизнес-приложений, требующих надежного выполнения транзакций в среде Интернет. Tamino поддерживает механизм выполнения классических транзакций, удовлетворяющих требованиям ACID (Atomic, Consistent, Isolated, Durable) на уровне объектов.
Tamino поддерживает механизм блокировки доступа к изменяемым данным на уровне объекта. Блокировка доступа устанавливается в начале транзации и снимается при выполнении команд End Transaction или Backout Transaction. В сочетании с Bolero - фабрикой приложений для электронного бизнеса, Tamino поддерживает не только классические транзакции, но и так называемые "длинные транзакции", охватывающие сложные бизнес-процессы.
Ведение журналов
Tamino поддерживает ведение журналов на уровне операций с базой данных и на уровне внутренних событий исполнительной системы.
Интеграция информационных технологий
Tamino может играть роль интегратора информационных технологий. С помощью компонентов Data Map, X-Node и X-port Tamino позволяет не трогать существующие базы данных, делая их доступными Интернет и приложениям бизнес-бизнес.
Tamino и Adabas
С помощью компонента Tamino Data Map и X-Node можно легко обеспечить доступ к данным СУБД Adabas. При этом, логическая структрура файла интерпретируется как соответствующая структура XML, запись файла - как конкретный экземпляр XML-документа.
Tamino и EntireX
С помощью EntireX можно взаимодействовать с существующими программными системами, такими как SAP, PeopleSoft, Baan, по протоколу DCOM. Поскольку Tamino имеет доступ к объектам DCOM, появляется возможность интеграции существующего программного обеспечения с новыми приложениями XML.
Tamino и Natural
С помощью Natural можно получать доступ как к объектам XML, так и к SQL-данным, хранящимся в Tamino. В свою очередь, Tamino может взаимодействовать с объектами Natural с помощью комбинации продуктов EntireX и NaturalX.
Tamino и Bolero
Bolero - фабрика приложений для электронного бизнеса, работает в среде Java Virtual Machine (JVM). Вследствие этого, приложения Bolero могут выполняться на любой платформе, имеющей сертифицированную JVM.
Приложения Bolero могут осуществлять доступ к объектам Tamino непосредственно с помощью URL, выполняя операции чтения, создания и изменения объектов XML с использованием интерфейса DOM.
Bolero поддерживает Unicode, что соответствует стандарту XML. Все это вместе делает Tamino и Bolero идеальной парой для разработки приложений электронного бизнеса.
Данная уникальная комбинация позволяет Tamino:
Хранить любые типы объектов Интернет, такие как страницы XML или HTML. Реализовать концепцию безопасного выполнения транзакций бизнес-приложений в среде Интернет. Обеспечить пользователя средствами эффективного и избирательного поиска и отображения комплексных информационных объектов и структурированных данных. Хранить любые типы документов стандартных приложений, такие как письма, факсы, электронные таблицы. Хранить любые типы сложных информационных объектов, таких как мультимедиа или биометрические данные. Хранить традиционные данные, представленные в реляционной структуре, такие как тексты и числа. Обеспечить доступ к существующей информации, хранящейся во внешних базах данных, таких как Adabas или РСУБД.
Платформы
В настоящее время информационный сервер Tamino выпускается на платформе Windows NT. В течение следующего года предполагается выпуск продукта на платформах Unix, включая Sun Solaris, AIX, Linux и др., а также OS/390.
Требования к программно-технической платформе:
ПК: INTEL PentiumT II Processor от 300 Мгц; HDD: > 150 MB (NTFS); RAM: 128 MB; Windows NT 4.0 SP5; Microsoft IIS 3 и выше; или Apache WS 1.3.3, 1.3.4, 1.3.6 или 1.3.9; или IBM HTTP Server 1.3.6 и выше.
Лицензирование
Стоимость лицензии Tamino зависит только от числа процессоров, на которых функционирует система, а также от числа дополнительных интегрируемых продуктом СУБД.
Преимущества технологии Curl.
Curl Corporation разработала технологию, предоставляющую новые и важные преимущества как для конечных пользователей, так и для разработчиков и провайдеров содержания Web ресурсов.
Предоставляя конечному пользователю более богатый интерфейс, интерактивную и улучшенную скорость передачи информации, технология Curl безусловно обогатит опыт пользователя в сети. С помощью программной платформы Surge, которая включает в себя и plug-in модуль, на своем компьютере пользователь сможет работать гораздо быстрее и эффективнее с помощью использования содержимого Web страниц написанных на Curl. Не рабочие задачи, такие как сбор и поиск информации или игры, станут приносить гораздо больше удовольствия. Что же касается электронной коммерции, то пользователь откроет для себя более динамичный процесс совершения покупок, быстрый и безопасный расчет. Все эти преимущества пользователь получает без всяких дополнительных устройств или ОС, но исключительно с помощью среды Surge и ее компонентов.
Технология Curl освобождает разработчиков от компромиссных решений для содержания и скорости отклика Web-страниц и приложений, а также значительно снижают усилия, стоимость и время требуемое на разработку и поддержку содержания Web-страниц. Используя Surge Lab IDE, разработчики смогут создавать Web-проекты, качество представления содержимого которых будет равняться скорости их загрузки. Они смогут создавать проекты, используя преимущества работы в общей, унифицированной среде разработки, которая может сочетать в себе функциональность HTML с функциональностью скриптов и концепциями ООП.
Технология Curl выдвинет провайдеров содержимого Web на новый уровень доставки содержимого к конечному пользователю, удовлетворяя потребности последнего к наиболее быстрому, лучшему и дешевому доступу в Internet. В мире технологии Curl провайдеры смогут предложить пользователю новые высоты интерактивностии объема содержимого, т.к. содержимое Web созданное с ее помощью является более компактным по отношению к уже существующим технологиям.
Современный Web приложения созданы, как правило, на технологиях, тяжелых для понимания, которые делают процесс создания таких приложений более сложным, чем он мог бы быть. Поскольку интерактивные компоненты Web приложений могут вести себя по разному не только в зависимости от ОС, но и в зависимости от конкретного броузера, разработчикам в большинстве случаев приходится проводить все операции на сервере и формировать исходный результат как HTML документ для броузера, что ведет к появлению следующих проблем:
Низкий отклик - для динамического обновления любой новой информации Web сервер должен переслать, а броузер перерисовать заново весь документ, а не только обновленную или новую информацию. Отсутствие гибкости - информация передается от сервера к клиенту. HTML вынуждает объединять при передаче информацию и ее визуальное представление, тем самым увеличивая объем пересылаемой информации.
Технология Curl позволяет решить эти проблемы с помощью компактного, самоописывающегося языка программирования, использующего вычисления на стороне конечного пользователя:
Интеграция программного кода и данных - как и любая программа, Web приложение состоит из программной части и некоего набора данных. HTML технология позволяет только представлять, отображать информацию, но не расчитывать ее или формировать. Технология Curl позволяет не чуствовать разницы между программой и интерактивным документом. Одна общая среда разработки - технология Curl является в равной степени форматом представления информации, таким, как HTML, и языком программирования с элементами ООП, таким как Java, Visual Basic, C++. Дизайнер или программист, использующий Curl, может объединять информацию по форматированию и расположению инфомации и объектно-ориентированный интерфейс в одном общем формате, без труда интерпретируемым с помощью среды Surge. Причем интерактивность и вычисления будут выполняться на клиентском ПК. Маленький размер - при использовании технологии Curl, информация, посланная на ПК пользователя, сразу содержит код, который "знает" как интерпретировать данные.Таким образом количество передаваемой информации будет меньшим, чем при использовании традиционных технологий.
Преобразование Бизнес Модель в Модель сообщений
UML Модель сообщений специфицирована как тип сообщения и состоит из: классов сообщений, атрибутов и соответствий (ассоциаций). Эти термы формально определены в UML и представляют класс сообщений, который является подкласс формального класса UML. Эти термы используют различные формы обычного UML класса, т.к. сообщение может состоять из атрибутов форм одного или более классов.
Правило 1. Классы сообщений должны быть структурно иерархически взаимосвязаны. Корневой класс всегда должен быть определен. Создавая корневой класс предпочтительно ему дать имя БМ сообщения, например при моделировании EDIFACT сообщения CusDec (таможенная декларация), классу предпочтительно дать имя CustomDeclaration. Ниже изображен формальный UML класс - CustomDeclaration
Секции и подсекции в БМ могут быть разделены на категории по:
простым секциям, т.е секция которая не категоризируется по списку ролей и списку значений; списку ролей - т.е секции содержат данные, являющимися именами ролей; списку значений - т.е секции содержат данные термов специальных кодов значений.
Ниже приведен пример создания корневой секции сообщения CusDec. В таблице приняты следующие сокращения:
O = Optional / Необязательный DE = элемент данных справочника UN/EDIFACT
R = Requred / Обязательный CL = значение из списка кодов справочника
D = Dependent / Зависимый
Секция А - Message Information (информация о сообщении)
Наименование терма, ссылка на Элемент данных O/R/D Значение клалификатора, примечание Элемент данных клалификатор А 1 идентификация документа  
A1-1 Document type coded R "914" = Customs declaration CL 1001 - 335
A1-2 Document issue date R CL 2005 - 137
A1-3 Customs procedure R 1 - export, 2 -import CL 8323
A1-4 Customs Declaration number R CL 3035 - CM
A1-5 Carrier booking number D Primary key, if not CU CL 1153 - BN
A1-6 Invoice reference number D CL 1101- 935
A1-7 Consignor reference number D Primary key, If not BN CL 1153 - CU
A1-8 Reference to previous message D CL 1153 - ACW
A1-9 Message sender O For return purposes CL 3035 - MS
A1-10 Message receiver O For on-distribution CL 3035 - MR
A2 функции сообщения DE 1225
A2-1 Original D CL 1225 - 9
A2-2 Replace D CL 1225 - 5
A2-3 Cancellation D CL 1225 - 1
A3 идентификация Edifact
A3-1 Message type O Fixed "CUSDEC" DE 0065
A3-2 Message type version O Fixed " D" DE 0052
A3-3 Message type release O Fixed "98A" DE 0054
A3-4 Controlling agency O Fixed "UN" DE 0051
A3-5 MIG identity O Fixed "SE0023" DE 0057
A3-6 Message reference number O DE 0062
Таблица 2
Аналогичным образом строятся остальные секции БМ.
Правило 2. Создать класс сообщений для каждой необязательной секции. Имя класса сообщений должно быть эквивалентно имени секции.
Секция категорий списка ролей будет формироваться не из класса сообщений, но имя роли будет позже использоваться при создании соответствий (ассоциаций).
Секция категорий списка значений должна формироваться не из класса сообщений, но позже она будет использоваться для создания атрибутов. При моделировании проще выбрать класс, если класс сообщений будет иметь один атрибут.
Правило 3 (необязательное) . Секция может быть перенесена, при соблюдении следующих условий:
максимальное кол-во соответствий = 1 (не повторяющихся), и существует только одна родительская ассоциация.
Перенос между секциями мог бы осуществляться в виде иерархических уровней, или дочерняя секция переносилась бы с ее родительской секцией.
Правило 4 . Создание единственной ассоциации (соответствия).
Единственное соответствие создается из сообщения родительского класса к дочернему классу сообщения при отсутствии множественной ссылочности.
"Соответствие" в сообщение имеет только одно направление - от родительского класса к дочернему. Возможно представления множественных соответствий. Множественные соответствия записываются как Min..Max Например по одной таможенной декларации возможно провести от одного до : (десяти) контейнеров. В этом случае соответствия представится как 0..9. Множественность должна описываться в конце дочерней секции.
Правило 5 . Создание множественного соответствия.
Множественные соответствия создаются для класса сообщений, включающие подсекции категории списка ролей.
Каждое множественное соответствие дает свое имя роли. Имя роли определяется как имя терма данных в подсекции категории списка ролей. Каждое имя роли будет заменено дочерним именем класса, сгенерированным в XML/DTD или схемы XML. Использование нотации UML "+" показывает, что имя роли имеет атрибут "public".
На рисунке ниже изображено альтернативное изображение UML модели.
Данная техника моделирования может быть использована в основной модели при моделировании ролей. Однако она не может быть использована при моделировании самого сообщения, т.к. наследование увеличивает комплексный уровень генерации описаний тагов XML.
Данные термов в секции могут быть категоризированны как: необязательный терм данных, имя роли и значение кода (см таблицу 2). Возращаясь к примеру в таблице 2 значение терма (терм кодов) A1-3 (Customs procedure ) в справочнике кодов 8323 имеет значение 1- export и 2- import, значение CU для роли A1-7 (Consignor reference number ) по справочнику кодов 1153 , а значение для данных A1-2 (Document issue date ) является датой принятия документа (например 12/12/2000).
Правило 5 . Создание атрибутов для термов данных и кодов значений.
Атрибут создается для каждого необязательного терма данных и располагается в классе сообщения, соответствующего атрибуту секции. Секция, состоящая из кодов значений, должна быть преобразована в один атрибут, который всегда имеет значение соответствующее списку кодов. Ниже приведен пример для секции A3 "Идентификация EDIFACT сообщения"
Когда атрибуты созданы, количество свойств может быть определено на информации из БМ. :
тип данных; множественность; допустимые значения; бизнес правила; комментарии стандартные ссылки.
Тип данных используется в создании XML схемы и может иметь допустимые значения соответствующие определению схемы XML.
Множественность - используется в создании XML/DTD или схемы XML. Допускаются следующие два значения:
0..1 - для необязательных (optional) атрибутов
1..1 - для обязательных (mandatory) атрибутов
Допустимые значения используют определение одного или более допустимых значений кодов атрибутов. Например:
Таможенный режим TypeDeclaration - 1 "export" , 2 "import" Вид перевозки EquipmentType - CN - контейнер, PL - паллеты;
Эти значения всегда используются при создании XML/DTD или схемы XML.
Бизнес правила могут быть определены для более сложных зависимостей в БМ. Хотя бизнес правила не используются при создании XML/DTD или XML схемы.
Комментарии о терме данных в БМ могут быть скопированы как комментарии атрибутов. Оны будут использованы для документирования.
Стандартные ссылки представляют уникальный идентификатор какточеку определения стандартного атрибута т.е. номер тага элемента данных UN/EDIFACT. Они могут быть использованы для документирования, а также и при создании XML/DTD и схемы XML как альтернативных атрибут имени.
Ниже на рис. 4 приведена диаграма классов UML бизнес модели сообщения CusDec:
Рис. 4
При автоматической генерации из БМ в XML/DTD или XML схема используется формальный алгоритм преобразования. Правила преобразования UML модели в XML/DTD или схеме XML осуществляюстя в соответсвии следующими правилами:
Модель сообщения XML/DTD XML Sсhema
Имя класса корневого сообщения Имя корневого элемента Имя типа корневого элемента
Имя роли Имя элемента Имя типа элемента
Множественное соответствие ?, *, +, (empty) Соответствие min и max
Имя атрибута Имя элемента Имя типа элемента
Тип данных атрибута - Тип данных или макс. длинна
Атрибут множественности ?, (empty) Соответствие min и max
Значение атрибутов допустимый список значений Допустимый список значений
При создании XML/DTD или схемы XML БМ специфицируется последовательно по секциям, начиная с корневой, и далее с подсекции и термов данных и должны быть сохранены в модели сообщения. Соответствия и атрибуты должны быть смоделированы в некоторой последовательности. Это возможно только для атрибутов, исключая соответствия. Ниже приведен пример XML/DTD, полученный в результате моделирования секции сообщения Customs.
Поста Address?)> ; адрес поста ; "destination", "departure","border" ; примечание ; почтовый индекс
Проблема кнопки "Back" и проблема кнопки "Refresh"
Филипп Зуев, Ирина Пономарева, Владимир Якименко
Во всех современных браузерах есть кнопка "Back", которая позволяет пользователю повторно просмотреть те страницы, которые он уже видел раньше.
Также существует кнопка "Refresh", которая позволяет "обновить" страницу, которую пользователь просматривает.
Эти две кнопки предназначены для удобства пользователя, но иногда после нажатия на одну из них пользователь вместо страницы, которую он ожидал, видит совсем другую.
Эта статья была написана для того, чтобы объяснить, почему это происходит и как этого избежать.
Страницы бывают двух видов: статические и динамические (последние еще иногда называют скриптами). Статическая страница всегда выглядит для пользователя одинаково. Динамическая страница, как правило, выглядит по-разному в зависимости от того, какие данные были переданы от браузера серверу. Мы поговорим о том, как эти данные передаются, когда будем рассказывать об отличии методов GET и POST.
Каждый раз, когда браузер запрашивает с сервера новую страницу, он передает серверу информацию, которая необходима, чтобы найти или создать эту страницу. Эта информация обязательно содержит:
адрес страницы (который ещё называют Universal Resource Locator - URL), зарезервированное слово HTTP-протокола (GET или POST), которое сообщает серверу, что именно пользователь браузера хочет сделать со страницей. Дело в том, что некоторые браузеры позволяют своим пользователям не только просматривать страницы с сервера, но и заменять их другими страницами по своему усмотрению или даже удалять. Разумеется, сервер не каждому пользователю позволит изменять или удалять страницы. Это зарезервированное слово называется "метод" или "метод протокола http". Методы GET и POST используются для получения страницы с сервера, при этом они могут посылать серверу дополнительные данные, которые сервер может использовать для формирования страницы. Метод GET показывает эти данные в адресной строке браузера.
Проверка корректности
Процесс проверки корректности по схеме определен в [3]. Она может выполняться применительно к документу XML или к части документа, например, отдельному элементу.
В запросной модели данных с каждым узлом-элементом ассоциируется аннотация типа. Аннотация типа свидетельствует о том, что данный элемент прошел проверку на соответствие определенному заявленному типу. Элементы, которые не прошли проверку или не соответствуют заявленному типу, получают аннотацию родового типа anyType . Например, элемент, создаваемый конструктором элементов, имеет аннотацию anyType до тех пор, пока не получит более конкретный тип с помощью выражения validate . Ниже конструируется элемент и проверяется в соответствии со схемой (схемами), которые указываются в прологе запроса. validate { 123 Elm St. Elko, NV 85039 }
Аннотация типа используется в выражениях, проверяющих тип элемента, таких как instance of и typeswitch, и в выражениях, требующих элемента конкретного типа, таких как вызовы функций. Так, проверка элемента shipto может присвоить ему аннотацию типа USAddress, которая может позволить использовать его в качестве аргумента вызова функции, типом параметра которой является element of type USAddress.
ПРОВОЗГЛАШЕНИЕ СТРУКТУРЫ ДОКУМЕНТА
Хорошо, хорошо, я признаю: переходя к использованию XML в качестве промежуточного программного обеспечения, я пропустил один важный шаг. Если теги и элементы XML используются исключительно ради удобства на вашем собственном узле Web (как если бы вы использовали CSS), то не имеет никакого значения, что вы даете этим элементам и тегам имена, смысл которых отличается от стандартного и известен только вам. Если же, с другой стороны, вы хотите предоставлять данные внешнему миру и получать информацию от партнеров по бизнесу, то это обстоятельство приобретает огромное значение. Элементы и атрибуты должны употребляться вами точно так же, как и всеми остальными людьми, или по крайней мере вы должны документировать то, что делаете. Для этого вам придется использовать определения типов документов (Document Type Definition, DTD). Хранимые в начале файла XML или внешним образом в виде файла *.DTD, эти определения описывают информационную структуру документа. DTD перечисляют возможные имена элементов, определяют имеющиеся атрибуты для каждого типа элементов и описывают сочетаемость одних элементов с другими. Каждая строка в определении типа документа может содержать декларацию типа элемента, именовать элемент и определять тип данных, которые элемент может содержать. Она имеет следующий вид
Например, декларация определяет элемент с именем publication, содержащий символьные данные (т. е. текст). Декларация определяет элемент с именем special_report, содержащий подэлементы article_1, article_2 и article_3 в указанном порядке, например:
XML: время пришло XML превосходит самое себя Управление сетями и системами с помощью XML
После определения элементов DTD могут также определять атрибуты с помощью команды !ATTLIST. Она указывает элемент, именует связанный с ним атрибут и затем описывает его допустимые значения.
Например, следующая команда устанавливает соответствие между атрибутом manufacturer и элементом car, причем первый из них может принимать одно из указанных значений:
!ATTLIST позволяет управлять атрибутами и многими другими способами: задавать значения по умолчанию, подавлять пробелы и т. д. DTD могут также содержать декларации !ENTITY, где определяются ссылки на объекты, а также декларации !NOTATION, указывающие, что делать с двоичными файлами не в формате XML.
Серьезное и несколько удивительное ограничение DTD состоит в том, что они не допускают типизации данных, т. е. ограничивают данные конкретным форматом (таким, как дата, целое число или число с плавающей точкой). Как вы, вероятно, уже заметили, DTD используют иной синтаксис, нежели XML, и не очень-то интуитивно понятны. По названным причинам DTD будут, видимо, заменены на более мощные и простые в использовании схемы XML, работа над которыми ведется в настоящее время. Дополнительную информацию о схемах XML можно почерпнуть из рабочего проекта, ссылка на который приведена в Таблице, и из врезки «Что в имени твоем?».
Возможно, вам приходилось слышать определения «правильно составленный» (well-formed) и «действительный» (valid) применительно к документам XML. Документ является правильно составленным, если для каждого открывающего тега имеется соответствующий закрывающий тег, а накладывающиеся теги отсутствуют. (Таким образом, большая часть документов HTML составлена неправильно.) Документ является действительным, если он содержит DTD и соответствует его правилам.
Распространение информации среди пользователей BI-инструментов
Подготовлено: по материалам зарубежных сайтов Перевод: Авторские права:
Разбиение отчетов
Разбиение отчетов автоматизирует ручной процесс «проталкивания документов» («paper pushing»), в результате удается существенно сократить административные расходы и время обработки. Например, представим отчет, в котором содержится информация об отработанных и о пропущенных по болезни днях по каждому сотруднику. Страницы этого отчета можно автоматически разбить и направить в электронной форме каждому служащему, при этом будут сэкономлены многие и многие часы работы отдела кадров.
Разделить страницу на несколько частей
Вместо одной большой заготовки попробуйте разбить контент на несколько небольших страниц. Каждая страница будет быстро грузиться, и пользователь будет уютно ощущать себя на удобном сайте.
РАЗГОВОРЫ О BIZTALK
XML иногда описывается как система для самодокументирования данных. Мы не будем придумывать ничего нового и рассмотрим стандартный пример с элементами, составляющими информацию о книге:
Джон Милтон Потерянный рай
Если вы продемонстрируете эту формулировку во время презентации, то большинство присутствующих согласно закивают, соглашаясь, что имя автора действительно имеет смысл выделить в отдельный элемент данных и дать ему смысловой тег .
Но реальная жизнь намного сложнее, даже если вы ограничиваетесь достаточно предсказуемым понятием книги. Традиционно автором «Тома Сойера» считается Марк Твен, но реальный человек получал гонорары под именем Самуэль Клеменс. Должны ли вы создать другой тег для псевдонимов? Или же использовать тег с атрибутом nametype=pseudonym? Как различать разные издания? Будут ли данные об авторских правах описываться с помощью атрибутов тега или каждый их элемент будет иметь отдельный тег внутри элемента ? Если два книжных магазина реализуют свои собственные приложения и затем решат обмениваться данными из своих каталогов, то кто будет проверять правильность соответствия?
За исключением пары случаев, не имеющих отношения к бизнесу, Консорциум World Wide Web (W3C, ) четко обозначил свою позицию: он не собирается давать свое благословение каким бы то ни было приложениям XML (в терминологии XML «приложением» называется описание отраслевых терминов с помощью некоторого набора тегов XML, это не имеет никакого отношения к программным пакетам). Другими словами, конкретные вертикальные рынки должны самостоятельно согласовать внутри отрасли имена для своих объектов. Дабы способствовать открытости и предсказуемости при составлении схем XML в вертикальных отраслях, Microsoft выдвинула инициативу, названную BizTalk. По состоянию на август 1999 года эту инициативу поддержало свыше 25 компаний.
Разработка модели базы данных
Первым и наиболее важным действием при создании базы данных является разработка ее модели. Итак, приступаем.
Шаг 1
Нам нужно как-то назвать базу данных. Назовем ее db_website.
Шаг 2
Необходимо определить, что именно будут содержать таблицы базы данных. В БД могут входить сотни таблиц. Сначала нам потребуется всего одна таблица для хранения наших пресс-релизов. Назовем ее tbl_news_items.
Шаг 3
Следует определить поля, которые будет содержать наша таблица. Эти поля будут являть собой все элементы пресс-релиза. В нашем примере используются пять полей: col_id (числовой идентификатор пресс-релиза), col_title (название), col_date (дата публикации), col_fullstory (содержимое), col_author (имя автора). Поле col_id будет содержать уникальный идентификатор, по которому пользователь сможет запрашивать содержимое определенного пресс-релиза.
Развитие технологии составления документов
HTML предполагает, что документ состоит из стандартных элементов разметки, которые отображаются совершенно определенным образом. Набор элементов HTML - это типизация компонентов обычного печатного документа: заглавия, списки различных типов, параграфы, таблицы, цитирование и т.п. При этом все элементы разделены на два типа: строковые и блочные. К первым можно отнести параграф, список, таблицу. К строковым элементам - выделение курсивом или насыщенностью, текст гипертекстовых ссылок. Все это определено в Document Type Definition спецификации HTML, которая формально записана на SGML.
Жесткие правила отображения элементов на ранних стадиях становления Web-технологий позволяли обеспечить четкие и ясные требования к браузерам, а также возможность быстрого наполнения Web информацией. По мере увеличения количества информации и усложнения структуры набора документов Web-узлов простота технологии стала превращаться в недостаток. Приходилось копировать фрагменты кода, вводить новые элементы разметки для варьирования форматов изображения в зависимости от контекста, поддерживать все более сложные форматы графических файлов.
Следует также учитывать, что создание Web-узлов превратилось сегодня в отдельный вид профессиональной деятельности. При этом узел стал самостоятельным товаром, стоимость которого не должна превышать разумных пределов, определяемых его функциональным назначением (виртуальный магазин, информационная служба, ядро корпоративной системы и т.п.). Исходя из этого, сформировалось определенное понимание состава функций ПО Web-узла, типизации страниц Web-узла по их функциональному назначению, составу компонентов и методам обработки информации на страницах.
Первое, с чем столкнулись авторы и разработчики Web-узлов, - это необходимость повторения фрагментов кода на каждой странице, например логотипа компании или главного меню Web-узла. Для решения этой проблемы используется метод подстановок, заимствованный из программирования макроопределений. Так появились Server Site Includes (SSI).
Вставка внешнего файла в HTML-страницу - это самый простой способ применения SSI:
... ... -> ... -> ...
Строчки HTML-комментариев содержат директивы SSI. В первом случае указывается виртуальный путь в рамках дерева документов сервера. Во втором случае - путь относительно каталога, в котором размещен документ, куда осуществляется вставка.
Вставка в документ результатов исполнения программ открывает гораздо больше возможностей. Такие вставки тоже могут быть двух типов:
... ... -> ... -> ...
Конструкция дает возможность вставить в документ результат выполнения внешней программы, например, date (вставка текущей даты). Вариант позволяет вставить в документ результат выполнения cgi-сценария. Это очень мощное средство проектирования страниц узла, которое позволяет через механизм CGI принимать запросы от браузеров и генерировать страницы с учетом результатов выполнения этих запросов. Именно таким способом первоначально реализовывались системы поиска в базах данных, а позднее и системы поиска информации по ключевым словам.
Порядок обработки запроса от браузера на получение документа со вставками (Server Parsed Document) следующий:
подтвердить установку соединения и получить запрос от браузера;
убедиться в наличии разрешения на выполнение подстановок в данном каталоге;
начать поиск и интерпретацию директив SSI в документе, а также модификацию содержания страницы за счет подстановок;
сформировать отклик и отправить его браузеру.
Таким образом, сервер является интерпретатором языка SSI, т.е. в составе модулей сервера должен быть и модуль интерпретации SSI.
Вполне естественно, что идея SSI получила дальнейшее развитие, например, появилась возможность условной генерации вставки по условию.
Кроме того, были разработаны расширенные языки SSI. Наиболее известными продолжениями данного подхода с определенными оговорками можно считать пакет PHP, чрезвычайно популярный среди разработчиков узлов под управлением сервера Apache, а также механизм ASP, который был реализован в IISt. Но главную роль в развитии технологии программирования составных документов сыграл механизм LiveWare, впервые реализованный в 1995 году в серверах компании Netscape Communications. Благодаря SSI документ стал составным на стороне сервера. Но Web-технология имеет архитектуру клиент-сервер, поэтому необходимо было реализовать такие же возможности формирования документа и на стороне клиента.
Для большинства разработчиков Web программирование в рамках спецификации LiveWare связано с JavaScript. Этот простой объектно-ориентированный язык программирования на стороне браузера позволил "оживить" Web-страницы. Примечательно, что практически все учебники по JavaScript начинаются с описания элемента разметки SCRIPT. В этом легко усматривается традиция SSI. Дело в том, что JavaScript предполагает четыре способа размещения программного кода на HTML-странице и передачи управления интерпретатору для выполнения этого кода. Элемент разметки SCRIPT - только один из них. При этом методологически правильнее начать изучение языка с URL-схемы javascript, позволяющей программировать гипертекстовые переходы, или с обработчиков событий, программирование которых позволяет заменять правила реакции браузера на действия пользователя по умолчанию.
Интерпретация кода в элементе SCRIPT происходит только в момент начальной загрузки страницы. Управление переходит к интерпретатору в момент, когда HTML-программа синтаксического разбора "натыкается" на элемент разметки SCRIPT. Код выполняется, и результат его работы подставляется в документ (если это можно сделать). Налицо типичная вставка, реализованная на стороне клиента.
Остановимся теперь на технологии, которая стала, с одной стороны, развитием HTML-разметки, а с другой - следующим шагом по направлению к XML.
Речь идет о каскадных таблицах стилей, Cascading Style Sheets (CSS), патентом на спецификацию которых владеет Microsoft. Но спецификация относится к категории открытых стандартов и может использоваться всеми разработчиками ПО для Web. Основная идея CSS состоит в том, чтобы отделить логическую структуру документа от формы его представления (способа форматирования изображения на носителе).
С появлением CSS в HTML стало возможным использование двух обобщенных элементов разметки: DIV (обобщенный блок) и SPAN (обобщенный строчный элемент разметки). Теперь можно составлять логическую структуру документов, а затем определять формат ее отображения.
Этот подход изменил всю технологию проектирования страниц Web-узла. Теперь сначала определяются типы страниц, потом логическая структура страницы для каждого типа и в последнюю очередь для каждого логического элемента определяется его состав и внешний вид.
Возможность указания стиля во внешнем файле позволяет применять одно определение стилей для всего узла и изменять вид страниц, редактируя только данный файл. Следующий шаг на этом пути - динамическое переопределение стиля на стороне клиента в зависимости от условий отображения документа и действий пользователя. Для программирования таких изменений применяется язык типа JavaScript.
До сих пор речь шла о развитии технологий, опирающихся на HTML - элементы разметки и способы их размещения на страницах. Но есть еще один аспект Web-технологии - язык программирования Java.
Первоначально в Java не предполагалось осуществлять манипулирование объектами HTML-страницы и, хотя Duke бегал по границе экрана браузера Sun, реально Java внедрился в документ только в виде элемента разметки applet. Как универсальный язык программирования интерфейсов, главным образом графических, Java поддерживал более абстрактные типы данных и объекты, чем это требовалось для программирования HTML-страниц.
Сейчас ситуация изменилась. На Java написаны браузеры и серверы. При этом Java-код являетя изначально интерпретируемым.Следовательно, на Java можно писать SSI и изменять содержание документа на стороне браузера. Но возможности Java сегодня используются прежде всего для преодоления негативных особенностей HTTP-обмена (поддержка постоянных TCP-соединений) и вывода динамически изменяемой графики. Следует отметить, что протокол HTTP версии 1.1 [6] позволяет компоновать документ из различных частей, которые могут располагаться на разных серверах. Это не установка нового соединения для подкачки картинки при разборе HTML-документа, а список заголовков HTTP-отклика, в которых указывается URL. Таким образом, HTTP модифицирован для поддержки составных документов.
Rcp
Команда rcp копирует файлы в или из других систем, которые поддерживаются BSD-сетью. Доступ к файлам на удаленной системе контролируются тем же способом, что и при использовании команды rlogin . Использовать rcp вы сможете в том случае, если у вас есть разрешение использовать rlogin для связи с удаленной машиной без подтверждения пароля.
Чтобы скопировать файл groucho из вашей home -директории удаленной машины harpo в локальный файл chico , вы должны ввести следующую командную последовательность:
rcp harpo:groucho chico
И наоборот, чтобы скопировать файл из локальной машины в файл удаленной машины, достаточно переставить аргументы в предыдущей команде:
rcp chico harpo:groucho
Можно скопировать сразу всю директорию, указав опцию -r . Команда
rcp -r tuna_fish harpo:big_store
скопирует содержимое локальной директории tuna_fish в директорию с именем big_store на удаленной машине harpo . При этом, если такой директории на удаленной машине не существует, то она создастся. Можно копировать файлы, используя шаблон. Например вы хотите скопировать все фортрановские программы из локальной директории в директорию на удаленной машине harpo :
rcp *.f harpo:fortran_dir
Чтобы скопировать все фортрановские программы из директории fortran_dir на удаленной машине harpo в локальную директорию local_dir , нужно ввести:
rcp harpo:fortran_dir/\*.f local_dir
Если же имя host а и имена файлов заключить в кавычки, то тогда не нужно использовать символа \\everb :
\bverb rcp 'harpo:fortran_dir/*.f' local_dir
Если вы работаете на локальной машине aries под пользовательским именем jones и хотите скопировать файл chico в файл group на удаленной машине harpo , на которой вы работаете под именем boby (т.е. имена пользователей отличаются), то вам необходимо ввести следующую команду:
rcp chico boby@harpo:group
Rdist
Команда позволяет на заданных машинах хранить идентичные копии файлов. По умолчанию, rdist просматривает только те файлы, версия которых на удаленных машинах более старая, чем на локальной машине. Это делается сравнением последнего времени модификации и размера файла на локальной машине и на удаленных.
Выполнить rdist команды можно из командной строки или из командного файла. По умолчанию, rdist будет искать командный файл под именем `` distfile ", затем под именем `` Distfile ".
Определить список файлов или машин в командном файле можно в одном из следующих форматов:
var_n = name_l
или
[label:] source_l -> dest_l
command_list
где
var_n - Имя переменной, которая будет использоваться в последующих ссылках.
name_l - Список файлов, директорий или машин.
label - Метка для дальнейших ссылок.
source_l - Список файлов или директорий на локальной машине, которые будут выступать как главные копии.
dest_l - Список машин, на которых главные копии будут устанавливаться.
command_list - Команды программы rdist.
Например, команда
FILES = (.login .cshrc .mailrc .logout .rhosts )
назначает переменной FILES список файлов, указанных в скобках. А команда
HOSTS = ( aries gemini libra pisces )
назначает переменной HOSTS список имен машин. А затем эти переменные можно использовать в подкомандах программы rdist. Последовательность команд:
dotfiles: ${FILES} -> ${HOSTS}
install -y;
установит копии, определенные переменной FILES на удаленные машины, заданные переменной HOSTS . Опция `` -y " предотвращает обновление удаленных файлов, которые модифицировались позднее, чем соответствующие исходные файлы на локальной машине.
Программа rdist может быть также использована для копирования файлов с одной системы на другие, причем ее использовать предпочтительнее, чем команду rcp , поскольку rdist сохраняет режимы доступа владельца и группы, а также время последней модификации. Для таких целей rdist используется с ключом -c . Например, скопировать содержимое директории tuna_fish в директорию big_store на удаленной машине с именем harpo:
rdist -c tuna_fish harpo:big_store
Ресурсы Internet
Вся информация о BizTalk, в том числе полная спецификация тегов BizTalk, имеется на .
Полная спецификация Internet Content Exchange (ICE) доступна интерактивным образом на .
Дополнительную информацию о XML Schema можно найти на .
Ресурсы Internet
Наилучшей исходной точкой для более подробного знакомства с WBEM является сервер DMTF с адресом . Там вы найдете спецификации для всех схем Common Information Model (CIM), а также Extensible Markup Language (XML), Document Type Definition (DTD) для CIM, таблиц стилей для Cascading Style Sheet (CSS) и Extensible Style Language (XSL), реализации CIM поверх HTTP и кодирования XML для CIM Schema.
Программное обеспечение Solaris WBEM Services и комплект для разработки программного обеспечения Sun WBEM можно бесплатно загрузить с .
Microsoft имеет большие планы в отношении применения XML для разных задач, а не только управления сетями и системами. Подробную же информацию о Windows Management Instrumentation (WMI), Win32 CIM Object Manager можно найти на .
Ресурсы Internet
Тим Брей, соредактор спецификации Extensible Markup Language (XML) 1.0, написал отличное введение в XML «XML и второе поколение Web» для Scientific American. Его можно прочитать на . Его же статью «Расширение концепции документа» можно найти на сервере журнала Web Techniques по адресу: .
Домашняя страница XML консорциума World Wide Web со ссылками на ознакомительные статьи, ответы на вопросы и соответствующие стандарты расположена по адресу: .
Страница Мариуса Гаршола с бесплатным программным обеспечением XML находится на .
Привлекательную информационную страницу «Что такое XML можно найти на .
Страница «Как овладеть XML» компании Washington Technology содержит 10 различных ссылок, в том числе ответы на вопросы, с помощью которых вы сможете быстро овладеть XML. См. .
Пользователям Internet Explorer 5 любопытная демонстрация на позволяет интерактивным образом изменять представление файла XML посредством применения различных таблиц стилей.
Если вы хотите быть в курсе событий в области XML, то посетите , публикуемый Seybold Publications и O-Reilly.
Революция в ИТ
Х-фаза Интернет
Все больше людей общаются друг с другом с помощью Интернет. Ежегодный прирост пользователей Интернет составляет 60 процентов. Еще более высокими темпами развивается электронный бизнес в Интернет.
Вместе с тем, существенный рост Интернет выявил все недостатки технологий, основанных на языке HTML. HTML (HyperText Markuo Language) был разработан для решения задачи отображения содержимого (некоторые эксперты превратили его применение в искусство) и для ручного поиска информации. Однако, HTML не подходит для автоматической обработки информации. Например, наш браузер "знает", что конструкция Sun появится на экране как заголовок. Но какой смысл несет содержимое? Одна из звезд нашей галактики? Имя джазового музыканта? Название компьютерной компании? Мы можем только догадаться по контексту, а компьютер - нет.
В 1996 году группа экспертов, возглавленная Йоном Босаком (Jon Bosac) из компании Sun Microsystems и поддержанная консорциумом World Wide Web (W3C) начала разработку нового стандарта. Этот новый стандарт должен был бы быть простым, расширяемым и читаемым (понятным) как людьми, так и компьютерами. В феврале 1998 года этот стандарт обрел имя: XML - eXtensible Markup Language (расширяемый язык разметки). В этот же год он начал применяться в электронной торговле. По данным агентства Zona Research уже в третьем квартале по сравнению со вторым процент компаний, использующих XML, вырос с 1-го до 16. Новый стандарт был быстро одобрен и принят такими лидерами индустрии как Sun, Microsoft, DataChannel, NetScape, IBM, SAP Adobe и Software AG. За это же время с помощью XML разработаны десятки "вертикальных" стандартов, таких как: CDF (Channel Definition Format), OSD (Open Software Description), и т.п., что делает XML для Интернет действительно lingua galactica.
Появление XML означает начало нового этапа развития Интернет, преобразования всемирной паутины в глобальную базу знаний и глобальную вычислительную среду.
Какие же свойства XML делают его столь привлекательным?
Простота
Язык XML чрезвычайно прост для восприятия человеком. В то же время он легко может быть обработан компьютером. Существенно проще создать XML-документ, чем HTML, где автору необходимо учитывать поведение разных браузеров.
Открытость
Язык XML является стандартом W3C. По сути, когда говорим об XML, мы понимаем совокупность трех тесно связанных стандартов: собственно XML - как средство описания структуры документов, XSL - как средство преобразования XML-документа в HTML-документ или в другую среду отображения; и XLL - расширяемый (или открытый) язык связывания документов, аналогичный применяемому в HTML, но имеющему возможность, например, устанавливать многонаправленные ссылки, ссылаться не на весь документ, а на конкретный его элемент, и т.д. Кроме того, для разработчиков приложений предоставляется возможность использовать программный интерфейс XML OM, реализованный, в частности Microsoft в виде DOM (Document Object Model).
Расширяемость
Язык XML не имеет фиксированного набора элементов разметки (тэгов). Более того, новые тэги могут создаваться в процессе создания документа. При этом нет необходимости внедрять новые версии программного обеспечения.
Само-определенность
Традиционные СУБД требуют, чтобы структура записей всегда соответствовала схеме данных, заранее заданной администратором базы данных. Документы, представленные в структуре XML, могут храниться без таких описаний, поскольку эти метаданные уже включены в сам текст документа в виде элементов XML и/или их свойств.
Идентификация автора и версий документа на уровне элемента XML.
Любой элемент XML может иметь неограниченное число свойств, таких как автор или номер версии.
Машинно-читаемый контекст
Тэги, свойства и структурные элементы XML обеспечивают информацию о контексте, позволяя, тем самым, интерпретировать значение элемента XML, что открывает новые возможности для построения интеллектуальных поисковых машин, средств многомерного анализа данных, агентов и т.п. В этом видится главное преимущество над HTML, где трудно или невозможно проанализировать информацию о контексте.
Разделение содержания документа от формы его представления
Тэги XML описывают значение, а не представление выделяемой ими части документа. Девиз HTML: "Я знаю, как это выглядит". Девиз XML: "Я знаю, что это значит, а ты можешь мне сказать, как это должно выглядеть ". Собственно форма представления документа в формате XML может управляться с помощью расширяемых стилей (XSL - eXtensible Stylesheets Language), позволяющих менять внешний вид документа, не затрагивая его содержание. Одно и то же содержание может быть легко представлено в нескольких видах.
Поддержка многоязыковых документов и Unicode
Данное обстоятельство является важным при построении глобальных приложений.
Сравнение и агрегация данных
Иерархическая древовидная структура XML-документа позволяет эффективно выполнять поэлементные операции сравнения и агрегации. Использование XML упрощает процессы поиска и слияния данных, хранящихся в разнородных базах данных и приложениях, вследствие включения в состав передаваемого сообщения описания контекста передаваемых данных.
Разные типы данных
XML-документ может состоять из любых типов данных - от мультимедиа (графика, звук, видео) до активных компонентов (аплеты Java, ActiveX). Данные, полученные клиентом, могут быть дополнительно обработаны на клиенте, без необходимости выхода в сеть, что, соответственно, позволит увеличить пропускную способность существующих сетей Интернет.
Работа с существующими данными
Грамматика языка XML позволяет просто решать вопрос отображения существующих данных, будь то файловая система или РСУБД. Важно отметить, что XML позволяет реализовать не только чтение данных, хранящихся в разных источниках, и их слияние в единый документ, но и строить системы обновления XML-документов, позволяя обновлять (и передавать по сети) только изменяемые в конкретной транзакции данные. Данное обстоятельство может оказаться существенным резервом повышения пропускной способности существующих сетей.
Взгляд на распределенные данные с одного сервера XML-документ может состоять из вложенных элементов, значение которых хранится на разных удаленных серверах. В этом смысле XML на сегодня является самым изощренным форматом описания распределенных данных, с помощью которого можно представить весь WWW как одну громадную базы данных.
Быстрое одобрение индустрией программного обеспечения
Такие компании как Software AG, IBM, Sun, Microsoft, SAP, NetScape, DataChannel и многие другие уже объявили о поддержке XML. Microsoft будет применять XML в качестве формата обмена в Microsoft Office, а также в IE5. SAP объявила о поддержке XML в составе SAP Business Connector with R/3, Software AG поддерживает XML в линии продуктов Bolero и Natural и выпускает Tamino как информационный XML-сервер.
Режим прокрутки Scrollback mode
Клавиша Scroll Lock устанавливает сессию в режим обратной прокрутки. При этом в 25й строке экрана загорается соответствующий флаг. Режим прокрутки позволяет с помощью курсора (клавиши PgUp, PgDn, стрелки вверх и вниз) или мыши перемещаться по всему тексту текущей сессии, просматривая ее содержание.
Возможность обратной прокрутки ограничивается только памятью компьютера.
В режиме Scrollback никакие управляющие команды не работают и запрещается введение нового текста.
Rlogin
Команда rlogin позволяет вам ``войти" в сеанс работы на удаленном компьютере. По сути, она обеспечивает доступ в режиме удаленного терминала к удаленному компьютеру через сетевое соединение.
Формат команды:
rlogin hostname
где hostname это логическое имя удаленной машины.( Отметим, что ВСЕГДА вместо логических номеров машины вы можете использовать IP-адрес.) Например,
rlogin aries
Если вы имеете ``прозрачный" (т.е. не требующий пароля) доступ к машине aries с данной локальной машины, вы получите приглашение shell-оболочки. В противном случае, вам придется вводить пароль входа на машину aries . После получения приглашения вы работаете на удаленной машине. Полезно проверить текущее имя машины командой hostname .
Команда rlogin может применяться последовательно, что дает возможность входить на удаленную машину через ряд промежуточных. Так, предположим, что между вашей машиной и машиной aries нет прямого соединения. Тогда команда rlogin aries , естественно, не будет выполнена успешно. Однако если вы имеете соединение, скажем, с машиной hydra , и знаете, что эта с этой машины доступна aries , вы последовательно выполняете две команды rlogin :
rlogin hydra и
rlogin aries
(по ходу дела вводя пароли)
Выход из сетевого соединения с удаленной машиной осуществляется командой exit . Отметим, что в последнем примере после выполнения команды exit вы окажетесь в операционной среде машины hydra. И чтобы перейти на локальную машину вам придется ввести еще одну команду exit . Более простой способ закрыть все сетевые соединения и вернуться на локальную машину-это ввести последовательность `` ~. ''. Последовательность `` Ctrl-Z '' приостанавливает работу на удаленной машине и позволяет оказаться на командном уровне вашей локальной машины. Команда fg возобновляет работу на удаленной машине.
Если вы выполняете rlogin на удаленную машину, в которой у вас нет home -директории, то система выведет на экран сообщение об ошибке и назначит вам, по умолчанию, home-директорию " / ".
Для работы на удаленных машинах с использованием различных имен пользователя, нужно выполнить команду rlogin с опцией -l , указывающей имя, под которым вы зарегистрированы на удаленной машине.
rlogin aries -l jones .
Когда rlogin не может обеспечить связь с требуемой удаленной машиной, на экране появляются сообщения об ошибках и вы остаетесь в среде локальной машины. Следующие сообщения могут появиться на экране:
unknown host данная удаленная машина не определена в базе данных для имен host'ов
Connection refused удаленная машина существует в базе данных host имен, но она посылает сообщение, что отказывается от связи
Network unreachable нет маршрутной карты для данной удаленной машины
Connection timed out удаленная машина не отвечает на требование связаться, это сообщение обычно указывает на то, что удаленная машина выключена
Rsh
Команда rsh используется для выполнения команд через сеть. Например, вы хотите скомпилировать фортрановскую программу cad.f на удаленной машине gemini . Для этого введите
rsh gemini fc cad.f
Если вы используете другое login имя (например, boby ) на удаленной машине, то используйте опцию -l также, как в случае команды rlogin :
rsh gemini -l boby fc cad.f
Доступ к удаленным системам по команде rsh контролируется также, как для команды rlogin . Чтобы воспользоваться командой rsh , вам должно быть разрешено выполнять команду rlogin для доступа к удаленной системе без подтверждения пароля. Команда rsh не позволяет выполнять интерактивные команды.
Ruptime
Команда ruptime используется для проверки статуса других машин в вашей локальной сети или в вашей локальной подсети, если ваша сеть разделена на подсети. Для использования ruptime введите
ruptime
Результат будет выведен на экран. Вывод команды ruptime сходен с выводом, получаемым в результате выполнения команды uptime , отличие состоит лишь в том, что для команды ruptime количество дней, в течение которых удаленная машина была включена, отделяется от количества часов знаком `` + ''. По выводу команды можно увидеть, как долго каждая система была включена, как много пользователей сделали login и какова загрузка удаленных машин.
Rwho
Если ваша сеть имеет широковещательные возможности, то вы можете использовать команду rwho для определения, кто из удаленных пользователей сделал login и на каких машинах вашей локальной сети или локальной подсети, если ваша система использует подсети. Для использования команды введите
rwho
На экран выведется результат выполнения команды. Если вы зададите опцию `` -а ", то получите более детальную информацию, а если задать опцию `` -r ", то можно получить список удаленных пользователей в обратном алфавитном порядке. Замечание: rwho команда работает только на тех машинах, где запущена специальная системная задача rwho daemon .
Сценарии и документы
Практическая часть этой статьи позволяет придти к выводу, что сами по себе органы управления ActiveX практически бесполезны без поддержки со стороны сценариев, встраиваемых в HTML-документ. Так что легко понять, почему Microsoft считает сценарии в Internet Explorer компонентом, не уступающим по важности самим органам управления. И хотя для профессиональных Web-дизайнеров, большинство из которых ориентировались до сих пор на Netscape Navigator, концепция сценариев не является чем-то особенно новым, в самой системе ActiveX сценарии занимают очень важное место.
Впрочем, кое-что новое для пользователей Netscape в сценариях Internet Explorer все-таки есть - это поддержка нового языка VBScript, особого "сценарного" диалекта Visual Basic ("Visual Basic Scripting Edition"). Вероятно, поддержка VBScript позволит привлечь к работе со сценариями много программистов-любителей, которые обычно хорошо знакомы с Visual Basic. Считается, что С-подобный синтаксис JavaScript отпугивает от этого языка многих начинающих программистов.
Двуязычие броузера Internet Explorer делает осмысленным и даже необходимым использование атрибута LANGUAGE тега , добавив к открывающему тегу следующую пару атрибутов:
FOR="имя объекта"
EVENT="имя события"
Имя объекта - это тот идентификатор, который был ему приписан с помощью атрибута ID (см. выше). Как правило, имена событий (набор которых свой у каждого органа управления) не содержат префикса "on" - так, событие щелчка мыши всегда обозначается идентификатором Click, а не onClick.
Система FLORID
Система FLORID [HLLS97, LHL+98] - реализация прототипа дедуктивного и объектно-ориентированного формализма F-логики [KLW95]. Чтобы использовать FLORID как механизм обработки запросов для Web, документ Web моделируется следующими двумя классами:
url::string[get => webdoc]. webdoc::string[url => url; author => string; modif => string; type => string; hrefs@(string) => url; error =>> string].
Первая из этих деклараций вводит класс url, подкласс string с единственным методом get. Нотация get => webdoc означает, что get - метод, вырабатывающий единственное значение (single-valued), который возвращает объект типа webdoc. Метод get является определяемым системой. Результатом вызова u.get для url u в заголовке дедуктивного правила является выборка из Web документа с данным URL и кэширование его в локальной базе данных FLORID как объекта webdoc с идентификатором объекта u.get.
Класс webdoc с методами self, author, modif, type, hrefs и error моделирует основную информацию, общую для всех документов Web. Нотация hrefs@(string) = >> url означает, что многозначный метод hrefs получает string как аргумент и возвращает множество объектов типа url. Идея состоит в том, что, если d есть webdoc, то d.hrefs@(aLabel) возвращает URL всех документов, на которые указывают связи, помеченные как aLabel внутри документа d.
По необходимости могут декларироваться подклассы документов с использованием наследования F-логики, например:
htmldoc::webdoc[title => string; text => string].
Вычисление во FLORID выражается наборами дедуктивных правил. Например, приведенная ниже программа осуществляет выборку из Web множества всех документов, достижимых непосредственно или косвенным образом из URL по связям, метки которых содержат строку "база данных".
(:url).get.(Y:url).get <-(X:url).get[hrefs@(L)=>>{Y}], substr(<база данных>,L).
FLORID обеспечивает мощный формализм для управления слабоструктурированными данными в контексте Web.
Однако, он не обеспечивает в настоящее время конструирования в результате вычисления новых сайтов. Результат всегда представляет собой некоторое множество объектов F-логики в локальной памяти.
Языки ULIXES и PENELOPE
В проекте ARANEUS [AMM97b] процесс обработки запросов и реструктуризации разбивается на две фазы. На первой фазе для построения реляционных представлений над Web используется язык ULIXES. Эти представления могут далее анализироваться и интегрироваться с использованием стандартных технологий баз данных. По запросам, сформулированным на языке ULIXES, производится выборка реляционных данных из экземпляров схем страниц, которые определены средствами модели ADM, с интенсивным использованием выражений путей без символа <*> (star-free). Вторая фаза заключается в генерации гипертекстовых представлений данных с использованием языка PENELOPE. Проблемы оптимизации запросов для реляционных представлений, поддерживаемых над множествами страниц Web, например, построенных средствами ULIXES, обсуждаются в [MMM98].
Интерактивные интерфейсы запросов
Все языки, рассмотренные в предыдущих двух подразделах, слишком сложны для непосредственного применения интерактивными пользователями, точно так же, как и SQL. Предполагается, что они, подобно SQL, должны использоваться, главным образом, как инструментальные средства программирования. Однако проводились работы по созданию интерактивных интерфейсов запросов, пригодных для случайных пользователей. Одним из них является Dataguides [GW97] - интерактивное средство запросов для слабоструктурированных данных, основанное на иерархических "выжимках" (summaries) графа данных. Расширения для поддержки запросов в отдельных сложных Web-сайтах рассмотрены в [GW98]. Система, описанная в [HML+98], поддерживает запросы, которые сочетают мультимедийные возможности, например, схожесть с данным эскизом или изображением, возможности работы с текстами, такие как поиск по ключевым словам, а также семантику предметной области.
Теория запросов в Web
Определяя семантику языков запросов первого поколения для Web, можно немедленно обнаружить, что легко формулируемые запросы вида "перечислить все документы Web, которые не указывают ни на какие другие документы", могут быть довольно трудными для исполнения. В связи с этим обстоятельством возникают, естественно, вопросы о вычислимости запросов в таком контексте. Абитебул и Виану [AV97a], а также Мендельсон и Мило [MM97] предложили формальные способы категоризации запросов в Web, в соответствии с тем, могут ли они в принципе быть вычисленными или нет. Ключевая идея заключается, по существу, в том, что единственный возможный способ доступа в Web - это навигация по связям из известных стартовых точек. (Заметим, что специальным частным случаем является навигация по связям, исходя из больших совокупностей стартовых точек, называемых индексными серверами или поисковыми машинами). Абитебул и Виану [AV97b] обсуждают также фундаментальные проблемы, возникающие при оптимизации запросов, связанных с обходом путей. Михайла, Мило и Мендельсон [MMM97] показывают, как анализировать запросы в WebSQL на основе максимального числа Web-сайтов. Флореску, Леви и Сучу [FLS98] описывают алгоритм для запросов по содержанию, для запросов с правильными выражениями путей, который затем используется для проверки ограничений целостности на структуре Web-сайтов [FFLS98].
Системы XML/EDI
Комбинация XML и EDI предполагает для XML/EDI разработку предложений основных методов описания и кодирования EDI сообщений посредством XML обработки. Формы, обрабатывающие XML документы должны быть согласованы, чтобы осуществлять взаимодействие с существующими XML/EDI системами. Для этого они должны иметь возможность генерировать EDIFACT сообщения, осуществлять их анализ и отображение.
XML/EDI предлагает пользователям, использующих текущие стандарты пути решения возможных проблем и может быть интегрировано в существующие EDI системы путем:
Разработки форм для приложений пользователя, способных генерировать EDI сообщения Создания форматов EDI сообщения для их передачи между компьютерами по Интернет, или через сети с добавленными услугами (VANs) Разработки пользовательских шаблонов для интерпретации согласованных правил на компьютере получателя с помощью стандартных программ просмотра (броузеров)
XML/EDI представляет нечто больше, чем прямой перенос XML документов в системы EDI. В рамках построения XML/EDI представляется слияние пяти технологий (XML, EDI, Templates, Agents и Repository), которые существенно расширят существующие возможности информационной системы. Каждый из этих компонент добавляет свои специфические возможности.
Использование технологий XML/EDI реализует следующие цели:
Сделать EDI универсально допустимыми, используя свободно распространяемый код и синтаксис SQL (XQL) Осуществить разработку "последующих" EDI - сообщений таким образом, чтобы они были полностью совместимы с существующими X12 и UN/EDIFACT стандартами Осуществление, по возможности, единой трансляции сообщений X12 и UN/EDIFACT
На рис. 2 представлены составные части технологий XML/EDI:
Рис. 2 Составные части XML/EDI технологий
Более подробно про каждую из составных частей:
XML. В основе обмена документами лежат транспортные протоколы, используемые в Интернет. С помощью заранее определенных тэгов определяется объектная модель данных, которая в последствии заполняется данными и передается в качестве электронного документа.
Существующее идентификаторы сегментов EDI заменяются тэгами XML, или часть данных из EDI сегмента добавляются в тэги в качестве параметров.
EDI. Разработанные в EDI системах стандарты способны представлять данные в простом формате. Эти данные однозначно интерпретируются на принимающей и передающей стороне. XML/EDI позволит обеспечить 100 % совместимостью с существующими EDI системами, используя при этом обмен EDIFACT сообщениями. Разработка протоколов XML/EDI позволяет использовать уже существующие EDI системы, что не потребует новых капиталовложений для разработки глобальных систем.
Templates (Шаблоны) - это набор определенных правил, которые осуществляют управление процессом, как на клиентской, так и на серверной стороне. С помощью шаблонов можно выразить в XML все особенности процесса, который должен быть выполнен. Шаблон могжет быть загружен как с удаленного источника, откуда пришел XML документ, так и быть его составной частью. Шаблоны используют Document Type Definitions (DTD's), по которым определяется объектная модель данных. Удаленное использование (DTD's) позволит всем клиентским приложениям однозначно определить используемую модель данных.
Agents (Агенты) интерпретируют шаблоны, чтобы интерактивно выполнить необходимые транзакции и взаимодействовать с пользователем. Агенты могут быть реализованы как аплеты Java или внедренные объекты ActiveX. Разбор структуры XML может осуществляться Агентом прямо на компьютере клиента и использовать при этом необходимые для пользователя данные и их представление. Первоначально агенты будут управляться Шаблонами и предоставлять пользователю некоторые дополнительные возможности. Предполагается, что позже будут разработаны соответствующие протоколы для Агентов.
Repository (хранилище) - совместно используемые в Интернете общедоступные словари - которые уже используются в традиционных EDI системах. Данные словари позволяют пользователям найти значение и область определения EDI элементов. Совместно используемые общие словари обеспечивают автоматические поисковые таблицы более гибким механизмом поиска.
Данный компонент обеспечит семантическую основу для EDI транзакций.
Можно выделить следующие основные принципы построения XML/EDI:
XML используется как макет " моделирование обмена данными " XSL используется как уровень "представления" Возможность интеграции с традиционными методами EDI Использование маршрутизациии по IP, а текже использование протоколов HTTP, FTP и SMTP Централизованное представление документа и методология обработки Протоколирование приема/отправки документов Использование современных инструментальных средств программирования (Java и ActiveX) Разделение данных и программ Использование технологии агента для манипулирования данными, синтаксического анализа, отображения, поиска и т.д.
Определенные XML/EDI компоненты сформированы на основе существующих протоколов передачи и обработки кодированных в XML данных.
Рис 3. Уровни Интерфейсов XML/EDI
На рисунке представлены следующие интерфейсы уровней XML/EDI:
Использование стандартных транспортирных механизмов данных по Интернет и хранения файлов Форматы представления данных и передачи сообщения Синтаксис XML данных Правила грамматического разбора XML документа или создание объектной модели Правила XSL представления, связь со скриптами и уровнем разбора объекта Использование правил управления данными для пользовательских приложений и интерфейсов баз данных
Сегодня уже доступны синтаксические XML анализаторы, программы просмотра XML-документов (броузеры), программы разметки страниц и библиотеки программ. Предполагается использование специальных XML/EDI компонент встаивать в существующие программные продукты. Это позволит значительно ускорить создание новых приложений, реализующих XML/EDI.
Первичные компоненты XML/EDI представляют общей язык описания и синтаксические правила и включают:
таблицу определения данных - DTD Базу (хранилище) данных - Repositories Сегменты и элементы данных (т.e. EDIFACT, X12, или BSI директории) Базу бизнес объектов Страницы торговых партнеров (База данных предприятий).
На рис. 4 представлены возможные варианты подключения отдельных компонентов XML/EDI. На данной схеме выделены в отдельные компоненты: удаленный пользователь, бизнес приложения, существующие EDI-системы, публичные директории и специальные словари и базы данных.
Рис 4 Связи в XML/EDI
Конечный пользователь посредством WEB-броузера может взаимодействовать с любыми компонентами системы, используя XML-представления и XQL запросы.
Хотелось бы отметить о возможности более интересующегося читателя подчерпнуть более подробную информацию на следующих серверах:
- рекомендации Торговой Палаты
- EDI группа
- консультативная EDI группа
- Обзор публикаций по EDI
- рабочая группа по защите UN/EDIFACT (SJWG)
- EDI стандарты
- EDI стандарты
- ассоциация пользователь электронными сообщениями
- введение в XML, статьи по XML
- рекомендации группы W3 по использованию XML
- руководство по XML
- публичный сервер пользователей XML
- публичный сервер пользователей XML
- сервер группы XML/EDI
- разработки Microsoft в области применения XML
- Руководство по применению XML в системах EDI
-Европейский XML/EDI пилотный проект
- пилотные прокты Программы TEDIM
- электронный бизнес
- электронная коммерция
- бизнес через WEB
because of the copyright nature
=1= #!/usr/bin/perl =2= =3= use CGI; # must be version 2 or higher =4= use News::NNTPClient; =5= use MIME::Base64; =6= =7= $nntpserver = "news.teleport.com"; # location of news server =8= =9= ## because of the copyright nature of this material, you should =10= ## put this script in a directory that has an appropriate htaccess file. =11= =12= @groups = ( =13= ["clari.living.comics.bizarro", "Bizarro"], =14= ["clari.living.comics.cafe_angst","Cafe Angst"], =15= ["clari.living.comics.doonesbury","Doonesbury"], =16= ["clari.living.comics.forbetter","For Better or For Worse"], =17= ["clari.living.comics.foxtrot","Foxtrot"], =18= ["clari.living.comics.ozone_patrol","Ozone Patrol"], =19= ["clari.editorial.cartoons.toles","Toles"], =20= ["clari.editorial.cartoons.worldviews","Worldviews"], =21= ["clari.news.photos","News photos (not a comic, but handy)"], =22= ); =23= =24= $Q = new CGI; =25= $Qself = $Q->self_url; =26= =27= unless ($group = $Q->param('group')) { # nothing at all, give index =28= $links = join "\n", =29= map { "[0]\">$_->[1] " } @groups; =30= =31= print <<"GROK"; q/"/; =32= @{[$Q->header]} =33= @{[$Q->start_html('Comics','merlyn@stonehenge.com')]} =34= Read the Comics =35= Select the group you want to read: =36= =37= $links =38= =39= Please respect the copyrights and license agreements of this service. =40= @{[$Q->end_html]} =41= GROK =42= q/"/; =43= exit 0; =44= } =45= =46= unless ($article = $Q->param('article')) { # group but no art, give group =47= $N = new News::NNTPClient($nntpserver,119,0); =48= for ($N->xover($N->group($group))) { =49= ($numb,$subj) = split /\t/; =50= $links .= "$subj \n"; =51= } =52= =53= print <<"GROK"; q/"/; =54= @{[$Q->header]} =55= @{[$Q->start_html('Comics','merlyn@stonehenge.com')]} =56= Read the Comics =57= Select the article you wish to view: =58= =59= $links =60= =61= Please respect the copyrights and license agreements of this service. =62= @{[$Q->end_html]} =63= GROK =64= q/"/; =65= exit 0; =66= } =67= =68= ## $group and $article both valid: =69= $N = new News::NNTPClient($nntpserver,119,0); =70= $N->group($group); =71= @art = $N->article($article); =72= shift @art while @art and $art[0] !~ /^Content-Type: (image\/[-a-z]+)/; =73= $type = $1; =74= shift @art while @art and $art[0] !~ /^\s*$/; =75= pop @art; # heh =76= $gif = decode_base64(join "", @art); =77= print "Content-type: $type\n\n"; =78= print $gif; =79= exit 0;
Тип события, которое будет
Элемент
Onevent
Атрибуты:
type - Тип события, которое будет обрабатываться
Существует четыре типа событий:
onenterbackward
Сработает при выборе элемента "prev"
onenterforward
Сработает при вызове карты
onpick
Сработает при выборе опции в списке элемента "select"
ontimer
Сработает по истечении времени у элемента "timer". Choose Accept. Choose Accept Choose Accept.
Сохранение текста сессии
После установления связи с удаленной машиной весь текст, который появляется на экране в процессе работы может быть запомнен в файле персонального компьютера или выведен на принтер.
На то, что текст сессии сохраняется указывает соответствующий флажок Capture в 25й строке экрана. Такой флажок устанавливается и убирается по Alt+C. Capture ON может быть установлен только для одной сессии.
Сохранение текста происходит в так называемом Capture файле на PC пользователя. Этот файл никогда не удаляется, запись в него всегда происходит в режиме добавления. Имя Capture файла устанавливается в Config.tel, по умолчанию это capfile. Имя capture файла может быть изменено также и в процессе работы NCSA Telnet на время этой работы: через меню параметров, вызываемое по Alt+P.
Именем capture файла может быть также prn (принтер), тогда текст сессии будет распечатываться. Но, если принтер случайно оказался не в ON-LINE, то будет выведено сообщение:
Error, A(bort), R(etry), I(gnore)
При этом ответ A может вызвать завершение Telnet для всех сессий.
Независимо от того, установлен ли Capture флаг, можно сохранить в Capture файле копию экрана текущей сессии по Alt+D.
Создаем деку.
В этом примере, мы начнем создавать деку, которая позволяет нам сначала выбрать имя пользователя из предложенного списка, затем ввести пароль после чего выводит на экран полученные данные.
UserName: John Doe Paul Smith Joe Dean Bill Todd Password: You entered: Name: $(name) Password: $(password)
Как вы наверно уже заметили, вначале примера идет пролог, в котором мы определяем версию XML и DTD для нашего документа. Затем следует элемент , дека которая содержит три карты: Login, Password и Result. Каждая из этих карт определяется с использованием элемента . Поскольку карты Login и Password определяют события, они используют элемент для определения события которое произойдет, когда пользователь закончит ввод.
Если мы определяем элемент типом "accept" он появляется на экране в качестве опции
Выбор этой опции приведет к анализу введенной пользователем информации.
Атрибут "href" тега работает так же, как и в элементе из HTML. Также как и в HTML, для того, чтобы на экран вывелась другая карты из активной деки, на нее надо сослаться используя символ "#" перед именем карты.
Эта карта обрабатывает пользовательский ввод и используя определенные в предыдущей карте переменные выводит их содержимое на экран. Вызов переменных осуществляется следующим образом:
$(variable_name)
Создание базы данных
Теперь нам необходимо установить соединение с СУБД MySQL и создать нашу базу данных. Ниже мы покажем, как сделать это из командной строки. Однако существует множество систем управления, или менеджеров СУБД MySQL, которые позволяют администрировать ее, используя дружественный графический интерфейс.
Прежде всего вам обязательно следует знать основы языка запросов SQL (Structured Query Language). В поставку СУБД MySQL входит полное описание поддерживаемой спецификации SQL. Этот язык несложен для постижения, поскольку его операторы и их конструкции легко понять и запомнить. Для работы вам потребуются операторы создания (CREATE или INSERT), выборки (SELECT) и удаления (DROP или DELETE) данных, а также их изменения (UPDATE, MODIFY). В конкретных примерах мы воспользуемся только некоторыми из них.
Чтобы не рассматривать установку пользовательских учетных записей (user accounts) и назначение необходимых прав доступа, предположим, что вы используете учетную запись администратора (root).
Шаг 1
Откройте терминальное окно (если вы работаете в графической оболочке X Window ОС Linux или в ОС Windows 9x/NT/2000) и установите соединение с СУБД MySQL, введя в командной строке mysql. В ответ вы должны получить приглашение для ввода команд mysql>.
Шаг 2
Создадим нашу базу данных, введя:
CREATE DATABASE db_website;
После ввода каждой команды не забывайте печатать символ (;). Он очень важен, поскольку посылает MySQL сигнал конца ввода команды.
Шаг 3
Далее необходимо послать команду, указывающую системе MySQL, какую конкретно базу данных мы собираемся использовать. Введите:
use db_website;
Шаг 4
Создадим таблицу tbl_news_items, где определим тип данных, которые будут храниться в ее полях. Введите:
1. CREATE TABLE tbl_news_items ( 2. col_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 3. col_title VARCHAR(100), 4. col_author VARCHAR(100), 5. col_body TEXT, 6. col_date DATE 7. );
Шаг 5
Теперь, когда мы создали таблицу для хранения наших данных, нам нужно заполнить ее какими-то примерными данными. Заметьте, что в нижеследующей команде мы не будем определять поле col_id, потому что оно заполняется автоматически по мере добавления новых данных. Также имейте в виду, что синтаксис для даты — <год/месяц/день>. Итак, в командной строке mysql> введите следующую команду.
8. INSERT INTO tbl_news_items (col_title, _ col_author, col_body, col_date) 9. VALUES ( 10. ‘Мой первый пресс-релиз’, 11. ‘Ваше Имя’, 12. ‘Этот пресс-релиз хранится в БД MySQL’, 13. ‘2001/4/15’ 14. );
Введите еще несколько подобных запросов для вставки. Чтобы просмотреть то, что хранится в базе данных, в командной строке mysql> введите:
SELECT * FROM tbl_news_items;
Создание динамического сайта
Первое, что нужно для создания динамического сайта, — это Web-сервер, например Apache.
Web-сервер может использоваться для обслуживания электронного магазина, сервера новостей, поискового механизма, системы дистанционного обучения и даже для всей совокупности перечисленных сфер. Выбор Web-сервера зависит от того, каким видом деятельности частное лицо или организация собирается заниматься в Интернете.
Немногие из принимаемых в бизнесе стратегических решений столь же значимы, как выбор платформы для Web-сервера. Характеристики сервера — это чрезвычайно важный фактор, определяющий надежность узла, его «отзывчивость» на запросы клиентов, а также то, какие усилия необходимо предпринимать для поддержания его в рабочем состоянии. При правильном выборе компонентов и качественном проекте Web-узел может стать для клиентов и партнеров новым, более удобным способом взаимодействия с вашей компанией. Перегрузка Web-сервера может привести к тому, что сервер баз данных или какой-либо иной ресурс станет недоступным для клиентов.
Крупные компании до недавнего времени делали ставки на Microsoft Internet Information Server, Netscape FastTrack, IBM WebSphere, а Apache в основном использовался небольшими компаниями. Однако сейчас ситуация несколько изменилась, и Apache начинает поддерживать работоспособность некоторых крупных Интернет-проектов, в частности Yahoo.
Полную версию статьи вы можете найти на нашем .
Apache предоставляет богатые возможности, позволяющие настроить Web-сервер в соответствии с потребностями индивидуальных и корпоративных пользователей. Настройка производится с помощью директив, содержащихся в конфигурационных файлах. Apache позволяет создавать виртуальные Web-узлы, а также выполняет функции proxy-сервера. Если нужно предоставить доступ к содержимому сервера лишь ограниченному кругу лиц, Web-сервер можно настроить так, чтобы при обращении к указанным каталогам сервер проверял регистрационные имена и пароли в собственной или в одной из подключенных к нему баз данных.
Далее вам нужно решить, как вы собираетесь хранить информационное наполнение (контент), которое отображается на Web-странице. В данной статье на конкретном примере мы покажем, как создать базу данных в СУБД MySQL, которая позволит нам разбить Web-контент на таблицы, содержащие поля и записи с данными. Поле — это дискретная единица данных в таблице. Например, мы можем создать таблицу tbl_news_items с полями col_title, col_date, col_fullstory, col_author. СУБД MySQL — отличный выбор для создания такой базы данных вследствие простоты в использовании и администрировании, свободной распространяемости для разных платформ, включая Linux и Windows, и быстро растущей популярности.
После этого мы создадим динамические шаблонные страницы на HTML. Чтобы разработать приложения для взаимодействия с базой данных и шаблонами, мы воспользуемся языком Perl.
На самом деле нам необходимо создать три Perl-программы, или скрипта: один будет отображать ссылки на все имеющиеся пресс-релизы (pr-list-dbi.pl), другой — содержимое выбранного пресс-релиза (pr-content-dbi.pl), а третий позволит нам добавить свежий пресс-релиз в базу данных (pr-add-dbi.pl). Работу по верстке можно возложить на любимый HTML-редактор, например, Allaire HomeSite (). Только помните, что при создании шаблона необходимо оставлять пустые области, в которые будет вставляться динамическое наполнение (естественно, переменной длины).
После разработки общего дизайна для своих пресс-релизов просто вставьте в указанные выше пустые области специальные ключевые слова (см. об этом ниже). Как только пользователь запросит какой-либо пресс-релиз, Web-сервер обработает Perl-код и заменит ключевые слова в шаблонах информационным наполнением, извлеченным из базы данных, то есть каким-то конкретным пресс-релизом.
И последнее, что нужно сделать, — загрузить ваши шаблоны на Web-сервер в определенные директории. Можно воспользоваться FTP-клиентом CuteFTP (), но мы предпочитаем использовать файловую оболочку FAR. Две важные вещи, которые следует запомнить: первое — файлы шаблонов должны содержать имена, оканчивающиеся на .pl, и второе — они должны иметь право на выполнение (в UNIX-системах надо выполнить команду chmod 0755 имя_шаблона.pl).Это все!
Создание единого глобального электронного рынка - проект ebXML
© А.Календарев.
Оригинал статьи находится на сайте, посвященном проблеме использования электронных документов -
Создание галереи с помощью php.
,
Предлагаю вашему вниманию пример программирования на языке php с использованием баз данных mysql (в одном из вариантов программы) на примере создания галереи фотографий, картинок и т.п. Картинки в предпросмотре должны быть определенной ширины (чтобы не расползалась страница). Подобный вариант используется мной (2 вариант) и (1 вариант).
Галерея имеет следующие свойства:
предпросмотр; навигация "вперед-назад"; навигация по номерам страниц галереи; наличие описаний к картинкам; администрирование описаний к картинкам; варианты 2 и 3 имеют возможность изменять порядок вывода картинок; вариант 3 сделан с использованием базы mysql варианты 1 и 3 легко преобразуемы в галерею с возможностью дополнения галереи посетителями; если вы обнаружили еще какие-то свойства галереи, буду рад выслушать ваше мнение по адресу
Вариант 1
Программа ищет файлы картинок в указанном ей каталоге с маленькими картинками (предпросмотр). Затем она ищет описания для выводимых картинок в текстовом файле. Определяет кол-во картинок и создает навигацию по галерее. Определяет размеры картинок и выводит их с описаниями и с яваскриптом на каждой картинке, который открывает большой вариант картинки в новом окне с размерами на 40 пикселей больше размера картинки с возможностью скроллинга, если таковой окажется необходим для просмотра картинки полностью (при малом размере экрана).
Вот собственно и код варианта:
<html >
<head >
Photo-galery
head >
Картинная галерея.
// Пишем переменные, которые зависят от Вас
//
$scrpic=10; // максимальное кол-во фоток на
странице$big='../pic/big_regats/'; // путь к большим картинкам
$small='../pic/small_regats/'; // путь к малым картинкам
$ini=$DOCUMENT_ROOT .'/avrora/pic/read/read_regats.ini'; // путь к файлу с текстами к картинкам
//
//В данном случае, файл строится так: строка с названием картинки (без расширения файла)
//затем строка с подписью к картинке
//затем название следующей картинки и так далее.
//
//Например:
//1
//Моя первая фотография
//rt
//моя фотография rt.jpg
//.... и так до последней картинки. Если подписи к картинке нет, то надо оставлять пустую строку.
//
//
$kav="'"; // одинарные кавычки пригодятся нам потом в таком виде
// для отображения в браузере в яваскрипте. Там необходимо иметь оба вида кавычек,
// а для php надо еще поставить выводимое выражение в кавычки.
$podp='увеличить'; // надпись под картинкой,
// побуждающая клиента нажать на картинку для увеличения
//
$style_zag2='zag2-main'; // стили текста на странице
$style_osn='osn-main'; // стили текста на странице
$style_link='link'; // стили текста на странице
//
//
//сама программа
$text=file ($ini); // читаем файл с подписями к картинкам в массив $text
$dir=$small; // указываем путь к каталогу малых фотографий
$handle=opendir($dir); // читаем заголовок каталога
$si=0; // счетчик файлов в папке
while ($file = readdir ($handle)) { // читаем файл, пока не закончатся
if ($file!="..") { // исключаем из списка файлов "." и ".." (корень и верхний каталог).
$pic[$si]=$file; // присваиваем текущему элементу массива с именами файлов имя текущего файла
$si++; // плюсуем к счетчику файлов в папке 1
}
} // следующий файл
$maxpic=count ($pic)-1; // сколько файлов в папке с малыми картинками
if ($begin=="") { // если на страницу зашли впервые, то $begin присваеваем 1
$begin=1;
}
$end=$begin+$scrpic-1; // $end - номер последней картинки на странице
if ($end>$maxpic) { // если последний номер на странице больше кол-во картинок в папке,
// то он равен последнему
$end=$maxpic;
}
$beginrew=$begin-$scrpic; // при переходе назад, начинаем показывать картинки с номера,
//равному "первый номер текущей страницы минус кол-во картинок на странице"
$beginfw=$begin+$scrpic; // при переходе вперед, начинаем показывать картинки с номера,
//равному "первый номер текущей страницы плюс кол-во картинок на странице"
$hrefrew='назад ';
// создаем ссылку "назад"
$hreffw='вперед ';
// создаем ссылку "вперед"
$navig=$hrefrew.' '.$hreffw; // ставим между ссылками "назад-вперед" символ ""
if ($beginrew<=0) { // если мы на первой странице, то ссылка назад не нужна
// $hrefrew='назад ';
$navig=$hreffw;
}
if ($beginfw>$maxpic) { // если мы на последней странице, то ссылка вперед не нужна
// $hreffw='вперед ';
$navig=$hrefrew;
}
// вывод на экран номеров страниц галереи
$scrmax=ceil ($maxpic/$scrpic); // вычисляем, сколько страниц с картинками
for ($scr=1; $scr<=$scrmax; $scr++) { // начиная с первого номера до кол-ва страниц галереи
$beginsrc=($scr-1)*$scrpic+1; // вычисляем номер картинки,
// с которого будут выводиться картинки на странице
if ($beginsrc==$begin) { // если страница текущая,
// то ее номер выводим в виде простого текста, а не ссылки
echo ' '.$scr.' ';
}
else { // если страница не текущая, то выводим ссылку на нее и передаем параметры:
// номер картинки, с которой начать выводить на этой странице
echo ' '.$scr.' ';
}
}
echo '
'.$navig.' ';
// вывод на экран навигации "вперед-назад"
for ($i=$begin; $i<=$end; $i++) { // начиная с первой картинки на странице,
// перебираем картинки вплоть до последней на странице
for ($j=0; $j<sizeof ($text); $j++) { // читаем файл ини и собираем описания
$name_file=explode (".",$pic[$i]); //выделяем в названии файла его имя (без расширения)
if (trim ($text[$j])==$name_file[0]) { // ищем название картинки,
// предварительно обрезав пробелы вокруг названия картинки в файле
// (если текущее название картинки $pic[$i] совпадает с проверяемым $text[$j])
$descript=trim ($text[$j+1]);
// если картинка найдена, то в $descript пишем описание к картинке
}
else { // если название картинки не совпадает с искомым, то плюем на него
}
}
$photo=$big.$pic[$i];
// присваиваем $photo имя малого файла+путь к папке с большими картинками
$size=getimagesize ($photo); // читаем информацию о картинке
$width=$size[0]+40; // получаем ширину картинки и + 40 (свободное поле вокруг картинки)
$height=$size[1]+40; // получаем высоту картинки и + 40 (свободное поле вокруг картинки)
$sxp=$size[2]; // получаем тип (расширение файла картинки)
$smphoto=$small.$pic[$i];
// присваиваем $smphoto имя малого файла+путь к папке с малыми картинками
$smsize=getimagesize ($smphoto); // читаем информацию о картинке
$smwidth=$smsize[0]; // получаем ширину картинки
$smheight=$smsize[1]; // получаем высоту картинки
$smexp=$smsize[2]; // получаем тип (расширение файла картинки)
$winstat='toolbar=0,location =0,directories=0,status=0,menubar=0,scrollbars=1,resizable=1,width='.$width.',height='.$height; // статус открываемого окна с большой картинкой
// выводим таблицу галереи.
// если номер картинки четный, то картинка слева, а описание справа и наоборот
// делаем это для неужасного внешнего вида галереи
// Вы можете разположить картинки как Вам заблагорассудится.
// итак:
?>
// выводим одинаковую часть кода таблицы дл ячейки картинки
//Далее выводим картинки в ячейках таблиц с описаниями. Делаем все с "предпросмотром"
//"предпросмотр предпочтителен, потому что не надо сразу грузить большие файлы,
//а клиент если захочет, сам загрузит то, что его заинтересовало в новых окнах.
//
if ($i/2==ceil ($i/2)) { // если номер картинки на странице четный
echo '
'.$descript.'
'.$podp.'
';
}
else { // если номер картинки нечетный
echo '
'.$descript.'
'.$podp.'
';
}
}
// вывод на экран "вперед-назад"
echo ''.$navig.' ';
// вывод на экран номеров страниц
echo '
';
for ($scr=1; $scr<=$scrmax; $scr++) {
$beginsrc=($scr-1)*$scrpic+1;
if ($beginsrc==$begin) {
echo '
'.$scr.' ';
}
else {
echo '
'.$scr.' ';
}
}
?>
html >
Программа администрирования текстов описаний:
Была применена в моей статье . Я считаю этот способ самым проостым для начинающего программиста. Более сложный способ обновления я собираюсь сделать в будущих статьях.
Конечно, можно делать более серьезные интерфейсы, но в этом варианте, который конечно не рассчитан на ламера, можно быстро править сразу все позиции.
Вот собственно код:
<html >
<head >
admin weather
head >
$adr=$DOCUMENT_ROOT ."/avrora/pic/read/read_regats.ini"; // адрес файла, в котором и будут записываться названия файлов с описаниями
$password='pass'; // простенькая система авторизации
$eror='Password eror!';
$old=file ($adr); // читаем то, что сейчас есть в файле
if ($submit) { // проверяем на нажатость кнопки
if ($pass==$password) {
$fp=fopen ($adr,"w");
fwrite ($fp, $ini); // записываем в файл измененные данные
fclose ($fp);
$old=file ($adr);
}
else {
echo $eror;
}
}
?>
<for m method=post action="echo $PHP_SELF ?>"> // информация, введенная в форму, обрабатывается этим же файлом
password:
inicialisation:
for ($i=0; $i<sizeof ($old); $i++) {
echo $old[$i], ""; // выводим на экран текущий вариант файла
}
?>
for m>
html >
В этом варианте, файл создаем так, как написано в комментарии к программе:
1
Моя первая фотография
rt
моя фотография rt.jpg
, где 1 и rt - имена файлов, а строки под ними соответственно описания к ним.
Вариант 2
Отличие этого варианта отпредыдущего в том, что:
Программа читает файл инициализации галереи.
В каждой строке такая конструкция (так надо заполнять файл для этого варианта! ):
1.jpg|Моя первая фотография
rt.jpg|моя фотография rt.jpg
где символ "|" - это разделитель между описанием и именем файла картинки.
Как видно, в этом варианте надо писать в файле имя файла картинки с расширением. Если это вам это очень мешает, то можете переделать так, чтобы было в файле только имя, а расширение определялось бы автоматически, основываясь на первом примере.
Алгоритм такого варианта будет: определитьимя картинки, считать имена файлов в папке с файлами, обрезая у имен файлов расширения, находим нужный, сравнивая каждый раз с тем, что взяли из файла. Именно совпавший и будет искомым.
Далее программа, создав массив из имен и описаний картинок, определяет, на какой странице галереи клиент находится и выводит ему соответственно ту или иную страницу.
Сам движок галереи остается тем же, как вы наверное заметили.
Изменяются некоторые его части.
Вот сам код:
<html > <head >Photo-galery head >
Картинная галерея.
// Пишем переменные, которые зависят от Вас // $scrpic=10; // максимальное кол-во фоток на странице$big='../pic/big_regats/'; // путь к большим картинкам $small='../pic/small_regats/'; // путь к малым картинкам $ini=$DOCUMENT_ROOT .'/avrora/pic/read/read_regats1.ini'; // путь к файлу с текстами к картинкам // //В данном случае, файл строится так: строка с названием картинки (без расширения файла) //затем строка с подписью к картинке //затем название следующей картинки и так далее. // //Например: //1|Моя первая фотография //rt|моя фотография rt.jpg //.... и так до последней картинки. Если подписи к картинке нет, то надо оставлять пустую строку. // // $kav="'"; // одинарные кавычки пригодятся нам потом в таком виде // для отображения в браузере в яваскрипте. Там необходимо иметь оба вида кавычек, // а для php надо еще поставить выводимое выражение в кавычки. $podp='увеличить'; // надпись под картинкой, // побуждающая клиента нажать на картинку для увеличения // $style_zag2='zag2-main'; // стили текста на странице $style_osn='osn-main'; // стили текста на странице $style_link='link'; // стили текста на странице // // //сама программа
$text=file ($ini); // читаем файл с подписями к картинкам в массив $text
for ($i=0; $si<sizeof ($text); $i++) { // читаем файл ини и сохраняем имена картинок. $si=$i+1; $string=explode ("|",$text[$i]); $pic[$si]=$string[0]; // присваиваем текущему элементу массива с именами файлов имя текущего файла $description[$si]=$string[1]; } $maxpic=count ($pic); // сколько файлов в папке с малыми картинкамиif ($begin=="") { // если на страницу зашли впервые, то $begin присваеваем 1 $begin=1; }$end=$begin+$scrpic-1; // $end - номер последней картинки на страницеif ($end>$maxpic) { // если последний номер на странице больше кол-во картинок в папке, // то он равен последнему
$end=$maxpic; }
$beginrew=$begin-$scrpic; // при переходе назад, начинаем показывать картинки с номера, //равному "первый номер текущей страницы минус кол-во картинок на странице" $beginfw=$begin+$scrpic; // при переходе вперед, начинаем показывать картинки с номера, //равному "первый номер текущей страницы плюс кол-во картинок на странице"
$hrefrew='назад '; // создаем ссылку "назад" $hreffw='вперед '; // создаем ссылку "вперед" $navig=$hrefrew.' '.$hreffw; // ставим между ссылками "назад-вперед" символ ""if ($beginrew<=0) { // если мы на первой странице, то ссылка назад не нужна
// $hrefrew='назад ';
$navig=$hreffw; }if ($beginfw>$maxpic) { // если мы на последней странице, то ссылка вперед не нужна
// $hreffw='вперед ';
$navig=$hrefrew; }
// вывод на экран номеров страниц галереи
$scrmax=ceil ($maxpic/$scrpic); // вычисляем, сколько страниц с картинками
for ($scr=1; $scr<=$scrmax; $scr++) { // начиная с первого номера до кол-ва страниц галереи $beginsrc=($scr-1)*$scrpic+1; // вычисляем номер картинки, // с которого будут выводиться картинки на странице if ($beginsrc==$begin) { // если страница текущая, // то ее номер выводим в виде простого текста, а не ссылки echo ' '.$scr.' '; } else { // если страница не текущая, то выводим ссылку на нее и передаем параметры: // номер картинки, с которой начать выводить на этой странице echo ' '.$scr.' '; } }
echo '
'.$navig.' ';
// вывод на экран навигации "вперед-назад"for ($i=$begin; $i<=$end; $i++) { // начиная с первой картинки на странице, // перебираем картинки вплоть до последней на странице
$descript=$description[$i];
$photo=$big.$pic[$i]; // присваиваем $photo имя малого файла+путь к папке с большими картинками $size=getimagesize ($photo); // читаем информацию о картинке $width=$size[0]+40; // получаем ширину картинки и + 40 (свободное поле вокруг картинки) $height=$size[1]+40; // получаем высоту картинки и + 40 (свободное поле вокруг картинки) $sxp=$size[2]; // получаем тип (расширение файла картинки)
$smphoto=$small.$pic[$i]; // присваиваем $smphoto имя малого файла+путь к папке с малыми картинками $smsize=getimagesize ($smphoto); // читаем информацию о картинке $smwidth=$smsize[0]; // получаем ширину картинки $smheight=$smsize[1]; // получаем высоту картинки $smexp=$smsize[2]; // получаем тип (расширение файла картинки) $winstat='toolbar=0,location =0,directories=0,status=0,menubar=0,scrollbars=1,resizable=1,width='.$width.',height='.$height; // статус открываемого окна с большой картинкой
// выводим таблицу галереи. // если номер картинки четный, то картинка слева, а описание справа и наоборот // делаем это для неужасного внешнего вида галереи // Вы можете разположить картинки как Вам заблагорассудится. // итак: ?>
// выводим одинаковую часть кода таблицы дл ячейки картинки
//Далее выводим картинки в ячейках таблиц с описаниями. Делаем все с "предпросмотром" //"предпросмотр предпочтителен, потому что не надо сразу грузить большие файлы, //а клиент если захочет, сам загрузит то, что его заинтересовало в новых окнах. // if ($i/2==ceil ($i/2)) { // если номер картинки на странице четный echo ''.$descript.'
> > >'.$podp.'
';
}
else { // если номер картинки нечетный
echo '
'.$descript.'
> >'.$podp.'
'; } }
// вывод на экран "вперед-назад"echo ''.$navig.' ';
// вывод на экран номеров страницecho '
';
for ($scr=1; $scr<=$scrmax; $scr++) {
$beginsrc=($scr-1)*$scrpic+1;
if ($beginsrc==$begin) {
echo '
'.$scr.' ';
}
else {
echo '
'.$scr.' ';
}
}
?>
html >
Программа администрирования та же, что и в варианте 1.
Вариант 3
В этом варианте используется база данных mysql вместо текстового файла для хранения описаний, имен картинок и порядка их следования.
Здесь тоже в базе хранятся именя файлов с расширениями (при варианте без расширений, будет тратиться время на пиоск картинки по описанному выше алгоритму, а при заливке картинок через вэбинтерфейс проще хранить имена файлов с расширениями).
Алгоритм работы программы такой же, что и в предыдущем примере. Однако, вместо считывания файла, считывается база галереи. Для ускорения можно было бы поместить операцию считывания в цикл вывода картинок на экран и не считывать все строки базы.
Для создания таблицы базы картинок используйте этот скрипт:
//инициализация mysql:
$mysql_login='login';
$mysql_host='host';
$mysql_pass='password';
$mysql_db='db';
//
mysql_connect ($mysql_host,$mysql_login,$mysql_pass);
mysql_select_db ($mysql_db);
mysql_query ("set CHARACTER SET cp1251_koi8") or die ("!--не могу записать"); // эта строка
используется, если сайт в кодировке win, а база в кодировке кои-8.
Если кодировки совпадают, строку надо закомментировать.
$query="CREATE TABLE galery_regats (numer tinyint(4) NOT NULL, name text NOT NULL, description text NOT NULL)";
$res=mysql_query ($query) or die ("!--не могу создать таблицу");
head er("location : admin.php"); // переход на страницу администрирования
?>
Программа администрирования:
<html >
<head >
Admin galery
head >
// логин/пароль
$log='total';
$pas='total';
//инициализация
mysql:
$mysql_login='login';
$mysql_host='host';
$mysql_pass='password'; $mysql_db='db';
//
$style_zag2='zag2-main'; // стили текста на странице
$style_osn='osn-main'; // стили текста на
странице$style_link='link'; // стили текста на странице
$kon_str="\n"; // конец строки
$razdel="|"; // разделитель между именем картинки и описанием
?>
Картинная галерея.
mysql_connect ($mysql_host,$mysql_login,$mysql_pass);
mysql_select_db ($mysql_db);
mysql_query ("set CHARACTER SET cp1251_koi8") or die ("!--не могу записать");
switch ($prov) { // проверяем состояние переменной $prov
case "edit":
// если пишем новый вариант базы:
if ($login!=$log $pass!=$pas) { echo "Введите правильно логин/пароль"; } // если пароль неверен
else {
// удаляем текущую базу картинок и создаем пустую таблицу
$query="DROP TABLE galery_regats"
$res=mysql_query ($query) or die ("!--не могу удалить таблицу");
$query="CREATE TABLE galery_regats (numer tinyint(4) NOT NULL, name text NOT NULL, description text NOT NULL)";
$res=mysql_query ($query) or die ("!--не могу создать таблицу");
$pics=explode ($kon_str,$block); // бьем наш список по символу переноса строки
for ($i=0; $i<sizeof ($pics); $i++) { // пишем в базу данные
$string=explode ($razdel,$pics[$i]); // бьем строки по символу разделителя
$query="insert into galery_regats (number, name, description) values ('$i', '$string[0]', '$string[1]')";
mysql_query ($query) or die ("!--не могу записать"); // пишем в таблицу
}
}
break;
default:
// если мы зашли не по нажатию на ентер:
// читаем базу картинок и сохраняем в массивы
$zapros="select * from galery_regats order by
numer";$res=mysql_query ($zapros);
$kol=mysql_num_rows ($res);
if ($kol==0) {
echo "Нет картинок в галерее. ";
}
for ($i=0; $i<$kol; $i++) { // читаем базу и сохраняем имена картинок.
$pic[$i]=mysql_result ($res,$i,"name"); // присваиваем текущему элементу массива
$description[$i]=mysql_result ($res,$i,"description");
}
break;
}
}
?>
<for m method=post action=" echo $PHP_SELF ; ?>">
// выводим текущее состояние базы картинок
for ($i=0; $i<sizeof ($pic); $i++) {
echo $pic[$i].$razdel.$description[$i].$kon_str;
}
?>
value="edit">
for m>
html >
Форма заполняется как и во втором варианте.
А для получения 3-го варианта в коде программы 2- го варианта строки от строки
//сама программа
до строки
$maxpic=count ($pic); // сколько файлов в папке с малыми картинками
которые являются блоком считывания файла в массивы,
заменяются на блок:
mysql_connect ($mysql_host,$mysql_login,$mysql_pass); // соединение с базой (коннект)
mysql_select_db ($mysql_db); // выбор базы
mysql_query ("set CHARACTER SET cp1251_koi8") or die ("-------------не могу записать");
// Если кодировки базы и сайта совпадают - закомментировать эту строку
$zapros="select * from galery_regats order by numer";
$res=mysql_query ($zapros);
$kol=mysql_num_rows ($res);
if ($kol==0) {
echo "Нет картинок в галерее.";
}
for ($i=0; $i
$si=$i+1;
$pic[$si]=mysql_result ($res,$i,"name"); // присваиваем текущему элементу массива с именами файлов имя текущего файла
$description[$si]=mysql_result ($res,$i,"description");
} Результат работы блока точно такой же, что и во втором варианте - массивы $pic и $description, где храним имена файлов картинок и описания к ним. Но работает такая галерея быстрее. Однако, каждый раз, когда хотите залить новую картинку, надо администрить галерею, даже если не нужно описание.А в первом варианте стоит только лишь закинуть в папки файлы картинок.
Таким образом, получаем 3 рабочих варианта программы галереи. Если будут возникать вопросы по работе программы, адаптации под "свой сайт" или по принципам, пишите мне по адресу
Тотоев Александр
Создание и реструктуризация Web-сайтов
В двух предыдущих разделах обсуждались задачи, которые касались запросов, адресованных к существующим Web-сайтам и их содержанию. Однако, принимая во внимание тот факт, Web-сайты, по существу, обеспечивают доступ к сложным структурам информации, естественно применить методы систем баз данных для создания и поддержки Web-сайтов. Можно выделить два общих класса задач создания Web-сайтов: создание Web-сайтов из некоторой совокупности внутренних (underlying) источников данных и создание их путем реструктуризации существующих Web-сайтов. Как оказалось, для обоих этих классов задач необходимы одни и те же методы. Более того, заметим, что обеспечение Web-интерфейса для данных, которые содержатся в единственной системе базы данных [NS96], является простым частным случаем задачи создания Web-сайтов.4
Для того, чтобы стали понятными проблема создания Web-сайтов и возможность импорта для этой цели технологий баз данных, перечислим те задачи, которые должен решать создатель Web-сайта: (1) выбор тех данных, которые будут представлены на сайте и обеспечение доступа к ним, (2) проектирование структуры сайта, то есть, определение данных, содержащихся на каждой странице, и связей между страницами, и (3) проектирование графического представления страниц. В существующих инструментальных средствах управления Web-сайтами эти задачи, по большей части, взаимозависимы. При отсутствии каких-либо инструментальных средств создания сайта, разработчик вручную пишет содержимое HTML-файлов или пишет программы для их продуцирования. Одновременно он должен сосредоточить свое внимание на содержании страницы, ее связях с другими страницами, а также на ее графическом представлении. В результате, весьма утомительным становится решение нескольких других важных задач, таких как автоматическое обновление сайта, реструктуризация сайта или спецификация ограничений целостности, налагаемых на структуру сайта.
Web-сайты как декларативно определенные структуры: С целью применения технологий баз данных для создания Web-сайтов было разработано несколько систем [FFK+98, AMM98, AM98, CDSS98, PF98, JB97, LSB+98, TN98].
Общая характерное свойство этих систем состоит в том, что они обеспечивают явное декларативное представление структуры Web-сайта. Структура Web-сайта рассматривается как представление, определенное над существующими данными. Однако, следует подчеркнуть, что языки, используемые для создания этих представлений, дают в результате графы Web-страниц с гипертекстовыми связями, а не простые таблицы. Указанные выше системы различаются моделями данных, которую они используют, языками запросов, а также использованием или отказом от использования промежуточного логического представления Web-сайта наряду с наличием конечного представления в формате HTML.
Создание Web-сайта, использующего декларативное представление его структуры, обеспечивает несколько важных преимуществ. Так как структура и содержание Web-сайта определяются декларативно по запросу, а не процедурным образом с помощью программы, достаточно просто могут создаваться множественные версии такого сайта. Например, возможно легко построить внутренние и внешние представления сайта организации или создать сайты, предназначенные для различных классов пользователей. В настоящее время создание множественных версий требует написания многочисленных наборов программ или создания вручную различных наборов HTML-файлов. Создание множественных версий сайта может быть осуществлено либо написанием различных запросов, специфицирующих определения версий сайта, либо путем изменения графического представления независимо от внутренней структуры. Кроме того, декларативное представление структуры Web-сайта также позволяет легко поддерживать эволюцию этой структуры. Например, чтобы реорганизовать страницы, основанные на часто используемых шаблонах [PE97], или расширить содержание сайта, просто переписывают запрос, специфицирующий определение сайта, а не перерабатывают набор программ или HTML-файлов. Декларативная спецификация Web-сайтов обладает и другими достоинствами. Например, появляется возможность формулировать и налагать на сайт ограничения целостности [FFLS98], осуществлять обновление сайта фрагментарно, когда происходят изменения внутренних данных.
Помимо этого, декларативная спецификация обеспечивает платформу для разработки алгоритмов оптимизации управления Web-сайтом с интенсивной обработкой данных на стадии исполнения. Актуальной проблемой управления Web-сайтом на стадии исполнения является автоматический поиск оптимального компромисса между предварительной обработкой частей Web-сайта и обработкой непосредственно при обращении. Отметим, наконец, что создание Web-сайтов, использующих эту парадигму, также облегчит решение задач обработки запросов к Web-сайтам и интеграции данных из множественных Web-источников.
Архитектура прототипа системы с декларативно определенной структурой показана на рис. 3. На нижнем уровне системы осуществляется доступ к множеству источников данных, содержащих те данные, которые будут обслуживаться на Web-сайте. Эти данные могут храниться в базах данных, в структурированных файлах, или на уже существующих Web-сайтах. Данные представляются в системе средствами некоторой модели данных, и система обеспечивает унифицированный интерфейс к этим источникам данных, используя технологии, подобные описанным в предыдущем разделе. Главным шагом в создании Web-сайта является спецификация выражения, которое в декларативной форме представляет структуру Web-сайта. Это выражение записывается на специальном языке запросов, предоставляемом системой. В результате применения этого запроса к внутренним данным формируется логическое представление Web-сайта в терминах модели данных системы (например, как помеченный ориентированный граф). Наконец, для фактического создания доступного для просмотра Web-сайта система содержит метод (например, HTML-шаблоны) для трансляции специфицированной логической структуры в набор HTML-файлов.
Рассмотрим теперь кратко наиболее важные характеристики различных систем. Система STRUDEL [FFK+98] использует в качестве модели слабоструктурированных данных помеченные ориентированные графы для моделирования как внутренних данных, так и Web-сайта. В этой системе используется единственный язык запросов STRUQL, служащий и для интеграции исходных данных и для определения структуры Web-сайта.
Система ARANEUS [AMM97b] использует более структурированную модель данных ADM и предоставляет язык для преобразования данных в ADM, а также язык для создания Web-сайта из данных, моделируемых средствами ADM. Кроме того, ARANEUS использует в этой модели данных специфические для Web конструкции. Система Autoweb [PF98] основана на модели проектирования гипермедийной среды (Hypermedia Design Model, HDM) - инструментальном средстве для разработки гипермедийных приложений. Модель данных этой системы базируется на модели "сущность-связь". "Схема доступа" определяет, как осуществлять навигацию и доступ к гипербазе на просматриваемом сайте. "Схема представления" определяет, каким образом представляются объекты и пути в гипербазе и схемах доступа. Во всех трех упомянутых выше системах обеспечивается строгое разделение между стадиями создания логической структуры Web-сайта и спецификации графического представления сайта. Система YAT [CDSS98] демонстрирует применение языка конвертирования данных к решению проблемы создания Web-сайта. При использовании YAT, проектировщик Web-сайта записывает множество правил преобразования исходных данных в дерево абстрактного синтаксиса, представляющее результирующие данные в формате HTML, опуская фазу промежуточного логического представления. Фактически, другие языки для конвертирования данных (например, [MZ98, MPP+93, PMSL94]) могут подобным же образом использоваться для создания Web-сайта. Система WIRM [JB97] аналогична указанным выше системам в том смысле, что она дает пользователям возможность строить Web-сайты, в которых страницы могут рассматриваться как чувствительные к контексту представления внутренних данных. Главное назначение WIRM состоит в интеграции данных медицинских исследований в рамках национального проекта по изучению мозга человека.
Создание индекса для сайта
Автор: Randal L. Schwartz Перевод Анисимова Михаила ()
Вы, может, знаете, что HTML разрешает вставлять META-тэги в заголовок документа. Тогда вы, я просто уверен, знаете для чего они нужны. Кто не в курсе - кратенько поясню: Существуют поисковые сервера, которые ползают по зарегистрировавшимся в их базе сайтах и индексируют странички. При этом они обращают пристальное внимание на МЕТА-тэги, а особенно на keywords и description (<ключевые слова> и <описание>).
Синтаксис этих двух МЕТА-тэгов выглядит так:
Ключевые слова также могут быть разделены запятой.
Ну а теперь непосредственно о скрипте. Скрипт осматривает все странички сайта на предмет meta description и meta keywords и составляет итоговую таблицу - индекс, или предметный указатель.
Строки 1-3: Обычное начало программы.
5-26: Часть скрипта, которую нужно сконфигурировать под свои нужды.
7: Список URLов, которые необходимо проиндексировать. Но если все страницы сайта связаны гиперссылками - то необходима лишь один URL.
9-24: Определение процедуры OK_TO_FOLLOW. Принимает URI-объект (http), возвращает единицу, если эту ссылку надо сканировать и нуль, если не надо.
11-13: Необходимо, чтобы скрипт не выходил за пределы сайта.
14-16: Не нужно также запускать никакие CGI-скрипты
17-22: Убираем из процесса индексации картинки и другие не-HTML файлы.
Отметьте небольшую хитрость: цикл for здесь вовсе не цикл, он нужен лишь для того, чтобы переменная $_ равнялась тому, что внутри скобок for ()
23: Передано то, что необходимо проиндексировать - вернем единицу.
28-31: Подключаем модули: CGI::Pretty - стандартный, LWP::UserAgent, HTML:Entities, WWW::Robot - входят в библиотеку LWP.
33-35: Определение глобальных переменных. %description - хэш, ключами которого являются URLы, а значениями - описания (meta description). %keywords - URL- >ключевые слова (keywords). %keywords_caps содержит регистр (верхний или нижний) написания ключевого слова.
37-45: Настройки индексатора. За подробностями обратитесь к документации по WWW::Robot. Здесь же устанавливаем, что индексатор идентифицирует себя как MetaBot, версии 0.15, ну и e-mail адрес. USERAGENT - будет LWP::UserAgent, отключена проверка MIME-типов.
47: Включает проверку конфигурации прокси-сервера, вобщем-то это и не нужно. 49-54: Одна из двух callback-функций, которую вызывает WWW::Robot. Как только найден URL, вызывается follow-url-test callback. Здесь вызываем функцию OK_TO_FOLLOW, чтобы отсеять лишнее.
55-76: Вытаскиваем информацию с каждой странички.
58-61: Нам нужны только keywords и description
63-67: Сохраним описание, предварительно очистив его от переносов строк и символов табуляции, заменив их на пробелы.
68-75: Запомним ключевые слова и их регистр. В данном скрипте предполагается, что слова разделены запятыми. Можно разделителями сделать пробелы, заменив split(/,/,... на split (/ /, ... Или и пробелы и запятые - split (/[, ]/,...
77: Запуск индексации. Для большого сайта займет довольно длительное время.
В строке 81 содержится оператор print, который продолжается до конца скрипта и выводит таблицу-индекс.
79: хэш %seen_letter нужен для того чтобы вверху странички выдать ссылки в виде букв алфавита, например:
Для каждого ключевого слова выдается ссылка на документ, где оно встречается и описание из этого документа (3 колонки в таблице).
Вот и все.
Создание news-reader'а с веб-интерфейсом.
Перевод Анисимова Михаила ()
Каждый, кто начинает программировать на Перле, сталкивается с аббревиатурой CPAN, что значит Comprehensive Perl Archive Network ("всеобъемлющий архив по Перлу") CPAN - прекрасный ресурс, где можно отыскать все что угодно, связанное с Перлом. В мире много зеркал CPAN, так что выбирайте то, которое вам ближе географически. Для этого сходите на ftp://ftp.funet.fi/pub/languages/perl/CPAN/CPAN, где есть список всех зеркал.
Немного об организации архива. Каждое зеркало центрального сервера содержит файл CPAN/Roadmap или CPAN/Roadmap.html, а также CPAN/modules/Readme, где есть описания всех содержащихся модулей. Вы скажете - Зачем нам эти модули? Мы и сами можем написать... Ну если так - то пожалуйста, пишите сами. А те, кто желает сэкономить время и силы, зайдите на CPAN и найдите для себя уже готовый модуль.
Не так давно передо мной стала задача - сделать что-то наподобие news-reader'а прямо на веб-странице. То есть: при обращении к серверу пользователь получает список сообщений в группе новостей (конференции) в виде ссылок на сами сообщения. Щелкнув по ссылке, пользователь сможет поглядеть картинку, содержащуюся в сообщении. Доступ к конференции осуществляется по протоколу NNTP.
Мне нужен был CGI, NNTP и base64 для декодирования картинок внутри сообщений. Для обеспечения CGI-интерфейса был взят модуль CGI.pm (CPAN/authors/id/LDS/CGI.pm-2.13.tar.gz). Для того, чтобы общаться с news-сервером по NNTP протоколу я нашел NNTPClient все там же на CPAN - CPAN/authors/id/RVA/NNTPClient-0.22.pm.gz. Ну и последний компонент - base64 декодировщик я нашел в модуле LWP (MIME:Base64) (CPAN/authors/id/LDS/CGI-modules-2.74.tar.gz.)
Использование библиотек, написанных не мной самим, позволило отвлечься от низкоуровневых задач, и сконцентрироваться на самом высоком уровне функционирования скрипта. Да и время сэкономило немало.
Вот такой скрипт получился в результате:
Создание нового пресс-релиза
Расширим функциональность нашей системы, добавив возможность создания новых пресс-релизов, без необходимости непосредственной работы с базой данных для пополнения таблицы tbl_news_items новой информацией.
Итак, новая Perl-программа (которая, как и предыдущие две, находится на компакт-диске) будет отличаться от предыдущих прежде всего тем, что предназначена не для отображения данных, а для их добавления в БД. Следовательно, мы должны несколько изменить часть, отвечающую за взаимодействие с БД, применив SQL-запрос INSERT и соответствующие ему операторы модуля DBI.
Строки 12-18 — это тело основной программы:
12. if ($cmd ne "add") { 13. &show_form; 14. } else { 15. $dbh = DBI->connect(‘dbi:mysql:db_website’, _ ’root’,’’); 16. &add_pr; 17. dbh->disconnect; 18. }
Здесь мы проверяем, поступила ли команда на добавление пресс-релиза в базу данных. Как только она поступила, устанавливаем соединение с БД (15), выполняем подпрограмму app_pr() (16) и завершаем соединение (17). Если же команды не было, то просто отображаем форму заполнения (13) для данных пресс-релиза — процедура show_form().
Строки 20-36 — это тело процедуры добавления пресс-релиза pr_add():
19. 20. sub add_pr { 21. $title = $q->param("pr_title"); 22. $author = $q->param("pr_author"); 23. $body = $q->param("pr_body"); 24. $body =~ s/\r\n/ /g; 25. 26. my($sql) = "INSERT INTO tbl_news_items (col_title,col_author,col_body,col_date) VALUES (\’$title\’,\’$author\’,\’$body\’,CURDATE())"; 27. $rs = $dbh->do($sql); 28. 29. if ($@) { 30. $rc = $dbh->rollback; 31. } else { 32. $rc = $dbh->commit; 33. } 34. 35. print "Location: /cgi-bin/pr-list-dbi.pl\n\n"; 36. }
Сперва обрабатываем данные формы (22-25), составляем SQL-запрос (27) и выполняем его (27) с помощью DBI-метода $dbh->do(). Поскольку здесь производится процедура вставки данных в БД, то нужно позаботиться о возможности отмены операции в случае сбоев. Для этого мы вставили код отмены транзакции и отката в предыдущее состояние (30-34). При сбое при выполнении $dbh->do() отменяем сделанные изменения (31). Если же сбоя не произошло, то подтверждаем сделанные изменения (33). Далее после всех действий просто переходим на страницу со списком всех пресс-релизов (36).
Строки 37-55 — это тело процедуры вывода формы для ввода информации о новом пресс-релизе (используется HTML-шаблон, имя которого задано в переменной $TPL_INSERT, pr-add-tpl.htm): 37. 38. sub show_form { 39. print "Content-type:text/html\n\n"; 40. 41. open (L, "$TPL_INSERT"); 42. while ($line=) { 43. chomp($line); 44. if ($line=~/\@/) { 45. if ($line=~/\@ADD\@/) { 46. $toadd = "pr-add-dbi.pl"; 47. $line =~ s/\@ADD\@/$toadd/; 48. } else { 49. $tolist = "pr-list-dbi.pl"; 50. $line =~ s/\@LIST\@/$tolist/; 51. } 52. } 53. print "$line\n"; 54. } 55. close(L);
Спец-ориентированные Java-приложения
2.1 RMI-приложения
Вызов удаленных методов (RMI - Remote Method Invocation) обеспечивает средства коммуникации между Java программами, даже если они выполняются на разных компьютерах, находящихся в противоположных точках земного шара.
Важная особенность RMI заключается в том, что он представляет программируемый интерфейс для работы с сетями в отличие от сокетов TCP. Главное преимущество его в том, что он предлагает вам интерфейс более высокого уровеня, основанный на вызовах методов, так, как если бы удаленный объект обрабатывался локально. RMI более удобен и более естественен, чем интерфейс, основанный на сокетах, но он требует выполнения Java-программ на обоих концах соединения. Сетевое соединение, тем не менеее, достигается использованием все того же TCP/IP протокола.
Рассмотрим основные шаги для построения работающего RMI-приложения:
Разработка удаленных объектов и кодов для сервера и клиента Java-компиляция RMI-компиляция Перемещение .class-файлов в соответствующие директории Регистрация Старт сервера Старт клиента
Следующий ниже пример разработан для клиента и сервера, выполняющихся на одной и той же машине, однако, заложенные здесь принципы можно с успехом применить для программ, выполняющихся на разных машинах и даже с различной архитектурой. Программа клиента ищет имена и номера телефонов в центральной базе, постоянно резидентной на сервере.
Как работает RMI
Вы определяете Java-интерфейс, чтобы описать каждый объект, который будет дистанционно разделяем, и перечисляeте общие методы, которые могут быть вызваны для объекта. Сервер будет использовать RMI-интерфейс и создаст объекты для вызова, специальным образом зарегистрированные и доступные для вызова по URL-основанной схеме, например: rmi://localhost/LookupServer
Клиент, используя эту запись, будет пытаться отыскать объект с данным именем, и получить удаленную ссылку к нему. Затем вызванный метод будет обработан с помощью RMI компилятора и преобразован из пользовательского кода в последовательную форму объекта, который передается пользователю с помощью TCP/IP.
Разработка удаленного объектного кода
RMI поддерживает объекты Java, осуществляющие связь через их методы, независимо от того, где эти объекты размещены. Первый шаг для создания класса, к которому можно обратиться дистанционно, - это определение интерфейса, описывающего методы, которые являются дистанционно-разделяемыми. // Lookup.java import java.rmi.*; public interface Lookup extends Remote { public String findInfo(String info) throws RemoteException; }
Java.rmi.Remote - пустой интерфейс, который указывает, что это удаленный объект, - так объекты класса, выполняющие Поиск(_Lookup_) отмечены удаленными ссылками. Все методы в удаленном интерфейсе должны быть объявлены через исключение типа Java.rmi.RemoteException, которое активизируется всякий раз, когда метод удаленного вызова дает сбои.
Разработка серверного кода
После того как вы определили интерфейс к удаленному объекту, нужно выполнить следующий шаг - разработать код сервера. Сервер осуществляет объектный интерфейс и создает образцы объекта, который будет дистанционно-разделяем.
Для нашего примера это будет выглядеть следующим образом:
// LookupServer.java import java.io.*; import java.util.*; import java.rmi.*; import java.rmi.server.*; public class LookupServer extends UnicastRemoteObject implements Lookup { private Vector save = new Vector(); public LookupServer(String db) throws RemoteException { try { FileReader fr = new FileReader(db); BufferedReader br = new BufferedReader(fr); String s = null; while ((s = br.readLine()) != null) save.addElement(s); fr.close(); } catch (Throwable e) { System.err.println(_exception_); System.exit(1); } } public String findInfo(String info) { if (info == null) return null; info = info.toLowerCase(); int n = save.size(); for (int i = 0; i < n; i++) { String dbs = (String)save.elementAt(i); if (dbs.toLowerCase().indexOf(info) != -1) return dbs; } return null; } public static void main(String args[]) { try { RMISecurityManager security = new RMISecurityManager(); System.setSecurityManager(security); String db = args[0]; LookupServer server = new LookupServer(db); Naming.rebind(_LookupServer_, server); System.err.println(_LookupServer ready..._); } catch (Throwable e) { System.err.println(_exception: _ + e); System.exit(1); } } }
Сервер читает в текстовой базе номера телефонов и имена и сохраняет их внутренне. Метод findInfo ищет затем нужное имя и телефон.
Пример базы данных:
Ivanov, Ivan 295-0083
Petrov, Peter 775-9958
Romanov, Alexander 555-7779
Заметим, что LookupServer является расширением стандартного класса java.rmi.server.UnicastRemoteObject и выполняет Lookup. Один из этих классов обеспечивает некоторые базисные реквизиты, необходимые для удаленных объектов, а другой определяет методы, которые будут вызваны дистанционно.
Установка службы безопасности
Наиболее сложная часть этого кода - то, что происходит в процедуре main(). Первым делом нужно установить защиту. RMI принужден загружать удаленные .class файлы и в этом смысле напоминает какой-нибудь web-браузер с его операциями по загрузке апплетов, что само по себе всегда небезопасно. Если вы не установили защиту, то по умолчанию должны загружаться только локальные файлы, и RMI по определению не может работать с такими ограничениями. Так что вы должны установить security manager, чтобы сделать возможной загрузку удаленных .class файлов.
Образец LookupServer затем регистрируется с помощью службы Naming.rebind и становится доступным клиенту по имени.
Вы могли бы задаться вопросом, как удаленный метод фактически становится вызываемым, если сервер не содержит никакого сетевого кода и никаких TCP/IP примитивов? Это происходит за сценой, поскольку сервер и клиент используют так называемые скелетоны и стабы для коммуникации между собой. Соответствующие .class файлы генерируются из серверного .class файла через RMI транслятор, описанный ниже.
Концептуально, класс stub(заглушка) выглядит так:
public class LookupServer_Stub extends java.rmi.server.RemoteStub implements Lookup, java.rmi.Remote { ... }
и скелетон - так: public class LookupServer_Skel implements java.rmi.server.Skeleton { ... }
Использование команды: Javap -c LookupServer_Stub
будет показывать байт-код и иллюстрировать то, что происходит за сценой.
Стаб(stub) -это суррогат для удаленного объекта, и скелетон - некая сущность на сервере, которая обрабатывает удаленные вызовы.
Стаб обеспечивает функции приема передачи на стороне клиента, а скелетон - на стороне сервера. При этом производится преобразование объектов в последовательную форму, а проще говоря, в поток байтов, передаваемых с помощью протокола TCP/IP
Разработка клиентского кода // LookupClient.java import java.rmi.*; import java.rmi.server.*; public class LookupClient { public static void main(String args[]) { try { RMISecurityManager security = new RMISecurityManager(); System.setSecurityManager(security); String host = _localhost_; String server = _LookupServer_; String name = _rmi://_ + host + _/_ + server; Lookup look_obj = (Lookup)Naming.lookup(name); String results = look_obj.findInfo(args[0]); if (results == null) System.err.println(_** not found **_); else System.out.println(results); } catch (Throwable e) { System.err.println(_exception: _ + e); System.exit(1); } } }
Если вы активизируете сервер, выполняя прямой клиентский запрос, то защита для пользователя определяется такая же как и на сервере. URL при этом определяется как: Rmi://localhost/LookupServer
где localhost - имя локального компьютера (IP, адрес = 127.0.0.1), используемого как сервер. Клиент располагается на той же самой машине. Вы можете также использовать и удаленную главную ЭВМ. Когда вызов к нужному методу сделан, результаты незамедлительно передаются клиенту.
Компиляция кода
Три файла - Lookup.java, LookupServer.java, и LookupClient.java компилируются как и обычно в Java: javac Lookup.java javac LookupServer.java javac LookupClient.java
Выполнение RMI компилятора
После того, как вы откомпилируете эти файлы, выполните RMI Compiler (rmic): rmic LookupServer
чтобы получить LookupServer_Skel.class и LookupServer_Stub.class файлы. Вы должны переместить клиентские файлы (Lookup.class, LookupClient.class, и LookupServer_Stub.class) в директорию, откуда вы их желаете выполнять как клиент.
Вы должны переместить серверные файлы (Lookup.class, LookupServer.class, LookupServer_Skel.class, и LookupServer_Stub.class) в директорию, где они станут доступными для публичного доступа.
Регистрация
Объект, к которому обращаются дистанционно, должен быть введен в регистр объектов, т.е. зарегистрирован. В JDK 1.1 имеется специальная программа
Rmiregistry
Rmiregistry может выполняться или в отдельном окне или как фоновый процесс на сервере.
Старт сервера
Вы должны стартовать сервер по команде: java LookupServer database_name
К примеру, если ваша база данных с набором имен и телефонов находится в файле C:\PHONE.TXT, то вы должны дать команду: java LookupServer C:\PHONE.TXT
Старт клиента
Клиентская программа стартуется по команде: java LookupClient Ivanov
_Ivanov_ - это искомое имя в базе.
Таким образом, RMI дает возможность создавать распределенные Java-to-Java прикладные программы, в которых методы удаленных объектов Java вызываются из других Java-программ на различных главных ЭВМ так как, если бы эти методы вызывались локально. Естественно, что подобные возможности можно эффективно использовать при работе с SQL-серверами, которые предоставляют Java-API интерфейс для доступа к данным. Например, в группе продуктов Informix в Informix Client SDK дано описание Informix Object Interface for Java, где приводятся многочисленные примеры, как организовать взаимодействующие RMI-приложения с доступом к базам данных Informix. Более того, имеется и соответствующий RMI-сервер, который содержит массу удобных и полезных методов, которые можно вызывать дистанционно. В сущности, приведенный выше пример можно приспособить для работы с любыми базами данных и SQL-серверами, если вы знаете каким образом устроен Java-API интерфейс для доступа к базам данных. В крайнем случае не возбраняется и использование JDBC в RMI-приложениях, хотя вряд ли это будет в достаточной степени эффективно. В Informix, например, для непосредственного взаимодействия с базами данных существуют два RMI-пакета: informix.api.remote.rmi - для удаленных клиентов и informix.api.remote.rmi.server - для rmi-сервера. При этом в клиентском приложении используется интерфейс к DBMSManager, который накапливает информацию обо всех серверах Informix и базах данных, и вы можете установить либо локальное, либо удаленное соединение с базой через RMI сервер.Для локального соединения создается DirectDBMSManager объект. Для удаленного соединения создается RMIDBMS-Manager объект и передается к соответствующему RMI серверу. Спецификация RMI сервера осуществляется в форме: rmi://hostname[:port]/ //Создание DBMSManager объекта DBMSManager getDBMSManager() throws Exception { // based on RMI Checkbox, get appropriate DBMSManager DBMSManager dbmsManager; if (RMIcheckbox.getState()) dbmsManager = new RMIDBMSManager(rmiServerTextField.getText()); else dbmsManager = new DirectDBMSManager(); return dbmsManager;
Само взаимодействие с базой осуществляется с помощью специальных транзакционных методов и методов управления курсором, которые могут вызываться как локально, так и дистанционно. В различных базах и SQL-серверах это может осуществляться по разному, но если сервер кроссплатформенный - единый и универсальный Java-API интерфейс играет немаловажную роль.
Статьи по web-дизайну
Mike Melnikov ()
Ниже приведены некоторые статьи, написанные мною с целью помочь начинающим WEB-дизайнерам. Статьи основаны на информации, распыленной в различных источниках (начиная с книг и кончая Internet, или наоборот :), а также на личном опыте.
- некоторые общие размышления, которые, тем не менее, имеют под собой твердую почву.
- для того, чтобы начать творить, нужно иметь хороший и надежный инструмент.
- хороший инструмент иметь мало - нужно его еще и освоить.
- самый первый вопрос, который можно предъявить web-сайту - для чего ты, собственно, нужен?
- почему на одни странички ходить приятно, а с других хочется уйти почти сразу?
- провожают по уму, а встречают - все же по одежке. Её величество Графика :-)
- у Вас есть красивая фотография, а если она еще и быстро пересылается, то и все остальные смогут ее оценить.
- у Вас есть красивая фотография в формате GIF ;), а если она еще и быстро пересылается, то и все остальные смогут ее оценить.
- как это влияет на нас и наших посетителей? И почему некоторым из них не нравится Ваш дизайн (как одна из возможных причин :)?
- как сделать так, чтобы посетители Ваших страничек могли отправить Вам сообщение? Краткое руководство по созданию формы на Вашей страничке и ее отсылки по почте с использованием готового CGI-скрипта.
- краткое и понятное объяснение о применении включений на стороне сервера и получаемых от этого преимуществ.
- нет-нет, это не комедия Карло Гольдони, и Труффальдино здесь ни при чем. Это... несчастный web-дизайнер, прилагающий массу усилий, чтобы угодить и приверженцам Microsoft Internet Explorer, и приверженцам Netscape Navigator.
- продолжаем наш практикум по написанию совместимых страничек. И на этот раз остановимся на правилах, применение которых позволяет резко уменьшить количество проблем с совместимостью.
- таблицы, как основное средство верстки сложного дизайна, и особенности их использования при создании совместимых страничек. - а теперь разберемся как и для чего разрезают картинки и зачем помещают их в таблицы. - невидимые таблицы - очень мощное средство.
Правильное их применение позволяет получать эффекты, другими способами довольно трудно достижимые. - Давайте-ка займемся сегодня оформлением таблиц. Вам наверняка не нравится, как оформлены таблицы по умолчанию. То, что называется рамкой, практически никогда не вписывается дизайн. А их псевдотрехмерность просто ужасна! - Итак, Вы сделали первую версию своего сайта и даже вывесили его в Internet, но через некоторое время Вы заметите, что на него практически никто не ходит, за исключением Вас и изредка Ваших друзей. - Если Вы еще не догадались, то я имею в виду META-теги. Их роль не заметна при отображении странички. Это лишь команды для web-сервера или броузера, но команды важные. - Кто об этом все знает, тот может пропустить эту статью, остальным же я поведаю о причинах возникновения различных кодировок и проблемах web-дизайна, связанных с ними. - Знание некоторых принципов возмещает незнание многих фактов. Сегодня мы поговорим о технологии сжатия JPEG и о том, за счет чего достигаются столь сильные степени сжатия. - Скриптовые языки в некотором роде перевернули мир, и именно благодаря им появился DHTML, который позволяет делать со страничкой практически что угодно. - Продолжаем разговор о применении скриптов на web-страничках. И начнем мы, пожалуй, с написания некоторых функций, которые нам впоследствии очень пригодятся. - Несколько небольших и полезных Java-скриптов позволяющих добавить к функциональности сайта некоторые приятные мелочи. - С этой статьи мы начнем разбираться с более сложными и функционально-законченными скриптами. И начнем с написания универсальной функции проверки формы перед отсылкой на сервер. - Для чего применяются фреймы? Как правильно с ними работать? Когда их лучше избегать и какие подводные камни могут подстерегать нас на этом пути? - Сегодня мы разберемся с тем, как организовать на страничке локальную баннерную систему, пользуясь только средствами JavaScript. - Как лучше всего организовать работу по созданию сайта? Чему следует уделить больше внимания? И с чего же все-таки следует начать? - Эффект, который мы сейчас рассмотрим, является, пожалуй, самым распространенным.И заключается он в смене изображения при наведении на него мышкой. Часто можно слышать английское название эффекта - RollOver, что обычно переводят как "перекатывание". - Немного специфическая статья и посвящена она решению проблем, возникающих при использовании на сайте фреймов. И, в частности, проблеме индексации таких сайтов поисковыми роботами и формированию фреймовой структуры при обращении к одной из внутренних страничек. - Поговорим о каскадных таблицах стилей. Их применение позволяет перейти на новый уровень создания сайтов и добиваться нужных эффектов оформления более простыми и логичными способами. - Продолжаем разговор о применении таблиц стилей. Сначала разберемся с каскадностью стилей, а потом перейдем к рассмотрению синтаксиса и обзору наиболее часто встречающихся параметров, применяемых при создании стилей.
Строительство приложений с помощью WML.
WML был разработан для для устройств с низкой пропускной способностью и маленьким дисплеем. В качестве составной этого дизайна была применена концепция дек и карт. Один WML-документ (а точнее элементы, содержащиеся внутри элемента ) называется декой (deck). Интерактивное взаимодействие с пользователем осуществляется с помощью карт (card). Достоинство такой реализации заключается в том, что несколько экранов могут быть загружены на клиентское устройство за один раз. Используя WMLScript, обработка действий пользователя может быть произведена с использованием находящихся в одной деке карт, исключая тем самым множественные транзакции с сервером. Конечно, в связи с ограниченными ресурсами клиентского устройства возникает другая проблема. Поэтому вам вполне возможно придется разбрасывать ваши карты по разным деками во избежании чрезмерного увеличения объема одного файла.
Структура запроса
В XQuery запрос состоит из двух частей, называемых прологом запроса (query prolog) и телом запроса (query body). Пролог состоит из серии объявлений, которые определяют среду для обработки тела. Тело запроса - просто выражение, чье значение определяет результат запроса.
Пролог нужен только в том случае, если тело зависит от одного или нескольких пространств имен, схем или функций. Если такая зависимость существует, объекты, от которых зависит тело запроса должны быть объявлены в прологе запроса. Мы обсудим по отдельности объявления для пространства имен, схем и функций.
В объявлении пространства имен определяется префикс пространства имен и указывается его привязка к URI пространства имен. Префикс может быть любым идентификатором. В следующем объявлении пространства имен определяется префикс xyz и указывается его привязка. namespace xyz = "http://www.xyz.com/example/names"
Это объявление позволяет использовать префикс xyz в именах QName в теле запроса. Префикс связывается с URI некоторого пространства имен и служит в качестве уникального квалификатора для имен элементов, атрибутов и типов. Например, xyz:billing-address может уникально идентифицировать элемент billing-address , определенный в пространстве имен http://www.xyz.com/example/names. С одним пространством имен можно связать несколько префиксов.
В прологе запроса можно объявить пространство имен по умолчанию, применяемое ко всем неквалифицированным именам элементов и топов, и еще одно пространство имен по умолчанию, применяемое ко всем неквалифицированным именам функций. Ниже иллюстрируется синтаксис объявления пространств имен по умолчанию. default element namespace = "http://www.xyz.com/example/names" default function namespace = "http://www.xyz.com/example/functions"
Если пространства имен по умолчанию не введены, то неквалифицированные имена элементов, типов или функций считаются не относящимися к какому-либо пространству имен. Неквалифицированные имена атрибутов всегда считаются не относящимися к какому-либо пространству имен.
Помимо объявлений пространств имен пролог запроса может содержать одно или несколько объявлений импорта схемы. При объявлении импорта схемы указывается URI схемы, а также может быть указан второй URI, определяющий место, где может быть найден файл схемы. Цель импорта заключается в том, чтобы предоставить процессору запросов определения элементов, атрибутов и типов, которые объявлены в указанной схеме. Процессор запросов может использовать эти определения для проверки вновь сконструированных элементов, для оптимизации и для проведения статического анализа типов в запросе.
В схеме набор элементов, атрибутов и типов обычно определяется в некотором пространстве имен, называемом целевым пространством имен (target namespace) схемы, но префикс пространства имен не определяется. Поэтому при импорте схемы можно указать префикс пространства имен, привязанный к целевому пространству имен этой схемы. В следующем объявлении импорта схемы префикс пространства имен xhtml связывается с целевым пространством имен некоторой схемы, а также системе предоставляется отдельная , позволяющая найти эту схему. schema namespace xhtml = "http://www.w3.org/1999/xhtml" at "http://www.w3.org/1999/xhtml/xhtml.xsd"
Помимо объявлений пространства имен и импорта схем пролог запроса может содержать одно или несколько определений функции. Функции, определенные в прологе запроса, могут использоваться в теле запроса или в телах других функций.
Структура
Элемент
Access
Атрибуты:
domain - имя домена для запрета доступа. Микроброузер будет просматривать и сравнивать со значением этого атрибута все имена доменов встречающиеся в документе. Так если " " броузер сможет зайти на "http://www.motorola.com/", но не сможет зайти на "http://www.rola.com/" или на "http://www.motorola.net/".
path - путь для сравнения. Работает примерно так же как и атрибут домен. Так если " " путь "/internal/wml" пройдет проверку, в то время как "/internal-wml" - нет.
Элемент "access" с примерно такими атрибутами: " " разрешит ссылку на деку только со следующих адресов:
http://www.motorola.com/spin/getuid.cgi
https://www.motorola.com/spin/index.wml
http://www.motorola.com/spin/madk/create_index.cgi?x=123&y=234
А с этих запретит: http://www.mot.com/spin/getuid.cgi
http://www.motorola.com/internal/spin/getuid.cgi
Элемент
Card
События:
onenterbackward
Сработает при выборе элемента "prev"
onenterforward
Сработает при вызове карты
ontimer
Сработает по истечении времени у элемента "timer".
Атрибуты:
id - атрибут, позволяющий сослаться на эту карточку из других элементов. Ссылка на карточку состоит из символа "#" и значения ее атрибута id (#nextcard).
title - значение этого атрибута может быть использовано для озаглавливания экрана, в котором отображается карточка, а также может появится в списке ранее посещенных страниц, а также в любом другом месте по усмотрению микроброузера.
newcontext - может быть использован для того, чтобы сбросить состояние деки. Этот атрибут может иметь значение "true" или "false".
ordered - сообщает микроброузеру принадлежит ли эта карта к упорядоченному списку карт или нет. Разработчики могут использовать этот атрибут по своему усмотрению и разрабатывать либо деку с последовательным просмотром карточек, либо состоящую из одной большой карточки.
Немного более сложная дека в качестве примера:
Start Here. Card Accept Card Accept2
ТАБЛИЦЫ СТИЛЕЙ
До сих пор при обсуждении XML я обходил стороной два важных вопроса. Первый из них касается того, как именно должны форматироваться элементы XML. (Вы наверняка пытались, но тщетно, найти инструкции по форматированию в приводимых фрагментах кода.) Второй же связан с тем, как браузеры смогут понимать нестандартные теги типа . Ответ лежит в использовании таблиц стилей. Пользующиеся умеренной популярностью в Web каскадируемые таблицы стилей (Cascading Style Sheet, CSS) позволяют изменять форматирование известных тегов HTML и определять новые теги. В частности, на Web-сервере Network Magazine таблицы стилей CSS используются для стандартизации представления типичных элементов, таких, как , и для введения новых, таких, как врезки. CSS могут служить и для форматирования документов XML, но это не очень удачный выбор. Главное достоинство XML в том, что он представляет формат документа, для возможных манипуляций, в виде древовидной структуры. К сожалению, CSS не способны взаимодействовать с деревом и могут только форматировать документы XML «как они есть». Вы можете вывести документ на экран в любом приглянувшемся формате, но не можете осуществить какое-либо избирательное представление его данных без применения языка сценариев. Более того, для использования CSS вам придется изучить еще один синтаксис. Данные ограничения привели к созданию XSL. Это приложение XML со своей собственной семантикой (фиксированным набором элементов), следовательно, оно может быть использовано для создания таблиц стилей (шаблонов документов), понятных любой программе разбора XML. Таблицы стилей XSL описывают, как документы XML должны преобразовываться в другие форматы, такие, как HTML или RTF. Но таблицы стилей XML — это нечто большее, чем просто преобразователи форматов; они также предоставляют механизм для манипулирования данными. Например, данные можно сортировать, производить по ним поиск, удалять или добавлять прямо из браузера. Давайте рассмотрим какую-либо простую таблицу стилей, которой мы могли бы воспользоваться для представленного ранее приложения Editor Contacts.
Editor Contacts Name: Title: Publication: Street Address: City: State: Zip: E-Mail:
При сохранении на диск под именем EDITORS.XSL (или любым другим) этот шаблон будет применен к EDITORS.XML при добавлении в него следующей строки после первой:
В конечном итоге текст на экране браузера будет выглядеть точно так же, как представленный ранее фрагмент HTML. Однако XSL может действовать как функция текстового процессора merge-print. Определенный как неотъемлемая часть пространства имен XSL, элемент xsl:for-each сообщает процессору о том, что он должен циклически обрабатывать все узлы в исходном файле XML. Атрибут xsl:value-of вставляет значение узла XML в элемент HTML. Таким образом, если вам придется вернуться к EDITORS.XML и вставить десятки или сотни контактных адресов, то они без каких-либо изменений будут отображаться в таблице стилей. Благодаря тому, что информацию о форматировании требуется передать только один раз, XML и XSL экономят пропускную способность. Таблицы стилей XSL имитируют функцию merge-print еще и в том, что они позволяют избирательно опускать поля данных при отображении.
Кроме того, вывод может быть отсортирован по любому конкретному полю данных. Для сортировки базы данных контактных адресов по фамилии редактора в прямом алфавитном порядке элемент xsl:for-each следует изменить следующим образом:
XSL способен также осуществлять условную трансформацию вывода в зависимости от значений различных элементов или атрибутов. Более того, он позволяет запрашивать данные с использованием множества разнообразных операторов шаблонов, символов подстановки, фильтров, булевых операторов и выражений множества. XML и XSL никоим образом не предназначены для замены SQL, к тому же вряд ли найдется много желающих хранить свои базы данных непосредственно в формате XML. Однако XSL открывает возможность разнообразного поиска по данным после их загрузки в браузер. Вам никогда уже не понадобится использовать для поиска информации примитивную встроенную команду браузера Find.
Значительный потенциал XML в качестве промежуточного программного обеспечения подкрепляется объектной моделью документа (Document Object Model, DOM), версия 1.0 которого была принята в качестве рекомендации W3C в октябре 1998 года. DOM возникла как спецификация для обеспечения переносимости сценариев JavaScript и программ на Java между браузерами Web и позднее эволюционировала в API для документов HTML и XML. Она определяет логическую структуру документов, способы доступа и манипулирования ими. Программисты могут создавать документы, управлять их структурой и добавлять, модифицировать или удалять элементы и содержимое.
DOM не оказывает никакого влияния на то, как следует писать документы XML и HTML. Вместо определения набора структур данных она представляет документы в соответствии с объектной моделью, такой, как древовидная структура, состоящая из узлов. Нет никакой необходимости использовать DOM просто для просмотра документов XML из браузера. Она применяется, когда по сценарию требуется изменить документ XML или обратиться к его данным.На сервере DOM может применяться для анализа поступивших от клиента файлов XML и соответствующей реакции на них. Кроме того, программистами DOM может использоваться в качестве промежуточного уровня для преобразования из формата базы данных в XML. При правильной реализации интерфейсов DOM пользователям никогда не потребуется знать, что данные хранятся в каком-либо ином формате, а не в XML.
Таймер
Элемент:
timer
Атрибуты:
value - промежуток времени в десятых долях секунды.
Wait ten seconds Подождите минутку
Tamino - информационный сервер для электронного бизнеса
Деловой мир развивается все стремительнее, и, в свою очередь требует пересмотра и создания новых бизнес-процессов, которые должны быть реализованы за короткое время для того, чтобы сохранить конкурентноспособность предприятия. Электронный бизнес и работа в Интернет, находящиеся сегодня на периферии корпоративных ИТ, должны будут объединиться с последними.
Это обстоятельство приводит к необходимости создания такой инфраструктуры ИТ, в которой новые приложения смогут работать совместно с существующими компонентами, прикладными системами и людскими ресурсами. В то время как быстрое развитие электронного бизнеса и развитие будущих рынков предполагает состояние "перманентной революции", сохранение инвестиций, сделанных в оборудование, обслуживающий персонал клиента, требует принятия более эволюционных мер. ИТ должна быть способна реализовать радикальные изменения и быстро, и по возможности - плавно.
Вместе с тем электронный бизнес ставит новые проблемы:
Необходимость быстрой адаптации технологии в соответствие с быстро изменяющимися требованиями рынка Обеспечение соответствия скоростям передачи данных, иногда изменяющимся на порядки величин Необходимость соединения существующих островов ИТ без дублирования существующих промышленных решений Требование сокращения расходов на программирование в среде Интернет и администрирование серверов.
Tamino был создан для решения именно этих проблем.
ТЕГ — ЭТО СООБЩЕНИЕ
ICE является далеко не единственным предложенным стандартом, где XML применяется для определения коммуникационного протокола. К слову сказать, уже один тег , как он определен в BizTalk, помещает отраслевые множества данных на конвейер сообщений. Так, еще несколько протоколов Internet аналогично описываются с помощью XML. Это, например, Platform for Privacy Preferences (P3P) и Synchronyzed Multimedia Integration Language (SMIL, произносится как «смайл»). И не приходится сомневаться, что вскоре появятся еще.
Эти детища двух инициатив — одной, стремящейся более строго и полно регламентировать, что должен собой представлять правильно составленный документ XML, и второй, решившей применить XML к «диалоговым» приложениям, — показывают, что XML не удастся подвести под одну мерку.
В своей основе XML очень прост, но в реальном мире разные задачи, такие, как преобразование стилей, спецификации печатных данных и иерархические схемы, смешиваются настолько энергично, что в результате мы рискуем получить барочный букет угловых скобок. Однако с учетом того, что инструменты для упорядочения хаоса XML становятся все лучше, вполне вероятно, что его усложнение будет иметь положительный эффект, так как оно позволит решить с помощью XML и другие задачи вычислительного мира. Но мы должны считаться с фактом, что, как и HTML до него, XML имеет самостоятельную ценность и круг задач.
Роберт Ричардсон — внештатный редактор Network Magazine. Он организовал бесплатный электронный журнал Small Office TECH по адресу: .
Технологии баз данных для World-Wide Web: обзор
Даниэла Флореску, Алон Леви, Альберто Мендельсон
Журнал , #04-05/98
Технология Tamino
С выпуском Tamino компания Software AG представляет новое поколение СУБД, первый в мире информационный XML-сервер, являющийся быстродействующим, надежным, высоко масштабируемым продуктом, основанным на открытых стандартах. Компоненты Tamino обеспечивают решение поставленной задачи - обеспечивать быстрый, но плавный процесс изменения ИТ - поскольку Tamino объединяет технологии Интернет с современными достижениями в области разработки баз данных и средств доступа к существующим базам данных. Информационный сервер Tamino представляет собой совершенно новую разработку интегрированного решения, включающего в себя:
Технология X-Machine
Высокопроизводительный инструмент для хранения XML-данных в их оригинальном виде, включая возможность подключения функциональных расширений сервера, написанных пользователем, для выполнения различных операций преобразования документов.
Технология X-Machine позволяет хранить и искать объекты данных, относящихся к бизнес-процессам, в их оригинальном виде. X-Machine представляет собой первую в мире реализацию истинной базы данных XML.
Tamino поддерживает XML V.1.0, язык ссылок XLL, таблицы стилей XSL и подмножество XQL, а также концепцию пространства имен XML.
X-Machine включает в себя:
XML-процессор
Объекты XML, запоминаемые в XML-хранилище, описываются соответствующей схемой данных, выраженной в правилах отображения. Данная информация хранится в базе данных Tamino. Внутренний XML-процессор выполняет проверку правильности синтаксиса описателей объекта и отвечает за синтаксическую корректность (well-formed) структуры объектов XML. Процессор объектов
Процессор объектов используется при запоминании объектов XML в XML-хранилище. При этом структурированные данные (данные РСУБД) запоминаются в таблицах и колонках, соответствующих Описанию схемы. Обмен с внешними источниками данных выполняется с помощью компонента X-Node. Интерпретатор запросов XML
В качестве языка запросов используется XQL. Интерпретатор запросов обрабатывает полученный запрос совместно с Генератором объектов в целях поиска и формирования результата в виде XML-документа. Генератор объектов (Object Composer)
Данный компонент используется при поиске и чтении объектов. Используя уникальные идентификаторы объектов, сформированные X-Machine при их запоминании, Генератор объектов конструирует информационные объекты и возвращает их как результат выполнения запроса в виде XML-документов. В простейшем случае информационные объекты будут объектами XML. В сложных запросах для конструирования XML-объекта из традиционных источников данных Генератор объектов будет обращаться к Tamino X-Node или Tamino SQL Engine. Программы обслуживания
Tamino предоставляет ряд программ обслуживания информационного сервера. В качестве главного примера может служить программа загрузки XML-объектов (аналог утилиты массовой загрузки данных в традиционных СУБД).
Tamino SQL Engine
С помощью SQL-процессора реализованные в Tamino средства отображения данных в XML позволяют автоматически решать задачу их представления в виде объектов Интернет, и наоборот, информационные объекты Интернет могут стать доступными в виде реляционных данных для стандартных приложений, ориентированных на SQL.
Для поддержки работоспособности SQL приложений, в состав Tamino входит SQL-процессор, обеспечивающий также и среду хранения реляционных данных. SQL-процессор поддерживает выполнение операторов SQL версии 2 в части манипулирования определения и управления данными (DML, DDL, DCL), а также выполнение ACID-транзакций.
SQL-процессор получает SQL-запросы от Tamino несколькими способами:
Внутренние обращения Tamino X-Machine SQL-приложения либо с помощью встроенного SQL, либо с помощью стандартных интерфейсов ODBC, JDBC, OLE DB. Диспетчер Tamino
Кроме того, SQL-процессор предоставляет препроцессоры для компиляторов со стандартных языков программирования.
Диспетчер Tamino
Инструментарий для администрирования объектов Tamino в Интернет. Для выполнения функций администрирования (создание базы данных, запуск/остановка сервера, сохранение/восстановление, загрузка данных, и т.д.) в состав диспетчера Tamino входит агент, устанавливаемый на каждом узле, где развернут сервер Tamino.
Кроме того, Диспетчер Tamino взаимодействует с Генератором схемы Tamino для настройки параметров XML-процессора (Parser), задания правил отображения данных и установки программ-расширений сервера Tamino.
Расширения сервера
Архитектура Tamino позволяет пользователям встраивать специализированные функции для дополнительной обработки информации, обеспечивающие возможности работы с данными, хранящимися в Tamino, которые, в свою очередь, могут быть представлены как XML, так и не-XML структуры. Программы-расширения сервера устанавливаются на узле сервера с помощью Диспетчера Tamino, и, будучи установленными, доступны пользователям как стандартные встроенные функции сервера.
Кроме того, расширения сервера могут использоваться для реализации динамического отображения данных, т.е. преобразования структуры XML в структуру РУСБД на основании значения элемента документа.
Расширения сервера являются составной частью Tamino, и могут быть написаны на C, C++ или на других языках, поддерживающих COM/DCOM. Предлагаемый инструментарий среды разработки оснащен помощниками (Wizards), упрощающих процесс написания программ. Применение расширений сервера позволит уменьшить нагрузку на сеть за счет перевода обработки данных с клиента на сервер.
Описание схемы
Компонент Описание схемы (Schema Description) Tamino составляет его базу знаний, содержащую правила отображения, хранения и конструирования объектов XML. Правила построения объектов основаны на информации о схеме данных, поддерживаемой администратором сервера. Правила используются для:
Отображения структур XML во внутреннюю структуру XML-хранилища, обеспечивая хранение XML-документов в их исходном виде Отображения структур XML в структуры существующих СУБД и наоборот, что делает возможным объединение данных из разнородных источников Отображения структур существующих файлов Adabas Отображения структур XML в структуру другого сервера Tamino
Правила построения и отображения структур данных поддержаны соотвествующим графическим инструментарием, входящим в состав Администратора Tamino.
X-Node
С помощью компонента Tamino X-Node пользователь получает доступ к разнородным и распределенным источникам данных. В качестве источников данных могут быть базы данных, файловые системы, или данные, полученные из систем передачи сообщений. Компонент X-Node позволяет представить прикладной программе все эти источники, как единый источник необходимых данных, независимо от их физического расположения. X-Node позволяет перегруппировывать данные, объединять существующие базы данных с новыми источниками данных, поскольку все обрабатываемые данные представляются в виде одного объекта XML.
С помощью X-Node предоставляется возможность использования существующих баз данных предприятия в их существующем виде и на существующих платформах, обеспечивая доступ к ним из Интернет.
Tamino SDK
Комплект инструментальных средств разработки приложений, обеспечивающий взаимодействие Tamino с XQL, SQL или объектно-ориентированными приложениями (DOM), и состоит из набора следующих интерфейсов:
Интерфейс прямого доступа к объектам XML с помощью традиционной их адресации по URL. Интерфейс языка запросов XQL, существующего в настоящее время в виде проекта стандарта. Интерфейсы OLE DB, ODBC, JDBC и DCOM для приложений, использующих SQL и объектно-ориентированные технологии.
Tamino поддерживает спецификации модели DOM на уровне W3C's Document Object Model Recommendation Level 1, что делает возможным предоставлять клиентам объекты XML как объекты DOM. Данная возможность позволяет приложению получить доступ к элементу документа, обработать его и изменять его значения. Модель DOM реализована на сервере в виде интерфейса с прикладной программой клиента, что поддерживает идеологию "тонкого" клиента.
Текст
У элемента p нет атрибутов
У элемента br нет атрибутов
Telnet
Команда telnet позволяет вам ``войти" в терминальный сеанс работы с удаленным компьютером. Формат команды:
telnet [ remote_host ]
где remote_host представляет собой адрес удаленной машины. Пример:
telnet aries
В ответ вы получите обычное приглашение с удаленной машины. Вы вводите свое имя и пароль и оказываетесь в режиме терминальной работы с машиной aries. Для разрыва связи и возвращения на локальную машину используйте команду exit.
Имя удаленной машины в командной строке telnet'а является необязательным параметром. Введя команду telnet без параметров вы немедленно получите приглашение telnet> и теперь, пользуясь командами самого telnet'а вы можете установить соединение с удаленной машиной или настроить параметры telnet'а. Наиболее полезной командой telnet'а для начинающих пользователей является команда ``?", выдающая краткую справку по командам telnet'а. Пример работы с командами telnet'а:
% telnet
telnet> ?
Commands may be abbreviated. Commands are:
close close current connection
display display operating parameters
mode try to enter line-by-line or character-at-a-time mode
open connect to a site
quit exit telnet
send transmit special characters ('send ?' for more)
set set operating parameters ('set ?' for more)
unset unset operating parameters ('unset ?' for more)
status print status information
toggle toggle operating parameters ('toggle ?' for more)
slc change state of special charaters ('slc ?' for more)
z suspend telnet
! invoke a subshell
? print help information
telnet> quit
%
Если вы уже установили терминальную связь с удаленным компьютером вы можете вернуться в командный режим telnet'а с помощью ввода управляющей последовательности < Esc> (если на клавиатуре вы не нашли такой клавиши, вы вводите < Esc> с помощью одновременного нажатия двух клавиш Ctrl-[). Это обычно используется для изменения коммуникационных параметров.
Более подробную информацию о формате и назначении команд telnet'а вы можете получить дав следующую команду на приглашение telnet'а:
telnet> ? command
где command - имя команды по которой вы хотите получить подробную справку.
Тип 'Application'
Этот тип используется для данных, неподпадающих под остальные категории, в частности, для данных, обрабатываемых прикладными почтовыми программами. Это информация, которая должна быть обработана соответствующим приложением для того, чтобы принять наглядную либо исполняемую для получателя форму. Предполагаемое использование для этого типа включает в себя пересылку файлов по почте, таблицы, данные для почтовых систем расписания, языки лдя "активной" (вычислительной) почты. (Последняя, в частности, может поднять проблемы безопасности, которые должны быть поняты разработчиками ПО и рассмотрены ниже в параграфе "Application/PostScript").
Например, тот, кто занимается расписанием встреч, может определить стандартное представление информации о датах запланированных встреч. "Умный" пользовательский почтовый агент может использовать эту информацию для проведения диалога с пользователем, и может затем посылать в дальнейшем почту, основанную на том диалоге. Вообще, существует несколько "активных" почтовых языков, разработанных для специализированных программ, которые посылаются по почте и автоматчески запускаются в системе получателя.
Подобные приложения могут быть определены как подтипы для типа "application". Изначально предопределено два подтипа: "octet-stream" и "PostScript".
В общем, подтип для 'application' зачастую может быть именем приложения, для которого предназначены пересылаемые данные. Однако, это не означает, что любое имя прикладной программы может свободно использоваться как подтип для 'application'. Такие употребления (кроме подтипов, начинающихся с "x-") должны быть зарегестрированы в IANA.
Тип 'Audio'
Этот подтип означает, что тело содержит аудио-данные. Хотя пока еще нет консенсуса по "идеальному" аудио-формату для компьютеров, сейчас имеется сильная потребность в универсальном формате.
Предопределенный подтип - "basic" введен в ответ на это требование, обеспечивая минимальный примитивный аудио-формат. Ожидается определение в дальнейшем более "богатых" форматов, обеспечивающих более высокое качество воспроизведения.
Содержимое тела, имеющего подтип "audio/basic", - аудио-данные в 8-битной форме, кодированные с использованием ISDN mu-law. Формат, соответствующий этому подтипу, предполагает максимальную частоту звучания 8000 Hz и единственный канал.
Формальный синтаксис лдя поля 'Content-Type': audio_тип := "audio" "/" ("basic" / подтип-расширение)
Тип 'Image'
Этот тип означает, что тело письма содержит графический объект. Его подтипы соответствуют конкретным графическим форматам. Их значения нечувствительны к регистру букв. Два предопределенных подтипа - "jpeg" для формата JPEG с кодированием JFIF, и "gif" - для формата GIF.
Формальный синтаксис поля 'Content-Type': image_тип := "image" "/" ("gif" / "jpeg" / подтип-расширение)
Тип экрана (BIOS совместимость)
Этот параметр обычно устанавливается в файле конфигурации. Установка Direct to screen означает быструю запись информации непосредственно на экран. Но при этом могут возникнуть проблемы если на локальной машине используется Windows, который пишет на экран через BIOS. Для обеспечения Windows совместимости можно установить соответствующий параметр.
Тип 'message'
При пересылке почты часто возникает необходимость включить внутрь письма другое письмо. Для этого и используется тип 'message'.
Основной подтип - "rfc822" - не требует параметров в поле Content-Type. Дополнительные подтипы - "partial" и "External-body" - предполагают наличие параметров.
ЗАМЕЧАНИЕ: Для перенаправляемой и возвращаемой почты можно было бы определить отдельные подтипы, однако, такая почта может пересылаться как multipart-письмо, в котором первая часть содержит некоторую пояснительную текстовую информацию, а другая, имеющая тип 'message/rfc822', содержит перенаправляемое/возвращаемое письмо. Подобный способ перенаправления/возвращения почты сохраняет информацию о типе оригинального письма и позволяет ему быть корректно представленным получателю, и поэтому настоятельно рекомендуется.
Тип 'multipart'
Этот тип используется, если один или более различных наборов данных заключены в одном письме. Каждая часть тела должна иметь синтакс письма RFC 822 (то есть, иметь заголовок,ь пустую строку и тело), но должна иметь открывающую и закрывающую границы.
Часть письма не должна интерпретироваться как настоящее письмо RFC 822. Вообще, для части письма наличие заголовка не обязательно, так что она может начинаться и с пустой строки, но при этом, все признаки, описываемые в заголовке, имеют значение по умолчанию. Для частей письма имеют смысл только поля, описывающие содержимое, то есть. начтинающиеся с "Content-". Все остальные поля, необходимые в заголовке верхнего уровня, обычно игнорируются в частях письма при обработке почты, более того, в некоторых почтовых шлюзах они могут быть просто удалены. Для экспериментальных и частных целей могут использоваться "X-" поля, но информация, в них заложенная, может быть потеряна при прохождении некоторых почтовых шлюзов.
ЗАМЕЧАНИЕ: Различие между письмом RFC 822 и частью письма MIME является маленькой, но важной. Шлюз между почтой Internet и X.400, например, должен иметь возможность отличить часть письма, содержащую графическое изображение, от части письма, содежащей вложенное письмо, телом которого является графическое изображение. Для представления последнего соответствующая часть письма должна иметь "Content-Type: message" и ее тело после пустой строки должно являться вложенным письмом со своим собственным полем заголовка "Content-Type: image". Схожесть синтаксиса обеспечивает легкость конверсии от письма к части письма, но различие между ними должно быть усвоено производителями ПО.
Граница части письма не должна появляться внутри самой части письма.
Все существующие и будущие подтипы типа "multipart" должны иметь идентичный синтаксис. Они могут различаться своей семантикой. Это требование гарантирует, что совместимые пользовательские агенты смогут по крайней мере распознать и разделить части многочастного письма, даже имеющего неизвестный им подтип.
Как упомянуто в определении поля Content-Transfer-Encoding, использование других значений кроме "7bit", "8bit" или "binary" запрещено для типа "multipart". Почтовые шлюзы и другие почтовые агенты часто вносят изменения в заголовки верхнего уровня. В частности, они могут добавлять, убирать, переупорядочивать определенные поля. Такие изменения запрещены для заголовков частей письма, находяшихся внутри тела типа "multipart".
Тип терминала
По умолчанию устанавливается эмуляция терминалов VT102 и Textronix. При необходимости можно сузить эту интерпретацию команд установив а) Только VT102 и графические команды Textronix игнорируются или б) Простой терминал без какой бы то ни было эмуляции.
Тип 'Text'
Тип 'text' предназначен для пересылки текстовых материалов. Это значение поля - по умолчанию. Для обозначения языковой кодировки текста используется параметр "charset" для некоторых подтипов, включая основной подтип, "text/plain", соответствующий простому (неформатированному) тексту. В Internet'овской почте значением Content-Type по умолчанию является следующее: "text/plain; charset=us-ascii". Если текст является размеченным и нет соответствующего ПО для корректного визуального представления этого текста пользователю, имеет смысл сообщить ему подтип этих текстовых данных.
Тип 'Video'
Этот тип означает, что в теле письма содержится анимационное изображение, возможно, со звуком и цветом. Термин "video" используется безотносительно к технологии получения подвижного во времени изображения. Подтип "mpeg" указывает на видео, кодированное в соответствии со стандартом MPEG.
Хотя MIME-стандарт запрещает смешение разнородных мультимедийных данных в одном теле (письма или части письма), многие так называемые "video"-форматы включают синхронизированный звук, что допускается для подтипов типа "video".
Формальный синтаксис лдя поля 'Content-Type': video-type := "video" "/" ("mpeg" / подтип-расширение)
Типы
При создании запроса иногда необходимо сослаться на некоторый тип. Например, как уже было отмечено, при определении функции требуется описать типы параметров функции и ее результата. В других видах выражений XQuery также требуется возможность ссылаться на некоторые типы.
Один из способов сослаться на тип - это указать его квалифицированное имя, или QName. QName может указывать на встроенный тип, такой как xs:integer , или на тип, который определен в некоторой схеме, такой как abc:address . Если в QName имеется префикс пространства имен (часть, расположенная слева от двоеточия), этот префикс должен быть привязан к некоторому идентификатору пространства имен. Это связывание достигается путем описываемого в следующем разделе объявления пространства имен в прологе запроса.
Еще один способ сослаться на тип - сделать это с помощью родового ключевого слова, такого как element или attribute . За этим ключевым словом может следовать QName, которое в большей степени ограничивает имя или тип узла. Например, element обозначает любой элемент, element shipto - любой элемент с именем shipto ; и element of type abc:address означает элемент, тип которого - address , объявленный в пространстве имен abc . Ключевое слово attribute обозначает любой атрибут, node - любой узел, а item - любой объект (узел или атомарное значение).
В XQuery также предусмотрен дополнительный синтаксис, который позволяет ссылаться на другие виды узлов и на типы элементов, которые определены в локальной части схемы. Например, element city in customer/address указывает на элемент с именем city , как это определено в контексте схемы customer/address .
За ссылкой на тип может следовать один из трех индикаторов присутствия: означает , означает , а означает . Отсутствие индикатора присутствия означает присутствие ровно одного экземпляра указанного типа. Проиллюстрируем использование индикаторов присутствия. element memo? означает возможное появление элемента с именем memo
element of type order+ означает один или несколько элементов с типом order
element* означает любое число любых элементов
attribute? означает необязательный атрибут с любым именем и типом
<
Ссылки на тип появляются не только в определениях функции, но и других местах. Одно из таких мест - второй операнд операции instance of , которая возвращает true , если ее первый операнд является экземпляром типа, указанного во втором операнде. Следующие примеры иллюстрируют использование операции instance of (предполагается, что префикс xs привязан к пространству имен схемы ). 49 instance of xs:integer возвращает true
"Hello" instance of xs:integer возвращает false
369 instance of element*возвращает true
$a instance of element shipto возвращает true , если $a привязана к элементу с именем shipto
Первая часть typeswitch состоит из выражения, тип которого проверяется (выражение операнда, operand expression), и необязательной переменной, связываемой со значением выражения операнда. Далее следуют одно или несколько операторов case, каждый из которых содержит тип и выражение. Операнд выражения по очереди проверяется на соответствие типу, указанному в каждом из условий case. Первый оператор case, для которого операнд выражения является экземпляром заданного типа, называется действующим случаем (effective case); выражение в этом операторе case вычисляется и служит результатом typeswitch . Если выражение операнда не соответствует ни одному из типов, указанных в условиях case, результат typeswitch берется из последнего оператора, действующего по умолчанию.
Проиллюстрируем использование typeswitch . Это выражение может появиться в цикле, где переменная $customer итерируется над множеством элементов customer, каждый из которых имеет подэлемент с именем billing-address . Подэлементы billing-address могут относиться к нескольким различным типам, каждый из которых требуется обрабатывать особым образом. Переменная $a связывается с billing-address , а затем вычисляется одно из нескольких выражений, в зависимости от динамического типа $a . В каждом операторе case $a имеет особый тип, например, в первом условии case типом $a должен быть element of type USAddress .
Если выясняется, что элемент billing-address не соответствует ни одному из ожидаемых типов, результатом выражения является . typeswitch ($customer/billing-address) as $a case element of type USAddress return $a/state case element of type CanadaAddress return $a/province case element of type JapanAddress return $a/prefecture default return "unknown"
Имена типов также используются в трех внешне похожих выражениях XQuery, называемых cast, treat и assert . Каждое из этих выражений содержит ключевое слово, ссылку на тип и выражение, заключенное в скобки.
Выражение cast служит для преобразования результата выражения к одному из встроенных типов XML Schema. Поддерживается предопределенный набор преобразований. Например, результат выражения $x div 5 может быть приведен к типу xs:double с помощью выражения cast as xs:double($x div 5) . В случае неудачного выполнения операция приведения типа может вернуть значение ошибки. Например, выполнение cast as xs:integer($mystring) будет успешным, если $mystring - строковое представление integer , но вернет ошибку, если $mystring имеет значение . Выражение cast не может использоваться для приведения значения к типу, определенному пользователем; для этого ему следует написать специальную функцию.
Выражение treat позволяет гарантировать, что динамический (времени исполнения) тип выражения соответствует предполагаемому типу. Например, предположим, что статическим(времени компиляции) типом выражения $customer/shipping-address является Address . Некоторое подвыражение может иметь смысл только для значений, соответствующих подтипу Address , такому как USAddress . Создатель подвыражения может использовать выражение treat для объявления ожидаемого типа подвыражения. treat as USAddress($customer/billing-address)
В отличие от cast , выражение treat на самом деле не меняет тип операнда. Выполнение происходит в два этапа: (1) операнду присваивается некоторый статический тип, который может использоваться для проверки типа при компиляции запроса; (2) во время выполнения, если реальное значение выражения не соответствует указанному типу, возвращается значение ошибки.
Чтобы понять, как процессор запросов мог бы использовать информацию, предоставляемую выражением treat , рассмотрим следующий пример. $customer/billing-address/zipcode
Компилятор XQuery, проверяющий типы, мог бы решить, что в этом примере имеется ошибка типа, поскольку статическим типом $customer/billing-address является Address , а тип Address , в общем случае, не имеет подэлемента zipcode . Однако в следующей формулировке статический тип выражения меняется на USAddress , у которого есть подэлемент zipcode , и ошибка типа исчезает. (treat as USAddress ($customer/billing-address))/zipcode
Как и treat , выражение assert используется для предоставления процессору запросов информации, которая может оказаться полезной для проверки типов. Выражение assert сообщает процессору запросов, что его выражение операнда имеет некоторый статический тип. Если процессор производит статическую проверку типов, он может породить ошибку, если окажется не в состоянии проверить, что данное выражение соответствует заявленному типу. Выражение assert является более строгим, чем выражение treat , поскольку оно относится к статическому типу выражения и, следовательно, не зависит от входных данных и может быть проверено перед выполнением запроса. С другой стороны, выражение treat относится к динамическому типу выражения и, как следствие, зависит от входных данных и может быть проверено только при выполнении запроса.
В следующем примере будет генерироваться ошибка типа времени компиляции, если статическим типом $customer/billing-address является Address . (assert as USAddress ($customer/billing-address))/zipcode
В XQuery не требуется, чтобы в реализации поддерживалась статическая проверка типов. Для процессора запросов, который не обеспечивает статическую проверку, assert эквивалентно treat .
ТО, ЧТО ВЫ ВИДИТЕ, — ЭТО ВСЕ, ЧТО ВЫ ПОЛУЧАЕТЕ
По сути, HTML — это технология представления информации, он описывает то, как браузер должен скомпоновать текст и график на странице. В результате «то, что вы видите, — это все, что вы получаете». Нет никакого способа описать данные независимо от отображения этих данных (за исключением чрезвычайно слабой системы ключевых слов в заголовке страницы Web). Это главная причина, почему так трудно найти нужную информацию с помощью механизма поиска.
Клиент не имеет никаких более-менее приемлемых средств извлечения данных со страницы Web для дальнейшей работы с ними. При наличии твердой руки вы можете вставить содержимое таблицы HTML в электронную таблицу, но это не решение! Далее, на любой конкретной странице Web клиент получает только одно представление конкретного множества данных.
Предположим, что вы просматриваете список аукционов eBay, упорядоченный по дате открытия торгов. Если вы захотите взглянуть на тот же список, но отсортированный по дате закрытия торгов, то вашему браузеру придется посылать новый запрос серверу. В свою очередь серверу придется заново отправлять полную страницу HTML со списком аукционов. Такого рода манипулирование данными ведет к значительному увеличению числа обращений к серверам Web и затрудняет, таким образом, их дальнейшее масштабирование.
Другая проблема с HTML в том, что это «плоский» язык, т. е. авторы не могут использовать его для предоставления информации об иерархии данных. Далее, он непоследователен и поэтому затрудняет разбор текста программным обеспечением. Например, хотя большинство открывающих тегов (такие, как или ) имеет соответствующие закрывающие теги, некоторые (например, ) их не имеют.
Простым решением для некоторых из перечисленных проблем было бы введение дополнительных тегов HTML, таких, как , или . С их помощью клиент мог бы определить, что собой представляют данные, и отображать их по-разному или экспортировать по запросу пользователя. История, однако, показывает, что введение дополнительных тегов для HTML может занять годы; консенсуса по поводу того, что они должны значить, редко когда удается достичь быстро, если он вообще возможен.
Если же вы решите не дожидаться изменения стандарта, то имейте в виду, что вы создаете нечто свое, нестандартное и тем самым отказываетесь от одного из главных преимуществ HTML.
Поэтому в 1996 году члены рабочей группы Консорциума World Wide Web (W3C, http://www.w3.org) вернулись к рассмотрению стандартного обобщенного языка разметки (Standard Generalized Markup Language, SGML), сильно упрощенным потомком которого является HTML. Предложенный в 1974 году Чарльзом Голдфарбом, SGML представляет собой метаязык — систему для описания других языков. При всех своих возможностях он слишком сложен для большинства браузеров Web: одна спецификация SGML занимает свыше 500 страниц.
Упростив SGML для использования с Web, группа предложила XML (рекомендация W3C по статусу на февраль 1998 года). XML представляет собой подмножество SGML, причем любой действительный документ XML является действительным документом SGML. И, как и SGML, XML — это метаязык, определяющий другие языки разметки для специфических целей. Например, язык синхронизированной интеграции мультимедиа (Synchronized Multimedia Integration Language, SMIL) базируется на XML.
XML используется для разметки стандартных документов во многом так же, как HTML. Однако XML превосходит его при работе со структурированными данными, такими, как результаты запроса, метаинформация об узле Web или элементы и типы схемы.
Документ XML выглядит во многом похожим на HTML. Он также состоит из текстовых фрагментов, аннотированных заключенными в угловые скобки тегами. Однако, в отличие от HTML, смысл тега зависит от регистра, а каждый открывающий тег должен во всех случаях иметь парный закрывающий тег.
ТРАНСПОРТ ДАННЫХ
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 - заголовок. В зависимости от микроброузера может не выводиться на экран.
Bogus: uno eins dos zwei Single Multiple Pick your fav Stooge: Moe Shemp Larry Curley Curley Joe Pick your fav Marx Bro. Groucho Harpo Chico Zeppo Your fav was $fav.
Элемент:
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 - Заголовок
Field Type: Nested Password First Name: Last Name: Gender: Male Female $fname $lname is a $gender. Input a password: Min 3 chars. Password was $passwd.
Установка 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."! "; 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 $f[a] \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
Затем скачайте дистрибутив Perl - файл с именем (436.137 байт), желательно в только что созданную директорию. Это саморазворачивающийся архив, Вам нужно будет просто его запустить, чтобы разархивировать в текущую директорию. (Заметим, что версия Perl в этом архиве довольно стара и пригодна разве что для демонстрационных целей. В частности, в ней нет ни одного стандартного модуля. Поэтому, если Вы хотите использовать Perl в сколько-нибудь серьезных целях, Вам придется установить более свежую версию. Как это сделать описано в . Все же рекомендуем Вам установить сначала предлагаемый дистрибутив, благо он очень маленький, а уже потом - новую версию поверх.)
Теперь настроим сервер. Найдите в файле конфигурации Apache conf/httpd.conf строчку AddHandler cgi-script .bat .exe
Замените ее на AddHandler cgi-script .bat .exe .pl .cgi
Как это ни странно, но эту директиву AddHandler иногда указывать не обязательно. Однако лучше перестраховаться...
Вот, собственно, и все. Можете пользоваться Perl-транслятором. Для проверки его работоспособности используйте такой скрипт (помещенный, разумеется, в директорию cgi-bin или аналогичную): #!/usr/local/bin/perl print "Content-type: text/html\n\n"; print "It works! \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 и добавьте в его конец (но перед блоков виртуальных хостов, если они там есть) такие строки: Options ExecCGI ScriptAlias "/__php_dir__/" "f:/usr/local/php3/" Action application/x-httpd-php3 "/__php_dir__/php.exe"
Ну вот, пожалуй, и все. Если Вы все сделали правильно, то PHP установлен. Проверьте его работоспособность с помощью простого скрипта, например такого: echo "It works! \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 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
При желании можно добавить и другие параметры (например, 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 ).
Введение в 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.
4871 250.00
В этом примере значения элементов и атрибутов - константы. Однако во многих случаях необходимо создавать элемент или атрибут, значением которых является вычисляемое выражение. Выражение, заключенное в фигурные скобки, необходимо вычислить, а не трактовать как символьный текст. В конструкторе элемента это выражение вычисляется и заменяется своим значением. В следующем примере значения элементов и атрибутов вычисляются. Переменные $s, $i и $bids , используемые в этих выражениях, должны быть связаны с некоторыми выражениями. {$i} {max($bids[itemno = $i]/bid-amount)}
В следующем примере конструктор элементов содержит выражение, заключенное в фигурные скобки, которое генерирует один атрибут и два подэлемента. Переменная $b должна быть связана с некоторым выражением. { $b/@status $b/itemno $b/bid-amount }
Узел-элемент, созданный конструктором элемента, является новым узлом, обладающим собственной индивидуальностью. Если, как в приведенном примере, вновь созданный элемент имеет узлы-потомки и атрибуты, порожденные из существующих узлов, то новые узлы-потомки и атрибуты являются копиями узлов, из которых они были получены, но как узлы они индивидуальны.
В приведенных примерах конструкторов элементов, хотя содержимое элементов может быть вычисляемым, имя конструируемого элемента - известная константа. Однако иногда необходимо сконструировать элемент, имя которого, как и его содержимое, вычисляется. Для этого в 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 {$m} times {$n} is {$m * $n}
В результате получается следующая последовательность из четырех элементов. 2 times 5 is 10 2 times 10 is 20 3 times 5 is 15 3 times 10 is 30
Операторы 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 { $i/itemno, $i/description, {count ($b)} }
Операторы 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 { $e/name, {$e/salary + $e/commission + $e/bonus} } sortby (pay)
Иногда желательно определять значение по умолчанию, которое может заменять пропущенные операнды в арифметических выражениях. Ниже объясняется, как в этом случае может использоваться функция, определенная пользователем.
Операции над последовательностями. Оператор intersect порождает последовательность, в которую включены все узлы, имеющиеся в обоих операндах. Оператор except позволяет получить последовательность, содержащую все узлы, которые есть в первом операнде, но отсутствуют во втором.
Операторы union, intersect и except возвращают последовательность узлов в порядке документа и удаляют дубликаты из получившихся последовательностей с учетом индивидуальности узлов. Запрос Q6 является примером использования оператора intersect .
(Q6) Создать новый элемент с именем recent-large-bids, содержащий копии всех элементов bid документа bids.xml, которые имеют bid-amount со значением больше 1000 и bid-date со значением позже 1 января 2002 года.
document("bids.xml") /*/ bid [bid-amount > 1000.00] intersect document("bids.xml") /*/ bid [bid-date > date("2002-01-01")]
Выражения, в которых используются операции union, intersect и except , часто можно представить в другом виде. Так, запросу Q6 эквивалентен следующий запрос. document("bids.xml")/*/bid [bid-amount > 1000.00 and bid-date > date("2002-01-01")]
Важно помнить о том, что 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) Создать отчет, описывающий состояние ставок для различных товаров. Пометить каждую ставку статусом или . Поместить отчет в элемент с именем bid-status-report.
for $i in document ()/*/item return - { $i/itemno, for $b in document (
)/*/bid[itemno = $i/itemno] return { $b/bidder, $b/bid-amount, { if ($b/bid-date > $i/end-date) then else if ($b/bid-amount < $i/reserve-price) then else } } }
Кванторные выражения. Кванторные выражения позволяют проверить некоторое условие, устанавливая, истинно ли оно для некоторого значения последовательности (называется квантором существования) или для всех значений последовательности (называется квантором всеобщности). Результатом всегда является 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.
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
Вырезка/вставка текста между сессиями
С помощью режима прокрутки 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. 16.
17. Пресс-релизы 2001 18. 19. 20. @BLOCK@ 21. 22.
Этот файл предназначен для отображения списка всех доступных пресс-релизов.
Шаг 2
Создайте файл pr-list-block-tpl.htm, который будет отображать каждый блок с найденным пресс-релизом в виде таблицы:
23. 24. @TITLE@ 25. @AUTHOR@ , _ @DATE@ 26.
Шаг 3
Создайте файл pr-content-tpl.htm, который будет отображать содержание пресс-релиза:
27. 28.
29. Press-releases 2001: @TITLE@ 30. 31. 32. @TITLE@ 33. 34. @TITLE@ 35. Author: @AUTHOR@ Date: @DATE@ 36. @BODY@ 37.
38. Show the list of press-releases.. 39. 40.
Шаг 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=) { 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=) { 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 с текстом выбранного пресс-релиза.
Выводы, перспективы и будущие разработки
В связи с темой данного обзора важным становится вопрос, порождает ли 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].
в терминах модели данных, основанной
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.
Вызов скрипта.
Без возможности производить различные операции с информацией на сервере, 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 или любой другой язык. В следующем листинге приведен исходный код для нашей новой деки. В ней содержится всего один элемент , который предлагает пользователю выбор из нескольких опций. Элемент вызывает серверный скрипт с определенными параметрами.
Books Music Video Software
Скрипт показанный на листинге 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"%> <%Response.write(Body)%>
Несколько вещей необходимо напомнить для тех, кто захочет повторить этот пример в своих условиях. Вы обязательно должны "зарегистрировать" MIME типы на своем сервере для того, чтобы файлы WML и WMLScript правильно обрабатывались и отображались сервером.
.wml text/vnd.wap.wml .wmls text/vnd.wap.wmlscript
Если вы хотите использовать картинки (WBMP) вам также необходимо добавить и этот MIME-тип:
.wbmp image/vnd.wap.wbmp
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();
Здесь задействован стандартный метод 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. Вероятно, еще до этого момента вы сможете извлечь преимущества из следования правильной практике кодирования, в частности инструментарий поиска сможет различать разные теги, например то, что Network имеет иной смысл, нежели Network .
Однако поиск поиском, но дело приобретает весьма любопытной оборот, когда вам приходится обмениваться схожим информационным наполнением с другими людьми, собирающими информацию в близких предметных областях. Документ 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, позволяет экспонировать данные и манипулировать ими.
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.
Настройка графического пользовательского интерфейса приложения может превратиться просто в редактирование таблицы стилей.
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 - указывает кодировку, в которой микроброузер должен посылать ссылку.
Небольшой пример простейшей навигации. Hello World! Next Card!
Элемент
Setvar
Атрибуты:
name - имя, присваемое переменной. Переменная так же может выполнять эту функцию, например: .
value - значение, присваемое переменной.
Элемент
Postfield
Атрибут:
name имя, присваемое переменной. Переменная так же может выполнять эту функцию, например:
.
value - значение, присваемое переменной. Hello World!
Элемент
Anchor
Атрибуты:
title - имя элемента. Микроброузер может воспользоваться этим атрибутом по своему усмотрению. При перемещении курсора на анкор, микроброузер может вывести его имя в софт-кнопке.
Элемент
A
Атрибут:
href - URL на который ссылается анкор. У этого элемента нет дополнительных атрибутов позволяющих указать статус ссылки или ее метод. Если необходимы эти опции можно воспользоваться элементом "anchor" с внедренным в него элементом "go":
click me click me
и высокая конкуренция на рынке
Быстрое развитие и высокая конкуренция на рынке не прощают ошибок. В этой среде необходимо правильно и своевременно принимать решения. Однако задача поиска необходимой для этого информации, кажущаяся простой на первый взгляд, вызывает ряд сложностей, так как данные накапливаются и хранятся по всей организации. Для ее решения компаниям необходимо разрабатывать инфраструктуры, обеспечивающие своевременное распространение и совместное использование информации.
ПО для распространения информации должно обеспечить передачу данных огромному количеству пользователей внутри и вне предприятия и существенно повысить эффективность работы за счет:
быстрой доставки важнейших сведений;
минимизации времени рабочего цикла в результате прекращения распространения информации вручную, более рациональной обработки документов и повышения производительности работы сотрудников;
рассылки любого содержимого, включая файлы разных форматов (например отчетов из приложений других поставщиков или старых систем, рисунков, диаграмм, документов и презентаций);
оптимального хранения файлов и реализации простого и быстрого извлечения нужной информации.
в коем случае не претендует
Данный обзор не в коем случае не претендует на полноту описания всех возможностей языка 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-сообщения, в общем случае, рекурсивен.
Замена графического текста
По возможности, используйте форматированный текст вместо графического. Если необходимо изменить размеры и цвет текста, воспользуйтесь или .
Запланированные отчеты
Приложения по доставке информации обеспечивают выполнение запросов через электронную почту. В соответствии с некоторым расписанием (ежедневно, еженедельно и т.д), формируется определенный информационный материал и отсылается подписчику. И теперь не нужно часами составлять одни и те же отчеты. (Например, менеджеры по продажам могут назначить определенный день, в который они каждый месяц будут получать в свой почтовый ящик отчет о работе своих отделов). Регулировать план рассылок может либо только администратор, либо несколько авторизованных пользователей. Содержимое, время, частота, формат и даже метод распространения информации может меняться в соответствии с индивидуальными требованиями.
Запуск NCSA Telnet из DOS
telnet [options] [machine machine ....]
где options:
-? Подсказка Usage.
-c colorcode Установка цвета по умолчанию.
-h Ставится перед указанием пути к конфигурационному файлу.
-s Вход в режим сервера (открывается экран консоли) PC ждет внешних FTP или rcp запросов. Таким образом открывается доступ к файлам PC с удаленной машины. (* не работает)
-t Опция BIOS, позволяет сделать Telnet совместимым с Windows и Topview, но замедляет скорость вывода на экран. (* не удалось проверить.)
Бизнес в интернете: Сайты - Софт - Языки - Дизайн