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

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

Содержание


Анатомия клиент/серверных Бизнес- объектов
Нирвана компонентов CORBA
Брокер объектных запросов (Object Request Broker - ORB), —
Трехзвенная архитектура клиент/сервер в объектном стиле
Подобный материал:
1   ...   6   7   8   9   10   11   12   13   ...   16

Анатомия клиент/серверных Бизнес- объектов


Обычно бизнес-объект (например, автомобиль) имеет несколько объектов-представлений, развернутых на нескольких клиентах. Бизнес-объект и бизнес-процесс могут располагаться на одном или нескольких серверах. Красота архитектуры CORBA заключается в том, что все объек­ты-участники имеют IDL-определенные интерфейсы и могут выпол­няться на ORB (рис. 1-10). Таким образом, не имеет значения, выполня­ются объекты-участники на одной и той же машине, или на разных (ORB обеспечивает прозрачность локальный/удаленный). Касается это клиентов, или нет, но они все еще имеют дело с единственным при­кладным компонентом , даже если он построен из объектов, выполня­ющихся на разных машинах. Хорошо спроектированный бизнес-объект строится на основе сервисов CORBA. Например, вы можете использо­вать сервисы совместного доступа и транзакций для обеспечения цело­стности состояния бизнес-объекта. ORB предоставляет вам сервисы бес­платно, используйте их, если вам это нужно.

Business Object- Component


Нирвана компонентов CORBA


Совместно используемые тзиес-огьекты (Cooperative Business Objects - CBO) - sro реальность. Пшожо лругим реальностям они могут выть настроены лля удовлетворения трееований пользователя сез вмешательства разработчика. Вы sepere некую вещь, выражающую coson некоторую сущность. например, заказчик, и получаете то. что ожшали: объект "заказчик" как таковой. Вы получаете именно заказчика и ничего кроме заказчика, оеъект. готовый к выполнению и использованию!

Oliver Sims, автор Business Objects (McCraw-HiH. 199't)

Ha самом базовом уровне компонентная инфраструктура представ­ляет объектную шину — Брокер объектных запросов (Object Request Broker - ORB), — которая позволяет компонентам взаимодействовать, невзи­рая на разницу в адресных пространствах, языках, операционных сис­тем и сетевых инфраструктур. Шина предоставляет также механизмы, позволяющие компонентам обмениваться метаданными и исследовать друг друга. На следующем уровне эта инфраструктура расширяет шину за счет дополнительных сервисов системного уровня, которые позволяют создавать "суперинтеллектуальные" компоненты. Примерами таких сер­висов служат сервисы лицензирования, безопасности, управления вер­сиями, хранения, стыковки составных частей, обмена семантическими сообщениями, выполнения сценариев, транзакций.

Конечная цель состоит в том, чтобы позволить вам создавать ком­поненты, которые ведут себя как бизнес-объекты. Эти компоненты мо­делируют своих двойников из реального мира в приложениях для неко­торых отраслей промышленности. Обычно они выполняют специфич­ные бизнес-функции, например, "автомобиль", "заказчик" или "гос­тиница". Вы можете сгруппировать эти бизнес-объекты в визуальные наборы, которые отображаются на экране, но основаны на отношениях клиент/сервер.

Итак, последняя нирвана в области компонентов клиент/сервер -суперинтеллектуальные прикладные компоненты, которые более чем взаимодействуют, они сотрудничают на семантическом уровне для вы-



полнения требуемой задачи. Например, разъездные агенты, используя глобальную сеть должны иметь возможность обмениваться информаци­ей со своими коллегами. Агенты представляют собой примеры бизнес-объектов. Такая инфраструктура обеспечивает стандарты сотрудничества приложений в форме инфраструктур уровня приложения (OMG назы­вает их отраслевыми или доменными структурами - domain frameworks). Такие инфраструктуры определяют правила стыковки между независи­мыми компонентами.

На рис. 1-11 показана эволюция компонентов от простого взаимо­действия к сотрудничеству. Эволюция отражает расширение границ сер-висов компонентной инфраструктуры. Компонентная шина дает вам простое взаимодействие, системные сервисы дают суперинтеллектуаль­ные компоненты, а инфраструктуры уровня приложений обеспечивают семантику прикладного уровня для компонентов, которые сотруднича­ют в между собой.

Трехзвенная архитектура клиент/сервер в объектном стиле


Бизнес- объекты идеальны для создания масштабируемой трехзвен-ной архитектуры клиент/сервер, поскольку им присуща декомпозиция. Бизнес-объект не является монолитным куском кода. Наоборот, он боль­ше напоминает модель конструктора "Лего", которую вы сначала раз­бираете, а затем опять собираете в трехзвенную цепочку клиент/сервер (рис. 1-12). Первое звено представляет визуальные аспекты бизнес-объекта ~ один или несколько визуальных объектов могут воплощать различные представления. Эти визуальные объекты обычно располагаются на кли­ентах. Промежуточное звено - серверные объекты, представляющие хранимые данные и функции бизнес-логики. В третье звено включаются базы данных и унаследованные серверные приложения. Такое деление бизнес- объектов достаточно условно. Вы обязаны решить, где располо­жить различные звенья для этапа выполнения.

Серверные объекты промежуточного звена взаимодействуют со сво­ими клиентами (визуальными объектами) и реализуют логику бизнес-объектов. Они могут извлекать информацию о своем состоянии из не­скольких источников данных, например, SQL-серверов, файлов HTML, Lotus Notes и мониторов транзакций. Серверные объекты воплощают интегрированную модель несопоставимых источников данных и фоно­вых приложений. Клиенты взаимодействуют с бизнес-объектами, кото­рые обычно соответствуют отраслевым понятиям. Их не интересует «кух­ня» третьего звена - хранимые процедуры и базы данных. Бизнес-объекты скрывают всю эту суету.



Серверный объект может кэшировать данные, извлекаемые из ло­кального объекта БД для ускорения последующего доступа, или сразу модифицировать источник данных третьего звена с обновлением пред­ставления. Клиенты никогда не должны непосредственно взаимодей­ствовать с источниками данных третьего звена. Эти источники должны полностью инкапсулироваться и абстрагироваться серверными объек­тами промежуточного звена. Например, у вас должна быть возможность заменить одну БД на другую, не влияя на клиентов.

Обычно клиенты взаимодействуют с серверными объектами проме­жуточного звена посредством ORB. В дополнение к этому объекты сред­него звена могут общаться друг с другом посредством сервера ORB, который может использоваться для выравнивания нагрузки, координа­ции распределенных транзакций и обмена бизнес-событиями. Благода­ря этому бизнес-объекты ORB приобретают мощную масштабируемость. Наконец, серверные объекты взаимодействуют с третьим звеном, ис­пользуя традиционное ППО. Мы намерены продолжить рассказ о биз­нес-объектах в части 4.