Remkomplekty.ru

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

Архитектура веб приложений

АРХИТЕКТУРА ВЕБ-ПРИЛОЖЕНИЙ

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

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

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

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

В настоящее время принципиально изменились технологии работы компаний в интернете. Теперь все ресурсы интернета размещены на дисках компьютеров, подключенных к сети, т.е. сетевых дисках. Это означает, что мы имеем дело с распределенными сетевыми ресурсами. В случае необходимости получить доступ к информации какого-либо компьютера можно с любого компьютера без обращения к серверу, воспользовавшись сетевыми службами, которые, в свою очередь, также находятся на удаленных сетевых ресурсах. Такие службы называются веб-сервисами. Речь идет о переносе модели «клиент — сервер» на сетевую модель, где сетевая служба сама становится объектом со своими функциями (методами) и атрибутами (свойствами). Вызывая методы этой службы из своих приложений, можно решать различные задачи. Тенденция к появлению специализированных интернет-сервисов (служб) может в будущем привести к тому, что практически отпадет необходимость локального программного обеспечения. Примером могут быть облачные среды разработки приложений IDE (Integrated Development Environment), которые дают возможность с мобильного устройства (смартфона или планшета) разрабатывать приложения на различных языках программирования. К таким IDE относятся, например, EclipseOrion, Cloud 9 IDE, eXoCloudIDE. Переход разработки в «облака» приводит к изменению интерфейса информационных систем — он становится веб-интерфейсом. Общий вывод, который следует из всего изложенного, такой: главное, чтобы концептуально система не устаревала, а на уровне программно-аппаратных средств постоянно происходили бы изменения, порождающие циклический реинжиниринг системы на базе современных технологий.

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

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

Веб-приложение — это клиент-серверное приложение, в котором клиентом выступает браузер, а сервером — веб-сервер. Логика веб-приложения распределена между сервером и клиентом, хранение данных осуществляется преимущественно на сервере, обмен информацией происходит по сети. Одним из достоинств такого подхода является тот факт, что клиенты не зависят от конкретной операционной системы пользователя, поэтому веб-приложения являются кросс-платформенными сервисами. Переход к веб-приложениям стал очень популярен в конце 1990-х — начале 2000-х гг.

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

Рис. 1.3. Схема взаимодействия компонентов информационных систем с использованием интернет-технологий 1

С серверной частью все сложнее. Структурно она состоит из трех крупных компонентов:

  • 1) веб-сервера (НТТР-сервера);
  • 2) сервера базы данных (БД);
  • 3) программного интерпретатора.

Веб-сервер является связующим звеном между веб-приложе- нием и клиентом. Он принимает запросы от клиента в виде набора данных по протоколу HTTP и возвращает в ответ документы на языке HTML и файлы, которые требуются дополнительно (картинки, листы стилей, другие объекты). При этом документы и другие файлы могут быть как статическими (находиться в файловой системе сервера), так и динамическими, т.е. сформированными программной частью. Наиболее распространенным веб-сервером является Apache, его используют для организации веб-узлов более чем в 70% случаев (а для русской части интернета этот показатель достигает 90%).

Кроме того, существуют разработки специальных веб-серверов для различных приложений, входящих в большие комплексы, например при использовании веб-приложений на технологиях компании Microsoft используют Internet Information Server (IIS). От выбора сервера зависит набор возможностей по языкам программирования, применяемым для разработки информационной системы.

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

Программный интерпретатор — это сердце системы. С помощью программного интерпретатора выполняется код, содержащий логику работы системы (алгоритмы). Поясним, почему этот элемент называется именно так. В веб-среде могут выполняться приложения, написанные на различных языках программирования. Их можно разделить на две группы: компилируемые (исполняемые как обычные программы на компьютере) и интерпретируемые (требующие интерпретатора для выполнения). При разработке веб-приложений используются оба этих типа, но особую популярность заслужили именно интерпретируемые языки: Perl, PHP, Ruby, Python. Интерпретируемые программы медленнее выполняются, но процесс их разработки значительно проще и быстрее. Учитывая постоянно повышающиеся требования бизнеса на скорость внедрения изменений в программные продукты (информационные системы), быстрый цикл разработки программ становится решающим фактором. Кроме того, мощность компьютеров постоянно возрастает, позволяя до определенного предела забывать о производительности приложений в угоду удобству и скорости разработки.

