Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
<ul><ul><li>Малышкин Фёдор </li></ul></ul><ul><ul><li>26.10.2007 </li></ul></ul>Распределённые приложения. Часть 1. «Клиен...
Введение <ul><li>В данной серии презентаций будет сделана попытка разъяснить  принципы проектирования и реализации распред...
Как это было... <ul><li>Объединённый код бизнес-логики и представления («клиента»), которые обычно разворачивались на одно...
Преимущества (Как это было...) <ul><li>Сокращённое время реализации </li></ul><ul><li>Сглаживание недочётов проектирования...
Недостатки (Как это было...) <ul><li>Невозможность использования функционала приложения, минуя данного клиента (без реализ...
Недостатки 2 (Как это было...) <ul><li>Сложность связей бизнес-логики внутри приложения </li></ul><ul><li>Сложность входа ...
Разделение <ul><li>Под «Разделением» понимается разделение на логическом и физическом уровне, ранее существовавшего единог...
Возможные варианты разделения
Возможные варианты разделения
Преимущества (Разделение) <ul><li>Готовые части для использования внешними программами, как следствие повышенная интеграци...
Преимущества  2 (Разделение) <ul><li>Защищённость модуля бизнес-логики от изменений в клиенте и наоборот </li></ul><ul><li...
Недостатки (Разделение) <ul><li>БОльший объём работы (создание кода и документации) </li></ul><ul><li>Необходимость тщател...
Замечания к архитектуре и разработке <ul><li>Отсутствие влияния деталей реализации компонентов на протокол взаимодействия ...
Замечания к архитектуре и разработке <ul><li>Серверная компонента должна быть спроектирована и реализованная с учётом возм...
Замечания к архитектуре и разработке <ul><li>Автономность операций - каждая предоставляемая операция, должна быть как можн...
Далее... <ul><li>«Подходы к разработке клиентских приложений» </li></ul><ul><li>«Создание веб-сервисов и клиентов к ним» <...
Вопросы <ul><li>? </li></ul>
Координаты <ul><li>ООО «Магнетософт» </li></ul><ul><li>Телефон: +7 912 864 89 59 </li></ul><ul><li>E-mail :   [email_addre...
Upcoming SlideShare
Loading in …5
×

Распределённые приложения. Часть 1. «Клиент и ядро бизнес-логики»

1,707 views

Published on

Распределённые приложения. Часть 1.
«Клиент и ядро бизнес-логики»

  • Be the first to comment

Распределённые приложения. Часть 1. «Клиент и ядро бизнес-логики»

  1. 1. <ul><ul><li>Малышкин Фёдор </li></ul></ul><ul><ul><li>26.10.2007 </li></ul></ul>Распределённые приложения. Часть 1. «Клиент и ядро бизнес-логики»
  2. 2. Введение <ul><li>В данной серии презентаций будет сделана попытка разъяснить принципы проектирования и реализации распределённых систем. </li></ul><ul><li>В этой презентации будут обсуждаться вопросы разделения клиентской составляющей приложения и её бизнес-логики на отдельные компоненты. </li></ul>
  3. 3. Как это было... <ul><li>Объединённый код бизнес-логики и представления («клиента»), которые обычно разворачивались на одном сервере и представляли собой одно приложение. </li></ul>
  4. 4. Преимущества (Как это было...) <ul><li>Сокращённое время реализации </li></ul><ul><li>Сглаживание недочётов проектирования </li></ul><ul><li>Гибкость в вопросах реализации взаимодействия между внутренними компонентами (на уровне Java вызовов) </li></ul><ul><li>Надёжность взаимодействия между внутренними компонентами </li></ul><ul><li>Высокая скорость внесения изменений и добавления нового функционала </li></ul>
  5. 5. Недостатки (Как это было...) <ul><li>Невозможность использования функционала приложения, минуя данного клиента (без реализации дополнительных «дверей») </li></ul><ul><li>Ограниченные возможности интеграции с другими системами (предоставление функционала) </li></ul><ul><li>Ограниченные возможности распределённой обработки данных </li></ul><ul><li>Минимальная масштабируемость (и как следствие – отказоустойчивость) </li></ul>
  6. 6. Недостатки 2 (Как это было...) <ul><li>Сложность связей бизнес-логики внутри приложения </li></ul><ul><li>Сложность входа в проект новых разработчиков, обязанных принять сложившуюся архитектуру ВСЕГО приложения </li></ul><ul><li>Отсутствие возможности повторного использования на уровне готовых программных комплексов </li></ul><ul><li>Отсутствие стандартного подхода к разработке приложения </li></ul>
  7. 7. Разделение <ul><li>Под «Разделением» понимается разделение на логическом и физическом уровне, ранее существовавшего единого приложения, на компоненты: </li></ul><ul><ul><li>Клиент – приложение, отображающие данные в системе и интерпритирующее пользовательский ввод и передающий его в серверную компоненту. </li></ul></ul><ul><ul><li>Сервер бизнес-логики – компонента, ответственная за управление хранением данных, выдачей данных по запросу, сложной проверкой (связанной со значительными вычислительными ресурсами), синхронизацией с другими системами и прочее... </li></ul></ul>
  8. 8. Возможные варианты разделения
  9. 9. Возможные варианты разделения
  10. 10. Преимущества (Разделение) <ul><li>Готовые части для использования внешними программами, как следствие повышенная интеграция с ними </li></ul><ul><li>Возможность создания других клиентов для приложения (включая другие языки), использование функционала приложения в других приложениях </li></ul><ul><li>Повышенная масштабируемость (несколько клиентов для одного сервера, возможность развёртывания клиента на площадках с плохим пропускным каналом) </li></ul>
  11. 11. Преимущества 2 (Разделение) <ul><li>Защищённость модуля бизнес-логики от изменений в клиенте и наоборот </li></ul><ul><li>Явное разграничение ответственностей программистов при создании приложения </li></ul><ul><li>Более лёгкое тестирование компонентов при таком разграничении ответственности </li></ul><ul><li>Явные связи, форматы обмена и последовательности вызовов между компонентами </li></ul><ul><li>Мощные возможности мониторинга поведения программы (с помощью внутренних инструментов и внешних средств) </li></ul><ul><li>Возможности внедрения промежуточных элементов в взаимодействие компонентов (ESB, адаптеры) </li></ul><ul><li>Лёгкая реализация поднятия защищённых каналов между компонентами </li></ul>
  12. 12. Недостатки (Разделение) <ul><li>БОльший объём работы (создание кода и документации) </li></ul><ul><li>Необходимость тщательной разработки архитектуры приложениях и взаимодействия компонентов </li></ul><ul><li>Дополнительное время на поддержку инфраструктуры взаимодействия между компонентами (дополнительный код для обеспечения взаимодействия) </li></ul><ul><li>Повышенная квалификация, как разработчиков, так и архитекторов приложения </li></ul><ul><li>Дополнительные накладные расходы на обеспечения взаимодействия и коммуникацию между компонентами </li></ul>
  13. 13. Замечания к архитектуре и разработке <ul><li>Отсутствие влияния деталей реализации компонентов на протокол взаимодействия (клиента на сервер/сервера на клиент) </li></ul><ul><li>Протокол взаимодействия основан на предметной области </li></ul><ul><li>Отсутствие в протоколе взаимодействия ссылок на детали реализации (язык, среда выполнения, база данных, операционная система или библиотека) </li></ul><ul><li>Транзакционность операций – при неуспешном выполнении восстанавливается status quo. </li></ul><ul><li>Атомарность операций – не должно быть операций из серии «Сделать12Вещей»: каждая операция должна выполнять 1 определенную ей вещь, деление операций должно быть достаточно мелкозернистым (но не доводить до абсурда конечно). </li></ul>
  14. 14. Замечания к архитектуре и разработке <ul><li>Серверная компонента должна быть спроектирована и реализованная с учётом возможного большого количества клиентов и высокой интенсивности взаимодействия с ним. </li></ul><ul><li>Клиентская компонента должна избегать излишних операций с сервером при отсутствии необходимости в этом: например не запрашивать документы пользователя каждый раз при запросе пользователем их списка – сохранить ранее запрошенные документы и их контрольную сумму и при запросе – сверять с контрольной суммой сервера (запрашивать при разнице сумм). Так же следует поступать и при данных разделяемых всеми пользователями – например со списком подразделений – хранить его в общем ресурсе, доступном все сессиям пользователей, и периодически проверять необходимость обновления данного списка. </li></ul>
  15. 15. Замечания к архитектуре и разработке <ul><li>Автономность операций - каждая предоставляемая операция, должна быть как можно более независима от ранее выполненных операций для данного пользователя: пытаться передавать все необходимые параметры для успешного выполнения операции в рамках одного вызова – возвращать данные так же – в рамках одного вызова. В случае невозможности создания таких операций – вводить явную поддержку пользовательских сессий во взаимодействии между клиентами. </li></ul><ul><li>Жёсткое документирование взаимодействия (операции, форматы обмена сообщений, последовательность вызова операций) </li></ul>
  16. 16. Далее... <ul><li>«Подходы к разработке клиентских приложений» </li></ul><ul><li>«Создание веб-сервисов и клиентов к ним» </li></ul><ul><li>«Подходы к разработке серверных приложений» </li></ul>
  17. 17. Вопросы <ul><li>? </li></ul>
  18. 18. Координаты <ul><li>ООО «Магнетософт» </li></ul><ul><li>Телефон: +7 912 864 89 59 </li></ul><ul><li>E-mail : [email_address] </li></ul><ul><li>Офисы : </li></ul><ul><li>г. Сыктывкар, г. Санкт-Петербург, </li></ul><ul><li>пр. Бумажников, 2 Невский пр., д. 125, к. 2, литер «Б» </li></ul>

×