>> статьи на xmlhack.ru

Архив дискуссии «XML. С чего начать?» эхи fido7.ru.xml

Автор: Олег Паращенко
Опубликовано на xmlhack.ru (05.08.2001, рус.): http://xmlhack.ru/texts/01/WithWhatToStart/wwts_fido7_ru_xml.html
В закладки:    

Добрый день.

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

Заранее благодарен.

-- 
Best regards, Ed
 

Hi.

> Есть желание заказчика переработать существующий сайт с использованием
> XML-технологий. Сейчас сайт сделан на php/MySQL.

Моя предыдущая разведка боем показала что родных средств от MySQL дя XML
нет. У кого есть другая информация.

> Сайт небольшой, по сути это некий иерархический каталог изделий,
> то есть структурно это по-моему очень хорошо ложится на концепцию
> XML да и вообще распространенный тип сайтов.
> Да, каталог достаточно статичен, то есть возможны разные варианты
> работы, как генерация на лету, так и просто генерация набора
> HTML-ей при изменении каталога. Кроме того есть и яная динамика,
> в основном касающаяся работы с юзерами (регистрация/логин/логаут/etc) и
> поисков по каталогу.
>
> Проблема в том, что у меня при попытке знакомства с XML разбежались
> глаза :) Столько всего вокруг, что не знаешь за что браться.
> Может кто подскажет ? Может есть примеры реализаций такого типа сайтов ?
>
> Вот мои начальные вопросы:
> 1. Возможно ли и насколько оправдано применение XML для такого проекта ?

Полностью и абсолютно оправдано. Именно этот класс задач.

> 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=&apos;{@login}&apos; and
      password=&apos;{@password}&apos;
  </xsql:set-session-param>
  <xsql:set-session-param name="password" ignore-empty-value="yes">
    select password from profile where
      username=&apos;{@login}&apos; and
      password=&apos;{@password}&apos;
  </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
минут.

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Aleksei Valikov <valikov@fzi.de> wrote:
AV>Hi.

>> Есть желание заказчика переработать существующий сайт с использованием
>> XML-технологий. Сейчас сайт сделан на php/MySQL.

AV>Моя предыдущая разведка боем показала что родных средств от MySQL дя XML
AV>нет. У кого есть другая информация.

Скорее всего, php+MySQL подразумевает + Apache. Родные средства от
apache для XML еще как есть. См. www.apache.org.
Правда, есть большой шанс, что это получится не "вместе с php", а
"вместо php".

-- 
Victor Wagner                   vitus@ice.ru
Chief Technical Officer         Office:7-(095)-748-53-88
Communiware.Net                 Home: 7-(095)-135-46-61
http://www.communiware.net      http://www.ice.ru/~vitus
 

Hi.

>> Есть желание заказчика переработать существующий сайт с использованием
>> XML-технологий. Сейчас сайт сделан на php/MySQL.

AV>Моя предыдущая разведка боем показала что родных средств от MySQL дя XML
AV>нет. У кого есть другая информация.

>Скорее всего, 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>

Bye.
/lexi




-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

                Hi, Aleksei!

>>>>> "AV" == Aleksei Valikov <valikov@fzi.de> writes:

 AV> Я о XML-enabling MySQL. Родных разработок не нашел - не там смотрел?

 а нет их.
 
 AV> То есть - запрос SELECT A, B FROM C, как из MySQL по этому запросу
 AV> получить 
 AV> <ROW>
 AV>   <A>a-value</A> <B>b-value</B>
 AV> </ROW>

 несложно это все пишется, вот только зачем?
 
 т.е. неверняка будет приложение, которое будет обрабатывать XML. К нему
 дописать еще один слой, вместо стандартной db-api для выбраного языка
 труда не составит. Да, потеря эфективности... А что делать? ;)
 
-- 
                Bor.
 

"Vladimir Bormotov" <bor@vb.dn.ua> wrote in message
news:m3elt9xeyc.fsf@vb.dn.ua...
>  AV> Я о XML-enabling MySQL. Родных разработок не нашел - не там смотрел?
>
>  а нет их.
>
>  AV> То есть - запрос SELECT A, B FROM C, как из MySQL по этому запросу
>  AV> получить
>  AV> <ROW>
>  AV>   <A>a-value</A> <B>b-value</B>
>  AV> </ROW>
>
>  несложно это все пишется, вот только зачем?
>
>  т.е. неверняка будет приложение, которое будет обрабатывать XML. К нему
>  дописать еще один слой, вместо стандартной db-api для выбраного языка
>  труда не составит. Да, потеря эфективности... А что делать? ;)

А зачем, кстати, получать XML из MySQL? Куда его потом девать
предполагается?  Я бы предпочел получать персистенс-объекты, с ними хоть
что-то делать вразумительное потом можно, а XML-то зачем? Да тем более
такого незатейливого вида. Я бы еще как-то понял если бы дерево развесистое
вынималось из базы одним запросом, это как бы жизнь сильно упрощает.

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

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

Т.


 

Aleksei Valikov wrote:
> 
> Для того чтобы получать 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, где этих проблем
нет (хотя наверное есть другие).

> Ребята, я често не агент Оракла :) Хотя похоже ;-)
> 
> > 4. Какие из XML-related технологий и соответственно продуктов рекомендуется
> >    использовать для такого проекта ?
> 
> Пинайте меня ногами бейте руками, все равно буду рекомендовать 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
это все никакого отношения не имеет.


 

Timur Evdokimov wrote:
> 
> А зачем, кстати, получать XML из MySQL? Куда его потом девать
> предполагается?  Я бы предпочел получать персистенс-объекты, с ними хоть
> что-то делать вразумительное потом можно, а XML-то зачем?
Персистенс-объекты в каком-то смысле предполагают конкретный язык
реализации. Яву к примеру. Если же из базы достается XML, то дальше ты к
одному языку не привязан. Я не говорю, что это нужно, но теоретически...

> Да тем более такого незатейливого вида. Я бы еще как-то понял если бы дерево развесистое
> вынималось из базы одним запросом, это как бы жизнь сильно упрощает.
Да легко. XLE это называется. Или Castor. Другой вопрос, что с mysql
будут грабли, потому как он сам весьма кривой.

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


 

Hi.

>  AV> Я о XML-enabling MySQL. Родных разработок не нашел - не там смотрел?
>  а нет их.

Вот и я о том же.

>  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, тем легче
все это делается.

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Hi.
> > Для того чтобы получать XML из базы можно использовать очень много чего. Я
> > не перестану повторять, что мой любимый инструмент - XSQL сервлет от Oracle,
> > http://technet.oracle.com/tech/xml/, более подробное описание XML-DB
> > продуктов на http://www.rpbourret.com/xml/XMLDatabaseProds.htm.
> Не в обиду будь сказано, а просто имей в виду - у Oracle XSQL _очень_
> плохо с поддержкой других СУБД, помимо родной. В частности с mysql, о
> котором тут разговор, он не работает ни через родной JDBC-драйвер, ни
> через мост ODBC-JDBC, если дело происходит под виндой.

Какой MySQL? Какая версия XSQL? Какие именно сообщения? Там были
незначительные багфиксы по поводу jdbc, но чтобы так как ты говоришь...
Больше похоже на плохую конфигурацию.

> > <?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, где этих проблем
> нет (хотя наверное есть другие).

Каких именно проблем? У меня с точностью наоборот - выкинул Cocoon и теперь
на XSQL.

> > Ребята, я често не агент Оракла :)
> Хотя похоже ;-)

