|
|
|
Архитектура распределенного приложения
|
|||
|---|---|---|---|
|
#18+
Еще один вопрос возник. Я понимаю, что многие интернет приложения сводятся к обычным WEB-сайтам, для просмотра которых требуется только браузер. Но меня интересует архитектура, при которой на стороне клиента находится не браузер, а толстый клиент. То есть мне надо минимизировать объем передаваемой по сети информации посредством кэширования ее на клиенте. То есть никаких html-страничек, по сети гоняются только данные. Плюс дополнительным требованием к такой системе является безопасность. Я практически не разбираюсь в вопросах безопасности и в вопросах построения распределенных систем, поэтому хочу проконсультироваться. Возможна ли следующая архитектура, в чем ее недостатки и какие элементы в ней еще необходимы, а от каких следует избавиться 1. - клиент Java-приложение - сервер Web-сервер - клиент взаимодействует с сервером по протоколу HTTP/HTTPS - количество клиентов (от 1000, ~20000) - объем извлекаемой информации в 10 раз больше записываемой 2. На стороне сервера - Web-сервер Tomcat (на самом деле я не знаю потенциала Tomcat и мне сложно предположить какое количество клиентов он сможет обслужить, если Tomcat не подходит, то посоветуйте другой Web-сервер, но только аргументировано) - JSP/servlets (они должны обращаться к БД напрямую или иначе? как получить масштабированное решение?) - Нужен ли сервер приложений для масштабированного решения или достаточно JSP-контейнера по типу Tomcat? Какой сервер приложений лучше рассмотреть (желательно простой) как вариант. Достаточно ли одного сервера приложений? - БД Oracle (здесь советов не надо) 3. HTTPS Защищенный протокол. Это хорошо. А есть ли у него недостатки и какие существуют альтернативные решения (все передаваемые данные должны быть защищены)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 14:09 |
|
||
|
Архитектура распределенного приложения
|
|||
|---|---|---|---|
|
#18+
1. в коммерческих проектах я бы не рекомендовал затачиваться на https. у многих заказчиков есть свои стандарты безопасности. лучше надстраивать криптосредства заказчиков над http. 2. если жесткие требования к траффику, то об xml можно забыть - лучше гонять сериализированные объекты. правда избегай передачи больших массивов - сериализация штука непроизводительная. 3. важно количество конкурентных клиентов. 1000-20000 - мало похоже на правду. 4. tomcat и прочие контейнеры я бы тоже не стал использовать в коммерческих приложениях. лучше полноценный J2EE сервер(например почти бесплатный SunOne, еще лучше Weblogic, если 20к для заказчиков не деньги). и проблемы горизонтального масштабирования тебя никогда не коснутся. поддержки одного сервера достаточно. если конечно не будешь использовать нестандартные фичи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 15:20 |
|
||
|
Архитектура распределенного приложения
|
|||
|---|---|---|---|
|
#18+
В дополнение к сказанному могу посоветовать смотреть в сторону JDO. Существуют очень продвинутые инструменты, уже обеспечивающие массу очень важных фич, повышающих быстродействие JDO-приложений. Сам могу рекомендовать Versant Open Access JDO . Вместе с ним вы получаете и многоуровневый кэш (на клиенте и на сервере), и средства оптимизации производительности, и много чего еще, что как-раз и рассчитано на использование в описанной вами конфигурации (в т.ч. и с Tomcat, Weblogic, JBoss, Sun One Studio ... ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 16:37 |
|
||
|
Архитектура распределенного приложения
|
|||
|---|---|---|---|
|
#18+
Можно использовать RMI (к примеру у нас с оракловым AS сервером "толстые" клиенты работают через ORMI т.е. EJB интерфейсы дёргают напрямую и HTTP им не нать) ЗЫ насчёт security ничего сказать не могу(не владею информацией) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 17:00 |
|
||
|
Архитектура распределенного приложения
|
|||
|---|---|---|---|
|
#18+
2 Ora-мучитель Необходим также слой бизнес-логики между БД и сервлетами/JSP. Этот слой может также составным. В него могут входить persistence-объекты, которые реализуется с помощью готовых средств ORM (например, TopLink, Hibernate) и EJB, все это может использоваться вместе или порознь. Опять же детали конкретной реализации бизнес-логики зависят от Вашей прикладной задачи. Или же Вы сами можете реализовать этот слой, используя JDBC, написав набор своих dbaware-классов для persistence-объектов. В Hibernate нет ничего уникального, его исходный код довольно хорошо читаем, можете взять его за основу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 17:13 |
|
||
|
Архитектура распределенного приложения
|
|||
|---|---|---|---|
|
#18+
2 Ora-мучитель Насчет сети - мне кажется, что можно не упираться в HTTP, а реализовать на сокетах свой протокол передачи "только данных". В этом тоже ничего фантастического нет. в JDK 1.5 появился JMXConnectorFactory - обратите внимание на него. Мне кажется, веб тут не нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 17:20 |
|
||
|
Архитектура распределенного приложения
|
|||
|---|---|---|---|
|
#18+
2 Steppenwulf Я не имею опыта создания интернет приложений, но знающие люди говорят, что практикуется во многих организациях оставлять 80 порт открытым, а все остальное закрывать. К тому же, если необходимо возвращать наборы записей, то изобретать свой протокол не самая приятная задача. 2 all Неужели XML-ные данные действительно так сильно нагружают сеть? А какова допустимая нагрузка на Tomcat (в concurrent-клиентах)? Tomcat кажется поддерживает EJB. Можно ли реализовать всю бизнес-логику на EJB. И по безопасности еще вопрос. Эта область для меня вообще загадка. Есть клиент и есть сервер и еще есть большое желание не изобретать велосипед. Хочется обезопаситься, но при этом не писать код, а использовать стандартные способы защиты канала. Может кто что порекомендует? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 17:56 |
|
||
|
Архитектура распределенного приложения
|
|||
|---|---|---|---|
|
#18+
Ora-мучительTomcat кажется поддерживает EJB. Можно ли реализовать всю бизнес-логику на EJB. бизнес-логику на EJB реализовать конечно можно. Но ТОМКАТ не поддерживает EJB-контейнеры Если надо EJB, то лучше использовать специализированный сервер приложений, например, Oracle Application Server ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 18:33 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=33014106&tid=2152583]: |
0ms |
get settings: |
11ms |
get forum list: |
24ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
89ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 243ms |
| total: | 458ms |

| 0 / 0 |
