KR101145005B1

KR101145005B1 - 보안 모듈 간 통신 메커니즘

Info

Publication number: KR101145005B1
Application number: KR1020107006722A
Authority: KR
Inventors: 료 치지와; 이삭 알프레드 헨리 와슬리스키
Original assignee: 야후! 인크.
Priority date: 2007-08-27
Filing date: 2008-08-11
Publication date: 2012-05-21
Also published as: US9424551B2; JP2011501829A; US20120131448A1; TW200926043A; EP2183721A2; US8108770B2; KR20100049669A; US20090063613A1; CN101790747A; US8108771B2; JP5017453B2; WO2009029404A3; US20090064183A1; WO2009029404A2; CN101790747B; EP2183721B1; EP2183721A4; HK1145558A1; TWI387933B

Abstract

본 발명은 도메인 보안 모델을 구현하는 브라우저 클라이언트와 같은 사용자 에이전트에 의해 처리되는 문서의 맥락에서 실행되는 코드 모듈들 사이의 안전하고 구조화된 상호작용들을 용이하게 하는 것과 관련된 방법들, 장치들 및 시스템들을 제공한다. 특정 구현에서, 베이스 문서 내에 로딩된 모듈 커넥터 스크립트 또는 객체가 상이한 근원들 또는 도메인들에 대응하는 청취자 모듈들 및 송신자 모듈들을 발견하고, 이들 사이에 정보를 전달한다. 이러한 방식으로, 청취자 모듈은 어떠한 형태의 상호접속도 명시적으로 정의할 필요 없이 최종 사용자가 양 모듈을 웹페이지에 추가하게 함으로써 간단하게, 동일 페이지 상에 위치하는 송신자 모듈로부터의 정보를 소비하고 이용할 수 있다. 예를 들어, 사진 모듈은 원격 사진 공유 사이트에서 사용자 계정에 액세스하고, 슬라이드쇼에서 사진들을 렌더링하는 모듈에 하나 또는 그 이상의 사진을 제공할 수 있다.

Description

보안 모듈 간 통신 메커니즘{SECURE INTER-MODULE COMMUNICATION MECHANISM}

본 발명은 일반적으로 브라우저 또는 다른 클라이언트 애플리케이션에 의해 처리되는 웹페이지 또는 다른 구조화된 문서의 맥락에서 실행 가능한 코드 객체들(code objects) 사이의 통신에 관한 것이다.

인터넷과 같은 광역 네트워크들에 의해 접속되는 상호작용 시스템들은 정보 교환, 사교적 상호작용 및 디지털 매체의 공유를 위한 활성 매체들로 꾸준히 진화하여 왔다. 통상적으로, 인터넷 사용자들은 개인 홈 페이지(예를 들어, my.yahoo.com 등), 사교 네트워크 사이트(예를 들어, facebook.com, myspace.com 등) 상의 개인 페이지 등과 같은 맞춤화 가능한 개인 페이지들을 특징으로 하는 다양한 서비스 제공자들과의 하나 또는 그 이상의 계정을 유지한다. 그러한 페이지들의 최종 사용자들에 대한 유용성 및 맞춤화를 향상시키기 위하여, 때때로 서비스 제공자들은 사용자들이 하나 또는 그 이상의 기능 모듈 또는 위젯(이하, 모듈이라 함)을 이용하여 그들의 페이지들을 맞춤화하는 것을 허용한다.

웹 또는 인터넷 환경에서, 그러한 모듈들은 다양한 유용하거나 재미있는 기능들을 달성하기 위하여 브라우저와 같은 클라이언트 애플리케이션의 맥락에서 실행되는 HTML 코드 및 스크립트들(자바스크립트, 및 비동기 자바스크립트 및 XML(AJAX) 등)을 포함할 수 있다. 예를 들어, RSS(Really Simple Syndication) 피드들로부터 얻어지는 블로그 엔트리들, 뉴스 헤드라인들 또는 팟캐스트(podcast)들과 같은 콘텐츠를 표시하기 위해 모듈들이 개발될 수 있다. flickr.com과 같은 콘텐츠 수집 사이트 상에서 호스트되는 사진들의 슬라이드쇼를 표시하기 위해 다른 모듈들이 개발될 수 있다. 다른 모듈들은 실시간 주가를 표시할 수 있다. 많은 사례에서, 모듈들은 베이스 HTML 문서 내에 프레임들 또는 인라인 프레임들(iframes)로서 나타나는데, 이는 베이스 HTML 문서 내에 다른 HTML 문서를 임베드하는 것을 가능하게 한다.

이러한 맞춤화 가능한 페이지들을 유지하는 서비스 제공자들은 사용자들이 선택하여 그들의 페이지들에 추가할 수 있는 다수의 모듈을 개발할 수 있다. 그러나, 모듈들이 수행할 수 있는 기능들의 광범위한 다양성 및 외견상 제한되지 않는 사용자들의 창조성을 고려하여, 일부 서비스 제공자들은 또한 제삼자들이 모듈들을 개발하는 것도 마찬가지로 허용하는 열린 개발 환경을 제공한다. 그러나, 제삼자 모듈들을 허용함에 있어서 보안 문제가 수반되는 경우, 서비스 제공자들은 또한 통상적으로 제삼자 모듈들과 관련된 보안 문제를 최소화하기 위해 소정의 수단들에 의존한다. 구체적으로, 웹페이지의 상이한 윈도우들 및 프레임들 내의 콘텐츠는 문서 객체 모델과의 스크립팅에 의해 강력한 방식으로 상호작용할 수 있다. 그러나, 브라우저 클라이언트는 그의 다양한 윈도우들 및 프레임들 내에 베이스 페이지 및 하나 또는 그 이상의 모듈과 같은 관계없는 콘텐츠를 동시에 표시할 수 있으므로, 데이터 무결성 및 정보의 프라이버시를 보호하기 위해 소정의 정책들이 적용되어야만 한다. 보안 수단들이 취해지지 않는 경우, 하나의 프레임 내에서 실행되는 모듈이 다른 모듈들 또는 베이스 문서 내의 정보를 학습하는 것이 가능할 수도 있다. 이러한 방식으로 제한되지 않는 액세스를 허용하는 것은 사용자의 프라이버시의 위반일 수 있다.

