Ключевые модели разработки n-уровневых приложений

О технологиях создания распределённых приложений, а также кто такие DNA, MTS и другие...

Чернила Word ещё не успели высохнуть на моей прошлой статье, а мои коллеги уже начали одолевать меня вопросами "А что же было дальше?" Как человек в глубине души (ключевое слово здесь - "в глубине") очень добрый и отзывчивый, не могу не рассказать продолжения сказки под названием "Как можно было бы разрабатывать распределённые приложения". С момента сдачи Скауту первой статьи произошли некоторые изменения в моей жизни, как разработчика. Наконец-то пришли первые диски с MSDN 2001 и первое, что я поставил на свою вторую машину, было… (ладно, "на двадцать вопросов времени нет") Microsoft Visual Studio .NET. Посему, прошу всё, что было сказано относительно MSVS 98, считать относящимся к VS .NET. Это на самом деле впечатляющее средство! Но об этом позднее, а сейчас - обещанные модели разработки n-уровневых (распределённых) приложений.

Замечание: начиная с этой статьи, я буду стараться по возможности отказываться от слова "n-уровневый" в пользу слова "распределённый".

Технологии создания распределённых приложений

Существует целый ряд технологий, позволяющих создавать распределённые приложения:

• Remote Automation, наша хорошая знакомая ещё по Visual Studio 97
• DCOM, предложенная (модель же, всё-таки!) в середине 97го года и расширяющая стандартную модель COM взаимодействием между объектами по сети
• DNA, значение и суть которой будет расшифрована позже
• CORBA, о которой я вообще ничего говорить не собираюсь
• Java, потрясая которой, Sun обещала заставить холодильники заказывать хозяину продукты
• .NET, наконец. Платформа, которую MS предлагает для обеспечения независимости от языков программирования

Как легко видеть, далеко не все элементы этого списка эквивалентны. Например, RA и DCOM - чисто утилитарные технологии, с использованием которых MS пыталась "заткнуть дыры" в различных направлениях разработки, в то время, как DNA и .NET - это целые новые мировоззрения, по-философски глубокие и концептуально чистые, предлагающие массу удобств как разработчикам, так и их пользователям. Впрочем, по-порядку…

От COM к MTS

Выпуск MTS был значительной вехой в истории развития Windows, как распределённой платформы. В соответствии с концепцией Windows NT, как сервера приложений, MTS был разработан именно для этой ОС. Из названия MTS ясно, для чего он предназначался - управлять и координировать распределённые транзакции. Но это было куда как более могучее средство, нежели чем просто монитор транзакций. MTS обеспечивал совершенно новую среду для выполнения бизнес-объектов в промежуточном слое ПО (business tier, по вышепринятому объявлению) и обеспечивал распределённые приложения масштаба предприятия критически важной инфраструктурой, которая отсутствовала ранее в классической COM. Главным же было именно повсеместное использование MTS в качестве среды, в которой выполнялись бизнес-объекты вне зависимости от того, работали они с транзакциями или нет. Словом, MTS мог и делал очень много. Настолько много, что пользователей стало раздражать несоответствие между функциональностью и названием. Но тут пришло время выхода Windows 2000, а вместе с ней на арену вышла и COM+ - операционное окружение бизнес-объектов.

С выпуском MTS некоторые из разработчиков стали на распутье: использовать MTS или нет? Некоторые (большинство) стали его использовать, поскольку особой переделки существующих COM-компонентов не требовалось, а ценность новой инфраструктуры была огромной. Другие не смогли разглядеть ("слона-то я…") того удобства, которое принес MTS (кстати, никто не знает, что сейчас с ними?:). Правда, нельзя не отметить, что поскольку никто в MS не задавался целью интегрировать MTS и COM, то в результате получилось два практически независимых окружения времени исполнения (я бы сказал run-time environments): никто никогда не адаптировал COM к MTS, а целью MTS никогда не было устранение известных недостатков COM, а скорее предоставление альтернативы. В итоге всякая система на базе MTS не является идеальной ни по быстродействию (хоть оно и весьма высоко), ни по надёжности (хоть и крайне трудно "убить" MTS на отдельно взятом сервере). А кто идеален?

Если вы дочитали до этого места, то возможно вас интересует вопрос, а почему это я говорю о MTS в прошедшем времени? Да потому что время его прошло - на смену MTS пришли службы компонентов Windows 2000, известные также и под своим вторым именем: COM+. Фактически, COM+ есть ни что иное, как эволюционизировавший MTS. Но Большая часть знаний, которыми обладал MTS-разработчик, пригодится и в COM+, но есть и некоторые изменения, который COM+ привнёс в распределённые вычисления. Их довольно много, но главное, что произошло - это то, что COM+ уже не самостоятельное расширение Windows из пакета Option Pack, а интегрированная часть Windows 2000. Они не существуют по отдельности. Из этого вытекает многое - и новая работа с контекстами, и изменения, касающиеся работы с регистрацией компонентов. Нового слишком много, а места в статье слишком мало, так предлагаю читателю самому обратиться к соответствующим разделам MSDN Online. Рекомендованные статьи можно найти в списке ссылок.

Windows DNA

