Скажите, чем отличаются обычные веб-сервисы от удаленного вызова методов и работы с помощью проекта Hession (The Hessian binary web service protocol makes web services usable without requiring a large framewor)
Какой из способв лучше использоваться когда проект состоит из серверной и клиентсвой части. Где сервер на jboss, а клиент приложение на swing.

спасибо

Здравствуйте, Аноним, Вы писали:

А>Скажите, чем отличаются обычные веб-сервисы от удаленного вызова методов и работы с помощью проекта Hession (The Hessian binary web service protocol makes web services usable without requiring a large framewor)
А>Какой из способв лучше использоваться когда проект состоит из серверной и клиентсвой части. Где сервер на jboss, а клиент приложение на swing.

Под обычным веб сервисом почти всегда подразумевают SOAP поверх HTTP. Одно из важных преимуществ hessian это производительность. Если сервис активно нагружен, то XML сериализация будет отъедать очень солидную долю процессорного время. Хотя вроде как существуют некоторые экзотические сериализаторы с очень хорошей производительностью.
Но вообще, если клиент — Swing, то почему не RMI?

А>Скажите, чем отличаются обычные веб-сервисы от удаленного вызова методов и работы с помощью проекта Hession (The Hessian binary web service protocol makes web services usable without requiring a large framewor)
А>Какой из способв лучше использоваться когда проект состоит из серверной и клиентсвой части. Где сервер на jboss, а клиент приложение на swing.

Удалённый вызов методов, достоинства:
1. Быстрее чем вебсервисы
2. В/из методов можно передавать любые сериализуемые объекты
недостаток:
1. Нужны клиентские либы жибосса, примерно 15 мегов. Однако, если захочется заюзать ещё и JMS (а ведь захочется же), то клиентские либы всё равно понадобятся, так что...

Веб-сервисы, достоинства:
1. Работают через http-прокси, например. (Однако, EJB тоже можно дёргать по http, жибосс умеет такую фичу).
2. Не нужны клиентские либы жибосса.
недостаток:
1. В/из методов можно передавать не все объекты, а только те, что дружат с веб-сервисной хмл-сериализацией.

Я бы юзал удалённые вызовы EJB. (В своих программах мы так и делаем)

А>Удалённый вызов методов, достоинства:
А>1. Быстрее чем вебсервисы
А>2. В/из методов можно передавать любые сериализуемые объекты
А>недостаток:
А>1. Нужны клиентские либы жибосса, примерно 15 мегов. Однако, если захочется заюзать ещё и JMS (а ведь захочется же), то клиентские либы всё равно понадобятся, так что...

А>Веб-сервисы, достоинства:
А>1. Работают через http-прокси, например. (Однако, EJB тоже можно дёргать по http, жибосс умеет такую фичу).
А>2. Не нужны клиентские либы жибосса.
А>недостаток:
А>1. В/из методов можно передавать не все объекты, а только те, что дружат с веб-сервисной хмл-сериализацией.

А>Я бы юзал удалённые вызовы EJB. (В своих программах мы так и делаем)

Сменил EJB на Spring Remote/HTTP Invoke (это удаленный вызов (rmi) внутри http транспорта) и счаслив, стало намного быстрее и удобнее.
Вобщем рекомендую как достойную альтернативу ejb.