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

Типы доступа "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: <id1@host.com> Content-Type: multipart/alternative; boundary=42 Content-ID: <id001@guppylake.bellcore.com> --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: <id42@guppylake.bellcore.com> --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: <id42@guppylake.bellcore.com> --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: <id42@guppylake.bellcore.com> 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 не распознает тег <OBJECT> - и потому, даже с подключенным модулем ScriptActive, не может вызывать органы управления, вводимые этим тегом. Как известно, вызов подключаемых модулей Netscape производится с помощью тега <EMBED>. Это значит, что авторы, которые хотят, чтобы органы управления на их страницах работали в обоих броузерах, должны продублировать информацию тега <OBJECT> в теге <EMBED>. А чтобы заставить Internet Explorer не обращать внимания на этот лишний для него <EMBED> (как вы знаете, Internet Explorer поддерживает этот тег и даже способен работать с подключаемыми модулями Netscape), этот тег помещают внутрь соответствующей пары тегов <OBJECT> ... </OBJECT>.

Такой выход из положения применяется в HTML довольно часто - пользуясь каким-нибудь новым тегом, автор в целях совместимости помещает между этим тегом и парным ему закрывающим что-нибудь, что будет видно только старым броузерам, игнорирующим новый тег; новый же броузер, распознающий этот тег, наоборот, обязан игнорировать все, что расположено внутри парного тега. (Надо признаться, что Netscape Navigator едва ли не первый раз в своей жизни оказывается в роли "старого броузера".) Вот как выглядит тег <OBJECT>, информация которого повторена во вложенном теге <EMBED>: <OBJECT WIDTH=320 HEIGHT=240 CLASSID="clsid:0D5C3F21-6DF8-11CF-AAEB-02608C9EA5BF" CODEBASE="http://www.ncompasslabs.com/ActiveX/ocx/nbillbrd.ocx" DATA="http://www.ncompasslabs.com/ActiveX/inline/billboard.ods" > <PARAM NAME="Slideshow" VALUE="1"> <PARAM NAME="LocalButtons" VALUE="0"> <PARAM NAME="Delay" VALUE="1"> <EMBED WIDTH=320 HEIGHT=240 SRC="BillBoard.ods" CODE="http://www.ncompasslabs.com/ActiveX/ocx/nbillbrd.ocx" Slideshow=1 <!- параметры стали атрибутами -> LocalButtons=0 Delay=1 > </OBJECT>

Для атрибута CLASSID тег <EMBED> не имеет соответствующего элемента, поэтому броузеру (точнее, подключаемому модулю) приходится извлекать идентификатор класса из самого файла с органом управления. Разумеется, присутствие тега <EMBED> - в любом случае не более чем следствие предусмотрительности автора страницы (и его вежливости по отношению к пользователям Netscape Navigator); к примеру, на сервере использовать этот тег как-то не принято.



Администрирование.


Выводим на экран форму с паролем pass. В окне вводятся: номера названия ссылки Затем, после нажатия на кнопку и проверки пароля, записываем новый список в файл.

<html> <head> <title>admin weather</title> </head> <body> <?php $adr=$DOCUMENT_ROOT."/weather/weather.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; } } ?>

<form method=post action="<?php echo $PHP_SELF?>"> // информация, введенная в форму, обрабатывается этим же файлом password:<input type=text name=pass><br> inicialisation:<textarea name="ini" rows=15 cols=60> <? for ($i=0; $i<sizeof($old); $i++) { echo $old[$i], ""; // выводим на экран текущий вариант файла } ?> </textarea> <br> <input type=submit name="submit" value="Enter"> </form>

</body> </html>

После ввода информации в файл в виде, получаем:

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" - ссылка на погоду в городе Ларнака на Яхе.

Ссылки на города организовываются по принципу:

<a href=http://www.czar.ru/weather/weather.php?weather=50>Ларнака</a>



Анатомия сообщения BizTalk


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

