Главная » Delphi » Разработка приложений COM+

0

Теперь, рассмотрев отдельные возможности спецификации COM+, можно  при ступать  к разработке приложения, в котором были  бы  реализованы такие  свойства COM+, как транзакции, контроль за временем существования объектов и совместное использование ресурсов.

Цель  — масштабируемость

В наше  время  основной целью  системного проектирования является достижение высокой масштабируемости. В связи  с быстрым распространением Internet,  intranet, extranet и других видов сетей, объединением корпоративных данных  в централизован ные  хранилища и потребностью в массовом  совместном использовании этих  данных, стали предъявляться жесткие требования к масштабируемости систем.  Современные системы вынуждены одновременно взаимодействовать с гораздо большим  количеством пользователей, чем  прежде. Это  действительно серьезная задача,  особенно учитывая такие  технические ограничения, как количество возможных одновременных подклю чений к базе данных, пропускная способность сети, загрузка сервера и т.п. В старые до брые  времена (в начале  90 х годов)  к системам архитектуры клиент/сервер относились как к единственному типу масштабируемых приложений. Но базы данных  с увеличени ем количества триггеров и хранимых процедур становились все сложнее, а клиенты по стоянно сталкивались со сложностями реализации своих  бизнес  правил. Вскоре  стало очевидно, что подобные системы никогда  не смогут стать настолько масштабируемыми, чтобы  обслужить  действительно большое количество пользователей. Поэтому  много уровневая архитектура вскоре заняла  лидирующие  позиции в сфере построения мас штабируемых систем.  В этой  архитектуре функции приложения и распределенные под ключения к базе данных находятся на среднем уровне,  что позволяет упростить как саму базу данных, так и клиентскую часть приложения, а кроме  того,  существенно оптимизи ровать использование ресурсов.

НА ЗАМЕТКУ

Структура многоуровневой модели построена таким образом, что увеличение пропуск- ной способности приложения приводит к увеличению временных задержек. Другими словами, увеличение масштабируемости приводит к снижению производительности.

Контекст исполнения

Не забывайте о том, что, в отличие от объектов COM, объекты COM+ не работают непосредственно в контексте клиента. К тому же клиенты никогда  не получают  указа тели на интерфейсы непосредственно в объектах. Вместо этого  в COM+ между клиен тами и объектами используются посредники. При  таком  подходе  посредник, с точки зрения клиента, является точной копией объекта. Учитывая тот  факт,  что  средства COM+ имеют  полный контроль над посредниками, они  могут управлять также  и дос тупом к методам  интерфейсов объектов. Такая  возможность может  быть  использова на для управления временем существования и защитой объектов.

Учет состояния объектов

Среди  разработчиков, использующих  технологию COM+,  часто  можно  услышать дискуссии  о различиях между объектами, учитывающими и не учитывающими состоя ние (stateful и stateless).  Несмотря на то что в спецификации COM нет никаких указа ний по этому поводу, в большинстве случаев объекты COM учитывают состояние. Это означает, что они постоянно, начиная с момента создания и до момента удаления, со держат  какую то  информацию. Проблема, связанная с использованием таких  объек тов,  заключается в их низкой масштабируемости. Указанное объясняется тем,  что хранимая информация должна  поддерживаться для каждого  объекта при  обращении к нему каждого  клиента. Объекты, не учитывающие состояние, не хранят информа цию  о  своем  состоянии в промежутках между вызовами методов. В спецификации COM+ преимущественно используются именно такие  объекты, потому  что  они  упро щают  оптимизацию приложений. Если какой либо  объект вообще  не хранит инфор мации, то  теоретически он  может  быть  дезактивирован средствами COM+ в проме жутках  между обращениями к его  методам  безо  всякого  вреда  для работы приложе ния.  Такая  возможность появилась благодаря тому,  что  в  COM+  клиент работает только  с указателями на внутреннего посредника, а не напрямую  с самим объектом. И это — не просто теория, а фактическая организация работы с объектами в COM+. Всеэкземпляры объектов между вызовами методов уничтожаются для того,  чтобы  осво бодить  ресурсы, выделенные под объекты. При  очередном обращении клиента к объ екту посредник COM+ перехватывает этот  вызов  и автоматически создает  новый эк земпляр объекта. Такой  подход  позволяет значительно повысить масштабируемость системы, потому что в каждый  момент времени будет существовать относительно не много активных экземпляров класса.

При  разработке интерфейсов для работы с объектами, не учитывающими состоя ние,  вероятно, придется уклониться от привычных подходов к проектированию ин терфейсов. В качестве примера рассмотрим типичный интерфейс в стиле COM:

ICheckbook = interface

[‘{2CCF0409-EE29-11D2-AF31-0000861EF0BB}’]

procedure SetAccount(AccountNum: WideString); safecall;

procedure AddActivity(Amount: Integer); safecall;

end;

В приложении такой интерфейс можно использовать следующим образом:

var

CB: ICheckbook;

begin

CB := SomehowGetInstance;

CB.SetAccount(‘12345ABCDE’);      // Открыть текущий счет

CB.AddActivity(-100);             // и снять с него 100$

end;

Проблема в данном  случае заключается в том, что между вызовами методов объект должен  хранить информацию о номере счета,  а следовательно, учитывать свое со стояние. В COM+ для данного интерфейса используется другой  подход,  который за ключается в передаче всей необходимой информации непосредственно в метод  Ad- dActivity(). В этом случае объекту ненужно  учитывать состояния:

procedure AddActivity(AccountNum: WideString; Amount: Integer); safecall;

Текущее  состояние активного объекта еще называют контекстом. Средства COM+ используют контекст каждого  активного объекта для  получения информации о его специфических параметрах (например о состоянии системы безопасности или о транзакции). Сам объект для получения указателя  на интерфейс контекста IOb- jectContext в любой  момент может  вызвать метод  GetObjectContext(). Интер фейс IObjectContext определен в модуле Mtx следующим образом:

IObjectContext = interface(IUnknown) [‘{51372AE0-CAE7-11CF-BE81-00AA00A2FA25}’]

function CreateInstance(const cid, rid: TGUID; out pv): HResult;

stdcall;

procedure SetComplete; safecall; procedure SetAbort; safecall; procedure EnableCommit; safecall; procedure DisableCommit; safecall;

function IsInTransaction: Bool; stdcall;

function IsSecurityEnabled: Bool; stdcall;

function IsCallerInRole(const bstrRole: WideString): Bool;

end;

safecall;Наиболее важными методами в этом интерфейсе являются SetComplete() и Se- tAbort(). При  вызове любого  из них  объект уведомляет средства COM+ о том,  что он больше  не обрабатывает информацию о состоянии. В ответ  на уведомление сред ства COM+ уничтожат данный объект (клиент об этом,  конечно же, ничего знать  не будет) и освободят ресурсы  для других экземпляров. Если объект принимает участие в транзакции, то методы  SetComplete() и SetAbort() также  выполняют соответст венно  завершение транзакции или отказ от нее.

Контроль за временем существования объектов

В программировании COM  существует  правило, согласно которому указатели  на интерфейсы освобождаются сразу же после того, как в них отпадает необходимость. В традиционной спецификации COM этого  правила нужно было  придерживаться, что бы рационально использовать системные ресурсы.  Согласно спецификации COM+ объекты, не  учитывающие состояния,  автоматически  уничтожаются после  вызова ими  метода  SetComplete() или  SetAbort(). Удаление  экземпляра объекта проис ходит  скрытно от клиента, и клиентская часть  приложения не нуждается  ни в каких дополнительных модификациях.

Источник: Тейксейра, Стив, Пачеко, Ксавье.   Borland Delphi 6. Руководство разработчика. : Пер.  с англ. — М. : Издательский дом “Вильямс”, 2002. —  1120 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии