Инфраструктура службы на стороне сервера

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

 

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

В системе, включающей в себя клиентский компонент ("клиент") и серверный компонент ("сервер"), сервер может раскрывать для использования службу, которую клиент может использовать. Традиционно, чтобы раскрыть для использования службу, разработчик пишет специальный файл со специальным расширением для службы. Например, в платформе Microsoft. NET™ веб-служба раскрывается для использования как результат существования ASMX-файла на сервере, специальным расширением является ASMX. Веб-служба обычно предоставляет один или более способов, существующих на сервере, которые позволяют клиенту вызывать, чтобы получить определенную информацию. Веб-служба обычно вызывается через использование URL. Например, URL http://www.xyz.com/app/login.asmx ведет к службе регистрации на сервере XYZ.com. В типичном случае, URL направляет к физическому файлу, такому как АSМХ-файл, существующему на сервере. Клиент может вызывать веб-службу, используя URL, который ведет к ASMX-файлу на сервере.

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

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

Раскрытие изобретения

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

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

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

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

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

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

Упомянутые выше аспекты и многие из сопутствующих преимуществ этого изобретения, станут более легко очевидными, как и более понятыми, посредством ссылки к последующему подробному описанию, приведенному вместе с сопровождающими чертежами, где:

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

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

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

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

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

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

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

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

Осуществление изобретения

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

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

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

Фиг.1 иллюстрирует примерную распределенную вычислительную систему 100, которая включает в себя, по меньшей мере, одного клиента 102 и, по меньшей мере, один сервер 104. Сервер 104 предоставляет, по меньшей мере, одну раскрытую для использования службу 105, такую как веб-служба, которую клиент 102 может использовать. Веб-служба, как правило, предоставляет один или более способов, существующих на сервере, которые предоставляют клиенту возможность вызывать для получения определенную информацию. Следующий код иллюстрирует примерную веб-службу SimpleService, раскрытую для использования на сервере 104.

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

В примерном варианте осуществления изобретения ссылка на класс-посредник 108 для сервера 104 предоставляется клиенту 102, например, разработчиком клиента 102, который знает, что клиенту 102 может быть необходимо использовать раскрытую для использования службу 105, предоставляемую сервером 104. Таким образом, после того, как клиент 102 определяет, что ему необходимо использовать службу 105, описанную в классе-посреднике 108, клиент 102 отправляет запрос 106 класса-посредника серверу 104, используя ссылку. Сервер 104 затем возвращает класс-посредник 108. Клиент 102 определяет, что предлагается сервером 104, проверяя класс-посредник 108. Посредством осмотра клиент 102 узнает, какие способы он может вызвать, чтобы использовать раскрытую для использования службу 105. Клиент 102 затем делает запрос 110 раскрытой для использования службы 105, используя информацию, предоставляемую в классе-посреднике 108. Например, клиент 102 может вызвать заданный способ, предложенный раскрытой для использования службой 105.

Следующий текст иллюстрирует примерное содержимое в классе-посреднике 108 для раскрытой для использования службы SimpleService.

Type.registerNamespace('Acme');

Acme.SimpleServlce=

{path: "/app/AtlasServices/Acme/SimpleService.asmx", Hello World: function(onMethodComplete, onMethodTimeout) {return Atlas.Net.ServiceMethodRequest.callMethod (this.path, "Hello World", {}, onMethodComplete, onMethodTimeout);} }

В вариантах осуществления изобретения информация о типе, содержащаяся в классе-посреднике 108, для службы, такой как служба 105, предоставляет указатель для сервера 104, чтобы найти службу. Информация о типе может быть, к примеру, именем типа службы, URL, ведущим к службе, и/или наименованием способа службы. Например, в примерном содержимом в классе-посреднике 108 для раскрытой для использования службы SimpleService, показанной выше, информация о типе для предоставленной службы SimpleService включает в себя имя типа Acme.SimpleService, URL "/app/AtlasServices/Acme/SimpleService.asmx", и имя способа "Hello World".

Также, показанное выше примерное содержимое в классе-посреднике 108 для примерной SimpleService, класс-посредник 108 включает в себя путь, который ведет к раскрытой для использования службе 105, такой как примерная SimpleService на сервере 104. В вариантах осуществления изобретения путь, ведущий к раскрытой для использования службе 105, может быть традиционным путем, псевдовиртуальным путем или зашифрованным путем. Фиг.2А-2С предоставляют пример для каждого из трех типов пути.

В типичном варианте традиционный путь ведет к физическому файлу на сервере 104, который содержит раскрытую для использования службу 105. Фиг.2А иллюстрирует примерный традиционный путь 200

http://server/app/folder/SimpleService.asmx. Традиционный путь 200 направляет к физическому файлу - SimpleService.asmx - на сервере 104.