В приведенном на рис. 1.3 примере используется интерпретируемый язык Рег1 как мощный и подходящий для большинства проектов по созданию информационных систем с веб-интерфейсом. Программный код системы состоит из модулей и скриптов. Эти два компонента реализуют логику выполнения и основную функциональность системы.

Выбор языка Рег1 обусловлен следующими факторами:

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

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

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

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

Проблема некорректного отображения обусловлена тем, что совместимость браузеров с международными стандартами не является полной, т.е. при создании HTML-кода страниц и приложений нужно учитывать особенности каждого из числа основных веббраузеров, используемых на рынке (MS Internet Explorer, Chrome, Opera, FireFox, Safari). При этом нет гарантии, что протестированное на основных видах браузеров приложение будет корректно работать на других, более редких, продуктах.

Смысл проблемы некорректной работы элементов управления состоит в том, что в большинстве браузеров предусмотрена установка расширений (дополнительных модулей, называемых плагинами). Некоторые веб-приложения построены таким образом, что требуют наличия тех или иных расширений браузера для своей работы. В мире веб-сайтов характерный пример — это Flash-объекты (анимированные мини-приложения с расширенными возможностями). До недавнего времени поддержка Flash в операционной системе Linux оставляла желать лучшего, поэтому сайты и приложения, построенные с использованием технологии плагинов, не могли там работать.

Использование мобильных устройств. В настоящее время с появлением мобильных устройств клиентом веб-сервера может быть не только персональный компьютер, оснащенный обычным веббраузером, но и собственно мобильное устройство. Мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров. Они имеют ограниченного размера экран, малый объем памяти, а нередко и невозможность отобразить что-либо, кроме нескольких строк черно-белого текста. В настоящее время для них существуют другие протоколы передачи данных, например WAP (Wireless Access Protocol), и соответствующие языки разметки, например, WML (Wireless Markup Language)

Читать еще:  Принципы архитектуры предприятия

и CHTML (Compact HTML). Для передачи данных на мобильное устройство соответствующего формата используются специальные сайты, поддерживающие WAP и WML. Наиболее перспективными являются приложения, которые в зависимости от типа клиента умеют генерировать тот или иной код. Именно такой подход реализован в технологии Microsoft ASP.NET.

Разделение бизнес-логики и интерфейса. С ростом объема используемых данных и числа посетителей сайта возрастают и требования к надежности, производительности и масштабируемости веб-приложений. Для удовлетворения указанных требований бизнес-логику, которая реализована в веб-приложениях, отделяют от интерфейса приложения и переносят на сервер приложений в виде независимых бизнес-объектов, которые могут быть реализованы в одной из известных технологий: СОМ, Microsoft.NET и др. Часто такие бизнес-объекты реализуют какую-либо часть функциональности информационной системы (не конкретной системы, а предоставляют модуль или часть модуля, которые можно «вживлять» в любую информационную систему). Такие бизнес-объекты могут представлять веб-сервисы.

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

  • [1] См.: Весь Рунет как на ладони: статистика доменов .ш, .рф и .su на StatOnline.

Какую технологию выбрать или архитектура современных приложений

ru-RU | создано: 13.05.2015 | опубликовано: 13.05.2015 | обновлено: 02.01.2018 | просмотров за всё время: 10385

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

Направление

