Статьи

Как прикладные сервисы устроены сейчас?

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

Хорошо, это радикальный взгляд на вещи. Скажем мягче: каждый сервис кроме специфичных для него прикладных функций реализует набор универсальных функций, свойственных всем остальным сервисам. Например, и ЖЖ, и Job.ru косвенно предоставляют своим пользователям услуги хостинга, поскольку хранят у себя их данные. И Job.ru, и Лавпленет, а также их многочисленные конкуренты, помогают пользователю структурировать данные о собственной персоне, поскольку предлагают заполнить анкету.

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

Что в этом плохого?

Есть две крупные неприятности и несколько помельче.

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

Во-вторых, нам приходится работать с разрозненными данными об одном и том же. Сайты Job.ru. Superjob.ru, Rabota.ru и т. п. предлагают пользователю практически одинаковые анкеты, но искать каждый из них позволяет только по собственной базе данных. В результате пользователь вынужден либо сузить круг возможных контактов, ограничившись одним из них, либо потратить много времени на работу с несколькими наиболее популярными ресурсами. Похожая история с социальными сетями. Хорошо, когда все твои коллеги собрались в Linked In, но если они вдобавок рассеяны по «Моему Кругу», «Профессионалам» и Software People, желание вступать в любую из этих сетей пропадает.

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

Как надо все переделать?

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

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

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

c) Наиболее важные типы базовых сервисов:

- ведение пользовательских профилей;

- структурирование и редактирование контента;

- ответственное хранение контента, т. е. хостинг;

- поиск структурированного (и не очень, но таковой будет вымирать) контента;

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

Как люди будут с этим работать?

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

Будем считать, что речь идет о пользователе-читателе, у которого еще нет никаких собственных ресурсов в Интернете. Он совершает следующие шаги:

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

b) Получение хостинга. Дальше пользователь приобретает площадку для размещения своих данных. Он находит тот сервис, который его устраивает по набору услуг и условиям их предоставления, и регистрируется на нем, указывая ссылку на свой основной профиль. Хостинг отправляет запрос сервису профилей, а сервис профилей просит пользователя подтвердить запрос. Нечто похожее происходит при использовании OpenID в форумах и блогах. После подтверждения запроса на хостинге автоматически создается учетная запись, ссылающаяся на основной профиль пользователя, и выделяются заказанные мощности.

c) Создание и публикация контента. Теперь предположим, что упомянутый пользователь хочет составить свое резюме и опубликовать его в Интернете таким образом, чтобы оно сделалось доступно любому заинтересованному работодателю. Он набирает в Гугле слова «бланк резюме» и получает множество ссылок на сервисы, которые предлагают различные формы резюме и пользовательский интерфейс для их заполнения. На одном из них он заполняет резюме и сохраняет его на свой хостинг. При этом он указывает (хостингу) что сохраняемый документ является публичным. Тогда хостинг вносит его в свой каталог, доступный поисковикам. Через время краткое резюме нашего героя оказывается в индексах.

Теперь представим себе пользователя, который ищет сотрудника

Работодатель идет в поисковик, набирает там слово «резюме» и нажимает на кнопку «Задать критерии поиска» (пусть специалисты по юзабилити придумают название покороче).

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

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

Схема взаимодействия межу редактором документов, хостингом и поисковиком показана на рисунке. Редакторов, хостингов и поисковиков в Интернете может быть сколько угодно. Я могу завести себе хостинг на любом сервисе, который предоставляет такую услугу, и сохранять туда документы из любых редакторов. Если я объявляю документ публичным, он будет обнаружен и проиндексирован всеми поисковиками.

Куда девать сложную бизнес-логику?

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

Есть разные варианты.

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

1. Запрашиваем у поисковика форму для поиска резюме.

2. Предлагаем пользователю заполнить ее.

3. После того, как пользователь заполнил форму, отправляем такой же запрос поисковику.

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

5. Выдаем пользователю страницу, на которой отобранные резюме упорядочены по убыванию толковости.

Можно представить себе более тесную интеграцию между поисковыми порталами и приложениями.

a) Каждый уважающий себя поисковик поддерживает стандартный интерфейс между порталами и плагинами в части портала.

b) Каждое уважающее себя приложение поддерживает стандартный интерфейс между порталами и плагинами в части плагина.

c) Авторы приложения размещают его на сервере приложений (примерно так же, как пользователи могут размещать свой контент на хостинге).

d) Поисковик при очередной переиндексации Сети находит новое приложение и включает его в свой ассортимент плагинов.

e) Пользователь поискового портала получает доступ к функциональности приложения через интерфейс поискового портала.

Если ты такой умный, то почему ты такой бедный?

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