Spec-Zone .ru
спецификации, руководства, описания, API
|
Темы, обсужденные в этом разделе, включают:
Традиционные приложения для предприятия являются, по большей части, автономными монолитными программами, у которых есть ограниченный доступ к процедурам друг друга и данным. Они являются обычно громоздкими, чтобы создать и дорогой, чтобы поддержать, потому что даже простые изменения требуют, чтобы вся программа была перекомпилирована и повторно протестирована.
В отличие от этого, приложения, созданные, используя распределенные объекты, такие как CORBA естественно, предоставляют себя многоярусной архитектуре, способствуя аккуратному разделению проблем. У трехярусного приложения есть уровень кода пользовательского интерфейса, код вычисления (или бизнес-логика) уровень, и уровень доступа к базе данных. Все взаимодействие между уровнями происходит через интерфейсы, которые должны опубликовать все объекты CORBA. Схема ниже иллюстрирует переход от монолитных приложений до многоярусных, модульных приложений.
Уровень пользовательского интерфейса является уровнем взаимодействия с пользователем. Его фокус находится на эффективном проекте пользовательского интерфейса и доступности всюду по Вашей организации. Уровень пользовательского интерфейса может находиться на рабочем столе пользователя на интранет Вашей организации, или во всемирной паутине (Интернет). Несколько реализаций пользовательского интерфейса могут быть развернуты, которые получают доступ к тому же самому серверу. Уровень UI обычно вызывает методы на уровень бизнес-логики и таким образом действует как клиент серверов бизнес-логики.
Служба, или уровень бизнес-логики, является основанным на сервере кодом, с которым взаимодействует клиентский код. Уровень бизнес-логики составляется из бизнес-объектов - объекты CORBA, которые выполняют логические деловые функции, такие как контроль за состоянием запасов, бюджет, заказы продаж, и тарификация. Эти объекты вызывают методы на объекты уровня Хранилища данных.
Уровень хранилища данных составляется из объектов, которые инкапсулируют подпрограммы базы данных и взаимодействуют непосредственно с продуктом (ами) DBMS. Например, гипотетическое get_Sales_Sum
метод мог бы быть реализован, чтобы получить данные из реляционной базы данных через соответствующий SQL SELECT
операторы.