|
|
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Краткое описание задачи: Назначение: Учет сбыта электроэнергии (физ.лица и юр.лица),биллинг, отслеживание состояний оборудования, договоры и т.п. Клиентов (роли разные 6-7 типов ролей): до 10 000, 99% удаленные клиенты Железо: только x86, однако скупиться не будут, купят мощняцкие ОС: только какой-нибудь из UNIX (скорее и Linux и ЛюбойBSD) БД: любая кроме MS SQL и FireBird Каналы: в лучшем случае 256Kbit, в подавляющем большинстве модемные соединения, либо 64/128 на одного клиента. Интерфейс клиента: web ВОПРОС: какую технологию использовать в качестве ОПТИМАЛЬНОЙ для сервера приложений? Нам советуют использовать JBoss и Tomcat.Некий чел упомянул WebSphere в связке DB/2, однако другой чел поднял его на смех и сказал, что на указанном железе и думать нечего, нужно только от IBM и не x86. Я не имею опыта в этих сферах.Я работал только с MS продуктами. Есть команда разработчиков и у них почти сложилось понимание, НО! я хочу иметь собственной мнение. Кто имел опыт подобных разработок - поделитесь советом...Заранее благодарен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 11:37 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторВОПРОС: какую технологию использовать в качестве ОПТИМАЛЬНОЙ для сервера приложений? ответьте на вопрос самому себе - а он действительо нужен- апп. сервер? авторБД: любая кроме MS SQL... С чего бы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 15:45 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Что Вы понимаете под сервером приложений? Например, считаете ли Вы Веб-сервер сервером приложений? Имелось ввиду, наверное, не MS SQL, а MySQL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 15:52 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Имеется в виду именно MS SQL по причинам указанным выше: ОС - Unix 2BrokenPot: а шут его знает, уважаемый...теоретически - да, сервер приложений...веб приложений...а практически? затрудняюсь сказать э-ма кабы знать точно что такое сервер приложений? точные критерии где? что такое sql server - знаю, что такое application server - знаю слишком много общего...значит ни фига не знаю... Иван Васильевич: "Казань брал...Шпака не брал" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 16:13 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
В принципе конечно же можно и MS SQL (все равно на разных машинах работать будут), но смущает возникновение некоторой, как бы мягче выразиться, неодроности среды...говоря техническим языком - гетерогенности, прости Господи.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 16:16 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Ничего не понимаю... авторИмеется в виду именно MS SQL по причинам указанным выше: ОС - Unix и авторпринципе конечно же можно и MS SQL (все равно на разных машинах работать будут), Простите, кто на ком стоял?! ((с) Проф. Преображенский) авторчто такое сервер приложений? ... что такое application server - знаю Да Вы прям, Сократ, батенька... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 16:23 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinНичего не понимаю... авторИмеется в виду именно MS SQL по причинам указанным выше: ОС - Unix и авторпринципе конечно же можно и MS SQL (все равно на разных машинах работать будут), Простите, кто на ком стоял?! ((с) Проф. Преображенский) авторчто такое сервер приложений? ... что такое application server - знаю Да Вы прям, Сократ, батенька... Вы мне льстите прям таки :D ну ладно б еще Гераклит какой-нибудь... на самом деле написал просто убого! спешка...в любом случае рад, что повеселил почтеннейшую публику. Имеется в виду: что такое application server - знаю слишком много общих вещей, стало быть ничего конкретного. Практически не использовал в отличие от серверов БД. Далее. Можно использовать MS SQL на отдельной машине с Windows Server, но как я указывал выше возникает неоднородность среды, ибо первоначальная задумка - сервер приложений вместе с БД сервером находятся на одной мощной машине под управлением Unix... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 16:41 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторИмеется в виду: что такое application server - знаю слишком много общих вещей, стало быть ничего конкретного. Практически не использовал в отличие от серверов БД. Тогда, м.б. ну ее нафиг, эту задумку: автор сервер приложений вместе с БД сервером находятся на одной мощной машине под управлением Unix ... ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 16:44 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Сорри, рука дрогнула. Т.е. перефразируя вопрос. Зачем Вам сервер приложений и именно под юникс? Какими требованиями навеяна эта задумка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 16:45 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Дык, возвращаю к своему первому посту: спецы уговаривают! а я должен свое понимание иметь! Мотивируют тем, что ЭФФЕКТИВНЫЙ и БЕЗОПАСНЫЙ веб доступ для такого количества клиентов - 10000 (см. пост) без app.server не обеспечить! мол еще и логику развивать удобнее рисуя ява классы, нежели работая непосредственно с ХП на сервере БД. Я-то как раз логику всегда реализовывал на сервере БД, но меня убеждают, что сей подход является нынче сермяжным и кондовым...и такое количество коннектов не выдержит! Вот и прошу совета добрых людей... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 16:51 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSКлиентов (роли разные 6-7 типов ролей): до 10 000, 99% удаленные клиенты Это откуда столько клиентов? Всю страну хотите окучить? :)) Зачем апп-сервер? Кто-нибудь из вашей команды вообще понимает, о чем речь, или просто хочется попробовать поизучать, а потом плюнуть (как всегда)? -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 16:52 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторМотивируют тем, что ЭФФЕКТИВНЫЙ и БЕЗОПАСНЫЙ веб доступ для такого количества клиентов - 10000 (см. пост) без app.server не обеспечить! мол еще и логику развивать удобнее рисуя ява классы, нежели работая непосредственно с ХП на сервере БД. Либо кто-то нас тут разводит, либо плюньте в тех, кто так вам сказал :)) Так все же, что это за "клиенты"? -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 16:55 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторДык, возвращаю к своему первому посту: спецы уговаривают! Огласите компанию в которой эти спецы работают. авторМотивируют тем, что ЭФФЕКТИВНЫЙ и БЕЗОПАСНЫЙ веб доступ для такого количества клиентов - 10000 (см. пост) без app.server не обеспечить! М.б. просто эти "специ" не знают, как это сделать без app.server? автормол еще и логику развивать удобнее рисуя ява классы, нежели работая непосредственно с ХП на сервере БД. Старая песня о главном. Поинтересуйтесь у них, о работающих решениях и послушайте отзывы клиентов. авторЯ-то как раз логику всегда реализовывал на сервере БД, но меня убеждают, что сей подход является нынче сермяжным и кондовым...и такое количество коннектов не выдержит! Ага... Счас... Сервер СУБД он не выдержит, а вот апп. сервер - это совсем другое дело. Гы... ЗЫ. У Вас будет одновременно 10 000 активных сессий? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 16:59 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Количество клиентов для меня тоже сомнительно...но разаработчики предлагают из корпоративной системы вырастить...как бы это выразится...сервис для: - коммунальщиков - тепловиков - расчетных центров муниципалитетов - хрен знает еще кого... посттепенно наращивая мощности, но для этого непременно нужен аппсервер! твердят мне все. Они твердят, а решать - мне! я плохо знаю оракл, но неужто нельзя оюойтись одним мщным сервером БД с привинченным веб сервером? но мне надо понимание...в чем необходимость аппсервера для таких крупных решений? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:00 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторЕсть команда разработчиков и у них почти сложилось понимание Ну если по-правильному, то систему такого уровня надо выбирать в тендере, и "написать" - будет только один из игроков. Ибо риски высочайшие, рискуете получить ЕГАИС ;) А если в тендере выигравшая команда определится, то там в ее требованиях и будет написано, что им нужно в качестве платформы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:02 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
2tygra Да какая разводка, уважаемый! сам в холодном поту! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:03 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторно неужто нельзя оюойтись одним мщным сервером БД с привинченным веб сервером? Для того, чтоб точно ответить на этот вопрос, нужно чуть больше детальной информации, чем авторНазначение: Учет сбыта электроэнергии (физ.лица и юр.лица),биллинг, отслеживание состояний оборудования, договоры и т.п. Клиентов (роли разные 6-7 типов ролей): до 10 000, 99% удаленные клиенты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:09 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
чтобы объявить тендер нужно самому не быть лохом! и хоть чуть соображать на что тебя толкают... Сам не хочу никаких усложнений. По мне бы БД да апач...,но вдруг и правда утонем ХП по мере роста системы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:10 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
если вы не тех. специалист то нужно как-то на нетехнические вопросы обратить внимание. Доверие вашим советчикам: у них есть есть опыт разработки подобных систем? Если есть то делайте как они говорят. Если нет то и смысла на их слова обращать внимания нет, отвечать-то не они будут. Найдите тех кто подобные системы делал и разговаривайте с ними. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:12 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Сервер БД и сервер приложений ВСЕГДА лучше расположить на разных машинах. Чтобы нагрузку распределить. 10 000 одновременно подконнекченных НЕ БУДЕТ НИКОГДА. И почему, собственно, юникс лучше, если клиентов - много? На юниксе тоже можно безграмотно сделать... Ну, а сервер приложений, конечно, нужен. Ведь не будете же вы каждому из предполагаемых 10 000 инсталлировать приложение. Ну и, наконец, веб-сервер - имхо, как раз для этой цели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:14 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
вот...пытаюсь найти... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:14 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
ну 10 000 конечно они загибают - не вырастет система до такого уровня...но несколько (3-5) тысяч точно будет. 2BrokenPot Так значит все же сервер приложений нужен? вернемся к первому моему посту: какой? можно обойтись веб сервером? можно обойтись без явы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:17 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторно несколько (3-5) тысяч точно будет. Еще раз спрощу. Активных одновременно сколько будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:19 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
активных пользователей - не менее 2500 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:20 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSДа какая разводка, уважаемый! сам в холодном поту! А это мы ща проверим: 0. Россия? 1. чем фиребёрд не угодил? 2. город, область? 3. для бытовых абонентов 10к - это смешно, для юрлиц - это очень дофига. Кого больше будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:21 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Учет электроэнергии производится либо по городу, либо по району области. По стране - не производится. :) В Киеве - ~1 000 000 абонентов-потребителей электроэнергии. Предполагается, что ваше приложение будет обслуживать каждого из них? Прикиньте, какая доля бытовых потребителей имеет инет, какая доля из них будет пользоваться вашим сайтом и для чего? Может, и получится две тысячи... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:26 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
В нашем городе бытовые потребители не ходят на сайт биллинговой системы учета электроэнергии по причине отсутствия таковой :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:27 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Виноват: ТАКОВОГО. Сайт отсутствует, а биллинговая система, конечно же, есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:28 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSактивных пользователей - не менее 2500 Врешь, музыкант! Я понимаю, ежели бы реал-тайм биллинг был... но 2500 активных веб-пользователей... что они делают все одновременно и постоянно такое? Договоры заключают, показания вбивают ежечасно? Враки всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:28 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Dried Gagarin GeenSДа какая разводка, уважаемый! сам в холодном поту! А это мы ща проверим: 0. Россия? 1. чем фиребёрд не угодил? 2. город, область? 3. для бытовых абонентов 10к - это смешно, для юрлиц - это очень дофига. Кого больше будет? Да че тут проверять? 0.Россия конечно 1.Всем не угодил! когда-то на нем кое что приходилось делать - сложилось твердое негативное мнение (вру, не на нем, а на его предке интербейзе) - как корпоративный сервер, ни к черту не годится, рядом с тем же MSSQL и рядом не стоял...и не уговаривайте - не уговорюсь! 2.А вот это - не скажу. Почему? по кочану... 3.Неправильно поняли: не десять тысяч бытовых абонентов...а 10000 точек обслуживания суть рабочих мест, причем и бытовые и юр лица в одной БД. 10 000 (ну загибают конечно! не будет столько! я им сразу сказал). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:28 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
BrokenPotУчет электроэнергии производится либо по городу, либо по району области. По стране - не производится. :) Это "по стране" не производится, а вот по России - производится. Вы не в теме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:30 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
10 000 рабочих мест?! У нас в Киеве их не более двухсот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:30 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Dried Gagarin BrokenPotУчет электроэнергии производится либо по городу, либо по району области. По стране - не производится. :) Это "по стране" не производится, а вот по России - производится. Вы не в теме. Вы не шутите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:31 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS...причем и бытовые и юр лица в одной БД... глупость из тех еще. откажитесь от этой идеи. сделайте _разные_ БД. Объяснение - за отдельную плату. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:32 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Dried Gagarin GeenS...причем и бытовые и юр лица в одной БД... глупость из тех еще. откажитесь от этой идеи. сделайте _разные_ БД. Объяснение - за отдельную плату. +1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:33 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Dried Gagarin BrokenPotУчет электроэнергии производится либо по городу, либо по району области. По стране - не производится. :) Это "по стране" не производится, а вот по России - производится. Вы не в теме. И что же, из Калининграда (обл), Москвы, Перми и Магадана будут коннектиться к одной базе и формировать счета за истекший месяц для своего участка? Вы - шутите... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:35 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
BrokenPotВы не шутите? Это не шутки, это реалии реформы по Чубайсу. Появление сбытов, имеющих точки поставки по всей России - реальность ближайших лет. РЖД может свои сбыты объединить в единую структуру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:35 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Еще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование: заранее заложиться (прошу прощения за карточный жаргон) на мультиуслуги и разные компании из самых разных регионов России. А такие компании будут расти ка грибы по всем прогнозам! по моему проще и яснее не объяснишь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:36 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
И что будет делать клиент в системе? Для чего пишите систему то? Систем по учету электричества и коммуналки до кукуя уже, даже хороших наверное с десяток наберется, хотите сделать велисапед очередной? А есть хоть какое ТЗ, ну хоть чего-то? Иначе как можно говорить об оборудовании и т.д. А апп-сервер - это фетиш, модно это. Но вам не нужен. Может вам и ничего не нужно. С чем работали с тем и работайте ЗЫ Но я так и не понял. в чем суть системы и зачем в ней столько клиентов. И главное, как их будете искать? Закон издадите? Или вы от чубайса? -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:38 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Dried Gagarin GeenS...причем и бытовые и юр лица в одной БД... глупость из тех еще. откажитесь от этой идеи. сделайте _разные_ БД. Объяснение - за отдельную плату. Нет, милейший, как раз не глупость, а труднодостижимый идеал - сбыт должен быть консолидированным! Консолидацию (особенно в части потерь) из разных БД - уже проходили, никак пройти не можем до конца...слезы! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:39 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование ВЫ всерьез считаете, что кто-то доверит какой-то организации учет своих услуг???!!! Вернитесь с небес на землю... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:39 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
автор GeenSЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование: заранее заложиться (прошу прощения за карточный жаргон) на мультиуслуги и разные компании из самых разных регионов России. А такие компании будут расти ка грибы по всем прогнозам! по моему проще и яснее не объяснишь... Поный бред, никто ниоткуда не придет, особенно в аренду на деревню дедушке. Уже полстраны имеет или свои или купленные системы, если не больше. Вменяемый руководитель поставит и себе либо собственную, либо региональную. Но никак не будет арендовать где-то хз где, за которую не отвечает и никак не может повлиять. Бросайте затею, пока не поздно. Хотя если хотите денег получить без учета результата, то можно и поразрабатывать :)) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:42 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin авторЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование ВЫ всерьез считаете, что кто-то доверит какой-то организации учет своих услуг???!!! Вернитесь с небес на землю... Мир не стоит на месте...уже доверяют и бухгалтерии и ERP есть как услуга...все постепенно выносится на хостинг - это очевидно. Будущее за специализированными центрами ПО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:42 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS pkarklin авторЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование ВЫ всерьез считаете, что кто-то доверит какой-то организации учет своих услуг???!!! Вернитесь с небес на землю... Мир не стоит на месте...уже доверяют и бухгалтерии и ERP есть как услуга...все постепенно выносится на хостинг - это очевидно. Будущее за специализированными центрами ПО. Есть примеры? Причем тут хостинг? -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:43 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygra автор GeenSЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование: заранее заложиться (прошу прощения за карточный жаргон) на мультиуслуги и разные компании из самых разных регионов России. А такие компании будут расти ка грибы по всем прогнозам! по моему проще и яснее не объяснишь... Поный бред, никто ниоткуда не придет, особенно в аренду на деревню дедушке. Уже полстраны имеет или свои или купленные системы, если не больше. Вменяемый руководитель поставит и себе либо собственную, либо региональную. Но никак не будет арендовать где-то хз где, за которую не отвечает и никак не может повлиять. Бросайте затею, пока не поздно. Хотя если хотите денег получить без учета результата, то можно и поразрабатывать :)) -- Tygra's -- Мои фотогалереи тут и тут Спасибо за совет...а надо подумать...хотите в долю? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:44 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSМир не стоит на месте...уже доверяют и бухгалтерии и ERP есть как услуга...все постепенно выносится на хостинг - это очевидно. Будущее за специализированными центрами ПО. Ссылочки на Success Story приветсвуются... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:45 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygra GeenS pkarklin авторЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование ВЫ всерьез считаете, что кто-то доверит какой-то организации учет своих услуг???!!! Вернитесь с небес на землю... Мир не стоит на месте...уже доверяют и бухгалтерии и ERP есть как услуга...все постепенно выносится на хостинг - это очевидно. Будущее за специализированными центрами ПО. Есть примеры? Причем тут хостинг? -- Tygra's -- Мои фотогалереи тут и тут http://www.netsuite.com ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:47 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
не думал, что процессинговые услуги для многих являются новостью. Точно на улицу нужно чаще выходить, коллеги. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:47 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygraВменяемый руководитель поставит и себе либо собственную, либо региональную. + 1000 Причем в конторах типа РЖД, РАО EC или Газпром. Такие системы на региональный уровень спускаются сверху. Им надо свои разработческие конторы кормить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:48 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторСпасибо за совет...а надо подумать...хотите в долю? ;) Нет, я такой болезнью давно переболел :) авторhttp://www.netsuite.com И где там российские компании? :) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:49 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafmне думал, что процессинговые услуги для многих являются новостью. Точно на улицу нужно чаще выходить, коллеги. Услуги какого рода конкретно? Бухгалтерия? :) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:50 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Хотел бы вернуться к техническим аспектам проблемы...Оставит маркетинг маркетологам... Так нужен или не нужен для такой задачи аппсервер? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:50 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторhttp://www.netsuite.com И что?! У них даже сайта Российского нет. Под Success Story понимается немного другое... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:52 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygraНе нужен :) -- Tygra's -- Мои фотогалереи тут и тут Спасибо за совет и восхищен Вашей лаконичностью! А как Вам видится архитектура? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:52 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafmне думал, что процессинговые услуги для многих являются новостью. Точно на улицу нужно чаще выходить, коллеги. И коим местом озвученные Вами услуги коррелируются с тем, что нужно автору? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:53 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Никак :) Неизвестно, что и как будет делать система. Учитывая удаленный доступ, я бы сделал ехе, который ходит на вебсервисы, которые ходят в БД :) Теперь это у меня модный подход :) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 17:54 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygraНикак :) Неизвестно, что и как будет делать система. Учитывая удаленный доступ, я бы сделал ехе, который ходит на вебсервисы, которые ходят в БД :) Теперь это у меня модный подход :) -- Tygra's -- Мои фотогалереи тут и тут весьма интересно! 1) вообще без браузера? 2) а какой толщины канал нужон для этого дела? 3) а веб-сервисы - ява или дотнет? или...дайте угадаю...по фигу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 18:00 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin iscrafmне думал, что процессинговые услуги для многих являются новостью. Точно на улицу нужно чаще выходить, коллеги. И коим местом озвученные Вами услуги коррелируются с тем, что нужно автору? Да вроде по-русски написано: АвторЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование: заранее заложиться (прошу прощения за карточный жаргон) на мультиуслуги и разные компании из самых разных регионов России. А такие компании будут расти ка грибы по всем прогнозам! по моему проще и яснее не объяснишь... GeenS, побродите лучше по сайтам компаний, предоставляющих подобные услуги и покопайте нужную Вам информацию, будет полезней. Например сюда . Здесь Вам только в очередной раз расскажут, что СУБД еще и обед может готовить, просто Вы с ней говорить не умеете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 18:01 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafm pkarklin iscrafmне думал, что процессинговые услуги для многих являются новостью. Точно на улицу нужно чаще выходить, коллеги. И коим местом озвученные Вами услуги коррелируются с тем, что нужно автору? Да вроде по-русски написано: АвторЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование: заранее заложиться (прошу прощения за карточный жаргон) на мультиуслуги и разные компании из самых разных регионов России. А такие компании будут расти ка грибы по всем прогнозам! по моему проще и яснее не объяснишь... GeenS, побродите лучше по сайтам компаний, предоставляющих подобные услуги и покопайте нужную Вам информацию, будет полезней. Например сюда . Здесь Вам только в очередной раз расскажут, что СУБД еще и обед может готовить, просто Вы с ней говорить не умеете. спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 18:03 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Коллеги, к сожалению вынужден на сегодня оставить интереснейшую дискуссию - есть, к счастью жизнь и вне стен офиса! завтра надеюсь на плодотворное продолжение... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 18:04 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafmДа вроде по-русски написано: Так прям и видится фантастическая картина, что Краснодаргоргаз и Краснодарэнерго считают услуги, оказываемые ими, у стороннего ООО. М.б. на другом витке эволюции... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 18:06 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
ИМХО: Зря Вы на FireBird маханули рукой. Кручу 60Гб на SUSE 9.3 - прелесть... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 18:16 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinТак прям и видится фантастическая картина, что Краснодаргоргаз и Краснодарэнерго считают услуги, оказываемые ими, у стороннего ООО. М.б. на другом витке эволюции... Немного не так. Краснодарскэнергосбыт считает у "стороннего ООО" услуги, оказываемые Краснодарскэнерго, притом данные о показаниях счетчиков передаются из Краснодарскэнерго т.к. электросетевое хозяйство - это их собственность, равно как и АСКУЭ... Данные об оплате поступают в "стороннее ООО" из банков, почты, платежных операторов и проч. опять же в электронном виде заверенные ЭЦП... печать и конвертование счетов и квитанций производит ООО "Кранодарск-принт", потому как это тоже дешевле на аутсорс отдать... В общем полная идиллия наступит... рай на земле... и топикстартер - пророк его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 18:43 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Хм. Жадные буржуи для таких систем используют WebLogic или WebSphere, хотя они и стоят диких бабок (по мнению российских "кустарей-одиночек с мотором"). Наверняка буржуи дураки... Точно!! Чего взять с тупых америкосов!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 18:49 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование: заранее заложиться (прошу прощения за карточный жаргон) на мультиуслуги и разные компании из самых разных регионов России. А такие компании будут расти ка грибы по всем прогнозам! по моему проще и яснее не объяснишь... Вам доверяют создать биллинговую систему на 10 000 клиентов? Даже если приблизительно прикинуть то получается ваша фирма хочет захватить рынок ну как минимум 20% всего Российского биллинга. Идея мягко говоря амбициозная. В энергетике вам столько не дадут явно, там уже SPL начинает внедряться, года через 2-3 SPL заберет минимум половину этого рынка в энергетике. Но, что самое странное, данная амбициозная задача доверена человеку, который судя по всем предыдущим высказываниям лишь поверхностно владеет темой. Как повашему, чем закончится данный проект? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 20:25 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinТак прям и видится фантастическая картина, что Краснодаргоргаз и Краснодарэнерго считают услуги, оказываемые ими, у стороннего ООО. М.б. на другом витке эволюции... Павел, дался Вам это Краснодар?! Меня вот что слегка настораживает - а автор топика примерно размер базы своей вообще считал? И нагрузки и на СУБД, и на приложение? Пусть даже на практике будет 10000 пользователей одновременно - чушь, конечно, ну да Бог с ним... Получается, что все эти люди что-то должны видеть - верно? Система охватит полстраны - снова чушь, но опять посчитаем. Это сколько миллионов счетчиков? Только у конечных пользователей думаю не меньше 10 миллионов (на самом деле скорее всего гораздо больше, ну да снова Бог с ним). Плюс счетчики на предприятиях, на всяких распределительных подстанциях и т.п. - думаю, прикинем миллионов до 15. Это минимум 15млн. записей в месяц. 180млн. записей в год. Плюс по-хорошему таблицы со структурой связи счетчиков. Плюс если работают юрлица - наверняка будет нужно вносить записи о показаниях с промобъектов не раз в месяц, а хотя бы раз в час (а по-хорошему на важных объектах такие вещи мониторят горрраздо чаще - ну да снова пропустим). Это с одного счетчика 720 записей в месяц. В год 8640. Если таких счетчиков по стране наберется хотя бы тысяч 10 (а ведь их больше) - в год это еще 86млн. записей. Итого 250млн. записей в год только с показаниями. Не много конечно. Но уже и не настолько мало! И не забывайте, что я скорее всего брал цифры достаточно заниженные (в разы, если не на порядки). А теперь начинайте прикидывать объем базы, типовые запросы пользователей, нагрузку и т.п. Особенно постарайтесь придумать, какие 10000 коннектов у вас одновременно будут. И сколько из этих соединений породят одновременные запросы к БД. И что в таких запросах будет первично - ФИО абонента или расчетный период - как индексы строить-то будете? И каково будет допустимое время ожидания ответа? А потом пойдите посчитайте, сколько будут стоить сервера, удовлетворяющие таким требованиям? И какие СУБД это выдержат? После чего набейте морду людям, которые предлагают на ту же железку еще и сервер приложений повесить. И заодно прикиньте - а доверили бы писать софт такой важности лично Вам (без обид)? Ну и еще подумайте, а настолько ли при таких объемах и т.п. была глупа идея разнести базы для рядовых абонентов, которым нужны итоговые показания трех прошлых месяцев со временем реакции до пяти минут - и для юрлиц, которым могут понадобиться цифры с поминутными разбивками, сложными иерархиями и т.п., причем СРОЧНО. Я это все к чему - у Вас правильно спрашивали, а насколько описанные планы осуществимы!!! Потому что проще всего ляпнуть "будет мильён тыщ посетителей - поэтому покупай ЧТО-НИБУДЬ". А если по факту будет 50 активных пользователей с крайне призрачной перспективой их увеличения - то от этого и считайте. А если Вам кто-то говорит столь огромные цифры - ТРЕБУЙТЕ аргументации! Если смогут аргументировать - то пусть тогда считают мощность всей системы. Я, например, не специалист - но какой мощности нужен сервер для одновременной работы 10тыс пользователей по тому же вебу? И какой ширины канал? Особенно если логику повесить не на СУБД, а именно на этот сервер? Почему-то мне кажется, что цена такой машинки выйдет за рамки 100 баксов. А теперь давайте на него же СУБД подвесим? Итого мораль - а смысл Вам писать программу на миллион и ставить ее на сервер за штуку? А заказчикам смысл ПО для железа на миллион заказывать у Вас за штуку? Удачи, конечно - но у Вас там еще и конь не валялся... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 01:14 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Кстати - это я коснулся только процесса выборки данных. А как они будут обновляться? В каком режиме? Нагрузка, опять-таки? И насколько внесение данных сможет подвесить выборку? Да и еще - если охватывать страну, то с учетов всех часовых поясов надо планировать систему 24х7 - Вы это учитывали? И по софту учитывали, и по железу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 01:19 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Ребяты! Не хочу никого обидеть но по-моему все гораздо проще: Просто в одной богатой конторе есть баблосов немеряно,умные РУКи нащупали тему как это бабло получше распилить.Тендор уже выигран.Бабло заложено (в смысле поделено предварительно в % )..Как обычно толком никто ничего не знает пока.Идет предварительная работа в плане бюджета.... А если серьезно с такими исходными данными ожидать вразумительных советов по меньшей мере наивно. Все равно, что спрашивать сколько стоит хороший дом с приусадебным участком в пригороде. Код: plaintext -Ну вот наконец-то мы и открылись... а теперь давайте сядем и все вместе подумаем ...чем будем заниматься . З.Ы. Не судите так строго. Вы что шуток не понимаете! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 01:57 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Доброе утро коллеги, Dried Gagarin pkarklinТак прям и видится фантастическая картина, что Краснодаргоргаз и Краснодарэнерго считают услуги, оказываемые ими, у стороннего ООО. М.б. на другом витке эволюции... Немного не так. Краснодарскэнергосбыт считает у "стороннего ООО" услуги, оказываемые Краснодарскэнерго, притом данные о показаниях счетчиков передаются из Краснодарскэнерго т.к. электросетевое хозяйство - это их собственность, равно как и АСКУЭ... Данные об оплате поступают в "стороннее ООО" из банков, почты, платежных операторов и проч. опять же в электронном виде заверенные ЭЦП... печать и конвертование счетов и квитанций производит ООО "Кранодарск-принт", потому как это тоже дешевле на аутсорс отдать... В общем полная идиллия наступит... рай на земле... и топикстартер - пророк его. Весьма интересно! сейчас кстати около того что-то и есть...только причем тут т.н. Краснодарэнергосбыт? и вообще Краснодар? Краснодар к этому не готов...но направление по компасу -зюйд - коллега из Калуги выбрал верное :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 08:20 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... GeenSЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование: заранее заложиться (прошу прощения за карточный жаргон) на мультиуслуги и разные компании из самых разных регионов России. А такие компании будут расти ка грибы по всем прогнозам! по моему проще и яснее не объяснишь... Вам доверяют создать биллинговую систему на 10 000 клиентов? Даже если приблизительно прикинуть то получается ваша фирма хочет захватить рынок ну как минимум 20% всего Российского биллинга. Идея мягко говоря амбициозная. В энергетике вам столько не дадут явно, там уже SPL начинает внедряться, года через 2-3 SPL заберет минимум половину этого рынка в энергетике. Но, что самое странное, данная амбициозная задача доверена человеку, который судя по всем предыдущим высказываниям лишь поверхностно владеет темой. Как повашему, чем закончится данный проект? ох-хо-хо... Да ничего мне не доверяют...Идут разговоры...Это стадия такая...Я вообще на самом деле даже не решил еще: участвовать или нет... Я же говорил - мне твердят в уши спецы...Я еще хочу понять суть этих спецов. Надеюсь на Вашу помощь. Абсолютно верно! Темой больших систем владею не очень...Темой энергосбыта - очень владею! А насчет амбиций - упаси Бог идти на такие масштабы! Пахнет катастрофой...Но запас надо ведь иметь? или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 08:28 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSЯ же говорил - мне твердят в уши спецы...Я еще хочу понять суть этих спецов. Надеюсь на Вашу помощь. Абсолютно верно! Темой больших систем владею не очень...Темой энергосбыта - очень владею! А насчет амбиций - упаси Бог идти на такие масштабы! Пахнет катастрофой...Но запас надо ведь иметь? или нет? По поводу ваших "спецов" - я вам уже писал. Раз они так "классно" оценивают масштабы - заставьте их сразу оценить и нагрузку. Но только не однобоко, а со стороны ВСЕХ элементов! И лишь после этого начинайте им хоть немного верить. Запас????? Не смешите меня? КАКОЙ запас можно иметь на ОДНОМ серваке, на котором одновременно и это приложение крутится, и СУБД?! Вы хоть цифры прикиньте-то... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 09:16 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
2just_nick Признателен за трезвый расчет. На самом деле и у меня по предварительным прикидкам подозрения вызывали именно количество учетных объектов, а не количество рабочих мест, которое в любом случае - однозначно завышено. Теперь мои опасения подтвердились. 1) Затраты на систему даже регионального уровня будут чрезвычайно высоки именно в части железа. 2) Закладываться на систему федерального уровня - ахинея, никто не вытянет, кроме очень крупных игроков 3) Расчеты приблизительно совпадают с оценками некой иностранной фирмы, которая предложила ОЧЕНЬ ДОРОГОЙ проект для такого же решения. Наши обещают дешевле - думаю, что брешут, собаки... 4) Вообще страшно стало...так и доложу начальству... 2leonidy Да нет, конечно, все не так. Никакого тендера нет и не было. Так - разговоры. Просто кое у кого появилась мысль - окупить, хотя бы окупить, расходы на создание корпоративной системы. Просто скажу, что окупить не получится - и все. А чисто корпоративную систему построить - я и спрашивать не стану - НЕ НУЖЕН конечно сервер приложений! Привет бесстрашному Тигре! он прав 150 раз! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 09:16 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS2just_nick Признателен за трезвый расчет. ... 3) Расчеты приблизительно совпадают с оценками некой иностранной фирмы, которая предложила ОЧЕНЬ ДОРОГОЙ проект для такого же решения. Наши обещают дешевле - думаю, что брешут, собаки... ... Блин - кто бы тогда взял меня в консалтеры, раз я так хорошо считаю? Хочется поработать с действительно крупными системами... Согласен в Краснодарэнерго, раз уж его Карклинь упоминал его несколько раз. Или раз Вы сказали про "в сторону юга" - то Ростов бы вообще идеально подошел - и переезжать бы не пришлось! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 09:27 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
just_nick GeenS2just_nick Признателен за трезвый расчет. ... 3) Расчеты приблизительно совпадают с оценками некой иностранной фирмы, которая предложила ОЧЕНЬ ДОРОГОЙ проект для такого же решения. Наши обещают дешевле - думаю, что брешут, собаки... ... Блин - кто бы тогда взял меня в консалтеры, раз я так хорошо считаю? Хочется поработать с действительно крупными системами... Согласен в Краснодарэнерго, раз уж его Карклинь упоминал его несколько раз. Или раз Вы сказали про "в сторону юга" - то Ростов бы вообще идеально подошел - и переезжать бы не пришлось! РОСТОВЧАНИН? а-ха... уже теплее во всех смыслах... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 09:39 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSРОСТОВЧАНИН? а-ха... уже теплее во всех смыслах...он самый... "жить ведь где-то надо"(с) Вам тут сотрудники не нужны? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 09:56 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS Для систем такого масштаба существует стандартное решение: 1. 1 сервер БД без(почти) бизнес логики 2. N серверов приложений с бизнес логики 3. терминалы или веб доступ к 2 масштабируемость за счет числа N и числа процессоров на 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 10:18 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
модДля систем такого масштаба существует стандартное решение: 1. 1 сервер БД без(почти) бизнес логики 2. N серверов приложений с бизнес логики 3. терминалы или веб доступ к 2 масштабируемость за счет числа N и числа процессоров на 1. Исчо один... Только вчера на аналогичное "решение" отвечал... Если ОДИН сервер СУБД не справляется с нагрузкой от большого числа пользователей, то мы между ним и пользователями поставим ЕЩЕ ОДИН СЕРВЕР (несколько), который решит эти проблемы? Бред... И, простите, в приведенном варианте решения серверу СУБД только процессоры нужны? А дисковое пространство? А память? Таким образом, дабы действительно что-то масiтабировать при прtдложенном "стандартном решении" надо: 1. Умощьнять сервер СУБД 2. Добавлять сервера приложений. Теперь забываем про сервер приложений, и, оказывается, для масштабирования достаточно умощьнать только сервер СУБД (на выбор - scale up или scale out). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 10:32 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
just_nick GeenSРОСТОВЧАНИН? а-ха... уже теплее во всех смыслах...он самый... "жить ведь где-то надо"(с) Вам тут сотрудники не нужны? ;) Может и нужны ;) ...будут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 10:44 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS Прохожий..... GeenSЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование: заранее заложиться (прошу прощения за карточный жаргон) на мультиуслуги и разные компании из самых разных регионов России. А такие компании будут расти ка грибы по всем прогнозам! по моему проще и яснее не объяснишь... Вам доверяют создать биллинговую систему на 10 000 клиентов? Даже если приблизительно прикинуть то получается ваша фирма хочет захватить рынок ну как минимум 20% всего Российского биллинга. Идея мягко говоря амбициозная. В энергетике вам столько не дадут явно, там уже SPL начинает внедряться, года через 2-3 SPL заберет минимум половину этого рынка в энергетике. Но, что самое странное, данная амбициозная задача доверена человеку, который судя по всем предыдущим высказываниям лишь поверхностно владеет темой. Как повашему, чем закончится данный проект? ох-хо-хо... Да ничего мне не доверяют...Идут разговоры...Это стадия такая...Я вообще на самом деле даже не решил еще: участвовать или нет... Я же говорил - мне твердят в уши спецы...Я еще хочу понять суть этих спецов. Надеюсь на Вашу помощь. Абсолютно верно! Темой больших систем владею не очень...Темой энергосбыта - очень владею! А насчет амбиций - упаси Бог идти на такие масштабы! Пахнет катастрофой...Но запас надо ведь иметь? или нет? Не надо болезненно реагировать. Просто, что вы писали до этого, попахивает несерьезностью. Даже примитивно посчитав 10000 (одновременно работающих операторов) * 1000 (минимальное количество обслуживаемых абонентов 1 оператором) = 10млн абонентов (и это по минимуму, в реалиях будет значительно больше). Чисто технически хранение этой информации за 3-5 лет потребует каких мощностей, а ее обработка? Вы хотите создать национальный датацентр с суперЭВМ? А за работу с абонентами юрлицами вот так: авторИнтерфейс клиента: web пользователи вас сожгут на костре! Мой совет: Забейте на все и проектируйте систему на 300-500 пользователей, используя общедоступные средства, слишком жирный сервер приложений иметь чревато, так что лучше сбалансировать нагрузку между клиентом и сервером, все делайте на NET с доступом через WebService и люди к вам потянутся. P.S. если вам и вправду надо станет 10000 пользователей, ничто не мешает создать 20 баз на 20 серверах, а пытаться иметь одну БД на несколько десятков миллионов абонентов это маразм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 10:53 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinЕсли ОДИН сервер СУБД не справляется с нагрузкой от большого числа пользователей, то мы между ним и пользователями поставим ЕЩЕ ОДИН СЕРВЕР (несколько), который решит эти проблемы? Ключевое слово: бизнес-логика (перечитайте еще раз). И еще раз повторяю - это стандартное решение, которое применяется в системах такого масштаба, например, в банках (не наших). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:12 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... А за работу с абонентами юрлицами вот так: авторИнтерфейс клиента: web пользователи вас сожгут на костре! А что делать если сеть филиалов весьма распылена географически, а каналы скверные? если делать десктопного клиента, то конечно нужны каналы не менее 256Кбит, а у нас далеко не везде связисты дают такую возможность... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:18 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
модКлючевое слово: бизнес-логика (перечитайте еще раз). Хотите об этом поговорить? Давайте. Она эта бизнес-логика, реализуемая в вашем варианте не на сервере СУБД, будет обходиться без данных, получаемых с сервера? Т.е. В Вашем варианте мы сначала потянем необходимые данные на апп. сервер, там их "посчитаем" и положим обратно? И на кой этот геморой нужен? Зачем таскать данные еще куда-то, если их можно посчитать там, где они лежат? Не ставя дополнительных серверов и не городя между ними 10гигабиные каналы связи, превращая сервер СУБД в простое хранилище? модИ еще раз повторяю - это стандартное решение, которое применяется в системах такого масштаба, например, в банках (не наших). "Мода" на это "стандартное" решение давно прошла! Несколько лет назад все носились с идеей N-звенок, как с писаной торбой, но когда поняли, во что выливаются такие проекты, когда N-звенку совали кудя не попадя, Вы, надеюсь, слышали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:22 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSА что делать если сеть филиалов весьма распылена географически, а каналы скверные? если делать десктопного клиента, то конечно нужны каналы не менее 256Кбит, а у нас далеко не везде связисты дают такую возможность... Еще один миф, в котором утверждается, что WEB интерфейс (оставим в стороне обсуждение его убогости) менее требователен к ширине каналов!!! Вы, как мне показалось, здравомыслящий человек. Ну сами посчитайте, что при использовании WEB клиента траффик будет не меньше, а БОЛЬШЕ, ибо кроме самих данных (предположим TDS пакетов), клиент и WEB сервер будут обмениваться еще кучей дополнительной информации. ВЫ скажите - "а обновления клиентских частей"? Для этого существуют различные способы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:26 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторесли делать десктопного клиента, то конечно нужны каналы не менее 256Кбит, а у нас далеко не везде связисты дают такую возможность... Сильно ошибаетесь. авторкогда N-звенку совали кудя не попадя А теперь вспомним самое главное - КТО совал и куда.. Я -же говорю: тупые американцы! Используют дурацкие, ущербные трехзвенки и сервера приложений ведущих производителей. Ту-у-упы-ы-Е! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:31 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
anonimouseЯ -же говорю: тупые американцы! Используют дурацкие, ущербные трехзвенки и сервера приложений ведущих производителей. Ту-у-упы-ы-Е! Вы ошибетесь! Они не тупые. Они очень хорошие маркетологи, умеющие навешать клиенту лапши на уши теми же аргументами, которыми и автора топика "спецы" подчивали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:35 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin GeenSА что делать если сеть филиалов весьма распылена географически, а каналы скверные? если делать десктопного клиента, то конечно нужны каналы не менее 256Кбит, а у нас далеко не везде связисты дают такую возможность... Еще один миф, в котором утверждается, что WEB интерфейс (оставим в стороне обсуждение его убогости) менее требователен к ширине каналов!!! Вы, как мне показалось, здравомыслящий человек. Ну сами посчитайте, что при использовании WEB клиента траффик будет не меньше, а БОЛЬШЕ, ибо кроме самих данных (предположим TDS пакетов), клиент и WEB сервер будут обмениваться еще кучей дополнительной информации. ВЫ скажите - "а обновления клиентских частей"? Для этого существуют различные способы. Ну вот как раз насчет обновления клиентских частей я меньше всего беспокоюсь...Я понимаю, что использование десктопного интерфейса дает преимущества как то: защищенность клиента от несанкционированного доступа, несравнимое с веб удобство и функциональность. Но: я никода не видел практического решения работы десктопного приложения через веб сервисы дотнет, а видел десктоп работающий с БД напрямую (Delphi + MS SQL 2000) - это выглядело, мягко говоря, не очень хорошо, хотя впрочем там система была очень криво спроектирована и возможно бесполезного трафика было сверх меры... А канал-то был 265Кбит на ОДНОГО КЛИЕНТА ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:36 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS Прохожий..... А за работу с абонентами юрлицами вот так: авторИнтерфейс клиента: web пользователи вас сожгут на костре! А что делать если сеть филиалов весьма распылена географически, а каналы скверные? если делать десктопного клиента, то конечно нужны каналы не менее 256Кбит, а у нас далеко не везде связисты дают такую возможность... Вы думаете web вас спасет от узких каналов? На канале в 64кбит даже странички размером в 100кб тормозят, и представте, все это будет использовать биллинговый центр, где уж никак не 1 оператор. Применяйте сжатие передаваемой информации (в NET реализуется проще простого), можно использовать кеширование некоторой инфы на клиенте. На мой взгляд так даже экономичней использовать трафик. Передается посути только xml с данными и все, ничего лишнего, а если xml еще и сжать, то вообще альтернативы нет! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:36 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSА канал-то был 265Кбит на ОДНОГО КЛИЕНТА конечно же 256Кбит...сорри...хотя вот сейчас вспоминаю..наверное не было 256...было меньше...они только пробывали получить такой канал, а в тот момент не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:39 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSа видел десктоп работающий с БД напрямую (Delphi + MS SQL 2000) - это выглядело, мягко говоря, не очень хорошо, хотя впрочем там система была очень криво спроектирована и возможно бесполезного трафика было сверх меры... А канал-то был 265Кбит на ОДНОГО КЛИЕНТА Из собственного опыта. Удаленный филиал. 15 клиентов на канале 64 кбит. Разницы (в режиме нормальной операционной работы) что в локальной сети, что у них - никакой. Если же ВЫ потащите на клиента сотни тысяч записей за один присест - тады "ой". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:39 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin GeenSа видел десктоп работающий с БД напрямую (Delphi + MS SQL 2000) - это выглядело, мягко говоря, не очень хорошо, хотя впрочем там система была очень криво спроектирована и возможно бесполезного трафика было сверх меры... А канал-то был 265Кбит на ОДНОГО КЛИЕНТА Из собственного опыта. Удаленный филиал. 15 клиентов на канале 64 кбит. Разницы (в режиме нормальной операционной работы) что в локальной сети, что у них - никакой. Если же ВЫ потащите на клиента сотни тысяч записей за один присест - тады "ой". Да согласен, чрезвычайно зависит от проетирования, я бы даже сказал - стиля разработки клиента. Я например как могу избегаю редактируемые курсоры и вообче всякие привязки к данным через датасеты - все должно решаться только в ХП получающей параметрами значения ОТВЯЗАННЫХ контролов, т.е. все проверки на корректность, наличие / отсутствие и т.п. ИМХО. Но я так делаю - пока все хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:43 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторЯ например как могу избегаю редактируемые курсоры и вообче всякие привязки к данным через датасеты - все должно решаться только в ХП получающей параметрами значения ОТВЯЗАННЫХ контролов, т.е. все проверки на корректность, наличие / отсутствие и т.п. Я, наоборот, использую датасеты (в режиме кэшированных изменений) + db-aware контролы (за редким исключением) и хп на стороне сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:48 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinНесколько лет назад все носились с идеей N-звенок, как с писаной торбой, но когда поняли, во что выливаются такие проекты, когда N-звенку совали кудя не попадя, Вы, надеюсь, слышали. а во что они выливаются собственно? Как работали, так и продолжают работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:52 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSКраткое описание задачи: Назначение: Учет сбыта электроэнергии (физ.лица и юр.лица),биллинг, отслеживание состояний оборудования, договоры и т.п. Я не имею опыта в этих сферах.Я работал только с MS продуктами. Есть команда разработчиков и у них почти сложилось понимание, НО! я хочу иметь собственной мнение. Кто имел опыт подобных разработок - поделитесь советом...Заранее благодарен iseries + telnet 5250 (green sreen) хватит и 9600 коннекта при нынешних ценах на x86 софт не дороже будет -) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 11:53 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Уважаемые! Каждый волен отстаивать свою точку зрения и ту тенологию которой владеет. Я имел возможность поюзать и даже поучаствовать в проектах с многозвенной архитектурой и классической клиент серверной.И там и там есть свои плюсы и минусы.Одно могу сказать точно: какая разница насколько красиво ваше решение если оно не работает.Качество проектирования складывается из многих составляющих.Даже на очень хорошее железо можно такой глючный софт поставить.Классический клиент сервер хорош до определенных масштабов.Явно не для ваших амбиций:).WEB клиент по-моему убогий изначально ,плюс убогая ,как правило, реализация .К тому же достаточно дорогие спецы.Теперь ,что подразумевать под многозвенкой?.Если сервер приложений это просто набор интерфейсов доступа к базе- выигрыш в производительности сомнительный.Под Ado.net все и так работает не быстро .Хотя если данные достаточно статичны при правильном подходе число запросов к серверу можно значительно уменьшить ,но при этом надо иметь хорошие каналы .ХМL знаете ли ... Или вы на самом деле будете писать свой сервер приложений.В смысле бизнеслогику туда вынесите или хотя бы часть... но спрашивается зачем?Если отказаться от WEB клиента то есть на клиенте классический EXE.И пусть все умное делается на клиенте.Не думаю ,что нормальное железо дороже чем софт. В любом случае: оччень мощный сервер с базой отдельно , сервер(ы) приложений(доступа) отдельно, "толстый" клиент c возможностью удаленного обновления. З.Ы. и упаси вас господь от репликаций и проч. "стандартных" решений от MS. а мода здесь совершенно не при чем ,хотя имеет место быть.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 12:18 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinЗачем таскать данные еще куда-то, если их можно посчитать там, где они лежат? Не ставя дополнительных серверов и не городя между ними 10гигабиные каналы связи, превращая сервер СУБД в простое хранилище? Дело все в том, что СП и каналы связи могут масштабироваться (и недорого), а вот сервер БД - один (и дорогой и масштабировать его дорого). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 12:19 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
leonidyУважаемые! Каждый волен отстаивать свою точку зрения и ту тенологию которой владеет. Я имел возможность поюзать и даже поучаствовать в проектах с многозвенной архитектурой и классической клиент серверной.И там и там есть свои плюсы и минусы.Одно могу сказать точно: какая разница насколько красиво ваше решение если оно не работает.Качество проектирования складывается из многих составляющих.Даже на очень хорошее железо можно такой глючный софт поставить.Классический клиент сервер хорош до определенных масштабов.Явно не для ваших амбиций:).WEB клиент по-моему убогий изначально ,плюс убогая ,как правило, реализация .К тому же достаточно дорогие спецы.Теперь ,что подразумевать под многозвенкой?.Если сервер приложений это просто набор интерфейсов доступа к базе- выигрыш в производительности сомнительный.Под Ado.net все и так работает не быстро .Хотя если данные достаточно статичны при правильном подходе число запросов к серверу можно значительно уменьшить ,но при этом надо иметь хорошие каналы .ХМL знаете ли ... Или вы на самом деле будете писать свой сервер приложений.В смысле бизнеслогику туда вынесите или хотя бы часть... но спрашивается зачем?Если отказаться от WEB клиента то есть на клиенте классический EXE.И пусть все умное делается на клиенте.Не думаю ,что нормальное железо дороже чем софт. В любом случае: оччень мощный сервер с базой отдельно , сервер(ы) приложений(доступа) отдельно, "толстый" клиент c возможностью удаленного обновления. З.Ы. и упаси вас господь от репликаций и проч. "стандартных" решений от MS. а мода здесь совершенно не при чем ,хотя имеет место быть.. только не толстый клиент! так мы и до DBF докатимся... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 12:40 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
модДело все в том, что СП и каналы связи могут масштабироваться (и недорого), а вот сервер БД - один (и дорогой и масштабировать его дорого). Еще раз. Умощнением (увеличением кол-ва) только апп. серрверов проблемы масштабирования не решить. От того, что Вы в одном месте информационного потока сделали "шире" общая пропускная способность не увеличится, так как будет определяться самым "узким" местом на пути этого потока, которым в Вашем примере станет сервер СУБД. Таким образом, при наличии апп. сервера надо умощнать и апп. сервер и сервер СУБД, и только сервер СУБД в случаи отсутствия первого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 12:44 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
На самом деле вот что: или БЛогика на сервере БД и доступ через веб сервисы или БД+аппсервер+тонкий (веб?) клиент Мне один чел вообще говорит: все делать на сервере приложений, берем шустрый MySQL и используем его только как хранилище данных объектов, т.е. храним собственно объекты. Аппсервер дергает объекты из базы (конструктором класса) чето-там ими манипулирует...и назад если надо. Я ему сразу: мил человек, ява твоя в таком разе столько отожрет что мама не горюй! Он начал возмущаться. Я ему говорю, ладно: как ты себе представляешь объект выбирающий списки для отчетов, вообще объект отчет. Примолк. Наверное думает. Откуда такое небрежение к реляционным БД? Прям будто они только то и могут что поля хранить в таблицах! А че это мы как не свои прямо? Ведь праздник же коллеги! Поздравляю! Забыл совсем... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 12:49 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
вы понимаете что такое "Сервер приложений"? Это некая программулина (JBoss например) в которой выполняются ваши программные модули. Эти написанные вами модули могут обращаться к БД или ещё куда. Сделанные вами гуй (веб или десктоп) может обращаться к вашим модулям установленным в сервере приложений. И что в результате: вы думаете что ваш модуль установленный в сервер приложений выполнит подсчёт быстрее чем select sum(payment) from payments join customers where name='Рога и копыта' ? Никаких шансов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 13:11 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторНикаких шансов Валялсо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 13:16 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSНа самом деле вот что: или БЛогика на сервере БД и доступ через веб сервисы или БД+аппсервер+тонкий (веб?) клиент Зачем же в крайности впадать. БД (в которой реализована часть логики) + аппсервер (в котором реализована другая часть логики, расчеты, подготовка отчетных данных и т.п.) и клиент подключенный через веб сервисы (в котором тоже реализована часть логики). Вот вы говорите веб, вот представьте получили вы списки показаний например с АСКУЭ (1 список на 10000 ТУ, а то и больше) вы их че в случае с каналом 64к на e-mail будете отправлять чтоли? А отчеты в 200-300 страниц, тоже по мылу гонять? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 13:20 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin ВЫ всерьез считаете, что кто-то доверит какой-то организации учет своих услуг???!!! Вернитесь с небес на землю... А что здесь такого крамольного ? Мы уж лет 5, как предоставляем услуги расчетного интернет-центра сторонним организациям (ЖКХ, домофонная компания, торговый дом). На выходе квитанции, акты, счета-фактуры, отчеты и справки. Счета выставляются и в электронном виде: для удержания из зарплаты, для оплаты через городские платежные системы (в т.ч. через банкоматы, интернет, телефон). Услуги самые разнообразные (вода, электричество, тепло, вывоз мусора, охрана, аренда, сервисное обслуживание домофонов и охранных систем, и т.д.). Конечно, 10000 пользователей у нас нет (я думаю никогда и не будет) и соответственно проблем с этим связанных. Но идея вполне жизнеспособная. Мы используем: База данных - Oracle Сервер приложений - Baikonur У клиента - специализированный браузер ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 13:36 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1024вы думаете что ваш модуль установленный в сервер приложений выполнит подсчёт быстрее чем select sum(payment) from payments join customers where name='Рога и копыта' Никаких шансов интересно.. откуда такие стойкие заблуждения, что сервера приложений выполняют селекты и подобную работу за СУБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 13:39 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
пусть что угодно выпоняет. В случае скл сервера весь расчёт пройдёт быстрее и ресурсов потребует меньше. Практически всегда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 13:45 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1024пусть что угодно выпоняет. В случае скл сервера весь расчёт пройдёт быстрее и ресурсов потребует меньше. Практически всегда. Вы видимо с трудом представляете объем вычислений в поставленной задаче. Что на счет MSSQL то практикой доказано, что математические вычисления на T-SQL выполняются медленнее, чем классическими win32 средствами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 13:58 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1024пусть что угодно выпоняет. В случае скл сервера весь расчёт пройдёт быстрее и ресурсов потребует меньше. Практически всегда. а что он быстрее сделает? Например с одного сервера на другой передаст заархивированные и кодированные файлы документов? Или возьмет записи из одной СУБД, преобразует их к формату другой, запишет и т.п.? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:03 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
неправда. Чтобы сделать select sum(... отдельно от скл сервера нужно сделать выборку всех значение и просуммировать их. Само суммирование может быть хоть на ассемблере но при больших объёмах накладные расходы многократно превысят любой выигрыш в скорости расчёта: 1.данные нужно передать от скл сервера к расчётному модулю 2.данные не поместятся в память и их надо хранить на диске (хотя можно запрашивать данные кусками и считать по мере поступления, но это как-то реализовывать нужно) т.е. по сути придётся разрабатывать то что встроено в скл сервер ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:05 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1024неправда. Чтобы сделать select sum(... В вашем понятии вычисления это select sum() ? Вы чтонибудь слышали, об интерполляции, экстраполляции показаний ПУ? А о получении чисто аналитических данных, таких как потери в отдельно взятом районе? Это все тоже MSSQL будет считать, при таких количествах абонентов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:13 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
понятия не имею кто и что будет считать. Я сказал о том что сервер приложений в подавляющем большинстве случаев подменяет стандартный функционал скл сервера. И делает это хуже чем сам скл сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:22 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1024понятия не имею кто и что будет считать. Я сказал о том что сервер приложений в подавляющем большинстве случаев подменяет стандартный функционал скл сервера. И делает это хуже чем сам скл сервер. Никто и не говорил, что все нужно отдать серверу приложений. А "делает это хуже", не сервер приложений, а его разработчики. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:28 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
честно говоря не представляю как можно сделать лучше простую выборку с парой жойнов. Выкачать на сервер приложений таблицы и там сжойнить? Смешно. А зачем он тогда нужен? Для вывода на принтер, например может понадобиться. Для работы с данными скорей всего нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:33 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1024честно говоря не представляю как можно сделать лучше простую выборку с парой жойнов. Выкачать на сервер приложений таблицы и там сжойнить? Смешно. А зачем он тогда нужен? Для вывода на принтер, например может понадобиться. Для работы с данными скорей всего нет. Сдалась вам эта выборка... Выборка и делается всегда запросами к серверу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:40 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1024честно говоря не представляю как можно сделать лучше простую выборку с парой жойнов. Выкачать на сервер приложений таблицы и там сжойнить? Смешно. Вы действительно считаете что в приведенном ниже коде на ABAP select выполняет самостоятельно сервер приложений, а не нагружает этим СУБД? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. И зачем зациклились на выборках? Их выполняет сервер СУБД. Возьмите например задачу забрать с FTP файл, сделать его парсинг и записать в таблицы СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:40 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafmИ зачем зациклились на выборках? Их выполняет сервер СУБД. Возьмите например задачу забрать с FTP файл, сделать его парсинг и записать в таблицы СУБД. Я сделаю это только с помошью функционала, предлоставляемого сервером (DTS). Не нужно мне писать для этого апп. сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:52 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin iscrafmИ зачем зациклились на выборках? Их выполняет сервер СУБД. Возьмите например задачу забрать с FTP файл, сделать его парсинг и записать в таблицы СУБД. Я сделаю это только с помошью функционала, предлоставляемого сервером (DTS). Не нужно мне писать для этого апп. сервер. Хорошо, пусть так, а несколько тысяч пользователей с каналами в 64к вы предлагаете законнектить прямо к серваку? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:56 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... pkarklin iscrafmИ зачем зациклились на выборках? Их выполняет сервер СУБД. Возьмите например задачу забрать с FTP файл, сделать его парсинг и записать в таблицы СУБД. Я сделаю это только с помошью функционала, предлоставляемого сервером (DTS). Не нужно мне писать для этого апп. сервер. Хорошо, пусть так, а несколько тысяч пользователей с каналами в 64к вы предлагаете законнектить прямо к серваку? Не совсем понятно, что Вы хотели спросить: 1. Выдержит ли сервер несколько тысяч коннектов (а с чего бы ему не выдержать?) 2. Или, речь идет именно о ширине канала в контексте скачивания с FTP? Если второе, то забирать с фтп будет сервер, а не пользователь, уж у сервера то в инет канал должен быть хороший (раз мы хотим чего то скачивать). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 14:59 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Даешь 100 страниц уже к этому вечеру!!!!!!!!!!!!!!!!!!!!!!!! Переплюнем "Странные мысли о ...." :)) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:02 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Прохожий..... pkarklin iscrafmИ зачем зациклились на выборках? Их выполняет сервер СУБД. Возьмите например задачу забрать с FTP файл, сделать его парсинг и записать в таблицы СУБД. Я сделаю это только с помошью функционала, предлоставляемого сервером (DTS). Не нужно мне писать для этого апп. сервер. Хорошо, пусть так, а несколько тысяч пользователей с каналами в 64к вы предлагаете законнектить прямо к серваку? Не совсем понятно, что Вы хотели спросить: 1. Выдержит ли сервер несколько тысяч коннектов (а с чего бы ему не выдержать?) 2. Или, речь идет именно о ширине канала в контексте скачивания с FTP? Если второе, то забирать с фтп будет сервер, а не пользователь, уж у сервера то в инет канал должен быть хороший (раз мы хотим чего то скачивать). При чем тут FTP? Топик был если вы забыли, о расчетной биллинговой системе, а не об отправлялке файлов на FTP. Сервер то выдержит тысячи коннектов, но нужно ли это? Сможете ли вы на сервере легко реализовать логику способную отправлять и получать данные на таких узких каналах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:07 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
И чем таким отличается логика, которая должна работать на узких каналах, от обычной логики? :)) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:09 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... 1024неправда. Чтобы сделать select sum(... В вашем понятии вычисления это select sum() ? Вы чтонибудь слышали, об интерполляции, экстраполляции показаний ПУ? А о получении чисто аналитических данных, таких как потери в отдельно взятом районе? Это все тоже MSSQL будет считать, при таких количествах абонентов? А Вы что-нибудь слышали об SQL Server Analysis Services - составной части поставки MS SQL? Видимо нет! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:09 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....При чем тут FTP? Топик был если вы забыли, о расчетной биллинговой системе, а не об отправлялке файлов на FTP. И действительно, причем? Я отвечал не Вам. Вы задали вопрос на мой ответ, который с моим ответом на не Ваш вопрос не как не коррелируется. Прохожий.....Сервер то выдержит тысячи коннектов, но нужно ли это? Сможете ли вы на сервере легко реализовать логику способную отправлять и получать данные на таких узких каналах? Выдержит, не переживайте. Он для этого и предназначен. А вот как коррелируется реализация логики на сервере с шириной канала, мне не совсем понятно. Не потрудитесь объяснить, что ВЫ имели ввиду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:13 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygraИ чем таким отличается логика, которая должна работать на узких каналах, от обычной логики? :)) -- Tygra's -- Мои фотогалереи тут и тут Чем? Объемами передаваемой информации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:14 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Мне кажется, такая задача должна хорошо масштабироваться по регионам. Я бы предложил такую структуру: 1.N серверов = БД(данные по 1..M регионам) + App Server + Толстый клиент Пользователи работают с данными своего региона Число пользователей ограничено Легко масштабируется вырезанием из БД региона и размещением на отдельном сервере App Server + Толстый клиент обеспечивают сжатие трафика и безопасность В случае выхода из строя одного серера остальные работают 2.Один большОй сервер = БД(глобальная)+Репликатор+ App Server + Толстый клиент Репликатор собирает данные с региональных серверов Работают пользователи которым нужна глобальная информация Число пользователей ограничено Масштабируется железом По идее, если к глобальным данным не требуется доступ из ineta, то связку App Server + Толстый клиент - можно заменить на клиента коннектящегося прямо к глобальной базе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:22 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
есть опыт реализации подобных задач? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:25 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
leonidy З.Ы. и упаси вас господь от репликаций и проч. "стандартных" решений от MS. Ну, конечно, будем изобретать свои "решения". Эти решения успешно используют многие компании, одна из которых имеет филиалы в 80 регионах страны и все это на "стандартной" репликации от MS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:29 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... tygraИ чем таким отличается логика, которая должна работать на узких каналах, от обычной логики? :)) -- Tygra's -- Мои фотогалереи тут и тут Чем? Объемами передаваемой информации. Логика к объему не имеет никакого отношения :) Реализация передачи информации от сервера к клиенту - да, тут можно что-то говорить. Можно в вебсервисах жать зипом результат и передавать клиенту, там разжимать и обрабатывать. Но логика тут ни при чем, и СУБД ни при чем, и апп-сервер тоже ни при чем :) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:35 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1024есть опыт реализации подобных задач? Если вопрос ко мне, то да. Есть опыт: Проект1. БД1->Репликатор->БД2-AppServer-Толстый клиент Проект2. БД1-AppServer-Толстый клиент + шифрование и сжатие трафика ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:43 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygra Прохожий..... tygraИ чем таким отличается логика, которая должна работать на узких каналах, от обычной логики? :)) -- Tygra's -- Мои фотогалереи тут и тут Чем? Объемами передаваемой информации. Логика к объему не имеет никакого отношения :) Реализация передачи информации от сервера к клиенту - да, тут можно что-то говорить. Можно в вебсервисах жать зипом результат и передавать клиенту, там разжимать и обрабатывать. Но логика тут ни при чем, и СУБД ни при чем, и апп-сервер тоже ни при чем :) -- Tygra's -- Мои фотогалереи тут и тут Логика тут действительно нипричем, вот только, что бы, что то отправить клиенту, это что то нужно сформировать (тут и работает логика) и что то мне подсказывает, что это легче реализовать не на самом MSSQL и не на прямом к нему коннекте. То же самое и с полученными от клиента данными. Я непротивник двузвенки, скорее наоборот, но не в этой задаче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:46 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS...ВОПРОС: какую технологию использовать в качестве ОПТИМАЛЬНОЙ для сервера приложений?Нам советуют использовать JBoss и Tomcat.Некий чел упомянул WebSphere в связке DB/2, однако другой чел поднял его на смех и сказал, что на указанном железе и думать нечего, нужно только от IBM и не x86. ... немного воды... сервер - тот кто предоставляет услуги... клиент - тот кто пользуется предоставляемыми услугами... клиент-серверная технология означает реализацию в проекте как клиента так и сервера. увы по наследству это не передаётся и не наследуется... трёх-звенка, эн звенка и прочая муть - маркетинговый ход от мелкомягких.. апп.сервер - название от мелкомягких клиент-серверной архитектуры... немного примеров... знаю, что в далёкие 90 в Киеве поставили AS400 для сбора(в ввиде вечерних транзакций) и анализа каждодневного состояния дел фирмы CocaColla (если щаз не склерозю)... немного фундамента... апп. сервер (пущай будет так обзываться - не суть) необходим только тогда когда есть централизованные задачи, которые не может более продуктивнее и оптимальнее выполнить БД. Щаз таких задач всё меньше и меньше (если абстрактно), а вот если применимо к задаче - вполне может быть что БД необходимо будет "разгрузить". Ну например логику удержания каналов в поднятом состоянии оптимально с точки зрения параметров и времени удержания - вряд ли стоит тащить на хранимки в БД резюме.. лично я не вижу работы для апп. сервера. Возможно плохо представляю задачу - хз. Озвученное Вами железо - не серьёзный подход. На мой взгляд плясать нуна начинать от решений IBM(as400 я имею ввиду) не меньше. Всё остальное мягко говоря не серьёзно при таком кол-ве транзакций и клиентов... с уважением (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:48 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторЕсли вопрос ко мне, то да. Есть опыт: вопрос был про объёмы аналогичные указаным автором ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:49 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... tygra Прохожий..... tygraИ чем таким отличается логика, которая должна работать на узких каналах, от обычной логики? :)) Чем? Объемами передаваемой информации. Логика к объему не имеет никакого отношения :) Реализация передачи информации от сервера к клиенту - да, тут можно что-то говорить. Можно в вебсервисах жать зипом результат и передавать клиенту, там разжимать и обрабатывать. Но логика тут ни при чем, и СУБД ни при чем, и апп-сервер тоже ни при чем :) Логика тут действительно нипричем, вот только, что бы, что то отправить клиенту, это что то нужно сформировать (тут и работает логика) и что то мне подсказывает, что это легче реализовать не на самом MSSQL и не на прямом к нему коннекте. То же самое и с полученными от клиента данными. Я непротивник двузвенки, скорее наоборот, но не в этой задаче. А можно попробробнее? :) Как логика формирует то, что отправить клиенту, и почему на MSSQL это нельзя а где-то еще можно? С примером :) Не забывая про веб-сервисы, которые скорее всего желательно использовать, дабы не давать прямых коннектов к БД. Но все же, причем тут логика и вынос? -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:52 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Вот я испрашивал: что вы считаете сервером приложений. Я бы предложил считать сервером приложений сервис, который формирует и отправляет клиенту ПРИЛОЖЕНИЕ. На то он и сервер приложений. Как правило, конечно, не всё сразу, а ту(те) форму(формы), которые клиент запросил. Основное назначение сервера - не что-то там разгрузить, а приложение предоставить. По запросу. Наиболее наглядный пример такого - веб-сервер. Еще раз спрашиваю: вы собираетесь каждому из 10 000 пользователей приложение инсталлировать? Инсталляции рассылать с инструкцией? А обновления рассылать? Это же целый механизм! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:55 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygraА можно попробробнее? :) Как логика формирует то, что отправить клиенту, и почему на MSSQL это нельзя а где-то еще можно? С примером :) Не забывая про веб-сервисы, которые скорее всего желательно использовать, дабы не давать прямых коннектов к БД. Но все же, причем тут логика и вынос? -- Tygra's -- Мои фотогалереи тут и тут А кто сказал, что на MSSQL нельзя? Я помоему сказал как я бы подошел к задаче, а не можно, нельзя, ненадо выдергивать отдельные фразы из обсуждения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 15:56 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1024 авторЕсли вопрос ко мне, то да. Есть опыт: вопрос был про объёмы аналогичные указаным автором У меня работало он-лайн 110-120 пользователей на двухголовом хеоне+раид1. Не знаю какое железо нужно чтобы поддерживать хотя бы 2500 юзеров. Поэтому и предлагаю распрделенную схему... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 16:01 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
NetObserverУ меня работало он-лайн 110-120 пользователей на двухголовом хеоне+раид1. И это было действительно число активных пользователей в секунду: Код: plaintext или это число коннектов? NetObserverНе знаю какое железо нужно чтобы поддерживать хотя бы 2500 юзеров. Поэтому и предлагаю распрделенную схему... Тоже активных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 16:06 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
А железо, ведь, определяется не только количеством юзеров. ведь пока толком неизвестно, что такого страшного эти юзеры будут делать. Если будут запрашивать мегатонные выборки - да, тяжело придется. Но в нормальном случае этого не требуется. А требуется окрывать карточку одного абонента. Одного. Ничего в этом страшного нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 16:06 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
BrokenPotА железо, ведь, определяется не только количеством юзеров. ведь пока толком неизвестно, что такого страшного эти юзеры будут делать. Если будут запрашивать мегатонные выборки - да, тяжело придется. Но в нормальном случае этого не требуется. А требуется окрывать карточку одного абонента. Одного. Ничего в этом страшного нет. Карточки не самое страшное, самое страшное это навигация по ней, но и это не все, помимо этого есть мегатонные загрузки в базу и такие же выгрузки, да еще и плюс чисто математические расчеты. Кстати тут забыли о главном достоинстве трезвенки, клиенту побарабану какая БД юзается и где она вообще, при желании можно хоть несколько баз создать и юзер об этом даже знать не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 16:15 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinИ это было действительно число активных пользователей в секунду: или это число коннектов? У меня специфичная задача: каждый он-лайн клиент кроме обычной работы с сервером запрос-ответ, получает от сервера приложений постоянный поток данных в среднем ~1К\сек. Потоки жмутся\шифруюся сервером. Кроме того на основании этих данных клиент периодически генерит запросы на сервер без участия человека. Так что каждый он-лайн клиент создает обьективную нагрузку на сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 16:18 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....Кстати тут забыли о главном достоинстве трезвенки, клиенту побарабану какая БД юзается и где она вообще, при желании можно хоть несколько баз создать и юзер об этом даже знать не будет. И тут мы опять подошли к главному вопросу - что такое трехзвенка?! Что такое апп-сервер? Что он должен делать, а что нет? Считаем вебсервисы, которые тупо передают селект от базы во вне в виде xml или чего еще, апп-сервером и трехзвенкой? -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 16:18 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygra Прохожий.....Кстати тут забыли о главном достоинстве трезвенки, клиенту побарабану какая БД юзается и где она вообще, при желании можно хоть несколько баз создать и юзер об этом даже знать не будет. И тут мы опять подошли к главному вопросу - что такое трехзвенка?! Что такое апп-сервер? Что он должен делать, а что нет? Считаем вебсервисы, которые тупо передают селект от базы во вне в виде xml или чего еще, апп-сервером и трехзвенкой? -- Tygra's -- Мои фотогалереи тут и тут Вот именно, что они не должны тупо передавать таблицы с сервака клиенту! Т.е. они должны еще и часть работы выполнять! Зачем все валить на сервер БД? Ему и так будет тяжело! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 16:22 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....есть мегатонные загрузки в базу и такие же выгрузки, да еще и плюс чисто математические расчеты. Да, это верно, но 10 000 пользователей их не делают. Прохожий.....Кстати тут забыли о главном достоинстве трезвенки, клиенту побарабану какая БД юзается и где она вообще, при желании можно хоть несколько баз создать и юзер об этом даже знать не будет. А в случае двухзвенки разве Марии Ивановне не по барабану, какая БД юзается и сколько их там вообще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 17:15 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... tygra Прохожий.....Кстати тут забыли о главном достоинстве трезвенки, клиенту побарабану какая БД юзается и где она вообще, при желании можно хоть несколько баз создать и юзер об этом даже знать не будет. И тут мы опять подошли к главному вопросу - что такое трехзвенка?! Что такое апп-сервер? Что он должен делать, а что нет? Считаем вебсервисы, которые тупо передают селект от базы во вне в виде xml или чего еще, апп-сервером и трехзвенкой? -- Tygra's -- Мои фотогалереи тут и тут Вот именно, что они не должны тупо передавать таблицы с сервака клиенту! Т.е. они должны еще и часть работы выполнять! Зачем все валить на сервер БД? Ему и так будет тяжело! Кто сказал, что серверу БД будет тяжело? И откуда известно, что апп-сервер должен что-то обязательно делать кроме передачи? И чем он, апп-сервер, может помочь серверу БД и системе в целом? Лишними проблемами? :) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 17:33 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygra Прохожий..... tygra Прохожий.....Кстати тут забыли о главном достоинстве трезвенки, клиенту побарабану какая БД юзается и где она вообще, при желании можно хоть несколько баз создать и юзер об этом даже знать не будет. И тут мы опять подошли к главному вопросу - что такое трехзвенка?! Что такое апп-сервер? Что он должен делать, а что нет? Считаем вебсервисы, которые тупо передают селект от базы во вне в виде xml или чего еще, апп-сервером и трехзвенкой? -- Tygra's -- Мои фотогалереи тут и тут Вот именно, что они не должны тупо передавать таблицы с сервака клиенту! Т.е. они должны еще и часть работы выполнять! Зачем все валить на сервер БД? Ему и так будет тяжело! Кто сказал, что серверу БД будет тяжело? И откуда известно, что апп-сервер должен что-то обязательно делать кроме передачи? И чем он, апп-сервер, может помочь серверу БД и системе в целом? Лишними проблемами? :) -- Tygra's -- Мои фотогалереи тут и тут Я тоже считаю, что сервер приложений если может помочь чем-нибудь, то - раздачей приложений пользователям. Что ему еще делать? Ума не приложу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 17:57 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Что такое раздача? Что такое приложение? Или что такое пользователь? Или ваш сервер приложений приложения не отдает? Тогда он - не сервер приложений, а сервер чего-то другого. Сервер расчетов. Сервер бизнес-логики. Сервер преобразования данных. Сервер чего-то еще, чего вы на него нагрузили. См. мой пост выше о сервере приложений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 18:12 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygra авторраздачей приложений пользователям. Это чего такое? :) Это когда у клиента на машине ничего нет, кроме небольшого клиентского приложения. Весь контент хранится централизовано на сервере приложений. Клиент подключаясь к выбранному серверу приложений (где бы он не находился), получает от него доступный контент и работает с ним не заморачиваясь какие там СУБД, где они размещены, один сервер или несколько. Примерно так . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 18:22 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Ну прочитайте вот эту чтоли статью: http://www.gotdotnet.ru/LearnDotNet/XMLWebServices/749.aspx Там вроде четко обозначены достоинства web сервисов перед прямыми коннектами. Со времен написания статьи конечно много времени прошло, но многое до сих пор актуально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 18:24 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Н-да...Туману только добавилось...Да и дисскусия уходит в сторону. Хотелось бы резюмировать. 0) Мне лично по душе двухзвенка, да еще и на MS SQL ибо я это знаю и делал многократно, но мне также нужно понять аргументацию предлагающих апп.сервер, т.е почему они утверждают, что без него не обойтись? при том, что я безусловно резко понижу требования к числу юзеров. Как справедливо было замечено выше - лучше добавлять базы данных по мере необходимости и умощнять сервера. Но вдруг и правда MS SQL в какой-то момент не прожует поток данных? и эти хлопцы окажуться правы? у меня нет опыта на таких крупных системах и мне надо авторитетное мнение. 1) Если все же придется выбирать апп.сервер, кто-нибудь может подсказать по JBoss - что за зверь? как он себя ведет в реальных проектах? сложность разработки для него? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 08:24 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....Ну прочитайте вот эту чтоли статью: http://www.gotdotnet.ru/LearnDotNet/XMLWebServices/749.aspx Там вроде четко обозначены достоинства web сервисов перед прямыми коннектами. Со времен написания статьи конечно много времени прошло, но многое до сих пор актуально. Упасть не встать какая полезная статья. Вот, собственно и все. Запускаем нашу программу, вводим запрос, жмем Run и получаем либо набор записей на экране, либо сообщение о количестве обработанных записей, либо сообщение об ошибке. Как мы видим, количество кода, требуемое для работы с веб службой WebDBConnector минимально, удобство в работе налицо. Hello, World! - 2. А теперь рассмотрим чем постулирует автор: Безопасность. Если доступ к SQL серверу осуществляется напрямую через IP, возникает брешь в безопасности какна стороне клиента, так и на сервере. Причем клиент может быть отгорожен фаерволом или прокси, чтовообще делает невозможным прямой доступ к SQL серверу. Детский сад, да и только. Какая разница к чему осуществляется доступ по IP? Брешь в безопасности м.б. в любой системе, внезависимости, выставлен SQL Server на ружу или нет. Все зависит от кривизны рук управляющего этой безопасность. Автор не в курсе возможностей SQL Serverа в плане обеспечения безопастности начиная от шифрования триффика и заканчивая шифрования самих данных. Надежность. Зачастую связь через Интернет является нестабильной, возможны обрывы связи. Если программа,работающая с SQL использует постоянное или длительное соединение с сервером это будет приводить к частым ошибками сделает невозможным стабильную работу такой программы. Весь стандартный инструментарий MS SQL Server работаетименно таким образом - соединение с базой данных поддерживается постоянно. Бред... Соединение нужно только на моменты обращения к серверу. Пользователь может вообще работать в "портфельном" режиме. Скорость. Стандартные протоколы обмена данными между SQL сервером и клиентом, как правило, не расчитаны дляработы в интернет. Передается множетсво избыточной информации и т.д. В результате время между запросом иполучением результирующего набора данных может стать очень большим. Возможны частые таймауты, т.е. программабудет считать, что сервер не отвечает, в то время как информация просто поступает с очень большой задержкой. Зачот! Однозначно!!! Автор и понятия не имеет о протоколах работы SQL Serverа. ЗЫ. Как говорится, "иногда лучше жевать, чем говорить". ((с) не мой) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 08:37 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторМне лично по душе двухзвенка, да еще и на MS SQL ибо я это знаю и делал многократно, но мне также нужно понять аргументацию предлагающих апп.сервер, т.е почему они утверждают, что без него не обойтись? Ну, почему же обязательно двузвенка?! Сделайте WEB доступ, но без апп.сервера! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 08:38 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin авторМне лично по душе двухзвенка, да еще и на MS SQL ибо я это знаю и делал многократно, но мне также нужно понять аргументацию предлагающих апп.сервер, т.е почему они утверждают, что без него не обойтись? Ну, почему же обязательно двузвенка?! Сделайте WEB доступ, но без апп.сервера! Мне тут два момента не понятны: 0) если использовать вебсервисы для доступа к MSSQL использование IIS обязательно? 1) если, как Вы советуете, пользовать MSSQL через вебдоступ (то бишь IIS), вебсервисы - обязательны? кажется не обязательны или мне кажется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 08:57 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1. Можно и без него. 2. Совсем не обязательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:03 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin1. Можно и без него. 2. Совсем не обязательно. Т.о получаем варианты 1) MSSQL+webservice+IIS+browser 2) MSSQL+webservice+desktop application 3) MSSQL+IIS+browser На Ваш взгляд наилучшее соотношение по параметрам надежность/безопасность/удобство пользователя какой вариант дает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:16 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin2 Это будет работать на слабых каналах? скажем на dial-up? хотя бы минимум комфорта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:32 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS pkarklin2 Это будет работать на слабых каналах? скажем на dial-up? хотя бы минимум комфорта? Еще раз. Работа на плохих каналах не так сильно зависит от выбранной архитектуры. Вы и с апп. сервером можете любой канал завалить, если будете таскать огромные объемы на клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:36 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
А ведь как-то надо получать столистовые отчеты...какие приемы здесь возможны? предположим мы все предусмотрели: и транзакции компактные, и курсорами не злоупотребляем, а по возможности вообще избегаем, но ведь отчеты есть отчеты - сколько попросил столько и будет? какую методу Вы бы применили? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:40 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
На стороне вебсервиса топтать, передавать, на клиенте распаковывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:47 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinНа стороне вебсервиса топтать, передавать, на клиенте распаковывать. это у вебсервиса есть собственные средства упаковки/сжатия т.е. это свойство запроса к сервису? или делать файл, паковать внешними средствами и полученный файл ими же раскрывать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:51 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS0) Мне лично по душе двухзвенка, да еще и на MS SQL ибо я это знаю и делал многократно, но мне также нужно понять аргументацию предлагающих апп.сервер, т.е почему они утверждают, что без него не обойтись? при том, что я безусловно резко понижу требования к числу юзеров. Как справедливо было замечено выше - лучше добавлять базы данных по мере необходимости и умощнять сервера. Но вдруг и правда MS SQL в какой-то момент не прожует поток данных? и эти хлопцы окажуться правы? у меня нет опыта на таких крупных системах и мне надо авторитетное мнение. Еще раз повторим - поток данных, который обрабатывает сервер БД, и апп-сервер - это две разные вещи, никак между собой не связанные. Если передавать поток данных через 10 звеньев, то он от этого не станет меньше. GeenSА ведь как-то надо получать столистовые отчеты...какие приемы здесь возможны? предположим мы все предусмотрели: и транзакции компактные, и курсорами не злоупотребляем, а по возможности вообще избегаем, но ведь отчеты есть отчеты - сколько попросил столько и будет? какую методу Вы бы применили? Отчет придется передавать в любой системе - хоть двух хоть в пятизвенной, потому разницы нет никакой. Главное правильно сфформировать отчет, чтобы не передавалось лишних данных - это касается вообще любых архитектур, т.к. большим трафиком можно и локалку нагнуть. GeenS pkarklin1. Можно и без него. 2. Совсем не обязательно. Т.о получаем варианты 1) MSSQL+webservice+IIS+browser 2) MSSQL+webservice+desktop application 3) MSSQL+IIS+browser На Ваш взгляд наилучшее соотношение по параметрам надежность/безопасность/удобство пользователя какой вариант дает? 2 вариант - я доволен его работой. IIS конечно обязателен в этом случае. Можно кэшировать часто используемые данные, которые редко меняются (вебсервисы) - это к тому, что если сильно захочется, то можно таки разгрузить сервер БД :) К тому же, можно увеличить число серверов с IIS, если потребуется. -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:52 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS pkarklinНа стороне вебсервиса топтать, передавать, на клиенте распаковывать. это у вебсервиса есть собственные средства упаковки/сжатия т.е. это свойство запроса к сервису? или делать файл, паковать внешними средствами и полученный файл ими же раскрывать? Для .net наверняка есть библиотеки, которые на лету жмут информацию, например в zip. Получаете от сервера ответ, жмете и отправляете в результат вебсервиса, клиент получает и разжимает. Для Delphi например тоже есть библиотеки для сжатия-разжатия. -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:54 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygra и pkarklin Агромное СПАСИБО и всяческий респект! Начало укладываться что-то в голове... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:57 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenSНачало укладываться что-то в голове... в итоге пришли к апп-серверу интересно со стороны наблюдать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 10:48 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS Азбука . Внизу смотрите, где живут веб-сервисы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 10:58 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Ага. Википедия - кладезь знаний. :) В указанной статье все правильно написано. А у Вас другое мнение по тому где живут веб-сервисы? Или слово Сервер приложений настолько Вам не любо, что готовы как угодно извернуться, лишь бы не признать его существование? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 11:11 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafm GeenSНачало укладываться что-то в голове... в итоге пришли к апп-серверу интересно со стороны наблюдать. Да как раз получается, что нет, не к апп-серверу, а к трехзвенке, если можно это так назвать :) Потому как по вашим с прохожим определениям, апп-сервер должен раздавать приложения :) А в данном случае он ничего не раздает - он только данные переправляет из БД клиенту и обратно. Это можно считать заменой ODBC :)) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 11:21 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafmВ указанной статье все правильно написано. А у Вас другое мнение по тому где живут веб-сервисы? Или слово Сервер приложений настолько Вам не любо, что готовы как угодно извернуться, лишь бы не признать его существование? В 958 повторяю, что не являюсь противником N-звенок, если они употребляются к месту. Всегда выступаю оппоннентом тех, кто хочет перенести ВСЮ обработку на апп. сервер (как на одном из форумов join и sorting). То, что умеет делать СУБД лучше, должно делаться на стороне СУБД. Называть промежуточное (ые) звено (ья) можно как угодно и это необязательно должен быть один из серверов, приведенных в списке в статье. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 11:24 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygraЭто можно считать заменой ODBC :)) web service = ODBC :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 11:29 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinкак на одном из форумов join и sorting это уже, мягко говоря, перемудрили. Думаю не стоит на такие отклонения серьезно обращать внимание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 11:43 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafm pkarklinкак на одном из форумов join и sorting это уже, мягко говоря, перемудрили. Думаю не стоит на такие отклонения серьезно обращать внимание. Гм... Это было описание архитектуры eBay. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 11:45 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafm tygraЭто можно считать заменой ODBC :)) web service = ODBC :) И то и то предоставляет доступ к СУБД => по сути одно и то же :)) Это когда в сервисах не зашита бизнес-логика. -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 12:07 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygraПотому как по вашим с прохожим определениям, апп-сервер должен раздавать приложения :) А в данном случае он ничего не раздает - он только данные переправляет из БД клиенту и обратно. -- Tygra's -- Мои фотогалереи тут и тут О! Правда, это Я на этом настаиваю :):) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 12:17 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Вас послушать, так зачем люди ASP.NET учат, трехзвенки городят? Взять да и перейти всем на прямые коннекты к MSSQL, кстати я непонял где автор вообще сказал, что он хочет MSSQL? И юзать эти прямые коннекты наверно так: Тынц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 12:21 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinГм... Это было описание архитектуры eBay. Вы про это что-ли ? То что SP выкинули, тригеры вижу... Чтобы join-или не вижу. Хотя правильно некоторые подмечают, что бывают ситуации когда такие операции быстрее сделать самому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 12:26 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafm pkarklinГм... Это было описание архитектуры eBay. Вы про это что-ли ? То что SP выкинули, тригеры вижу... Чтобы join-или не вижу. Хотя правильно некоторые подмечают, что бывают ситуации когда такие операции быстрее сделать самому. Страница 22 Ну, чего уж. Давайте и обеспечение ACID на сторону апп.сервера унесем. Так еще сотню лимонов строк кода можно написать. Насчет ситуаций, м.б... В редких определенных случаях. Но вот так чтоб поголовно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 12:45 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... pkarklin Вас послушать, так зачем люди ASP.NET учат, трехзвенки городят? Взять да и перейти всем на прямые коннекты к MSSQL, кстати я непонял где автор вообще сказал, что он хочет MSSQL? И юзать эти прямые коннекты наверно так: Тынц Гм... Это ВЫ спросите у тех, кто учит и городит. Свою точку зрения я уже изложил, причем неоднократно и не только в этом топике. Это м.б. не MS SQL, а любой из серверов большой тройки. Чем Вам, собственно, тынц, не понравился? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 12:47 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinГм... Это ВЫ спросите у тех, кто учит и городит. Свою точку зрения я уже изложил, причем неоднократно и не только в этом топике. Городим... И будем городить, на данный момент горожу четырехзвенку на тех самых веб-сервисах. И жутко доволен! Если бы стали делать это же самое в двузвенке, получислось бы намного сложнее и геморойнее! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 12:51 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....Городим... И будем городить, на данный момент горожу четырехзвенку на тех самых веб-сервисах. И жутко доволен! Если бы стали делать это же самое в двузвенке, получислось бы намного сложнее и геморойнее! Ну, что ж. Я с удовольствием (говорю это без иронии) послушаю Вашу success story. Очень будет интересно в деталях узнать, при реализации какой функциональности и какой геморой с его реализацией на двузвенке заставил Вас принять решение о разработке N-звенки. Можно пару примерчиков? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 12:58 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Прохожий.....Городим... И будем городить, на данный момент горожу четырехзвенку на тех самых веб-сервисах. И жутко доволен! Если бы стали делать это же самое в двузвенке, получислось бы намного сложнее и геморойнее! Ну, что ж. Я с удовольствием (говорю это без иронии) послушаю Вашу success story. Очень будет интересно в деталях узнать, при реализации какой функциональности и какой геморой с его реализацией на двузвенке заставил Вас принять решение о разработке N-звенки. Можно пару примерчиков? Лично в моем случае балансировка загрузки тех самых узких каналов, и отсутствие амбиций приобретать суперкомпьютер и подключать его к гигабитным каналам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:01 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... pkarklin Вас послушать, так зачем люди ASP.NET учат, трехзвенки городят? Взять да и перейти всем на прямые коннекты к MSSQL, кстати я непонял где автор вообще сказал, что он хочет MSSQL? И юзать эти прямые коннекты наверно так: Тынц В первом постер автор отверг MSSQL, однако причина не столь важна, чтобы ее нельзя было снять. Если автор сумеет доказать, что предлагаемое решение с использованием юникс и бесплатного апп.сервера JBoss не оптимально, почему не рассмотреть платформу MS ? Не вижу препятствий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:01 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinСтраница 22 Насчет ситуаций, м.б... В редких определенных случаях. Но вот так чтоб поголовно... ага,спасибо, увидел. Имхо, в случае с eBay наверное не поголовно. На ту же сортировку списка дергать СУБД накладно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:02 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
по JBoss - так же не всё однозначно. Он вытянет вобще подобное? У IBM есть бесплатный вариант WebSphere, не знаю насколько лучше но всёж ибм. Да и вообще говорить о крупной системе и пытаться экономить переходя на опенсурс без всякой поддержки по-моему не особо правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:07 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafmНа ту же сортировку списка дергать СУБД накладно. Давайте так. Классическая двузвенка. Набор данных при первом запросе на клиента выдается с определенной в хп дефолтной сортировкой, которая отображается в гриде в заголовке столбца. Если пользователь хочет пересортировать набор он просто кликает по соответствующему заголовку. Сортировка выполняется локально, зачем еще раз запрашивать СУБД или апп. сервер? Тем более, что пользователь захотел отсортировать данные, которые были закешированы на клиенте и в которые он уже внес изменения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:07 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....Лично в моем случае балансировка загрузки тех самых узких каналов, и отсутствие амбиций приобретать суперкомпьютер и подключать его к гигабитным каналам. Гм... А почему бы кластер с балансировкой нагрузки не сделать (Oracle RAC). Ну или Federated Database Servers на базе MS SQL? Зачем супер компютер? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:10 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
1024по JBoss - так же не всё однозначно. Он вытянет вобще подобное? У IBM есть бесплатный вариант WebSphere, не знаю насколько лучше но всёж ибм. Да и вообще говорить о крупной системе и пытаться экономить переходя на опенсурс без всякой поддержки по-моему не особо правильно. Хм...пойду посмотрю на ибм. Тогда вероятно можно будет использовать связку с DB/2...но где найти прогера на DB/2 ? в наших краях абсолютно нереально...или MS, или ораклисты, где-то я слышал есть мужичок на Sybase вещи ваяет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:15 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Прохожий.....Лично в моем случае балансировка загрузки тех самых узких каналов, и отсутствие амбиций приобретать суперкомпьютер и подключать его к гигабитным каналам. Гм... А почему бы кластер с балансировкой нагрузки не сделать (Oracle RAC). Ну или Federated Database Servers на базе MS SQL? Зачем супер компютер? Вы живете по принципу - "Зачем просто, если можно сложно"? Ну а загрузку каналов клиентов которые тоже от 64к до 256к на клиента, как распределить? У меня например часть инфы от клиента идет на головной сервер ночью, предлагаете городить очередные спагетти? Или держать 10-30 компов в региональных отделениях круглосуточно подключенными к головному серверу? Я нигде не говорил, что чего то нельзя реализовать в двузвенке, но есть такое понятие как затраты на реализацию! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:22 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... Вы живете по принципу - "Зачем просто, если можно сложно"? Гм... Мне кажется, все как раз наоборот. Прохожий..... Ну а загрузку каналов клиентов которые тоже от 64к до 256к на клиента, как распределить? Куда чего Вы хотите распределять? У Вас же клиенты на узком канале сидят, а не сервер?! Или...??? авторУ меня например часть инфы от клиента идет на головной сервер ночью, предлагаете городить очередные спагетти? Пусть идет. Макароны тут причем? авторИли держать 10-30 компов в региональных отделениях круглосуточно подключенными к головному серверу? Нужны данные - подключены. Не нужны - не подключены. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:29 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin мы об он-лайн сервисе говорим? Какая тут классическая двухзвенка. Это уже крайность, но с другого конца только. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:31 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
2авор зачем дб2. По какому спецы есть по тому и рассматривайте. Хоть по фокспро. Про вебсферу я к тому что этот момент так же как и остальные должен подвергаться критической оценке. Серверов приложений полно разных развелось, решений только вменяемых на них нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:35 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafmмы об он-лайн сервисе говорим? Какая тут классическая двухзвенка. Это уже крайность, но с другого конца только. :) Вы о чем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:36 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Куда чего Вы хотите распределять? У Вас же клиенты на узком канале сидят, а не сервер?! Или...??? Я распределяю нагрузку по ВРЕМЕНИ, если 10 клиентов одновременно начнут таскать десятки мегабайт инфы работа встанет! Предложения таскать эту нагрузку через FTP или мыло пользователям не нравятся и не удивляйтесь, что есть еще люди несогласные с программистами, в жизни обычно программист делает то, что хочет пользователь, а не наоборот! pkarklin Нужны данные - подключены. Не нужны - не подключены. Данные нужны головному серверу, а не им! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:40 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin iscrafmмы об он-лайн сервисе говорим? Какая тут классическая двухзвенка. Это уже крайность, но с другого конца только. :) Вы о чем? pkarklinДавайте так. Классическая двузвенка. Набор данных при первом запросе на клиента выдается с определенной в хп дефолтной сортировкой, которая отображается в гриде в заголовке столбца. Если пользователь хочет пересортировать набор он просто кликает по соответствующему заголовку. Сортировка выполняется локально, зачем еще раз запрашивать СУБД или апп. сервер? Тем более, что пользователь захотел отсортировать данные, которые были закешированы на клиенте и в которые он уже внес изменения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:42 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... Я распределяю нагрузку по ВРЕМЕНИ, если 10 клиентов одновременно начнут таскать десятки мегабайт инфы работа встанет! Они у Вас действительн по столько инфы таскают? Что за инфа? авторДанные нужны головному серверу, а не им! Так почему же Вы отвергли идею с репликацией? Выбранная Вами СУБД не позволяет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:56 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
2 iscrafm Вот Вы о чем... Чем Вас не устроила моя "локальная сортировка"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 13:58 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Они у Вас действительн по столько инфы таскают? Что за инфа? Порнопродукцию таскают, в отделения и обратно... :) Вы вот тут громче всех кричите, автору нужна двузвенка. Опишите схему работы данной двузвенки на конкретных примерах поставленной задачи (отправка данных, получение данных, расчеты, отчеты и т.п.) и поясните в каждом из пунктов в чем выгода по скорости работы и по затратам на реализацию по сравнению с трехзвенкой. Может вы нас действительно переубедите, и заодно автору очень интересно будет ваше представление! Я действительно не видел столь масштабных и приемлемо работающих двузвенок, может ВЫ нам откроете глаза? Дерзайте! Нам всем уже интересно! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:12 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
2 Прохожий..... Понятно. Лучший способ защиты - это нападение. ПрохожийВы вот тут громче всех кричите, автору нужна двузвенка. Я тут здесь громче всех кричу, что приемущества, приписываемые многозвенке некоторыми ее апологетами, в большинстве случаев такими не являются, и лишь только вносят лишнее усложнение в систему. Прохожий.....Опишите схему работы данной двузвенки на конкретных примерах поставленной задачи (отправка данных, получение данных, расчеты, отчеты и т.п.) и поясните в каждом из пунктов в чем выгода по скорости работы и по затратам на реализацию по сравнению с трехзвенкой. Думаю, тысяч за $5 000 я бы взялся набросать техническую архитектуру для автора, но при наличие чуть более подробного ТЗ. Советы я могу давать бесплатно. На "слабо" меня брать не надо. Пока от Вас я только и слышу что "это будет работать медлено", это "вообще не реализуемо" без каких-либо расчетов скорости и затрат на реализацию. авторЯ действительно не видел столь масштабных и приемлемо работающих двузвенок, может ВЫ нам откроете глаза? Дерзайте! Нам всем уже интересно! Я Вам уже упоминал о крупной компании-дистрибьютере, имеющую филиалы в 80 регионах (от Калиниграда до Владивостока) в которых работает двузвенка + репликация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:23 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Сорри, рука дрогнула... Продолжу про репликацию. Выже стали изобретать велосипед, реализуя обмен с головным сервером самостоятельно. Еще раз спрошу - это невозможно было реализовать функционалом выбранной вами СУБД? Какая, кстати, она? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:25 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Добрый день. Может повторюсь, так как не очень внимательно прочитал все сообщения, слишком много не по теме. По опыту скажу. Во первых. Все таки определитесь чего вы хотите и постройте приблизительную архитектуру. Если много клиентов и тонкие каналы, только Web доступ и ничего больше. На это есть два аргумента, первый запаритесь клиентские места обновлять (или разоритесь на системы автом. обновления, либо лицензии на терминальный доступ), во вторых HTTP все таки хорошо живет на тонких каналах. Во вторых. Определитесь банально с деньгами. Прикинте примерную смету. Мне почему то показалось что Вы немного путаете сервера приложений (WebLogic, WebSphere, EAS, Oracle App Server, SharePoint ну и так далее) и веб сервера (IIS, Apache), может я и ошибаюсь). Конечно в большинство серверов приложений интегрированы web сервера, но все таки это разные вещи. К чему я это, в большинство серверов приложений поддерживают дополнительные возможности типа очереди сообщений, кластеризация и так далее, все это стоит деньги и не малые. Затем вам нужно определится, какими знаниями в части разработки вы распологаете, все таки J2EE и . NET различаются :)) и цены на разработку тоже. Я думаю что после того как вы ответите на эти три вопроса все встанет на свои места. Остальное дела техники и денег. От себя скажу не предстовлая правто ваши задачи От себя скажу не представляя правда ваши задачи СУБД<> Server J2EE<>WEB SERVER<>HTTP Client Это позволит вам обеспечить гибкость системы и потратить не малые деньги :)) Удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:34 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinСорри, рука дрогнула... Продолжу про репликацию. Выже стали изобретать велосипед, реализуя обмен с головным сервером самостоятельно. Еще раз спрошу - это невозможно было реализовать функционалом выбранной вами СУБД? Какая, кстати, она? Репликация в данной задаче действительно как к телеге пятое колесо, но не будем зацикливаться на моей задаче, она работает, все вполне довольны, да и существенно отличается от поставленной автором задачи. Почему мне интересна данная тема? Потому, что я работал около 4 лет в биллинге именно той самой энергетики и коммунальных услуг, нет, подобных проектов не разрабатывал, но имею представление о том чего хочет автор и без ТЗ и потому дико сомниваюсь, что двузвенкой в конечном результате все будут довольны! Более того, скажу, что в трезвенке вида сервер - вебсервис - GUIклиент будет тяжело найти удобные решения для каналов в 64к. pkarklinДумаю, тысяч за $5 000 я бы взялся набросать техническую архитектуру для автора За 5000 автор и сам напишет нехуже вас... Для чего я вас об этом попросил, я хочу видеть реальную выгоду двузвенки (ну вот интересно мне), пока от вас поступали только голословные заявления, приведите хоть один пример в поставленной задаче, где двузвенка отработает на 20, 30, 40% быстрее трезвенки и потребует не больших финансовых затрат. Как вы вообще видите снижение трафика между клиентом и сервером в двузвенке? Про трезвенку я уже говорил, сжатие потоков? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:46 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
ХабаровскДобрый день. Может повторюсь, так как не очень внимательно прочитал все сообщения, слишком много не по теме. По опыту скажу. Во первых. Все таки определитесь чего вы хотите и постройте приблизительную архитектуру. Если много клиентов и тонкие каналы, только Web доступ и ничего больше. На это есть два аргумента, первый запаритесь клиентские места обновлять (или разоритесь на системы автом. обновления, либо лицензии на терминальный доступ), во вторых HTTP все таки хорошо живет на тонких каналах. Во вторых. Определитесь банально с деньгами. Прикинте примерную смету. Мне почему то показалось что Вы немного путаете сервера приложений (WebLogic, WebSphere, EAS, Oracle App Server, SharePoint ну и так далее) и веб сервера (IIS, Apache), может я и ошибаюсь). Конечно в большинство серверов приложений интегрированы web сервера, но все таки это разные вещи. К чему я это, в большинство серверов приложений поддерживают дополнительные возможности типа очереди сообщений, кластеризация и так далее, все это стоит деньги и не малые. Затем вам нужно определится, какими знаниями в части разработки вы распологаете, все таки J2EE и . NET различаются :)) и цены на разработку тоже. Я думаю что после того как вы ответите на эти три вопроса все встанет на свои места. Остальное дела техники и денег. От себя скажу не предстовлая правто ваши задачи От себя скажу не представляя правда ваши задачи СУБД<> Server J2EE<>WEB SERVER<>HTTP Client Это позволит вам обеспечить гибкость системы и потратить не малые деньги :)) Удачи. Спасибо. Вот сейчас посмотрел ибм - там есть маленькая бесплатная вебсфера (не до конца правда разобрался насколько и в какой части бесплатная) - там кажется, да, есть в комплекте web serbver...Но ведь Вы правы, Ява - это другая планета, и в части цен на разработку тоже...А те люди которые мне предложили проект позиционируют себя именно как Ява спецы...бес их знает какие они спецы... я только на Windows программировал. Страшно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:47 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Прохожий.....Ну прочитайте вот эту чтоли статью: http://www.gotdotnet.ru/LearnDotNet/XMLWebServices/749.aspx Там вроде четко обозначены достоинства web сервисов перед прямыми коннектами. Со времен написания статьи конечно много времени прошло, но многое до сих пор актуально. Надежность. Зачастую связь через Интернет является нестабильной, возможны обрывы связи. Если программа,работающая с SQL использует постоянное или длительное соединение с сервером это будет приводить к частым ошибками сделает невозможным стабильную работу такой программы. Весь стандартный инструментарий MS SQL Server работаетименно таким образом - соединение с базой данных поддерживается постоянно. Бред... Соединение нужно только на моменты обращения к серверу. Пользователь может вообще работать в "портфельном" режиме. ЗЫ. Как говорится, "иногда лучше жевать, чем говорить". ((с) не мой) Хотел спросить! По поводу соединений. Идея такая: - как же без постоянного соединения получится делать строгие приложения? Например, хотя бы такая функциональность, что если один юзер накладную открыл, то другому доступ только для чтения. Других нормальных способов, кроме программных блокировок (sp_getapplock), я не вижу. Получается, что нужно всё время соединение держать открытым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:50 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinПродолжу про репликацию. Выже стали изобретать велосипед, реализуя обмен с головным сервером самостоятельно. Еще раз спрошу - это невозможно было реализовать функционалом выбранной вами СУБД? Какая, кстати, она? и мы изобретаем . Не люблю безоговорочно принимать функционал только потому, его реализовал тот или тот. СУБД разные, решение - одно . Простое и легкое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:50 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iscrafmи мы изобретаем. Да читал, читал уже... :) iscrafmСУБД разные, решение - одно. Ну, давайте, не будем здесь еще раз повторяться о СУБДнезависимых решениях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:57 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторЕсли много клиентов и тонкие каналы, только Web доступ и ничего больше. Что ни пост, то перл.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:57 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
AlbatrossХотел спросить! По поводу соединений. Идея такая: - как же без постоянного соединения получится делать строгие приложения? Например, хотя бы такая функциональность, что если один юзер накладную открыл, то другому доступ только для чтения. Других нормальных способов, кроме программных блокировок (sp_getapplock), я не вижу. Получается, что нужно всё время соединение держать открытым. То, что Вы их не видите, еще не значит, что они не сущестуют. sp_getapplock действительно ориентируется на spid, и поэтому ее нельзя использовать для идентификации процесса конкретного пользователя, который, например, работает в портфельном режиме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 14:59 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinНу, давайте, не будем здесь еще раз повторяться о СУБДнезависимых решениях. само решение конечно привязано к СУБД. Но транспорт обмена изменениями (репликация) не зависит от СУБД конечно. На каждый случай городить репликацию средствами СУБД накладно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 15:06 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS ХабаровскДобрый день. Может повторюсь, так как не очень внимательно прочитал все сообщения, слишком много не по теме. По опыту скажу. Во первых. Все таки определитесь чего вы хотите и постройте приблизительную архитектуру. Если много клиентов и тонкие каналы, только Web доступ и ничего больше. На это есть два аргумента, первый запаритесь клиентские места обновлять (или разоритесь на системы автом. обновления, либо лицензии на терминальный доступ), во вторых HTTP все таки хорошо живет на тонких каналах. Во вторых. Определитесь банально с деньгами. Прикинте примерную смету. Мне почему то показалось что Вы немного путаете сервера приложений (WebLogic, WebSphere, EAS, Oracle App Server, SharePoint ну и так далее) и веб сервера (IIS, Apache), может я и ошибаюсь). Конечно в большинство серверов приложений интегрированы web сервера, но все таки это разные вещи. К чему я это, в большинство серверов приложений поддерживают дополнительные возможности типа очереди сообщений, кластеризация и так далее, все это стоит деньги и не малые. Затем вам нужно определится, какими знаниями в части разработки вы распологаете, все таки J2EE и . NET различаются :)) и цены на разработку тоже. Я думаю что после того как вы ответите на эти три вопроса все встанет на свои места. Остальное дела техники и денег. От себя скажу не предстовлая правто ваши задачи От себя скажу не представляя правда ваши задачи СУБД<> Server J2EE<>WEB SERVER<>HTTP Client Это позволит вам обеспечить гибкость системы и потратить не малые деньги :)) Удачи. Спасибо. Вот сейчас посмотрел ибм - там есть маленькая бесплатная вебсфера (не до конца правда разобрался насколько и в какой части бесплатная) - там кажется, да, есть в комплекте web serbver...Но ведь Вы правы, Ява - это другая планета, и в части цен на разработку тоже...А те люди которые мне предложили проект позиционируют себя именно как Ява спецы...бес их знает какие они спецы... я только на Windows программировал. Страшно. Еще добавлю в случае если вы выберите архитектуру (СУБД<> Server J2EE<>WEB SERVER<>HTTP Client) и вам повезет нарветесь на грамотных разработчиков то при соблюдении спецификации J2EE можно не зависеть от поставщика сервера приложений и базы данных как и от платформы на которой они работают (ну или по крайней мере с минимальными переделками). Правда такое бывает редко, слишком много нюансов в каждом приложении и мало грамотных разработчиков. Еще раз удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 15:07 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....Репликация в данной задаче действительно как к телеге пятое колесо О! Сразу видно, что ответ давал технический специалист. Тут и все выкладки и расчеты. Прохожий.....Более того, скажу, что в трезвенке вида сервер - вебсервис - GUIклиент будет тяжело найти удобные решения для каналов в 64к. и Прохожий.....]Для чего я вас об этом попросил, я хочу видеть реальную выгоду двузвенки (ну вот интересно мне), пока от вас поступали только голословные заявления, приведите хоть один пример в поставленной задаче, где двузвенка отработает на 20, 30, 40% быстрее трезвенки и потребует не больших финансовых затрат. И опять, все с расчетами и экономическими обоснованиями. А я говорю, что для определения архитектуры ширина канала не основной параметр. Что ж Вы с меня требуете расчетов и обоснований, если сами их не приводите? По поводу якобы уменьшения трафика при многозвенке (давайте пока сжатие данных оставим) я уже в этом топике упоминал. Не хотите перечитать топик еще раз? Дабы вспомнить, кто начала говорить об эффективности многозвенки над двузвенкой. Прохожий.....Как вы вообще видите снижение трафика между клиентом и сервером в двузвенке? Про трезвенку я уже говорил, сжатие потоков? Т.е. Вы не знаете, как имея, скажем только SQL Server и клиентское приложение сжать набор данных для отчета и передать его на клиента в виде выходного параметра расширенной хп или хп, использующей CLR сборку, а уже на клиенте распокавать и залить его ввиде набора, скажем, в TClientDataSet дабы сформировать отчет? Он от того, что Вы не знаете как это сделать возможность то эта не пропадает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 15:11 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Я вот знаю одну систему для коммунального биллинга, которая требует для работы по минимуму модем на 9200 :)) И ничего, работает себе, и даже с MS SQL. ----------- Все же у меня предложение: давайте сначала разберемся, о простых трезвенках мы говорим или о трехзвенках с апп-серверами :)) А потом уже можно и вглубь и вширь :)) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 15:20 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin О! Сразу видно, что ответ давал технический специалист. Тут и все выкладки и расчеты. А кто вам обещал выкладки и расчеты? Ну если вашими же словами, то за $5000 могу и выкладки и расчеты. pkarklin Не хотите перечитать топик еще раз? Если честно, то нет, неасилю... pkarklin (давайте пока сжатие данных оставим) А почему собственно оставим? Это одно из основных условий, минимизировать трафик! pkarklin Т.е. Вы не знаете, как имея, скажем только SQL Server и клиентское приложение сжать набор данных для отчета и передать его на клиента в виде выходного параметра расширенной хп или хп, использующей CLR сборку, а уже на клиенте распокавать и залить его ввиде набора, скажем, в TClientDataSet дабы сформировать отчет? Он от того, что Вы не знаете как это сделать возможность то эта не пропадает. Я прекрасно знаю что такое SQLCLR и более того писал их, и потому скажу, что их написание в особо критичных случаях намного сложнее, чем скажем написание простого приложения на том же CLR. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 15:28 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygraЯ вот знаю одну систему для коммунального биллинга, которая требует для работы по минимуму модем на 9200 :)) И ничего, работает себе, и даже с MS SQL. ----------- Все же у меня предложение: давайте сначала разберемся, о простых трезвенках мы говорим или о трехзвенках с апп-серверами :)) А потом уже можно и вглубь и вширь :)) -- Tygra's -- Мои фотогалереи тут и тут Песня! А как сделана? жуть как интересно! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 15:36 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
[quot kolobok0 резюме.. лично я не вижу работы для апп. сервера. Возможно плохо представляю задачу - хз. Озвученное Вами железо - не серьёзный подход. На мой взгляд плясать нуна начинать от решений IBM(as400 я имею ввиду) не меньше. Всё остальное мягко говоря не серьёзно при таком кол-ве транзакций и клиентов... с уважением (круглый)[/quot] я им еще несколько страниц сказал iseries (по-старому as/400) юзать нет, блин, апп-серверы, различные по толщине клиенты.. тьху ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 15:45 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Идея аффтора - изначально бред, с точки зрения экономики и маркетинга. Что было раскрыто сразу и многими (читаем внимательно топик). Тем не менее масса народу взялась обсуждать технические особенности реализации бреда. Делать нечего? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 16:13 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Billling DeveloperИдея аффтора - изначально бред, с точки зрения экономики и маркетинга. Что было раскрыто сразу и многими (читаем внимательно топик). Тем не менее масса народу взялась обсуждать технические особенности реализации бреда. Делать нечего? Конечно бред! Но зато скока эмоций! :) Хотя мое ИМХО, бред это то, что сейчас творится в энергетике и коммунальном хозяйстве вцелом... Энергетики, осуществляющие биллинг водоснабжения, как вам такое? А они это всерьез обсуждают на своих высоких совещаниях! Я так понял все, что нужно автору, это создать систему биллинга для своего скромного отделения на 200-300 пользователей максимум, но с перспективой расширится на всю Россию матушку, глупо конечно, но если начальники хотят куда денешся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 16:25 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS tygraЯ вот знаю одну систему для коммунального биллинга, которая требует для работы по минимуму модем на 9200 :)) И ничего, работает себе, и даже с MS SQL. ----------- Все же у меня предложение: давайте сначала разберемся, о простых трезвенках мы говорим или о трехзвенках с апп-серверами :)) А потом уже можно и вглубь и вширь :)) -- Tygra's -- Мои фотогалереи тут и тут Песня! А как сделана? жуть как интересно! Да просто не таскают 100-страничных отчетов на клиента :)) Ну это я просто к слову, о том, что на 64к не сделать двухзвенки :) -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 16:32 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
2аутор у меня есть небольшой опыт в жабе. С моей точки зрения к спецам по жабе (ко всем) нужно относиться очень осторожно. В идеале просто потребовать подтвердить их слова примерами решений. Хотя это скорей ко всем относится. И на возраст посмотреть. Если меньше 30 лет то пусть сначала на бумажках потренируется. Чисто моё предвзятое мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 16:55 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Хабаровск Если много клиентов и тонкие каналы, только Web доступ и ничего больше. На это есть два аргумента, первый запаритесь клиентские места обновлять (или разоритесь на системы автом. обновления, либо лицензии на терминальный доступ), во вторых HTTP все таки хорошо живет на тонких каналах. Не согласен, да проблема толстых клиентов - обновление версий, но это 1(одна) проблема. А Web доступом много проблем 1)Откровенно убогий интерфейс. Попробуйте реализовать хотябы выбор из 2-х уровневого справочника город-улица. Видел системы где проблемы интерфейса решались загружаемыми ActiveX компонентами. 2)Безопасность. Уверен SSL не отделаетесь, придется тащить на клиента криптографические библиотеки. 3)Нет возможности реализовать сжатие трафика 4)По поводу "HTTP все таки хорошо живет на тонких каналах" это верно, если вам надо посмотреть пару страничек которые браузер к тому же закешировал. А вы пробовали ввести несколько десятков документов в web формах? Так кто там говорил про обновление версий и экономию тарфика? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 17:56 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
5)Проблема разных версий браузеров. Недавно видел ПО где в качестве достоинств было "тонкий клиент", а в документации мелким шрифтом "Требуется Internet Explorer 6.0" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 18:03 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
нынче технология такая - oltp <-> olap <-> web <-> browser платформа? психически здоровые люди во всем мире уже лет 10 разрабатывают корпоративные приложения кейсами. советую изучить умл и работаать с продуктами рэйшнл. железо? любой блэд с вирутализацией. с коментов смеялсо - ньювасюки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 19:34 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
NetObserver5)Проблема разных версий браузеров. Недавно видел ПО где в качестве достоинств было "тонкий клиент", а в документации мелким шрифтом "Требуется Internet Explorer 6.0" :) норм стиль. совместимость не ниже. опера 9 пойдет. если имеются ввиду жаба, то не ниже 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 19:39 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
akzс коментов смеялсо - ньювасюки. +1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2007, 00:16 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
GeenS Абсолютно верно! Темой больших систем владею не очень...Темой энергосбыта - очень владею! А насчет амбиций - упаси Бог идти на такие масштабы! Пахнет катастрофой...Но запас надо ведь иметь? или нет? Добрый день. Ваша идея вполне понятна. Отвлекаясь от технической стороны вопроса, если вы сделаете такую систему - заказчики есть на услуги ее аренды? Это скорее маркетинговый вопрос уже. Про SPL тут правильно писали, они я думаю захватят большую часть рынка в биллинге коммунальных платежей. Хотя! Это вопрос политический более, а не технический. Вот например одну известную импортную систему биллинга в одном крупнейшем операторе связи за огромные бабки начали внедрять - "сверху". Так же сейчас и похоже завершили. Тогда как теперь внедряют - другие системы, уже отечественные. Так что если а) сделаете что-то удобоваримое хоть немного и главное красиво выглядящее и б) это систему будет кто-то продвигать в играх на весьма высоких уровнях руководств - то почему бы вам не занять эту нишу... Ну а не получится - уйдете большим менеджером в SPL... С уважением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2007, 01:03 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
NetObserver Хабаровск Если много клиентов и тонкие каналы, только Web доступ и ничего больше. На это есть два аргумента, первый запаритесь клиентские места обновлять (или разоритесь на системы автом. обновления, либо лицензии на терминальный доступ), во вторых HTTP все таки хорошо живет на тонких каналах. Не согласен, да проблема толстых клиентов - обновление версий, но это 1(одна) проблема. А Web доступом много проблем 1)Откровенно убогий интерфейс. Попробуйте реализовать хотябы выбор из 2-х уровневого справочника город-улица. Видел системы где проблемы интерфейса решались загружаемыми ActiveX компонентами. 2)Безопасность. Уверен SSL не отделаетесь, придется тащить на клиента криптографические библиотеки. 3)Нет возможности реализовать сжатие трафика 4)По поводу "HTTP все таки хорошо живет на тонких каналах" это верно, если вам надо посмотреть пару страничек которые браузер к тому же закешировал. А вы пробовали ввести несколько десятков документов в web формах? Так кто там говорил про обновление версий и экономию тарфика? Даже не буду спорить, ДА убогость клиента налицо, но мир не стоит на месте существуют разные технологии позволяющие нивелировать часть недостатков в частности AJAX (с помощью ее кстати и реализовывают выбор из двух справочников). Но это все лирика потому что, не зная чего хочешь, не сможешь этого получить, поэтому первым пунктом я и написал «Все таки определитесь чего вы хотите и постройте приблизительную архитектуру» ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2007, 09:13 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
To NetObserver 1)У веб-приложения убогий интерфейс может быть только из-за убогой реализации разработчиком. Если темой владеет и руки в нужном месте, то сделает конфетку. AJAX - рулит, ActiveX - в топку. 2)SSL хватит за глаза. Все криптографические библиотеки имеются с браузером. Над ними парились не один год и не нужно изобретать велосипед. 3)"Content-Encoding: gzip" ни о чем не говорит? 4)Тоже самое что и п.1. Руки в нужном месте, владение нормальными знаниями (HTTP,HTML) и опытом. 5)В том весь и фокус, что проблема разных версий браузеров легко становится проблемой заказчика. А для исполнителя не является проблемой. Выставляешь требования и все. По поводу спора об абстрактной необходимости сервера-приложений. Бывают ситуации, когда его наличие необходимо. Вопрос только в каких случаях, и как реализовывать. В доказательство привожу абстрактный пример. К примеру, существует машина, на ней СУБД, выдающая выборку за 1 "ед.работы" и производящая некую обработку данных за 10 "ед.работы". В случае 2-х звенной архитектуры, для 10 клиентов с равномерными обращениями на обработку данных нагрузили бы сервак СУБД на 100 "ед.работы" в единицу времени. В случае 3-х звенной, с реализацией сервак СУБД только выдает (сервер СУБД будет нагружен только на 10 "ед.работы"), а обработка делается только на стороне сервера-приложений может получится разная картина. К примеру такая: а) Сервер-приложений выполняет требуемую оработку за 10 "ед.работы". Тогда узким местом становится именно он. Чтобы его расширить, ставим на один сервер СУБД (нагрузка=1 "ед.работы" * 10 клиентов=10), 10 серверов апп-сервера (по 10 "ед.работы" на каждого клиента). б) Сервер-приложений выполняет требуемую обработку эффективней, чем СУБД, тогда выполняемая им работа меньше 10 "ед.работы". Получается пункт (а), только упрощенный. А теперь вопрос: всегда ли выгоднее иметь одну машину с условной мощностью 100, чем 11 машин с условной мощностью 10? Ответ на этот вопрос и будет ответом об эффективности использования той или иной архитектуры. К примеру, если речь идет о террабайте дискового пространства, то возможно один винт лучше десятка 100гиговых. А если речь идет о 100 террабайтах, тут, даже если и найдете в продаже сие чудо, оно будет стоить непомерно дороже ста террабайтных винтов. Аналогично и с процовой мощностью, и с опер.памятью, и с пропускной способностью мамы, и с сетевыми делами. Везде есть некая граница, после чего дальнейшее прибавление в условной мощности приводит к нелинейному удорожанию системы, и как следствие, к невозможности масштабирования. По поводу темы. Думаю, что и веб-сервера вполне достаточно, он ведь является определенным сервером-приложений, позволяющим отделить "мух от котлет". Да и возможностей к архитектурным изменениям у такой реализации больше. Если вдруг, все-таки кто-то что-то удачно впарит, и срочно придется увеличивать масштаб системы на порядки, то для тонких клиентов-браузеров ничего ровным счетом не изменится (ну вообще ничего, ведь отдаваемый неким гейтом HTML будет точно таким же), а на стороне сервера можно будет все перебрать по кускам вплоть до реализации системы типа "яндекса". Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2007, 02:09 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
биллингист GeenS Абсолютно верно! Темой больших систем владею не очень...Темой энергосбыта - очень владею! А насчет амбиций - упаси Бог идти на такие масштабы! Пахнет катастрофой...Но запас надо ведь иметь? или нет? Добрый день. Ваша идея вполне понятна. Отвлекаясь от технической стороны вопроса, если вы сделаете такую систему - заказчики есть на услуги ее аренды? Это скорее маркетинговый вопрос уже. Про SPL тут правильно писали, они я думаю захватят большую часть рынка в биллинге коммунальных платежей. Хотя! Это вопрос политический более, а не технический. Вот например одну известную импортную систему биллинга в одном крупнейшем операторе связи за огромные бабки начали внедрять - "сверху". Так же сейчас и похоже завершили. Тогда как теперь внедряют - другие системы, уже отечественные. Так что если а) сделаете что-то удобоваримое хоть немного и главное красиво выглядящее и б) это систему будет кто-то продвигать в играх на весьма высоких уровнях руководств - то почему бы вам не занять эту нишу... Ну а не получится - уйдете большим менеджером в SPL... С уважением. Доброе утро очень рад услышать мнение человека, который понимает все нюансы вопроса...Кто в теме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 08:08 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iLLer To NetObserver 1)У веб-приложения убогий интерфейс может быть только из-за убогой реализации разработчиком. Если темой владеет и руки в нужном месте, то сделает конфетку. AJAX - рулит, ActiveX - в топку. 2)SSL хватит за глаза. Все криптографические библиотеки имеются с браузером. Над ними парились не один год и не нужно изобретать велосипед. 3)"Content-Encoding: gzip" ни о чем не говорит? 4)Тоже самое что и п.1. Руки в нужном месте, владение нормальными знаниями (HTTP,HTML) и опытом. 5)В том весь и фокус, что проблема разных версий браузеров легко становится проблемой заказчика. А для исполнителя не является проблемой. Выставляешь требования и все. По поводу спора об абстрактной необходимости сервера-приложений. Бывают ситуации, когда его наличие необходимо. Вопрос только в каких случаях, и как реализовывать. В доказательство привожу абстрактный пример. К примеру, существует машина, на ней СУБД, выдающая выборку за 1 "ед.работы" и производящая некую обработку данных за 10 "ед.работы". В случае 2-х звенной архитектуры, для 10 клиентов с равномерными обращениями на обработку данных нагрузили бы сервак СУБД на 100 "ед.работы" в единицу времени. В случае 3-х звенной, с реализацией сервак СУБД только выдает (сервер СУБД будет нагружен только на 10 "ед.работы"), а обработка делается только на стороне сервера-приложений может получится разная картина. К примеру такая: а) Сервер-приложений выполняет требуемую оработку за 10 "ед.работы". Тогда узким местом становится именно он. Чтобы его расширить, ставим на один сервер СУБД (нагрузка=1 "ед.работы" * 10 клиентов=10), 10 серверов апп-сервера (по 10 "ед.работы" на каждого клиента). б) Сервер-приложений выполняет требуемую обработку эффективней, чем СУБД, тогда выполняемая им работа меньше 10 "ед.работы". Получается пункт (а), только упрощенный. А теперь вопрос: всегда ли выгоднее иметь одну машину с условной мощностью 100, чем 11 машин с условной мощностью 10? Ответ на этот вопрос и будет ответом об эффективности использования той или иной архитектуры. К примеру, если речь идет о террабайте дискового пространства, то возможно один винт лучше десятка 100гиговых. А если речь идет о 100 террабайтах, тут, даже если и найдете в продаже сие чудо, оно будет стоить непомерно дороже ста террабайтных винтов. Аналогично и с процовой мощностью, и с опер.памятью, и с пропускной способностью мамы, и с сетевыми делами. Везде есть некая граница, после чего дальнейшее прибавление в условной мощности приводит к нелинейному удорожанию системы, и как следствие, к невозможности масштабирования. По поводу темы. Думаю, что и веб-сервера вполне достаточно, он ведь является определенным сервером-приложений, позволяющим отделить "мух от котлет". Да и возможностей к архитектурным изменениям у такой реализации больше. Если вдруг, все-таки кто-то что-то удачно впарит, и срочно придется увеличивать масштаб системы на порядки, то для тонких клиентов-браузеров ничего ровным счетом не изменится (ну вообще ничего, ведь отдаваемый неким гейтом HTML будет точно таким же), а на стороне сервера можно будет все перебрать по кускам вплоть до реализации системы типа "яндекса". Posted via ActualForum NNTP Server 1.4 +100 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 11:02 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
iLLerВ доказательство привожу абстрактный пример. Ну, хоть один с "примером"... iLLerК примеру, существует машина, на ней СУБД, выдающая выборку за 1 "ед.работы" и производящая некую обработку данных за 10 "ед.работы". В случае 2-х звенной архитектуры, для 10 клиентов с равномерными обращениями на обработку данных нагрузили бы сервак СУБД на 100 "ед.работы" в единицу времени. Гм... Если Вы уж решили разделять весь процесс на "выборку" и "обработку", то у меня в случие 2ву звенки получается 110 ер. iLLerВ случае 3-х звенной, с реализацией сервак СУБД только выдает (сервер СУБД будет нагружен только на 10 "ед.работы"), а обработка делается только на стороне сервера-приложений может получится разная картина. К примеру такая: а) Сервер-приложений выполняет требуемую оработку за 10 "ед.работы". Тогда узким местом становится именно он. Чтобы его расширить, ставим на один сервер СУБД (нагрузка=1 "ед.работы" * 10 клиентов=10), 10 серверов апп-сервера (по 10 "ед.работы" на каждого клиента). б) Сервер-приложений выполняет требуемую обработку эффективней, чем СУБД, тогда выполняемая им работа меньше 10 "ед.работы". Получается пункт (а), только упрощенный. Ну, опуская затраты на обмен между серверами, допустим, что так. На счет того, что апп. сервер "сделает обработку эффективней" - очень большие сомнения... iLLerА теперь вопрос: всегда ли выгоднее иметь одну машину с условной мощностью 100, чем 11 машин с условной мощностью 10? Ответ на этот вопрос и будет ответом об эффективности использования той или иной архитектуры. Безусловно!!! И, машина, обеспечивающая 100 (точнее 110) будет дешевле (до определенного уровня), чем 11 машин по 10. Подумайте, почему уголь с карьеров возят на большегрузных Белазах, а не на ГАЗиках! iLLerК примеру, если речь идет о террабайте дискового пространства, то возможно один винт лучше десятка 100гиговых. А если речь идет о 100 террабайтах, тут, даже если и найдете в продаже сие чудо, оно будет стоить непомерно дороже ста террабайтных винтов. И куда и каким образом Вы прицепите эти 100 винтов? К каждому из апп. серверов по 10? Но, позвольте, данные у Вас то хранятся в СУБД, и , следовательно, дисковое протсранство нужно именно там, а не на апп. серверах. И что имеем в результате? Кроме дисковового пространства на сервере СУБД, нам еще необходимо и дисковое пространство на апп. серверах, раз мы туда переносим нагрузку. iLLerАналогично и с процовой мощностью, и с опер.памятью, и с пропускной способностью мамы, и с сетевыми делами. Гм... Вы опять исходите из неверного постулата и используете идилическую ситуацию, когда 10 пользователям нужны РАЗНЫЕ данные. В реалии, данные, запрашиваемые разными пользователями, обычно имеют некоторое пересечение, что позволяет говорить о нелинейной зависимости потребности в ресурсах (в первую очередь память и процессор) и централизация таких ресурсов в этом случаи позволяет уменьшить общие суммарные треования к ним, в проивоположность размазыванию этих ресурсов по N системам. Так же не стоит забывать, что современные СУБД имеют дополнительные возможности по оптимизации использования этих ресурсов в случаи множественного обращения пользователей за данными, которые имеют некоторое пересчение. Вы же предлагаете на это забить и сделать (перенеся обработку на апп. сервера) зависимость потребности в ресурсах от числа пользователей линейной. iLLerВезде есть некая граница, после чего дальнейшее прибавление в условной мощности приводит к нелинейному удорожанию системы, и как следствие, к невозможности масштабирования. Бесспорно, что такая граница есть. Но, она слишком эфемерна, и вряд - ли, кто-то из участвующих в обсуждении, доберется в ближайше время до нее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 11:32 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Вы всем упорно навязываете свою мысль о двухзвенной архитектуре (для поставленной задачи). Но еще не привели ни одного довода в пользу того. Соображения типа pkarklinБезусловно!!! И, машина, обеспечивающая 100 (точнее 110) будет дешевле (до определенного уровня), чем 11 машин по 10. Подумайте, почему уголь с карьеров возят на большегрузных Белазах, а не на ГАЗиках! мне лично ни о чем не говорят, детский лепет и не более, приведите свой пример и желательно в деньгах, если вы так считаете. Сервер БД и без того не будет простым двухпроцессорным ксеоном, так зачем его еще умощнять заставляя выполнять чисто вычислительные задачи? Зачем городить десятки SQLCLR процедур (в случае с MSSQL) и обвешивать ими сервер, когда можно написать одно приложение делающее эту работу и разместить его на отдельной машине. Выражаясь вашими же словами, вы пытаетесь к Белазу прикрутить автопогрузчик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 16:03 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....Вы всем упорно навязываете свою мысль о двухзвенной архитектуре (для поставленной задачи). Нет. Я упорно пытаюсь опровергнуть "преимущества" многозвенки над двузвенкой вне контекста задачи. Я где-то в ответе iLLer указывал на конкретную задачу? Нет! Впрочем, как этого не сделал и сам iLLer. Обсуждался лишь абстрактный пример. Прохожий.....Но еще не привели ни одного довода в пользу того. Гм... Еще раз... терпеливо. Я привожу доводы не "в пользу", а "против" якобы преимуществ многозвенки над двузвенкой. Неужели Вы еще этого не поняли? Прохожий.....мне лично ни о чем не говорят, детский лепет и не более, приведите свой пример и желательно в деньгах, если вы так считаете. Ну что ж. В деньгах будем мерять что? Под какую задачу? Давайте развернутое ТЗ, а не "идею" топикстартера. Попробуем прикинуть. Прохожий.....Сервер БД и без того не будет простым двухпроцессорным ксеоном, так зачем его еще умощнять заставляя выполнять чисто вычислительные задачи? Интересно... С этого момента можно по-подробнее? В чем основное предназначение сервера СУБД? И что для Вас есть "чисто вычислительные задачи"? Прохожий.....Зачем городить десятки SQLCLR процедур (в случае с MSSQL) и обвешивать ими сервер, когда можно написать одно приложение делающее эту работу и разместить его на отдельной машине. А затем, что в 99% случаев именно централизованная архитектура имеет выигрыш. Зачем мне еще какае-то приложение и отдельная машина, если с поставленной задачей успешно справится сам сервер СУБД? Прохожий.....Выражаясь вашими же словами, вы пытаетесь к Белазу прикрутить автопогрузчик. И погрузчик, и разгрузчик, ибо задачи ETL существуют в большинстве систем. И опять, я буду использовать возможности и инструменты, предоставляемые сервером СУБД, а не буду городить городушки в виде отдельного приложения и на отдельной машине. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 16:20 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Нет. Я упорно пытаюсь опровергнуть "преимущества" многозвенки над двузвенкой вне контекста задачи. Я где-то в ответе iLLer указывал на конкретную задачу? Нет! Впрочем, как этого не сделал и сам iLLer. Обсуждался лишь абстрактный пример. Если действительно вне контекста задачи, то и пишите свои мысли вне этой темы! Здесь изначально обсуждалось, как автору построить систему для ЕГО задачи! pkarklin Гм... Еще раз... терпеливо. Я привожу доводы не "в пользу", а "против" якобы преимуществ многозвенки над двузвенкой. Неужели Вы еще этого не поняли? Вы пытаетесь все мерить одним аршином, и систему на 10 пользователей бухучета и системы подобные Яндексу… pkarklin Ну что ж. В деньгах будем мерять что? Под какую задачу? Давайте развернутое ТЗ, а не "идею" топикстартера. Попробуем прикинуть. Если вы даже в общих чертах не поняли задачи, а исходите только из чего то совершенно абстрактного, то о чем вообще речь… pkarklin А затем, что в 99% случаев именно централизованная архитектура имеет выигрыш. Зачем мне еще какае-то приложение и отдельная машина, если с поставленной задачей успешно справится сам сервер СУБД? А справится ли успешно? Опять голословные измышления и не более того, где факты основанные хоть на каком то примере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 16:39 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....Если действительно вне контекста задачи, то и пишите свои мысли вне этой темы! Давайте договоримся так. Я сам без Ваших указаний буду принимать решение что, где и когда мне писать. Прохожий.....Здесь изначально обсуждалось, как автору построить систему для ЕГО задачи! И что? Кто мне может запретить высказывать свое мнение о подходах к решению задачи автора, отвечая на "абстракнтый пример"?! Я не нарушал Правил форума. Если Вы полагаете обратное - есть ссылка "Пожаловаться модератору". Она всегда к Вашим услугам. Прохожий.....Вы пытаетесь все мерить одним аршином, и систему на 10 пользователей бухучета… Мне это позволяет имеющийся у меня опыт. Прохожий........ и системы подобные Яндексу Господи... Яндекс то тут причем?! Прохожий.....Если вы даже в общих чертах не поняли задачи, а исходите только из чего то совершенно абстрактного, то о чем вообще речь… IMHO, Вам все-таки, надо еще раз перечитать топик, отслеживая последовательность появления сообщений. Прохожий.....А справится ли успешно? Опять голословные измышления и не более того, где факты основанные хоть на каком то примере? Ок. Какой "конкретный" пример Вас удовлетворит? Кстати, про пример я начал спрашивать. И что Вы мне ответили? Перечитайте еще раз, хотя бы свои ответы на мои вопросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 16:50 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklinДавайте договоримся так. Я сам без Ваших указаний буду принимать решение что, где и когда мне писать. Да никто вам не указывает, упаси господь… ИМХО: просто вы уже потеряли суть темы и пишите о чем-то своем совершенно абстрактном и вряд ли нужном в этой теме! Нравится вам двухзвенка, ну и отлично, мне тоже нравится, тока в отличии от вас я не пытаюсь все «подстричь» под одну гребенку. Вы вообще задумывались, что может быть какое то мнение кроме вашего? Я тоже вроде немало работаю в ИТ, но очень часто сомневаюсь в правильности тех или иных решений! И потому если мне доказывают, что есть лучшее решение я с удовольствием встаю на его сторону. pkarklin Мне это позволяет имеющийся у меня опыт. Опыт позволяет ЧТО? Проектировать «неправильные» системы? Кстати этот опыт измеряется какой системой подобной заданным условиям? pkarklin Ок. Какой "конкретный" пример Вас удовлетворит? Кстати, про пример я начал спрашивать. И что Вы мне ответили? Перечитайте еще раз, хотя бы свои ответы на мои вопросы. Это вы про $5000, ну извините тогда что пристаю к вам, нету у меня лишних $5000. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 17:16 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....ИМХО: просто вы уже потеряли суть темы и пишите о чем-то своем совершенно абстрактном и вряд ли нужном в этой теме! Ок. Ждем от автора топика высказывания "вопрос закрыт". И, критика "абстрактного примера", приведенного в этом топике, тоже IMHO, не такая уж и абстрактная. Прохожий.....Нравится вам двухзвенка, ну и отлично, мне тоже нравится, тока в отличии от вас я не пытаюсь все «подстричь» под одну гребенку. Мне "нравятся" любые архитектурные решения примененные с умом и к месту. Мне не нравится приведение в качестве аргументов в защиту той или иной архитектуры доводов, не имеющих под собой никакого обоснования. Прохожий.....Вы вообще задумывались, что может быть какое то мнение кроме вашего? Я тоже вроде немало работаю в ИТ, но очень часто сомневаюсь в правильности тех или иных решений! И потому если мне доказывают, что есть лучшее решение я с удовольствием встаю на его сторону. У нас с Вами много общего. Я так же, как и Вы встану на сторону "лучшего решения", если будут приведены аргументированные и убедительные доказательства "лучшести" оного. Пока в этом топике (да и не только в этом) большинство аргументов за многозвенность смахивают на элементарную безграмотность в контексте используемой в системе СУБД. Системы, изначально расчитанные на "СУБДнезависимость" я не рассматриваю. Прохожий.....Опыт позволяет ЧТО? Проектировать «неправильные» системы? Если бы я проектировал "неправильные" системы, то давно бы остался без работы. Прохожий.....Кстати этот опыт измеряется какой системой подобной заданным условиям? А Вы, опять же, перечитайте топик. Например, я "из личного опыта" приводил пример сколько пользователей могут работать и на каком канале в классической двузвенке. Пример реализаций других "фич среднего уровня" на сервер СУБД я тоже приводил. Прохожий.....Это вы про $5000, ну извините тогда что пристаю к вам, нету у меня лишних $5000. Вы все-таки мастер в уходе от ответов на вопросы. Боюсь, что мне не имеет смысла продолжать с Вами дискуссию в таком ключе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 17:29 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Еще раз пробежался глазами по теме, не считая высказываний вида: однозначно двузвенка. Не нашел с вашей стороны ни одного конструктивного предложения по теме и не одного довода в пользу двузвенки в данной задаче, только вопросы и выпады в сторону оппонентов. Примеров «из своего опыта» тоже не нашел кроме этого: Клик Ну и что вы предлагали перечитать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 18:08 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....Еще раз пробежался глазами по теме, не считая высказываний вида: однозначно двузвенка. Это уже смахивает на наглую ложь. М.б. потрудитесь привести цитаты моих высказываний "вида: однозначно двузвенка"? Автору топика я рекомендовал как раз другое! Прохожий.....]Не нашел с вашей стороны ни одного конструктивного предложения по теме и не одного довода в пользу двузвенки в данной задаче, только вопросы и выпады в сторону оппонентов. Видимо надо было не "пробежаться глазами", а таки внимательно перечиатать, дабы увидеть эти "конструктивные предложения". Вопросы - да? Причем ни на один вопрос, связанный с причиной выбора той или иной архитектуры я не получил ответов, а только высказывания типа "стандартное решение", "ширина каналов", "масштабирование" не подкрепленные никакой аргументацией. Свою точку зрения я аргументировал, например, указывая на то, что одним увеличенеим апп. серверов систему не "смаштабировать". Как решить те или иные задачи без апп. сервера - тоже примеры приводились. Вы же упорно не хотите ничего слышать. Прохожий.....Примеров «из своего опыта» тоже не нашел кроме этого: Клик Искать и хотеть найти - две большие разницы. Прохожий.....Ну и что вы предлагали перечитать? Еще раз перечитать этот топик и привести мои высказывания: "вида: однозначно двузвенка". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 08:24 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Внесу-ка и я небольшую лепту: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 09:01 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Насчет СУБД<> Server J2EE<>WEB SERVER<>HTTP Client Видел в действии технологию от Oracle (на примере приложения OEBS), на 33600 модемной связи можно работать, хотя по документации заявлено, что работать можно даже на 9600!!! СУБД - Oracle DB Server J2EE и WEB SERVER - Oracle AS Client - Java сервлет (если не ошибаюсь с терминологией) Все платформонезависимо, неограниченная маштабируемость, среда разработки Oracle Forms and Reports. Да существуют проблемы, да убогий интерфейс, но технология рабочая. Про маштабируемость только читал, но искренне в это верю :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 09:13 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
MLightсреда разработки Oracle Forms and Reports. + возможность переноса бизнес логики на pl/sql с сервера на клиента и обратно - распределение нагрузки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 09:25 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
MLightНасчет СУБД<> Server J2EE<>WEB SERVER<>HTTP Client Видел в действии технологию от Oracle (на примере приложения OEBS), на 33600 модемной связи можно работать, хотя по документации заявлено, что работать можно даже на 9600!!! СУБД - Oracle DB Server J2EE и WEB SERVER - Oracle AS Client - Java сервлет (если не ошибаюсь с терминологией) Все платформонезависимо, неограниченная маштабируемость, среда разработки Oracle Forms and Reports. Да существуют проблемы, да убогий интерфейс, но технология рабочая. Про маштабируемость только читал, но искренне в это верю :). Только там нет никакого апп.севрера с бизнес-логикой. Формзовый сервер - это голимый PL\SQL клиент. Вся логика зарыта на стороне СУБД в туевой хуче пакетов. Явааплеты понадобились, дабы реализовать жалкое подобие MDI интерфейса. Работает этот интерфейс чудовищно тормознуто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 10:06 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
MLight Client - Java сервлет (если не ошибаюсь с терминологией) Сервлет работает на http сервере В браузере работает апплет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 10:12 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Я тут здесь громче всех кричу, что приемущества, приписываемые многозвенке некоторыми ее апологетами, в большинстве случаев такими не являются, и лишь только вносят лишнее усложнение в систему. Ну если это не призывы к двузвенке, то тогда незнаю... pkarklin Прохожий.....Примеров «из своего опыта» тоже не нашел кроме этого: Клик Искать и хотеть найти - две большие разницы. Дайте ссылку, с хорошим примером, с конкретикой, помоему это нетрудно сделать. Или вам больше нравится пофлудить? Да и вообще сдались всем эти споры про n-звенки в каких то совершенно абстрактных задачах. Задача была вполне конкретной: биллинг электроэнергетики и возможно части коммунальных услуг, каналы в 64к, кстати не только 64к, там еще и про диал-ап говорилось, а это в среднем 40-50к и 10000клиентов, сдача сервиса в аренду. Будет тут работать классическая двузвенка с GUI без применения извратов? ИМХО: нет! Если есть другое мнение - докажите! Выражаясь по аналогии со словами pkarklin еще никто не доказал достоинства двузвенки в этом проекте! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 12:04 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий.....Ну если это не призывы к двузвенке, то тогда незнаю... Мне ужу надоело повторять, что я не являюсь противником многозвенок. Прохожий.....Дайте ссылку, с хорошим примером, с конкретикой, помоему это нетрудно сделать. Или вам больше нравится пофлудить? На что Вам дать ссылку? На систему класса ERP, разработанную под собственные нужды, которой в принципе побарабану ширина каналов? Прохожий.....Задача была вполне конкретной: биллинг электроэнергетики и возможно части коммунальных услуг, каналы в 64к, кстати не только 64к, там еще и про диал-ап говорилось, а это в среднем 40-50к и 10000клиентов, сдача сервиса в аренду. Будет тут работать классическая двузвенка с GUI без применения извратов? ИМХО: нет! Если есть другое мнение - докажите! Еще раз... терпеливо... Покажите мне где я рекомендовал автору топика использовть двузвенку? Похоже эта мысль присутствует только в Вашем воображении. Рекомендовал я совсем обратное. Прохожий.....]Выражаясь по аналогии со словами pkarklin еще никто не доказал достоинства двузвенки в этом проекте! Впрочем как и никто не доказал достоинств многозвенок, причем ни только в этом проекте! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 12:43 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin На что Вам дать ссылку? На систему класса ERP, разработанную под собственные нужды, которой в принципе побарабану ширина каналов? хоть на что-нибудь дайте ссылку ну или хотя бы сделайте детальное описание проекта подобного проекту автора. Или прикажете читать ваши высказывания как учения Иисуса-Христа? pkarklin Еще раз... терпеливо... Покажите мне где я рекомендовал автору топика использовть двузвенку? Похоже эта мысль присутствует только в Вашем воображении. Рекомендовал я совсем обратное. Если вы рекомендовали автору обратное, зачем в таком случае все остальные рассуждения? Рекомендуете одно, а рассуждаете о противоположном?! pkarklin Впрочем как и никто не доказал достоинств многозвенок, причем ни только в этом проекте! А с чего вы решили, что именно ВАМ кто-то собрался что-то доказывать? И если действительно нет никаких достоинств, то зачем вы рекомендовали автору "совсем обратное"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 13:12 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Прохожий..... хоть на что-нибудь дайте ссылку ну или хотя бы сделайте детальное описание проекта подобного проекту автора. Или прикажете читать ваши высказывания как учения Иисуса-Христа? Вы их можете совсем не читать и не отвечать на них, ибо у Вас что не "задача" - то ее решение, только промежуточное звено. Прохожий.....Если вы рекомендовали автору обратное, зачем в таком случае все остальные рассуждения? Рекомендуете одно, а рассуждаете о противоположном?! Ну тупить то не надо!!! Вы, я надеюсь, помните, из каких вариантов автор предлагал выбрать? Я выбрал второй. Причем исходя из следующих предпосылок: 1. Реализация нормального тонкого (нет необходимости устанавливать database connectivity на клиенте) клиента с нормальным GUI. 2. Реализовать (при необходимости) на промежуточном уровне пуллинг коннектов, что может понадобиться (а может и нет) при таком числе активных пользователей. Все! Никакой бизнес-логики вне СУБД. Остальные рассуждения были ответами на "решения", которые предлагалось реализовывать на промежуточном уровне. Прохожий.....А с чего вы решили, что именно ВАМ кто-то собрался что-то доказывать? Не передергивайте. Я опровергал, причем на конкретных примерах, якобы невозможность чего-то сделать на стороне СУБД, и якобы приемущества реализации чего-то на стороне промежуточного звена. И, требовать доказывать преимущества двузвенок, вместо того, чтоб доказать приемущества выбранной Вами архитектуры начали Вы, а не я. Вспомните мой вопрос про Success Story и проблемы двузвеник, которые Вам пришлось решать. Интерес был непраздным. В ответ я опять услышал набивший оскомину фетиш "масштабирование", покоторому я проехался уже не раз. Не надо мне ничего доказывать. Я себе уже все доказал ((с) В.Высоцкий) Прохожий.....]И если действительно нет никаких достоинств, то зачем вы рекомендовали автору "совсем обратное"? Ответил выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 14:03 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
Наверное пора подводить черту. Во-первых на основании высказываний участников, собственных изысканий, советов друзей сформировалось у меня вполне устойчивое мнение. Во-вторых, врядли что нибудь кардинально новое будет сообщено в дискуссии. Итак. Абстрагируемся от всяческих "...звенок". Не суть важно сколько звеньев, важно как устроена архитектура системы. У меня сформировались вполне четкие постулаты. Выскажу. Бизнес логика. Все таки место ей на сервере БД. Мой ЛИЧНЫЙ опыт мне ЛИЧНО доказывает, что бизнес логика написанная при помощи простых хранимых процедур на декларативном SQL (коллеги, прошу обратить внимание, декларативность языка - есть выдающееся его достоинство, это вам подтвердят любые эксперты в области компьютерных языков), при насыщении системы продуманным и богатым набором пользовательских функций (почему все о них забыли? это же мощнейщее средство - мне они очень и очень помогали!) - весьма эффективна, по скорости непревзойденна. Что надо-то на самом деле? ТЩАТЕЛЬНЕЙШЕЕ ПРОЕКТИРОВАНИЕ БД - и все. Разбивка таблиц по подсистемам, проектирование процедур как API системы, смоделировав поведение, соглашение по именам (ОЧЕНЬ ВАЖНО), префиксы имен объектов системы (ОЧЕНЬ ВАЖНО) - одним словом "Arbeit, Arbeit und Disciplin". Я не встречал в своей практике случаев когда невозможно было обойтись одним T-SQL. Мне могут заметить, что я не делал больших систем. Да не делал. Но расчеты и обработки - такие вывернутые приходилось делать - мама не горюй! И ничего. Очень даже работают. В той же энергетике. Так это T-SQL! А PL/SQL еще более наворочен из того что я знаю. Даже наверное излишне. А сколько еще инструментов имеют современные СУБД? Дискуссия тоже это подтверждает. Сервер приложений. Необходимость сервера приложений для меня была не очевидна, сейчас еще более не очевидна. Просто нужен инструмент: А) дающий возможность удаленного доступа к БД и бизнес логике расположенной на БД; Б) регулирующий нагрузку на стадии удаленного доступа; В) обеспечивающий некоторую достаточную степень безопасности для сервера БД, с тем чтобы (простите мне мой французский!) не выставлять его (сервер БД) голой ж..ой в интернет...Это и есть сервер приложений? если да, то он таки нужен... Об интерфейсе. Все таки web. Я тут встретил старого приятеля он большой спец по web и .NET работал в Москве, потом вернулся - не нравится потогонка, лодырь (но при этом светлая голова). Так он мне показал свои фокусы на AJAX - весьма развитые штучки можно сделать, если грамотно спроектировать, вполне и очень даже юзабельно! О платформе Желательно MS. Однако если встанут непреодолимые препятствия - можно иные, но в любом случае, даже тот же JBoss не будет содержать в себе БЛ. Ни за что... О простоте Коллеги которые строят мудреные системы где часть БЛ на сервере, часть на СП, строят сложную модель объектов, выстраивает маппирование ХП на объекты...придумывают внутренний язык системы - ох, от лукавого это все... Коллеги, обращаюсь к вам - простота, сама по себе достоинство! если мы хотим получить новую функциональность посредством неадекватного усложнения системы тогда ну ее на х... эту новую функциональность. Это значит что надо остановиться и подумать: о природе новой функциональности (а откуда она упала на нас?), о способах приобрести ее (если она нужна) иным путем. И скорее всего решение будет найдено. Я тут промоделировал одну схему, которую мне предлагал некий человек при которой в БД строиться только минимальная структура - хранилище объектов, а бизнес логика поддерживается красивой и развитой объектной моделью вне БД. И что? На первый взгляд все красиво. Начал проектировать инструмент манипуляции объектами в модели (добавление новых классов и объектов, изменение атрибутов etc.). Очень быстро выяснилось, что потребуется генерация сложного динамического SQL встроенного в модель, умного, хитро вывернутого, ЧРЕВАТОГО НЕОЧЕВИДНЫМИ ОШИБКАМИ - и все для чего? для того, чтобы записывать результаты работы с этой объектной красотой в БД. Ради этого столько крови? фи... Вытягивать данные из такой структуры БД в отчеты тоже вылилось в какой то абсурд. Сначала надо вытянуть запрашиваемые объекты (до этого надо написать инструмент создания запросов для данной объектной модели - еще один паровой велосипед!), потом средствами языка для этого совершенно не приспособленного опросить объекты (разве это сравниться с элегантной лаконичной красотой SQL ?) выложить результат в некую структуру: либо XML, либо еще что нибудь свое...Ну и на хрена все это? ИМХО этот путь ведет в ад. Пусть лучше я буду ретроградом и буду масштабировать аппаратурой БД, но в этот кошмар с написанием ОО-моделей я втягиваться не хочу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 14:03 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin MLightНасчет СУБД<> Server J2EE<>WEB SERVER<>HTTP Client Видел в действии технологию от Oracle (на примере приложения OEBS), на 33600 модемной связи можно работать, хотя по документации заявлено, что работать можно даже на 9600!!! СУБД - Oracle DB Server J2EE и WEB SERVER - Oracle AS Client - Java сервлет (если не ошибаюсь с терминологией) Все платформонезависимо, неограниченная маштабируемость, среда разработки Oracle Forms and Reports. Да существуют проблемы, да убогий интерфейс, но технология рабочая. Про маштабируемость только читал, но искренне в это верю :). Только там нет никакого апп.севрера с бизнес-логикой. Формзовый сервер - это голимый PL\SQL клиент. Вся логика зарыта на стороне СУБД в туевой хуче пакетов. Явааплеты понадобились, дабы реализовать жалкое подобие MDI интерфейса. Работает этот интерфейс чудовищно тормознуто. Да, древняя технология, не особо красивая, но повторяю, лично работал через модемное подключение 33600. Говорят существуют проблемы при нестабильной связи, но покажите мне промышленную систему с web-клиентом. Ни SAP, ни MS этим похвастаться не могут. И что в нем чудовищно тормознутого????? Я не понимаю. Насчет бизнес-логикой, конечно большая часть зарыта на сервере БД, но часть все-таки разработана на сервере приложений в т.ч. и "Персонализация". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 14:16 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
MLightГоворят существуют проблемы при нестабильной связи, но покажите мне промышленную систему с web-клиентом. А он обязательно должен быть WEB? ;) MLightНи SAP, ни MS этим похвастаться не могут. У них есть классические Win32 тонкие клиенты. MLightИ что в нем чудовищно тормознутого????? Я не понимаю. С каких это пор GUI на яве стал работать так же быстро, как GUI Win32 клиент? :) MLightно часть все-таки разработана на сервере приложений в т.ч. и "Персонализация". Давайте не будем врать друг другу. Нет там апп. сервера, и присутствет классический WEB сервер с дополнительным функционалом. Маркетологи могут его называть как угодно (iAS), WEB сервером он не перестанет быть. "Персонализацию" можно реализовать и без явы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 14:27 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin MLightГоворят существуют проблемы при нестабильной связи, но покажите мне промышленную систему с web-клиентом. А он обязательно должен быть WEB? ;) Для филильных организаций предпочтительно pkarklin MLightИ что в нем чудовищно тормознутого????? Я не понимаю. С каких это пор GUI на яве стал работать так же быстро, как GUI Win32 клиент? :) Тоже самое, что Феррари быстрее БМВ. Если скорость реагирования интерфейса 1мс против 0.5 мс, какая разница!!! pkarklin MLightно часть все-таки разработана на сервере приложений в т.ч. и "Персонализация". Давайте не будем врать друг другу. Нет там апп. сервера, и присутствет классический WEB сервер с дополнительным функционалом. Маркетологи могут его называть как угодно (iAS), WEB сервером он не перестанет быть. "Персонализацию" можно реализовать и без явы. А что вы хотели от AS? Маны небесной и решения всех проблем. Там обязательно должен быть web-сервер, если клиент это explorer, firefox еtс. Согласно требованиям GeenS очень подходит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 15:07 |
|
||
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#18+
MLightДля филильных организаций предпочтительно Можно поинтересоваться Вашей точкой зрения почему? MLightТоже самое, что Феррари быстрее БМВ. Если скорость реагирования интерфейса 1мс против 0.5 мс, какая разница!!! Я незнаю на каком оборудовании Вы сравнивали производительность, но на средней рабочей станции разница быстродействия контроллов заметна невооруженным глазом. И она различается не в два раза, а минимум на порядок. MLightА что вы хотели от AS? Маны небесной и решения всех проблем. Я? Ничего! Но не стоит поднимать его "уровень" до апп. сервера. Кесарю - кесарево. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 15:16 |
|
||
|
|
start [/forum/topic.php?all=1&fid=33&tid=1548999]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
48ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
292ms |
get tp. blocked users: |
2ms |
| others: | 272ms |
| total: | 662ms |
| 0 / 0 |
