Привет всем! Я пишу систему на java, поэтому вопрос сюда. 

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

Какой должна быть архитектура такой ИС? И как она должна обмениваться данными с удаленным клиентом: переодически опрашивать об изменениях или удаленный пользователь работает в режиме on-line или это без разницы?

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

И еще вопрос: с помощью каких технологий java возможна интеграция с другими приложениями?

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

Это сообщение отредактировал(а) _tims_ - 24.10.2007, 06:05

Пишите сразу как web приложение:

1. Базу данных я взял бы Oracle Express - бесплатно, до 4 Гб пользовательских данных.
    Возможность дальнейщего масштабирования.
2  JSP для презентационного уровня. Бесплатный и широко используемый
    сервер Apache Tomcat. В рамках структурирования приложения использовал бы Struts.
3. Для связи с базой либо JDBC напрямую с собственной реализацией шаблона DAO, 
    либо Hibernate.

Только приготовьтесь "убить" солидное время на изучение. 

Я бы добавил еще Spring. Тогда в пунктах 2 и 3 можно варьировать решения и избежать vendor-lock-in

Думаю веб-сервисы будут хорошим решением.

Я бы стал делать так:

Клиент: Eclipse RCP + Spring

Сервер: axis + Hibernate + String + MySQL 5 

Взаимодействие: Web-сервисы

При проектировании бизнес логики стоит максимально избегать периодическое опрашивания сервера (почти всегда это можно сделать, а если всё же нет, то это будет несколько режимов и можно сделать периодическое обращение к серверу по таймеру).

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

Спасибо за ответы 

У меня еще вопрос: лучше использовать трехзвенную архитектуру (клиентская часть, сервер прилож., сервер БД) или двухзвенную (клиентская часть, серверная часть(БД, логика приложения))?

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

спасибо 

Вообще-то вопрос 



тянет совершенно однозначно на клиент/сервер (то есть на толстого клиента, реализующего бизнес логику).

И рекомендация совмещать бизнес логику и базу данных на одном узле может быть воспринята неоднозначно
тем человеком, который не очень хорошо знаком с особенностями архитектуры приложений Java EE.
Я бы хотел подчеркнуть, что современный подход это web приложение, не важно, на одном узле
работает сервер приложения и база данных, или на разных физических узлах, тем более что
с точки зрения структуры правильного web приложения не важно на одном физическом узле они работают,
или на разных.

Это сообщение отредактировал(а) mbasil - 25.10.2007, 12:16

Впринципе, здесь  уже все ответили, только одно замечание:


pompei, за MySQL  нужно платить.


mbasil,  Oracle Express 4Гб конечно не мало, но все же это ограничение

Может лудше PostgreSQL ?

В каком смысле "платить"? MySQL что, стал платным?

Он всегда был платным.




Т.е. насколько я понимаю, если _tims_ пишет ПО для своей фирмы, то ничего страшного, а если он пишет ПО на заказ, то это уже не гуд, так как он должен будет предоставить заказчику исходные коды, а заказчик сможет их передать кому угодно....

Vasay, Oracle Express хорош именно возможность дальнейшего масштабирования.
Появятся  у компании деньги и при переходе на платную Enterprise версию перенос 
базы данных можно будет сделать за пол-дня без особого напряга и какого бы то ни было
участия разработчиков, только силами администратора. Да и сам администратор базы
частично уже будет готов к работе, не понадобится его переподготовка.
И не зарекайтесь, что масштабирования Вашей системы не понадобится никогда.