|
|
|
Выбор сервера приложений
|
|||
|---|---|---|---|
|
#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 |
|
||
|
|
start [/forum/topic.php?fid=33&msg=34801584&tid=1548999]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
125ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 277ms |
| total: | 508ms |
| 0 / 0 |