DNA (на языке оригинала делящая сокращение с ДНК) это ни что иное, как концепция интеграции Web и клиент-серверных приложений с использованием COM. DNA-сервисы, предлагаемые разработчиками, используются приложениями посредством COM и включают в себя управление компонентами, динамический HTML, Web-браузер и сервер, создание и выполнение сценариев, транзакции, управление очередями, работу с БД и проч. в том же духе. Важным является то, что поскольку для целей коммуникаций в этой архитектуре используются открытые стандарты групп W3 и IETF, то для целей создания DNA-приложений годятся все средства разработки, лишь бы они поддерживали COM.

Конечно, описать Windows DNA в рамках одной статьи невозможно, но попробую дать хотя бы общее представление о том, что это такое, для чего нужно и чем может помочь.

Расшифровываемый, как Distributed interNet Applications Architecture, этот акроним скрывает за собой многое. Архитектура DNA предполагала чёткое разделение (едва ли не впервые на платформе Windows) трёх основных слоёв распределённой системы, о которых речь шла ранее. Microsoft предложила эту архитектуру одновременно с выпуском всех ключевых продуктов, необходимых для создания ПО в этой архитектуре: MTS (Microsoft Transaction Server в составе NT 4 SP4), Exchange Server 5.5, SQL Server 6.5 (пожалуй, первый сервер БД, от MS, который был положительно принят рынком), IIS, Terminal Server, IE 4. Взаимодействуя друг с другом, решения, созданные на этой основе, обладают всеми достоинствами распределённых систем: они надёжны, производительны и масштабируемы. Ключевое место в этой схеме отводилось MTS, в котором должны выполняться бизнес объекты: компоненты регистрируются в MTS, а он обеспечивает их безопасное выполнение с поддержкой транзакций. Для написания COM-объектов, которые должны взаимодействовать с MTS, не требовалось практически никаких усилий, кроме получения указателя лишь на один интерфейс IObjectContext (конечно, далеко не во всех приложениях всё так просто) и обращения к его методам. Классы можно (и нужно!) писать таким образом, как будто всегда будет выполняться только один экземпляр. Конечно, за этой видимой простотой прячется грандиозная работа MTS, но, по-крайней, мере внешне всё очень просто.

Весьма впечатляющим в MTS было то, как поддерживались подтверждения и откаты транзакций. В процессе работы какого-либо объекта в зависимости от реализуемой им логики, он мог инициировать множество вложенных транзакций во множестве других используемых им объектов. Но ничто не вечно и всегда приходило время решать, что делать с изменёнными данными. Для традиционных "плоских" транзактных схем задача подтверждения или отката каскада транзакций чрезвычайно сложна. Требуется немалый опыт и терпение, чтобы отладить такую систему. С применением MTS всё радикально упрощалось. Главное правило для MTS-разработки формулировалось так: "каждый сам за себя". Другими словами, каждый объект должен был на основании своих данных сказать серверу транзакций, закрепляет он свою транзакцию или отменяет, а уж MTS соберёт всё "в кучу" [1].

Ну и что?

Я знаю, что трудно читать две страницы прописных истин не задаться вопросом, что вынесен в заголовок раздела. Конечно, MTS - "это было круто", а DNA - это тоже "не просто так", но естественно, что не для простой констатации этих фактов была задумана эта статья. Отвечая на "Ну и что?" и "И чем это всё может мне помочь?", скажу просто: заказчики не платят нам за инфраструктуру. У них всё просто: работает - получи деньги, не работает - свободен. И никакие рассказы о том, как сложно было организовать взаимодействие объектов или правильно откатить транзакцию, которая выполняется в сети, не помогут. Как говорит один человек: "Но результат же - НО-О-О-О-ЛЬ!!":) Вот для того, чтобы избавить нас от малопроизводительной (хоть и очень интересной!) траты времени на создание инфраструктуры, MS и предоставляет разработчикам всё то, о чём говорилось выше.

ЕСС

Регулярно посещая, практически живя на MSDN Online, в августе прошлого, 2000 года я обнаружил весьма интересную статью. Это не был front-end, но это было то, чего тогда так не хватало: хорошая методика и хорошие примеры. Итак, встречайте: ECC. Это очень эффективное средство построения распределённых систем, ориентированных на интенсивную работу с данными.

Суть методики ECC (расшифровываемой, как Engine-Collection-Class) заключается в следующем:

• интерфейсы системы группируются по функционалу:
  • класс (Class)
  • коллекция классов (Collection)
  • класс, создающий и обеспечивающий манипуляцию коллекциями классов (Engine)
• ввиду использования в ECC весьма высокого уровня абстракции можно применять любую методологию для описания систем, построенных с применением ECC - объектно-ориентированную методологию или компонентно-ориентированную (как, например, COM)
• интуитивно ясная модель разработки существенно упрощает разработку бизнес-объектов и уменьшает количество времени, которое нужно для построения системы
• ЕСС позволяется создавать повторно используемые объекты, для чего изначально и разрабатывалась

Суть ECC заключается в рассмотрении бизнес-объекта в качестве триединой сущности.

Это означает следующее: предположим, что мы моделируем некий класс, являющийся интерфейсом к простейшему справочнику (lookup table), который состоит только из двух полей (обведён красным на диаграмме).

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

Необходимые комментарии по тексту: ясно, что свойства Id и Description описывают соответствующие поля в таблице antypes. Остальные свойства служат для сохранения состояния объекта:

В следующей статье цикла будет рассказано о том, как выглядит код классов Collection и Engine на VB и VC++

[1] - Листинг скрипта работы с транзакциями MTS - прим.авт.
[обратно к тексту]