BEA купят, а жаль

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/10/bea.aspx

eWeek сообщил на днях о единодушной уверенности всех западных аналитиков в том, что в ближайшие полгода состоится покупка BEA каким-нибудь из крупных вендоров. Причины – у компании не ладится бизнес в северной Америке и она не добирает оборотов относительно прогнозов. В первом квартале прогнозировали $358, получили -- $342. Акции упали, соответственно с $16 до $11.

Основных покупателей два: Oracle и Hewlett-Packard. Руководство Oracle не скрывает, что хочет сделать это приобретение, но просто ждет подходящего момента. HP тоже в покупке заинтересовано, но у нее хуже с деньгами – она не может выплатить такую же премию за акции, как Oracle. (См. http://www.eweek.com/print_article2/0,1217,a=213246,00.asp)

Мне, как аналитику в этой области, искренне жаль. Программный комплекс BEA был построен очень грамотно и качественно. Вряд ли наиболее вероятный покупатель (Oracle) сохранит платформы WebLogic и AquaLogic как они есть. Middleware – не ERP, и ситуация с PeopleSoft вряд ли повторится. Скорее всего будет взят курс либо на полную ликвидацию этого ПО, либо на его унификацию с аналогичными линейками Oracle (SOA Suite, BPM Suite), возможно с сохранением лишь отдельных продуктов.

Как бы то ни было, но ухудшение состояния BEA указывает на изменение спроса на рынке middleware, где все меньше возможностей остается для независимых поставщиков «тяжелых» платформ.

//Влад Боркус

Published 10 сентября 2007 г. 13:28 by Vlad Borkus
Filed under: SOA

Comments

Математика рисков ИТшника: нужна ли нам автостраховка?

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/03/20383.aspx

Нам, специалистам по ИТ с высшим образованием, негоже тратить деньги так же бездумно, как прочим простым смертным. Образование требует, чтобы перед покупкой чего бы то ни было производилось сравнение и оценивались риски. Вот и я задумался над вопросом, в выгодна ли автостраховка КАСКО? Проведем элементарную математическую оценку, исходя из принципа, что страховая компания не должна работать в убыток:

Цена страховки = (вероятность наступления случая)*(стоимость случая) +(прибыль страховщика).

Так как прибыль страховщика всегда больше ноля, то мы в среднем всегда в накладе – страховка это «разводка». Но может есть в этом деле потаенный смысл? Провел опрос знакомых на предмет покупают ли они КАСКО и окупается ли это?

Артур. Первый год вождения. Страховку не покупал. Несколько мелких инцидентов общей ценой менее $1000. Баланс цена страховки/ремонт: $2500(теоретическая)/$1000.

Марина, Купила страховку. Стаж вождения 15 лет. Цена страховки $1500. За пять лет несколько инцидентов общей ценой $1000. Баланс страховка/ремонт -- $7500/$1000. В итоге сомневается в нужности страховки.

Михаил. Сторонник страховки. Считает, что она убыточна, но покупается просто спокойствие. Денежной составляющей не раскрыл.

Ольга – покупает страховку 5 лет по цене $1200. Стаж вождения 10 лет. За это время 4 камня в лобовое стекло (замена ценой $350) плюс авария с ремонтом на $5000. Баланс страховка/ремонт: $6000/$6400. Ее брат – взял назад стоимость страховки в нескольких авариях, теперь его отказываются страховать. Баланс за пять лет: $12000/$20000.

Татьяна – стаж 10 лет. Машину не страхует. За 7 лет использования машины мелкие проблемы на менее чем $1000. Баланс: $7500(теоретическая)/$1000.

Андрей -- машину не страхует (не считает выгодным, так как работает в страховой компании :)). За пять лет проблем на $2000. Баланс: $7500(теоретическая)/$2000.

Есть, в общем, повод задуматься. Вероятно, страховать от угона все же для спокойствия нужно, так как стоимость случая получается большая, а цена страховки ($250 в год) мала. А вот страховать от аварий, кроме как по ОСАГО получается как-то не очень обоснованно.

Вопрос: это у всех так или выборка такая? Кто чего думает?

//Влад Боркус

Published 3 сентября 2007 г. 14:03 by Vlad Borkus Edit
Filed under: Жизнь

Comments

IBM: ESB мешает SOA

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/03/ibm-esb-soa.aspx