Хотя кто знает. :)

> > Пинайте меня ногами бейте руками, все равно буду рекомендовать Oracle XDK.
> > Пререквизиты - jdbc-enabled база данных и веб-сервер с поддержкой сервлетов.
> Далеко не любая база. А так оно конечно неплохая вещь.

Есть ли информация, с чем именно какие проблемы?

> > Apache катит за милую душу. XSQL мы хорошо гоняли на Apache JServ, Jackarta
> > Tomcat есть информация что хорошо работает на Allaire JRun и ServletExec.
> > Apache JServ оптимально по-моему.
> Ну уж нет. Самый пожалуй кривой контейнер на сегодня.

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

> > Я прекрасно обхожусь безо всяких скриптовых языков - только XSQL. Это
> > идеологически чисто если это волнует - чистый XML.
> Это идеологически нечисто, потому как бизнес-логика у тебя где? Я бы
> предпочел иметь ее например в виде EJB, хотя полгода назад тоже думал,
> что кокуна мне хватит. Ан нет.

Я говорю не о бизнес-логике а об имплементации. Совсем все идеологически
чистым не может быть.

И вообще - сдается мы в разных областях работаем. Мои задачи - виртуальные
каталоги и их интеграция (WebCDS, JCDS, сейчас идет CoastBase, работающий
прототип представляем в середине июля).

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

И я о том же.

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Hi.

> А зачем, кстати, получать XML из MySQL? Куда его потом девать
> предполагается?  Я бы предпочел получать персистенс-объекты, с ними хоть
> что-то делать вразумительное потом можно, а XML-то зачем?

Никто не говорит о том, что XML нужно использовать для всего чего не попадя.
Есть определнный класс задач, какой именно - это отдельный разговор, для
которого важны возможности базы экспортировать данные в XML. Основное,
пожалуй - это web-приложения с использование db и проекты интеграции.
Веб оставим, ибо найдутся любители представлять данные и форматироват html
скриптами еще там чем угодно, это дела вкуса, мне ничего милее XSLT нет.
В проектах же интеграции - каким образом ты себе представляешь
стандартизацию обмена данными между десятками провайдеров, и огромным
количество потребителей и их приложениями, которые на этих стандартах
работают? Persistant объекты, это все хорошо и мило, но когда в
инфрастуктуре работает множество платформ и решений, ты считаешь это
реальным выучить api всего этого безобразия?

> Да тем более такого незатейливого вида. Я бы еще как-то понял если бы дерево развесистое
> вынималось из базы одним запросом, это как бы жизнь сильно упрощает. 
:)
Естественно такие запросы нафиг не сдались - это просто пример. Если бы
обеспечивалось это, может быть обеспечивалось и что-нибудь более сложное.

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

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

Я надеюсь я хоть на что-нибудь свет пролил.

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

"Serge Shikov" <shikov@rinet.ru> wrote in message
news:3B134ECD.572F9B70@rinet.ru...
> > Ну то есть я склонен допустить, что есть и другие задачи, и даже был бы
> > отчасти рад, если меня бы просветили насчет моей дремучести.
> Ну этта как всегда - нафига нужен еще один уровень (в данном случае
> XML)? Чтобы абстрагироваться от каких-то особенностей других уровней (в
> данном случае - от базы и от приложения).

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

Т.



 

"Aleksei Valikov" <valikov@fzi.de> wrote in message
news:9evq93$7iv$1@host.talk.ru...
> Hi.
>
> > А зачем, кстати, получать XML из MySQL? Куда его потом девать
> > предполагается?  Я бы предпочел получать персистенс-объекты, с ними хоть
> > что-то делать вразумительное потом можно, а XML-то зачем?
>
> Никто не говорит о том, что XML нужно использовать для всего чего не попадя.
> Есть определнный класс задач, какой именно - это отдельный разговор, для
> которого важны возможности базы экспортировать данные в XML. Основное,
> пожалуй - это web-приложения с использование db и проекты интеграции.
> Веб оставим, ибо найдутся любители представлять данные и форматироват html
> скриптами еще там чем угодно, это дела вкуса, мне ничего милее XSLT нет.

Это тоже кстати вопрос. Местами JSP/taglibs на чистом HTML и удобнее бывают.
:) 
> В проектах же интеграции - каким образом ты себе представляешь
> стандартизацию обмена данными между десятками провайдеров, и огромным
> количество потребителей и их приложениями, которые на этих стандартах
> работают? Persistant объекты, это все хорошо и мило, но когда в
> инфрастуктуре работает множество платформ и решений, ты считаешь это
> реальным выучить api всего этого безобразия?

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

То есть к примеру от того, какого объема данные у тебя передаются между
потребителем и провайдером за одну транзакцию - весь каталог или одна
позиция. Если весь каталог или по крайней мере достаточно весомый кусок, то
XML, базара нет. А в иных случаях может быть проще провайдеру открыть наружу
SOAP-сервис. И никакого XML, помимо того что собственно маршаллится. Кстати
M$ полным ходом двигает SOAP именно в эту нишу, в смысле в проекты
интеграции.

Т.


 

Hi.

> > Никто не говорит о том, что XML нужно использовать для всего чего не попадя.
> > Есть определнный класс задач, какой именно - это отдельный разговор, для
> > которого важны возможности базы экспортировать данные в XML. Основное,
> > пожалуй - это web-приложения с использование db и проекты интеграции.
> > Веб оставим, ибо найдутся любители представлять данные и форматироват html
> > скриптами еще там чем угодно, это дела вкуса, мне ничего милее XSLT нет. 
> Это тоже кстати вопрос. Местами JSP/taglibs на чистом HTML и удобнее бывают.
> :)

Я и говорю - дело вкуса. :)

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

Мне не совсен ясен здесь критерий объема. Не пояснишь?

> А в иных случаях может быть проще провайдеру открыть наружу
> 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 как
всегда раздули дым без огня.

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Hi.
> > Ну этта как всегда - нафига нужен еще один уровень (в данном случае
> > XML)? Чтобы абстрагироваться от каких-то особенностей других уровней (в
> > данном случае - от базы и от приложения).
>
> Это вполне понятно. Но есть у меня такое неоформленное еще окончательно
> соображение, что круг приложений, в которых это актуально, достаточно узок.
> Я собственно хотел более конкретных примеров, чтобы подтвердить или
> опровергнуть это самое соображение. :)

С моей точки зрения это соображение не является верным.
За примерами далеко ходить не надо +xml +case +studies.
Вот например от developerWorks (ну хоть бы кто сделал developerRests или
developerSleeps)
http://www-105.ibm.com/developerworks/casestudies.nsf/dw/xml-byname?OpenDocu
ment&Count=500

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Aleksei Valikov <valikov@fzi.de> сообщил в новостях
следующее:9evurc$38r$1@host.talk.ru...
> Hi.
> 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 как
> всегда раздули дым без огня.
Категорически несогласен.
Во-первых, если MS дым и раздувала, то теперь (да и при зарождении) далеко
не она одно там стояла. Но дело не в этом.

Стандартизация (в частности то, что ты описал в своем примере выше) и
призвана для того, чтобы каждый девелопер не изобретал свой формат для RPC
по XML, не придумывал каждый раз своих форматов описания и т.д. и т.п.
SOAP сам по себе может быть ничего и не дает, но когда написаны средства для
работы с ним (для примера SOAP реализация Apache, MS и т.д.), когда на нем
(КАК на СТАНДАРТЕ) работают и разрабатываются WebServices, когда существует
уже куча стандартов (подчеркиваю, не довесок, а стандартов) вокруг - как-то:
WSDL, UDDI, XAML, RDF и т.д - то получается очень даже мощные, переносимые и
независимые средства. Я могу еще долго... уффф...

