посоветуйте форум по Java

[Sherman]

EJB модуль - да. Может быть отдельно задеплоен на app. server.

http://download.oracle.com/docs/cd/E17802_01/products/products/ejb/javadoc-3_0-fr/javax/ejb/Remote.html - для интерфейса удаленного объекта

+ имплементация.

Затем нужно задеплоить bean на app server.

В приложении его можно получать через JNDI например и использовать методы интерфейса для которого была аннотация @Remote.

Если есть желание все же использовать "толстый" J2EE надо прочитать все же хотя бы tutorial целиком.

http://download.oracle.com/javaee/5/tutorial/doc/javaeetutorial5.pdf

 

[Sherman]

p.s. А вообще призываю вас еще раз забить на EJB и даже на APP Server.

Для web-а можно использовать GWT+JPA2, Spring+JPA2, Spring Roo, Play Framework.

Сервлет-контейнер: tomcat/jetty.

Messaging: any JMS impl.

 

[dr-sm]

однако, EJB 3.1 скорее ближе к Spring, чем к монстру EJB2.

 

[iceman]

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

просто если подключать к проекту либу с бином, то она и оказывается в jar файле, и в итоге получается что использую я не тот бин, который уже задиплоин, а тот который идет с поставкой моего проекта. а без вложенной либы - проект не компилица, пробовал уже делать копию интерфейса бина(с @Remote), бесполезно.

про JNDI прочитаю, разберусь, спасибо ! +)

 

[iceman]

Sherman

p.s. А вообще призываю вас еще раз забить на EJB и даже на APP Server.

Для web-а можно использовать GWT+JPA2, Spring+JPA2, Spring Roo, Play Framework.

Сервлет-контейнер: tomcat/jetty.

Oracle Glassfish уже куплен да и не для веба мне это нужно. должны крутится приложения отвечающие за репликацию из одной информ. системы в нашу, системы мониторинга удаленных терминалов и всякая лабуда, веб интерфейсы написаны pl/sql

 

[Sherman]

GF вроде бесплатен и даже с открытым кодом? У нас кстати, на работе тоже не web. Большое распределенное клиент-серверное приложение с кучей отдельных серверов на java и клиентом на c#. Для HTTP используется embedded jetty и JSON. Бинарный протокол через socket(NIO, свой framework). InMemory Storage(свой). Кое-где RMI. JPA2 для persistence. Ну и конечно JMS

 

[pilot911]

GF вроде бесплатен и даже с открытым кодом? У нас кстати, на работе тоже не web. Большое распределенное клиент-серверное приложение с кучей отдельных серверов на java и клиентом на c#. Для HTTP используется embedded jetty и JSON. Бинарный протокол через socket(NIO, свой framework). InMemory Storage(свой). Кое-где RMI. JPA2 для persistence. Ну и конечно JMS

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

 

[Sherman]

Подробно писать не могу - NDA. Но смысл в том, что двигаемся мы всяко в сторону JPA2 + rdbms(Oracle) в плане storage. В плане API нам сейчас вообще key-value хватает(то есть все операции по PK фактически). У нас правда есть одно ключевое требование к системе: soft realtime для многих операций. То есть если клиент где-то в GUI шмякнул по кнопке и что-то изменил, надо чтобы об этом узнали, как сервисы, которые на этом завязаны(ну там скажем пересчитали что-то), так и другие клиенты, которые работают с теми же данными. Плюс наши сервисы используют кучу внешних сервисов(также по модели подписки). Получается что самое сложное в storage - это вовсе не хранение, а реализация event-driven architecture. Типа изменилось поле в такой-то "таблице", и надо сразу оповестить об этом кучу подписчиков. Поэтому, база у нас - это всего лишь persistence storage, не более.

 

[pilot911]

Подробно писать не могу - NDA. Но смысл в том, что двигаемся мы всяко в сторону JPA2 + rdbms(Oracle) в плане storage. В плане API нам сейчас вообще key-value хватает(то есть все операции по PK фактически). У нас правда есть одно ключевое требование к системе: soft realtime для многих операций. То есть если клиент где-то в GUI шмякнул по кнопке и что-то изменил, надо чтобы об этом узнали, как сервисы, которые на этом завязаны(ну там скажем пересчитали что-то), так и другие клиенты, которые работают с теми же данными. Плюс наши сервисы используют кучу внешних сервисов(также по модели подписки). Получается что самое сложное в storage - это вовсе не хранение, а реализация event-driven architecture. Типа изменилось поле в такой-то "таблице", и надо сразу оповестить об этом кучу подписчиков. Поэтому, база у нас - это всего лишь persistence storage, не более.

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

 

[Sherman]

У нас вообще не ОПЕРДЕНЬ, поэтому никакого генерирования форм, конструктора объектов и т.д. GUI точно также программируется отдельными людьми, как и сервера. Между ними есть пара протоколов(JSON и бинарный). Некоторая часть контроллов(например GRID) прямо напрямую связаны со storage, поэтому сообщения о события доходят до GRID точно также как и для какого-нибудь сервера-подписчика. Я про архитекутуру GUI не сильно много знаю, так как это не моя епархия.

 

[pilot911]

спасибо )