Несколько лет, когда технология ESB (Enterprise Services Bus) была «коньком» фирмы Sonic Software, корпорация IBM ее недолюбливала. Но потом, когда ESB была разрекламирована Garnter, то IBM резко сменила позицию и выпустила свой ESB-продукт. Но вот недавно на сайте DeveloperWorks появилась статья о том, что увлечение ESB мешает правильному пониманию концепций SOA, подменяя внедрение архитектуры внедрением программного продукта. (http://www.ibm.com/developerworks/webservices/library/ws-soa-esbarch/index.html)

Многие блоггеры восприняли статью как знак того, что IBM «сдает» ESB, хотя внимательное чтение показывает, что это не так. Скорее IBM подводит читателя к мысли, что помимо покупки ESB стоило бы приобрести и консалтинг в области SOA.

Главных тезисов по ESB и SOA всего два:

• внедрение ESB-ориентирвоанной архитектуры само по себе не дает добавочной бизнес-стоимости, так как это чисто технологическое решение для соединения сервисов;
  
• в отличие от ESB главная цель SOA – это согласование бизнес-мира и мира ИТ, а потому несет четкую бизнес-ценность.
  

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

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

• Не создавать системы «на будущее».
  
• Внедрять только то, что уже нужно бизнесу;
• Стыковать потребности бизнеса и ИТ-решение.
  

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

Published 3 сентября 2007 г. 0:01 by Vlad Borkus
Filed under: SOA, ESB

KM-2007 Обзор персональных систем сбора информации и управления знаниями

Основные результаты исследования опубликованы в еженедельнике PCWeek/RE, здесь же приводятся некоторая дополнительная методическая информация.

Ограничение ответственности

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

 

Рассмотренные системы

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

Лидеры (системы, имеющие функционал наиболее полно отражающий сформулированные потребности):

• Macropool GMBH WebResearch. Лучше всего организовано сохранение из Web;


• Kinook Ultra Reсall. Обладает самыми развитыми механизмами классифкации;


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

(Замечание. Метрика обновлена на 16.05.2007 для отражения некоторых новых требований).

Другие изучавшиеся продукты:

AskSam (www.asksam.com), MDE Infohandler (www.mdesoft.com), eGems Gemteque Software (www.egems.com), Personal Knowbase (www.bitsmithsoft.com), Baltsoft General Knowledge Base, TreePad фирмы Freebyte (www.treepad.com), EverNote, Knowledge Workshop (www.lmsweb.com), Inquiry Professional (metaproducts.com), ScrapBook for Firefox, WikiD, ConnectedText и другие Wiki-системы, IBM Lotus Domino, Microsoft SharePoint Portal/WSS и еще пара десятков других, менее интересных продуктов.

Методика анализа

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

На наш взгляд система должна поддерживать такие сценарии, как:

Сценарии использования («высокоуровневые»)

С1. Интенсивное накопление "знаний" в ходе исследовательского проекта.

Особенности: меньший объем информации, узкая и интенсивная направленность ее потока, мелкая детализация классификатора.

Типовые операции: накопление документов и вырезок в ходе проекта, интенсивная обработка (удаление мусора, выделение главного); создание связанных заметок формирование из этих заметок нового документа (например: высказываний товарищей при формировании требований, накопление собственных мыслей (заметок), их привязка к документам).

С2. Фоновое (медленное и длительное) накопление "знаний".

Особенности: большой объем информации, широкий разброс тем, низкая плотность информации по темам. А стало быть и более грубый классификатор.

Типовые операции: накопление документов и вырезок на долговременной основе, минимальная обработка;

С3. Выемка информации по теме.

Сценарии использования («низкоуровневые»):

• «мгновенное» сохранение Web-страницы;


• захват выделенной части Web-страницы;


• захват вырезок из не Web-содержимого;


• импорт файлов из файловой системы;


• классификация содержимого по иерархическому рубрикатору;


• классификация по ключевым словам;


• отнесение документа к разным разделам классификатора;


• создание и редактирование заметок и документов;


• связывание документов перекрестными ссылками;


• поиск документов;


• печать и экспорт.

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

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

Самым существенным качеством, различающим системы является примененная в них метафора классификации, так как именно она определяет совместимость или несовместимость со стилем мышления пользователя. Иначе говоря, система с одной метафорой будет казаться ему логичной, а с другой -- нет. Помимо всего перечисленного, система должна полностью поддерживать русский язык, а также быть устойчивой к сбоям программного и аппаратного обеспечения. А для использования в рабочих группах она должна поддерживать сетевой доступ и разграничение прав доступа. В приведенных выше сценариях много всевозможных тонкостей, и при их детализации набралось примерно 150 требований (www.konnasi.ru/wgkm_compare.htm). При анализе рынка был просмотрен широкий спектр кандидатов, но значительная их часть по разным причинам отпала уже на первых его этапах.

Описание проекта можно посмотреть здесть (сохраненная копия PCWeek/RE)

 

Основные результаты

Исследование не выявило продукта на 100% удовлетворяющего наши потребности, несмотря на то, что был рассмотрен по меньшей мере десяток из них. Три продукта Macropool GMBH WebResearch Professional (www.macropool.com), Kinook UltraRecall (www.kinook.com), WJJSoft MyBase (www.wjjsoft.com) в наибольшей степени приближаются в понятию оптимальной системы. Для временного использования мы выбрали первую из перечисленных систем, несмотря на ее заметные недостатки в области классификации информации. Мы с интересом будем наблюдать за эволюцией рассмотренных решений.

Рабочие документы

Оценка систем Macropool GMBH WebResearch, Kinook Ultra Recall 3.0 Professional, WJJSOFT MyBase 5.3 по метрике

Итоговые диаграммы.

Степень соответствия группам ключевых (наиболее важных) требований

Степень соответствия группам всех (как важных, так и неважных) требований

Таблица. Интегральные оценки систем по группам критериев метрики, с учетом весов.

Таблица. Сильные стороны систем

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

WS-Security: начинание благое, но безопасность SOA не обеспечивает

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/08/19/ws-security.aspx

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

Примерно так обстоит дело со стандартами в области безопасности SOA. В стеке WS-* запланирована очень глобальная модель безопасности, включающая почти десяток всяких спецификаций (WS-Security, WS-Secure Conversation, WS-Trust, WS-Federation, WS-Policy, а также XML Digital Signature, Security Tokens Profiles (для SAML, Kerberos,X.509) и т. п.

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

Я бы не стал писать про это статью, но на днях натолкнулся на интересное выступление на эту тему специалиста в области безопасности Брэда Хилла (http://www.isecpartners.com/files/iSEC_HILL_AttackingXMLSecurity_bh07.pdf). В почти 200-страничной презентации обстоятельно показывается, почему стек WS-S -- пока не лучший способ для обеспечения безопасности для открытых в Интернете сервисов,B2B-сервисов и внутрикорпоративных web-сервисов.

Во первых, для любых внутрикорпоративных и B2B ИТ-систем характерна более высокая степень доверия к их пользователям, и проблемы безопасности как правило решаются "не внутрикорпоративными фаерволами, а организационными мероприятиями и [в случае B2B] адвокатами". Главное, что должна обеспечить общая инфраструктура безопасности -- это протоколирование всех действий и точную идентификацию пользователей, получивших доступ к конкретной системе. Это тезис, с которым сложно не согласиться.

Но для этих задач ЛУЧШЕ всего подходит стандартный SSL, при одновременном применении _клиентского_ и северного сертификатов. В самом деле, у него есть набор явных преимуществ:

1) Он решает как задачу безопасной аутентификации (по сертификату);
2) Он защищает трафик от пользователя к системе;
3) Что еще более важно -- он совершенно ОДИНАКОВО реализован во всех системах, в том числе старых -- пяти и даже более летней давности;
4) Он покрывает 99% процентов того, что нужно для решения реальных задач.