따라서, 대부분의 공개적으로 이용 가능한 브라우저 클라이언트들(Mozilla® Firefox 및 Microsoft® Internet Explorer® 등)은 동일 근원으로부터의 콘텐츠와의 상호작용들만을 허가하는 도메인 보안 모델을 지원한다. 예를 들어, 하나의 도메인(예를 들어, http://yahoo.com/)에 대응하는 인라인 프레임의 객체는, 다른 프레임 또는 베이스 문서의 콘텐츠가 다른 도메인(예를 들어, https://example.com/)으로부터 공급되는 경우에 그 콘텐츠에 액세스하지 못할 수 있다. 예를 들어, 자바스크립트와 관련하여, 크로스-사이트 보안 문제들을 방지하기 위하여, 브라우저들은 자바스크립트 객체 모델에서 동일 근원 정책을 실시한다. 즉, 하나의 인라인 프레임 내에서 실행되는 스크립트들은 인라인 프레임들 내의 양 페이지들이 동일 근원으로부터 제공되지 않는 경우에는 다른 인라인 프레임 내의 어떠한 객체에도 액세스하지 못할 수 있다. 일부 브라우저들은 프로토콜, 포트(주어지는 경우) 및 호스트가 두 페이지에 대해 동일한 경우에 두 페이지가 동일 근원을 갖는 것으로 간주한다. 도메인 보안이 없는 경우, 악성 페이지가 다른 페이지를 염탐(snoop)하거나, 그의 도메인 밖의 쿠키들에 액세스하거나, 동적 하이퍼텍스트 마크업 언어(DHTML)를 이용하여 콘텐츠를 조작할 수 있다.

서비스 제공자들은 제삼자 모듈들과 연계하여 표준 브라우저들에 의해 지원되는 도메인 보안 모델의 이점을 이용할 수 있다. 예를 들어, 서비스 제공자는 베이스 문서와 다른 근원 또는 도메인에 대응하는 인라인 프레임들 내에서 제삼자 모듈 또는 제삼자 모듈에 대한 참조들(예를 들어, src 속성)을 포함하는 HTML 문서들은 물론이고, 다른 인라인 프레임들 내에 임베디드된 문서들을 서비스할 수 있다. 이러한 방식으로, 주어진 제삼자 모듈의 동작은 그의 대응 인라인 프레임의 맥락에 효과적으로 포함된다.

본 발명은 도메인 보안 모델을 구현하는 브라우저 클라이언트와 같은 사용자 에이전트에 의해 처리되는 문서의 맥락에서 실행되는 코드 모듈들 사이의 안전하고 구조화된 상호작용들을 용이하게 하는 것과 관련된 방법들, 장치들 및 시스템들을 제공한다. 특정 구현에서, 베이스 문서 내로 로딩된 모듈 커넥터 스크립트 또는 객체가, 상이한 근원들 또는 도메인들에 대응하는 청취자(listener) 모듈들 및 송신자 모듈들을 발견하고, 이들 사이에 정보를 패스한다. 이러한 방식으로, 청취자 모듈은 어떠한 형태의 상호접속도 명시적으로 정의할 필요 없이 최종 사용자가 양 모듈을 웹페이지에 추가하게 함으로써 간단하게, 동일 페이지 상에 위치하는 송신자 모듈로부터의 정보를 소비하고 이용할 수 있다. 예를 들어, 사진 모듈은 원격 사진 공유 사이트에서 사용자 계정에 액세스하고, 슬라이드쇼로 사진들을 렌더링하는 모듈에 하나 또는 그 이상의 사진을 제공할 수 있다.

도 1은 본 발명의 특정 구현들이 동작할 수 있는 네트워크 환경을 나타내는 개략도이다.
도 2는 물리 서버를 구현하는 데 사용될 수 있는 예시적인 컴퓨팅 시스템 아키텍처를 나타내는 도면이다.
도 3은 예시적인 그래픽 사용자 인터페이스를 나타내는 도면이다.
도 4는 베이스 웹페이지 또는 문서에 대응하는 HTML 문서의 요소들을 나타내는 예시적인 코드의 도면이다.
도 5는 모듈에 대응하는 HTML 문서의 요소들을 나타내는 예시적인 코드의 도면이다.
도 6 내지 9는 본 발명의 특정 구현에 따른 모듈간 통신 프로세스들을 나타내는 흐름도들이다.

A. 예시적인 네트워크 시스템 아키텍처

도 1은 특정 구현들이 동작할 수 있는 예시적인 네트워크 환경을 나타낸다. 도 1에 도시된 바와 같이, 본 발명의 특정 구현들은 서비스 제공자 사이트(30) 및 하나 또는 그 이상의 클라이언트 시스템(28)을 포함하는 네트워크 환경에서 동작할 수 있다. 서비스 제공자 사이트(30)는 하이퍼텍스트 전송 프로토콜(HTTP) 서버(26) 및 네트워크 애플리케이션(27)을 호스팅하는 네트워크 애플리케이션 서버(31), 데이터베이스(22)에 동작적으로 결합되는 데이터베이스 시스템(20), 및 모듈 정보의 데이터 저장소(36)에 동작적으로 결합되는 모듈 호스팅 플랫폼(34)을 포함한다. 라우터(27)는 서비스 제공자 사이트(30)를 네트워크 클라우드(network cloud)(24)에 동작적으로 결합한다. 네트워크 클라우드(24)는 일반적으로 하나 또는 그 이상의 상호접속된 네트워크를 나타내며, 여기에 설명되는 시스템들 및 호스트들은 그러한 네트워크를 통해 통신할 수 있다. 네트워크 클라우드(24)는 패킷 기반 광역 네트워크(인터넷 등), 비공개 네트워크, 무선 네트워크, 위성 네트워크, 셀룰러 네트워크, 페이징 네트워크 등을 포함할 수 있다.

데이터베이스 시스템(20)은, 데이터베이스 애플리케이션을 호스트할 수 있고, 사교 네트워크 시스템, 맞춤화 가능한 사용자 홈 페이지(예를 들어, my.yahoo.com) 등과 같은 다양한 네트워크 애플리케이션들과 연계하여 동작할 수 있는 네트워크 어드레스 가능 시스템이다. 데이터베이스 시스템(20)은 컴퓨터 네트워크를 통해 하나 또는 그 이상의 호스트에 의해 액세스 가능하다. 일 구현에서, 데이터베이스(22)는 사용자 계정 정보, 사용자 프로파일 데이터, 어드레스들, 프레퍼런스(preference)들, 금융 계정 정보와 같은 다양한 타입의 정보를 저장할 수 있다. 데이터베이스(22)는 디지털 콘텐츠 데이터 객체들 및 다른 매체 자산들과 같은 콘텐츠도 저장할 수 있다. 특정 구현들에서, 콘텐츠 데이터 객체 또는 콘텐츠 객체는 데이터 파일 또는 레코드 내에 통상적으로 저장되거나 구현되는 디지털 정보의 개별 아이템이다. 콘텐츠 객체들은 텍스트(예를 들어, ASCII, SGML, HTML), 이미지(예를 들어, jpeg, tif 및 gif), 그래픽(벡터 기반 또는 비트맵), 오디오, 비디오(예를 들어, mpeg) 또는 기타 멀티미디어 및 이들의 조합을 포함하는 다양한 형태를 가질 수 있다. 콘텐츠 객체 데이터는 실행 가능 코드 객체(예를 들어, 브라우저 윈도우 또는 프레임 내에서 실행 가능한 게임), 팟캐스트 등도 포함할 수 있다. 구조적으로, 데이터베이스(22)는 데이터 저장 및 관리 시스템들의 대형 클래스를 의미한다. 특정 구현들에서, 데이터베이스(22)는 데이터베이스 서버, 대용량 저장 매체, 매체 라이브러리 시스템 등과 같은 컴포넌트들을 포함하는 임의의 적절한 물리 시스템에 의해 구현될 수 있다. 모듈 호스팅 플랫폼(34)은 서비스 제공자 사이트(30)에 의해 내부적으로 개발된 모듈들은 물론이고, 제삼자들에 의해 개발된 모듈들도 호스트한다. 데이터 저장소(36)는 컴퓨터 프로그램 코드, HTML 코드, 스크립트, Adobe® Flash® (swf) 객체 등과 같은 모듈 정의 데이터를 저장한다.

특정 구현에서, 네트워크 애플리케이션(27)은 사교 네트워크 애플리케이션 또는 맞춤화 가능한 홈 페이지와 같은 네트워크 애플리케이션을 하나 또는 그 이상의 사용자에게 제공하기 위해 요구되는 바에 따라, 데이터베이스 시스템(20)에 액세스하여, 그 안에 저장된 데이터를 검색, 추가 또는 변경할 수 있다. 주어진 사용자로부터의 홈페이지에 대한 요청에 응답하여, 네트워크 애플리케이션 서버(27)는 데이터베이스 시스템(20)에 액세스하여, 대응하는 사용자 계정으로부터 페이지 포맷 및 레이아웃 정보를 검색할 수 있다. 레이아웃 정보는 많은 것들 중에서 사용자가 그의 페이지에 추가한 모듈들을 식별할 수 있다. 이어서, 네트워크 애플리케이션(27)은 레이아웃 정보에서 식별된 모듈들을 추가하도록 HTML 코드 및 다른 콘텐츠를 취득하거나 생성하기 위하여 모듈 호스팅 플랫폼(34)에 액세스할 수 있다. 이어서, 네트워크 애플리케이션(27)은 이러한 콘텐츠를 베이스 문서 또는 페이지 템플릿 내에 병합하고, 병합된 페이지를 사용자에게 전송할 수 있다.

클라이언트 시스템들(28)은 네트워크 서비스 제공자 또는 임의의 다른 적절한 수단을 통해 네트워크 환경에 동작 가능하게 접속된다. 클라이언트 시스템들(28)은 랩탑 컴퓨터, 개인용 휴대 단말기(PDA) 등과 같은 개인용 컴퓨터 또는 이동 장치를 포함할 수 있다. 클라이언트 시스템들(28)은 하나 또는 그 이상의 프로세서, 메모리, 네트워크 인터페이스, 하나 또는 그 이상의 입력/출력(I/O) 장치 및 이들 컴포넌트를 상호접속하는 시스템 버스를 포함할 수 있다. 클라이언트 시스템들(28)은 또한 운영 체제, 및 서비스 제공자 사이트(30)와 상호작용하도록 동작하는 브라우저 클라이언트와 같은 사용자 에이전트를 포함할 수 있다. 브라우저 클라이언트들은 Microsoft® Internet Explorer®, Mozilla Firefox®, Apple® Safari®, Netscape® Navigator® 및 임의의 다른 적절한 사용자 에이전트를 포함할 수 있다. 그러한 브라우저 클라이언트들은 상이한 근원들로부터 서비스되는 콘텐츠(예를 들어, 코드 객체들 및 스크립트들) 사이의 상호작용을 불허하는 도메인 보안 모델을 지원한다. 특정 구현에서, 근원은 호스트 이름, 포트 및 프로토콜의 조합으로서 정의된다. 호스트 이름은 IP 어드레스 또는 도메인 이름일 수 있다. 포트는 전송 제어 프로토콜/인터넷 프로토콜(TCP/IP) 포트를 지칭하며, 프로토콜은 HTTP, S-HTTP, HTTPS(HTTP over Secure Sockets Layer)와 같은, 전송 계층 위의 프로토콜 계층들을 지칭한다. 또한, 일부 브라우저들은 IP 어드레스(예를 들어, 66.213.145.93) 및 이 IP 어드레스들에 분해되는 도메인 이름을, 인라인 프레임들과 연계하여 사용될 때, 상이한 근원들로서 간주한다.

A.1. 예시적인 서버 시스템 아키텍처

여기에 설명되는 서버 호스트 시스템들(네트워크 애플리케이션 서버(31) 등)은 컴퓨팅 시스템들 및 아키텍처들의 광범위한 배열로 구현될 수 있다. 또한, 클라이언트 시스템들(28)에 대한 시스템 아키텍처는 서버 시스템 아키텍처들과 매우 유사할 수 있다. 예를 들어, 시스템 아키텍처는 마우스, 키보드 및 디스플레이 장치와 같은 I/O 시스템들을 더 포함할 수 있다. 제한이 아니라, 설명의 목적으로 예시적인 컴퓨팅 아키텍처들이 아래에 설명된다.

도 2는 물리 서버를 구현하는 데 사용될 수 있는 예시적인 컴퓨팅 시스템 아키텍처를 나타낸다. 일 실시예에서, 하드웨어 시스템(200)은 프로세서(202), 캐시 메모리(204), 및 여기에 설명되는 기능들과 관련된 하나 또는 그 이상의 소프트웨어 애플리케이션 및 드라이버를 포함한다. 또한, 하드웨어 시스템(200)은 고성능 입출력(I/O) 버스(206) 및 표준 I/O 버스(208)를 포함한다. 호스트 브리지(210)가 프로세서(202)를 고성능 I/O 버스(206)에 결합하는 반면, I/O 버스 브리지(212)는 2개의 버스(206, 208)를 서로 결합한다. 시스템 메모리(214) 및 네트워크/통신 인터페이스(216)가 버스(206)에 결합된다. 하드웨어 시스템(200)은 비디오 메모리(도시되지 않음) 및 비디오 메모리에 결합되는 디스플레이 장치를 더 포함할 수 있다. 대용량 저장 장치(218) 및 I/O 포트들(220)이 버스(208)에 결합된다. 하드웨어 시스템(200)은 버스(208)에 결합되는 키보드 및 포인팅 장치, 및 디스플레이 장치(도시되지 않음)를 옵션으로서 포함할 수 있다. 집합적으로 이들 요소는, 캘리포니아, 산타 클라라의 인텔 사에 의해 제조되는 x86 호환 프로세서들 및 캘리포니아, 서니베일의 AMD(Advanced Micro Devices) 사에 의해 제조되는 x86 호환 프로세서들은 물론이고, 임의의 다른 적절한 프로세서에 기초하는 범용 컴퓨터 시스템들을 포함하지만 이것에만 한정되지는 않는 광범위한 카테고리의 컴퓨터 하드웨어 시스템들을 나타내는 것을 의도한다.

하드웨어 시스템(200)의 요소들은 아래에 더 상세히 설명된다. 구체적으로, 네트워크 인터페이스(216)는 하드웨어 시스템(200)과 이더넷(예를 들어, IEEE 802.3) 네트워크 등과 같은 임의의 광범위한 네트워크 사이에 통신을 제공한다. 대용량 저장 장치(218)는 로케이션 서버(22) 내에 구현되는 전술한 기능들을 수행하기 위한 데이터 및 프로그래밍 명령어들에 대한 영구 저장을 제공하는 반면, 시스템 메모리(214)(예를 들어, DRAM)는 프로세서(202)에 의해 실행될 때의 데이터 및 프로그래밍 명령어들에 대한 임시 저장을 제공한다. I/O 포트들(220)은 하드웨어 시스템(200)에 결합될 수 있는 추가 주변 장치들 사이의 통신을 제공하는 하나 또는 그 이상의 직렬 및/또는 병렬 통신 포트이다.

하드웨어 시스템(200)은 다양한 시스템 아키텍처를 포함할 수 있으며, 하드웨어 시스템(200)의 다양한 컴포넌트는 재배열될 수 있다. 예를 들어, 캐시(204)는 프로세서(202)와 함께 온-칩일 수 있다. 대안으로, 캐시(204)와 프로세서(202)는 "프로세서 모듈"로서 함께 팩킹될 수 있으며, 프로세서(202)는 "프로세서 코어"로서 지칭된다. 또한, 본 발명의 소정 실시예들은 상기 컴포넌트들의 모두를 필요로 하지 않거나 포함하지 않을 수도 있다. 예를 들어, 표준 I/O 버스(208)에 결합되는 것으로 도시된 주변 장치들은 고성능 I/O 버스(206)에 결합될 수 있다. 또한, 일부 실시예들에서는 단일 버스만이 존재할 수 있고, 하드웨어 시스템(200)의 컴포넌트들은 단일 버스에 결합될 수 있다. 또한, 하드웨어 시스템(200)은 추가 프로세서, 저장 장치 또는 메모리와 같은 추가 컴포넌트들을 포함할 수 있다.

후술하는 바와 같이, 일 구현에서, 여기에 설명되는 물리 서버들 중 하나 또는 그 이상의 물리 서버의 동작들은 하드웨어 시스템(200)에 의해 실행되는 일련의 소프트웨어 루틴들로서 구현된다. 이러한 소프트웨어 루틴들은 프로세서(202)와 같은 하드웨어 시스템 내의 프로세서에 의해 실행될 복수의 또는 일련의 명령어들을 포함한다. 초기에, 일련의 명령어들은 대용량 저장 장치(218)와 같은 저장 장치 상에 저장될 수 있다. 그러나, 일련의 명령어들은 디스켓, CD-ROM, ROM, EEPROM 등과 같은 임의의 적절한 저장 매체 상에 저장될 수 있다. 또한, 일련의 명령어들은 국지적으로 저장될 필요는 없으며, 네트워크/통신 인터페이스(216)를 통해 네트워크 상의 서버와 같은 원격 저장 장치로부터 수신될 수 있다. 명령어들은 대용량 저장 장치(218)와 같은 저장 장치로부터 메모리(214) 내에 복사된 후, 프로세서(202)에 의해 액세스되고 실행된다.

운영 체제는 소프트웨어 애플리케이션들(도시되지 않음)에 대한 데이터의 입출력을 포함하는 하드웨어 시스템(200)의 동작을 관리하고 제어한다. 운영 체제는 시스템 상에서 실행되고 있는 소프트웨어 애플리케이션들과 시스템의 하드웨어 컴포넌트들 간의 인터페이스를 제공한다. 본 발명의 일 실시예에 따르면, 운영 체제는 워싱턴, 레드먼드의 마이크로소프트사로부터 입수 가능한 Windows® 95/98/NT/XP/Vista 운영 체제이다. 그러나, 본 발명은 캘리포니아, 쿠퍼티노의 애플 컴퓨터사로부터 입수 가능한 애플 매킨토시 운영 체제, UNIX 운영 체제, LINUX 운영 체제 등과 같은 다른 적절한 운영 체제들과 함께 이용될 수 있다. 물론, 다른 구현들도 가능하다. 예를 들어, 여기에 설명되는 서버 기능들은 백플레인을 통해 통신하는 복수의 서버 블레이드에 의해 구현될 수 있다.

B. 모듈간 통신 기능들

도 3은 브라우저 윈도우(304) 내에 렌더링되는 예시적인 베이스 웹페이지(302)를 나타낸다. 베이스 웹페이지(302)는 베이스 웹페이지(302) 내에 인라인 프레임들로서 삽입되는 2개의 모듈 윈도우(306a, 306b)를 포함한다. 도 4는 브라우저 클라이언트가 브라우저 윈도우(304) 내에 베이스 웹페이지(302)를 렌더링하기 위해 처리하는 베이스 웹페이지(302)의 (소정의 의사 코드를 포함하는) HTML 코드의 서브세트를 나타낸다. 베이스 웹페이지(302)의 HTML 코드는 제1 인라인 프레임 요소(402) 및 제2 인라인 프레임 요소(404)를 포함한다. "src" 요소는 브라우저 클라이언트가 인라인 프레임의 맥락 내에서 유니폼 리소스 로케이터(URL)에 대응하는 콘텐츠에 로딩하게 한다. 일 구현에서, 서비스 제공자 사이트(30)는 베이스 웹페이지(302)의 근원과 다른 근원들로부터의 인라인 프레임 요소들(402, 404) 내의 모듈들을 서비스한다. 설명의 목적으로, 본 개시는 그러한 인라인 프레임들(402, 404)을 모듈 인라인 프레임들로서 지칭한다. 이러한 인라인 프레임들은 베이스 웹페이지(302)의 자식 요소(child element)들이다. 예를 들어, (설명의 목적으로 모듈 A로 표시되는) 제1 모듈에 대응하는 콘텐츠는 modulehost1.com으로 명명되는 호스트로부터 서비스받을 수 있으며, 제2 모듈은 modulehost2.com으로 명명되는 호스트로부터 서비스받을 수 있다. 도 3에 도시된 바와 같이, 베이스 웹페이지(302)는 http://my.yahoo.com/과 연관된 호스트로부터 서비스받는다. 도 4에 나타난 바와 같이, 베이스 웹페이지(302)의 HTML 코드는 (설명의 목적으로 "콘딧(conduit)"으로 명명되는) 모듈 커넥터 스크립트 요소(406)를 더 포함한다. 도시된 구현에서, 모듈 커넥터 스크립트는 페이지 내에 로딩되는 자바스크립트 객체이다. 스크립트 요소(406)는 또한 모듈 식별자(moduleId) 맵핑 정보(408)에 대한 인라인 프레임 토큰(iFtoken)을 포함한다. 도 4에 나타난 바와 같이, 인라인 프레임 요소들(402, 404)은 모듈(예를 들어, module_A, module_B)을 식별하는 식별자들(id)을 포함하고, 로케이션 (src) 스트링은 주어진 모듈에 대응하는 토큰 값(iFtokenA, iFtokenB 등)을 식별하는 토큰(token) 파라미터를 포함한다. 맵핑 정보(408)는 이러한 토큰들을 대응 모듈 식별자들에 맵핑한다. 모듈 커넥터 스크립트는 이러한 맵핑들을 이용하여, 하나의 인라인 프레임 내에서 실행되는 모듈이 다른 모듈인 것처럼 가장하지 못하도록 보장할 수 있다. 예를 들어, 모듈 커넥터 스크립트로 패스되는 메시지들은 모듈 커넥터 스크립트가 모듈 인라인 프레임의 식별자(id)에 관하여 메시지를 검증하는 데 사용할 수 있는 토큰들, 및 모듈 맵핑 정보(408)에 대한 토큰을 포함할 수 있다. 일 구현에서, 모듈 커넥터 스크립트는 토큰들을 이용하여, 메시지들이 추가되어야 하는 메시지 큐들 및 모듈들을 식별한다. 다른 구현들도 가능하다. 예를 들어, 모듈들 중 하나 또는 그 이상은 브라우저 윈도우(304) 내에 가시적으로 렌더링될 필요가 없다.

도 5는 "모듈 A"에 대응하는 HTML 문서의 (모듈 상호접속 및 다른 기능들을 나타내기 위한 소정의 의사 코드를 포함하는) 예시적인 HTML 코드를 나타낸다. 도시된 코드는 단지 설명을 위한 것이다. 동일하거나 유사한 구조 및 커맨드들을 갖는 모듈 B에 대해 유사한 문서가 로딩될 수 있다. 아래에 더 상세히 설명되는 바와 같이, 모듈들은 송신자들 및 청취자들로서 등록될 수 있다. 도 5는 HTML 코드가 메신저 스크립트 객체로 하여금 모듈 인라인 프레임 내에 로딩되게 하는 스크립트 요소(502)를 포함하는 것을 나타낸다. 메신저 스크립트에 대한 데이터 로케이터는 또한 토큰(iFtokenA)을 포함하며, 이 토큰은 서비스 제공자 사이트(30)에 의해 수신되고, 메신저 스크립트에 포함되어, 메신저 스크립트가 후술하는 바와 같이 토큰을 메신저 인라인 프레임 요소 내에 임베드하는 것을 허용한다. 특히, 메신저 스크립트는 로딩되어 실행될 때에 (본 명세서에서 "메신저 인라인 프레임"으로서 지칭되는) 다른 인라인 프레임을 모듈 인라인 프레임 내에 임베드하도록 동작한다. 일 구현에서, 메신저 스크립트는 모듈 인라인 프레임의 HTML 문서의 객체 모델에 액세스하고, HTML 코드를 추가하여, 실행 시간에 메신저 인라인 프레임을 생성한다. 메신저 인라인 프레임은 모듈 인라인 프레임의 자식 요소이다. 일 구현에서, 메신저 인라인 프레임은 브라우저 윈도우(304) 내에 보이거나 렌더링되지 않는다. 설명의 목적으로 예시적인 코드가 아래에 제공된다.

메신저 인라인 프레임 요소의 src 속성 내에 표시되는 근원은 베이스 웹페이지(302)와 동일한 근원이므로, 베이스 웹페이지(302)의 객체들은 메신저 인라인 프레임의 콘텐츠와 상호작용할 수 있다. 그러나, 모듈 인라인 프레임의 콘텐츠는 베이스 웹페이지(302) 또는 메신저 인라인 프레임의 콘텐츠와 상호작용할 수 없다. 메신저 인라인 프레임 요소의 src 속성은 또한 토큰 값(여기서는 iFtokenA)을 포함한다. 전술한 바와 같이, 메신저 스크립트는 또한 메신저 스크립트가 메신저 인라인 프레임을 베이스 웹페이지(302)의 모듈 커넥터 스크립트에 등록하게 하는 코드를 포함한다((top.conduit.register(window, token)). 모듈 커넥터 스크립트는 그에게 전달되는 토큰 및 토큰 맵핑 정보(408)에 대한 모듈 식별자를 이용하여, (모듈 인라인 프레임의 id 속성에 액세스함으로써) 메신저 스크립트 및 메신저 인라인 프레임에 대응하는 모듈 인라인 프레임을 식별할 수 있다. 모듈 커넥터 스크립트는 또한 인라인 프레임 및 메신저 인라인 프레임 요소들에 액세스하고, 이들을 그의 맵핑 정보(408)에 대해 비교함으로써 등록 메시지를 확인(validate)할 수 있다. 또한, 모듈 커넥터 스크립트는 토큰 값들을 이용하여, 다양한 메시지가 추가되어야 하는 메신저 인라인 프레임 메시지 큐를 식별할 수 있다. 메신저 인라인 프레임 요소의 src URL은 또한 메시지 큐로서 작용하는 (# 뒤의) 인코딩된 스트링을 포함한다. 해시(#) 뒤의 스트링 값의 변경들은 브라우저 클라이언트가 새로운 요청을 전송하게 하지 않는다. 특정 구현에서, 인코딩된 스트링은 자바스크립트 객체 표기법(JSON)을 이용하여 메시지 큐를 구현하며, 각각의 메시지는 JSON 신택스를 이용하여 범위가 정해진다. 대부분의 브라우저 클라이언트들의 도메인 보안 모델에 따르면, 메신저 스크립트는 먼저 메신저 인라인 프레임 요소의 로케이션 (src)를 설정하고, 또한 메신저 인라인 프레임이 생성된 후에 이 로케이션을 재설정할 수 있다. 또한, 메신저 인라인 프레임 요소의 로케이션 (src)가 베이스 웹페이지(302)와 동일한 근원으로 설정되는 경우, 모듈 커넥터 스크립트는 로케이션 (src) 및 인코딩된 스트링에 액세스하여, 메시지 큐 내에 어떤 메시지들이 있는지를 결정할 수 있다. 또한, 모듈 커넥터 스크립트는 새로운 메시지들을 추가하고 만료된 메시지들을 삭제하기 위해 메시지 큐를 변경할 수 있다. 또한, 메신저 스크립트는 모듈 인라인 프레임의 맥락에서 동작하지만, 여전히 로케이션 (src) 속성을 판독하고 변경할 수 있다. 다른 구현들에서, 모듈 커넥터 스크립트는 또한 인라인 프레임 내에 임베디드될 수 있다. 그러한 구현에서, 메신저 스크립트는 (베이스 웹페이지(302)와 다른 경우에) 모듈 커넥터 스크립트의 근원과 동일한 근원을 식별하는 메신저 인라인 프레임 요소들을 생성할 것이다. 후술하는 바와 같이, 메신저 인라인 프레임 요소는 모듈에 의해 전송된 제1 메시지에 응답하여 동적으로 생성될 수 있다.

더욱이, 메신저 스크립트는 또한 메시징 애플리케이션 프로그래밍 인터페이스(API)를 선언하여, 모듈들이 송신자들 및 청취자들로서 등록하고 메시지들을 송신하고 수신하는 것을 가능하게 할 수 있다. 메시징 API는 또한 제삼자 모듈 개발자들이 이용 가능한 공개 사양이다. 메시징 API는 모듈 개발자들이 모듈 커넥터 스크립트에 등록하는 것은 물론, 다른 모듈들로부터 메시지들을 송신 및 수신할 수 있는 모듈들을 생성하는 것을 가능하게 한다. 예를 들어, 도 5의 예시적인 코드에서, 모듈은 사용자의 계정에 업로드된 하나 또는 그 이상의 사진에 대한 URL들을 얻기 위해 사이트 flickr.com에 액세스하는 loadPhotosFromFlickr 기능(function)을 포함한다. advertisePhotos 함수는 메신저 스크립트에 의해 선언된 인터페이스를 이용하여 메시지들을 전송한다. 도시된 구현에서, 기능은 메신저 스크립트가 대응하는 메신저 인라인 프레임의 로케이션 (src) 속성의 메시지 큐 내에 사진 URL들을 포스트하게 하는, 메시징 API에 따르는 send 커맨드(504)를 포함한다(아래 참조). 특정 구현에서, 모듈 커넥터 스크립트는 복수의 채널을 지원한다. 각각의 메시지는 채널을 식별하고, 채널 상에서 전송될 대응 데이터를 포함한다. 도 5에 나타난 바와 같이, send 커맨드(504)는 "pictures"라고 하는 채널을 식별한다. 또한, 각각의 채널은 청취 모듈이 예상할 수 있는 출력 포맷과 연관된다. 추가 채널들은 text, pictures, music, video 등을 포함할 수 있다. 예를 들어, pictures 채널은 출력이 사진들에 대한 URL들일 것을 요구하고, video 채널은 출력이 비디오들에 대한 URL들일 것을 요구한다. 일 구현에서, 모듈은 또한 "listener" 채널 상에서 send 커맨드를 발행함으로써 하나 또는 그 이상의 채널 상에 청취자로서 등록할 수 있다. 예를 들어, 하나의 가능한 메시징 API에 따르면, 모듈 개발자는 다음과 같은 API, 즉 receive("pictures", handler)를 갖는 receive 기능을 호출하고 핸들러(예를 들어, handler = function(msg))를 정의하는 모듈을 생성할 수 있다. 기반(underlying) 메시징 구현은 (send({channel:"listener", data:"pictures"})와 같은) send 동작을 수행하여, 특정 채널을 청취하기 위한 모듈의 능력을 광고할 수 있다. 메시징 구현은 미래의 참조를 위해 핸들러들에 대한 포인터들을 저장하며, 따라서 해당 채널 상의 메시지가 수신될 때, 메시지는 핸들러 기능으로 라우팅될 수 있다. 이러한 방식으로, 모듈은 receive 메시징 API에 의존하여 그가 메시지들을 수신할 수 있는 채널(들)을 식별하는 send 커맨드를 청취자 채널 상에서 발행한다. receive 함수는 수신된 메시지들에 대한 핸들러를 더 식별하며, 핸들러는 메시지를 처리하는 함수를 정의한다. 예를 들어, 메시지가 사진에 대한 URL인 경우, 핸들러 함수는 사진을 검색하고, 사용자에게 표시되는 슬라이스쇼에 사진을 추가하는 프로세스를 정의할 수 있다.

B.1. 메신저 스크립트- 송신

도 6은 모듈로부터 메시지들을 전송하기 위해 본 발명의 일 구현에 따라 메신저 스크립트에 의해 구현될 수 있는 방법을 나타낸다. 메신저 스크립트는 모듈 인라인 프레임의 맥락에서 동작하는 모듈로부터 발행되는 send 커맨드들을 청취한다(602). send 커맨드에 응답하여, 메신저 스크립트는 그에게 전달된 파라미터 정보에 기초하여 메시지를 구성하고, 타임 스탬프를 생성한다(604). 메신저 인라인 프레임이 아직 생성되지 않은 경우(606), 메신저 스크립트는 모듈 인라인 프레임 내에 메신저 인라인 프레임 요소를 생성하고, 메시지 및 타임 스탬프를 로케이션 (src) 속성에 대한 인코딩된 파라미터들로서 메시지 큐에 추가한다(위 참조)(608). 메신저 인라인 프레임이 이미 생성된 경우, 메신저 스크립트는 메시지 큐를 검사하여 타임 스탬프에 기초하여 만료된 메시지들을 삭제하며(610), 새로운 메시지 및 타임 스탬프를 메시지 큐에 추가한다(612). 이어서, 메신저 인라인 프레임의 로케이션 (src) 속성에 추가된 메시지들은 모듈 커넥터 스크립트에 의해 액세스되고 판독되는 데 이용될 수 있다.

B.2. 모듈 커넥터 스크립트

도 7은 본 발명의 하나의 가능한 구현에 따른 모듈 커넥터 스크립트에 의해 구현되는 방법을 나타낸다. 도 7에 도시된 프로세스 흐름은 제1 메신저 인라인 프레임의 등록에 응답하여 개시될 수 있다(위 참조). 도 7에 도시된 바와 같이, 메시지 커넥터 스크립트는 주기적으로, 예를 들어 20 밀리초마다 동작하여(702), 임의의 등록된 메신저 인라인 프레임들을 검사한다(704). 임의의 메신저 인라인 프레임들이 등록된 경우, 메시지 커넥터 스크립트는 모든 등록된 메신저 인라인 프레임에 대해(706), 임의의 새로운 메시지들이 메시지 큐에 추가되었는지를 결정한다(708). 추가된 경우, 메시지 커넥터 스크립트는 모든 새로운 메시지들(710)에 대해, 메시지를 각각의 메시지 내에 표시되는 채널의 임의의 청취자들에게 전달한다(712, 714).

도 8은 메시지를 청취자 모듈에 전달하는 것과 관련된, 본 발명의 하나의 가능한 구현에 따른 모듈 커넥터 스크립트에 의해 구현되는 프로세스를 나타낸다. 도 8에 도시된 바와 같이, 메시지 커넥터 스크립트는 청취자 모듈에 대응하는 메신저 인라인 프레임의 로케이션 (src) 속성에 액세스하고(802), 메시지 큐의 파라미터 정보를 디코딩한다(804). 메시지 큐 내의 각각의 메시지의 타임 스탬프들을 이용하여, 메시지 커넥터 스크립트는 오래된 메시지들을 삭제함으로써 메시지 큐로부터 오래된 메시지들을 소멸시키고(806), 새로운 메시지를 메시지 큐에 추가한다(808). 이러한 방식으로, 메시지는 대응하는 청취자 모듈의 모듈 인라인 프레임의 맥락에서 동작하는 메신저 스크립트에 의해 액세스될 수 있다.

다른 구현들도 가능하다. 예를 들어, 메시지 커넥터 스크립트의 동작은, 주어진 모듈과 상호작용할 수 있는 모듈들 또는 모듈이 메시지들을 수신할 수 있는 채널들을 정의하는 하나 또는 그 이상의 규칙을 구성할 수 있는 최종 사용자에 의해 조정될 수 있다. 또한, 모듈 커넥터 스크립트가 동작하는 시간 간격은 고정 값이거나, 각각의 동작에서 점차로 증가할 수 있다.

B.3. 메신저 스크립트 - 청취

도 9는 메시지들을 청취하고 이들을 모듈에 제공하기 위해 본 발명의 일 구현에 따라 메신저 스크립트에 의해 구현될 수 있는 방법을 나타낸다. 도 9에 도시된 바와 같이, 메신저 스크립트는 주기적으로 동작하는 청취 프로세스를 실행한다(902). 주어진 시간 간격 후에, 메신저 스크립트는 메신저 인라인 프레임의 로케이션 (src) 속성을 디코딩하여, 메시지 큐 내의 메시지들을 검사하고(904), 메시지를 수신하도록 등록된 핸들러에 임의의 새로운 메시지들을 전달한다(위 참조)(906). 이러한 방식으로, 모듈은 하나 또는 그 이상의 메시지를 수신하고, 이들을 처리하여, 예를 들어 브라우저 윈도우(304) 내에 렌더링되는 출력을 생성한다. 또한, 모듈간 통신을 위한 구조화된 메커니즘은 보안을 계속 유지하면서 모듈들이 상호작용하는 것을 허용하는데, 이는 모듈들이 다른 페이지 객체들과 통신하고 상호작용하기 위해 여기에 개시된 수단만을 갖기 때문이다.

본 발명은 특정 실시예들을 참조하여 설명되었다. 예를 들어, 본 발명의 실시예들은 HTTP, HTML 및 자바스크립트와 관련하여 동작하는 것으로 설명되었지만, 본 발명은 임의의 적절한 프로토콜 환경과 관련하여 이용될 수 있다. 다른 실시예들은 이 분야의 통상의 기술자들에게 명백할 것이다. 따라서, 본 발명은 첨부된 청구항들에 의해 지시되는 것 외에는 한정되는 것을 의도하지 않는다.

Claims

제1 근원(origin)에서, 사용자 에이전트로부터 웹페이지에 대한 요청을 수신하는 단계 - 상기 사용자 에이전트는 인라인 프레임들(inline frames)에 걸쳐 상이한 근원들로부터의 콘텐츠 사이의 상호작용을 불허하는 도메인 보안 모델을 구현하도록 동작함 -;
레이아웃 정보의 데이터 저장소에 액세스하여, 베이스 문서에 추가할 하나 또는 그 이상의 모듈 객체들을 식별하는 단계; 및
상기 제1 근원으로부터, 상기 베이스 문서를 상기 사용자 에이전트로 전송하는 단계 - 상기 베이스 문서는 하나 또는 그 이상의 모듈 인라인 프레임 요소들을 포함하고, 각각의 모듈 인라인 프레임 요소는 상기 사용자 에이전트가 인라인 프레임 내에 제2 근원으로부터의 모듈 문서를 로딩하도록 동작하고, 상기 모듈 문서는 메신저 객체, 및 상기 식별된 모듈 객체들 중 하나 또는 그 이상을 포함함 -
를 포함하고,
각각의 메신저 객체는, 상기 사용자 에이전트의 맥락(context)에서,
대응하는 모듈 인라인 프레임 내에서, 상기 제1 근원을 식별하는 로케이션 속성을 포함하는 메신저 인라인 프레임 요소를 생성하고,
상기 모듈 객체에 의해 보내진 메시지에 응답하여, 상기 메시지를 상기 로케이션 속성에 추가하고,
상기 메신저 인라인 프레임 요소의 로케이션 속성에서 검출된 새로운 메시지를 상기 모듈 객체에 제공하도록
동작하고,
상기 베이스 문서는, 상기 사용자 에이전트의 맥락에서,
하나 또는 그 이상의 메신저 인라인 프레임 요소들의 로케이션 속성들에 액세스하여 새로운 메시지들을 검사하고,
새로운 메시지에 응답하여, 상기 새로운 메시지를 대응하는 메신저 인라인 프레임 요소들의 하나 또는 그 이상의 로케이션 속성들에 추가하도록
동작하는 모듈 커넥터 객체를 더 포함하는
방법.
제1항에 있어서, 상기 메신저 객체는 상기 모듈 커넥터 객체에 등록하도록 또한 동작하는 방법.
제1항에 있어서, 상기 메신저 객체는 상기 모듈 객체에 대한 메시징 애플리케이션 프로그래밍 인터페이스를 정의하도록 또한 동작하는 방법.
제1항에 있어서, 상기 메신저 객체는 상기 메신저 인라인 프레임 요소의 로케이션 속성에 이전에 추가된 메시지들을 소멸(expire)하도록 또한 동작하는 방법.
제1항에 있어서, 상기 모듈 커넥터 객체는 상기 메신저 인라인 프레임 요소의 로케이션 속성에 이전에 추가된 메시지들을 소멸하도록 또한 동작하는 방법.
제1항에 있어서, 상기 모듈 커넥터 객체는 채널 상에 청취자로서 등록하도록 또한 동작하고, 상기 모듈 객체는 상기 새로운 메시지의 채널 및 상기 등록된 청취자 채널에 기초하여 상기 새로운 메시지를 대응하는 메신저 인라인 프레임 요소들의 하나 또는 그 이상의 로케이션 속성들에 선택적으로 추가하도록 동작하는 방법.
제1항에 있어서, 상기 제1 근원 및 제2 근원은 호스트 이름, 포트 및 프로토콜의 조합과 관련하여 정의되는 방법.
제1항에 있어서, 상기 요청은 사용자를 식별하고, 상기 레이아웃 정보는 상기 사용자와 연관된 사용자 계정으로부터 액세스되는 방법.
네트워크 인터페이스;
메모리;
하나 또는 그 이상의 프로세서들; 및
네트워크 애플리케이션 프로그램 로직
을 포함하고,
상기 네트워크 애플리케이션 프로그램 로직은, 실행시에, 상기 하나 또는 그 이상의 프로세서들로 하여금,
제1 근원에서, 사용자 에이전트로부터 웹페이지에 대한 요청을 수신하고 - 상기 사용자 에이전트는 인라인 프레임들에 걸쳐 상이한 근원들로부터의 콘텐츠 사이의 상호작용을 불허하는 도메인 보안 모델을 구현하도록 동작함 -;
레이아웃 정보의 데이터 저장소에 액세스하여, 베이스 문서에 추가할 하나 또는 그 이상의 모듈 객체들을 식별하고;
상기 제1 근원으로부터, 상기 베이스 문서를 상기 사용자 에이전트로 전송하게 하도록
동작 가능한 하나 또는 그 이상의 컴퓨터 판독 가능 명령어들을 포함하고,
상기 베이스 문서는 하나 또는 그 이상의 모듈 인라인 프레임 요소들을 포함하고, 각각의 모듈 인라인 프레임 요소는 상기 사용자 에이전트가 인라인 프레임 내에 제2 근원으로부터의 모듈 문서를 로딩하게 야기하도록 동작하고, 상기 모듈 문서는 메신저 객체, 및 상기 식별된 모듈 객체들 중 하나 또는 그 이상을 포함하고,
각각의 메신저 객체는, 상기 사용자 에이전트의 맥락에서,
대응하는 모듈 인라인 프레임 내에서, 상기 제1 근원을 식별하는 로케이션 속성을 포함하는 메신저 인라인 프레임 요소를 생성하고,
상기 모듈 객체에 의해 보내진 메시지에 응답하여, 상기 메시지를 상기 로케이션 속성에 추가하고,
상기 메신저 인라인 프레임 요소의 로케이션 속성에서 검출된 새로운 메시지를 상기 모듈 객체에 제공하도록
동작하고,
상기 베이스 문서는, 상기 사용자 에이전트의 맥락에서,
하나 또는 그 이상의 메신저 인라인 프레임 요소들의 로케이션 속성들에 액세스하여 새로운 메시지들을 검사하고,
새로운 메시지에 응답하여, 상기 새로운 메시지를 대응하는 메신저 인라인 프레임 요소들의 하나 또는 그 이상의 로케이션 속성들에 추가하도록
동작하는 모듈 커넥터 객체를 더 포함하는 장치.
제9항에 있어서, 상기 메신저 객체는 상기 모듈 커넥터 객체에 등록하도록 또한 동작하는 장치.
제9항에 있어서, 상기 메신저 객체는 상기 모듈 객체에 대한 메시징 애플리케이션 프로그래밍 인터페이스를 정의하도록 또한 동작하는 장치.
제9항에 있어서, 상기 메신저 객체는 상기 메신저 인라인 프레임 요소의 로케이션 속성에 이전에 추가된 메시지들을 소멸하도록 또한 동작하는 장치.
제9항에 있어서, 상기 모듈 커넥터 객체는 상기 메신저 인라인 프레임 요소의 로케이션 속성에 이전에 추가된 메시지들을 소멸하도록 또한 동작하는 장치.
제9항에 있어서, 상기 모듈 객체는 채널 상에 청취자로서 등록하도록 또한 동작하고, 상기 모듈 커넥터 객체는 상기 새로운 메시지의 채널 및 상기 등록된 청취자 채널에 기초하여 상기 새로운 메시지를 대응하는 메신저 인라인 프레임 요소들의 하나 또는 그 이상의 로케이션 속성들에 선택적으로 추가하도록 동작하는 장치.
제9항에 있어서, 상기 제1 근원 및 제2 근원은 호스트 이름, 포트 및 프로토콜의 조합과 관련하여 정의되는 장치.
제9항에 있어서, 상기 요청은 사용자를 식별하고, 상기 레이아웃 정보는 상기 사용자와 연관된 사용자 계정으로부터 액세스되는 장치.
인라인 프레임들에 걸쳐 상이한 근원들로부터의 콘텐츠 사이의 상호작용을 불허하는 도메인 보안 모델을 구현하는 단계;
제1 근원으로부터 베이스 문서를 수신하고, 렌더링하는 단계 - 상기 베이스 문서는 하나 또는 그 이상의 모듈 인라인 프레임 요소들을 포함함 -;
각각의 모듈 인라인 프레임 요소에 대해, 각각의 제2 근원으로부터, 인라인 프레임 내에 모듈 문서를 로딩하는 단계 - 상기 모듈 문서는 메신저 객체, 및 식별된 모듈 객체들 중 하나 또는 그 이상을 포함함 -
를 포함하고,
각각의 메신저 객체는,
대응하는 모듈 인라인 프레임 내에서, 상기 제1 근원을 식별하는 로케이션 속성을 포함하는 메신저 인라인 프레임 요소를 생성하고,
상기 모듈 객체에 의해 보내진 메시지에 응답하여, 상기 메시지를 상기 로케이션 속성에 추가하고,
상기 메신저 인라인 프레임 요소의 로케이션 속성에서 검출된 새로운 메시지를 상기 모듈 객체에 제공하도록
동작하고,
상기 베이스 문서는,
하나 또는 그 이상의 메신저 인라인 프레임 요소들의 로케이션 속성들에 액세스하여 새로운 메시지들을 검사하고,
새로운 메시지에 응답하여, 상기 새로운 메시지를 대응하는 메신저 인라인 프레임 요소들의 하나 또는 그 이상의 로케이션 속성들에 추가하도록
동작하는 모듈 커넥터 객체를 더 포함하는 방법.
제17항에 있어서, 상기 제1 근원 및 각각의 제2 근원은 호스트 이름, 포트 및 프로토콜의 조합과 관련하여 정의되는 방법.
제17항에 있어서, 상기 모듈 객체들에 액세스 가능한 메시징 애플리케이션 프로그래밍 인터페이스를 정의하는 단계를 더 포함하는 방법.
제17항에 있어서, 메신저 객체를 상기 모듈 커넥터 객체에 등록하는 단계를 더 포함하는 방법.