Общая Архитектура Брокеров Объектных Запросов - Common Object Request Broker Architecture (CORBA) является наиболее важным (и амбициозным) проектом в области промежуточного программного обеспечения (middleware), который когда-либо выдвигала компьютерная промышленность. CORBA— результат работы консорциума Object Management Group (OMG), который включает более 1000 компаний, представляющих весь "цвет" компьютерной индустрии,в том числе и Microsoft.Для остальной части компьютерной промышленности следующим поколением middleware является CORBA. Объектная шина (object bus) CORBA определяет структуру "живущих на ней" компонентов, а также способы их взаимодействия. Следовательно, выбирая открытую объектную шину, индустрия тем самым выбирает действительно открытую, ничем не ограниченную область применения компонентов.
Что делает CORBA крайне важной, так это то, что она определяет промежуточное программное обеспечение, которое потенциально связано со всеми другими формами существующих клиент/серверных middleware. Другими словами, CORBA использует объекты как унифицирующую метафору для объединения уже существующих приложений единой шиной взаимодействия. В то же время, она обеспечивает надежный фундамент для построения будущего, основанного на компонентах. Ценность CORBA состоит в том, что вся ее система самоопределяема (самоописываема). Кроме того, спецификация сервиса всегда отделена от его реализации. Это позволяет вам соединять существующие системы с единой шиной.
CORBA спроектирована таким образом, чтобы позволить интеллектуальным компонентам находить друг друга и взаимодействовать посредством объектной шины. Однако, CORBA обеспечивает не только взаимодействие. Она также определяет широкий набор связанных с шиной сервисов для создания и удаления объектов, для доступа к ним по именам, хранения их в долговременной памяти, предоставления информации об их состоянии и задания определенных связей между ними.
CORBA позволяет вам создать простой объект, а затем сделать его транзакционным, защищенным, блокируемым, или сохраняемым, за счет применения множественного наследования от соответствующих сервисов. Это означает, что вы можете сначала спроектировать обычный компонент с требуемой функциональностью, а затем дополнить его средствами промежуточного программного обеспечения, как на стадии его компиляции, так и на стадии выполнения. Так что, добро пожаловать в эпоху гибкого middleware, «сделанного на заказ». В любых других формах клиент/серверных технологий не существует ничего подобного.
Здесь рассказано об объектной шине CORBA и объектных системных сервисах, расширяющих эту шину. Мы начнем с обзора CORBA и с того, что она значит для интеллектуальных компонентов. Затем, мы рассмотрим объектную модель CORBA и архитектуру, которая связывает это все в единое целое. Наконец, мы оценим перспективы хорошо известных технологий клиент/сервер. Как вы увидите, некоторых важных моментов для распределенных объектов все еще не хватает. Далее мы и коснемся того, что готовит OMG в своих новых спецификациях.
Распределённые объекты в стиле CORBA
Возможно, секрет успеха OMG заключается в том, что эта группа дает спецификации интерфейсов, но не код как таковой. Интерфейсы, определенные OMG, всегда основаны на реальных технологиях, разработанных компаниями — членами этой группы. Спецификации написаны на пассивном языке описания интерфейсов IDL (Interface Definition Language), который определяет функциональность компонентов, — т.е. внешние (часто называемые контрактными) интерфейсы с потенциальными клиентами (в программном смысле). Компоненты, написанные на IDL, должны быть доступны независимо от программных языков, инструментальных средств, операционных систем и сетевой инфраструктуры программных компонент. А после принятия в декабре 1994 спецификации CORBA 2.0 эти компоненты будут способны взаимодействовать через объектные брокеры CORBA, созданные разными производителями.
ЧTO такое распределенные объекты CORBA?
Объекты CORBA представляют собой интеллектуальные единицы способные жить в любом месте сети. Они упакованы в виде двоичных компонентов, к которым удаленные кзженты могут обращаться, вызыая их методы. Как язык, так и компилятор, используемые для создания серверных объектов, являются полностью прозрачными для клиентов. Клиент не обязан знать, где располагается распределенный объект или под управлением какой операционной системы он выполняется. Он может находиться в том же процессе или на машине, расположенной где-то в "межгалактической" сети. Кроме того, клиенту не нужно знать, как реализован серверный объект. Например, серверный объект может быть реализован как набор классов C++ или с помощью миллиона строк на КОБОЛе - клиент не почувствует разницу. В чем действительно нуждается клиент, так это в опубликованном интерфейсе своего серверного объекта. Такой интерфейс служит связующим контрактом между клиентом и сервером. Весь смысл в IDL
CORBA IDL является чисто декларативным языком. Это означает, что он не описывает детали реализации. Вы можете использовать IDL, чтобы лаконично определить API, а также некоторые важные моменты, например, обработку ошибок. Методы, определенные на языке IDL, могут быть реализованы и вызваны из любых языков, которые обеспечивают поддержку CORBA. В настоящий момент это С, C++, Ada и Smalltalk COBOL, Java и Objective С. Программисты имеют дело с объектами CORBA, используя естественные и хорошо знакомые языковые конструкции. Для всех сервисов и компонентов, которые связаны с шиной CORBA, IDL предоставляет интерфейсы, не зависящие от операционной системы и языка программирования. IDL позволяет взаимодействовать клиентскими серверным объектам, написанным на различных языках
Рис 1 CORBA IDL Обеспечивает Интероперабельность
Вы можете использовать OMG IDL для указания атрибутов компонентов, родительских классов, от которых они унаследованы, исклюльных ситуаций, порождаемых компонентами, генерируемых ими событий, а также методов, которые поддерживаются интерфейсом компонентов, включая входные и выходные параметры методов и их типы данных. Грамматика IDL является подмножеством C++ с дополнительными ключевыми словами для поддержки концепции распределеннос, кроме того, полностью поддерживаются особенности стандарта препроцессора C++ и директивы pragma.
Амбициозность целей CORBA заключается в «IDL-изации» всего клиент/серверного middleware и всех компонентов, взаимодействующих через ORB. OMG надеется достичь этих целей с помощью следующих двух шагов: 1) она превратит все в гвозди и 2) даст каждому молоток.
«Гвоздем» программы станет IDL. Он позволяет производителям компонентов описать на стандартном языке определений интерфейсы и структуры поставляемых объектов. Определенные с помощью IDL контракты связывают производителей распределенных объектных сервисов с их клиентами. Объект, который запрашивает что-либо у другого объекта, обязан знать интерфейс этого объекта. Репозитарий Интерфейсов (Interface Repository) CORBA содержит определения всех таких интерфейсов. Он содержит метаданные, позволяющие компонентам находить друг друга динамически во время выполнения (run-time). Это делает CORBA самоопределяемой системой.
«Молоток» состоит из набора распределенных сервисов, которые будут поставлять производители OMG. Такие сервисы определяют: какие объекты существуют в сети, какие методы они предоставляют, и какие-адаптеры объектных интерфейсов они поддерживают. Местонахождение объекта должно быть прозрачным для клиента. Не должно иметь значения, находится ли объект в том же процессе или где-то во вселенной.
Целью является создание мультипроизводителей, мульти-операционных систем, мультиязыков, функционирующих в мире, используя объекты. Такие производители, как Oracle, Sun, HP, IBM, Digital, Apple,Netscape, Tandem и NCR, используют CORBA как стандартный, IDL-ный интерфейс на объектной дороге. IDL является контрактом, который связывает их всех вместе.
Компоненты СОКВА: от системных объектов к Бизнес-объектам
Обратите внимание, что мы использовали термины «компоненты» и «распределенные объекты» как взаимозаменяемые. Распределенныеобъекты CORBA по определению являются компонентами из-за способа их упаковки. В распределенных объектных системах единицей работы и распределенности является компонент. Инфраструктура распределенных объектов CORBA предоставляет простые механизмы, чтобы компоненты стали более автономными, самоуправляемыми и взаимодействующими. Такая заявка намного смелее, любых попыток конкурирующих форм промежуточного программного обеспечения Технология распределенных объектов CORBA позволяет нам собирать в единое целое сложные информационные клиент/серверные системы, просто связывая и расширяя их компоненты. Вы можете модифицировать объекты, не влияя на другие компоненты или на то, как они взаимодействуют. Клиент-серверные приложения превращаются в наборы взаимодействующих компонентов.
Последнее достижение в области индустрии компонентов клиент/сервер — суперинтеллектуальные компоненты, которые не просто взаимодействуют, — они сотрудничают на семантическом (смысловом) уровне, чтобы выполнить необходимую работу. Программисты могут легко добиться необходимого взаимодействия компонентов, создавая проммный код независимо для каждого компонента . Хитрость, однако, состоит в том, чтобы создать компоненты, которые a priori ничего не знают друг о друге, но сделают именно то, что нужно. Чтобы этого добиться, необходимы стандарты, устанавливающие правила стыковки на разных уровнях взаимодействия компонентов.
ОМА- Архитектура Управления Объектами от OMG(Object Management Architecture)
Осенью 1990 года OMG впервые опубликовала Руководство по Арпектуре Управления Объектами (Object Management Architecture Guide -ОMA Guide). Его обновление было сделано в 1992 году. Подробности, касающиеся Общих Средств (Common Facilities) были добавлены в январе 1995. На рис 2 показаны четыре основных элемента данной архитекы: 1) Брокер Объектных Запросов (Object Request Broker — ORB) опредеяет объектную шину CORBA; 2) Сервисы CORBA (CORBAservices)определяют системный уровень объектной структуры, которая расширяет шину; 3) Общие Средства CORBA (CORBAfacilities) определяют горизонтальные и вертикальные структуры, которые непосредственно используются бизнес-объектами; 4) Application Objects представляют прикладные объекты и приложения, то есть конечных потребителей ифраструктуры CORBA. Данный раздел описывает общий взгляд на четыре приведенных элемента инфраструктуры CORBA.
Рис 2. Архитектура Управления Объектами ORB
Брокер объектных запросов - Object Request Broker (ORB)
Брокер объектных запросов — это объектная шина. Она позволяет объектам прозрачно генерировать запросы и получать ответные отклики от других объектов - локальных или удаленных. Клиент ничего не знает о мех анизмах, используемых для коммуникации, активизации или хранения серверных объектов. Спецификации CORBA 1.1 (выпущенные в 1991)определяют только IDL, языковое связывание и API для обращения к ORB. Таким образом, вы могли бы написать переносимые программы, способные работать на дюжине CORBA-совместимых ORB, представленных на рынке (особенно со стороны клиента). CORBA 2.0 определяет взаимодействие (interoperability) ORB разных производителей.
CORBA ORB обеспечивает широкий спектр сервисов распределенного промежуточного программного обеспечения. ORB позволяет объектам обнаруживать друг друга во время выполнения (run-time) и вызывать сервисы друг друга. ORB намного более сложен, чем альтернативные формы клиент/серверного middleware, включая традиционные вызовы удаленных процедур (Remote Procedure Calls — RPC), обмен сообщениями (Message-Oriented Middleware — MOM), хранимые процедуры баз данных или сетевые службы взаимодействия "точка-точка" (peer-to-peer). Теоретически, CORBA является лучшим клиент/серверным middleware из когда-либо определенных. На практике же CORBA хороша настолько,насколько хорош реализующий эту архитектуру продукт. Чтобы показать, почему CORBA ORB так хороши для ППО архитектуры клиент/сервер, мы приводим следующий '«краткий» список замечательных свойств, присущих всем ORB:
ORB против RPC
Итак, чем вызовы методов ORB отличаются от вызовов RPC? Эти механизмы очень похожи, но есть некоторые важные отличия. С помощью RPC вы вызываете указанную функцию (данные отделены), С помощью ORB, наоборот, вы вызываете метод определенного объекта. Различные объектные классы могут отвечать на вызов одного и того же метода по-разному благодаря полиморфизму. Поскольку каждый объект управляет своим собственным экземпляром данных, вызываемый метод работает с этим определенным экземпляром данных. Вызов методов ORB обладает точностью скальпеля. Вызов направляется определенному объекту, который управляет конкретными данными, затем выполняется функция определенным для данного класса способом. Вызовы RPC, наоборот, не отличаются специализацией — все функции с одним и тем же именем реализованы одинаково. Здесь нет дифференцированных сервисов.
Анатомия CORBA ORB
CORBA Object Request Broker представляет собой промежуточное программное обеспечение, которое устанавливает клиент/серверныe отношения между объектами. Используя ORB, объект-клиент может прозрачно (не задумываясь ни о чем) вызывать метод объекта-сервера, который может находиться на той же машине или где-то в сети. ORB перехватывает вызов и отвечает за поиск объекта, способного ответить на запрос, передает ему параметры, вызывает метод и возвращает результат. Клиент не должен беспокоиться о том, где расположен объект, на каком языке программирования он создан, под управлением какой операционной системы выполняется и т.п. Клиента никогда не интересуют системные аспекты объектов, не являющиеся частью их интерфейсов. Очень важно отметить то, что роли клиент/сервер используются только для координации взаимодействия между двумя объектами. Объекты на шине ORB могут выступать и в качестве клиентов, и в качестве серверов, в зависимости от ситуации.
На рис 3 показаны клиентская и серверная части CORBA ORB. Светлые части являются новыми для CORBA 2.0. Несмотря на большое количество прямоугольников, ситуация не так запутана, как кажется. Главнoe - необходимо понять, что CORBA, подобно SQL, предоставляет как статические, так и динамические интерфейсы для своих сервисов. Это произошло потому, что OMG получила два запроса на разработку ORB: один от HyperDesk и Digital, основанный на динамическом API, а другой от Sun и HP, основанный на статическом API. OMG дала задание двум группам объединить эти две особенности. Результатом явилась CORBA. «Общая» («Common») в аббревиатуре CORBA означает слияние предложений для такого двойного API, что имеет колоссальный смысл, поскольку дает нам и статический и динамический API.
Рис 3 Структура ORB в CORBA
Для начала давайте рассмотрим, что делает CORBA с клиентской стороны:
В стандарте CORBA 2.0 ORB предоставляют глобальные идентификаторы - Репозитарные ID (Repository ID) - для уникальной и глобальной идентификации компонентов и их интерфейсов среди ORB разных производителей и множества репозитариев. Репозитарный ID генерируется системой и представляет собой уникальную строку, которая используется для поддержания целостности в соглашениях по наименованию. Соглашения по наименованию используются для всех репозитариев, при этом конфликты имен недопустимы. Репозитарный ID генерируется директивой pragma языка IDL. Эта директива специфицирует, генерировать ли идентификатор с использованием системы универсальных уникальных идентификаторов (Universal Unique Identifiers — UUID) DCE или он будет определяться пользователем — добавлением уникального префикса к составным именам IDL. Сам по себе репозитарный ID представляет строку, состоящую из трехуровневой иерархии имен. Поддержка как статических, так и динамических вызовов клиент/сервер, а также репозитарий интерфейсов, дает CORBA неоспоримые преимущества по сравнению с конкурирующими middleware. Статические вызовы легче программировать, они быстрее и самодокументируемы. Динамические вызовы предоставляют максимальную гибкость, но они сложнее в программировании; они очень полезны для инструментальных средств, которые исследуют сервисы во время выполнения.
Серверная часть не может определить разницу между статическим и динамическим вызовом; оба они имеют одинаковую семантику сообщения. В обоих случаях ORB находит объектный адаптер сервера, передает ему параметры, а затем передает управление коду объекта с помощью IDL-стаба (или скелетона - skeleton) сервера. На рис 3 показано, что делают элементы CORBA на стороне сервера:
На этом закончим панорамный обзор компонентов ORB и их интерфейсов.
CORBA: Архитектура Взаимодействия ORB (Inter-ORB)
Даже если некоторым разработчикам приложений понадобится разобраться в том, как взаимодействуют ORB, то это будет чисто спортивный интерес. Мы углубимся в вопросы взаимодействия стандарта CORBA. Ниже дано описание того, что делает каждый из элементов архитектуры взаимодействия ORB в стандарте CORBA:
GIOP также определяет формат для Интероперабельных Объектных Ссылок (Interoperable Object References - IOR). ORB обязан создавать IOR (из ссылки объекта) всегда, когда ссылка объекта передается между ORB. IOR ассоциирует набор профилей (tagged profiles) со ссылкой на объект. Эти профили описывают один и тот же объект, но каждый из них описывает способ контакта с объектом посредством механизма конкретного ORB. Более точно, профиль предоставляет самоописываемые данные, идентифицирующие домен ORB (с которым ассоциирована ссылка) и поддерживаемые им протоколы.
Общие средства 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 эти объекты верхнего уровня узнаваемы конечным пользователем системы. Масштаб объекта соответствует такой «бизнес»-сущности, как автомобиль или налоговая декларация. Слово «бизнес» используется в достаточно широком смысле. Бизнес-объект является самодостаточным, т.е. имеет пользовательский интерфейс, состояние, и знает, как взаимодействовать с другими, независимо разработанными бизнес-объектами, для выполнения возложенной на него задачи.
Взаимодействие бизнес-объектов
Бизнес-объекты будут использоваться для проектирования систем, которые имитируют бизнес-процессы. В реальном мире бизнес-события редко замыкаются на единственный бизнес-объект. Как правило, в эти события вовлечено множество объектов (группы взаимосвязанных объектов). Для имитации своих двойников из реального мира бизнес-объекты должны уметь взаимодействовать друг с другом на семантическом уровне. Такие взаимодействия вы можете описать, используя наиболее популярные методологии проектирования, включая Ivar Jacobson's use cases, Ian Graham's task scripts, Grady Booch's interaction diagrams, and Jim Rambaugh's event traces. Все эти методологии используют некоторую форму диаграмм сценариев, чтобы показать, "кто" и "что" делает, "для кого" и "когда". Эти сценарии могут полностью описать (документировать) результат определенных бизнес-событий.
Бизнес-объекты должны обладать поздним и гибким связыванием, а также четко определенными интерфейсами, чтобы их можно было реализовать независимо друг от друга. Бизнес-объекты должны уметь распознавать события в своей среде, изменять свои атрибуты и взаимодействовать с другими бизнес-объектами. Подобно любым объектам CORBA, бизнес-объекты раскрывают свои интерфейсы для клиентов посредством IDL и взаимодействуют с другими объектами через ORB.
рис 4
На рис.4 показан набор из четырех бизнес-объектов, которые являются частью системы заказа автомобилей: заказчик, счет, автомобиль, склад. Обратите внимание, что склад - бизнес-объект, который содержит другие бизнес-объекты — автомобили. Очевидно, что эти четыре бизнес-объекта имеют некоторую согласованную семантику для взаимодействия друг с другом, чтобы выполнять прикладные транзакации. На нижнем уровне они могли бы использовать сервис объектных транзакаций CORBA для синхронизаций своих действий. Они также способны "поделить" между собой единственное окно для корректного отображения информации.
Анатомия Бизнес-объектов CORBA
Бизнес-объекты CORBA представляют собой разновидность парадигмы Модель/Представление/Контроллер (Model/View/Controller - MVC) MVC является шаблоном проектирования объектов, используемым для построения интерфейсов в Smalltalk и практически во всех библиотеках классов GUI (чаще всего в библиотеках программирования для графических оболочек Unix и Java; например, хорошо знакомая нашим программистам библиотека компонентов JavaBeans с возможностью работы с базами данных — JBCL , входящая в состав Borland JBuilder, реализована именно в модели MVC). MVC состоит из объектов трех типов. "Модель" представляет объект приложения и его инкапсулированные данные. "Представление" (view) отвечает за визуальный вид объекта на экране. А "контроллер" определяет способ реакции пользовательского интерфейса на события пользовательского ввода и оболочки GUI.
В модели CORBA прикладной объект также состоит из трех типов объектов:
Типичный прикладной компонент состоит из бизнес-объекта, одного или нескольких объектов-представлений и бизнес-процесса. Обратите внимание, что эти сущности выступают как единое целое. Внутреннее разделение обязанностей между различными объектами никак не волнует (является прозрачным для) пользователей и клиентов данного бизнес-объекта. Бизнес-объект взаимодействует также с другими серверами и объектами системного уровня, но, опять же, как единый механизм. Пользователь видит только агрегированный бизнес-объект. Клиенты объекта имеют дело только с IDL-определенными интерфейсами, выставленными данным агрегированным бизнес-объектом. OMG выпустило RFP для Общих бизнес-объектов (Common Business Objects) и Средств бизнес-объектов (Business Object Facility). Средства будут предоставлять бизнес-объектам структуру для обмена семантической информацией и ьподдержки правил стыковки.
Анатомия клиент/серверных визнес-объектов
Обычно бизнес-объект (например, автомобиль) имеет несколько объектов-представлений, развернутых на нескольких клиентах. Бизнес-объект и бизнес-процесс могут располагаться на одном или нескольких серверах. Красота архитектуры CORBA заключается в том, что все объекты-участники имеют IDL-определенные интерфейсы и могут выполняться на ORB. Таким образом, не имеет значения, выполняются объекты-участники на одной и той же машине, или на разных (ORB обеспечивает прозрачность локальный/удаленный). Касается это клиентов, или нет, но они все еще имеют дело с единственным при'кладным компонентом , даже если он построен из объектов, выполняющихся на разных машинах. Хорошо спроектированный бизнес-объект строится на основе сервисов CORBA. Например, вы можете использовать сервисы совместного доступа и транзакций для обеспечения целостности состояния бизнес-объекта. ORB предоставляет вам сервисы бесплатно, используйте их, если вам это нужно.
Нирвана компонентов CORBA
На самом базовом уровне компонентная инфраструктура представляет объектную шину — Брокер объектных запросов (Object Request Broker - ORB), — которая позволяет компонентам взаимодействовать, невзирая на разницу в адресных пространствах, языках, операционных систем и сетевых инфраструктур. Шина предоставляет также механизмы, позволяющие компонентам обмениваться метаданными и исследовать друг друга. На следующем уровне эта инфраструктура расширяет шину за счёт дополнительных сервисов системного уровня, которые позволяют создавать "суперинтеллектуальные" компоненты. Примерами таких Сервисов служат сервисы лицензирования, безопасности, управления версиями, хранения, стыковки составных частей, обмена семантическими сообщениями, выполнения сценариев, транзакций.
Конечная цель состоит в том, чтобы позволить вам создавать компоненты, которые ведут себя как бизнес-объекты. Эти компоненты моделируют своих двойников из реального мира в приложениях для некоторых отраслей промышленности. Обычно они выполняют специфичные бизнес-функции, например, "автомобиль", "заказчик" или "гостиница". Вы можете сгруппировать эти бизнес-объекты в визуальные наборы, которые отображаются на экране, но основаны на отношениях клиент/сервер.
Итак, последняя нирвана в области компонентов клиент/сервер —суперинтеллектуальные прикладные компоненты, которые более чем взаимодействуют, они сотрудничают на семантическом уровне для выполнения требуемой задачи. Например, разъездные агенты, используя глобальную сеть должны иметь возможность обмениваться информацией со своими коллегами. Агенты представляют собой примеры бизнес-объектов. Такая инфраструктура обеспечивает стандарты сотрудничества приложений в форме инфраструктур уровня приложения (OMG называет их отраслевыми или доменными структурами - domain frameworks).Такие инфраструктуры определяют правила стыковки между независимыми компонентами.
Трехзвенноя архитектура клиент/сервер в объектном стиле
Бизнес- объекты идеальны для создания масштабируемой трехзвенной архитектуры клиент/сервер, поскольку им присуща декомпозиция. Бизнес-объект не является монолитным куском кода. Наоборот, он больше напоминает модель конструктора "Лего", которую вы сначала разбираете, а затем опять собираете в трехзвенную цепочку клиент/сервер. Первое звено представляет визуальные аспекты бизнес-объекта— один или несколько визуальных объектов могут воплощать различные представления. Эти визуальные объекты обычно располагаются на клиентах. Промежуточное звено — серверные объекты, представляющие хранимые данные и функции бизнес-логики. В третье звено включаются базы данных и унаследованные серверные приложения. Такое деление бизнес-объектов достаточно условно. Вы обязаны решить, где расположить различные звенья для этапа выполнения.
Серверные объекты промежуточного звена взаимодействуют со своими клиентами (визуальными объектами) и реализуют логику бизнес-объектов. Они могут извлекать информацию о своем состоянии из нескольких источников данных, например, SQL-серверов, файлов HTML, Lotus Notes и мониторов транзакций. Серверные объекты воплощают интегрированную модель несопоставимых источников данных и фоновых приложений. Клиенты взаимодействуют с бизнес-объектами, которые обычно соответствуют отраслевым понятиям. Их не интересует «кухня» третьего звена - хранимые процедуры и базы данных. Бизнес-объекты скрывают всю эту суету.
Серверный объект может кэшировать данные, извлекаемые из локального объекта БД для ускорения последующего доступа, или сразу модифицировать источник данных третьего звена с обновлением представления. Клиенты никогда не должны непосредственно взаимодействовать с источниками данных третьего звена. Эти источники должны полностью инкапсулироваться и абстрагироваться серверными объектами промежуточного звена. Например, у вас должна быть возможность заменить одну БД на другую, не влияя на клиентов.
Обычно клиенты взаимодействуют с серверными объектами промежуточного звена посредством ORB. В дополнение к этому объекты среднего звена могут общаться друг с другом посредством сервера ORB, который может использоваться для выравнивания нагрузки, координации распределенных транзакций и обмена бизнес-событиями. Благодаря этому бизнес-объекты ORB приобретают мощную масштабируемость. Наконец, серверные объекты взаимодействуют с третьим звеном, используя традиционное ППО. Мы намерены продолжить рассказ о бизнес-объектах далее.
Распределенные объекты CORBA — смоделированные как бизнес-объекты — превосходно подходят для трехзвенной архитектуры клиент/сервер. Они обеспечивают масштабируемые гибкие решения для межгалактической среды клиент/сервер, для Internet и Intranet. Бизнес-объекты могут естественным образом подвергаться декомпозиции и разбиению на множество звеньев для удовлетворения потребностей приложения. Они представляют собой самоописываемые и самоуправляемые "единицы интеллектуальности", которые вы можете перемещать повсюду и запускать там, где в этом есть наибольший смысл. Наиболее важно то, что бизнес-объекты эволюционны, они не вынуждают вас выбросить существующие серверные приложения и начать все сначала. Вы можете инкапсулировать то, что уже имеете, и постепенно добавлять новую интеллектуальность, по одному компоненту за один раз.
назад | содержание | далее