Если вернуться к твоему примеру: Может быть и не стоит просто так переводит
законченный solution на новый стандарт, просто потому, что таковой появился.
HО: разрабатывать новые решения, не изобретая по 10 раз велосипедов,
во-первых, ощутимо быстрее,  во-вторых, любой человек, знакомый со
стандартом, запросто продолжит начатое или включится в разработку, а,
в-третьих, получается очень даже переносимое решение.
Пример. Пишем WebService, любой, дело не в конечном коде и не в платформе.
Декларируем наружу методы, типы принимаемых и возвращаемых данных и ВСЕ.
Hикаких сопроводительных описаний форматов XML вызовов. Hичего. Клиентское
приложение берет реализацию SOAP-а или пишет свою (если очень хочется) и
дергает твой сервис - ПО СТАНДАРТУ... Вот именно в этом и прелесть того же
SOAP. Может он не всех устраивает (а как же иначе?) - но это стандарт. Вот
если тебе аргументированно не хватает SOAP-а, тогда конечно - пиши свой...

Надеюсь, убедил.

best regards,
Pavel Veller



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Pavel Veller <pveller@itos.eu.org> сообщил в новостях
следующее:9f0b6e$7hq$1@host.talk.ru...
> Aleksei Valikov <valikov@fzi.de> сообщил в новостях
> следующее:9evurc$38r$1@host.talk.ru...
[skipped]
Вдогонку, тебе ведь знаком BizTalk Server от Microsft или CxStudio на Java?
Представь себе иметь такие решения и не иметь при этом платформенно- и
протокольно-независимого стандарта RPC как SOAP?

best regards,
Pavel Veller



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Hi.

> Стандартизация (в частности то, что ты описал в своем примере выше) и [skip]
> если тебе аргументированно не хватает SOAP-а, тогда конечно - пиши свой...
>
> Надеюсь, убедил.

Павел, я должен извиниться за то что не совсем правильно выразился.

Сказав, что SOAP это пшик и buzzword я не имел ввиду полезность его как
стандарта - эта полезность очевидна.
Я говорю о том, что по сути дела SOAP это абсолютно ничего нового и
революционного с точки зрения реализации, особого влияния ни на существующие
системы ни на этап проектирования он не оказывает. Все что он изменяет это
переправляет "мы используем формат XXX" на "мы используем SOAP" и все.
Реальная-то работа это ведь не синтаксис конвертов, реальная работа - это
как раз семантика содержимого. Потому мое мнение - пофиг во что заворачивать
лишь бы семантика была реализована. А к реализации семантики, как всем
понятно, SOAP никакого отношения не имеет. В мою работу SOAP привнес немного
полировки но никаких особых изменений не внес.
Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Aleksei Valikov <valikov@fzi.de> сообщил в новостях
следующее:9f0ci1$fkh$1@host.talk.ru...
> Hi. [skipped]
> Я говорю о том, что по сути дела SOAP это абсолютно ничего нового и
> революционного с точки зрения реализации, особого влияния ни на существующие
> системы ни на этап проектирования он не оказывает.
Я с тобой соглашусь в том смысле, что SOAP не принес ничего революционно
нового в смысле реализации.
А я и не ждал от него ничего в этом плане.
>Все что он изменяет это
> переправляет "мы используем формат XXX" на "мы используем SOAP" и все.
Вот в этом-то и главное достижение. До этого было: у нас XXX и спецификация
к нему 30 страниц, а у нас - YYY и гораздо круче, но спецификация там
страниц 150 и т.д. Чтобы объединить такого рода
приложения/компоненты/сервисы надо все эти стандарты проштудировать и на
каждую комбинацию соединения писать специфический маршалинг/демаршалинг с
осознанием того, что следующая компонетна будет таким же образом
прикручиваться.
> Реальная-то работа это ведь не синтаксис конвертов, реальная работа - это
> как раз семантика содержимого. Потому мое мнение - пофиг во что заворачивать
> лишь бы семантика была реализована. А к реализации семантики, как всем
> понятно, SOAP никакого отношения не имеет.
Так вот я считаю, что именно как стандарт и надо SOAP рассматривать. Это и
есть стандарт.
Или, Алексей, ты считаешь, что SOAP претендует на революционность
реализации, а таковой не дает ?

best regards,
Pavel Veller



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Hi.

> [skipped]
> Вдогонку, тебе ведь знаком BizTalk Server от Microsft или CxStudio на Java?
> Представь себе иметь такие решения и не иметь при этом платформенно- и
> протокольно-независимого стандарта RPC как SOAP?

Только BizTalk.

Я абсолютно согласен с важностью SOAP как стандартного протокола
(представления, как угодно), но также считаю что не нужно переоценивать его
семантическую роль. А это для меня главнее

Я опишу сценарий, думаю ты поймешь о чем я.

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

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Hi.

> Или, Алексей, ты считаешь, что SOAP претендует на революционность
> реализации, а таковой не дает ?

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

Думаю, разобрались?

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Aleksei Valikov <valikov@fzi.de> сообщил в новостях
следующее:9f0ea3$nhd$1@host.talk.ru...
> Hi.
>
> > [skipped]
> > Вдогонку, тебе ведь знаком BizTalk Server от Microsft или CxStudio на Java?
> > Представь себе иметь такие решения и не иметь при этом платформенно- и
> > протокольно-независимого стандарта RPC как SOAP? [skipped]
> Я опишу сценарий, думаю ты поймешь о чем я.
> Система интегрирует множество больших и малых каталогов, содержащих
> мета-данные о большом наборе документов. Провайдеры не выражают особого
> желания быть интегрированными, но в принципе не против и потому худо-бедно
> предоставляют когда XML когда не-XML интерфейсы к своим данным.
> Централизировать данные не представляется возможным, поэтому был
> спроектирован распределенный поиск (виртуальные каталоги, куча публикаций по
> этому поводу, две диссертации защитились уже еще одна через год навероне
> будет) посредством которого запросы распределяются по провайдерам и
> используются их родные механизмы для поиска. Что я хочу сказать -
> представляешь как ничтожна роль SOAP в этом проекте? Ну да, используем как
> стандарт для рассылки запросов по своим врапперам, но настолько это
> незначительно...
:)) очень знакомо. Только конечно не в таких масштабах. Потому я SOAP как
стандарт и побежал защищать, что наступал на такие грабли. А представь себе,
что все провайдеры в твоем приложении интегрируются через
webservices/еще_чего_нибудь на SOAP? А чтобы так в конце концов было (может
будет уже и не SOAP - не суть), надо с этого начинать. Даже если кажется,
что не совсем хочется быть интегрируемым и вроде бы проще дать свой формат
на выход, всегда есть смысл задуматься над тем, что уже существует стандарт
для этих целей.

ЗЫ. Алексей, за резкость первого сообщения - пардон. Очень уж хотелось...
привет

best regards,
Pavel Veller





-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Aleksei Valikov <valikov@fzi.de> сообщил в новостях
следующее:9f0fk6$sul$1@host.talk.ru...
> Нет, я так не считаю. Я убедился, что SOAP не дает существенных преимуществ
> в моих задачах - и поэтому для меня это не более чем пустой звук, буквально
> форма без содержания. Отсюда и мое мнение, и я соглашусь с тем, что его
> можно посчитать не совсем адекватным.
>
> Думаю, разобрались?
конечно :) мы и не разбирались - отстаивали свои точки зрения и дали другим
повод подумать :)
привет

