![]() |
Модераторы: LSD, AntonSaburov |
![]() ![]() ![]() |
|
robocoffee |
|
|||
Новичок Профиль Группа: Участник Сообщений: 15 Регистрация: 11.9.2009 Репутация: нет Всего: нет |
Здравствуйте, друзья!
есть проект для небольшой фирмы, структура базы данных достаточно сложная, хранится огромное количество данных, но количество пользователей всего 10-20 человек. И работа только в локальной сети. Сложной обработки этих данных не предвидится. Отчеты, автоматическое формирование документов, сравнение данных и т.д. Все, ничего больше. Я решил писать обычное клиентское приложение на Java + MySQL. Без сервера приложений, и без веб-интерфейса. Плюсы я вижу такие: меньше времени на разработку, легкость в установке и поддержке. Минусов пока не вижу ![]() Скажите пожалуйста, какие проблемы могут возникнуть при таком подходе? и есть ли причины для использования j2EE в такой задаче? |
|||
|
||||
jcyber |
|
|||
![]() Шустрый ![]() Профиль Группа: Участник Сообщений: 57 Регистрация: 2.4.2009 Репутация: нет Всего: нет |
Если программа предназначена только для пользования сотрудниками конторы, то нет необходимости поднимать апп. сервер, писать среднее звено и заниматся прочей ерундой. Для такое ситуации вполне подойдет Standalone + JWS.
|
|||
|
||||
Nofate |
|
|||
![]() Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 266 Регистрация: 13.10.2008 Репутация: 2 Всего: 8 |
У нас есть проект для небольших фирм, написанный в виде толстого клиента + mssql. Много таблиц, очень много данных, пользователей пять-десять, документы, отчеты ). И напрягает отсутствие полноценного сервера приложений. Хотя бы банально невозможностью красиво сделать блокировки и обновление данных на всех клиентах. Кроме того пользователи время от времени умудряются работать в устаревшей версии клиента.
Хотя не скрою: проколов в архитектуре хватает. =) Это сообщение отредактировал(а) Nofate - 10.12.2009, 10:14 -------------------- The future is not set, there is no fate but what we make for ourselves. Нофейтово пространство и смежные области |
|||
|
||||
robocoffee |
|
||||
Новичок Профиль Группа: Участник Сообщений: 15 Регистрация: 11.9.2009 Репутация: нет Всего: нет |
- я примерно также рассуждал, радует что верно мыслил ![]()
- если это единственный минус - то с этим готов смириться ![]() спасибо! |
||||
|
|||||
jcyber |
|
|||
![]() Шустрый ![]() Профиль Группа: Участник Сообщений: 57 Регистрация: 2.4.2009 Репутация: нет Всего: нет |
Обновление данных зависит только от пользователя. Если даже у вас будет сервер с, к примеру, EJB модулем, то на сервер всеравно нужно послать запрос что бы получить обновленные данные из БД, будь то десктоп(нажать на кнопку) или веб-клиент(релоад страницы). Проблемы со старыми версиями решает JWS. |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
robocoffee,
Придерживаюсь мнения, что архитектура толстый клиент <-> DB - есть моветон. Даже делая толстый клиент я бы использовал сервер приложений, как промежуточный уровень. п.с. при современных наборах решений для построения веб приложений, разработать красивый веб интерфейсы не сложней (а то и легче) чем десктоп апликэйшен. Другое дело, что "программка" может быть удобней для не привыкшего к браузеру пользователя. -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
robocoffee |
|
|||
Новичок Профиль Группа: Участник Сообщений: 15 Регистрация: 11.9.2009 Репутация: нет Всего: нет |
Vasay,
отлично, а можно пару аргументов в пользу этого? серьезно, буду очень благодарен за конструктивные мысли. Пытался найти какие нибудь статьи на эту тему, но пока - ничего конкретного, везде пишут "решение зависит от задачи". |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
При архитектуре десктоп приложение <-> база данных возникает проблема разграничение прав доступа к информации в базе. Постараюсь привести пример (может быть весьма неудачный) Есть в фирме 2 менеджера. Они со своего рабочего места должны иметь доступ к информации о своих (и только своих) клиентах. Но не будем же мы создавать отдельную БД для каждого менеджера? Не будем - все клиенты хранятся в одной таблице в одной БД к которой имеет доступ программа каждого менеджера. Вопрос - как разграничить доступ к информации для менеджера 1 и менеджера 2 ? Получается, что это возможно только внутри клиентской программы при формировании sql запроса. Но если нам попался технически грамотный менеджер, то он вполне сможет выдрать строку подключения к базе данных из программы, подключиться к БД с помощью какого-нибудь клиента и спокойно скачать информацию о всех клиентах фирмы, не только своих. Ну а если у нас трехзвенная архитектура, то разграничение прав доступа идет на уровне сервера, и менеджер1 не сможет узнать про клиентов менеджера 2 не зная его пароля и логина. (ну, или не договорившись с администратором базы данных ![]() Это сообщение отредактировал(а) Vasay - 10.12.2009, 12:14 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
robocoffee |
|
|||
Новичок Профиль Группа: Участник Сообщений: 15 Регистрация: 11.9.2009 Репутация: нет Всего: нет |
Vasay
кстати да! сталкивался с этим, ну подумали что не настолько это уж страшно, а менеджер производящий такие действия - настоящий ренегат, таких административными методами вычисляют ![]() спасибо за ваше время ![]() |
|||
|
||||
DimW |
|
||||||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
жжоте! наличие промежуточного уровня уже говорит о том что клиент "тонкий".
для этого существует авторизация. ну так вот - после того как менеджер вводит логин пароль, в его текущей сессии инициализируются параметры необходимые для этого самого разграничения клиентов, таким образом передав значения этих параметров в sql зарос и делается это самое разграничение.
это уже говорит о технически не грамотных прогерах.
разграничение впринцыпе должно идти на уровне сервера, только в одном случае это БД сервер, во втором сервер приложений, а на десктопе это выглядет мягко говоря глупо. robocoffee, здесь вопрос скорее не в проигреше подхода по каким либо недостаткам технологий, а в целесообразности выбора архитектуры. поверьте в "толстом" клиенте как и в "тонком" достаточно средств которые способны выдержать все требования по разграничению прав доступа, маштабируемости приложения, и т.д. успехов. |
||||||||
|
|||||||||
robocoffee |
|
|||
Новичок Профиль Группа: Участник Сообщений: 15 Регистрация: 11.9.2009 Репутация: нет Всего: нет |
DimW,
спасибо! можно сказать, вопросов больше нет, ответ получен ![]() |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
DimW,
В моем понимании "тонкий клиент" - это браузер. Любое десктоп приложение - это уже "толстый клиент" и он вовсе не обязан общаться с БД напрямую, общение может происходить, например, и через xml службу. И какие возможности предлагает MySQL (о которой шла речь) для разграничения прав доступа? Если мне не изменяет память. максимум что вы можете сделать - это дать ограниченные права на доступ к конкретной базе данных на сервере. Но если вы дали пользователю Manager1 возможность делать SELECT из DB_CUSTOMER, то вы не сможете ограничить его возможности селектить любые данные из этой базы данных. (хотя, я могу ошибаться). Ну а вытащить строку подключения к базе данных из java программы не так уж сложно - если человеку надо, то он это сделает. -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
ivanovpv |
|
|||
![]() Варвар ![]() ![]() Профиль Группа: Участник Сообщений: 639 Регистрация: 26.1.2005 Где: Москва Репутация: 2 Всего: 28 |
Я бы не был таким категоричным... Толщина клиента и наличие сервера приложений вещи из разных опер. Можно иметь тонкого клиента, без сервера приложений, а можно иметь сервер приложений с толстым клиентом. Сервер приложений нужен не для определения толщины клиента, он нужен либо: а) Для отделения бизнес-логики от данных и визуализации или же б) Для масштабируемости решения В данном случае, очевидно автор собирается БЛ оставить на стороне гуйного клиента, но поскольку юзеров мало, то тогда зачем ему сервер приложений (не надо масштабируемости, а БЛ все равно на стороне клиента). Ну а в остальном DimW, я с вами согласен -------------------- Aut viam inveniam aut faciam |
|||
|
||||
COVD |
|
|||
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1655 Регистрация: 26.7.2005 Репутация: 4 Всего: 43 |
Решение вопроса "J2EE - не J2EE"" зависит, на мой взгляд, также от имеющегося опыта. Тем, кто освоил строительство из блоков, врядли будет комфортно класть стены из кирпича. И наоборот.
Можно начать на той технологии, которая лучше освоена. Если проект не умрет, значит скорее всего будет развиваться. И возможно потребуется смена технологии. |
|||
|
||||
DimW |
|
||||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
не совсем так, технологии такие как COM, CORBA, не накладывают технологических ограничений на реализацию клиентского приложения. по этому чем будет выступать клиент, браузевом или десктопным приложением - дело второе.
вы путаете разграничение прав на объекты БД и с реализацие секюрности приложения. у мускула как и многих современных БД есть понятие сесси, в которой как и в случае http сессис сервлет контейнера можно организовать инициализацию объекта(в случае с мускулом - инициализацию глобальных переменных) в которых можно хранить параметры авторизованного, посто эти параметры необходимо передавать в sql который должен выполняться с учетом их значений. ну т.е. если пользователь XXX в системе фигурирует как менеджер компании, то в соответствии с его привелениями приложение должно давать ему доступ только к его клиентам. примерно так:
можно хоть один пример тонкого без сервера и толстого с сервером. в случае с мускулом возможно так и есть, но если взять СУБД такие как oracle, BD2, ms sql, то встроенные языки достаточно эффективны для того что бы реализовывать БЛ именно на стороне БД. |
||||||
|
|||||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Исходя из опыта, и личных наблюдений - это хорошо для систем, которые постоянно дорабатываются, или для создания впечатления постоянной занятости.. ![]() А если серьёзно - это будет требовать постоянного контроля БД, наличия грамотного специалиста, дополнительных ограничений в масштабируемости.. Если серьёзно, мало верю, что так можно будет сделать решение "под ключ", даже простое. -------------------- упс! |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
DimW,
Допустим, нам удалось извлечь из программы имя пользователя и пароль для подключение к БД (в большинстве известных мне случаев - данные для подключения лежат либо в конфигурационном файле, либо имя пользователя и пароль для входа в программу и есть имя пользователя и пароль для доступа к БД) берем какую-нибудь тулзу для работы с БД, подключаемся через нее к серверу MySQL, и кто нам запретит выполнить запрос вида
п.с. Возможно, в новых версиях MySQL и есть варианты защиты, но раньше их точно не было. -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
назовите хоть одну систему уровня предприятия которая не доробатывается? имхо это кросплатформенное явление ![]() что в вашем понимании "контроль БД"? не уж то администрирование? а в случае с реализацией БЛ на сервере приложений отсутствие таковых это норма? ![]() и как же БЛ на стороне БД сказывается на маштабируемости приложения? на этот вопрос обязательно ответьте, уж больно интересно стало ваша вера пропорциональна вашему опыту и наблидениям. Добавлено через 7 минут и 46 секунд Vasay, вы все верно говорите про то, что в случае с десктопом, овладеть не легальным доступом к БД проще чем в случае с сервером приложений. вот только я вам не про то толкую, я ведь про разграничение доступа в приложении, а не про наглое овладевание паролем к БД. ![]() |
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Да банально - не разу не встречался с масштабированием БД на практике - единственный способ повышения производительности был - покупка нового сервака. В свою очередь интересно услышать, какие есть варианты? -------------------- упс! |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
DimW, может я изначально не ясно выражался - но я и имел ввиду именно "наглое овладевание паролем". Который, в случае с десктоп приложением, вполне доступен для "плохого" менеджера, если конечно это приложение общается с БД напрямую, а не через сервер. Кроме того трехзвенная архитектура дает много плюсов в сравнении с двухзвенной. Это сообщение отредактировал(а) Vasay - 10.12.2009, 18:45 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
DimW |
|
||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
так я и думал... serger, маштабируемость и производительность это разные понятия, не вытекающие друг из друга. маштабируемость - это возможность одновременного доступа к данным, чем больше пользователей могут одновременно использовать один и тот же ресурс тем показатель маштабируемости выше. производительность - это показатель за какое время все эти пользователи смогут выполнить тот или иной процесс.
сомниваюсь, что сторона реализации БЛ, была причиной покупки сервера. Добавлено через 11 минут и 17 секунд все ясно было по поводу овладевания паролем - с этим все ясно. просто помимо этого вы упоменули: в связи с этим я и привел пример как это делать в случае с двухзвенкой.
вобщем то да, я сам двухзвенку на дух не переношу - изжила она себя, в корпоративных маштабах. |
||||
|
|||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Спасибо за разъяснение - понял. Честно говоря, теперь не совсем понятно, чем же они всё же различаются в реальной жизни? Именно на уровне БД. -------------------- упс! |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
DimW,
Это я упомянул, как единственный известный мне способ в MySQL защитить данные второго менеджера от первого, если первый подключается к БД напрямую. а не через программу. Ну т.е. у каждого менеджера своя БД со своим паролем и логином ![]() Понятно, что это изврат ![]() п.с. масштабируемость в моем понимании - это то насколько просто увеличить производительность приложения. Т.е. если можно поставить второй сервер, настроить кластер - и все заработает, и даст хороший прирост производительность, то мы имеем отличную масштабируемость. -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
v2v |
|
||||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1620 Регистрация: 20.9.2006 Где: Киев Репутация: 9 Всего: 56 |
кто мешает создать пользователя для доступа к бд , который будет иметь доступ только к конкретно сформированным представлениям. Добавлено @ 19:49
зачем своя бд? просто свой логин\пароль. и данные между пользователями не шарятся.
Это сообщение отредактировал(а) v2v - 10.12.2009, 19:50 |
||||||
|
|||||||
AntonSaburov |
|
|||
![]() Штурман ![]() ![]() ![]() ![]() Профиль Группа: Модератор Сообщений: 5658 Регистрация: 2.7.2002 Где: Санкт-Петербург Репутация: 8 Всего: 118 |
Мы решали проблему доступа на уровне БД за счет того, что ВСЕ данные получались/менялись ТОЛЬКО через хранимые процедуры.
По сути слой бизнес-логики был вынесен в БД на уровен хранимых процедур. До сих пор считаю, что это один из самых эффективных способов для офиса, который не собирается превращаться в два, три и расползаться по всему миру. И никто не собирается получать доступ к данным извне. Как только нужен Интернет-доступ - сразу появится сервер приложений (пусть даже очень просто в виде Томката+Spring). Правда и в этом случае можно сделать доступ через хранимые процедуры. |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
v2v,
Вы правы есть такая возможность (честно - не знал что в MySQL можно устанавливать права на представления) Это вариант, хотя и накладывающий некоторые ограничения на работу с БД -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
DimW |
|
||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
serger, понимаете, каким бы мега маштабированным приложение не было, маштабированней СУБД оно быть не может, ведь механизмы блокировок, формирования rollback сегментов, кеширования используемых данных, и .т.д. - реализованы в СУБД. Не позволят они приложению повлиять на маштабируемость и производительность в лучшею сторону, только в худшую. Vasay, ваше понимание и объективная реальность различаются, может стоит не уператься, а раз и навсегда заполнить этот пробел?!
именно так и поступили, десятки филиалов по всей стране активно работают с системой и преград для расширений мы не видим. ![]() Это сообщение отредактировал(а) DimW - 11.12.2009, 10:26 |
||||
|
|||||
Vasay |
|
||||||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
Ну я бы сказал, мое понимание понятия "масштабируемости" не дальше от объективной реальности чем Ваше ![]()
http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%...%81%D1%82%D1%8C
Это сообщение отредактировал(а) Vasay - 11.12.2009, 12:02 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
||||||
|
|||||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
да наверное Вы правы, первое не исключает второе, правильный выбор СУБД и грамотная разработка БЛ скорее отсрочит потребность в расширении аппаратной платформы, но ни как не исключит ее расширение при бурном развитии функциональности и числа пользователей приложения. ![]() |
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Красиво написано, ![]() Мне интересно, как всё-таки как базы "масштабируются" в реальной жизни. Те как увеличить производительность только за счёт увеличения количества "машин". -------------------- упс! |
|||
|
||||
Vasay |
|
||||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
Большинство современных баз данных позволяют объединить несколько отдельных серверов в кластер. отсюда
Справедливости ради стоит заметить, что не только DB умеют объединятся в кластер но и сервера приложений. -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
||||
|
|||||
v2v |
|
||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1620 Регистрация: 20.9.2006 Где: Киев Репутация: 9 Всего: 56 |
хотел написать про такой вариант, но потом задумался, а на сколько удобно делать выборки через хранимые процедуры? нда, если бизнес логика реализована и выполняется в процедурах дб то это правильно, удобно и довольно быстро, но что если вернуть надо не 1 или 0, а целую таблицу значений? как это у вас было реализовано?
можно. но нужно ли делать лишнюю нагрузку на дб, если есть промежуточный слой который достаточно защищён от клиентов что-бы доверить ему управлять доступом? |
||||
|
|||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
А сами создавали кластера? Меня практика интересует. Точнее впечатления от использования. А не выписки из рекламных брошюр, уж извините. ![]() Сталкивался со смешанной логикой (часть на хп, основная часть в приложении) - честно говоря она меня напрягла. Много повторений. Не ясность какая-то, что на чём реализовывать и тп. Добавлено через 6 минут и 26 секунд Вот, кстати, читаю: NoSQL -------------------- упс! |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
v2v,
AntonSaburov, А как обстоят дела с правами доступа в случае с хранимыми процедурами? Т.е. есть процедура, которая селектит данные из таблицы1 и апдейтит таблицу2. Есть пользователь1 у которго есть доступ к процедуре. Должен ли у пользователя1 быть доступ на селект из таблицы1 и апдейт для таблицы2 ? serger,
Не, сам не создавал ![]() ![]() -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
v2v |
|
||||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1620 Регистрация: 20.9.2006 Где: Киев Репутация: 9 Всего: 56 |
а зря, в какой то мере брошюры отражают суть., и кроме того по ним можно узнать какую именно технологию кластеризации продвигает производитель. по-поводу практики. да, с помощью кластеризации можно значительно увеличить прирост производительности, путём разнесения разных задач на разные машины кластера. например, пользователи у нас получают доступ к данным с помощью сложных запросов через первую машину, а на второй выполняется постоянное обновление и пересчёт новых входных данных из сети. И пользователи довольны, и обновление работает быстро.
в оракле вроде должен. про mysql боюсь соврать, но тоже наверное должен.
должен сказать что большинство проблем можно решить правильной архитектурой базы данных, и не нужны никакие NoSQL. Современные реляционные бд с успехом могут справится с указанными объёмами и шустренько работать с ними. Это сообщение отредактировал(а) v2v - 11.12.2009, 16:56 |
||||||
|
|||||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Спасибо. Нет, ну ПРАВИЛЬНАЯ архитектура решит большинство проблем. Но кто ж её такую делает, да ещё и сразу.. И ещё я всё таки "наивно полагал", что всё-таки система сама должна распределить задачи, между нодами, только успевай их подключать.. ![]() -------------------- упс! |
|||
|
||||
DimW |
|
||||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
если это действительно нужно, то к примеру у оракл есть коллекции, которые могут выступать в качестве OUT параметра, соответственно для их обработки в оракловом jdbc есть возможности.
v2v, не все системы пишутся с чистого листа, есть варианты когда уже существующую системы необходимо адаптировать для трех-звенки, сами понимаете переписывать то что уже работает глупо.
Vasay, вы рассматриваете все немного не стого ракурса. представьте что процедура это бизнес действие, которая в свою очередь на сервере приложений мапится с каким нить URL, на который и дается прово выполнения пользователю приложения. что касается запросов данных в процедурах, то этого делать не обязательно, можно использовать sql для получения данных на форме из resultset. Это сообщение отредактировал(а) DimW - 11.12.2009, 14:22 |
||||||
|
|||||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
А с какого ракурса я должен все рассматривать? Хочу рассматривать 3х и 2х звенную архитектуру с ракурса защиты от несанкционированного доступа. И считаю, что 3х звенка в этом плане предпочтительней. Насчет логика в BD против логики в апликэйшен сервере - тут столько факторов, что спорить по этому поводу бессмысленно. Например: 1. наличие специалистов. 2. стоимость 3. историческая архитектура системы и т.д. Кстати, вопрос стоимости весьма интересен - производительность чего выгодней наращивать в конкретной системе - сервера приложений или сервера DB? -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
DimW |
|
||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
нет, не должен(в случае с оракл).
шансы одинаковые, если кто то овладел паролем, то ему ни что не мешает миновать все уровни и работать с БД на прямую. если говорить о возможности овладивания, то да, в случае с двухзвенкой сделать это гараздо проше. |
||||
|
|||||
v2v |
|
||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1620 Регистрация: 20.9.2006 Где: Киев Репутация: 9 Всего: 56 |
эх. Вы прокоментировали фразу выдернутую из контекста. Я не утверждаю что нельзя обойтись только ХП, но мне кажеться это совсем не удобным. Для каждого запроса надо написать свою обёртку в виде Хп. В 2 раза больше кода. Но это ещё куда не шло, а представьте что вам надо извлечь не 100 записей, а допустим 100К. Одной хваткой вытянуть из базы не удастся, надо реализовывать постраничнкую подкачку: ждбс для запросов предоставляет стандартный понятный механизм, а как быть с процедурами? Опять таки надо накручивать сложную лишнюю логику выборки без которой можна было бы обойтись. Но я полностью поддерживаю хп подход. Бизнес-логику которая обновляет/удаляет/вставляет записи в более чем одну табличку надо выполнять на уровне хп.
да, на практике это оказалось не столь эффективно. |
||||
|
|||||
DimW |
|
||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
так я тоже, поэтому я чуть ниже об этом сказал ![]()
|
||||
|
|||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
Если так, то вместе с возможностью создавать VIEW и назначать права на доступ к ним в теории мы можем обеспечить неплохую защиту данным.
Ну, в случае 3х звенной архитектуры сервер с DB может принимать запросы только с ip апликэйшен сервера. Правда, тут мы имеем другие неприятных моментов связанных с тем, что апп сервер должен иметь доступ ко всей информации с которой он работает, например, нужно не допустить возможность SQL инъекции. Это сообщение отредактировал(а) Vasay - 11.12.2009, 16:53 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Вот видео «Проблемы масштабирования интернет-проектов: когда, как и почему возникают, как с ними бороться».
Там в общих чертах про масштабирование. В принципе почти то что мне хотелось узнать. (мало деталей) http://javatoday.ru/2009/03/siw-2009-video/ -------------------- упс! |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
||||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
господа, а с каких пор наличие в приложении асинхронных запросов к апп серв. стало определять его как - "толстое" приожение? время лекции - [15:50]. досмотрел до середины, на мой взгляд отвратительная лекция, ни о чем... serger, и чем же скажем вот эта статья, хуже этой гoвнo-лекции?!... |
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Ну доклад вводный. Оратор не блеск какой, но мне понравилось. Может многие вещи банальны или спорны, однако от вас я и этого не услышал. ![]() Кстати, если отбросить рекламную составляющую, а чем она плоха? Ну посоветуйте что нить путное тогда.. ![]() -------------------- упс! |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
я не говорил что она плоха, я сказал что она отвратительна в плане академической ценности, просто как это часто бывает - собрали народ потусоваться ![]() к таму же, это моя личная оценка, понравилось, так понравилось... не могу по советывать ничего в плане расширения аппаратных платформ ибо опыт в этом отсутствует. serger, вы пояснить можете, по поводу толщины ПО и ajax, это я туплю? |
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Не помню такого, если честно, я ж тоже не всё внимательно слушал.. Ну часто бывает, что докладчики сбиваются и тп., всякое бывает - сам часто такие перлы выдавал! ![]() -------------------- упс! |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
Вопрос по поводу толщины клиента очень спорный. Если по уму - тонкий клиент, это приложение не обремененное никакой логикой, кроме логики отображения. Впринципе, я не видел чтоб JS выполнял какую-либо логику, кроме отображения, ну, может еще валидацию (но в любом случае она должна быть дублирована на стороне сервера). Другое дело Flash - тут вполне может быть логика не относящаяся к отображению, так браузер загрузивший какое-нибудь flash приложение уже толстый клиент? Или еще тонкий? Добавлено через 7 минут и 49 секунд Хотя если говорить о flash - то браузер тут как бы не причем. Flash может вполне обойтись и без него. Это сообщение отредактировал(а) Vasay - 14.12.2009, 15:49 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Vasay, ну ваше определение, ИМХО, весьма логично.
-------------------- упс! |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
||||
|
||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
В свое время, в документации по Oracle 9I я прочитал "Режим клиент/сервер устарел". В то время это заявление меня это сильно озадачило.
Принятие решения об архитектуре приложения вопрос весьма важный. Заказчик говорит - "У нас всегда будет мало клиентов, мы всегда будем работать в локальной сети". Он обманываться рад. Такие прогнозы как правило не оправдываются. Писать бизнес логику и презентационную логику на ХП, извините меня это решение не только черевато последствиями, но - день вчерашний. БД должна информацию эффективно сохранять и извлекать, а не картинки делать (хотя и может). Попробуйте усложнить такое приложение и выполнить одновременно больше запросов и выяснится, что ваше приложение масштабировать невозможно. Его надо переписывать. Использование Ajax диктует свои права. Валидация на клиенте запросы с клиента информации и ее обработка. Это, извините, и есть толстый, а иногда и претолстый клиент. Я думаю никого не обманывает эвфемизм "rich". После нескольких лет работы с JEE и чтения авторизованных курсов SUN по архитектуре распределенных приложений я для себя решил, что ребята из Oracle правы и теперь, при разработке даже небольших приложений я сначала спрашиваю себя - а не сделать ли его Web приложением, даже если сначала и база данных и сервер приложений будут на одной машине. Это конечно первоначально снизит производительность по сравнению с архитектурой клиент/сервер, но потом ... |
|||
|
||||
DimW |
|
||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
пример последствий, привести можете? mbasil, я вот не пойму - использование хп в веб приложении это экзотика? или это как то не укладывается в архитектуру веб-приложения? или есть трудности в их использовании? почему вы хп и вэб ставите по разные стороны баррикад?
странно вы рассуждаете, как будто при использовании веб приложения запросы выполняются вне БД ![]()
ну давайте подумаем как валидация делает вдруг "клиента толстым "... по скольку вы реализуете БЛ на аппсерве, то логично бы было валидировать что то на том же уровне, т.е. грубо говоря вы пишете сервлет который лезет в БД, что то там берет, потом э то что то вы анализируете в сервлете и возвращаете в качестве ответа ассинхронного запроса(ajax) true или false. и что же в данном случае делает клиента "толстым"? |
||||
|
|||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
Лекцию посмотрел после предыдущего сообщения. По-моему зря вы его так сильно, в грязь.
Оратор из него никудышний, конечно. Про пул подключений толком сказать не мог, как будто это всем понятно. От того и вопрос возник, на который он так же невразумительно ответил. Когда говорил о кэшировании забыл, что на клиенте можно кэшировать помимо куки в объекте JavaScript. По поводу кэширования в базе не знает, что Oracle позволяет кэшировать информацию клиентского сеанса в оперативной памяти. Ясно, что парень работает со специфическими интернет приложениями. Однако дело свое, похоже знает и многие аспекты доклада перекликаются с тем, что предлагает SUN в своих курсах и я с этим согласен. Вообще, будучи сам разработчиком я довольно часто забывал, что архитектура не сколько обязана обеспечивать функциональные требования приложения (это надо делать обязательно, но можно по разному), сколько обязана обеспечить качество работы приложения. масштабируемость, время отклика, общую производительность и т.п. По поводу Ajax еще добавлю. Думаю сам по себе он не обязывает делать толстого клиента, но стимулирует и подталкивает. Еще недавно пуристы JEE говорили - на клиенте только HTML и больше ничего. Я видел недавно одно приложение где всего то была одна страница, а дальше все EXT-GWT. При этом серверная часть только и делала, что пасовала задачи на сервер базы. Крайности всегда отвратительны. Ну вспомните историю. - Сначала у нас были ES, которые делали все, а клиент перфокарты или терминал. - Затем PC и десктоп приложения. - Потом мы с трудом по капле "выдавливали из себя раба" переходили на клиент/сервер (сервер мощный - пусть делает все, вплоть до презентационной логики) - Потом пришло отрезвление, каким бы мощным не был сервер базы данных, возможности его не безграничны. И мы окунулись в распределенные приложения. - Сегодня кластеризация и кэширование стало общим местом. - Что то будет завтра? |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
||||
|
||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
To DimW
Последствия выполнения все на сервере приложений в ХП: - Приложение плохо структурировано (мы же говорим о корпоративных приложениях). Вспомните старую книгу Тейта "Горький вкус Java" - она до сих пор актуальна. - Сервер базы данных вместо эффективной выборки данных и выполнения DML занимается созданием страниц. Были у меня на курсе работники одного банка, в котором начальство вдруг решило, что все филиалы должны работать непосредственно на мощном сервере, который они приобрели. Приложение на ХП просто привело к колапсу сервера. ------- Использовать ХП обязательно надо, но для тех задач, для которых они хорошо подходят. ХП это условно пакетные задачи, которые должны обрабатывать данные непосредственно на сервере базы без пересылки по сети больших объемов и решать специфические задачи. Пример, который считаю характерным - закрытие банковского операционного дня: надо пересчитать остатки по счетам на конец рабочего дня и выполнить ряд других операций за один вызов. Пример отрицательный - один мой слушатель рассказывал, что для разборки больших объемов XML они использовали парсер в виде хранимой процедуры на Java. Результат понятен. ----------- Валидация и не только. Я уже только что писал свое мнение, что Ajax стимулирует переносить часть обработки информации на клиента - не только обработки презентационной логики (это само собой подразумевается), но и части бизнес логики. А что это, как не толстый клиент. Когда нам говорили "на клиенте - только HTML) я полагал, что это долго не продлится. Тенденция сегодняшняя налицо. SUN даже не переписывает курс по шаблонам JEE, так как мы находимся в переходном периоде: часть шаблонов JEE устарела, а новые неоднозначны. ------ Если бы реализации, использующие Ajax работали только так, как вы это описываете, то разумеется говорить о "толстом" клиенте было бы нельзя. Но сегодня все больше работы переносится на клиента. Одни всем известные фреймворки чего стоят (уже упоминавшиеся мной EXT, GWT, Dojo и т.п). Бросьте, если вам эта тенденция не нравится, это не означает, что ее нет. Это сообщение отредактировал(а) mbasil - 16.12.2009, 10:45 |
|||
|
||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
Ну да, в лекции нет технических подробностей, материал преподнесен через призму специалиста, которому ближе Интернет, чем корпоративные приложения, но надо признать - он неплохо очертил необходимость количественного подхода к оценке качества архитектуры распределенных приложений. Мы как разработчики часто забываем о необходимости тестирования под нагрузкой и на репрезентативных данных. Мы больше заботимся о функциональных качествах приложения. Задачи архитектора в другой плоскости. К сожалению в России разделение труда в нашей области плохо приживается. Я даже горжусь, что я сам себе системный аналитик, архитектор, девелопер, кодер, тестировщик и администратор базы данных. Есть такое подозрение, что я что-то делаю плохо. Психология разработчика плохо вяжется, например с психологией архитектора.
|
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Очень понравилось - постоянно себя приходится в связи с этим изменять в течении дня. -------------------- упс! |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
mbasil,
Спасибо за интересные посты, единственное, я все же не согласился бы с тем что Ajax подталкивает нас делать на JS толстого клиента. Современные JS/Ajax фрэймворки даже валидацию выполняют на стороне сервера и вряд ли в ближайшее время начнут выполнять какую-либо логику (кроме логики "рисования"). -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
DimW |
|
||||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
вы случайно не про oracle HTML DB( или как его сейчас - APEX)? ![]() mbasil, мы говорим видимо о разных вещах - вы, как можно, а я как нужно. ведь ни кто насильно не заставляет вас, формирование интерфейсов выносить на уровень БД, пусть этим занимается сервер приложений. по этому утверждение что ХП это плохо в данном контексте - не верно.
да, то что не запрещено, то можно. ![]()
если вам за каждый этот скил платят, то гордиться есть чем, если нет то стыдно должно быть, вам и вашему руководителю. наша российская действительность как раз и диктует ту позицию за которую гордится не стоит. ![]() Это сообщение отредактировал(а) DimW - 16.12.2009, 11:57 |
||||||
|
|||||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
Ну я вовсе не говорил, ХП это плохо - с большим удовольствием их использую, так как с 94 года работаю с Oracle, а там без этого - никуда. Я лишь хотел подчеркнуть, что при разработке современных приложений уровня предприятия (пусть и небольшого) следует соблюдать правильный баланс между назначением узлов и действиями этими узлами выполняемыми - разделение труда должно быть четкое не только между людьми, но и между узлами распределенного приложения.
To Vasay Утверждение
во второй части кажется весьма сомнительным. Я не утверждаю, что стремление к "rich" клиенту приведет к "толстому" в плане возврата к старым временам клиенту. Я полагаю, что судя по тому, что происходит сейчас, похоже клиент перестает быть столь "тонким", как это было до недавнего времени. И баланс нагрузки в web приложениях будет частично перераспределяться на клиента. Мне кажется, что тенденция налицо. Впрочем, может я и ошибаюсь Когда наш руководитель в силу обстоятельств заставил меня, разработчика, проводить авторизованные курсы по администрированию Oracle, я в течении года испытывал непрерывное чувство стыда. Теперь я провожу курсы по администрированию без особого напряжения, но знаю, что никогда не буду хорошим администратором. А не далее как на прошлой неделе местное подразделение SUN доверило мне прочитать курсы по шаблонам и архитектуре. Так как курсы прошли относительно удачно (клиент в основном доволен), то чего это я должен стыдится? Обстоятельства так сложились. |
|||
|
||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
На самом деле то, что мы работаем многостаночниками проблема не наша, а руководителей. IT специалисты у нас хороши а руководители, увы... Традиция.
Это сообщение отредактировал(а) mbasil - 16.12.2009, 13:22 |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
mbasil,
Если говорить про Ajax/js, то с распределением нагрузки на клиента я, все же, не согласен Раньше пользователь получил статичный html и пока он не заполнит формочки, не нажмет кнопку, сервер ничего не делает. После нажатия кнопки сабмита формы - сервер начинает Валидировать поля, делать какие-то операции с данными, писать их в базу. А что мы имеем с Ajax интерфейсом? Пользователь получил форму, начал заполнять, допустим, форму поиска - а ему тут же варианты с сервера подгружаются, или ввел имя пользователя на форме регистрации - тут же пошел запрос на сервер - проверять не зарегистрирован ли пользователь с таким именем уже.... При этом когда пользователь нажмет кнопку - все равно нужно будет провести повторную валидацию, и все те действия, которые выполнялись бы и без ajax. Т.е. никакого распределения нагрузки нет - логики стало больше, но она осталась на сервере. -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
Ну, может я сам себя убедил в этом тезисе.
Недавно "наковырял" для упраженения формочку, где клиент в HTML форме пишет параметры запроса (со всякими там больше, меньше или LIKE), жмет кнопку, а сервер ему возвращает результаты, которые тут же можно перелистать и исправить, а результаты приходят в виде JSON массива. Кроме того, я уже говорил, что однажды встретил небольшое приложение, где вся основная работа выполнялась в JavaScript. Мне это откровенно не нравится, но кое-где имеет место. А с другой стороны в книгах "Ajax на практике" и "Ajax в действии", в которых рассказывается про использование фреймворка DWR, позволяющего стряпать клиента Web службы на JavaScript. Как вам такой компот, я всегда полагал, что клиент Web службы это прерогатива толстого клиента. Или нет? |
|||
|
||||
COVD |
|
|||
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1655 Регистрация: 26.7.2005 Репутация: 4 Всего: 43 |
mbasil,
![]() (только, наверное, ЕС, а не ES ![]()
Возможность или необходимость быть "многостаночником" делает, на мой взгляд, работу интересной. А мечтой "хорошего" руководителя является налаживание сборочного конвейера. |
|||
|
||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
И еще надо добавить нагрузка на приложение в презентационной части увеличивается, так как пользователь избалован Интернетом. Хочу контента и красот ! Просто статические страницы ему недостаточны. Волей неволей появляются новые фреймворки и Java Script библиотеки, которые обещают много в ответ на возрастающие потребности. Только не говорите, что эти потребности никогда не коснутся корпоративных приложений.
|
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
размазано как то получилось, давайте по существу на конкретном примере, если не утамил еще... ![]() вот я, всю логику реализую на уровне БД которая в свою очередь мапится с конкретным URL на аппсерве, за формирование интерфейса отвечает сервер приложений. что в данном случае нужно балансировать? на что стоит обратить внимание? какие есть потенциальные неприятности в плане потери произвадительности по отношению к ситуации когда БЛ реализована на аппсерве? mbasil, как вы считаете, почему такой подход вызывает не доверие, боязнь(может быть), не понимание у многих разработчиков? ну и вообще есть ли такая проблема, может я параноик? ![]() |
|||
|
||||
Vasay |
|
||||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
mbasil,
DWR все же клиент-серверная технология. Логика там остается на стороне сервера.
Интернет то как-раз не балует. Требование соответствия URL контенту делает неприемлемыми, для создания сайтов, большинство фрэймворков. Так что их создают для корпоративного применения. -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
||||
|
|||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
To DimW
При реализации БЛ на сервере приложений ваше приложение легко масштабировать в "ширину" и в "высоту", например добавлением кластеров серверов приложений и балансированием их загрузки. При размещении БЛ на сервере базы данных в ХП, при повышении количества пользователей: - Вы можете масштабировать только в высоту, то есть, грубо говоря только покупкой более мощных машин для сервера базы данных. Сервер базы данных занимается работой, которая для него является побочной. Трудно настраивать на сервере базы данных, какой процент мощности он должен направлять на выполнение SQL, а какой на выполнение отдельных ХП. - При усложнении БЛ вам без специальных ухищрений не уследить структурой БЛ. - Одна из идей EJB заключается в том, что сервер приложений сам следит за загрузкой компонентов и управляет ею по ситуации. См. пул сеансовых компонентов без сохранения состояния и компонентов управляемых сообщениями, а также пассивирование и активирование сеансовых компонентов с сохранением состояния. Не зря большинство шаблонов проектирования JEE направлено на поддержку четкой структуры приложения. Такой подход делает архитектуру приложения максимально гибкой, все время поддерживая решение потенциальных запросов на рост масштаба. Если приложение не слишком велико и расти не будет - ну и пишите на здоровье с использованием БЛ на ХП. Если заметите множество решений JEE направлено на строжайшую экономию ресурсов и тонкое управление оными ресурсами. Примеры - использование HTTP протокола, пулов подключений к базе данных, управление кэшами различных уровней и т.п. Используя БЛ в ХП вы сами себя ограничиваете в этой части. Дай бог, чтобы вы это делали осознанно, в силу специфики вашего приложения, а не потому просто, что вам это "нравится" или просто привычно. Я честно говоря "наелся" тех случаев, когда говорят у нас будет 50 пользователей и не больше, база данных будет маленькой, а в Интернет мы никогда не выйдем. И никогда подобные провозглашения будущего не сбываются. Когда-то было время, читая курсы работникам сбербанка заикнулся про web приложение. Они подняли меня на смех - "У нас Интернет киоски, физически отрезанные от основной сети. Мы НИКОГДА не будем работать в глобальной сети." Теперь они усердно пишут под ВебСферу IBM и усердно изучают Java. Рекомендую еще раз послушать того парня, о котором мы говорили выше. Многое из того, что он говорит по части архитектурных решений перекликается с тем, что рекомендует SUN. Это сообщение отредактировал(а) mbasil - 16.12.2009, 18:33 |
|||
|
||||
DimW |
|
||||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
прежде чем буду дальше писать, еще раз напомню свою позицию. я не против ХП, я не против размешения БЛ на сервере приложений.
просто пытаюсь понять почему высказывания в сторону БЛ в БД такие как (ниже) имеют место быть? дайте хоть ссылки на то где об этом написано. я тоже могу сказать что приложение можно маштабировать ТОЛЬКО в "ширину" и что?
побочной ![]()
ну и как по вашему понять какая реализация побочнее другой для конкретного уровня? да ни как, все относительно. идем дальше - по поводу расширения аппаратной платформы в ту или иную сторону. возьмем два приложения, которые реализуют БЛ которую я показал выше, каждое на своем уровне. в каждом из приложений работают 100, пользователей одновременно. аппаратные платформы были выбраны с учетом максимального числа пользователей = 200. случилось так, что кол-во пользователей в течении недели долно прирости до 1000. mbasil, что делаем, что расширяем? в одном случае одну сторону в другом другую? ![]() к чему я клоню: вы считаете, что реализация БЛ на уровне аппсерва даст вам мифическую надежду на простое и разумное расширения платформы(только не надо говорить что вы имели ввиду что то другое). увеличив мощности на сервере приложений вы всего лишь позволите большему числу пользователей одновременно воспользоваться API которое добавляет нового клиента, сам же оператор INSERT выполняется на стороне БД, таким образом вся ваша маштабность на одной стороне закончилась, как только обработчик покинул уровень приложения. быть может не стоит колотить себя в грудь и декларировать все то что презентует SUN, как не оправержимую истину?! у оракла тоже много технологий высасанных из пальца(HTML DB, APEX, XSQL), которые он активно продвигает и поддерживает, и ими пользуются, и точно так же в презенташках пишут о выгоде с одного ракурса - удобного для них. вобщем я по прежнему не в понятках, чем же один подход предпочтительней другова, имхо голову включать нужно при любой архитектуре, а сама технология за вас приложение маштабней и производительней не сделает. и всеравно спасибо за попытку объяснить. ![]() |
||||||
|
|||||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Смысл данного примера, аналогичен ощупыванию слепцами слона, из известной притчи. ![]() -------------------- упс! |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
serger, вы считаете что этот пример не достаточно сложный для того что бы его рассматривать? придумайте свой, и попробуйте объяснить себе и нам, где эта грань побочности. по каким критериям можно судить о пренадлежности реализации логики на той или иной стороне? |
|||
|
||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
DimW
1. Из вашего примера выходит, что вся бизнес логика приложения заключается исключительно в запросах и DML операциях, а также в минимальных проверках. Очевидно, что таких процедур у вас немного. Впрочем, даже в этом случае есть смысл воспользоваться пакетами. Однако PL/SQL пакет, каков бы он ни был хорош (люблю, черт возьми, вместе с разработчиками Oracle использовать PL/SQL пакеты), не предлагает структуры более высокого уровня. Дальше все - россыпь однородных объектов (пакетов). При большом количестве разбирайся, как хочешь. Нет структуры более высокого уровня, а значит она вам не нужна. Поздравляю: либо ваше приложение невелико, либо вы - гений. 2. Отказ от объектного подхода при реализации бизнес логики говорит о том, что она либо очень проста, либо не требует внесения регулярных изменений и дополнений. Вы конечно можете воспользоваться объектными типами PL/SQL, но мы то с вами знаем, что это за бодяга. Вы даже можете писать бизнес логику на сервере на Java. Правда под каждый класс надо ваять PL/SQL заглушки - Славно придумали ребята ! 3. Кроме того, в некоторых приложениях требуется кэшировать информацию сеанса. Есть положение не мной придуманное (не буду опять ссылаться на известно кого, чтобы вас не раздражать), что информацию надо кэшировать ближе к тому слою, в котором она используется. И наверное, при размещении бизнес логики в ХП приходится хранить ее кэш в презентационной части. Что, как следствие, приводит к тесному связыванию бизнес логики с презентационной (tight couple). Более предпочтительным считается подход loose couple. Сами понимаете, почему. 4. Мы же говорили о масштабировании. То есть о потенциальном росте нагрузки. Подумайте, что проще кластеризовать, сервер приложений или сервер базы данных и что будет стоить дороже. В итоге мы с вами останемся каждый при своем мнении. Не страшно. Главное, что наша перепалка дала пищу для размышления тем, кто только начинает писать и может быть не имеет возможности построить RAC Oracle только для того, что запихнуть на него бизнес логику приложения. Полагаю, что дальнейший обмен колкостями смысла не имеет. |
|||
|
||||
COVD |
|
|||
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1655 Регистрация: 26.7.2005 Репутация: 4 Всего: 43 |
XП (хранимые процедуры) удобны тем, что это скрипт: внес изменения - и они сразу вступили в силу после сохранения. Но редактировать их неудобно. Вот циклы для XП - выглядят "побочными" операцими. Всякие разветвленные if-else тоже.
А редактировать, например, на Java - удобно. ХП хороши, когда надо совершить, например, действие над несколькими таблицами. Интуитивно ясно, что правильнее это доверить механизму базы данных (т.е. ХП), нежели "дергать" таблицы во внешнее приложение. Это сообщение отредактировал(а) COVD - 17.12.2009, 14:28 |
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
Бизнес приложение состоит из большого количества кусочков с разным функционалом, в том числе и таких. Ну и с различной степенью связанности м/у с собой. Я не считаю, что пример плохой, я говорю, что он объясняет только "какой у слона хобот", но соответственно мы не можем из этого примера узнать, какие у слона, например, ноги. И отсюда, даже приведя кучу примеров компонентов, мы только в комплексе сможем решить, как лучше реализовать их взаимодействие, что, опять таки, для бизнес-приложений не реально. -------------------- упс! |
|||
|
||||
DimW |
|
||||||||||||||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
я бы согласился с вами, но не могу сдержаться, прокоментирую некоторые ваши реплики. такое чувство что вы даже не попытались сделать шаг к тому что понять меня. :( по 1.
да, не следует этого из моего примера, это общий случай, в 90% БЛ это манипуляция данными с учетом правил, которые накладывает бизнес процесс. и обсолютно не важно, простая валидация используется или сложная, простой DML, или сподвывертом, два DML оператора или один. в конце концов это не важно, для конечного использования бизнес единицы, пусть это будет процедура, пусть она будет в пакете, пусть это метод в классе на другом уровне.
пакет->процедуры(функции) - однородные объекты ![]() класс->методы - ну пипец какое разнообразие ![]() если нет четкого описания бизнес действие ---> объект_исполнитель(не важно какого уровня), то надеятся на успешный проект не стоит. к счастью такие средства(CASE) есть. по 2. опять вы про то как "можно"... по 3.
ну так ничего и не мешает, кеширование результата, на БЛ оказывать влияние не может, так что нужно кеширование- реализовывайте, не нужно так не нужно... по 4.
mbasil, я ведь не зря на пинок нарывался:
думал вы как то подтвердите или оправергните мое умозаключение, не могу я оценить что будет дешевле и проше, нет такова опыта, в отличие от вас. от того и общаюсь с вами на эту тему, что бы наконец это понимание у меня было. если у вас еще осталось желание, то прошу прокомментировать 4 пункт, прав я или нет. спасибо. Добавлено через 12 минут и 9 секунд
и тем самым "разваливает" все зависипые объекты, и все сессис из пула твердят что "состояние пакетов было сброшено" ![]()
COVD, serger, согласитесь, что размазывать БЛ по нескольким уровням из за удобства это тоже не есть гуд. |
||||||||||||||||
|
|||||||||||||||||
DimW |
|
||||||||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
to all:
вы занаете, я наверное сам виноват в вашем недопонимании, я не привел ни одного примера, как я вижу разработку веб приложений с использованием ХП. рассмотрим один из модулей системы, которую я разрабатываю и поддерживаю. скрин модуля в приложенном файле. и так: 1) MVC(в моем случае jsp)
затем сама формачка в которой редактируются значения:
затем мапинг MVC с ХП по адресу - /jdbf-admin.sys_pk_security.modify_application_unit.jdbf (функция яваскрипт doSave())
и сама ХП:
опять же БЛ не блещет сложностью, но подход думаю понятен. кто нить может оценить данный подход в плане перспективы использования? Присоединённый файл ( Кол-во скачиваний: 21 ) ![]() |
||||||||
|
|||||||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
очень провокационная фраза.. Еле сдерживаюсь... ![]() В общем, мой опыт смешения был не очень удачный, однако не могу ничего утверждать... Как раз и хотелось бы понять... И, кстати, вашу позицию, я как-то до сих пор не могу уловить. ![]() -------------------- упс! |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
||||
|
||||
COVD |
|
||||
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1655 Регистрация: 26.7.2005 Репутация: 4 Всего: 43 |
И не надо "размазывать". Если на серверной стороне кроме базы данных есть более высокий слой, то пресловутая бизнессссс логика должна быть там. А в хранимых процедурах - специфические, внутренние для базы данных операции, которые не относятся к БЛ.
Так если процедура работает неправильно и требует срочного исправления, все равно это наверное лучше, чем перезапускать базу данных. Это сообщение отредактировал(а) COVD - 17.12.2009, 16:52 |
||||
|
|||||
mbasil |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 399 Регистрация: 4.5.2007 Где: Москва Репутация: 9 Всего: 13 |
Многое зависит от типа вашей системы. Это транзакционная (OLTP) система или система больше ориентированная на получение и просмотр информации (Dcision Support System).
Я полагаю, что бизнес логика даже в случае OLTP поровну содержит запросы и DML предложения. Причем выполнение DML предложения проще (без учета сложности управления транзакциями), чем работа с разнообразными запросами, которые в том числе требуют и того или иного кэширования результатов на сервере приложений. Не забывайте, что если вы используете JPA, например с Hibernate, то контекст постоянства также является кэшем первого уровня. Таким образом (я полагаю), что при возрастании количества пользователей и достаточно сложной бизнес логике (даже в OLTP системе), нагрузка будет больше увеличиваться на стороне бизнес логики, чем на стороне базы данных. Особенно в том случае, если вы обеспечите грамотное кэширование информации на разных уровнях. Однако даже если работа большей частью связана с обработкой SQL предложений, есть смысл выносить бизнес логику с уровня базы данных, хотя это и в какой то степени увеличит время обслуживания одного запроса. Все узлы распределенного приложения должны (по возможности) иметь запас мощности. Когда один из узлов перегружен никакой запас мощности на других узлах не позволит обеспечить нужное качество обслуживания). Да, обычно сервер базы данных более мощный, чем остальные узлы. Но если вы его перегрузите и нет возможности его сделать мощнее (по затратам или в силу ограничений железа), вы столкнетесь с проблемой отсутствия гибкости приложения, с невозможностью продублировать бизнес логику на кластере серверов приложения. Если представить запросы пользователей как некоторую суету внутри сети из узлов, то при правильно спроектированной сети суета должна уменьшаться с удалением от точки входа. А база данных стоит дальше всего. Ее основное назначение в системе - обеспечивать постоянство, а не суетиться на каждый чих пользователя. |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
mbasil, спасибо, в принцыпе все понятно.
видимо мне просто все это еще предстоит переварить, но зная себя - пока не споткнусь не пойму(не поверю). было бы проще если бы я на данный момент не имел опыта, был начинающим программистом, но блин мы в четыре рыла(+ 8-10 аналитиков по 1-2 человека на предметрую область) поддерживали систему(толстую) которая охватывала все предметные обрасти предприятия, была сложнейшая логика написанная на pl/sql, работа была организованна таким образом что это было делать просто. сейчас поддерживаем систему (веб) с одной предметной областью, гемороя огребаем по самые нехочу... наследие индусов... ![]() невольно возникает вопрос, так в чем же проблема в архитектуре или в организации труда(подходе, отношении к своему делу)!? по поводу этого - http://forum.vingrad.ru/index.php?showtopi...t&p=2049640 ничего сказать не хотите? не обязательно, но хотелось бы получить мнение человека который разрабатывал как на уровне БД так и на уровне приложения. спасибо. |
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
DimW, очень напоминает систему построения отчётов...
-------------------- упс! |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
система на оборот транзакционная, я показал один из модулей этой системы, а именно как эти самые модули я описываю на аппсерве и как осушествляется доступ(вызов) БЛ на стороне БД. роли аппсерва в этом случае отводится только доступ к данным и их представлению втом или ином виде пользователю(см. скрин), т.е. пользовательские теги отвечают за генерацию html, а доступ к БЛ в БД мапируется для конкретного урла. в данном случае ХП - sys_pk_security.modify_application_unit доступна по урлу - "<%=request.getContextPath()%>/jdbf-admin.sys_pk_security.modify_application_unit.jdbf", который представлен ввиде экшена - /jdbf-admin.sys_pk_security.modify_application_unit. Это сообщение отредактировал(а) DimW - 18.12.2009, 13:08 |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
DimW,
А где MVC? (jsp не может быть - MVC, jsp предназначен для "View") Я вижу только что-то похожее на "View", в котором что-то делает
который должен быть в "Model", а не посреди тэгов отвечающих за рисование интерфейса. Это сообщение отредактировал(а) Vasay - 18.12.2009, 13:20 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
DimW, а в jsp условия, циклы как реализуются?
-------------------- упс! |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
Vasay, в данном случае jsp представлено как MV, не спорю что это криво, в ближайшее время планируется вынемти это недоразумение за пределы jsp, в свое оправдание могу объяснить это как издержки неопытности, в то время когда этот тег реализовывался
![]() будет примерно так:
serger, вы имеете ввиду как у меня это реализовано, если да, то ни как, т.е. каждый тег является закончинным компонентом который служит для конкретных целей, все операции по генерации html вынесены в обработчик пользовательского тега. |
|||
|
||||
serger |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 518 Регистрация: 19.6.2007 Где: Ижевск Репутация: 2 Всего: 5 |
А динамические запросы как строятся, а видимость элементов HTML как контролируется?
В общем, всё равно не до конца понятно. Сомневаюсь, что сможете на пальцах раскрыть детали. Трудно воспринимается, так как ОЧЕНЬ уж все непривычно. ![]() Думаю, такое сравнивать бесполезно - время покажет... -------------------- упс! |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
их попросту нет. путем выдачи определенных приверегий пользователю системы к примеру кнопка:
если пользователю выдана привеления на объект доступа aceessApplicationUnitAdd то от ее увидет. надеюсь что я окажусь прав, как и вы. ![]() |
|||
|
||||
Vasay |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 18 Всего: 73 |
DimW,
Может я просто не понял Вашу идею, но как-то мне не нравится :-( Я бы сделал так: (Снизу вверх, упрощенная версия ) классы сущностный (Entity) - pojo классы для представления данных из DB в программе. классы доступа к данным (DAO) - в этих классах осуществляется вся работа с бд. Т.е. есть у Вас класс UnitDAO, у него есть методы: getUnitList(.....) - возвращает список Unit , может иметь несколько реализаций (без параметров - весь список, с параметрами типа max и first) getUnitById(long id) deliteUnitById(long id) saveUnit(Unit unit) .... и тд - вообщем все операции, которые Вам могут потребоваться. Есть контроллер, конкретная реализация будет зависеть от фрэймворка и конкретной задачи. Например, для стандартных CRUD операций можно сделать UnitController c методами list() show() edit() delite() create() save() соответственно, определенный метод вызывается в соответствии с определенным URL (например, можно формировать url таким образом: http://site.com/unit/list?max=10&first=20 - мы просим вызвать метод list() UnitController-а и говорим - покажи 10 результатов начиная с 20-го) UnitController запрашивает в UnitDAO метод getUnitList(10,20); получает список из 10 Unit-ов (в упрощенном варианте, в реальном приложении желательно иметь промежуточный класс) и скармливает его шаблонизатору (шаблонизатор - тот же jsp, velocity, freemarker....) Это сообщение отредактировал(а) Vasay - 18.12.2009, 15:47 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
DimW |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 3 Всего: 44 |
всем спасибо, лично для меня данное обсуждение очень полезно.
есть над чем задуматься!!! ![]() буду надеяться что я тоже прав, поскольку в ближайшее время пересмотреть архитектуру проекта не реально. время покажет ![]() |
|||
|
||||
![]() ![]() ![]() |
Правила форума "Java" | |
|
Если Вам помогли, и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, LSD, AntonSaburov, powerOn, tux. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Java EE (J2EE) и Spring | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |