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

Часть 1. Web-сайт или Web-приложение?

Принимайте правильные решения, проанализировав свое присутствие в Web

Серия контента:

В нашем мире iPad-ов, iPhone-ов, Android-ов и устройств, сфокусированных на приложениях, уже несовременно говорить: «у меня статический Web-сайт». Если у вас нет механизма для сложного поиска, хотя бы трех способов оплаты покупок и пары страниц с хитрыми Ajax-взаимодействиями, вас могут назвать «застрявшими в 1990-ых». Многим разработчикам приходится ухищряться, чтобы удовлетворить запросы руководства: Добавьте немного интерактивности! Не отставайте от Amazon.com или Bing, или IBM! Сделайте Web-сайт... Web-приложением. Однако если вы расширяете уже существующие сайты, в результате может получиться недостаточно сфокусированное, а иногда и менее функциональное присутствие в Web.

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

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

Web-сайты не обязательно должны быть Web-приложениями

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

Web-сайты в основном служат для информационных целей

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

Рисунок 1. Пример страницы из Википедии

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

Web-сайты могут быть динамическими

Большинство блогов на самом деле являются Web-сайтами. Хотя блоги управляются такими программами, как WordPress или Movable Type, их результатом являются информационные сайты, состоящие в основном из простых неинтерактивных страниц. Это говорит о важном различии: Web-сайт определяется не тем, как он сгенерирован, а тем, как предоставляемыми им информацией и функциями пользуются его посетители. Понимание этого различия может помочь вам сфокусироваться на том, как выглядит ваше присутствие в Web с точки зрения пользователя.

На ранних стадиях следует сосредоточиться на восприятии сайта пользователем. Пользователю неинтересно, на каких технологиях построен ваш сайт: HTML и CSS, ColdFusion, PHP или Perl. Пользователи просто оценивают сайт, основываясь на том, что они видят. Чтобы понять, сайт какого типа вы создаете или исследуете, нужно немного отвлечься от программирования. Просто откройте браузер, зайдите на свой сайт и оцените его.

Web-приложения, как правило, являются интерактивными

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

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

Большинство Web-сайтов являются в некоторой степени гибридами. Например, взгляните на домашнюю страницу сайта Amazon.com, показанную на рисунке 2. Amazon.com – это гибрид, который однако, является информационным сайтом.

Рисунок 2. Amazon.com

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

Так как любой Web-сайт представляет какую-либо информацию, нужно определить баланс между информацией и интерактивностью. Что вы больше делаете: читаете или взаимодействуете? Вы проводите на одной странице 30 секунд или 10 минут? Если вы много взаимодействуете и проводите мало времени на каждой странице, перед вами интерактивный сайт.

Чем отличаются информационные и интерактивные сайты

До сих пор мы обсуждали довольно простой способ оценки сайтов. Сайт является либо информационным, либо интерактивным. Черным или белым.

Большинство интерактивных сайтов на самом деле являются гибридами. Если нет информации, то получается, что нет ничего, с чем можно было бы взаимодействовать . Представьте, что было бы, если бы на Amazon.com не было ничего, кроме кнопок - ни книг, ни DVD-дисков. Сайт не имел бы смысла. Необходимо иметь какую-либо информацию, с которой можно работать. Таким образом, даже интерактивные сайты в действительности являются гибридами: комбинацией информации и взаимодействий.

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

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

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

В этом момент ребята, занимающиеся электронными книгами, дополненными изданиями (enhanced editions) и следующим поколением издательских продуктов начинают взволнованно махать руками. До нового поколения читателей следует доносить информацию современными средствами, верно? Есть новые способы представления информации: плавающие аннотации, всплывающие окна с дополнительной информацией и встроенные видео.

Да, для расширенной информации есть свое место

Я не хочу сказать, что нужно избегать дополненных изданий или не следует пытаться расширить границы возможного с помощью подхода к информации в стиле Web 2.0/3.0.. Однако, подобные средства служат не совсем для того, чтобы получать информацию быстро и эффективно. Большинство новых способов представления информации используются в иммерсивных и даже развлекательных приложениях. Эти способы не просто передают информацию, они изменяют механизм ее восприятия.

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

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

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

Интерактивность основана на прерывистой работе

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

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

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

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

Пример интерактивного сайта: Audi.com

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

На рисунке 3 показана стартовая страница, Web-сайта Audi.com. Сайт выглядит глянцево даже до начала взаимодействия с ним.

Рисунок 3. Стартовая страница сайта Audi.com

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

