Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Новейшая история транзакционных технологий

Ник Голл

Мне выпала честь сообщить вам об окончании войны между облегченной Transaction Processing Lite — TP-lite) и полной (TP-heavy) версиями технологий обработки транзакций. Технология TP-lite проиграла и уходит в небытие. Воздавая должное столь важному событию, считаю своим долгом подробно осветить эту безжалостную борьбу и описать доблестного победителя — сервер транзакций.

В те далекие времена, еще до клиент-серверной реформации, в мире централизованных вычислений "правили" мониторы транзакций. Они обеспечивали работу банков, авиакомпаний и страховых агентств — словом, были повсюду. Мониторы транзакций как нельзя лучше вписывались в трехуровневую архитектуру TP-heavy, т. е. уровень представления, бизнес-логика и данные были должным образом разделены. (Ну хорошо, по крайней мере были разделены уровень представления и бизнес-логика — мы не могли заглянуть далее виртуального уровня доступа к данным VSAM.) Если же вспомнить столь модный сегодня тонкий клиент, то что может быть "тоньше" терминала 3270 с его зеленым монитором?! Итак, жизнь была просто прекрасна... для IBM.

Но вот разразилась клиент-серверная "культурная революция". Оплоты централизованных вычислений были разрушены, и управление перешло к настольным машинам. Поставщики реляционных СУБД (РСУБД) провозгласили наивысшей ценностью двухуровневую архитектуру. К тому времени недорогие настольные ПК уже имели вычислительную мощность, сравнимую с мощностью мэйнфреймов первого поколения и, кроме того, предлагали интуитивно понятный графический пользовательский интерфейс. Теперь ничто не мешало соединить в них уровень представления и бизнес-логику. В результате не только подешевела единица производительности MIPS (Million Instructions Per Second), но и стала возможной простейшая форма параллельных вычислений — в виде одновременного запуска приложений на тысячах настольных компьютеров.

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

Единственная проблема заключалась в том, что настоящей масштабируемости все же не получилось. Несметное число настольных приложений "бомбардировали" сервер СУБД своими пространными динамическими SQL-запросами, которые не только до предела нагружали сервер, но также "забивали" локальные сети, не говоря уже о распределенных сетях и коммутируемых линиях. Тогда поставщики реляционных СУБД выступили с идеей TP-lite: вернуть часть бизнес-логики с настольных компьютеров, но не в мониторы транзакций, а на сервер СУБД в виде хранимых процедур.

Война TP-технологий

Так началась война TP-lite против TP-heavy. Поставщики РСУБД c удовольствием указывали на дороговизну и сложность TP-heavy. В ответ на это появились на рынке более совершенные мониторы транзакций на основе Unix: TUXEDO фирмы BEA Systems, ACMSxp фирмы Digital, Encina фирмы IBM, Top End фирмы NCR и UniKix фирмы UniKix Technologies. Но продукты TP-heavy, выполненные даже для ОС Unix, не были популярны, за исключением тех, что использовались в самых больших и критически важных приложениях.

Они не были популярны также и потому, что отсутствовал способ быстрого переноса программ с TP-lite на TP-heavy. Приходилось "выбрасывать в корзину" огромные массивы наработанного кода на языке Visual Basic или PowerBuilder и начинать все сначала. Вы снова должны были отделять уровень представления от бизнес-логики и отказываться от однопользовательской и однопоточной модели программирования. И наконец, страх и неуверенность перед использованием мониторов транзакций росли "благодаря" стараниям поставщиков РСУБД, усиленно распространявших мнение, что мониторы транзакций нужны тогда и только тогда, когда требуется двухфазная фиксация (two-phase commit) в гетерогенных базах данных, т. е. способность к синхронному обновлению в двух или более базах данных различных производителей. "Много ли приложений нуждаются в этом?" — спрашивали они.

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

Ренессанс сервера транзакций

Контрреволюционный удар нанесла сеть Интернет. Новым тонким клиентом стал Web-браузер. Реакционные двухуровневые приложения TP-lite с их непоколебимыми притязаниями на размещение в толстом клиенте и непомерным аппетитом к ресурсам сети и сервера были публично осуждены и сосланы "в лагеря на перевоспитание". В образовавшийся вакуум власти ворвались Web-серверы, программные интерфейсы CGI и сценарии Perl. Хотя некоторые и пытались представить эти академические поделки как трехуровневые системы, вскоре стало ясно, что архитектура Web первого поколения немасштабируема. Наступило время реабилитации и возрождения мониторов транзакций.

Догадайтесь, кто оказался первым на этом пути? Правильно: великий "заимствователь" чужих идей — Microsoft. Не так давно, всего несколько лет назад, для разработки монитора транзакций нового поколения фирма Microsoft наняла несколько выдающихся умов в области обработки транзакций, в том числе Джима Грея, написавшего целую книгу на эту тему. Результатом данных усилий стало ПО Microsoft Transaction Server (MTS). В сервере MTS, выпущенном в январе текущего года, учтены наиболее распространенные претензии к мониторам транзакций.

Он недорог — по всей видимости, он будет встроен в анонсированную недавно версию Enterprise Edition операционной системы Windows NT Server. Пользователи смогут легко перейти на него, перенеся код на Visual Basic с клиента на сервер. После отделения бизнес-логики от уровня представления, что по общему признанию является задачей нетривиальной, бизнес-логику необходимо "упаковать" в объекты ActiveX. MTS активно использует многопоточность и прекрасно справляется с множественными запросами тонких клиентов к серверу БД.

