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