Модель же безопасности на уровне сообщений, примененная в WS-S, не дает в этом смысле никаких преимуществ, так как опять-таки в 99% случая все, что от нее требуется -- это аутентификация пользователей. Но он также неодинаково реализован на новых и старых системах, а применение агентов-посредников тоже не всегда удобно и эффективно. Также WS-S (в конечном итоге за счет XML Digital Signature) опирается на шифрование больших объемов данных открытыми ключами – очень ресурсоемкая операция по сравнению с симметричным шифрованием в SSL. Поэтому при использовании для интеграции внутрикорпоративных систем WS-Security оказывается менее адекватен, чем SSL.

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

WS-Security плох тем, что для его реализации используется работа многих слоев (от XML Encryption, XML Digital Signature, Security Tokens Profiles (SAML, Kerberos, X.509), WS-Trust, WS-Federation и т.п) -- слишком много точек для потенциальной атаки, слишком сложно заставить все это скоординировано работать.

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

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

//Влад Боркус, www.konnasi.ru

Published 19 августа 2007 г. 23:09 by Vlad Borkus Edit
Filed under: SOA, Безопасность

Comments

Место виртуализации

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/08/17/_1C043504410442043E04_-_3204380440044204430430043B04380437043004460438043804_.aspx

В последние дни в прессе появилось много статей по поводу слияния Citrix и компании Xen Source, производящей ПО виртуализации. Это заставило и меня выйти из спячки, чтобы вставить свои два слова.. Вообще-то я считаю направление виртуализации слегка переразрекламерированным, но есть в нем и полезное зерно. Пользу, как мне кажется могут принести несколько направлений:

