Remkomplekty.ru

IT Новости из мира ПК
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Архитектура мобильного клиент серверного приложения

Лекция 1. Введение в архитектуру клиент-серверных андроид-приложений. Часть 1

Представляем курс по архитектуре клиент-серверных андроид-приложений на основе материалов курса Артура Василова, который проходил на Google Developers Group 2016 в Казани.

Чтобы на практике познакомиться с архитектурой клиент-серверных приложений, записывайтесь на продвинутый курс по разработке приложения «Чат-мессенжер»

Введение в архитектуру android приложений

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

И этот вопрос логичен. Во-первых, пользователю совсем-совсем безразлична архитектура вашего приложения. Серьезно, кто из вас при использовании программ и приложений часто задумывается о том, сделали его по MVP или MVC? Ответ – никто. Во-вторых, работа с архитектурой требует дополнительных усилий: ее нужно создавать, в нее нужно вникать и учить людей работать по ней. Но чтобы создать более четкую картину для ответа на этот вопрос, нужно вернуться в относительно недалекое прошлое, а именно в 2007 и 2008 года, когда были выпущены соответственно первые версии устройств под iOS и Android.

Нужно признать, что Google успел отстать от Apple в плане выхода на мобильный рынок и это привело к некоторым последствиям, а именно к спешке при выходе первой версии Android. Нет ничего удивительного в том, что Google стремился в первую очередь доделать основные пользовательские функции, а забота об удобстве разработчиков была вторым приоритетом. Поэтому вместе с первой версией Android Google не предоставил разработчикам каких-то стандартных рекомендаций ни по разработке, ни по дизайну и UX. Что привело к тому, что каждый разработчик или каждая компания были вынуждены писать как хотели и как умели.

Конечно, нужно признать, что в дальнейшем Google проделал огромную работу по популяризации системы Android среди разработчиков. Но при этом изначальные проблемы так и не были до конца решены.

Какие же это проблемы? В плане дизайна понятно, что абсолютно разные стили приложений смущают пользователя системы Android, и ему бывает тяжело ориентироваться. Но что не так с отсутствием стандартов в самом коде? Ведь как было сказано чуть выше, пользователь никак не может знать, насколько хорош код вашего приложения, и это не влияет на его использование. Проблема заключается в том, что не все разработчики хорошо владеют паттернами проектирования и умеют разрабатывать хорошую архитектуру приложений. Если же не следовать четким принципам в архитектуре вы очень скоро получите код, который:

  • Невозможно поддерживать. В коде будет много сложной логики, она не будет расположена в строго определенных классах, будет непонятно, как работает та или иная часть вашего приложения. Из этого следует, что при добавлении нового функционала вам придется либо долго и усиленно разбираться в написанном коде, рефакторить его и делать все правильно, либо сделать задачу кое-как, то есть, образно говоря, через костыли. В связи с тем, что не все разработчики понимают необходимость рефакторинга и умеют убеждать в этой необходимости руководство, и не каждый руководитель согласится отсрочить выход новой версии и понести дополнительные траты из-за рефакторинга, намного чаще выбирается второй вариант. Это часто приводит к ужасающим последствиям. Лично мне не раз приходилось видеть огромные приложения, состоящие из трех файлов Activity. Разумеется, каждая из этих Activity состояла из тысяч, а то и из десятков тысяч строк, что делало их абсолютно невозможными для чтения. Более того, каждый новый функционал, реализованный через костыли, является причиной дополнительных багов и крашей.
  • Невозможно протестировать. Эта проблема плавно вытекает из первой. Вы не сможете писать модульные тесты, если все приложение – это один большой модуль. Более того, в силу особенностей написания тестов для Android-приложений на JVM, при большом количестве зависимостей от классов Android в тестируемых классах, вы не сможете писать тесты. А отсуствие тестов:
    1. Дает вам гораздо меньше уверенности в том, что ваш код работает правильно.
    2. Вы не сможете быстро проверить, что добавленные изменения не сломают работу остальных частей вашего приложения.

