Сергей Зыков - Основы проектирования корпоративных систем

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

Это, конечно, COM-модель, по сути, технологический стандарт компании Microsoft, на котором строятся и приложения. NET, и приложения, которые надстраиваются над. NET, в том числе офисные. Другим подходом является технологический стандарт Sun Microsystems – Java Beans или Enterprise Java Beans, в случае корпоративных реализаций. Важно отметить, что по большому счету, за некоторыми незначительными исключениями, Java Beans не является стандартом с языковой интероперабельностью, т. е. зависит от языка программирования. И, к сожалению, при разработке по этому стандарту в основном нужно полагаться на использование языка Java.

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

Если говорить о классе, о компоненте, который реализует функцию, например логическую функцию управления верхнего уровня целым рядом более мелких классов системы, то, наверное, имело бы смысл использовать язык логического программирования типа Prolog или SmallTalk. Или использовать язык функционального программирования типа Lisp, SML и F#. И F# во многом используется в этом качестве. Если говорить о моделировании функций, о математическом моделировании, то вполне можно использовать функциональный язык типа F#. Если говорить, например, о построении графического интерфейса или интерфейса с операционной системой Windows, то, конечно, лучше использовать языки типа C#. То есть языки, с одной стороны, полностью объектно-ориентированные, а с другой – это родной язык. NЕT, он предельно тесно интегрирован с CLR, со средой выполнения и, собственно, с платформой. NET и ее виртуальной машиной. Поэтому языковая интероперабельность является достаточно важным преимуществом с точки зрения больших корпоративных систем и, конечно, с точки зрения учебного процесса, когда на единой программной платформе, на платформе. NET, можно показать, как строятся не только приложение на основе различных подходов к программированию (логического подхода, объектно-ориентированного подхода, функционального подхода и т. д.), но и гетерогенные предложения, которые представляют собой конгломераты или семейства компонентов, разработанных на различных языках программирования. И еще один подход – CORBA, который основан на построении обобщенной объектной шины для взаимодействия гетерогенных объектов на основе брокеров объектных запросов, т. е., по сути, механизма обмена сообщениями между объектами. К сожалению, он сейчас не так широко распространен в связи с достаточно громоздкими интерфейсами языка определения контрактов, средств взаимодействия между компонентами – IDL. И достаточно сложно представить отображение одного языка реализации в другой, поэтому сегодня не так популярен этот подход. Рассмотрим, каким образом строится приложение из компонентов. Существуют два основных уровня (рис. 13.1). Нижний уровень схематически представлен тремя блоками различной формы с отверстиями – это компонентная среда. По сути, речь идет о. NET и CLR, т. е. NET Framework большого количества классов, которые взаимодействуют друг с другом, и компонентах, построенных на основе этих классов, которые тоже имеют контракты, связаны друг с другом и позволяют разворачивать внешние компоненты – надстроечные компоненты прикладного уровня, которые расположены на уровень выше в виде двух больших блоков, подобных кубикам с различного рода шипами или, наоборот, пазами, схематически представляют собой интерфейсы и описываются контрактами. Каждый компонент имеет интерфейс, даже несколько интерфейсов того или иного рода, которые полностью описываются интерфейсными контрактами, программными контрактами и позволяют компонентам осуществлять взаимодействие на основе компонентной модели. То есть эти контракты в полной мере соответствуют компонентной модели, которая применяется.

Рис. 13.1.Основные элементы компонентных приложений