best rgards,
Pavel Veller



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Hi.

[skip]
> > представляешь как ничтожна роль SOAP в этом проекте? Ну да, используем как
> > стандарт для рассылки запросов по своим врапперам, но настолько это
> > незначительно...
> :)) очень знакомо. Только конечно не в таких масштабах. Потому я SOAP как
> стандарт и побежал защищать, что наступал на такие грабли. А представь себе,
> что все провайдеры в твоем приложении интегрируются через
> webservices/еще_чего_нибудь на SOAP?

Они сейчас так и интегрируются. Но проблема в том, что им, провайдерам это
нафиг не надо, если бы их Европейская комиссия как ранее финансировавшая их
проекты не пинала, они вообще пальцем не пошевелили. [beep]
Но хочу обратить внимание что даже в этом случае SOAP явно недостаточно,
семантические проблемы, которые тут можно сказать главенствуют это не
решает. Я достал со своей семантикой, да? а вот как она меня достала.

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

> А чтобы так в конце концов было (может
> будет уже и не SOAP - не суть), надо с этого начинать. Даже если кажется,
> что не совсем хочется быть интегрируемым и вроде бы проще дать свой формат
> на выход, всегда есть смысл задуматься над тем, что уже существует стандарт
> для этих целей.

Мне кажется гораздо более важным выработка и хорошее документирование
собственно семантики, сейчас XML Schema - стандарт, ну так и создавать
репозитории готовых разработанных схем чтобы они могли быть повторно
использованы. Да, я знаю, что такое делается, но это пока не тот уровень.
Если знакомы вещи типа EDI (X12, EDIFACT в Европе) - то вот как должно быть.

> ЗЫ. Алексей, за резкость первого сообщения - пардон. Очень уж хотелось...

Не проблема :)

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Aleksei Valikov wrote:
> 
> Я говорю о том, что по сути дела SOAP это абсолютно ничего нового и
> революционного с точки зрения реализации, особого влияния ни на существующие
> системы ни на этап проектирования он не оказывает. Все что он изменяет это
> переправляет "мы используем формат XXX" на "мы используем SOAP" и все.
> Реальная-то работа это ведь не синтаксис конвертов, реальная работа - это
> как раз семантика содержимого. Потому мое мнение - пофиг во что заворачивать
> лишь бы семантика была реализована. А к реализации семантики, как всем
> понятно, SOAP никакого отношения не имеет. В мою работу SOAP привнес немного
> полировки но никаких особых изменений не внес.
А что, они ожидались что-ли? Это даже странно - ведь в конце концов SOAP
- это такая мелочь, что даже странно думать, что он серезно изменит
что-то в разработке приложений. На RPC ведь уже скока лет назад писали,
и ничего, обходились как-то. Ну небольшая иногда полезная мелочь, не
более того.


 

Здравствуйте Уважаемые.

"Aleksei Valikov" <valikov@fzi.de> wrote in message
news:9evn67$jbg$1@host.talk.ru...
> Hi.
> >  AV> То есть - запрос SELECT A, B FROM C, как из MySQL по этому запросу
> >  AV> получить
> >  AV> <ROW>
> >  AV>   <A>a-value</A> <B>b-value</B>
> >  AV> </ROW>
> >  несложно это все пишется, вот только зачем?
> То что это пишется несложно всем понятно. Теги понавтыкать и делов-то
> (правда я не знаю что там из объектной функциональности есть, это уже
> сложнее ). Но, хочу обратить внимание, если всегда писать то, что несложно
> пишется и освобождать разработчиков используемого продукта от этого труда,
> то куда в итоге заходим.
> Это насчет "несложно пишется".

так что хочется то - XML текст или DOM дерево ?

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

вот уж, что не факт, то - не факт

> >  т.е. неверняка будет приложение, которое будет обрабатывать XML. К нему
> >  дописать еще один слой, вместо стандартной db-api для выбраного языка
> >  труда не составит. Да, потеря эфективности... А что делать? ;)
>
> Смотри дальше по треду. Мне кажется, это крайне неверный подход дописывать
> на "db-api для выбранного языка" дополнительные уровни. Причин много -
> начиная с того что db-api для выбранного языка может просто не
существовать

выбрать другой язык. К примеру, если для TurboPascal не АПИ для MySQL - ...

> и заканчивая тем, что если в проекте интеграции для каждого провайдера нужно
> будет писать на db-api для выбранного языка, то это [] можно.

ну и ... ? не дешевле ли выбрать или иную базу или иной язык ?

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

не совсем так, на сколько я помню - Оракл сделал поддержку XML по нескольким
причинам -
1) веяние времени (мода)
2) попытка избавить программистов от "излишнего труда" при простых
преобразованиях DB->XML
3) "мы первые, мы - круче всех" ;)

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Aleksei Valikov" <valikov@fzi.de> wrote in message
news:9evq93$7iv$1@host.talk.ru...
> Hi.
>
> работают? Persistant объекты, это все хорошо и мило, но когда в
> инфрастуктуре работает множество платформ и решений, ты считаешь это
> реальным выучить api всего этого безобразия?

ну не все так плохо - большинство решений используют устоявшиеся АПИ, будь
то COM, или CORBA или EJB. каждое из трех с небольшими затратами может быть
преобразовано в XML/DOM
И потом, далеко не для всего "безобразия" есть мост безобразия->XML :(

> > Да тем более такого незатейливого вида. Я бы еще как-то понял если бы дерево развесистое
> > вынималось из базы одним запросом, это как бы жизнь сильно упрощает.
> :)
> Естественно такие запросы нафиг не сдались - это просто пример. Если бы
> обеспечивалось это, может быть обеспечивалось и что-нибудь более сложное.

Ну не зря же люди придумали мульти-тир ;)

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

а если есть множество DTD ?
я все же склоняюсь к мысли, что XML это именно протокол, а не среда хранения

> > 2. XML сам по себе достаточно примитивен, поэтому логика разложения его в
> > таблицы по отдельным нодам и фрагментам дерева и склеивания обратно при
> > доставании оттуда - достаточно просто. Так как схему базы определяю я сам,
> > производительность системы при этом максимальна (а это типа критично).
> Все это не так просто как кажется. Согласен, своя схема бд - можно все
> сделать хорошо и красиво в обоих подходах. Эффективность кстати практически
> наравне - бенчмарки можно посмотреть в двух статьях что я привел.
> Но не менее часто встречающаяся задача - добавление XML-функциональности к
> существующим реляционным решениям. И тут такое начинается... Ох... Блин...

возращаясь к мульти-тир решениям ...

> Ладно, не суть. Факт в том что класс XML задач намного шире чем эти два
> пункта. Вкратце, exchange, storage, transformation.

только второй, скорее всего, притянут за уши. Т.е. если верить тебе, то это
один из вариантов exchange.

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

сколько людей - столько мнений ;)

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Timur Evdokimov" <te@tq.ru> wrote in message
news:9evsq2$7kd$1@news.radio-msu.net...
>
> "Aleksei Valikov" <valikov@fzi.de> wrote in message
> news:9evq93$7iv$1@host.talk.ru...
> > Веб оставим, ибо найдутся любители представлять данные и форматироват html
> > скриптами еще там чем угодно, это дела вкуса, мне ничего милее XSLT нет.
>
> Это тоже кстати вопрос. Местами JSP/taglibs на чистом HTML и удобнее бывают.
> :)

