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

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

Содержание


Взаимодействие Бизнес-объектов
Анатомия визнес-ОБъектов CORBA
Подобный материал:
1   ...   5   6   7   8   9   10   11   12   ...   16

Взаимодействие Бизнес-объектов


Бизнес-объекты будут использоваться для проектирования систем, которые имитируют бизнес-процессы. В реальном мире бизнес-события редко замыкаются на единственный бизнес-объект. Как правило, в эти события вовлечено множество объектов (группы взаимосвязанных объек­тов). Для имитации своих двойников из реального мира бизнес-объекты должны уметь взаимодействовать друг с другом на семантическом уров­не. Такие взаимодействия вы можете описать, используя наиболее по­пулярные методологии проектирования, включая IvarJacobson's use cases, lan Graham's task scripts, Grady Booch's interaction diagrams, and Jim Rumbaugh's event traces. Все эти методологии используют некоторую форму диаграмм сценариев, чтобы показать, "кто" и "что" делает, "для кого" и "когда". Эти сценарии могут полностью описать (документировать) результат определенных бизнес-событий.

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

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



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

Анатомия визнес-ОБъектов CORBA


Бизнес-объекты CORBA представляют собой разновидность пара­дигмы Модель/Представление/Контроллер (Model/View/Controller — МУС). MVC является шаблоном проектирования объектов, используемым для построения интерфейсов в Smalltalk и практически во всех библиотеках классов GUI (чаще всего в библиотеках программирования для графи­ческих оболочек Unix и Java; например, хорошо знакомая нашим про­граммистам библиотека компонентов JavaBeans с возможностью работы с базами данных — JBCL , входящая в состав Borland JBuilder, реализова­на именно в модели MVC, прим. ред.). MVC состоит из объектов трех типов. "Модель" представляет объект приложения и его инкапсулиро­ванные данные. "Представление" (view) отвечает за визуальный вид объекта на экране. А "контроллер" определяет способ реакции пользовательского интерфейса на события пользовательского ввода и оболочки GUI.

В модели CORBA прикладной объект также состоит из трех типов объектов (рис. 1-9):

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

Объекты бизнес-процессов инкапсулируют прикладную логику на уровне предприятия. В традиционных системах MVC контроллер за­висит от процесса. В модели CORBA функции короткоживущего про­цесса управляются бизнес-объектом. Долгоживущие процессы, вов­лекающие в функционирование другие бизнес-объекты, управля­ются объектом бизнес-процесса - это специализация бизнес-объек­та, который управляет долгоживущими процессами и средой в целом. Например, он знает, как управлять потоком документов или долго-живущей транзакцией. Бизнес-процесс обычно выступает в роли клея, объединяющего другие объекты. Например, он определяет ре­акцию объекта на изменения в среде. Такое изменение может быть вызвано исполнением прикладной транзакции или приходом сооб­щения от другого бизнес-объекта. Обратите внимание, что некото­рые бизнес-объекты могут быть полностью процессо-ориентирова-ны и не связаны с кпкими-либо данными или представлениями.



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

Типичный прикладной компонент состоит из бизнес-объекта, од­ного или нескольких объектов-представлений и бизнес-процесса. Обра­тите внимание, что эти сущности выступают как единое целое. Внут­реннее разделение обязанностей между различными объектами никак не волнует (является прозрачным для) пользователей и клиентов дан­ного бизнес-объекта. Бизнес-объект взаимодействует также с другими серверами и объектами системного уровня, но, опять же, как единый механизм. Пользователь видит только агрегированный бизнес-объект. Клиенты объекта имеют дело только с IDL-определенными интерфей­сами, выставленными данным агрегированным бизнес-объектом. OMG выпустило RFP для Общих бизнес-объектов (Common Business Objects) и Средств бизнес объектов (Business Object Facility). Средства будут предос­тавлять бизнес-объектам структуру для обмена семантической инфор­мацией и поддержки правил стыковки. (Примечание переводчика: Необ­ходимо ешё раз напомнить, что OMG готовит только спецификации). Мы ожидаем появления этой инфраструктуры к середине 1997 (еще об этом в части 4).