KR20060080132A

KR20060080132A - 통신을 위한 방법, 프로토콜, 및 서버-클라이언트 환경에네트워킹된 애플리케이션을 제공하는 시스템

Info

Publication number: KR20060080132A
Application number: KR1020060000973A
Authority: KR
Inventors: 아디탸 반소드; 천 유 왕; 월터 씨. 슈
Original assignee: 마이크로소프트 코포레이션
Priority date: 2005-01-04
Filing date: 2006-01-04
Publication date: 2006-07-07
Also published as: JP2006195979A; BRPI0600004A; CA2531919A1; EP1677488A1; MXPA06000106A

Abstract

제1 컴퓨터와 제2 컴퓨터 간의 통신을 위한 방법과 프로토콜, 및 서버-클라이언트 환경에 네트워킹된 애플리케이션을 제공하는 시스템이 개시된다. 프로토콜은 제1 컴퓨터로부터 제2 컴퓨터로의, 제2 컴퓨터 상의 함수에 대한 함수 식별자 및 이 함수에 대한 인수를 포함하는 요청을 포함한다. 인수는 함수 식별자에 의해 호출되는 함수에 대한 유형에 의해 정의될 수 있다. 프로토콜은 또한 제2 컴퓨터로부터 제1 컴퓨터로의, 함수의 결과를 포함하며 제1 컴퓨터에 대한 스크립트 입력으로서 정의된 응답을 포함한다. 클라이언트-서버 환경에서 네트워킹된 애플리케이션을 제공하는 시스템은 서버 상의 애플리케이션 함수의 세트를 포함하며, 이 애플리케이션 함수는 데이터 유형 정의를 포함하고 클라이언트 함수의 세트는 스크립트 환경을 정의한다. 클라이언트 함수는 서버 상의 애플리케이션 함수 각각과 매칭하는 유형을 포함하도록 정의된다.

클라이언트 함수, 클라이언트-서버 환경, 네트워킹된 애플리케이션, 스크립트 환경

Description

통신을 위한 방법, 프로토콜, 및 서버-클라이언트 환경에 네트워킹된 애플리케이션을 제공하는 시스템{WEB APPLICATION ARCHITECTURE}

도 1은 본 발명을 구현하는 데에 적절한 컴퓨터 하드웨어의 블럭도.

도 2는 본 발명의 한 양태에 따른 서버 개발 환경의 클라이언트 측 프록시들을 생성하는 본 발명의 일반적인 방법을 도시하는 흐름도.

도 3은 도 2에서 생성된 프록시 환경을 획득하는 클라이언트 측 방법을 도시하는 도면.

도 4는 본 발명의 아키텍처를 구현하는 데에 적절한 시스템의 일 실시예의 블럭도.

도 5는 본 발명의 기본적인 아키텍처를 이용하는 웹 기반 애플리케이션의 운영을 위한 클라이언트와 서버의 대화의 일 실시예를 도시하는 흐름도.

도 6은 서버 측 객체 정의와 클라이언트 측 프록시 객체 정의의 비교.

도 7은 서버 인터페이스 및 이 메소드와 관련된 대응하는 자바스크립트 스텁(stub)의 제1 예를 도시하는 도면.

도 8은 본 발명의 방법을 구현하기 위하여 프로토콜을 이용하는 서버로의 클라이언트 요청 및 서버로부터의 응답의 예를 도시하는 도면.

도 9는 서버 측 인터페이스 및 대응하는 자바스크립트 스텁의 제2 예를 도시 하는 도면.

도 10은 서버 측 인터페이스 및 대응하는 자바스크립트 스텁의 제3 예를 도시하는 도면.

도 11은 서버 측 인터페이스 및 대응하는 자바스크립트 스텁의 제4 예를 도시하는 도면.

도 12는 본 발명에 따른 응답 프로토콜에서의 포스트(post)의 제2 예를 도시하는 도면.

도 13은 본 발명에 따라 클라이언트가 이 클라이언트에 의한 동기식 프록시 호출 및 비동기식 프록시 호출을 제어하는 방법을 도시하는 흐름도.

<도면의 주요 부분에 대한 부호의 설명>

120: 프로세싱 유닛

130: 시스템 메모리

218: 자바 스크립트 스텁

230: 데이터 계층

424: 사용자 인터페이스

460: 클라이언트 장치

484: 객체

본 발명은 네트워크 기반 애플리케이션을 제공하는 것에 관한 것으로, 보다 상세히는 인터넷 및 웹-기반 애플리케이션을 제공하는 것에 적용가능한 것이다.

인터넷 기반 애플리케이션이 보다 강력해짐에 따라, 자연스럽고 응답성 있는 사용자 경험을 유지하는 것은 개발자들에게 중요한 특징이 되었다. 웹-기반 애플리케이션은 일반적으로 클라이언트 컴퓨터에서 실행되는 웹 브라우저 애플리케이션을 이용하여 액세스되는 서버 상에 제공되는 하나 이상의 함수들을 포함한다. 클라이언트(웹 브라우저) 및 서버가 고속인 방식으로 통신하기 위하여, 이들 간의, 통신 프로토콜, 일반적으로 HTTP의 효과적인 이용이 요구된다.

일반적으로, 웹 브라우저는 서버로부터 페이지 및 함수(통상적으로 HTML과 같은 마크업 언어의 형태로 되어 있음)를 수신함으로써 애플리케이션으로의 인터페이스, 또는 애플리케이션의 기능적 컴포넌트를 렌더링(render)한다. 몇몇의 경우에서, 브라우저는 서버에 위치된 페이지의 요청에 대한 각각의 응답으로 수신된 데이터의 새로운 페이지를 렌더링해야 한다. 이러한 정보를 제공하기 위한 하나의 일반적인 포맷은 HTTP(Hyper Text Transfer Protocol)이다. 통상적으로, 웹 브라우저는 HTTP에서의 "GET" 또는 "POST" 명령을 이용하여 웹 페이지를 요청할 것이고, 웹 페이지를 렌더링하는 데에 필요한 모든 정보를 웹 브라우저에 반환할 것이다. 페이지를 렌더링하는 데에 필요한 정보와 같은 소정 양의 데이터는 사용자가 페이지의 오직 일부만 갱신하고 있을 때에도 여러 횟수 반복될 수 있다. 웹 브라우저로부터 간단한 데이터 요청들을 갱신함으로써 페이지의 오직 일부에서만 데이터를 갱신하는 기법들이 개발되었지만, 이러한 프로토콜은 개발자가 웹 기반 애플 리케이션에서 이용가능한 기본 메소드로의 완전한 액세스를 할 수 있게 하는 데에 있어 완전하게 유연성 있지는 않았다.

브라우저가 원격 서버 상의 객체 및 클래스에서의 메소드 호출을 원격적으로 할 수 있도록 하는 클라이언트 서버 프로토콜의 현재 예들은 SOAP(Simple Object Access Protocol) 및 XML-RPC를 포함한다. SOAP 및 XML-RPC는 둘 다 클라이언트가 전송 데이터 유형을 이해하기를 요구한다. 이 두 프로토콜은 XML로 된 파라미터 및 반환 값을 인코딩하는 표준 방식을 기술하고, 공통 네트워크 프로토콜을 통하여 이들을 전달한다. SOAP 및 XML-RPC는 주로 서버에 의한 서버 통신 및 씩 클라이언트(thick client)에 의한 서버 통신에 이용된다. 이들은 모두 장황한(verbos) 프로토콜이며, 매우 효율적일 필요는 없다. 특히, SOAP는 서버로부터 수신된 데이터를 이해하고 이 데이터를 클라이언트에 이용가능하게 만드는 클라이언트 상의 비교적 정교한 메카니즘을 필요로 한다. 자바스크립트(JavaScript)와 같은 간단한 스크립트 언어로 이를 달성하는 것은 어려울 수 있다. 웹 브라우저에서 자바스크립트를 이용하는 것의 한 가지 이점은 거의 모든 웹 브라우저 애플리케이션이 자신들이 스크립트를 실행할 수 있게 하는 스크립트 엔진을 포함한다는 점이다. 웹 브라우저가 스크립트 엔진을 이용하는 것은 아키텍처의 클라이언트 측에서 고객 맞춤(customization)을 보다 적게 요구한다.

그러므로, 웹 기반 애플리케이션을 초기화하는 데에 웹 브라우저와 클라이언트 간의 통신을 향상시키는 방법이 바람직할 것이다.

제1 컴퓨터와 제2 컴퓨터 간의 통신을 위한 방법, 프로토콜, 및 클라이언트-서버 환경에서 네트워킹된 애플리케이션을 제공하는 시스템이 개시된다.

간단히 기술된, 본 발명의 한 양태는, 클라이언트-서버 환경에서 네트워킹된 애플리케이션을 제공하는 시스템이 포함된다. 일 실시예에서, 시스템은 서버 상의 데이터 유형 정의를 포함하는 애플리케이션 함수의 세트, 및 스크립트 환경에서 정의되는 클라이언트 함수의 세트를 포함한다. 고유한 양태에서, 클라이언트 함수는 애플리케이션 함수의 세트의 애플리케이션 함수 각각과 매칭(match)하는 유형을 포함하도록 정의된다.

