Ключевые слова:web, xml, sql, database, oracle, mysql, (найти похожие документы)
From: Паращенко Олег <http://xmlhack.ru/authors/OlPa/>;
Subject: Архив дискуссии в ru.xml "XML. С чего начать"
Архив дискуссии "XML. С чего начать?" эхи fido7.ru.xml
Компановка информации: http://xmlhack.ru/
05.08.01 Паращенко Олег <http://xmlhack.ru/authors/OlPa/>;
Ed V. Bartosh <ed@vitebsk.net>
Пнд 28 Май 2001 17:25:57 1 из 47
Есть желание заказчика переработать существующий сайт с использованием
XML-технологий. Сейчас сайт сделан на php/MySQL.
Сайт небольшой, по сути это некий иерархический каталог изделий,
то есть структурно это по-моему очень хорошо ложится на концепцию
XML да и вообще распространенный тип сайтов.
Да, каталог достаточно статичен, то есть возможны разные варианты
работы, как генерация на лету, так и просто генерация набора
HTML-ей при изменении каталога. Кроме того есть и явная динамика,
в основном касающаяся работы с юзерами (регистрация/логин/логаут/etc) и
поисков по каталогу.
Проблема в том, что у меня при попытке знакомства с XML разбежались
глаза :) Столько всего вокруг, что не знаешь за что браться.
Может кто подскажет ? Может есть примеры реализаций такого типа сайтов ?
Вот мои начальные вопросы:
1. Возможно ли и насколько оправдано применение XML для такого проекта ?
2. Hужно ли использовать СУБД для хранения каталога или хранить его в
XML ? Если в СУБД, то как получать XML из базы ?
3. Hужен ли DTD, если XML будет делаться не руками, а генериться на
основании информации из базы ?
4. Какие из XML-related технологий и соответственно продуктов рекомендуется
использовать для такого проекта ?
5. Каким образом должна решаться динамика (аутентификация пользователей,
пермишены для разных категорий пользователей и т.д.) ? Я имею ввиду,
что для этого использовать ? Тот же php оставить или есть более
"идеологически" правильные варианты ?
6. Какие средства лучше всего использовать для редактирования каталога,
если он будет в XMLе ?
7. Как быть с хостингом такого проекта ? Если закладываться на некий
софт, который должен быть у хостера, то не возникнет ли потом проблем ?
Aleksei Valikov <valikov@fzi.de>
Пнд 28 Май 2001 19:10:16 2 из 47
> 2. Hужно ли использовать СУБД для хранения каталога или хранить его в
> XML ? Если в СУБД, то как получать XML из базы ?
Можно делать и так и так, но если ты хранишь информацию просто в XML, то
нужно думать о возможностьях поиска в файлах. Это можно, но мое мнение что
информацию лучше всего хранить все же в базе данных, они для того и созданы.
Для того чтобы получать XML из базы можно использовать очень много чего. Я
не перестану повторять, что мой любимый инструмент - XSQL сервлет от Oracle,
http://technet.oracle.com/tech/xml/, более подробное описание XML-DB
продуктов на http://www.rpbourret.com/xml/XMLDatabaseProds.htm.
Что касается XSQL, то пишем файл например guestbook.xsql
==============
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="guestbook.xsl"?>
<page connection="home" title="guestbook" xmlns:xsql="urn:oracle-xsql">
<xsql:set-page-param name="date">
select to_char(sysdate, 'DD/MM/YYYY HH24:MI') from dual
</xsql:set-page-param>
<xsql:include-param name="date"/>
<xsql:insert-request table="guestbookview" transform="mins.xsl"/>
<xsql:set-cookie name="last-person" max-age="31536000"
ignore-empty-value="yes" value="{@person}"/>
<xsql:set-cookie name="last-email" max-age="31536000"
ignore-empty-value="yes" value="{@email}"/>
<xsql:query
rowset-element="messages"
row-element="message"
id-attribute=""
skip-rows="{@skip}"
max-rows="25"
null-indicator="no">
select * from guestbookview order by id DESC
</xsql:query>
</page>
==============
и получаем запрос в каноническом XML. Поддерживаются object types, cursors и
еще много чего.
Если нужно получать например в HTML, то прицепляется XSLT:
<?xml-stylesheet type="text/xsl" href="guestbook.xsl"?>
и все вместе результирует с полпинка гостевую книгу.
Ребята, я често не агент Оракла :)
> 3. Hужен ли DTD, если XML будет делаться не руками, а генериться на
> основании информации из базы ?
Роль DTD - установить "формат" документа, взаимное расположение элементов,
атрибутов и их элементарные типы. Если ты генерируешь XML только для того
чтобы удобнее затем преобразовать в HTML XSLT-процессором, то тебе
совершенно неважен DTD, лишь бы ты в ладах с самим собой был. Тут, правда
есть одна особенность - если в DTD указаны например значения по умолчанию,
то без валидируещего парсера и указания DTD ты эти значения просто будешь
терять. Пример надо?
Совсем другое дело когда XML используется как средство интеграции. Тогда DTD
нужен как стандарт обмена. Здесь DTD или XML Schema очень важны. Интеграция
при отсутствии общей схемы очень сложна - у меня коллега диссертацию по этой
теме пишет.
Конкретно для твоего случая - если ты собираешься документы, которые
генеришь из базы "кому-нибудь показывать" в смысле будешь явзяться
провайдером контента, то да, стандарт на представление нужен. А то завтра у
тебя изменится element name character case, и твои документы уже не смогут
корректно обрабатываться. А если будет стандарт, то изменив имена к примеру
колонок в бд тебе все равно придется выводить информацию в том же стандарте
и ничего не будет нарушено.
> 4. Какие из XML-related технологий и соответственно продуктов рекомендуется
> использовать для такого проекта ?
Пинайте меня ногами бейте руками, все равно буду рекомендовать Oracle XDK.
Пререквизиты - jdbc-enabled база данных и веб-сервер с поддержкой сервлетов.
Apache катит за милую душу. XSQL мы хорошо гоняли на Apache JServ, Jackarta
Tomcat есть информация что хорошо работает на Allaire JRun и ServletExec.
Apache JServ оптимально по-моему.
> 5. Каким образом должна решаться динамика (аутентификация пользователей,
> пермишены для разных категорий пользователей и т.д.) ? Я имею ввиду,
> что для этого использовать ? Тот же php оставить или есть более
> "идеологически" правильные варианты ?
Я прекрасно обхожусь безо всяких скриптовых языков - только XSQL. Это
идеологически чисто если это волнует - чистый XML.
При авторизации логин и пароль проверяются stored procedure через sql запрос
(реальные данные о пользователях по-другому абсолютно закрыты), если они
верны, то они устанавливаются как параметры сессии. При выполнение действий
над чувствительными данными, все операции четко выделены в stored
procedures, которые всегда в качестве двух из параметров требуют логин и
пароль. Проставляется все автоматически из параметров сессии.
Все это делается на чистом XSQL очень просто.
Вот пример - без хранимой процедуры из незакрытой таблицы, сразу
предупреждаю ТАК ДЕЛАТЬ НЕЛЬЗЯ это просто чтобы все открыто
проиллюстрировать.
Устанавливаем параметры сессии:
<xsql:set-session-param name="username" ignore-empty-value="yes">
select username from profile where
username='{@login}' and
password='{@password}'
</xsql:set-session-param>
<xsql:set-session-param name="password" ignore-empty-value="yes">
select password from profile where
username='{@login}' and
password='{@password}'
</xsql:set-session-param>
Вот например изменение чувствительных данных
<xsql:dml>
DECLARE NUMROWS INTEGER;
BEGIN
SELECT COUNT(*) INTO NUMROWS
FROM PROFILE
WHERE USERNAME='{@username}' and PASSWORD='{@password}';
IF NUMROWS = 1 THEN
IF '{@action}'='Post' THEN
INSERT INTO MAINPAGEVIEW (POSTED, CONTENT)
VALUES ('{@posted}', '{@content}');
END IF;
IF '{@action}'='Delete' THEN
DELETE FROM MAINPAGE
WHERE ID='{@ID}';
END IF;
END IF;
END;
</xsql:dml>
Еще раз повторяю ТАК ДЕЛАТЬ НЕЛЬЗЯ. Нужно все убирать в хранимые процедуры и
очень четко контролировать доступ.
К сожалению очень мало информации по exploits XSQL-based решений. Вернее нет
вообще. В форумах ни у кого проблем пока не было, во всяком случае не слышно
ничего.
> 6. Какие средства лучше всего использовать для редактирования каталога,
> если он будет в XMLе ?
Назвался груздем - полезай в кузов. В смысле, делай web-интерфейс для
редактирования данных.
Но это так, теория. На практике - абсолютно любые. Хорошее решение должно
предусматривать возможности импортировать данные в оговоренном (xsd или dtd)
формате в базу данных. А дальше - пишешь в чем угодно XML и заливаешь его в
базу.
На XSQL это выглядит примерно так:
<xsql:insert-request table="guestbookview" transform="mins.xsl"/>
Входящий xml преобразовывается как тебе надо посредством xslt к
каноническому виду и вставляется в базу данных. Хочешь в броузере через
web-интерфейс его редактируй, да хоть в ворде, лишь бы на выходе получался
xml с оговоренным dtd (или преобразуемый к нему посредством xslt).
> 7. Как быть с хостингом такого проекта ? Если закладываться на некий
> софт, который должен быть у хостера, то не возникнет ли потом проблем ?
Не нужно так делать - нельзя завязываться на софте хостера. В этом смысле
выгодно сервлет-решение, просто нужно иметь возможность разместить свой
сервлет у хостера. Да, извините меня ради бога, IIS не получится, увы и ах.
Но я так думаю Apache, ведь да? Установка XSQL сервлета - дело меньше чем 20
минут.
vitus@ice.ru <vitus@ice.ru>
Пнд 28 Май 2001 19:43:25 3 из 47
AV>Моя предыдущая разведка боем показала что родных средств от MySQL дя XML
AV>нет. У кого есть другая информация.
Скорее всего, php+MySQL подразумевает + Apache. Родные средства от
apache для XML еще как есть. См. http://www.apache.org.
Правда, есть большой шанс, что это получится не "вместе с php", а
"вместо php".
Aleksei Valikov <valikov@fzi.de>
Пнд 28 Май 2001 19:52:07 4 из 47
>Скорее всего, php+MySQL подразумевает + Apache. Родные средства от
>apache для XML еще как есть. См. www.apache.org.
>Правда, есть большой шанс, что это получится не "вместе с php", а
>"вместо php".
Я о XML-enabling MySQL. Родных разработок не нашел - не там смотрел?
То есть - запрос SELECT A, B FROM C, как из MySQL по этому запросу получить
<ROW>
<A>a-value</A>
<B>b-value</B>
</ROW>
Timur Evdokimov <te@tq.ru>
Втр 29 Май 2001 11:44:54 6 из 47
> т.е. неверняка будет приложение, которое будет обрабатывать XML. К нему
> дописать еще один слой, вместо стандартной db-api для выбраного языка
> труда не составит. Да, потеря эфективности... А что делать? ;)
А зачем, кстати, получать XML из MySQL? Куда его потом девать
предполагается? Я бы предпочел получать персистенс-объекты, с ними хоть
что-то делать вразумительное потом можно, а XML-то зачем? Да тем более
такого незатейливого вида. Я бы еще как-то понял если бы дерево развесистое
вынималось из базы одним запросом, это как бы жизнь сильно упрощает.
Почему-то большинство моих встреченных до сих пор задач, которые были
связаны с хранением данных в виде XML (веб-приложения), имеют следующие
характеристики:
1. XML требуется только для хранения данных и соблюдения их
структурирования. Поэтому можно хранить его фрагменты и ноды в реляционной
базе как строки и текст, склеивая их потом в процессе доставания.
2. XML сам по себе достаточно примитивен, поэтому логика разложения его в
таблицы по отдельным нодам и фрагментам дерева и склеивания обратно при
доставании оттуда - достаточно просто. Так как схему базы определяю я сам,
производительность системы при этом максимальна (а это типа критично).
Ну то есть я склонен допустить, что есть и другие задачи, и даже был бы
отчасти рад, если меня бы просветили насчет моей дремучести.
Serge Shikov <shikov@rinet.ru>
Втр 29 Май 2001 13:16:20 7 из 47
> Для того чтобы получать XML из базы можно использовать очень много чего. Я
> не перестану повторять, что мой любимый инструмент - XSQL сервлет от Oracle,
> http://technet.oracle.com/tech/xml/, более подробное описание XML-DB
> продуктов на http://www.rpbourret.com/xml/XMLDatabaseProds.htm.
Не в обиду будь сказано, а просто имей в виду - у Oracle XSQL _очень_
плохо с поддержкой других СУБД, помимо родной. В частности с mysql, о
котором тут разговор, он не работает ни через родной JDBC-драйвер, ни
через мост ODBC-JDBC, если дело происходит под виндой.
> Что касается XSQL, то пишем файл например guestbook.xsql
> ==============
> <?xml version="1.0"?>
> <?xml-stylesheet type="text/xsl" href="guestbook.xsl"?>
> <page connection="home" title="guestbook" xmlns:xsql="urn:oracle-xsql">
> <xsql:set-page-param name="date">
> select to_char(sysdate, 'DD/MM/YYYY HH24:MI') from dual
Так что я бы вот это все выкинул, и заменил на Cocoon, где этих проблем
нет (хотя наверное есть другие).
> Пинайте меня ногами бейте руками, все равно буду рекомендовать Oracle XDK.
> Пререквизиты - jdbc-enabled база данных и веб-сервер с поддержкой сервлетов.
Далеко не любая база. А так оно конечно неплохая вещь.
> Apache катит за милую душу. XSQL мы хорошо гоняли на Apache JServ, Jackarta
> Tomcat есть информация что хорошо работает на Allaire JRun и ServletExec.
> Apache JServ оптимально по-моему.
Ну уж нет. Самый пожалуй кривой контейнер на сегодня.
> > 5. Каким образом должна решаться динамика (аутентификация пользователей,
> > пермишены для разных категорий пользователей и т.д.) ? Я имею ввиду,
> > что для этого использовать ? Тот же php оставить или есть более
> > "идеологически" правильные варианты ?
>
> Я прекрасно обхожусь безо всяких скриптовых языков - только XSQL. Это
> идеологически чисто если это волнует - чистый XML.
Это идеологически нечисто, потому как бизнес-логика у тебя где? Я бы
предпочел иметь ее например в виде EJB, хотя полгода назад тоже думал,
что кокуна мне хватит. Ан нет.
> К сожалению очень мало информации по exploits XSQL-based решений. Вернее нет
> вообще. В форумах ни у кого проблем пока не было, во всяком случае не слышно
> ничего.
Начинать надо с более фундаментальных вещей. Например почитать про J2EE,
там достаточно много и понятно написано про безопасность. Впрочем, к XML
это все никакого отношения не имеет.
Serge Shikov <shikov@rinet.ru>
Втр 29 Май 2001 13:28:02 8 из 47
> А зачем, кстати, получать XML из MySQL? Куда его потом девать
> предполагается? Я бы предпочел получать персистенс-объекты, с ними хоть
> что-то делать вразумительное потом можно, а XML-то зачем?
Персистенс-объекты в каком-то смысле предполагают конкретный язык
реализации. Яву к примеру. Если же из базы достается XML, то дальше ты к
одному языку не привязан. Я не говорю, что это нужно, но теоретически...
> Да тем более такого незатейливого вида. Я бы еще как-то понял если бы дерево развесистое
> вынималось из базы одним запросом, это как бы жизнь сильно упрощает.
Да легко. XLE это называется. Или Castor. Другой вопрос, что с mysql
будут грабли, потому как он сам весьма кривой.
> Ну то есть я склонен допустить, что есть и другие задачи, и даже был бы
> отчасти рад, если меня бы просветили насчет моей дремучести.
Ну этта как всегда - нафига нужен еще один уровень (в данном случае
XML)? Чтобы абстрагироваться от каких-то особенностей других уровней (в
данном случае - от базы и от приложения).
Aleksei Valikov <valikov@fzi.de>
Втр 29 Май 2001 13:44:03 9 из 47
> AV> То есть - запрос SELECT A, B FROM C, как из MySQL по этому запросу
> AV> получить
> AV> <ROW>
> AV> <A>a-value</A> <B>b-value</B>
> AV> </ROW>
>
> несложно это все пишется, вот только зачем?
То что это пишется несложно всем понятно. Теги понавтыкать и делов-то
(правда я не знаю что там из объектной функциональности есть, это уже
сложнее ). Но, хочу обратить внимание, если всегда писать то, что несложно
пишется и освобождать разработчиков используемого продукта от этого труда,
то куда в итоге заходим.
Это насчет "несложно пишется".
Насчет "зачем". Вопрос двоякий - "зачем родная разработка от MySQL" и "зачем
такое нужно в принципе".
Второй вопрос обсуждается в мессаге ниже по треду.
Насчет первого - конечно необязательно. Просто с большой степенью
уверенности можно утверждать, что родная разработка будет работать быстрее
чем утилиты третьих сторон.
> т.е. неверняка будет приложение, которое будет обрабатывать XML. К нему
> дописать еще один слой, вместо стандартной db-api для выбраного языка
> труда не составит. Да, потеря эфективности... А что делать? ;)
Смотри дальше по треду. Мне кажется, это крайне неверный подход дописывать
на "db-api для выбранного языка" дополнительные уровни. Причин много -
начиная с того что db-api для выбранного языка может просто не существовать
и заканчивая тем, что если в проекте интеграции для каждого провайдера нужно
будет писать на db-api для выбранного языка, то это [] можно.
Следующий момент может быть (вернее очень часто бывает) тот, что приложений
может быть много и соответственно умножается effort по их разработке. Чтобы
этого избежать используются как правило механизм врапперов (wrappers) - но
чем более родным образом бд поддерживает экспорт-импорт из-в XML, тем легче
все это делается.
Aleksei Valikov <valikov@fzi.de>
Втр 29 Май 2001 14:44:03 11 из 47
> А зачем, кстати, получать XML из MySQL? Куда его потом девать
> предполагается? Я бы предпочел получать персистенс-объекты, с ними хоть
> что-то делать вразумительное потом можно, а XML-то зачем?
Никто не говорит о том, что XML нужно использовать для всего чего не попадя.
Есть определнный класс задач, какой именно - это отдельный разговор, для
которого важны возможности базы экспортировать данные в XML. Основное,
пожалуй - это web-приложения с использование db и проекты интеграции.
Веб оставим, ибо найдутся любители представлять данные и форматироват html
скриптами еще там чем угодно, это дела вкуса, мне ничего милее XSLT нет.
В проектах же интеграции - каким образом ты себе представляешь
стандартизацию обмена данными между десятками провайдеров, и огромным
количество потребителей и их приложениями, которые на этих стандартах
работают? Persistant объекты, это все хорошо и мило, но когда в
инфрастуктуре работает множество платформ и решений, ты считаешь это
реальным выучить api всего этого безобразия?
> 1. XML требуется только для хранения данных и соблюдения их
> структурирования. Поэтому можно хранить его фрагменты и ноды в реляционной
> базе как строки и текст, склеивая их потом в процессе доставания.
XML это прежде всего способ представления полуструктурированных (или
древовидно-структурированных) данных. Хранение в XML - оно постольку
поскольку, после определенного барьера приходится переходить на более другие
способы хранения.
Хранение XML в реляционной бд вопрос очень непростой. Есть хорошие работы в
этой области, например http://www.cs.wisc.edu/~jai/papers/RdbmsForXML.pdf
или http://research.microsoft.com/research/db/debull/99sept/issue.htm -
Storing and Querying XML Data using an RDBMS от Флореску и Кроссмана, но
тема как оказывается просто глобальна (если кого интересует, могу
предоставить список литературы). Основных подхода правда всего два -
вычленять сущности из XML или не выпендриваться и хранить узлы, ребра, текст
и прочее в своих таблицах (это то что Флореску предлагает и похоже на то что
описал ты).
> 2. XML сам по себе достаточно примитивен, поэтому логика разложения его в
> таблицы по отдельным нодам и фрагментам дерева и склеивания обратно при
> доставании оттуда - достаточно просто. Так как схему базы определяю я сам,
> производительность системы при этом максимальна (а это типа критично).
Все это не так просто как кажется. Согласен, своя схема бд - можно все
сделать хорошо и красиво в обоих подходах. Эффективность кстати практически
наравне - бенчмарки можно посмотреть в двух статьях что я привел.
Но не менее часто встречающаяся задача - добавление XML-функциональности к
существующим реляционным решениям. И тут такое начинается... Ох... Блин...
Ладно, не суть. Факт в том что класс XML задач намного шире чем эти два
пункта. Вкратце, exchange, storage, transformation.
Timur Evdokimov <te@tq.ru>
Втр 29 Май 2001 15:05:16 12 из 47
> В проектах же интеграции - каким образом ты себе представляешь
> стандартизацию обмена данными между десятками провайдеров, и огромным
> количество потребителей и их приложениями, которые на этих стандартах
> работают? Persistant объекты, это все хорошо и мило, но когда в
> инфрастуктуре работает множество платформ и решений, ты считаешь это
> реальным выучить api всего этого безобразия?
Не могу ничего возражать. Все сильно зависит от специфики предметной
области.
То есть к примеру от того, какого объема данные у тебя передаются между
потребителем и провайдером за одну транзакцию - весь каталог или одна
позиция. Если весь каталог или по крайней мере достаточно весомый кусок, то
XML, базара нет. А в иных случаях может быть проще провайдеру открыть наружу
SOAP-сервис. И никакого XML, помимо того что собственно маршаллится. Кстати
M$ полным ходом двигает SOAP именно в эту нишу, в смысле в проекты
интеграции.
Aleksei Valikov <valikov@fzi.de>
Втр 29 Май 2001 15:49:38 14 из 47
> А в иных случаях может быть проще провайдеру открыть наружу
> SOAP-сервис. И никакого XML, помимо того что собственно маршаллится.
Прости, как никакого XML? А SOAP это что?
"SOAP provides a simple and lightweight mechanism for exchanging structured
and typed information between peers in a decentralized, distributed
environment using XML."
Да и често говоря SOAP это buzzword и ничего более. Пшик, много шума из-за
ерунды. Есдинственный смысл который я вижу - нормальное пропускание
SOAP-контейнеров через различные firewall, и все!
Семантику-то структурирования данных все равно сам должен обеспечивать и как
это делать? Самое естественное решение - XML и есть.
> Кстати M$ полным ходом двигает SOAP именно в эту нишу, в смысле в проекты
интеграции.
SOAP это громкий звук. Никакие проблемы интергации (несоответствие схем,
object identity, constraints for semistructured data) он не решает. Я могу
ошибаться, но для меня это было вот как:
О, народ у нас теперь есть SOAP! Давайте вместо
<cds:request xmlns:cds="http://cds.fzi.de"
<query>
<intersects/>
<x>100</x>
<y>200</y>
</query>
</cds:request>
теперь писать
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<cds:request xmlns:cds="http://cds.fzi.de"
<query>
<intersects/>
<x>100</x>
<y>200</y>
</query>
</cds:request>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
ну фигли ну давайте. Разница-то какая принципиальная? Да никакой. MS как
всегда раздули дым без огня.
Aleksei Valikov <valikov@fzi.de>
Втр 29 Май 2001 17:02:02 15 из 47
> Это вполне понятно. Но есть у меня такое неоформленное еще окончательно
> соображение, что круг приложений, в которых это актуально, достаточно узок.
> Я собственно хотел более конкретных примеров, чтобы подтвердить или
> опровергнуть это самое соображение. :)
С моей точки зрения это соображение не является верным.
За примерами далеко ходить не надо +xml +case +studies.
Вот например от developerWorks (ну хоть бы кто сделал developerRests или
developerSleeps)
http://www-105.ibm.com/developerworks/casestudies.nsf/dw/xml-byname?OpenDocument&Count=500
Pavel Veller <pveller@itos.eu.org>
Втр 29 Май 2001 19:33:10 16 из 47
> ну фигли ну давайте. Разница-то какая принципиальная? Да никакой. MS как
> всегда раздули дым без огня.
Категорически несогласен.
Во-первых, если MS дым и раздувала, то теперь (да и при зарождении) далеко
не она одно там стояла. Но дело не в этом.
Стандартизация (в частности то, что ты описал в своем примере выше) и
призвана для того, чтобы каждый девелопер не изобретал свой формат для RPC
по XML, не придумывал каждый раз своих форматов описания и т.д. и т.п.
SOAP сам по себе может быть ничего и не дает, но когда написаны средства для
работы с ним (для примера SOAP реализация Apache, MS и т.д.), когда на нем
(КАК на СТАНДАРТЕ) работают и разрабатываются WebServices, когда существует
уже куча стандартов (подчеркиваю, не довесок, а стандартов) вокруг - как-то:
WSDL, UDDI, XAML, RDF и т.д - то получается очень даже мощные, переносимые и
независимые средства. Я могу еще долго... уффф...
Если вернуться к твоему примеру: Может быть и не стоит просто так переводит
законченный solution на новый стандарт, просто потому, что таковой появился.
HО: разрабатывать новые решения, не изобретая по 10 раз велосипедов,
во-первых, ощутимо быстрее, во-вторых, любой человек, знакомый со
стандартом, запросто продолжит начатое или включится в разработку, а,
в-третьих, получается очень даже переносимое решение.
Пример. Пишем WebService, любой, дело не в конечном коде и не в платформе.
Декларируем наружу методы, типы принимаемых и возвращаемых данных и ВСЕ.
Hикаких сопроводительных описаний форматов XML вызовов. Hичего. Клиентское
приложение берет реализацию SOAP-а или пишет свою (если очень хочется) и
дергает твой сервис - ПО СТАНДАРТУ... Вот именно в этом и прелесть того же
SOAP. Может он не всех устраивает (а как же иначе?) - но это стандарт. Вот
если тебе аргументированно не хватает SOAP-а, тогда конечно - пиши свой...
Вдогонку, тебе ведь знаком BizTalk Server от Microsft или CxStudio на Java?
Представь себе иметь такие решения и не иметь при этом платформенно- и
протокольно-независимого стандарта RPC как SOAP?
Aleksei Valikov <valikov@fzi.de>
Втр 29 Май 2001 19:49:43 18 из 47
> Стандартизация (в частности то, что ты описал в своем примере выше) и [skip]
> если тебе аргументированно не хватает SOAP-а, тогда конечно - пиши свой...
Павел, я должен извиниться за то что не совсем правильно выразился.
Сказав, что SOAP это пшик и buzzword я не имел ввиду полезность его как
стандарта - эта полезность очевидна.
Я говорю о том, что по сути дела SOAP это абсолютно ничего нового и
революционного с точки зрения реализации, особого влияния ни на существующие
системы ни на этап проектирования он не оказывает. Все что он изменяет это
переправляет "мы используем формат XXX" на "мы используем SOAP" и все.
Реальная-то работа это ведь не синтаксис конвертов, реальная работа - это
как раз семантика содержимого. Потому мое мнение - пофиг во что заворачивать
лишь бы семантика была реализована. А к реализации семантики, как всем
понятно, SOAP никакого отношения не имеет. В мою работу SOAP привнес немного
полировки но никаких особых изменений не внес.
Aleksei Valikov <valikov@fzi.de>
Втр 29 Май 2001 20:15:56 20 из 47
> Вдогонку, тебе ведь знаком BizTalk Server от Microsft или CxStudio на Java?
> Представь себе иметь такие решения и не иметь при этом платформенно- и
> протокольно-независимого стандарта RPC как SOAP?
Только BizTalk.
Я абсолютно согласен с важностью SOAP как стандартного протокола
(представления, как угодно), но также считаю что не нужно переоценивать его
семантическую роль. А это для меня главнее
Я опишу сценарий, думаю ты поймешь о чем я.
Система интегрирует множество больших и малых каталогов, содержащих
мета-данные о большом наборе документов. Провайдеры не выражают особого
желания быть интегрированными, но в принципе не против и потому худо-бедно
предоставляют когда XML когда не-XML интерфейсы к своим данным.
Централизировать данные не представляется возможным, поэтому был
спроектирован распределенный поиск (виртуальные каталоги, куча публикаций по
этому поводу, две диссертации защитились уже еще одна через год навероне
будет) посредством которого запросы распределяются по провайдерам и
используются их родные механизмы для поиска. Что я хочу сказать -
представляешь как ничтожна роль SOAP в этом проекте? Ну да, используем как
стандарт для рассылки запросов по своим врапперам, но настолько это
незначительно...
Aleksei Valikov <valikov@fzi.de>
Втр 29 Май 2001 20:57:01 24 из 47
> стандарт и побежал защищать, что наступал на такие грабли. А представь себе,
> что все провайдеры в твоем приложении интегрируются через
> webservices/еще_чего_нибудь на SOAP?
Они сейчас так и интегрируются. Но проблема в том, что им, провайдерам это
нафиг не надо, если бы их Европейская комиссия как ранее финансировавшая их
проекты не пинала, они вообще пальцем не пошевелили. [beep]
Но хочу обратить внимание что даже в этом случае SOAP явно недостаточно,
семантические проблемы, которые тут можно сказать главенствуют это не
решает. Я достал со своей семантикой, да? а вот как она меня достала.
Правда тут конечно подход иной был бы - врапперы были бы более-менее
централизованы и для них были бы иные методы реализации.
> А чтобы так в конце концов было (может
> будет уже и не SOAP - не суть), надо с этого начинать. Даже если кажется,
> что не совсем хочется быть интегрируемым и вроде бы проще дать свой формат
> на выход, всегда есть смысл задуматься над тем, что уже существует стандарт
> для этих целей.
Мне кажется гораздо более важным выработка и хорошее документирование
собственно семантики, сейчас XML Schema - стандарт, ну так и создавать
репозитории готовых разработанных схем чтобы они могли быть повторно
использованы. Да, я знаю, что такое делается, но это пока не тот уровень.
Если знакомы вещи типа EDI (X12, EDIFACT в Европе) - то вот как должно быть.
Serge Shikov <shikov@rinet.ru>
Втр 29 Май 2001 21:28:02 25 из 47
> понятно, SOAP никакого отношения не имеет. В мою работу SOAP привнес немного
> полировки но никаких особых изменений не внес.
А что, они ожидались что-ли? Это даже странно - ведь в конце концов SOAP
- это такая мелочь, что даже странно думать, что он серезно изменит
что-то в разработке приложений. На RPC ведь уже скока лет назад писали,
и ничего, обходились как-то. Ну небольшая иногда полезная мелочь, не
более того.
Timur Evdokimov <te@tq.ru>
Срд 30 Май 2001 02:11:43 31 из 47
>>> скриптами еще там чем угодно, это дела вкуса, мне ничего милее XSLT нет.
>> Это тоже кстати вопрос. Местами JSP/taglibs на чистом HTML и удобнее бывают
> Тимур, а можно пример в студию ?
То есть ты не веришь что такое бывает? :)
Да сколько угодно. Например:
1. Когда не требуется отделять контент от представления, либо по причине
убогости представления (например веб-интерфейс к B2B-системе заказов, шесть
jsp-страниц), либо по причине прямолинейности отображения контента
2. Когда некому создавать/поддерживать XSLT.
3. Когда просто мало времени на то, чтобы разработать целостную архитектуру
представления контента и ее XSLT-отображение.
В общем я к тому что XML это круто и все такое, но веб-приложения иногда
(т.е. не всегда) можно делать без него, даже в двадцать первом веке.
> Поправь меня если я не прав, но мои "заблуждения" говорят, что SOAP - одно
> из приложений/применений XML ?
Я собственно имел в виду, что при использовании какой-либо реализации SOAP
XML генерировать не надо, он сам там маршаллится, демаршаллится и всячески
своей жизнью живет. А ты как бы просто делаешь remote calls объектов на
сервере из кода на клиенте.
Serge Shikov <shikov@rinet.ru>
Срд 30 Май 2001 11:10:03 32 из 47
> Нет, я так не считаю. Я убедился, что SOAP не дает существенных преимуществ
> в моих задачах - и поэтому для меня это не более чем пустой звук, буквально
> форма без содержания.
Судя по описанию твоей задачи - у тебя типичная задача ;-) Ну то есть я
буквально недавно занимался ровно тем же самым - куча "провайдеров"
присылали нам свои цены буквально на все, а мы их интегрировали в
Оракловскую БД, и обеспечивали по ней поиск через WEB. При этом админы
американских интернет-магазинов в массе своей тупые настолько, что
экспортируя свою базу скажем в csv, они не догадываются, что следовало
бы квотить запятые внутри полей, а также искейпить кавычки внутри поля,
которое само заключено в кавычки. А те которые XML слали, забывали & на
& заменять. Надо ли сделать вывод, что у XML нету преимуществ по
сравнению с csv? Вряд ли. Но если люди и старые стандарты не соблюдают,
что толку им новые подсовывать?
> Отсюда и мое мнение, и я соглашусь с тем, что его
> можно посчитать не совсем адекватным.
Мораль - не мнение твое такое, а задачи твои такие. Для их решения нужны
не столько технологии или стандарты (их и так навалом), сколько что-то
другое.
Serge Shikov <shikov@rinet.ru>
Срд 30 Май 2001 11:32:01 33 из 47
> Хм... на сколько я помню, SOAP подразумевал маршрутизацию сообщений, может
> что изменилось с тех давних пор ?
Я лично не помню такого. SOAP-клиент должен точно _знать_, где живет
сервер, и какие сервисы у него имеются. Кто такая эта маршрутизация, о
которой ты говоришь? Наоборот, я знаю что IBM делает поверх SOAP (вернее
не только SOAP) такую штуку, как WSDK, где имеет место быть Request
Broker, чтобы клиенты могли обращаться к нему за списком сервисов и
адресами провайдеров, которые их обеспечивают. И все равно -
маршрутизация не предусматривается, брокер - это просто каталог
сервисов, дальше общение клиент - сервис все равно идет напрямую.
Aleksei Valikov <valikov@fzi.de>
Срд 30 Май 2001 12:38:40 35 из 47
> > Это насчет "несложно пишется".
> так что хочется то - XML текст или DOM дерево ?
Хочется возможность и того и того в зависимости от приложений. Я не понимаю,
чего ты споришь? Если надо будет всю мелочь самим реализовывать это тазиком
накрыться можно.
> выбрать другой язык. К примеру, если для TurboPascal не АПИ для MySQL -
Ты интересные вещи говоришь. Все эти "легко реализовать" и "выбрать другой
язык" ведут к размельчению задач на более мелкие типа "изучить MySQL db-api
на таком-то языке". Я охотно соглашусь, что когда у тебя один MySQL в
проекте, это можно сделать. Так легче всего, но мы говорим о несколько
других классах задач. Никто не предлагает писать сумму прописью на XML.
> ну и ... ? не дешевле ли выбрать или иную базу или иной язык ?
Слушай, я сержусь. Представь себе какой-нибудь захудалый Голландский
институт исследования береговой флоры и фауны с несколькими гигабайтами
исследовательской информации, а тут приходим мы и говорим - ребята, вы
знаете, мы решили, что нам легче чтобы вы выбрали другую базу. Теперь
угадай, на сколько голландских букв тебя пошлют?
Я, конечно утрирую, у них стоит Oracle и с ними проблем нет - но пойми
ошибочность подхода.
> 2) попытка избавить программистов от "излишнего труда" при простых
преобразованиях DB->XML
Вопрос элементарный - не было бы XDK от Oracle так бы все на cocoon и
сидели. И все.
Aleksei Valikov <valikov@fzi.de>
Срд 30 Май 2001 12:58:02 36 из 47
> Судя по описанию твоей задачи - у тебя типичная задача ;-) Ну то есть я
> буквально недавно занимался ровно тем же самым - куча "провайдеров"
> присылали нам свои цены буквально на все, а мы их интегрировали в
> Оракловскую БД, и обеспечивали по ней поиск через WEB.
Тут не о таком уровне интеграции речь идет - я не посню, я это описывал или
нет, но во-первых документы или даже мета-данные не хранятся в общем и целом
на каком-либо сервере централизованно, это одна из возможностей (просто не у
всех есть ресурсы создавать свои отдельные компоненты, поддерживать сервера
и так далее, для этого мы не ценральном сервере сделали XML-репозиторий
кстати на Оракле полностью, как - могу рассказать), во-вторых центральный
сервер даже не сам ищет на провайдерах.
Там идет какой-то глобально сложный распределенный поиск, как именно все это
делается я не знаю. Но черт ногу сломит...
То о чем ты говоришь - это да, это типичная задача. Там правда тоже не все
чисто - проблемы начинаются когда схемы различных провайдеров не совпадают а
даже если и совпадают, интегрировать катологи тоже не так просто - у всех
они разбиты на различные классы или категории, у некоторых это дело вообще
хиерархическое и корректно объединять это - серьезная научная задача
(Agrawal and Srikant 2001 in
http://www.almaden.ibm.com/cs/people/srikant/papers/www10_catalog.pdf)
Aleksei Valikov <valikov@fzi.de>
Срд 30 Май 2001 13:32:46 38 из 47
> Ну не зря же люди придумали мульти-тир ;)
Причем здесь multi-tire? Я говорю о более сложных запросах. На Oracle мы в
экпортируемых запросах используем object types, коллекции, курсоры, в общем
чего только "не" чтобы по максимуму приблизить абстракцию реляционных данных
внутри самой базы к целевой XML схеме. И если бы XSQL сервлет этого не
поддерживал, пришлось бы делать денормализацию в XSLT, или писать свое
решение для экспорта таких запросов.
> если "хранение", то только для статических данных. Иначе - ...
Ай... не надо, да про хранение статических данных. Естественно, не в файлах
хранить. Почитай у Буррета про native XML databases.
> а если использвать XML, как универсальный протокол обмена данными - другое
дело
Нет, не так. XML это не "универсальный протокол" и далее по тексту. XML это
формат представления, который может быть легко обработак. Как протокол
обмена он сильно больших преимуществ не дает (я опять о семантике, ну
область моя, ну что поделаешь). А вот если обменивающиеся стороны
договорятся об одной схеме обмена - вот это радикальный шаг.
> Т.е. если верить тебе, то это один из вариантов exchange.
Хех... С такой точки зрения любой storage это вариант exchange - между
приложением и базой данных,. между приложением и файловой системой - но это
неверный подход. Слишком плоско.
Aleksei Valikov <valikov@fzi.de>
Срд 30 Май 2001 18:02:05 43 из 47
> Не смею предвосхищать решение модератора; но мне лично тоже
> было бы _очень_ интересно почитать про XML-репозиторий. Да и
> не такой уж это оффтопик.
Я на этой неделе буду готовить материал для CSIT'01 в Уфе, это описание
нашего репозитория для CoastBase плюс еще немного теории по updateable XML
views для реляционных БД (что собственно и является XML-репозиторием
построенным на RDB). Как закончу - выложу.
Если вкратце то XML view состоит из 3 частей:
экспорт в целевую схему - денормализация реляционных данных
импорт из целевой схемы - нормализация древовидно-структурированных данных
язык запросов - запросы относительно целевой схемы
Первое решается построением иерархических абстракций поверх реляционных
данных - в Оракле это может быть object view, курсоры.
Второе может быть решено instead-of триггерами on object views, но это
довольно Oracle-specific, другие варианты - нормализация вскими утилитами
или XSLT (что в принципе один фиг)
Третье - язык свой делать и транслировать его в запросы целевой БД.
Есть другие подходы - ждите статьи.
Из существующих проектов обратите внимание на MIX из San Diego Supercomputer
Center и работы группы Jayavel Shanmugasundaram из IBM Almaden Research
Center.
Vladlen Bulatov <vlad@econ.msu.ru>
Чтв 31 Май 2001 21:30:56 46 из 47
> Ты прочитай еще раз сам что написал. Это абсолютно разные вещи которые
> задействую абсолютно разные механизмы.
так мы придем к компромису или нет ? ;)
я утверждаю, что ... !
0) рассмотрим классическую систему клиент-сервер, т.е. клиент требует некие
данные, активируя при этом сервер, а сервер же в ответ эти данные отдает.
1) на сервере некие данные (RDBMS, File-System & etc) преобразуются в XML и
посылаются клинету
2) клиент, получив XML, преобразует его к своему формату (например,
веб-браузер к графическому - изображение на экране)
т.е. в данном случае XML, как средство хранения не используется.
за исключением, случаев будь то - XML файлы на сервере, XML-прокси или
XML-акселератор.
Но и то, и другое и третье могут и не хранить это в XML.
а если допустить обратное, то выходит, что весь мир пользуется или
графическими изображениями на экране или печатными копиями, а все
остальное - так себе.
Andrey Prokopenko <Andrey.Prokopenko@p10.f9.n454.z2.fidonet.org>
Срд 06 Июн 2001 12:15:40 47 из 47
VB> т.е. в данном случае XML, как средство хранения не используется.
VB> за исключением, случаев будь то - XML файлы на сервере, XML-прокси или
VB> XML-акселератор.
В случае pеляционных баз данных XML действительно вносит дополнительные
"тоpмоза", вместе с тем делая пpиводя малопонятные SQL выбоpки и отдаваемые
стопки табличек с индексами к более человеческому, естественному пpедставлению.
В этом его одно из главных пpеимуществ. Hо пpеимущства в скоpости пpи
использовании XML пpоявляются лишь пpи использовании обьектно-оpиентиpованных
баз данных, нативно воспpинимающих XML.
В их случае пpоцедуpа маппинга XML->SQL и обpатная SQL<-XML, подчас довольно
мучительная как для базы так и для мозгов pазpаботчика ( я как Oracle
Developer, имею к нему самое непосpедственное отношение :), пpосто-напpосто
отсутствует. Реляционная модель базы, pанее казавшая такой удобной, показывает
свою убогость и неадексватность естественному пpедставлению данных.
Hа сегодня из пpомышленных pазpаботок таких DBMS всего две:
Cache http://www.cache.ru - постpоена на базе MSM/MUMPS.
и Tamino http://www.tamino.ru - постpоена на базе ADABAS.