Тимур, а можно пример в студию ?

> > ...
> То есть к примеру от того, какого объема данные у тебя передаются между
> потребителем и провайдером за одну транзакцию - весь каталог или одна
> позиция. Если весь каталог или по крайней мере достаточно весомый кусок, то
> XML, базара нет. А в иных случаях может быть проще провайдеру открыть наружу
> SOAP-сервис. И никакого XML, помимо того что собственно маршаллится. Кстати
> M$ полным ходом двигает SOAP именно в эту нишу, в смысле в проекты
> интеграции.

Поправь меня если я не прав, но мои "заблуждения" говорят, что SOAP - одно
из приложений/применений XML ?

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Aleksei Valikov" <valikov@fzi.de> wrote in message
news:9evurc$38r$1@host.talk.ru...
> > Кстати M$ полным ходом двигает SOAP именно в эту нишу, в смысле в проекты
> интеграции.
> SOAP это громкий звук. Никакие проблемы интергации (несоответствие схем,
> object identity, constraints for semistructured data) он не решает. Я могу
> ошибаться, но для меня это было вот как: 
> О, народ у нас теперь есть SOAP! Давайте вместо
> <cds:request xmlns:cds="http://cds.fzi.de"
> </cds:request> 
> теперь писать
> <SOAP-ENV:Envelope>
>     <cds:request xmlns:cds="http://cds.fzi.de">
>      </cds:request>
> </SOAP-ENV:Envelope>
> ну фигли ну давайте. Разница-то какая принципиальная? Да никакой. MS как
> всегда раздули дым без огня.

Хм... на сколько я помню, SOAP подразумевал маршрутизацию сообщений, может
что изменилось с тех давних пор ?

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Serge Shikov" <shikov@rinet.ru> wrote in message
news:3B13CA33.5E2FFBFA@rinet.ru...
> > как раз семантика содержимого. Потому мое мнение - пофиг во что заворачивать
> > лишь бы семантика была реализована. А к реализации семантики, как всем
> > понятно, SOAP никакого отношения не имеет. В мою работу SOAP привнес немного
> > полировки но никаких особых изменений не внес.
> А что, они ожидались что-ли? Это даже странно - ведь в конце концов SOAP
> - это такая мелочь, что даже странно думать, что он серезно изменит
> что-то в разработке приложений. На RPC ведь уже скока лет назад писали,
> и ничего, обходились как-то. Ну небольшая иногда полезная мелочь, не
> более того.

Хех, каждый изобретает велосипед по своему ;)
тем паче если его потом покупают

но за thread - спасибо, почитать на самом деле было интересно.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

"Vladlen Bulatov" <vlad@econ.msu.ru> wrote in message
news:9f1006$30ec$1@ddt.demos.su...
> Здравствуйте Уважаемые.
>
> "Timur Evdokimov" <te@tq.ru> wrote in message
> news:9evsq2$7kd$1@news.radio-msu.net...
> >
> > > Веб оставим, ибо найдутся любители представлять данные и форматировать html
> > > скриптами еще там чем угодно, это дела вкуса, мне ничего милее XSLT нет.
> > Это тоже кстати вопрос. Местами JSP/taglibs на чистом HTML и удобнее бывают.
> > :)
> Тимур, а можно пример в студию ?

То есть ты не веришь что такое бывает? :)
Да сколько угодно. Например:
1. Когда не требуется отделять контент от представления, либо по причине
убогости представления (например веб-интерфейс к B2B-системе заказов, шесть
jsp-страниц), либо по причине прямолинейности отображения контента
2. Когда некому создавать/поддерживать XSLT.
3. Когда просто мало времени на то, чтобы разработать целостную архитектуру
представления контента и ее XSLT-отображение.

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

> Поправь меня если я не прав, но мои "заблуждения" говорят, что SOAP - одно
> из приложений/применений XML ?

Я собственно имел в виду, что при использовании какой-либо реализации SOAP
XML генерировать не надо, он сам там маршаллится, демаршаллится и всячески
своей жизнью живет. А ты как бы просто делаешь remote calls объектов на
сервере из кода на клиенте.

Т.


 

Aleksei Valikov wrote:
> 
> > Или, Алексей, ты считаешь, что SOAP претендует на революционность
> > реализации, а таковой не дает ?
> 
> Нет, я так не считаю. Я убедился, что SOAP не дает существенных преимуществ
> в моих задачах - и поэтому для меня это не более чем пустой звук, буквально
> форма без содержания.
Судя по описанию твоей задачи - у тебя типичная задача ;-) Ну то есть я
буквально недавно занимался ровно тем же самым - куча "провайдеров"
присылали нам свои цены буквально на все, а мы их интегрировали в
Оракловскую БД, и обеспечивали по ней поиск через WEB. При этом админы
американских интернет-магазинов в массе своей тупые настолько, что
экспортируя свою базу скажем в csv, они не догадываются, что следовало
бы квотить запятые внутри полей, а также искейпить кавычки внутри поля,
которое само заключено в кавычки. А те которые XML слали, забывали & на
& заменять. Надо ли сделать вывод, что у XML нету преимуществ по
сравнению с csv? Вряд ли. Но если люди и старые стандарты не соблюдают,
что толку им новые подсовывать?

> Отсюда и мое мнение, и я соглашусь с тем, что его
> можно посчитать не совсем адекватным.
Мораль - не мнение твое такое, а задачи твои такие. Для их решения нужны
не столько технологии или стандарты (их и так навалом), сколько что-то
другое.

 

Vladlen Bulatov wrote:
> 
> не совсем так, на сколько я помню - Оракл сделал поддержку XML по нескольким
> причинам -
> 1) веяние времени (мода)
> 2) попытка избавить программистов от "излишнего труда" при простых
> преобразованиях DB->XML
> 3) "мы первые, мы - круче всех" ;)
BTW, поддержка XML у IBM (в DB2 в виде XML Extender и вообще) появилась
примерно так на годик раньше ;-) Так что вопрос крутизны даже не стоял.


 

Vladlen Bulatov wrote:
> 
> Хм... на сколько я помню, SOAP подразумевал маршрутизацию сообщений, может
> что изменилось с тех давних пор ?
Я лично не помню такого. SOAP-клиент должен точно _знать_, где живет
сервер, и какие сервисы у него имеются. Кто такая эта маршрутизация, о
которой ты говоришь? Наоборот, я знаю что IBM делает поверх SOAP (вернее
не только SOAP) такую штуку, как WSDK, где имеет место быть Request
Broker, чтобы клиенты могли обращаться к нему за списком сервисов и
адресами провайдеров, которые их обеспечивают. И все равно -
маршрутизация не предусматривается, брокер - это просто каталог
сервисов, дальше общение клиент - сервис все равно идет напрямую.


 

Hi.

> > Это насчет "несложно пишется".
> так что хочется то - XML текст или DOM дерево ?

Хочется возможность и того и того в зависимости от приложений. Я не понимаю,
чего ты споришь? Если надо будет всю мелочь самим реализовывать это тазиком
накрыться можно.

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

Да? :)

> > >  т.е. неверняка будет приложение, которое будет обрабатывать XML. К нему
> > >  дописать еще один слой, вместо стандартной db-api для выбраного языка
> > >  труда не составит. Да, потеря эфективности... А что делать? ;)
> >
> > Смотри дальше по треду. Мне кажется, это крайне неверный подход дописывать
> > на "db-api для выбранного языка" дополнительные уровни. Причин много -
> > начиная с того что db-api для выбранного языка может просто не
> существовать
>
> выбрать другой язык. К примеру, если для TurboPascal не АПИ для MySQL -
...

