Ну а что. Пишется приложение, которое слушает определенный порт или на сокетах или тот же RMI сразу берем.
Формат запроса/ответа можем придумать сами или взять готовые (xml и т.п.).
Возможно, придется создавать очередь запросов, свой пул подключений к БД с возможностями настройки, автонастройки.
Т.е. создать какую-то примитивную прослойку между БД и клиентом можно, при чем на яве скорее, что это делать удобнее и быстрее.

Меня всегда интересовал вопрос целесообразности этого (трехзвенки с написанием своего сервера приложений)? )
Вижу такие варианты, когда это можно попробовать:
- например, нам дорого покупать БД-кластер и мы хотим сами распределять нагрузку и резервирование, т.е. пишем среднее звено, которое будет выполнять эту функцию
- например, у нас много сложных промежуточных операций в запросах (между клиентом и сервером), которые возможно лучше вынести на отдельную машину (эцп, шифрование, в принципе сложный формат сообщений и т.п.)
- например, у нас в принципе есть операции, которые лучше решать не внутри БД (какие именно правда не представляю)

Но в общем сознании пишут, что дескать на сервер приложений выносят некий бизнес слой. Что входит в это понятие фз и чем не угодила БД тоже не ясно.

Если кто прояснит, думаю, тоже будет в тему.

Petro123нет логики. А это первое качество программиста.
- вы писали много кода для СУБД. Но там нет ООП.
- вопрос - куда и как засунуть это ООП? На котором хотят писать программисты.
Если вы не знаете ОРМ\ООП то вообще смените профессию.
Либо вы флудер.
Ребят, а в чем логика вашего поста?
ООП (если уж тру-программисты хотят писать именно используя его :)), можно писать и просто на клиенте,
ТС же, как я понял, ставит вопрос именно занафига вообще сервер приложений - неужели только для того, что программисты хотят писать на ООП имхо, или я чигота не догоняю? )

Ну можно представить, что сервер приложений получает от БД или наборы данных или хмл-ки и т.п., сериализует их в объекты/классы и дальше настоящие программисты работают с этим так что ли? )

Ну еще можно понять оправданность сервера приложений с т.з. повышения безопасноти доступа к БД...

Blazkowicz , сначала не было, но потом, как сами заметили:
банковский щётА вопрос был, как писать эти самые серверные приложения (т.е. среднее звено в трёхзвенке), так как я пока не представляю себе, как взаимодействует клиентское приложение со средним звеном (если среднее звено - это не веб-сервер).

Еще можно понять, что сервер приложений может играть роль единого интерфейса для всех клиентов ИС, обращаясь в при этом к совершенно разным источникам данных (разные СУБД, сервисы, файлы и т.п.).

BlazkowiczКак написать трехзвенку, если среднее звено не сервер? И где тут про контейнеры?
Я конечно не шарю, но тем лучше, - может тоже для себя что-то уясню )
1. Автор подразумевает, что роль среднего звена (сервера приложений) может играть веб-сервер. Так?
При этом мы знаем, что в частном случае, тот же GF включает в себя контейнер томката или нет? (ну если именно про: где тут про контейнеры).
2. Далее он спрашивает как писать среднее звено, если используем не готовый веб-сервер. Так? Т.е. человек по сути спрашивает, как писать сервер приложений, как я понял. Что не так? )