БЕЗОПАСНЫЙ И СТАБИЛЬНЫЙ ХОСТИНГ РАСШИРЕНИЙ ТРЕТЬИХ СТОРОН ДЛЯ ВЕБ-СЛУЖБ Российский патент 2011 года по МПК G06F15/16 

Родственная заявка

Данная заявка заявляет приоритет предварительной патентной заявки США № 60/692190, поданной 20 июня 2005.

Уровень техники

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

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

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

Даже с помощью первых двух вариантов код третьей стороны имеет доступ к полному сетевому стеку, таким образом, коммерческие веб-службы должны разместить брандмауэры (потенциально дорогостоящие многоуровневые брандмауэры) вокруг него, чтобы оградить его от нецелесообразной связи с серверами служб или чтобы оградить его от выполнения неподходящих действий, таких как отправка несанкционированной рассылки во внешний мир. Другим непрактичным решением для коммерческой веб-службы является запустить основанную на языке кода третьей стороны виртуальную машину, такую как Java Virtual Machine (JVM) компании Sun или. NET AppDomains. Притом, что они гораздо дешевле, чем физические аппаратные или VMM-решения, языковые VM-решения являются негибкими, сильно ограничивающими структуру кода третьей стороны, который может быть безопасно запущен. Также языковые VM-решения жертвуют безопасностью, увеличивая внешнюю уязвимость, поскольку они не могут адекватно сдерживать использование ресурсов.

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

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

Например, скажем, вымышленная компания, которую мы будем называть Hope Software Corporation (HSC), хочет расширить службу, называемую веб-службой отображения карты мира (WMWS). HSC желает расширить службу WMWS, отрисовывая дома с различных веб-сайтов и нанося списки недвижимости, получаемые от служб предоставления списков (MLS), на спутниковую карту из WMWS. Предполагая, что WMWS раскрывает необходимые интерфейсы прикладного программирования (API), чтобы построить это приложение, HSC все еще должен управлять операциями, навязанными существующим веб-приложением. Скажем, приложение HSC действительно популярно и становится характерной чертой на очень популярном веб-сайте. Теперь HSC должна обеспечить, чтобы его приложение было масштабируемым, чтобы управлять излишней нагрузкой, которая может произойти на несколько часов. HSC должна обеспечить, чтобы его приложение корректно переставало действовать в случае, когда одна из ее машин "умирает". HSC знает, что если они не могут обслужить своих клиентов в режиме 24×7, их обслужит кто-то еще.

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

Еще в одном примере, скажем, HSC может модифицировать (здесь "мод") массовую многопользовательскую онлайновую игру (MMOG) типа Everquest™ или World of Warcraft™. Поступая таким образом, HSC создает свои собственные зоны, монстров и искусственный интеллект (AI). Несмотря на огромный успех модов для клиентских игр, моды для MMOG нигде не увидеть, так как операторы MMOG не имеют безопасного и надежного механизма, чтобы изолировать моды на MMOG-серверах.

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

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

До сих пор мы описывали только Интернет-сценарии. Следует явно указать, что способы, описанные здесь, применимы к широкому диапазону вычислительных сценариев. Например, "веб-служба", которую необходимо расширить, может действительно быть любым произвольным вычислительным узлом, таким как устройство мобильного телефона или персональный компьютер. Он может быть даже произвольной вычислительной системой, такой как равноправная или решетчатая сеть. Рассмотрим проект типа SETI@home распределенной системы обработки для анализа радиосигналов. В этой схеме каждый владелец каждого ПК, разделяющий необходимость "доверять" программному обеспечению SETI@home, не может быть злонамеренным. Тем не менее, это программное обеспечение относительно фиксированно - невозможно случайному астроному, например, быстро использовать ресурсы этих нескольких тысяч компьютеров, чтобы оценить новый алгоритм анализа радиосигнала.

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

Сущность изобретения

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

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

Краткое описание чертежей

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

Фиг.1 - блок-схема осуществления, описанного в данном документе.

Фиг.2 - блок-схема осуществления, описанного в данном документе.

Фиг.3 - блок-схема, показывающая методологическое осуществление, описанное в данном документе.

Подробное описание

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

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

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

Контекст и примерные сценарии

Примерные варианты осуществления, описанные в данном документе, являются дополнительными к существующим веб-службам, предоставленным множеством компаний программного обеспечения и таким же образом предоставленным внешними сторонами. Примерные варианты осуществления нацелены на разработчиков типа Боба и Hope Software Company (HSC), которые были описаны в разделе "Уровень техники". Эти разработчики хотят расширить существующие службы или создать новые службы, не заботясь о функционировании служб.

