Здравствуйте знатоки! С новым годом всех!

По проблеме, начну издалека  :
Металлургическое предприятие, занимаемся АСУТП. 
На предприятии пара дюжин SCADA систем различных типов.
Для представления информации со всех систем в информационном портале (в виде мнемосхем с опр.функционалом), написан тонкий клиент (J2SE апплет), который пользователь запускает посредством internet браузера.
Для доступа к данным, сам апплет по сокету соединяется с серверами доступа (для каждого типа системы свой коннектор, для некоторых систем они резервируются и т.д., написаны на vc++).

Для облегчения клиентского апплета, хотим внести в данную (уже наверное 3-звенную) схему еще один сервер приложений. На него перенести вcю логику работы с данными (чтение, запись, матем.функционал, распределение нагрузки и резервирование источников), инициализация мнемосхем, аутентификация и т.д.
Возможные нагрузки: единовременное обращение за данными (от 4kb - до 2 мег) от 100-150 клиентов.
Возможно в будущем появится надобность в доступе из Internet.
Платформа для сервера приложений (может быть либо windows, либо linux)

Пробовали в качестве сервера использовать RMI, но, обслуживание клиентов ведется последовательно, что очень сильно снижает производительность.

Перед тем как опубликовать тему, провел какое то время на вашем форуме, склоняюсь к j2ee и сервлетам.
Возможно я безграмотно, описал проблему, не ругайтесь сильно   , новый год ведь, но готов на любую критику и обсуждения.
Как вы поняли имеется желание сделать это на java, уровень работы с java - только написание апплетов, с j2ee никакого опыта работы не имею, как и представления.
Буду очень признателен за любые предложения

С Уважением

JEE для такой системы подходит однозначно ( хотя это и не единственное решение, конечно )
Что можно записать как основные преимущества :
1) Это спецификация, а не продукт - то есть можно с малыми затратами сделать на бесплатном JBOSS/Linux, в продакшн поставить коммерческий сервер/систему.
2) Масштабируемо - вопрос нагрузки решается простой установкой более мощного железа или кластера ( если не сделать узких мест в проекте, конечно )
3) Интероперабельна ( или как еще обозвать ? ). Связь с имеющимися SCADA системами делается либо через вебсервисы, большинство современных систем поддерживают, либо можно сделать свои коннекторы, в том числе используя имеющиеся С++ модули - это не тривиально, но реализуемо.
4) Широко используется, в том числе и в подобных задачах - есть очень много готовых наработок и литературы ( на русском правда искать лучше и не пытаться ). Есть и готовые коммерческие решения - http://www.ctc-control.com/products/software/ctsfeatures.asp вроде очень похоже на вашу задачу :-)
5) Большинство необходимых для подобного приложения функционала уже реализовано в контейнере, на задачи низкого уровня ( авторизация, доступ к данным, транзакции, кеширование соединений и т п ) можно не отвлекаться.

Для интерфейса можно и не аплет использовать, а сделать прямо web/AJAX - тогда на клиентах вообще можно ничего не настраивать, и работать откуда угодно. В том числе в вариантах PDA/WAP - на самом деле, на западе это сейчас наиболее распространенный вариант. Все сисадмины уже поняли, что гораздо проще педалировать один сервер, чем сотни или тысячи клиентов - даже если надо только JVM на каждый поставить...

Из минусов :
- не самая выдающаяся производительность. На самом деле все заточено под скорость разработки и удобство сопровождения систем. Впрочем, уже и в России стоимость работы програмиста гораздо больше любого железа. Плюс, обычно большинство тормозов проистекают из ошибок в архитектуре.
- Сложность обучения и проблемы со специалистами. Для того, чтобы писать подобные системы нужно знать много. Реально - хорошо обучаемому специалисту потребуется от полугода для освоения ( это я по своему опыту ).

Советую почитать http://www.theserverside.com/tt/books/DVTP...dbook/index.tss - о возможных архитектурных решениях. 