Ни для кого не секрет, что в мире IT существует множество технологий. Даже если говорить только о клиентской (front-end) части, то можно, навскидку, вспомнить такие как: AngularJS, KnockoutJS, EmberJS, BreezeJS, DurandalJS и другие. Если же говорить о серверной (back-end) части ПО, тут в последние время появилось тоже очень много возможностей, как то: Web API, OData, ASP.NET MVC, WCF-services. Хотя Microsoft и планирует объединить первые три в одно целое под названием MVC 6, технологии всё равно разные.

Так уж получилось, что я имею опыт работы c платформой .NET. А если конкретно, то ASP.NET на C# (хотя опыт есть и на Windows Mobile, Windows Phone, WPF, WCF и другие платформы). Когда-то я начинал с ASP.NET WebForms, позже перешел на ASP.NET MVC (о чем не жалею ни секунды). И в связи с этим, повествование будет идти касательно NET. А также мы поговорим о JavaScript.

История о JavaScript

В стародавние времена, когда .NET еще не было и в мыслях, была такая платформа ASP. Я обратил на нее внимание только начиная с версии 3.0. В те далекие времена, язык JavaScript (JS) был всего лишь дополнением к основному языку ASP 3.0 (серверная разметка в HTML). JS — выполнял вспомогательные функции для решения задач на клиентской стороне, потому что JavaScript выполняться в браузере на клиенте. Мелкие функции, простые расчеты и другие нетребовательные операции: отобразить сообщение об ошибке, проверить ввод пользователя, подставить значение по умолчанию и прочие функции – вот для чего в основном программисты использовали JS.

На данный момент, вот уже в течении 3-5 лет JS перерос в нечто большее, чем просто вспомогательный язык. Он приобрел статус самостоятельного основного языка для разработки по web. Язык может теперь работать напрямую с http-сервером (node.js), что ставит его на один уровень с другими языками.

Front-End

Выбор клиентской части от основной архитектуры приложения следует начать с определения, “что есть что”. Перед тем как начать выбирать, приведу схему архитектуры современного web-приложения.

Итак, давайте рассмотрим часть “Клиент”, ведь именно это и есть Front-End. Желтая зона, состоящая из четырех подзон представляет собой простые понятия:

  • базовые операции – определение namespace’ов, утилиты, настройки приложения, хелперы, вспомогательные функции и классы и другие обобщенные сборки полезных вещей. Это своего рода “кладовочка”, в которой полно разного инструмента и расходного материала на выбор. Здесь лежат базовые определения для приложения.
  • Widgets – контролы и компоненты сторонних разработчиков, например, jQuery UI, Bootstrap и другие полезные компоненты (контролы) и UI-фреймворки.
  • MV* frameworks – фреймворки на JavaScript, которые отвечают некоторым требованиям, то есть “знают” о маршрутизации (router), привязка данных (data-binding), шаблонные представления (template/views), модели (models) и доступ к данным (data access). MV* – представляет собой семейство паттернов MVC, MVP, MVVM. Примерами таких фреймворков могут послужить: backbone.js, knockoutjs, maria.js.
  • JavaScript-библиотеки – сборки сторонних разработчиков, именно те, что являются вспомогательными инструментами или базовыми основами. Например, jQuery, underscore.js, moment.js и другие.

Всё, что объединено в нижнем блоке раздела “Клиент” можно назвать “App framework”. Реализации в конкретном приложении может значительно отличаться в зависимости от выбранных технологий и остальных сторонних фреймворков, которые перечислены в верхней (желтой) части раздела “Клиент”. Подробное описание этих компонентов системы мы отложим как темы для будущих статей, но сравнительную таблицу я всё-таки приведу:

Back-End

Пришло время рассмотреть часть “Сервер”, потому что вряд ли найдется сколько-нибудь полезный проект (сайт, приложение), который не был бы ни коим образом связан с данными (БД). Про сквозную интеграцию говорить особо нечего, единственное, что можно упомянуть, что, так или иначе, в любом проекте есть базовые операции, как то: чтение настроек, запись настроек, файловые операция чтения/записи и другие подобного рода обобщенные операции. Модули и сервисы которые управляют этими операциями носят имя – “управление операциями”.

Что касается “безопасности”, то тут существует огромное количество вариантов реализации: авторизация и аутентификация на основе ASP.NET SimpleMembership, Microsoft Identity, Open Auth и даже собственная реализация механизмов.

По остальным составляющим “кубика” “Web-сервер” пройдемся снизу вверх. Уровень доступа к данным (DAL) имеет в себе определение “Компоненты доступа к данным”. Под этим большим понятием кроются компоненты типа ORM (например, MS EntityFramework или LLBLGen). А также компоненты “прямого” доступа к БД (например, SQLDataReader, SqlCommand или кастомные реализации на их основе).

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

К “Сервисам” можно отнести такие компоненты как SQL Report Service или сервисы по синхронизации данных, сервисы распределяющие нагрузку или другого типа сервисы, которые работают непосредственно с БД.

Уровень бизнес-логики” – это есть “приложение”, как раз то, чем определяются задачи и функции программы (web-приложения). Бизнес-логика приложения содержит привила управления данными проходящие через программу. Уровень бизнес-логики призван решать прикладные задачи.

Уровень представления” – самый простой для понимания раздел архитектуры, потому что он лежит на “поверхности” и его можно “пощупать мышкой” 🙂 Представления генерирующие серверной частью приложения актуальны и на сегодняшний день, но позиции такого рода подхода стремительно падают в пользу HTML5. Мне доводилось встречать приложения достаточно мощные и многофункциональные, которые были сделаны практически без использования JavaScript, но эра таких web-приложений практически сошла на нет.

Концепция web-приложения

Современные web-приложения “стремятся” к виду Desktop-приложений, но специфика работы Web стандартов, то есть асинхронная модель поведения, когда на любой Request приходится ждать Response от сервера, накладывает ряд ограничений на дизайн и, соответственно, на архитектуру приложения. Примером может быть например, обязательное требование (в описании Web 2.0) уведомление пользователя о процессе запроса. То есть, если пользователь кликнул кнопку “отправить сообщение”, то программист должен уведомить пользователя о течении процесса, показав на время ожидания ответа от сервера о результате операции картинку анимации, или вывод динамического сообщения. Понятно, что подобного рода интерфейс может быть и в Desktop-приложениях, но для Web-платформы это ключевое понятие (особенно если учесть, что на Request не всегда приходит Response).

Вариант архитектуры для Web-приложения

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

Front-End:

  • KnockoutJS – как фреймворк для связывания данных JavaScript-моделей с HTML. В ответ на очень частый вопрос “почему именно knockout” отвечаю. Принцип связывания данных у KnockoutJS построен на модели MVVM, что соответствует принципу в WPF и Silverlight, а значит мне не нужно переосмысливать базовые понятия, принципы и паттерны. Кстати сказать, AngularJS реализует принцип MVC, что не может не повлиять я внутренние концепции при реализации приложений с его использованием. OpenSource
  • Для доступа к web-сервисам я использую jQuery.ajax(), иногда AmplifyJS, и совсем редко — вызовы напрямую через XMLHttpRequest. OpenSource
  • Bootstrap – фреймворк для построения UI. Данный фреймворк создает адаптивную HTML-разметку, которая одинаково хорошо выглядит как на разных браузерах, так и на разных разрешениях экрана. OpenSource
  • SiteJs – это набор скриптов для построения web-приложения по принципам SPA (и не только).

Back-End:

  • Web API – современные решения для построения сервисов на основе RESTful. OpenSource
  • EntityFramework – быстроразвивающийся ORM от компании Microsoft, который недавно стал OpenSource.
  • ASP.NET MVC — как web-платформа для web-приложений. OpenSource. Альтернативой может быть node.js или Web API self-host. По сути, совершенно не важно какую web-платформу вы используете. Ключевой момент состоит в том, что HTML5 может работать на любой, а сервис предоставляющий данные для вашего приложения, может быть как платформе ASP.NET, так и на других современных платформах, вплоть до сторонних сервисов.

