Разработка распределённых программных систем для Windows

Первая статья из цикла, посвященного распределенным программным системам. "n-уровневая" модель модель построения приложений.

Введение

Как известно, "серебряной пули нет", но вот уже более 50ти лет работы по поиску наилучших способов для разработки ПО не прекращаются. Эволюция методов длится со времён Фортрана и в настоящее время её плодами пользуются миллионы программистов во всём мире. Начавшийся около десяти лет назад бум клиент-серверных технологий преобразил мир разработки коммерческого ПО. Был предоставлен целый ряд APIs, позволяющих сначала "сырое" межпроцессное сообщение (например, RPC), а затем, по мере продвижения компанией Microsoft технологии OLE (c названием которой они позже поиграли вдоволь!:)) и разработкой т.н. межмашинного (ну и слово! "Cross-machine" куда как проще) OLE и широко известной технологии DCOM. Когда всё это только появилось, и многие из разработчиков вздохнули свободнее, наслаждаясь плодами эволюции, они даже и не предполагали, что это было только начало…

Архитектуры

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

• Уровень базы данных (DB layer) представляет собой "программную прослойку", позволяющую компонентам с уровня бизнес-логики (бизнес-правилам) обращаться к данным, хранящимся в БД
• Уровень бизнес-логики (Business logic level) содержит правила (да, те самые бизнес-правила!), описывающие, каким образом пользователь обращается к данным и манипулирует ими
• Уровень представлений (Presentations level) - вершина айсберга. Это та самая прослойка между пользователем и логикой работы программы; видимая часть системы. Это тот слой в хорошей системе, через который пользователь и выполняет свою работу.

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

Теперь, когда введены основные понятия, необходимо хорошо представить себе, что такое эти самые "multi-tier models". В настоящее время для разработки приложений используются, по меньшей мере, 4 модели:

1. "Классическая" Она интуитивно используется начинающими программистами; другое её применение - в оч. маленьких тестах. Эта модель характеризуется тем, что все три уровня сосредоточены в рамках одной программы. Типичным примером таких систем являются практически все настольные "базы данных", сработанные с применение замечательного инструмента под названием FoxPro версий 2.x (да и остальные ушли недалеко!). Нет ничего проще, чем разрабатывать такие системы. Они очень просты в понимании, а для программирования практически не требуется никакой подготовки. Однако, как заметил Stroustroup, "для того, чтобы быть полезной, техника не должна быть слишком "умной""
2. Двухуровневая модель. В ней по-прежнему и представления и бизнес-логика ютятся в рамках одного исполняемого компонента, однако есть и прогресс. Из прежней построенной по "классической" модели, программы выделяется в самостоятельный уровень DB Layer. Он обеспечивает возможность по одновременному доступу к данным нескольких пользователей и освобождает программиста, работающего с бизнес-правилами от обязанностей по контролю над блокировками и разделением данных. Несмотря ни на что, это уже "настоящий клиент-сервер":)
3. Трёхуровневая модель. Все три уровня отделены друг от друга и располагаются в отдельных, самостоятельных компонентах. В случае изменения какого-нибудь бизнес-правила уже не надо отслеживать сотни связей, потому что это изменение уже подчиняется контракту на использование и чётко определяет перечень компонентов из других слоёв, с которыми осуществляется взаимодействие. Надо ли говорить, что это несравненно удобнее, чем разработка в любой из перечисленных ранее моделей. Однако здесь не всё так гладко, как хотелось бы. Как правило, когда архитекторы систем дозревают до использования этой модели ПО, они сталкиваются с рядом проблем, обусловленных следующим: система, в которой бизнес-слой выделяется в самостоятельный, нуждается в его дополнительном разбиении на два. Действительно, когда созданы предпосылки для инкапсуляции в самостоятельные объекты процессов, моделируемых разрабатываемой системой, становится очевидно, что вся её бизнес-логика распадается на клиентскую бизнес-логику и серверную бизнес-логику. При этом клиентская бизнес-логика обеспечивает приём от пользователя и передачу ему данных и информации, которые будут обработаны внутри компонентов серверной бизнес-логики и отображены в слое представлений, соответственно. Так, например, в случае моделирования некоторого объекта платёжной системы, скажем, дебетовой эл. карты, можно следующим образом представить это разделение: (рис. 1)
4. n-уровневая модель. Как это ни странно, но именно эта модель концептуально яснее всех остальных. Клиентская бизнес-логика отделяется от клиентского ПО и физически функционирует в той же среде, что и серверная. Типичным примером приложений, построенных в "настоящей" n-уровневой модели является грамотно построенная Web-система. В самом деле: клиент работает только со слоем представлений. Никакие компоненты бизнес-логики системы не выполняются в браузере (кто бы им ещё это разрешил!), а вся фактическая работа выполняется на сервере.