<BizTalk xmlns=”urn:shemas- biztalk-org:BizTalk/biztalk-0.81.xml”> <Route>

Теги маршрута

</Route> <Body> <MsgType xmlns= ”urn:ваше-пространство-имен”>

Ваш документ



Аннотация


Электронный бизнес приводит к изменению устоявшихся подходов применения информационных технологий. Информационные системы, работающие в среде Интернет и обслуживающие неограниченное число пользователей, требуют появления новых, масштабируемых систем, обладающих свойствами высокой пропускной способности и скорости выполнения транзакций. Информация, обрабатываемая такими системами, по своей сути является разнородной и может храниться в разных частях света. Появление таких новых возможностей обработки информации стало возможным благодаря открытым стандартам коммуникаций, таким как: 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 с использованием пространств имен:

<inventory xmlns:storea= “http://www.knowknew.com/ books.dtd” xmlns:storeb= “http://www.amazon.com/schema”> <storea:magazine> <storea:title>Network Magazine</storea:title> </storea:magazine> <storeb:magazine> <storeb:magazine storeb:title= “Data Communications”> </storeb:magazine> </inventory>

В определении 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 <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> 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 Это <bold><italic>текст с разметкой</italic></bold> <smaller>в соответствии с определением RFC 1341</smaller> <nl><nl>Неправда ли, <bigger><bigger>он крут?</bigger></bigger> --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:

    Сообщение<Message Name=имя сообщения>
    Группа сегментов<SegmentGroup>
    Сегмент<Segment Name=имя сегмента>
    Группа Элементов данных<ElementGroup >
    Элемент данных
    Квалификатор    		<DataElement id=код данных>
    Каждый элемент XML имеет определенный набор параметров, которые содержат информацию. Возвращаясь к нашему примеру, Все содержание EDI-сообщения INVOICE будет обрамлено следующими тагами:

    <Message Name="INVOICE">

    ..... сегменты и группы сегментов, составляющие сообщение ...

    </Message>

    Значение атрибута Name для тага <Message> представляет имя EDI-сообщения. Для упрощения синтаксического анализа и сохранения наглядности документа вводится таг <SegmentGroup>, который обрамляет повторяющиеся группы сегментов:

    <Message Name="INVOICE"> <Segment Name="UNH"> <!-- содержание сегмента UNH --> </Segment>

    <Segment Name="BGM"> <!-- содержание сегмента BGM --> </Segment> <!-- ....... информация о сегментах DTM,NAD-->

    <SegmentGroup> <!-- ......


    обрамляет группу сегментов (LIN, IMD,MEA,QTY,PRI,CUX) --> <Segment Name="LIN"> <!-- ...... содержание сегмента LIN --> </Segment> <Segment Name="IMD"> <!--...... содержание сегмента IMD --> </Segment> <!--..... информация об остальных сегментах группы LIN (MEA,QTY,PRI,CUX) --> </SegmentGroup> <!--.... контрольная секция, сегменты UNS,CNT,UNT --> </Message>

    Каждый сегмент содержит группу элементов данных, в соответствии со справочником сегментов EDSD, который входит в набор стандартов UN/EDIFACT. Например, в соответствии со справочником EDSD, сегмент NAD (имя и адрес) имеет следующие описание:

    № группыКод справочникаОписание данныхУсл/обязформат
    0103035КВАЛИФИКАТОР УЧАСТНИКАMan..3
    020C082ОСОБЕННОСТИ ИДЕНТИФИКАЦИИ УЧАСТНИКОВC  
     3039Идентификация участниковMan..35
     1131Квалификатор контролирующего органаCan..3
     3055Код контролирующего органаCan..3
    030C058НАЗВАНИЕ И АДРЕСС 
     3124Строка имени (названия) и адресаMan..35
     3124Строка имени (названия) и адресаCan..35
    040C080НАЗВАНИЕ УЧАСТНИКАС 
     3036Название участникаMan..35
     3036Название участникаCan..35
     3045Код названия участникаCan..3
    050С059УЛИЦА C 
     3042Улица и номер п.я.Can..35
     3042Улица и номер п.я.Can..35
    0603164НАЗВАНИЕ ГОРОДА Can..35
    0703229ИДЕНТИФИКАЦИЯ РЕГИОНАCan..9
    0803251ИДЕНТИФИКАЦИЯ ПОЧТОВОГО КОДАCan..9
    0903207КОД СТРАНЫCan..3
    Возвращаясь к нашему примеру, кодировка в UN/EDIFACT NAD+SE+++OY Valio++ Helsinki++Box 789+Fi' будет преобразована в:

    <Segment Name="NAD"> <DataElement id=10 dic=3035> SE </DataElement>

    <DataElement id=40> OY Valio </DataElement>

    <DataElement id=60> Y=Helsinki </DataElement>

    <DataElement id=80> Box 789 </DataElement>

    <DataElement id=90 dic=3207> FI </DataElement>



    </Segment>

    Атрибутом тага <DataElement> id - является номер группы в справочнике элементов данных, а атрибут dic - номер справочника, по которому определяется квалификатор.

    Элементы данных могут быть простыми и составными, состоящими из компонентов. Составные элементы данных объединяются тагами <ElementGroup>. Например, сегмент цена: PRI+INV:180' содержит составной элемент данных, включающий квалификатор INV (цена по инвойсу) и значение цены - 180:

    <Segment Name="PRI"> <ElementGroup id=10> <DataElement id=1 dic=5125> INV </DataElement>

    <DataElement id=2 dic=5118> 180 </DataElement>

    </ElementGroup>

    </Segment>

    В данном примере таг <ElementGroup> имеет аттрибут id, который имеет значение положения составного элемента по справочнику EDCD. Значения id тага <DataElement> представляет относительное месторасположение в справочнике сегментов.

    Преобразование XML документа в метаданные осуществляется посредством обработки XQL-запросов анализатором XSL. Ниже представлен текст запроса для преобразования EDIFACT элемента PRI (таг <Price> ) в XEDI метаданные:

    <xsl:template>

    xsl:for-each select="//Price"> <Segment Name="PRI"> <ElementGroup id=10> <DataElement id=1 dic=5125> INV </DataElement>

    <DataElement id=2 dic=5118> <xsl:value-of select="//Price"/> </DataElement>

    </ElementGroup>

    </Segment>

    </xsl:for-each>

    </xsl:template>

    Таг <xsl:template> определяет область действия шаблона XSL фильтра, а таг <xsl:for-each> определяет область шаблона, на которую распространяется данный запрос. Параметр select определяет область действия запроса в соответствии с синтаксисом запроса. Таг <xsl:value-of select=строка запроса /> осуществляет подстановку результата.

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


    Для выделения всех дочерних элементов - используется символ "*", для выделения элемента, расположенного просто "ниже" по дереву(на любом уровне вложенности) символ - "//". Условие на значение в запросе должно заключаться в символы "[" и "]". Для выбора значения атрибута в условии указывается символ @.

    Примеры простых шаблонов:

    " Transaction/"возвращает дочерние элементы для элемента Transaction
    "Consignor//"список всех элементов, вложенных в Consignor
    "SegmentName[@Id]"список элементов SegmentName, в котором определен атрибут Id
    "SegmentName [@Id=2]"поиск всех тагов, которые имеют значение атрибута id равное 2
    При формировании ответа на сообщение обратное преобразование из метаданных в XML-документ, осуществляется с помощью следующего шаблона:

    <xsl:template>

    xsl:for-each select="//Segment/"> <Price> <xsl:value-of select=" Segment[@Name="PRI"]/DataElement[@Id="2"]"/> </Price> </xsl:for-each>

    </xsl:template>

    Данный запрос интерпретируется как: выбрать все значения из тагов <DataElement&gt;, имеющие значение параметра Id="2", и которые имеют вхождение в таги <Segment> со значением параметра Name="PRI".

    Выполнение более сложных запросов, например, при формировании метаданных для сегмента NAD осуществляется, учитывая уровни вложенности:

    <xsl:template>

    xsl:for-each select="//Consignor"> <Segment Name="NAD"> <DataElement id=10 dic=3035> SE </DataElement>

    <DataElement id=40> <xsl:value-of select="//Consignor/ConsignorName"/> </DataElement>

    <DataElement id=50> <xsl:value-of select="//Consignor/Address/Street"/> </DataElement>

    <DataElement id=60> <xsl:value-of select="//Consignor/Address/City"/> </DataElement>

    <DataElement id=80> <xsl:value-of select="//Consignor/Address/Zip"/> </DataElement>



    <DataElement id=90 dic=3207> <xsl:value-of select="//Consignor/Address/Country"/> </DataElement>

    </Segment>

    </xsl:for-each>

    </xsl:template>

    В заключение хочется отметить, что предлагаемый способ формирования XEDI метаданных находится на стадии утверждения. В настоящее время в XML-EDI Group находится на рассмотрении предложения по комбинированному формированию метаданных, при котором используется конверсия не только стандарта UN/EDIFACT, но и не менее популярного в США и Германии стандарта формирования электронных документов ANSI X12.

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



    Форматирование текста


    br p table tr td

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

    <элемент> значение элемента </элемент>

    Если элемент не содержит внутри себя какую либо информацию (обычно такое случается с элементом форматирования <br>), вы можете использовать тэг с добавленным к нему "/" (например <br/>).



    Ftp


    Команда ftp позволяет переносить файлы с локального компьютера на удаленный и обратно. Формат команды:

    ftp [ remote_host ]

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

    ftp&gt ?

    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&gt 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 <emp> { $e/name, <pay> | {$e/salary + defaulted ($e/commission,0) + defaulted ($e/bonus,0)} </pay> } </emp> 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

    ("Бегущая строка")

    В отличие от тега <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.



    Использование переменных


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

    Используя элемент <setvar> в качестве результата выполнения пользователем определенных действий. Кроме того, этот элемент может быть использован для определения переменной внутри следующих элементов: <go>, <prev>, <refresh>. Следующий элемент создает переменную x и присваивает ей значение "123". <setvar name="x" value="123"/>

    Переменным также присваивается значение через использование элементов <input>, <select>, <option> и других. При этом автоматически создается переменная с именем этого элемента. По окончании ввода, ей присваивается значение соответствующее выбору пользователя. Например следующий элемент создаст переменную с именем "x" <select name="x" title="X Value:">

    Несмотря на то, что мы не описывает 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<sizeCol*2; j++) { if (str2[j] != 0) { str3[k]=str2[j]; k=k+1; } } String str = new String(str3,cp1); System.out.print(str); } System.out.println(__); // Загрузка следующего ряда в наборе more = rs.next (); } } }

В этой простой программе, приводимой во множестве руководств, мною произведено одно небольшое изменение, позволяющее использовать ее для работы с различными базами данных, содержащих таблицы с полями в кириллической кодировке. Дело в том, что хотя 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 = <year> create YearPage(v) link YearPage(v) -> <Year> -> u YearPage(v) -> <Paper> ->PaperPresentation(x), // Связать корневую страницу с каждой // страницей года RootPage() -> <YearPage> -> 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 <RootPage>, [label: <Paper> / x] as x.year from x in browse(<bibtex: myfile.bib>) | select [year: y.url] + y as y.url from y in <browse(RootPage)>

Запрос в WebOQL состоит из двух подзапросов. Полученная в результате первого из них подструктура Web поступает в качестве исходных данных во второй запрос, что достигается с помощью использования оператора <|>. Первый подзапрос строит страницы Root, Paper и Year, а второй переопределяет каждую страницу 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(<root.html>) 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