Пишите, если нужны консультации

Забыл об важном моменте: время отклика (загрузка апплета, инициализация, получение данных, динамизация объектов) в интранете - должно быть 1-4 сек.

Сразу вопрос можно по RMI, - эта технология подразумевает только одно поточную реализацию, т.е. на сервере создается только один объект метод которого и вызывают клиенты. Т.е. для реализации параллельного обслуживания клиентов, пул потоков и управление ими - реализовывать придется самому ?

Теперь по J2EE: 

• использование платформы Linux (в Вашем случае JBOSS/Linux) я так понимаю действительно оправдано - по производительности ? Почему не TomCat ?
• я не представляю кто и как решает задачи (авторизация, доступ к данным, транзакции, кеширование соединений) если это все специфично
• Ваше утверждение насчет сложности реализации и времени обучения - конечно не утешительны  

если, все же решаться на EE
 - с чего начать обучение, 
 - есть ли руководства по установке, настройке JBOSS - если можно на русском языке ,
 - смотрел книги по java - по EE не нашел - что порекомендуете из книг ?

RMI - это низкоуровневый механизм, все навороты с потоками, безопасностью и т.п. строятся поверх него - см например http://www-128.ibm.com/developerworks/library/j-rmiframe/ . В общем-то, именно это и является одной из основных функций JEE сервера, клиентов к нему можно и через RMI подключать, это на самом деле основной способ.

По времени обработки - собственно, обработки запросов клиентов на сервере обычно занимают несколько милисекунд, остальное прикладные методы занимают.

По поводу платформы - разницы по производительности особой нет ( в пределах 10-15% ), Linux в режиме 64бит несколько быстрее обрабатывает запросы чем Windows, но медленнее общается с дисками. Под большой нагрузкой лучше всего работает Solaris - кстати, при возможности наверно наилучший выбор.  Промышленная система, безопасная, производительная - и бесплатная ! 64-х битный Enterprise Windows сервер сам по себе денег стоит немалых.

По поводу Jboss - дело в том, что Tomcat реализует только часть спецификации JEE ( Servlet/JSP ), это веб сервер. А вот поддержка осталных функций - это сервер приложений, Jboss, SUN Glassfish, IBM Websphere, Oracle OC4J, BEA Weblogic .... Tomcat кстати входит как компонент в Jboss , да и в кучу коммерческих серверов. 

Причем, поддержка реализованных в контейнере функций буквально декларативна, просто в дескрипторе объявляется - приложению нужна такая-то база данных, перечесляются ресурсы и соединения, кому можно разрешить доступ, и т.п. - разница примерно как купить свое здание или организовать офис в бизнес-центре. В первом случае для прокладки телефонов надо сделать кучу работы, во втором надо только вписать в договор "требуется N телефонных линий".

Ну а по поводу сложности обучения - технологий для построения приложений промышленного уровня не так много ( кроме JEE наверно всерьез можно только Microsoft .NET / DNA / ... рассматривать ), и простых среди них не наблюдается :-(

По обучению - наверно можно поставить JAVA EE Tools Bundle , http://javashoplm.sun.com/ECom/docs/Welcom...sactionId=noreg , все в комплекте и там примеров довольно много. Про Jboss документации много на www.jboss.org - но вот с русской боюсь напряженно.

Хорошие книжки - http://www.ozon.ru/context/detail/id/847016/ , немного устарела но основы очень хорошо описаны ( кстати, про RMI/CORBA/аплеты и т.д. тоже есть )
http://www.ozon.ru/context/detail/id/1256375/ - вроде тоже ничего. 
К сожалению, даже на Ozon.ru остальные книги которые можно рекомендовать - на английском. Например http://www.ozon.ru/context/detail/id/1861851/ http://www.ozon.ru/context/detail/id/1831334/

Добавлено @ 00:18 
Ну и здесь по форуму много рекомендаций