Доброго времени суток!
 Изначально запостил данный топик в Технологиях->Проектирование, но ветка не особо активная похоже, т.к. в течении 3-4 дней ни одного ответа. Решил отписать сюда потому, как смысл больше относится к разработке на Java - хотелось бы услышать мнение завсегдатаев этого форума. Вот оригинал.
  
  Если в кратце, то стоит на данный момент выбор написания ERP - системы для компании, и больше склоняюсь к Java апплетам и серверу приложений с СУБД. 
  Есть соблазн так же использовать Java EE, т.к. с ней работал, и в качестве тонкого клиента бразуер будет, но клиент должен быть очень "богатым" в плане пользовательского интерфейса, и есть сомнение, что без костылей на JavaScript не обойтись, а этого бы не хотелось бы....

Заранее благодарен за ответы!

Очень богатый клиент можно написать на Swing и он будет подключаться вызывать методы сервера через RMI.
Стартовать его можно как самостоятельно (т.е. как обычное java приложение), так и как web application через java web start. 
Хотя web (т.е. взаимодействие через http) все-таки иногда бывает предпочтительнее - не нужно тащить jvm для каждого клиента. 


Современные js фреймворки типа jQuery отлично решают такие проблемы - можно будет обойтись и без костылей.

Это сообщение отредактировал(а) Stolzen - 6.6.2011, 03:13

Идеи можно посмотреть здесь - Схема построения Enterprise-приложений
В качестве AppServer можно взять JBoss. В принципе можно и Glassfish или вообще Tomcat с OpenEJB или Spring.

Ребят, спасибо за ответы!
 
AntonSaburov, спасибо за статью.
Так же прочёл оригинальный ман, датированный 1999 годом, по поводу этого всего дела.
 И если честно немного остался в замешательстве. Большая просьба прояснить.

Значит по статье.
  Сначала там приводиться мега-простейший пример использования RMI: создаётся простенький сервер с нужным портом, простенький клиент;  клиент лукаппит  необходимый объект и всё в порядке. 
  Потом авторы говорят, а давайте будем перегонять объекты м/ду клиентом и сервером через HTTP, тем самым улучшится масштабируемость приложения. И получилось следующее:
Клиентская часть - это Апплет(вообщем GUI), и некоторый Poxy, через который происходит общение с сервером по HTTP.
Серверная часть - клиентский Proxy общается тут с сервлетами, а те в свою очередь посредством RMI общаются с остальным сервером приложений. 
 Вопрос: зачем на этом уровне RMI, не громоздко ли это?
По хорошему на сервере приложений неплохо бы задействовать Spring+Hibernate и этим можно ограничится, в RMI и сервлетах в голом виде нет необходимости. 
Или всё-таки я что-то упустил?

Это сообщение отредактировал(а) lexnext1 - 13.6.2011, 09:14

Не знаю насчет оригинального мана, не читал, я думаю, что можно обратиться к этому мануалу - http://download.oracle.com/javase/tutorial/rmi/overview.html

Если остановились на толстом клиенте, при соблюдении архитектуры MVC проблем с отделением не должно быть. Создаете интерфейс для модели, реализуете на сервере, а клиенту даете RMI стаб. При использовании spring все очень упрощается - можно почитать тут. Регистрировать и использовать RMI службы с помощью Spring очень просто и удобно.

С EJB практически та же история - делаете модель удаленной (например, с помощью аннотации @Remote), подключаетесь к серверу приложений (JBoss, GlassFish, etc) и используете. Правда, с этим я только в теории знаком.

По поводу 

Если я правильно понял, то при таком подходе на машине клиента будет работать апплет (т.е. джава приложение). RMI тут нужен, чтобы он мог подключаться к самому серверу и использовать некоторые его объекты, потому что в противном случае (без использования rmi) это будет просто локальное приложение. 

Не сильно понимаю приемуществ подобного подхода (может быть, еще не созрел). У нас в проекте тоже такое используется, кстати. Любой может зайти на сайт (ну не любой, нужна авторизация), скачать апплет и через java web start подключиться и производить какие-нибудь манипуляции с сервером. Наверное это нужно для того, чтобы была возможность с любой машины скачать программу и работать? Не знаю... 

Это сообщение отредактировал(а) Stolzen - 13.6.2011, 10:18