kT_________Уважаемые коллеги, буду благодарен если наспамите бэст_практикс ссылок по сабжу.(client - NetBeans RCP, server-side Spring)
В этой комбинации всё просто до безобразия. Смотрите Remoting протоколы и выбираете более вам подходящий. Spring Http Invoker простой и удобный.
Вот если вы захотите ORM использовать. Вот, тогда у вас начнется настоящее веселье и целый набор разнообразных вариантов.

kT_________Да, конечно захочу. Есть БД, надо в клиенте отображать таблички. т.о. ОРМ в Спринге мне тоже очень интересен, у Вас нет ссылок под рукой? ;)
http://martinfowler.com/articles/enterprisePatterns.html
http://www.oracle.com/technetwork/java/index-138725.html

kT_________Да, конечно захочу. Есть БД, надо в клиенте отображать таблички. т.о. ОРМ в Спринге мне тоже очень интересен, у Вас нет ссылок под рукой? ;)
Проблема ORM не в спринге, а в толстом клиенте.
- Единство и борьба противоположностей - серверная domain model vs клиентская. С одной стороны они очень сильно совпадают и разделение моделей ведёт к дублированию структур. Так же нужна куча тупого кода - гонять структуры туда и обратно. С другой стороны, если использовать одну и ту же модель, то на клиенте может понадобиться код, не нужный на сервере, иногда даже вредный. И наоборот.
- Разрешать ли клиенту ленивую загрузку, или как иначе бороться с LazyLoadException?
- Использовать ли dirty check?
- Использовать ли удаление в PersistentCollection, или делать самостоятельно.

kT_________Мне очень интересно как правильно внутри спринга должно быть реализовано та часть кода, которая стоит между обработкой клиентских запросов и взаимодействием с БД ;)
Обычно реализуют как Transaction Script
http://martinfowler.com/eaaCatalog/transactionScript.html
Хотя варианты бывают разные.
http://martinfowler.com/eaaCatalog/domainModel.html

kT_________Кроме того, думаю можно и без ОРМа, имет ли он смысл вообще, когда в БД две-три таблицы, это по фэн-шую из Спринга вызывать например хранимки и отдавать клиенту?
Когда в БД нет большого количества ассоциаций, то ORM скорее всего применять не нужно.