Для чего бизнес логика выделена как отдельный компонент в клиент серверной архитектуре - Контакты компаний и предприятий на Atlaso.ru

Клиент-сервер с бизнес-логикой на клиенте

Клиентская часть обменивается данными с сервером посредством SQL запросов. Обработка информации в клиент-серверных системах ведется на уровне множества кортежей.

Процесс разработки разделяется на создание БД и написание клиентской части с бизнес-логикой.

Достоинства

Высокая производительность, стабильность и надежность при многопользовательской работе.
Легко организуется защита данных (шифрование сетевого трафика SSH, SSL)
Универсальность языка определения и манипулирования данными

Недостатки

Более высокая цена СУБД. (сервер БД продается отдельно).
Достаточно высокие требования к квалификации разработчиков
Навыки администрирования сервера БД
Повышенные требования к пропускной способности сети
Повышенные требования к клиентским местам (на них выполняется слой бизнес- логики)

Выводы

При количестве пользователей от 2 до ~50 она является хорошим вариантом. С ростом числа пользователей начинает сказываться недостаточная пропускная способность сети.

Клиент-сервер с бизнес-логикой на сервере

Используется возможность современных серверов БД исполнять хранимые SQL процедуры на сервере, куда и переносится максимально возможная часть бизнес-логики. Требования к серверу БД возрастают, однако резко понижаются требования к клиентским машинам (за счет выноса с них бизнес-логики) и к пропускной способности сети (клиенту передаются только данные, необходимые пользователю).

Достоинства

Пониженные, по сравнению с предыдущим классом систем, требования к пропускной способности сети и клиентским местам.
Более простой процесс создания бизнес-логики.

Недостатки

Повышенные требования к серверу БД.(каждый сеанс «съедает» память из расчета предельной загрузки)
Невысокая переносимость (мобильность) системы на другие серверы БД.

Выводы

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

N-уровневая архитектура

Тонкий клиент представляет собой некоторый терминал типа HTML—browser или эмуляторы X-терминала

Вся бизнес- логика оформляется в виде набора приложений, запускаемых на сервере приложений под управлением ОС типа UNIX.

Сервера БД занимаются только проблемами хранения, добавления, модификации и поддержания непротиворечивости данных.

Сервер приложений соединен с сервером БД при помощи отдельного высокоскоростного сегмента сети.

Достоинства

Повышенная защищенность.
Высокая производительность.
Легкость развития и модификации.
Легкость администрирования.
Возможность создания системы с массовым параллелизмом (серверов БД может быть несколько, а сервером приложений могут служить несколько соединенных в кластер компьютеров).

Недостатки

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

Выводы

Единственная альтернатива для создания ИС для очень большого количества пользователей.

Практические занятия

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

Презентация по ER-моделированию

ER нотации

Пример модели в ERwin

Подготовка SQL скриптов генерации схемы отношений БД в ERwin. Разработка скрипта для ввода тестовой информации.

Видео-презентация (Для проигрывания требуется Windows Media Player)

Архитектура MS SQL Server 2005. Настройка и использование основных компонент среды. Создание учебной базы данных.

Видео-презентация (Для проигрывания требуется Windows Media Player)

Работа с СУБД MS SQL Server 2005, ORACLE 10g. Примеры соединений с БД, технологии разработки клиенского приложения

Использование технологии Java Database Connectivity (JDBC) для работы с базами данных

Презентация

Примеры к презентации

SQL-скрипты, проект и исходные коды

package org.mai806.jdbcsample;

import java.sql.*;

public class QuerySample {
    
