На ошибках CORBA мы можем многому научиться.
Краткая история
В начале 1990-х гг. ночным кошмаром были проблемы обеспечения возможности общения программ, выполняемых на разных машинах, особенно, если использовались разные аппаратные средства, операционные системы и языки программирования: либо программисты использовали сокеты и сами реализовывали весь стек протоколов, либо их программы вовсе не взаимодействовали. (Другие ранние средства промежуточного программного обеспечения, такие как Sun ONC, Apollo NCS и DCE, были ограничены средой C и Unix и не подходили для использования в неоднородных средах.)
После фальстарта с CORBA 1.0, которая не была интероперабельной и обеспечивала отображение только для языка C, консорциум OMG (Object Management Group) в 1997 г. опубликовал спецификацию CORBA 2.0. В ней определялись стандартный протокол и отображение для языка C++, а в 1998 г. было определено отображение для Java. В результате разработчики получили инструментальное средство, позволяющее им относительно легко создавать неоднородные распределенные приложения. CORBA быстро завоевала популярность, и с использованием этой технологии был создан ряд критически важных приложений. Будущее CORBA выглядело вполне благоприятным.
На этапе развития CORBA в середине и конце 1990-х наибольшие изменения, влиявшие на компьютерный ландшафт, были связаны с появлением Java и Web. В CORBA обеспечивалось отображение для языка Java, но не делалось ничего для взаимодействия с быстро разрастающейся Всемирной Путиной. Не дожидаясь решения от CORBA, компании обратились к другим технологиям и начали создавать инфраструктуру электронной коммерции на основе Web-браузеров, HTTP, Java и EJB (Enterprise JavaBeans).
Кроме того, разработчики, получившие опыт использования CORBA, обнаружили, что написание любого нетривиального CORBA-приложения является поразительно трудной задачей. Многие API были сложными, несогласованными и просто непонятными, что вынуждало разработчиков вникать в многочисленные детали. В противоположность этому, простота компонентных моделей, таких как EJB, существенно упрощала программирование (хотя и делала его менее гибким), и поэтому все громче и громче звучали призывы к построению компонентной модели CORBA. Однако для разработки компонентной модели потребовалось много времени. Работа над CBOF (Common Business Object Facility) началась в 1996 г., но была приостановлена из-за политических распрей, и, в конце концов, от этого подхода отказались в пользу CCM (CORBA Component Model). Окончательная спецификация CCM была опубликована в 1999 г., но оказалось, что это событие имеет, большей частью, сомнительную важность:
- Спецификация была объемной и сложной, и большая часть специфицированных средств так никогда и не была реализована даже на уровне экспериментов. При чтении документа становилось ясно, что CCM является технически незрелой; ряд разделов спецификации было, по существу, невозможно реализовать, а те, которые реализовать удавалось, не обеспечивали переносимости.
- Ни одна из компаний, поставлявших программное обеспечение CORBA, не взялась на реализацию CCM, что делало эту модель мертворожденной.
- Даже если бы реализации появились к моменту публикации окончательной спецификации CMM, было бы слишком поздно. Поезд уже ушел: технология EJB укрепилась в индустрии до такой степени, что у любой другой компонентной технологии не оставалось никаких шансов на успех.
Неудача CCM не слишком способствовала росту доверия потребителей CORBA, которых по-прежнему ставила в тупик сложность этой технологии.
В тоже время, индустрия нуждалась в промежуточном программном обеспечении все сильнее и сильнее. После некоторого опыта разработки и использования систем электронной коммерции, основанных на HTTP, HTML и CGI, стало ясно, что применение такого способа построения распределенных систем чревато серьезными ограничениями. При отсутствии должной системы типов функциональность приложений сводилась к синтаксическому разбору HTML для извлечения семантики, сложность которой редко превышала сложность действия по очистке экрана. Результирующие системы оказывались очень неустойчивыми. С другой стороны, в EJB имелась настоящая система типов, но эта технология ограничивалась средой Java и во многих ситуациях была непригодна. В бочке меда CORBA также имелось несколько ложек дегтя:
- Коммерческие реализации CORBA обычно стоили несколько тысяч долларов за рабочее место, к чему во многих случаях добавлялась плата за каждую установленную копию приложения. Это ограничивало распространение платформы – для многих потенциальных потребителей CORBA просто была слишком дорогой.
- Для использования платформы требовался слишком высокий уровень знаний, было сложно и трудно правильно ее использовать; все это приводило к потребности в долгом времени разработки, и было чревато большим количеством дефектов. В ранних реализациях платформы также часто присутствовали ошибки, а их качественная документация не предоставлялась. Компаниям было трудно находить CORBA-программистов требуемой классификации.
Microsoft никогда не использовала CORBA, предпочитая продвигать свою собственную технологию DCOM (Distributed Component Object Model). В результате большая часть рынка либо занимала выжидательную позицию, либо использовала DCOM, но и DCOM не могла выиграть сражение на поле промежуточного программного обеспечения, поскольку эту технологию можно было применять только в среде Windows. (У переноса DCOM в среду Unix, выполненного Software AG, никогда не было сторонников.) В конце концов, после нескольких попыток добиться масштабируемости DCOM Microsoft прекратила работу над этой платформой. К этому времени рынок промежуточного программного обеспечения находился в очень фрагментированном состоянии при наличии нескольких конкурирующих технологий, ни одна из которых не могла набрать достаточной популярности, чтобы можно было унифицировать разработку распределенных систем.
Еще одним важным фактором, приведшим к упадку CORBA, является XML. В конце 1990-х XML стал новой серебряной пулей компьютерной индустрии: почти по определению, если что-то основывалось на XML, то это было здорово. После отказа от DCOM компания Microsoft не собиралась оставлять мировой рынок электронной коммерции своим конкурентам, и, вместо того чтобы продолжать сражение без шансов на победу, она использовала XML для создания совершенно нового поля боя. В конце 1999 г. компьютерная индустрия увидела публикацию спецификации SOAP. В протоколе SOAP, исходно разработанном компаниями Microsoft и DevelopMentor и переданном затем для стандартизации в консорциум W3C, язык XML использовался для кодирования данных в удаленных вызовах процедур.
У SOAP имелись серьезные технические недостатки, но это был ловкий ход в маркетинговой стратегии. Он привел к дальнейшей фрагментации рынка, поскольку многочисленные поставщики, стремящиеся к своему куску пирога, переключали свои усилия с рынка CORBA на растущий рынок Web-сервисов. У потребителей добавились сомнения в жизнеспособности CORBA, и во многих случаях они заблокировали свои инвестиции в эту технологию.
Еще один удар нанес технологии CORBA кризис Internet-индустрии в начале 2002 года (Internet bubble burst). Финансовый спад индустрии привел к уходу с рынка многих софтверных компаний и вынудил выжившие компания переориентировать свои цели. В результате существенно сократилось число коммерческих CORBA-продуктов. Еще до спада несколько поставщиков прекратило развивать свои CORBA-продукты или стало уделять им меньшее внимание, а после кризиса за ними последовали другие компании. То, что во второй половине 1990-х гг. было преуспевающим рынком с большим числом конкурирующих продуктов, неожиданно превратилось в периферийный рынок со значительно меньшим числом поставщиков, потребителей и инвестиций. К этому времени появились реализации CORBA категории open source, которые частично компенсировали уход коммерческих поставщиков, но этого было недостаточно для возврата утраченной популярности и восстановления доверия рынка: CORBA больше не являлась любимцем индустрии.
Сегодня CORBA, главным образом, используется для связывания компонентов, выполняемых внутри корпоративных сетей, в которых коммуникации защищаются брандмауэрами от внешнего мира. Технология CORBA используется также при разработке систем реального времени и встроенных систем, секторе, в котором CORBA действительно развивается. Однако в целом CORBA находится в упадке, и теперь ее нельзя назвать никак иначе, кроме как нишевой технологией.
Притом, что всего лишь несколько лет тому назад CORBA считалась передним краем промежуточного программного обеспечения, сулившим революционизировать электронную коммерцию, странно видеть, насколько быстро эта технология ушла на обочину, и полезно проанализировать некоторые более глубокие причины ее упадка.
Технические проблемы
Очевидно, что упадку CORBA способствовал ряд внешних факторов, таких как кризис индустрии Internet и конкуренция со стороны других технологий, в частности, DCOM, EJB и Web-сервисы. Можно также утверждать, что CORBA стала жертвой моды в компьютерной индустрии. В этой индустрии техническое превосходство некоторой технологии часто мало связано с ее успешностью – более важными факторами могут популярность и маркетинг.
Однако эти аргументы не могут полностью объяснить потерю популярности технологии CORBA. В конце концов, если бы эта технология была настолько привлекательной, какой она представлялась вначале, сомнительно, чтобы потребители предпочли бы ей альтернативные технологии.
Техническое превосходство не является достаточным предварительным условием успешности, но в долговременной перспективе оно представляет собой необходимое предварительное условие. Вне зависимости от того, какие силы в индустрии используются для раскрутки технологии, если в этой технологии имеются серьезные технические недостатки, от нее рано или поздно откажутся. Именно здесь мы можем обнаружить основные причины провала CORBA.
Сложность
Наиболее очевидной технической проблемой является сложность CORBA – в частности, сложность ее API. Многие API CORBA являются гораздо более пространными, чем это действительно необходимо. Например, для объектного адаптера CORBA требуется более 200 строк определений интерфейсов, хотя те же функциональные возможности можно обеспечить с помощью примерно 30 строк – оставшиеся 170 строк не несут никакой функциональной нагрузки, а лишь существенно усложняют взаимодействие программ с подсистемой поддержки времени выполнения CORBA.
Еще одной проблемной областью является отображение для языка C++. Это отображение трудно использовать, и в нем имеется много подводных камней, которые приводят к ошибкам, относящимся, в частности, к надежности потоков управления, надежности исключительных ситуаций и управлению памятью. В спецификации CORBA можно найти ряд других примеров слишком сложных и плохо спроектированных API. Например, в службах именования, коммерции и оповещения обеспечиваются API, способствующие ошибкам и затрудняющие использование. Аналогично, конфигурирование CCM является настолько сложным, что им невозможно эффективно пользоваться без привлечения дополнительных инструментальных средств.
Плохо разработанные интерфейсы и языковые отображения – это наиболее заметная часть любой технологии, поскольку именно они, прежде всего, используются при разработке программного обеспечения. Именно здесь соприкасаются разработчики и платформа, и удобство использования и надежность интерфейсов и языковых отображений оказывают решающее влияние на время разработки и число дефектов. Очевидно, что любая технология, которой свойственна чрезмерная сложность, не может слишком расположить к себе разработчиков и еще меньше может расположить к себе менеджеров.
Сложность возникает также и из-за неудачных архитектурных решений. Например, IOR (interoperable object reference – интероперабельные объектные ссылки) в CORBA – это прозрачные (opaque) сущности, содержимое которых считается скрытым от разработчиков. Это решение неудачно по трем причинам:
- Прозрачные ссылки в значительной степени навязывают использование службы именования, поскольку клиенты не могут создавать объектные ссылки без помощи внешней службы. Это не только усложняет разработку и внедрение систем, но также приводит к появлению в системе избыточного состояния (с сопутствующим риском повреждения этого состояния) и порождает в системе дополнительную критическую точку.
- Прозрачные ссылки значительно усложняют некоторые API. Например, API перехватчика (interceptor) в CORBA был бы гораздо проще, если бы структура объектных ссылок не была скрыта.
- При использовании прозрачных ссылок для установления идентичности объектов требуются удаленные вызовы. Для некоторых приложений накладные расходы этих вызовов оказываются чрезмерно высокими.
Еще одним источником сложности является система типов. Например, в языке определения интерфейсов CORBA обеспечивается большой набор типов, среди которых присутствуют типы целых чисел без знака, чисел с фиксированной точкой и плавающей точкой с повышенной точностью, типы ограниченных и неограниченных последовательностей и массивов, а также тип «Any», который позволяет сохранять значения произвольного типа.
Поддержка этих типов усложняет многие API (в частности, интерфейсы для перехвата и динамического вызова) и приводит к появлению тонких проблем переносимости. Например, в Java не поддерживаются беззнаковые типы, и поэтому использование в интерфейсе целого числа без знака может привести к переполнению, если Java-клиент взаимодействует с C++-сервером. Аналогично, на платформе, в которой отсутствует поддержка чисел с фиксированной точкой или плавающей точкой с двойной точностью, в реализациях требуется эмуляция этих типов. Трудно реализовать эмуляторы таким образом, чтобы они вели себя одинаково на всех платформах, и для них требуются дополнительные API. Это еще больше повышает сложность и является источником трудно диагностируемых проблем интероперабельности.
Наконец, некоторые из произведенных в OMG ранних спецификаций объектных служб, таких как службы жизненного цикла (life cycle), запросов (query), управления параллелизмом (concurrency control), связей (relationship) и коллекций (collection) были не только сложными, но и не выполняли вообще никаких полезных функций. Они только добавляли шум в уже сложный набор спецификаций, путая потребителей и укрепляя репутацию CORBA как трудно используемой технологии.
Недостаточные средства
В CORBA обеспечиваются достаточно развитые функциональные возможности, но в ней отсутствует поддержка двух базовых средств:
Безопасность. Нешифрованный трафик в CORBA позволяет производить атаки типа перехвата информации (eavesdropping) и «человек посередине» (man-in-the-middle), и для обеспечения такого трафика требуется наличие открытого порта в корпоративном брандмауэре для каждой службы. Это противоречит обычным корпоративным политикам безопасности. (Между прочим, этот недостаток CORBA был основной предпосылкой возникновения SOAP. Отсутствие потребности в открытии порта в корпоративном брандмауэре и возможность передачи всех данных через порт 80 расценивались как серьезные преимущества, несмотря на наивность этой идеи.) В OMG было предпринято несколько попыток специфицировать правила безопасности и обхода брандмауэра для CORBA, но от этих идей отказались по причинам наличия технических недостатков и отсутствия заинтересованности у поставщиков брандмауэров.
Поддержка версий. Для введенного в действие коммерческого программного обеспечения требуется middleware, которое допускает поэтапную модернизацию этого программного обеспечения с обеспечением обратной совместимости. В CORBA не предоставляется какой-либо механизм поддержки версий (кроме механизма поддержки версий по порождению (versioning by derivation) *, который является чрезвычайно несовершенным). Появление новой версии CORBA-приложения, вообще говоря, нарушает существующий контракт взаимодействия клиента и сервера. Это вынуждает заменять все части внедренного приложения одновременно, что обычно не является допустимым. (Этот недостаток CORBA является еще одной серьезной предпосылкой появления SOAP. Считалось, что слабосвязанная природа языка XML позволяет применить его для решения этой проблемы, хотя эта идея была не менее наивной, чем идея направления всех коммуникаций через порт 80.)
Для коммерческой инфраструктуры электронной коммерции отсутствие поддержки безопасности и версий является просто непреодолимым препятствием – многие потенциальные потребители из области электронной коммерции отказались от CORBA только из-за этого.
Другие технические проблемы
Технологии CORBA свойственен ряд других технических проблем, включая следующее:
- Недостатки разработки протокола интероперабельности CORBA делают почти невозможным построение высокопроизводительной службы распространения событий (event distribution service).
- В применяемом в CORBA способе кодирования аргументов и результатов вызовов имеется значительная избыточность, но в протоколе не поддерживается сжатие. Это приводит к низкой производительности при работе в территориально распределенных сетях.
- В спецификации почти полностью игнорируется многопотоковость (threading), и поэтому многопотоковые приложения являются, по существу, не переносимыми (хотя многопотоковость очень важна для коммерческих приложений).
- В CORBA не поддерживается асинхронная диспетчеризация на стороне сервера.
- Отсутствует языковое отображение для C# и Visual Basic, и полностью игнорируется .NET.
Этот список проблем приведен только для примера, и его можно существенно расширить. Такие проблемы влияют только на меньшинство потребителей, но из-за них в прессе появляются дополнительные отрицательные отзывы, и ограничивается рынок.
Процедурные проблемы
В основе упадка CORBA лежат технические проблемы. Возникает вопрос: как же так может быть, чтобы технология, созданная крупнейшим в мире софтверным консорциумом, испытывала подобные трудности? Но оказывается, что технические проблемы – это симптом, а не причина болезни.
OMG – это организация, публикующая спецификации на основе консенсуса. По существу, члены OMG голосованием принимают решение о выпуске RFP (Request For Proposals, запрос предложений) по поводу некоторой спецификации, компании-члены OMG в ответ представляют проекты спецификации, и члены OMG голосуют за то, какой из проектов следует принять в качестве стандарта. Теоретически этот демократический процесс является честным и справедливым, но на практике он не работает:
Отсутствуют квалификационные требования для участия в процессе стандартизации. Некоторые участники являются экспертами в соответствующей области, но, грубо говоря, большое число членов OMG плохо понимает технологию, за которую они голосуют. Это постоянно приводит к принятию спецификаций, обладающих серьезными техническими дефектами.
RFP часто публикуются по поводу непроработанных технологий. Члены OMG условно составляют две группы: пользователи технологии и поставщики технологии. Обычно именно пользователи хотят расширить спецификацию CORBA возможностями, позволяющими решить некоторую конкретную проблему. Эти пользователи в надежде, что поставщики откликнутся на их призыв, предложив решение этой проблемы, проталкивают публикацию RFP. Однако пользователи мало что знают о внутренних деталях реализации CORBA. В лучшем случае это приводит к публикации RFP, содержащей требования, которые трудно реализуются или оказывают отрицательное воздействие на производительность. В худшем случае появляются RFP, представляющие собой всего лишь призывы к поставщикам творить чудеса. Вместо того чтобы способствовать стандартизации передового опыта, такие RFP направлены на внесение в спецификации новшеств, предварительно не опробованных на практике.
Поставщики откликаются на RFP даже в тех случаях, когда им известны технические дефекты. Это может показаться удивительным. В конце концов, зачем поставщику предлагать стандарт для чего бы то ни было, чему свойственны известные технические проблемы? Причина кроется в том, что поставщики конкурируют между собой за потребителей и непрерывно борются на свое положение. Обещание откликнуться на RFP, даже если известно, что в ней содержатся серьезные проблемы, иногда используется для получения благосклонности пользователей (и, возможно, контрактов).
У поставщиков имеется конфликт интересов, когда дело доходит до стандартизации. Для поставщиков стандартизация является обоюдоострым мечом. С одной стороны, стандартизация привлекательна, поскольку упрощает торговлю технологией. С другой стороны, слишком строгая стандартизация кажется поставщикам приносящей вред, поскольку они хотят сохранить контроль над средствами, отличающими их продукт от продуктов конкурентов.
Иногда поставщики пытаются блокировать стандартизацию чего-либо, что потребовало бы внесения изменений в их существующие продукты. Это приводит к тому, что средства, которые следовало бы стандартизовать, остаются проприетарными, или они специфицируются настолько туманно, что спецификация становится бесполезной. Некоторые поставщики также отказываются различать стандартные и проприетарные средства, так что потребители забредают на территорию, зависящую от реализации, без предупреждений со стороны производителей. В результате перенос CORBA-приложения между реализациями платформы разных поставщиков может оказаться поразительно дорогостоящим; часто потребители оказываются привязанными к конкретному продукту, несмотря на всю стандартизацию.
В ответ на RFP часто поступает несколько проектов спецификации. Вместо того чтобы выбрать одну из конкурентных спецификаций, распространенной реакцией членов OMG является обращение к компаниям, представившим проекты, с просьбой объединить все возможности в единую спецификацию. Эта практика является основной причиной сложности CORBA. При объединении особенностей разных проектов спецификация превращается в кухонную раковину, в которую сливаются все предложения, приходившие кому-либо и когда-либо в голову. Это не только приводит к увеличению объема спецификации, но и чревато внесением в нее несогласованностей. Различные средства, являющиеся совершенно разумными по отдельности, могут противоречить одно другому и приводить к семантическим конфликтам.
Основные поставщики временами блокируют процесс стандартизации, пока их любимые средства не будут включены в объединенный стандарт. Это приводит к перерождению технологического процесса во внутреннюю политическую борьбу, вынуждает принимать нечестные компромиссные решения и порождает задержки. Например, жертвами такой внутриполитической борьбы пали первые попытки определения компонентной модели и отображения для C++. В обоих случаях работа приостанавливалась, а потом от полученных результатов отказывались и начинали все сначала.
В OMG для принятия спецификации не требуется наличие эталонной реализации. Эта практика открывает путь спецификациям, являющимся «воздушными замками». В нескольких случаях консорциум OMG публиковал стандарты, которые оказывались частично или полностью не реализуемыми из-за наличия серьезных технических дефектов. В ряде других случаев спецификации, которые можно было бы реализовать, являлись практически бесполезными, поскольку навязывали неприемлемые накладные расходы времени выполнения. Естественно, повторяющиеся случаи такого рода являются досадными и мало способствуют росту доверия потребителей. Требование наличия эталонной реализации вынудило бы подателей проектов спецификации реализовывать свои предложения и позволило бы избежать таких инцидентов.
В целом, недостатки процесса принятия технологических спецификаций в OMG должны рассматриваться как основная причина упадка CORBA. Этот процесс потворствует «разработке комитетом» (design by committee)** и политическому маневрированию до того момента, когда уже трудно достичь хотя бы удовлетворительного технического качества, не говоря уже о техническом превосходстве. Кроме того, добавление в стандарт разъединенных возможностей приводит к постепенной эрозии архитектурного замысла. (Например, архитектурная концепция прозрачных ссылок была проигнорирована при обновлении спецификации в 2000 г. В результате ссылки больше не являются прозрачными, но API по-прежнему обращаются с ними, как с прозрачными ссылками.)
Tехнических дефектов CORBA накопилось настолько много, что уже трудно исправить или добавить что-либо, не испортив что-то другое. Например, при каждом пересмотре протокола интероперабельности приходилось вносить несогласованные изменения, и несколько раз приходилось перерабатывать много исправлений и пояснений по причине появления непредусмотренных взаимодействий со средствами, добавленными с течением времени.
Можем ли мы учиться на ошибках прошлого?
Демократический процесс, принятый в OMG, однозначно не подходит для создания хорошего программного обеспечения. Однако, несмотря на известные процедурные проблемы, при производстве технологии индустрия предпочитает полагаться на крупные консорциумы. При стандартизации Web-сервисов, очередной серебряной пули промежуточного программного обеспечения, используется процесс, во многом похожий на процесс OMG, и во многих отношениях ему также свойственны внутриполитическая борьба, фрагментация, отсутствие архитектурной согласованности, разработка комитетом и раздувание возможностей. Кажется неизбежным, что Web-сервисам суждена история, похожая на историю CORBA.
Какие шаги следует предпринять, чтобы получить лучший процесс стандартизации и лучшее промежуточное программное обеспечение? Осознавая, что основная причина технических неудач кроется в процедурных неудачах, я предлагаю, по меньшей мере, следующее:
Консорциумы, занимающиеся стандартизацией, нуждаются в надежных правилах, гарантирующих, что они стандартизуют существующий передовой опыт. В области стандартов нет места инновациям. Вбрасывание «всего лишь небольшой дополнительной возможности» неизбежно порождает непредвиденные технические проблемы, не взирая на самые благие намерения.
Никакой стандарт не должен приниматься при отсутствии эталонной реализации. Это обеспечивает первую линию проверки готовности к работе стандартизуемой технологии. (Нет настолько выдающихся людей, чтобы они могли взглянуть на спецификацию и убедиться в отсутствии в ней скрытых дефектов, не выполнив реализацию этой спецификации.)
Никакой стандарт не должен приниматься без использования соответствующей спецификации при реализации нескольких проектов разумной сложности. Это необходимо для вылавливания плохих API. Слишком часто разработчики API вообще не используют собственные интерфейсы, что приводит к катастрофическим последствиям для их пригодности к практическому применению.
Интересно, что в сообществе open source эти правила соблюдаются гораздо лучше, чем в промышленных консорциумах.
К новшествам в области open source обычно применяется Дарвинский процесс естественного отбора. Различные разработчики реализуют свои идеи о том, как что-то должно работать, а другие члены сообщества open source пытаются использовать полученные средства и критикуют или совершенствуют их. Таким образом, программное обеспечение тщательно изучается и тестируется, и выживают только «наиболее приспособленные индивидуумы». (Во многих проектах open source этот процесс формализуется путем различения экспериментальных и производственных выпусков продуктов: экспериментальные выпуски служат испытательными стендами и эволюционными фильтрами.)
Для создания качественного программного обеспечения умение говорить «нет» обычно является гораздо более важным, чем умение говорить «да». В open source эта идея воплощается в том, что можно назвать «благожелательной диктатурой»: хотя в общую работу вносит свой вклад много людей, один эксперт (или небольшая группа экспертов) отвергает или принимает каждое предлагаемое изменение. Это позволяет сохранить исходный архитектурный замысел и предотвращает пресловутый уход за одним дитем сразу семью няньками.
В основе практики open source находятся два важных предварительных условия: сотрудничество и доверие. Без сотрудничества не может работать эволюционный процесс; без доверия никакая группа экспертов не сможет выступать в качестве окончательного арбитра. Однако именно здесь кроется смерть софтверных консорциумов. Наивно созывать конкурирующих поставщиков и потребителей в консорциум и ожидать, что они совместно смогут создать высококачественный продукт – коммерческие реалии неизбежно приводят к тому, что в умах участников консорциума сотрудничество и доверие находятся на самом последнем месте.
Конечно, софтверные консорциумы вносят свой вклад в эволюционный процесс, как и проекты open source. Но в качестве испытательного стенда и эволюционного фильтра используются коммерческий рынок и потребители, которые проявляют свою диктатуру (обычно не благожелательную) с помощью своих же кошельков. Это работает немного лучше, чем индустрия, подбрасывающая серебряные пули, под которыми потребители прыгают, как лемминги по утесу. Пока мы не изменим этот процесс, день появления универсального промежуточного программного обеспечения останется таким же отдаленным, как и было всегда.
Мичи Хеннинг (Michi Henning, ) является руководителем исследовательских работ компании ZeroC. С 1995 по 2002 гг. он работал над CORBA в качестве члена совета по архитектуры OMG, а также как разработчик ORB, консультант и преподаватель. Вместе со Стивом Виноски (Steve Vinoski) он написал книгу «Advanced CORBA Programming with C++» (Addison-Wesley, 1999). После перехода на работу в компанию ZeroC он занимается проектированием и реализацией продукта Ice, промежуточного программного обеспечения нового поколения. В 2003 г. при его участии было написано руководство «Distributed Programming with Ice». Он получил диплом с отличием по специальности «Компьютерные науки» в University of Queensland, Австралия.
*Идея этого механизма поддержки версий состоит в том, что новые функциональные возможности новой версии представляются в некотором интерфейсе, который «порождается» из интерфейса предыдущей версии. Типы предыдущей версии не изменяются, и новая функциональность представляется новыми типами с обеспечением обратной совместимости. Подробности см. на zeroc.com (Прим. С. Кузнецова).
** Результат того, что имеется много содействующих разработке, но не имеется единого видения (см. в википедии). (Прим. С. Кузнецова)