MTS строится на основе современной распределенной компонентной модели — Distributed Component Object Model (DCOM). Несмотря на то что это фирменная технология, принадлежащая Microsoft, DCOM имеет широкую поддержку со стороны многих поставщиков ПО. В сочетании с MTS технология DCOM позволяет разработчикам разделить их монолитные приложения на повторно используемые компоненты для обработки транзакций. Даже фирма SAP основала свой компонентный стандарт для системы R/3 на модели DCOM, и ходят слухи, что следующее поколение R/3 может быть создано уже на основе MTS.

Конечно, как и большинство "технологий версии 1.0" фирмы Microsoft, эта тоже нуждается в совершенствовании. Так, управление потоками слишком примитивно, отсутствует баланс нагрузки между серверами, полная двухфазная фиксация поддерживается только сервером SQL Server, а распределенные службы справочника, такие, как Active Directory, необходимые для развертывания служб MTS в крупных масштабах, не появятся вплоть до выпуска Windows NT 5.0.

MTS против OTS

Корпорация Microsoft со своим сервером транзакций нового поколения обогнала всех, однако конкуренты отстают от нее не так уж сильно. Многие из основных поставщиков РСУБД "выбросили белые флаги" перед наступающими серверами транзакций и анонсировали собственные продукты TP-heavy.

Прошлой осенью компания Oracle представила свою технологию Network Computing Architecture (NCA), реализующую спецификацию Object Transaction Server (OTS) в рамках архитектуры CORBA (Common Object Request Broker Architecture). В начале этого года Sybase также анонсировала сервер Jaguar Component Transaction Server (CTS), который будет работать, подобно MTS, под управлением ОС Windows NT, а для работы под управлением ОС Unix использовать Java Transaction Server (JTS) — Java-версию сервера OTS фирмы JavaSoft. Недавно и IBM выпустила продукт Component Broker Connector, тоже реализующий спецификацию OTS технологии CORBA. Того и гляди — Informix забудет про свой модульный подход DataBlade и примется за трехуровневый продукт TP-heavy.

Помимо обращенных недавно в новую веру производителей РСУБД, свои компонентно-ориентированные серверы транзакций начали разрабатывать и традиционные поставщики мониторов транзакций. Фирма BEA Systems объединяет свой монитор транзакций TUXEDO с технологией Object Broker, приобретенной у фирмы Digital. Ожидается, что фирма NCR добавит собственную реализацию OTS к своему продукту Top End.

Даже более мелкие производители занялись разработкой серверов транзакций. Так, фирма Kiva Software предлагает Web-ориентированный сервер транзакций, представляющий собой рабочий механизм для таких прикладных служб в Интернет, как Travelocity или Internet Shopping Network. Фирма Visigenic планирует выпустить OTS как часть своей технологии ORB. Кроме того, фирма Iona предлагает OTS, основанный на механизме Encina фирмы IBM.

Куда мы идем?

Ясно, что накал борьбы сместился от противостояния между технологиями TP-lite в виде хранимых процедур РСУБД и TP-heavy в виде мониторов транзакций к конкуренции между серверами MTS на базе DCOM и OTS на базе CORBA. Сервер MTS идет чуть впереди по цене, легкости овладения и простоте конфигурирования. OTS обгоняет его по масштабируемости и кроссплатформенной поддержке с учетом того, что OTS поддерживают традиционные поставщики мониторов транзакций. К 2000 году, скорее всего, сложится следующая обстановка: MTS будет доминировать на рынке средних и малых систем, а OTS — на рынке крупных корпоративных.

Надо отметить, что и в MTS и в OTS, помимо недостатка инструментальных средств разработки, что, в общем-то, характерно для всех новых технологий, отмечается отсутствие еще одного критически важного компонента — интегрированных средств передачи сообщений с качеством, пригодным для применения в бизнес-приложениях (Business Quality Messaging — BQM). В своих будущих статьях я собираюсь более подробно рассказать о технологиях BQM, но сейчас хочу лишь отметить, что серверы транзакций, чтобы поддерживать обработку транзакций между предприятиями в рамках экстрасети, должны развиваться от парадигмы синхронности к концепции асинхронного обмена сообщениями. Microsoft объявила о своих планах интеграции сервера MTS, уже почти готового к выпуску, со своим связующим ПО организации очередей сообщений под кодовым названием Falcon, а рабочая группа Object Management Group рассматривает предложения по интеграции ПО для организации очередей, подобного MQSeries фирмы IBM, в технологию CORBA и сервис OTS


Сервисный центр apple ремонт iphone айфона.




  
12 '1997
СОДЕРЖАНИЕ

колонка редактора

• Старая песня о главном

локальные сети

• Средства кластеризации серверов Windows NT

• Главный недостаток Windows NT в России, или Почему я за архитектуру клиент—сервер

• Серверы NetWare в зеркальном отражении

• ЭМС и Европейская Директива

• Оценка эффективности работы персонала

• Novell Education: кузница сетевых инженеров

корпоративные сети

• Службы LANE — мост в XXI век?

• Новейшая история транзакционных технологий

• Внезапные потери связи

• Новейшие Интернет-технологии от Novell

услуги сетей связи

• Телефонные станции для быстро растущих и крупных предприятий

• CDMA — россиянам

• О пригодности телефонных каналов для передачи данных

• Тарификационные системы для учрежденческих АТС

• Маршрутизаторы ISDN со встроенными концентраторами

интернет и интрасети

• Распределение нагрузки Web-сервера

• Естественная эволюция индустрии Интернет

• Игры в Интернет

защита данных

• Управление ИБП

новые продукты

• Network Exchange 2550 фирмы Netrix

только на сервере

• Технология Dynamic HTML: "раздвоение личности"

• Тестируем АТМ-адаптеры



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх