Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

20.02.2017

Google
WWW CITForum.ru
С Новым годом!
2003 г

SOAP и REST, вместе или порознь?

Леонид Черняк
18.09.2003
Открытые системы, #09/2003

На протяжении последних двух лет в среде разработчиков стандартов для Web-сервисов развернулась активная дискуссия на тему: «SOAP против REST». С этими двумя аббревиатурами ассоциируются два почти диаметрально противоположных подхода к организации Web-сервисов. SOAP (Simple Object Access Protocol) — хорошо известный нижний уровень в стеке протоколов. REST (Representational State Transfer) — менее известное явление, называемое его авторами «архитектурным стилем». В творческом споре против основной массы сторонников SOAP выступает небольшая, никак формально не организованная, группа инакомыслящих, которые поддерживают REST. Скорее всего, победителя в этом противостоянии не будет; как обычно бывает, большинство учтет мнение меньшинства, и вместо противопоставляющего лозунга «SOAP против REST» появится конструктивный «SOAP + REST».

Утверждение, что будущее — за сетевыми архитектурами, превратилось в банальность, сейчас только и разговоров, что Grid да SOA (Service-Oriented Architecture). Но, как говорят англичане, «ободрать кошку можно по-разному», какими именно станут в будущем сетевые архитектуры, сказать сложно, однако наступила пора выбора. Есть взгляды, которых придерживается большинство; их разделяют и крупные компании. Но есть и мнения оппонирующих им «диссидентов».

Во всех нынешних начинаниях, связанных с сетями, так или иначе, присутствует World Wide Web. Первопроходец Всемирной паутины Тим Бернерс-Ли дал своему детищу гениальное по лаконичности определение: «Web — это просто пространство (буквально, «вселенная», universe — Л.Ч.) глобальной информации с сетевым доступом». Идеи, которые заложила возглавляемая им группа энтузиастов из CERN в фундамент архитектуры Web, были настолько продуктивными, что спустя несколько лет оказались востребованными в компьютерной индустрии.

На наших глазах почти в точности повторяется история заимствования корпоративными intranet-сетями технологий из Internet, которая имела место лет пять-семь назад. Однако есть и отличия, вполне очевидно, что архитектура WWW осмыслена адаптаторами в гораздо меньшей мере, чем в свое время архитектура Internet. В той трактовке Web, которая получила распространение и усиленно эксплуатируется (особенно, когда речь идет о Web-сервисах), все сводится к представлению Web исключительно в качестве коммуникационной среды, что явно противоречит приведенному определению. Web-cервисы, построенные на основе протокола SOAP, не используют возможности Web в полной мере — в том числе, и возможности механизма адресации информационных ресурсов, основанного на универсальных идентификаторах ресурсов (URI).

Не удивительно, что в академической среде и в близком к ней инженерном сообществе, глубже понимающем идеи WWW, возникло альтернативное направление, которое, по мнению его приверженцев, полноценно, по-настоящему использует это великолепное изобретение. Такие альтернативные сервисы называют сервисами на основе REST.

За фасадом победного шествия архитектур, ориентированных на сервисы, и Web-сервисов, вне сферы внимания коммерческой прессы идет невидимое миру противоборство приверженцев различных точек зрения на устройство Web-сервисов. С одной стороны выступает вся индустрия, возглавляемая такими могучими компаниями, как IBM, Microsoft, Sun Microsystems, которые продвигают идеи Web-сервисов на основе «святой троицы» протоколов SOAP/WSDL/UDDI, с другой — крошечная группа энтузиастов идеологии Web в чистом виде. И это не просто борьба технических идей, а скорее отчаянное сопротивление «пуристов», сопротивление, как им кажется, искажению и коммерциализации принципов Всемирной паутины. Острие их нападок направлено на группы Technical Architecture Group (TAG) и особенно Web Services Architecture Working Group (WSAWG), которые действуют в составе основного координирующего органа Web, консорциума W3C. По их мнению, наиболее полно выраженному Марком Бэйкером, в конце 2004 года коммерческие подходы к Web-сервисам ожидает серьезный кризис. В TAG, напротив, считают проповедуемые альтернативные сервисы на основе архитектурного стиля REST частным случаем использования HTTP и не видят за ними серьезного будущего. Наиболее выдержанные специалисты, например, Дэвид Орчард (David Orchard), директор по технологиям компании BEA Systems, являются выразителями более умеренных взглядов.

Консолидированная точка зрения большинства на Web-сервисы представлена в статье «SOA — шаг за горизонт», публикуемой в этом номере журнала. Но двумя лицами дело не ограничивается; может быть и третье, и четвертое. В этой же статье представлена точка зрения меньшинства; знакомство с ней будет полезно хотя бы потому, что позволит лучше понять, почему название «Web-сервисы» используется в основном не вполне корректно. Название неудачное: троица протоколов не имеет по сути своей никакого отношения к Web, кроме использования механизма адресации. Однако название уже прижилось, как говорится, «термин занят». В данной статье, чтобы различить два подхода, будем временно использовать термин «SOAP-сервисы» для обозначения сервисов, построенных на основе SOAP/WSDL/UDDI, и «REST-сервисы» для альтернативного подхода.

