Сейчас пошла мода front-end корпоративных приложений делать в ввиде сайтов. Такой подход имеет свои плюсы, но речь идёт о минусах. А именно - довольно слабое взаимодействие приложения с локальной средой компьютера клиента. Я понимаю, что при использовании интернета таких проблем нет, да и они вообще не могут поставлены, ибо существенно нарушают защиту локального компьютера. 

А в корпоративных front-end требуются гораздо более продвинутая функциональность приложения в отношении клиента, мне понадобилась следующая функциональность, которую непонятно как реализовать:

1. Взаимодействие с процессами на клиенте (посылка сообщений процессу, открытие или закрытие процесса, передача информации процессу)

2. Доступ к файловой системе на клиенте

Насколько я понимаю возможно множество вариантов решения - от plug-in к браузеру до ActiveX или каких-то локальных сервисов... Хотелось бы узнать общие тенденции и правила разработки, кто чем пользуется, плюсы и минусы реального, практического использования.

Я бы скорее предположил, что сейчас в этой области пошла мода на (XML) веб-сервисы, а не сайты. Которые могут обеспечить возможность доступа как через браузер, так и с помощью собственного клиента.

Что касается взаимодействия с локальной системой, я бы предпочел собственный клиент, дабы не зависить от браузера. Мало ли, какие ограничения по безопасности там всплывут в следующих версиях...

Хотя, я в разработке корпоративных  приложений такого типа не участвовал, и запросто могу ошибаться.

Это сообщение отредактировал(а) catlion - 1.5.2007, 18:28

После
 я бы тоже отказался от броузера в сторону "собственного клиента" и WEB-Service, как сказал catlion, но появляется задача, которая была решаема "с броузером" - кроссплатформенность... да и это решаемо (ява например) ....

Vit, кажется кроссплатформенность тебе ненужна, т.к. ...

Корпоративный бизнес, он особенный.... Если б речь шла о своём клиенте - тогда понятно, на фига было бы вообще с web заморачиваться? Есть куча Multi-tier технологий - DCOM, CORBA, MIDAS и их реализация на всех обычных языках програмирования. Поэтому задачу начальство ставит просто - "клиент это браузер". Кросплатформенность в 99% не нужна, как правило в корпорациях на всех компьютерах (кроме естественно серверов и компов разработчиков) стоит одна и та же версия одной операционной системы, одна и та же версия одного и того же браузера и сотрудники пользоваться чем-то другим или не имеют права, или в конкретно данном случае обязаны пользоваться именно тем что оговорено.

Я предложил бы два слоя - Web-приложение как интерактивная оболочка + плагины к приложению на сервере (допустим в виде dll), которые получают от Web-приложения данные о юзере и уже сами запускают процессы управления на клиенте. Навскидку - через WMI.

Я тут прочитал ваше рассуждение, если что-то не понял -- простите, бо только вот из отпуска приехал, еще мало соображаю.

Получается так, что нужно получить из браузера доступ к компьютеру с которого просматривается сайт, да ??? Если без наворотов и без кроссбраузерности, тогда ActiveX.
А если нет. Тогда связку из сайта (типа оболочка (asp.net Все равно делает кроссбраузерность)), дальше Web-сервис, на который поступают команды типа "убить процесс" или что-то в этом роде. Но при этом на Web-сервис приходят сообщения типа IP пользователя (Request.ServerVariables["REMOTE_ADDR"] (т.к. мыне используем в корпоративных сетях прокси, то получим реальный ip)) И после этого мы уже коннектимся и передаем по сокету данные на тот компьютер откуда пришел пакет на Web-Сервис. А на клиента обязана стоять windows-сервис, который будет слушать порт к которому будет коннектится Web-Сервис.
Вот такую вот сложную связку я представляю себе. Если я в чем-то ошибся, то звиняйте.


Vit, кстати, а я такие приложения знал под названием poor-приложения. (типа вся действенная часть находится где-то там, а ты только отдаешь команды)