Большой проект (клиент-серверная система)

Попробуйте J2EE, язык программирования Java, по остальным парметрам ограничений нет. Посмотрите примеры подобных проетов на www.ibm.com Там же можно бесплатно взять на пробу сервер приложений и различные приложения.

 

Поподробнее условия
1. Кол-во рабочих мест
2. База (железо, сеть и т.д.)
3. Объем документооборота
4. Территориальное удаление рабочих мест

глядишь, может быть и посоветуем чего ;-)

 

боже мой, неужели Вы думаете, что на этом форуме, да и на любом другом, Вам дадут квалифициованный совет?
а Ваш вопрос я бы переформулировал и составил из двух связанных частей:
1. как можно с минимальными затратами создать корпоративную информационную систему, которая даст максимальный эффект? (ответ на этот вопрос волнует многих, и не только в России )
2. как обеспечить минимальную ТСО после внедрения системы.

ПС. хотя можете воспользоваться "аргументированным" советом, который Вам дал HorstWessel.
ППС. в принципе, с десяток таких советов и я могу Вам дать .

 

Off
AlTk
Напрасно Вы считаете людей вокруг себя глупее вас самих.
Вообще говоря, вопрос был сформулирован вполне определнно: язык, сервера, кадры, курсы... Ваша же "переформулировка" не более чем демагогия.

 

1C? 8.0 можно попробовать.

 

Зачем изобретать велосипед? Есть конторы которые такие вопросы решали и решают на профессиональном уровне. Дешевле обойдётся.

 

"Проект не будет затачиваться под конкретную фирму, хочется универсальную систему создать, поэтому:"
в реальности такого не бывает.

"По поводу готовых сторонних систем,"
это не готовые системы, а конструктора.

почему-то список систем у Вас состоит из одной системы - 1С разных версий. и на основании того, сколько памяти отъедает окошко выбора БД, Вы делаете вывод о всех остальных, так что-ли?

 

2 dj
Вы бюджет сначала огласите. А то разговоры о платформах, БД, железе - туфта. Нет бюджета - ничего не будет.

 

100 Мег. Тут дело не в том, сколько занимает, а как правильно говорит Гость

т.к. даже внутри 1С еть локальная (т.е. однопользовательская), которая стоит $140, а есть 8.0, например УПП, который в серверной базовой комплектации на 10 рабочих мест $6000 стоит, причем это без учета лицензионных ОС(Win) и СУБД(MS SQL), да плюс железо, на котором это будет работать... А есть еще Парус (который на в большом варианте на Оракле работает), Аксапта, Navision, продукты фирмы SAP. Так там деньги от десятков КилоБаксов только начинаются...
Грубо, какой сегмент рынка?

 

про бюджет таки Вы не сказали. От этого много зависит. Одно, когда нужно определится с бюджетом, другое, когда его нужно освоить.
без указания бюджета ответить правильно на Ваши вопросы нельзя. Одно дело когда делать Ваш ERP/CRM самомтоятельно на Delphi/IB это одни деньги. коробка дельфей стоит около 3000 долларов на человека. Приличный дельфийский разработчик стоит 700-800 баков в месяц на руки ему. Одним не обойдешься, нужна команда, с менеджером, архитектором, тестерами и т.д. Им нужны средства коллективной работы. Они тоже стоят денег. Больших.
Другое дело - J2EE, там деньги еще больше. Если брать коммерческие средства разработки, сервера приложений и т.д. Нормальный разработчик стоит в 1.5 или 2 раза больше чем дельфийский.

Курсы и сертификация тоже стоят денег. Порядка 5 тысяч баков за курс на человека. Это если брать полный курс. По большому счету все равно, чему обучаешься, J2EE, .NET или чему то еще.

Поэтому и надо плясать от бюджета. Если конечно не опираться на продукты с краснооктябрьского рынка. на этом можно "поэкономить". Но на зарплате не поэкономишь.

 

Гость

Не за четыре же буквы эти деньги берут. Посмотрим внимательней.

При этом выполняет свою работу в 5 раз быстрее и надежнее так как владеет мощнейшим инструментом, имеет компонентную архитектуру, серию шаблонов и готовых фреймоворк(и?) Значительная часть функциональности уже реализована сервером приложений.

