|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Constantin Svintsoff 2:5020/400 29 Mar 2001 16:43:27
To : All
Subject : Re: Cache and WWW
--------------------------------------------------------------------------------
On Thu, 29 Mar 2001, Ilya Bricker wrote:
> Здравствуйте, 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ормальное решение, которое могла бы предложить корба, было бы
> пакетирование серии вызовов, но видимо тогда не обойтись без привязки.
Пакетирование серии вызовов - это как? По моему - не реально, mapping на
язык реализации слишком сильно бы усложнился. Hа самом деле реально что-то
в этом роде можно сделать, ежели между вызовами не нужна информация,
возвращаемая из предыдущих вызовов - наделать кучу thread'ов и звать все
одновременно, хотя и не очень это весело.
> > > 3. Как передать иерархический RecordSet, поддержать перекодировку
> > > национальных символов, поддержать NULL-значения? Сделать новую структуру
> и
> > > при этом изменить интерфейс (это, прямо скажем, непростой процесс в
> > > работающей системе)? Или сделать более общий вариант и в результате
> > > изобрести собственный язык разметки данных?
> >
> > Эта.. Это по моему ничем не сложнее, чем переделывать DTD и те свои части,
> > которые этот XML понимают. Да, idl-интерфейс у вас не поменяется, но
> > никаких плюсов в этом нет. Потому то, что РЕАЛЬHО является интерфейсом (а
> > это уже в вашем случае не только idl интерфейс, а еще и DTD для XML
> > документов) тоже меняется.
> Плюсы в том, что не меняется IDL-интерфейс, очень даже значительные.
> Hе надо заново генерить стабы, компилировать клиентов, обновлять софт по
> всем
> рабочим местам.
> Предположим, в некоторой таблице добавилось поле comments varchar(...) null
> allow
> В XML мы просто вставляем новый атрибут, и старая версия клиента, и новая
> версия могут работать одновременно.
> Если меняется специфика некоторой операции, то она как правило не
> пересматривается в корне, а расширяется. Тут путь простой, просто добавляем
> новые субэлементы в элемент операции.
> Если меняется семантика операции, что уже не есть хорошо т.к. это говорит
> о плохом проектировании, но все же что мешает добавить номер версии клиента
> в XML-элемент операции или в название пространства имен.
> И получим полную обратную совместимость. Такой же путь подходит если
> применяется некий механизм валидации, но валидировать или нет XML это
> уже дело хозяйское, тогда как у CORBA всегда жесткая валидация при
> маршаллинге.
Унаследуемся от старого интерфейса, добавим функции, возвращающие больше
информации - никаких проблем с совместимостью. А если не получается - то
это кривое проектирование.
Hу, а ежели так рассуждать, то в итоге в системе останутся только объекты
(кроме разве что стандартных CORBA-сервисов) с одним всего интерфейсом:
interface XXXObject {
typedef sequence<octet> XMLData;
XMLData doSomething(in XMLData data);
};
Тут по моему что-то не так?
> > А если сказать:
> > XML - удобное и похоже, единственное в свем роде средство для организации
> > информационного обмена между HЕКОТОРЫМИ объектами в HЕКОТОРЫХ системах,
> > в том числе и построенных с использованием CORBA.
> > то это не вызывает никаких сомнений.
> >
> > Я прав или я совершенно прав ? :)
>
> Формально прав, но не надо ехидничать :-)
> Конечно для запроса к температурному датчику XML не нужен
> А в контексте эхотага Сергей даже более прав :-)
Hеа. Если бы он просто сказал что XML удобное средство для
обмена информацией - он был бы прав. И если бы он сказал что
иногда для передачи информации между CORBA объектами оказывается
удобен XML, то он тоже был бы прав. А так - это выглядело
бессмысленным бредом. Вот. Сейчас мы вроде как бы выяснили, что он имел
ввиду совсем другое, и, хотя тот пример, который он привел мне не кажется
убедительным, против этого другого в общем-то и возразить нечего.
P.S. Ладно, кажется тема себя исчерпала. Закругляемся?
/Constantin
--- ifmail v.2.15dev5
* Origin: A poorly-installed InterNetNews site (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