Фиг.2В иллюстрирует примерный псевдовиртуальный путь 240. Внешне псевдовиртуальный путь 240 выглядит подобно традиционному пути 200. Однако псевдовиртуальный путь 240 фактически не указывает соответствие с физическим файлом так, как это делает традиционный путь 200. Псевдовиртуальный путь 240 фактически устанавливает соответствие с раскрытой для использования службой 105. Как показано на фиг.2В, псевдовиртуальный путь 240 включает в себя специальный маркер 242 и специальный синтаксис 244. В вариантах осуществления изобретения специальный маркер 242 и специальный синтаксис 244 могут быть составлены в любом синтаксисе или формате, который сервер 104 может распознать. Например, в некоторых вариантах осуществления изобретения специальный маркер 242 и специальный синтаксис 244 выступают как один объект, хотя сервер 104 может распознать части специального маркера 242 и специального синтаксиса 244 в объекте. Вышеуказанный код для примерного класса-посредника для примерной раскрытой для использования службы SimpleService иллюстрирует псевдовиртуальный путь для примерной SimpleService. Путь читается как "/app/AtlasServices/Acme/SimpleService.asmx". "AtlasServices/Acme" в пути функционирует как специальный маркер 242, указывающий, что путь является псевдовиртуальным путем. "SimpleService.asmx" в пути является примерным специальным синтаксисом 244, устанавливающим соответствие с раскрытой для использования SimpleService.

В вариантах осуществления изобретения существование специального маркера 242 в пути помогает серверу 104 определить, что путь функционирует как псевдовиртуальный путь 240, а не как традиционный путь 200, который ведет к местоположению физического файла. Специальный маркер 242 указывает, что содержимое, которое следует за специальным маркером 242 в пути, является специальным синтаксисом 244. Специальный синтаксис 244 предоставляет описание того, чем является раскрытая для использования служба 105. Специальный синтаксис 244 не устанавливает соответствие псевдовиртуального пути 240 с физическим файлом на сервере 104. Специальный синтаксис, хотя он выглядит почти аналогично обычному пути, в типичном варианте содержит информацию о типе, ассоциативно связанную с раскрытой для использования службой 105. Например, информация о типе может раскрывать имя типа раскрытой для использования службы 105.

Когда показано открыто, информация о типе, раскрытая в специальном синтаксисе 244, может дать возможность клиенту 102 предположить и вызвать способы службы, к которым клиент 102 не должен получить доступ. Например, клиент 102 может предположить, что служба, предоставленная ссылкой http://Server/App/Special_Token/Forbidden.asmx, может содержать способ "Forbidden()" и произвести вызов способа "Forbidden()", где, фактически, способ "Forbidden()" предоставляется службой, а клиент 102 не должен иметь доступа к нему.

Чтобы предотвратить излишние раскрытие серверной информации, примерные варианты осуществления изобретения шифруют псевдовиртуальный путь 240. Фиг.2С иллюстрирует примерный зашифрованный путь 260. Зашифрованный путь 260 может содержать традиционный путь 200 или псевдовиртуальный путь 240. В примерном варианте осуществления изобретения зашифрованное содержимое 262 в зашифрованном псевдовиртуальном пути содержит только специальный синтаксис 244, который устанавливает соответствие непосредственно с раскрытой для использования службой 105. В альтернативном варианте осуществления изобретения зашифрованное содержимое 262 в зашифрованном псевдовиртуальном пути содержит и специальный маркер 242, и специальный синтаксис 244.

В примерных вариантах осуществления изобретения неважно, какой тип пути, к примеру, традиционный путь или псевдовиртуальный путь, используется в классе-посреднике 108, чтобы представить раскрытую для использования службу 105, все, что клиент 102 воспринимает из пути, это URL для раскрытой для использования службы 105. Клиент 102 отправляет путь, т.е. URL, серверу 104, чтобы запросить раскрытую для использования службу 105. Сервер 104 интерпретирует принятый путь, чтобы определить, является ли принятый путь традиционным путем 200, псевдовиртуальным путем 240 или зашифрованным путем 260. Когда сервер 104 обнаруживает зашифрованную информацию в пути, он сначала дешифрует зашифрованную информацию. Сервер 104 затем использует дешифрованную информацию, чтобы определить, является ли путь псевдовиртуальным путем или традиционным путем. Например, если сервер 104 обнаруживает специальный маркер 242 в принятом пути, сервер 104 определяет, что принятый путь является псевдовиртуальным путем 240, и что содержимое после специального маркера 242 является специальным синтаксисом 244, устанавливающим соответствие непосредственно с раскрытой для использования службой 105.

Как иллюстрировано на фиг.6, в примерном варианте осуществления изобретения, чтобы предоставить для использования службу 105 так, что она может быть вызвана клиентом 102, служба 105 сначала регистрируется через интерфейс 600 прикладного программирования ("API"). API 600 может быть реализован на одном или более считываемом компьютером носителях и содержать функции, относящиеся к формированию псевдовиртуального пути 240 для предоставленной службы 105 на сервере 104. API 600 создает псевдовиртуальный путь 240 для службы 105. Псевдовиртуальный путь 240 затем включается в класс-посредник 108 для сервера 104. Как показано на фиг.1, когда клиент 102 запрашивает класс-посредник 108, сервер 104 отправляет класс-посредник 108, содержащий псевдовиртуальный путь 240, клиенту 102. Клиент 102 может, таким образом, обратиться за доступом к предоставленной для использования службе 105 с помощью псевдовиртуального пути 240.

