Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java: Общие вопросы > какая архитектура системы лучше

Автор: _tims_ 24.10.2007, 05:41

Привет всем! Я пишу систему на java, поэтому вопрос сюда.  Мне нужно написать для маленькой фирмы территориально-распределенную информационную систему, ну там: клиентская часть, сервер логики приложения, сервер БД. Так вот. Т.к. фирма маленькая и не может позволить себе лишние затраты на всякие прибамбасы, меня интересует прежде всего экономическая эффективность архитектуры такой ИС. В связи с чем вопросы. Какой должна быть архитектура такой ИС? И как она должна обмениваться данными с удаленным клиентом: переодически опрашивать об изменениях или удаленный пользователь работает в режиме on-line или это без разницы? Особенно меня интересует связь между клиентом и сервером, которая осуществляется через глобальную сеть.. такое вообще практикуется или только по выделенным линиям и лвс??  И еще вопрос: с помощью каких технологий java возможна интеграция с другими приложениями? Надеюсь здесь многие шарят в этой области и могут подсказать какие-нить полезные ссылки или хорошую лит-ру на эту тему. Или по своему опыту подсказать что-нить. Заранее пасиб.

Автор: mbasil 24.10.2007, 08:49

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

Автор: fixxer 24.10.2007, 11:05

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

Автор: Zverek 24.10.2007, 14:49

Цитата(_tims_ @  24.10.2007,  05:41 ) И еще вопрос: с помощью каких технологий java возможна интеграция с другими приложениями? Думаю веб-сервисы будут хорошим решением.

Автор: pompei 24.10.2007, 15:14

Я бы стал делать так: Клиент: Eclipse RCP + Spring Сервер: axis + Hibernate + String + MySQL 5  Взаимодействие: Web-сервисы При проектировании бизнес логики стоит максимально избегать периодическое опрашивания сервера (почти всегда это можно сделать, а если всё же нет, то это будет несколько режимов и можно сделать периодическое обращение к серверу по таймеру). Необходимо изначально задаться целью чтобы сервер не знал о клиентах, а только обслуживал авторизированные веб-сервисы. (Т.е. постараться избежать например таких функций как: посмотреть какие данные в текущий момент вводит клиент в форму и пр.)

Автор: _tims_ 24.10.2007, 21:02

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

Автор: powerOn 24.10.2007, 21:39

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

Автор: _tims_ 24.10.2007, 22:29

спасибо

Автор: mbasil 25.10.2007, 12:16

Вообще-то вопрос  Цитата (клиентская часть, серверная часть(БД, логика приложения))?" тянет совершенно однозначно на клиент/сервер (то есть на толстого клиента, реализующего бизнес логику). И рекомендация совмещать бизнес логику и базу данных на одном узле может быть воспринята неоднозначно тем человеком, который не очень хорошо знаком с особенностями архитектуры приложений Java EE. Я бы хотел подчеркнуть, что современный подход это web приложение, не важно, на одном узле работает сервер приложения и база данных, или на разных физических узлах, тем более что с точки зрения структуры правильного web приложения не важно на одном физическом узле они работают, или на разных.

Автор: Vasay 25.10.2007, 13:23

Впринципе, здесь  уже все ответили, только одно замечание: pompei, за MySQL  нужно платить. mbasil,  Oracle Express 4Гб конечно не мало, но все же это ограничение Может лудше PostgreSQL ?

Автор: AlexeyVorotnikov 25.10.2007, 13:37

Цитата(Vasay @  25.10.2007,  14:23 ) pompei, за MySQL  нужно платить. В каком смысле "платить"? MySQL что, стал платным?

Автор: Vasay 25.10.2007, 13:46

Цитата В каком смысле "платить"? MySQL что, стал платным?  Он всегда был платным. Цитата MySQL имеет двойное лицензирование. MySQL может распространяться в соответствии с условиями лицензии GPL. Но по условиям GPL, если какая-либо программа требует MySQL, то она тоже должна распространяться по лицензии GPL. Однако, это может расходиться с планами разработчиков, которые могут не хотеть раскрыть исходных текстов своих программ. Для таких случаев предусмотрены коммерческая лицензия компании MySQL AB, которая так же обеспечивает качественную сервисную поддержку. Т.е. насколько я понимаю, если _tims_ пишет ПО для своей фирмы, то ничего страшного, а если он пишет ПО на заказ, то это уже не гуд, так как он должен будет предоставить заказчику исходные коды, а заказчик сможет их передать кому угодно....

Автор: mbasil 26.10.2007, 09:04

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)