1. Применение для организации виртуальных серверов в публичных бизнес-проектах. Это в первую очередь, конечно, уже широко используемый виртуальный Web-хостинг. Но возможно и множество других вариантов. Например, при наличии хороших каналов свзяи можно предложить малому бизнесу полный хостинг ряда бизнес-систем на выделенном виртуальном сервере.
Для хостера эффективнее держать один мощный сервер, поделенный на 10 виртуальных, чем десять реальных серверов, -- нагрузка будет равномернее. Следовательно, можно сэкономить на цене закупки и поддержки -- хотя только до той точки, где цена многопроцессорного сервера начинает сильно отклоняться от линейной корреляции с числом/мощностью процессоров в сторону экспоненциальной зависимости. Естественно, доступ к подобным серверам часто будет терминальным и тут как раз ясно, где выгода от альянса Citrix и Xen. При этом клиенту от виртуализации тоже хорошо -- он уверен, что его данные не увидит конкурент, а забититься о сервере не нужно. В подобном хостинге важно, что сервера, принадлежащие несвязанным между собой компаниям, являются абсолютно изолированными логически.

2. В корпорациях для систем уровня департаментов.
Здесь, однако, выигрыш от виртуализации может временами оказаться меньше, чем в публичном хостинге. В конце концов это не критические для бизнеса, работающие с большой нагрузкой, -- их _всегда_ ставят выделенный сервер. Но число и загрузку серверов уровня департамента в принципе можно оптимизировать просто путем помещения нескольких софтверных пакетов на один большой сервер, а не на несколько выделенных, т.е. это вопрос планирования ИТ. Хотя, конечно, это не всегда возможно из-за организационных заморочек крупных фирм, и не всегда желательно иметь на одной машине много программ из-за их воздействия друг на друга.
Полезно понимать, что в корпорациях сервера не изолированы, а связаны между собой доверительными отношениями, общими службами каталогов, устройствами и т.п. Это требует высокой открытости виртуального сервера для внешнего (внутрикорпоративного) мира и управления его внутренностями "снаружи". Частично проблема есть и в публичных проектах -- когда нужно подключать устройства, расположенные у клиента локально, скажем, принтер или переносной накопитель. Но там она более мелкого масштаба.

