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

В чем состояли просчёты советской программы ВЦКП? Их два. Один крупный: проглядели стремительную миниатюризацию и, как следствие, появившееся обилие терминалов. Хотя отдельные центры, как, например, петербургский «ВЦКП Жилищного Хозяйства», основанный в 1980 году, действуют до сих пор, мигрировав в 1990-х от мейнфреймов к сетям ПК. Второй: просчитались по мелочам, не спрогнозировав развал страны с последующим переходом к состоянию технологической зависимости.

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

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

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

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

SaaS и манипуляции терминами

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

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

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

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

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

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

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

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

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

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

От CORBA к SOA

Признаю, что название главы логически не совсем корректно, поскольку 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].

Новоиспечённый инженер после пяти лет обучения, имеющий базовые знания Java, XML и UML, после своего прихода на предприятие и перед началом работы был привлечён в понедельник к чтению публичного отчёта по J2EE v1.4 на 228 страницах.

На шести первых страницах этого отчёта значились ссылки на EJB, JSP, JMS, JMX, JCA, JAAS, JAXP, JDBC, JNDI. Эта новая версия J2EE и веб-служб предполагала знание концепций SOAP, SAAJ, JAX-RPC и JAXR. Каждый из этих акронимов имеет соответствующую специ фикацию.

Спецификация EJB 2.1 – это документ PDF на 640 страницах, который будет прочтён во вторник. Среда будет посвящена чтению документации по сервлетам Servlet 2.4 на 307 страницах. В четверг он штурмует документ по JSP 2.0 на 374 страницах. И так далее. .

После месяца интенсивных чтений наш инженер наконец готов начать продуктивную работу. .

Я добавил бы, что указанные в статье оценки как временных рамок, так и продуктивности работы излишне оптимистичны. Но вернёмся к CORBA.

Из небольшого списка известных в тот период открытых реализаций (Orba-cus, MICO, Robin) нами в продукте использовался omniORB. В комплекте к третьей версии выпуска 2000 года шла единственная реализованная служба именования (COS naming services) и библиотека синхронизации потоков – минимум, чтобы просто запустить разработку «с нуля». Впрочем, небольшой команде стартапа этого вполне хватило.

В начале 2000-х в ИТ-отрасли разразился кризис лопнувшего пузыря интернет-компаний, продвигать сложные и дорогие инфраструктуры, а коммерческие реализации CORBA стоили порядка тысячи долларов за рабочее место, стало очень трудно. Постепенно из кустов начали выкатывать на сцену рояль веб-сервисов, который из-за проблем с CORBA должен был стать новой платформой интеграции служб и приложений в гетерогенной среде. Концепции быстро придумали многообещающее название СОА. Надо сказать, что рояль не стоял без дела и в кустах: разработка веб-служб и развитие XML велись в конце 1990-х и активно продолжились в 2000-х годах. Поскольку это была технология, хотя и весьма базового уровня, но относительно простая, дешёвая и открытая не только на уровне спецификаций, но и в виде множества реализаций.