Заключение

На этом наверное, всё. Единственное, что стоит отметить, так это то, что каждый из вас вправе выбирать любую удобную и близкую по духу конфигурацию архитектуры приложения. В этой статье я озвучил лишь базовые понятия и основные принципы построения современного web-приложения (сайта). С другой стороны, у каждого из выбранного компонента архитектуры есть свои плюсы и минусы. Умея ловко подбирать “правильные кубики” позволит в дальнейшем: а) избежать необходимость “переделки” приложения или его частей; б) с легкостью поддерживать приложение, обновляя сборки и фреймворки на новые более производительные версии; в) идти в ногу со временем, применяя новые стандарты в программировании и дизайне.

Читать еще:  Архитектура локальной сети

Лекция 8 Архитектуры web-приложений;

Web-приложения (web applications, часто их называют Интернет-приложениями, internet applications) представляют собой набор страниц, объединенных общей функциональностью. Все Web-приложения являются клиент-серверными, что, очевидно, определяется технологией построения Интернета. В приложениях обычно задействуются все вышеперечисленные технологии, от DHTML, исполняемом в клиентском браузере, до расширений Web-сервера. В настоящий момент Web-приложения используются как внутри предприятий в локальных сетях, так и в Интернете — это широко известные Интернет-магазины.

Архитектура Web-приложенийВсе Web-приложения можно условно разбить на три составные части: серверная часть, клиентское приложение и интерфейс. Серверную часть образует Web-сервер, возвращающий страницы приложения по запросам пользователя. Чаще всего эти страницы создаются динамически на основе информации, обрабатываемой приложением. Именно на создание страниц «на лету» направлены различные расширения Web-серверов, одно из которых — CGI — уже было ранее упомянуто.Клиентское приложение (браузер) последовательно запрашивает страницы с сервера, используя Dynamic HTML для управления интерфейсом и частичной обработки информации на компьютере клиента. Пользовательский интерфейс специально выделен отдельным пунктом, так как именно формированием клиентского интерфейса и работой с ним Web-приложения отличаются от привычных клиент-серверных приложений. В последнем случае клиентское приложение обменивается с сервером только данными, используя для формирования интерфейса ресурсы приложения. В Web-приложениях интерфейс практически полностью формируется на сервере, оставляя для исполнения клиентом только управление созданной страницей. Более того, существующие стандарты на браузеры накладывают дополнительную специфику на модель поведения приложения. В частности, два свойства, которые необходимо принимать во внимание при разработке приложения -наличие истории просмотра страниц и произвольный доступ к любой странице приложения по известному адресу. Последнее свойство обязательно должно учитываться в приложениях, использующих авторизацию пользователя. Другая серьезная проблема в разработке Web-приложения -отслеживание сессии конкретного пользователя. Дело в том, что по определению HTTP-протокол не имеет понятия текущего состояния (stateless), т.е. очередной запрос страницы абсолютно не зависит от предыдущих запросов и потому не требует уникального идентификатора. Для отслеживания последовательных запросов и идентификации пользователя используются так называемые cookies.

Лекция 9 Сервис–ориентированная архитектура (SOA).