Такая ситуация продолжалась достаточно долго. Приложения под Android продолжались писаться в разных стилях с абсолютно разными подходами в дизайне и в архитектуре. Кто-то брал дизайн из системы iOS, а паттерны проектирования из Web-разработки (в частности, попытки использовать MVC в Android обязаны своему существованию именно Web-разработчикам, перешедшим в Android). И сложно сказать, почему не было никаких попыток исправить эту ситуацию, Android – это очень молодая система, и к моменту ее выхода все паттерны проектирования и архитектурные паттерны уже были широко известны.

В общем, все шло своим чередом до 2014 года, когда случилось сразу два важнейших события. Первое хорошо известно всем – это презентация концепции Material Design на Google I/O. Можно по-разному относиться к этой концепции, кто-то считает ее неудачной, кто-то говорит, что таким образом Google ограничивает свободу разработчиков в выборе дизайна. Но то, что появление этой концепции сильно улучшило ситуацию в среднем, – это бесспорно.

Понятно, что за конференцией Google I/O следят все и что Google приложил немало усилий в популяризации философии Material Design, так что Material Design был обречен на использование всеми. А вот другое знаковое событие произошло куда с меньшей популярностью, так как это была всего лишь статья. Это статья “Architecting Android… The clean way?” от Fernando Cejas. По сути эти всего лишь адаптация принципов Clean Architecture от “дядюшки Боба” (Роберта Мартина) для использования в Android. Эта статья дала огромный толчок (а вполне возможно, что это просто совпадение и статья вышла в тот момент, когда разработчики уже были готовы искать лучшие решения) в развитии архитектуры приложений.

Если говорить кратко (а подробнее мы посмотрим дальше по курсу), то хорошая архитектура должна позволять писать тесты для классов, содержащих бизнес-логику и должна строить модули приложения независимыми от почти всех внешних элементов. А если говорить еще проще, то ваш код должен быть тестируемым и его должно быть легко применять и приятно читать. Качество кода приложения можно даже замерить стандартной единицей измерения – количество WTF в минуту (из книги Роберта Мартина “Clean Code”).

Теперь мы можем примерно представить, что от нас требуется при построении архитектуры приложения и можем перейти непосредственно к рассмотрению всех тем!

Основные задачи при разработке клиент-серверных приложений

Так в чем же заключается сложность создания клиент-серверных Android-приложений, которые бы удовлетворяли всем принципам, которые были описаны ранее? Есть 2 крупные проблемы, каждую из которых на самом деле можно разбить еще на большее число проблем:

  • Реализация клиент-серверного взаимодействия. Казалось бы, в чем здесь проблема? Мы все умеем выполнять запросы к серверу с использованием различных средств, обрабатывать результат и показывать его пользователю. И да, и нет. Здесь существует масса факторов. Во-первых, нужно уметь корректно обрабатывать ошибки, которые могут быть самыми разными: от отсутствия интернета и неправильных параметров в запросе, до не отвечающего сервера и ошибках в ответе. Во-вторых, в вашем приложении может быть не один запрос, а много, и вполне возможна ситуация, что вам придется комбинировать результаты этих запросов сложным образом: выполнять их параллельно, использовать результат предыдущего запроса для выполнения следующего и так далее. В-третьих, и это самое неприятное – запросы могут занимать значительное время, а пользователь часто не самый терпеливый и тихий человек – он может крутить устройство (и тогда вы потеряете текущие данные в Activity), а может и вовсе закрыть приложение, и тогда вы можете получить рассинхронизацию в данных (когда на сервере данные обновились, а приложение не знает об этом и отображает некорректную или устаревшую информацию). И все это нужно каким-то образом решать.
  • Обеспечение возможности тестирования классов, содержащих бизнес-логику приложения. Это также подразумевает под собой немало внутренних проблем. Во-первых, нужно обеспечить модульность классов. Это следует из самой сути и из самого названия Unit-тестов. Чтобы обеспечить модульность, нужно разделять классы по логическим слоям для каждого экрана. То есть вместо того, чтобы писать весь код, относящийся к одному экрану, в одной активити, нужно грамотно разделить его на несколько классов, каждый из которых будет иметь свою зону ответственности. Во-вторых, если говорить о тестах с помощью JUnit, то нужно понимать, что тестируемые таким образом классы должны содержать минимальное количество зависимостей от Android-классов, так как Java и ее виртуальная машина об этих классах не знает ничего (подробнее этот момент будет описан в лекции про тестирование). В-третьих, самая сложная логика приложения почти всегда связана с работой с данными от сервера. Мы должны протестировать различные возможные ситуации, такие как ожидаемый ответ сервера, ошибка сервера и разные ответы, приводящие к разному поведению приложения. Но при выполнении теста мы не можем по своему желанию “уронить” сервер или заставить его отдать нужные нам данные. К тому же, серверные запросы выполняются долго и асинхронно, а тесты должны работать последовательно. Все эти проблемы можно решить, если подменять реализацию сервера на определенном слое, к которому будут обращаться тестируемые классы. Все это также будет рассмотрено далее.

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

