Задача:
Сделать серверное приложение, которое время от времени по каналу TCP/IP обменивается некой информацией с клиентами по инициативе самих клиентов. Кроме того программа должна иметь возможность выполнять дополнительные действия связанные с ее деятельностью, т.е. здесь должен быть GUI. Там же возможность работы с базой данных (добавить там, удалить, изменить).
Подскажите пожалуйста как мне организовать это приложение? Т.е. может здесь нужно сделать службу? Или приложение, которое будет висеть в трейе?
Т.к. вопрос объемный лучше будет наверно, если вы посоветуете мне какую-нибудь книгу или ссылку.
А обязательно TCP/IP? Может лучше вообще сделать Web-приложение? Пусть юзеры что надо аплоадят эксплорером, веб-интерфейс прикрутить просто, и с БД работать тоже несложно.
Здравствуйте, Amor, Вы писали:
A>Кроме того программа должна иметь возможность выполнять дополнительные действия связанные с ее деятельностью, т.е. здесь должен быть GUI.
Зачем? Локально клиент тоже можт быть запущен. Вопрос только, какие клиенты будут.
A>Т.е. может здесь нужно сделать службу?
Лучше так, к тому же получишь фактически нахаляву возможность частичного удаленного управления.
A>Или приложение, которое будет висеть в трейе?
А вот это не надо. Вообще без GUI лучше обойтись.
Здравствуйте, vasketsov, Вы писали:
V>Здравствуйте, Amor, Вы писали:
A>>Кроме того программа должна иметь возможность выполнять дополнительные действия связанные с ее деятельностью, т.е. здесь должен быть GUI. V>Зачем? Локально клиент тоже можт быть запущен. Вопрос только, какие клиенты будут.
Здесь ресь не о клиенте идет. GUI для сервера.
A>>Т.е. может здесь нужно сделать службу? V>Лучше так, к тому же получишь фактически нахаляву возможность частичного удаленного управления.
A>>Или приложение, которое будет висеть в трейе? V>А вот это не надо. Вообще без GUI лучше обойтись.
GUI нужно, для выполнения пользователем других действий (там же — работа с БД)
Т.е. программа постоянно работает с клиентами, а когда пользователю моего приложения понадобиться сделать эти действия — он "запускает" GUI.
Здравствуйте, Gollum, Вы писали:
G>Здравствуйте, Amor, Вы писали:
G>А обязательно TCP/IP? Может лучше вообще сделать Web-приложение? Пусть юзеры что надо аплоадят эксплорером, веб-интерфейс прикрутить просто, и с БД работать тоже несложно.
Ну здесь не пользователи (люди) пользуются услугами сервера. А клиентские программы сами, без участия человека.
Здравствуйте, Amor, Вы писали:
A>Здесь ресь не о клиенте идет. GUI для сервера.
не является нужным.
A>GUI нужно, для выполнения пользователем других действий (там же — работа с БД) A>Т.е. программа постоянно работает с клиентами, а когда пользователю моего приложения понадобиться сделать эти действия — он "запускает" GUI.
А почему он не может это действия сделать через клиента?
И вообще, что за действия на сервере требуют GUI? Ибо для подключения к базе GUI не надо.
A>Ну здесь не пользователи (люди) пользуются услугами сервера. А клиентские программы сами, без участия >человека.
вы слишком мало задали условий чтобы выдать какие-то рекомендации
Есть же множество проверенных промышленных решений для архитектуры клиент-сервер,
выбор которых зависит от множества факторов
(ОС, язык/среда разработки, необходимость стыковки с существующим ПО)
начните с детальной постановки задачи, возможно решение придет само собой
Здравствуйте, Amor, Вы писали:
A>Привет всем!!!
A>Задача: A>Сделать серверное приложение, которое время от времени по каналу TCP/IP обменивается некой информацией с клиентами по инициативе самих клиентов. Кроме того программа должна иметь возможность выполнять дополнительные действия связанные с ее деятельностью, т.е. здесь должен быть GUI. Там же возможность работы с базой данных (добавить там, удалить, изменить).
A>Подскажите пожалуйста как мне организовать это приложение? Т.е. может здесь нужно сделать службу? Или приложение, которое будет висеть в трейе?
A>Т.к. вопрос объемный лучше будет наверно, если вы посоветуете мне какую-нибудь книгу или ссылку.
A>Спасибо заранее.
На C# элементарно написать сервисное приложение. Как механизм обмена данными выбрать Remoting. С СОМ+ лучше не связываться и веб-сервисы мне тоже не нравятся, а вот ремоутинг можно будет даже в инет вытащить и использовать как веб сервисы. Т.е. ремоутинг сможет работать в интранете обмениваяюсь данными в бинарном виде и в инете обмениваясь ХМЛ-ом без написания каких-либо доп. оберток.
Здравствуйте, vasketsov, Вы писали:
V>Здравствуйте, Amor, Вы писали:
A>>Здесь ресь не о клиенте идет. GUI для сервера. V>не является нужным.
A>>GUI нужно, для выполнения пользователем других действий (там же — работа с БД) A>>Т.е. программа постоянно работает с клиентами, а когда пользователю моего приложения понадобиться сделать эти действия — он "запускает" GUI. V>А почему он не может это действия сделать через клиента? V>И вообще, что за действия на сервере требуют GUI? Ибо для подключения к базе GUI не надо.
Схему так можно описать: КЛИЕНТ-СЕРВЕР-ПОЛЬЗОВАТЕЛЬ. Клиент время от времени отправляет серверу информацию о своей деятельности. Сервер там ему что-то отвечает. Пользователь же должен выполнять некие действия. Можно конечно, это GUI вынести вообще в отдельное приложение. Не знаю грамотно ли так делать? Делают ли так?
K>На C# элементарно написать сервисное приложение. Как механизм обмена данными выбрать Remoting. С СОМ+ лучше не связываться и веб-сервисы мне тоже не нравятся, а вот ремоутинг можно будет даже в инет вытащить и использовать как веб сервисы. Т.е. ремоутинг сможет работать в интранете обмениваяюсь данными в бинарном виде и в инете обмениваясь ХМЛ-ом без написания каких-либо доп. оберток.
*** А что это за зверь такой Remoting? Может посоветуйте что и где почитать о взаимодействии различных серверов между собой, особенно что нового появилось в этой области.
Сейчас я разрабатываю сервера приложений (например игровые сервера) на С++ и сокетах, все взаимодействие в форме XML, что достаточно трудоемко. Интересно как это делают другие... Было бы интересно поделиться опытом.
Здравствуйте, Amor, Вы писали:
A>Схему так можно описать: КЛИЕНТ-СЕРВЕР-ПОЛЬЗОВАТЕЛЬ. Клиент время от времени отправляет серверу информацию о своей деятельности. Сервер там ему что-то отвечает. Пользователь же должен выполнять некие действия. Можно конечно, это GUI вынести вообще в отдельное приложение. Не знаю грамотно ли так делать? Делают ли так?
возьми любое серверное приложение — это сервисы безGUIвые. Все управление (GUI или командная строка) через отдельное приложение
примеры:
IIS, MS SQL сервер, Exchange
Oracle 8i/9i
рассмотри вариант выключения/включения питания (когда нет оператора)
Здравствуйте, SCS, Вы писали:
SCS>Здравствуйте, Amor, Вы писали:
A>>Схему так можно описать: КЛИЕНТ-СЕРВЕР-ПОЛЬЗОВАТЕЛЬ. Клиент время от времени отправляет серверу информацию о своей деятельности. Сервер там ему что-то отвечает. Пользователь же должен выполнять некие действия. Можно конечно, это GUI вынести вообще в отдельное приложение. Не знаю грамотно ли так делать? Делают ли так? SCS>возьми любое серверное приложение — это сервисы безGUIвые. Все управление (GUI или командная строка) через отдельное приложение
SCS>примеры: SCS>IIS, MS SQL сервер, Exchange SCS>Oracle 8i/9i
SCS>рассмотри вариант выключения/включения питания (когда нет оператора)
Т.е. можно сделать так: написать службу, которая запускается при запуске системы, взаимодействует с клентами, обращается к БД и проч. И есть отдельное приложение, которое выполняет вот те самые "загадочные" действия и управляет службой через ControlService() возможно даже удаленно.
Здравствуйте, Amor, Вы писали: A>Т.е. можно сделать так: написать службу, которая запускается при запуске системы, взаимодействует с клентами, обращается к БД и проч. И есть отдельное приложение, которое выполняет вот те самые "загадочные" действия и управляет службой через ControlService() возможно даже удаленно.
Не обязательно через ControlService(). Через это управляют только "тпру" да "поехали" — через Control Panel, MMC, FAR Plugin и еще туеву хучу всего. Просто твое приложение как-то коннектится к службе и общается с ней. Например, для MS SQL есть свои протоколы подключения для выполнения SQL команд. И все управление сервером при помощи них и происходит.
... << RSDN@Home 1.0 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Amor, Вы писали: A>>Т.е. можно сделать так: написать службу, которая запускается при запуске системы, взаимодействует с клентами, обращается к БД и проч. И есть отдельное приложение, которое выполняет вот те самые "загадочные" действия и управляет службой через ControlService() возможно даже удаленно. S>Не обязательно через ControlService(). Через это управляют только "тпру" да "поехали" — через Control Panel, MMC, FAR Plugin и еще туеву хучу всего. Просто твое приложение как-то коннектится к службе и общается с ней. Например, для MS SQL есть свои протоколы подключения для выполнения SQL команд. И все управление сервером при помощи них и происходит.
Чего-чего-то я не понял.....
Что значит тпру-да-поехали?
Как надо?
Управление службой + выполнение определенных действий = вот что мне надо сделать
Здравствуйте, Amor, Вы писали:
A>Чего-чего-то я не понял..... A> A>Что значит тпру-да-поехали?
Значит через ControlService службу можно остановить и запустить. Все. A>Как надо? A>Управление службой + выполнение определенных действий = вот что мне надо сделать
Вынудить службу на "выполнение определенных действий" придется по своему коммуникационному каналу. На выбор:
— Перезапись конфигурационного файла в условленном месте
— Named Pipes
— TCP/IP
— ... гуру дополнят.
... << RSDN@Home 1.0 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Amor, Вы писали:
A>>Чего-чего-то я не понял..... A>> A>>Что значит тпру-да-поехали? S>Значит через ControlService службу можно остановить и запустить. Все.
Но можно ведь передавать в ControlService() пользовательские коды. А не только SERVICE_CONTROL_XXX.
Здравствуйте, Amor, Вы писали:
A>Но можно ведь передавать в ControlService() пользовательские коды. А не только SERVICE_CONTROL_XXX.
числа 128-255. даже сточку не передать. очень ограничено.
делай по Remoting (если .Net), NamedPipe, TCP/IP, COM+
A>>Ну здесь не пользователи (люди) пользуются услугами сервера. А клиентские программы сами, без участия >человека.
A>вы слишком мало задали условий чтобы выдать какие-то рекомендации A>Есть же множество проверенных промышленных решений для архитектуры клиент-сервер, A>выбор которых зависит от множества факторов A>(ОС, язык/среда разработки, необходимость стыковки с существующим ПО) A>начните с детальной постановки задачи, возможно решение придет само собой
A>>(ОС, язык/среда разработки, необходимость стыковки с существующим ПО) A>>начните с детальной постановки задачи, возможно решение придет само собой
A>ОС — WindowsNT A>язык/среда — Visual C++ 6.0
как один из жизнеспособных вариантов — ISAPI, http, xml.
мы такое делали, сервер управлялся через сервисное приложение имеющее GUI и
запускающее/останавливающее IIS с помощью SCM API (описано в книге Рихтера и Кларка)
Можно субмитить данные программно, в виде XML.
действия и управляет службой через ControlService() возможно даже удаленно.