다른 실시예에서, 본 발명은 인터넷을 통한 웹 애플리케이션을 제공하는 방법이다. 이 방법은 서버 상의, 정의된 유형을 가지는 객체 및 함수를 포함하는 서버 환경을 제공하는 단계, 스크립트 환경에서의, 서버 환경에서의 대응하는 함수 및 객체와 매핑되는 유형을 가지는 스크립트 환경에서의 함수 및 객체를 포함하는 클라이언트 환경을 생성하는 단계, 클라이언트 환경을 서버에 제공하는 단계를 포함할 수 있다.

또 다른 환경에서, 본 발명은 웹-기반 애플리케이션을 제공하기 위하여 서버컴포넌트 및 클라이언트 컴포넌트를 초기화하고 설치하는 시스템이다. 이 시스템은 속성을 가지는 객체 및 메소드를 포함하는 서버 애플리케이션의 세트를 포함한다. 코드 생성기는 자바스크립트 클라이언트 측 라이브러리 및 서버 측 라이브러리를 각각의 상기 객체 및 메소드에게 제공한다. 서버 측 서비스는 클라이언트로부터 서버 상의 대응하는 객체 및 함수로 데이터를 라우팅하는 디스패쳐 (dispatcher) 및 마셀러(marshaler)를 포함한다.

다른 실시예에서, 본 발명은 인터넷 애플리케이션을 구현하는 시스템이다. 이 시스템은 각각이 정의된 유형을 포함하는 애플리케이션 객체 및 메소드의 세트를 포함하는 서버를 포함한다. 또한 상기 객체 및 메소드를 호출하는 스크립트 - 각각은 상기 애플리케이션 객체 및 메소드의 세트 중 적어도 하나의 객체 또는 매소드와 매칭하는 유형 정의를 포함함 - 의 클라이언트 세트를 생성하는 생성 엔진이 제공된다. 클라이언트 프로세싱 상치 상의 하나 이상의 클라이언트 스크립트로부터의 요청을 수신하고 상기 요청을 상기 애플리케이션 객체 및 메소드 중 하나로 라우팅하는 응답 엔진이 제공된다.

간단히 기술된 본 발명은, 다른 양태에서, 네트워크에서 동작하는 컴퓨터들 간에서 비대칭적으로 동작하는 통신 프로토콜 및 메소드를 포함한다. 클라이언트로부터 서버로의 통신은 데이터 효율성 및 서버에 의한 해석에 최적화된다. 서버로부터 클라이언트로의 통신은 기존의 클라이언트 애플리케이션 자원을 이용하는 클라이언트에 의한 해석에 최적화된다.

일 실시예에서, 본 발명은 분산형 프로세싱 시스템에서 클라이언트 프로세스와 서버 프로세스 간에 통신하는 방법이다. 이 방법은 클라이언트 프로세스에 의하여 요청된 서버 함수의 유형에 의해 정의된 포맷을 가지는 데이터 스트링을 포함하는 함수 요청을 서버에게 발행하는 단계, 서버 프로세스에 의하여, 함수 호출을 수신하고 스트링에서 요청된 함수를 수행하는 단계, 및 서버 프로세스에 의하여, 함수 요청에 대한 - 서버 객체에 의해 정의되는 클라이언트 측 프로세싱 포맷으로 되어 있는 - 응답을 발행하는 단계를 포함한다.

다른 실시예에서, 본 발명은 제1 컴퓨터와 제2 컴퓨터 간의 통신을 위한 프로토콜을 포함할 수 있다. 이 프로토콜은 제1 컴퓨터로부터 제2 컴퓨터로의, 제2 컴퓨터 상의 함수에 대한 함수 식별자 및 이 함수에 대한 인수를 포함하는, 요청을 포함한다. 인수는 함수 식별자에 의해 호출되는 함수에 대한 유형에 의해 정의될 수 있다. 프로토콜은 또한 제2 컴퓨터로부터 제1 컴퓨터로의 함수의 결과를 포함하여 스크립트 입력으로서 정의된 응답을 포함한다.

대안적인 실시예에서, 본 발명은 클라이언트와 서버 간의 통신의 방법이다. 이 실시예에서, 이 방법은 서버 상의 데이터 유형에 따라 정렬된 파라미터 스트링을 포함하는 요청으로 데이터를 포맷하는 단계, 네트워크를 통하여 데이터를 요청으로 송신하는 단계, 및 스크립트 입력 응답 포맷으로 응답 데이터를 포맷함으로써 데이터에 대한 응답을 생성하는 단계를 포함할 수 있다.

네트워크 환경에서 웹 기반 애플리케이션을 구현하는 고유한 아키텍처가 제공된다. 이 아키텍처는 클라이언트 및 서버 모두에게 프로그래밍 인터페이스의 완전한 세트, 즉, 서버 상에서 이용가능한 함수 및 객체를 제공하고, 클라이언트와 서버 간의, "프로토콜"이라 칭하는, 고유한 통신 방법으로 데이터 통신을 최소화시킨다. 이 통신 방법은 제공된 애플리케이션의 함수를 구현하기 위한 데이터를 포함하도록 최적화된다. 본 발명은 본 발명을 인터넷을 통하여 제공되는 웹 기반 애플리케이션에 적용하는 것에 관하여 본원에 기술될 것이다. 아키텍처의 적용은 본 원에 기술된 특정 운영 환경인 인터넷이나 본원에 기술된 컴퓨팅 언어에 한정되는 것이 아니라고 인식될 것이다.

본 발명은 본 발명의 구현의 일 실시예로서 웹-기반 이메일 서비스 및, 이 웹-기반 이메일 서비스용 철자-검사 함수를 제공하는 것에 관련하여 예시될 것이다. 예시적인 애플리케이션 및 함수를 가지는 아키텍처의 특정 예시는 본 발명의 아키텍처 및 프로토콜을 이용하여 구현될 수 있는 애플리케이션 및 함수의 범위를 제한하지 않는다고 인식될 것이다.

아키텍처는 비대칭적인 고유한 포스트(post) 및 응답 프로토콜을 이용한다: 포스트 프로토콜은 비-유형화된 데이터를 서버에 제공하는 반면, 응답 프로토콜은 유형화되고 스크립트 포맷으로 된 데이터를 포함한다. 서버에 존재하는 각 객체 및 메소드에 대응하는 자동적으로 생성된 클라이언트 측 라이브러리가 제공된다. 다른 고유한 양태에서, 경량(lightweight) 프로토콜이 클라이언트와 서버 간에서 데이터를 이동시킨다. 프로토콜의 예는 도 8 및 도 11에 도시된다. 고유한 양태에서, 클라이언트는 서버에 송신되는 데이터를 타이핑하고 서버는 그 날짜에 요구되는 프로세싱을 처리한다. 서버는 데이터 구조가 알려진 '유형화된' 스크립트로 다시 응답을 송신한다.

일반적으로, 서버 측 컴포넌트 및 클라이언트 측 컴포넌트를 초기화하고 설치하는 프로세스는 서버에서 개발되었으며, 속성들을 가지는 메소드 및 클래스를 포함하는 애플리케이션을 취하고 클라이언트 환경 및 서버 환경을 생성한다. (본원에서 "CodeGen" 엔진 또는 프로세스라고 칭하는) 코드 생성기는, 본원에서 종종 클라이어트 측 프록시라 칭하는 자바스크립트 클라이언트 측 라이브러리 객체와 스텁(stub) 컴포넌트, 및 개발된 애플리케이션 내의 각 객체 및 컴포넌트를 위한 서버 측 코드 "프록시"를 생성한다. 일단 환경이 생성되고, 클라이언트 환경이 설치되면, 디스패처 및 마셀러를 포함하는 서버 측 서비스는 클라이언트 상의 함수들로부터 서버 상의 대응하는 객체 및 함수로 데이터를 라우팅한다. 본 발명은 본원에서는 자바스크립트를 이용하여 본 발명을 적용하는 것에 관련하여 기술될 것이지만, 이 아키텍처는 다른 스트립트 환경을 포함할 수 있다고 이해될 것이다.

본 발명에 따르면, 개발자는 복수의 클래스 및 메소드를 발생시키는 서버 상의 애플리케이션을 생성한다. 애플리케이션이 컴파일될 때, 예를 들면, 동적 링크 라이브러리(DLL) 또는 실행가능 스크립트 객체(.exe 파일들)가 생성된다. 애플리케이션을 컴파일한 이후에, 개발자가 익스포팅(export)에 대하여 표시를 한 객체 및 메소드에 대하여, CodeGen 프로세스는 표시된 메소드에 대한 자바 스크립트로 된 스텁 및 표시된 클래스에 대한 자바스크립트로 된 객체를 생성한다. 자바스크립트는 웹 브라우저에 의해 소비될 수 있는 하나 이상의 자바스크립트 파일로 패키징(package)되고 서버에 접속된 클라이언트로 전송되어 웹-기반 애플리케이션을 구현한다.