Рисунок 4. Изображение на стартовой странице сайта Audi изменяется по щелчку мыши

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

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

Рисунок 5. При наведении мыши на меню появляются полноценные изображения и списки опций

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

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

Рисунок 6. Навигационные меню просты и сами просят на них нажать

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

Рисунок 7. На внутренних страницах нужно больше нажимать мышью, чем читать

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

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

Добавить интерактивность не так просто

При интерактивном подходе главным становится вопрос где именно на экране должно происходить взаимодействие. Это не только рассуждения типа "Этот виджет нужно поместить в левом верхнем углу? А может быть справа?" Есть два базовых подхода (один из которых не очень хорош):

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

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

Перемешиваем информацию и взаимодействия

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

С другой стороны, большинство информационных сайтов в определенный момент должны позволить пользователю что-то нажать или поискать. Представьте, если бы вся информация Википедии хранилась на одной странице! И даже в этом случае, пользователь должен прокручивать страницу; а это тоже является взаимодействием. Все сайты являются гибридами. На большинстве сайтов нет подавляющего перевеса одной из этих сторон, например, 90% информации и только 10% интерактивности (или наоборот). На большинстве сайтов это соотношение составляет примерно 75/25. Вам нужно будет принять решение о количестве информации на вашем интерактивном сайте, либо о количестве взаимодействий на вашем информационном сайте. Конечно же, это должны быть хорошие решения.

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

Создавать гибриды гораздо сложнее

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

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

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

И, наконец, нужно упражняться и укреплять свои слабые места. Если вы проводите дни, работая над сайтами, заполненными информацией, поищите, где на сайте вы могли бы добавить немного интерактивности. Создайте с помощью JavaScript или jQuery сворачиваемые области. Расширьте свой информационный сайт, чтобы на нем соотношение между информацией и интерактивностью составляло 60/40. Также верно и обратное. Ищите способы увеличить количество информации на своем интерактивном сайте. Создайте боковые панели с информацией, появляющиеся в нужное время, на которых будет выведено больше информации, чем вы обычно предоставляете. Укрепляйте свои слабые места.

Используйте свои сайты

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

Используйте свои сайты. Часто и много.

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

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

Заключение

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

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

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

Я решил изменить это и написал статью-перевод-обзор об одном из докладов с конференции NoSQL прошедшей 5 октября в Нью-Йорке. В этой статье будет говорится о системе Riak, с которой мне довелось иметь счастье работать последнее время.

Что такое Riak? Многие модные слова популярные сейчас, можно отнести к Riak. Riak — это документно-ориентированная база данных. Riak — это децентрализованное key-value хранилище данных, с поддержкой стандартных операций — get , put и delete . Riak — это распределенное, масштабируемое, отказоустойчивое решение для хранения информации. А так же Riak — это система с открытым исходным кодом и поддержкой обращений с помощью HTTP, JSON и REST. Ну и конечно RIAK — это NoSQL.

Если копнуть глубже, можно увидеть, что на Riak оказало сильное влияние Amazon Dynamo , теорема CAP (C onsistency, A vailability and P artition Tolerance) Эрика Бревера (Eric Brewer), сама система Интернета в целом, а так же опыт команды разработки Basho в разработке сетевых сред. Мы начали разрабатывать Riak осенью 2007 года, для использования в двух приложениях для Basho, которые были запущенны на Riak и работали на нем большую часть времени.

Чтобы понять почему Riak настолько мощный, требуется рассказать немного теории. Вначале поговорим об Amazon Dynamo.В документе описывающем Amazon Dynamo есть три термина для описания поведения распределенной системы хранения данных: N , R и W . N — это количество реплик каждого значения в хранилище. R — количество данных реплик для выполнения операции чтения. W — количество реплик необходимых для выполнения операции записи. Цель Riak — перенести N , R , и W в логику приложения. Это позволяет Riak адаптироваться к требованиям отдельных приложений.

N для каждого сегмента (bucket ). Например все объекты в сегменте «artist» будут иметь одинаковое значение N , а объекты в сегменте «album» совсем другое. Система использует непротиворечивый алгоритм хеширования для выбора места сохранения N количества реплик ваших данных. Когда поступает запрос, Riak использует хеширование для преобразования текстового ключа в 160-битное число. Когда узел кластера добавляется в Riak, он получает части от 160-битного пространства ключей. Узел имеющий ближайшее значение хэша от ключа (160-битное число) и содержит в себе первую реплику. Остальные N реплик сохранены на узлах с другими N-1 частями 160-битного пространства ключей.Непротиворечивый алгоритм кэширования очень важен — он позволяет каждому узлу Riak выполнить любой запрос. Поскольку любой узел может вычислить, с какими именно другими узлами необходимо связаться, чтобы выполнить запрос, любой узел может выступать в качестве организатора для любого клиента. Тут нет управляющего сервера , нет единой точки для сбоя в системе.

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

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

