KR101953942B1

KR101953942B1 - 전용 캐시 관리 시스템 및 방법

Info

Publication number: KR101953942B1
Application number: KR1020147015715A
Authority: KR
Inventors: 윌리엄 더블유 차우; 사이람 수레쉬; 존 현; 마크 추이에
Original assignee: 모보파일스 인코포레이티드 디비에이 모보라이즈
Priority date: 2011-11-11
Filing date: 2012-11-12
Publication date: 2019-03-04
Also published as: US9940403B2; US20130124667A1; KR20140094602A; EP2776936A1; CA2890411A1; CA2890411C; CN103946833B; IN2014CN04305A; WO2013071277A1; JP6081472B2; AU2016202039A1; AU2012334941A1; JP2014534537A; EP2776936A4; CN103946833A

Abstract

네트워크를 통해서 원격 서버와 통신하도록 또는 서버에 의해서 제공되는 콘텐트 또는 서비스에 액세스하도록 설정된 클라이언트 기반의 컴퓨터 시스템이 제공된다. 시스템은 프로세서, 스토리지 디바이스, 설정에 의해서 규정되는 일련의 리소스에 대해서 전용화된 클라이언트측 캐시, 및 상기 설정에 의해서 지시되는 바와 같이 캐시를 자동으로 관리하는 캐시 관리자를 포함하고 있다. 클라이언트측 캐시는 클라이언트 애플리케이션으로부터 서버로의 리소스 중의 하나에 대한 요청을 투명하게 인터셉트하고, 또한 클라이언트 애플리케이션이 요청을 서버로 전송하고 또한 서버로부터 응답을 수신한 것처럼 네트워크를 통해서 언제 요청을 서버로 전송하고 또한 서버로부터의 응답이 언제 클라이언트 애플리케이션에 나타나도록 제공하는 것을 자동으로 결정하는 설정에 의해서 지시되고 있다.

Description

전용 캐시 관리 시스템 및 방법{SYSTEM AND METHOD FOR MANAGING DEDICATED CACHES}

본 발명의 실시예의 특징은 웹 캐싱과 같은 캐시 관리와 관련된다.

현재의 클라이언트 서버 시스템, 예를 들면 웹 애플리케이션의 경우, 예를 들면 최종 사용자 컴퓨터에 또는 네트워크 중의 어딘가와 같은 다양한 지점에서 레버리지 캐싱을 실행하여 성능을 최적화하고 있다. 이들 웹 캐싱 솔루션은 일반적으로 공유 캐시를 제공하고 있으며, 여기에서 복수의 사용자 및/또는 사이트로부터의 콘텐트는 디스크 및/또는 메모리의 동일한 공간을 공유하면서 후속하는 액세스에서의 더욱 빠른 검색을 위해서 콘텐트를 저장하고 있다. 공유 캐시는 서로 다른 사이트에 걸쳐서 및/또는 서로 다른 사용자에 의해서 액세스되는 콘텐츠 간의 동일하지만 제한된 캐시 공간 때문에 경쟁을 유발하게 된다.

이들 웹 캐싱 솔루션은 또한 애플리케이션에 기초하여 캐싱 거동을 중앙식으로 맞춤 설정하는 방식을 제공하지 않았다. 예를 들면, 대형 회사는, 서로 다른 부서 또는 사업부를 위해서 별도의 것으로서 특정 웹 애플리케이션이 실행되는 복수의 서버를 가지고 있을 수 있다. 이들 해결책은 특정 도메인 및/또는 URL을 목표로 하고 있으며, 따라서 이들은 애플리케이션 타입에 기초한 캐싱 정책을 적용할 수 없었다.

본 발명의 각 실시예의 특징은 중앙식으로 관리되는 캐시 컨트롤을 제공함으로써 이들 및 기타 우려를 해소한다. 더욱 상세하게는, 본 발명의 실시예의 특징은 사용자당(또는 사용자 계정당) 무엇을 캐시할지 또는 퍼지(purge)할 지의 (예를 들면, 유니폼 리소스 로케이터(URL, uniform resource locator) 패턴을 통한) 초정밀 컨트롤을 제공한다. 다른 특징은 보안 소켓층(SSL), 도메인 네임 시스템(DNS), 또는 네트워킹 방법의 변동 없이 연속적으로(seamless) 가능 또는 불가능을 허용한다. 또 다른 특징은 도메인 또는 URL 패턴당 공간을 할당하는 방법을 제공한다. 추가적인 특징은 애플리케이션 특유 컨트롤을 위해서, 판독 조작 및 기록 조작의 캐시 동작 조정, 및 URL 템플릿을 통한 자동 설정(예를 들면, 오토 모볼라이징(auto-mobolizing))을 제공한다.

또한, 본 발명의 실시예의 특징은 종점 특유 웹 기능의 중앙식 컨트롤을 위해 제공된다. 더욱 상세하게는, 이들 특징은 동기화(sync) 동작을 조정하는 단계와, 오프라인 액세스의 가능 및 불가능을 위한 형태 기반 인증에 대한 지원을 추가하는 단계와, 유일 식별자(UI, unique identifier) 요소를 설정하는 단계, 및 실제 최종 사용자 경험을 측정하거나 보고하는 단계를 제공한다.

따라서, 본 발명의 실시예는 각각 (예컨대, 특정 서버/사이트, 서브패스/폴더, 또는 파일/객체에 대한) 특정 URL 패턴와 관련된 콘텐트의 캐시에 대해서 할당될 수 있는 전용 캐시 관리 방법을 제공한다. 이들 전용 캐시는 캐시가 최종 사용자의 컴퓨터 또는 하나 이상의 서버 시스템과 통신하는 클라이언트 시스템 사이의 중간 캐시 서버에 존재하는 것과 같이 관리 시스템으로부터 원격에 위치(또한 이런 점에서 관리 시스템에 대해서 원격 전용 캐시라고 지칭됨)할 수 있다.

본 발명과 관련된 특허 출원인 미합중국 특허 출원 12/630,806(이하, "U.S. 12/630,806"이라 함)은, URL의 범위 내에 있는 클라이언트의 요청에 대해서 서버 응답을 캐시하기 위한 목적으로, 하나 이상의 URL이 어떻게 서버 계정 또는 애플리케이션과 관련되어 있는 지에 대해서 기술하고 있다. U.S. 12/630,806은 서버 계정의 캐시에 대한 맞춤화된 스토리지 제한을 규정하는 것 및/또는 서버 계정의 캐시에 무엇이 저장되어야 하는지를 맞춤화하는 것과 같은, 관리능(manageability)을 현저하게 개선시키는 다양한 특징의 서버 계정 캐시에 대해서 기술하고 있다. 각각의 서버 계정에 대한 맞춤화된 스토리지 제한을 지원하는 것에 의해서, U.S. 12/630,806은 서버 계정에 대한 개별 캐시 공간을 전용화하고, 따라서 이 캐시 공간이 서버 계정과 관련된 URL 패턴의 캐시를 구체적으로 전용화하는 것과 같은 특징을 제공하며, 여기에서 패턴은 사이트, 서브패스/폴더, 또는 특정한 파일/객체일 수 있다.

서버 계정당 전용 캐시의 결과적인 장점은 전용 캐시는 다른 사이트/폴더/파일을 위한 콘텐트와 캐시 공간을 공유하지 않고, 따라서 브라우저 또는 프록시 서버에 의해서 제공되는 공유 캐시에서와 같이 공통 캐시 공간을 공유함에 따라서 발생되는 통상적인 캐시 경쟁에 노출되지 않는다는 것이다. 이들 공유 캐시에 대한 캐시 경쟁은 보통은 전용 캐시보다 높다. 따라서, 각각 하나 이상의 URL 패턴과 관련된 하나 이상의 전용 캐시를 생성하는 것에 의해서, 이들 전용 캐시는 공유 캐시에 비해서 더 긴 캐시 수명 및 더 높은 캐시 히트율을 보장하는데 도움을 줄 수 있다. 이는, 다시, 더 빠른 웹 성능, 더 적은 대역폭의 사용, 더 적은 요청/왕복 시간의 수행, 및 더 낮은 서버측 인프라스트럭처 상의 전체 부하와 같은 이득을 제공할 수 있다.

본 발명은 전용 캐시에 대한 초정밀 관리 및 컨트롤을 제공함으로써 U.S. 12/630,806의 전용 캐시를 개선하였다. 무엇을 캐시할 것인지 또한 어떻게 캐시할 것인지의 초정밀 컨트롤을 제공하게 되면 예를 들면 복수의 관련된 요청/URL을 동일한 캐시 콘텐트로 매치시키거나 또는 서버에 의해서 규정된 것을 넘어서 콘텐트의 캐시 가능한 수명을 연장시키는 것과 같이 성능은 향상시키고 또한 인프라스트럭처의 부하는 감소시킬 수 있다.