CodeGen 프로세스는 또한 서버 측 프록시 엘리먼트를 생성한다. 일 실시예에서, CodeGen 프로세스는 서버 상에서 실행되는 C# 코드를 생성하고, 서버 상의 객체 및 함수를 클라이언트 상의 객체 및 스텁에 직접적으로 매핑시킨다. CodeGen 프로세스는 또한 클라이언트 호출이 서버 측 컴포넌트를 활성화할 수 있게 하는 프 록시, 디스패처, 및 마셀러를 생성한다. 그 다음 이러한 서버 애플리케이션 코드 세트는 서버용으로 컴파일된다. C#의 이용하는 것 또한 예시적인 것임을 유의해야 한다. 본 발명에 따라서 임의의 객체 지향 프로그래밍 언어가 이용될 수 있다.

일단 CodeGen 프로세스가 완료되면, 서버 측 라이브러리에 대응하는 클라이언트 라이브러리가 생성된 것이다. 서버 상에 위치한 서비스를 호출하는 것을 시도하는 클라이언트 개발자는 이제 서버 측 개발자가 이용했을 방식으로 클라이언트 측 컴포넌트를 이용할 수 있다. 모든 면에서, 서버 상에서 이용가능한 객체, 프로토콜, 인터페이스, 및 API는 모두 클라이언트 상에서 이용가능하다.

자동 생성된 클라이언트 코드 및 서버 코드는 프로토콜 자체를 포함한다. 클라이언트가 로컬 클라이언트 라이브러리에서의 메소드를 호출할 때, 생성된 로컬 자바스크립트 스텁이 실행된다. "프록시"로서, 이 클라이언트와 서버 엘리먼트와의 대화는 런타임(runtime)에 투명하다. 스텁이 실행될 때, 서버로부터의 애플리케이션에 의해 요구되는, 함수 내의 임의의 데이터는 요청이 서버로 라우팅되도록 할 것이다. 서버로 송신된 요청에서의 데이터는 마셀링될 수 있다 - 데이터를 모으고 특정 함수 또는 객체를 위하여 지정된 포맷으로 데이터를 변환한다. 이러한 경우 이 데이터는 서버 상의 마셀러(또는 이 경우 "디-마셀러")에 의해 이해되는 요청된 객체 또는 메소드 유형에 의해 정의된 전송 포맷으로 마셀링된다.

서버 상의 마셀러 및 디스패처는 요청을 취하고 요청에서의 데이터를 디-마셀링하며, 이 요청을 실제 서버 측 객체 또는 메소드로 디스패칭한다. 그 다음 서버 측 코드는 컴포넌트에 상주하는 함수 및 요청에 기초하여 응답을 생성하고, 예 를 들면, 어레이(array) 또는 엘리먼트와 같은, 클라이언트 상의 스크립트 라이브러리에 의해 해석될 수 있는 응답 포맷으로 결과 데이터를 클라이언트에게 다시 전달한다. 클라이언트 상에서, 자동적으로 생성된 클라이언트 측 자바스크립트 엔진은 이 응답을 언-마셀(un-marchal)하고 클라이언트로 다시 전달하여 프로세싱한다.

이용되는 클라이언트와 서버 간의 프로토콜은 HTTP 프로토콜에 기초하며, XMLHTTP와 같은 클라이언트 측 객체를 이용하여 관리된다. XMLHTTP (Extensible Markup Language Hypertext Transfer Protocol)는 XML, HTML 또는 라이브러리 데이터가 HTTP를 이용하여 인터넷을 통하여 웹 서버로 및 이 웹 서버로부터 전송될 수 있게 하는 API 세트이다. XMLHTTP의 이점은 ASP 또는 CGI 프로그램인 파일들이 클라이언트로부터 질의될 때, 사용자가 브라우저를 반복적으로 새로고침(refresh)하지 않고도 클라이언트는 최신 정보를 투명하게 검색하도록 XMLHTTP를 이용할 수 있다는 점이다. 다른 유형의 객체가 이러한 서비스를 제공하는 데에 이용될 수 있다.

클라이언트는 호출될 메소드에 관련된 정보를 가지고 인코딩되는 URL에 대하여 HTTP 요청을 발행함으로써 서버 상의 메소드를 호출한다. URL은 서버 측에서 디코딩되어 요청된 서비스가 요청에 연결되고 메소드가 요구하는 URL이 호출되는 것을 보장한다. URL은 직접 요청된 스키마를 인코딩한다. 응답을 완료하는 데에 필요한 데이터는 HTTP 요청의 본문에 인코딩된다.

본원에 기술된 아키텍처 및 방법은 다양한 프로세싱 시스템에서 수행될 수 있다. 본 발명을 구현하기에 적절한 프로세싱 시스템의 일례가 도 1에 도시된다. 도 1은 본 발명이 구현될 수 있는 적절한 일반적인 컴퓨팅 시스템 환경(100)의 예를 도시한다. 컴퓨팅 시스템 환경(100)은 단지 적절한 컴퓨팅 환경의 일 예이며 본 발명의 사용 또는 기능의 범위에 제한을 가하도록 의도된 것은 아니다. 컴퓨팅 환경(100)은 예시적인 운영 환경(100)에 도시된 컴포넌트들 중의 임의의 하나 또는 조합에 관하여 임의의 종속성(dependency) 또는 요구사항(requirement)을 갖는 것으로 해석되어서는 안된다.

본 발명은 많은 다른 범용 또는 특수목적 컴퓨팅 시스템 환경들 또는 구성들과 함께 동작될 수 있다. 본 발명과 함께 사용하기에 적합할 수 있는 잘 알려진 컴퓨팅 시스템, 환경, 및/또는 구성의 예로는, 퍼스널 컴퓨터, 서버 컴퓨터, 핸드헬드(hand-held) 또는 랩탑 장치, 멀티프로세서 시스템, 마이크로프로세서-기반 시스템, 셋 탑 박스(set top box), 프로그램가능한 가전제품(programmable consumer electronics), 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기의 시스템 또는 장치 중의 임의의 것을 포함하는 분산형 컴퓨팅 환경 등을 포함하지만, 이에 한정되지 않는다.

본 발명은 컴퓨터에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터 실행가능 명령어의 일반적인 관점에서 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 본 발명은 또한 통신 네트워크를 통해 링크된 원격 프로세싱 장치에 의해 태스크를 수행하는 분산형 컴퓨팅 환경에서 실행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 국부 및 원격 컴퓨터 저장 매체 내에 모두 위치할 수 있다.

도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(110)의 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들로는, 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 프로세싱 유닛(120)에 연결시키는 시스템 버스(121)가 포함될 수 있지만, 이에 한정되는 것은 아니다. 시스템 버스(121)는 다양한 버스 아키텍처 중의 임의의 것을 사용하는 로컬 버스, 주변 버스, 및 메모리 버스 또는 메모리 컨트롤러를 포함하는 몇 가지 유형의 버스 구조 중의 임의의 것일 수 있다. 예로서, 이러한 아키텍처는 산업 표준 아키텍처(ISA) 버스, 마이크로 채널 아키텍처(MCA) 버스, 인핸스드 ISA(Enhanced ISA; EISA) 버스, 비디오 일렉트로닉스 표준 어소시에이션(VESA) 로컬 버스, 및 메자닌(Mezzanine) 버스로도 알려진 주변 컴포넌트 상호접속(PCI) 버스를 포함하지만, 이에 한정되는 것은 아니다.

컴퓨터(110)는 통상적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있으며, 휘발성 및 비휘발성 매체, 분리형(removable) 및 비분리형(non-removable) 매체를 둘다 포함한다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만, 이에 한정되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 둘다 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 기타 자기 저장장치, 또는 컴퓨터(110)에 의해 액세스 될 수 있고 원하는 정보를 저장하는 데 사용될 수 있는 임의의 기타 매체를 포함하지만, 이에 한정되지 않는다. 통신 매체는 통상적으로 반송파 또는 기타 전송 메카니즘 등의 변조된 데이터 신호에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 다른 데이터를 구현하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 신호 내의 정보를 인코딩하도록 하나 또는 그 이상의 특성을 설정 또는 변경시킨 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크 또는 직접 유선 접속 등의 유선 매체와, 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함하지만, 이에 한정되지 않는다. 상술한 것들 중 임의의 조합이 컴퓨터 판독가능 매체의 범위 내에 또한 포함되어야 한다.

시스템 메모리(130)는 ROM(131) 및 RAM(132) 등의 휘발성 및/또는 비휘발성 메모리의 형태의 컴퓨터 저장 매체를 포함한다. 시동중과 같은 때에 컴퓨터(110) 내의 구성요소들 간에 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(133; BIOS)은 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로 프로세싱 유닛(120)에 즉시 액세스할 수 있고 및/또는 프로세싱 유닛(120)에 의해 현재 작동되는 프로그램 모듈 및/또는 데이터를 포함한다. 예로서, (한정하고자 하는 것은 아님) 도 1은 운영 체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)를 도시한다.

컴퓨터(110)는 또한 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 1에는 비분리형 비휘발성 자기 매체로부터 판독하거나 그 자기 매체에 기록하는 하드 디스크 드라이브(140), 분리형 비휘발성 자기 디스크(152)로부터 판독하거나 그 자기 디스크에 기록하는 자기 디스크 드라이브(151), 및 CD-ROM 또는 기타 광 매체 등의 분리형 비휘발성 광 디스크(156)로부터 판독하거나 그 광 디스크에 기록하는 광 디스크 드라이브(155)가 도시되어 있다. 예시적인 운영 환경에서 사용될 수 있는 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래쉬 메모리 카드, DVD(Digital versatile disk), 디지털 비디오 테이프, 고체 RAM, 고체 ROM 등을 포함하지만 이에 한정되지 않는다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 분리형 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

