2 Выбор метода решения задачи

Вид материала

Документы

Содержание Уровень прикладной и принятия решения Уровень доступа к данным Сервер бизнес-логики

Подобный материал:

• Программирование, 94.79kb.
• Методические указания к лабораторной работе, 84.19kb.
• Задачи амбулаторной хирургической службы. Принципы организации хирургии «одного дня»., 128.57kb.
• Вдокладе представлен сравнительный анализ метода конечных объёмов и метода Галёркина, 27.76kb.
• Задачи профиля: формирование теоретических знаний о теории и методологии по основам, 29.92kb.
• Задачи и их решение Стандартные и нестандартные задачи Задачи «на работу» Задачи «на, 157.13kb.
• Суть метода координат, 16.15kb.
• Минимизация функций  многих переменных, 731.7kb.
• Г. А. Нестационарные задачи термоупругости слоистых композитых конструкций, 87.81kb.
• Задачи: познакомить педагогов с опытом работы по использованию метода продуктивного, 61.96kb.

2 Выбор метода решения задачи

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

Сегодня разработчикам приходится сталкиваться не только с задачами реализации адекватных техническим требованиям функциональности и пользовательского интерфейса, но и с оптимизацией обмена данными между различными компонентами системы. Учитывая, что корпоративные системы обладают достаточно высоким уровнем сложности, в процессе их эксплуатации возникает ряд вопросов, связанных с надежностью и управляемостью такой системы. Появление такого рода акцентов в процессе проектирования и разработки корпоративных систем приводит к необходимости решения следующей важной задачи — выделения из клиентской и серверной части системы компонентов, несущих на себе строго определенную служебную функциональность [18].

Обычно выделяют следующие уровни (рис 2.1):

• презентационная логика (Presentation Layer - PL), включающая уровень представления;
  
• бизнес-логика (Business Layer - BL), включающая уровень прикладной и принятия решения;
  
• логика доступа к ресурсам (Access Layer - AL).
  

Рисунок 2.1 — Уровни приложений


Уровень представления отвечает за обеспечение интерфейса системы.

Уровень прикладной и принятия решения реализуют правила и процедуры в форме решений в трех обширных категориях:

• формальные решения подразумевают точные запросы на проверку полномочий. Лежит ли эта транзакция в пределах кредита, отведенного клиенту? Может ли заказ быть отправлен в четверг? В этих случаях процесс на уровне бизнес – логики принимает определенное решение или отвечает на поставленный вопрос;
  
• решения по проведению политики подразумеваются и являются безоговорочными. Например:
  

• информацию о клиентах, которые имеют неоплаченные счета, нельзя удалять из БД;
  
• менеджеры не могут санкционировать выплаты, превышающие их полномочия;
  

• Решения по координации и управлению ресурсами также подразумеваются и являются безоговорочными. Вот несколько примеров, составляющие слой бизнес – логики:
  

• принимать заказы только при наличии необходимой продукции на складе;
  
• прекращать регистрацию на семинар, когда не осталось свободных мест;
  
• управлять расписанием поставок в целях оптимизации времени доставки.
  

Уровень доступа к данным отвечает за поддержание согласованности и защищенности информации, одновременно обеспечивая хорошую производительность.

Таким образом, можно прийти к нескольким моделям клиент-серверного взаимодействия:

1. "Толстый" клиент. Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении PL и BL уровней. Серверная часть, при описанном подходе, представляет собой сервер баз данных, реализующий AL. К описанной модели часто применяют аббревиатуру RDA - Remote Data Access.
   

В этой системе клиент-сервер для запуска приложений необходимо, чтобы клиентское ПО было заранее установлено.

2. "Тонкий" клиент. Модель, начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, а сервер объединяет BL и AL.
   

В архитектуре с “тонким” клиентом специализированное программное обеспечение не обязательно устанавливать на клиенте, поскольку исполняемые компоненты могут загружаться с Web-сайта для последующего взаимодействия с клиентом. Таким образом, “тонкий” клиент получает два ключевых преимущества при работе в сети: универсальный доступ и уменьшение затрат на инсталляцию и управление. Однако, из-за наличия браузеров и HTML, тонким клиентам для динамического управления бизнес-приложениями необходимо использование дополнительных средств, таких как Java-апплеты и элементы управления ActiveX.

