Java vs .NET
 
28.10.2003
Андрей Драница


 
стр. 1
стр. 2 >>


Какие новые товары
Вступили нынче в карантин?
Пришли ли бочки жданных вин?
И что чума? и где пожары?
И нет ли голода, войны
Или подобной новизны?
А. С. Пушкин. «Евгений Онегин»

Дабы ввести читателя в курс дела, начну с конкретного примера. Предположим, вы — владелец маленького оптового магазинчика стройматериалов. Осознав, что вести учет в тетрадке неудобно, вы решаетесь на минимальную автоматизацию. Разумеется, ни о каком «тяжелом» покупном продукте речи нет, гораздо проще решить задачу подручными средствами, для чего привлекаем знакомого программиста, который создает базу данных (например, в Access) с несколькими таблицами, одна из которых приведена для примера.

За компьютер сажаем студента, который получает от продавцов на бумажке сведения о заказах и вносит их в БД. Практически никакого программирования. Это классическое локальное приложение, в данном случае реализованное на базе Access.

Бизнес, однако, ширится, и постепенно наш студент перестает справляться с вводом заказов, распечаткой отчетов и прочей рутиной. Конечно, можно завести второй ПК, создать там вторую БД и прикрепить к ней часть менеджеров, но это неминуемо усложнит работу, ведь теперь банальный общий отчет просто так не получить, его придется сводить из двух. К счастью, наш знакомый подсказывает, что компьютеры можно объединить в локальную сеть, оставив базу данных лишь на одном из них, и тогда вносить изменения можно будет хоть с пяти компьютеров. Казалось бы, вот оно оптимальное классическое файл-серверное решение!

Но постепенно вы начинаете замечать, что время отклика системы стремительно увеличивается, — если раньше файл открывался за секунду, то теперь внесение изменений занимает десятки секунд. Как человек, «кое-что понимающий» в компьютерах, для обслуживания БД вы покупаете самую мощную машину и модернизируете локальную сеть с 10 до 100 Мбит/с. Поначалу это дает результат, но вскоре «тормоза» появляются вновь. Снова идем к спецу с двумя извечными вопросами: кто виноват? что делать? А происходит следующее: наша база растет не по дням, а по часам. При работе с таблицами на ваш компьютер перекачивается огромный объем данных. Вы вносите изменения (на что действительно уходят доли секунды), а потом файл снова медленно бредет по сети обратно на сервер. Конечно, файл можно разбить на части, например поквартально, однако ясно, что бухгалтер, которому нужен доступ ко всей годовой отчетности, будет против.

Теперь второй ключевой вопрос: что делать? Выход в клиент-серверной технологии. Пишется специальная программа (клиент), которая ставится на каждый компьютер. Теперь, когда нужно внести какое-нибудь изменение, эта программа отсылает серверу запрос, где он и выполняется. Таким образом, по сети передаются в основном запросы и частичные выборки данных. Выигрыш в скорости очевиден. Наученный горьким опытом, вы интересуетесь: «А если рабочих мест будет не двадцать, а сто двадцать или даже двести, эта система будет работать?» и получаете обнадеживающий ответ: «Да хоть тысяча, понадобится только купить сервер помощнее и все. Пять минут делов!»

Казалось бы, панацея найдена, по крайней мере, с производительностью проблем уже не будет. Как бы не так — проблемы приходят оттуда, откуда не ждали. Однажды к вам заглядывает ваш заместитель и обращает внимание на некоторые «странности» в отчетности. Оказывается, в нашей многострадальной базе по неизвестным причинам периодически происходят странные изменения: исчезают и появляются «задним числом» заказы; менеджеры устраивают словесные потасовки по поводу принадлежности того или иного заказа; иногда изменяется статус, даты и цены уже выполненных заказов; по фирме поползли слухи, что кто-то «слил» базу данных по клиентам на сторону… Конечно, можно немного изменить программу, например, запретив указывать дату ранее сегодняшнего дня, но кто помешает недобросовестному сотруднику просто переставить время на своем компьютере? И как быть с другими вопросами? Кажется, выхода нет, хоть обратно к тетрадке возвращайся! Да и программист тут вроде бы не поможет — дело-то не в программах, а в людях.

