Hi michael_nur!

> А вот как ведет себя MSSoapClient, мне не очень нравится.

)

> Кстати, если использовать _ws3client.vcx, как в Webservice
> Wizard,получается примерно так же, криво.

Всё получается так как и нужно - обрати внимание на строки КОММЕНТАРИЯ
которые и вставляет мастер (когда перетаскиваешь с Toolbox в окно кода свой
зарегистрированный WS), и которые есть на закладке WebServices в TaskPane:

* Do not remove or alter following line. It is used to support IntelliSense
for your XML Web service.
*__VFPWSDef__: loVFPWebService = http://IGORHOME/VFPWebService/VFPWebService.wsdl
, VFPWebService , VFPWebServiceSoapPort

возьми словарик и переведи.

> 2. Работает,при создании объекта из DLL-ки, мои методы видны через
> IntelliSens, а из Webservice-нет, только родные проперти MSSoapClient,
> может так и надо?

Да, так и надо - поскольку у объекта MSSoapClient НЕТУ методов твоего WS -
он банальный прокси. А поддержку IntelliSense включает при указанных выше
условиях

> 3. Для того чтобы во всем разобраться мне надо лишь понять как происходит
> доступ к методам объекта через Web-сервис, пока ясно, что в основе лежит
> WinSocket.

Где-то в "глубинах" да, но это настолько неважно, что лучше забудь. Доступ
организует SOAP по технологии прокси-объекта. Т.е. у тебя "как-бы" удалённый
объект имеется. Хотя реально он просто все обращения к себе пересылает на
сервер, где они и обрабатываются.
P.S. MSFT собирается прикрыть SOAP, переведя всё на .NET Remoting - как я
понимаю в Sedna уже будет создан механизм работы с WS через NET Remoting а
не через SOAP. Так что пользовать "напрямую" MSSoapClient я бы не
советовал - есть шанс, что MS портирует враппер типа _ws3client.vcx - т.е.
достаточно будет просто заменить базовый класс... В случае же "прямого"
использования скорее всего придётся переписывать кучу кода.
P.S. SOAP уже сегодня как-то очень нехорошо себя ведёт на W2003 серверах :(

Posted via ActualForum NNTP Server 1.3

Hi dmitryx!

> Для большого отчета у меня вибирается около 5000 записей

Я бы не сказал что это "большой" отчёт - разве что полей там за 200 и все
сплошь memo с вложенными в них "документами" :)

> и, мягко говоря, скорость даже в локальной сети не внушает - 8 секунд до
> получения xml строки

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

> и 34 секунды после конвертирования ее xml adapter'ом в курсор

А вот этого я не понял абсолютно - что жу это такое ты с этим курсором
делаешь на клиенте то? Ведь по всем прикидкам самое трудоёмкое и
длительное - это и должно уносится на сервер... Или тебе надо тек мощно
"тасовать" выбраные данные, что ты решил не грузить этим сервер а всё
поручить клиенту? Или ты где-то неточно выразился в моментах проведения
замеров.

> а что же будет у клиентов, которые подключены на 128кбит/с - боюсь
> представить.

Вот что что, а скорость подключения тут не первую роль играет и 128К должно
хватать с запасом - можешь посчитать какого размера XML передаётся и
учитывая скорость соединения рассчитать сколько времени будет затрачено
именно на передачу (не на выборку, не на серверные операции, конвертацию в
XML и обратно и прочее) - думаю что при разумных объёмах выборки это не
превысит 10% от общих затрат времени (впрочем если тебе вдруг нужно печатать
безумные отчёты по 10000 страниц то и тут можно ускорить процесс - получать
данные порциями - так чтобы время передачи "размазалось" с учётом времени на
распечатку).

> Не могли бы вы по-подробнее описать технологию по работе с большими
> запросами, и даст ли это ощутимое ускорение?

Ощутимое ускорение дадут "агрегирующие" запросы - т.е. когда надо
"пробежать" по сравнительно большому объёму данных, а в результате получить
сравнительно маленький объём - т.е. всякие сводные/итоговые отчёты это
первый кандидат на перенос на сервер. Если же реально берётся 10 записей а
потом они пару минут "тасуются" - обрабатываются масивными и медленными
алгоритмами - то боюсь что в общем случае ты получишь лишь замедление - тут
возможно стоит на серверной стороне только выборку делать, а уж сами эти
расчёты перенести на клиент - но конечно тут влияет общее число клиентов и
сравнительная производительность сервера и клиента - т.е. если одновременно
клиентов 1000 и более то даже на "дохлых" старых процессорах самих клиентов
выгоднее делать расчёты нежели на сверхсовременном сервере - даже
многопроцессорном.

Posted via ActualForum NNTP Server 1.3