3. Сервер бизнес-логики. Модель с физически выделенным в отдельное приложение блоком BL.
   

Жесткость связей в схеме взаимодействия уровней системы часто определяется отсутствием (или наличием) транспортного или сетевого уровня (Transport Layer - TL), обеспечивающего обмен информацией между различными компонентами.

С точки зрения применения описанных моделей, при проектировании прикладных систем разработчик часто сталкивается с правилом 20/80 [21]. Суть этого правила заключается в том, что 80% пользователей обращаются к 20% функциональности, заложенной в систему. Оставшиеся 20% задействуют основную бизнес-логику — 80%. В первую группу пользователей попадают операторы информационных систем (ввод и редактирование информации), а также рядовые сотрудники и менеджеры, обращающиеся к поисковым и справочным механизмам (поиск и чтение данных). Во вторую группу пользователей попадают эксперты, аналитики и менеджеры управляющего звена, которым требуются как специфические возможности отбора информации, так и развитые средства ее анализа и представления.

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

Любая прикладная система, вне зависимости от выбранной модели взаимодействия, требует такой инструментарий, который бы смог существенно ускорить сам процесс создания системы и, одновременно с этим, обеспечить прозрачность и наращиваемость кода. На фоне разработки и внедрения систем корпоративного масштаба явно присутствует тенденция использования объектно-ориентированных компонентных средств разработки [16]. Соответственно, полноценное применение объектов в распределенной клиент-серверной среде требует и распределенного объектно-ориентированного взаимодействия, то есть возможности обращения к удаленным объектам.

При построении реальных систем корпоративного масштаба уже мало обходиться их разделением на три базовых фрагмента PL, BL и AL. Так как бизнес-логика является блоком, наиболее емким и специфичным для каждого проекта, именно ее приходится разделять на более мелкие составляющие. Такими составляющими могут быть, например, функциональные компоненты обработки транзакций (Transaction Process Monitoring), обеспечения безопасности (Security), отбора и анализа данных в процессе принятия решений (Decision Support), асинхронного уведомления о событиях (Event Alerts), тиражирования данных (Replication), почтового обмена (Mailing) и др. Вследствие наличия такого огромного количества функций, закладываемых в блоки поддержки бизнес-логики, появляется понятие сервера приложений (Application Server - AS). Причем сервер приложений не просто является неким единым универсальным средним BL-звеном между клиентской и серверной частью системы, но существует во множественном варианте, как частично изолированные приложения, выполняющие специальные функции, обладающие открытыми интерфейсами управления и поддерживающие стандарты объектного взаимодействия. Проникновение информационных технологий в сферу бизнеса в качестве неотъемлемого условия успешного управления приводит к тому, что системы корпоративных масштабов требуют сочетания различных клиент-серверных моделей в зависимости от задач, решаемых на различных направлениях деятельности предприятия. Вспомнив о правиле 20/80, можно придти к выводу, что наиболее оптимальным выбором, с точки зрения управляемости и надежности системы, является сочетание различных моделей взаимодействия клиентской и серверной части. По сути, мы приходим даже не к трехуровневой, а многоуровневой (N-tier) модели, объединяющей различных по "толщине" клиентов, серверы баз данных и множество специализированных серверов приложений, взаимодействующих на базе открытых объектных стандартов. Существенным облегчением в реализации многоуровневых гетерогенных систем является активная работа ряда производителей программного обеспечения, направленная на создание переходного ПО. В отличие от продуктов middleware, обеспечивающих верхний транспортный уровень (универсальные интерфейсы доступа к данным ODBC, JDBC, BDE; Message Oriented Middleware — MOM; Оbject Request Broker — ORB), переходное ПО отвечает за трансляцию вызовов в рамках одного стандарта обмена в вызовы другого —- мосты ODBC/JDBC и BDE/ODBC, COM/CORBA, Java/ActiveX и т. п.

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