|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Ilya Bricker 2:5020/400 29 Mar 2001 10:36:49
To : All
Subject : Re: Cache and WWW
--------------------------------------------------------------------------------
Здравствуйте, Constantin!
"Constantin Svintsoff" <kostik@iclub.nsu.ru> wrote in message
news:Pine.BSF.4.21.0103281708140.63492-100000@iclub.nsu.ru...
> Hi, there!
[...]
> > 2. Почему это хуже, если передаются аттрибуты не одного объекта, а их
> > множества, т.е. RecordSet (подсказка несколько CORBA-вызывов вместо
одного
> > при использовании XML)
>
> Подсказка:
> typedef sequence<AttributeList> ObjectsAttributesList;
> далее понятно.
Это простейший, частный вариант решения. Проблема более общая:
как совершить сложную транзакцию (просто получение данных я тоже
рассматриваю как транзакцию) в рамках одного запроса.
CORBA не предлагает нормального решения, хотя и могла бы.
"не"нормальных решения два:
1. инициировать транзакцию с клиента и дергать в ней элементарные
методы типа get/set. Интересный эффект возникает даже на мегабитных
каналах связи, но имеющих высокую латентность (например, спутниковый
канал с пингом 300). Сложная транзакция может длиться десятки секунд,
причем 99% времени будет уходить на передачу данных туда-сюда после
каждого вызова метода, а их могут быть десятки-сотни в одной транзакции.
2. городить монстрообразные производные типы данных из вложенных
структур и сиквенсов. В конечном итоге это приводит к появлению
образований типа <название свойства, значение свойства>
Hормальное решение, которое могла бы предложить корба, было бы
пакетирование серии вызовов, но видимо тогда не обойтись без привязки.
> > 3. Как передать иерархический RecordSet, поддержать перекодировку
> > национальных символов, поддержать NULL-значения? Сделать новую структуру
и
> > при этом изменить интерфейс (это, прямо скажем, непростой процесс в
> > работающей системе)? Или сделать более общий вариант и в результате
> > изобрести собственный язык разметки данных?
>
> Эта.. Это по моему ничем не сложнее, чем переделывать DTD и те свои части,
> которые этот XML понимают. Да, idl-интерфейс у вас не поменяется, но
> никаких плюсов в этом нет. Потому то, что РЕАЛЬHО является интерфейсом (а
> это уже в вашем случае не только idl интерфейс, а еще и DTD для XML
> документов) тоже меняется.
Плюсы в том, что не меняется IDL-интерфейс, очень даже значительные.
Hе надо заново генерить стабы, компилировать клиентов, обновлять софт по
всем
рабочим местам.
Предположим, в некоторой таблице добавилось поле comments varchar(...) null
allow
В XML мы просто вставляем новый атрибут, и старая версия клиента, и новая
версия могут работать одновременно.
Если меняется специфика некоторой операции, то она как правило не
пересматривается в корне, а расширяется. Тут путь простой, просто добавляем
новые субэлементы в элемент операции.
Если меняется семантика операции, что уже не есть хорошо т.к. это говорит
о плохом проектировании, но все же что мешает добавить номер версии клиента
в XML-элемент операции или в название пространства имен.
И получим полную обратную совместимость. Такой же путь подходит если
применяется некий механизм валидации, но валидировать или нет XML это
уже дело хозяйское, тогда как у CORBA всегда жесткая валидация при
маршаллинге.
> А если сказать:
> XML - удобное и похоже, единственное в свем роде средство для организации
> информационного обмена между HЕКОТОРЫМИ объектами в HЕКОТОРЫХ системах,
> в том числе и построенных с использованием CORBA.
> то это не вызывает никаких сомнений.
>
> Я прав или я совершенно прав ? :)
Формально прав, но не надо ехидничать :-)
Конечно для запроса к температурному датчику XML не нужен
А в контексте эхотага Сергей даже более прав :-)
--
Илья Бриккер
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
