23 октября, вторник 17:43
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

iBank 2 - о Сервере Приложения

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • iBank 2 - о Сервере Приложения

    Уважаемые участники Форума!

    Дабы не загромождать топик о воплощении тонких клиентов обсуждением технических вопросов реализации Сервера Приложения "iBank 2", данная тема была мною вынесена в отдельную.

    Итак начинаем.

    Участники Форума:

    - ender - Александр Аксельрод, разработчик компании "БСС"

    и

    - hedin - Сергей Астахов, проработавший в КОМИТЕ много времени, известный многим как активный участник фидошной эхи RU.JAVA (в Профиле на Банкире указано, что работает уже в компании "БИС")

    высказали в форуме свои мнения об ущербности Сервера Приложения "iBank 2".

    отправил Александр Аксельрод, aka ender, компания "БСС"

    ...Система не масштабируема. В системе используется специализированный сервер приложений собственной разработки и собственный протокол взаимодействия с ним. Ввиду этого невозможно использовать промышленные сервера приложений сторонних призводителей...

    ...Итак подытожив умозаключения великого разработчика Димитрия.

    1. Бифит пошел своим путем и написал свой сервер приложений, решим при этом попутно (по его словам) все задачи масштабирования и балансировки. Сточки зрения разработчика заслуживает уважения - изобрести свой велосипед и его реализовать...

    2. Следствие первого - если Банк захочет промышленное решение - придется заплатить несколько сотен килобаксов - (достойный ответ разработчика) - собствено я с этого и начинал. Сначала переложил на заказчика разработку своего Jerry, а потом еще и денег попросит чтобы подключить WebLogic....

    отправил Сергей Астахов, aka hedin, компания "БИС"
    Насколько я понял, вы в своём сервере не удосужились поддержать хотя бы часть спецификаций J2EE, решив делать всё по своему.
    Далее в своих письмах я постараюсь максимально доходчиво при минимуме технических тонкостей высказать свою точку зрения по двум вопросам:

    - Почему для банковской компоненты системы "iBank 2" мы не стали использовать промышленные сервера приложений, соответствующие спецификации Java 2 Enterprise Edition (J2EE)?

    - Почему Сервер Приложения "iBank 2" (неофициальное название - Jerry) не был реализован в соответствии со спецификацией J2EE?


    Ответ прост и сложен одновременно.

    Если кратко - для системы Интернет-Банкинга нет никакой необходимости в промышленном J2EE-сервере.

    J2EE-сервер - избыточен для таких задач.

    Небольшой ликбез.

    Что такое J2EE ?

    J2EE - это прежде всего набор спецификаций на службы, программные интерфейсы (API) и протоколы, для разработки распределенных серверных приложений.

    Ключевые технологии и стандарты J2EE - JDBC, JNDI, EJB, RMI, JSP, Java Servlet API, XML, JMS, Java IDL, JTS, JTA, JavaMail, JAF.

    Одна из основных изюминок и наболее маркетингово раскрученная технология J2EE - это EJB (Enterprise Java Beans).

    EJB - это каркас для разработки и установки распределенной бизнес логики корпоративных приложений.

    Основой этой технологии является EJB-компонента - компонента, в которой реализуется бизнес-логика. Спецификация EJB определяет как и когда EJB компоненты должны связываться с их контейнерами.

    Контейнер обеспечивает все основные службы, такие как служба каталогов, управление транзакциями, безопасность, пулинг ресурсов и отказоустойчивость. Реализация такого контейнера - это cердце J2EE Сервера Приложений.

    Как и у всякой технологии у EJB существуют достоинства и недостатки.

    Достоинства:

    - "Прозрачная" масштабируемость - масштабируемостью разработаевымаего приложения занимается Сервер Приложений, производители которых могут применить сложные алгоритмы масштабирования для удовлетворения практически произвольной нагрузки. Тем не менее, слово "прозрачная" не случайно заключено в кавычки, ибо масштабируемость всегда накладывает отпечаток на логику приложения.

    Чтобы получить ПО-НАСТОЯЩЕМУ МАСШТАБИРУЕМОЕ решение, НЕОБХОДИМО на этапе разработки привязываться к специфики конкретного Сервера Приложения конкретного разработчика.

    - Наличие всей необходимой инфраструктуры (с избытком) для разработки приложений.

    В Сервере Приложения, соотвующего спецификации EJB, уже есть все что нужно разработчику - подсистемы управления транзакциями, безопасностью, временем жизни компонентов, JNDI (Java Naming and Directory Interface) и т.д.

    Минусы:

    - Увеличение времени разработки - как не парадоксально, но для разработки решения на базе EJB требуется больше времени и ресурсов, чем при разработке аналогичного решения без использования технологии EJB. Стоимость такого решения будет дороже.

    - Плохая переносимость между различными Серверами Приложений. Разработчики промышленных Серверов Приложений в погоне за масштабируемостью и производительностью встраивают в Сервера Приложений свои фирменные технологии и механизмы, с использованием которых, разработчики приложений могут добиться реальной МАСШТАБИРУЕМОСТИ, ПРОИЗВОДИТЕЛЬНОСТИ и т.д.

    Это конечно не означает что под каждый Сервер Приложения нужно полностью переписывать код, но это существенно осложняет разработки и поддержку приложения под различными Серверами Приложений.

    - Высокая стоимость промышленных Серверов Приложений.

    IBM WEBSPHERE SERVER - Лицензия на один процессор + годовая поддержка - 10700$

    Sun Java System Application Server Enterprise Edition 7 - Лицензия на один процессор + годовая поддержка - 10000$

    Более полная таблица с ценами - http://www.theserverside.com/reviews/matrix.tss

    Как видно цены приблизительно у всех одинаковые - около 10 000 $ за Лицензию на процессор.

    Кроме коммерческих J2EE-серверов, есть еще и Open-Source Сервера Приложений. Можно привести в пример JBOSS, на который ссылались вышеназванные участники Форума. Но:

    1. JBOSS не соответствует спецификации J2EE - http://java.sun.com/j2ee/compatibility_1.3.html (это как раз тот случай, когда все остальные плюсы и минусы уже не важны).

    2. JBOSS содержит большое количество ошибок, по сравнению с другими промышленными Серверами Приложений

    3. Хоть JBOSS и является Open-Source, но для того чтобы получить более менее толковую документацию и квалифицированную техническую поддержку придется платить деньги консалтинговой компании http://www.jboss.com

    4. JBOSS сложен в установке и поддержке.

    5. JBOSS проигрывает в производительности по сравнению с промышленными Серверами Приложений.

    Почему мы не стали использовать EJB ?

    Технология EJB замечательная и универсальная, красивая и мощная, НО:

    Технологии не должны выбираться из-за личных предпочтений разработчиков, платности-бесплатности, больших возможностей, красоты т.д.

    Технологии - это всего лишь инструмент для достижения конкретных поставленных задач.

    Когда мы начинали разрабатывать iBank 2 стояли следующие задачи :

    1. Сделать Cервер Приложения "iBank 2" быстрым.

    2. Сделать Cервер Приложения "iBank 2" надежным.

    3. Сделать Cервер Приложения "iBank 2" мастштабируемым.

    4. Иметь возможность в случае необходимости расширять и развивать Сервер Приложения.

    5. Сделать Cервер Приложения "iBank 2" легким в установке и администрировании.

    6. Cделать Cервер Приложения "iBank 2" доступным по цене, НЕ ВЫНУЖДАЯ заказчика нести дополнительные затраты на покупку чрезмерно избыточного промышленного Сервера Приложения.


    Мы перепробывали много платформ. Среди них:

    - JBOSS. На данном Сервере Приложения мы реализовали проект Internet-Трейдинга, но Сервер Приложения оказался на проверку ужасно сырым и глючным. В тот период мы также участвовали в разработке и развитии JBOSS'а. В нём есть и наш код...

    - IBM WebSphere, BEA Weblogic. Данные Сервера Приложений оказались чрезмерно тяжеловесными.

    - TomCat 3.1. На нем мы и остановили свой выбор. В процессе развития мы выкинули из него поддержку ненужных технологий (например, JSP), реализовали менеджер соединений с БД и менеджер транзакций, встроили поддержку GSL и IBTP, добавили механизм балансировки и распределения нагрузки.

    В итоге мы получили решение, которое удовлетворяет всем необходимым требованиям.

    Об использовании в Сервере Приложения "iBank 2" остальных технологий J2EE.

    Используются:

    - Java Database Connectivity (JDBC). Благодаря этой технологии cистема "iBank 2" успешно функционирует со всеми промышленными СУБД - Oracle, MS SQL Server, Sybase, PostgreSQL и IBM DB2.

    - Java servlets. Вся интерфейсная часть обработчиков клиентских запросов реализованы с использованием этой технологии.

    - JavaMail. Применяется достаточно широко для рассылки сообщений администраторам системы "iBank 2", операционистам, для интеграции с SMS-шлюзами.

    - Extensible Markup Language (XML). Один из основных "китов", на которых базируется iBank 2.

    - Java Naming and Directory Interface (JNDI). Применятся в Шлюзах, например поиск доступных принтеров в сети.

    Не используются:

    - Java Server Pages. Нет необходимости.

    - Java IDL/CORBA, Java Messaging Service (JMS). Не используется, ибо Cервер Приложения "iBank 2" - это целостная система, а не набор разрозненных компонент, написанных на различных языках программирования и размазанных по всему миру. Будет необходимость использования для взаимодействия iBank'а с внешними системами - АБСы, карточные процессинги и прочие бэкофисные программы - будем использовать.

    - Java Transaction Architecture (JTA)/Java Transaction Service (JTS). Не используется, ибо для системы "iBank 2" необходим высокопроизводительный, надежный, и в тоже время простой в использовании менеджер транзакций.

    Есть еще одна причина, по которой мы не используем J2EE-сервер. Причина - в позиционировании.

    iBank 2 - это не универсальный конструктор (универсальная платформа), в рамках которого можно решать сколь угодно разноплановые и сложные задачи.

    iBank 2 создавался для решения четко очерченного круга задач - для предоставления услуг электронного банкинга.

    Сервер Приложения "iBank 2" не позиционируется как универсальный J2EE-сервер, и предназначен исключительно для исполнения серверных модулей системы "iBank 2".

    J2EE-сервер - это прежде всего платформа для исполнения различных распределенных приложений.

    Если банк вдруг захочет писать свои EJB-компоненты для своих внутрибанковских задач, а потом запускать онные на J2EE-сервере, тогда банк со спокойной душой может сделать выбор необходимого ему промышленного Сервера Приложения, максимально полно отвечающего банковским задачам.
    Последний раз редактировалось Димитрий; 29.03.2004, 10:26.
    С уважением, Репан Димитрий
    Компания "БИФИТ" - www.bifit.com

  • #2
    Димитрий
    Контейнер обеспечивает все основные службы, такие как служба каталогов, управление транзакциями, безопасность, пулинг ресурсов и отказоустойчивость.
    В процессе развития мы выкинули из него поддержку ненужных технологий (например, JSP), реализовали менеджер соединений с БД и менеджер транзакций, встроили поддержку GSL и IBTP, добавили механизм балансировки и распределения нагрузки.
    Вот про это и речь.
    Вы фактически реализовали бОльшую часть функциональности контейнера, но используя не общепризнаные спецификации, а свои. В результате приложение без переписывания просто не переносимо на другие контейнеры. Ведь что такое тот же JTA (http://java.sun.com/products/jta/index.html) - это просто набор интерфейсов, которые может использовать приложение для управления транзакциями. Он не может являться быстрым и надёжным или наоборот медленным и ненадёжым - таковым его делает реализация. Или JMS - эта не спецификация взаимодействия с компонентами на других языках, а всего лишь API к очередям сообщений, используя которые можно легко и просто масштабировать программу по объёму документооборота. Или в Вашем сервере никакой асинхронной обработки не предусмотрено?

    Что же касается сырости и глючности того же JBoss, то по моему Ваша информация устарела минимум на несколько лет. JBoss не является сертифицированным J2EE сервером только де-юре, де-факто же он более соответствует стандарту чем большинство коммерческих серверов. Документация действительно стоит денег. Целых $10 за книжку или $100 за годовую подписку на все книжки.
    Последний раз редактировалось hedin; 29.03.2004, 15:36. Причина: Очепятка

    Комментарий

    Пользователи, просматривающие эту тему

    Свернуть

    Присутствует 1. Участников: 0, гостей: 1.

    Обработка...
    X