Читать еще:  Ошибка формата потока данных

Сердце вашего проекта в надежных руках

Разработка серверной части приложения

Введение

Присутствие в интернете стало необходимостью для современных компаний. Без этого невозможно выстроить полноценного взаимодействия с клиентами. Часто для решения подобной задачи прибегают к созданию клиент-серверных приложений. Каждое из них состоит из клиентской части и Back-end. Под последним термином подразумевается серверная часть приложения. Если в дальнейшем нужно самостоятельно изменять контент мобильной программы, то Back-end должен быть создан особенно качественно. Компания Appomart гарантирует выполнение поставленных задач в соответствии предъявляемым требованиям. Поэтому, заказывая создание серверных приложений, можете быть уверены в надлежащем результате.

Для чего нужен Back-end?

Разработка клиент-серверных приложений подразумевает создание двух частей. Первая, Front-end, принимает запросы от пользователей. Она видна с экранов мобильных устройств клиентов. Вторая, серверное приложение, обрабатывает полученные запросы, выполняет роль административной панели. Здесь хранятся базы данных, логика программы. Без этого не будет работать ни одно клиент-серверное приложение. По сути Back-end — это сердце программы. Это интеллект, который отвечает за обработку запросов клиентов, скорость работы приложения. Поэтому важно, чтобы архитектура серверного приложения была продумана до мелочей, чтобы даже высоконагруженные сервисы работали бесперебойно и быстро.

Как выбрать язык программирования?

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

Важность документации и «брошенные» проекты

В Appomart довольно часто обращаются заказчики, которых «бросили» по тем или иным причинам другие подрядчики. И мы берем чужой, порою даже некорректно работающий проект, осуществляем его аудит и последующую доработку и поддержку. В процессе изучения исходного кода и материалов, полученных от заказчика, мы сталкиваемся с тем, что многие разработчики намеренно не документируют методы сервера, чтобы привязать к себе клиента, за счет несоизмеримости трудозатрат передачи проекта в поддержку другому разработчику, ввиду отсутствия документации к серверной части, а порой просто из-за непрофессионализма. Данный факт, к сожалению, является не только печальным но и распространенным. Заказчику, в этом случае, необходимо оплачивать разработку документации по существующему проекту, а также аудит исходного кода, прежде чем можно будет судить о работоспособности, удобстве и целесообразности поддержки проекта. Сотрудники Appomart всегда ведут электронную документацию методов серверной части в формате, поддерживаемом Postman и Swagger, для последующего использования.

Как проверить подрядчика до подписания договора?

