Здравствуйте. Пишу порграмму (морду к БД) для обработки данных, сейчас все операции по работе  с БД, находятся в ней.  Уже появилось много проблем, связанных с синхронизацией, расстоновкой блокировок и тд.Я вижу необходимость в промежуточном слое, что-то типа сервера-приложений (не уверен что правильно применяю данный термин). Этот слой должен выбирать данные из БД, отправлять клиенту, скорректированные принимать от клиента и обратно записывать в БД. Подскажите как это можно реализовать?Для этого нужно использовать j2ee ?

bio_hazard, можно и без J2EE наверное. Тут ведь прежде всего надо будет решить, как клиенты будут общаться с сервером. Возможно, и простого RMI хватит. Но вообще все зависит от размеров системы: если она большая, то лучше ЕЕ задействовать, ну или что-то похожее (типа Spring).
В плане реализации вариантов много. Можно замутить веб-приложение на базе какого-нибудь несложного сервера типа Tomcat. Если необходимо работать с сервером из настольного приложения (т.е. веб-интерфейс не устраивает), и при этом интенсивность обмена данными между клиентом и сервером невелика, можно установить на Tomcat какой-нибудь AXIS и общаться с сервером посредством Web Services. Наконец, можно поднять полноценный сервер приложений (типа Glassfish) и уже задействовать возможности J2EE на полную катушку с помощью всякоразных EJB'ей.

Спасибо, пойду читать про axis

По поводу AXIS сразу отмечу, что Web Services - это ДАЛЕКО не самый быстрый и эффективный способ обмена данными между клиентом и сервером. Так что в случае выбора этого пути следует хорошенько продумать вопросы производительности. Т.е. если обмен данными носит периодический характер и объем передаваемых данных не слишком велик, то проблем возникнуть не должно; в противном же случае будут серьезные тормоза.

Объем не большой совсем, буквально по 0,5 кб текста , в 2-3 минуты должно гонятся.

ну, скажем так, так было пару лет назад... сейчас все несколько иначе, т.к. эти тормоза были в основном связаны с малой пропускной способностью канала, а он сейчас потолстел почти везде довольно сильно. Так что сейчас веб сервисы работают не на много медленнее. К тому же SOAP будет выгднее использовать, т.к. я на 100% уверен, что для передачи данных байтовый протокол изобретать будет лень и данные будут передаваться структурированно XML-ником... К тому же, не стоит забывать, что если будет какая-то транзакционная работа, как будет реализован механизм транзакций? В случае веб сервисов есть WS-AtomicTransaction. А если надо засекьюрить протокол? HTTPS - легко. Вобщем, может с точки зрения производительности это вариант не самый быстрый, но с точки зрения расширяемости и кроссплатформенности - самое то 

По поводу производительности: дело не только в пропускной способности канала (100 Мбит локалка не всегда спасает ), но и в необходимости производить XML-сериализацию/десериализацию данных. На эти операции может уходить довольно много времени; "бинарные" сериализаторы (например, при использовании RMI) работают пошустрее. 
Впрочем, в случае буквально по 0,5 кб текста , в 2-3 минуты это точно не будет критично, благо при сериализации простого текста делать практически ничего не надо.

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