LINUX.ORG.RU
Форум — Development  

[Java][noob]Проблема проектирования взаимодествия с веб-сервисом

 ,


0

1

Пусть есть некая служба А. Служба А через веб-морду предоставляет пользователю данные, пользователь выбирает нужный ему набор и сообщает свои реквизиты. Служба А запрашивает у веб-сервиса Б (по SOAP), имеет ли пользователь с такими реквизитами право на получение такого набора данных. Веб-сервис,на основе своих алгоритмов дает ответ- да\нет.

Если я ничего не путаю, то схема обработки выглядит так:

1) Клиент отправляет POST запрос с указанием желаемого набора и своих реквизитов

2) Сервлет инициирует соединение с веб-сервисом

3) Формирует SOAP запрос и отправляет веб-сервису

4) Получает ответ от веб-сервиса

5) Закрывает соединение с веб-сервисом

6) Отправляет ответ пользователю

Поскольку производительность все таки немного важна (служба, скорее всего, будет испытывать нагрузки), хотелось бы убрать постоянное создание и закрытие соединения с веб-сервисом, чтобы сервлет отрабатывал быстрее.

Вопрос: Существует ли _нечто_, что могло бы существовать на протяжении работы службы(не сервлета) и держать открытым соединение с веб-сервисом, чтобы сервлеты могли, при работе, сразу отправлять через это _нечто_ запросы и получать ответы?

note: Вообще я думаю о создании отдельного диспетчера с очередью, но хотелось бы знать, может в J2EE есть механизмы, упрощающие подобную процедуру. Очень не хочется возводить велосипед.

note2:в J2EE я новичок, так что сильно не ругайтесь.

Предположение: Возможно, убрав процедуру открытия\закрытия соединения я особо ничего не выиграю, так ли это?

← ввод/вывод в модуле ядра
Глюк GCC? →
  1 2 →
Ответ на: комментарий от vertexua

Честно говоря со спрингом последний раз работал больше года назад. Помню, что как попробовал, сильно понравилось, что не нужно писать xml, а есть очень крутой (как у всех гугловых либ) eDSL. Ну и вообще у него API прикольный, посмотри таториал. Возможно 3-й спринг уже догнал жуйс как DI, но и жирком оброс.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Ну в Spring уже давно @Autowired и т.д.

У меня в Spring MVC проекте и такого много

@RequestMapping("/setmainphoto/{id}/{photoId}")
	public String manageBusPhotos(@PathVariable long id, @PathVariable long photoId){
		Bus bus = getBusesDao().getBus(id);
		bus.setMainPhoto(photoId);
		getBusesDao().merge(bus);
		return "redirect:../../managebusphotos/"+id;
	}

Все на аннотации перетащили

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Да, видел, вроде норм. Просто уже привык к guic-овым Provider<?> легкому конфигурированию MethodInterceptor-ов через bindInterceptor, @Named инъекциям. Помню реальную ситуацию, когда чуваки из параллельного проекта пытались сконфигурить spring, что бы с разными БД работал (с мастер базой или репликой) через AOP. У них там что-то долго глючило, а у меня все сразу заработало, хоть и ручками пописать пришлось.

Ну а вместо SpringMVC у меня Jersey. Выглядит примерно так же как и твой пример. Я вначале хотел хаюзать связку guice + springmvc, но потом мне jersey показали, и мне понравилось.

dizza ★★★★★
()
Ответ на: комментарий от umbr

> Персистентные соединения(HTTP 1.1) - не айс, большого прироста производительности не дадут, а вот SOAP-запрос, с несколькими переменными - это уже 500-1000 байт трафика.

байты трафика не имеют ровно никакого значения. в ограничения сети ты не упрешься, не переживай. а вот задержка - имеет.

val-amart ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 →
← ввод/вывод в модуле ядра
Development
Глюк GCC? →