Поделиться через

Определение концепции

  • Статья

 

Мэри Киртланд
Microsoft Corporation

10 января 2001 г.

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

Благодарим всех за ваши комментарии и отзывы. Мы отслеживаем вопросы, которые вы поднимаете, так что продолжайте!

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

В некоторых комментариях также предполагается, что для разработки этого примера используется платформа .NET Framework. Это не обязательно так. Мы будем использовать все технологии, которые мы считаем лучшими для работы. И лучшее не всегда означает технически выше, проще в использовании, или большинство в новостях. Что бы мы ни выбрали, мы расскажем вам, почему и расскажем, какие проблемы мы столкнулись, когда мы пытались использовать его.

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

Приступая к работе

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

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

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

  • Вы являетесь источником чувствительных к времени или параметризованных данных, которые хотят использовать конечные пользователи или другие организации. Если данные не меняются часто и клиентам почти всегда нужны все данные, можно просто опубликовать XML-документ на веб-сайте. Но если клиенты хотят выполнять запросы к вашим данным, то веб-служба имеет смысл. Если вы хотите отправить данные клиентам, операции подписки и уведомлений также являются потенциальными веб-службами.
  • Вы реализуете алгоритмы, которые другие компании не могут или не хотят реализовывать сами. В этом случае каждый алгоритм является потенциальной веб-службой: клиенты передают данные, а вы отвечаете ответом.
  • Вы объединяете несколько других служб для предоставления службы более высокого уровня. В этом случае клиенты используют вашу службу, так как она предоставляет сочетание нужных сведений, сохраняя их работу по объединению существующих служб.
  • Вы хотите интегрировать бизнес-процессы с партнерами. Каждый этап бизнес-процесса, который проходит через границу предприятия, является потенциальной операцией веб-службы или веб-службы.
  • У вас есть разнородная и (или) географически распределенная корпоративная архитектура, в которой использование частных сетей или тесно связанных протоколов для интеграции приложений нецелесообразно. API каждого приложения, которое требуется интегрировать, является потенциальной веб-службой.
  • Вы предоставляете службы инфраструктуры ("сантехника") для других разработчиков веб-приложений и веб-служб, например службы удостоверений или службы выставления счетов. Вместо создания пользовательских библиотек API для каждой клиентской платформы можно предоставить API в виде веб-службы.

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

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

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

Видение, ред. 1

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

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

Вот первый разрез в нашем видении проекта:

  • The server-side Favorites Service will enable Web surfers to store their favorite links in a safe, secure, central location, so their favorites are accessible anywhere, any time. We will offer the service free of charge to all users; however because we want to protect each user's privacy, users will need to be authenticated to access their favorites. By using the service through a client Web site, users agree that we may use their favorite lists after all personally identifying information is stripped from the data. На втором этапе этого проекта мы лицензироваем дополнительные службы для веб-сайтов. Пример:
    • Статистические данные о том, какие страницы с их сайтов добавляются в закладки.
    • Рекомендуемые ссылки на основе анализа сходства всех избранных пользователей.

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

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

Возможно, некоторые дополнительные исследования были в порядке.

Видение, ред. 2

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

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

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

Наше измененное видение выглядит следующим образом:

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

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

Мы определили этапы следующим образом:

  • На первом этапе мы реализуем и развернем веб-службу избранного, которая может быть лицензирована разработчикам веб-сайтов для использования в фоновом режиме для управления избранной своих клиентов. (Фактически каждый пользователь имеет личное хранилище данных избранного пользователей.) Мы также предоставим пример, показывающий, как интегрировать службу избранного в веб-сайт. Служба и пример будут доступны для лицензирования до 1 марта 2001 г. Наша цель состоит в том, чтобы лицензировать службу к 1 марта 2001 года, на 5-10 сайтов, которые представляют примерно 10000 новых пользователей в месяц. (Мы считаем, что это управляемый темп роста, учитывая наши нынешние сотрудники.)
  • На втором этапе мы реализуем расширения браузера для интернет-Обозреватель и Netscape Navigator, которые предоставят конечным пользователям безопасный и безопасный способ управления избранного на любом веб-сайте так же, как они управляют избранными на стороне клиента сегодня. Мы также реализуем и развертываем веб-сайт, который пользователи могут использовать для управления избранным, чтения нашего заявления о конфиденциальности, настройки параметров профиля пользователя в отношении использования личных данных и загрузки расширений браузера. Расширения браузера и веб-сайт будут поставлены до 1 мая 2001 года. Наша цель — охватить 1000 новых пользователей в месяц.
  • На третьем этапе мы расширим веб-службу избранного, чтобы конечные пользователи могли видеть как избранное, сохраненное ими напрямую (через надстройку браузера или веб-сайт избранного), так и избранное, сохраненное через лицензирований службы "Избранное". У лицензий будет возможность отображения специального логотипа, который позволяет конечным пользователям узнать, что используется служба "Избранное консультантов" (и, следовательно, эти избранное также будут доступны через надстройку браузера или веб-сайт избранного). Лицензии также могут продолжать использовать службу избранного в фоновом режиме. В этом случае избранное, хранящееся на этом сайте, будет недоступно через надстройку браузера или веб-сайт избранного. Третий этап будет осуществляться к 1 июня 2001 года.
    Третий этап обеспечивает основу для будущих веб-служб. Например, если пользователь посещает веб-страницу, на сайте может отображаться список веб-страниц, которые также понравились другим пользователям. Веб-сайт получает список страниц из веб-службы. Мы еще не решили, следует ли реализовать этот тип службы профилирования.

С этим мы могли бы конкретизировать остальную часть документа Видение.

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

  • Конечные пользователи — все, кто использует веб-браузер для посещения веб-сайтов.
  • Лицензии — любая компания с веб-сайтом, использующим службу избранного.
  • Разработчики лицензий — разработчики, создающий веб-сайт лицензированного.
  • Операторы лицензий — операторы веб-сайта лицензирований.
  • Операторы — пользователи, ответственные за работу службы избранного.

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

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

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

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

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

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

Остальные бизнес-цели и цели проектирования можно найти в документе "Визуальное представление избранного".

Заключение

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

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

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

Увидимся!

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