Предоставление клиенту возможности для указания значений R и W во время запроса, означает, что во время запроса приложение может указать точно, сколько узлов могут выйти из строя. Это очень просто: для каждого запроса, N-R (для чтения) или N-W (для записи) узлов может быть недоступно, однако кластер и данные будут по-прежнему вполне доступны.

Итак, в примере который мы использовали с N=3 и R=W=2 , мы можем иметь 3-2=1 узел недоступным в кластере, но кластер по прежнему будет предоставлять данные. Для особо важных данных, мы можем увеличить значение N до 10, и если мы все ещё будем использовать значение R или W равное 2, мы можем иметь 8 недоступных узлов в кластере, но запросы на чтение и запись будут проходить успешно. Riak дает возможность изменять значения N/R/W так как это хороший способ улучшить поведение приложения при использовании теоремы CAP .

Если вы знакомы с теоремой CAP Эрика Бревера, вы знаете, что есть три аспекта, которые необходимо учитывать при рассуждениях о хранении данных: целостность данных, доступность данных в хранилище, и устойчивость к разделению. Если вы знакомы с исследованием, вы также знаете, что невозможно реализовать систему отвечающую всем трем условиям.

Поскольку вы не можете реализовать все три условия, большинство систем хранения данных используют два. Riak позволяет, не только выбрать любые из них, но и разные приложения могут выбрать различные объемы каждого. Вероятнее всего вы выберите доступность и устойчивость к разделению. Однако вы разрабатываете аппликации которые работают на реальных машинах и вы хотите чтобы они были доступны в любое время для пользователей. Структура Riak реализована для поддержки этой возможности (мы хотим чтобы наши приложения работали все время). Это означает, что вы готовы пожертвовать целостностью данных. Есть много советов как выв можете гарантировать целостность данных (например read-your-writes) в документе описывающем Amazon Dynamo и я советую вам перечитать этот документ.

Вот простой пример как может быть решен вопрос с целостностью данных. Давайте посмотрим на кластер который уже работает и имеет документ с версией 0.

Вдруг в сети происходит сбой. Узлы 0 и 2 находятся в Нью-Йорке, узлы 1 и 3 в Лос-Анджелесе и трансконтинентальная связь рвется. Как поведет себя каждая часть кластера? Если вы установили значения N/R/W надлежащим образом, обе части кластера по сути будут предоставлять версию 0 документа, как и раньше. Клиенты не будут знать о сбое. Теперь предположим что клиент внес изменения в документ, хранящийся в половине кластера находящегося в Нью-Йорке (вы же указали N/R/W так, чтобы это было разрешено?). Этот клиент ввел некоторое несоответствие. Теперь клиенты присоединившиеся к части кластера находящегося в Нью-Йорке получат версию 1 документа, в то время как клиенты присоединившееся к части находящейся в Лос-Анджелесе получат версию 0 этого документа. Теперь предположим что трансконтинентальная связь восстанавливается и обе половины кластера работают вместе. Что должен сделать Riak с двумя разными версиями документа?

В этом случае Riak использует алгоритм вектора времени , для определения какая версия документа более корректная. Алгоритм вектора времени это специальная реализация алгоритма временных меток Лампорта (Lamport clocks / Lamport timestamps). В отличии от обычных временных меток, система временных меток Лампорта построена таким образом, что происхождение и преемственность, может быть определена путем простого сравнения. Каждый раз когда данные сохраняются в Riak, их вектор времени увеличивается, и когда кластер восстановиться Riak сможет определить какие данные сохранить. В нашем случае Riak определит что версия 1 является приемником версии 0, и версия 0 будет заменена версией 1, и данные снова будут целостны.

Все становится немного более интересно, если в то время как части не связанны, клиенты внесут изменения в обоих частях кластера. Теперь когда кластер восстановится, вектор времени покажет, что ни одна из версий является преемницей другой версии. Riak не может определить какая из версий должна быть выбрана, поэтому в этом случае как и с возможностью изменить значения N/R/W, Riak переносит возможность урегулирования конфликта в приложение. Вместо реализации произвольного правила выбора версии как это сделано в других системах, Riak возвращает оба значения приложению предоставляя возможность выбора более верного варианта. Конечно если вы хотите использовать просто правило — данные пришедшие последними и используются, в Riak есть простой флаг для включения такого поведения (allow_mult свойство сегмента)