К счастью и у этой проблемы есть решение — трехзвенная архитектура. Помимо сервера базы данных и клиентской программы появляется промежуточное звено — сервер приложений, выполняющий функции сервера бизнес-логики. По сути, это обычная программа, устанавливаемая на сервере с БД (или, если нагрузка велика, на отдельном сервере) и выполняющая проверку вводимых данных и прочие сервисные функции. Каким образом она может избавить нас от головной боли? Путем предварительной проверки поступающих запросов на предмет соответствия бизнес-логике. Например, манипуляции со временем станут невозможны — время заключения заказа устанавливается не по часам на компьютере менеджера, а по часам на сервере. Немного модифицируем клиентскую программу, чтобы та при старте требовала имя и пароль, и тогда можно запретить менеджерам просматривать информацию по заказам своих коллег. Короче говоря, очередная панацея найдена. Теперь работа выглядит следующим образом: во время запроса данных клиентская программа отсылает на сервер бизнес-логики вместе с запросом имя сотрудника и его пароль. Сервер проверяет, верен ли пароль, и можно ли этому сотруднику предоставлять требуемую информацию (например, рядовому менеджеру незачем видеть финансовые отчеты, его дело — работа с клиентской базой); затем обращается к БД и отсылает ответ клиентской программе. Кажется, проблем отныне уж точно не возникнет1.

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

За всей этой борьбой — сначала с технологиями, затем с собственными сотрудниками — мы как-то забыли об основе основ — наших клиентах. Именно вокруг них должен крутиться любой бизнес, именно клиент — краеугольный камень любого дела. Так вот, с развитием современных технологий клиент поумнел, ему подавай все сразу и быстро, так что вполне реальна ситуация, когда к вам начнут обращаться крупные клиенты со странными вопросами типа: «А нельзя ли, мол, покупать и отслеживать заказ через Интернет?» К тому же появились и другие заботы: во-первых, вы решили открыть второй офис, а цена за выделенную линию от офиса до офиса снова заставила задуматься о «тетрадочных» временах; во-вторых, в нашей клиентской программе периодически отлавливаются ошибки, вследствие чего администраторам приходится регулярно переустанавливать ПО на всех компьютерах (а их все больше и больше). Бизнес растет — ему требуются новые решения.

Итак, нужно:

- еще больше упростить администрирование клиентского ПО;
- как-то связать рабочие места второго офиса с нашей БД;
- предоставить клиентам возможность связываться с нами (приобретать товары, отслеживать заказы, просматривать каталоги и т. д.) через Интернет.

Самый дорогой сорт кофе в мире — Kopi Luwak (600-800 долларов за килограмм). В мешки попадают только зерна, прошедшие через пищеварительный тракт индонезийской виверры (Paradoxus Hermaphroditus). Понятно, что сбор такого кофе — занятие малоприятное, да и возможности виверр по пропусканию через себя кофейных зерен ограничены. Поэтому Kopi Luwak производится очень мало — от 250 кг в год.Каково решение? Тонкие клиенты и веб-технологии. Начнем по порядку — с упрощения администрирования клиентского ПО. Самый логичный ответ: проще всего управлять тем, чего нет. Нет программы — нет проблемы. А как же тогда работать с нашей БД? Через браузер.

Вторая проблема — связь удаленного офиса с нашей БД. Вместо дорогостоящей выделенной линии офис-офис покупаем во вторую контору обычный модем, Интернет-карту и наслаждаемся современными технологиями за 20 долларов в месяц. При чем здесь Интернет? Смотрите дальше.

Третья проблема — Интернет-магазин. Можно, конечно, перепоручить его обслуживание сторонней организации, но так как Интернет-магазин всего лишь добавка к обычному магазину, к тому же для решения первых двух проблем все равно придется строить сетевую инфраструктуру, целесообразно держать его под рукой. Для этого придется обзавестись выделенным подключением к Интернету, а также прикупить сервер и некоторое ПО — в первую очередь веб-сервер3. Принципиальная схема показана на стр. 27 (подробнее см. раздел, посвященный Java2EE).

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


1  На самом деле, 99 процентов этих проблем можно решить и при работе в клиент-сервере. Другое дело, что «трехзвенка» позволяет локализовать модуль управления бизнес-логикой, и при внесении изменений в бизнес-логику не придется переустанавливать клиентские программы на всех компьютерах в компании. — Прим. ред.
2 Отчасти этим и объясняется высочайшая популярность Delphi в России — идеального средства как для клиент-серверного, так и трехзвенного решения.
3 Можно ограничиться и более дешевым вариантом — платным хостингом.


 
стр. 1
стр. 2 >>

<<…плюс джаваизация всей страны
Все материалы номера
Кофе или чай >>