Мы призываем Вас внимательно выбирать подрядчика, и ориентироваться не только на заманчивую цену, но и на перечень документов, которые вы получите вместе с проектом, а также условия передачи исходного кода, и покрытие кода комментариями, схемы баз данных (будь то Mongo DB или MySQL). Залогом успеха, как правило становится грамотная рабочая документация, которая явно указывает на требования к передаваемой Вам по завершению каждого из этапов работы материалов.

Особенности разработки

PHP для серверной части

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

Framework

Framework (программная платформа) — используется для систематизации и повышения уровней абстракции, что позволяет сделать проект более гибким и масштабируемым. Однако, стоит понимать, что framework должен быть выбран корректно, на основе глубинного анализа рабочей документации проекта, без которой невозможно разработать качественный продукт.

Delphi, JAVA, Python

Есть и другие языки, которые используются для создания Back-end. Так, распространены созданные в среде Delphi серверные приложения. С ее помощью программа получает улучшенную отладку, в среде также просто сформировать уникальные программы, предусмотрено визуальное создание, что дает возможность сделать красивый, понятный и удобный интерфейс. Также популярность получили серверные приложения на Java. Такие легко дополняются, легко исполняются на любых платформах и отличаются достойным уровнем безопасности. Еще одним популярным языком считается Python. Серверные приложения с его помощью создаются быстро, просто, без серьезных затрат.

Распространение

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

Создадим клиент-серверное приложение Android, iOS качественно и в срок

Разработка «под ключ»

Программисты Appomart опытны и квалифицированы, чтобы реализовать задачи самых разнообразных уровней. Мы одинаково хорошо реализуем социальные сети, высоконагруженные бизнес-проекты, или программную часть для небольших стартапов. При необходимости мы создадим клиентскую часть приложения под управлением Android, iOS в соответствии с имеющимися потребностями, предъявляемыми требованиями.

IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.

О модели взаимодействия клиент-сервер простыми словами. Архитектура «клиент-сервер» с примерами

  • 28.07.2016
  • Сервера и протоколы
  • Комментариев нет

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем рубрику Сервера и протоколы. В этой записи мы поговорим о том, как работают приложения и сайты в сети Интернет, да и вообще в любой компьютерной сети. В основе работы приложения лежит так называемая модель взаимодействия клиент-сервер, которая позволяет разделять функционал и вычислительную нагрузку между клиентскими приложениями (заказчиками услуг) и серверными приложениями (поставщиками услуг).

Модель взаимодействия клиент-сервер. Архитектура «клиент-сервер».

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

Концепция взаимодействия клиент-сервер

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

Здесь мы разберемся с концепцией, которая позволяет нам выполнять все эти действия в сети Интернет. Данная концепция получила название «клиент-сервер». Как понятно из названия, в данной концепции участвуют две стороны: клиент и сервер. Здесь всё как в жизни: клиент – это заказчик той или иной услуги, а сервер – поставщик услуг. Клиент и сервер физически представляют собой программы, например, типичным клиентом является браузер. В качестве сервера можно привести следующие примеры: все HTTP сервера (в частности Apache), MySQL сервер, локальный веб-сервер AMPPS или готовая сборка Denwer (последних два примера – это не проста сервера, а целый набор серверов).

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

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

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

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

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

Простая схема взаимодействия клиент-сервер

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

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

Читать еще:  Архитектура приложения при разработке

Почему веб-мастеру нужно понимать модель взаимодействия клиент-сервер

Давайте теперь ответим на вопрос: «зачем веб-мастеру или веб-разработчику понимать концепцию взаимодействия клиент-сервер?». Ответ, естественно, очевиден. Чтобы что-то делать своими руками нужно понимать, как это работает. Чтобы сделать сайт и, чтобы он правильно работал в сети Интернет или хотя бы просто работал, нам нужно понимать, как работает сеть Интернет.

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

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

Архитектура «клиент-сервер»

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

Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).

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

Двухуровневая модель взаимодействия клиент-сервер