Курсы действительно дорогие, если говорить о полном курсе, потому как нужно помимо собственно "традиционного" программирования нужно освоить технику разработки приложений J2EE. Как правило, такие курсы можно найти у производителей серверов приложений.
А вот, по большому счету, учиться не все равно чему: стандарт J2EE является открытым (в отличие от .NET) и поддерживается различными производителями. Это дает Вам возможность выбора: или приобретать готовые серверы и приложения с полным циклом поддержки и мало тратить на обучение, или больше тратить на обучение и получать бесплатно серверы и приложения. Это два предельных случая, хотя возможны и другие варианты.

 

о, боже мой!
а я-то думал, что же надо использовать???
а тут делов-то - взял J2EE и готова КИС, причем какая-то функциональность уже реализованан каким-то сервером приложений (налогового учета или расчета прочности трубы там случаем нет?).

ПС. HorsWessel, кстати, нормальный разработчик на COBOL, я так думаю, будет стоить дороже всех других разработчиков, вместе взятых.
да, и еще. стандарт-то открытый, только вот реализация разная у разных производителей, так что не факт, что созданное у одного будет работать у другого.

ППС. dj, почему Вы не хотите приобрести готовую систему, Вам _интересно самим_ ее написать?

 

AlTk
Я ответил Гостю о цене проекта на Delphi, J2EE или .NET - к чему Ваш возглас о стоимости разработчика на COBOL? Опять демагогия.

Не утрируйте, я нигде не сказал что J2EE это панацея.

Что касается налогового учета или прочности трубы то, скорее всего, компоненты с такими функциями уже есть. Мне они не интересны. Но! Если ваш "налоговый учет" является частью КИС, то Вы обязаны реализовать механизм взаимодействия "налогового учета" с другими компонентами системы. В случае компонентов J2EE все эти механизмы уже реализованы сервером приложений, разработчику остается лишь выбрать подходящий тип компонента(ов) (или шаблон) для реализации собственно "налогового учета" - и все!

Единственно верное замечание - различная реализация серверов приложений. Но если бы Вы потрудились внимательнее прочитать мой пост, то смогли бы увидеть:

 

" ответил Гостю о цене проекта на Delphi, J2EE или .NET - к чему Ваш возглас о стоимости разработчика на COBOL ... "
к тому, что Ваши выводы неправильны - это я о цене проекта "на Delphi, J2EE или .NET".

"В случае компонентов J2EE все эти механизмы уже реализованы "
интересно, Вы про какие механизмы взаимодействия говорите.
я перестал Вас понимать.

 

AlTk

Откуда это видно? Это следует из из того, что специалист на COBOL стоит дорого?

Взаимно.

Я говорю об RMI, JMS, Web-Services, ORB...

 

да нет, это видно из того, что цена проекта не определяется языком программирвоания и зарплатой разработчику за этот язык.

"Я говорю об RMI, JMS, Web-Services, ORB"
то есть, по Вашему это как-раз в них уже реализованы механизмы взаимодействия учета налогов и расчета прочности трубы, так что-ли? :D
видели мы такие механизмы взаимодействия. IPX они назывались, да TDS c OCI впридачу. :D

ПС. ну ладно, дам совет я совет dj. конкретный совет, чисто пацанский - в качестве языка программирования - Ada или Jovial, а в качестве БД - Terradata.

 

HorstWessel
Вот не надо про сервера приложений. что они часть функциональности уже реализуют. С точки зрения бизнеслогики они не умеют ничего. Поскольку бизнеслогика должна быть реализована разработчиком, используя сервисы сервера. Далеко не все сервера умеют делать все, что бы хотелось. И насчет скорости разработки это тоже весьма далеко от правды. И компонентной модели, впрочем тоже. да, J2EE подразумевает под собой компонентную модель, да, у нее есть набор общедоступных фреймворков (которые почти всегда НЕ реализуют бизнеслогику), есть набор паттернов проектирования, общедоступный. НО! Никто не запрещает использовать тот же подход и в программировании на Delphi или С# или на чем угодно еще. Никто не запрещает использовать те же паттерны при проектировании приложений на чем угодно. НИКТО! Применение того или иного подхода просто говорит и грамотности проектировщика/архитектора.