    public static void main(String[] args) throws Exception {
        
        /* ======== Подключение к MS SQL Server ===== */
        // Загрузка драйвера
        Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
        // Соединение с базой данных
        Connection connection = DriverManager.getConnection(
                "jdbc:sqlserver://localhost:1433;databaseName=o01;", 
                // localhost - сервер СУБД, o01 - имя базы данных
                "sa", "123"); // пользователь, пароль
        
        /* ======== Подключение к Oracle ============
        // Загрузка драйвера
        Class.forName("oracle.jdbc.OracleDriver");
        // Соединение с базой данных
        Connection connection = DriverManager.getConnection(
                        "jdbc:oracle:thin:@localhost:1521:orcl", 
                        // localhost - сервер СУБД, orcl - SID базы оракла
                        "o01", "o01"); // пользователь, пароль         
        
        // Создание Statement
        PreparedStatement stmt = connection.prepareStatement
        ("select ID, NAME from PERSON where NAME like ?");
        stmt.setString(1, "%S%");
        // Выполнение запроса
        ResultSet rs = stmt.executeQuery();
        // Перебор результата выполнения запроса
        while(rs.next()) {
            // Пример выбора параметра по номеру или по имени
            System.out.println("ID: " +
                    rs.getLong(1) + "; NAME="+
                    rs.getString("NAME"));
        }
        
        // закрытие использованных ресурсов БД
        rs.close();
        stmt.close();
        connection.close();
    }
}

Листинг
P.1.
Выполнение запроса: QuerySample.java

package org.mai806.jdbcsample;

import java.sql.*;
import java.util.ResourceBundle;

public class StoredProcedureSample {
    
    private static Connection connection = null;
    public static void main(String[] args) throws Exception {
        // Получение соединения из значений параметров в файле properties
        ResourceBundle properties = ResourceBundle.getBundle("database");
        Class.forName(properties.getString("driver"));
        connection = DriverManager.getConnection(
                properties.getString("url"),
                properties.getString("user"),
                properties.getString("password"));
        
        transferAmount(1,2,100.0);
        connection.close();
    }
    
    /**
     * Переводит указанную сумму с одного счета на другой
     * @param from счет плательщика
     * @param to счет получателя
     * @param amount сумма
     */
    public static void transferAmount(long from, long to, double amount)
    throws Exception {
        // Создание Statement
        CallableStatement stmt
                = connection.prepareCall("{call TransferAmount(?,?,?)}");
        // Установка параметров
        stmt.setLong(1, from);
        stmt.setLong(2, to);
        stmt.setDouble(3, amount);
        // Выполнение процедуры
        stmt.execute(); 
    }
}

Листинг
P.2.
Выполнение хранимой процедуры: StoredProcedureSample.java

package org.mai806.jdbcsample;

import java.sql.*;
import java.util.ResourceBundle;

public class TransactionalSample {
    
    private static Connection connection = null;
    public static void main(String[] args) throws Exception {
        
        // Получение соединения из значений параметров в файле properties
        ResourceBundle properties = ResourceBundle.getBundle("database");
        Class.forName(properties.getString("driver"));
        connection = DriverManager.getConnection(
                properties.getString("url"),
                properties.getString("user"),
                properties.getString("password"));
        
        // Ручное управление транзакциями
        connection.setAutoCommit(false);
        
        try {
            transferAmount(2, 1, 10.0);
        } finally {
            connection.close();
        }
    }
    