Ты интересные вещи говоришь. Все эти "легко реализовать" и "выбрать другой
язык" ведут к размельчению задач на более мелкие типа "изучить MySQL db-api
на таком-то языке". Я охотно соглашусь, что когда у тебя один MySQL в
проекте, это можно сделать. Так легче всего, но мы говорим о несколько
других классах задач. Никто не предлагает писать сумму прописью на XML.

> > и заканчивая тем, что если в проекте интеграции для каждого провайдера нужно
> > будет писать на db-api для выбранного языка, то это [] можно.
>
> ну и ... ? не дешевле ли выбрать или иную базу или иной язык ?

Слушай, я сержусь. Представь себе какой-нибудь захудалый Голландский
институт исследования береговой флоры и фауны с несколькими гигабайтами
исследовательской информации, а тут приходим мы и говорим - ребята, вы
знаете, мы решили, что нам легче чтобы вы выбрали другую базу. Теперь
угадай, на сколько голландских букв тебя пошлют?
Я, конечно утрирую, у них стоит Oracle и с ними проблем нет - но пойми
ошибочность подхода.

> не совсем так, на сколько я помню - Оракл сделал поддержку XML по нескольким
> причинам -
> 1) веяние времени (мода)

Это есть :), но не первая причина - это точно.

> 2) попытка избавить программистов от "излишнего труда" при простых
преобразованиях DB->XML

Вопрос элементарный - не было бы XDK от Oracle так бы все на cocoon и
сидели. И все.

> 3) "мы первые, мы - круче всех" ;)

Во-первых они не первые, во-вторых и без этой XDK Oracle круче всех :).




-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Hi.

> > Нет, я так не считаю. Я убедился, что SOAP не дает существенных преимуществ
> > в моих задачах - и поэтому для меня это не более чем пустой звук, буквально
> > форма без содержания.
> Судя по описанию твоей задачи - у тебя типичная задача ;-) Ну то есть я
> буквально недавно занимался ровно тем же самым - куча "провайдеров"
> присылали нам свои цены буквально на все, а мы их интегрировали в
> Оракловскую БД, и обеспечивали по ней поиск через WEB.

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

То о чем ты говоришь - это да, это типичная задача. Там правда тоже не все
чисто - проблемы начинаются когда схемы различных провайдеров не совпадают а
даже если и совпадают, интегрировать катологи тоже не так просто - у всех
они разбиты на различные классы или категории, у некоторых это дело вообще
хиерархическое и корректно объединять это - серьезная научная задача
(Agrawal and Srikant 2001 in
http://www.almaden.ibm.com/cs/people/srikant/papers/www10_catalog.pdf)

> При этом админы
> американских интернет-магазинов в массе своей тупые настолько, что
> экспортируя свою базу скажем в csv, они не догадываются, что следовало
> бы квотить запятые внутри полей, а также искейпить кавычки внутри поля,
> которое само заключено в кавычки. А те которые XML слали, забывали & на
> & заменять. Надо ли сделать вывод, что у XML нету преимуществ по
> сравнению с csv? Вряд ли. Но если люди и старые стандарты не соблюдают,
> что толку им новые подсовывать?

Ох... мои мозоли...

> > Отсюда и мое мнение, и я соглашусь с тем, что его
> > можно посчитать не совсем адекватным.
> Мораль - не мнение твое такое, а задачи твои такие. Для их решения нужны
> не столько технологии или стандарты (их и так навалом), сколько что-то
> другое.

Вполне согласен.

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Aleksei Valikov <valikov@fzi.de> сообщил в новостях
следующее:9f28hv$lre$1@host.talk.ru...
[skipped]
>... для этого мы не ценральном сервере сделали XML-репозиторий
> кстати на Оракле полностью, как - могу рассказать)....
Алексей, мне было бы очень интересно, но боюсь уйдем в оффтопик этой конфы.
Может мылом пообщаемся?

best regards,
Pavel Veller



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Hi.

> > работают? Persistant объекты, это все хорошо и мило, но когда в
> > инфрастуктуре работает множество платформ и решений, ты считаешь это
> > реальным выучить api всего этого безобразия?
>
> ну не все так плохо - большинство решений используют устоявшиеся АПИ, будь
> то COM, или CORBA или EJB. каждое из трех с небольшими затратами может быть
> преобразовано в XML/DOM

Можешь мне поверить что насчет "большинство решений используют устоявшиеся
АПИ", крупными русскими буквами ХРЕН ТАМ!

> И потом, далеко не для всего "безобразия" есть мост безобразия->XML :(

Об этом я и говорю - чем больше у всех это будет тем меньше мне работать. :)
Поэтому не надо задавать вопросов "а зачем это надо".

> > > Да тем более такого незатейливого вида. Я бы еще как-то понял если бы дерево развесистое
> > > вынималось из базы одним запросом, это как бы жизнь сильно упрощает.
> > :)
> > Естественно такие запросы нафиг не сдались - это просто пример. Если бы
> > обеспечивалось это, может быть обеспечивалось и что-нибудь более сложное.
>
> Ну не зря же люди придумали мульти-тир ;)

Причем здесь multi-tire? Я говорю о более сложных запросах. На Oracle мы в
экпортируемых запросах используем object types, коллекции, курсоры, в общем
чего только "не" чтобы по максимуму приблизить абстракцию реляционных данных
внутри самой базы к целевой XML схеме. И если бы XSQL сервлет этого не
поддерживал, пришлось бы делать денормализацию в XSLT, или писать свое
решение для экспорта таких запросов.

> если "хранение", то только для статических данных. Иначе - ...

Ай... не надо, да про хранение статических данных. Естественно, не в файлах
хранить. Почитай у Буррета про native XML databases.

> а если использвать XML, как универсальный протокол обмена данными - другое
дело

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

> а если есть множество DTD ?

Слушай, ну прочитай ты статью от Флореску - тебе все ясно станет.

> > Но не менее часто встречающаяся задача - добавление XML-функциональности к
> > существующим реляционным решениям. И тут такое начинается... Ох... Блин...
>
> возращаясь к мульти-тир решениям ...

Тебе хорошо словами бросаться - многозвенка-то она многозвенка, это понятно,
это и используем, но что внутри нее, внутри многозвенки-то?

> > Ладно, не суть. Факт в том что класс XML задач намного шире чем эти два
> > пункта. Вкратце, exchange, storage, transformation.
>
> только второй, скорее всего, притянут за уши.

Ну нет же, ну!

> Т.е. если верить тебе, то это один из вариантов exchange.

Хех... С такой точки зрения любой storage это вариант exchange - между
приложением и базой данных,. между приложением и файловой системой - но это
неверный подход. Слишком плоско.

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Aleksei Valikov wrote:
> 
> > > Нет, я так не считаю. Я убедился, что SOAP не дает существенных преимуществ
> > > в моих задачах - и поэтому для меня это не более чем пустой звук, буквально
> > > форма без содержания.
> > Судя по описанию твоей задачи - у тебя типичная задача ;-) Ну то есть я
> > буквально недавно занимался ровно тем же самым - куча "провайдеров"
> > присылали нам свои цены буквально на все, а мы их интегрировали в
> > Оракловскую БД, и обеспечивали по ней поиск через WEB.
> 
> Тут не о таком уровне интеграции речь идет - я не посню, я это описывал или
> нет, но во-первых документы или даже мета-данные не хранятся в общем и целом
> на каком-либо сервере централизованно, это одна из возможностей (просто не у
> всех есть ресурсы создавать свои отдельные компоненты, поддерживать сервера
> и так далее, для этого мы не ценральном сервере сделали XML-репозиторий
> кстати на Оракле полностью, как - могу рассказать), во-вторых центральный
> сервер даже не сам ищет на провайдерах.
Так это не важно. Главное что провайдеры, как я понял, от вас совершенно
не зависят, и результат вашей работы им не очень-то нужен. Я не говорю,
что задача таже самая, ну а вот эффект - примерно тот же самый. Чего
делать - я не знаю, но явно тут не технологические решения нужны.


 