이들 전용 캐시의 중앙식 관리는 이들 복수의 전용 캐시를 원격으로 컨트롤할 수 있도록 관리자에 의해서 취해질 수 있는 광범위한 동작을 제공할 수 있다. 예를 들면, 이들 동작은 이들 전용 캐시를 동적으로 생성/삭제하고, 각각 할당되는 공간을 조정하고, 또한 각각에 대해서 적용되는 캐시 정책을 설정/변경하는 것을 포함할 수 있다.

본 발명의 예시적인 실시예에 있어서, 네트워크를 통해서 원격 서버와 통신하고 또한 서버에 의해서 제공되는 콘텐트 또는 서비스에 대한 액세스를 제공하도록 설정된 클라이언트 기반 컴퓨터 시스템이 제공된다. 시스템은 프로세서, 스토리지 디바이스, 설정에 의해서 규정되는 일련의 리소스에 대해서 전용화된 클라이언트측 캐시, 및 상기 설정에 의해서 지시되는 바와 같이 캐시를 자동으로 관리하는 캐시 관리자를 포함하고 있다. 클라이언트측 캐시는 다음 설정에 의해서 수행된다: 클라이언트 애플리케이션으로부터 서버로의 리소스 중의 하나에 대한 요청을 투명하게 인터셉트하고; 또한 클라이언트 애플리케이션이 요청을 서버로 전송하고 또한 서버로부터 응답을 수신한 것처럼 네트워크를 통해서 언제 요청을 서버로 전송하고 또한 서버로부터의 응답이 언제 클라이언트 애플리케이션에 나타나도록 제공하는 것을 자동으로 결정한다. 클라이언트측 캐시는 클라이언트 애플리케이션이 요청을 전송한 것처럼 요청이 서버에 나타나도록 하기 위해서 요청을 서버로 전송하는 단계와, 서버로부터의 응답을 제공하는 단계, 및 스토리지 디바이스 상에 응답을 저장하는 단계에 의해서, 또는 캐시로부터의 응답을 제공하는 것에 의해서 이를 수행한다.

본 발명의 다른 예시적인 실시예에 있어서, 네트워크를 통해서 원격 서버와 통신하고 또한 서버에 의해서 제공되는 콘텐트 또는 서비스에 대한 액세스를 제공하기 위해서 컴퓨터를 설정하는 방법이 제공된다. 이 방법은 다음을 포함한다: 각각 하나 이상의 URL과 관련된 하나 이상의 전용 캐시를 생성하는 단계; 각각의 캐시에 대해서, 하나 이상의 규칙(rule)에 따라서 상기 캐시를 관리하는 단계; 클라이언트 애플리케이션으로부터 상기 서버로의 상기 URL 중의 하나에 대한 요청을 투명하게 인터셉트하는 단계; 및 클라이언트 애플리케이션이 요청을 서버로 전송하고 또한 서버로부터 응답을 수신한 것처럼 네트워크를 통해서 언제 요청을 서버로 전송하고 또한 서버로부터의 응답을 언제 클라이언트 애플리케이션에 나타나도록 제공할 지를 자동으로 결정하는 단계를 포함한다. 응답을 제공하는 단계는, 클라이언트 애플리케이션이 요청을 전송한 것처럼 요청이 서버에 나타나도록 하기 위해서 요청을 서버로 전송하는 단계와, 서버로부터의 응답을 제공하는 단계, 및 스토리지 디바이스 상에 응답을 저장하는 단계, 또는 이들 각 캐시 중의 하나로부터의 반응을 제공하는 단계를 포함한다.

첨부 도면은 본 발명의 각 실시예를 도시하고 있으며, 발명의 상세한 설명과 더불어, 본 발명의 원리 및 특징을 설명하는데 기여한다.
도 1은 본 발명의 예시적인 실시예에 따른, 캐시가 원격 서버 상의 애플리케이션/데이터에 액세스하는 클라이언트 컴퓨터 상에 상주하는 중앙식으로 관리되는 전용 캐시의 시스템 아키텍처를 나타내는 다이아그램이다.
도 2는 본 발명의 예시적인 실시예에 따른 클라이언트 프로세스의 실례를 나타내는 다이아그램이다.
도 3은 일 실시예에 따른 관리 서버를 갖는 클라이언트 컴퓨터에 등록하기 위한 등록 프로세스의 일례를 나타내는 UML(Unified Modeling Language) 시퀀스 다이아그램이다.
도 4는 일 실시예에 따른 예시적인 관리 태스크 루프를 나타내는 UML 시퀀스 다이아그램이다.
도 5는 일 실시예에 따른 관리 서버로부터 태스크가 수신됨에 따라 관리자에 의해서 태스크를 예시적으로 처리하는 것을 나타내는 UML 시퀀스 다이아그램이다.
도 6은 일 실시예에 따른 애플리케이션 설정 데이터를 처리하기 위한 예시적인 UML 프레임 업데이트 애플리케이션 설정을 나타내는 UML 시퀀스 다이아그램이다.
도 7은 일 실시예에 따른 사이트 설정 데이터를 처리하기 위한 예시적인 UML 프레임 사이트 설정 업데이트를 나타내는 UML 시퀀스 다이아그램이다.
도 8은 일 실시예에 따른 설정 템플릿 설정값을 처리하기 위한 예시적인 UML 프레임 설정 템플릿 적용을 나타내는 UML 시퀀스 다이아그램이다.
도 9는 일 실시예에 따른 캐시 퍼지 태스크를 처리하기 위한 예시적인 UML 프레임 캐시 퍼지를 나타내는 UML 시퀀스 다이아그램이다.
도 10은 일 실시예에 따른 캐시로부터의 특정 항목을 삭제하기 위한 예시적인 UML 프레임 캐시 항목 삭제를 나타내는 UML 시퀀스 다이아그램이다.
도 11은 본 발명의 일 실시예에 따른 전용 캐시 관리의 예시적인 방법을 도시하고 있다.

이하의 설명적인 실시예는 단지 본 발명의 예시적인 응용이며 또한 발명의 범주를 제한하고자 의도되지 않았다. 우선권 주장 문서 내의 부록에 본 출원의 예시적인 실시예의 더욱 구현 지향적인 상세가 포함되어 제공된다.

1 전용 캐시 관리

본 발명의 실시예는 전용 캐시를 제공하며, 여기에서 각각의 캐시는 하나 이상의 유니폼 리소스 로케이터(URL, uniform resource locator) 패턴에 대한 콘텐트를 저장하기 위해서 전용화되어 있다. 이들 전용 캐시는 각각 서버 계정과 관련되어 있으며, 여기에서 서버 계정은, 관련된 미합중국 특허 출원 U.S. 12/630,806에 설명된 바와 같이, 서버 응답을 캐시하기 위한 목적으로 하나 이상의 URL과 관련되어 있다. 본 발명의 실시예는, 어떤 콘텐트가 캐시될 것인지 및 어떻게 캐시될 것인지를 규정하는 것과 같은 각각의 전용 캐시의 맞춤화를 가능하게 하는 것에 의해 종래 기술에 비해 현저한 개선을 제공한다.

