Здравствуйте, Agent Smith, Вы писали:
AS>>>Сколько может быть клиентов у одного сервера, если использовать Remoting?
TK>>Для ремотинг не требуется поддержания постоянного соединения с клиентом — так что клиентов может быть практически не ограниченное число (конечно, нужно учитывать какую нагрузку они генерируют) AS>А если решаемая задача требует постоянного подключения (скажем, обновление информации через каждые 30-60 секунд)?
Значит соединение будет держаться практически постоянно. С другой стороны — можно сделать канал на основе UDP и рассылать сообщения (можно даже широко вещательные) подписчикам. В данном случае — постоянного соединения не потребуется (правда возможны потери данных и про это никто не узнает)
AS>Не понял, в каком смысле инициировать посылку данных? Т.е. сервер не должен запрашивать данные у клиента? В принципе, ето не так важно. Важно другое: сервер должен быть в состоянии отсылать данные клиенту, причем запросы могут быть разного характера, опять же в реальном времени.
Если в реальном времени — то тут наверное лучше использовать Remoting — соединение будет установлено практически постоянно и нет избыточночти вносимой HTTP протоколом.
AS>А GZIP это открытый стандарт и стандарт ли вообще? Или коммерческая технология, которую по правилам нужно лицензировать?
Классы для сжатия информации с использованием GZIP есть в поставке J# Redist
AS>Так и не понял, какую технологию лучше всего использовать в моем примере. Пока склоняюсь к Remoting, т.к. нейтральность к платформе не опрелеляющий фактор. Очень важно поддержка по крайней мере одной платформы: Windows, но во всех ее модификациях (современных) (в принципе, .Net он и в CE — .Net, т.е. тут проблем быть не должно).
В CompactFramework нет поддержки Remoting — только Web сервисы
AS>Но всеже желательно иметь возможность построить такой интерфейс, чтобы с сервером могли работать клиенты из под Linux, MacOS, но опять же это не определяющий фактор.
В Rotor есть поддержка Remoting. Наверное mono когда-нибудь будет нормально работать...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Agent Smith, Вы писали:
AS>Скажите, чем отличаются Web-сервисы от Remoting? Обе технологии используют SOAP. Рихтер говорит, что центральное место в стратегии .Net занимают Web-сервисы, а к чему тогда относится технология Remoting? Или Remoting это и есть технология, на которую опираются/могут опираться Web-сервисы?
Упрощенно говоря WebService это такой вебсервер: получил запрос (через HTTP, XML, SOAP) — ответил (может и не отвечать, а сделать чегото, но на мой взгляд основная ценность именно если ответил), ответил причем также через HTTP, XML, SOAP.
То на что основной маркетинговый упор — WebService и клиент могут быть написаны абсолютно независимо — языки, технологии, главное следовать нескольким стандартам — UDDI (возможность катологизирования в коммон вебсервис директориях) и WSDL (умение предостовлять свой интерфейс в коммон формате).
UDDI — причем не обязателен...
Remoting — это внутреннее дело датнета
Типа продвинутого COM/DCOM'а
Можно создать обеъкт внутри сервера, можно на клиенте, SOAP здесь только если наш remote объект возвращает нам другой объект — не remoting.
После создания такого объекта можем вызывать его методы, чего он там будет делать — дело десятое.
Из плюсов — возможность использовать TCP и байнари форматер, вроде как быстрее (не всегда), но меннее защещенее, поэтому МС советует TCP/binary только внутри, за файрволом
Hello, "Agent Smith" > Скажите, чем отличаются Web-сервисы от Remoting? Обе технологии используют SOAP.
Remoting может использовать SOAP. Но это не единственный механизм.
> Рихтер говорит, что центральное место в стратегии .Net занимают Web-сервисы, а к чему тогда относится технология Remoting?
Веб сервисы это открытая технология реализации которой есть практически для любой платформы. Если считать, что стратегия .NET завоевать рынок, то открытые веб сервисы подходят для этого лучше некуда (простота разработки, совместимость с любыми клиентами и т.п.)
> Или Remoting это и есть технология, на которую опираются/могут опираться Web-сервисы?
Отдельная технология. Основана на закрытых форматах в большинстве случаев — совместима только сама с собой.
Но, при этом гибкие возможности по использованию и настройке
Posted via RSDN NNTP Server 1.7 "Bedlam"
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Agent Smith, Вы писали:
TK>>Значит соединение будет держаться практически постоянно. С другой стороны — можно сделать канал на основе UDP и рассылать сообщения (можно даже широко вещательные) подписчикам. В данном случае — постоянного соединения не потребуется (правда возможны потери данных и про это никто не узнает)
AS>А что такое UDP? Это технология в составе Remoting?
Нет, это просто протокол. В отличии от TCP он не ориентирован на установление постоянного соединения с клиентом. (как следствие он не гарантирует доставку сообщений)
AS>А у Web-сервисов ведь можно установить постоянное соединение. Все равно Web-интерфейса мне не надо, требуется нормальное Windows-приложение.
Web сервисы обыно работают по след. схеме — соединение, запрос, получание ответа, закрытие соединения (для HTTP 1.1 соединение с сервером можно не закрывать, а использовать повторно)
TK>>В CompactFramework нет поддержки Remoting — только Web сервисы AS>А ничего не известно, будет ли? И вообще, есть ли способ это обойти? В RSDN в статье по SOAP было сказанно, что SOAP-приложения или их части могут использовать как SOAP Toolkit 3.0, так и Remoting (было сказанно, что взаимодействие с компонентами .Net — тема отдельной статьи)
Скорее всего, что будет. В любом случае — сейчас можно использовать remoting + http протокол + soap формат как веб сервис.
TK>>В Rotor есть поддержка Remoting. Наверное mono когда-нибудь будет нормально работать...
AS>Кое-что слышал про Rotor, но так и не понял, что это такое. Mono — это тот проект .Net под Линукс? Он меня пока не интересует, вот если бы выпустили офф. версию .Net под MacOS... А никто не знает, Фотошоп под Макинтош переписывали с Маковскими библиотеками графического интерфейса, или как?
Rotor — это реализация основных библиотек .NET с открытым исходным кодом (работает на FreeBSD, MacOS X, Windows). можно скачать с сайта Microsoft
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Скажите, чем отличаются Web-сервисы от Remoting? Обе технологии используют SOAP. Рихтер говорит, что центральное место в стратегии .Net занимают Web-сервисы, а к чему тогда относится технология Remoting? Или Remoting это и есть технология, на которую опираются/могут опираться Web-сервисы?
21.10.03 02:09: Перенесено из 'XML/SOAP'
Never argue with a woman who reads. It's likely she can also think. (c)
По сути это, наверное, Web-сервис. Но только по сути. А что бы Вы использовали как технологию разработки? Пусть, например, передается текстовая информация + какие-то файлы, например, изображения.
Сколько может быть клиентов у одного сервера, если использовать Remoting? Требуется возможность передавать данные в обе стороны в реальном времени. Для текстовых данных особенно важна скорость передачи.
Спасибо
Never argue with a woman who reads. It's likely she can also think. (c)
Здравствуйте, Agent Smith, Вы писали:
AS>Тогда скажите, какая технология предпочтительнее, скажем, при разработке приложения архитектуры:
AS>По сути это, наверное, Web-сервис. Но только по сути. А что бы Вы использовали как технологию разработки? Пусть, например, передается текстовая информация + какие-то файлы, например, изображения.
Изначально веб сервисы использовались для передачи данных в текстовом формате (двоичные данные переводятся в base64). Но, для того-же .NET есть Web Services Enhancements в котором есть поддержка DIME для передачи данных в двоичном виде.
AS>Сколько может быть клиентов у одного сервера, если использовать Remoting?
Для ремотинг не требуется поддержания постоянного соединения с клиентом — так что клиентов может быть практически не ограниченное число (конечно, нужно учитывать какую нагрузку они генерируют)
AS>Требуется возможность передавать данные в обе стороны в реальном времени.
Web сервисы преполагают работу по принципу запрос-ответ. Если от сервера не требуется инициировать посылку данных, то использование web сервисов хороший выбор...
AS>Для текстовых данных особенно важна скорость передачи.
Для веб сервисов можно использовать стандартные возможности HTTP 1.1 протокола — например сжатие передаваемого контента с использованием GZip
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
AS>>Сколько может быть клиентов у одного сервера, если использовать Remoting?
TK>Для ремотинг не требуется поддержания постоянного соединения с клиентом — так что клиентов может быть практически не ограниченное число (конечно, нужно учитывать какую нагрузку они генерируют)
А если решаемая задача требует постоянного подключения (скажем, обновление информации через каждые 30-60 секунд)?
AS>>Требуется возможность передавать данные в обе стороны в реальном времени.
TK>Web сервисы преполагают работу по принципу запрос-ответ. Если от сервера не требуется инициировать посылку данных, то использование web сервисов хороший выбор...
Не понял, в каком смысле инициировать посылку данных? Т.е. сервер не должен запрашивать данные у клиента? В принципе, ето не так важно. Важно другое: сервер должен быть в состоянии отсылать данные клиенту, причем запросы могут быть разного характера, опять же в реальном времени.
TK>Для веб сервисов можно использовать стандартные возможности HTTP 1.1 протокола — например сжатие передаваемого контента с использованием GZip
А GZIP это открытый стандарт и стандарт ли вообще? Или коммерческая технология, которую по правилам нужно лицензировать?
Так и не понял, какую технологию лучше всего использовать в моем примере. Пока склоняюсь к Remoting, т.к. нейтральность к платформе не опрелеляющий фактор. Очень важно поддержка по крайней мере одной платформы: Windows, но во всех ее модификациях (современных) (в принципе, .Net он и в CE — .Net, т.е. тут проблем быть не должно). Но всеже желательно иметь возможность построить такой интерфейс, чтобы с сервером могли работать клиенты из под Linux, MacOS, но опять же это не определяющий фактор.
Never argue with a woman who reads. It's likely she can also think. (c)
Да, еще забыл спросить, как можно тестировать распределенные приложения на локальной машине? Конечно, можно воспользоваться бесплатным .Net-хостингом, но не хотелось бы...
Never argue with a woman who reads. It's likely she can also think. (c)
Здравствуйте, Agent Smith, Вы писали:
AS>Да, еще забыл спросить, как можно тестировать распределенные приложения на локальной машине? Конечно, можно воспользоваться бесплатным .Net-хостингом, но не хотелось бы...
Тестирование в проуессе разработки — можно делать и на одной машине — принципиальных отличий от работы по сети нет. Если-же хочется по полной — можно поставить VMware (или что-нибудь подобное), создать виртуальную сеть — и тестировать все там.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Agent Smith, Вы писали:
AS>>А может быть кто ответит на мой вопрос от 14.10.03 17:25? Просто интересно очеень... и надо...
TK>Надо давать не дату вопроса, а URL
OK здесь
Здравствуйте, TK, Вы писали:
TK>Значит соединение будет держаться практически постоянно. С другой стороны — можно сделать канал на основе UDP и рассылать сообщения (можно даже широко вещательные) подписчикам. В данном случае — постоянного соединения не потребуется (правда возможны потери данных и про это никто не узнает)
А что такое UDP? Это технология в составе Remoting?
TK>Если в реальном времени — то тут наверное лучше использовать Remoting — соединение будет установлено практически постоянно и нет избыточночти вносимой HTTP протоколом.
А у Web-сервисов ведь можно установить постоянное соединение. Все равно Web-интерфейса мне не надо, требуется нормальное Windows-приложение.
TK>В CompactFramework нет поддержки Remoting — только Web сервисы
А ничего не известно, будет ли? И вообще, есть ли способ это обойти? В RSDN в статье по SOAP было сказанно, что SOAP-приложения или их части могут использовать как SOAP Toolkit 3.0, так и Remoting (было сказанно, что взаимодействие с компонентами .Net — тема отдельной статьи)
AS>>Но всеже желательно иметь возможность построить такой интерфейс, чтобы с сервером могли работать клиенты из под Linux, MacOS, но опять же это не определяющий фактор.
TK>В Rotor есть поддержка Remoting. Наверное mono когда-нибудь будет нормально работать...
Кое-что слышал про Rotor, но так и не понял, что это такое. Mono — это тот проект .Net под Линукс? Он меня пока не интересует, вот если бы выпустили офф. версию .Net под MacOS... А никто не знает, Фотошоп под Макинтош переписывали с Маковскими библиотеками графического интерфейса, или как?
Never argue with a woman who reads. It's likely she can also think. (c)
Здравствуйте, TK, Вы писали:
TK>>>В CompactFramework нет поддержки Remoting — только Web сервисы AS>>А ничего не известно, будет ли? И вообще, есть ли способ это обойти? В RSDN в статье по SOAP было сказанно, что SOAP-приложения или их части могут использовать как SOAP Toolkit 3.0, так и Remoting (было сказанно, что взаимодействие с компонентами .Net — тема отдельной статьи)
TK>Скорее всего, что будет. В любом случае — сейчас можно использовать remoting + http протокол + soap формат как веб сервис.
А можно по-подробнее? Скажем, основа системы Remoting, а КПК-клиент работает на основе Web-сервиса — это реально?
AS>>Кое-что слышал про Rotor, но так и не понял, что это такое. Mono — это тот проект .Net под Линукс? Он меня пока не интересует, вот если бы выпустили офф. версию .Net под MacOS... А никто не знает, Фотошоп под Макинтош переписывали с Маковскими библиотеками графического интерфейса, или как?
TK>Rotor — это реализация основных библиотек .NET с открытым исходным кодом (работает на FreeBSD, MacOS X, Windows). можно скачать с сайта Microsoft
Т.е. Rotor это оффициальный порт .net от Microsoft? А как на счет WindowsForms? Они, например, не самым лучшим образом сочитаются с пользовательским интерфейсом MacOS X...
Never argue with a woman who reads. It's likely she can also think. (c)
Здравствуйте, Agent Smith, Вы писали:
TK>>Скорее всего, что будет. В любом случае — сейчас можно использовать remoting + http протокол + soap формат как веб сервис.
AS>А можно по-подробнее? Скажем, основа системы Remoting, а КПК-клиент работает на основе Web-сервиса — это реально?
Реально. Через remoting публикуется объект, после этого в проекте выбирается пункт добавить web reference в диалоге указывается путь к опубликованному объекту + ?SDL и создается оболочка для работы с ним.
TK>>Rotor — это реализация основных библиотек .NET с открытым исходным кодом (работает на FreeBSD, MacOS X, Windows). можно скачать с сайта Microsoft
AS>Т.е. Rotor это оффициальный порт .net от Microsoft? А как на счет WindowsForms? Они, например, не самым лучшим образом сочитаются с пользовательским интерфейсом MacOS X...
Windows.Forms там нет. ADO.NET там нет. Есть лицензия по которой rotor нельзя использовать в коммерческих проектах.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Agent Smith, Вы писали:
AS>Интересно, а взялся бы кто-нибудь за статью в RSDN о распределенных приложениях, части которых построены на разных технологиях?
Можно написать примерный сценарий — и сделать голосование.
Если выскажется много народу, то вполне возможно, что кото-нибудь ее напишет...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Agent Smith, Вы писали:
AS>>Интересно, а взялся бы кто-нибудь за статью в RSDN о распределенных приложениях, части которых построены на разных технологиях?
TK>Можно написать примерный сценарий — и сделать голосование. TK>Если выскажется много народу, то вполне возможно, что кото-нибудь ее напишет...
Т.к. я с темой знаком весьма посредственно, то за сценарий не возьмусь...
Never argue with a woman who reads. It's likely she can also think. (c)
Здравствуйте, Agent Smith, Вы писали:
AS>А какая разница по сложности и технологическим отличиям между использованием для Web-сервисов Web-форм и WindowsForms?
Несовсем понятно о это чем ты
Если про web-service's clients то — SOAP client это всего навсего набор классов, какой интерфейс по барабану,
есле про web-service itself — то в слове web-service ключевое слово — WEB
А какая технология лучше в плане расширяемости (т.е. чтобы она позволяла писать мне какие-то надстройки, например новые способы сжатия данных, короче говоря не стесняла свободу творчества)?
Never argue with a woman who reads. It's likely she can also think. (c)
Здравствуйте, Agent Smith, Вы писали:
AS>А какая технология лучше в плане расширяемости (т.е. чтобы она позволяла писать мне какие-то надстройки, например новые способы сжатия данных, короче говоря не стесняла свободу творчества)?
Проще (без всяких там заморочек с особенностью данных) ремотинг. Но сама по себе технология намного сложнее, чем веб сервисы.
Здравствуйте, Agent Smith, Вы писали:
AS>А какая разница по сложности и технологическим отличиям между использованием для Web-сервисов Web-форм и WindowsForms?
Здравствуйте, Agent Smith, Вы писали:
AS>А какая технология лучше в плане расширяемости (т.е. чтобы она позволяла писать мне какие-то надстройки, например новые способы сжатия данных, короче говоря не стесняла свободу творчества)?
Remoting — копай в стророну Sinks
Вообще про ремотинг найди книжку Инго Раммера, оченно полезная вещь
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Agent Smith, Вы писали:
AS>>Интересно, а взялся бы кто-нибудь за статью в RSDN о распределенных приложениях, части которых построены на разных технологиях?
TK>Можно написать примерный сценарий — и сделать голосование. TK>Если выскажется много народу, то вполне возможно, что кото-нибудь ее напишет...
Да что там писать то? Прочитал в MSDN примерно как строиться Главное, это технологии, а каждая их них — это как минимум статья. Хотелось бы посмотреть, кто будет писать по этому статью. Этож целая книга
Здравствуйте, Agent Smith, Вы писали:
AS>Здравствуйте, illegal planet, Вы писали:
IP>>Вообще про ремотинг найди книжку Инго Раммера, оченно полезная вещь
AS>А на русском она есть? Хотя бы в электронном виде? А то видел только от Русской Редакции
up
Never argue with a woman who reads. It's likely she can also think. (c)
Главное, это технологии, а каждая их них — это как минимум статья. Хотелось бы посмотреть, кто будет писать по этому статью. Этож целая книга 