Здесь четко видно, что есть клиент (1-ый уровень), который позволяет человеку сделать запрос, и есть сервер, который обрабатывает запрос клиента.

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

Многоуровневая архитектура взаимодействия клиент-сервер

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

Если мы посмотрим на данную архитектуру с позиции сайта. То первый уровень можно считать браузером, с помощью которого посетитель заходит на сайт, второй уровень – это связка Apache + PHP, а третий уровень – это база данных. Если уж говорить совсем просто, то PHP больше ничего и не делает, кроме как, гоняет строки и базы данных на экран и обратно в базу данных.

Преимущества и недостатки архитектуры клиент-сервер

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

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

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

Лекция 4. Архитектура с сервером приложений;

Развитие идей архитектуры клиент-сервер привел к появлению трехзвенной архитектуры доступа к базам данных (в литературе ее также называют многозвенной архитектурой,.

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

Архитектура клиент-сервер — двухзвенная: первым звеном в ней есть программа клиента а второй — сервер БД и сама БД.

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

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

В клиентской программе, которая в этой архитектуре называется облегченным или тонким клиентом (thin сlіепt), размещается клиентский набор данных, который представляет собой копию части данных из БД. Все изменения, что пользователь вносит в данные, изменяют эту локальную копию и могут к нужной поре не передаваться в БД (режим отложенной обработки данных). Потом при восстановлении отдаленного набора данных только измененные записи передаются серверу применений. В свою очередь сервер применений пересылает эти изменения SQL-серверу для записи их в отдаленную БД.

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

Заметим, что на рис. 5 по левую сторону показанный вариант размещения сервера применений на машине сервера БД. Такой вариант наиболее популярный, так как снижает загрузка сети и гарантирует одновременную работу обеих серверов.

Сервер применений может располагаться на любой сетевой машине, оснащенной ВDЕ в случае работы с клиентским применением созданным в среде Delphi. Разумеется, в этом случае каталог его размещения должен быть доступным другим сетевым машинам, а самая машина сервера применений должна быть включена в период работы с сервером данных. Больше того, в этой архитектуре можно использовать файл-серверный вариант размещения данных (на рис. 5 — по правую сторону). Таким образом, вместо сервера БД с успехом могут использоваться файлы-серверы с таблицами DЬаsе и Рагаdох. Преимущества облегченного клиента и централизации бизнесов-правил будут в полной мере оказываться и в этом случае. Кроме того, в таких системах существенным образом снижается нагрузка на сеть, так как фильтрация и отбор данных реализуются сервером применений, а клиенту пересылаются лишь результаты запроса.

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

Рис. 5. Разновидности архитектур с сервером приложений

К дополнительным преимуществам можно отнести :

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

· важное уменьшение сетевой нагрузки за счет отложенного восстановления и регулированного объема пактов данных:

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

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

Связь «тонких клиентов» с сервером применений осуществляется средствами, которые базируются на механизмах OLЕ-автоматизации и объектно-ориентированных вызовов, которые являются стандартами для отдаленных процедур в распределенных системах. На сегодняшний день существуют несколько технологий взаимодействия объектов и программ, которые параллельно развиваются и конкурируют : СОМ (Соmропепt ОЬjесt Моdel — компонентная модель объектов) корпорации Місгоsoft , СОRВА (Common ОЬjесt Require Вгокег Агсhytecture — архитектура с поставщиком необходимых общих объектов) независимой группы ОМС, МТ (Місгоsoft Тгапsасtion Server) и прочие. Эти технологии предназначены для того, чтобы одна программа (клиент) смогла заставить работать объект, который есть частью другой программы (частью сервера), так, будто этот объект был частью клиента. Причем в общем случае обе эти программы могут быть расположены на разных компьютерах (в том числе, которые находятся в разных частях мира), написанные на разных языках и таких, что выполняются под управлением разных операционных систем. Больше того самые компьютеры могут быть разного типа — например, ІВМ- совместный ПК и рабочая станция SUN.

Читать еще:  Тест на тему архитектура пк

Вопрос для самоконтроля

1. Что такое локальная база данных?

2. Что представляет собой база данных в локальной и распределенной архітектурах?

3. Кем и как выполняется синхронизация данных в архитектуре «сервер^-сервер-файл-сервер»?

4. Назовите недостатки архитектуры сервер^-сервер-файл-сервер?

5. Назовите преимущества архитектуры сервер^-сервер-клиент-сервер?

Заметки из Зазеркалья

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Реализовано в версии 8.3.12.64 мобильной платформы.

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

Сценарии мобильной работы

До недавнего времени платформа «1С:Предприятие» предлагала единственную технологию, с помощью которой можно было работать с её приложениями, используя мобильные устройства. Это мобильная платформа.

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

По своей архитектуре такие приложения очень похожи на файловый вариант работы системы 1С:Предприятие. На мобильном устройстве существует собственная база данных, «внутри» мобильного приложения существует как клиент, обеспечивающий взаимодействие с пользователем, так и сервер, обеспечивающий взаимодействие с базой данных.

Такие мобильные приложения могут взаимодействовать с «основным» приложением, установленным в офисе. Но это не онлайн взаимодействие, а периодический обмен данными с бэк-офисом. Основная работа в мобильном приложении ведется в оффлайн-режиме. А при появлении интернет-соединения выполняется синхронизация данных.

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

Получается, что неохваченным оказывается значительный круг задач, обладающий следующими характерными особенностями:

  • Взаимодействие с информационной базой должно выполняться в онлайн-режиме;
  • На мобильном устройстве должна быть доступна вся функциональность «основного» прикладного решения, даже такого крупного, как, например, «1С:ERP Управление предприятием»;
  • Интерфейс должен обеспечивать комфортную работу на любых мобильных устройствах с любым размером и расположением экрана.

Мобильный клиент

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

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

Формы, разработанные для настольной версии 1С:Предприятия, он автоматически компонует таким образом, чтобы обеспечить удобство работы с ними на маленьких экранах мобильных телефонов на приемлемом уровне.

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

Потенциальные пользователи

На наш взгляд эта технология будет востребована в тех внедрениях, где обязательно требуется онлайн доступ в систему с мобильных устройств. Чтобы данные, введенные на мобильном устройстве, попадали непосредственно в «общую» базу данных, минуя промежуточные шаги синхронизации.

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

Кроме этого мобильный клиент будет полезен для пользователей сервисов, работающих на базе технологии 1Сfresh. Это сервисы 1Сfresh.com и «Бухгалтерское обслуживание», поддерживаемые фирмой «1С», а также любые другие сервисы, развернутые с использованием этой технологии.

Функциональность

Если сравнивать функциональность мобильного клиента с тем, что «умеет» тонкий клиент, то тут есть не только ограничения, но и преимущества.

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

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

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

Другое ограничение, впрочем, как и для мобильной платформы, заключается в недоступности некоторых объектов встроенного языка и некоторых элементов интерфейса. Но мы будем стараться эти различия минимизировать по мере развития мобильного клиента.

Автоматизация построения интерфейса форм

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

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

Например, важные элементы это таблица динамического списка в форме списка, табличный документ в форме отчёта. Важные колонки это, например, колонки «Наименование» и «Дата».

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

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

Адаптация конфигураций к мобильному клиенту

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

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

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

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

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

Дистрибутив, сборка и публикация

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

Поэтому мы не публикуем мобильный клиент как отдельное универсальное приложение. Мобильный клиент поставляется вместе с мобильной платформой в виде набора исполняемых файлов. На основе этих файлов разработчик должен собрать приложение, которое будет работать на мобильном устройстве. Процедуры сборки и публикации приложений, что для мобильной платформы, что для мобильного клиента, схожие. Используется один и тот же инструмент – сборщик мобильных приложений.

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

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×