Aleksei Valikov wrote:
> 
> > > Нет, я так не считаю. Я убедился, что SOAP не дает существенных преимуществ
> > > в моих задачах - и поэтому для меня это не более чем пустой звук, буквально
> > > форма без содержания.
> > Судя по описанию твоей задачи - у тебя типичная задача ;-) Ну то есть я
> > буквально недавно занимался ровно тем же самым - куча "провайдеров"
> > присылали нам свои цены буквально на все, а мы их интегрировали в
> > Оракловскую БД, и обеспечивали по ней поиск через WEB.
> 
> Тут не о таком уровне интеграции речь идет - я не посню, я это описывал или
> нет, но во-первых документы или даже мета-данные не хранятся в общем и целом
> на каком-либо сервере централизованно, это одна из возможностей (просто не у
> всех есть ресурсы создавать свои отдельные компоненты, поддерживать сервера
> и так далее, для этого мы не ценральном сервере сделали XML-репозиторий
> X-Mozilla-Status: 0009стью, как - могу рассказать), во-вторых центральный
> сервер даже не сам ищет на провайдерах.
Так это не важно. Главное что провайдеры, как я понял, от вас совершенно
не зависят, и результат вашей работы им не очень-то нужен. Я не говорю,
что задача таже самая, ну а вот эффект - примерно тот же самый. Чего
делать - я не знаю, но явно тут не технологические решения нужны.
 

Hi.

> Так это не важно. Главное что провайдеры, как я понял, от вас совершенно
> не зависят, и результат вашей работы им не очень-то нужен. Я не говорю,
> что задача таже самая, ну а вот эффект - примерно тот же самый. Чего
> делать - я не знаю, но явно тут не технологические решения нужны.

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

Bye.
/lexi




-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

"Pavel Veller" <pveller@itos.eu.org> wrote:
> Aleksei Valikov <valikov@fzi.de> сообщил в новостях:
> [skipped]
> >... для этого мы не ценральном сервере сделали XML-репозиторий
> > кстати на Оракле полностью, как - могу рассказать)....
> Алексей, мне было бы очень интересно, но боюсь уйдем в оффтопик
> этой конфы. Может мылом пообщаемся?

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

Привет всем,
Николай



 

Hi.

> > Алексей, мне было бы очень интересно, но боюсь уйдем в оффтопик
> > этой конфы. Может мылом пообщаемся?
>
> Не смею предвосхищать решение модератора; но мне лично тоже
> было бы _очень_ интересно почитать про 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.

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Здравствуйте Уважаемые.

"Aleksei Valikov" <valikov@fzi.de> wrote in message
news:9f2b53$4uo$1@host.talk.ru...
> Hi.
> > > работают? Persistant объекты, это все хорошо и мило, но когда в
> > > инфрастуктуре работает множество платформ и решений, ты считаешь это
> > > реальным выучить api всего этого безобразия?
> >
> > ну не все так плохо - большинство решений используют устоявшиеся АПИ, будь
> > то COM, или CORBA или EJB. каждое из трех с небольшими затратами может
> > быть преобразовано в XML/DOM
> Можешь мне поверить что насчет "большинство решений используют устоявшиеся
> АПИ", крупными русскими буквами ХРЕН ТАМ!

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

> > И потом, далеко не для всего "безобразия" есть мост безобразия->XML :(
> Об этом я и говорю - чем больше у всех это будет тем меньше мне работать.
:)
> Поэтому не надо задавать вопросов "а зачем это надо".

зачем надо - понятно, непонятно другое - зачем везде, где ни попадя,
использовать XML ?

> > > Естественно такие запросы нафиг не сдались - это просто пример. Если бы
> > > обеспечивалось это, может быть обеспечивалось и что-нибудь более сложное.
> > Ну не зря же люди придумали мульти-тир ;)
> Причем здесь multi-tire? Я говорю о более сложных запросах. На Oracle мы в
> экпортируемых запросах используем object types, коллекции, курсоры, в общем
> чего только "не" чтобы по максимуму приблизить абстракцию реляционных
данных

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

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

а написать еще один "поставщик данных" в многоуровневой среде не
проще/дешевле ?

> > если "хранение", то только для статических данных. Иначе - ...
> Ай... не надо, да про хранение статических данных. Естественно, не в файлах
> хранить. Почитай у Буррета про native XML databases.

ну а в таком случае ты будешь тратить те же ресурсы на преобразование, и в
придачу к этому - можешь потерять на изменениях в структуре данных (XML)
Т.ч. ... я бы поостерегся. Я хочу сказать, что я с удовольствием
посмотрю-почитаю, как у вас все получится, но сам пока не готов сказать, что
XML 4ever ...

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

А при чем здесь семантика ? я имел в виду переносимость данных и т.д.
Т.е. XML - это не частный формат представления, т.е. и использовать его
можно практически везде.

>  А вот если обменивающиеся стороны
> договорятся об одной схеме обмена - вот это радикальный шаг.

правильно, только это уже обмен данными между приложениями, а каков он
будет - один фиг.
будь то IIOP, или RPC или XML

> > а если есть множество DTD ?
> Слушай, ну прочитай ты статью от Флореску - тебе все ясно станет.

думаю - не все, т.е. я согласен, что XML это хорошо, но использовать его
везде - по моему не оправданно

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

а внутри XML'ем может и не пахнуть совсем, вот когда твоя среда начинает
работать наружу тогда - да, XML оправдывает себя почти на все 100 (но опять
же - почти)

> > > Ладно, не суть. Факт в том что класс XML задач намного шире чем эти два
> > > пункта. Вкратце, exchange, storage, transformation.
> > только второй, скорее всего, притянут за уши.
> Ну нет же, ну!

требую сатисфакции, тьфу - доказательств ;)

> > Т.е. если верить тебе, то это один из вариантов exchange.
> Хех... С такой точки зрения любой storage это вариант exchange - между
> приложением и базой данных,. между приложением и файловой системой - но это
> неверный подход. Слишком плоско.

"не надо передергивать" (С) известен многим

т.е. ты согласен хотя бы с тем, что exchange и storage - практически, одно и
тоже ?

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Hi.

> > Можешь мне поверить что насчет "большинство решений используют устоявшиеся
> > АПИ", крупными русскими буквами ХРЕН ТАМ!
>
> тогда уж примеры сюда, при чем именно, для "большинство решений"
> т.к. я пока не сталкивался "слишком часто" с "меньшинством решений", поэтому
> и называю ЭТО - меньшинством

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

И знаешь - просто в разных областях работаем.

> зачем надо - понятно, непонятно другое - зачем везде, где ни попадя,
> использовать XML ?

Никто, как ты, возможно, не заметил, к этому не призывает. Я говорю о том,
что класс задач XML довольно широк.

> так я и говорю, что надобности в этом почти нет.

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

>Т.е. это один из способов решения, но мне кажется - далеко не оптимальный.

