Предисловие редакторов русского издания
Вид материала | Документы |
СодержаниеАнатомия клиент/серверных Бизнес- объектов Нирвана компонентов CORBA Брокер объектных запросов (Object Request Broker - ORB), — Трехзвенная архитектура клиент/сервер в объектном стиле |
- От редакторов русского издания, 12579.28kb.
- Предисловие переводчика и редактора русского издания, 173.31kb.
- Предисловие от редакторов, 3279.6kb.
- Крайон книга третья. Алхимия человеческого духа руководство по переходу человечества, 3416.54kb.
- Электронная библиотека студента Православного Гуманитарного Университета, 3857.93kb.
- Предисловие, 5158.35kb.
- Автор файла (январь 2009г.): Мухамеджан Мухамеджанов, 250.83kb.
- Предисловие ко второму изданию, 1366.96kb.
- Аллан Кардек спиритизм в самом простом его выражении содержание, 4227.55kb.
- Философия русского религиозного искусства XVI-XX вв. Антология, 6335.43kb.
Анатомия клиент/серверных Бизнес- объектов
Обычно бизнес-объект (например, автомобиль) имеет несколько объектов-представлений, развернутых на нескольких клиентах. Бизнес-объект и бизнес-процесс могут располагаться на одном или нескольких серверах. Красота архитектуры 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.