Рой Филдинг и архитектурный стиль REST

Собственное видение проблем программного обеспечения Сети Филдинг описал в докторской диссертации «Архитектурные стили и проектирование архитектур сетевого программного обеспечение» [1]. Работа представляет собой не только фундаментальное исследование на означенную тему, но одновременно и прекрасный учебник.

В настоящее время Филдинг работает в должности научного руководителя компании Day Software, но миру профессионалов он гораздо лучше известен своими прежними достижениями и общественной деятельностью. Стоит вспомнить участие в разработке инфраструктуры World Wide Web, где именно он был главным архитектором Hypertext Transfer Protocol (HTTP/1.1), а также соавтором стандартов для HTTP и URI. Кроме того, Филдинг был в числе инициаторов нескольких проектов известных программных систем с открытым кодом (один из них — проект Apache HTTP Server, который, как признано, является основой более 60% Internet-сайтов). В сферу научных интересов Филдинга входят также архитектура программного обеспечения для сетевых приложений, сетевые протоколы прикладного уровня, средства совместной разработки программного обеспечения. За свои научные успехи, в частности, за проект Apache, в 1999 году он был удостоен ACM Software System Award. В том же году Филдинг был включен в почетный список Top100 молодых исследователей, который составляется журналом MIT Technology Review.

Стиль REST методично раскрыт в диссертации Филдинга, первые четыре главы которой посвящены определению понятия «архитектурный стиль» вообще и принципам построения сетевого программного обеспечения. В пятой главе изложены начала REST. В более сжатом виде идеи стиля REST изложены в [2]; прочтение этой статьи можно считать обязательным для того, кто хочет понять, что такое WWW и REST. В данном случае вполне можно ограничиться самым грубым приближением и сказать, что REST задуман как основа масштабируемого прикладного протокола, обеспечивающего доступ к информационным ресурсам. Подчеркнем, именно к ресурсам. Противопоставление REST остальному миру сервисов можно, в какой-то мере, сравнить с противопоставлением процессорной архитектуры RISC архитектуре CISC. В обоих случаях используется ограниченный набор операций; в случае доступа к ресурсам в стиле REST их всего четыре: GET, PUT, POST и DELETE. Этих четырех операций оказывается достаточно для оптимальных манипуляций с сетевыми ресурсами; главное, что они позволяют, — отделить размещение ресурсов на сервере от восприятия этой информации клиентом и потоковую передачу информации. Антиподом REST является подход, основанный на вызове удаленных процедур (Remote Procedure Call — RPC).

Пути развития прикладных протоколов

Количественное и качественное развитие всевозможных Internet-приложений формирует потребность в новых прикладных протоколах. В их совершенствовании видится три возможных пути.

Традиционный подход к протоколам. Этот подход и соответствующая категория протоколов названы традиционными, потому что они появились раньше других и изначально были основаны на первичных протоколах Internet, а именно TCP и UDP. Недостаток этого подхода заключается в невозможности совместного использования ими инфраструктуры. Скажем, протокол RosettaNet существенно отличается от протокола ebXML а тот, в свою очередь, — от протокла Jabber. И хотя сейчас они сближаются поскольку стали использовать XML, реальная совместимость еще не достигнута. Опасность традиционного пути состоит в том, что при появлении новых требований всякий раз возникает потребность в создании новых протоколов.

Структурный, или рамочный подход. Структурный подход родился из понимания неизбежности постоянного обновления прикладных протоколов. Как следствие, возникла мысль о рамочной конструкции (framework). Пример такого протокола являют собой SOAP,WSDL, а также менее известные протоколы BEEP/BXXP (Block Extensible Exchange Protocol). Рамочная конструкция предполагает несколько общих характеристик: тип системы; язык описания сервисов; адресную модель; связь с транспортными протоколами нижних уровней (binding); решения по безопасности; разбиение сообщений на компоненты (framing).

По сравнению с традиционной, эта стратегия позволяет создавать общую инфраструктуру. К слабостям рамочного подхода можно отнести то, что по своей логике он продолжает технологии DCOM и CORBA. Не полностью решается проблема безопасности, маршрутизации и асинхронных двунаправленных коммуникаций. Кроме того, не оправдались первые надежды на XML как на средство, которое обеспечит совместимость приложений, как только будет выбрана основная группа стандартов, например, SOAP/WSDL/UDDI. Со временем стала очевидной необходимость в дополнительных протоколах. Начали появляться WS-Security, WS-Routing, WS-Inspect и т.д. Неопределенность всей картины в целом сильно сдерживает широкое распространение Web-сервисов и стимулирует многих занимать выжидательную позицию в надежде на W3C и другие организации, которые обеспечили бы взаимодействие.

REST и горизонтальный подход. Стратегия, опирающаяся на горизонтальный подход к протоколам, наиболее радикальна. Слово «горизонтальный» означает в данном случае сохранение существующего уровня, без выстраивания уровней поверх него. Предполагается отказаться от разработки новых протоколов, а использовать несколько хорошо проверенных, считая, что для работы с объектами вполне достаточно уметь выполнять четыре типа действий: создание (Creation), восстановление (Retrieval), изменение (Update) и уничтожение (Destruction). Из этих действий получается так называемый «шаблон проектирования» CRUD. Протокол Hypertext Transfer Protocol определяет методы GET/PUT/POST/DELETE, которые и реализуют шаблон CRUD.