앞서 기술되고 도 1에 도시된 드라이브 및 그 관련 컴퓨터 저장 매체는 컴퓨터(110)를 위한 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 제공한다. 도 1에서, 예를 들어, 하드 디스크 드라이브(141)는 운영 체제(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)를 저장하는 것으로 도시된다. 이들 컴포넌트는 운영 체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)와 동일할 수도 있고 다를 수도 있다. 운영 체제(144), 애플리케이션 프로그램 (145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 다른 복사본(different copies)임을 나타내기 위하여 다른 번호를 부여하였다. 사용자는 일반적으로 마우스, 트랙볼, 또는 터치 패드라 불리우는 포인팅 장치(161) 및 키보드(162)와 같은 입력 장치를 통해 컴퓨터(110)에 명령 및 정보를 입력할 수 있다. (도시되지 않은) 기타 입력 장치는 마이크로폰, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 입력 장치 및 그외의 입력 장치는 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 종종 프로세싱 유닛(120)에 접속되지만, 병렬 포트, 게임 포트 또는 유니버설 시리얼 포트(USB)와 같은 기타 인터페이스 및 버스 구조에 의해 접속될 수 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치는 또한 비디오 인터페이스(190) 등의 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터 외에도, 컴퓨터는 또한 출력 주변 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196) 등의 기타 주변 출력 장치를 포함할 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용한 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어(peer) 장치, 또는 기타 공통 네트워크 노드일 수 있으며, 비록 도 1 에는 메모리 저장 장치(181)만이 도시되어 있지만, 컴퓨터(110)에 관하여 상술한 구성요소 중 다수 또는 모든 구성요소를 일반적으로 포함한다. 도 1에 도시된 논리적 접속은 근거리 통신망(LAN; 171) 및 원거리 통신망(WAN; 173)을 포함하지만, 그 외의 네트워크를 포함할 수도 있다. 이러한 네트 워크 환경은 사무실, 기업 광역 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷, 및 인터넷에서 일반적인 것이다.

LAN 네트워크 환경에서 사용되는 경우, 컴퓨터(110)는 네트워크 인터페이스, 즉, 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워크 환경에서 사용되는 경우, 컴퓨터(110)는 일반적으로 인터넷 등의 WAN(173)을 통해 통신을 구축하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메카니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에서, 컴퓨터(110)에 관하여 도시된 프로그램 모듈 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수 있다. 예로서 (한정하고자 하는 것은 아님), 도 1은 메모리 장치(181)에 상주하는 원격 애플리케이션 프로그램(185)을 도시한다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들간의 통신 링크를 구축하는 그 외의 수단이 사용될 수 있음이 인식될 것이다.

본 발명의 아키텍처를 이용하는 애플리케이션을 구현하기 위하여, 이 아키텍처의 클라이언트 측 컴포넌트 및 서버 측 컴포넌트가 설치되어야 한다. 도 2a는 본 발명에 따른 클라이언트 측 환경을 생성하는 제1 방법을 도시한다. 도 2b는 논리적인 관점의 아키텍처를 도시한다.

도 2a의, 단계(202)에서, 웹 애플리케이션의 개발자는 서버 상의 도구를 이용하여 웹-기반 애플리케이션을 생성할 것이다. 이 생성된 애플리케이션은 속성들을 가지는 클래스 및 메소드를 이용하는 함수 및 특징을 포함할 것이다. 일 실시 예에서, 개발은 임의의 개수의 애플리케이션 프로그래밍 언어로 이루어질 수 있다. 본 예에서, 개발은 마이크로소프트로부터의 객체 지향 프로그래밍 언어이며, .NET 플랫폼에서 동작하도록 설계된 C# 프로그래밍 언어에서 이루어진다. .NET 플랫폼은 분산형 컴퓨팅 환경에서 구현된 웹 애플리케이션 및 웹 서비스를 위한 소프트웨어 플랫폼이다. 일단 단계(202)에서 애플리케이션 및 특징이 개발되었다면, 메소드 및 클래스들이 서버에 존재한다. 단계(204)에서, 개발자는 개발자가 클라이언트 측 애플리케이션 개발자에게 이용가능하게 하도록 시도하는 익스포팅될 수 있는 객체 및 메소드로서 표시한다. 일 실시예에서, 서버 측에서 이용될 수 있는 모든 메소드는 익스포팅을 위하여 표시될 수 있다. 단계(206)에서, 애플리케이션이 컴파일되어, DLL(dynamic link libraries) 및 실행가능 파일을 생성한다. 애플리케이션이 컴파일된 이후에, 단계(208)에서, 코드 생성(CodeGen) 프로세스는 생성된 DLL 및 실행가능 파일을 검사하고 단계(204)에서 표시된 클래스들에 대한 스크립트 객체를 생성하며, 스크립트 스텁 및 객체로 정확하게 매핑되는 서버 상에서 실행되는 서버 코드 동등물 또한 생성한다.

일 실시예에서, 클라이언트 객체는 자바스크립트로 생성되지만, 다른 스크립트 언어가 이용될 수 있다. 본 발명의 한 고유한 양태는 클라이언트 장치를 위한 자바스크립트와 같은 스크립트 환경에서 이러한 객체를 생성하는 것이다. 스크립트 객체의 이용은 클라이언트 상의 웹 브라우저 소프트웨어에서의 본래의 스크립트 엔진의 사용자가 본원에 기술된 아키텍처를 구현할 수 있게 한다. 그 다음 단계(210)에서, 스크립트 클래스는 하나 이상의 파일들로 패키징되고 그 다음 단계 (210)에서 클라이언트에게 전송된다.

애플리케이션용으로 개발된 새로운 함수들이 새로운 메소드 또는 새로운 클래스들을 생성할 수 있다. 결과적으로, 프로세스는 새로운 특징들이 개발될 때, 단계(204) 내지 단계(210)가 반복되어 서버 상에서 구현된 새로운 특징들이 클라이언트 환경에 전달되도록 단계(202)로 되돌아갈 수 있다.

도 2b는 본 발명의 논리적 관점의 아키텍처를 도시한다. 클라이언트 장치 상의 특정 사용자에게, 환경은 비교적 투명하다. 클라이언트 장치에서, 사용자는 웹 기반 애플리케이션 형태로 말단 사용자 특징들에 노출될 것이다. 일례에서, 이메일 메세지 서비스, 달력 기능 및 접촉 기능(212)을 포함하는, 이러한 형태는 마이크로소프트 핫메일과 같은 웹-기반 이메일 서비스일 수 있다. 클라이언트 측 렌더링(214)은 서버에 의해 제공된 데이터를 이용하는 컨텐츠 및 스크립트 스텁(218)에 의해 제공된다. 클라이언트 측 및 서버 측 모두의 HTTP 핸들러(220)는 클라이언트 장치와 서버 장치 간의 통신을 처리한다. 마셀러(222) 및 디스패처(224)는 CodeGen 프로세스에 의해 생성된 객체 모델 코드(226)에 HTTP 핸들러로부터의 요청을 제공하는 것을 조정한다. 예를 들면, 클라이언트가 서버 상의 철자 검사 함수를 호출했을 때, 클라이언트 인터페이스는 실제로는 스크립트 어레이를 취하는 자바스크립트 함수이다. 클라이언트 상의 - 스텁(214)으로 작성된 객체 모델(216)에 의해 구현된 - 마셀링 프로세스는 각 어레이(또는 엘리먼트 또는 어레이나 엘리먼트들의 조합)를 취하여 이 어레이를 전송 포맷으로 작성한다. 일반적으로, 어레이는 엘리먼트의 구두점으로 구분된 스트링의 형태를 취하며, 각 엘리먼트는 어레이, 정수 스트링, 또는 몇몇의 다른 구조일 수 있다. 서버 상의 마셀링 프로세스는 재귀적으로 어레이 내의 엘리먼트를 평가하고 있다. 객체 모델(226) 및 자바스크립트 객체 모델(216)은 모두 강력하게 유형화되어서, 소정의 객체에 송신된 어레이는, 정확한 유형을 가지는 어레이 내의 잘 정의된 개수의 엘리먼트 및 합성된 유형에 대하여, 합성된 유형의 정확한 포맷을 가진다. 객체 모델은 데이터 계층(230) 및 저장 관리자(228)를 통하여 실제인 데이터(232)와 대화한다. 스텁들이 서버 객체 모델(226)에 기초하여 생성되기 때문에, 스텁들은 유형 및 속성들의 데이터 계층(230)으로의 직접적인 매핑을 가진다.