Разговоры о том, что все быстрей делается на J2EE верны только отчасти. да, быстрей, но когда? когда делается приложение масштаба корпорации. Причем не нашего мелкого предприятия, а нормального американского предприятия. Для примера, американская компания, которая принимает 300 тысяч входящих телефонных звонков в сутки не считается большой. Это отвлеченный пример, что бы просто применить нужный масштаб.
И потом, J2EE подразумевает под собой слой бизнеслогики, а не слой представления или хранения данных. Их все равно делают на чем то другом. И на Java тоже, но это другая Java. Вы скажете, а как же JSP и прочее, что позволяет вынесли слой представления на сервер? Это частный случай. причем не очень удачный.


dj
Вы правы. Но тоже отчасти. Если вы знаете, что Вам дадут 10 рублей, вы не пойдете покупать мороженое в Баскин-Робинс?

 

Гость

Это вас удивляет? Бизнес-логику, по прежнему, надо реализовавать.
Но

то реализацию бизнес-логики Вы можете позаимствовать у других и, без дополнительных усилий, интегрировать со своим проектом.

Не используйте их. А что бы вам хотелось, но сервер приложений этого не мог и какой?

Для этого Вам, на чем угодно, придется вначале создать сервер приложений. Это возможно, но какой ценой???

Для заказчика все равно, на чем написана его OSS, хоть, как выразился AlTk, на Коболе. Причем не зависимо от его размера. Ему плевать на все эти детали. А вот для команий-разработчиков это вопрос важный. Используя J2EE можно создавать приложения и сервисы одинаково эффективно, как для крупных потребителей, так и для мелких.

Это еще один плюс, который позволяет интегрировать унаследованные данные или сервисы.

И очень полезный.

Не более нейдачный чем Web вообще.

 

HorstWessel

Нет. Меня это не удивляет. Я нооборот заострял на этом внимание.

Это маркетинговые сказки. Вы, уважаемый, сами то когда нибудь это делали? Усилия то будут и о-го-го какие. Мало не покажется.

Для того что бы использовать компонентную модель в своих приложения или паттерны проектирования мне НЕ НУЖЕН сервер приложений. Сервер приложений есть слой бизнес логики, который вынесен в отдельное место. В общем случае он не обязателен. А паттерны это вообще шаблон действий. Не более того.

Используя J2EE НЕЛЬЗЯ создавать маленькие экономически эффективные приложения. Хотя бы потому, что применение J2EE тянет за собой всю инфраструктуру, необходимую для нормального функционирования J2EE приложений. Хуже того, J2EE даже с точки зрения скорости разработки, и с точки срения скорости работы (хотя так неправильно говорить) эффективна при больших нагрузках.

Да это вообще не плюс. Это не положительное или отрицательное качество. Это просто предназначение этой технологии.

А с точки зрения слоя представления веб вообще не очень удачное дело. Он хорош для представления текста. А не всего основного.

 

Пооследняя фраза неправильная.
Правильно Не всего остального

 

Гость

Неоднократно.

В тысячу раз меньше чем писать с нуля.

В этом случае вы не сможете эффективно "расшарить" бизнес-логику, и сведете роль компонентов к нулю.

А вот это уже действительно маркетинговые сказки, хотя бы потому, что уже давно существуют средства разработки поддягивающие всю инфраструктуру J2EE приложений вместо Вас. Использовать-ли их или писать все самому - дело вкуса, или задачи.

Хорошо. Положительное предназанчение.

Конечно, полноценный интерфейс выглядит лучше и более функциональный. Но web, все же, вообще, удачное дело для слоя представления, потому как не требует доставки и развертывания на клиентской стороне.

Кстати, еще один плюс: развертываение приложений и последующее обслуживание.

 

HorstWessel