Фиг.3А иллюстрирует примерный процесс 300 для предоставления для использования серверной службы с помощью псевдовиртуального пути. В типичном варианте процесс 300 формирует псевдовиртуальный путь для каждой раскрытой для использования службы на сервере. При приеме запроса от клиента на раскрытую для использования службу, сервер определяет, включает ли в себя запрос псевдовиртуальный путь или традиционный путь, и соответственно поставляет раскрытую для использования службу. В примерном варианте осуществления, как иллюстрировано, процесс 300 начинается выполнением подпрограммы 302, которая формирует и предоставляет потенциальным клиентам псевдовиртуальный путь для раскрытой для использования службы на сервере. Фиг.4 иллюстрирует примерное осуществление программы 302 и далее будет описана подробно. Альтернативно, потенциальный клиент для раскрытой для использования службы может принять традиционный путь к службе. Клиент, который желает получить доступ к раскрытой для использования службе, отправит запрос службы серверу. Такой запрос может содержать псевдовиртуальный путь, традиционный путь, или зашифрованный путь, который включает в себя либо псевдовиртуальный путь, либо традиционный путь. Следовательно, при определении того, что сервер принял запрос службы от клиента (см. блок 304 ветвления), процесс 300 переходит к выполнению другой программы 306, которая определяет, включает ли в себя принятый запрос службы псевдовиртуальный путь. См. блок 306. Фиг.5 иллюстрирует примерное осуществление программы 306 и далее будет описана подробно.

После выполнения программы 306 процесс 300 переходит к определению того, включает ли в себя запрос службы от клиента псевдовиртуальный путь. См. блок 308 ветвления. Если ответ для блока 308 ветвления - НЕТ, процесс 300 переходит к обработке запроса службы, как включающего в себя традиционный путь, который устанавливает соответствие с физическим файлом для раскрытой для использования службы, и предоставляет физический файл клиенту. См. блок 310. Процесс 300 тогда завершается. Если ответ к блоку 308 ветвления - ДА, тогда запрос службы включает в себя псевдовиртуальный путь; процесс 300 переходит к предоставлению клиенту службы, представленной в специальном синтаксисе псевдовиртуального пути. См. блок 312. Процесс 300 тогда завершается.

Фиг.4 иллюстрирует примерную подпрограмму 302 предоставления псевдовиртуального пути любому клиенту, предназначенному, чтобы использовать службы, предоставляемые для использования на сервере. Подпрограмма 302 сначала формирует псевдовиртуальный путь для раскрытой для использования серверной службы. См. блок 402. В вариантах осуществления изобретения псевдовиртуальный путь может быть сформирован разными средствами. Например, как отмечено выше, раскрытая для использования служба может быть передана в API, который формирует псевдовиртуальный путь для службы. Альтернативно, псевдовиртуальный путь может быть создан вручную или скриптом (сценарием).

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

Фиг.5 иллюстрирует примерную подпрограмму 306, которая определяет, включает ли в себя запрос службы, отправленный клиентом, псевдовиртуальный путь. Подпрограмма 306 начинается синтаксическим разбором запроса службы. См. блок 502. Подпрограмма 306 тогда решает, содержит ли запрос службы какое-либо зашифрованное содержимое. См. блок 504 ветвления. Если запрос службы включает в себя зашифрованное содержимое, программа 306 переходит к дешифрованию зашифрованного содержимого. См. блок 506. Если ответ на блок 504 ветвления - НЕТ, означающий, что запрос службы содержит обычный текст, или если подпрограмма 306 дешифровала какое-либо зашифрованное содержимое, программа 306 переходит к определению того, включает ли в себя запрос службы специальный маркер, указывающий присутствие псевдовиртуального пути. См. блок 508 ветвления. Если ответ на блок 508 ветвления - ДА, означающий, что запрос службы включает в себя псевдовиртуальный путь, подпрограмма 306 возвращает значение ИСТИНА и завершается. См. блок 512. Если ответ на блок 508 ветвления - НЕТ, означающий, что запрос службы не включает в себя псевдовиртуальный путь, программа 306 возвращает значение ЛОЖЬ и завершается. См. блок 510.

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

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

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

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

3. Способ по п.1, в котором псевдо-виртуальный путь зашифрован.

4. Способ по п.3, в котором только часть со специальным синтаксисом псевдо-виртуального пути зашифрована.

5. Способ по п.3, в котором как специальный маркер, так и специальный синтаксис в псевдо-виртуальном пути зашифрованы.

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

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

8. Реализуемый на компьютере способ по п.6, в котором класс-посредник идентифицирует по меньшей мере одну службу, предоставленную сервером.

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

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

11. Вычислительная система по п.9, в которой псевдо-виртуальный путь зашифрован.

12. Вычислительная система по п.11, в которой только специальный синтаксис в псевдо-виртуальном пути зашифрован.

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

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

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