Один из самых. Хотя возможно у нас разные оценки оптимальности - для меня
это не только время выполнения.

> > внутри самой базы к целевой XML схеме. И если бы XSQL сервлет этого не
> > поддерживал, пришлось бы делать денормализацию в XSLT, или писать свое
> > решение для экспорта таких запросов.
>
> а написать еще один "поставщик данных" в многоуровневой среде не
> проще/дешевле ?

Я перестаю тебя понимать. Чтобы все было просто, я формулирую задачу а ты
объясняешь, как ты ее декомпозируешь и какую именно из частей решаешь
написанием еще одного поставщика данных.
Задача - обеспечить экпорт, импорт в данной XML схеме иноформации из
реляционной базы данных и обработку запросов в данном XML-based языке
запросов. Все три схемы - представления данных в XML, схема реляционной БД и
языка запросов фиксированы.

> > > если "хранение", то только для статических данных. Иначе - ...
> > Ай... не надо, да про хранение статических данных. Естественно, не в файлах
> > хранить. Почитай у Буррета про native XML databases.
>
> ну а в таком случае ты будешь тратить те же ресурсы на преобразование, и в
> придачу к этому - можешь потерять на изменениях в структуре данных (XML)

Послушай, это перестает быть смешным. Почитай faq от Tamino (Software AG)
http://www.softwareag.com/taminoplatform/faq.htm, может быть что-нибудь
прояснится.

> Т.ч. ... я бы поостерегся.
> Я хочу сказать, что я с удовольствием посмотрю-почитаю, как у вас все получится,
> но сам пока не готов сказать, что XML 4ever ...

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

> > Нет, не так. XML это не "универсальный протокол" и далее по тексту. XML это
> > формат представления, который может быть легко обработак. Как протокол
> > обмена он сильно больших преимуществ не дает (я опять о семантике, ну
> > область моя, ну что поделаешь).
>
> А при чем здесь семантика ? я имел в виду переносимость данных и т.д.

XML без априорной семантической информации переносимость данных не
обеспечивает. In plain English, прочитать-то это прочитают, но не поймут.
Или переносимость - это "сам читаю сам пишу"? Тогда хоть csv...

> > > > пункта. Вкратце, exchange, storage, transformation.
> > > только второй, скорее всего, притянут за уши.
> > Ну нет же, ну!
>
> требую сатисфакции, тьфу - доказательств ;)

Вон твоя сатисфакция, в коробках продается Tamino называется.

> т.е. ты согласен хотя бы с тем, что exchange и storage - практически, одно
и тоже ?

Ты прочитай еще раз сам что написал. Это абсолютно разные вещи которые
задействую абсолютно разные механизмы.

Bye.
/lexi



-- 
Отправлено через сервер Talk.Ru - http://www.talk.ru
 

Здравствуйте Уважаемые.

"Aleksei Valikov" <valikov@fzi.de> wrote in message
news:9f3hl9$dga$1@host.talk.ru...
> Hi.
> > > АПИ", крупными русскими буквами ХРЕН ТАМ!
> И знаешь - просто в разных областях работаем.

опустим, ок ? а то мы уже вышли за пределы топика.

> Никто, как ты, возможно, не заметил, к этому не призывает. Я говорю о том,
> что класс задач XML довольно широк.

т.е. и здесь нашли компромис ;)

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

скорее всего ты не так меня понял - я к тому, что прослойка так и так будет,
legacy DB ли это или нечто частное.

> >Т.е. это один из способов решения, но мне кажется - далеко не оптимальный.
> Один из самых. Хотя возможно у нас разные оценки оптимальности - для меня
> это не только время выполнения.

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

> > а написать еще один "поставщик данных" в многоуровневой среде не
> > проще/дешевле ?
> Я перестаю тебя понимать. Чтобы все было просто, я формулирую задачу а ты
> объясняешь, как ты ее декомпозируешь и какую именно из частей решаешь
> написанием еще одного поставщика данных.
> Задача - обеспечить экпорт, импорт в данной XML схеме иноформации из
> реляционной базы данных и обработку запросов в данном XML-based языке
> запросов. Все три схемы - представления данных в XML, схема реляционной БД и
> языка запросов фиксированы.

здесь писать уже не буду, это будет несколько длинно, но чуть позже - напишу

> > ну а в таком случае ты будешь тратить те же ресурсы на преобразование, и в
> > придачу к этому - можешь потерять на изменениях в структуре данных (XML)
> Послушай, это перестает быть смешным. Почитай faq от Tamino (Software AG)
> http://www.softwareag.com/taminoplatform/faq.htm, может быть что-нибудь
> прояснится.

вот получу от них XML Starter Kit - посмотрим,
а пока, то что я у них прочитал - то же самое, что я и говорил. Только они
предлагают уже готовое решение и не за маленькие деньги, чтобы пойти на
такой риск.

> > Т.ч. ... я бы поостерегся.
> > Я хочу сказать, что я с удовольствием посмотрю-почитаю, как у вас все получится,
> > но сам пока не готов сказать, что XML 4ever ...
> Никто ведь не заставляет. Это очень разумно - с критических позиций
> подходить к новым технологиям, ибо они требуют вложений как человеко-времени
> так и денег. И если устраивают существующие решения, то как в анекдоте,
> "ничего не трогай, сынок".

опять вышли на компромис ;)
 - XML надо использовать там, где это на самом деле всесторонне оправдано.

> > > Нет, не так. XML это не "универсальный протокол" и далее по тексту. XML это
> > > формат представления, который может быть легко обработак. Как протокол
> > > обмена он сильно больших преимуществ не дает (я опять о семантике, ну
> > > область моя, ну что поделаешь).
> > А при чем здесь семантика ? я имел в виду переносимость данных и т.д.
> XML без априорной семантической информации переносимость данных не
> обеспечивает. In plain English, прочитать-то это прочитают, но не поймут.
> Или переносимость - это "сам читаю сам пишу"? Тогда хоть csv...

опс, да мы просто говорим на разных языках ;)
и здесь почти компромис ;)
(это я к тому, что node somemydata в разных DTD может иметь совершенно
разную смысловую нагрузку, а заставить всех "делать как я" - невозможно)

> > > > > пункта. Вкратце, exchange, storage, transformation.
> > > > только второй, скорее всего, притянут за уши.
> > > Ну нет же, ну!
> > требую сатисфакции, тьфу - доказательств ;)
> Вон твоя сатисфакция, в коробках продается Tamino называется.

продается, но в SoftAG ни кто не говорит, что XML там используется везде.
Наружу - да, а у нутре - "а у нутре у ние нийонка".

> > т.е. ты согласен хотя бы с тем, что exchange и storage - практически, одно
> и тоже ?
> Ты прочитай еще раз сам что написал. Это абсолютно разные вещи которые
> задействую абсолютно разные механизмы.

так мы придем к компромису или нет ? ;)
я утверждаю, что ... !
0) рассмотрим классическую систему клиент-сервер, т.е. клиент требует некие
данные, активируя при этом сервер, а сервер же в ответ эти данные отдает.
1) на сервере некие данные (RDBMS, File-System & etc) преобразуются в XML и
посылаются клинету
2) клиент, получив XML, преобразует его к своему формату (например,
веб-браузер к графическому - изображение на экране)

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

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

 г-------  Hello Vladlen! How are you ?  --------

 Прочитал недавно Четверг Май 31 2001 что Vladlen Bulatov написал All и
отбарабанил:

 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.

   with *.*

 Fight The Future ... e-mail:faceless(at)trans.nsys.by ICQ:48066659