А я говорил, что их нет? Неправда. Я говорил про ЭКОНОМИЧЕСКУЮ эффективность МАЛЕНЬКИХ приложений J2EE. Ее (эффективности) нет! Эти средства (развертывания) стоят ОЧЕНЬ дорого. И применение таких средств ЭКОНОМИЧЕСКИ неоправдано. Именно поэтому применение J2EE ЭКОНОМИЧЕСКИ не оправдано на маленьких проектах.

Предназначение не бывает положительным или отрицательным. Оно просто бывает.

Веб, еще раз повторюсь, не очень удачное решение для слоя представления. С точки зрения юзабилити и повторного использования - отвратителен. Смешивание собственно данных и описание представления - отвратительно. И это не только мое мнение.

З.Ы. Я не противник J2EE. Я просто говорю, что каждой технологии есть свое место. место J2EE - большие и высоконагруженные приложения, там где распределенные клиенты, там где куча транспортных протоколов и т.д. Т.е. приложения для больших предприятий. Действительно больших. Не нужно пихать J2EE всюду. Это не правильно. Для приложения, которое будет обрабатывать даже сотни документов в день J2EE избыточен и слишком дорог.
Возвращаясь к тому, что хочет узнать dj - нужно очень хорошо представлять, что хотят получить заказчики. И, возможно, в силу ограничений бюджета, в силу того, что просто не нужно использовать такого монстра как J2EE, а это действительно монстр, нужно выбрать что-то другое.

 

Гость

Да, Вы говорили, что нет эффективности вследствие "необходимости тянуть всю инфраструктуру J2EE приложений. Я Вам возразил. Теперь Вы утверждаете что эффективности нет потому, что

Если $99 не осилите за SUN Developer Studio, тогда возьмите Eclipse бесплатно. То же самое и серверами приложений - цена от 0 до затрудняюсь ответить. Кроме того вы не учитываете возможность аренды сервера (Google вам в помощь).

Повсеметсное распространение браузеров говорит об обратном.
Если браузер

используйте апплеты или Java Web Start. Браузеры это позволяют. В любом случае не нужно ломать голову и тратить средства на поддержку приложений на стороне клиента.

P.S.
Я не утверждаю что J2EE следует использовать каждой торговой палатке, но все же J2EE уже эффективно там, где предполагается развитие.

 

Вообще то поклонение какому то одному средству разработки всегда считалось признаком непрофессионализма. Нет можно писать всю жизнь на чем то одном, но кричать что это единственное на чем вообще можно хоть что-то написать...
Опять же соглашусь с Гостем

Важна грамотность и умение вести разработку, а конкретное средство вторично.

ЗЫ: Я не спорю что J2EE прекрасно или нет.

 

Разговор ниачем. Вы посмотрите изначальный пост. Человек более-менее задачу сформулировать не может. А вы тут спорите на чем лучше реализовывать бизнес-логику. Он может и слова то такого не понимает. Так разве что языками помолоть.

 

HorstWessel

Я с самого начала говорил про экономическую эффективность. Прочитайте внимательно.

Не кривите душой, говоря о бесплатных или почти бесплатных серверах и IDE. Они есть, я не говорил обратного. Только кто, где и зачем их применяет? Почему то для критических бизнес приложений применяют WebSphere, weblogic, BES, стоимость которых стартует с десятков тысяч долларов. а JBuilder, который позволяет делать EJB стоит что-то около $1500 на разработчика.

Вот тут Вы меня рассмешили. для выполнения апплетов и и приложений с вебстартом требуется установленная джава машина, как минимум. Если их нет, то конечно можно ее поставить. Но апплет отчасти, а приложения с вебстатртом полностью, никакого отношения к браузеру, как к клиенту отношения не имеют. Браузер выполняет роль "запускателя" джава машины. Т.е. веб нужен только для того, что бы по http затянуть на клиента джавовский архив и запустить его, предварительно запустив джава машину. и ВСЕ! т.е. вы имеете уже rich клиента, написанного на джаве.

По сути своей это ничем не отличается от случая, когда один исполняемый файл лежит на файловом сервере и его запускают все клиенты.

Оно говорит о том, что распространено смотрение страничек, как текста. Не более того. И браузер действительно очень удобный инструмент для этого. Он ведь для этого и предназначен. Для просмотра гипертекста. Все остальное - от лукавого.