Предисловие редакторов русского издания

Вид материалаДокументы

Содержание


Объектные Сервисы: Middleware под заказ
Общие средства CORBA (CORBAfacilities)
Corba business objects: бизнес-объекты
Подобный материал:
1   ...   4   5   6   7   8   9   10   11   ...   16

Объектные Сервисы: Middleware под заказ


Объектные сервисы CORBA предоставляют уникальную возможность создавать middleware в соответствии с предъявляемыми требованиями

(build-to-order). Это не похоже ни на какие классические системы кли­ент/сервер, существующие сегодня. Производители компонентов CORBA могут разрабатывать свои объекты, не касаясь системных сервисов. Затем, в зависимости от того, что необходимо заказчику, разработчик (или системный интегратор) может интегрировать первоначальный компонент с любым сочетанием сервисов CORBA для получения требуемой функци­ональности. Для этого сначала необходимо создать подкласс исходного класса, а затем объединить его с классами требуемых объектных сервисов посредством множественного наследования. Например, вы можете разра­ботать компонент под названием «автомобиль» и создать согласованную (при параллельном выполнении), подлежащую долговременному хране­нию, транзакционную версию автомобиля, выполнив множественное на­следование от соответствующих сервисов. Вы также можете использовать некоторые из этих сервисов посредством делегирования.

Кроме того, некоторые поставщики ORB получат преимущества от применения метаклассов собственных расширений CORBA, позволяя вам создавать ваши «смеси» во время создания объекта. Метакласс - это класс, который также является исполняемым объектом. Это означает, что вы можете создать и настроить новый класс во время выполнения. Фабрики объектов (object factories) могут использовать возможности таких метаклассов, чтобы скомпоновать класс во время выполнения, основываясь на запросе клиента. Вы можете создавать нестандартные (made-to-order) классы, выполняя множественное наследование от су­ществующих объектных сервисов. Например, фабрика может взять обыч­ный компонент, такой как «автомобиль», и сделать его транзакцион-ным, блокируемым, защищенным, выполняя множественное наследо­вание от классов существующих объектных сервисов. Такой подход яв­ляется основной формой создания нестандартного промежуточного программного обеспечения. Прелесть заключается в том, что поставщик исходного компонента может ничего не знать о транзакциях, безопасно­сти или блокировках. Эти сервисы добавляются к компоненту автомати­чески во время создания его фабрикой на основе требований клиента.

Если вам не нравится множественное наследование, то некоторые реализации ORB позволяют добавлять методы к существующему классу «на лету». В частности, вы можете добавить функции обратного вызова (callbacks) до и после, которые запускаются до и после выполнения любого обычного метода. Вы можете использовать эти до и после функ­ции, чтобы вызвать любой из существующих сервисов CORBA или, что то же самое, все, что живет на шине ORB. Вы даже можете подключить сценарии к триггерам до/после. Например, триггер до можно использо­вать для получения блокировки от сервиса контроля совместного досту-пп. ;1 триггер tior'ip -- 'пя гс гнятпч

Комбинируя технологию метаклассов с ссрвисами CORBA, вы смо­жете легко настроить среду middleware для выполнения определенных компонентов. Это демонстрирует неограниченную гибкость компонен­тов. Большинство разработчиков компонентов, вероятно, изберет более консервативный подход и будет создавать свои «смеси» на этапе компи­ляции или посредством инструментальных средств на этапе проектиро­вания. В любом случае, эта технология все же предоставляет больше гиб­кости, чем любая из сегодняшних версий промежуточного программно­го обеспечения клиент/сервер.

Общие средства CORBA (CORBAfacilities)


Средства CORBA представляют собой набор определенных на IDL структур, которые предоставляют сервисы для непосредственной связи с объектами приложения. Думайте о них, как о следующем шаге вверх в семантической иерархии. Две категории общих средств - горизонталь­ные и вертикальные — определяют правила совместного использования тех бизнес-компонентов, которым необходимо эффективно взаимодей­ствовать между собой. В октябре 1994 OMG выпустила в свет запрос на разработку общих средств (RFP1) с целью получения технологии со­ставных документов. В марте 1996 OMG адаптировала OpenDoc для сво­ей технологии составных документов. Этой технологии присвоили на­звание Средства компонентов для распределенных документов (Distributed Document Component Facility — DDCF). DDCF определяет сервисы пред­ставления компонентов и стандарт обмена документами, основанный на OpenDoc Bento.

Общие средства, находящиеся в настоящее время в разработке, вклю­чают мобильные агенты, обмен данными, структуры прикладных объек­тов и интернационализацию. Подобно скоростным магистралям, общие средства являются бесконечным проектом. Работа продолжится до тех пор, пока не будут определены IDL-интерфейсы CORBA для всех рас­пределенных сервисов, известных сегодня, а также тех, которые еще будут изобретены. Когда это произойдет, CORBA предоставит IDL-ин­терфейсы фактически для каждого сетевого сервиса (многие будут пред­ставлять IDL-изованные версии существующих middleware).

CORBA BUSINESS OBJECTS: БИЗНЕС-ОБЪЕКТЫ


Бизнес-объекты предоставляют естественный способ описания не­зависимых от конкретного приложения концепций, таких как заказ­чик, заказ, конкурент, деньги, платежи, автомобиль, пациент. Они спо-



собствуют формированию взгляда на программное обеспечение, как на нечто, выходящее за пределы инструментальных средств, приложений, баз данных и других системных концепций. Окончательная цель объект­ной технологии и компонентов состоит в том, чтобы предоставить та­кие компоненты среднего уровня детализации (medium-grained), кото­рые лучше всего описывают поведение реального мира. Конечно, кто-то должен первым определить правила игры для компонентов, чем и занимается OMG. (Согласно Business Object Task Force - комитету OMG по бизнес-объектам, бизнес-объекты — суть компоненты уровня при­ложения, которые вы вольны использовать в непредопределенных ком­бинациях. Бизнес-объект, по определению, не зависит от какого-либо конкретного приложения. "Пост-монолитные" приложения будут со­стоять из набора бизнес-объектов — приложение будет просто обеспе­чивать среду для функционирования таких бизнес-объектов. Другими сло­вами, бизнес-объект есть компонент, представляющий «узнаваемую» в повседневной жизни сущность. В про­тивоположность этому, объекты сис­темного уровня представляют сущнос­ти, которые имеют смысл только для информационных систем или для про­граммистов. Они не понятны конечным пользователям.

В небоскребе чей-то потолок явля­ется чьим-то полом, пока вы не добе­ретесь до пентхауса, где только небо будет вашим потолком. Вы можете представлять бизнес-объект как "пен-тхаус компонентов". В соответствии с определением OMG эти объекты вер­хнего уровня узнаваемы конечным пользователем системы. Масштаб объекта соответствует такой «бизнес»-сущности, как автомобиль или нало­говая декларация. Слово «бизнес» ис­пользуется в достаточно широком смысле. Бизнес-объект является само­достаточным, т.е. имеет пользователь­ский интерфейс, состояние, и знает, как взаимодействовать с другими, не­зависимо разработанными бизнес-объектами, для выполнения возложен­ной на него задачи.