사용자 시스템에서 클라이언트 측 환경을 제공하기 위하여, 상술한 바와 같이, 하나 이상의 스크립트 파일이 클라이언트 컴퓨팅 장치에 송신되고 이 장치에 저장될 필요가 있다. 웹-기반 애플리케이션에서는, 통상적으로 이러한 애플리케이션은 서비스 제공자에 의해 제공된다. 본 발명의 기본적인 아키텍처를 이용하는 애플리케이션을 제공하는 서비스 제공자는 사용자가 서비스를 액세스하기 위하여 로그인 또는 계정을 생성할 것을 요구하고 이 로그인 또는 계정 생성 단계는 클라이언트 환경을 설치하는 데에 이용될 수 있다. 이러한 경우, 서비스 제공자는 웹-기반 서비스 또는 애플리케이션의 규정을 제어하는, 사람 또는 컴퓨터가 구현한 프로세스라 간주될 수 있다.

도 3에서, 단계(300)에서 사용자는 계정 또는 로그인을 생성할 것이다. 일단 사용자가 로그인을 개시한다면, 사용자의 제1 경험은 단계(302)에서 사용자의 컴퓨터에 다운로드되는 애플리케이션 자바스크립트 파일을 다운로드하는 것일 수 있다. 단계(304)에서, 사용자가 애플리케이션 서버에 의해 제공되는 웹 서비스와의 대화를 시작할 때, 스크립트 엔진은 사용자 컴퓨터 상의 객체를 이용하여 서버 측 애플리케이션 클래스 및 메소드를 가지고 본 발명의 프로토콜을 전달한다. 사용자로부터의 특정 서버 또는 애플리케이션에 대한 요청을 수신하고 애플리케이션을 위한 클라이언트 환경의 다운로드 프로세스를 개시하는 대응하는 프로세스는 서버 상에서 실행된다고 이해될 것이다.

도 4는 본 발명의 아키텍처 및 프로토콜을 구현하는 데에 적절한 한 시스템의 블럭도이다. 도 4는 도 1에 도시된 컴퓨팅 장치(100)일 수 있는 클라이언트 장치(460), 및 애플리케이션 서버(420)를 도시한다. 본원에서 이용되거나 도 4에서 라벨(480)이 달린 블럭으로서 도시된 "서버" 또는 "네트워크 서버"는 데이터 및 애플리케이션이 보유되는 임의의 기기 또는 기기들의 조합을 포함한다.

클라이언트 기기에서 실행되는 브라우징 소프트웨어(300)는 네트워크 인터페이스(402)를 통해 애플리케이션 서버(480)와 통신한다. 클라이언트 장치(460)와 서버(480) 간의 통신은 네트워크, 또는 인터넷과 같은 공용 네트워크와 사설 네트워크의 조합을 통해 하나 이상의 요청(402) 및 응답(404)을 거쳐 일어날 수 있다. 클라이언트 장치(460)와 서버(480) 간의 통신은 통상적으로 HTTP 프로토콜을 이용하지만, 본 발명은 HTTP를 통신 프로토콜로서 이용하는 것에 제한되지 않는다.

클라이언트 장치(460)는 몇몇의 응답(404)의 프로세싱을 처리하는 전송 컴포넌트(410)를 포함한다. 컨텐츠 데이터가 반환될 때, 데이터는 전송 컴포넌트(410)로부터 다른 코드 계층(420)을 지나 스크립트 엔진(426) 및 파서/해석기(422)로 전 달된다. 그 다음 파서는 컨텐츠를 파싱하고 해석하여 사용자 인터페이스(424)를 통해 사용자에게 디스플레이한다. 파서(422)는 컨텐츠에 의한 참조에 내장된 임의의 스크립트를 해석할 필요가 있기 때문에 스크립트 엔진(426)을 호출할 수 있다. 컨텐츠는 또한 전송 컴포넌트(410)에 포함되거나 이 전송 컴포넌트에 관련된 저장 관리자(455)를 통해 액세스되는 로컬 저장 장치(436)에 저장될 수 있다.

저장 장치(436)는 또한 캐쉬 테이블, 데이터 캐쉬, 쿠키, 및 상술한 자바스크립트 파일 세트를 포함하는 자바스크립트 컨테이너(container)를 포함할 수 있다. 전송 컴포넌트(410)는 자바스크립트 및 예를 들면, 쿠키 컨테이너의 쿠키와 같은 다른 정보를 저장하고 검색하는 저장 관리자(455)를 포함하거나 이 저장 관리자와 관련된다. 스크립트 관리자(450)는 아키텍처에 의해 제공된 클라이언트 측 스크립트로부터 스텁 및 객체를 실행시키는 스크립트 엔진으로부터의 요청을 구현한다. 후술될 바와 같이, 스크립트 관리자(450)는 서버(480)로의 2가지 유형의 호출 - 서버(480) 상의 함수 및 객체에 관한 동기식 호출 및 비동기식 호출 - 을 처리한다. 이들 요청들은 도 13에 관련하여 후술된다.

서버(480)는 본 발명이 구현될 수 있는 예시적인 운영 체제(492)를 포함할 수 있다. 운영 체제(492)는 단지 적절한 운영 환경의 일례이며 본 발명의 사용자 기능의 범위에 제한을 가하는 것으로 의도되지 않는다. 운영 환경의 일례는 마이크로소프트로부터 이용가능한 윈도우즈 계열 운영 체제이다. 이 환경은 설계 및 런타임 객체를 포함하는 플랫폼인 애플리케이션 프레임워크(460), 및 웹 서버에서 애플리케이션을 실행할 수 있도록 하는 제어를 포함할 수 있다. 프레임워크가 요 구사항은 아니지만, 본원에 기술된 특정 서비스는 프레임워크의 컴포넌트로서 포함될 수 있거나, 마찬가지로 운영 체제에 포함되거나 운영 체제에서 실행되는 독립형 애플리케이션으로서 제공될 수 있다. 애플리케이션 프레임워크는 마이크로소프트사로부터 이용가능한 .NET 애플리케이션 프레임워크로서 상술한 것일 수 있다. 애플리케이션 프레임워크는 본 발명에 관련하여 이용될 수 있는 암호화, 압축 및 인증과 같은 기능을 구현하는 자원 클래스를 포함할 수 있다.

개발된 애플리케이션 컨텐츠(482), 객체(484), 및 메소드(486)는 애플리케이션 프레임워크 내에서 제공된다. 애플리케이션(489)은 하나 이상의 클래스 및 메소드로 구성될 수 있다. 컴파일러(487)는 애플리케이션(489)을 위한 DLL 및 실생가능 파일을 생성한다. 애플리케이션 프레임워크(460) 내에서 CodeGen 엔진(495)이 또한 도시된다. 상술한 바와 같이, 일단 객체 및 클래스가 특정 애플리케이션(489)에 대하여 생성되고 컴파일러(487)에 의해 컴파일되면, CodeGen 엔진(495)은 클라이언트 측 스크립트 객체, 마셀러(494), 디스패처(492), 및 서버 애플리케이션 코드(490)를 모두 생성할 것이다.

서버 상의 애플리케이션에서의 메소드와 클래스 간의 대화는 서버 측 객체를 가지고 일어난다. 응답은 서버 측 "프록시" 객체(290)에 제공되고 그 다음에 이 객체는 클라이언트 측 프록시로부터의 호출에 기초하여 클라이언트 장치에 응답을 제공한다.

CodeGen 엔진(495)은 소프트웨어의 컴파일된 조각을 분석하는 "반영(reflection)"이라 칭하는 기법을 통하여 동작하여 자동적으로 마셀링, 디-마셀링, 및 디스패칭을 구현하는 파서, 변환기, 포맷기, 및 텍스트 작성기(총체적으로는 "스텁") 세트를 생성한다. 반영 메카니즘은 애플리케이션 프레임워크에서 제공되고 런타임시에 클래스 및 객체 정의를 발견하는 기법이다. 실제로, CodeGen 엔진은 컴파일된 코드를 다시 컴파일하는 컴파일러이다. CodeGen 엔진은 자신의 고유한 상태와 같은 변수들, 및 계정으로의 환경적 정보를 취한다. CodeGen의 스텁은 함수들을 이것의 자동적으로 생성된 프레임워크의 일부로서 동기식으로 디스패칭한다. 이는 또한 해쉬테이블과 같은 컬렉션 유형을 프록싱할 수 있는데, 이러한 특징은 SOAP에는 이용될 수 없다. 그리고, 최종적으로, CodeGen은 클라이언트에게 서버 예외들을 균일하게 전달할 수 있다. 결과 자바스크립트 스텁은 서버의 애플리케이션 클래스 및 객체의 런타임 속성 정의와 매칭하는 정의를 포함할 것이다.

일단 서버 애플리케이션 코드(490)가 생성되면, 코드는 서버(480) 상의 저장 관리자(455)와 대화하여 데이터(498)를 액세스한다. 클라이언트 장치(460)로부터의 요청은 마셀러(494)에 의해 수신되고 디스패처(492)에 의해 분산된다. 요청이 서버(480)에 의해 수신될 때, 디스패처는 서버에게 클라이언트가 실행하기를 시도하고 있는 함수가 무엇인지 알려준다. 인보케이션(invocation) 호출은 요청(404)의 일부로서 클라이언트로부터 수신된 요청 URL로 작성된다. 한 양태에서, URL은 .Net 네임스페이스의 표현을 포함한다. 특정 애플리케이션을 위한 모든 프로그래밍 코드는 네임스페이스 "application.namespace"에 나타난다. 디스패처(492)는 그 정보를 키 오프(key off)한다. 마셀러(494)는 URL의 컴포넌트를 분리시키고 각 엘리먼트를 검사하고, 이것이 매칭될 때, 디스패처는 요청 전반에서의 정보를 애플 리케이션 코드(490) 내의 함수로 위임한다.

