Здравствуйте.

Появилась необходимость спроектировать и реализовать одно приложение.
Состоять оно должно из трех частей, а именно:
1) База данных
2) Сервер
3) Клиент


Клиентская часть должна быть реализована в двух видах:
1) Desktop-приложение
2) Веб-интерфейс

Собственно сам вопрос. Каким образом (с помощью чего) организовать взаимодействие (формат сообщений) между сервером и клиентскими приложениями? В случае настольного приложения, вопросы не возникают, можно использовать сокеты для соединения, и например сериализованное представления объекта, как сообщения. А что делать с веб-интерфейсом?
Пожалуйста посоветуйте куда смотреть и что читать.

Прошу прощения за сумбурное изложение.

Заранее благодарен.

Здравствуйте, Hellhang, Вы писали:

H>Клиентская часть должна быть реализована в двух видах:
H>1) Desktop-приложение
H>2) Веб-интерфейс
H>Собственно сам вопрос. Каким образом (с помощью чего) организовать взаимодействие (формат сообщений) между сервером и клиентскими приложениями? В случае настольного приложения, вопросы не возникают, можно использовать сокеты для соединения, и например сериализованное представления объекта, как сообщения. А что делать с веб-интерфейсом?

Имеется в виду не браузер -> веб-сервер, а веб-сервер -> сервер?
Не думаю, что реализация на сырых сокетах оправданна. Можно взять веб-сервисы, например.

Здравствуйте, Hellhang, Вы писали:

H>Собственно сам вопрос. Каким образом (с помощью чего) организовать взаимодействие (формат сообщений) между сервером и клиентскими приложениями? В случае настольного приложения, вопросы не возникают, можно использовать сокеты для соединения, и например сериализованное представления объекта, как сообщения. А что делать с веб-интерфейсом?

Типа изобрести свой RMI и потом долго иметь отношения любовного характера с прокси серверами?

Здравствуйте, Hellhang, Вы писали:

H>1) База данных
H>2) Сервер
H>3) Клиент
Обычная трехзвенка?


H>Клиентская часть должна быть реализована в двух видах:
H>1) Desktop-приложение
H>2) Веб-интерфейс
Т.е. два клиено с доступом к одному серверному API?


H>Пожалуйста посоветуйте куда смотреть и что читать.
Смотреть Spring. API приложения реализутся в виде сервисов. Сервисы публикуются (expose) в виде чего угодно. Хотите SOAP, хотите RMI, хотите HttpInvoker. Выбор транспорта вообще довольно малая часть от проеквтирования приложения.
Затем определитесь с типом web морды. Если это JavaScript ориентированый Rich итерфейс (ExtJS, GWT и производные), те же сервисы с тем же спрингом. Протокол — JSON или SOAP. Возможно RESTful, но это не всегда выход.
Если web морда какой-то шаблонный, движок с рендерингом HTML на сервере, то это просто реализуется через MVC, где контроллер обращается к все тем же сервисам.

Здравствуйте, Blazkowicz, Вы писали:

B>Обычная трехзвенка?
Да

B>Т.е. два клиено с доступом к одному серверному API?
Да

Мне посоветовали посмотреть в сторону серверов приложений. Не знаю даже с чего начать. За Spring спасибо, буду смотреть.

А что можете сказать за Glassfish? А то что-то мне Spring показался слишком уж монструозным.

Здравствуйте, Hellhang, Вы писали:

H>А что можете сказать за Glassfish? А то что-то мне Spring показался слишком уж монструозным.
Вы не рано ли взялись за проективрование системы в рамках технологии, которой вообще не понимаете?

Здравствуйте, Hellhang, Вы писали:

H>А что можете сказать за Glassfish? А то что-то мне Spring показался слишком уж монструозным.

А мне наоборот кажется EJB (Glassfish) монструознее и совсем закрыто. Поменять поведение практически невозможно. Спринг же можно кастомизировать практически как хочешь. Я в текущем проекте несколько раз натыкался на случаи, когда в EJB это не сделаешь никак а в Spring это делается штатно и просто.