Файл: Технология клиент-сервер (Архитектура. Компоненты системы SQL Server 2012. Объекты базы данных SQL Server).pdf

Символ управления наследованием. Из приведенных листингов видно, что в eid перед каждым ElementID есть символ #. Это символ, управляющий наследованием. Есть несколько возможных вариантов управления наследованием, за каждый из которых отвечает своей символ перед ElementID в атрибуте eid:

1. Отсутствие управляющего символа либо символ # – жесткое (полное) переопределение элемента. Полностью переопределяется как его атрибуты, так и его содержимое. Если в родителе присутствовали атрибуты у элемента, а у наследника их нет, считается что их нет. Если в родителе присутствовали внутренние элементы у элемента, а у наследника их нет, считается что их нет.

2. Символ @ – мягкое переопределение элемента. Если отсутствуют все атрибуты либо только в части, недостающие атрибуты берутся из родительского представления. Если полностью отсутствует содержимое элемента, оно перейдет из родителя. Для возможности мягкого переопределение необходимо, чтобы в элементе отсутствовали текстовые элементы, не входящие в другие элементы, так как в таком случае порядок следования и переопределения элементов будет непредсказуем. Для решения данной проблемы следует ввести дополнительный элемент для описания простого текста.

Маркер будущего элемента. Подведем итоги с маркером будущего элемента – атрибутом next-eid, который содержит число – ElementID следующего добавляемого элемента. После каждого добавления элемента должен инкрементироваться.

1. Маркер храниться в атрибуте next-eid тэга view корневого представления.

2. У представлений, наследующих другие представления такого атрибута нет – они наследуют маркер у корневого родителя.

3. С маркером возможна всего одна операция – инкрементация. Он не может уменьшаться.

4. При добавлении нового элемента в дочерний элемент, родительский маркер так же инкрементироваться. Это необходимо для корректного наследования элементов.

5. Он всегда больше самого большого ElementID данного представления как минимум на единицу. В двух ситуациях он может быть больше, чем на единицу: если элемент с максимальным ID был удален из представления либо если элемент был добавлен в ребенка этого представления.

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

Любой элемент может содержать в себе:

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

---

2. Любое количество простого текста, но при этом не может содержать другие элементы.

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

Виды элементов. Доступны все элементы, которые доступны в HTML в тэге body, но поведение некоторых скорректировано. Так же добавлены новые элементы со своим поведением.

1. Null – «несуществующий тэг». Необходим, чтобы при наследовании удалить родительский элемент.

2. Parent – «полностью наследуемый тэг». Имеет только один атрибут – eid – и полностью наследует элемент без родителя без изменений.

3. Include – «тэг-включение». Благодаря этому тэгу можно полностью вставить одно представление в другое. Содержит в себе ViewID.

4. Textelement – «текстовый элемент». Может содержать в себе только текст. Не может содержать другие элементы.

5. A – «ссылка». Тот же тэг из HTML, но с небольшим отличием. Вместо атрибута href содержит атрибут href-view, который должен содержать в себе ViewID.

3.2. Клиент-серверное взаимодействие

В то время, как получение документа в режиме чтения, по большей части на прикладном уровне модели OSI/ISO выглядит, как запрос контента методом GET с указанием конкретного ресурса (имитирующего путь к документу в файловой директории в нашей «виртуальной файловой системе), редактирование представляет более сложный процесс в виде распределенного клиент-серверного приложения. На стороне сервера приложение представлено PHP-скриптом на базе фреймворка Laravel, на клиенте JavaScript-приложение, напрямую работающее с деревом DOM, ведущее историю изменений в рамках текущей сессии, получающий и отправляющий на сервер данные об изменениях^[16].

Механизм изменений представлен REST-API с XML в качестве формата взаимодействия на прикладном уровне, таким образом HTTP решает задачи транспорта. Такой подход не вполне укладывается в модель OSI/ISO, так как прикладной уровень сам состоит из двух подуровней: собственно механизм взаимодействия клиент-сервер, и сам протокол HTTP (а в случае шифрованного соединения HTTPS, фактически он и будет использоваться, в особенности в режиме редактирования).

Этапы осуществления взаимодействия. Упрощенно механизм обмена можно описать следующим способом: клиент (редактор) получает от сервера набор XML представления страниц, отрисовывает по ним DOM-дерево, и после визуального редактирования (WYSIWYG) данные в формате XML представления отправляются обратно на сервер^[17].

---

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

В случае, если создается новый документ, клиент запрашивает у сервера данные о родительской странице, для использования в качестве шаблона (Рис. 3.3 – Приложение 2). Затем, после создания на ее основе новой страницы, данные отправляются на сервер и сохраняются в БД.

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

Если посетитель впервые запрашивает сохраненную в редакторе страницу, на серверной стороне происходит генерация документа – компиляция из внутреннего формата XML файлов HTML и CSS (и при необходимости js). Клиенту уже отправляются сгенерированные статичные файлы (рис.3.5, Блок 3) – Приложение 2). При последующих обращениях посетители будут получать закешированные сгенерированные файлы (рис.3.5, Блок 4) – Приложение 2).

Так как это статичное содержимое, CMS будет работать быстро и с возможность обеспечивать работу при высоких нагрузках при использовании вебсервера Nginx.

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

ЗАКЛЮЧЕНИЕ

Проработав теоретические и практические материалы научных статей, учебных пособий, научно-популярные публикации в сети Интернет, мы пришли к следующим выводам:

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

---

Сеть Интернет построена по технологии «клиент-сервер».

Серверы — это компьютеры или программы, которые предоставляют какие-либо сервисы клиентам, например, веб-сервер или сервер электронной почты.

Клиенты — это компьютеры или программы, которые используют то, что предлагают серверы, например веб-браузеры или почтовые клиенты.

Основные виды технологии распределенной обработки данных:

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

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

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

4. Технология «клиент-сервер», ориентированная на изменения данных в одном месте. Удаленные серверы не связаны между собой сетью ЭВМ, т.е. отсутствует сервер-координатор. Клиент может изменять данные только в своей локальной базе. Возникает опасность «смертельных объятий», т.е. ситуация, когда задача А ждет записи, заблокированные задачей В, а задача В ждет записи, заблокированные задачей А. Поэтому распределенная СУБД должна иметь средство контроля совпадений противоречивых запросов. Распределение данных реализует метод расчленения; реализуется обработка распределенной транзакции.

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

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

6. Технология «клиент-сервер», ориентированная на сетевую СУБД. Обеспечивает стратегию расчленения и дублирования. Позволяет получить более быстрый доступ к данным. Распределенная СУБД обеспечивает независимость клиента от места размещения сервера, глобальную оптимизацию, распределенный контроль целостности базы, распределенное административное управление.

---

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

Применительно к CMS используется обычно двух-трёхзвенная архитектура клиент/сервер. Например, трехзвенная архитектура разбивает процесс обработки данных между клиентом, сервером приложений и хранилищем данных. В отличие от традиционной двухзвенной архитектуры здесь присутствует сервер приложений как промежуточное звено между клиентом и хранилищем данных.

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

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

Преимущества технологии «клиент-сервер»:

- не требуются одновременные крупные финансовые вложения, так как мощность можно наращивать постепенно;

- добавление сервера или рабочей станции повышает общую мощность системы;

- пользователь имеет большой выбор платформ;

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

Недостатки технологии «клиент-сервер»:

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

- поддержка работы данной системы требует отдельного специалиста — системного администратора;

- высокая стоимость оборудования.

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

---