На самом деле, эти модели, конечно, существенно сложнее, но сейчас не время замусоривать пространство определений. Всё будет. Позже…

Зачем переделывать?

Иногда меня спрашивают, а для чего вообще необходимо перестраивать уже работающую программу для выделения каких-то мифических слоёв? Надо сказать, что я очень люблю такие вопросы! Я вообще люблю вопросы, на которые у меня есть ответы. Здесь ответ прост: как разработчики-профессионалы, мы обязаны предоставить заказчикам наших систем

• масштабируемость
• доступность
• безопасность
• управляемость

Это "четыре кита" грамотной системы. У пользователя не должно возникать проблем с переносом предложенных нами систем с одиночного сервера в кластер, а администраторы не обязаны особенно беспокоиться, что будет происходить, если вместо оптоволокна в качестве канала будет использоваться 10Mb Ethernet. Само собой, мы обязаны единообразно обеспечить безопасность на всех уровнях системы - от пользовательского интерфейса до критических операций над БД. И даже лучшие из разработанных нами систем всё ещё нуждаются в управлении, ну, по-крайней мере, в обслуживании. Так что и это мы тоже должны предоставить. А теперь представьте себе программу на каком-нибудь FoxPro, сработанную одним из многотысячной армии умельцев, в которой автор смешал в кучу формы и запись в БД, индексы в которой могут пропадать "просто так", система блокировок пишется вручную, а нескольким пользователям приходится ждать своей очереди, чтобы поработать… Хорошо, если бы это был страшный сон, но это всё ещё реальность. При этом обеспечить выполнение тех четырёх требований, о которых говорилось выше, применением n-уровневой модели разработки проще простого ("разделяй и властвуй", но на новом уровне). И чем быстрее все мы перейдём на n-уровневую модель разработки, тем лучше и для нас, и для наших клиентов.

n-уровневая модель разработки
(щелчок мышью по изображению откроет увеличенную картинку в новом окне)

Надеюсь, что актуальность этой проблемы - разработки распределённых приложений - стала для читателя очевидной. Поэтому будем считать торжественную часть закрытой и перейдём к обзору требований к разработке и разработчику распределённых приложений для Windows.

Требования к разработке ПО в трёхуровневой архитектуре

Промышленная разработка программного обеспечения накладывает свои требования к организации самого процесса разработки. Как показывает опыт, правильный подбор персонала для разработки распределённых приложений - это много процентов успеха. Оптимальный количественный состав группы по разработке продукта - 4 человека (это подтверждается и материалами моей недавней беседы с руководителем одной известной software-компании). Среди них обязательно должны быть:

• Специалист по архитектуре, в которой разрабатывается система (DCOM, COM+, CORBA и т.п.)
• Специалист по языкам разработки, используемым в проекте: естественно, что в таких проектах каждый должен быть специалистом чрезвычайно высокой квалификации в области программирования, но помимо этого обязательно наличие человека, способного ответить на любой вопрос относительно среды или языка разработки.
• Эксперт в области использования СУБД проекта (MS SQL Server, Oracle и т.п.)
• Ответственный за внутреннюю документацию.

Кроме этих четырёх, жизненно необходима группа по контролю над качеством выдаваемого кода (как исходного, так и исполняемого).

Другим важным элементом хорошего проекта является правильно подобранные средства разработки. Это один из камней преткновения в любом обсуждении. На самом деле, глупо обсуждать, что лучше, а что хуже. Слишком много дополнительных, часто неявных "но" и "если" существуют в разработке, но коли речь идёт о разработке для Windows и под Windows, то лучшим выбором лично я считаю MS Visual Studio. То, что сейчас предлагает MS (VS 98 SP5) - наверно, лучший комплект средств разработки, которые когда-либо создавались. А в сочетании с комплектом MSDN любой программист становится монстром разработки:)

Заключение

В следующих статьях этого цикла будут рассмотрены способы разработки, основанные на методе ECC (Engine-Collection-Class), показаны различные примеры использования этого метода на языках С++ и VB.