도 5는 클라이언트에서 실행되는 철자 검사 애플리케이션이 서버에서 실행되는 메소드를 호출하고 서버로부터 응답을 수신하는 일반적인 프로세스를 도시하는 흐름도이다. 일반적으로, 클라이언트가 서버 상의 철자 검사 함수를 호출할 때, 클라이언트 인터페이스는 실제로 입력으로서 스크립트 어레이를 취하는 스크립트 함수이다. 스크립트 관리자는 마셀링 프로세스를 포함하는데, 이 프로세스는 각 어레이를 취하고 이 어레이를 업스트림(upstream) 전송 포맷으로 작성한다. 일 실시예에서, 포맷은 엘리먼트 내부의 구두점으로 구분된 리스트 이후의 중괄호로서 열람되는 어레이이다.

도 5에서, 단계(505)에서 철자 검사 함수가 일반적으로 몇몇의 사용자 대화에 의해 개시될 것이다. 사용자 대화는 이메일 애플리케이션 또는 텍스트 편집기와 같은 다른 애플리케이션 프로그램에서의 함수에 대한 특정 호출일 수 있거나, 사용자가 이메일 메세지를 위하여 "보내기" 명령어를 눌렀을 때 함수가 자동적으로 호출될 수 있다. 단계(510)에서, 자바스크립트 애플리케이션 "철자 검사"는 본원에 정의된 함수들에 따라서, 서버 측 함수 "철자 검사"를 위한 데이터 또는 속성을 포함하는 요청을 발행할 것이다. 단계(515)에서, 데이터는 서버 상의 "철자 검사" 함수에 대하여 유형화된 포맷으로 마셀링되고 단계(520)에서, XMLHTTP 요청이 송신 컴포넌트를 통하여 서버 측 메소드로 송신된다. 요청의 예들은 도 7 내지 10에 관련하여 이하 기술된다.

서버 측에서, 요청은 유형화된 객체로 디마셀링되고 변환될 것이다. 단계 (525, 530, 535, 및 540)는 애플리케이션 서버(480)에서 수행된다. 단계(525)에서, 요청이 수신될 때, 이 단계는 마셀러(494) 및 디스패처(492)에 의해 동작되어 단계(525)에서 객체를 서버 상의 특정 함수에 디스패칭할 것이다. 그 다음 호출된 메소드는 단계(530)에서 요청 데이터 상에서 동작하고 몇몇의 응답을 반환할 것이다. 단계(535)에서 응답은 자바스크립트 응답으로 변환되고 애플리케이션 서버 코드(490)에 의해 다운스트림(downstream) 포맷으로 클라이언트에게 전송된다. 서버 측 프록시는 서버 측 함수 호출의 결과를 자바스크립트로 전환하고 이 스크립트는 클라이언트데 다시 송신되고 스크립트 관리자에 의해 해석된다. 스크립트 엔진은 자바스크립트 응답을 전반적으로 파싱하고 이를 평가한다. 마찬가지로, "디-마셀러"는 클라이언트 상에서 필요하지 않다 - EVAL 함수는 디-마셀링하는 동등물을 관리한다.

단계(545 및 550)는 클라이언트 상에서 일어난다. 단계(545)에서 클라이언트 측 스크립트에 의하여 응답을 수신할 때, EVAL 동작은 응답 상에서 수행될 것이다. EVAL 함수는 자바스크립트 표현식, 상태문, 또는 일련의 상태문을 나타내는 스트링을 취한다. 표현식은 기존의 객체의 변수 및 속성을 포함할 수 있다. 인수가 표현식을 나타낸다면, EVAL은 표현식을 평가한다. 인수가 하나 이상의 자바스크립트 상태문을 나타낸다면, EVAL은 상태문을 수행한다. 단계(550)에서 EVAL 함수의 출력은 요청하는 스텁으로 송신된다.

도 6은 클래스 "메세지 헤더"에 대한 CodeGen 프로세스의 출력을 도시한다. 메세지 헤더 클래스는 이메일 메세지에서 제공된 정보를 포함할 수 있다. 도 6에 도시된 바와 같이, 통상적인 이메일 메세지 헤더는 제목, 발신 주소, 발신인 이름, 날짜, 크기, 메세지 링크 및 상태 아이콘을 포함할 수 있다. C# 객체 정의(620)는 서버 상에 생성되는 한편, 자바스크립트 객체 정의(610)는 CodeGen 프로세스에 의해 클라이언트에 대하여 생성되었다. C# 객체 정의는 스크립트 생성자(624)의 뒤에 있는 객체의 전술한 속성에 대한 속성 선언(622)을 포함하며, 여기에서 스크립트 생성자는 스트링 "subject = strSubject, fromAddr = strFromAddr, fromName = strFromName, date = dDate, size = iSize, msgLink = strMsgLink, theIcon = oIcon"을 정의한다. 대응하는 자바스크립트 객체 정의는 C# 객체 정의로부터의 엘리먼트(612) 및 C# 객체를 포함하는 서버 상의 메세지 헤더 함수 "messagehdr"와 네임스페이스 "serverNamespace"에 대한 함수 정의를 포함한다.

도 7은 함수 "GetMessages" 및 그 관련된 자바스크립트 스텁(720)에 대한 예시적인 C# 인터페이스(710)의 일례를 도시한다. 상술한 바와 같이 함수 GetMessages는 Messagehdr 객체를 이 함수의 인수로서 취한다. 서버 측 C# 인터페이스 "get messages"는 서버(280) 상의 메일박스를 가지는 사용자를 위한 특정 사용자의 폴더의 정의된 입력을 요구한다. 클라이언트 측 자바스크립트 스텁(720)은 서버로의 비동기식 및 동기식 XMLHTTP 요청을 조정하는 "gXMLHTTPProxy"로서 알려진 객체를 호출하는 함수를 포함한다. gXMLHTTPProxy의 기능들은 도 13에 관련하여 이하 기술된다. 도 7의 예에서, 함수 "GetMessages"는 동기식 요청이다.

상술한 바와 같이, 서버에 대한 요청을 형식화할 때, 스크립트 관리자(255)가 동기식 또는 비동기식 요청을 수행할 수 있다. 동기식 요청에서, 보다 상세히 후술될 바와 같이, 클라이언트는 HTTP에서의 "POST" 함수와 매우 유사한 방식으로 상호작용할 것이다. 즉, 클라이언트가 서버 측 메소드로부터 몇몇의 데이터를 요청할 것이지만, 데이터가 서버로부터 수신될 때까지, 대기중인 애플리케이션을 기다리고 홀딩(hold)할 것이다. 동기식 요청에서 자바스크립트는 서버에게 호출을 하여 데이터를 검색하고, 웹 브라우저에서 자바스크립트에게 결과를 제공하기 전에 서버가 다시 돌아오는 것을 기다린다. 동기식 요청은 본질적으로 블럭킹된 호출인데, 여기서 브라우저는 서버가 다시 돌아올 때까지 동결(frozen)된다.

비동기식 요청은 데이터에 곧바로 호출하지 않는다. 비동기식 요청은 큐에 위치되고 요청들은 블러킹되지 않은 호출로 XMLHTTP 객체를 통하여 서버에 송신된다. 예를 들면, 웹 브라우저에 구현된 철자 검사 함수를 요청한다면, 이메일을 타이핑하는 것을 계속하면서 철자 검사 함수가 서버 상에 일어날 수 있다. 데이터가 다시 돌아오면, 자바스크립트는 호출을 취득하여 철자 검사 함수를 다시 시작한다.

도 8은 GetMessages 스크립트 및 함수에 의해 생성된 응답(820) 및 요청(810)의 일례를 나타낸다. 업스트림 요청은 URL의 일반적인 포맷: 서버 + 버전 + 서버 네임스페이스 + 클래스id + 메소드id를 포맷으로 취한다. 도 8에 도시된 예에서, POST 동작은 소정의 폴더 F000000001을 위한 GetMessages함수에 대한 요청을 포함한다. POST에 대한 응답은 스크립트 정의(610)에 직접 매핑되는 MessageHdr의 C# 객체 정의에 정의된 엘리먼트를 포함하는 새로운 어레이이다. 응답 예(820)는 애플리케이션 서버로부터 검색된 MessageHDR 객체의 어레이를 나타낸다.

이와 같이, (이 경우 어레이이지만 다른 포맷을 포함할 수 있는) 응답 포맷 은 클라이언트 상의 스크립팅된 객체에 정확하게 알려지며, 그 다음 이 클라이언트는 어레이에 수신된 객체를 파싱하고 이를 클라이언트 상의 임의의 랜더링된 스크립트에 제공하여 클라이언트 프로세싱 장치의 사용자 인터페이스에 디스플레이한다.

