Параметры сетевого взаимодействия в Java (клиент / сервер) - PullRequest
Новая
       23

Параметры сетевого взаимодействия в Java (клиент / сервер)

1 голос
/ 03 октября 2011

Существует RMI, который, как я понимаю, является относительно хрупким, прямые соединения Socket, который является довольно низким уровнем, и Strings, которые хотя и кажутся такими же прочными, как и метафорический PHP.

Какие менее базовые опции у меня есть для интернет-клиент / сервер связи? Каковы преимущества / недостатки? Какие проблемы я должен принять во внимание? Предложения сторонних библиотек хороши, если они остаются независимыми от платформы (т. Е. Нет ограничительного нативного кода).

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

Ответы [ 2 ]

2 голосов
/ 03 октября 2011

Как вы указали "на основе интернета", многое можно сказать о подходе на основе HTTP, RESTful (я выделил некоторые проблемы, которые следует учитывать):

Плюсы:

  • Вы можете использовать / злоупотреблять одним из множества веб-уровней frameworks для серверной части (например, Spring MVC , Play! )
  • Работа на низком уровне была выполнена на стороне клиента (Apache HTTPClient)
  • Протокол простого текста легко отлаживать по проводам
  • Тонны инструментов, которые помогут вам Отладка взаимодействия (например, SoapUI ) - вы можете притвориться клиентом ИЛИ сервером и поэтому развиваются изолированно до другого конца готов
  • Использование известного порта (80/443) делает пробивание через корпоративные брандмауэры намного проще

Минусы:

  • Существует довольно серьезное предположение, что сервер будет выполнять львиную долю работы - если ваша модель "перевернута", тогда может быть бессмысленно быть RESTful
  • Необработанная производительность будет ниже, чем при использовании метода «бит на проводе»
  • Протокол простого текста легко нюхать по проводам (SSL может исправить это)
0 голосов
/ 03 октября 2011

Что означает «относительно хрупкий»?Проблемы с RMI связаны с тем, что он представляет собой большую надстройку на узкой основе и, в частности, что он сильно зависит от DNS и сериализации объектов.Чем ближе вы к кремнию, тем менее хрупкой становится любая программа, но тем больше кода вы должны написать.Это компромисс.Я не одноглазый сторонник RMI, несмотря на то, что написал книгу об этом, но «хрупкость» - слишком сильное слово.Он делает то, что делает, и делает это достаточно хорошо.RMI / IIOP делает это еще лучше во многих отношениях, если вам нужна масштабируемая масштабируемость.Если ваш взгляд на мир представляет собой, по крайней мере, один раз удаленный вызов метода без особой безопасности, RMI / JRMP предоставит его вам.Чем дальше вы получаете от этой модели, тем сложнее становится применять.

...