После всей этой теории как насчет нескольких примеров кода для демонстрации как легко работать с Riak?

Так как Riak написан на Erlang, давайте начнем с Erlang.

Первая строка кода описывает присоединение нашего клиента к кластеру Riak. Вторая строка создает новый объект (документ, пара ключ/значение). Третья строка сохраняет объект в Riak. Четвертая возвращает объект обратно из Riak. последние две строки изменяют значение нашего объекта и сохраняют его снова в кластер Riak.

Если вы не хотите использовать Erlang, Riak так же поставляется с библиотеками для Python…

…Riak так же имеет библиотеки для Ruby…


… Java…

… PHP…


… JavaScript…


…но на самом деле все эти библиотеки работают с Riak с помощью стандартного RESTful HTTP, и это позволяет использовать Riak на любой системе поддерживающей HTTP — например используя инструменты командной строки такие как curl или wget .

Это хорошо когда вам нужно отправить или получить данные из Riak, но что делать когда вы хотите сделать запрос по нескольким объектам одновременно? Это же NoSQL, ведь так? Как насчет небольшого Map/Reduce?

Система Map/Reduce Riak имеет много общего с другими системами Map/Reduce. Функция Map происходит на узле где находятся данные, увеличивая локальность данных одновременно с распределением вычислений в кластере. Часть Map/Reduce Riak которая более всего отличается от других решений заметна в том, что Riak не запускает метод Map над всеми данными в сегменте (bucket). Вместо этого Riak дает возможность клиенту предоставить список ключей объектов на которых должен быть запущен метод Map. Методы Map могут предоставлять больше ключей для более поздних фаз выполнения методов Map, но список ключей для метода Map должен быть определен всегда. Конечно вы можете указать любое количество ключей которое вы хотите, например если вы хотите выполнить метод Map по всем значениям в сегменте, достаточно включить их все в запрос Map/Reduce (функции list_keys или list_bucket могут быть полезны в таких случаях).

Различия в реализации Map/Reduce Riak при сравнении с другими системами обусловлены сильным желанием поддержки ссылок в Riak. Первый вопрос при переходе из мира RDBMS это — «Как я могу организовать связи между моими данными?» Было решено что лучший ответ на этот вопрос — ссылки.

Например если вы хотите организовать связи между записью исполнителя и несколькими записями альбомов, вы хотите создавать ссылки к альбомам в записи исполнителя. Аналогично вы можете создать ссылки в записи альбома к записям композиций входящим в этот альбом. Как только вы добавите ссылки и определите как Riak может получить эти ссылки из ваших объектов, вы получите доступ к новому синтаксису Map/Reduce. Например в данном примере вы можете видеть простой синтаксис позволяющий нам сказать — «Начни с исполнителя REM, потом следуй ко всем альбомам с которым связан исполнитель, потом следуй ко всем композициям с которыми связан альбом, потом извлеки имена этих композиций." Результатом этого запроса будут имена всех композиций REM которые были когда-либо выпущены.

Разработчики решили что link-walking (переход по ссылкам) настолько полезный, что даже реализовали URL синтаксис для него. Вверху вы можете видеть ссылку похожую на URL, и выполнение GET запроса по этому URL вернет вам список всех объектов композиций, который ранее мы получили в примере с Map/Reduce.

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

Если вы заинтересованы в получении дополнительной информации, вы можете посетить сайт

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Подобные документы

Обоснование выбора используемого программного обеспечения. Входная и выходная информация. Реляционная модель базы данных предметной области. Создание модели информационной системы с помощью Run All Fusion Process Modeler r7. Результаты тестовых испытаний.

курсовая работа , добавлен 12.04.2014


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

дипломная работа , добавлен 03.07.2015


Проектирование автоматизированных систем обработки информации и управления. Анализ структуры и деятельности предприятия, создание моделей "Как есть". Определение проблемных областей предприятия. Требования к структуре и функционированию системы.

курсовая работа , добавлен 29.12.2012


Цель создания информационной системы. Автоматизированная информационная система "Строительное предприятие". Использование вычислительной техники и программного обеспечения для создания автоматизированной информационной системы управления на предприятии.

курсовая работа , добавлен 04.01.2011


Ознакомление с основами работы ООО "Мир Компьютеров". Описание информационной системы предприятия. Разработка объектно-ориентированной модели подсистемы средствами Rational Rose и функциональной модели подсистемы средствами AllFusion Process Modeler.