도 9 및 도 10은 애플리케이션 프레임워크(260)에서 동작하는 CodeGen 프로세스(290)에 의해 생성된 객체 및 함수의 추가적인 예를 나타낸다. 도 9 및 10의 예는 철자 검사 애플리케이션에서 이용될 수 있는 2개의 철자 검사 메소드에 관한 것이다. 도 9는 하나의 단어를 입력으로서 취하고, 그 철자를 검사하여 철자가 올바른지 올바른지 않은지에 대한 표시를 반환하는 함수 "checkspellingofword"를 나타낸다. 함수는 참/거짓 결과를 반환한다. 스크립트 스텁(910)은 gXMLHTTP 객체에 대한 동기식 호출 "EXAMPLEInvokeSync"을 나타낸다. 결과적으로, 스크립트(910)는 클라이언트에 애플리케이션을 배포하기 전에 메소드(920)에 대한 반환 응답을 기다릴 것이다.

도 10은 복수의 단어를 입력으로서 취하고 스트링으로 응답하는 인터페이스 "checkspelling"(1010)를 나타낸다. 스크립트 함수(1020)는 추가적인 필터 - 호출을 프로토콜 포맷으로 마셀링할 수 있는 스크립트인 "dimensionFilter_words"- 를 포함한다. 스크립트(1020)는 gXMLHTTP 객체로의 비동기식 요청 호출 "EXAMPLEInvokeAsync"의 일례이다. 결과적으로, 스크립트(1020)는 프로세싱에 대한 요청들을 큐잉하고 브라우저 스크립트 엔진을 동결시키지 않고 결과를 기다릴 것이다. 스크립트(1020)는 또한 gXMLHTTP 프럭시가 실행되고 있는 서버로부터의 응답을 기다리면서 클라이언트가 다른 기능들을 수행하는 것을 계속할 수 있게 하는 스크립트가 제공하는 콜백 함수를 포함한다.

도 11은 다른 인터페이스/스텁 관계를 나타낸다. 도 12는 도 11에 도시된 인터페이스/스텁 관계에 대한 요청/응답 예를 나타낸다. 도 11에서, 함수 "checkspellingwithsuggestions"에 대한 인터페이스가 나타나고 이 인터페이스는 입력으로서 문장(또는 일련의 문장)을 취하고, "suggestions"의 스트링으로 응답한다. 이러한 예에서 gXMLHTTP 객체의 호출은 비동기식이다.

도 11에 도시된 checkspellingwithsuggestions 함수의 예시적인 POST 요청이 도 12에 나타난다. POST 함수는 또한 서버 + 서버 네임스페이스 + 버전 + 클래스 Id + 메소드Id인 포맷으로 제공되며, 이 예에서 정의된 프로토콜은 checkSpellingWithSuggestions 함수로 액세스될 수 있는 스트링 정의를 포함한다. 응답은 2개의 중첩된 어레이를 포함하는 새로운 어레이로 제공된다.

어레이는 클라이언트 상의 스크립트 환경 및 자바스크립트 엔진에 의해 해석될 수 있는 표준 자바스크립트 어레이이다. 자바스크립트 함수 철자 검사(1120)가 스트링 어레이를 요구하기 때문에, 어레이가 스크립트 환경으로 직접 제공되고 자바스크립트 가상 기기에 의해 동작될 수 있다. 그러므로, 브라우저로부터 서버로의 프로토콜은 전송에 상당히 최적화된다. 클라이언트 측 함수가 서버 객체의 유형 정의를 포함하기 때문에 서버 측 객체 및 메소드로의 호출은 강력하게 유형화된 포맷으로 제공된다. 데이터는 자바스크립트로 클라이언트에게 반환되고, 표준 EVAL 함수에 의하여 자바스크립트 언어로 클라이언트 측에서 평가될 수 있다. EVAL 함수는 자바스크립트가 함수인지, 어레이를 생성인지, 객체의 생성인지를 판정할 수 있어, 평가 프로세스 이후에, 이 함수는 또한 자바스크립트 객체 모델에서는 객체가 된다.

도 13은 서버로의 동기식 및 비동기식 XMLHTTP 요청을 제어하는 gXMLHTTP 객체를 도시한다. 초기에, 단계(1310)에서, 프로세스는 정확한 브라우저 구성을 결정하고 브라우저가 본 발명의 아키텍처에서 이용하는 데에 적절한 것인지 판정한다. 단계(1312)에서, 버전, 서버 및 네임스페이스 식별자를 포함하는 초기화 변수가 객체에 전달된다.

XMLHTTP 객체는 동기식 XMLHTTP 함수, 비동기식 XMLHTTP 함수, 작업 아이템 또는 요청 블럭들의 스택, 서비스 내에 있는 현재 요청 블럭, 타이머, 및 쿠키 처리 함수를 인스턴스화하는 생성자를 포함한다.

단계(1314)에서, 방법은 브라우저의 전송 컴포넌트(410)의 HTTP 서비스를 이용하여 HTTP를 위한 XMLHTTP 프록시를 인스턴스화하려는 시도를 한다. 그 다음, 단계(1315)에서, 방법은 호출 스크립트 정의에 의존하여 동기식 또는 비동기식 함수를 호출한다.

방법이 비동기식 XMLHTTP 요청을 호출하면, XMLHTTP 메소드를 호출하는 스크립트 스레드는 대기하고 XMLHTTP가 성공하거나 타임아웃 될 때까지 데이터를 반환하지 않는다. 상술한 예에서 단계(1316)에서 동기식 XMLHTTP 요청은 서버로의 URL 호출을 생성함으로써 시작한다. 일단 URL이 생성되면, 단계(1318)에서, 동기식 접속이 열리고 단계(1320)에서 URL이 서버로 포스팅된다. 그 다음, 방법은 단일한 파라미터 - responseText일 수 있는 응답을 기다린다. 일단 응답이 수신되거나 타임아웃되면, 호출하는 스크립트로 제공되고 단계(1324)에서 스크립트 스레드가 배포된다. 본원에서 이하에 응답은 클라이언트 상의 EVAL 함수를 이용하는 후술될 설명에 따라서 평가될 수 있다.

단계(1315)에서, 응답이 비동기식 XMLHTTP 응답에 관한 것이라면, 단계(1330)에서 마찬가지로 URL의 생성을 시작한다. 이러한 경우, URL은 상기 식별된 컴포넌트 외에도 콜백 함수를 포함한다. 콜백은 비동기식 호출이 완료된 이후에 XMLHTTP 프록시가 호출한 사용자가 제공한 함수이다. 이 함수는 하나의 파라미터, XMLHTTP 응답 텍스트를 취한다. URL이 생성된 이후, 단계(1334)에서 시스템은 비동기식 호출을 큐잉(queue)하고 타임아웃 타이머를 설정한다(1336). 큐잉 단계(1334)는 단계(1338)에서 서버에 현재 실행되는 블럭이 있는지 여부를 판정하는 디스패처 함수를 호출한다. 블럭이 존재한다면, 함수는 단계(1336)로 돌아가서 다시 수면상태에 이르게 된다.

큐 스택이 비어있지 않는 한, 프로세스에서의 요청이 존재하고 이 요청은 일단 완료되면 호출하는 디스패처를 관리할 것이다. 그러므로, 타임아웃 윈도우는 스택이 이미 비었을 때를 탐지할 때에만 호출된다. 단계(1338)에서 일단 블럭이 비었다면, 단계(1340)에서 비동기식 접속이 열리고 URL이 포스팅된다. 단계(1342)에서 일단 호출이 큐잉되면, 단계(1334)에서 호출 핸들러가 시작된다.

콜백 핸들러는 XMLHTTP 동작이 완료되기를 기다리고 콜백이 실행된다. 단계(1344)에서 응답이 수신될 때, 현재 요청은 디스패치 큐로부터 제거되고(1346), 단 계(1348)에서 디스패처는 또한 디큐잉(dequeue)하도록 설정된다. 단계(1350)에서 응답은 호출하는 스크립트로 전달된다.

본 발명의 전술한 상세한 설명은 예시 및 설명을 위하여 제공되었다. 이는 본 발명을 개시된 정확한 형태로 제한하거나 소모시키려는 의도는 아니다. 상기 교시에 비추어 다수의 수정 및 변형물이 가능하다. 본원에 기술된 바와 같이, 본 발명의 범위 및 내용을 벗어나지 않는 본 발명의 아키텍처에 대한 다양한 변형물이 가능하다. 일 실시예에서, 요청 및 응답은 압축되고 암호화될 수 있다.

본 발명의 원리 및 그 실질적인 적용을 가장 잘 기술하여 본 기술 분야에서 숙련된 기술을 가진 자가 다양한 실시예에서 및 제시된 특정 사용에 적합하게 된 다양한 변경물들로 본 발명을 가장 잘 이용할 수 있게 하기 위하여 상술한 실시예들이 선택되었다. 본 발명의 범위는 특허 청구 범위에 의해 정의된다고 의도된다.

