![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Может ли MIDAS сервер [D5, Oracle]
sergey32 © (2002-07-23 14:50:00)поддерживать системные сообщения для пользователей,
которые зарегистрированы на сервера?
Например при измении данных в какой-то определенной таблице
выдавать сообщения пользователям, что эта таблица была изменена.
Digitman (2002-07-24 11:55:00) [1]>sergey32
Конечно, можно) Отчего ж нельзя ? Было б желание ...
sergey32 (2002-07-24 11:52:00) [2]Так все-таки можно это сделать или нет?
Digitman (2002-07-24 11:39:00) [3]>sergey32
В принципе - да. Но при условии обеспечения четкой сериализации прямых и обратных вызовов. Иначе - "зависания" и клиента и BSS тебе гарантированы. Не предусматривает их транспортный уровень такой возможности. А доработка трансп.уровня - это уж, извини, далеко не 20 строк ...
Иными словами - без доработки транспорта не удастся добиться полной асинхронности и независимости друг от друга прямых и обратных вызовов
Digitman (2002-07-24 11:35:00) [4]>sergey32
В принципе - да. Но при условии обеспечения четкой сериализации прямых и обратных вызовов. Иначе - "зависания" и клиента и BSS гарантированы.
Polevi (2002-07-24 11:34:00) [5]ты сможешь это сделать если поймешь смысл этих изменений
sergey32 (2002-07-24 11:20:00) [6]т.е. если я допишу в sconnect.pas эти изменения, то я смогу отправлять пользователям сообщения?
Digitman (2002-07-24 11:08:00) [7]>sergey32
Ты ошибаешься.
Сервер BSS (в проекте scktsrvr.dpr , если ты, конечно, о нем говоришь как об основе) в создаваемых им клиентских транспортных кодовых потоках использует как минимум тот же маршаллер, что и у клиентов BSS (TSocketConnection), именно - класс TDataBlockInterpreter. А этот класс описан и реализован как раз в SConnect.pas
server5_TLB.pas здесь ни при чем - это как раз реализация собственно фабрики класса AppServer"а, это просто бизнес-логика. Мы же здесь говорим о транспорте и маршаллинге как об "узких" местах в стандартном ПО для реализации твоей задачи
sergey32 (2002-07-24 11:00:00) [8]Задача такая:
есть таблица, в которую записываютя ID_MESSAGEи ID_USER
надо, чтобы при добавлении записи в эту таблицу,
у пользователя, для которого было отправлено сообщение,
на экране появилась мессага, что пришло сообщение.
Polevi (2002-07-24 10:58:00) [9]IAppServerModule содержит лишь один метод SetClientCallback(IUnknown) - этот интерфейс нужен лишь для того чтобы AppServer мог передать модулю клиентский интерфейс, полученный им от клиента. Клиент должен реализовать IClientCallback - не вижу в этом никаких проблем, просто internal auto server..
sergey32 (2002-07-24 10:49:00) [10]В той реализации, на которой написан этот сервер SConnect.pas не используется.
Там используется scctsrvr как основа.
и вторая часть сервера сделана на основе server5_TLB.pas
Digitman (2002-07-24 10:33:00) [11]>Polevi
Все это замечательно и вполне понятно мне - примерно то же самое есть и в составе моих комплексных доработок...
но вот ведь "задачка" : чтобы эта "кухня" заработала, придется регистрировать на кл.стороне фабрику класса, реализующего интерфейс IAppServerModule. Как тебе это смотрится ?
sergey32 (2002-07-24 10:26:00) [12]В той реализации, на которой написан этот сервер SConnect.pas не используется.
Там используется scctsrvr как основа.
и вторая часть сервера сделана на основе server5_TLB.pas
Polevi (2002-07-24 10:12:00) [13]2Digitman ©
я имел в виду что callback вызовы могут носить нотификационный характер - в ответ клиент может сам вызвать ф-ию сервера, если нужно
Вот какие изменения внесены мной в SConnect - возможно тут больше 20 строк, но не намного
unit SConnect;
...
const
{ Action Signatures }
...
asSetCallbackInterface=$13;
...
TSocketConnection = class(TStreamedConnection)
...
public
CallbackInterface:IDispatch;
...
procedure TSocketConnection.DoConnect;
begin
...
inherited DoConnect;
SendCallbackInterface;
...
end
procedure TSocketConnection.SendCallbackInterface;
var
Data: IDataBlock;
begin
Data := TDataBlock.Create as IDataBlock;
FInterpreter.WriteVariant(CallbackInterface, Data);
Data.Signature := CallSig or asSetCallbackInterface;
Data := FInterpreter.FSendDataBlock.Send(Data, False);
end;
TDataBlockInterpreter = class
...
public
FCallbackObject:IClientCallbackDisp;
FAppServerModule:IAppServerModule;
...
procedure TDataBlockInterpreter.DoCreateObject(const Data: IDataBlock);
var
V: OleVariant;
VarFlags: TVarFlags;
I: Integer;
begin
V := CreateObject(ReadVariant(VarFlags, Data));
FAppServerModule:=IUnknown(V) as IAppServerModule;
...
end
procedure TDataBlockInterpreter.InterpretData(const Data: IDataBlock);
begin
...
asSetCallbackInterface: DoSetCallbackInterface(Data);
...
end
procedure TDataBlockInterpreter.DoSetCallbackInterface(
const Data: IDataBlock);
var
TmpFlags: TVarFlags;
begin
FCallbackObject:=IClientCallbackDisp(IDispatch(ReadVariant(TmpFlags,Data)));
FAppServerModule.SetClientCallback(FCallbackObject);
end;
Digitman (2002-07-24 10:01:00) [14]>Polevi
Кто тебе это сказал ? Мало ли где и что требуется или не требуется ! Это уже - бизнес-логика, а не транспортный уровень и не маршаллинг. Где это регламентировано ? Что мешает серверу попытаться выполнить обратный вызов интерфейсного метода-функции, если таковой предоставлен клиентом ?
Polevi (2002-07-24 09:22:00) [15]2Digitman ©
Для callback вызова ответ не требуется
Digitman (2002-07-24 08:29:00) [16]>Polevi
Ну, про 20 строчек ты загнул, конечно)...
Вся беда в том, что ни BSS ни TSocketConnection не позволяют реализовать асинхронный и независимый маршаллинг прямых и обратных вызовов. Только последовательно - запрос и следом ожидаемый ответ. Если, к примеру, маршаллер клиента транслировал серверу некий его интерфейсный вызов (см. CallSig) и ожидает возвращения результата (см. ResultSig), и в это же время маршаллер сервера выполнит асинхронный обратный вызов (т.е. тоже - CallSig), то коллизии в тек.реализации связки TSocketConnection + BSS обеспечены 100%-но.
Polevi (2002-07-23 23:34:00) [17]PS
Под AppServer я подразумеваю BSS
Polevi (2002-07-23 23:31:00) [18]менять надо только SConnect.pas
у меня реализовано так:
в SocketConnection добавлено свойство CLientCallback - сразу после коннекта SC передает его App Server"у
Серверный модуль реализует некий интерфейс IAppServerModule, с помощью которого APp Server передает ему полученный от клиента CLientCallback
примерно 20 строк в SConnect все удовольствие
sergey32 (2002-07-23 18:37:00) [19]А много надо дорабатывать и в каких именно компонентах?
Digitman (2002-07-23 18:33:00) [20]можно свои.
можно доработать существующие.
Могу сказать, что я выбрал 2-й вариант, когда такая необходимость возникла. Хотя это и не первопричина доработки была .. Осн.задача ставилась такова - исключить необходимость регистрации класса фабрики AppServer"а в реестре