курсовая работа , добавлен 13.01.2015


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

дипломная работа , добавлен 30.08.2010


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

дипломная работа , добавлен 29.06.2011


Обоснование необходимости совершенствования информационной системы (ИС) ООО "Мехсервис". Анализ системы учета деятельности авторемонтного предприятия. Разработка концепции построения автоматизированной ИС. Описание продукта информационной технологии.

дипломная работа , добавлен 22.05.2012

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

Статья о планах обучения пользователей работе в СЭД поможет вам не допускать ошибок в работе.

Несомненными преимуществами веб-ориентированной системы являются следующие факты:

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

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

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

Можно работать и в офисе, и дома, и в командировке, как со стационарного ПК, так и с ноутбука или планшета.

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

Стоимость системы управления базами данных зависит от выбора технологии разработки веб-приложения: использования открытой полностью кроссплатформенной или конкретной платформы для создания веб-приложений, например, Microsoft ASP.NET, что в свою очередь может наложить требования к СУБД, но, в тоже время, имеет и ряд своих преимуществ.

Как и любые другие, веб-ориентированные системы в тоже время имеют свои недостатки:

1. Для работы с системой необходимо подключение к сети Интернет.

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

2. Не все СЭД могут быть заменены на веб-ориентированные по причине ограниченности функциональных возможностей интернет-браузеров.

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

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

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

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

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

Технические особенности

Существенное преимущество построения Web приложений для поддержки стандартных функций браузера заключается в том, что функции должны выполняться независимо от операционной системы данного клиента. Вместо того чтобы писать различные версии для Microsoft Windows , Mac OS X, GNU/Linux и других операционных систем, приложение создается один раз для произвольно выбранной платформы и на ней разворачивается. Однако различная реализация CSS, или Java-апплетов для полной или частичной реализации пользовательского интерфейса. Поскольку большинство браузеров поддерживает эти технологии (как правило, с помощью плагинов), Flash- или Java-приложения могут выполняться с легкостью. Так как они предоставляют программисту больший контроль над интерфейсом, они способны обходить многие несовместимости в конфигурациях браузеров, хотя несовместимость между Java или Flash реализациями на стороне клиента может приводить к различным осложнениям. В связи с архитектурным сходством с традиционными клиент-серверными приложениями, в некотором роде «толстыми» клиентами, существуют споры относительно корректности отнесения подобных систем к веб-приложениям; альтернативный термин «Богатое Интернет приложение» (англ. Rich Internet Applications ).

Устройство веб-приложений

Веб-приложение получает запрос от клиента и выполняет вычисления, после этого формирует веб-страницу и отправляет её клиенту по сети с использованием протокола базы данных или другого веб-приложения, расположенного на другом сервере. Ярким примером веб-приложения является система управления содержимым статей Википедии : множество её участников могут принимать участие в создании сетевой энциклопедии, используя для этого браузеры своих операционных систем (будь то Microsoft Windows , GNU/Linux или любая другая операционная система) и не загружая дополнительных исполняемых модулей для работы с базой данных статей.

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

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

На стороне клиента используется:

• Flash
• ActiveX

См. также

Ссылки

• How Microsoft lost the API war - Обсуждение замены традиционных приложений Windows на веб-приложения
• Web Applications 1.0 документирование работы веб-приложений.
• The Other Road Ahead - Статья где утверждается что будущее за серверными, а не за клиентскими приложениями

Литература

• Марко Беллиньясо Разработка Web-приложений в среде ASP.NET 2.0: задача - проект - решение = ASP.NET 2.0 Website Programming: Problem - Design - Solution. - М.: «Диалектика» , 2007. - С. 640. - ISBN 0-7645-8464-2
• Олищук Андрей Владимирович Разработка Web-приложений на PHP 5. Профессиональная работа. - М.: «Вильямс» , 2006. - С. 352. - ISBN 5-8459-0944-9

Wikimedia Foundation . 2010 .

Смотреть что такое "Web-ориентированный интерфейс" в других словарях:

Возможно, эта статья содержит оригинальное исследование. Добавьте ссылки на источники, в противном случае она может быть выставлена на удаление. Дополнительные сведения могут быть на странице обсуждения. (25 мая 2011) … Википедия

Интерфейс пользователя (UI англ. user interface) совокупность средств, при помощи которых пользователь общается с различными устройствами, чаще всего с компьютером или бытовой техникой, либо иным сложным инструментарием (системой). Интерфейс… … Википедия