Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри

Авторам мемуаров о создании в СССР первых ВЦКП [7], возможно, будет не только досадно, но и приятно. Досадно за опередившие время своего технологического воплощения концепции. Приятно за реализацию идеи – лучше поздно, чем никогда.

Впрочем, для истории это уже неважно. Нам интереснее попытаться усмотреть тенденции технологического маятника, резко качнувшегося в 1980–90-х годах в сторону децентрализации и теперь возвращающегося на позиции годов 1970-х в качественно новой ситуации обилия дешёвых терминалов с их избыточными мощностями и общедоступными высокоскоростными каналами связи.

Программировать распределённое приложение сложнее, чем централизованное. Не только технически, но и организационно. Но в качестве выигрыша получаем автономию сотрудников, рабочего места и отсутствие необходимости поддержки службы в состоянии 24Ч7.

Наиболее очевидное применение децентрализации – автономные программы аналитической обработки данных. Мощность терминала позволяет хранить и обрабатывать локальную копию части общей базы данных, используя собственные ресурсы и не заставляя центральный сервер накаляться от множества параллельных тяжёлых запросов к СУБД. Пример из практики мы рассмотрим в следующих главах.

Софтостроение – производственный процесс с высокой долей НИОКР [71]. Наукоемкий процесс, или, как его ещё называют, высокотехнологичный. На выходе – продукт: программа, программный пакет, система или комплекс.

По причине развития общедоступных каналов связи работать с программами можно с удалённого терминала, в роли которого выступает множество устройств: от персонального компьютера до мобильного телефона. Эксплуатацию же программ ведут поставщики услуг в «облаках» – современные ВЦКП. Это и есть «программа как услуга», SaaS [72].

Значит ли это, что софтостроительные фирмы теперь, как утверждают некоторые маркетологи, «производят услуги»? Разумеется, нет.

Во-первых, услуги не производят, их оказывают. Во-вторых, услуга от продукта, материального товара, принципиально отличается минимум по трём пунктам:

• услуги физически неосязаемы;

• услуги не поддаются хранению;

• оказание и потребление услуг, как правило, совпадают по времени и месту.

В чем же фокус? Фокус в том, что классическая цепочка «производитель – конечный потребитель» подразумевает, что потребитель сам приобретает нужную программу и право на использование, сам её устанавливает и эксплуатирует. Разумеется, между производителем и потребителем может быть много перепродавцов и посредников, а вокруг – консультантов, но ситуация от этого принципиально не меняется.

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

Это значит всего лишь, что софтостроители продолжают производить продукт. Но конечным пользователем для них является ВЦКП в «облаках», оказывающий на базе этого продукта услуги своим клиентам. Программа – это продукт, как и многие другие, например автомобиль, позволяющий на своей основе оказывать такие полезные услуги, как прокат, извоз или транспортировка.

Признаю, что название главы логически не совсем корректно, поскольку CORBA [73]– одна из технологий создания сервис-ориентированной архитектуры, СОА [74], оно отражает хронологию развития событий. Поскольку маркетинговый шум вокруг СОА стих, жужжащие словечки вроде « loose coupling » подзабылись, а в последние годы стало модным даже говорить о том, что «СОА выдохлась», можно вернуться к сюжету в спокойной обстановке на уровне собственно технологии. Мне слово «СОА» напоминает другое из 1980-х годов, СОИ – Стратегическая Оборонная Инициатива, оказавшаяся пропагандистским пузырём игры в «звёздные войны» администрации американского президента Рейгана. Просто ассоциации, ничего личного.

Предшественником современной СОА на базе веб-служб, с полным правом можно считать CORBA. Это сейчас задним числом обобщают подходы, представляя СОА как набор слабосвязанных сетевых служб, реализовать которые можно по-разному. А тогда, в середине 1990-х, вокруг CORBA стоял достаточно сильный шум продавцов волшебных палочек, но никаких упоминаний СОА ещё не было. Только начинал своё бурное развитие интерактивный веб динамического контента, приём заказов через интернет-магазин считался «крутой фишкой» для компании, а где-то в недрах Microsoft из XML-RPC [75]тихо прорастал SOAP [76].

CORBA имела очевидные достоинства, прежде всего это интероперабельность [77] и отраслевая стандартизация не только протоколов (шины), но и самих служб и общих механизмов – facilities . Например, служб имён, транзакций, безопасности, хранения объектов, конкурентного доступа, времени и т. п. Однажды реализованный программистами сервис мог использоваться многими системами без какой-либо дополнительной адаптации и ограничений с их стороны. Следует отметить, что фактически проигнорированная отраслью CORBA 1.0 не была интероперабельной и предназначалась только для языка C.

Почему же и CORBA 2, продержавшись несколько лет в основном потоке технологий, была оттеснена на обочину? Причин много, весьма подробный анализ описан в статье одного из разработчиков стандарта [14]. Мне же, как участнику разработки реальной системы на основе технологии, хотелось бы выделить следующие:

• Стандарт поддерживался многими корпорациями, поэтому развитие требовало длительного согласования интересов всех участников. Некоторые из них продвигали свои альтернативы, например Sun Java RMI и Jini, Microsoft DCOM.

• Несмотря на реальную поддержку интероперабельности, множества языков и сред программирования, основным средством разработки оставался C++. Но код на C++, манипулирующий инфраструктурой CORBA и службами, является излишне сложным по сравнению с той же Java или даже Delphi. Практиковавшие подтвердят, остальным будет достаточно взглянуть на примеры в Сети. А Java-программисты не спешили использовать CORBA из-за упомянутых альтернатив.

• Запоздалая (1999 год), объёмная и весьма сложная спецификация компонентной модели. Java-сообщество к тому времени обладало альтернативой в виде EJB [78]с открытыми и коммерческими реализациями.

Кто знает, откажись тогда корпорация Sun от роли единственно правильного хранителя своей технологии, сосредоточься она на интеграции с CORBA и реализации спецификаций, возможно, её история не закончилась бы через 10 лет поглощением со стороны Oracle. Но Sun тогда, на пике бума доткомов [79], предпочла строить свой собственный мир, планируя накрыть им всю отрасль. Насколько простой оказалась придуманная в корпорации реальность, можно судить по фрагменту из статьи 2002 года «Страдает ли Java от сложности?» [16].