Например, предположим, что HSC ищет дом для покупки в некоторых окрестностях Сиэтла: Королева Анна и Лиши. HSC тратит около 45 минут в день, объединяя списки домов для продажи по различным веб-службам списков недвижимости. HSC смотрит веб-службу карты мира (WMWS) и размышляет, как замечательно было бы видеть дома для продажи нанесенными на карту в WMWS. Это только побочный проект для HSC, который делается в свободное время.

HSC пишет код, чтобы отобразить данные из разных веб-служб списков недвижимости на WMWS. Затем HSC банально "публикует" это решение так, что его друзья также могут его использовать, так как HSC никогда не должен думать о том, где его разместить, как много это стоит, как покупать сервер и т.д. Поскольку решение HSC обретает популярность, HSC начинает добавлять больше признаков, наподобие статистики преступности, объектов для продажи, больше городов, возможности доступа с мобильных устройств и предупреждения об опасности. HSC покупает доменное имя, так же как и различные ключевые слова поисковой машины, чтобы направлять трафик к своему приложению. Веб-служба (которая применяет, по меньшей мере, один из примерных вариантов осуществления, описанных в данном документе) продолжает запускать свое решение для своей базы пользователей, которая теперь исчисляется в миллионах.

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

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

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

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

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

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

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

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

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

Изолированный процесс (IsoProc)

Фиг.1 показывает типичную хостовую вычислительную систему 100, которая имеет одно или более ядер обработки (к примеру, процессоров и связанных аппаратных средств) и одну или более подсистем памяти. Хостовая вычислительная система 100 может быть одним компьютером или множеством соединенных компьютеров, которые работают совместно.

Как показано на фиг.1, хостовая вычислительная система 100 имеет две разных подсистемы памяти: память 110 и аппаратные/программно-аппаратные средства 140. Память 110 является примером типичных подсистем памяти, в которых может быть сохранено программное обеспечение. Память 110 может быть любым доступным читаемым процессором носителем, который является доступным посредством хостовой вычислительной системы 100. Память 110 может быть либо энергозависимым, либо энергонезависимым носителем. Кроме того, она может быть либо съемным, либо несъемным носителем. Аппаратные/программно-аппаратные средства 140 являются примером типичных аппаратных средств (к примеру, ROM) или программно-аппаратных средств, в которых могут быть сохранены выполняемые компьютером инструкции.

На фиг.1 память 110 и аппаратные/программно-аппаратные средства 140 изображены как две отдельных области, чтобы подчеркнуть их разную природу, но с практической точки зрения, высокоуровневая операционная система может не делать сильных различий между ними. Действительно, выполняемые инструкции, сохраненные в аппаратных/программно-аппаратных средствах 140, могут быть частью адресуемого диапазона памяти 110.

Хостовая вычислительная система 100 имеет операционную систему (представленную как ядро 120 OS в памяти 110), которая предоставляет архитектуру для использования изолированных процессов программного обеспечения (SIP), таких как SIP 130 и SIP 140. В хостовой вычислительной системе 100 неядровый код в этой OS запускается в SIP. SIP связываются друг с другом, с OS и с сетью 180 связи через строго заданные каналы связи. Более подробно, SIP может только связаться с другими процессами и ядром через каналы связи, которые имеют специальное разрешение (от OS) на использование. Это разрешение определяет, как и какой SIP связывается с другими процессами, с OS и с сетью 180 связи.

Как изображено на фиг.1, аппаратные/программно-аппаратные средства 140 показывают примеры аппаратных изолированных процессов 150 (HIP) и программно-аппаратных изолированных процессов 160 (FIP). Они действительно идентичны SIP, кроме того, что их код не сохранен в рабочей первичной памяти (типа памяти 110).

С целью включения в терминологию термин "изолированный процесс" и его сокращенное представление "isoproc" используется в данном документе. Он определен как "изолированный процесс", и примеры его явно включают в себя SIP, HIP и FIP. Таким образом, если контекст явно не указывает иное, ссылка в данном документе на "isoproc" включает в себя концепции SIP, HIP и/или FIP.

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

Специальное разрешение, предоставленное посредством OS, определяет свойства связи ассоциированного определенного канала связи субъектного isoproc, где такие свойства включают в себя одно или более из следующего:

- с каким другим isoproc этот субъектный isoproc может осуществлять связь;

- ресурсы системы, к которым isoproc может получить доступ через канал;

- другие процессы системы, с которыми isoproc может взаимодействовать;

- способность получить доступ к механизмам связи (к примеру, TCP или веб-протоколам), чтобы осуществлять связь с другими системами;

- возможность осуществлять связь с конкретными системами;

- тип связи;

- скорость, объем и время связи.

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

Следующие патентные заявки США содержатся в данном документе по обращению:

- Заявка с порядковым № 11/118684, озаглавленная "Inter-Process Interference Elimination" и зарегистрированная 29 апреля 2005 года;

- Заявка с порядковым № 11/007655, озаглавленная "Inter-Process Communications Employing Bi-directional Message Conduits" и зарегистрированная 7 декабря 2004 года;

- Заявка с порядковым № 11/007808, озаглавленная "Self-Describing Artifacts and Application Abstractions" и зарегистрированная 7 декабря 2004 года.

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

Иллюстративное окружение

Фиг.2 показывает хостовое вычислительное окружение 200 (такое как веб-сервер) с операционной системой (представленной как ядро 210 OS), которая поддерживает и предусматривает процессы isoproc. Хостовое вычислительное окружение 200 предоставляет недорогое и безопасное окружение для хостинга для запуска кода третьей стороны, такого как isoproc 220 расширения. Третья сторона (к примеру, разработчик программного обеспечения или веб-службы) записывает свой isoproc 220 расширения так, что код запускается в своем собственном isoproc в хостовом вычислительном окружении 200.

OS 210 включает в себя регулятор 212 каналов связи, который является компонентом OS, который специально предоставляет разрешение для isoproc использовать каналы связи. Это разрешение определяет свойства связи определенного канала связи. Без специального разрешения от регулятора 212 канала связи isoproc 220 расширения буквально не может осуществить связь с любым другим кодом где-либо в мире (не говоря даже о сетевом стеке OS или файловой системе OS).

Для этого примерного варианта осуществления isoproc 220 расширения принимает входящие запросы от isoproc 230 сетевой службы по каналу 232 связи. Isoproc 230 сетевой службы действует как посредник между isoproc 220 расширения и внешней сетью 260 связи, такой как Интернет. Isoproc 230 сетевой службы отвечает за обработку связи между isoproc 220 расширения и внешним миром (к примеру, Интернетом 160). В альтернативном варианте осуществления isoproc 230 сетевой службы может быть заменен прямым соединением с внешней сетью 260 связи, когда isoproc 220 расширения статически проверяется и верифицируется, чтобы он не мог выполнять любую запрещенную операцию против внешней сети связи.

Isoproc 220 расширения осуществляет связь с isoproc 240 агента веб-службы в хостовой вычислительной системе с помощью предоставленного OS канала 242 связи между процессами. Isoproc 240 агента веб-службы действует как посредник между isoproc 220 расширения и другими внутренними веб-службами 250, такими как система базы данных, содержащая карты веб-служб всемирной картографии. Isoproc 240 агента веб-службы отвечает за управление запросами от isoproc 220 расширения и осуществляет связь с серверами 250 веб-службы. Чтобы сделать это, может быть применен любой эффективный и доступный протокол, такой как SOAP. В альтернативном варианте осуществления isoproc 240 агента веб-службы может быть заменен, когда фильтрующие признаки кода для isoproc 240 агента веб-службы верифицируемым образом вставляются в код isoproc 220 расширения.

Как изображено, каналы 232 и 242 являются только двумя предоставленными OS каналами связи между процессами, которые isoproc 220 расширения имеет специальное разрешение использовать.

Isoproc 230 сетевой службы и isoproc 240 агента веб-службы могут характерно называться "медиаторами". Они называются так из-за того, что они действуют как посредники или медиаторы между isoproc 220 расширения и другими источниками данных, такими как серверы 250 веб-службы и Интернет 260.

Каждый isoproc имеет отдельный и индивидуальный интерфейс с ядром OS (обычно именуемый интерфейсом прикладного программирования (API) или стандартный двоичный интерфейс прикладных программ (ABI)), через который каждый isoproc может запросить вычислительные ресурсы из OS, например, создание нового потока выполнения, но не может непосредственно повлиять на состояние любого другого isoproc. Этот интерфейс позволяет isoproc 220 расширения управлять своим собственным выполнением, но он не влияет на выполнение других isoproc. Умышленно этот интерфейс не может быть разрушен как механизм для связи между процессами. Интерфейс isoproc к ядру не может быть перехвачен, модифицирован или отслежено его содержимое без явного разрешения разработчика isoproc.

С помощью этого примерного окружения:

- Isoproc 220 расширения может осуществить связь только с медиатором, таким как isoproc 230 сетевой службы и isoproc 240 агента веб-службы.

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

- Isoproc 220 расширения осуществляет связь с обоими медиаторами (и любым другим isoproc) через полностью определенные, статически верифицируемые контракты.

Многие из этих isoproc расширения могут содержаться в единичном сервере, так как isoproc расширения являются маленькими (типично, служебные данные <400 Кб памяти RAM). Также имеется мало, до никаких, факторов мультиплексирования, обнаруженных в мониторах виртуальных машин.

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