본 발명의 실시예는 최종 사용자, 시스템 관리자, 또는 웹 사이트 개발자에 의해서와 같이 동적으로 맞춤화될 수 있는 설정값을 통해서 초정밀 캐시 컨트롤을 제공한다. 이들 설정값은 파일 내 또는 데이터베이스 내와 같은, 본 기술 분야에서 통상의 지식을 가진 자이게는 공지된 복수의 서로 다른 방법으로 저장될 수 있다. 본 발명의 예시적인 실시예는 YAML 규격(http://www.yaml.org/)에 따르는 텍스트 파일 내의 이들 설정값을 지원하며, 이 규격은 사용자가 임의의 표준 텍스트 에디터를 사용하여 직접 편집할 수 있는 간단한 확장 가능한 구조를 가능하게 하고 있다.

1.1 애플리케이션 기반 설정

본 발명의 실시예는 각각의 캐시에 대해서 서로 다른 캐시 규칙/정책/거동을 할당할 수 있고, 따라서 각각의 캐시는 맞춤화되어 각각의 웹 사이트/애플리케이션에 대해서 서로 다른 능력을 지원할 수 있는데, 이는 각각의 웹 사이트/애플리케이션이 어떻게 캐시되는 가에 따라서 영향을 받는 매우 다른 거동을 가질 수 있기 때문이다. 각각의 웹 애플리케이션에 대해서 맞춤화한 설정을 한정하기 위한 유연한 방법을 지원하는 것에 의해서, 본 발명의 실시예는 임의의 현재 및 미래의 웹 애플리케이션을 지원하도록 구성될 수 있다.

본 발명의 실시예는 또한 URL 템플릿에 기초하여 캐시를 자동으로 생성할 수도 있다. 예를 들면, server1.acme.com 또는 server99.acme.com과 같은 모든 가능한 서버명을 미리 알지 않고도 acme.com과 같은 인터넷 도메인 내의 임의의 서버에 대한 캐시를 자동으로 생성하는 것이 바람직할 수 있다. URL 템플릿은 시스템으로 하여금 원격 서버로부터 액세스되는 콘텐트에 대해서 URL과 매치되도록 사용되어지는 스트링 기반의 패턴에 기초하여 자동으로 캐시를 생성하도록 허용한다. 예를 들면, "http://*.acme.com"과 같이 규정되는 URL 템플릿은 클라이언트 시스템으로 하여금 각각에 대해서 명시적으로 규정할 필요없이 acme.com 도메인 내의 임의의 서버로부터의 콘텐트에 대해서 개별적인 캐시를 자동으로 생성하도록 허용할 수 있다.

본 발명의 실시예는, 각각의 설정에 대해서 URL을 할당하는 것에 의해서 및 이 설정을 매치되는 URL을 갖는 임의의 서버 계정의 캐시에 적용하는 것과 같은 복수의 서로 다른 방식의 캐시에 대해서 하나 이상의 설정을 적용할 수 있다. 또한 HTTP 응답의 "Server" 헤더 내의 정보 또는 아마도 서버로부터 반환되는 맞춤화 헤더와 같은 서버로부터 획득될 수 있는 일부 다른 식별 정보에도 설정을 할당할 수 있다.

본 발명의 예시적인 실시예는 각각의 설정에 할당될 수 있는 이하의 속성을 지원하는 것에 의해서 설정을 캐시에 매치시키고 있다.

URL 기반의 설정과 관련되는 속성의 예에 대해서 다음에 나타낸다.

id:

mode: domain

url: 'http[s]://maps\.google\.com/.*'

마찬가지로, 맞춤화된 하이퍼텍스트 트랜스퍼 프로토콜(HTTP, hypertext transfer protocol)에 기초한 설정과 관련된 속성에 대해서 다음에 나타낸다.

id:

mode: header

name: MicrosoftSharePointTeamServices

value: '12\.0\.0\.[0-9]+'

1.2 요청 및 응답의 매치

예시적인 일 실시예에 따르면, 애플리케이션 설정값은 두 개의 가능한 속성값을 포함하고 있다.

● 매치 속성: 어떤 요청/응답이 어떤 애플리케이션 설정값이 적용되는지를 규정.

● 동작 속성: 애플리케이션 설정값에 대해서 동작/거동을 규정.

매치 속성은 요청의 URL 또는 응답의 바디(body)와 같은 클라이언트/서버의 요청 또는 응답의 하나 이상의 컴포넌트와 매치될 수 있다. 본 발명의 예시적인 실시예는 이하의 매치 속성을 제공한다.

일단 설정값이, 매치 속성에 기초하여, 요청 또는 응답과 매치된다는 것이 확인되면, 이후에 이에 대응하여 요청/응답에 동작 속성이 적용될 수 있다.

1.3 설정 동작

예시적인 실시예에 따르면, 애플리케이션 설정값과 관련될 수 있는 복수의 서로 다른 동작 속성이 있으며, 여기에서 하나 이상의 동작의 임의의 조합은 캐시의 디폴트 거동을 변화시키도록 규정될 수 있다. 이는 서로 다른 타입의 웹 사이트/애플리케이션을 지원하기 위해서 또는 디폴트 값을 뛰어 넘어서 다른 웹 애플리케이션의 캐시능(cacheability)을 오버라이드/최적화하기 위해서와 같은 각각의 서버 계정에 대한 전용 캐시의 거동 및 동작을 맞춤화할 수 있는 능력을 제공한다.

1.3.1 요청의 리맵핑

각각 서로 다른 URL을 사용하는 서로 다른 요청이 실제로는 동일한 반응 데이터에 대응하는 경우가 있을 수 있다. 예를 들면, 웹 개발자는 보편적으로 URL을 레버리지하여, 이전 페이지의 URL 또는 아마도 세션 식별자와 같은 임시 데이터를 전송하였다. 이들 경우에 있어서, 이들 겉보기에는 서로 다른 요청이 실제로는 서버로부터의 동일한 반응에 의한 결과인 경우, 이들을 동일한 요청인 것처럼 처리하고 따라서 이들이 상기 반응의 동일한 캐시 버전으로부터 모두 서비스될 수 있는 것이 유리하였다.

동일한 기본 응답에 대한 동일한 요청의 서로 다른 변형을 리맵핑하는 것을 지원하기 위해서, 본 발명의 예시적인 실시예는 URL 질의 스트링 인자에서와 같이 규정된 임시 데이터를 제거하는 것과 같이, 동일한 기본 요청의 유사한 인스턴스 사이에서 서로 다른 요청의 일부를 필터하고, 따라서 이들 서로 다른 요청의 변형이 궁극적으로는 동일하게 보이도록 한다. 이하의 표는 HTTP 요청의 일부를 필터링하기 위한 설정값의 예시적인 동작 속성을 나열하고 있다.

이들 동작 속성을 사용하여, 이전 페이지를 규정하는 요청 URL로부터의 질의 스트링 인자를 필터링하기 위한 설정값의 예를 다음에 나타낸다.

cache:

gets:

- subPath:'.*\?retURL=.+'

filterUrlPatterns:

- '[\?&]retURL=[^&]+'

유사한 방식으로, 요청의 임시 컴포넌트를 필터링하는 것에 의해서, 동일한 캐시에 대한 동일한 웹 페이지(SharePoint site)에 대한 요청의 리매핑 변형에 대한 설정값의 다른, 조금 더 복잡한, 설정값의 예를 다음에 나타낸다.

cache:

posts:

- subPath:'.*/AllItems\.aspx.*'

notBodyPatterns:

- '.*&ctl.*%24btnWikiSave=Apply&.*'

filterUrlPatterns:

- '(?i)[\?&]source=[^&]*'

- '(?i)[\?&]contenttypeid=[^&]*'

- '(?i)[\?&]initialtabid=[^&]*'

- '(?i)[\?&]visibilitycontext=[^&]*'

- '(?i)[\?&]isdlg=[^&]*'

- '(?i)[\?&]viewcount=[^&]*'

1.3.2 캐시 수명 컨트롤

캐시된 응답의 수명을 컨트롤하거나 변경하는 것이 바람직할 수 있는 경우가 있는데, 예를 들면 서버가 캐시를 가능하게 하도록 적절하게 설정되어 있지 않거나 사용자가 서버에 의해서 규정된 캐시 수명을 오버라이드하는 것을 선호하는 경우가 있다. 예를 들면, 서버 상에는 종종 (예컨대, 이미지, 자바스크립트, 캐스케이딩 스타일 시트, PDF, 등과 같이) 캐시 가능하지만 이 중의 일부가 클라이언트에서 최적적으로 캐시되도록 적절하게 설정되지 않은 정적(static) 콘텐트가 존재한다.

본 발명의 예시적인 실시예에 따른 전용 캐시 관리 시스템 내에 저장된 항목의 수명을 컨트롤하기 위해서, 시스템은 서버 응답에 대해서 유효 주기를 적용하며, 이는, 있다면, 서버에 의해서 제공되는 유효 주기에 대해서 우선권을 취하게 된다. 이하의 표는 서버 응답을 어떻게 캐시하는지를 컨트롤하는 설정값의 예시적인 동작 속성을 나열하고 있다.

이들 동작 속성을 사용하여, "_layouts" 폴더로부터의 요청에 대한 1 년(31,536,000 초)의 캐시 유효 기간을 규정하는 설정값의 예를 다음에 나타낸다.

cache:

gets:

- subPath: '.*/_layouts/.*'

maxAge: 31536000

2 중앙식 관리

본 발명의 실시예는 이들 캐시의 조작 및 거동을 중앙식으로 설정하기 위해서 관리자에게 관리 콘솔을 제공하는 관리 서버를 제공하는 것에 의해서 원격 전용 캐시에 대한 중앙식 관리 능력을 제공한다. 예시적인 실시예에 있어서, 관리 콘솔은 캐시되는 애플리케이션/사이트의 정상적인 클라이언트-서버 상호 작용으로부터 이탈하여 동작한다.

도 1은 중앙식으로 관리되는 (캐시(103)와 같은) 전용 캐시의 예시적인 실시예를 나타내는 다이아그램이며, 여기에서 캐시는 (서버(108)와 같은) 원격 서버 상의 애플리케이션/데이터에 액세스 중인 (클라이언트(100)와 같은) 클라이언트 컴퓨터 상에 상주하고 있다.

도 1을 참조하면, 클라이언트(100)는 컴퓨터이며, (인터넷과 같은) 네트워크(107)를 통한 서버(108)와의 통신을 지원하고 있다. 클라이언트(100)는 클라이언트 애플리케이션(클라이언트 앱, Client App)(101)의 동작을 지원하고 있으며, 이는, 예를 들어서, 원격 서버와의 통신을 가능하게 하는 웹 브라우저와 같은 임의의 인터넷 기반의 클라이언트 애플리케이션일 수 있다. 클라이언트(100)는 컴퓨터 명령의 형태의 소프트웨어를 실행하기 위한 중앙 처리 장치(CPU), CPU가 액세스 하거나 또는 생성하는 소프트웨어 및 관련 데이터를 저장하기 위한 (디스크 드라이브와 같은) 비휘발성 스토리지, 및 네트워크(107)에 액세스하기 위한 (인터넷 서비스(104)와 같은) 네트워크 인터페이스를 포함할 수 있다.

더욱 상세하게는, 클라이언트 앱(101) 및 인터넷 서비스(104) 사이에 애플리케이션 프로그래밍 인터페이스(API, application programming interface) 인터셉트(102)가 주입되어, API 인터셉트(102)가 클라이언트 앱(101)으로부터의 요청을 (인터넷 서비스(104)를 통해서) 서버(108), 캐시(103), 또는 이들 둘의 임의의 조합으로 안내할 수 있도록 하고 있다. 캐시(103)로 안내된 요청은 (예를 들면, 디스크 드라이브와 같은 비휘발성 스토리지 디바이스와 같은) 스토리지(106) 상에 로컬 저장된 응답을 사용하여 조작될 수 있다. 스토리지(106)에 대한 액세스는 파일 시스템, 데이터베이스, 또는 이들의 조합과 같은 통상적인 스토리지 액세스층인 스토리지 서비스(105)를 통해서 조작될 수 있다.

또한, 관리자(150)는 캐시(103)의 기능 및 조작을 관리하며, 또한 (예를 들면, 캐시(103)와 같은 로컬 전용 캐시를 관리하기 위한 원격 서버와 같은) 관리 서버(107)와 상호 작용하여 설정 변경 및 동작을 동적으로 수신하고 또한 처리한다. 이 경우, "로컬 전용 캐시"(local dedicated cache)는 클라이언트 컴퓨터 시스템에 대해서 로컬인 스토리지 디바이스 상에 저장되는 전용 캐시를 가리킨다.

도 2는 예시적인 시스템 내의 클라이언트 프로세서의 실시예를 나타내는 소프트웨어 아키텍처 다이아그램이다. 본 도면은 본 실시예와 가장 관련성이 있는 소프트웨어 컴포넌트를 나타내고 있으며, 또한 본 기술 분야에서 통상의 지식을 가진 자라면 도시하지 않은 다른 소프트웨어 컴포넌트가 있음을 이해할 것이다. 각각 110, 130, 140, 및 150으로 도면 부호가 매겨진 네 개의 논리적으로 구별되는 프로세스가 도시되어 있다. 프로세스(110 및 130)에 대해서, 도 1로부터의 (예컨대, 클라이언트 앱(101), API 인터셉트(102), 캐시(103), 및 인터넷 서비스(104)와 같은) 소프트웨어층이 도시되어 있으며, 이들이 어떻게 본 다이아그램 내에서 특정 인스턴스에 대해서 매핑하고 있는지를 나타내고 있다.

프로세스(110)는 정상적으로는 인터넷 서비스(104)의 일 타입인 Microsoft의 WinInet 다이나믹 링크 라이브러리(DLL, dynamic-link library)에 링크되는 클라이언트 앱(101)의 일 타입인 마이크로소프트 워드(Microsoft Word) 또는 마이크로소프트 인터넷 익스플로러(Microsoft Internet Explorer)와 같은 WinInet 클라이언트(111)를 실행하고 있다. WinInet 인터셉트(160)는 WinInet 클라이언트(111)로부터의 요청을 인터셉트하는 예시적인 API 인터셉트(102)이며, 이는 WinInet 인터셉트가 WinInet(161)에 대해서 의도하고 있는 요청을 대신에 캐시(103)로 방향을 전환하도록 허용하고 있다. WinInet 클라이언트(111)는 Microsoft Word용의 COM Office 애드인 또는 Microsoft Internet Explorer용의 BHO(browser helper object)로서 구현될 수 있는 애플리케이션 플러그인(113)을 로드한다. 애플리케이션 플러그인은, 콘텐트 또는 상태의 캐시를 회득하거나 또는 설정하는 것과 같은, 클라이언트 사용자 인터페이스로부터 캐시(130)로의 액세스를 제공할 수 있다. 애플리케이션 플러그인은 또한 WinInet 인터셉트(160)를 주입하여 WinInet 클라이언트(111) 및 WinInet(161) 사이의 함수 호출의 인터셉트를 가능하게 할 수 있다. 이는 캐시(103)가 WinInet 클라이언트(111)로부터 발행된 인터넷 요청을 수신하고 또한 조작할 수 있도록 허용한다.

실시예는 인터넷 서비스로서 Mozilla Netlib을 사용하는 Mozilla Firefox와 같은 인터넷 서비스(104)에 액세스하는 임의의 클라이언트 앱(101)에 적용된다. 인터넷 서비스(104)의 API를 통해 인터넷에 액세스하는 임의의 애플리케이션은 API 인터셉트(102)에 의해서 인터셉트되고, 이는 이후에 그 인터넷 요청을 캐시(103)로 방향을 전환하도록 할 수 있다. 서로 다른 인터넷 서비스(104)에 액세스하는 클라이언트 앱(101)은 인터셉트를 가능하게 하기 위해서 서로 다른 API 인터셉트(102)를 사용할 수 있다.

캐시(103)는, 예를 들어, 프로세스(110 및 130) 내에서와 같이 공통의 교차 애플리케이션일 수 있다. 캐시(103)는 캐시 엔진(162)을 포함할 수 있으며, 이 엔진은 또한 애플리케이션 고유의 기능을 제공하는 하나 이상의 소프트웨어 컴포넌트를 포함할 수 있다. 캐시(103)는 또한 영개 이상의 앱 익스텐터(162)(App Extender)를 포함할 수 있으며, 이는 애플리케이션 특유의 기능을 구비한 캐시 엔진(162)을 논리적으로 연장하고 있다. 일부 실시예에 있어서, 캐시 엔진(162)은 서로 다른 계산 플랫폼에 걸친 이식성을 향상시킨 자바 가상 머신(164)(JVM, Java Virtual Machine) 내에서 동작하는 Java 소프트웨어일 수 있다. 캐시 엔진(162)이 인터넷 요청을 수신하게 되면, 캐시 엔진(162)은 별도의 프로세스(140)를 통해서 액세스될 있는 데이터베이스(141)를 통하는 것과 같이 스토리지로부터 응답 데이터를 질의할 수 있다. 캐시 엔진(162)은 또한 앱 익스텐더(163)를 호출하여 이 요청을 보조할 수 있다. 유효한 응답이 발견되면, 캐시 엔진(162)은 이 응답을 상위층의, 예를 들면 프로세스(110) 내의 WinInet 클라이언트(111)와 같은 클라이언트 앱(101)으로 반환한다. 다르게는, 캐시 엔진(162)은 이 요청이 서버로 발행되도록 할 수 있으며, 이는 크롤러 프로세스(130)를 통하는 것과 같이 다른 맥락을 통해서 수행될 수도 있다.

캐시(103)가 도 2의 실시예의 클라이언트 컴퓨터 상에서 실행되고 있지만, 캐시(103)는 또한 서버에 비해서 클라이언트 컴퓨터에 대해서 양호한 가용성 또는 더 많은 대역폭을 갖는 것과 같은 하나 이상의 별도의 계산 시스템 상에도 실행될 수 있다. 예를 들면, 캐시(103)는 동일하거나 근접한 근거리 통신망(local area network)(예컨대, 이더넷, 와이파이, 블루투스와 같은) 상에서 다른 플랫폼(예컨대, 서버, 폰, 등) 상에서 실행될 수 있으며, 따라서 캐시(103)가 개선된 가용성 및/또는 성능 특성을 웹 애플리케이션에 제공할 수 있도록 한다.

일부 실시예에 따른 본 발명의 특징은 제 3 자 소프트웨어의 지원을 통한 애플리케이션 특유 맞춤화를 지원한다는 것이다. 외부 소프트웨어가 요청의 조작을 도울 수 있는 직접적인 및 간접적인 다수의 방법이 있다. 예를 들면, 애플리케이션 특유의 소프트웨어에 대한 직접적인 호출은 캐시 엔진(162)에 링크된 외부 함수를 통해서 지원될 수 있다. 다른 예로서, 애플리케이션 특유의 소프트웨어에 대한 간접적인 호출은 캐시 엔진(162)에 의해서 개방되는 메시지 큐 또는 파이프와 같은 인터-프로세스 통신을 통해서 지원될 수 있다. 외부 소프트웨어에 대한 호출은 요청 파라미터에 기초하여 한정되는 것과 같이 조건적일 수 있다. 예를 들면, 외부 소프트웨어에 대한 호출은 특정한 호출이 수행되기 전에 패턴이 요청 헤드와 매치되도록 규정하는 설정 파라미터와 같은 캐시 엔진(162) 상의 설정 파라미터에 의해서 설정될 수 있다.

프로세스(130)는 크롤러(131)를 실행하고 있으며, 이 크롤러는 종종 백그라운드에서 (즉, 사용자에게는 보이지 않으면서) 서버와의 통신을 지원하고 있다. 크롤러는 JVM(164)과 마찬가지로 동일한 JVM 인스턴스일 수 있는 JVM(132) 내부에서 동작하는 Java 소프트웨어 컴포넌트일 수 있다. 크롤러(131)는 WinInet 클라이언트(111)와 동일하거나 유사한 WinInet 브라우저(134)와 같은 인터넷 기반의 클라이언트 앱(101)을 프로그램적으로 컨트롤하는 것에 의해서 서버 리소스를 요청한다. WinInet 브라우저(134)는 Java에서의 Web Application Testing (Watij) 또는 TeamDev JExplorer와 같은 브라우저 컨트롤층(133)을 통해서 프로그램적으로 컨트롤될 수 있다. 또한 프로세스(110)와 유사하게, 프로세스(130)는 (예컨대, 크롤러(131)가 Java 네이티브 인터페이스(JNI, Java native interface)를 통해서 LoadLibrary를 호출하는 것과 같이) WinInet 인터셉트(160)를 주입하여 WinInet 브라우저(134)로부터의 인터넷 요청의 인터셉트를 가능하게 한다.

프로세스(130)는 캐시 버전을 분실하거나 또는 리프레시되어야 하는 경우와 같이 캐시(103)로의 인터넷 요청이 서버로 전송된다는 점에서 프로세스(110)와 다를 수 있으며; 이들 요청은 WinInet 인터셉트(160)에 의해서 WinInet(161)까지 통과되어 전달되며 따라서 이들은 서버에 의해서 조작될 수 있다. 캐시(103)는 (프로세스(110)에 비해서) 다른 동작 모드를 제공함으로써 이 거동을 지원할 수 있으며, 이 동작 모드는 초기화 시간 중에 이루어진 호출을 통하는 것과 같이, 크롤러(131)에 의해서 명시적으로 요청될 수 있다. 서버로부터 수신되는 임의의 새로운 응답 데이터는 데이터베이스(141)에 저장될 수 있으며, 따라서 유지되고 또한 프로세스(110)에 의해서와 같이 액세스가 가능하게 된다.

일부 실시예는 데이터베이스(141)를 통해서 스토리지에 액세스할 수 있으며, 이 스토리지는 파일 시스템, 데이터베이스, 또는 이들의 조합으로 이루어질 수 있다. 데이터베이스(141)는 캐시(103)에서와 마찬가지로 동일한 프로세스 내에서 액세스될 수 있으며, 또는 프로세스(140)와 같은 별도의 맥락 또는 프로세스에 의해서 제공될 수도 있다. 일부 실시예에 있어서, 프로세스(140)는 로컬에 저장된 서버 콘텐트에 대한 액세스를 관리하는 데이터베이스(141)를 동작시킨다. 데이터베이스(141)는 JVM(142) 내부에서 동작하고 있는 Java 소프트웨어 컴포넌트일 수 있다. 기타 프로세스는 Java remote method invocation (RMI) 또는 Java database connectivity (JDBC)와 같은 공통 인터-프로세스 통신(IPC, common inter-process communications) 메커니즘을 사용하는 프로세스(140)와 통신하는 것에 의해서 데이터베이스로부터 데이터를 추출하거나 데이터베이스에 데이터를 저장할 수 있다. 데이터베이스(141)는 또한 프로세스(110 또는 130) 내에서와 같이 클라이언트 프로세스 내에서 동작할 수 있으며; 이는, 예를 들면, 데이터베이스(141)가 공유 데이터의 인터-프로세스 직렬화를 지원하는 경우에 가능하다.

프로세스(150)는 관리자(151)를 동작시키며, 관리자는 크롤러의 기동 및 서버 접속에서의 변동에 대한 감시와 같은 잡다한 제어 및 관리 태스크를 조작하고 있다. 관리자(151)는 JVM(152) 내에서 동작하는 Java 소프트웨어 컴포넌트일 수 있다. 기타 프로세스는 Java RMI와 같은 공통 IPC 메커니즘을 사용하는 것에 의해서 관리자(151)에 의해서 제공되어지는 서비스에 액세스할 수 있다.

3 클라이언트/서버의 상호 작용

3.1 클라이언트 등록

도 1의 실시예에서와 같은 본 발명의 예시적인 실시예에 있어서, 각각의 원격 캐시(즉, 중앙 관리자에 비해서)는 관리 서버(170)에서 유지되고 있는 특정한 설정과 논리적으로 관련되어 있으며, 따라서 원격 캐시는 설치시에 사전 설정될 수 있으며 또는 설치 후 바로 재설정될 수 있다. 예시적인 실시예에 있어서, (캐시(103)와 같은) 원격 캐시는 클라이언트(100)와 같은 클라이언트 컴퓨터 상에 상주하고 있으며, 클라이언트(100)는 관리 서버(170)와 함께 등록(register)하여 먼저 그 설정 데이터를 획득하고 또한 이후에 주기적으로 설정에서의 변동이 있는지에 대해서 체크하게 된다. 모든 클라이언트는 특정한 설정 그룹과 관련되어 있으며, 또한 각각의 설정 그룹은 각각의 클라이언트(100)에 할당될 수 있는 생성자 GUID(Owner globally unique identifier)라고 불리는 고유 식별자((UI, unique identifier)를 가지고 있다.

생성자 GUID를 클라이언트(100)에 할당하는 것은 임의의 적절한 방식으로 수행될 수 있다. 예시적인 일 실시예에 있어서, 클라이언트(100)용 소프트웨어 설치 패키지는 내부에 임베드된 속성으로서의 생성자 GUID(Owner GUID)를 포함할 수 있으며, 따라서 이후에 클라이언트(100)로 사용 가능하게 된다. 이 경우, 각각의 그룹에 대해서 서로 다른 설치 패키지가 있어야 하며, 또한 각각의 이들 설치 패키지는 서로 다른 URL을 통해서 유일하게 식별될 수 있다. 생성자 GUID를 할당하기 위한 다른 방법에는, 예를 들어, 클라이언트(100)를 설치하기 전 또는 후에 사용자가 설정 그룹을 선택할 수 있도록 하는 단계, 또는 관리 서버(170)가 IP 어드레스, 컴퓨터명, 또는 현재 사용자의 유저명과 같은 클라이언트에 대한 일부 정보에 기초하여 생성자 GUID를 할당하도록 허용하는 단계를 포함할 수 있다.

도 3은 관리 서버(170)를 사용하여 클라이언트(100)를 등록하기 위한 예시적인 실시예의 UML(Unified Modeling Language) 시퀀스를 나타내고 있다. 인스톨러(180)가 기동하게 되면, 이 인스톨러(180)는 파일 설치 단계(3001) 및 기타 공통적인 설치 태스크를 수행하고, 또한 생성자 GUID 저장 단계(3002)를 수행한다. 인스톨러(180)가 종료되면, 그 최종 태스크는 관리자 기동 단계(3003)를 수행하는 것에 의해서 (예를 들면, 캐싱 관리자와 같은) 관리자(150)를 기동하는 것이다.

관리자(150)는, 캐시(103)에 대한 설정 및 설정값을 추출, 적용, 및 업데이트하는 것을 포함하는 클라이언트측 캐시 관리 함수를 조작한다. 관리자(150)가 최초로 동작하면, 레지스터 단계(3010)를 수행하여 관리 서버(170)에 초기 등록을 수행한다. 새로운 클라이언트(100)가 관리 서버(170)에 등록될 때마다, 관리 서버(170)는 클라이언트 GUID 할당 단계(3020)를 수행하며, 이 단계에서는 후속하는 관리 서버(170)와의 상호 작용을 위해서 이 클라이언트에 대해서 고유 식별자가 할당된다. 관리 서버(170)는 또한 태스크 생성 단계(3021)를 수행하여 새로운 클라이언트(100)와 관련된 임의의 초기 태스크를 생성한다. 관리 서버(170)는 단계(3030)에서 새로운 설정 또는 라이센스 태스크와 같은, 가능하다면 새로운 클라이언트에 대한 임의의 초기 태스크와 함께 새로운 클라이언트 GUID를 새로운 클라이언트(100)로 반환하게 된다.

예시적인 일 실시예에 있어서, 일단 관리자(150)가 등록을 하게 되면, 관리자는 후속적으로 관리 서버(170)와 함께, 예를 들면, UML 프레임 태스크 루프(3040)(이하에서 도 4를 참조하여 추가 설명됨)에서 설명되는 바와 같이 관리 서버(170) 상의 관리자에 의해서 이루어지는 임의의 설정 변경의 결과에 의해서 생성될 수 있는 임의의 새로운 태스크에 대해서 주기적인 베이스로 체크한다.

3.2 MMC 태스크

도 4는 본 발명의 일 실시예에 따른 예시적인 UML 프레임 태스크 루프(3040)를 나타내는 UML 시퀀스 다이아그램이다.

도 4를 참조하면, UML 프레임 태스크 루프(3040)는 관리자(150)가 관리 서버(170)로부터 수신할 수 있는 태스크를 일반적으로 처리하는 방법에 대해서 도시하고 있다. (매 5 초 마다와 같은) 주기적인 베이스로, 관리자(150)는 태스크 요청 단계(4001)에서 관리 서버(170) 상의 관리자에 의해서 이루어지는 임의의 설정 변경의 결과로써 생성될 수 있는 새로운 태스크에 대해서 체크한다. 태스크 수신 단계(4010)를 통해서 임의의 태스크가 반환되면, 이들은 태스크 처리 단계(4020)에 적용될 수 있다. 태스크의 수행 결과는 결과 보고 단계(4030)를 통해서 관리 서버(170)로 되돌아가서 보고된다.

도 4는 또한 태스크 수신 단계(4010) 중에서 관리 서버(170)에 의해서 관리자(150)로 전송되는 일반화된 태스크(401)를 나타내고 있다. 이는 타입(402)에 의해서, 또한 선택적인 페이로드(403)에 의해서 한정된다. 태스크(401)의 타입(402) 및 페이로드(403)는 서로 다르며 또한 문자 스트링, 이진 데이터 등을 포함하는 다양한 인코딩으로 표현될 수 있다. 태스크 처리(4020)에 있어서, 하나 이상의 태스크가 처리될 수 있으면, 이들 각각은 서로 다른 타입일 수 있다. 각각의 특정 태스크의 처리는 태스크 처리(4020)의 개별적인 변형으로서 이하에서 설명된다. 모든 태스크가 처리된 이후에, 관리자(150)는 결과 보고(4030)를 수행하여 그 결과를 관리 서버(170)로 전송한다.

도 5는 관리 서버(170)로부터 태스크가 수신됨에 따라 관리자(150)에 의한 태스크의 일반적인 처리를 위한 예시적인 처리를 나타내는 UML 시퀀스 다이아그램의 상세도이다. 하나 이상의 태스크는 태스크 루프(3040)의 각각의 반복에서 수신될 수 있으며, 이들 태스크는 루프(5000) 내의 관리자(150)에 의해서 처리된다. 각각의 태스크는 태스크 타입(402)에 의해서 결정되는 바와 같이 태스크의 타입에 기초하여 단계(5010)에서 처리된다.

3.2.1 설정값 업데이트 태스크

예를 들면, 도 5를 계속 참조하여 설명하면, 관리자(150)가 "설정값 업데이트"라고 설정된 태스크 타입(402)을 갖는 태스크9401)를 수신하면, 이후에 페이로드(403)는 클라이언트(100)에서 수행되어야 할 필요가 있으며, 각각 도 6 내지 도 8을 참조하여 이하에서 더욱 상세하게 설명되는 애플리케이션 설정 데이터의 업데이트(단계 5011), 사이트 설정 데이터의 업데이트(단계 5012), 또는 설정 템플릿 설정값의 업데이트(단계 5013)와 같은 복수의 서브태스크를 포함할 수 있다.

설정값 업데이트 태스크의 페이로드가 애플리케이션 설정이 업데이트되어야 함을 지시하는 경우, 단계(5011)에서 업데이트된다. 애플리케이션 설정 데이터는 클라이언트(100)에 대해서 캐시(103) 및/또는 관리자(150)의 조작을 컨트롤하기 위한 것과 같이, 초정밀 컨트롤 또는 복잡한 조작 파라미터를 제공할 수 있다. 예를 들면, 애플리케이션 설정 데이터는 어떤 HTTP 요청이 캐시되어야 할 지 또는 어떤 특정한 URL이 캐시되어야 할 지와 같은 캐시(103)에 대한 애플리케이션 특유의 거동을 규정할 수 있다.

도 6은, 본 발명의 일 실시예에 따른, 관리자(150)가 설정값 업데이트 태스크(401)의 페이로드(403)가 애플리케이션 설정 데이터를 포함하고 있음을 발견한 경우의 애플리케이션 설정 데이터의 예시적인 처리를 나타내고 있다. 먼저, 관리자(150)는 태스크 페이로드 판독 단계(6001)를 수행하여 애플리케이션 설정 데이터를 획득하거나, 또는 애플리케이션 설정 획득 단계(6002)에서 관리 서버(170)로부터와 같이 어디에서 획득하는 지를 지시할 수 있다. 이후에, 관리자(150)는 애플리케이션 설정 저장 단계(6004)에서 스토리지(106)에 애플리케이션 설정을 저장하기 전에, 이 애플리케이션 설정 데이터가 유효한지를 보장하기 위해서 애플리케이션 설정 파싱 단계(6003)에서 이를 파싱하고 체크한다. 관리자(150)는 이제 애플리케이션 설정 적용 단계(6005)에서 새로운 설정을 적용할 수 있으며, 이 단계는 실행 시간 자료 구조를 업데이트하는 단계, 및 캐시(103)로 통지하는 것과 같이, 컴포넌트로 통지하는 단계(6006)에서, 변동에 대해서 다른 컴포넌트로 통지하는 단계를 포함할 수 있다.

도 5로 되돌아가면, 설정값 업데이트 태스크 페이로드가 사이트 설정 데이터가 업데이트될 필요가 있다고 지시하는 경우, 단계(5012)에서 업데이트된다. 사이트 설정 데이터는 생성될 전용 캐시, 및 어떤 호스트 네임 또는 URL 패턴을 각각의 캐시가 조작하게 될 지를 규정할 수 있다.

도 7은, 본 발명의 일 실시예에 따른, 관리자(150)가 설정값 업데이트 태스크(401)의 페이로드(403)가 사이트 설정 데이터를 포함하고 있음을 발견한 경우의 사이트 설정 데이터의 예시적인 처리를 나타내고 있다. 먼저, 관리자(150)는 유입되는 사이트 판독 단계(7001)를 수행하여 새로운 사이트 설정으로부터 사이트를 획득한다. 관리자(150)는 이후에 기존 사이트 판독 단계(7002)를 수행하여 업데이트되어야 하는 데이터베이스(141) 내에 현재의 사이트를 저장한다. 다음으로, 루프(7003)에 있어서, 유입되는 사이트 설정 내의 각 사이트에 대해서, 관리자(150)는 유입되는 사이트 적용 단계(7004)를 수행할 수 있으며, 예를 들면, 새로운 사이트를 추가하거나 또는 기존 사이트를 업데이트할 수 있다. 이 변동은 이후에 사이트 저장 단계(7005)에서 데이터베이스(141)에 저장되어질 수 있다. 이후에 관리자는 컴포넌트에게 통지하는 단계(7006)를 수행할 수 있고, 따라서 캐시(103)와 같은 다른 컴포넌트가 각각의 변동을 적용할 수 있다. 다음으로, 루프(7010)에 있어서, 관리자(150)는 더 이상 사이트 설정의 일부가 아닌 임의의 사이트에 대해서 검색하며, 또한 삭제된 사이트 제거 단계(7011)에서 이들을 제거한다.

다시 도 5를 참조하면, 설정값 업데이트 태스크 페이로드가 설정 템플릿으로부터의 설정값이 사용 가능함을 표시하는 경우, 이후에 이 설정값은 설정 템플리트 적용 단계(5013)에서 적용된다. 설정 템플리트는 본 발명의 예시적인 시스템 실시예의 조작에 영향을 미치는 설정값을 포함하고 있으며, 이 설정값은 애플리케이션 설정 데이터와 유사하다. 이들 설정값은 본질상 그래픽 사용자 인터페이스를 통해서 최종 사용자 또는 관리자에 의해서 수정될 수 있는 설정값과 같이 더욱 동적이라는 점에서 애플리케이션 설정 데이터에서의 값과 다를 수 있다.

도 8은 본 발명의 일 실시예에 따라 유입되는 설정값 판독 단계(8001)를 관리자(150)가 수행하여 페이로드(403)로부터 설정값을 획득하는 경우, 설정 템플리트 설정값의 예시적인 처리 방법을 나타내고 있다. 관리자(150)는 로컬 설정값 획득 단계(8002)를 수행하여 데이터베이스(141)로부터 현재의 설정값을 획득하고, 이후에 유입되는 설정값에 기초하여 로컬 설정값 업데이트 단계(8003)를 수행하고, 또한 이후에 로컬 설정값 저장 단계(8004)를 수행하여 로컬 설정값을 데이터베이스(141)에 유지할 수 있다.

설정값 업데이트의 서브태스크의 결과는 수집되며 따라서 이들은 단계(4030)에서 관리 서버(171)로 전송되어질 수 있다.

3.2.2 캐시 퍼지(purge) 태스크

관리자(150)가 "캐시 퍼지"(Purge Cache)로 설정된 태스크 타입(402)을 갖는 태스크를 수신하게 되면, 페이로드(403)는, 도 5에서의 단계(5014)에서 지시되는 바와 같이, 클라이언트(100)에서 캐시를 퍼지하기 위한 명령을 구체화한다.

도 9는 본 발명의 일 실시예에 따른 캐시 퍼지 단계(5014) 태스크를 처리하기 위한 예시적인 UML 시퀀스를 상세하게 나타낸 도면이다. 도 9를 참조하면, 관리자(150)는, 예를 들면, 퍼지될 캐시에 대해서 기술하고 있는 페이로드(403)로부터 퍼지 설정값을 판독하는 단계(9001)를 수행하며, 관리자(150)는 루프(9010) 내에서 규정된 각각의 캐시를 퍼지할 수 있다. 각각의 캐시 퍼지 요청은, 예를 들면, 호스트 네임 또는 URL 패턴과 같은 퍼지될 사이트를 식별할 수 있다. 관리자(150)는 사이트 정보 판독 단계(9011)를 수행하여 이 사이트의 캐시가 스토리지(106) 내의 어디에 저장되어 있는 지를 결정하며, 따라서 관리자(150)는 이후에 사이트 캐시 삭제 단계(9012)를 수행할 수 있다.

캐시 퍼지 태스크의 결과는 수집되며 따라서 이들은 단계(4030)에서 관리 서버(170)로 전송될 수 있다.

3.2.3 캐시 항목 삭제 태스크

관리자(150)가 "캐시 항목 삭제"(Flush Cache Items)로 설정된 태스크 타입(402)을 갖는 태스크를 수신하게 되면, 페이로드(403)는, 도 5에서의 단계(5015)에서 지시되는 바와 같이, 클라이언트(100)에서 캐시로부터의 특정 항목을 삭제하기 위한 명령을 구체화한다.

도 10은 본 발명의 일 실시예에 따른 캐시 항목 삭제 단계(5015) 태스크를 처리하기 위한 예시적인 UML 시퀀스를 상세하게 나타낸 도면이다. 도 10을 참조하면, 관리자(150)는, 예를 들면, 어떤 캐시 항목이 클라이언트(100) 상의 캐시로부터 삭제되어야 하는 지에 대해서 기술하고 있는 페이로드(403)로부터 삭제 요청 판독 단계(10001)를 수행한다. 관리자(150)는 이후에 데이터베이스(141)로부터 사이트 정보 판독 단계(10002)를 수행하여, 각 사이트의 캐시, 예를 들면 이들의 현재의 콘텐트에 대한 정보를 획득할 수 있다.

다음으로, 루프(10010)(외측 루프)에 있어서, 페이로드(403)로부터 추출되는 각각의 삭제 요청에 대해서, 이 삭제 요청은, 정규 표현식 또는 URL 패턴을 사용하는 것과 같이, 캐시로부터 삭제되어야 할 특정 콘텐트 또는 콘텐트 타입에 대해서 기술하고 있을 수 있다. 루프(10020)(중간 루프)에 있어서, 이들 각각의 삭제 요청에 대해서, 관리자(150)는 캐시 항목 탐색 단계(10023)를 수행하여 스토리지(106) 상에 저장된 대응하는 사이트 캐시 내의 삭제 요청과 매치되는 항목의 위치를 결정할 수 있다. 예시적인 일 실시예에 있어서, 캐시 항목은 신속한 탐색을 위해서, 예를 들면 캐시 항목의 URL의 해쉬(hash)를 사용하는 것과 같이, "탐색 키"(lookup key)라고 명명된 파일 내에 저장되며, 따라서 이들 캐시 항목의 결정은 이들의 실제 URL을 획득하고 또한 비교하기 위해서 이들 캐시 항목에 대한 대응하는 메타데이터를 판독하는데 필요할 수 있다.

다음으로, 루프(10030)(내측 루프)에 있어서, 이들 캐시 항목의 각각에 대해서, 관리자(150)는 또한 관련 항목 탐색 단계(10034)를 수행하여, 캐시 항목 또는 이 캐시 항목에 대한 대응하는 HTTP 응답 헤더에 대한 사용자 친화적인 이름을 참조하는 매핑 파일과 같은 이들 항목과 관련된 임의의 콘텐트를 위치 결정할 수 있게 된다. 이후에, 단계(10035)에 있어서, 관리자(150)는, 스토리지(106)로부터, 삭제 요청과 매치되는 캐시 항목에 대해서 검색되어진 이들 항목을 모두 삭제한다.

캐시 항목 삭제 태스크의 결과는 수집되며 따라서 이들은 단계(4030)에서 관리 서버(170)로 전송될 수 있다.

3.3 예시적인 방법

도 11은 본 발명의 일 실시예에 따른 전용 캐시 관리의 예시적인 방법(1100)을 도시하고 있다. 방법(1100)은 네트워크를 통한 원격 서버와 통신하기 위해서 및 서버에 의해서 제공되는 콘텐트 또는 서비스에 대한 액세스를 제공하기 위한 컴퓨터 설정에 관한 것이다.

처리가 시작되면, 또한 단계(1110)에서는, 하나 이상의 전용 캐시가 생성되고, 각각의 캐시는 하나 이상의 URL과 관련되어 진다. 이후에 각각의 캐시는 하나 이상의 규칙을 사용하여 단계(1102)에서 관리된다. 클라이언트 애플리케이션으로부터 서버로의 URL에 대한 요청은 단계(1130)에서 투명하게 인터셉트된다. 캐시는 단계(1140)에서 클라이언트 애플리케이션이 요청을 서버로 전송하고 또한 서버로부터 응답을 수신한 것처럼 네트워크를 통해서 언제 요청을 서버로 전송하고 또한 서버로부터의 응답을 언제 클라이언트 애플리케이션에 나타나도록 제공할 지를 자동으로 결정한다. 캐시는 이를 (1) 클라이언트 애플리케이션이 요청을 전송함에도 불구하고 단계(1150)에서 요청이 서버에 나타나도록 하기 위해서 요청을 서버로 전송하는 것, 또는 (2) 캐시 중의 하나로부터 단계(1160)에서의 응답을 제공하는 것에 의해서 수행한다. 이후에 처리는 단계(1120)와 함께 캐시의 관리 및 요청의 인터셉트와 서비스를 반복하게 된다.

4 결론

상술한 예시들은 구체적인 인터넷 애플리케이션 및 프로토콜에 대해서 나타내고 있음에도 불구하고, 본 발명은 인터넷 애플리케이션 또는 프로토콜만으로 제한되는 것은 아니라는 점에 주목할 필요가 있다. 상술한 기타 현존 및 미래의 인터넷 애플리케이션 또는 프로토콜은 상술한 적응형 특징을 사용할 수 있다.

본 발명이 특정 실시예를 참조하여 설명되었지만, 이들 실시예는 예시적인 것일 뿐 제한하는 것은 아니다. 본 발명의 다양한 기타 애플리케이션 및 실시예는 본 발명의 상세한 설명의 내용, 후술하는 특허청구범위, 및 이의 균등물을 참조하면 명확해질 것이다.

Claims

네트워크를 통해서 원격 서버와 통신하도록 또한 상기 서버에 의해서 제공되는 콘텐트 또는 서비스로의 액세스를 제공하도록 설정된 클라이언트 기반 컴퓨터 시스템에 있어서,
프로세서;
스토리지 디바이스;
일 설정에 의해서 규정되는 일련의 리소스에 전용화된 클라이언트측 캐시; 및
상기 설정에 의해서 지시됨에 따라서 상기 캐시를 자동으로 관리하기 위한 캐시 관리자;를 포함하며,
상기 클라이언트측 캐시는 상기 설정에 의해서,
클라이언트 애플리케이션으로부터 상기 서버로의 리소스 중의 하나에 대한 요청을 투명하게 인터셉트하도록 지시되고; 또한
상기 클라이언트 애플리케이션이 상기 요청을 상기 서버로 전송하고 또한 상기 서버로부터 응답을 수신한 것처럼 상기 네트워크를 통해서 언제 상기 요청을 상기 서버로 전송하고 또한 상기 서버로부터의 상기 응답이 언제 상기 클라이언트 애플리케이션에 나타나도록 제공하는 것을 자동으로 결정하도록 지시되며,
상기 자동으로 결정하는 것은,
상기 클라이언트 애플리케이션이 상기 요청을 전송한 것처럼 상기 서버에 나타나도록 상기 요청을 상기 서버로 전송하는 단계, 상기 서버로부터의 상기 응답을 제공하는 단계, 및 상기 스토리지 디바이스 상에 상기 응답을 저장하는 단계에 의해서, 또는
상기 캐시로부터 상기 응답을 제공하는 단계에 의해서 결정되고,
상기 클라이언트측 캐시에 고유 식별자를 할당할 때, 클라이언트용 소프트웨어 설치 패키지의 경우, 내부에 임베디드된 속성으로서의 생성자 GUID(Owner GUID)를 포함하여 할당하는,
클라이언트 기반 컴퓨터 시스템.
제 1 항에 있어서,
상기 캐시, 상기 일련의 리소스, 또는 상기 캐시 관리자는 상기 설정에 대한 임의의 업데이트를 자동으로 적용하도록 설정된, 클라이언트 기반 컴퓨터 시스템.
제 1 항에 있어서,
상기 시스템은 관리 콘솔로부터 상기 설정을 수신하도록 설정된, 클라이언트 기반 컴퓨터 시스템.
제 3 항에 있어서,
상기 관리 콘솔을 더 포함하는, 클라이언트 기반 컴퓨터 시스템.
제 4 항에 있어서,
상기 캐시, 상기 일련의 리소스, 및 상기 캐시 관리자는 상기 설정이 상기 관리 콘솔에서 변경될 때마다 상기 설정에 대한 임의의 업데이트를 자동으로 적용하도록 설정되어 있는, 클라이언트 기반 컴퓨터 시스템.
제 4 항에 있어서,
상기 관리 콘솔은 유일 설정 식별자에 기초하여 상기 설정을 할당하도록 설정되어 있는, 클라이언트 기반 컴퓨터 시스템.
제 6 항에 있어서,
상기 관리 콘솔은 상기 시스템이 상기 관리 콘솔에 최초 등록할 때 상기 시스템에 유일 클라이언트 식별자를 할당하도록 더 설정되어 있는, 클라이언트 기반 컴퓨터 시스템.
제 1 항에 있어서,
상기 설정은 상기 캐시 관리자를 지시하기 위한 제 1 섹션부 및 상기 캐시를 지시하기 위한 제 2 섹션부를 포함하는, 클라이언트 기반 컴퓨터 시스템.
제 1 항에 있어서,
상기 요청은 HTTP 요청을 포함하는, 클라이언트 기반 컴퓨터 시스템.
제 9 항에 있어서,
상기 요청은 POST 요청을 포함하는, 클라이언트 기반 컴퓨터 시스템.
제 1 항에 있어서,
상기 설정은 일련의 규칙에 근거하여 상기 응답을 언제 상기 스토리지 디바이스에 저장할 지 또는 언제 상기 캐시로부터의 상기 응답을 제공할 지를 규정하는, 클라이언트 기반 컴퓨터 시스템.
제 11 항에 있어서,
상기 규칙은 상기 응답을 상기 스토리지 디바이스에 언제 저장할 지 또는 상기 캐시로부터의 상기 응답을 언제 제공할 지를 결정하기 위한 URL 패턴을 포함하는, 클라이언트 기반 컴퓨터 시스템.
제 11 항에 있어서,
상기 규칙은 저장된 응답이 얼마나 오래 상기 캐시 내에 유지되어야 하는지를 규정하는, 클라이언트 기반 컴퓨터 시스템.
제 11 항에 있어서,
상기 규칙은 저장된 응답이 얼마나 오래 상기 서버로부터 재확인 없이 상기 응답을 공급하도록 사용될 수 있는지를 규정하는, 클라이언트 기반 컴퓨터 시스템.
제 11 항에 있어서,
상기 규칙은 상기 캐시로부터의 상기 응답에 대한 상기 요청의 매핑을 규정하는, 클라이언트 기반 컴퓨터 시스템.
제 15 항에 있어서,
상기 매핑 규칙은 상기 요청의 일부를 필터링하는 것을 포함하는, 클라이언트 기반 컴퓨터 시스템.
제 1 항에 있어서,
상기 설정은 서로 다른 애플리케이션 타입에 대해 서로 다른 규칙과 관련되는, 클라이언트 기반 컴퓨터 시스템.
제 17 항에 있어서,
상기 클라이언트측 캐시는 상기 애플리케이션 타입 중의 특정한 하나와 관련되어 있는, 클라이언트 기반 컴퓨터 시스템.
제 1 항에 있어서,
상기 설정은 상기 원격 서버 상의 사용자 계정을 전용화된 상기 캐시에 관련시키는, 클라이언트 기반 컴퓨터 시스템.
제 1 항에 있어서,
상기 캐시 또는 상기 캐시 관리자는 상기 캐시의 콘텐트를 자동적으로 리프레시하도록 설정되어 있는, 클라이언트 기반 컴퓨터 시스템.
제 20 항에 있어서,
상기 캐시의 상기 콘텐트는 스케줄에 따라서 자동으로 리프레시되도록 구성되어 있는, 클라이언트 기반 컴퓨터 시스템.
제 1 항에 있어서,
상기 캐시는 복수의 전용 캐시를 포함하는, 클라이언트 기반 컴퓨터 시스템.
제 22 항에 있어서,
상기 설정은 각각의 상기 캐시가 전용화된, 대응하는 복수의 애플리케이션 타입을 규정하는, 클라이언트 기반 컴퓨터 시스템.
제 22 항에 있어서,
상기 설정은 각각의 상기 캐시가 전용화된, 대응하는 복수의 사용자 계정을 규정하는, 클라이언트 기반 컴퓨터 시스템.
제 22 항에 있어서,
상기 캐시 관리자는 상기 설정에 의해서 지시됨에 따라서 상기 스토리지 디바이스 상의 상기 전용 캐시를 재설정하도록 더 설정되는, 클라이언트 기반 컴퓨터 시스템.
제 25 항에 있어서,
상기 캐시 관리자는 상기 설정에 의해서 지시됨에 따라서 상기 스토리지 디바이스 상의 각각의 상기 전용 캐시의 저장 공간을 재설정하도록 더 설정되는, 클라이언트 기반 컴퓨터 시스템.
제 3 항에 있어서,
상기 캐시 관리자는 상기 관리 콘솔에 의해서 제공되는 명령어에 응답하도록 설정되어 있는, 클라이언트 기반 컴퓨터 시스템.
제 27 항에 있어서,
상기 명령어는 상기 설정을 업데이트하기 위한 것인, 클라이언트 기반 컴퓨터 시스템.
제 27 항에 있어서,
상기 명령어는 상기 캐시 내의 콘텐트를 삭제하기 위한 것인, 클라이언트 기반 컴퓨터 시스템.
제 29 항에 있어서,
상기 명령어는 URL 패턴에 대응하는 상기 캐시 내의 콘텐트를 삭제하기 위한 것인, 클라이언트 기반 컴퓨터 시스템.
제 27 항에 있어서,
상기 명령어는 상기 캐시 내의 콘텐트를 리프레시(refresh)하도록 하는 것인, 클라이언트 기반 컴퓨터 시스템.
네트워크를 통해서 원격 서버와 통신하도록 또한 상기 서버에 의해서 제공되는 콘텐트 또는 서비스로의 액세스를 제공하도록 컴퓨터를 설정하는 방법으로서,
각각 하나 이상의 URL과 관련된 하나 이상의 전용 캐시를 생성하는 단계;
각각의 캐시에 대해서, 하나 이상의 규칙에 따라서 상기 캐시를 관리하는 단계;
클라이언트 애플리케이션으로부터 상기 서버로의 상기 URL 중의 하나에 대한 요청을 투명하게 인터셉트하는 단계; 및
상기 클라이언트 애플리케이션이 상기 요청을 상기 서버로 전송하고 또한 상기 서버로부터 응답을 수신한 것처럼 상기 네트워크를 통해서 언제 상기 요청을 상기 서버로 전송하고 또한 상기 서버로부터의 상기 응답이 언제 상기 클라이언트 애플리케이션에 나타나도록 제공하는 것을 자동으로 결정하는 단계;를 포함하며,
상기 자동으로 결정하는 단계는,
상기 클라이언트 애플리케이션이 상기 요청을 전송한 것처럼 상기 서버에 나타나도록 상기 요청을 상기 서버로 전송하는 단계, 상기 서버로부터의 상기 응답을 제공하는 단계, 및 스토리지 디바이스 상에 상기 응답을 저장하는 단계, 또는
상기 캐시로부터 상기 응답을 제공하는 단계;를 포함하고,
상기 캐시에 고유 식별자를 할당할 때, 클라이언트용 소프트웨어 설치 패키지의 경우, 내부에 임베디드된 속성으로서의 생성자 GUID(Owner GUID)를 포함하여 할당하는,
컴퓨터 설정 방법.
제 32 항에 있어서,
상기 하나 이상의 캐시를 재구성하는 단계를 더 포함하는, 컴퓨터 설정 방법.
제 32 항에 있어서,
각각의 캐시와 관련된 상기 URL을 재구성하는 단계를 더 포함하는, 컴퓨터 설정 방법.
제 32 항에 있어서,
상기 응답을 상기 스토리지 디바이스에 언제 저장할 지 또는 상기 캐시로부터의 상기 응답을 언제 제공할 지를 결정하기 위해 URL 패턴을 사용하는 단계를 더 포함하는, 컴퓨터 설정 방법.
제 32 항에 있어서,
저장된 응답이 상기 캐시 내에 얼마나 오래 유지되어야 하는 지를 결정하기 위해 규칙을 사용하는 단계를 더 포함하는, 컴퓨터 설정 방법.
제 32 항에 있어서,
특정값에 기초하여 상기 서버로부터 재확인없이 저장된 응답이 얼마나 오래 상기 응답을 공급하도록 사용될 수 있는 지를 결정하기 위한 규칙을 사용하는 단계를 더 포함하는, 컴퓨터 설정 방법.
제 32 항에 있어서,
상기 캐시 내의 콘텐트를 삭제하기 위한 명령어에 응답하는 단계를 더 포함하는, 컴퓨터 설정 방법.
제 32 항에 있어서,
URL 패턴에 대응하는 상기 캐시 내의 콘텐트를 삭제하기 위한 명령어에 응답하는 단계를 더 포함하는, 컴퓨터 설정 방법.
제 32 항에 있어서,
상기 캐시 내의 콘텐트를 리프레시하도록 하기 위한 명령어에 응답하는 단계를 더 포함하는, 컴퓨터 설정 방법.