    /**
     * Переводит указанную сумму с одного счета на другой
     * @param from счет плательщика
     * @param to счет получателя
     * @param amount сумма
     */
    public static void transferAmount(long from, long to,
            double amount) throws Exception {
        PreparedStatement stmt = null;
        Statement query = null;
        try {
            stmt = connection.prepareStatement
            ("update ACCOUNT set AMOUNT=AMOUNT+? where ID=?");
            // Забираем сумму со счета плательщика
            stmt.setDouble(1, -amount);
            stmt.setLong(2, from);
            stmt.execute();
            
            // Добавляем сумму на счет получателя
            stmt.setDouble(1, amount);
            stmt.setLong(2, to);
            stmt.execute();
            
            // Пост-проверка: отрицательность счета плательщика
            query = connection.createStatement();
            ResultSet rs = query.executeQuery(
                    "select AMOUNT from ACCOUNT where ID="+from+" and AMOUNT<0");
            if (rs.next()) {
                throw new Exception("На счете №"+from+" 
                недосточно средств ["+(amount+rs.getDouble(1))+"] 
                для снятия суммы ["+amount+"]");
            }
            connection.commit();
            System.out.println("Перечисление средств успешно выполнено");
        } catch(Exception e) {
            e.printStackTrace();
            connection.rollback();
        } finally {
            if (stmt!=null)
                stmt.close();
            if (query!=null)
                query.close();
        }
    }
    
}

Листинг
P.3.
Работа с транзакциями: TransactionalSample.java

Работа с базами данных из J2EE Web-контейнера

Презентация

Объектно-реляционное отображения для работы с базами данных

Презентация

Использование препроцессора для работы с API СУБД

Презентация

Источник

Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов.

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

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

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

Рис.1. Компоненты сетевого приложения

Выполнение этих функций в основном обеспечивается программными средствами, которые можно представить в виде взаимосвязанных компонентов (рис. 1), где:

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

Автономная система (компьютер, не подключенный к сети) представляет все эти компоненты как на различных уровнях (ОС, служебное ПО и утилиты, прикладное ПО), так и на уровне приложений (не характерно для современных программ). Так же и сеть — она представляет все эти компоненты, но, в общем случае, распределенные между узлами. Задача сводится к обеспечению сетевого взаимодействия между этими компонентами.

Архитектура «клиент-сервер» определяет общие принципы организации взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых специфичных функций (сервисов) и клиенты, потребители этих функций.

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

Двухзвенная архитектура

В любой сети (даже одноранговой), построенной на современных сетевых технологиях, присутствуют элементы клиент-серверного взаимодействия, чаще всего на основе двухзвенной архитектуры. Двухзвенной (two-tier, 2-tier) она называется из-за необходимости распределения трех базовых компонентов между двумя узлами (клиентом и сервером).

Рис.2. Двухзвенная клиент-серверная архитектура

Двухзвенная архитектура используется в клиент-серверных системах, где сервер отвечает на клиентские запросы напрямую и в полном объеме, при этом используя только собственные ресурсы. Т.е. сервер не вызывает сторонние сетевые приложения и не обращается к сторонним ресурсам для выполнения какой-либо части запроса (рис. 2)

Расположение компонентов на стороне клиента или сервера определяет следующие основные модели их взаимодействия в рамках двухзвенной архитектуры:

сервер терминалов — распределенное представление данных;
файл-сервер — доступ к удаленной базе данных и файловым ресурсам;
сервер БД — удаленное представление данных;
сервер приложений — удаленное приложение.

Перечисленные модели с вариациями представлены на рис. 3.

Рис.3. Модели клиент-серверного взаимодействия

Исторически первой появилась модель распределенного представления данных (модель сервер терминалов). Она реализовывалась на универсальной ЭВМ (мэйнфрейме), выступавшей в роли сервера, с подключенными к ней алфавитно-цифровыми терминалами. Пользователи выполняли ввод данных с клавиатуры терминала, которые затем передавались на мэйнфрейм и там выполнялась их обработка, включая формирование «картинки» с результатами. Эта «картинка» и возвращалась пользователю на экран терминала.

С появлением персональных компьютеров и локальных сетей, была реализована модель файлового сервера, представлявшего доступ файловым ресурсам, в т.ч и к удаленной базе данных. В этом случае выделенный узел сети является файловым сервером, на котором размещены файлы базы данных. На клиентах выполняются приложения, в которых совмещены компонент представления и прикладной компонент (СУБД и прикладная программма), использующие подключенную удаленную базу как локальный файл. Протоколы обмена при этом представляют набор низкоуровневых вызовов операций файловой системы.

Такая модель показала свою неэффективность ввиду того, что при активной работе с таблицами БД возникает большая нагрузка на сеть. Частичным решением является поддержка тиражирования (репликации) таблиц и запросов. В этом случае, например при изменении данных, обновляется не вся таблица, а только модифицированная ее часть.

С появлением специализированных СУБД появилась возможность реализации другой модели доступа к удаленной базе данных — модели сервера баз данных. В этом случае ядро СУБД функционирует на сервере, прикладная программа на клиенте, а протокол обмена обеспечивается с помощью языка SQL. Такой подход по сравнению с файловым сервером ведет к уменьшению загрузки сети и унификации интерфейса «клиент-сервер». Однако, сетевой трафик остается достаточно высоким, кроме того, по прежнему невозможно удовлетворительное администрирование приложений, поскольку в одной программе совмещаются различные функции.

С разработкой и внедрением на уровне серверов баз данных механизма хранимых процедур появилась концепция активного сервера БД. В этом случае часть функций прикладного компонента реализованы в виде хранимых процедур, выполняемых на стороне сервера. Остальная прикладная логика выполняется на клиентской стороне. Протокол взаимодействия — соответствующий диалект языка SQL.

Преимущества такого подхода очевидны:

возможно централизованное администрирование прикладных функций;
снижение стоимости владения системой (TOC, total cost of ownership) за счет аренды сервера, а не его покупки;
значительное снижение сетевого трафика (т.к. передаются не SQL-запросы, а вызовы хранимых процедур).

Основной недостаток — ограниченность средств разработки хранимых процедур по сравнению с языками высокого уровня.

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

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

Трехзвенная архитектура

Рис.4. Трехзвенная клиент-серверная архитектура

Еще одна тенденция в клиент-серверных технологиях связана со все большим использованием распределенных вычислений. Они реализуются на основе модели сервера приложений, где сетевое приложение разделено на две и более частей, каждая из которых может выполняться на отдельном компьютере. Выделенные части приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее согласованном формате. В этом случае двухзвенная клиент-серверная архитектура становится трехзвенной (three-tier, 3-tier).

Как правило, третьим звеном в трехзвенной архитектуре становится сервер приложений, т.е. компоненты распределяются следующим образом (рис. 4):

Представление данных — на стороне клиента.
Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).
Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.

Рис.5. Многозвенная (N-tier) клиент-серверная архитектура

Трехзвенная архитектура может быть расширена до многозвенной (N-tier, Multi-tier) путем выделения дополнительных серверов, каждый из которых будет представлять собственные сервисы и пользоваться услугами прочих серверов разного уровня. Абстрактный пример многозвенной модели приведен на рис. 5.

Сравнение архитектур

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

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

Высокую степень гибкости и масштабируемости.
Высокую безопасность (т.к. защиту можно определить для каждого сервиса или уровня).
Высокую производительность (т.к. задачи распределены между серверами).

Клиент-серверные технологии

Архитектура клиент-сервер применяется в большом числе сетевых технологий, используемых для доступа к различным сетевым сервисам. Кратко рассмотрим некоторые типы таких сервисов (и серверов).

Web-серверы: Изначально представляли доступ к гипертекстовым документам по протоколу HTTP (Huper Text Transfer Protocol). Сейчас поддерживают расширенные возможности, в частности работу с бинарными файлами (изображения, мультимедиа и т.п.).
Серверы приложений: Предназначены для централизованного решения прикладных задач в некоторой предметной области. Для этого пользователи имеют право запускать серверные программы на исполнение. Использование серверов приложений позволяет снизить требования к конфигурации клиентов и упрощает общее управление сетью.
Серверы баз данных: Серверы баз данных используются для обработки пользовательских запросов на языке SQL. При этом СУБД находится на сервере, к которому и подключаются клиентские приложения.
Файл-серверы: Файл-сервер хранит информацию в виде файлов и представляет пользователям доступ к ней. Как правило файл-сервер обеспечивает и определенный уровень защиты от несакционированного доступа.
Прокси-сервер: Во-первых, действует как посредник, помогая пользователям получить информацию из Интернета и при этом обеспечивая защиту сети.; Во-вторых, сохраняет часто запрашиваемую информацию в кэш-памяти на локальном диске, быстро доставляя ее пользователям без повторного обращения к Интернету.
Файрволы (брандмауэры): Межсетевые экраны, анализирующие и фильтрующие проходящий сетевой трафик, с целью обеспечения безопасности сети.
Почтовые серверы: Представляют услуги по отправке и получению электронных почтовых сообщений.
Серверы удаленного доступа (RAS): Эти системы обеспечивают связь с сетью по коммутируемым линиям. Удаленный сотрудник может использовать ресурсы корпоративной ЛВС, подключившись к ней с помощью обычного модема.

Это лишь несколько типов из всего многообразия клиент-серверных технологий, используемых как в локальных, так и в глобальных сетях.

Для доступа к тем или иным сетевам сервисам используются клиенты, возможности которых характеризуются понятием «толщины». Оно определяет конфигурацию оборудования и программное обеспечение, имеющиеся у клиента. Рассмотрим возможные граничные значения:

«Тонкий» клиент: Этот термин определяет клиента, вычислительных ресурсов которого достаточно лишь для запуска необходимого сетевого приложения через web-интерфейс. Пользовательский интерфейс такого приложения формируется средствами статического HTML (выполнение JavaScript не предусматривается), вся прикладная логика выполняется на сервере.
Для работы тонкого клиента достаточно лишь обеспечить возможность запуска web-браузера, в окне которого и осуществляются все действия. По этой причине web-браузер часто называют «универсальным клиентом».
«Толстый» клиент: Таковым является рабочая станция или персональный компьютер, работающие под управлением собственной дисковой операционной системы и имеющие необходимый набор программного обеспечения. К сетевым серверам «толстые» клиенты обращаются в основном за дополнительными услугами (например, доступ к web-серверу или корпоративной базе данных).
Так же под «толстым» клиентом подразумевается и клиентское сетевое приложение, запущенное под управлением локальной ОС. Такое приложение совмещает компонент представления данных (графический пользовательский интерфейс ОС) и прикладной компонент (вычислительные мощности клиентского компьютера).

В последнее время все чаще используется еще один термин: «rich»-client. «Rich«-клиент своего рода компромисс между «толстым» и «тонким» клиентом. Как и «тонкий» клиент, «rich»-клиент также представляет графический интерфейс, описываемый уже средствами XML и включающий некоторую функциональность толстых клиентов (например интерфейс drag-and-drop, вкладки, множественные окна, выпадающие меню и т.п.)

Прикладная логика «rich»-клиента также реализована на сервере. Данные отправляются в стандартном формате обмена, на основе того же XML (протоколы SOAP, XML-RPC) и интерпретируются клиентом.

Некоторые основные протоколы «rich»-клиентов на базе XML приведены ниже:

XAML (eXtensible Application Markup Language) — разработан Microsoft, используется в приложениях на платформе .NET;
XUL (XML User Interface Language) — стандарт, разработанный в рамках проекта Mozilla, используется, например, в почтовом клиенте Mozilla Thunderbird или браузере Mozilla Firefox;
Flex — мультимедийная технология на основе XML, разработанная Macromedia/Adobe.

Заключение

Итак, основная идея архитектуры «клиент-сервер» состоит в разделении сетевого приложения на несколько компонентов, каждый из которых реализует специфический набор сервисов. Компоненты такого приложения могут выполняться на разных компьютерах, выполняя серверные и/или клиентские функции. Это позволяет повысить надежность, безопасность и производительность сетевых приложений и сети в целом.

Контрольные вопросы

В чем заключается основная идея К-С взаимодействия?
В чем отличия между понятиями «клиент-серверная архитектура» и «клиент-серверная технология»?
Перечислите компоненты К-С взаимодействия.
Какие задачи выполняет компонент представления в К-С архитектуре?
С какой целью средства доступа к БД представлены в виде отдельного компонента в К-С архитектуре?
Для чего бизнес-логика выделена как отдельный компонент в К-С архитектуре?
Перечислите модели клиент-серверного взаимодействия.
Опишите модель «файл-сервер».
Опишите модель «сервер БД».
Опишите модель «сервер приложений»
Опишите модель «сервер терминалов»
Перечислите основные типы серверов.

CC-BY-CA Анатольев А.Г., 31.01.2012

Источник

Клиент-сервер с бизнес-логикой на клиенте

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

Клиентская
часть обменивается данными с сервером
посредством SQLзапросов.
Обработка информации в клиент-серверных
системах ведется на уровне множества кортежей.

Процесс разработки разделяется
на создание БД и
написание клиентской части с бизнес-логикой.

Достоинства

Высокая производительность, стабильность и надежность при
многопользовательской работе.
Легко
организуется защита
данных (шифрование сетевого
трафика SSH,SSL)
Универсальность языка
определения и манипулирования данными

Недостатки

Более
высокая цена СУБД.
(сервер БД продается
отдельно).
Достаточно
высокие требования к квалификации
разработчиков
Навыки администрирования сервера БД
Повышенные
требования к пропускной
способности сети
Повышенные
требования к клиентским местам (на них
выполняется слой бизнес- логики)

Выводы

При
количестве пользователей от 2 до ~50 она
является хорошим вариантом. С ростом
числа пользователей начинает сказываться
недостаточная пропускная
способность сети.

Клиент-сервер с бизнес-логикой на сервере

Используется
возможность современных серверов БД исполнять
хранимые SQL процедуры
на сервере, куда и переносится максимально
возможная часть бизнес-логики. Требования
к серверу БД возрастают,
однако резко понижаются требования к
клиентским машинам (за счет выноса с
них бизнес-логики) и к пропускной
способностисети (клиенту
передаются только данные, необходимые
пользователю).

Достоинства

Пониженные,
по сравнению с предыдущим классом систем,
требования к пропускной
способности сети и
клиентским местам.
Более
простой процесс создания бизнес-логики.

Недостатки

Повышенные
требования к серверу БД.(каждый сеанс «съедает» память из
расчета предельной загрузки)
Невысокая переносимость (мобильность)
системы на другие серверы БД.

Выводы

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

N-уровневая
архитектура

Основными
элементами являются сервера БД,
сервер(кластер) приложений и
клиентская часть. Главная идея n-уровневой
архитектуры заключается в максимальном
упрощении клиента (тонкий клиент)
, выносе всей бизнес-логики с клиента и
сервера БД.

Тонкий клиент представляет
собой некоторый терминал типа HTML—browser или
эмуляторы X-терминала

Вся
бизнес- логика оформляется в виде набора
приложений, запускаемых на сервере
приложений под управлением ОС типа
UNIX.

Сервера БД занимаются
только проблемами хранения, добавления,
модификации и поддержаниянепротиворечивости данных.

Сервер
приложений соединен
с сервером БД при
помощи отдельного высокоскоростного сегмента сети.

Достоинства

Повышенная
защищенность.
Высокая производительность.
Легкость
развития и модификации.
Легкость администрирования.
Возможность
создания системы с
массовым параллелизмом (серверов БД может
быть несколько, а сервером приложений
могут служить несколько соединенных
в кластер компьютеров).

Недостатки

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

Выводы

Единственная альтернатива для
создания ИС для очень большого количества
пользователей.

5.
Лекция: Базовые объектные архитектуры
распределенных систем. Технологии .NET,
(D)COM+, CORBA, EJB

Соседние файлы в папке РСБДтЗ

#
#
#
05.03.2016269.82 Кб22Методичка РБД курсач.doc

Источник

Файл-сервер (или клиент )

Все три слоя образуют единый программный модуль

Пользоват. Интерфейс и бизнес-логика образуют единый модуль. Данные хранятся на сервере БД

Все слои исполняются на разных машинах.

Файл-сервер

Достоинства

Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры.

Логическая модель РБД

Логическая модель РБД строится на 3-х уровнях (слоях) абстракции данных: представления информации, обработки(бизнес- логики) и хранения. Слои образуют строгую иерархию: слой бизнес -логики взаимодействует со слоями хранения и представления. Физически, слои могут входить в состав одного программного модуля, или же распределяться на нескольких параллельных процессах в одном или нескольких узлах сети.

Слой представления информации
Обеспечивает интерфейс с пользователем. Как правило, получение информации от пользователя происходит посредством различных форм. А выдача результатов запросов — посредством отчетов.
Слой бизнес-логики
Связующий, именно он определяет функциональность и работоспособность системы в целом. Блоки программного кода распределены по сети и могут использоваться многократно (CORBA, DCOM) для создания сложных распределенных приложений.
Слой хранения данных
Обеспечивает физическое хранение, добавление, модификацию и выборку данных. На данный слой также возлагается проверка целостности и непротиворечивости данных, а также реализацию разделенных транзакций.

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

Слой Тип архитектуры	Файл-сервер	Клиент-сервер (Бизнес-логика на клиенте)	Клиент-сервер (бизнес-логика на сервере)	N-уровневая архитектура
Представления	Клиент	Клиент	Клиент	Клиент
Бизнес- логики	Клиент	Клиент	Сервер БД	Сервер приложений (комп. кластер)
Хранения	Файл- сервер (или клиент)	Сервер БД	Сервер БД	Сервер БД
	Все три слоя образуют единый программный модуль	Пользоват. Интерфейс и бизнес-логика образуют единый модуль. Данные хранятся на сервере БД	Вся бизнес логика реализована в виде хранимых процедур, исполняемых на сервере БД	Все слои исполняются на разных машинах.

Файл-сервер

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

Достоинства

Простота логики.
Низкие требования к аппаратному обеспечению и малый объем требуемой памяти.
Не требуют надежных многозадачных и многопользовательских ОС.
Невысокая цена СУБД.

Недостатки

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

Выводы
Файл-серверная архитектура является достаточно привлекательной альтернативой для создания однопользовательских ИС со слабыми требованиями к защите данных.

Клиент-сервер с бизнес-логикой на клиенте

В данных системах хранение, выборка и поддержание непротиворечивости данных возлагается на сервер БД, а вся бизнес-логика и логика представления исполняются на клиентских машинах. Так как все операции по манипулированию данными осуществляются только через сервер, производительность и сохранность данных зависит только от сервера БД. Серверы БД изначально рассчитаны на многопользовательский режим работы, имеют эффективные алгоритмы кеширования данных. Современные серверы имеют хорошую масштабируемость.
Клиентская часть обменивается данными с сервером посредством SQL запросов. Обработка информации в клинт-серверных системах ведется на уровне множества кортежей.
Процесс разработки разделяется на создание БД и написание клиентской части с бизнес-логикой.

Достоинства

Высокая производительность, стабильность и надежность при многопользовательской работе.
Легко организуется защита данных (шифрование сетевого трафика SSH, SSL )
Универсальность языка определения и манипулирования данными

Недостатки

Более высокая цена СУБД. (сервер БД продается отдельно).
Достаточно высокие требования к квалификации разработчиков
Навыки администрирования сервера БД
Повышенные требования к пропускной способности сети
Повышенные требования к клиентским местам (на них выполняется слой бизнес- логики)

Выводы
При количестве пользователей от 2 до ~50 она является хорошим вариантом. С ростом числа пользователей начинает сказываться недостаточная пропускная способность сети.

Клиент-сервер с бизнес-логикой на сервере.

Достоинства

Пониженные, по сравнению с предыдущим классом систем, требования к пропускной способности сети и клиентским местам.
Более простой процесс создания бизнес-логики.

Недостатки

Повышенные требования к серверу БД.(каждый сеанс «съедает» память из расчета предельной загрузки)
Невысокая переносимость ( мобильность) системы на другие серверы БД.

Выводы
По сравнению с предыдущими классами, позволяет держать большую нагрузку.

N-уровневая архитектура

Основными элементами являются сервера БД, сервер(кластер) приложений и клиентская часть. Главная идея n-уровневой архитектуры заключается в максимальном упрощении клиента (тонкий клиент) , выносе всей бизнес-логики с клиента и сервера БД.
Тонкий клиент представляет собой некоторый терминал типа HTML-browser или эмуляторы X-терминала
Вся бизнес- логика оформляется в виде набора приложений, запускаемых на сервере приложений под управлением ОС типа UNIX.
Сервера БД занимаются только проблемами хранения, добавления, модификации и поддержания непротиворечивости данных.
Сервер приложений соединен с сервером БД при помощи отдельного высокоскоростного сегмента сети.

Достоинства

Повышенная защищенность.
Высокая производительность.
Легкость развития и модификации.
Легкость администрирования.
Возможность создания системы с массовым параллелизмом (серверов БД может быть несколько, а сервером приложений могут служить несколько соединенных в кластер компьютеров).

Недостатки

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

Выводы
Единственная альтернатива для создания ИС для очень большого количества пользователей.

Источник

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

По бизнес-логике приюта для животных, предположим, котика, которого за неделю не забрали новые хозяева, надо усыпить. А до этого его надо кормить, поить и спать укладывать.

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

При этом все структуры данных, алгоритмы и т.д. — в двух программах практически одинаковы. Кроме вот этой маленькой детали.

«ЭТОТ один ИФЧИК решил СУДЬБУ КОТЕЙКИ», или, например «начинающий программист УБИЛ младенца ВЕКТОРОМ»

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

Не важно, бизнес это, расчет конфигурации молекул, приют или управление кораблем. Бизнес-логика — это та самая часть, которая в итоге должна работать правильно и надежно, та, результатов которой ждет заказчик (котенок, ребенок)

Если не отделять, допустим интерфейс от бизнес-логики, то вместо нажатия кнопки «отдать ребенка новым родителям» или «усыпить котенка», на двух аккуратных — почти похожих — пультах управления (интерфейсах) вы будете бегать туда-сюда, пытаясь понять, кого утопить, кого усыпить, кого отдать новым родителям и почему ничего не работает.

Вы не отделили интерфейс (панель управления для запуска котят на луну) от бизнес-логики и все запуталось.

Ну, я предупреждал.

Используете вы синглтоны, очереди, базы данных, флэт-файлы, микросервисы — не важно — важно, чтобы бизнес-логика работала правильно.

Под правильно подразумевается корректность результатов в приемлемое время. Все остальное ваших заказчиков не интересует. До тех пор, пока они не являются вашими владельцами.

Именно поэтому вы можете продавать очень плохой — с точки зрения программиста — софт клиентам, но с трудом сможете построить на нем надежную систему. Требования бизнес-логики может быть и выполняются, но поддерживать этот код невозможно

P.S. Маленький исторический экскурс.
Бизнес-логикой это называется потому, что в Нормальном Мире, во Внешней Империи, программирование в коммерции и корпорациях развивалось еще с 50х-60х годов: банки, страховые агентства, туроператоры, медицина.

Т.е. тебе платили за то, чтобы ты внедрил требования конкретного бизнеса

Хорошо, что это бизнес-логика, а не партийная логика, как в Северной Корее.

Источник

Клиент-сервер с бизнес-логикой на клиенте

Клиент-сервер с бизнес-логикой на сервере

N-уровневая архитектура

Практические занятия

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

Подготовка SQL скриптов генерации схемы отношений БД в ERwin. Разработка скрипта для ввода тестовой информации.

Архитектура MS SQL Server 2005. Настройка и использование основных компонент среды. Создание учебной базы данных.

Работа с СУБД MS SQL Server 2005, ORACLE 10g. Примеры соединений с БД, технологии разработки клиенского приложения

Использование технологии Java Database Connectivity (JDBC) для работы с базами данных

Работа с базами данных из J2EE Web-контейнера

Объектно-реляционное отображения для работы с базами данных

Использование препроцессора для работы с API СУБД

Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов.

Двухзвенная архитектура

Трехзвенная архитектура

Сравнение архитектур

Клиент-серверные технологии

Заключение

Контрольные вопросы

Клиент-сервер с бизнес-логикой на клиенте

Клиент-сервер с бизнес-логикой на сервере

Файл-сервер

Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры

Клиент-сервер с бизнес-логикой на клиенте

Клиент-сервер с бизнес-логикой на сервере

N-уровневая архитектура

Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры

Клиент-сервер с бизнес-логикой на клиенте

Клиент-сервер с бизнес-логикой на сервере

N-уровневая архитектура

Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры

Клиент-сервер с бизнес-логикой на клиенте

Клиент-сервер с бизнес-логикой на сервере

N-уровневая архитектура

Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры

Клиент-сервер с бизнес-логикой на клиенте

Клиент-сервер с бизнес-логикой на сервере

N-уровневая архитектура

Вам также понравится

Логическая модель РБД

Файл-сервер

Клиент-сервер с бизнес-логикой на клиенте

Клиент-сервер с бизнес-логикой на сервере.

N-уровневая архитектура

Другие крутые статьи на нашем сайте: