Пример процесса разработки спецификаций CORBA

Как упоминалось, разработка чрезвычайно востребованного для электронной коммерции стандарта промежуточного программного обеспечения производилась совместными усилиями нескольких сотен ведущих компьютерных фирм в рамках консорциума OMG. Ожидалось, что заинтересованность потребителей, участие в разработке ведущих фирм и значительные инвестиции обеспечат технологии CORBA безоблачное будущее. Однако произошло нечто противоположное – технология не смогла оправдать возложенных на нее надежд и заняла весьма узкую нишу на рынке (в основном – это встраиваемые системы).

Хеннинг отмечает внешние причины упадка CORBA, но основная причина – в ее техническом несовершенстве и, в первую очередь, – в ее сложности. Как же могло произойти так, что крупнейший в мире софтверный консорциум создал технически несовершенную технологию? Причину этого Хеннинг видит в организации совместной работы специалистов.

OMG публикует спецификации на основе голосования. Демократичность и справедливость процесса вместо ожидаемых дивидендов на практике сослужила плохую службу. Некоторые отрицательные проявления данного процесса перечисляются ниже.

1. Многие из участников разработки не являются экспертами в вопросах, за которые они голосуют, что постоянно приводит к принятию спецификаций, обладающих серьезными техническими дефектами.

2. Потребители, участвующие в разработке наравне с поставщиками, часто выдвигают требования, которые на практике трудно реализуемы. Нередко предлагаемая ими функциональность не столь принципиальна, но ее реализация противоречит принятой архитектуре системы и, поэтому оказывается очень громоздкой и запутанной.

3. Поставщики соглашаются на предложения потребителей даже в тех случаях, когда им известны технические дефекты. Делается это для получения благосклонности потребителей (и, возможно, контрактов), поскольку поставщики конкурируют между собой за потребителей.

4. У поставщика имеется конфликт интересов по отношению к стандартизации. С одной стороны, стандартизация привлекательна, поскольку упрощает торговлю технологией. С другой стороны, поставщики избегают слишком строгой стандартизации, чтобы не раскрывать свои решения, которые дают преимущества над конкурентами. Поставщики, стремясь удержать рынок сбыта, всячески пытаются привязать потребителя именно к своему продукту. Для этого многие компоненты, которые следовало бы стандартизовать, поставщики не раскрывают, пытаются блокировать их стандартизацию, или сделать эту стандартизацию слишком «туманной» и бесполезной. Похожее противодействие стандартизации возникает также в случаях, когда предлагаемая спецификация требует изменений в существующих продуктах поставщиков и т. п.

5. При рассмотрении конкурентных вариантов спецификации, предлагаемых разными участниками, OMG пытается объединить все возможности в единую спецификацию вместо того, чтобы выбрать один из вариантов. В итоге спецификация превращается в «кухонную раковину», в которую сливаются все предложения, приходившие кому-либо и когда-либо в голову. Эта практика является основной причиной сложности CORBA. Различные решения, совершенно разумные по отдельности, могут противоречить одно другому и приводить к семантическим конфликтам.

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

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

Как отмечает Хеннинг, для совместной разработки ключевое значение имеют сотрудничество и доверие. Без них: «Наивно созывать конкурирующих поставщиков и потребителей в консорциум и ожидать, что они совместно смогут создать высококачественный продукт – коммерческие реалии неизбежно приводят к тому, что в умах участников консорциума сотрудничество и доверие находятся на самом последнем месте».

Благодаря сотрудничеству и доверию эффективность совместной разработки у проектов с открытым программным кодом (open source) существенно выше. Тем не менее, при производстве технологий индустрия предпочитает полагаться на крупные консорциумы. Эффективность консорциумов можно несколько улучшить, если соблюдать ряд формальных требований, например, не принимать стандартов без предварительной их апробации на нескольких реальных проектах разумной сложности и пр. Однако формальными требованиями невозможно заставить конкурирующих разработчиков доверять друг другу.

Примечательно, что после своего ухода из консорциума OMG, где он был членом комитета по архитектуре CORBA, Мичи Хеннинг стал руководителем исследовательских работ в перспективном проекте с открытым кодом Ice (Internet Communications Engine). Ice известно, как эффективное и масштабируемое ПО промежуточного слоя, намного меньше и проще, чем CORBA. Ice поддерживает очень большое количество платформ программирования и конкурирует с SOAP.