제1 컴퓨터와 제2 컴퓨터 간의 통신을 위한 방법과 프로토콜, 및 서버-클라이언트 환경에 네트워킹된 애플리케이션을 제공하는 시스템이 개시된다. 프로토콜은 제1 컴퓨터로부터 제2 컴퓨터로의, 제2 컴퓨터 상의 함수에 대한 함수 식별자 및 이 함수에 대한 인수를 포함하는 요청을 포함한다. 인수는 함수 식별자에 의해 호출되는 함수에 대한 유형에 의해 정의될 수 있다. 프로토콜은 또한 제2 컴퓨터로부터 제1 컴퓨터로의, 함수의 결과를 포함하며 제1 컴퓨터에 대한 스크립트 입력으로서 정의된 응답을 포함한다. 클라이언트-서버 환경에서 네트워킹된 애플리케이션을 제공하는 시스템은 서버 상의 애플리케이션 함수의 세트를 포함하며, 이 애 플리케이션 함수는 데이터 유형 정의를 포함하고 클라이언트 함수의 세트는 스크립트 환경을 정의한다. 클라이언트 함수는 서버 상의 애플리케이션 함수 각각과 매칭하는 유형을 포함하도록 정의된다.

Claims

클라이언트 서버 환경에서 네트워킹된 애플리케이션을 제공하는 시스템으로서,

상기 서버 상의 애플리케이션 함수의 세트(489) - 상기 애플리케이션 함수는 유형 정의를 포함함 - , 및

스크립트 환경을 정의하는 클라이언트 함수의 세트(436) - 상기 클라이언트 함수는 상기 애플리케이션 함수의 세트에서의 상기 애플리케이션 함수 각각과 매칭하는 유형을 포함하도록 정의됨 -

를 포함하는 시스템.
제1항에 있어서,

클라이언트 함수로부터 서버 함수로의 요청을 프로세싱하는 상기 클라이언트 상의 요청 엔진(450)을 더 포함하는 시스템.
제2항에 있어서,

상기 요청 엔진(450)은 요청된 상기 서버 함수에 대한 상기 유형 정의에 대응하는 클라이언트 함수의 유형 포맷(404)으로 요청을 제출하는 시스템.
제2항에 있어서,

상기 엔진은 요청하는 클라이언트 함수(426, 436)에 응답하고, 상기 유형 정의는 상기 클라이언트 함수에 포함되는 시스템.
제2항에 있어서,

상기 요청 엔진(450)은 동기식 및 비동기식 요청을 프로세싱하는 스케줄러(scheduler)를 포함하는 시스템.
제2항에 있어서,

상기 요청 엔진(450)은 상기 서버 함수로부터의 응답 콜백을 수신하는 응답 청취자를 포함하는 시스템.
제1항에 있어서,

하나 이상의 유형 정의(450)는 속성들의 세트를 포함하는 시스템.
제1항에 있어서,

상기 클라이언트 함수의 세트(436)는 자바스크립트(210)로 제공되는 시스템.
제1항에 있어서,

상기 서버 상의 클라이언트 요청에 대한 응답을 제공하는 코드(490)를 더 포함하는 시스템.
제9항에 있어서,

상기 코드(490)는 스크립트가 파싱(parse)할 수 있는 포맷(406)으로 응답을 제공하는 시스템.
제9항에 있어서,

상기 코드는 마셀러(marshaler)(494)를 포함하는 시스템.
제9항에 있어서,

상기 코드는 디스패처(dispatcher)(492)를 포함하는 시스템.
제1항에 있어서,

특수하게 익스포팅(export)이 표시된 함수로부터 클라이언트 측 함수를 생성하는 생성 엔진(426)을 더 포함하는 시스템.
제1항에 있어서,

상기 서버를 위한 마셀러(494)를 생성하는 생성 엔진(426)을 더 포함하는 시스템.
제1항에 있어서,

상기 서버를 위한 디스패처(492)를 생성하는 생성 엔진(426)을 더 포함하는 시스템.
인터넷을 통하여 웹 애플리케이션을 제공하는 방법으로서,

서버 상의 함수 및 객체를 포함하는 서버 환경을 제공하는 단계(202) - 상기 객체 및 함수는 정의된 유형을 가짐 - ,

스크립트 환경(426)에서의 함수 및 객체를 포함하는 클라이언트 환경을 생성하는 단계(208) - 상기 스크립트 환경에서의 상기 함수 및 객체는 상기 서버 환경에서의 대응하는 함수 및 객체에 매핑되는 유형을 가짐 - , 및

상기 클라이언트 환경(426)을 상기 서버에게 제공하는 단계(210)를 포함하는 방법.
제16항에 있어서,

상기 생성 단계는 상기 함수 및 객체를 스크립트 언어로 출력하는 단계(210)를 포함하는 방법.
인터넷 애플리케이션을 구현하는 시스템으로서,

각각이 정의된 유형을 가지는 애플리케이션 객체(486) 및 메소드(484)의 세트를 포함하는 서버(480),

상기 객체 및 메소드를 호출하는 스크립트의 클라이언트 세트를 생성하는 생 성 엔진(495) - 상기 스크립트 각각은 상기 애플리케이션 객체 및 메소드의 세트 중 적어도 하나의 객체 또는 메소드와 매칭하는 유형 정의를 포함함 - , 및

클라이언트 프로세싱 장치 상의 하나 이상의 클라이언트 스크립트로부터 요청을 수신하고 상기 요청을 상기 애플리케이션 객체 및 메소드 중 하나로 라우팅하는 응답 엔진(494)을 포함하는 시스템.
제18항에 있어서,

각각의 클라이언트 스크립트는 대응하는 서버 객체 및 메소드에 매핑되는 정의된 유형(720)을 포함하는 시스템.
제18항에 있어서,

상기 생성 엔진(495)은 반영하는(reflective) 프로세스인 시스템.
분산형 프로세싱 시스템에서 클라이언트 프로세스와 서버 프로세스 간에 통신하는 방법으로서,

(a) 상기 클라이언트 프로세스에 의해, 상기 서버에게 함수 요청을 발행하는 단계 - 상기 함수 요청은 요청된 서버 함수의 유형에 의해 정의된 포맷을 가지는 데이터 스트링을 포함함 - ,

(b) 상기 서버 프로세스에 의해, 상기 함수 호출을 수신하고 상기 스트링 상의 요청된 함수를 수행하는 단계(530), 및

(c) 상기 서버 프로세스에 의해, 상기 함수 호출에 대한 응답을 발행하는 단계(540) - 상기 응답은 상기 객체에 의해 정의된 클라이언트 측 프로세싱 포맷으로 되어 있음 -

를 포함하는 방법.
제21항에 있어서,

상기 클라이언트 프로세스는 상기 요청된 함수에 대응하는 유형 정의(515)를 포함하는 방법.
제21항에 있어서,

상기 발행 및 수신 단계는 HTTP 프로토콜을 이용하여 수행되는 방법.
제23항에 있어서,

발행 단계(a)는 URL(810, 1210)로 함수 요청을 발행하는 단계를 포함하는 방법.
제24항에 있어서,

발행 단계(a)는 함수 식별자를 포함하는 URL(810)을 생성하는 단계를 포함하는 방법.
제24항에 있어서,

발행 단계(a)는 상기 요청된 함수의 유형 정의에 의해 정렬된 구두점으로 구분되는 리스트로된 상기 데이터 스트링을 포함하는 URL(1210)을 생성하는 단계를 포함하는 방법.
제24항에 있어서,

상기 URL(810)은 상기 프로토콜의 버전 번호를 포함하는 방법.
제21항에 있어서,

발행 단계(c)는 스크립트에 의해 해석될 수 있는 포맷(820, 1220)으로 상기 응답을 발행하는 단계를 포함하는 방법.
제28항에 있어서,

발행 단계(c)는 자바스크립트 포맷(710)으로 상기 응답을 발행하는 단계를 포함하는 방법.
제28항에 있어서,

발행 단계(c)는 상기 응답을 어레이(1220)로 발행하는 단계를 포함하는 방법.
제28항에 있어서,

발행 단계(c)는 상기 응답을 중첩된 어레이(1220)로 발행하는 단계를 포함하는 방법.
제28항에 있어서,

상기 방법은 객체(610)인 방법.
제32항에 있어서,

상기 방법은 객체의 객체(620)인 방법.
제32항에 있어서,

상기 방법은 어레이의 객체(620)인 방법.
제32항에 있어서,

상기 방법은 원시 데이터 유형의 객체(620)인 방법.
제28항에 있어서,

상기 응답은 원시 데이터 유형(620)인 방법.
제1 컴퓨터와 제2 컴퓨터 간의 통신을 위한 프로토콜로서,

상기 제1 컴퓨터로부터 상기 제2 컴퓨터로의, 상기 제2 컴퓨터 상의 함수에 대한 함수 식별자 및 상기 함수에 대한 인수를 포함하는 요청 - 상기 인수는 상기 함수 식별자에 의해 호출되는 함수에 대한 유형에 의해 정의됨 - , 및

상기 제2 컴퓨터로부터 상기 제1 컴퓨터로의, 상기 함수의 결과를 포함하는 응답(406, 820) - 상기 응답은 스크립트 입력으로서 정의됨 - 을 포함하는 프로토콜.
제37항에 있어서,

상기 인수(820)는 상기 유형에 기초하여 구성된 데이터를 포함하는 프로토콜.
제37항에 있어서,

상기 인수(820)는 상기 호출된 함수의 상기 유형 정의에 의해 정렬된 구두점으로 구분되는 리스트로된 데이터 스트링을 포함하는 프로토콜.
제37항에 있어서,

상기 스크립트 입력(720)은 자바스크립트 포맷인 프로토콜.