3. Распространение готовых виртуальных «устройств», по английски называемых appliance. Я считаю, что у этого направления большое будущее. Виртуальные appliances снимают кучу проблем с инсталляцией и первичной настройкой ПО. Самую большую пользу подобные устройства дают при распространении _ознакомительных_ версий сложных корпоративных программ. Уже сейчас таких пакетов десятки на сайте VMWare и это число будет расти. VMWare здесь четкий лидер, хотя и Microsoft'у есть что предложить.
Заметим, что по п.1 и 2. есть разные подходы к виртуализации. Первый -- это тот, что предлагает VMWare, Microsoft -- установка эмулятора под определенной ОС и эмуляция "гостевой ОС" в рамках обычного системного процесса. Полная эмуляция аппаратной платформы -- довольно сложная задача и здесь много разных "засад", поэтому результаты работы одной и той же комбинации ОС и прикладного ПО под VMWare и на "реальном железе" могут быть разными. Хотя при этом легче создавать виртуальные appliance.
Второй путь -- это установка ПО виртуализации ВМЕСТО операционной системы. Это ПО (паравиртуализация) является брокером между гостевыми ОС и нижележащими устройствами. Гостевые ОС при этом получают более низкий уровень привилегий, нежели тот, что им положен по "статусу ОС".
Это как раз тот путь, который исповедует Xen Hypervisor, SWSoft Vituozzo, SWSoft Parallels (на десктопе и сервере) и присмотрела для себя на будущее Microsoft в продукте Windows Hypervisor. Эффективнее всего подобную виртуализацию делать, если на всех виртуальных серверах крутится одна ОС. Тогда необходимо минимум эмуляции, а стало быть минимален и перерасход процессорных ресурсов. В этом смысле более потенциально производительным является продукт SWSoft Vituozzo.
В системе, где гостевые ОС различны (даже если это просто версии Windows) для надежноcти и скорости работы эмуляторов и паравиртуализаторов нужна поддержка со стороны процессоров, и современные процессоры Intel и AMD эту поддержку предоставляют. Но еще нужна и некоторая поддержка со стороны гостевой операционной системы...хотя в новых версиях Linux, Windows, Solaris она уже имеется. Конечно, в реальной жизни сложности остаются.
Теоретически подход паравиртуализации позволяет вплотную приблизить производительность виртуальной ОС к производительности лежащего в ее основе железа. Дискуссию на тему производительности можно, например, найти в документах фирмы Xen Source ( http://www.xensource.com/Documents/hypervisor_performance_comparison_1_0_5_with_esx-data.pdf .Вообще у этой компании интереснейший white papers, которые рекомендую почитать всем, кто интересуется темой.)
Интересным результатом является то, что на основных задачах производительность составляла от 80 до 100% производительности исходной аппаратной платформы. На мой взгляд это поразительные достижения средств виртуализации, хотя я и верю в них с трудом.
//Влад Боркус
Published 17 августа 2007 г. 1:13 by Vlad Borkus
Filed under: Виртуализация

Comments

Недоделанный стандарт XQuery

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/08/15/_1D04350434043E04340435043B0430043D043D044B043904_-_4104420430043D043404300440044204_-XQuery.aspx

Прочитал на неделе IBM Red Book, посвященный работе с XML в СУБД DB2. Хотя качество этих книг в последнее время падает -- их пишут коллективы авторов, редактура слабая, что приводит к большому числу повторов, -- эти книги все еще интересны и познавательны.

DB2, как известно, очень хорошая СУБД. Я в нее «влюбился» еще лет десять назад просто за программы инсталляции и администрирования -- все было настолько удобно по сравнению с Oracle DB, что использовать Oracle больше не хотелось.

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

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

Вокруг XML-СУБД было много шума в свое время, так как они существенно снижают нагрузку на разработчика приложений. И сейчас еще встречаются статьи на тему «как важно в SOA использовать «родную СУБД», а не гибридную»  и т.п. Но интерес к ним стих, так же, как когда-то спал интерес к объектным базам.

«Чисто» XML базы в существенной степени были вытеснены гибридными решениями на базе традиционных СУБД. Вначале гибриды были совсем примитивными (позволяли только хранить строку XML в поле BLOB), но потом обросли поддержкой специальных XML-полей в таблицах и стандарта XML-запросов Xquery.

По этому пути пошла и DB2. Она позволяет смешивать в запросах как SQL-поля, так и XQuery-поля, что дает возможность извлекать данные изнури XML-документов. Скажем, если сделать запрос на языке SQL-XML, то  можно делать выборку (SELECT) одновременно по полям таблицы и XML-иерархии, и выдавать результат в виде обычной SQL-таблицы. Или, наоборот, сделать запрос XQuery и получить результат в виде документа XML.

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

Но, что интересно, что вся красивая картинка рушится, когда надо записывать данные в XML. Записать можно только целый документ  -- стандарт XQuery 1.0 не поддерживает записи внутрь XML, только извлечение данных. Соответственно, гибридные СУБД предлагают некоторые обходные маневры -- в том числе DB2 имеет специальную хранимую процедуру -- но все равно это уже не стандартно, да и не очень эстетично.

 //Влад Боркус

Published 15 августа 2007 г. 3:15 by Vlad Borkus
Filed under: XML, СУБД, Базы Данных

Comments