Апологеты REST относят сервисы, построенные в этом стиле, ко второму поколению. Остальные Web-сервисы они объявляют сервисами первого поколения, подчеркивая при этом, что SOAP есть ни что иное, как DCOM или CORBA, но работающие через Internet. Действительно, первоначально технологии, подобные SOAP, называли Web-брокерами или объектными брокерами, построенными в Web. Как указывает Прескод [3], используемая в них модель RPC предназначена для замкнутого мира, где вы знаете каждого пользователя, где данные можно перераспределять между ними, где возможны прямые коммуникации. Для успешной работы в Web необходимо поддерживать сложный механизм, обеспечивающий взаимодействие на случай внесения системных изменений.

Требования со стороны защитников REST-сервисов выглядят иногда слишком экстремистскими. Так, Марк Бэйкер считает, что:

  • WSDL должен быть ограничен описанием взаимодействия в стиле REST;
  • следует прекратить работы по хореографии сервисов;
  • необходимо закрыть рабочую группу Web Services Architecture Working Group в W3C;
  • новые требования, предлагаемые вновь созданными рабочими группами, должны исходить не из представлений об интеграции с Web-архитектурой, а в полном соответствии с ней.

Разумеется, никто и никогда не выполнит подобные ультимативные условия, и потому подобная агрессивная тактика только мешает восприятию рациональных решений, существующих в REST-сервисах.

Ответ «традиционалистов»

По мнению специалистов из WSAWG, позиция оппонентов из лагеря REST не учитывает возможности более широкого взгляда на явления. Они считают, что использование Web-технологий является конкретной и частной реализацией Архитектуры, ориентированной на сервисы, и, следовательно, определенным ограничением на общую архитектуру SOA. Это ограничение заключается в том, что агенты SOA обращаются к объектам, которые в World Wide Web принято считать ресурсами, и которые идентифицируются при помощи URI. С другой стороны, Web-приложения в стиле REST строятся в предположении еще больших ограничений, которые заключаются в использовании унифицированной семантики и унифицированных средств манипулирования ресурсами. В WSAWG различают два типа сервисов.

  • Сервисы, логически совместимые с REST, обеспечивающие прямое манипулирование с объектами, т.е. с представлениями на XML ресурсов Web, которые действительно возможны с использованием минимального числа типов операций.
  • Сервисы, предназначенные для работы с распределенными объектами. Они в первую очередь должны обеспечивать возможность для более сложных операций над ресурсами, природа которых выходит за рамки традиционного представления о Web. Для выполнения такого рода сервисов ограниченного набора операций недостаточно. Это уже "посредничающие" сервисы, служащие средством для выполнения внешнего по отношению к ним кода.

Иначе говоря, «прямые» сервисы используют известные Web-серверы для манипуляций с данными, а «посредничающие» сервисы исполняются средствами внешних кодов, которые вызываются сообщениями и с помощью Web-серверов. Однако оба класса могут идентифицировать ресурсы общими средствами URI, использовать протоколы Web и форматы XML для обмена сообщениями.

REST + SOAP

Если обратиться к истории, то надо вспомнить, что на уровне языка ассемблера данные, и программы адресовались одинаково. Но уже тогда возникла проблема: как построить вызов к подпрограмме — подкомпилировать ее в тело кода, выполнив специальную макрокоманду, или же использовать вызов с передачей параметров. Сегодня стоит по сути дела та же самая проблема, но на другом уровне. В 70-е годы появилось структурное программирование, был предан анафеме оператор безусловного перехода goto, точнее обозначилось деление на данные и программы. В дальнейшем развитие оборудования хранения данных привело к созданию реляционных СУБД и языка SQL. Для работы с данными оказалось достаточным операторов insert, select, update и delete. В 90-е годы сети стали соединяться Internet-протоколами, подпрограммы с параметрами трансформировались в объекты с сообщениями, а хранимые процедуры стали нормой для операций, модифицирующих реляционные СУБД.

Конфликт «REST vs. SOAP» стоит рассматривать как диалектическое противоречие. Так или иначе оно будет разрешено, позволив более четко представить соотношение между кодами и данными на уровне архитектур SOA откроет путь к более продуктивному использованию Web-сервисов.

Литература

  1. Fielding, Architectural Styles and the Design of Network-based Software Architectures. Dissertation for the degree of doctor of philosophy in Information and Computer Science. www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
  2. Fielding, Richard Taylor, Principled Design of Modern Web Architecture. Proc. of the 2000 International Conference on Software Engineering (ICSE 2000). Limerick, Ireland, pp. 407-416, June 2000.
  3. Paul Prescod, Second generation Web Services. O'Reilly&Associates, XML.com, February 2002.
  4. Ruby, REST + SOAP. www.intertwingly.net/stories/2002/07/20/restSoap.html

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...