Се́рвис-ориенти́рованная архитекту́ра (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.

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

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

Архитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать дополнительно механизм файловой системы для обмена данными.

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

Элементы сервис-ориентированной архитектуры, по: Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice Hall.

SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабо-связанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

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

Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.

Использование компонентной архитектуры (SCA) для реализации SOA — это область текущих исследований.

Облачные системы.

Облачные (рассеяные) вычисления (англ. cloud computing, также используется термин Облачная (рассеянная) обработка данных) — технология обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как Интернет-сервис. Пользователь имеет доступ к собственным данным, но не может управлять и не должен заботиться об инфраструктуре, операционной системе и собственно программном обеспечении, с которым он работает. Термин «Облако» используется как метафора, основанная на изображении Интернета на диаграмме компьютерной сети, или как образ сложной инфраструктуры, за которой скрываются все технические детали. Согласно документу IEEE, опубликованному в 2008 году, «Облачная обработка данных — это парадигма, в рамках которой информация постоянно хранится на серверах в интернет и временно кэшируется на клиентской стороне, например, на персональных компьютерах, игровых приставках, ноутбуках, смартфонах и т. д.».

Облачная обработка данных как концепция включает в себя понятия:

− инфраструктура как услуга,

− платформа как услуга,

− программное обеспечение как услуга,

− данные как услуга,

− рабочее место как услуга.

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

Введение. Веб как программная платформа

Александр Колосов

Введение. Организационные вопросы

О чем этот курс?

  • Основополагающие принципы работы и стандарты Веб.
  • Архитектурные принципы и подходы к разработке серверной части (back-end) веб-приложений.
  • Инструментальные средства поддержки процесса разработки веб-приложений.
  • Современные проблемы разработки веб-приложений: обеспечение качества, безопасность, высокие нагрузки.

Необходимые базовые навыки

  • Web-технологии (HTML, CSS).
  • Сетевые технологии (TCP, IP, DNS).
  • Управление реляционными БД (SQL).
  • Знание любого языка программирования (Python, Ruby, C, Java, JavaScript, PHP, Pascal, …)
  • Работа с командной оболочкой UNIX/Linux (Bash).

Организация аудиторной нагрузки

Учебный план: 180 часов, из них 45 часов — аудиторная работа, 135 часов — самостоятельная работа.

  • Лекции (15 часов): среда (числитель), 9:45, каб. 341.
  • Практики (30 часов): среда (каждая неделя), 9:45/11:30, каб. 341.
  • Отчетность в осеннем семестре: экзамен по результатам мини-проекта по разработке веб-приложения.

Требования к минипроекту

  1. Функционально простое веб-приложение. Предполагаемый набор функций должен быть предоставлен в виде краткой спецификации требований.
  2. Приложение должно быть разработано с использованием существующего веб-фреймворка (любой язык, любой фреймворк).
  3. Приложение должно использовать БД (классическую реляционную, NoSQL, …)
  4. Доступ к приложению должен быть обеспечен посредством одного из веб-серверов общего назначения (Apache WebServer, Nginx, Microsoft IIS, OpenBSD httpd, lighttpd, …)
  1. В приложении должно быть реализовано разделение доступа (аутентификация и авторизация).
  2. Существенная часть кода должна быть покрыта unit-тестами.
  3. Должны быть учтены базовые рекомендации по обеспечению информационной безопасности.

Примерный план лекций

  1. Веб как программная платформа.
  2. Протокол HTTP.
  3. Внутреннее устройство Веб-сервера.
  4. Веб-приложения и фреймворки.
  5. Информационная безопасность веб-приложений.
  6. Технологии и инструментальные средства процесса разработки веб-приложений.
  7. Проблемы разработки высоконагруженных веб-приложений.

История развития идей гипермедиа

  • Идеи по созданию интерактивных источников информации:
    • Хорхе Луис Борхес — рассказ «Сад расходящихся тропок», 1941 г.
    • Вэнивар Буш — эссе «Как мы можем мыслить» (гипотетическая система «Мемекс»), 1945 г.
  • Гипермедиа — нелинейный носитель информации, содержащий изображения, аудио, видео, простой текст и гиперссылки.

    Цифровые технологии дают возможность реализовать накопленные идеи:

    • Тэд Нельсон: Project Xanadu, 1960–2016 гг. HES (Hypertext Editing System), 1967 г.
    • Дуглас Энгельбарт: NLS (oN-Line System), 1968 г. См. также The Mother of All Demos.
    • Apple Inc.: HyperCard, 1987 г.
    • Тим Бернерс-Ли: WorldWideWeb, средство простого обмена информацией для физиков CERN, 1990 г.

    Становление «Всемирной паутины»

    «Мне всего-лишь нужно было взять идею гипертекста , соединить ее с идеями TCP (Transmission Control Protocol) и доменной системы имен (DNS) и — та-да! — получилась Всемирная паутина (the World Wide Web)…»

    Причины успеха проекта WorldWideWeb

    • Благоприятные условия появления World Wide Web
      • наработки в области гипермедиа,
      • стандартизирован язык разметки SGML (Standard Generalized Markup Language),
      • широкое распространение набора протоколов TCP/IP.
    • Простота и открытость технологии, а также свободно-распространяемая реализация Web-сервера от CERN делают World Wide Web «killer feature» сети Интернет.
    • Основное применение: обмен информацией, знаниями и ресурсами в академическом сообществе.

    Базовые компоненты технологии Веб

    1. Язык разметки для форматирования гипертекстовых документов.
      Простой текст с добавленной в него информацией о способах его представления и строении.
      • На основе SGML был разработан более простой язык HTML.

    Унифицированная нотация для адресации ресурсов, доступных по сети.
    Концепция URI (Uniform Resource Identificator):

    1. Протокол для транспортировки гипертекстовых документов по сети.
      Протокол прикладного уровня HTTP (HyperText Transfer Protocol), работающий поверх протокола TCP:
      • взаимодействие в форме запрос/ответ,
      • формат сообщений: заголовки + пустая строка + тело,
      • протокол без сохранения состояния.

    От веб-сайтов к веб-приложениям

    • Отдельные веб-страницы размещались на веб-серверах больших исследовательских и образовательных организаций.
    • С ростом сети Интернет у большего количества пользователей появляется возможность разворачивать свои веб-серверы, появляются веб-сайты — наборы веб-страниц с единой тематикой и оформлением.
    • Переход от понимания Web как системы обмена статическими ресурсами к Web как динамическому информационныму сервису:
      • поисковые сервисы (сначала преимущественно по FTP и Gopher),
      • информация о погоде,
      • сколько воды осталось в автомате с газировкой,
      • телефонный справочник (одно из первых Web-приложений, продемоенстрированных Т. Бернерсом-Ли в CERN).
    • К середине 90-х Интернет получает все большее распространение среди обычных людей. Бизнес понимает, что Web — это новая платформа для продвижения своих товаров и услуг.

    Классическая высокоуровневая архитектура веб-приложения

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

    Веб как программная платформа

    Особенности клиент-серверной архитектуры

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

    • Централизация данных (проще обеспечить информационную безопасность)
    • Единая реализация приложения-сервера (нет необходимости учитывать особенности пользовательской платформы)
    • Независимая и простая реализация приложений-клиентов (проще разработать кросс-платформенное решение)
    • Менее требовательная к ресурсам реализация приложений-клиентов

    Недостатки и ограничения:

    • Сервер — единая точка отказа
    • Высокая зависимость от характеристик сети
    • Невозможность обеспечения согласованности данных, доступности и устойчивости к разделению одновременно (Теорема CAP)
    • Необходимость учета большого числа внешних негативных факторов при разработке приложений (Fallacies of distributed computing)

    Архитектура ПО для веб-приложений высокой степени сложности

    Главная » Блог » Архитектура ПО для веб-приложений высокой степени сложности

    Автор: Александр Третьякевич

    Задачи архитектуры

    Архитектура приложения должна строиться исходя из следующих задач:

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

    Высокоуровневое определение архитектуры

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

    • синхронный способ (прямое/управляемое взаимодействие через синхронную шину ESB)
    • асинхронный способ (генерирование и захват событий при помощи высокопроизводительного конвейера на основе сообщений)

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

    Компоненты архитектуры

    Высокоуровневая схема архитектуры представлена ниже:

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

    Синхронная шина ESB

    В приложении будет использован ESB-подобный тип коммуникации между отдельными службами, формирующими цельное приложение. Все службы имеют открытый публичный интерфейс (через реестр служб), и используют системную синхронную транспортную шину для связи между собой по типу точка-точка. Синхронная свяязь используется для запроса данных и выполнения процессов по запросу.
    Архитектура обеспечивает службам возможность использования различных средств связи, в т.ч. веб-сервисов (Java Axis и др.), XML-RPC вызовов, RPC-вызовов (Corba и др.), собственных протоколов. Самое очевидное решение – привязка к одному транспорту (например, к веб-сервисам) для уменьшения избыточности. Реализация ESB может основываться и на проприетарном облегченном протоколе собственной разработки, и на уже имеющихся решениях с открытым исходным кодом (типа Mule Java).

    Реестр служб

    Реестр служб отвечает за отслеживание и сбор информации (для системы в целом) о зарегистрированных службах, их адресах, текущем состоянии и возможностях, в т.ч.:

    • информации о хостах, содержащих текущие службы (или о точках входа для кластеров служб)
    • состоянии текущей службы (доступна/недоступна)
    • версии службы (для оперативного отслеживания состояния развертывания приложения в целом)
    • получение запросов от бизнес-служб и перевод их в адресные запросы

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

    Асинхронная шина событий


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

    • широковещательная рассылка события всем получателям
    • адресная посылка события определенному получателю
    • Р2Р-обмен между двумя службами

    Асинхронный транспорт


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

    • JMS (сервер+брокеры, напр. Apache MQ) – стандарт де-факто в настоящее время
    • AMQP (напр. RabbitMQ) – быстро набирающая популярность альтернатива
    • любой проприетарный легковесный протокол обмена сообщениями (меньше вероятность дополнительных расходов на разработку)

    База данных приложения


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

    Клиентское приложение


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

    • слой DAO (может быть основан на Hibernate)
    • бизнес-слой (образующий доменную структуру вместе с DAO), для облегчения разработки может быть использован Spring IoC
    • презентационный слой (веб-интерфейс пользователя с компонентами на AJAX, выбор конкретного способа реализации будет произведен после уточнения деталей спецификации с заказчиком).

    Клиентское приложение с самого начала должно быть готово к установке в кластере (несколько веб-серверов + Apache Balancer).

    Административное приложение


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

    • слой DAO (может быть основан на Hibernate)
    • бизнес-слой (образующий доменную структуру вместе с DAO), для облегчения разработки может быть использован Spring IoC
    • презентационный слой (веб-интерфейс пользователя с компонентами на AJAX, выбор конкретного способа реализации будет произведен после уточнения деталей спецификации с заказчиком).

    Служба контроля доступа (СКД)


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

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

    Служба массовых уведомлений (СМУ)


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

    • балансировка нагрузки на систему в случае необходимости отправки большого числа e-mail сообщений
    • использование нескольких хостов SMTP для обхода ограничений на число отправляемых сообщений (в т.ч. ограничений спам-фильтра) и увеличения пропускной способности системы в целом
    • отложенная обработка заданий на уведомление (полностью асинхронный режим работы клиента)

    Служба статистики


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

    Служба оплаты


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

    Служба рекламы


    Служба рекламы предоставляет возможность размещения баннерной рекламы раличных типов (PPC/PPI) и осуществляет отслеживание баннеров для службы статистики.

    Служба поиска


    В системе предусмотрено 2 способа поиска: полнотекстовый (основан на внутреннем индексировании данных, индексах из внешних источников и тэгах) и бизнес-поиск (специфический поиск для бизнеса с расширенными возможностями). Полнотекстовый поиск может быть реализован на поисковом движке Lucene (например, в форме интеграции Compass / Hibernate Search). Реализация бизнес-поиска зависит от его конкретного придназначения.

    Служба индексирования / веб-обходчик


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

    Вам понравилась статья и Вы хотите заказать у нас приложение? Свяжитесь с нами прямо сейчас!

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