Рассмотрим проект типа SETI@home распределенной системы обработки для анализа радиосигналов. В этой схеме каждый из собственников каждого персонального компьютера, разделяющий необходимость "доверять" программному обеспечению SETI@home, не может быть злонамеренным. Однако чтобы обеспечить этот уровень доверия, это программное обеспечение SETI@home является относительно фиксированным и неизменяемым. Следовательно, невозможно произвольному астроному, например, быстро использовать ресурсы этих тысяч компьютеров, чтобы оценить новый алгоритм анализа радиосигнала. С помощью технологий, описанных в данном документе, программное обеспечение может быть модифицируемым и все еще быть доверенным.

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

Методологическое осуществление

Фиг.3 показывает способ 300 предоставления безопасного, стабильного, надежного и масштабируемого операционного окружения для изолированных расширений веб-служб. Этот способ 300 выполняется одним или более из различных компонентов, как изображено на фиг.1 и/или 2. Кроме того, этот способ 300 может быть выполнен в программном обеспечении, аппаратных средствах, программно-аппаратных средствах или их комбинации.

Для легкости понимания этот способ изображен как отдельные этапы, представленные как независимые блоки на фиг.3; однако эти отдельно изображенные этапы не должны быть истолкованы как обязательный порядок в зависимости от их выполнения. Дополнительно, в целях обсуждения, способ 300 описывается со ссылкой на фиг.1 и/или 2. Также в целях обсуждения отдельные компоненты указаны как выполняющие отдельные функции; однако другие компоненты (или комбинации компонентов) могут выполнять отдельные функции.

На этапе 310 на фиг.3 вычислительное операционное окружение (такое как хостовое вычислительное окружение 200 веб-службы) предоставляет стандартный набор веб-служб через сеть связи (такую как интернет 260).

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

На этапе 330 на фиг.3 операционное окружение компьютера изолирует расширенные процессы ("isoproc расширения") от стандартного набора веб-служб и от сети связи. Веб-службы являются другими процессами isoproc. Возможность каждого isoproc осуществлять связь ограничена только определенными каналами связи, по которым он имеет специальное разрешение осуществлять связь.

Заключение

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

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

Изобретение относится к области обеспечения безопасности и стабильности хостинга расширений третьих сторон для веб-служб. Техническим результатом является обеспечение безопасности работы веб-служб за счет изолирования расширения третьей стороны. Вычислительное операционное окружение содержит: хостовую вычислительную систему, причем хостовая вычислительная система сконфигурирована, чтобы выполнять исполняемые компьютером инструкции операционной системы (ОС), которая поддерживает и обеспечивает первый и второй выполняющиеся изолированные процессы (isoproc), причем каждый выполняющийся isoproc способен осуществлять связь с другим выполняющимся isoproc только с помощью одного или более определенных заданных каналов связи между ними; регулятор канала связи, сконфигурированный выборочно предоставлять первому выполняющемуся isoproc специальное разрешение осуществлять связь по одному или более определенным заданным каналам связи ко второму выполняющемуся isoproc, скрывающий или фильтрующий механизм, выполненный с возможностью скрывать данные от выполняющихся isoproc. 3 н. и 16 з.п. ф-лы, 3 ил.

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

2. Вычислительное операционное окружение по п.1, в котором первый выполняющийся isoproc выбирается из группы, состоящей из аппаратного изолированного процесса (HIР), программно-аппаратного изолированного процесса (FIP) и программного изолированного процесса (SIP).

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

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

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

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

7. Вычислительное операционное окружение по п.1, в котором вычислительное операционное окружение является массовой многопользовательской онлайновой игрой.

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

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

10. Вычислительное операционное окружение по п.1, в котором регулятор канала связи дополнительно выполнен с возможностью предотвращать первый выполняющийся isoproc от получения доступа к ресурсам других выполняющихся isoproc за исключением второго выполняющегося isoproc.

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

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

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

14. Машиночитаемый носитель данных по п.13, в котором определенный стандартный isoproc представляет массовую многопользовательскую онлайновую игру (MMOG), а расширенный isoproc является "модом" к MMOG.

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

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

17. Машиночитаемый носитель данных по п.16, в котором каждый член стандартного набора веб-служб и расширенный isoproc выбирается из группы, состоящей из аппаратного изолированного процесса (HIP), программно-аппаратного изолированного процесса (FIP) и программного изолированного процесса (SIP).

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

19. Машиночитаемый носитель данных по п.16, в котором действие изоляции характеризуется определением того, с какими другими процессами расширенный isoproc может осуществлять связь, и регулированием такой связи между ними.