KR100791430B1 - 네트워크 캐싱 방법 및 시스템 - Google Patents

Abstract

프래그먼트 캐싱을 위한 방법, 시스템, 장치 및 컴퓨터 프로그램 제품이 제공된다. 메시지가 캐시 관리 유닛을 포함하는 컴퓨팅 장치에 수신된 후에, 그 메시지의 메시지 보디 내의 프래그먼트가 캐싱된다. 캐시 관리 유닛에서 그 프래그먼트에 대한 차후의 요청이 있으면 캐시 히트가 있게 된다. 캐시 관리 유닛은 컴퓨팅 장치가 클라이언트, 서버 또는 네트워크에 걸쳐 배치된 허브로서 기능하는지에 상관없이 프래그먼트 캐싱 동작을 지원하여 동등하게 동작한다. 다시 말하면, 프래그먼트 캐싱 기술은 네트워크에 걸쳐 균일하다. 캐시 ID 규칙은 원서버로부터의 프래그먼트를 수반하며, 캐시 ID 규칙은 동적 콘텐츠가 원서버로부터 멀리 떨어진 곳에 캐싱될 수 있도록 프래그먼트의 고유 캐시 ID를 형성하는 방법을 기술한다.

Description

네트워크 캐싱 방법 및 시스템{METHOD AND SYSTEM FOR NETWORK CACHING}

본 발명은 개선된 데이터 처리 시스템에 관한 것으로서, 특히 네트워크 자원 할당을 개선시킨 데이터 처리 시스템에 관한 것이다. 보다 구체적으로는, 본 발명은 컴퓨터 네트워크에서 데이터 객체를 캐싱하는 방법 및 시스템을 제공한다.

인터넷을 통해 전송되는 데이터량은 인터넷 사용자 수의 증가율 또는 그들의 트랜잭션 수의 증가율을 넘는 속도로 계속 증가하고 있다. 이러한 증가의 주된 요인은 월드 와이드 웹 사이트 자체의 성격의 변화이다. 월드 와이드 웹의 초기 단계에서, 웹 페이지는 텍스트, 이미지 및 다른 사이트로의 링크 등의 정적 콘텐츠로 주로 이루어져 있었다. 사용자의 웹 사이트와의 대화 범위는 HTML 페이지 및 그의 구성요소를 다운로드하는 것이었다. 페이지를 요청한 사람이 누구인지에 관계없이 콘텐츠가 통상 동일하였기 때문에, 웹 서버가 수많은 사용자를 지원하는 것은 비교적 간단하였다. 그렇지만, 현재의 경향은 웹 사이트의 콘텐츠 및 외양이 특정 사용자 및/또는 사용자 입력에 따라 변하는 대화형 웹 페이지쪽으로 가고 있다. 이것은 온라인 제품 선택 및 구매를 지원하는 전자 상거래 사이트의 경우에 특히 그러하다. 이러한 사이트는 그의 더욱 동적인 콘텐츠에 의해 이전의 웹 사이트와 구별된다. 이것의 친숙한 일례로는 많은 인터넷 비즈니스 사이트에서 제공되는 "온 라인 카탈로그"가 있다. 구매를 하기 위해 그 사이트에 로깅하는 각 고객은 카탈로그를 열람하고 또 수천개의 제품에 관한 상세한 정보까지도 세밀히 살펴볼 기회를 갖는다. 겉보기에, 웹 서버는 각 쇼핑객마다 독자적인 웹 페이지를 유지 및 갱신해야만 한다. 인터넷 사용자는 이러한 맞춤식의 대화형 웹 사이트의 편리성을 향유하고, 고객의 기대는 틀림없이 웹 페이지에 동적 콘텐츠를 더 사용하도록 하는 자극을 제공할 것이다.

인터넷 웹 페이지에 동적 콘텐츠를 사용하기 시작함으로써 웹 사이트의 운영자에게는 어떤 재고 관리 문제가 생기게 된다. 현재의 전자 상거래 사이트는 "열람 대 구입 비율"(browse-to-buy ratio)이 아주 높은 특징을 갖는다. 쇼핑 사이트의 경우, 영속적인 비즈니스 기록을 갱신하는 대화("트랜잭션") 각각에 대해 이를 갱신하지 않는 대화("요청" 또는 "질의")의 전형적인 비율은 60이다. 여기서, 제품 설명을 열람하는 것은 요청의 일례이고, 구입하는 것은 트랜잭션의 일례이다. 동적 콘텐츠의 보급 증가의 한가지 효과로는 트랜잭션의 수는 예측 및 관리 가능한 비율로 증가하지만 요청의 수는 폭발적으로 증가하고 있다는 것이다. 동적 콘텐츠를 갖는 웹 페이지의 높은 사용자 대화성이 트랜잭션당 많은 수의 요청을 떠맡고 있다. 이들 웹 페이지 내의 동적 콘텐츠는 일반적으로 사용자가 이들 웹 페이지 중의 하나의 열람을 요청할 때마다 생성된다. 이 결과 하나의 세션 동안 엄청난 양의 콘텐츠를 준비하여 사용자에게 전달해야만 한다.

사용자 기대로 인해 사이트 제공자는 사용자의 요청에 응답하여 동적 웹 콘텐츠를 신속하게 제공하지 않으면 안된다. 잠재적 고객이 웹 사이트가 너무 느리 다고 인식하게 되면, 그 사이트의 방문을 중단하게 되어 그 결과 영업 손실을 보게 될 수 있다. 그렇지만, 엄청난 양의 인터넷 트래픽을 처리하는 것은 전자 상거래에 과도한 재정 부담을 지울 수 있다. 전자 상거래가 잠재 고객에 의한 정보의 수요 증가를 충족시키기 위한 가장 간단한 방법은 컴퓨터, 저장 장치 및 대역폭을 더 추가함으로써 그의 서버측 하드웨어를 보강시키는 것이다. 이 해결 방안은 엄청난 비용이 들고 비효율적일 수 있다.

보다 비용 효율적인 방법은 성능의 향상을 위해 디지털 컴퓨터에서 통상 이용되는 기술인 캐싱이다. 데이터 저장을 위해 컴퓨터에서 사용되는 메인 메모리는 일반적으로 프로세서보다 훨씬 더 느리다. 데이터 액세스 동안 더 느린 메모리에 대응하기 위해, 프로세서의 정상적인 명령어 타이밍에 관례적으로 대기 상태가 부가된다. 프로세서가 메인 메모리로부터 데이터를 항상 액세스할 필요가 있는 경우, 그의 성능은 상당히 떨어질 것이다. 캐싱에서는 메인 메모리 액세스 병목 현상을 극복하기 위해 "데이터 국부성(data locality)"이라고 하는 통계적 특징의 이점을 활용하기 위해 "캐시"라고 하는 작지만 아주 빠른 메모리 버퍼를 이용한다. 데이터 국부성이란 연속적인 데이터 액세스가 메모리의 동일한 일반 영역에 관여되는 통상의 경향을 말한다. 이것을 통상, 데이터 액세스 중 80%는 20%의 동일 메모리에 대해서 이루어진다고 하는 "80/20" 규칙이라고 말한다.

웹과 관련된 것은 아니지만 이하의 일례는 일반적인 캐싱의 이점을 설명한다. 2개의 큰 숫자 배열을 곱하는 컴퓨터 프로그램을 가지고 있으며 컴퓨터가 이 프로그램을 보다 빠르게 실행할 수 있게 그 컴퓨터를 변형시킬 수 있는 방법을 생 각해내려고 한다고 가정하자. 가장 간단한 변형은 프로세서의 속도를 높이는 것이지만 이는 한계가 있다. 프로그램의 각 개개의 곱셈 연산은 프로세서가 2개의 피연산자를 메모리로부터 페치하여, 그 곱을 계산하게 한 다음에 그 결과를 다시 메모리에 기록하게 한다. 보다 높은 프로세서 속도에서는, 계산에 그다지 많은 시간이 걸리지 않기 때문에, 제한 인자는 프로세서가 메모리와 상호 작용하는 데 걸리는 시간이 된다. 보다 빠른 메모리가 사용될 수 있지만, 컴퓨터에 필요한 메모리 전부에 대해 대량의 초고속 메모리를 사용하는 것은 너무 비실용적이고 너무 고비용이 된다. 다행히, 행렬 곱셈 프로그램은 2개의 입력 배열 각각의 원소들이 어떤 메모리 범위 내의 연속한 주소를 차지하기 때문에 높은 데이터 국부성을 나타낸다. 따라서, 대량의 초고속 메모리를 사용하는 대신에, 소량의 초고속 메모리가 캐시로서 이용된다. 프로그램의 시작 시에, 메인 메모리로부터의 입력 배열이 캐시 버퍼로 전송된다. 프로그램이 실행되는 동안, 프로세서는 캐시로부터 피연산자를 페치하고 해당 결과를 캐시에 다시 기록한다. 데이터 액세스가 고속 캐시를 사용하기 때문에, 프로세서는 메인 메모리를 사용했을 경우보다 프로그램을 더 빠르게 실행시킬 수 있다. 사실, 캐시를 사용하면 메인 메모리 전부가 업그레이드된 것같은 거의 그만큼의 속도 향상을 가져오지만 비용은 상당히 낮다. 유의할 점은 캐시 시스템이 데이터 국부성의 가정이 정당화되는 상황에서만 유익하다는 것이며, 프로세서가 데이터를 가져오기 위해 빈번히 캐시 밖으로 나가야만 하는 경우, 캐시의 속도 이점은 사라지게 된다.

데이터 캐시의 사용과 관련된 다른 문제점은 "캐시 코히런시(cache coherency)"이다. 전술한 바와 같이, 데이터는 보다 빠른 액세스가 가능하도록 일반적으로 캐시로 복사된다. 캐시 내의 각 데이터는 메인 메모리 내의 원래의 데이터의 동일한 복사본이다. 컴퓨터 내의 한 애플리케이션이 메인 메모리 내의 한 변수를 액세스하는 동안 다른 애플리케이션이 캐시 내의 복사본을 액세스하는 경우에 문제가 일어날 수 있다. 그 변수의 한 버전이 다른 버전과 독립적으로 변경되는 경우, 캐시는 코히런시를 상실하여 유해한 결과를 가져올 수 있다. 예를 들어, 변수가 중요한 운영 체제 데이터에 대한 포인터인 경우, 치명적인 에러가 일어날 수 있다. 이를 피하기 위해, 캐시의 상태가 모니터링되어야만 한다. 캐시 내의 데이터가 수정될 때, 메인 메모리 내의 "신선하지 않은(stale)" 복사본은 갱신될 수 있을 때까지 일시적으로 무효화된다. 따라서, 임의의 캐시 장착 시스템의 중요한 특징은 캐시 코히런시를 유지하는 프로세스이다.

이들 공지된 문제점 및 이점을 살펴보면, 캐시는 소위 콘텐츠 전달 네트워크(Content Delivery Network, CDN)를 포함하여 인터넷 또는 개인 네트워크 내의 여러 장소에 있는 데이터 처리 시스템 내에 구현되어 왔다. 알게 되는 바와 같이, 웹 트래픽은 캐싱에 아주 적합하다. 전자 상거래 인터넷 트래픽의 대부분은 사용자로부터 서버로 전송되는 데이터보다는 서버로부터 사용자로 전송되는 데이터로 이루어져 있다. 대부분의 경우, 사용자는 웹 사이트에 정보를 요청하고, 사용자가 웹 사이트로 정보를 전송하는 일은 비교적 드물다. 예를 들면, 사용자가 웹 페이지를 요청하는 일은 빈번하고, 웹 사이트에 저장되는 개인 정보 또는 거래 정보를 제공하는 일은 비교적 드물다. 따라서, 데이터 트래픽의 대부분은 양호한 캐 시 코히런시 특성을 나타낸다. 게다가, 사용자가 다른 웹 사이트로 이동하기 전에 얼마 동안 하나의 웹 사이트의 콘텐츠를 열람 및 재열람하는 경향이 있기 때문에 데이터 트래픽의 대부분은 양호한 데이터 국부성 특성을 나타낸다. 게다가, 많은 사용자들은 동일한 정보를 요청하는 경향이 있으며, 그 정보를 어떤 지점에 캐싱하는 것이 이를 데이터베이스로부터 반복하여 검색하는 것 보다 효율적일 것이다. 또한, 대부분의 웹 애플리케이션은 데이터가 얼마나 최신의 것인가에 대해서는 얼마간의 여유를 허용해준다. 예를 들어, 제품 가격이 변할 때, 그 변화가 효력을 나타내기 위해 몇분의 지연을 갖는 것은 허용될 수 있다. 즉, 캐시 코히런시가 완벽하지 않아도 되며, 이 또한 캐싱을 더욱 유용하게 해준다.

웹 콘텐츠를 캐싱하는 것의 이점은 이하의 논의에서 대체적으로 설명될 수 있다. 클라이언트 브라우저로부터의 각 요청은 인터넷에 걸쳐 배치되어 있는 방화벽, 라우터 등의 다수의 데이터 처리 시스템과, 중간 서버, 프리젠테이션 서버(presentation server)(예를 들어, 정적 콘텐츠의 판독, 동적 페이지의 구축), 애플리케이션 서버(예를 들어, 페이지의 데이터 검색, 갱신 수행), 및 백엔드 서버(backend server)(예를 들어, 데이터베이스, 서비스 및 레거시 애플리케이션(legacy application)) 등의 여러가지 유형의 서버를 통해 지나갈 수 있다. 이들 처리 단계 각각에는 관련된 비용 및 성능 문제가 있다.

캐싱이 전혀 없는 경우, 모든 요청은 프리젠테이션 서버로 가게 되며, 이들 요청이 동적 콘텐츠를 요구하지 않기 때문에 그 서버는 어떤 요청들을 만족시킬 수는 있다. 불행히도, 많은 요청이 갱신을 하거나 동적 콘텐츠 페이지의 데이터를 획득하기 위해 애플리케이션 서버 및 백엔드 서버에 대해 처리도 요구한다.

그렇지만, 요청은 충족될 필요가 있는 정도까지만 전파되면 되며, 성능은 특히 애플리케이션 제공자의 사이트 내에서 캐시를 사용함으로써 향상될 수 있다. 예를 들어, 중간 서버에서의 캐싱은 대부분의 요청을 충족시킬 수 있으며 따라서 소수의 요청만이 프리젠테이션 서버로 전파된다. 프리젠테이션 서버에서의 캐싱은 프리젠테이션 서버에 도달하는 요청의 일부를 처리할 수 있으며, 따라서 소수의 요청만이 애플리케이션 서버로 전파한다. 애플리케이션 서버가 일반적으로 트랜잭션에 관한 것이기 때문에, 애플리케이션 서버 내에서는 제한된 캐싱이 달성될 수 있다. 그렇지만, 전체적으로 보아 애플리케이션 제공자의 사이트 내에서 캐시를 적정히 사용함으로써 상당한 비용 절감이 달성될 수 있다.

캐싱의 이점이 주어지면, 전술한 서버에 대한 대규모 투자 및 다른 하드웨어 없이도 캐싱 기술을 사용함으로써 동적 웹 콘텐츠를 포함하는 웹 사이트의 응답성을 향상시킬 수 있다. 그렇지만, 캐시의 적합성에 있어서의 주요 문제는 웹 콘텐츠가 변하는 빈도이다. 일반적으로, 액세스율(access rate)이 증가하고 갱신율(update rate)이 감소할 때 캐시의 구현이 적합하다. 보다 구체적으로 말하면, 웹 콘텐츠의 캐싱은 사용자가 웹 사이트로부터 정적 콘텐츠를 검색하는 일이 빈번하고 웹 사이트에 저장될 데이터를 전송하는 일이 드문 경우에 적합하다. 그렇지만, 웹 사이트가 상당량의 동적 콘텐츠를 포함하는 경우, 그 웹 사이트는 본질적으로 그의 콘텐츠가 빈번하게 변하도록 구성되어 있다. 이 경우, 웹 사이트 내의 캐시의 갱신율은 상당히 증가하고, 그에 따라 웹 사이트의 콘텐츠를 캐싱하려는 시도의 이점이 실효를 거두지 못하게 된다.

기업 내에서 동적 콘텐츠를 효율적으로 캐싱하기 위한 여러가지 방안이 제안 및/또는 구현되어 왔다. 웹 애플리케이션 서버 내에 웹 콘텐츠를 캐싱하기 위한 이들 기술은 처리용량 및 응답 시간의 측면에서 성능을 상당히 개선하였다.

전자 상거래 웹 사이트 내에서 동적 콘텐츠를 캐싱하는 것의 상당한 이점을 달성한 후에, 사용자에 보다 가까이 콘텐츠를 캐싱하면 응답 시간 또는 대기 시간에 있어 훨씬 더 많은 이점을 발휘할 수 있기 때문에 네트워크 자체에 걸쳐 있는 협동 캐시(cooperative cache), 즉 소위 "분산 캐싱(distributed caching)"을 구현하면 유익할 것이다. 그렇지만, 분산 캐싱 방안에 있어서 널리 알려진 캐싱 문제점이 고려되어야만 할 것이다. 캐시의 무분별한 배치 및 구현은 비용 효율적이지 못한 방식으로 성능을 향상시킬 수 있다. 캐시의 효용성을 결정하는 중요한 문제으로는 캐시 크기, 캐시 히트 경로 길이(cache hit path length), 캐시 콘텐츠를 유지하는 데 요구되는 작업량, 및 데이터 요청자와 데이터의 위치 사이의 거리가 있다.

캐시 크기와 관련하여, 메모리 및 디스크 공간은 그 크기가 계속 증가하고 있지만, 결코 그 한계를 생각하지 않아도 될 정도로 결코 충분히 크지는 않다. 다시 말하면, 분산 캐싱 기술에서는 대량의 메모리 및 디스크 공간이 캐시에 이용가능하다고 가정해서는 안되며, 일반적으로 대형 캐시가 필요한 것보다 소형 캐시가 필요한 것을 더 선호한다. 게다가, 메모리 및 디스크의 대역폭의 향상 속도가 그 크기의 증가 속도보다 더 느리며, 점점 더 많은 양의 데이터를 캐싱하려는 시도도 종국에는 대역폭 문제로 한계에 부딪칠 것이다.

캐시 히트 경로 길이와 관련하여, 분산 캐싱 방안은 양호하게는 보다 용이하게 배포될 수 있는 경량급 런타임 애플리케이션(lightweight runtime application)을 포함하지만, 캐시 히트의 처리용량이 아주 크게 되도록 최소량의 처리로 캐시 히트를 결정한다. 원하는 형태의 분산 캐싱 애플리케이션은 또한 최종 사용자에 가깝게 데이터를 "캐싱"하는 다른 형태의 분산 애플리케이션과 혼동해서는 안된다. 즉, 애플리케이션 및 그와 관련된 데이터의 일부를 인터넷에 걸쳐 분산시키는 여러가지 방법 중 하나로부터 이득을 보는 다른 형태의 애플리케이션이 있다. 예를 들어, 전체 애플리케이션 및 그와 관련된 데이터베이스가 여러 위치에 복제될 수 있고, 이어서 배포 기업은 필요에 따라 그 데이터베이스를 동기화하여 애플리케이션을 유지한다. 다른 경우, 애플리케이션 및 그와 관련된 데이터의 판독 전용 디스플레이 부분이 보호 호스트 사이트(protected host site)에 비즈니스 로직(business logic)을 유지하면서 플러그-인, 자바스크립트

또는 유사한 메카니즘을 사용하여 클라이언트 기반 브라우저들에 분산될 수 있다.

캐시 콘텐츠를 보유하는 데 요구되는 작업량과 관련하여, 서비스 제공 기업 내에서의 캐싱은 처리용량 또는 비용, 즉 초당 처리되는 요청의 수 또는 요구되는 서버 하드웨어의 양을 증가시키는데, 그 이유는 요청마다 더 적은 작업이 행해지기 때문이다. 서비스 제공 기업 내에서, 캐시는 양호하게는 기업의 진입 지점에 보다 가까이 위치하게 되는데 그 이유는 그 기업 내의 임의의 시스템에 의한 처리량이 감소되고 그에 따라 개선을 향상시키기 때문이다. 예를 들어, 디스패처(dispatcher) 근방에서의 캐싱은 애플리케이션 서버 내에서의 캐싱보다 훨씬 더 효율적일 수 있다. 서비스 제공 기업 내에서의 캐싱은 대기 시간을 어느 정도 향상시키지만, 이것은 일반적으로 부차적인 것인데 왜냐하면 서비스 제공 기업 내에서의 대기 시간은 일반적으로 인터넷을 통한 대기 시간보다 훨씬 더 작기 때문이다. 서비스 제공 기업 외부에서의 안정된 분산 캐싱 기술을 위한 고려사항은 이것 및 다른 문제점과 얽혀 있다.

데이터 요청자와 데이터의 위치 사이의 거리와 관련하여, 인터넷에서의 사용자 가시 대기시간(user-visible latency)은 사용자와 콘텐츠 사이의 거리에 의해 좌우된다. 이 거리는 물리적 거리보다는 라우팅 홉(routing hop)의 수에 의해 측정된다. 콘텐츠가 인터넷 서비스 제공자(Internet Service Provider, ISP) 등의 인터넷의 "경계"에 캐싱될 때, 사용자 가시 대기시간은 상당히 감소된다. 멀티미디어 파일 등의 대형 콘텐츠의 경우, 대역폭 요건도 상당히 완화될 수 있다. 안정된 분산 캐싱 방안은 사용자에 가까이 데이터를 캐싱하도록 해야만 한다.

사용자가 지리적으로 분산되어 있기 때문에, 사용자에 가까이 콘텐츠를 캐싱하는 것은 콘텐츠가 인터넷에 걸쳐 있는 ISP 및 교환 센터(exchange point)에 있는 다수의 캐시에 복제되어야만 함을 의미한다. 일반적으로, 이것은 캐싱 메카니즘이 콘텐츠의 보안 및 콘텐츠가 갱신되는 방식, 즉 캐시 코히런시에 대해 행하는 제어를 줄일 수 있다. 서비스 제공 기업 내에서의 캐싱 메카니즘이 외견상 하나의 조직의 제어하에 있다면 서비스 제공 기업 내에서 캐시 코히런시를 비교적 용이하게 유지할 수 있다. 그렇지만, 서비스 제공 기업 내부 및 외부 모두에 캐시를 보유하 는 것은 캐시 코히런시를 보장하는 데 요구되는 작업의 양 및 그 작업의 어려움을 상당히 증가시킨다. 콘텐츠 배포 벤더(content distribution vendor), 예를 들면 CDN을 사용하여 캐시 공간을 임대하고 공중 인터넷보다 훨씬 더 제어된 네트워크 환경 내에 보유되는 경우 보안 및 코히런시 문제가 최소화될 수 있지만, 이러한 방안은 공중 인터넷을 통해 공개 표준을 사용함으로써 획득되는 이점의 일부를 무력화시키는 효과를 갖는다.

양호하게는, 분산 캐싱 기술은 기업 경계를 어느 정도 고려하여 구현가능하게 되어야 하지만, 인터넷에 걸쳐 조정된 방식으로도 구현가능하게 되어야 한다. 게다가, 캐시는 예를 들어 클라이언트 브라우저에서의 최종 사용자 근방, 서비스 제공 기업의 디스패처 근방, 웹 애플리케이션 서버 내 또는 이들 사이의 임의의 장소 등 필요하다고 결정될 수 있는 각종의 중요한 장소에 배포가능해야 한다. 게다가, 이 기술은 서로 다른 조직이 로컬 시스템 요건에 따라 분산 캐싱 규격의 서로 다른 구현을 구축할 수 있도록 규격에 부합되어야만 한다.

임의의 잠재적으로 안정된 분산 캐싱 방안에 관한 문제점은 웹 콘텐츠를 프래그먼트로서 저작 및 게시하는 경향에 의해 복잡하게 된다. 콘텐츠 엔티티(content entity)가 하나의 프래그먼트로 구성될 수 있지만, 콘텐츠의 일부분은 하나의 프래그먼트 내에 배치되고, 웹 페이지 또는 다른 문서 등의 보다 큰 콘텐츠 엔티티는 여러개의 프래그먼트로 구성되어 있다. 프래그먼트는 개별적으로 저장되고 이어서 필요할 때 보다 큰 콘텐츠 엔티티로 조립될 수 있다.

이들 런타임 이점은 프래그먼트의 유지 및 사용의 다른 관점에서의 복잡성에 의해 상쇄된다. 프래그먼트는 서로 다른 수명을 부여받을 수 있으며, 그에 따라 일관된 무효화 메카니즘을 필요로 한다. 게다가, 정적 콘텐츠가 효율적으로 캐싱될 수 있도록 프래그먼트가 콘텐츠의 정적인 부분과 콘텐츠의 동적인 부분을 분리시키는 데 사용될 수 있는 반면, 전술한 바와 같이 동적 콘텐츠의 캐싱과 관련된 문제에 직면하게 된다. 가장 중요한 것은 프래그먼트 조립이 기업 경계 내의 위치로 제한되어 왔다는 것이다.

따라서, 프래그먼트 및 다른 객체의 캐싱을 지원하는 안정된 분산 캐싱 기술이 있다면 유리할 것이다. 게다가, 필요하다고 생각되는 기업 경계에 대한 고려를 많이 하거나 거의 하지 않음으로써 네트워크에 걸쳐 있는 캐시 사이트에 프래그먼트 조립을 동일 장소에 배치하고, 그에 따라 서비스 제공 기업에 대한 처리 부하를 경감시키고 원할 경우 분산 컴퓨팅의 추가의 이점을 달성하면 특히 유익할 것이다. 게다가, 프래그먼트가 인터넷에 걸쳐 일의적으로 식별될 수 있도록, 즉 분산된 캐시가 코히런트하게 유지되도록 일관된 작명(naming) 기술이 있다면 유리할 것이다.

안정된 분산 캐싱 방안에 대한 추가의 고려 사항으로서, 어떤 가능한 방안에서는 기존의 프로그래밍 모델의 문제를 고려해야만 한다. 예를 들어, 기존의 웹 애플리케이션 서버의 프로그래밍 모델을 분산 캐싱 기술과 연계하여 동작하는 새로운 프로그래밍 모델로 대체하는 것을 필요로 하는 분산 캐싱 기술을 제안할 수 있다. 양호하게는, 분산 캐싱 기술의 구현은 여러가지 프로그래밍 모델을 수용하며, 그에 따라 프로그래밍 모델간의 어떤 편중도 피하게 된다.

분산 캐싱 기술의 구현의 결과 캐시 위치를 최소한 고려하여 인터넷에 걸쳐 표준 방식으로 경량급 프로세스에 의해 유지가능한 프래그먼트 캐시 크기가 감소되면 유리할 것이다. 게다가, 분산 캐싱 기술의 구현이 분산 캐싱 기술을 구현하지 않은 다른 시스템과 연동가능하도록 분산 캐싱 기술이 기존의 프로그래밍 모델 및 인터넷 표준과 부합되면 특히 유리할 것이다.

본 발명의 제1 태양에 따르면, 네트워크 내의 데이터 처리 시스템에서 객체를 처리하는 방법으로서, 컴퓨팅 장치에서 제1 메시지를 수신하는 단계, 상기 제1 메시지 내의 메시지 헤더가 상기 제1 메시지가 프래그먼트와 관련되어 있음을 나타내는 것으로 결정하는 단계, 및 상기 제1 메시지 헤더로부터 상기 프래그먼트가 캐싱가능한 지의 여부를 결정하는 단계를 포함하는 방법이 제공된다.

본 발명의 제2 태양에 따르면, 특허청구범위의 청구항 제11항의 객체 처리용 컴퓨팅 장치에 있어서, 제1 메시지로부터의 프래그먼트를 컴퓨팅 장치 내의 캐시 관리 유닛에 의해 보유된 캐시에 저장하는 수단을 더 포함하고, 캐시 관리 유닛은 컴퓨팅 장치가 클라이언트, 서버 또는 네트워크에 걸쳐 배치된 허브로서 작용하는지에 관계없이 프래그먼트 캐싱 동작을 지원하여 동등하게 동작하는 것인 데이터 시스템에서의 객체 처리용 컴퓨팅 장치가 제공된다.

본 발명의 제3 태양에 따르면, 네트워크 내의 데이터 처리 시스템에서 객체를 처리하는 데 사용하기 위한 컴퓨터 판독 가능한 기록 매체로 된 컴퓨터 프로그램 제품으로서, 이 컴퓨터 프로그램 제품은 제1 메시지가 프래그먼트에 관련되어 있음을 상기 제1 메시지 내의 메시지 헤더가 나타내는 것으로 결정하는 경우에 제1 메시지를 수신하는 명령어, 및 상기 제1 메시지 내의 메시지 헤더로부터 상기 제1 메시지가 프래그먼트와 관련되어 있음을 나타내는 것으로 결정하는 명령어를 포함하는 것인 컴퓨터 프로그램 제품이 제공된다.
양호하게는, 상기 제1 메시지는 상기 프래그먼트가 프래그먼트 비지원 캐시 관리 유닛에 캐싱가능하지 않음을 나타내는 표시와 상기 프래그먼트가 프래그먼트 지원 캐시 관리 유닛에 캐싱가능함을 나타내는 표시를 갖는다. 예를 들어, 상기 제1 메시지는 프래그먼트 비지원 캐시 관리 유닛에 대한 no-cache 디렉티브와 프래그먼트 지원 캐시 관리 유닛에 대한 프래그먼트 캐싱용 디렉티브를 갖는 HTTP Cache-Control 헤더를 갖는다.

양호하게는, 상기 제1 메시지 내의 메시지 헤더가 상기 제1 메시지의 메시지 보디 부분이 프래그먼트임을 나타내는 것으로도 결정된다.

양호하게는, 상기 제1 메시지로부터의 프래그먼트는 상기 컴퓨팅 장치 내의 캐시 관리 유닛에 의해 보유된 캐시에 저장되고, 상기 캐시 관리 유닛은 상기 컴퓨팅 장치가 클라이언트, 서버 또는 상기 네트워크에 걸쳐 배치된 허브로서 작용하는지에 관계없이 프래그먼트 캐싱 동작을 지원하여 동등하게 동작한다.

상기 컴퓨팅 장치에서 상기 프래그먼트에 대한 요청을 포함한 제2 메시지를 수신하면, 양호하게는 상기 캐시가 탐색되고 상기 프래그먼트가 상기 캐시로부터 검색된다. 이어서, 상기 프래그먼트는 상기 제2 메시지를 그의 목적지 주소로 전송하지 않고 상기 제2 메시지의 발신자에게 제3 메시지에 넣어 전송된다.

삭제

선택적으로, 상기 제2 메시지는 상기 제3 메시지를 반환하기에 앞서 상기 컴퓨팅 장치에서 페이지 조립 동작이 필요하지 않음을 나타내는 정보를 포함한다.

선택적으로, 상기 제2 메시지는 상기 제3 메시지가 프래그먼트 지원 캐시 관리 유닛을 갖는 제2 컴퓨팅 장치에 의해 수신될 것임을 나타내는 디렉티브를 갖는 메시지 헤더를 갖는다.

양호하게는, 페이지 조립 동작은 상기 제3 메시지를 전송하기에 앞서 상기 컴퓨팅 장치에서 수행된다.

양호하게는, 페이지 조립 동작은 조립된 프래그먼트를 형성하기 위해 상기 컴퓨팅 장치에서 수행된다. 예를 들어, 상기 프래그먼트가 그 다음 레벨 프래그먼트로의 링크를 포함하는 최상위 레벨 프래그먼트인지 여부가 결정된다. 이어서, 상기 프래그먼트가 그 다음 레벨 프래그먼트로의 링크를 포함하는 최상위 레벨 프래그먼트라고 결정한 것에 응답하여 상기 그 다음 레벨 프래그먼트가 검색된다. 마지막으로, 상기 최상위 레벨 프래그먼트와 상기 그 다음 레벨 프래그먼트는 조립된 프래그먼트로 합성된다.

선택적으로, 상기 그 다음 레벨 프래그먼트의 콘텐츠는 최상위 레벨 프래그먼트의 콘텐츠 내에 내장된다. 또한, 최상위 레벨 프래그먼트의 특성 값과 그 다음 레벨 프래그먼트의 특성 값으로부터 조립된 프래그먼트에 대한 특성 값이 생성될 수 있다. 또한, 조립된 프래그먼트에 대한 헤더 값 또는 디렉티브가 최상위 레벨 프래그먼트의 헤더 값 또는 디렉티브와 그 다음 레벨 프래그먼트의 헤더 값 또는 디렉티브로부터 계산될 수 있다.

양호하게는, 조립된 프래그먼트를 포함하는 제4 메시지가 생성되며, 이 제4 메시지는 HTTP(Hypertext Transport Protocol) 응답 메시지이다.

양호하게는, 최상위 레벨 프래그먼트와 그 다음 레벨 프래그먼트에 대한 최단 만료 시간이 결정되고, "Expires" 헤더가 제4 메시지에서 최단 만료 시간으로 설정된다.

다른 대안에서, 최상위 레벨 프래그먼트와 그 다음 레벨 프래그먼트에 대해 가장 작은 최대 수명이 결정되고, "Cache-Control: max-age" 디렉티브가 제4 메시지에서 가장 작은 최대 수명으로 설정된다.

선택적으로, 최상위 레벨 프래그먼트와 그 다음 레벨 프래그먼트에 대해 콘텐츠 길이 값의 합이 계산되고, "Content-Length" 헤더가 제4 메시지에서 콘텐츠 길이 값의 합으로 설정된다.

선택적으로, 최상위 레벨 프래그먼트와 그 다음 레벨 프래그먼트에 대해 마지막 수정 시간이 결정되고, "Last-Modified" 헤더가 제4 메시지에서 마지막 수정 시간으로 설정된다.

선택적으로, 상기 제1 메시지로부터 한 세트의 종속성 식별자가 검색되고, 종속성 식별자는 상기 프래그먼트를 발신한 서버에 의해 생성되며, 상기 프래그먼트에 대한 소스 식별자와 연관하여 상기 종속성 식별자 세트가 저장된다. 이 경우, 선택적으로 무효화 요청 메시지가 수신되고 그로부터 종속성 식별자가 검색될 수 있다. 이것에 의해 종속성 식별자와 연관된 한 세트의 프래그먼트가 결정될 수 있고, 그 결과 결정된 프래그먼트 세트가 캐시로부터 제거될 수 있다.

양호하게는, 한 세트의 프래그먼트 캐싱 규칙이 제1 메시지로부터 결정될 수 있으며, 프래그먼트에 대한 캐시 식별자는 프래그먼트 캐싱 규칙에 따라 생성된다. 이 경우, 예를 들어, 프래그먼트는 캐시 식별자를 사용하여 일의적으로 식별될 수 있다. 게다가, 저장 단계는 프래그먼트에 대한 생성된 캐시 식별자를 사용하여 수행될 수 있다.

선택적으로, 프래그먼트와 연관된 URI(Uniform Resource Identifier)의 적어도 경로 부분이 베이스 캐시 식별자를 형성하기 위해 획득되고, 프래그먼트 캐싱 규칙이 프래그먼트에 대한 캐시 식별자를 형성하기 위해 베이스 캐시 식별자에 적용되며, 프래그먼트 캐싱 규칙은 베이스 캐시 식별자에 첨부되는 이름-값 쌍을 획득하는 데 사용되는 한 세트의 질의 파라미터 및/또는 쿠키 이름을 포함한다.

본 발명의 제4 태양에 따르면, 네트워크 내의 데이터 처리 시스템에서 객체를 처리하는 방법으로서, 프래그먼트에 대한 소스 식별자를 포함하는 요청 메시지를 서버에서 수신하는 단계, 상기 프래그먼트를 포함하는 응답 메시지를 생성하는 단계, 및 상기 요청 메시지가 프래그먼트와 관련되어 있음을, 그리고 상기 프래그먼트가 캐싱가능한 지의 여부를 나타내는 메시지 헤더를 상기 응답 메시지에 삽입하는 단계를 더 포함하는 방법이 제공된다.

본 발명의 제5 태양에 따르면, 네트워크 내의 데이터 처리 시스템에서 객체를 처리하는 장치로서, 프래그먼트에 대한 소스 식별자를 포함하는 요청 메시지를 서버에서 수신하는 수단, 상기 프래그먼트를 포함하는 응답 메시지를 생성하는 수단, 및 상기 요청 메시지가 프래그먼트와 관련되어 있음을, 그리고 상기 프래그먼트가 캐싱가능한 지의 여부를 나타내는 메시지 헤더를 상기 응답 메시지에 삽입하는 수단을 포함하는 장치가 제공된다.

본 발명의 제6 태양에 따르면, 네트워크 내의 데이터 처리 시스템에서 객체를 처리하는 데 사용하기 위한 컴퓨터 판독가능 매체로 된 컴퓨터 프로그램 제품으로서, 프래그먼트에 대한 소스 식별자를 포함하는 요청 메시지를 서버에서 수신하는 명령어, 상기 프래그먼트를 포함하는 응답 메시지를 생성하는 명령어, 및 상기 제1 메시지가 프래그먼트와 관련되어 있음을, 그리고 상기 프래그먼트가 캐싱가능한 지의 여부를 나타내는 메시지 헤더를 상기 응답 메시지에 삽입하는 명령어를 포함하는 컴퓨터 프로그램 제품이 제공된다.

양호하게는, 응답 메시지의 메시지 보디 부분이 프래그먼트임을 나타내는 메시지 헤더가 응답 메시지에 삽입된다.

삭제

양호하게는, 프래그먼트가 프래그먼트 비지원 캐시 관리 유닛에 대해서는 캐싱가능하지 않음을 나타내고 프래그먼트가 프래그먼트 지원 캐시 관리 유닛에 대해서는 캐싱가능함을 나타내는 메시지 헤더가 응답 메시지에 삽입된다.

본 발명의 제7 태양에 따르면, 네트워크 상으로 전송되는 메시지를 정의함에 있어 컴퓨팅 장치에 의해 사용되는 데이터 구조로서, 상기 메시지가 요청 메시지 또는 응답 메시지임을 나타내는 표시자, 및 상기 메시지가 프래그먼트 지원 캐시 관리 유닛에 의해 처리될 것이라는 것을 나타내는 키워드 및 상기 메시지가 처리되는 방식을 나타내는 하나 이상의 프래그먼트 헤더 디렉티브를 포함하는 프래그먼트 헤더를 포함하는 데이터 구조가 제공된다.

양호하게는, 프래그먼트 지원 캐시 관리 유닛은 컴퓨팅 장치 내에 위치하며, 이 컴퓨팅 장치가 클라이언트, 서버 또는 네트워크에 걸쳐 배치된 허브로서 작용하는지에 관계없이 프래그먼트 캐싱 동작을 지원하여 동등하게 동작한다.

양호하게는, 데이터 구조는 또한 요청 메시지를 처리하는 컴퓨팅 장치가 프래그먼트 지원 캐시 관리 유닛을 가짐을 나타내기 위해 요청 메시지에 포함시키기 위한 프래그먼트 헤더 디렉티브를 갖는다.

양호하게는, 데이터 구조는 응답 메시지 내의 프래그먼트를 프래그먼트 지원 캐시 관리 유닛에 의해 보유된 캐시로부터 제거하기 위해 원서버에 의해 사용되는 한 세트의 종속성 식별자를 나타내기 위해 응답 메시지에 포함시키기 위한 프래그먼트 헤더 디렉티브를 갖는다.

양호하게는, 데이터 구조는 상기 응답 메시지 내의 프래그먼트를 일의적으로 식별하는 캐시 식별자를 형성하는 데 사용되는 한 세트의 프래그먼트 캐싱 규칙을 나타내기 위해 응답 메시지 내에 포함시키기 위한 프래그먼트 헤더 디렉티브를 갖는다.

선택적으로, 요청 메시지 또는 응답 메시지는 HTTP(Hypertext Transport Protocol) 요청 메시지 또는 HTTP 응답 메시지이다.

본 발명의 제8 태양에 따르면, 콘텐츠 객체를 정의함에 있어서 컴퓨팅 장치에 의해 사용되는 데이터 구조로서, 마크업 언어 엘리먼트에 대한 한 세트의 구분자, 마크업 언어 엘리먼트가 프래그먼트로의 링크임을 나타내는 키워드, 및 프래그먼트에 대한 소스 식별자를 포함하며, 소스 식별자는 프래그먼트를 검색하기 위해 프래그먼트 지원 캐시 관리 유닛에 의해 사용되는 것인 데이터 구조가 제공된다.

양호하게는, 프래그먼트 지원 캐시 관리 유닛은 컴퓨팅 장치 내에 위치하며, 이 컴퓨팅 장치가 클라이언트, 서버 또는 네트워크에 걸쳐 위치한 허브로서 동작하는지에 관계없이 프래그먼트 캐싱 동작을 지원하여 동등하게 동작한다.

양호하게는, 데이터 구조는 프래그먼트에 대한 대체 소스 식별자를 가지며, 대체 소스 식별자는 프래그먼트를 검색하기 위해 프래그먼트 지원 캐시 관리 유닛 에 의해 사용될 수 있다.

양호하게는, 데이터 구조는 소스 식별자에 첨부되는 한 세트의 질의 파라미터를 갖는다.

양호하게는, 마크업 언어는 SGML(Standard Generalized Markup Language)이다. 양호하게는, 마크업 언어 엘리먼트는 HTML(Hypertext Markup Language)에 부합된다.

프래그먼트 캐싱을 위한 방법, 시스템, 장치 및 컴퓨터 프로그램 제품이 제공된다. 캐시 관리 유닛을 포함하는 컴퓨팅 장치에서 메시지가 수신된 후에, 메시지의 메시지 보디 내의 프래그먼트가 캐싱된다. 캐시 관리 유닛에서 차후에 프래그먼트에 대한 요청이 있으면 캐시 히트가 된다. 캐시 관리 유닛은 컴퓨팅 장치가 클라이언트, 서버, 또는 네트워크에 걸쳐 위치한 허브로서 동작하는지에 관계없이 동등하게 동작한다. 다시 말하면, 프래그먼트 캐싱 기술은 네트워크에 걸쳐 균일하다.

FRAGMENT 헤더는 HTTP 등의 네트워크 프로토콜 내에서 사용되도록 정의되어 있으며, 헤더는 프래그먼트의 처리 및 캐싱과 관련된 여러가지 목적을 위해 메타데이터를 프래그먼트와 연관시킨다. 캐시 ID 규칙은 원서버로부터의 프래그먼트를 수반하며, 캐시 ID 규칙은 동적 콘텐츠가 원서버로부터 먼 곳에 캐싱될 수 있도록 프래그먼트에 대한 고유의 캐시 ID를 형성하는 방법을 기술한다. 캐시 ID는 프래그먼트에 대한 URI(Uniform Resource Identifier)에 기초할 수 있지만, 캐시 ID는 또한 질의 파라미터 및/또는 쿠키에도 기초할 수 있다. 서버가 프래그먼트를 캐시 로부터 제거하는 무효화 동작을 개시할 수 있도록 프래그먼트에 대한 캐시 ID 또는 URI와 다를 수 있는 종속성 ID가 프래그먼트와 연관될 수 있다. FRAGMENTLINK 태그는 페이지 조립 또는 페이지 렌더링 동안 삽입될 포함된 프래그먼트에 대한 페이지 내의 위치를 지정하는 데 사용된다.

도 1a는 본 발명의 양호한 실시예가 구현될 수 있는 전형적인 분산 데이터 처리 시스템을 나타낸 도면이고,

도 1b는 본 발명의 양호한 실시예가 구현될 수 있는 데이터 처리 시스템에서 사용될 수 있는 전형적인 컴퓨터 구조를 나타낸 도면이며,

도 1c는 분산 데이터 처리 시스템 전반에 걸쳐 캐시가 구현되어 있는 전형적인 분산 데이터 처리 시스템을 나타낸 도면이고,

도 2는 여러 프래그먼트로 이루어진 전형적인 웹 페이지를 나타낸 도면이며,

도 3은 본 발명의 양호한 실시예에 따른 FRAGMENTLINK 태그의 공식적인 SGML(Standard Generalized Markup Language) 정의를 나타낸 도면이고,

도 4는 본 발명의 양호한 실시예에 따른 FRAGMENT 헤더의 공식적인 정의를 나타낸 도면이며,

도 5a 내지 도 5g는 객체 검색 경로를 따라 있는 한 세트의 프래그먼트 지원 에이전트(fragment-supporting agent) 및 프래그먼트 비지원 에이전트(non-fragment-supporting agent)를 나타낸 도면이고,

도 6a는 컴퓨팅 장치 내의 프래그먼트 지원 캐시용 캐시 관리 유닛을 나타낸 도면이며,

도 6b는 프래그먼트를 포함하는 응답 메시지를 처리할 때 프래그먼트 지원 캐시 관리 유닛에 의해 사용될 수 있는 프로세스를 나타낸 플로우차트이고,

도 6c는 메시지 보디가 프래그먼트 객체를 포함하는지 여부를 결정하는 양호한 방법을 나타낸 플로우차트 단계이며,

도 6d는 프래그먼트 객체가 캐싱가능한지 여부를 결정하는 보다 구체적인 방법을 나타낸 플로우차트 단계이고,

도 6e는 프래그먼트 객체가 캐싱가능한지 여부를 결정하는 양호한 방법을 나타낸 플로우차트 단계이고,

도 6f는 프래그먼트 객체가 특정의 컴퓨팅 장치에 캐싱되어야만 하는지 여부를 결정하는 방법을 나타낸 플로우차트이며,

도 6g는 다운스트림 장치가 프래그먼트 지원 캐시를 갖는지 여부를 결정하는 양호한 방법을 나타낸 플로우차트 단계이고,

도 6h는 현재 처리되고 있는 중인 프래그먼트 객체가 목적지 사용자/클라이언트 장치에 가장 가까운 프래그먼트 지원 캐시에만 캐싱되어야 하는지 여부를 결정하는 보다 구체적인 방법을 나타낸 플로우차트 단계이며,

도 6i는 현재 처리되고 있는 중인 프래그먼트 객체가 목적지 사용자/클라이언트 장치에 가장 가까운 프래그먼트 지원 캐시에만 캐싱되어야 하는지 여부를 결정하는 양호한 방법을 나타낸 플로우차트 단계이고,

도 6j는 현재의 컴퓨팅 장치로부터 응답 메시지를 반환하기에 앞서 페이지 조립이 요구되는지 여부를 결정하는 방법을 나타낸 플로우차트이며,

도 6k는 현재 처리되고 있는 중인 프래그먼트 객체가 다른 프래그먼트로의 링크를 갖는지 여부를 결정하는 보다 구체적인 방법을 나타낸 플로우차트 단계이고,

도 6l은 현재 처리되고 있는 중인 프래그먼트 객체가 다른 프래그먼트로의 링크를 갖는지 여부를 결정하는 대체 방법을 나타낸 플로우차트 단계이며,

도 6m은 페이지 조립을 수행하는 프로세스를 나타낸 플로우차트이고,

도 6n은 하나의 프래그먼트 링크를 다수의 프래그먼트 링크로 선택적으로 확장하는 프로세스를 나타낸 플로우차트이며,

도 6o는 응답 메시지로부터의 현재의 프래그먼트 내의 프래그먼트 링크가 다수의 프래그먼트 링크로 확장되어야만 하는지 여부를 결정하는 양호한 방법을 나타낸 플로우차트 단계이고,

도 6p는 프래그먼트 링크와 관련된 정보에 따라 하나의 프래그먼트 링크를 다수의 프래그먼트 링크로 확장하는 프로세스를 나타낸 플로우차트이며,

도 6q는 프래그먼트의 소스 식별자를 사용하여 프래그먼트를 검색하는 프로세스를 나타낸 플로우차트이고,

도 6r은 프래그먼트가 프래그먼트 지원 캐시 관리 유닛 내에 캐싱될 때 수행되는 처리의 일부를 나타낸 플로우차트이며,

도 6s는 프래그먼트가 캐시 관리 유닛을 포함하는 컴퓨팅 장치에 캐싱되는 경우 그 프래그먼트를 획득하기 위해 프래그먼트 지원 캐시 관리 유닛에 의해 사용 될 수 있는 프로세스를 나타낸 플로우차트이고,

도 6t는 복수의 프래그먼트와 관련된 헤더 값과 특성 값을 합성하는 프로세스를 나타낸 플로우차트이며,

도 6u는 헤더 타입 및 특성 값에 대한 일련의 합성 함수를 나타내는 한 세트의 단계를 나타낸 플로우차트이고,

도 6v는 요청 메시지를 처리할 때 프래그먼트 지원 캐시 관리 유닛에 의해 사용될 수 있는 프로세스를 나타낸 플로우차트이며,

도 6w는 본 발명의 양호한 실시예의 구현에 따라 무효화 메시지를 처리할 때 프래그먼트 지원 캐시 관리 유닛에 의해 사용될 수 있는 프로세스를 나타낸 플로우차트이고,

도 7a는 일부 캐시가 프래그먼트 조립을 언제 수행하는 지를 설명하기 위해 웹 애플리케이션 서버와 클라이언트 사이에서의 데이터 흐름의 일부를 나타낸 블록도이며,

도 7b는 한 세트의 장치가 최종 사용자 또는 클라이언트 장치에 가장 가까운 캐시 내의 캐시 프래그먼트에 어떻게 디렉션될 수 있는지를 설명하기 위해 웹 애플리케이션 서버와 클라이언트 사이의 데이터 흐름의 일부를 나타낸 블록도이고,

도 8a 내지 도 8d는 역할별 또는 카테고리별 동적 콘텐츠의 캐싱이 본 발명의 양호한 실시예를 사용하여 달성될 수 있음을 설명하기 위해 클라이언트, 프래그먼트 지원 중간 캐시 또는 서버에서 행해지는 처리 단계들의 일부를 나타낸 데이터 흐름도이며,

도 9a는 다수의 프래그먼트를 단 하나의 요청 메시지 내에 지정하고 이어서 이를 처리할 수 있는 프로세스를 나타낸 플로우차트이고,

도 9b는 단 하나의 요청 메시지를 중간 캐시 관리 유닛에서 수신하고 이어서 이를 처리할 수 있는 프로세스를 나타낸 플로우차트이며,

도 9c는 웹 애플리케이션 서버에서 다수의 프래그먼트에 대한 배치 요청 메시지를 처리하는 프로세스를 나타낸 플로우차트이고,

도 10a 내지 도 10d는 본 발명의 양호한 실시예에 따라 달성될 수 있는 유익한 캐시 크기 감축을 나타낸 한 세트의 일례를 나타낸 도면이며,

도 11a 내지 도 11h는 본 발명의 양호한 실시예의 기술이 프래그먼트를 저장 및 처리하기 위한 고유의 캐시 식별자를 구축 및 사용하는 방식을 설명하는 일련의 도면이다.

이제부터 첨부 도면에 도시되어 있는 바와 같은 본 발명의 양호한 실시예를 참조하여 단지 일례로서 본 발명에 대해 설명할 것이다.

본 발명은 분산 프래그먼트 캐싱 기술에 관한 것이다. 일반적으로, 본 발명의 양호한 실시예를 포함하거나 그에 관련된 것일 수 있는 장치는 광범위한 데이터 처리 기술을 포함한다. 따라서, 배경 기술로서, 본 발명의 양호한 실시예에 대해 보다 상세히 기술하기에 앞서 분산 데이터 처리 시스템 내의 하드웨어 및 소프트웨어 구성요소의 전형적인 구성에 대해 기술한다.

이제부터 도면을 참조하면, 도 1a는 데이터 처리 시스템들의 전형적인 네트 워크를 나타낸 것으로서, 그 각 시스템은 본 발명의 양호한 실시예의 어떤 측면을 구현할 수 있다. 분산 데이터 처리 시스템(100)은 네트워크(101)를 포함하며, 이 네트워크는 분산 데이터 처리 시스템(100) 내의 서로 연결되어 있는 여러가지 장치 및 컴퓨터들 간의 통신 링크를 제공하는 데 사용될 수 있는 매체이다. 네트워크(101)는 전선 또는 광 섬유 케이블 등의 영구적 연결 또는 전화 또는 무선 통신을 통해 이루어지는 일시적 연결을 포함할 수 있다. 도시된 일례에서, 서버(102)와 서버(103)는 저장 장치(104)와 함께 네트워크(101)에 연결되어 있다. 게다가, 클라이언트(105-107)도 네트워크(101)에 연결되어 있다. 클라이언트(105-107) 및 서버(102-103)는 메인 프레임, 퍼스널 컴퓨터, 개인 휴대 단말기(PDA) 등과 같은 각종의 컴퓨팅 장치로 대표될 수 있다. 분산 데이터 처리 시스템(100)은 도시되지 않은 부가의 서버, 클라이언트, 라우터, 다른 장치 및 P2P(peer-to-peer, 동등 계층간) 구조를 포함할 수 있다. 도 1a에 도시된 분산 데이터 처리 시스템은 각종의 P2P 서브넷 및 P2P 서비스를 완벽하게 지원할 수 있는 것으로 보기로 한다는 점에 유의한다.

도시된 일례에서, 분산 데이터 처리 시스템(100)은 서로 통신하기 위해 LDAP(Lightweight Directory Access Protocol, 경량 디렉토리 액세스 프로토콜), TCP/IP(Transport Control Protocol/Internet Protocol, 전송 제어 프로토콜/인터넷 프로토콜), HTTP(Hypertext Transport Protocol, 하이퍼텍스트 전송 프로토콜), WAP(Wireless Application Protocol, 무선 애플리케이션 프로토콜) 등과 같은 여러가지 프로토콜을 사용하는 네트워크 및 게이트웨이의 글로벌 집합체를 나타내는 네 트워크(101)를 갖는 인터넷을 포함할 수 있다. 물론, 분산 데이터 처리 시스템(100)은 예를 들면 인트라넷, LAN(local area network, 근거리 통신망), 무선 LAN, 또는 WAN(wide area network, 광역 통신망) 등의 다수의 서로 다른 유형의 네트워크도 포함할 수 있다. 예를 들어, 서버(102)는 클라이언트(109) 및 무선 통신 링크를 구현하는 네트워크(110)를 직접 지원한다. 네트워크 지원 전화(111)는 무선 링크(112)를 통해 네트워크(110)에 연결되고, PDA(113)는 무선 링크(114)를 통해 네트워크(110)에 연결된다. 전화(111) 및 PDA(113)는 또한 소위 PAN(Personal Area Network, 개인 통신망) 또는 개인 애드-혹 네트워크(personal ad-hoc network)를 구축하기 위해 블루투스

무선 기술 등의 적절한 기술을 사용하여 무선 링크(115)를 통해 서로 간에 직접 데이터를 전송할 수 있다. 이와 유사한 방식으로, PDA(113)는 무선 통신 링크(116)를 통해 PDA(107)에 데이터를 전송할 수 있다.

본 발명의 양호한 실시예는 각종의 하드웨어 플랫폼 상에 구현될 수 있다. 도 1a는 이기종 컴퓨팅 환경의 일례이고 본 발명에 대한 구조상 제한이 아니다. 유의할 점은 이후의 일례들이 서버형 기능과 비교할 때의 클라이언트형 기능을 구체적으로 언급하고 있다는 것이다. 그렇지만, 잘 알려진 바와 같이, 일부 컴퓨팅 장치는 허브 또는 컴퓨팅 장치, 즉 P2P 네트워크 내의 피어(peer) 등 클라이언트형 기능과 서버형 기능 모두를 나타낸다. 본 발명의 양호한 실시예는 필요에 따라 클라이언트, 서버, 피어 또는 허브 상에 구현될 수 있다.

이제, 도 1b를 참조하면, 동 도면은 본 발명의 양호한 실시예가 구현될 수 있는 도 1a에 도시한 것과 같은 데이터 처리 시스템의 전형적인 컴퓨터 구조를 나타낸 것이다. 데이터 처리 시스템(120)은 내부 시스템 버스(123)에 연결된 하나 이상의 CPU(중앙 처리 장치)(122)를 포함하며, 이 내부 시스템 버스(123)는 RAM(random access memory, 랜덤 액세스 메모리)(124), ROM(read only memory, 판독 전용 메모리)(126), 및 프린터(130), 디스크 장치(132) 또는 오디오 출력 시스템과 같은 도시되지 않은 다른 장치 등의 각종의 I/O 장치를 지원하는 입력/출력 어댑터(128)를 상호 연결시킨다. 시스템 버스(123)는 또한 통신 링크(136)로의 접속을 제공하는 통신 어댑터(134)도 연결시켜준다. 사용자 인터페이스 어댑터(148)는 키보드(140), 마우스(142), 또는 터치 스크린, 스타일러스 또는 마이크와 같은 도시되지 않은 다른 장치 등의 여러가지 사용자 장치를 연결시켜 준다. 디스플레이 어댑터(144)는 시스템 버스(123)를 디스플레이(146)에 연결시켜준다.

당업자라면 도 1b의 하드웨어가 시스템 구현에 따라 변할 수 있다는 것을 잘 알 것이다. 예를 들어, 시스템은 인텔

펜티엄

기반 프로세서 및 디지털 신호 처리기(DSP) 등의 하나 이상의 프로세서와, 휘발성 및 비휘발성 메모리를 한 종류 이상 구비할 수 있다. 도 1b에 도시된 하드웨어에 부가하여 또는 그 대신에 다른 주변 장치가 사용될 수 있다. 다시 말하면, 당업자라면 웹 지원 또는 네트워크 지원 전화 및 전기능을 갖춘(fully featured) 데스크톱 워크스테이션 내에 어떤 유사한 구성요소 또는 구조가 있을 것으로 기대할 것이다. 도시된 일례는 본 발명의 양호한 실시예에 대한 구조상 제한을 암시하고자 함이 아니다.

본 발명의 양호한 실시예는 각종의 하드웨어 플랫폼 상에 구현될 수 있는 것 이외에 각종의 소프트웨어 환경에서도 구현될 수 있다. 각 데이터 처리 시스템 내에서의 프로그램 실행을 제어하는 데 일반적인 운영 체제가 사용될 수 있다. 예를 들어, 한 장치는 리눅스

운영 체제를 실행시킬 수 있는 반면, 다른 장치는 간단한 자바

런타임 환경을 갖는다. 대표적인 컴퓨터 플랫폼은 그래픽 파일, 워드 프로세싱 파일, XML(Extensible Markup Language, 확장성 마크업 언어), HTML(Hypertext Markup Language, 하이퍼텍스트 마크업 언어), HDML(Handheld Device Markup Language, 휴대 기기 마크업 언어), WML(Wireless Markup Language, 무선 마크업 언어) 등의 각종의 포맷 및 인코딩으로 된 파일, 문서, 객체 도는 다른 데이터 항목에 액세스하는 공지의 소프트웨어 애플리케이션인 브라우저를 포함할 수 있다. 이들 객체는 일반적으로 URI(Uniform Resource Identifier)를 사용하여 어드레싱된다. URI 세트는 URL(Uniform Resource Locator)과 URN(Uniform Resource Name)을 포함한다.

이제, 도 1c를 참조하면, 동 도면은 도 1a에 도시한 것과 같은 전형적인 분산 데이터 처리 시스템을 도시한 것으로서, 분산 데이터 처리 시스템 전반에 걸쳐 캐시가 구현되어 있다. 분산 데이터 처리 시스템(150)은 콘텐츠에 대한 요청을 발생하는 요청측 엔티티(requesting entity)(152)를 포함한다. 요청측 엔티티(152)는 다양한 개인이나 기관 고객들, 또는 여러가지 목적으로 요청된 콘텐츠를 사용하는 기업에 서비스하는 ISP일 수 있다. 데이터, 예를 들면 요청이 요청측 엔티티(사용측 엔티티)로부터 응답측 엔티티[서비스 제공 엔티티, 예를 들면 원서버(origin server)]쪽으로 이동될 때, 그 데이터는 "업스트림으로" 이동한다고 말한다. 데이터, 예를 들면 응답이 응답측 엔티티로부터 수신측 엔티티로 이동할 때, 그 데이터는 "다운스트림으로" 이동한다고 말한다.

클라이언트 브라우저(154)로부터의 요청은 디스패처(dispatcher)(156)에 의해 라우팅되는데, 이 디스패처는 인터넷 교환 센터(Internet exchange point)(160)에서 그 요청들을 인터넷을 통해 포워딩하기에 앞서 그 요청들을 만족시키려고 시도하여 한 세트의 중간 서버(158)를 통해 그 요청들을 균일하게 분산시킨다. 각 브라우저(154)는 로컬 캐시(local cache)를 보유할 수 있으며, 각 서버(158)는 포워드 프록시 캐싱(forward proxy caching) 메카니즘을 지원한다. 인터넷 교환 센터(160)는 또한 중간 서버(162, 164)를 포함하며, 그 각각은 캐시를 포함할 수 있다. 브라우저(154)에 또는 중간 서버(158, 160, 162, 164)에 캐시를 구현하기 위한 여러가지 고려사항들에는 응답 시간의 향상 및/또는 대역폭의 감축이 포함된다.

그 다음에 요청들은 인터넷 교환 센터(160)로부터 서비스 제공 기업(168) 내의 디스패처(166)로 라우팅된다. 디스패처(166)는 착신 요청들을 디스패처(172)로 포워딩하기에 앞서 그 요청들을 충족시키려고 시도하는 중간 서버(170)들을 통해 그 요청들을 균일하게 분산시킨다. 각 중간 서버(170)는 리버스 프록시 캐싱(reverse proxy caching) 메카니즘을 지원한다. 성취되지 않은 요청들은 디스패처(172)에 의해 웹 애플리케이션 서버(174)들 전반에 걸쳐 균일하게 분산되고, 이 웹 애플리케이션 서버가 데이터베이스 서비스 또는 데이터베이스(176)에 액세스하는 다른 애플리케이션과 연계하여 요청을 궁극적으로 충족시킬 수 있다. 중간 서버(170)에 또는 웹 애플리케이션 서버(174)에 캐시를 구현하기 위한 여러가지 고 려사항들에는 처리용량(throughput)의 향상 및/또는 비용 절감이 포함된다.

응답들은 반대 방향으로 서비스 제공 기업으로부터 클라이언트 장치로 라우팅된다. 유의할 점은 유사한 중간 서버들이 사용측 기업 내에, 인터넷 전반에 걸쳐, 또는 서비스 제공 기업 내에 배치될 수 있다는 것이다. 또한, 유의할 점은 요청이 통과하는 클라이언트로부터 먼쪽에 있는 각각의 연속한 스테이지가 인식되는 응답 시간을 증가시킨다는 것이다.

본 발명의 양호한 실시예는 전술한 바와 같이 각종의 하드웨어 및 소프트웨어 플랫폼 상에 구현될 수 있다. 그럼에도, 보다 구체적으로 말하면, 본 발명의 양호한 실시예는 분산 프래그먼트 캐싱 기술에 관한 것이다. 그렇지만, 본 발명의 양호한 실시예에 대해 보다 상세하게 설명하기 전에, 일반적인 정적 및 동적 웹 콘텐츠에 관한 약간의 배경 정보를 제공한다.

정적 텍스트 및 그래픽 콘텐츠를 포함하는 웹 페이지의 포맷은 일반적으로 HTML 등의 마크업 언어(markup language)를 사용하여 지정된다. 이 마크업은 페이지가 인터넷 브라우저에 의해 판독될 때 단어 또는 이미지의 표시를 제어하는 특수 코드 또는 태그로 이루어져 있다. 그렇지만, 자바 서버 페이지(Java Server Page, JSP) 및 서블릿(servlet)은 동적 콘텐츠를 포함하는 웹 페이지에 더 적합하다.

기본적으로, JSP는 그 페이지를 포함하는 응답을 생성하기 위해 그 페이지에 대한 요청을 어떻게 처리해야 할지를 기술하는 내장 명령어를 갖는 마크업 언어 문서이다. 이 기술(description)은 정적 템플릿 콘텐츠와 하나의 문서 내에 자바 코드로서 구현된 동적 효과를 혼합시킨다. JSP를 사용하여 자바 코드를 그 페이지 내에 서버측 스크립트릿(scriptlet)으로서 인라인(inline)시킬 수도 있다. 즉, 자바 태그는 웹 페이지 상에 지정되고 웹 페이지를 요청했던 사용자에게 그를 전송하기 전에 그 웹 페이지를 수정하기 위해 웹 서버 상에서 실행된다. 이 방법은 프로그래밍 로직(programming logic)이 비교적 중요하지 않을 때 적절하다. 마크업 언어 문서 내에 사소한 정도 이상의 프로그래밍 로직을 갖게 되면 JSP의 이점인 문서의 표현(presentation)을 그 문서와 관련된 비즈니스 로직(business logic)과 분리시키는 것을 달성하지 못하게 된다. 마크업 언어 문서 내에 과도한 정도의 코드를 직접 인라인하는 것을 피하기 위해, JSP에서는 비즈니스 로직을 분리시키는 기능을 간단한 JSP 태그를 사용하여 런타임시에 액세스될 수 있는 자바빈(JavaBean)에 집어넣을 수 있다.

보다 구체적으로 설명하면, JSP는 자바 프로그래밍 언어로 작성된 마크업 형태의 태그와 스트립트릿을 사용하여 그 페이지에 대한 콘텐츠의 일부 또는 그 전부를 생성하는 로직을 캡슐화한다. 애플리케이션 로직은 그 페이지가 이들 태그 및 스크립트릿을 사용하여 액세스하는 자바빈 컴포넌트 등의 서버 기반 자원에 존재할 수 있다. 마크업 언어 태그를 사용하면 도구, 예를 들면 HTML 페이지 빌더(page builder)/에디터(editor)에 의해 조작될 수 있는 편리한 형식으로 유용한 기능의 마크업 언어 문서 내에서의 캡슐화가 가능하게 된다. 비즈니스 로직을 표현으로부터 분리함으로써, 재사용가능한 컴포넌트 기반 설계가 지원된다. JSP는 웹 페이지 저작자가 동적 콘텐츠 모듈을 정적 HTML 템플릿에 삽입시킬 수 있게 해주며, 따라서 웹 콘텐츠의 생성을 많이 단순화시켜준다. JSP는 썬사의 자바 엔터프라이즈판(J2EE) 프로그래밍 모델의 필수적인 부분이다.

유의할 점은 이하에서 논의되는 본 발명의 양호한 실시예의 일례들은 JSP를 사용할 수 있다는 것이다. 그렇지만, 다른 유형의 서버 페이지, 예를 들면 마이크로소프트사의 액티브 서버 페이지(ASP)도 사용될 수 있다.

제품 디스플레이 JSP는 제품에 관한 데이터를 제시한다. 특정 제품, 예를 들면 렌치에 대한 요청은 질의 파라미터로서의 제품 id 뿐만 아니라 그 JSP도 식별하게 된다. 제품 id 파라미터를 갖는 그 JSP의 실행은 HTML의 페이지를 출력한다. 그 제품에 대한 기초 데이터가 변할 때, 예를 들면 렌치 가격이 상승할 때, 그 페이지는 무효화되어야만 한다. 이를 위해, 데이터를 표현하는 종속성 id를 그 페이지와 관련시킴으로써 페이지와 데이터 사이에 종속성(dependency)이 확립되어야만 한다.

입도(granularity)는 효율적인 캐싱 전략에 중요한 웹 페이지의 특성이다. 웹 페이지의 콘텐츠는 몇가지 컴포넌트로 이루어져 있으며, 그의 일부는 자주 변할 수 있는 반면 다른 것들은 비교적 정적이다. 웹 페이지의 입도는 콘텐츠의 일부분인 "프래그먼트"의 관점에서 기술될 수 있다. 프래그먼트는 JSP 파일에 대한 HTTP 요청의 수행을 포함한 여러가지 방식으로 생성될 수 있다. 상기 일례에서, 제품 표시 페이지는 하나의 프래그먼트 페이지이다.

이제 도 2를 참조하면, 동 블록도는 프래그먼트로 이루어진 웹 페이지를 설명한 것이다. 이 일례는 일부 프래그먼트가 휘발성이고 어떤 시간 기준에 따라 갱신된다는 것이 알려져 있지만 프래그먼트 입도에 의해 페이지의 일부분이 캐싱될 수 있게 된다는 것을 설명하는 것이다. 즉, 여러가지 유형의 웹 콘텐츠가 캐싱으로부터 이익을 얻는 정도는 서로 다르다.

제품 표시 웹 페이지는 동적 콘텐츠 프래그먼트(200)를 포함한다. 최상위 레벨 프래그먼트는 자바 서버 페이지(JSP)(204)이고, 이 JSP는 5개의 자식 프래그먼트(206-214)를 포함한다. 프래그먼트(208, 212)는 캐싱된다. 유의할 점은 자식 프래그먼트는 동 도면에 시간축으로 나타낸 바와 같이 그의 기초 데이터의 변화율이 증가하는 순서로 좌에서 우로 정렬된다.

제품 URI(206)는 제품의 GIF(또는 .gif)(Graphics Interchange Format) 이미지 파일로의 URI(Uniform Resource Identifier) 링크이다. 포맷화된 테이블은 상세 제품 설명(208)을 포함할 수 있다. 개인별 맞춤 인사(210)를 표시하는 프래그먼트는 쇼핑객 이름을 사용할 수 있다. 이 인사는 종종 예를 들면 매 사용자마다 변하지만, 소정의 쇼핑객 이름이 동일 사용자에 의해 세션 도중에 재사용될 것이기 때문에 이를 캐싱하는 것이 여전히 도움이 될 수 있다.

JSP(212)는 간략 쇼핑 카트(abbreviated shopping cart)를 생성한다. 쇼핑 카드 JSP(212)는 데이터를 표시하기 위해 HTML 테이블을 생성할 수 있다. 이 콘텐츠는 쇼핑객이 그의 카트에 무언가를 추가할 때마다 갱신되어야만 하기 때문에 개인별 맞춤 인사(210)보다 훨씬 더 빈번히 변하게 된다. 그럼에도 불구하고, 쇼핑 카트가 쇼핑객에게 보고되는 모든 페이지상에 나타나게 되면, 그 카트가 표시될 때마다 동일한 데이터를 검색하기 보다는 JSP(212)를 캐싱하는 것이 보다 효율적이다. JSP(204)는 주식 감시 목록을 표시하는 웹 페이지 상에 나타나는 광고(214)도 포함할 수 있다. 광고는 그 페이지가 요청될 때마다 변하기 때문에, 갱신율이 너무 높아서 캐싱으로부터 이익을 얻지 못하게 된다.

도 1a 내지 도 2는 본 발명의 양호한 실시예의 논의를 위한 배경 상황으로서 여러가지 분산 데이터 처리 시스템 및 동적 콘텐츠의 일례를 나타낸 것이다. 전술한 바와 같이, 프래그먼트를 효율적으로 캐싱하는 것이 어려울 수 있다. 본 발명의 양호한 실시예는 동적 프래그먼트 및 개인별 맞춤 프래그먼트, 즉 동적 콘텐츠의 캐싱과 관련된 문제점을 극복하는 것에 특히 주목하여 프래그먼트를 효율적으로 캐싱하기 위해 HTML 및 HTTP에 대한 확장을 사용하는 기술에 관한 것이다.

유의할 점은 이하에 제공되는 일례들은 HTTP/1.1 및 HTML 4.1 등의 프로토콜의 특정의 규격에 대해 말하고 있다는 것이다. 그렇지만, 당업자라면 본 발명의 양호한 실시예에서 요구되는 것과 같은 등가의 특징 및 기능의 최소 세트를 제공하는 다른 프로토콜도 사용될 수 있다는 것을 잘 알 것이다.

용어

"정적 프래그먼트"는 질의 파라미터 또는 쿠키의 사용없이 획득될 수 있는 프래그먼트인 것으로 정의한다. 정적 프래그먼트는 참조, 캐싱 및/또는 전적으로 그의 URI로부터 페치될 수 있다.

"동적 프래그먼트"는 요청자에 의해 제공되는 파라미터 또는 쿠키에 기초하여 서버에서의 계산의 결과로서 생성되는 프래그먼트이다. 동적 프래그먼트의 일례는 스포츠 경기의 결과일 수 있다. 동적 프래그먼트는 사이트마다 특유한 데이터의 사용자 요청 서브세트로 이루어지는 것에 특징이 있다.

"개인별 맞춤 프래그먼트"도 요청자의 파라미터 또는 쿠키에 기초하여 계산의 결과로서 생성된다. 개인별 맞춤 프래그먼트는 그의 콘텐츠가 사용자에 의존하고 있다는 점에서 동적 프래그먼트의 특수한 경우이다. 개인별 맞춤 프래그먼트는 예를 들면 계좌 번호와 같이 비휘발성이거나 예를 들면 쇼핑백과 같이 휘발성일 수 있다. 프래그먼트의 정의 및 관리 목적상, 동적 및 개인별 맞춤 프래그먼트는 동등한 문제점을 나타내며, 따라서 용어 "동적"과 "개인별 맞춤"은 상호 교환적으로 사용될 것이다.

"최상위 레벨 프래그먼트"는 다른 어떤 프래그먼트에도 내포되지 않지만 그 자체는 다른 프래그먼트를 내포하는 프래그먼트이다.

"페이지 어셈블러"(page assembler)는 프래그먼트로부터 페이지를 작성하는 프로그램이다. 프래그먼트를 수집하여 페이지를 작성하는 프로세스를 "페이지 조립"(page assembly)이라고 한다. 비록 문자 그대로의 파싱이 수행되지 않더라도, 부가의 프래그먼트를 페치하여 문서에 조립해야만 하는지를 결정하기 위해 프래그먼트를 검사하는 프로세스를 이후부터 "파싱"이라고 한다. 예를 들어, 프래그먼트는 조립을 위해 페치되어야만 하는 부가의 프래그먼트를 지명하고 부가의 프래그먼트가 삽입되어야만 하는 정확한 위치를 지정하는 메타 정보를 수반할 수 있다. 부가의 프래그먼트에 대한 이러한 프래그먼트를 검사하는 일이 반드시 정식적인 컴퓨터 과학 파싱은 아니다.

FRAGEMENTLINK 태그의 정의

이제 도 3을 참조하면, 본 발명의 양호한 실시예에 따른 FRAGMENTLINK 태그 의 공식적인 SGML(Standard Generalized Markup Language) 정의가 제공된다. FRAGMENTLINK 태그는 페이지 조립 또는 페이지 렌더링(page rendering) 동안 문서 내에 삽입될 프래그먼트의 위치를 지정하는 데 사용된다. 새로운 객체는 부모 문서의 일부로서 파싱되고 그 자신의 FRAGMENTLINK 태그를 포함할 수 있다. FRAGMENTLINK 태그의 속성(attribute)의 정의에 대해서는 이하에서 논의한다.

[유의할 점은 마크업 언어가 일반적으로 구분 문자(delimiter)로서 각괄호("<"과 ">")를 사용한다는 것이다. 이 문서의 마크업 언어 버전에서의 있을 수 있는 포맷팅 문제 또는 전자적 해석 문제를 피하기 위해, 중괄호("{"과 "}")가 이 문서 전반에 걸쳐 대체 구분 문자로서 사용되어 왔다. 다른 포맷팅 기호로서, 긴 텍스트 문자열의 어떤 일례들은 이 문서에서 한 줄 이상의 텍스트를 차지한다. 당업자라면 어떤 텍스트 일례가 문서에서 줄 경계를 넘어 서는 것처럼 보이지만 그것이 한 줄의 텍스트로서 나타내려고 한 것이었는지를 결정할 수 있을 것이다.]

src=URI

SRC 속성은 문서에 삽입될 프래그먼트의 소스 위치를 지정한다. SRC 속성은 그 프래그먼트를 획득하기 위한 소스 식별자로서 기능한다. URI가 상대 URI인 경우, 절대 URI는 부모의 경로와 임의의 관련 BASE 태그로부터 얻어진다. 유의할 점은 2개의 서로 다른 페이지 내에 하나의 공통된 프래그먼트가 들어 있는 경우 이것은 혼란을 일으킬 수 있다는 것이다. 저작자는 프래그먼트 URI에 대해 절대 경로명만을 코딩할 것이 추천된다. URI의 프로토콜 부분은 "쿠키"를 지정할 수 있으며, 이 경우 삽입된 텍스트의 값은 지명된 쿠키로부터 취해진다.

alt=string

ALT 속성은 SRC 속성으로부터의 URI가 페치될 수 없는 경우 대체될 대체 HTML 텍스트를 지정한다. ALT 속성이 지정되지 않고 SRC 속성의 프래그먼트가 페치될 수 없는 경우, 어떤 프래그먼트도 페치되지 않는다.

parms=%parmlist

PARMS 속성은 공백으로 구분된(space-delimited) 이름의 목록을 지정한다. 각 이름은 부모 프래그먼트의 URI에 존재할 수 있는 질의 파라미터에 대응한다. PARMS 속성이 지정될 때, SRC 속성에 지정된 URI는 불완전한 것으로 간주된다. SRC 속성을 완전한 것으로 하기 위해서, PARMS 속성에 지명된 질의 파라미터의 각각의 값이 부모 문서로부터 페치되어 이름-값 쌍을 생성하는 데 사용되어야만 한다. 이 이름-값 쌍은 SRC 속성의 URI를 완전한 것으로 하기 위해 이에 질의 파라미터로서 첨부될 것이다. 지명된 파라미터가 부모 URI에 존재하지 않을 경우, 그 파라미터는 프래그먼트의 URI에 첨부되지 않는다. 각 파라미터는 PARMS 속성에 나타나는 것과 동일한 순서로 SRC 속성의 URI에 첨부되어야만 한다.

foreach=quoted-string

FOREACH 속성은 인용 부호로 둘러싸인 문자열을 지정한다. 인용 부호로 둘러싸인 문자열의 값은 양호하게는 이름과 값이 등호("=") 또는 어떤 다른 형태의 동등한 구분 기호에 의해 분리되어 있는 공백으로 구분된 이름-값 쌍의 목록으로 된 값을 갖는 쿠키의 이름이다. 쿠키에서의 각각의 이름-값 쌍에 대해, 이름-값 쌍이 질의 파라미터로서 부가된 URI를 SRC 속성으로 갖는 새로운 FRAGMENTLINK 태 그가 생성된다. 이것은 하나의 질의 파라미터, 예를 들어 사용자의 주식 감시 목록의 값만 다른 다수의 FRAGMENTLINK 태그를 자동적으로 생성하는 간단한 방법을 제공한다.

다시 말하면, FOREACH 속성은 프래그먼트로의 하나의 링크를 다수의 프래그먼트로의 한 세트의 다중 링크로의 확장에 대비한 것이다. 각각의 이름-값 쌍은 확장 파라미터 이름과 확장 파라미터 값의 쌍이 된다.

showlink=(no|comment|CDATA)

SHOWLINK 속성은 포함된 프래그먼트 데이터를 래핑(wrap)하는 데 사용되는 태그의 이름을 지정한다. "no"로 지정되면, 데이터는 래핑 태그(wrapping tag) 없이 포함된다. "comment"로 지정되면, FRAGMENTLINK 태그는 HTML 주석(comment)으로서 재작성된다. 임의의 다른 값으로 지정되면, FRAGMENTLINK 태그는 지정된 태그로서 재작성된다. CDATA가 유효한 태그인지를 확인하기 위한 어떤 검사도 행해지지 않으며, 따라서 프래그먼트를 어떻게 나타낼지를 정확하게 결정하는 것은 페이지 저작자에 달려 있다. SHOWLINK 속성이 생략되어 있으면, 어떤 래핑도 행해지지 않는다.

id=ID

ID 속성이 지정되면, 그의 식별자 값이 1999년 12월 24일자의 W3C 권고안인 "HTML 4.01 규격"에 따라 프래그먼트를 표현하는 결과 DOM 엘리먼트 내의 이 프래그먼트에 고유한 이름으로서 할당되며, 이 권고안은 인용함으로써 본 명세서에 포함되며, 이는 월드 와이드 웹 컨소시엄(World Wide Web Consortium, W3C)으로부터 www.w3c.org에서 입수가능하다.

class=CDATA

CLASS 속성이 지정되면, HTML 규격에 따라 이 프래그먼트를 표현하는 DOM 엘리먼트에 클래스 이름 또는 한 세트의 클래스 이름을 할당한다.

페이지가 조립될 때, 페이지 어셈블러는 지정된 프래그먼트를 페치하여 이를 부모 객체 내에 삽입한다. SHOWLINK 속성은 삽입된 데이터가 태그 또는 HTML 주석 내에 래핑될 수 있도록 하는 데 사용될 수 있다. 중첩 프래그먼트(nested fragment)에 대비하지만, 어떤 프래그먼트도 직접 또는 간접적으로 그 자신을 포함할 수는 없다. 프래그먼트 공간 내의 모든 프래그먼트의 중첩 구조(nesting structure)는 방향 비순환 그래프(directed, acyclic graphic: DAG)를 형성해야만 한다. 어떤 부수적인 HTTP 응답 헤더도 문서의 일부로 간주되지 않으며 문서에 삽입되기 전에 제거되어야만 한다. 캐시는 이들 헤더가 임의의 다른 문서에 대해서와 마찬가지로 그 헤더들을 보유하고 있어야만 한다. 대체 프래그먼트 URI가 지정될 수 있다. SRC 프래그먼트가 페치될 수 없는 경우 ALT 속성에 의해 지정되는 프래그먼트가 페치되어 삽입된다. SRC 속성의 프래그먼트도 ALT 속성의 프래그먼트도 페치될 수 없는 경우, 원래의 문서에 FRAGMENTLINK 태그가 포함되어 있지 않은 것처럼 렌더링이 계속될 수 있다.

동적 또는 개인별 맞춤 프래그먼트의 사용에 있어서의 문제점은 그 프래그먼트를 페치하는 데 사용되는 URI가 부모 페이지가 존재하는 환경 또는 전후 관계로부터 계산되어야만 한다는 것이다. 다시 말하면, URI는 부모 문서에 수반되는 질 의 파라미터로부터 동적으로 생성될 필요가 있을 수 있다. PARMS 속성이 이 특징을 지원한다. PARMS 속성은 프래그먼트를 페치할 때 사용될 부모 문서로부터의 질의 파라미터의 이름의 목록으로 이루어져 있다. 이름-값 쌍은 PARMS 속성에 지명된 각 파라미터에 대해 형성되고 FRAGMENTLINK 태그의 SRC 속성에 지정된 URI에 (아마도 부가적인) 질의 파라미터로서 첨부된다. 이들 이름-값 쌍은 PARMS 속성에 나타나는 것과 동일한 순서로 첨부되어야만 한다. 게다가, 부모와 관련된 쿠키는 프래그먼트를 정확하게 페치 또는 계산하는 데 필요할 수 있다. 부모 문서에 수반되는 모든 쿠키는 그 프래그먼트에 대한 요청과 함께 제공되어야만 한다.

종종 예를 들어 주식 감시 목록의 사용에 있어서, 질의 파라미터의 값만 다른 많은 FRAGMENTLINK 태그가 요구된다. FOREACH 속성은 페이지의 코딩을 단순화하고, 프래그먼트를 전송할 때 대역폭 요건을 완화시키며, 또 캐시 내의 프래그먼트의 크기를 감축시키는 간단한 방법으로서 사용될 수 있다. 예를 들어, FRAGMENTLINK 태그가 다음과 같이 생성된다고 가정하고,

쿠키가 있는 것으로 가정한다.

이렇게 하면 FRAGMENTLINK 태그가 일련의 FRAGMENTLINK 태그로 확장되며, 이 는 이어서 각각의 새로 생성된 FRAGMENTLINK 태그가 평가된다.

종종 프래그먼트의 텍스트는 조금이고, 쿠키의 값으로서 포함될 수 있으며, 그 결과 페이지 조립 동안 상당한 성능 이득을 얻게 된다. 이것을 지정하기 위해, 키워드 COOKIE가 예를 들어

와 같이 URI의 프로토콜에 배치된다.

FRAGMENT 헤더의 정의

이제 도 4를 참조하면, 본 발명의 양호한 실시예에 따른 FRAGMENT 헤더의 공식적인 정의가 제공된다. 본 발명의 일 실시예는 신규의 HTTP 헤더 및 기존의 "캐시-제어"(Cache-Control) 헤더에 대한 확장을 사용할 수 있다. FRAGMENT 헤더는 HTTP 규격, 즉 "하이퍼텍스트 전송 프로토콜 -- HTTP/1.1", RFC 2616(Request for Comments 2616), 인터넷 엔지니어링 태스크 포스(Internet Engineering Task Force), 1999년 6월판에 부합되며, 이는 인터넷 엔지니어링 태스크 포스로부터 www.ietf.org에서 입수가능하고, 인용함으로써 본 명세서에 포함된다.

프래그먼트로서 객체에 관한 모든 정보는 FRAGMENT라고 하는 헤더에 캡슐화되어 있다. 이 헤더는 클라이언트, 서버 또는 어떤 중간 캐시가 페이지 조립 기능을 갖는지 여부를 확인하는 데 사용된다. 이 헤더는 또한 (객체에 수반되는 쿠키 및 URI의 질의 파라미터에 기초하여) 프래그먼트에 대한 캐시 식별자를 형성하는 규칙들을 지정한다. 게다가, 이 헤더는 호스트가 개시한 무효화를 지원하여 객체와 그의 기초 데이터간의 종속성 관계를 지정한다. FRAGMENT 헤더는

디렉티브(directive)가 효력이 있을 경우에만 사용되는 것이다. FRAGMENT 헤더의 전체 구문이 도 4에 도시되어 있다. FRAGMENT 헤더의 속성의 정의에 대해서 이하에 기술한다.

contains-fragments: 이 속성은 응답의 보디가 페이지 어셈블러에 의해 사용될 수 있는 프래그먼트 디렉티브를 포함한다는 것을 지정한다.

supports-fragments: 이 속성은 데이터 스트림 내의 캐시 또는 최초의 요청자가 페이지 조립을 지원한다는 것을 지정한다. 이 디렉티브는 페이지 조립을 완벽하게 지원하는 임의의 캐시 또는 클라이언트에 의해 삽입될 수 있다.

dependencies: 이 속성은 응답의 보디가 의존하고 있는 종속성 이름의 목록을 지정한다.

cacheid: 이 속성은 객체에 대한 캐시 ID를 형성하는 데 사용되는 규칙들의 목록을 지정한다. 규칙이 "URI"로서 지정되면, 응답의 전체 URI가 캐시 ID로서 사용된다. 캐시 ID가 규칙으로서 지정되면, 이하에 보다 상세하게 기술되는 바와 같이 캐시 ID를 형성하기 위해 이 규칙들이 요청 URI에 적용된다.

본 발명의 양호한 실시예에서, 프래그먼트에 대한 캐싱 규칙들은 캐시가 페이지 조립을 지원하는 경우 다른 유형의 객체들에 대한 것과는 다르다. 따라서, "Cache-Control" 헤더는 프래그먼트 캐싱 규칙들이 적용된다는 것을 나타내기 위해 확장된다. 이것은 no-cache 디렉티브를 무시하도록 확장함으로써 행해진다. "fragmentrules" 이라고 하는 새로운 캐시-요청-디렉티브가 HTTP/1.1 규격의 섹션 14.9에 지정되어 있는 바와 같은 "Cache-Control" 일반-헤더 필드에 대한 확장으로서 구현된다. 이 확장의 목적은 프래그먼트 조립을 지원하는 캐시에서의 no-cache 디렉티브의 거동을 수정하는 것이다. 프래그먼트 조립을 지원하지 않는 캐시는 "fragmentrules" 디렉티브를 무시하게 되며, 이는 HTTP/1.0 및 HTTP/1.1에 대한 기초적인 기본 거동이다. 프래그먼트 조립을 지원하지 않는 캐시는 "fragmentrules" 디렉티브를 수반할 때 "no-cache" 디렉티브 (및 "Pragma: no-cache" 헤더가 있는 경우 이것)를 무시하고 응답에 수반되는 임의의 다른 헤더에 따라 캐싱 규칙들을 적용하게 된다. "Cache-Control" 헤더의 일례는 다음과 같이 될 것이다.

페이지 조립 기능 및 응답성의 확인

본 발명의 양호한 실시예는 브라우저 캐시를 비롯한 프래그먼트가 존재할 수 있는 모든 캐시를 포함하여 페이지 저작으로부터 브라우저 렌더링까지의 이벤트 연쇄에서의 임의의 지점에서 페이지 조립을 구현하는 것이 가능하도록 프래그먼트 포함(fragment inclusion)을 정의할 수 있는 이점을 제공한다. 페이지 조립을 행할 수 있는 소프트웨어 엔티티가 조립 지점으로서 정의된다.

이 기능은 이하의 가능한 시나리오를 제공한다.

1. 페이지를 서비스하는 HTTP 서버보다 브라우저에 더 가까운 조립 지점이 없다. 이 경우, 서버가 자체적으로 조립을 행하여 완전히 조립된 페이지를 서비스해야 한다.

2. 원서버를 위해 페이지 조립을 수행할 수 있는 어떤 종류의 프록시가 있다. 이 프록시는 그 사이트에 대한 조립 지점이 될 수 있다. 원서버는 이 프록시에 프래그먼트를 서비스할 수 있지만 어떤 페이지 조립도 행할 필요는 없다.

3. 사용자의 브라우저는 페이지 조립을 수행할 수 있다. 이 경우, 네트워크 캐시 또는 서버는 페이지 조립을 수행할 필요가 없다.

어떻게 프래그먼트를 서비스할지, 즉 완벽하게 조립할지 또는 조립하지 않을지를 결정하기 위해, 서버 및 캐시는 업스트림 에이전트 중 적어도 하나가 조립 지점으로서 기능하고 있는지를 결정할 수 있어야만 한다. 본 발명의 양호한 실시예는 HTTP 요청 헤더를 사용하며, 따라서 서버에 대한 조립 지점으로서 기능할 수 있는 임의의 에이전트는 프래그먼트를 받아들일 수 있으며 전체 페이지를 수신할 필요가 없다는 것을 나타내기 위해 헤더를 사용할 수 있다. FRAGMENT 헤더의 "supports-fragments" 디렉티브는 다운스트림 캐시에게 그것이 조립 지점이라는 것을 알려주기 위해 임의의 클라이언트 또는 캐시에 의해 삽입될 수 있다. "supports-fragments" 디렉티브의 일례로는

가 있다.

단지 프로세서가 페이지 조립을 지원한다는 것이 서버로부터 수신된 모든 객체에 대한 페이지 조립을 행해야만 하는 것을 의미하지는 않는다. 서버로부터 수신된 모든 문서를 파싱하여 이를 조립하려고 시도하는 것은 자원의 낭비는 물론 잠재적인 문제 요인이 된다. 따라서, 서버는 객체가 서비스되기 전에 조립될 필요가 있다는 것을 알려주어야만 한다. FRAGMENTS 헤더의 "contains-fragments" 디렉티브가 캐시 또는 브라우저에서의 페이지 조립이 요구되는 임의의 서버에 의해 삽입되어야만 한다. "contains-fragments" 디렉티브의 일례로는

가 있다.

브라우저 캐시를 비롯한 현재의 대부분의 HTTP 캐시는 질의 파라미터를 갖는 모든 객체가 캐싱될 수 있는 것은 아니라고 가정한다. HTTP/1.1에서는 캐시가 성공적으로 페치한 임의의 객체를 그 캐시가 캐싱할 수 있도록 캐싱 기능을 확장 및 일반화하고 있다. 그렇지만, HTTP 1.1 캐시조차도 종종은 동적 객체를 캐싱하는 것이 자원의 비효율적 사용이라는 가정하에 동적이라고 생각하는 객체를 캐싱하지 않도록 구성되어 있다. 이러한 가정이 무효인 상황의 일례는 개인화된 데이터의 경우이다. 개인화된 페이지는 질의 파라미터 또는 쿠키를 페이지와 관련시킴으로써 생성되고, 그에 따라 페이지를 보다 일반적인 페이지에 대한 특정의 보다 개인화된 경우로서 식별하게 된다. 페이지가 개인화되어 있다는 사실이 그 페이지를 본질적으로 캐싱될 수 없게 하지는 않는다. 페이지는 페이지의 기초를 이루는 데이터가 휘발성이 높을 경우에만 캐싱될 수 없다. 이것은 특정 기업의 웹 콘텐츠만 을 캐싱하는 기업용 서버에서 특히 그렇다. 이러한 페이지를 캐싱하는 것에 반대하여 보통 제시되는 논거는 이러한 페이지의 재사용 빈도가 너무 낮아 캐시에서의 공간을 정당화시키지 못한다는 것이다. 이러한 논거는 몇가지 이유로 불충분하다.

1. 문서의 최초 생성으로부터 브라우저에서의 최종 렌더링까지의 비용은 단지 명목상으로는 문서의 크기의 함수이다. 문서가 어떻게든 "동적"인 경우, 비용의 대부분은 그 문서를 처음으로 생성하는 데 든다. 따라서, 아무리 낮은 재사용이라도 서버에서의 상당한 비용 절감을 가져올 수 있다.

2. 캐시의 용량이 상당히 증가하였고 아주 고속으로 계속 증가할 것이다.

3. 프래그먼트 기술의 채택은 실제로 동일한 HTML 콘텐츠의 중복된 경우를 제거함으로써 캐싱되는 데이터량을 감소시킬수 있다.

프래그먼트의 도입은 특히 페이지 어셈블러가 캐시 내부에 구축되는 경우 캐시 정책의 규격을 아주 복잡하게 할 가능성이 있다. 페이지의 각 프래그먼트는 서로 다른 캐시 정책을 요구할 수 있다. 본 발명의 양호한 실시예는 종래 기술에서 이용가능한 것보다 캐싱 정책의 입도를 향상시키기 위해 HTTP 응답 헤더를 사용한다.

구현된 페이지 어셈블러로 전달되어야만 하는 캐싱에 영향을 미치는 요인에는 2가지, 즉 (1) 프래그먼트 수명, 및 (2) 객체에 대한 명시적인 서버-개시 무효화(server-initiated invalidation)가 있다. 서버-개시 무효화가 없는 경우, 다른 객체에 대해 캐시에서의 객체 수명을 지정하기 위한 동일한 메카니즘이 프래그먼트에 적용될 수 있다. 프래그먼트가 명시적으로 프래그먼트를 지원하지 않는 캐시에 캐싱되지 않도록 하는 것이 중요한 경우, "no-cache" 및 "fragmentrules" 디렉티브를 갖는 "Cache-Control" 헤더가 응답에 포함되어 있어야만 한다. "no-cache" 디렉티브는 비구현 캐시(non-implementing cache)에 의한 프래그먼트의 캐싱을 방지하고, "fragmentrules" 디렉티브는 구현 캐시(implementing cache)가 "no-cache" 디렉티브를 무시할 수 있게 해준다.

서버 -개시 무효화

서버-개시 무효화를 지원하는 캐시는 서버로부터의 명시적인 제어를 통해 어느 프래그먼트가 무효화되어야 하는지를 통지받을 수 있다. 서버-개시 무효화를 인식하지도 지원하지도 않는 기존의 보다 구식의 캐시와의 호환성을 유지하기 위해, 이러한 서버-무효화된 프래그먼트는 HTTP/1.1 "Cache-Control" 헤더 및 "no-cache" 디렉티브를 제공받아야만 한다. 이러한 프래그먼트는 캐시가 "no-cache" 디렉티브를 무시하고 프래그먼트별 규칙을 적용하기를 원하는 경우 확장된 디렉티브 "fragmentrules"를 제공받아야만 한다. 본 발명의 양호한 실시예의 프래그먼트 캐싱 기술을 구현하는 어떤 캐시라도 HTTP/1.1 규격에 기술되어 있는 바와 같은 HTTP/1.1 캐싱가능성 규칙(cachability rule)에 따라 기능을 구현해야만 한다.

서버에 의해 무효화되는 프래그먼트가 다수의 데이터 소스에 의존할 수 있고, 다수의 프래그먼트가 동일한 데이터에 의존할 수 있다. 공통 데이터에 기초한 모든 프래그먼트의 위치를 알아내어 하나의 무효화 지시를 캐시에 전송함으로써 다수의 프래그먼트를 무효화할 수 있는 것이 아주 바람직하다. 이것을 효과적으로 행하기 위해, 서버는 하나 이상의 무효화 ID를 프래그먼트에 할당한다. 구현 캐시 는 무효화 ID를 사용하여 캐싱된 항목들에 2차 인덱싱을 제공한다. 서버-개시 무효화 지시가 도달할 때, 무효화 ID 하에서 인덱싱된 모든 캐싱된 항목들은 무효화된다. 무효화 ID는 FRAGMENT 헤더의 "dependencies" 디렉티브를 통해 지정된다. "dependencies" 디렉티브의 사용의 일례로는

가 있다.

구현 서버(implementing server)는 "dependencies" 디렉티브를 사용하여 서비스 제공 호스트가 객체를 명시적으로 무효화할 것이라는 것을 알려준다. HTTP/1.1 규격에 정의되어 있는 바와 같은 통상의 에이징(aging) 및 캐싱가능성(cacheability)은 이 디렉티브에 의해 영향을 받지 않으며, 따라서 드물게 무효화되는 객체들은 서버-개시 무효화가 없는 경우 캐시로부터 제거될 수 있다. "dependencies" 헤더가 지정되어 있는 경우, 캐시는 어떤 "cache-control: no-cache" 헤더도 무시할 수 있다.

무효화 ID, URI, 및 캐시 ID는 각자의 역할이 있다. 이들 각각의 지정에 각기 다른 메카니즘을 제공함으로써 해결하기 어려울 수도 있는 불필요한 애플리케이션 설계 충돌을 방지하게 된다.

동적 프래그먼트 캐시 식별자

객체가 그의 URI와 다른 식별자로 캐싱되어야만 하는 일도 있을 수 있다. 또한 URI 자체의 콘텐츠에 기초하여 캐시 ID가 형성되는 엄격한 방식에 제약을 가해야만 하는 경우도 있을 수 있다. 이렇게 하는 이유는 URI가 고유의 캐시 ID의 일부로서 사용되어서는 안되는 질의 파라미터를 갖는 동적 객체에 대해 형성되는 일이 종종 있기 때문이다. 이들 파라미터가 캐싱 이전에 URI로부터 제거되지 않는 경우, 잘못된 캐시 미스가 일어날 수 있으며, 그 결과 동일한 객체의 여러 복사본이 여러개의 ID로 저장된다.

이러한 문제를 피하기 위해, 캐시 ID를 형성하는 한 세트의 규칙이 캐시 ID로서 직접 사용될 수 없는 URI를 갖는 동적 개체의 응답 헤더에 실려 있어야만 한다. 각 규칙은 질의 파라미터 이름 및 쿠키 이름의 목록을 포함한다. 종래 기술에서, 쿠키는 캐시 ID의 일부로서 사용되지 않지만, 많은 응용에서 어떤 요청이 다른 요청들과 구별되게 해주는 정보는 쿠키 내부의 데이터이다. 따라서, 쿠키의 값은 캐시 ID의 일부로서 지정될 수 있다. 캐시 ID의 일부로서 사용되는 어떤 쿠키도 이름-값 쌍의 형태이어야만 한다.

다시 말하면, CACHEID 디렉티브는 하나 이상의 규칙 세트로 이루어져 있다. 규칙 세트는 하나 이상의 규칙으로 이루어져 있다. 규칙은 문자열의 목록으로 이루어져 있으며, 각 문자열은 요청 URI로부터의 질의 파라미터 또는 수반되는 쿠키의 이름이다. CACHEID 디렉티브의 일례로는

가 있다.

이 디렉티브는 3개의 규칙, 즉

,

및 URI로 이루어져 있다. 규칙에서 "p_"항은 질의 파라미터의 parmname이고, "c_"항은 쿠키의 cookiename이다.

캐시는 캐시 ID를 생성하기 위해 프래그먼트의 URI의 경로명 부분에서 시작한다. 그 다음에, 캐시는 규칙 목록 내의 각 규칙의 적용을 시도한다. 규칙 목록 내의 모든 규칙이 적용될 수 있는 경우, 이 동작으로부터의 문자열은 캐시 ID로서 사용된다. 규칙 목록의 어떤 규칙이 적용될 수 없는 경우, 그 규칙 목록은 건너뛰고, 그 다음 규칙 목록이 적용되며, 이하 마찬가지이다. 그의 모든 비선택적인 규칙(non-optional rule)이 적용될 수 있는 규칙 목록이 존재하지 않는 경우, 그 객체는 캐싱될 수 없으며, 그렇지 않은 경우 성공적으로 적용되었던 첫번째 규칙 세트가 캐시 ID를 형성하는 데 사용된다.

대괄호("["와 "]")로 둘러싸인 규칙은 선택적인 규칙(optional rule)으로서, 이는 가능하다면 적용되어야만 하지만, 선택적인 규칙의 실패가 규칙 목록의 실패의 원인이 되지 않는다. 어떤 CACHEID 디렉티브도 객체에 수반되지 않는 경우, 그 객체는 질의 파라미터를 포함한 그의 전체 URI로 캐싱된다.

캐시는 규칙들을 적용하기 위해 먼저 원래의 URI로부터 모든 질의 파라미터를 제거함으로써 베이스 캐시 ID(base cache ID)를 형성해야만 한다. 캐시는 parmrule를 적용하기 위해 parmname에 지정된 이름을 갖는 질의 파라미터를 찾는다. 그 이름이 존재하는 경우, 원래의 URI로부터의 대응하는 이름-값 쌍이 베이스 캐시 ID에 첨부되어 새로운 베이스 캐시 ID를 형성한다. 이 과정은 모든 규칙들이 성공적으로 적용될 때까지 계속된다. 비선택적인 규칙이 적용될 수 없는 경우, 베이스 캐시 ID는 그의 원래의 상태로 복원되고 그 다음 규칙 목록이 적용된다. 캐시는 쿠키 규칙을 적용하기 위해 쿠키 이름 파라미터에 지정된 이름을 갖는 이름- 값 쌍의 형태의 쿠키를 찾는다. 존재하는 경우, 이름-값 쌍이 베이스 캐시 ID에 첨부되어 새로운 베이스 캐시 ID를 형성한다. 이 과정은 모든 규칙들이 성공적으로 적용될 때까지 계속된다. 비선택적인 규칙이 적용될 수 없는 경우, 베이스 캐시 ID는 그의 원래의 상태로 복원되고 그 다음 규칙 목록이 적용된다. 규칙 목록이 문자열 "URI"로 이루어져 있는 경우, 응답의 전체 URI가 캐시 ID로서 사용된다. 전술한 일례에서, 다른 2개의 규칙 목록 어느 것도 성공적으로 적용될 수 없는 경우, 그 요청의 전체 URI가 사용된다.

객체에 대한 요청이 캐시에 도달할 때, 그 캐시, 즉 캐시 관리 유닛 또는 캐시의 관리자(maintainer)는 먼저 객체가 그의 전체 URI로 캐싱되어 있는지를 알아보기 위한 검사를 한다. 그러한 경우, 객체는 반환되고, 그렇지 않은 경우, 베이스 캐시 ID는 프래그먼트의 URI의 경로 부분으로부터 형성되고, 탐색(lookup)이 다시 수행된다. 객체가 발견되지 않은 경우, 캐시와 연관된 규칙 테이블(rules table)에서 베이스 캐시 ID를 검색한다. 베이스 캐시 ID가 캐시의 규칙 테이블에 등록되어 있는 경우, 그 URI에 대한 규칙들이 전술한 바와 같이 적용된다. 규칙 목록이 성공적으로 적용된 경우, 새로운 캐시 ID로 객체를 다시 탐색한다. 객체가 발견되지 않은 경우, 캐시는 이것을 미스(miss)라고 간주하고, 서버로 요청을 보낸다. 그렇지 않고, 객체가 발견된 경우, 그 객체는 요청자에게 반환된다.

계속하여 전술한 일례에서, 객체의 전체 URI가

이고, 응답이 "cookie4"의 값을 갖는 "C4"라고 명명된 부수 쿠키를 갖는다고 가정하자. 이 경우, 캐시 ID는

로서 형성될 수 있는데 그 이유는 첫번째 규칙, 즉

이 적용되기 때문이다.

다중 캐시를 통한 페이지 조립

이제 도 5a 내지 도 5g를 참조하면, 객체 검색 경로를 따라 있는 한 세트의 프래그먼트 지원 에이전트와 프래그먼트 비지원 에이전트가 본 발명의 양호한 실시예의 프래그먼트 캐싱 기술이 다양한 처리 환경에서 성공적으로 구현될 수 있는 방법에 대한 논의의 기초로서 도시되어 있다.

클라이언트 브라우저와 서버 사이의 경로를 따라 다수의 캐시가 있고 그 캐시의 일부는 페이지 조립에 대한 지원을 요구하고 그 캐시의 일부는 페이지 조립에 대한 지원을 요구하지 않는 경우 어떤 곤란한 문제가 일어날 수 있다. 이들 문제는 이미지 또는 멀티미디어 등의 다른 유형의 내장 객체에 대해서는 일어나지 않는데, 그 이유는 캐시 및 브라우저가 이들 객체를 항상 독립적인 무관계 객체(independent, unrelated object)로서 취급하기 때문이다. 브라우저에서의 렌더링 후에도, 원래의 객체는 여전히 브라우저의 캐시에서 개별적인 것이다. 그렇지만, 페이지가 최상위 레벨 프래그먼트 "p"와 자식 프래그먼트 "c"를 포함하는 경우, "p"에 대한 URI를 사용하는 객체에 대한 요청은 브라우저에서 시작하여 목적지 서버에서 종료하는 에이전트의 연쇄에서의 페이지 조립에 대한 지원 레벨에 따라 프래그먼트 "p" 또는 완전히 작성된 페이지(fully composed page) "P"를 반환할 수 있다.

도 5a 내지 도 5g는 서로 다른 기능을 갖는 에이전트의 여러가지 구성 및 본 발명의 양호한 실시예가 이들을 처리할 수 있는 방법을 나타낸 것이다. 각 도면에서, 첫번째 캐시인 캐시 1과 두번째 캐시인 캐시 2는 클라이언트 브라우저와 서버 사이에 위치하고 있다. 이들 일례에서, "f"는 프래그먼트를 지원하는 에이전트를 나타내고, "nf"는 프래그먼트를 지원하지 않는 에이전트를 나타내며, "p"는 부모 프래그먼트를 나타내고, "c"는 자식 프래그먼트를 나타내며, "P(p,c)"는 자식 프래그먼트 "c"를 부모 프래그먼트 "p"에 내장시킴으로써 작성된 페이지를 나타낸다.

도 5a는 가장 간단한 경우를 나타낸 것이다. 이 일례에서, 서버는 프래그먼트를 지원하고, 2개의 캐시와 브라우저는 프래그먼트를 지원하거나 지원하지 않을 수 있다. 자식 프래그먼트 "c"를 포함하는 최상위 프래그먼트 "p"가 있다. 서버는 "p"와 "c"를 개별적으로 저장하지만, 이들이 관련되어 있다는 것을 알고 있다. "p"에 대한 특정의 요청에 대해, (임의의 수의 레벨로 있는) 브라우저와 서버 사이의 어떤 에이전트도 프래그먼트를 지원하는 경우, 개별적인 프래그먼트가 반환되지만, 그렇지 않은 경우 서버는 프래그먼트를 조립하여 완전히 조립된 페이지를 반환한다.

도 5b를 참조하면, 브라우저는 프래그먼트를 지원하지만 캐시 1과 캐시 2는 프래그먼트를 지원하지 않는다. 브라우저가 p를 요청(하고 이어서 p를 조립하려고 시도한 후 c를 요청)한 후, 각 에이전트는 "p"와 "c"의 복사본을 캐싱한다. 서버는 개별적인 프래그먼트를 반환하는데 그 이유는 브라우저가 프래그먼트를 지원한다는 것을 나타낼 것이기 때문이다. 그렇지만, 캐시 1과 캐시 2는 특히 브라우저에 의해 개별적으로 요청받았기 때문에 2개의 독립적인 HTTP 객체를 캐싱하고 있는 것처럼 행동하지만, 브라우저와 서버는 "p"와 "c"의 복사본이 관련이 있다는 것을 알고 있다. 브라우저는 이들을 개별적으로 캐싱하지만 필요할 때는 이들을 작성한다.

도 5c를 참조하면, 브라우저는 프래그먼트를 지원하지 않지만 캐시 1과 캐시 2는 프래그먼트를 지원한다. 이 경우, 서버는 개별적인 프래그먼트를 반환하는데, 그 이유는 캐시 2가 프래그먼트 지원을 나타내기 때문이다. 캐시 2는 개별적인 프래그먼트를 반환하는데 그 이유는 캐시 1이 프래그먼트 지원을 나타내기 때문이다. 캐시 1은 브라우저로 반환하기 전에 "p"와 "c" 프래그먼트로부터 최종 페이지 "P(p,c)"를 작성하는데 그 이유는 브라우저가 프래그먼트 지원을 나타내지 않기 때문이다.

도 5d를 참조하면, 브라우저와 캐시 2는 프래그먼트를 지원하지 않지만 캐시 1은 프래그먼트를 지원한다. 서버가 개별적인 프래그먼트를 반환한 이유는 캐시 1이 프래그먼트 지원을 나타내고 그 표시가 캐시 2를 통해 HTTP 헤더에서 수행될 것이기 때문이다. 캐시 2는 2개의 독립적인 HTTP 객체를 캐싱하고 있는 것처럼 행동하지만 브라우저, 캐시 1 및 서버는 개별적인 프래그먼트가 관련되어 있다는 것을 알고 있다. 캐시 2는 개별적인 프래그먼트를 통과시키는데 그 이유는 이들이 개별적으로 저장되어 있고 이들이 관련되어 있다는 것을 알지 못하기 때문이다. 캐시 1은 브라우저로 반환하기 전에 "p"와 "c" 프래그먼트로부터 최종 페이지 "P(p,c)"를 작성하는데 그 이유는 브라우저가 프래그먼트 지원을 나타내지 않기 때문이다.

도 5e를 참조하면, 브라우저와 캐시 1은 프래그먼트를 지원하지 않지만, 캐 시 2는 프래그먼트를 지원한다. 서버는 개별적인 프래그먼트를 반환하는데 그 이유는 캐시 2가 프래그먼트 지원을 나타내기 때문이다. 캐시 2는 캐시 1으로 전달하기 전에 "p"와 "c" 프래그먼트로부터 최종 페이지 "P(p,c)"를 작성하는데 그 이유는 브라우저도 캐시 1도 프래그먼트 지원을 나타내지 않기 때문이다. 캐시 1 및 브라우저는 작성된 프래그먼트를 하나의 HTTP 객체, 즉 최종 페이지 "P(p,c)"로서 저장한다.

도 5f를 참조하면, 하나의 브라우저가 2개의 브라우저, 즉 브라우저 1과 브라우저 2로 대체되어 있다. 브라우저 2는 부모 프래그먼트 "p"로 매핑될 페이지에 대한 요청을 발생한다. 캐시 1은 브라우저 2에 의해 발생된 요청을 "supports-fragments" 헤더를 전달하는 캐시 2로 포워딩한다. 캐시 2는 프래그먼트 "c"에 대한 프래그먼트 링크를 갖는 프래그먼트 "p"를 캐시 1에 반환하고, 캐시 1은 이를 브라우저 2로 반환한다. 브라우저 2는 프래그먼트 "p"를 파싱한 다음에 자식 프래그먼트 "c"에 대한 요청을 발생한다.

프래그먼트 처리를 위해 셋업되어 있지 않은 브라우저 1이 이제 페이지에 대한 요청을 발생하는 경우 잠재적 문제가 일어나게 된다. 브라우저 1은 브라우저 2에 의해 발생된 것과 동일한 URI를 갖는 요청을 발생하고, 이 URI는 프래그먼트 "p"에 대한 캐시 ID와 일치하게 된다. 캐시 1이 캐싱된 p 프래그먼트를 갖는 경우, 캐시 1은 프래그먼트 "c"에 대한 FRAGMENTLINK 태그를 갖는 캐싱된 프래그먼트를 브라우저 1로 전송한다. 브라우저 1이 FRAGMENTLINK 태그를 이해하지 못하기 때문에, 브라우저 1은 이를 무시하게 되며, 그에 따라 불완전한 페이지가 렌더링되 게 된다.

이러한 상황은 도 5g에 보다 일반적으로 도시되어 있는 바와 같이 프래그먼트를 지원하는 에이전트와 프래그먼트를 지원하지 않는 다른 에이전트가 프래그먼트를 지원하지 않는 캐시에 연결되어 있는 네트워크 내에서의 임의의 구성으로 일반화된다. 브라우저 2가 프래그먼트 "p"를 요청하는 경우, 프래그먼트를 지원하는 캐시 1은 프래그먼트 "p"와 "c"를 수신하여 이들을 조립하고, 그 후 캐시 1은 페이지 "P(p,c)"를 브라우저 2로 전달한다. 캐시 1을 통해 브라우저 1로부터의 프래그먼트 "p"에 대한 차후의 요청의 결과 조립되지 않은 페이지의 전달이 있게 된다.

이러한 잠재적 문제를 관리하기 위해, 페이지 조립을 지원하는 서버로부터의 임의의 최상위 레벨 프래그먼트는 예를 들면 "Cache-Control: no-cache fragmentrules" 사용하여 최상위 레벨 프래그먼트를 캐싱 불가로 표시해야 한다. 페이지 조립을 지원하는 캐시는 디렉티브 내의 "fragmentrules"를 인식하고 그에 따라 "no-cache" 디렉티브를 무시하고 정확한 거동을 객체에 적용하게 된다. 유의할 점은 이러한 상황을 관리하기 위해 단지 최상위 레벨 프래그먼트만이 캐싱 불가로 표시되기만 하면 된다는 것이다. 이것은 전체 페이지에 대한 URI가 최상위 프래그먼트에 대한 URI와 동일하기 때문에 일어날 수 있는, 즉 URI가 2개의 서로 다른 객체를 참조할 수 있는 불명료 때문이다. 내장된 프래그먼트는 결코 한가지 이상의 형태로 존재하지 않으며, 따라서 내장 프래그먼트에 대해 이러한 불명료는 일어나지 않는다.

부적합 캐싱을 방지하기 위한 고려사항들

바로 앞에서 언급한 바와 같이, 페이지 조립을 지원하는 서버로부터의 임의의 최상위 레벨 프래그먼트는 최상위 레벨 프래그먼트를 캐싱 불가로 표시해야만 한다. 이것은 프래그먼트를 지원하지 않는 캐시가 다른 프래그먼트를 포함하는 최상위 레벨 프래그먼트를 캐싱하려고 시도하는 잠재적 문제를 방지하며, 만약 그렇게 하는 경우 도 5g에 도시한 바와 같이 최상위 레벨 프래그먼트는 프래그먼트 지원 캐시를 포함하지 않는 어떤 브라우저로부터의 경로를 따라 액세스될 수 있으며, 그에 따라 FRAGMENTLINK 태그에 의해 지정되어지는 콘텐츠보다는 오히려 FRAGMENTLINK 태그를 갖는 페시지를 부적절하게 렌더링하게 된다.

게다가, 프래그먼트를 지원하지 않는 캐시는 일반적으로 캐시 인덱스/키(cache index/key)로서 객체와 연관되어 있는 URI 또는 URI 경로를 사용하며, 캐시가 모르는 사이에 객체는 프래그먼트가 될 수 있다. 객체가 프래그먼트이기 때문에, 프래그먼트를 지원하지 않는 캐시에서 캐시 ID로서 URI 또는 URI 경로만을 사용하는 것이 부적절하게 되는 것이 가능하며, 프래그먼트 지원 캐시에서는 캐시 ID가 객체, 즉 프래그먼트와 연관되어 있는 프래그먼트 캐싱 규칙에 따라 형성되어진다. 다시 말하면, 프래그먼트를 지원하지 않는 캐시는 모든 캐싱된 객체에 대해 그의 캐시 ID 알고리즘에 따라 그의 캐시 인덱스를 계속하여 체계화하지만, 본 발명의 양호한 실시예의 기술은 캐시 내에서의 프래그먼트의 배치를 위한 캐시 인덱스를 발생하기에 앞서 캐싱 가능한 프래그먼트에 대한 캐시 ID를 형성하는 데 사용되는 프래그먼트 캐싱 규칙을 위한 것이다. 따라서, 프래그먼트를 지원하지 않는 캐시는 아마도 캐시 히트의 결과로서 응답에서 실제로 프래그먼트인 그 의 객체를 반환할 수 있다. 그러면 여러가지 유형의 잘못 또는 렌더링 에러가 다운스트림에서 일어날 수 있다. 이러한 에러를 방지하기 위해, 캐싱이 부적절한 경우 그 캐싱이 방지되어야만 한다.

일반적으로, 프래그먼트 비지원 캐시에서의 캐싱은 "Cache-Control: no-cache fragmentrules" 헤더를 포함하고 또 "Pragma: no-cache" 헤더를 포함함으로써 방지될 수 있다. 두번째 헤더는 HTTP/1.1을 지원하지 않는 캐시에게 프래그먼트를 캐싱하지 말도록 알려주며, 프래그먼트를 지원하는 캐시도 HTTP/1.1를 지원해야만 한다. 앞서 간략히 언급한 바와 같이, 도 5g를 참조하면, 첫번째 헤더 내의 "no-cache" 디렉티브는 HTTP/1.1을 지원하지만 프래그먼트를 지원하지 않는 캐시에게 프래그먼트를 캐싱하지 말도록 알려주며, "fragmentrules" 디렉티브는 프래그먼트를 지원하는 캐시에게 프래그먼트 캐싱 규칙에 따라 프래그먼트가 캐싱되어야만 한다는 것을 알려준다.

효율적인 캐싱을 위한 고려사항

다수의 사용자들 사이에 공유되는 프래그먼트, 예를 들어 제품 설명 또는 주식 시세의 경우, 브라우저와 웹 애플리케이션 서버 사이의 대부분 또는 모든 캐시에 캐싱할 수 있는 것이 가장 효율적이다. 프래그먼트는 각 캐시가 다른 캐시들로 퍼져 나가는(fan out) 트리 구조를 따라 분산되어 있는 것으로 볼 수 있다. 특정 프래그먼트에 대한 첫번째 요청은 사용자와 웹 애플리케이션 서버 사이의 경로를 따라 캐시를 배치시킨다. 다른 사용자에 의한 동일 프래그먼트에 대한 차후의 요청들은 이들 캐시에서 프래그먼트를 발견할 수 있으며, 웹 애플리케이션 서버까지 전부 가 볼 필요가 없을 수 있다.

주식 감시 목록 등의 사용자별 프래그먼트, 예를 들면 개인화된 프래그먼트인 프래그먼트의 경우, 최종 사용자에 가장 가까운 프래그먼트 지원 캐시에만 캐싱하는 것을 허용하는 것이 가장 효율적인데 그 이유는 동일한 프래그먼트에 대한 차후의 요청만이 동일한 경로를 따라 있기 때문이다. 그렇지 않으면, 중간 캐시가 이들 사용자별 프래그먼트로 채워지게 되지만, 이들 중간 캐시가 이들 사용자별 프래그먼트에 대한 요청을 결코 보지 못하는 것은 이들이 사용자에 더 가까운 캐시에 의해 충족되기 때문이며, 이에 따라 공유된 프래그먼트를 중간 캐시로부터 밀어내게 된다.

"private" 디렉티브를 갖는 HTTP "Cache-Control" 헤더는 이전에 페이지에 대한 이러한 동일한 사용자별 특성을 지정하는 데 사용된 적이 있으며, 따라서 브라우저 캐시만이 이들을 캐싱하게 된다. 이러한 동일한 헤더는 프래그먼트 지원 캐시에 대해 콘텐츠를 사용자에 가장 가까운 프래그먼트 지원 캐시에 캐싱하도록 지시하기 위해 본 발명의 양호한 실시예에 의해 사용된다. 유의할 점은 사용자별 프래그먼트에 "Cache-Control: private"를 포함시키는 것은 선택적인 성능 최적화라는 것이다.

복합 문서를 위한 고려사항

프래그먼트 조립을 위해 프래그먼트를 페칭할 때, HTTP 요청이 형성되어야만 한다. 이러한 응답에 대한 헤더의 대부분은 최상위 레벨 프래그먼트내의 응답 헤더로부터 상속될 수 있다. 그렇지만, 어떤 응답 헤더는 페칭되는 특정 객체를 참 조하며, 이들을 부모 프래그먼트로부터 상속할 때 주의를 해야만 한다. 이와 마찬가지로, 대부분의 응답 헤더는 폐기될 수 있으며, 최상위 레벨 프래그먼트에 수반하는 응답 헤더는 응답을 클라이언트에 반환할 때 사용될 수 있다. 다시 말하면, 어떤 응답 헤더는 개개의 객체에 고유하며, 전체 문서의 상태에 영향을 줄 수 있다.

이 섹션에서는 프래그먼트 조립에서 HTTP 요청/응답 헤더의 처리에 관한 문제들에 대해 논의한다. 용어 "하향 전파(downward propagation)"는 부모 또는 최상위 레벨 프래그먼트로부터의 내장 객체에 대한 요청에 의한 요청 헤더의 상속을 말할 때 사용된다. 용어 "상향 전파(upward propagation)"는 내장 객체로부터의 응답 헤더의 부모 또는 최상위 레벨 프래그먼트로의 분해(resolution)를 말할 때 사용된다.

쿠키에 대한 복합 문서에 관한 한가지 특수한 문제는 페이지 조립 동안 원래의 "set-cookie" 응답 헤더를 이용할 수 없다는 것이다. 그 결과 얻어지는 쿠키 요청 헤더만이 클라이언트로부터 이용가능하다. 특히, 실제의 "path", "domaini" 또는 "expires" 값 중 어느 것도 이용할 수 없다. 덜 깊게 중첩된 프래그먼트(less-deeply nested fragment)가 요청에 부수하는 쿠키에 부과되는 제약조건을 만족시키지 못하는 다른 프래그먼트를 내장하고 있는 경우, 그 쿠키를 자식 프래그먼트로 전달하는 것은 부적절하다. 원래의 정보가 모두 존재하는 것은 아니기 때문에, 일반적으로 쿠키의 전달이 적절한지 여부를 결정하지 못할 수 있다. 이와 마찬가지로, 중첩된 프래그먼트는 부수적인 "set-cookie" 헤더를 가질 수 있다. 그 쿠키의 실제 값은 그 프래그먼트의 캐시 ID를 계산하는 데 필요할 수 있다. 게다가, 쿠키의 값은 더 깊게 중첩된 프래그먼트를 페치하는 데 필요할 수 있다. 그렇지만, 어떤 정보는 유추될 수 있다. 쿠키의 "expires" 부분이 아직 실시되지 않았다고 가정할 수 있으며, 실시된 경우 쿠키는 그 요청에 존재하지 않게 된다. 도메인이 그 요청 내의 도메인의 어떤 부분이라고 가정할 수 있으며, 또한 경로가 그 요청 내의 경로의 어떤 부분이라고 가정할 수 있다.

통상적으로, 브라우저는 쿠키에 대한 제약요건을 검사하고, 요청이 그 제약요건을 만족하지 못하는 경우, 쿠키는 요청 헤더 내에 포함되지 않는다. 그렇지만, 페이지 조립 캐시에서, 부수적인 쿠키를 갖는 문서 내에 포함된 FRAGMENTLINK 태그가 원래의 쿠키의 제약요건을 만족하지 못하는 URI를 참조하는 것은 가능하다. FRAGMENTLINK 태그에서 참조되는 객체는 부모의 쿠키가 적절히 평가되기를 요구할 수 있기 때문에, 덜 깊게 중첩된 프래그먼트로부터 더 깊게 중첩된 프래그먼트로 쿠키를 전파시켜야만 한다. 페이지 어셈블러가 그 쿠키에 대한 제약요건을 어기는 부적절한 방식으로 쿠키를 전달하지 않도록 하기 위해, 중첩된 프래그먼트의 URI에 대한 경로 및 도메인이 최상위 레벨 프래그먼트의 경로 및 도메인의 가장 보수적인 부분을 충족시켜야만 한다는 가이드라인이 있다. 다시 말하면, 중첩된 프래그먼트의 URI에서의 도메인은 그의 부모의 도메인과 일치해야 한다, 즉 그의 수퍼세트(superset)이어야만 하며, URI의 경로 부분은 그의 부모의 경로와 일치해야만 한다, 즉 그의 수퍼세트이어야만 한다. 이것은 "쿠키의 하향 전파"라고 할 수 있다.

이와 반대로, 이하에서는 "쿠키의 상향 전파"에 대해 기술한다. 프래그먼트가 호스트로부터 페치될 때, 그 응답이 "set-cookie" 헤더를 포함할 수 있다. 이러한 쿠키는 그 자체가 새로 반환된 프래그먼트내의 더 깊게 중첩된 프래그먼트의 정확한 평가를 위해 필요할 수 있다. 따라서, 페이지 어셈블러는 더 깊게 중첩된 프래그먼트를 페치하기 위해 "set-cookie" 헤더를 "cookie" 헤더로 변환시켜야만 한다. 이 새로운 쿠키는 적어도 2가지 목적을 위해, 즉 (1) 서버에서 더 깊게 중첩된 프래그먼트를 평가하기 위해서와, (2) 최근에 페치된 프래그먼트 또는 더 깊게 중첩된 프래그먼트에 대한 캐시 ID를 발생하기 위해 필요할 수 있다. 쿠키가 캐시 ID 발생을 위해 필요한 경우, 새로운 쿠키는 조립된 페이지와 함께 요청자로 다시 전송될 필요가 있다. 이렇게 하는 이유는 서버로부터 프래그먼트를 페치하려고 시도하기 전에 요청으로부터 캐시 ID를 계산하기 위해서는 쿠키가 그 페이지 또는 캐싱된 프래그먼트를 참조하는 임의의 페이지에 대한 그 다음 요청을 수반해야만 하기 때문이다.

"set-cookie" 헤더내의 쿠키를 중첩된 프래그먼트에 대한 요청 내의 "cookie" 헤더로 변환하는 것은 사용자를 대신하여 쿠키를 묵시적으로 수신하는 동작을 포함한다. 이러한 상황을 처리하기 위한 가이드라인에서는, (1) 최상위 레벨 프래그먼트가 이미 그 이름의 쿠키를 가지고 있어야만 하고, (2) 프래그먼트의 경로 및 도메인이 최상위 레벨 프래그먼트의 경로 및 도메인의 가장 보수적인 부분과 부합되어야만 한다.

이들 요건이 충족되면, 새로운 "set-cookie" 헤더의 효과는 단지 기존의 쿠 키의 값을 변경하는 것이 될 것이다. 애플리케이션 측면에서 볼 때, 이것은 단지 "더미" 쿠키가 최상위 레벨 프래그먼트를 수반할 필요가 있다는 것을 의미한다. 이들 "더미" 쿠키는 중첩된 프래그먼트를 페치하는 동안 및 프래그먼트의 "set-cookie" 헤더가 사용자로 다시 전파될 때 그의 값을 갱신하게 된다.

쿠키가 아닌 복합 문서에 대한 다른 특수한 고려사항에서는 "if-modified-since" 헤더를 수반한다. "if-modified-since" 헤더는 객체가 특정의 일자 및 시간 이후에 수정된 경우에만 그 객체가 반환되어야만 한다는 것을 나타내기 위해 요청자에 의해 사용된다. 객체가 그 시간 이후에 수정되지 않은 경우, 그것은 "신선한 것(fresh)"으로 간주되고, HTTP 304 "Not Modified" 응답은 통상 서버로부터 반환되고, 따라서 더 큰 응답 보디를 싣기 위해 필요하게 되는 대역폭을 절감하게 된다.

복합 문서에서, 어떤 컴포넌트는 "신선한 것"일 수 있는 반면 다른 것들은 "신선하지 않으며(stale)", 다른 컴포넌트의 상태는 불확정적일 수 있다. 어떤 컴포넌트도 "신선한 것"으로 결정될 수 없는 경우, 전체 문서는 완전한 응답(HTTP 200)으로서 반환되어야만 한다. 모든 컴포넌트가 "신선한 것"으로 결정된 경우, HTTP 304 응답이 반환될 수 있다. 그렇지만, 프래그먼트가 신선한 것으로 결정되기 위해서는, 컴포넌트의 HTTP 응답 코드에 유의하면서 페이지 조립을 수행할 필요가 있을 수 있다. 한 컴포넌트가 "신선한 것"인 경우, 컴포넌트가 말단 노드(leaf node)가 아니라면 중첩되어 있는 컴포넌트를 탐색 및 페치하기 위해 그의 콘텐츠가 여전히 필요하다.

따라서, HTTP 304 응답을 반환하게 되는 캐시로의 요청은 또한 페이지 조립이 계속될 수 있도록 프래그먼트의 텍스트를 반환해야 한다. 예를 들어 캐시 미스의 결과로서 서버로의 요청은 "if-modified-since" 헤더없이 발생되어야만 하는데 그 이유는 그렇지 않으면 프래그먼트의 텍스트가 페이지 조립을 계속하기 위해 필요하였을 때 서버가 HTTP 304 응답을 반환할 수 있기 때문이다. 다시 말하면, "if-modified-since" 헤더는 복합 문서를 위해 하향 전파될 수 없는데 그 이유는 HTTP 304 응답이 클라이언트에게 무효 응답이 될 수 있기 때문이다.

복합 문서에 대한 다른 특수 고려사항은 "if-modified-since" 헤더에서의 문제와 유사하지만 그 대신에 "last-modified" 헤더를 수반한다. 페이지 어셈블러는 또한 어느 프래그먼트가 "last-modified" 헤더를 반환하는지를 이해해야 하고 그 결과를 작성된 페이지에 대한 최근의 날짜를 갖는 하나의 합성된 "last-modified" 헤더로 병합해야 한다. 어느 프래그먼트도 "last-modified" 헤더를 반환하지 않는 경우, 조립된 전체 페이지는 "last-modified" 헤더를 반환하지 않을 필요가 있다. 이것이 중요한 이유는 "last-modified" 헤더가 브라우저의 로컬 캐시에 있는 파일과 동일하다는 것을 알아채는 경우 브라우저가 콘텐츠를 무시하기 때문이다.

예를 들어, ("last-modified" 헤더를 갖지 않는) 하나의 동적 콘텐츠와 "last-modified" 헤더를 갖는 (HTML로부터의) 하나의 정적 콘텐츠를 포함하는 페이지를 생각해보자. 정적 페이지의 "last-modified" 헤더를 갖는 페이지를 반환하려고 하는 경우, 동일한 페이지에 대한 차후의 요청이 브라우저에 의해 무시되며, 브라우저 캐시로부터의 이전 페이지가 표시된다. 다시 말하면, 모든 프래그먼트가 "last-modified" 헤더를 포함하는 경우, 이는 상향 전파되어 임의의 구성 프래그먼트의 가장 최근의 수정 시간을 반영하도록 조정되어야만 한다. 어떤 프래그먼트에도 "last-modified" 헤더가 없는 경우, "last-modified" 헤더가 반환되지 않을 수 있다.

프로그래밍 모델에 대한 고려사항

본 발명의 양호한 실시예에서는 분산 프래그먼트 캐싱을 위한 기술에 대해 설명한다. 그렇지만, 임의의 웹 애플리케이션 서버 프로그래밍 모델이라도 캐싱 기능을 예를 들어 중간 서버 및 브라우저에 위임하는 데 이를 사용할 수 있도록 가능한 한 중립적이 되도록 하였다. 본 발명의 양호한 실시예는 HTML에 대한 확장, 즉 FRAGMENTLINK 태그와 HTTP에 대한 확장, 즉 새로운 프래그먼트 캐싱 헤더를 사용하며, 이들도 중립적인 프로그래밍 모델이다.

프래그먼트를 프로그래밍할 때, 웹 애플리케이션 개발자는 이하의 2가지 유형의 정보를 지정해야만 한다.

1. 포함 메카니즘(include mechanism). 이것은 어느 프래그먼트를 포함시킬지와 이를 다른 프래그먼트의 어느 곳에 포함시킬지를 지정한다. 페이지에서의 그의 위치가 중요하기 때문에, 이것은 코드, 예를 들면 JSP 템플릿 또는 서블릿 클래스 내에 내장되어야만 한다.

2. 캐싱 제어 메타데이터. 이것은 프래그먼트에 대한 조건, 예를 들면 시간 제한을 지정한다. 이 정보는 코드에 내장되거나 이를 템플릿 이름, 예를 들면 JSP 파일 이름 또는 서블릿 클래스와 연관시켜 별도로 지정될 수도 있다.

본 발명의 양호한 실시예를 실시하는 데 J2EE 프로그래밍 모델이 사용되는 경우, 이들 2가지 특징은 이하의 메카니즘에 의해 지원될 수 있다.

1. 포함 메카니즘의 경우, J2EE 프로그래밍 모델은 포함된 프래그먼트를 지정하기 위해 웹 애플리케이션 서버 내에 이미 포함 구조(include construct), 예를 들어 "jsp:include" 태그 또는 "RequestDispatcher.include" 메쏘드를 가지고 있다. J2EE 런타임은 J2EE 포함 구조를 적절한 때에 FRAGMENTLINK 태그로 재작성하기 위해 수정될 수 있다.

2. 캐싱 제어 정보는 시스템 관리 콘솔로부터 지정되어 코드에 내장되는 대신에 각각의 프래그먼트 템플릿/클래스와 연관될 수 있다. 웹 애플리케이션 서버는 이 정보를 적절한 헤더에 삽입할 수 있다. 이 방법은 이 정보를 코드에 집어 넣은 것에 비해 이하의 이점을 갖는다.

A. 이 방법이 코드로 작성되기 때문에 프로그래머를 관여시킬 필요가 없이 관리 콘솔을 통해 동적으로 변경되는 것이 가능하게 된다.

B. J2EE 프로그래밍 모델에 새로운 메카니즘을 부가하지 않아도 된다.

J2EE 포함 구조를 FRAGMENTLINK 태그로 재작성하는 일은 이하의 고려 사항을 필요로 한다. 질의 파라미터에 대한 J2EE 의미론(semantics)에 의하면 모든 질의 파라미터가 부모 프래그먼트로부터 자식 프래그먼트로 반복적으로 전달되어야 한다. J2EE 웹 애플리케이션 서버가 FRAGMENTLINK 태그를 생성할 때, SRC 속성은 부모의 질의 파라미터가 첨부된 J2EE 포함의 URI이어야만 하다. 비-J2EE 웹 애플리케이션 서버는 그의 프로그래밍 모델에 부합하는 SRC 속성을 발생하게 된다. 이와 같이, 대용물이 존재하는지 여부에 관계없이 동일한 구문론이 행해지는데 그 이유는 애플리케이션 코드가 보게 되는 요청이 어느 경우에든지 동일하게 되기 때문이다. FRAGMENTLINK 태그는 몇가지 속성, 예를 들어 ALT, FOREACH, SHOWLINK, ID 및 CLASS를 가지며, 이들은 대응하는 "jsp:include" 속성을 갖지 않는다. 이들 특징은 J2EE 환경에서 사용되기 위해 "jsp:include"에 대한 확장을 필요로 한다.

서로 다른 웹 애플리케이션 서버가 중첩된 프래그먼트를 포함하기 위한 유사하지만 서로 다른 메카니즘을 갖는 다른 프로그래밍 모델을 지원할 수 있다. 이들 프로그래밍 모델 각각의 경우, 웹 애플리케이션 서버는 그 프로그래밍 모델의 규칙들과 부합하는 FRAGMENTLINK 태그를 생성해야만 한다.

무효화에 대한 고려사항

캐시를 최신 상태로 유지하기 위해서는, 엔트리의 콘텐츠가 더 이상 유효하지 않을 때 그 엔트리를 무효화(invalidate) 또는 덮어쓰기(overwrite)할 필요가 있다. 무효화는 시간에 기반하거나 외부 이벤트에 의해 트리거될 수 있다. 시간은 캐시에서의 최대 수명, 예를 들면 10분 이하이거나 절대 시간, 예를 들면 2001년 2월 5일 정오 이전일 수 있다. 최대 수명은 표준 HTTP "max-age" 디렉티브를 갖는 표준 HTTP "Cache-Control" 헤더를 사용하여 지정된다. 절대 시간은 표준 HTTP "Expires" 헤더를 사용하여 지정된다.

일례로서, 제품 설명이 최대 10분의 유효 기간을 갖는 것은 타당할 수 있다. 이것은 "Cache-Control: max-age=600"으로서 지정되며, 이는 이 프래그먼트가 600초 이하 동안 캐싱된 상태로 있게 된다는 것을 의미한다. 다른 일례로서, 판매는 동부 표준시로 2001년 12월 24일 월요일 오후 11시까지 계속될 수 있다. 이것은 "Expires=Mon, 24 Dec 2001 23:00:00 EST"로서 지정될 수 있다. 어느 경우든지, 프래그먼트는 새로운 프래그먼트에 자리를 내주기 위해 캐시의 교체 알고리즘에 의해 캐시로부터 제거될 수 있다.

이벤트-트리거형 무효화의 경우, 애플리케이션 서버가 무효화를 개시한다. 애플리케이션 서버는 데이터베이스 트리거, 갱신 HTTP 요청에 의해 호출되는 응용 프로그래밍 인터페이스(API) 또는 콘텐츠의 유효기간이 만료되었는지를 결정하기 위한 임의의 다른 메카니즘을 사용할 수 있다.

본 발명의 양호한 실시예의 기술은 각종의 무효화 메카니즘에 개방적이다. 이와 마찬가지로, 애플리케이션 서버가 무효화 메시지를 프래그먼트 지원 캐시에 전송하는 데 사용하는 프로토콜은 본 발명의 양호한 실시예의 기술에 의해 강제되지 않는다.

프래그먼트의 종속성이란 프래그먼트를 생성하는 데 사용되었던 어떤 기초 데이터에 대한 식별자이다. 종속성의 일례로서, 몇개의 페이지가 동일한 기초 사용자 프로파일을 사용할 수 있지만 서로 다른 프래그먼트를 사용할 수 있는 이유는 사용자 프로파일의 서로 다른 서브세트가 사용되거나 이들이 각기 달리 포맷되기 때문이다. 애플리케이션은 사용자 프로파일과 이를 사용하는 모든 프래그먼트 사이의 매핑을 결정한 다음에 사용자 프로파일이 변할 때마다 이들에 대한 캐시 ID를 구축할 수 있다. 그렇지만, 이 매핑이 각 종속성의 소스인 프래그먼트 각각에 위치하게 하는 것이 보다 나은 소프트웨어 엔지니어링이다. 이것에 의해 애플리케이 션은 사용자 프로파일과 연관되어 있는 사용자 ID를 사용하여 간단하게 무효화할 수 있고 캐시가 사용자 ID에 종속되어 있는 모든 프래그먼트를 무효화하게 할 수 있다. 사용자 프로파일을 사용하는 새로운 프래그먼트가 부가되거나 제거될 때, 종속성은 그 프래그먼트에 로컬이고, 애플리케이션의 무효화 메카니즘은 변하지 않는다. 예를 들어, 이 종속성은 이하와 같이 특정 사용자 프로파일에 대해 선언될 수 있다.

다수의 종속성이 공백으로 분리된 목록으로서 지정된다. 종속성은 대소문자의 구별이 있다. 프래그먼트 지원 캐시에서는 이들 종속성에 기초하여 무효화가 행해질 수 있다.

캐시 엔트리를 무효화하는 데 덮어쓰기 방법을 사용하는 데는 어떤 새로운 헤더 정보도 필요하지 않다. 프래그먼트 지원 캐시는 새로운 캐시 엔트리를 부가할 수 있는 프로토콜을 필요로 한다. 전술한 무효화 프로토콜과 같이, 이 덮어쓰기 프로토콜은 본 발명의 양호한 실시예의 기술에 의해 강제되지 않는다.

보안 문제에 대한 고려사항

프래그먼트를 지원하는 캐시에 의해 잠재적인 보안 요건들이 존중되어야만 한다. 사용자가 브라우저 형태의 애플리케이션을 동작시켜 URI를 클릭하면, 사용자는 그 애플리케이션 설계자에게 URI에 제공된 어떤 정보나 애플리케이션의 보안 정책에 따라 사용될 사용자의 쿠키도 처리하도록 위탁한다. 애플리케이션 설계자는 FRAGMENTLINK 태그를 사용하여 이 정보의 적절한 사용에 대한 어떤 책임을 캐시 에 위임하며, 본 발명의 양호한 실시예에 따라 구현된 캐시는 FRAGMENTLINK 태그가 그의 부모의 도메인이 아닌 다른 도메인에 링크할 수 없다는 규칙을 시행해야만 한다.

다른 프래그먼트를 포함하는 페이지는 결국에는 완전 확장된 페이지(fully-expanded page)로 조립되며, 이것은 브라우저와 애플리케이션 서버 사이의 경로를 따라 어느 곳에서든지 일어날 수 있다. 애플리케이션 개발자는 보안을 보장하기 위해 이하의 규칙, 즉 프래그먼트가 HTTPS를 필요로 하는 다른 프래그먼트를 포함하는 경우 그 프래그먼트는 HTTPS를 필요로 한다는 규칙을 따라야 한다. 이 규칙은 최상위 레벨 프래그먼트에 이르기까지 전파하도록 반복적으로 적용되어야만 한다. 이 규칙은 보호 프래그먼트가 비보호 프래그먼트 내부로부터 보지 못하도록 한다.

HTTPS 요청의 경우, "supports-fragments" 디렉티브를 갖는 FRAGMENT 헤더는 캐시가 HTTPS 세션을 종료시킬 수 있는 경우에만 포함되어야 한다. 그렇지 않은 경우, 캐시는 FRAGMENTLINK를 처리하기 위해 이를 보지 못할 수 있다. HTTPS를 종료시키지 않는 캐시는 여전히 HTTPS 요청에 대한 프래그먼트를 지원할 수 있다.

프래그먼트 지원 캐시용의 캐시 관리 유닛에 대한 설명

이제 도 6a를 참조하면, 본 발명의 양호한 실시예에 따른 컴퓨팅 장치 내의 프래그먼트 지원 캐시용의 캐시 관리 유닛을 나타낸 블록도가 도시되어 있다. 클라이언트 또는 서버이거나 아마도 클라이언트와 서버 기능 모두를 가질 수 있는 컴퓨팅 장치(600)는 컴퓨팅 장치(600)를 위해 객체를 캐싱하기 위한 기능을 갖는 프 래그먼트 지원 캐시 관리 유닛(602)을 포함한다. 예를 들어, 캐시 관리 유닛(602)은 다른 캐시 지원 장치들 사이의 데이터 경로 상에 있는 중간 캐시로서 작용할 수 있으며, 다른 경우에 캐시 관리 유닛(602)은 최종 사용자를 위해 클라이언트 장치에 객체를 캐싱할 수 있다.

프래그먼트 지원 캐시 관리 유닛(602)은 객체를 저장/캐싱하기 위한 객체 데이터베이스(604)를 포함하며, 이 데이터베이스는 객체와 연관되어 있는 메타데이터 및 객체와 함께 수신된 네트워크 헤더를 포함할 수 있다. 프래그먼트 지원 캐시 관리 유닛(602)은 또한 캐시 관리 동작에 관련된 정보를 저장하기 위한 데이터베이스를 포함하며, 이 관리 동작에 대해 여기서 언급하지만 도 6b 내지 도 6d를 참조하여 이하에 더욱 상세히 기술할 것이다. 규칙 목록 데이터베이스(606)는 URI 경로(608)와 그의 관련 규칙 목록(610)을 저장한다. 캐시 ID 데이터베이스(612)는 캐시 ID(614) 및 그의 관련 캐시 인덱스(616)를 저장한다. 종속성 데이터베이스(618)는 종속성 ID와 캐시 ID 사이의 매핑을 저장한다. 다수의 캐시 ID가 하나의 종속성과 연관될 수 있으며, 다수의 종속성이 하나의 캐시 ID와 연관될 수 있다.

프래그먼트 지원 캐시용의 캐시 관리 유닛 내에서의 일부 프로세스에 대한 설명

이제 도 6b를 참조하면, 본 발명의 양호한 실시예에 따른 프래그먼트를 포함하는 응답 메시지를 처리할 때 프래그먼트 지원 캐시 관리 유닛에 의해 사용될 수 있는 프로세스를 나타낸 플로우차트가 도시되어 있다. 다시 말하면, 도 6b는 응 답 메시지 내의 객체가 프래그먼트 지원 캐시에서 처리 및/또는 캐싱되어야 하는지와 그 방법을 결정하는 데 사용될 수 있는 프로세스를 제공한다.

이 프로세스는 도 6a에 도시한 것과 같은 프래그먼트 지원 캐시 관리 유닛을 포함하는 컴퓨팅 장치가 HTTP 응답 메시지 등의 응답 메시지를 수신(단계 6002)할 때 시작한다. 그 다음에, 캐시 관리 유닛이 응답 메시지 내의 메시지 보디 또는 페이로드 부분을 프래그먼트로서 처리해야하는지 비프래그먼트로서 처리해야 하는지 여부에 관한 결정이 행해진다(단계 6004).

응답 메시지가 비프래그먼트를 포함하는 것으로 처리되어야만 하는 경우, 기존의 HTTP 1.1 규칙을 사용하여 비프래그먼트 객체가 이 컴퓨팅 장치에, 즉 캐시 관리 유닛에 의해 캐싱되어야 하는지와 캐싱될 수 있는지 여부에 관한 결정이 행해진다(단계 6006). 예를 들어, 비프래그먼트 객체를 포함하는 응답 메시지는 그 객체가 캐싱되어서는 안된다는 표시를 가질 수 있으며, HTTP 응답 메시지에서 "Cache-Control" 헤더는 "no-cache" 디렉티브를 가질 수 있다. 객체가 캐싱되어야만 하고 또 그 객체가 캐싱될 수 있는 경우, 그 객체는 캐시 관리 유닛에 의해 적절히 저장된다(단계 6008). 어느 경우든지, 객체에 대한 캐싱 동작이 완료되고, 프로세스는 응답 메시지에 대한 임의의 다른 동작을 완료하기 위해 분기한다.

응답 메시지가 프래그먼트를 포함하는 것으로 처리되어야 하는 경우, 프래그먼트가 캐싱가능한지 여부에 관한 결정이 행해진다(단계 6010). 프래그먼트가 캐싱가능하지 않은 경우, 프로세스는 응답 메시지에 대한 임의의 다른 동작을 완료하기 위해 분기한다. 프래그먼트가 캐싱가능한 경우, 이 특정의 프래그먼트가 이 특정의 컴퓨팅 장치의 캐시에 캐싱되어야만 하는지에 관한 결정이 행해진다(단계 6012). 캐싱가능하지 않은 경우, 프로세스는 응답 메시지에 대한 임의의 다른 동작을 완료하기 위해 분기한다. 현재 처리되고 있는 프래그먼트가 현재의 컴퓨팅 장치에 캐싱되어야만 하는 경우, 그 프래그먼트는 캐시 관리 유닛에 의해 컴퓨팅 장치의 캐시에 저장된다(단계 6014).

프래그먼트가 캐싱되어 있거나, 현재의 컴퓨팅 장치에 캐싱되지 않은 것으로 결정되거나 캐싱 가능하지 않은 것으로 결정된 경우, 응답 메시지를 포워딩하기에 앞서 그 프레그먼트에 대해 페이지 조립이 필요한지 여부에 관한 결정이 행해진다(단계 6016). 페이지 조립이 필요한 경우, 페이지 조립이 수행된다(단계 6018). 어느 경우든지, 응답 메시지로부터의 프래그먼트 또는 비프래그먼트 객체는 현재의 컴퓨팅 장치의 캐시 관리 유닛에 의해 완전히 처리되고, 응답 메시지는 필요에 따라 수정되어 그의 목적지로 포워딩됨으로써(단계 6020), 이 프로세스를 완료한다.

이제 도 6c를 참조하면, 메시지 보디가 프래그먼트 객체를 포함하는지 여부를 결정하는 양호한 방법을 나타낸 플로우차트 단계가 도시되어 있다. 도 6c는 도 6b의 단계 6004를 대체할 수 있는 단계를 제공한다. 양호한 실시예에서, 수신된 응답 메시지가 페이로드 또는 메시지 보디를 프래그먼트로서 식별하는 메시지/프로토콜 헤더를 포함하는지 여부가 결정된다(단계 6022). 특히, 도 4에 도시한 바와 같이, 메시지의 페이로드가 프래그먼트 객체를 포함함을 나타내기 위해 FRAGMENT 헤더가 HTTP 메시지에 배치될 수 있다.

이제 도 6d를 참조하면, 프래그먼트 객체가 캐싱가능한지 여부를 결정하는 보다 상세한 방법을 나타내는 플로우차트 단계가 도시되어 있다. 도 6d는 도 6b의 단계 6010를 대체할 수 있는 단계를 제공한다. 이 실시예에서, 수신된 응답 메시지가 프래그먼트를 캐싱가능한 것으로 식별하는 캐시 제어용 프로토콜 헤더의 디렉티브를 포함하는지 여부가 결정된다(단계 6024).

이제 도 6e를 참조하면, 프래그먼트 객체가 캐싱가능한지 여부를 결정하는 양호한 방법을 나타낸 플로우차트 단계가 도시되어 있다. 도 6d와 유사한 방식으로, 도 6e는 도 6b의 단계 6010을 대체할 수 있는 단계를 제공한다. 양호한 실시예에서, 수신된 응답 메시지가 프래그먼트를 프래그먼트 지원 캐시에는 캐싱가능하고 프래그먼트 비지원 캐시에는 캐싱가능하지 않은 것으로 식별하는 메시지/프로토콜 헤더용 디렉티브를 갖는지 여부가 결정된다(단계 6026). 특히, 전술한 바와 같이, "Cache-Control" 헤더는 HTTP 메시지에 포함될 수 있으며, 객체의 캐싱을 방지하기 위해 "Cache-Control" 헤더에 "no-cache" 디렉티브를 배치하는 것이 표준 관행이고, 본 발명의 양호한 실시예는 프래그먼트 비지원 캐시에 대해서는 이러한 관행을 유지시키면서, "Cache-Control" 헤더의 사용을 확장하여 메시지 내의 프래그먼트가 프래그먼트 캐싱 규칙에 따라 캐싱가능함을 나타내기 위해 "fragmentrules" 디렉티브를 포함한다.

이제 도 6f를 참조하면, 프래그먼트 객체가 특정의 컴퓨팅 장치에 캐싱되어야만 하는지 여부를 결정하는 방법을 나타낸 플로우차트가 도시되어 있다. 도 6f는 도 6b의 단계 6012와 단계 6014를 대체할 수 있는 프로세스를 나타낸 것으로서, 이 프로세스가 호출될 때는, 이미 응답 메시지가 캐싱가능한 프래그먼트를 포함하는 것으로 결정된 것이다.

프로세스는 다운스트림 장치가 프래그먼트 지원 캐시를 갖는지 여부를 결정(단계 6028)하는 것으로 시작한다. 다운스트림 장치는 현재의 컴퓨팅 장치에 의해 응답 메시지를 포워딩받는 컴퓨팅 장치가 된다. 다운스트림 장치가 프래그먼트 지원 캐시를 갖지 않는 경우, 현재의 컴퓨팅 장치의 캐시 관리 유닛은 현재 처리되고 있는 프래그먼트 객체를 캐싱하고(단계 6030), 이 프로세스는 종료한다.

다운스트림 장치가 프래그먼트 지원 캐시를 갖는 경우, 현재 처리되고 있는 프래그먼트 캐시가 목적지 사용자/클라이언트 장치에 가장 가까운 프래그먼트 지원 캐시에만 저장되어야 하는지 여부에 관한 결정이 행해진다(단계 6032). 저장하지 않아도 되는 경우, 현재의 프래그먼트 객체는 현재의 컴퓨팅 장치에 캐싱될 수도 있으며, 프로세스는 단계 6030으로 분기하여 프래그먼트를 캐싱한다. 그렇지만, 프래그먼트가 목적지 사용자/클라이언트 장치에 가장 가까운 프래그먼트 지원 캐시에 저장되어야만 하는 경우, 현재의 컴퓨팅 장치는 프래그먼트를 캐싱하지 않고 프로세스는 종료한다.

이제 도 6g를 참조하면, 다운스트림 장치가 프래그먼트 지원 캐시를 갖는지 여부를 결정하는 양호한 방법을 나타낸 플로우차트 단계가 도시되어 있다. 도 6g는 도 6f의 단계 6028을 대체할 수 있는 단계를 제공한다. 도 6f 및 도 6g는 응답 메시지를 수신한 후에 개시되는 프로세스를 나타낸 것으로서, 응답 메시지는 현재의 컴퓨팅 장치에 의해 요청 메시지를 이전에 수신 및 포워딩한 결과로서 수신된다. 따라서, 응답 메시지가 수신될 때, 캐시 관리 유닛은 이전에 수신된 요청 메시지에 대한 어떤 형태의 상태 정보를 유지하고 있다.

다운스트림 장치가 프래그먼트 지원 캐시를 갖는지 여부를 결정하는 것에 관하여, 양호한 실시예에서는, 이전에 수신된 요청 메시지가 프래그먼트가 지원됨을 나타내는 디렉티브를 갖는 메시지/프로토콜 헤더를 포함하고 있었는지 여부에 관한 결정이 행해진다(단계 6034). 특히, 도 4에 도시한 바와 같이, FRAGMENT 헤더가 HTTP 메시지 내에 배치될 수 있으며, FRAGMENT 헤더가 "supports-fragements" 디렉티브를 포함할 수 있다.

이제 도 6h를 참조하면, 현재 처리되고 있는 프래그먼트 객체가 목적지 사용자/클라이언트 장치에 가장 가까운 프래그먼트 지원 캐시에만 저장되어야 하는지 여부를 결정하는 보다 구체적인 방법을 나타낸 플로우차트 단계가 도시되어 있다. 도 6h는 도 6f의 단계 6032를 대체할 수 있는 단계를 제공한다. 이 실시예에서, 현재의 컴퓨팅 장치에 의해 현재 처리되고 있는 응답 메시지는 응답 메시지 내의 프래그먼트가 목적지 사용자/장치에 가장 가까운 프래그먼트 지원 캐시에만 캐싱되어야 함을 나타내는 원서버로부터의 디렉티브를 포함하는 메시지/프로토콜 헤더를 갖는다(단계 6036).

이제 도 6i를 참조하면, 현재 처리되고 있는 프래그먼트 객체가 목적지 사용자/클라이언트 장치에 가장 가까운 프래그먼트 지원 캐시에만 캐싱되어야 하는지 여부를 결정하는 양호한 방법을 나타낸 플로우차트 단계가 도시되어 있다. 도 6h와 유사한 방식으로, 도 6i는 도 6f의 단계 6032를 대체할 수 있는 단계를 제공한다. 양호한 실시예에서, 현재의 컴퓨팅 장치에 의해 현재 처리되고 있는 응답 메시지가 프래그먼트 지원 캐시에 대해 응답 메시지 내의 프래그먼트가 목적지 사용자/장치에 가장 가까운 프래그먼트 지원 캐시에만 캐싱되어야 함을 알려주는 원서버로부터의 "private" 디렉티브를 포함하는 HTTP "Cache-Control" 메시지/프로토콜 헤더를 갖는다(단계 6038).

이제 도 6j를 참조하면, 응답 메시지를 현재의 컴퓨팅 장치에 반환하기에 앞서 페이지 조립이 필요한지 여부를 결정하는 방법을 나타낸 플로우차트가 도시되어 있다. 도 6j는 도 6b의 단계 6016와 단계 6018를 대체할 수 있는 프로세스를 나타낸 것이다. 이 프로세스가 호출될 때, 응답 메시지로부터의 프래그먼트는 필요에 따라 이미 캐싱되어 있다.

프로세스는 다운스트림 장치가 예를 들면 도 6f의 단계 6028과 유사한 방식으로 프래그먼트 지원 캐시를 갖는지 여부를 결정(단계 6040)하는 것으로 시작한다. 다운스트림 장치가 프래그먼트 지원 캐시를 갖는 경우, 페이지 조립이 필요하지 않으며, 프로세스는 완료된다. 다운스트림 장치가 프래그먼트 지원 캐시를 갖지 않는 경우, 현재 처리되고 있는 프래그먼트가 다른 프래그먼트로의 링크를 갖는지 여부에 관한 결정이 행해진다(단계 6042). 갖지 않는 경우, 페이지 조립이 필요하지 않으며, 프로세스는 완료한다. 다른 프래그먼트로의 링크가 현재의 프래그먼트에 존재하는 경우, 페이지 조립이 수행되고(단계 6044), 프로세스는 완료한다.

이제 도 6k를 참조하면, 현재 처리되고 있는 프래그먼트 객체가 다른 프래그먼트로의 링크를 갖는지를 결정하는 보다 구체적인 방법을 나타낸 플로우차트 단계가 도시되어 있다. 도 6k는 도 6j의 단계 6042를 대체할 수 있는 단계를 제공한다. 이 실시예에서, 현재의 프래그먼트가 포함될 프래그먼트의 소스 식별자 또는 소스 위치를 나타내는 태그된 엘리먼트(tagged element)를 포함하는 마크업 언어 엘리먼트를 갖는지 여부에 관한 결정이 행해진다(단계 6046). 특히, 도 3에 도시된 바와 같이, FRAGEMENTLINK 엘리먼트가 다른 프래그먼트로의 링크를 나타내기 위해 HTML 객체의 보디 내에 배치될 수 있다. HTTP 규격에서, 소스 식별자는 "Request-URI", 즉 요청할 자원을 식별하는 식별자로서 알려져 있다.

이제 도 6l을 참조하면, 현재 처리되고 있는 프래그먼트 객체가 다른 프래그먼트로의 링크를 갖는지 여부를 결정하는 대체 방법을 나타낸 플로우차트 단계가 도시되어 있다. 도 6k와 유사한 방식으로, 도 6l은 도 6j의 단계 6042를 대체할 수 있는 단계를 제공한다. 이 대체 실시예에서, 현재 처리되고 있는 응답 메시지가 응답 메시지의 메시지 보디 내의 프래그먼트, 즉 현재 처리되고 있는 프래그먼트가 다른 프래그먼트로의 링크를 가짐을 나타내는 디렉티브를 갖는 메시지/프로토콜 헤더를 포함하는지 여부에 관한 결정이 행해진다(단계 6048). 이것은 FRAGMENTLINK에 대한 프래그먼트를 스캔함으로써 결정될 수 있다. 그렇지만, 이것을 나타내기 위해 응답 헤더를 사용하는 것이 훨씬 더 효율적이며, 따라서 불필요한 스캔을 피하게 된다. 특히, 도 4에 도시한 바와 같이, FRAGMENT 헤더는 HTTP 메시지 내에 배치될 수 있으며, FRAGMENT 헤더는 "contains-fragments" 디렉티브를 포함할 수 있다. 이 디렉티브에 의해 현재의 컴퓨팅 장치의 캐시 관리 유닛은 FRAGMENTLINK 엘리먼트를 탐색하기 위해 현재의 프래그먼트의 스캔을 하지 않아도 된다.

이제 도 6m을 참조하면, 페이지 조립을 수행하는 프로세스를 나타낸 플로우차트가 도시되어 있다. 도 6m은 도 6b의 단계 6018 또는 도 6j의 단계 6044를 대체할 수 있는 단계를 제공한다. 프로세스는 응답 메시지로부터의 현재의 프래그먼트 내에 포함된 링크된 프래그먼트의 소스 식별자, 예를 들어 URI를 가져오는 것(단계 6050)으로 시작한다. 이어서, 링크된 프래그먼트는 소스 식별자를 사용하여 검색된다(단계 6052). 이어서, 검색된 프래그먼트 및 응답 메시지로부터의 현재의 프래그먼트는 합성되어 조립된 페이지, 즉 새로운 프래그먼트를 형성하고(단계 6054), 프로세스는 완료한다.

프래그먼트의 콘텐츠의 합성은 프래그먼트의 콘텐츠 유형에 대한 인코딩 규칙에 의존한다. 예를 들어, 마크업 언어 내의 각 엘리먼트는 프래그먼트로 볼 수 있으며, 자식 엘리먼트(child element)는 부모 엘리먼트(parent element)의 구분 태그(delimiting tag) 내에 태그된 엘리먼트(tagged element)를 삽입함으로써 부모 엘리먼트 내에 내장될 수 있다. 그렇지만, 이하에서 보다 상세히 기술하는 바와 같이 프래그먼트의 합성은 또한 헤더 및 프래그먼트의 특성값이 합성되는 방식에 대해 고려할 필요가 있다.

이제 도 6n을 참조하면, 프래그먼트 링크를 다수의 프래그먼트 링크로 선택적으로 확장하는 프로세스를 나타낸 플로우차트가 도시되어 있다. 다시 도 6m을 참조하면, 현재의 프래그먼트가 다수의 프래그먼트 링크를 포함하면, 다수의 링크된 프래그먼트를 검색하기 위해 단계 6050과 단계 6052가 필요한 횟수만큼 반복될 수 있으며, 이 모두는 합성되어 하나의 조립된 페이지를 형성할 수 있다. 이와 반 대로, 도 6n은 합성되어 하나의 조립된 페이지를 형성하는 다수의 프래그먼트에 대한 참조를 포함하기 위해 하나의 프래그먼트 링크가 콤팩트하게 표시될 수 있는 프로세스를 나타낸 것이다.

프로세스는 응답 메시지로부터의 현재의 프래그먼트 내의 프래그먼트 링크가 다수의 프래그먼트 링크로 확장되어야만 함을 나타내는지 여부를 결정(단계 6062)하는 것으로 시작한다. 확장되지 않아도 되는 경우, 프로세스는 완료되고, 확장해야 되는 경우, 프래그먼트 링크는 프래그먼트 링크와 연관된 정보를 사용하여 한 세트의 다수의 프래그먼트 링크로 확장된다(단계 6064).

이어서, 다수의 프래그먼트 링크가 루프에서 처리된다. 다수의 프래그먼트 링크의 세트 내의 그 다음 프래그먼트 링크가 획득되고(단계 6066), 프래그먼트 링크에 대한 소스 식별자가 획득된다(단계 6068). 이어서, 식별된 프래그먼트가 소스 식별자를 사용하여 검색된다(단계 6070). 다수의 프래그먼트 링크의 세트 내에 다른 프래그먼트 링크가 있는지 여부에 관한 결정이 행해지고(단계 6072), 있는 경우 프로세스는 단계 6066으로 분기하여 다른 프래그먼트 링크를 처리한다. 남아 있는 프래그먼트 링크가 없는 경우, 즉 모든 프래그먼트가 검색된 경우, 검색된 프래그먼트 모두가 원래의 응답 메시지로부터의 프래그먼트와 합성되고(단계 6074), 프로세스는 완료된다.

이제 도 6o를 참조하면, 응답 메시지로부터의 현재의 프래그먼트 내의 프래그먼트 링크가 다수의 프래그먼트 링크로 확장되어야 함을 나타내는지 여부를 결정하는 양호한 방법을 나타낸 플로우차트 단계가 도시되어 있다. 도 6o는 도 6n의 단계 6062를 대체할 수 있는 단계를 제공한다. 양호한 실시예에서, 응답 메시지로부터의 프래그먼트 내의 프래그먼트 링크에 대한 마크업 언어 태그된 엘리먼트가 그 프래그먼트 링크가 확장되어야만 함을 나타내는 속성을 포함하는지 여부에 관한 결정이 행해진다(단계 6076). 특히, 도 3에 도시한 바와 같이, FRAGMENTLINK 엘리먼트는 FOREACH 속성을 가질 수 있다.

이제 도 6p를 참조하면, 프래그먼트 링크를 그 프래그먼트 링크와 연관된 정보에 따라 다수의 프래그먼트 링크로 확장하는 프로세스를 나타낸 플로우차트가 도시되어 있다. 도 6p는 도 6n의 단계 6064를 대체할 수 있는 일련의 단계를 제공한다.

프로세스는 프래그먼트 링크에 대한 포함된 마크업 언어 태그된 엘리먼트로부터 쿠키 이름을 획득하는 것으로 시작한다(단계 6078). 도 3에 도시된 바와 같이, FOREACH 속성은 쿠키의 이름을 해석되는 문자열을 제공할 수 있다. 쿠키의 값이 검색되고(단계 6080), 쿠키의 값은 이름-값 쌍의 목록을 나타내는 문자열로서, 이 쌍은 이어서 루프에서 처리된다. 그 다음 이름-값 쌍은 쿠키 값으로부터 검색되고(단계 6082), 프래그먼트 링크는 이름-값 쌍을 사용하여, 예를 들어 이름-값 쌍을 질의 파라미터로서 사용하여 생성된다. 이어서, 쿠키 값에 다른 이름-값 쌍이 존재하는지에 관한 결정이 행해지고(단계 6086), 존재하는 경우, 프로세스는 단계 6082로 분기하여 다른 이름-값 쌍을 처리한다. 예를 들어, FRAGMENTLINK 엘리먼트는 각 이름-값 쌍마다 생성될 수 있으며, 그에 따라 원래의 FRAGMENTLINK 엘리먼트를 원래의 FRAGMENTLINK 엘리먼트를 대체하는 한 세트의 다수의 FRAGMENTLINK 엘리먼트로 확장한다. 남아 있는 이름-값 쌍이 없는 경우, 프로세스는 완료된다.

이제 도 6q를 참조하면, 프래그먼트에 대한 소스 식별자를 사용하여 프래그먼트를 검색하는 프로세스를 나타낸 플로우차트가 도시되어 있다. 도 6q는 도 6m의 단계 6052 또는 도 6n의 단계 6070을 대체할 수 있는 프로세스를 제공하는 것으로서, 도 6q의 프로세스는 프래그먼트에 대한 소스 식별자가 이미 결정된 후에 시작한다.

프로세스는 현재의 컴퓨팅 장치에 있는 로컬 캐시 내에 소스 식별자를 갖는 캐시 히트가 존재하는지 여부의 결정(단계 6092)으로 시작한다. 존재하는 경우, 프래그먼트가 캐시로부터 검색될 수 있고(단계 6094), 검색된 프래그먼트는 호출측 루틴으로 반환된다(단계 6096). 검색된 프래그먼트가 프래그먼트 링크를 포함하는 경우, 프로세스는 단계 6092로 루프백하여 프래그먼트 링크에 의해 식별되는 프래그먼트를 검색하고(단계 6098), 이에 따라 모든 자식 프래그먼트를 검색하기 위해 프로세스를 계속한다.

단계 6092에서 로컬 캐시 내에서 소스 식별자를 갖는 캐시 미스가 있었던 경우, 요청 메시지가 발생되고(단계 6100), 목적지 식별자로서 소스 식별자를 사용하여 전송된다(단계 6102). 도 4와 관련하여 설명한 바와 같이, 요청 메시지는 "supports-fragments" 디렉티브를 포함하게 되는데 그 이유는 현재의 컴퓨팅 장치가 프래그먼트 지원 캐시 관리 유닛을 포함하기 때문이다. 이어서 캐시 관리 유닛은 요청 메시지에 대한 응답을 기다린다(단계 6104). 양호하게는, 요청을 위한 쓰레드(thread)가 스폰(spawn)되고, 그 쓰레드는 컴퓨팅 장치가 다른 동작을 처리하 는 동안 응답을 기다릴 때 슬립(sleep) 상태에 있다.

응답 메시지가 수신된 후에, 응답 메시지의 메시지 보디 내의 프래그먼트가 검색되고(단계 6106) 캐싱된다(단계 6108). 전술한 바와 같이, 검색된 프래그먼트는 호출측 루틴으로 반환되고, 검색된 프래그먼트가 프래그먼트 링크를 포함하는 경우, 프로세스는 단계 6092로 루프백하여 프래그먼트 링크에 의해 식별되는 프래그먼트를 검색하며, 그에 따라 모든 자식 프래그먼트를 검색하기 위해 프로세스를 계속한다. 그렇지 않은 경우, 프래그먼트를 검색하는 프로세스는 완료된다.

이제 도 6r을 참조하면, 프래그먼트가 프래그먼트 지원 캐시 관리 유닛 내에 캐싱되어 있을 때 수행되는 처리의 일부를 나타낸 플로우차트가 도시되어 있다. 도 6r은 도 6b의 단계 6014 또는 도 6f의 단계 6030을 대체할 수 있는 프로세스를 제공하며, 도 6r의 프로세스는 프래그먼트가 현재의 컴퓨팅 장치에서 응답 메시지로 이미 수신된 후에 시작한다.

프로세스는 프래그먼트와 연관된 소스 식별자, 예를 들면 응답 메시지 내의 URI를 검색(단계 6112)하는 것으로 시작하며, 규칙 목록이 응답 메시지 내에 존재하는 경우 그 프레그먼트와 연관된 규칙 목록도 함께 검색한다(단계 6114). 규칙 목록은 처리되고 있는 요청에 대한 캐시 히트를 이루려고 시도할 때 나중에 사용하기 위해 URI 경로와 관련하여 규칙 목록 데이터베이스에 저장된다(단계 6116). 규칙 목록은 응답 메시지 내에 프래그먼트를 캐싱하기 위해 캐시 ID의 생성을 안내하는 데 사용된다(단계 6118).

이어서, 캐시 ID는 캐시 인덱스를 생성하는 데 사용되며(단계 6120), 캐시 인덱스는 응답 메시지로부터의 프래그먼트가 저장되어야만 하는 프래그먼트 저장 장치, 즉 캐시 메모리 내에서의 위치를 결정하는 데 사용된다. 캐시 인덱스는 해싱 알고리즘을 통해 캐시 ID를 부여함으로써 생성될 수 있다. 본 발명의 양호한 실시예의 기술은 캐시 관리 유닛의 각 구현이 프래그먼트에 수반되는 캐시 ID 규칙을 사용하는 기술에 부합하는 방식으로 캐시 ID가 생성된 후에 캐시 인덱스를 계산하기 위해 그 자신만의 알고리즘을 이용할 수 있다는 점에서 유연성이 있다.

이어서, 프래그먼트는 프래그먼트에 수반된 HTTP 응답 메시지 내의 헤더 또는 등가의 정보를 포함한 임의의 다른 필요한 정보 또는 메타 데이터와 함께 캐시에 저장되고(단계 6122), 이어서 새로 생성된 캐시 ID가 캐시 인덱스와 관련하여 저장된다(단계 6124). 다른 대안에서, 캐시 인덱스는 필요할 때마다 계산될 수 있으며, 캐시 인덱스를 저장할 필요가 없을 수 있다. 다른 대안으로서, 캐시 ID는 어떤 유형의 저장 인덱스 또는 데이터베이스 식별자로서 직접 사용될 수 있으며, 별도의 캐시 인덱스를 계산할 필요가 없을 수 있다.

응답 메시지 내의 프래그먼트와 연관된 종속성이 있는 경우, 종속성이 검색되어(단계 6126), 프래그먼트의 캐시 ID와 관련하여 저장된다(단계 6128).

이제 도 6s를 참조하면, 프래그먼트가 캐시 관리 유닛을 포함하는 컴퓨팅 장치에 캐싱되어 있는 경우 그 프래그먼트를 획득하기 위해 프래그먼트 지원 캐시 관리 유닛에 의해 사용될 수 있는 프로세스를 나타낸 플로우차트가 도시되어 있다. 다시 말하면, 도 6s는 예를 들어 요청 메시지의 검사에 응답하여 프래그먼트 지원 캐시에서 캐시 히트가 발생될 수 있는지를 결정하는 데 사용될 수 있는 프로세스를 나타낸 것이다.

프로세스는 요청과 관련된 소스 식별자, 예를 들면 URI 경로를 검색(단계 6132)하는 것으로 시작한다. 이어서, 규칙 목록 데이터베이스가 검색되어 URI 경로에 대한 규칙 목록 데이터베이스 내에 캐시 ID 규칙 목록이 존재하는지 여부를 결정한다(단계 6134). URI 경로와 관련된 규칙 목록이 존재하지 않는 경우, 캐시 미스 표시가 반환되고(단계 6136), 프로세스가 완료된다.

URI 경로와 관련된 규칙 목록이 있는 경우, 캐시 ID가 생성될 수 있는 것으로 가정하여, 즉 적어도 하나의 규칙이 성공적으로 평가되는데 필요한 모든 정보가 존재하는 것으로 가정하여 규칙 목록 내의 규칙들은 캐시 ID를 생성하는 데 사용된다(단계 6138). 이어서, 프래그먼트를 저장하기 위해 캐시 ID가 이미 사용되었는지, 즉 캐시 히트가 있었는지에 관한 결정이 행해진다(단계 6140). 그렇지 않은 경우, 캐시 미스 표시가 반환되고, 프로세스는 완료된다.

캐시 히트가 있는 경우, 캐시 ID와 관련된 캐시 인덱스가 검색되고(단계 6142), 이에 의해 캐시 인덱스를 사용하여 적절한 프래그먼트의 차후의 검색이 가능하게 된다(단계 6144). 이어서, 프래그먼트가 요청자에게 반환되고(단계 6146), 그에 따라 프로세스가 완료한다.

이제 도 6t를 참조하면, 복수의 프래그먼트와 연관된 헤더 값과 특성 값을 합성하는 프로세스를 나타내는 플로우차트가 도시되어 있다. 도 6t는 도 6m의 단계 6054 또는 도 6n의 단계 6074를 대체할 수 있는 프로세스를 제공한다. 합성될 각 프래그먼트는 응답 메시지로 수신된 것인지 컴퓨팅 장치의 캐시로부터 검색된 것인지에 상관없이 응답 메시지로 각 프래그먼트와 함께 수신된 연관된 한 세트의 프로토콜 헤더를 갖는다. 헤더 및 특성의 값은 각 헤더 또는 특성에 대해 하나의 디렉티브/값으로 합성된다.

프로세스는 합성될 모든 프래그먼트의 그 다음 헤더 유형의 헤더 값을 획득(단계 6152)하는 것으로 시작한다. 이어서, 적절한 합성 함수가 이들 헤더 값 모두에 대해 적용되고(단계 6154), 이어서 합성된 헤더 값이 조립된 페이지 또는 프래그먼트에 대해 설정되거나 그와 연관된다(단계 6156). 이어서, 처리할 다른 헤더 유형이 있는지 여부에 관한 결정이 행해지며(단계 6158), 있는 경우 프로세스는 단계 6152로 다시 분기하여 다른 헤더 유형을 처리하게 된다.

모든 헤더가 처리된 후에, 프로세스는 합성될 모든 프래그먼트의 그 다음 특성 유형에 대한 특성 값을 검색한다(단계 6160). 이어서, 이들 특성 값 모두에 대해 적절한 합성 함수가 적용되고(단계 6162), 이어서 합성된 특성 값이 조립된 페이지 또는 프래그먼트에 대해 설정되거나 그와 연관된다(단계 6164). 이어서, 처리할 다른 특성 유형이 있는지 여부에 관한 결정이 행해지고(단계 6166), 있는 경우 프로세스는 다시 단계 6160으로 분기하여 다른 특성 유형을 처리하고 그렇지 않은 경우 프로세스는 완료한다.

이제 도 6u를 참조하면, 헤더 유형 및 특성 값에 대한 일련의 합성 함수를 나타내는 한 세트의 단계들을 나타낸 플로우차트가 도시되어 있다. 도 6u는 도 6t의 단계 6154 또는 단계 6162에서 사용될 수 있는 어떤 합성 함수를 나타낸 것이며, 도시된 합성 함수가 캐시 관리 유닛에 존재할 수 있는 합성 함수의 전체 목록 은 아니다.

프로세스는 HTTP "Content-Length" 필드가 합성되고 있는지를 결정(단계 6168)하는 것으로 시작한다. 합성되지 않는 경우, 그 다음 단계는 건너뛰고, 그렇지 않은 경우, 합성된 "Content-Length" 필드의 값은 모든 "Content-Length" 필드의 합이 된다(단계 6170).

프로세스는 계속하여 HTTP "Last-Modified" 필드가 합성되고 있는지를 결정한다(단계 6172). 합성되지 않는 경우, 그 다음 단계는 건너뛰고, 그렇지 않은 경우, 합성된 "Last-Modified" 필드의 값은 모든 "Last-Modified" 필드 중 최후의 것이 된다(단계6174).

프로세스는 계속하여 만료 시간 값(expiration time value)이 합성되고 있는지를 결정한다(단계 6176). 합성되지 않는 경우, 그 다음 단계는 건너뛰고, 그렇지 않은 경우, 합성된 만료 시간 값의 값이 이하의 고려 사항에 따라 설정된다(단계 6178). 프래그먼트 내의 시간에 기초하여 무효화되는 응답 헤더와 조립된 페이지 내의 응답 헤더 사이의 관계가 프래그먼트를 지원하는 캐시에 의해 존중되어야만 한다. 조립 프로세스는 이하의 방식으로 조립된 페이지에 대한 무효화 시간을 결정해야만 한다. 첫째, 절대 시간인 "Expires" 헤더로부터, 상대 시간인 "max-age" 디렉티브를 갖는 "Cache-Control" 헤더, 및 최상위 레벨 프래그먼트 및 모든 반복적으로 포함된 프래그먼트를 포함한 모든 프래그먼트 중 가장 짧은 등가 시간 구간인 각 프래그먼트의 "Date" 헤더가 계산된다. 이것은 "Date" 헤더 값을 사용하여 절대 시간을 델타 시간으로 변환함으로써 행해진다. 이 값은 "minimumRelativeTime"라고 할 수 있다. 둘째, 조립된 페이지의 "Expires" 헤더 내의 값이 "Date" 헤더내의 값 + 계산된 minimumRelativeTime 값으로 설정된다. 이것은 HTTP/1.1 "Cache-Control" 헤더를 지원하지 않는 캐시에 필요하다. 셋째, 조립된 페이지의 "max-age"디렉티브는 계산된 minimumRelativeTime 값으로 설정되는데 그 이유는 "Expires" 헤더가 보다 제한적임에도 불구하고 "max-age" 디렉티브가 "Expires" 헤더에 우선하도록 HTTP/1.1 규격이 강제하기 때문이다. 이것은 HTTP/1.1을 지원하는 캐시에 필요하다.

프로세스의 마지막 단계는 콘텐츠 인코딩 유형을 적절한 값으로 설정한다(단계 6180). 제1 대안에서, HTTP/1.1 규격에 따르면, "no-transform" 캐시-제어 디렉티브가 합성되고 있는 헤더 중 하나에 존재하지 않기만 하다면, 새로운 인코딩이 클라이언트에 타당한 것으로 알려진 경우 캐시는 콘텐츠-인코딩을 수정할 수 있다. 제2 대안에서, 포함된 프래그먼트의 콘텐츠-인코딩은 최상위 레벨 프래그먼트와 동일한 것으로 변경된다.

이제 도 6v를 참조하면, 요청 메시지를 처리할 때 프래그먼트 지원 캐시 관리 유닛에 의해 사용될 수 있는 프로세스를 나타낸 플로우차트가 도시되어 있다. 응답 메시지의 처리를 나타낸 도 6b와 달리, 도 6v는 요청 메시지의 처리와 연관된 단계들의 일부를 나타낸 것이다.

프로세스는 요청 메시지를 수신하는 것으로 시작하고(단계 6192), 그 후에 소스 식별자는 요청 메시지로부터 검색된다(단계 6194). 소스 식별자는 로컬 캐시로부터 식별된 객체 또는 프래그먼트를 획득(즉, 캐시 히트가 일어남)하거나 또는 요청에 의해 객체 또는 프래그먼트를 검색(즉, 캐시 미스가 일어남)하는 데 사용된다(단계 6196). 캐시 히트 또는 캐시 미스와 연관된 프로세스는 도 6q와 관련하여 전술하였다. 어느 경우든지, 페이지 조립이 필요한 경우, 페이지 조립이 수행되고(단계 6198), 페이지 조립와 연관된 프로세스는 도 6t와 관련하여 전술하였다. 이어서, 수신된 요청 메시지에 대해 응답 메시지가 반환되고(단계 6200), 그에 따라 프로세스가 완료한다.

이제 도 6w를 참조하면, 본 발명의 양호한 실시예에 따라 무효화 메시지를 처리할 때 프래그먼트 지원 캐시 관리 유닛에 의해 사용될 수 있는 프로세스를 나타낸 플로우차트가 도시되어 있다. 전술한 바와 같이, 본 발명의 양호한 실시예의 기술은 어떤 특정의 무효화 알고리즘을 강제하지 않으며, 도 6w에 도시된 프로세스는 단지 종속성 ID의 사용의 일례에 불과하다.

프로세스는 컴퓨팅 장치에 캐싱될 수 있는 프래그먼트를 게시 또는 서비스해온 원서버로부터 무효화 요청 메시지를 컴퓨팅 장치에서 수신하는 것으로 시작한다(단계 6202). 이 요청은 종속성 id의 목록을 포함한다. 원서버는 상충되는 종속성을 생성하지 않는 것으로 가정하며, 적어도 그의 도메인 이름을 포함하는 애플리케이션 ID를 갖는 종속성에 적격성을 부여함으로써 전세계적으로 고유한 종속성이 유지될 수 있는 것으로 가정한다. 통상 애플리케이션 ID와 무효화 프로세스(invalidator)를 연관시키기 위해 인증이 필요하며, 따라서 무효화 프로세스는 그 자신의 콘텐츠만을 무효화할 수 있다.

이어서, 종속성 데이터베이스 내의 어떤 종속성이 수신된 메시지 내의 하나 이상의 종속성과 일치하는지 여부에 관한 결정이 행해지고(단계 6210), 일치하는 경우, 일치하는 종속성과 연관된 캐시 ID의 목록이 검색된다(단계 6212). 이어서, 캐시 ID는 관련 프래그먼트를 캐시로부터 제거하는 데 사용된다(단계 6214). 필요하거나 적절한 경우, 관련된 규칙 목록 및 종속성도 제거될 수 있다.

선택적인 응답이 무효화 요청 메시지의 발신자로 반환될 수 있다(단계 6216). 종속성 일치가 없는 경우, 프로세스는 단계 6216으로 분기한다. 어느 경우든지, 프로세스는 완료한다.

프래그먼트 지원 캐시의 캐시 관리 유닛 사이의 어떤 조정의 일례

이제 도 7a를 참조하면, 어떤 캐시가 프래그먼트 조립을 수행할 때를 설명하기 위해 웹 애플리케이션 서버와 클라이언트 사이의 데이터 흐름의 일부를 나타낸 블록도가 도시되어 있다. 클라이언트 장치(700)는 프래그먼트 비지원 캐시 관리 유닛(702)를 포함하며, 이 관리 유닛은 페이지에 대한 요청을 생성하여 그 요청을 중간 서버(704)로 전송한다. 클라이언트 장치 몰래, 요청된 페이지는 실제로 부모 프래그먼트와 자식 프래그먼트로의 링크를 포함한다. 중간 서버(704)는 요청을 수신하지만, 캐시 관리 유닛(704)은 프래그먼트를 지원하지 않으며 요청된 페이지를 캐싱한 것도 가지고 있지 않다.

이어서, 요청은 프래그먼트 지원 캐시 관리 유닛(710)을 구비하는 중간 서버(708)로 포워딩된다. 중간 서버(708)는 요청된 페이지를 캐싱한 것을 가지고 있지 않으며, 중간 서버(708)는 요청 메시지를 프래그먼트 비지원 캐시 관리 유닛(714)을 구비하는 중간 서버(712)로 전송하기에 앞서 요청 메시지에 "Fragment: supports-fragments" 헤더를 부가한다. 중간 서버(712)는 요청된 페이지를 캐싱한 것을 갖지 않으며 요청 메시지를 프래그먼트 지원 캐시 관리 유닛(718)을 구비하는 웹 애플리케이션 서버(716)로 전송/포워딩한다.

"Fragment: supports-fragments" 헤더를 포함하는 착신 요청 메시지로부터, 웹 애플리케이션 서버(716)는 다운스트림 컴퓨팅 장치가 페이지 어셈블러로서 작용할 수 있는 프래그먼트 지원 캐시 관리 유닛을 갖는 것으로 결정할 수 있다. 따라서, 응답에서 조립된 전체 페이지를 반환하는 대신에, 웹 애플리케이션 서버(716)는 FRAGMENTLINK 자식 프래그먼트를 포함하는 부모 프래그먼트를 갖는 응답을 반환한다. 중간 서버(712)는 프래그먼트를 지원하지 않으며, 따라서 응답을 포워딩할 뿐이다.

프래그먼트 지원 캐시 관리 유닛(710)은 자신이 최종 사용자 또는 클라이언트에 가장 가까운 프래그먼트 지원 캐시임을 인식하며, 원래의 요청은 "Fragment: supports-fragments" 헤더를 포함하지 않았으며, 따라서 프래그먼트 지원 캐시 관리 유닛(710)은 자신이 응답을 반환하기에 앞서 페이지 조립을 수행해야만 하는 것으로 결정한다. 페이지 조립 프로세스 동안, 프래그먼트 지원 캐시 관리 유닛(710)은 부모 프래그먼트에 링크되어 있는 자식 프래그먼트를 요청 및 수신하고, 자식 프래그먼트 및 부모 프래그먼트는 하나의 조립된 페이지로 합성되며, 조립된 페이지는 클라이언트 장치로 반환된다. 중간 서버(704)는 응답을 클라이언트 장치(700)로 포워딩하고, 이 클라이언트 장치는 이어서 조립된 페이지를 최종 사용자에게 제공한다. 중간 서버(704)나 클라이언트 장치(700) 어느 것도 조립된 페이지를 캐싱하지 않는데 그 이유는 응답에 이들 장치가 조립된 페이지를 캐싱하지 못하도록 하는 "no-cache" 디렉티브 표시가 있기 때문이다. 중간 서버(708)는 부모 프래그먼트 및 자식 프래그먼트 모두를 캐싱한다.

이제 도 7b를 참조하면, 한 세트의 장치에 대해 최종 사용자 또는 클라이언트 장치에 가장 가까운 캐시에 프래그먼트를 캐싱하도록 지시할 수 있는 방법을 설명하기 위해 웹 애플리케이션 서버와 클라이언트 사이의 데이터 흐름의 일부를 나타낸 블록도가 도시되어 있다. 클라이언트 장치(720)는 객체에 대한 요청을 생성하여 그 요청을 중간 서버(724)로 전송하는 프래그먼트 비지원 캐시 관리 유닛(722)를 구비한다. 클라이언트 장치 몰래, 요청된 객체는 실제로 프래그먼트이다. 중간 서버(724)는 요청을 수신하고, 캐시 관리 유닛(726)이 프래그먼트를 지원하지만 요청된 프래그먼트를 캐싱한 것을 갖지 않기 때문에, 캐시 관리 유닛(726)은 요청에 "Fragment: supports-fragments" 헤더를 부가하고 그 요청을 목적지 서버로 포워딩한다.

중간 서버(728)는 그 요청을 수신하고, 캐시 관리 유닛(730)이 요청된 프래그먼트를 캐싱한 것을 갖지 않기 때문에, 프래그먼트 지원 캐시 관리 유닛(730)은 "Fragment: supports-fragments" 헤더가 요청 메시지 내에 포함되도록 보장하고 그 요청을 목적지 서버로 포워딩한다. 중간 서버(732)는 프래그먼트를 지원하지 않고 요청된 객체를 캐싱한 것을 갖지 않는 캐시 관리 유닛(734)을 포함하며, 그 요청을 포워딩한다.

"Fragment: supports-fragments" 헤더를 포함하는 착신 요청 메시지로부터, 웹 애플리케이션 서버(736)는 다운스트림 컴퓨팅 장치가 프래그먼트 지원 캐시 관리 유닛을 갖는 것으로 결정할 수 있다. 따라서, 웹 애플리케이션 서버(736)는 프래그먼트를 포함하는 응답을 반환하는 것이 적절한 것으로 결정할 수 있다. 그렇지만, 웹 애플리케이션 서버(736)는 "Cache-Control: private" 헤더를 갖는 응답 메시지에 표시를 하고 그 결과 응답 내의 프래그먼트는 최종 사용자 또는 클라이언트 장치에 가장 가까운 프래그먼트 지원 캐시에 의해서만 캐싱되고, 캐시 관리 유닛(738)은 응답 내의 프래그먼트를 캐싱하지 않는다.

중간 서버(732)는 프래그먼트를 지원하지 않는다. 캐시 관리 유닛(734)은 "private" 디렉티브를 인식하며, 따라서 그 프래그먼트를 캐싱하지 않고, 중간 서버(732)는 그 응답을 포워딩할 뿐이다. 이와 반대로, 캐시 관리 유닛(730)은 프래그먼트를 지원하지만, 다운스트림 장치가 최종 사용자 또는 클라이언트 장치에 훨씬 더 가까운 프래그먼트를 캐싱할 수 있도록 원래의 요청이 "Fragment: supports-fragment" 헤더로 표시되어 있는 것을 인식한다. 따라서, 캐시 관리 유닛(730)은 "private" 디렉티브를 응답 내의 프래그먼트를 캐싱하지 말라는 지시로서 해석한다.

캐시 관리 유닛(726)도 프래그먼트를 지원하지만 다운스트림 장치가 최종 사용자 또는 클라이언트 장치에 보다 가까운 프래그먼트를 캐싱할 수 없도록 원래의 요청이 "Fragment: supports-fragment" 헤더로 표시되어 있지 않다는 것을 인식한다. 따라서, 캐시 관리 유닛(726)은 "private" 디렉티브를 응답 내의 프래그먼트를 캐싱하라는 지시로서 해석한다. 이어서, 중간 서버(724)는 응답을 클라이언트 장치(720)로 포워딩하고, 캐시 관리 유닛(722)은 프래그먼트를 지원하지 않으며 따라서 "private" 디렉티브를 그 프래그먼트를 캐싱하지 말라는 지시로서 인식한다.

역할별 또는 카테고리별 콘텐츠의 캐싱을 지원하는 데 사용되는 프래그먼트 지원 캐시의 일례

이제 도 8a 내지 도 8d를 참조하면, 동적 역할별 또는 카테고리별 콘텐츠의 캐싱이 본 발명의 양호한 실시예에 따라 달성될 수 있음을 설명하기 위해 클라이언트, 중간 프래그먼트 지원 캐시 또는 서버 내에서 일어나는 처리 단계들의 일부를 나타낸 데이터 흐름도가 도시되어 있다. 어떤 웹 콘텐츠는 특정 조직과의 연관 또는 조직 내에서의 역할에 기초하여 한 그룹의 사용자에 특유한 것이 되도록 카테고리화될 수 있다. 예를 들어, 기업은 제1 회사에 대해서는 그의 제품에 대한 가격 데이터베이스의 제1 버전을 게시하고 제2 회사에 대해서는 그의 제품에 대한 가격 데이터베이스의 제2 버전을 게시할 수 있다. 예를 들어, 제2 회사는 그 기업의 제품을 대량으로 구매하는 것에 대한 대가로 상당한 총량 할인을 받을 수 있다.

제1 회사의 제1 직원이 그 기업의 웹 사이트를 방문할 때, 이 직원은 제1 회사에 대한 가격 정보를 보여주는 웹 페이지를 수신해야만 한다. 가격 정보는 비교적 빈번하게 변할 수 있으며, 따라서 가격 정보는 정적 콘텐츠에 비해 캐싱하기 보다 어려울 것이다. 제2 회사의 직원이 그 기업의 웹 사이트를 방문할 때, 이 직원은 제2 회사에 대한 가격 정보를 보여주는 웹 페이지를 수신해야만 한다.

본 발명의 양호한 실시예에서, 서로 다른 고객 회사의 직원에 대해 생성된 웹 페이지는 동일 회사의 다른 직원들이 이용가능하도록 캐싱될 수 있다. 제1 회 사의 제2 직원이 그 기업의 웹 사이트를 방문할 때, 이 직원은 동일 회사의 제1 직원에 대해 캐싱되어 있던 웹 페이지를 수신할 수 있다. 다시 말하면, 그 기업의 콘텐츠는 서로 다른 조직, 즉 서로 다른 고객 회사에 의한 사용을 위해 카테고리화되어 있다.

제2 일례를 사용하여, 회사는 인적 자원 정보를 포함하는 웹 사이트를 가질 수 있지만, 그 정보의 일부는 그 회사의 관리직급의 직원만이 보도록 제한되어 있어야만 한다. 그렇지만, 관리직급 정보가 동적 콘텐츠일 수 있지만, 그 정보를 보는 각 관리자를 위해 관리직급 정보의 다수의 복사본을 캐싱할 할 필요가 없어야만 한다. 본 발명의 양호한 실시예에 따르면, 예를 들면 관리직 대 비관리직과 같은 역할별 콘텐츠가 캐싱될 수 있고, 조직 내에서의 사용자의 역할이 캐싱된 콘텐츠의 어느 세트가 사용자에게 반환될지의 결정에 도움을 주기 위해 사용될 수 있다.

이들 일례는 카테고리 구별을 사용하여 일반적인 방식으로 기술될 수 있다. 콘텐츠의 카테고리의 개념은 콘텐츠에 액세스하는 사용자에 적용될 수 있는 특성에 기초하여 사용자 역할, 단체의 엔티티 등에 적용될 수 있다. 도 8a 내지 도 8d는 본 발명의 양호한 실시예가 카테고리별 콘텐츠를 캐싱하는 데 사용될 수 있는 방식의 일반적인 일례를 제공한다.

도 8a를 참조하면, 클라이언트 애플리케이션, 예를 들어 브라우저는 페이지 요청을 생성하고(단계 802), 이를 애플리케이션 서버로 전송한다(단계 804). 프래그먼트 지원 중간 캐시는 요청된 페이지의 복사본을 가지고 있지 않으며, 따라서 캐싱된 복사본을 반환할 수 없다. 애플리케이션 서버는 요청된 페이지가 어떤 카테고리의 사용자만이 보도록 제한되어 있다고 결정하지만 애플리케이션 서버는 그 요청이 요청자를 제한된 카테고리의 사용자의 일원으로서 식별해주는 요구된 쿠키를 수반하지 않았음을 검지한다(단계 806). 서버는 인증 시도 페이지(authentication challenge page)를 생성하고(단계 808), 이를 클라이언트에게 전송하며(단계 810), 인증 시도 페이지는 캐싱가능하지 않은 것으로 표시되고 따라서 중간 캐시는 이를 캐싱하지 않는다.

클라이언트는 인증 시도 페이지를 수신하고 이를 사용자에게 제시하며(단계 812), 이어서 사용자는 사용자 ID와 패스워드를 제공하며(단계 814), 이들은 다시 서버로 전송된다(단계 816). 서버가 사용자의 정보를 인증하고(단계 818), 사용자 ID를 사용하여 식별된 사용자가 어느 사용자 카테고리에 속하는지를 결정한다(단계 820). 관리직 역할 등의 사용자 카테고리를 결정한 후에, 서버는 결정된 사용자 카테고리의 식별을 가능하게 해주는 정보를 포함하는 카테고리 쿠키를 생성한다(단계 822). 최초 요청된 페이지도 생성되고(단계 824), 페이지 및 카테고리 쿠키가 클라이언트로 전송된다(단계 826).

이 시점까지, 중간 캐시는 어떤 콘텐츠도 캐싱하지 않는다. 그렇지만, 현재 반환되고 있는 페이지는 프래그먼트 지원 캐싱 규칙에 따라 캐싱가능한 것으로 표시되며, 따라서 중간 캐시는 그 페이지에 대한 식별자를 사용하는 페이지, 그 페이지에 수반되는 카테고리 캐시, 및 클라이언트로의 응답 메시지에 수반되는 프래그먼트 캐싱 규칙에서 중간 캐시가 사용하도록 지시받은 다른 적절한 정보를 저장한다(단계 828). 클라이언트가 요청된 페이지를 수신한 후에, 그 페이지는 사용자에 게 제시되고(단계 830), 수반하는 카테고리 쿠키는 클라이언트 애플리케이션에 의해 그의 쿠키 캐시 내에 저장된다(단계 832).

도8b를 참조하면, 이전에 발생된 카테고리 쿠키를 갱신하는 일례가 도시되어 있다. 클라이언트 애플리케이션은 예를 들면 동일한 도메인으로부터 도 8a에 도시된 페이지 요청과 유사한 페이지 요청을 생성한다(단계 842). 그렇지만, 사용자는 사용자의 카테고리가 변경되게 하는 어떤 동작을 수행한다. 예를 들어, 사용자는 어떤 그룹의 직원의 관리자로서의 사용자의 역할과 관련하여 페이지를 보고 있을 수 있으며, 이어서 그 사용자는 재무 담당자로서의 사용자의 역할과 관련된 페이지를 보려고 할 수도 있다. 사용자는 이미 인증을 받았기 때문에, 서버는 다른 인증 프로세스를 수행하지 않아야 한다. 그렇지만, 서버는 그 사용자에 대해 새로운 카테고리 쿠키를 발생해야 한다.

페이지 요청은 수반하는 카테고리 쿠키와 함께 서버로 전송된다(단계 844). 중간 캐시는 요청된 페이지를 가지고 있지 않으며, 따라서 캐시 미스가 된다. 서버는 클라이언트가 새로운 카테고리 쿠키 값을 요청하는 동작을 요청하고 있다고 결정하고(단계 846), 새로운 카테고리 쿠키를 발생한다(848). 요청된 페이지도 생성되고(단계 850), 요청된 페이지 및 새로 발생된 카테고리 쿠키는 반환된다(단계 852). 이어서, 중간 캐시는 새로운 쿠키 값에 따라 페이지를 저장한다(단계 854). 클라이언트는 요청된 페이지를 수신하여 제시하고(단계 856), 새로운 쿠키 값은 클라이언트에서 쿠키 캐시에 저장된다(단계 858). 이와 같이, 중간 캐시는 카테고리 쿠키가 갱신될 때 갱신된다.

도 8c를 참조하면, 동일한 카테고리 쿠키를 계속하여 사용하면 그 결과 여전히 캐시 미스가 일어날 수 있는 방식의 일례가 도시되어 있다. 클라이언트 애플리케이션은 페이지 요청을 생성하여(단계 862), 이를 수반하는 카테고리 쿠키와 함께 서버로 전송한다(단계 864). 중간 캐시는 요청된 페이지를 가지고 있지 않으며, 따라서 캐시 미스가 일어난다. 서버는 카테고리 쿠키 내의 값을 사용하여 어떤 유형의 콘텐츠를 동적으로 결정하고 적절한 페이지를 생성하며(단계 866), 생성된 페이지 및 변경되지 않은 카테고리 쿠키가 반환된다(단계 868). 중간 캐시는 페이지를 저장하고(단계 870), 이를 클라이언트로 포워딩한다. 클라이언트는 요청된 페이지를 수신하여 제시하고(단계 872), 카테고리 쿠키가 변하지 않았기 때문에, 클라이언트는 쿠키 캐시 내의 카테고리 값을 덮어쓰는 것으로 도시되어 있지 않다.

본 발명의 양호한 실시예에 따르면, 단계 828, 854 및 870에서, 중간 캐시는 서버에 의해 응답 메시지에 배치되었던 프래그먼트 캐싱 규칙에 따라 응답 메시지로부터의 페이지의 복사본을 저장한다. 본 발명의 양호한 실시예는 페이지와 관련된 URI만이 캐싱 목적으로 사용되는 경우 그렇지 않았으면 동일한 것으로 식별될 수 있는 동일한 페이지의 2가지 서로 다른 버전을 구별하기 위해 캐시 ID 동작에서 쿠키를 사용할 수 있게 해준다. 보다 중요한 것은 카테고리 쿠키가 차후에 캐시 탐색 프로세스에서 사용될 수 있도록 페이지가 카테고리 쿠키와 연관되어 캐싱될 수 있으며, 그에 따라 도 8d에 도시된 바와 같이 주장된 카테고리 쿠키(asserted category cookie)에서의 유사성에 기초하여 캐시 히트가 확립될 수 있다는 것이다.

도 8d를 참조하면, 2명의 서로 다른 사용자가 동일한 카테고리 쿠키를 사용 하면 그 결과 여전히 서로 다른 사용자에 의한 하나의 페이지에 대한 액세스에 캐시 히트가 일어날 수 있는 방식에 대한 일례가 도시되어 있다. 이 일례에서, 서로 다른 사용자는 도 8c에 도시한 이전의 일례에서 제1 사용자와 동일한 페이지에 액세스하고 있다. 그렇지만, 제2 사용자는 제1 사용자와 동일한 카테고리의 사용자에 속해있다. 다시 말하면, 2명의 사용자가 동일한 카테고리의 사용자에 속하거나 동일한 역할을 부여받은 것으로 기술될 수 있다. 예를 들어, 이들 2명의 사용자가 2명의 사용자가 속해 있는 부서 내의 관리자에 특별 맞춤되어 있는 동적 콘텐츠를 포함하는 관리자용 회사 메모를 보고 있는 관리자일 수 있다. 각 관리자마다 메모를 생성 및 캐싱하기 보다는, 그 메모는 미리 관리자의 역할과 연관되어 있다. 제1 관리자가 메모에 액세스한 후에, 그 메모는 캐싱되고, 동일 카테고리 내의 다른 관리자에 의한 차후의 그 메모에 대한 검색 시도는 캐시 히트를 가져올 것이다. 다른 카테고리 내의 다른 관리자에 의한 차후의 그 메모에 대한 액세스 시도는 캐시 미스를 가져올 것이며, 그 이유는 2가지 서로 다른 버전의 메모가 동일한 URI와 연관되어 있을 수 있지만 차후의 관리자가 서로 다른 카테고리 쿠키를 가지고 있기 때문이다.

클라이언트 애플리케이션은 페이지 요청을 생성하여(단계 882), 이를 제2 사용자에 속하는 수반하는 카테고리 쿠키와 함께 서버로 전송한다(단계 884). 이 경우, 중간 캐시는 요청 내의 URI 경로에 의해 식별되는 요청된 페이지의 복사본 및 관련된 카테고리 쿠키를 가지고 있으며, 따라서 캐시 히트가 일어난다(단계 886). 중간 캐시는 그 요청을 서버로 포워딩하지 않고 즉시 요청된 페이지를 반환할 수 있으며(단계 888), 클라이언트는 요청된 페이지를 수신하여 제2 사용자에게 제시한다(단계 890).

이와 같이, 중간 캐시는 실제로 동일한 프래그먼트의 다수의 버전을 저장할 수 있으며, 적당한 버전의 프래그먼트가 사용자의 주장된 카테고리 쿠키에 기초하여 사용자에게 반환된다, 즉 카테고리 쿠키만이 그렇지 않았으면 동일한 프래그먼트의 서로 다른 버전 사이의 선택을 결정한다. 프래그먼트를 구별하기 위한 쿠키의 사용의 추가의 일례는 이하에 특히 쇼핑객 그룹의 카테고리와 관련하여 제공된다.

이제 도 9a를 참조하면, 다수의 프래그먼트가 하나의 요청 메시지에 지정되고 후속하여 처리될 수 있는 프로세스를 나타낸 플로우차트가 도시되어 있다. 도 9a에 도시된 프로세스는 도 6n에 도시된 프로세스 또는 다수의 프래그먼트가 획득될 필요가 있는 임의의 다른 프로세스와 연계하여 특히 이들 프래그먼트를 하나의 프래그먼트로 합성하기에 앞서 사용될 수 있다.

응답 메시지로부터 또는 캐시로부터 프래그먼트를 획득한 후에, 프로세스는 그 프래그먼트가 말단 프래그먼트인지 또는 다른 프래그먼트를 포함하는지를 알아보기 위한 "contains-fragments" 디렉티브를 검사하는 것으로 시작한다. 다른 프래그먼트를 포함하는 경우, 이들 포함된 프래그먼트를 찾아내기 위해 그 프래그먼트를 파싱한다.

그 다음 레벨 프래그먼트 모두에 대한 소스 식별자를 수집한 후에, 하나의 일괄 요청이 생성되고(단계 904), 이 일괄 요청은 프래그먼트를 획득하는 데 사용 될 서버측 배치 프로그램(batch server-side program), 즉 서블릿을 포함할 수 있다. 일괄 요청은 그 다음 레벨 프래그먼트에 대한 모든 소스 식별자, 예를 들어 URI를 포함한다. 이들 그 다음 레벨 프래그먼트 중 임의의 것에 대한 캐시 히트를 알아보기 위해 로컬 캐시가 검사된 것으로 가정하며, 그 다음 레벨 프래그먼트에 대한 캐시 히트가 있었던 경우, 그 프래그먼트는 일괄 처리에 포함되지 않는다.

이어서, 일괄 요청 메시지가 서버로 전송되고(단계 906), 캐시 관리 유닛은 다중 부분 MIME(Multipurpose Internet Mail Extension) 응답을 수신하기 위해 기다린다(단계 908). 양호하게는, 그 요청을 위한 쓰레드가 스폰되고, 컴퓨팅 장치가 다른 동작을 수행하는 동안 그 쓰레드가 응답을 기다릴 때 그 쓰레드는 슬립 상태에 있다.

응답이 수신된 후에, 캐시 관리 유닛은 응답 내의 각 프래그먼트를 살펴본다. 그 다음 프래그먼트가 다중 부분 응답 메시지로부터 검색(단계 910)된 다음에 캐싱된다(단계 912). 다중 부분 응답 메시지 내에 처리될 프래그먼트가 더 있는지에 관한 결정이 행해지고(단계 914), 더 있는 경우, 프로세스는 단계 910으로 분기하여 다른 프래그먼트를 처리한다. 그렇지 않은 경우, 새로 수신된 프래그먼트가 파싱 또는 검사되어 이들 프래그먼트가 그 다음 레벨 프래그먼트로의 링크를 포함하는지를 결정하고(단계 916), 포함하는 경우 프로세스는 다시 단계 902로 분기하여 필요한 경우 일괄 요청으로 더 많은 프래그먼트를 요청한다. 그렇지 않은 경우, 새로 수신된 프래그먼트는 페이지 조립 동작에서 합성되고(단계 918), 프로세스는 완료한다.

이제 도 9b를 참조하면, 하나의 요청 메시지가 중간 캐시 관리 유닛에 수신되고 후속하여 처리될 수 있는 프로세스를 나타낸 플로우차트가 도시되어 있다. 도 9b에 도시된 프로세스는 도 6v에 도시된 프로세스 또는 요청 메시지가 중간 캐시에서 처리되는 임의의 다른 프로세스와 연계하여 사용될 수 있다.

프로세스는 프래그먼트 지원 중간 캐시에서 일괄 요청이 수신(단계 922)될 때 시작한다. 이어서, 일괄 요청 내의 소스 식별자 세트가 루프에서 처리된다. 요청된 프래그먼트 중 하나에 대한 그 다음 소스 식별자가 요청 메시지로부터 검색되고(단계 924), 로컬 캐시에 캐시 히트가 있는지 여부에 관한 결정이 행해진다(단계 926). 캐시 히트가 있는 경우, 그 다음 단계를 건너뛸 수 있으며, 캐시 히트가 있는 경우, 소스 식별자는 일괄 요청 메시지로부터 제거될 수 있다(단계 928). 일괄 요청 메시지에 처리될 소스 식별자가 더 있는지 여부에 관한 결정이 행해지고(단계 930), 더 있는 경우, 프로세스는 다시 단계 924로 분기하여 다른 소스 식별자를 처리한다.

요청된 프래그먼트 모두가 로컬 캐시에서 발견되었는지 여부에 관한 결정이 행해진다(단계 932). 발견된 경우, 일괄 요청을 포워딩할 필요가 없으며, 프로세스는 응답 메시지를 준비하는 단계로 분기한다. 적어도 하나의 캐시 미스가 있는 경우, 소스 식별자 (또는 식별자)가 제거된 수정된 일괄 요청이 서버로 포워딩된다(단계 934). 다른 대안에서, 남아 있는 소스 식별자가 하나만 있는 경우, 일괄 요청은 통상의 요청 메시지로 변화될 수 있다. 캐시 관리 유닛은 다중 부분 MIME 응답을 수신하기 위해 기다리고(단계 936), 양호하게는 그 요청에 대한 쓰레드가 스폰되고, 컴퓨팅 장치가 다른 동작을 수행하는 동안 그 쓰레드가 응답을 기다리 때 그 쓰레드는 슬립 상태에 있다.

응답이 수신된 후에, 캐시 관리 유닛은 응답 내의 각 프래그먼트를 살펴본다. 그 다음 프래그먼트가 다중 부분 응답 메시지로부터 검색(단계 938)된 다음에, 그 프래그먼트를 로컬 캐시에 캐싱하는 것이 적절하다고 가정하여 캐싱된다(단계 940). 다중 부분 응답 메시지에 처리될 프래그먼트가 더 있는지 여부에 관한 결정이 행해지고(단계 942), 더 있는 경우, 프로세스는 다시 단계 938로 분기하여 다른 프래그먼트를 처리한다. 이 프로세스가 원래의 일괄 요청을 생성했던 캐시 관리 유닛에서 수행될 것으로 가정할 수 있기 때문에 이들 프래그먼트가 그 다음 레벨 프래그먼트로의 링크를 포함하는지 여부를 결정하기 위해 새로 수신된 프래그먼트는 파싱 또는 검사되지 않는 것으로 가정한다. 다른 대안에서, 이 프로세스는 도 9a에 기술한 것과 유사한 방식으로 현재의 캐시 관리 유닛에서 수행될 수 있다. 어느 경우든지, 원래의 일괄 요청에서 수신된 소스 식별자에 대응하는 프래그먼트를 갖는 다중 부분 MIME 응답이 생성되고(단계 944), 이 다중 부분 MIME 응답이 반환되며(단계 946), 이에 따라 프로세스가 완료한다.

이제 도 9c를 참조하면, 다수의 프래그먼트에 대한 일괄 요청 메시지를 처리하기 위한 웹 애플리케이션 서버에서의 프로세스를 나타낸 플로우차트가 도시되어 있다. 도 9c에 도시된 프로세스는 일괄 요청 메시지가 프래그먼트 요청을 완수할 수 없는 프래그먼트 지원 캐시 관리 유닛을 갖는 다수의 컴퓨팅 장치를 통과한 후에 수행될 수 있다. 즉, 다수의 장치가 캐시 미스를 가질 수 있다.

프로세스는 서버에서 일괄 요청을 수신하는 것으로 시작하고(단계 952), 일괄 요청은 다수의 프래그먼트 요청을 포함하고, 이 요청들은 차례로 처리된다. 그 다음 프래그먼트 요청은 일괄 요청 메시지로부터 검색되어(단계 954), 실행되고(단계 956), 이는 프래그먼트를 생성하는 단계를 포함하는 것으로 가정하며, 그 후에 프래그먼트는 이미 서버에 캐싱되어 있을 수 있지만 선택적으로 전송을 위해 포맷되거나 태그될 필요가 있을 수 있다. 일괄 요청 메시지 내에 다른 프래그먼트 요청이 있는지 여부에 관한 결정이 행해지고(단계 960), 있는 경우, 프로세스는 다른 프래그먼트 요청을 처리하기 위해 분기한다. 그렇지 않은 경우, 모든 요청된 프래그먼트를 갖는 다중 부분 MIME 응답 메시지가 생성되고(단계 962), 응답 메시지는 반환되며, 따라서 프로세스는 완료한다.

캐시 크기 감축의 일례

이제 도 10a 내지 도 10d를 참조하면, 본 발명의 양호한 실시예로 달성될 수 있는 유익한 캐시 크기 감축을 나타내는 한 세트의 일례가 제공된다. 특정의 애플리케이션에서 프래그먼트가 무엇으로 구성되어 있는지를 선택하는 한가지 기준은 콘텐츠가 서로 다른 페이지에 걸쳐 얼마나 자주 공유되는지이다. 콘텐츠가 아주 많이 공유되는 경우, 그 콘텐츠를 프래그먼트로 만드는 것은 캐시의 크기를 너무 중요시할 수 있는 데 그 이유는 그 프래그먼트를 여러 페이지에서 반복하지 않고 한번에 저장할 수 있기 때문이다. 따라서, 프래그먼트는 캐시 크기를 감축하기 위해 여러 페이지에 걸친 한 압축 형태를 제공한다. 이 압축의 이점은 비용 절감, 예를 들면 일정한 히트율을 위한 캐시 크기의 감축, 성능 향상, 예를 들면 일정한 크기의 캐시의 히트율 향상, 또는 이들의 어떤 조합으로 볼 수 있다. 도 10a 내지 도 10d는 본 발명의 양호한 실시예에 대한 여러가지 사용 시나리오 및 등가의 종래의 시나리오와 비교하여 달성될 수 있는 캐시 크기의 감축을 나타낸 것이다.

도 10a를 참조하면, 공유된 사이드바 시나리오가 도시되어 있다. 각 페이지는 사이드바 부분과 다른 페이지 부분을 포함하며, 종래 기술에 따르면, 각 페이지는 프래그먼트를 지원하지 않는 캐시 내의 모든 하위 객체를 갖는 전체 페이지로서 저장된다. 본 발명의 양호한 실시예에서, 각 페이지는 사이드바 프래그먼트 및 나머지 페이지 프래그먼트를 포함하도록 작성되며, 그 모두는 프래그먼트를 지원하는 캐시에 저장된다. 분명한 바와 같이, 본 발명의 양호한 실시예에서는, 사이드바 프래그먼트는 한번만 저장된다. 다시 말하면, 특정 사이트 상의 모든 페이지는 동일한 사이드바 프래그먼트를 공유한다. 사이드바가 모든 페이지의 20%인 경우, 모든 페이지로부터 이를 인수 분해(factoring)하면 사이드바는 복제될 수 없기 때문에 약 20% 정도 캐시의 크기를 감축시킬 수 있다.

도 10b를 참조하면, 쇼핑객 그룹 시나리오가 도시되어 있다. 제품 설명 페이지는 각 쇼핑객 그룹에 대해 서로 다른 가격을 가지고 있지만, 제품 설명의 나머지 부분은 쇼핑객 그룹과는 독립적이다. 종래 기술에 따르면, 제품과 쇼핑객 그룹의 각 조합에 대한 제품 페이지가 있으며, 이들 제품 페이지 각각은 잠재적으로 프래그먼트를 지원하지 않는 캐시에 캐싱될 수 있다. 이와 반대로, 본 발명의 양호한 실시예에 따른 프래그먼트를 지원하는 캐시는 제품-그룹 조합에 대한 가격 데이터 프래그먼트와 제품 설명 프래그먼트만 저장하면 되며 전체 페이지 조합 모두를 저장할 필요가 없다.

잠재적인 저장 공간 절감은 다음과 같이 근사화될 수 있다. 각 가격은 100B(s1)이고, 나머지 제품 설명은 10kB(s2)이다. 10,000개의 제품(p)과 5명의 쇼핑객(g)이 있다. 하나가 완전 확장된 페이지를 저장하는 경우, 각각이 약 10kB의 크기를 갖는 총 (10,000 x 5) = 50,000 (p*g)개의 항목이 있을 수 있고, 총 크기는 약 500,000kB(p*g*s2)가 된다. 그 대신에, 나머지 제품 설명과는 별도의 프래그먼트에 가격을 저장하는 경우, 캐시에 있는 각각 10kB의 10,000(p)개의 제품 프래그먼트(이는 100,000kB(p*s2)의 크기를 가짐) + 각각 100B(s1)의 10,000 x 5 = 50,000 (p*g)개의 가격(이는 5,000kB의 크기를 가짐)이 있다. 프래그먼트와의 총합은 이들의 합, 즉 105,000kB이다. 이것은 프래그먼트를 지원하는 캐시를 구현한 후에 캐시 크기의 크기 감축이 거의 5배이다.

도 10c를 참조하면, 개인화 시나리오가 도시되어 있다. 제품 설명 페이지는 개인화 섹션을 포함하고, 10,000개의 제품(p)과 100,000명의 사용자(u)가 있다. 종래 기술에 따르면, 완전히 확장된 페이지를 저장하는 경우, 캐시에는 잠재적으로 총 10,000 x 100,000 = 1,000,000,000 (u*p)개의 항목이 있다.

이와 반대로, 본 발명의 양호한 실시예에 따라 구현된 프래그먼트 지원 캐시에서는, 페이지를 개별적인 프래그먼트로서 저장할 수 있다. 그 경우, 캐시에는 총 10,000 + 100,000 = 110,000(u+p)개의 항목이 있을 뿐이며, 각 항목은 더 적다. 이것은 약 20,000배의 크기 감축이다.

계속하여 동일한 일례에서, 쿠키를 식별하는 SRC 속성을 갖는 FRAGMENTLINK 태그, 예를 들면

또는 URI 질의 파라미터, 예를 들면

가 그 쿠기의 값, 즉 질의 파라미터를 대체하는 데 사용될 수 있다. 이 시나리오에서, 개인화가 쿠키 값이 되기에 충분히 작은 경우, 이 변수 대체는 개인화 프래그먼트를 웹 애플리케이션 서버에 요청하여 이를 캐싱하는 오버헤드를 제거하는 데 사용될 수 있다. 예를 들어,

같은 인사는 이하의 HTML문으로 이름이 "userName"이고 값이 "John Smith"인 쿠키를 사용하여 수행될 수 있다.

도 10d를 참조하면, 주식 감시 목록 시나리오가 도시되어 있으며, 주식 감시 목록은 많은 웹 포털에서 이용가능하다. 페이지는 주식 시세의 개인화된 목록을 포함한다. 이 시나리오는 사용자별 정보가 포함된 프래그먼트 대신에 최상위 레벨 프래그먼트와 연관되어 있는 것을 제외하고는 개인화 시나리오와 유사하다. 각 사용자는 개별적인 주식 목록을 가지고 있지만, 각 주식은 많은 사용자 목록에 의해 공유된다. 100,000명의 사용자(u)와 1,000개의 주식(s)이 있다. 각 사용자 설명은 1kB(s1)이고, 각 주식 시세는 100B(s2)이다. 사용자는 그의 목록(1)에 평균 10개의 주식이 있다. 완전히 확장된 페이지를 저장하는 경우, 캐시 크기는 100,000 * 1kB = 100,000 kB(u*s1) + 100,000 * 10 * 100B = 100,000kB (u*l*s2), 총 200,000kB가 된다. 그 대신에, 개개의 주식 시세를 개별적인 프래그먼트로서 저장 하는 경우, 캐시 크기는 사용자별 프래그먼트에 대한 100,000 x 1kB = 100,000kB (u*s1) + 주식 시세 프래그먼트에 대한 1,000 * 100B = 100kB, 총 100,100kB가 된다. 이것은 주식 시세가 복제되지 않기 때문에 대략 2배의 크기 감축이 된다.

주식 감시 목록 시나리오는 프래그먼트의 FOREACH 특징을 사용함으로써 추가로 개선될 수 있다. 이 경우, 모든 사용자별 프래그먼트가 제거된다. 이것은 또한 도 10d에 도시되어 있다. FOREACH 특징은 "="로 분리된 이름-값 쌍의 공백 구분된 목록으로 된 값을 갖는 쿠키를 지정한다. 각각의 이름-값 쌍에 대해, 이름-값 쌍이 URI 질의 파라미터로서 부가된 프래그먼트가 생성된다. 이 시나리오에서, "stocks"이라는 쿠키는 값으로서 주식 심볼 파라미터의 목록, 예를 들면,

을 갖는다. 이것은 쿠키 내의 각 주식 심볼에 대해 하나씩 3개의 프래그먼트를 생성한다. 캐시의 크기는 하나의 비사용자별 템플릿 프래그먼트에 대한 1kB (s1) + 주식 시세 프래그먼트에 대한 100 kB (s*s2), 총 101kB가 된다. 이것은 사용자별 주식 목록 프래그먼트가 하나의 주식 목록 프래그먼트로 대체되기 때문에 대략 1000배의 크기 감축이 된다.

본 발명의 양호한 실시예는 또한 캐시 콘텐츠를 유지하는 데 요구되는 작업량을 감소시킨다. 특정의 애플리케이션에서 프래그먼트를 무엇으로 구성할지 선택하기 위한 기준은 콘텐츠의 일부분이 얼마나 종종 변하는지이다. 콘텐츠가 너무 자주 변하여 매번마다 수작업으로 게시될 수 없는 경우, 애플리케이션은 일반적으로 데이터베이스가 변하거나 시간 한계가 만료할 때 콘텐츠를 자동적으로 무효화하는 메카니즘 뿐만 아니라 그 콘텐츠를 생성하기 위해 데이터베이스를 액세스하는 템플릿, 예를 들면 JSP를 사용한다. 이러한 동적 콘텐츠 방법은 사람이 의사 결정에 개입하지 않고 빈번한 갱신을 가능하게 한다.

현재, 대부분의 캐시는 질의 파라미터를 갖는 요청이 일반적으로 동적 콘텐츠를 나타내기 때문에 이를 캐싱하지 않는다. 그렇지만, 동적 콘텐츠는 종종 캐싱하기 위한 양호한 후보가 된다. 콘텐츠가 어떤 속도로 변하지만(예를 들어, 가격은 매주 변할 수 있고, 뮤추얼 펀드는 매일 변하며, 주식은 매몇분마다 변함), 변화 사이에는 많은 횟수의 캐시 히트가 있을 수 있으며, 따라서 캐싱이 여전히 상당한 성능 향상을 제공한다.

콘텐츠가 빠르게 변할 수 있는 경우, 각 변화에 의해 야기되는 작업을 감소시키는 것이 중요하게 된다. 페이지를 프래그먼트로 분리함으로써 증분적 콘텐츠 생성이 가능하게 된다. 변화가 일어날 때, 직접 영향을 받는 그 페이지 중의 부분만이 다시 생성되면 된다. 콘텐츠가 빠르게 변화하면, 그 콘텐츠는 개별적인 프래그먼트로 될 수 있다.

다시 도 10a의 사이드바 시나리오를 참조하면, 사이드바는 몇분마다 변하는 콘텐츠, 예를 들면 뉴스 헤드라인을 포함한다. 완전히 확장된 페이지가 저장되면, 사이드바가 변할 때 모든 페이지는 다시 생성되어 대체되어야만 한다. 그 대신에, 사이드바가 개별적인 프래그먼트인 경우, 사이드바가 변할 때 단지 하나의 프래그먼트만 생성되어 대체되면 된다.

다시 도 10b의 쇼핑객 그룹 시나리오를 참조하면, 쇼핑객 그룹 가격은 쇼핑객 그룹 내에서의 판매량에 기초하여 매분마다 변할 수 있다. 완전히 확장된 페이 지가 저장되면, 50,000개의 페이지 모두가 매분마다 생성되어야만 한다. 이것은 매분마다 500,000kB의 캐시가 생성되어 대체되게 한다. 그 대신에, 가격이 개별적인 프래그먼트로서 저장되는 경우, 여전히 50,000개의 프래그먼트가 생성되어 대체되지만, 단지 5,000kB의 캐시가 생성되어 대체된다. 이것은 요구되는 대역폭이 100배 감소된 것이다. 제품 설명의 비가격 측면이 변하면, 5개의 페이지 대신에 하나의 프래그먼트만이 생성되어 대체되면 된다. 이것은 대역폭이 5배 감속된 것이다.

다시 도 10c의 개인화 시나리오를 참조하면, 제품은 몇초마다 변할 수 있으며, 사용자별 개인화는 매일마다 변할 수 있다. 확장된 페이지가 캐싱되는 경우, 각 제품 변화는 그 제품에 대한 100,000개의 페이지 모두가 생성되어 대체되게 하며, 각 개인화 변화는 그 사용자에 대한 10,000개의 페이지 모두가 생성되어 대체되게 한다. 그 대신에, 제품 설명 및 개인화가 개별적인 프래그먼트에 저장되면, 각 제품 변화는 단지 하나의 프래그먼트가 생성되어 대체되게 하고(100,000배 개선), 각 개인화 변화는 단지 하나의 프래그먼트가 생성되어 대체되게 한다(10,000배 개선).

다시 도 10d의 주식 감시 목록 시나리오를 참조하면, 주식 가격은 매 20초마다 변할 수 있다. 확장된 페이지가 캐시에 저장되는 경우, 100,000개의 사용자 페이지 모두(100,000kB)가 매 20초마다 생성되어야만 한다. 그 대신에, 주식이 개별적인 프래그먼트로서 저장되는 경우, 단지 1,000개의 주식 프래그먼트(100kB)만이 매 20초마다 생성되어 대체되면 된다. 이것은 대역폭에서 1,000배 이상의 개선 이다. 하나의 사용자 주식 감시 목록이 수정되면, 예를 들어 사용자가 감시 목록에 주식을 부가 또는 제거하면, 어느 경우든지 단지 하나의 프래그먼트만 생성되어 대체되면 된다.

프래그먼트 캐시 식별자의 생성 및 사용의 일례

전술한 바와 같이, 캐시에 각 프래그먼트를 어떻게 캐싱하는지를 지시하는 캐싱 정보는 그 프래그먼트와 관련되어 있다. 정적 콘텐츠의 경우, 캐싱 정보는 각 프래그먼트와 연관되어 있다. 동적 콘텐츠는 템플릿 또는 프로그램(JSP, CGI 등)에 의해 생성되고, 캐싱 정보는 이 템플릿과 연관되게 된다. 이것은 불변 정보이며, 따라서 템플릿에 의해 생성된 모든 프래그먼트는 동일한 값을 갖게 된다. 다른 대안에서, 템플릿은 캐싱 정보를 결정하는 코드를 가질 수 있으며, 따라서 템플릿은 어떤 알고리즘에 기초하여 각각의 생성된 프래그먼트마다 다를 수 있다. 어느 경우든지, 특정의 프래그먼트는 일정한 값을 갖는다.

프래그먼트는 콘텐츠의 다른 일부분과 조합하기 위해 구분되어 있는 콘텐츠의 일부분으로서 정의될 수 있다. 본 발명의 양호한 실시예에서는 표준화된 프래그먼트 지명 기술이 사용되며, 이 기술에서는 이상에서 보다 형식적으로 기재한 기술에 따라 캐시 ID를 생성한다. 이 섹션에서는 이하의 일련의 일례들을 통해 캐시 ID의 사용에 대해 기술할 것이지만, 먼저 캐시 ID의 형성 및 결정에 대한 간단한 개요가 제공된다.

캐시는 어떤 방식으로 캐시 ID를 사용하여 프래그먼트를 저장한다. 캐시를 사용하는 모든 애플리케이션들 사이에 캐시 ID가 고유한 것이 되기 위해서는 그 캐 시 ID에 충분한 정보가 포함되어 있어야 한다. 예를 들어, 제품 ID만으로 다른 가게의 제품 ID 또는 그 밖의 것과 완전히 충돌될 수 있다. 프래그먼트의 URI 경로가 일반적으로 이러한 동일한 이름 범위 문제를 적어도 부분적으로 해소해야 되기 때문에, 프래그먼트의 캐시 ID의 일부로서 URI 경로를 포함하는 것이 편리하다.

캐시 ID의 정보 콘텐츠는 이하의 일례에서 나타낸 바와 같이 프래그먼트가 얼마나 폭넓게 또는 좁게 공유되는지를 결정한다.

(A) 사용자 ID가 캐시 ID에 포함되어 있는 경우, 프래그먼트는 그 사용자에 대해서만 사용된다.

(B) 쇼핑객 그룹 ID가 캐시 ID에 포함되어 있는 경우, 프래그먼트는 그 쇼핑객 그룹의 모든 구성원에 걸쳐 공유된다.

(C) 캐시 ID에 사용자 ID도 쇼핑객 그룹 ID도 포함되어 있지 않은 경우, 프래그먼트는 모든 사용자에 걸쳐 공유된다.

웹 애플리케이션 개발자는 프래그먼트의 캐시 ID에 포함되어 있는 것이 무엇인지를 말해주는 CHCHEID 디렉티브를 갖는 프래그먼트의 HTTP FRAGMENT 헤더 내의 규칙에 의해 캐시 ID의 정보 콘텐츠를 지정할 수 있다. 규칙에 의해 임의의 URI 질의 파라미터 또는 쿠키가 URI 경로에 첨부될 수 있거나 (질의 파라미터를 포함한) 전체 URI가 가능하게 된다. 규칙이 없다는 것은 캐싱되지 않는다는 것을 의미한다. 다수의 규칙이 사용될 때, 규칙은 나타나는 순서로 시도된다. 실시되는 첫번째 규칙은 캐시 ID를 결정한다. 실시되는 규칙이 없는 경우, 프래그먼트가 캐싱되지 않는다. 질의 파라미터 또는 쿠키가 캐시 ID에 포함되어 있는 경우, 다음과 같이 질의 파라미터나 쿠키는 요구되거나 선택 사양일 수 있다.

(A) 부모의 요청에 존재하지 않는 요구된 질의 파라미터는 규칙을 실패하게 만든다.

(B) 부모의 요청 또는 결과에 존재하지 않는 요구된 쿠키는 규칙을 실패하게 만든다.

(C) 존재하지 않는 선택 사양의 질의 파라미터 또는 쿠키는 캐시 ID에 포함되지 않는다.

캐시 ID는 어떤 표준이 대소문자 비구분으로 선언한 부분을 제외하고는 대소문자를 구분한다. HTTP 규격에서는 URI의 프로토콜 및 호스트 이름은 대소문자를 구분하지 않는 반면 URI의 나머지는 질의 파라미터 이름을 포함하여 대소 문자를 구분하는 것으로 하고 있다. "HTTP State Management Mechanism"(HTTP 상태 관리 메카니즘), RFC 2109, 인터넷 엔지니어링 태스크 포스, 1997년 2월판 규격에 따르면, 쿠키 이름은 대소문자를 구분하지 않는다. 캐시 구현은 이들 대소문자를 구분하지 않는 부분을 한가지 문자로 변환함으로써 이를 용이하게 시행할 수 있다. 본 발명의 양호한 실시예의 프래그먼트 캐싱 기술에서는 양호하게는 질의 파라미터 값 및 쿠키 값이 대소문자를 구분하게 되어 있다.

이제 도 11a 내지 도 11h를 참조하면, 본 발명의 양호한 실시예의 기술이 프래그먼트를 저장 및 처리하기 위해 고유의 캐시 및 식별자를 구축 및 사용하는 방법을 설명하기 위해 일련의 도면이 사용된다.

도 11a를 참조하면, 사이트에 있는 모든 부모 프래그먼트는 동일한 사이드바 자식 프래그먼트를 포함한다. 모든 부모 프래그먼트가 동일한 사이드바 프래그먼트를 포함한다는 것을 제외하고는 부모 프래그먼트는 이 시나리오에서 지정되어 있지 않으며, 따라서 자식 프래그먼트만이 논의된다. 자식 프래그먼트는 그의 URI에 의해 논리적으로 한정된다. 자식 프래그먼트가 정적 콘텐츠이기 때문에, 그의 캐시 ID는 전체 URI가 된다. 캐시 ID 규칙은 다음과 같이 된다.

다시 말하면, 캐시 ID는 모든 질의 파라미터를 포함한 전체 URI가 된다. 캐시 ID의 일례를 들면

가 있다.

도 11b를 참조하면, 제품 설명 페이지는 내장된 프래그먼트나 자식 프래그먼트를 포함하지 않는다, 즉 그 페이지가 유일한 프래그먼트이다. 그 페이지는 productID에 의해 논리적으로 한정된다. 페이지 URI는 productID 질의 파라미터를 갖는다. 페이지 요청은 로그온 동안에 웹 애플리케이션 서버에 의해 생성된 암호화된 userID 쿠키를 갖는다. userID 쿠기에 의해 사용자별 상태(쇼핑 카트, 사용자 프로파일 등)가 사용자와 연관될 수 있다. userID는 질의 파라미터보다는 쿠키로서 사용되는데, 그 이유는 userID가 거의 모든 요청에서 사용될 수 있기 때문이며, 웹 애플리케이션 개발자가 userID를 모든 링크에 집어 넣는 것은 지루한 일일 것이다. 제품 페이지에 대한 하나의 캐시 ID 규칙은 캐시 ID로서 productID 질의 파라미터를 포함하는 전체 URI를 사용할 수 있으며, 따라서 정확한 한정해야 캐싱 될 수 있다. 이 하나의 프래그먼트 페이지의 경우, 캐시 ID는 그의 URI가 될 수 있다. 캐시 ID 규칙은 다음과 같이 될 수 있다.

다시 말하면, 캐시 ID는 모든 질의 파라미터를 포함한 전체 URI이다. 캐시 ID의 일례를 들면 다음과 같다.

이러한 최상위 레벨 프래그먼트에 대한 캐시 ID를 지정하는 다른 방법은 URI 질의 파라미터인 매매업자에 의해 사용되는 제품 ID, 예를 들면 AT13394 + 독자성(uniqueness)을 보장하기 위한 불변의 URI 경로, 예를 들면

가 있다. 이 경우, 캐시 ID 규칙은 다음과 같이 된다.

다시 말하면, 캐시 ID는 이하의 부분들이 서로 연결되어 있다.

(A) URI 경로와,

(B) productID 질의 파라미터의 이름 및 값.

규칙에 각괄호가 없는 것은 productID 파라미터가 존재해야만 함을 나타낸다. 그렇지 않으면, 규칙은 실패하고, 프래그먼트는 캐싱되지 않는다. 캐시 ID의 일례를 들면 다음과 같다.

또다시 유의할 점은 웹 애플리케이션 개발자는 캐시 ID의 정보 콘텐츠만을 지정할 뿐 정확한 포맷을 지정하지 않는다는 것이다. 캐시 구현은 캐시 ID에 지정된 정보 콘텐츠를 인코딩하기 위해 그 자신의 방식을 선택할 수 있다. 상기 일례에서는 분리 구분 문자로서 밑줄 문자("_")를 갖는 간단한 연결을 사용한다. 웹 애플리케이션 개발자는 이러한 인코딩을 알고 있을 필요가 없다.

도 11c를 참조하면, 제품 설명 시나리오의 확장이 제공된다. 가격은 이제 사용자가 속한 쇼핑객 그룹에 의해 결정되지만, 제품 설명의 나머지는 쇼핑객 그룹과는 독립적이다. 제품 설명 부모 프래그먼트는 가격 자식 프래그먼트를 포함한다. 부모는 productID에 의해 논리적으로 한정된다. 자식은 productID 및 groupID에 의해 논리적으로 한정된다. 페이지 URI는 productID 질의 파라미터를 갖는다. 페이지 요청은 암호화된 userID 및 groupID 쿠키를 갖는다. groupID 쿠키는 로그온 동안 사용자 프로파일에 기초하여 웹 애플리케이션에 의해 생성된다. groupID는 질의 파라미터가 아닌 쿠키로 되는데 그 이유는 거의 모든 요청에서 사용될 수 있기 때문이며, 웹 애플리케이션 개발자가 이를 모든 링크에 집어 넣는 일은 지루한 것이 될 것이다.

가격은 부모가 포함하고 있는 별도의 자식 프래그먼트에 있어야만 한다. 부모 프래그먼트에 대한 하나의 캐시 ID 규칙은 제품 표시 시나리오에서와 동일하다. 자식 프래그먼트에 대한 하나의 캐시 ID 규칙은 productID 질의 파라미터 및 groupID 쿠키와 함께 URI 경로를 사용하며, 따라서 정확하게 한정해야만 캐싱될 수 있다. 유의할 점은 캐시 ID가 사용자 ID를 포함하지 않는데 그 이유는 프래그먼트가 동일한 쇼핑객 그룹에 속하는 모든 사용자가 아닌 한 명의 사용자에 의해서만 사용될 수 있기 때문이며, 그에 따라 캐시를 갱신하기 위해 캐시가 훨씬 더 커지게 되고 작업이 더 많아지게 된다. 캐시 ID 규칙은 다음과 같다.

다시 말하면, 캐시 ID는 이하의 부분이 서로 연결되어 이루어진다.

(A) URI 경로와,

(B) productID 질의 파라미터의 이름 및 값과,

(C) groupID가 요청에 존재하는 경우 그의 이름 및 값.

콤마는 URI 질의 파라미터를 쿠키와 분리시킨다. 규칙에 있는 각괄호는 쿠키가 선택적인 것임을 나타낸다. 이 쿠키가 존재하지 않는 경우에도, 여전히 규칙은 성공할 수 있으며, 캐시 ID는 쿠키 이름-값 쌍을 포함하지 않는다. 이것에 의해 매매업자는 그룹마다의 가격 뿐만 아니라 비그룹 가격도 포함할 수 있게 된다. 캐시 ID의 일례를 들면 다음과 같다.

도 11d를 참조하면, 쇼핑객 그룹 시나리오의 확장이 제공되어 있다. 다수의 매매업자에 대한 지원이 부가되어 있으며, 예를 들어 애플리케이션 서비스 제공자(ASP)는 다수의 언어를 사용하여 동일한 웹 애플리케이션 서버에서 다수의 매매업자를 지원한다. 제품 설명 부모 프래그먼트는 또다시 가격 자식 프래그먼트를 포함한다. 부모는 productID, groupID, languageID 및 merchantID에 의해 논리적으로 한정된다. 페이지 URI는 productID 및 merchantID 질의 파라미터를 갖는 다. 요청은 userID, groupID, 및 languageID 쿠키를 갖는다. languageID 쿠키는 로그온 동안 사용자 프로파일에 기초하여 웹 애플리케이션에 의해 생성된다. languageID는 질의 파라미터가 아니라 쿠키가 되는데 그 이유는 모든 요청에서 사용되기 때문이고, 웹 애플리케이션 개발자가 모든 링크에 이를 집어넣는 일은 아주 지루할 것이다.

부모 프래그먼트에 대한 하나의 캐시 ID 규칙은 productID 및 merchantID 질의 파라미터 및 languageID 쿠키와 함께 URI 경로를 사용할 것이며, 따라서 정확하게 한정해야만 캐싱될 수 있다. 부모 캐시 ID 규칙은 다음과 같다.

다시 말하면, 캐시 ID는 다음의 부분들이 서로 연결되어 이루어진다.

(A) URI 경로와,

(B) productID 질의 파라미터의 이름 및 값과,

(C) merchantID 질의 파라미터의 이름 및 값과,

(D) languageID 쿠키가 요청에 존재하는 경우 그의 이름 및 값.

부모 캐시 ID의 일례를 들면 다음과 같다.

자식 프래그먼트에 대한 하나의 캐시 ID 규칙은 productID 및 merchantID 질의 파라미터 및 선택적인 languageID 쿠키와 함께 URI 경로를 사용할 것이며, 따라 서 정확하게 한정해야만 캐싱될 수 있다. 캐시 ID 규칙은 다음과 같다.

다시 말하면, 캐시 ID는 다음의 부분들이 서로 연결되어 이루어진다.

(A) URI 경로와,

(B) productID 질의 파라미터의 이름 및 값과,

(C) merchantID 질의 파라미터의 이름 및 값과,

(D) groupID 쿠키가 요청에 존재하는 경우 그의 이름 및 값과,

(E) languageID 쿠키가 요청에 존재하는 경우 그의 이름 및 값.

캐시 ID의 일례를 들면 다음과 같다.

도 11e를 참조하면, ASP 및 다수의 언어 시나리오에 대한 확장이 제공되어 있다. 제품을 식별하기 위한 다수의 방법에 대한 지원이 부가되어 있다. 제품 설명 부모 프래그먼트가 가격 자식 프래그먼트를 포함한다. 부모는 product (이를 지정하는 방법은 2가지가 있음), languageID, 및 merchantID에 의해 논리적으로 한정된다. 자식은 product, groupID, languageID, 및 merchantID에 의해 논리적으로 한정된다. 제품(product)은 productID 질의 파라미터에 의해서나 또는 partNumber 및 supplierNumber 질의 파라미터에 의해 식별된다. 요청은 userID, groupID, 및 languageID 쿠키를 갖는다. 부모 프래그먼트는 다음과 같이 지정된 2개의 규칙을 필요로 한다.

첫번째 규칙이 시도된다. 첫번째 규칙이 성공하면, 캐시 ID를 결정한다. 첫번째 규칙이 실패하면, 두번째 규칙이 시도된다. 두번째 규칙이 성공하면, 캐시 ID를 결정한다. 두번째 규칙이 실패하면, 프래그먼트는 캐싱되지 않는다. 첫번째 규칙은 캐시 ID가 이하의 부분이 서로 연결되어 이루어짐을 의미한다.

(A) URI 경로와,

(B) productID 질의 파라미터의 이름 및 값과,

(C) merchantID 질의 파라미터의 이름 및 값과,

(D) languageID 쿠키가 요청에 존재하는 경우 그의 이름 및 값.

첫번째 규칙에 대한 캐시 ID의 일례를 들면 다음과 같다.

두번째 규칙은 캐시 ID가 이하의 부분이 서로 연결되어 이루어짐을 의미한다.

(A) URI 경로와,

(B) partNumber 질의 파라미터의 이름 및 값과,

(C) supplierNumber 질의 파라미터의 이름 및 값과,

(D) merchantID 질의 파라미터의 이름 및 값과,

(E) languageID 쿠키가 요청에 존재하는 경우 그의 이름 및 값.

두번째 규칙에 대한 캐시 ID의 일례를 들면 다음과 같다.

자식 프래그먼트는 2가지 규칙을 필요로 하며, 이들 규칙은 다음과 같이 지정되어 있다.

첫번째 규칙이 시도된다. 첫번째 규칙이 성공하면, 캐시 ID를 결정한다. 첫번째 규칙이 실패하면, 두번째 규칙이 시도된다. 두번째 규칙이 성공하면, 캐시 ID를 결정한다. 두번째 규칙이 실패하면, 프래그먼트는 캐싱되지 않는다. 첫번째 규칙은 캐시 ID가 다음의 부분이 서로 연결되어 이루어짐을 의미한다.

(A) URI 경로와,

(B) productID 질의 파라미터의 이름 및 값과,

(C) merchantID 질의 파라미터의 이름 및 값과,

(D) groupID 쿠키가 요청에 존재하는 경우 그의 이름 및 값과,

(E) languageID 쿠키가 요청에 존재하는 경우 그의 이름 및 값.

첫번째 규칙에 대한 캐시 ID의 일례를 들면 다음과 같다.

두번째 규칙은 캐시 ID가 다음의 부분이 서로 연결되어 이루어짐을 의미한다.

(A) URI 경로와,

(B) partNumber 질의 파라미터의 이름 및 값과,

(C) supplierNumber 질의 파라미터의 이름 및 값과,

(D) merchantID 질의 파라미터의 이름 및 값과,

(E) groupID 쿠키의 이름 및 값과,

(F) languageID 쿠키의 이름 및 값.

두번째 규칙에 대한 캐시 ID의 일례를 들면 다음과 같다.

도 11f를 참조하면, 개인화를 사용하여 제품 설명 시나리오에 대한 확장이 제공되어 있다. 제품 설명 부모 프래그먼트는 개인화 자식 프래그먼트를 포함한다. 부모 프래그먼트는 productID에 의해 논리적으로 한정된다. 자식 프래그먼트는 userID에 의해 논리적으로 한정된다. 페이지 URI는 productID 질의 파라미터를 갖는다. 요청은 userID 쿠키를 갖는다.

부모 캐시 ID는 productID 질의 파라미터를 포함한다. 부모 프래그먼트에 대한 캐시 ID 규칙은 이하의 2가지 경우 중 어느 하나이다.

다시 말하면, 캐시 ID는 모든 질의 파라미터를 갖는 전체 URI이다. 다른 가 능한 규칙은 다음과 같다.

다시 말하면, 캐시 ID는 이하의 부분들이 서로 연결되어 이루어진다.

(A) URI 경로와,

(B) productID 질의 파라미터의 이름 및 값.

유의할 점은 이 페이지에 대한 요청이 userID 쿠키를 포함하고 있지만 어느 한 프래그먼트에 대한 캐시 ID에는 포함되어 있지 않은데 그 이유는 그 프래그먼트가 제품별 프래그먼트이고 사용자별 프래그먼트가 아니기 때문이다. 포함되어 있는 경우, 이 프래그먼트는 그 사용자에 의해서만 액세스가능하며, 그 결과 캐시를 갱신하기 위해서는 캐시가 더 커야 하고 작업이 더 많아지게 된다. 캐시 ID의 일례를 들면 다음과 같다.

개인화 자식 프래그먼트의 캐시 ID는 userID 쿠키를 포함한다. 자식 프래그먼트의 캐시 ID 규칙은 다음과 같다.

다시 말하면, 캐시 ID는 이하의 부분들이 서로 연결되어 이루어진다.

(A) URI 경로와,

(B) userID 쿠키의 이름 및 값.

캐시 ID의 일례를 들면 다음과 같다.

이러한 개인화 일례에서, 개인화 프래그먼트는 예를 들어 "Cache-Control: private"를 사용함으로써 비밀 데이터로서 표시되어야만 한다.

도 11g를 참조하면, 간단한 포털 페이지 상의 주식 감시 목록 부모 프래그먼트는 다수의 주식 시세 자식 프래그먼트를 포함한다. 부모 프래그먼트는 또한 간단한 개인화로서 사용자의 이름을 포함한다. 부모는 userID에 의해 논리적으로 한정된다. 즉, 주식 심볼의 목록은 사용자별로 되어 있다. 사용자 이름은 userID에 의해 논리적으로 한정되어 있다. 각각의 자식은 그의 주식 심볼에 의해 논리적으로 한정되어 있다. 즉 주식의 값은 사용자별로 되어 있지 않다. 페이지 URI는 질의 파라미터를 포함하지 않는다. 요청은 userID 쿠키를 갖는다.

최상위 레벨 프래그먼트는 요청된 사용자별 주식 시세의 목록을 포함한다. 최상위 레벨 프래그먼트의 URI는 질의 파라미터를 포함하지 않는다. 최상위 레벨 프래그먼트의 캐시 ID는 userID라고 하는 암호화된 쿠키를 포함한다. 캐시 ID 규칙은 다음과 같다.

다시 말하면, 캐시 ID는 이하의 부분들이 서로 연결되어 이루어진다.

(A) URI 경로와,

(B) userID 쿠키의 이름 및 값.

캐시 ID의 일례를 들면 다음과 같다.

주식 시세 프래그먼트 각각에 대해, 캐시 ID는 "symbol" 파라미터를 포함한 다. 캐시 ID 규칙은 전체 URI 또는 URI 경로 + StockSymbol 질의 파라미터로 된다.

다시 말하면, 캐시 ID는 이하의 부분들이 서로 연결되어 이루어진다.

(A) URI 경로와,

(B) symbol 질의 파라미터의 이름 및 값.

캐시 ID의 일례를 들면 다음과 같다.

이 시나리오는 FOREACH 특징을 사용하기 위해 수정될 수 있으며, 주식 시세 프래그먼트는 변하지 않지만, 부모 프래그먼트는 최상으로 최적화될 수 있다. 단지 하나의 정적 최상위 레벨 프래그먼트만이 존재한다. 사용자에 대한 공백 분리된 주식 심볼의 목록을 값으로 갖는 stockSymbols 쿠키가 사용된다. 모든 사용자에 대해 아주 정적인 단지 하나의 부모 프래그먼트만이 존재하며, 이는 stockSymbols 쿠키를 지명하는 FOREACH 속성을 갖는 FRAGMENTLINK 태그를 포함한다. 이것은 주식 심볼이 질의 파라미터로서 부가된 FOREACH 속성을 포함하는 FRAGMENTLINK의 SRC와 동일한 SRC 속성을 갖는 각 주식 심볼에 대한 간단한 FRAGMENTLINK를 동적으로 생성한다. 이 부모 프래그먼트는 모든 사용자에 대해 동일하기 때문에, 그의 URI를 캐시 ID로서 사용하는 하나의 캐시 규칙에서는 정확하게 한정해야만 캐싱될 수 있고, 이 캐시 ID는 다음과 같이 질의 파라미터를 갖지 않는다.

stockSymbols 쿠키는 부모 프래그먼트에 대한 사용자별 정보를 모두 포함하며, 페이지 요청과 함께 전달되고, 따라서 이 쿠키는 부모의 논리적 userID 한정을 만족시킨다.

사용자의 이름을 값으로 갖는 userName 쿠키는 userName 쿠키를 식별하는 SRC 속성을 갖는 간단한 개인화를 위해 FRAGMENTLINK 태그에서 사용된다. 이 프래그먼트는 userName 쿠키로부터 용이하게 생성될 수 있기 때문에 캐싱되지 않는다. userName 쿠키는 이 프래그먼트에 대한 사용자별 정보를 모두 포함하며 페이지 요청과 함께 전달되고, 따라서 이 쿠키는 부모의 논리적 userID 한정을 만족시킨다.

자식 프래그먼트에 대한 하나의 캐시 ID 규칙은 캐시 ID에 대해 그의 URI를 사용하며, 따라서 다음과 같이 정확하게 한정해야만 캐싱될 수 있다.

이러한 주식 감시 목록 시나리오에서, FOREACH 특징이 사용되지 않을 때, 최상위 레벨 주식 감시 목록 프래그먼트는 예를 들어 "Cache-Control: private"를 사용함으로써 비밀(private)로 표시된다. FOREACH 특징이 사용될 때, 단지 하나의 최상위 레벨 프래그먼트만이 공유되며, 따라서 이 프래그먼트는 비밀로 표시되지 않는다.

도 11h를 참조하면, MyYahoo! 등의 개인화된 포털 페이지와 유사한 시나리오를 나타낸 일례가 도시되어 있다. 제1 레벨 포털 프래그먼트는 다수의 말단 항목 프래그먼트(leaf item fragment)를 각각 포함하는 주식, 날씨, 스포츠, 등의 다수의 중간 레벨 토픽 프래그먼트를 포함한다. 부모 프래그먼트는 또한 사용자의 이름도 포함한다. 최상위 레벨 포털 프래그먼트는 userID에 의해 논리적으로 한정된다. 즉, 토픽의 목록은 사용자별로 되어 있다. 사용자 이름은 userID에 의해 논리적으로 한정된다. 중간 레벨 토픽 프래그먼트는 topicID 및 userID에 의해 논리적으로 한정된다. 즉, 토픽에 있는 항목의 목록은 사용자별로 되어 있다. 말단 항목 프래그먼트는 itemID에 의해 논리적으로 한정된다. 즉, 항목의 값은 사용자별로 되어 있지 않다. 페이지 URI는 질의 파라미터를 포함하지 않는다. 페이지 요청은 userID 쿠키를 갖는다. FOREACH 특징을 사용함으로써, 부모 프래그먼트는 최상으로 최적화될 수 있다.

FOREACH 특징을 사용하여, 사용자에 대한 topicID의 공백 분리된 목록을 값으로 갖는 토픽 쿠키(로그온 동안 사용자 프로파일에 기초하여 생성됨)가 사용된다. 모든 사용자에 대해 아주 정적인 단지 하나의 부모 프래그먼트만이 존재하며, 이는 토픽 쿠키를 지명하는 FOREACH 속성을 갖는 FRAGMENTLINK 태그를 포함한다. 이것은 각 topicID에 대한 간단한 FRAGMENTLINK를 동적으로 생성하며, 그의 SRC 속성은 topicID가 질의 파라미터로서 첨부되어 있는 FOREACH 속성을 포함하는 FRAGMENTLINK의 SRC와 동일하다. 이 부모 프래그먼트는 모든 사용자에 대해 동일하기 때문에, 그의 URI를 캐시 ID로서 사용하는 하나의 캐시 규칙에서는 정확하게 한정해야만 캐싱될 수 있고, 이는 다음과 같이 질의 파라미터를 갖지 않는다.

토픽 쿠키는 부모 프래그먼트에 대한 사용자별 정보를 모두 포함하며 페이지 요청과 함께 전달되고, 따라서 이 쿠키는 부모의 논리적 userID 한정을 만족시킨다. 사용자의 이름을 값으로 갖는 userName 쿠키는 간단한 개인화를 위한 FRAGMENTLINK에서 사용되며 그의 SRC 속성은 userName 쿠키를 식별한다. 이 프래그먼트는 userName 쿠키로부터 용이하게 생성될 수 있기 때문에 캐싱되지 않는다. userName 쿠키는 이 프래그먼트에 대한 사용자별 정보를 모두 포함하며, 페잊 요청과 함께 전달되고, 따라서 이 쿠키는 부모의 논리적 userID 한정을 만족시킨다.

각 토픽마다 토픽 프래그먼트가 있다. FOREACH 특징으로 인해, 토픽 프래그먼트 각각은 최상으로 최적화될 수 있다. 각 토픽마다, 사용자와 토픽에 대한 itemID의 공백 분리된 목록을 값으로 갖는 쿠키(로그온 동안 사용자 프로파일에 기초하여 생성됨)가 사용된다. 각 토픽마다, 모든 사용자에 대해 그 토픽에 대해 해당하는 쿠키를 지명하는 FOREACH 속성을 갖는 FRAGMENTLINK를 포함하는 아주 정적인 단지 하나의 토픽 프래그먼트만이 있다. 이것은 각 itemID마다 itemID가 질의 파라미터로서 부가된(topicID 질의 파라미터는 이미 그곳에 있음) FOREACH 속성을 포함하는 FRAGMENTLINK의 SRC를 SRC 속성으로 갖는 간단한 FRAGMENTLINK를 동적으로 생성한다. 각 토픽 프래그먼트는 모든 사용자에 대해 동일하기 때문에 그의 URI를 캐시 ID로서 사용하는 하나의 캐시 규칙에서는 정확하게 한정해야만 캐싱될 수 있으며, 이 프래그먼트는 그의 topicID를 질의 파라미터로서 갖는다. 토픽 쿠키는 토픽 프래그먼트에 대한 사용자별 정보를 모두 포함하고 페이지 요청과 함께 전달되며, 따라서 토픽 프래그먼트의 논리적 userID 한정을 만족시킨다.

각 항목 프래그먼트에 대한 URI는 질의 파라미터로서 그의 topicID 및 itemID를 포함한다. 각 항목 프래그먼트에 대한 하나의 캐시 ID 규칙은 캐시 ID에 대한 그의 URI를 사용하며, 따라서 정확하게 한정해야만 캐싱될 수 있다.

FRAGMENTLINK 태그의 규격의 일례

다시 도 11a의 사이드바 일례를 참조하면, 하나의 FRAGMENTLINK가 다음과 같이 사이드바가 아닌 페이지에 또한 사이드바가 요망되는 동일한 장소에 배치된다.

다시 도 11c의 쇼핑객 그룹 일례를 참조하면, 하나의 FRAGMENTLINK가 다음과 같이 가격이 있게 될 곳에 위치한다.

특정의 가격 프래그먼트에 대해 구축된 URI는 다음과 같이 된다.

프래그먼트에 대한 요청은 부모의 질의 파라미터, 즉 "productId" 및 쿠키, 즉 "groupId"를 모두 포함하며, 따라서 이들은 애플리케이션 서버에서 productPrice.jsp의 실행 동안에 이용가능하다.

다시 도 11f의 개인화 일례를 참조하면, 최상위 레벨 프래그먼트는 다음과 같이 개인화된 프래그먼트가 요망되는 곳에 위치한 FRAGMENTLINK를 포함하게 된다.

특정의 사용자별 개인화 프래그먼트에 대해 구축된 URI는 다음과 같이 보이게 된다.

프래그먼트에 대한 요청은 부모의 질의 파라미터(즉, "productId") 및 쿠키(즉, "userId")를 모두 포함한다. personalization.jsp의 실행 동안, "userId" 쿠키가 사용되지만 "productId" 질의 파라미터는 무시된다.

다시 도 11g의 주식 감시 목록 일례를 참조하면, 최상위 레벨 프래그먼트는 사용자가 얼마나 많은 주식 시세를 원했는지에 따라 가변 개수의 FRAGMENTLINK 태그를 포함하게 된다. 각각의 FRAGMENTLINK 태그는 주식 시세가 있게 될 곳에 위치된다. 각각은 다음과 같이 된다.

특정의 주식 시세 프래그먼트에 대해 구축된 URI는 다음과 같이 된다.

이 시나리오는 FOREACH 특징을 사용하도록 수정될 수 있다. 가변 수의 FRAGMENTLINK 태그는 하나의 FRAGMENTLINK 태그로 대체되고 FOREACH 속성은 주식 심볼 파라미터의 공백 분리된 목록을 값으로 갖는 쿠키(stocks)의 이름을 지정한다.

"stocks"이라는 쿠키의 값이

이었다면, 이것은 이하의 FRAGMENTLINK 태그 세트와 등가이다.

다시 도 11h의 전체 포털 일례를 참조하면, FOREACH 특징이 모든 사용자에 의해 공유되는 하나의 정적인 최상위 레벨 프래그먼트에 대해 사용될 수 있다. 최상위 레벨 프래그먼트 내의 userName은 사용자의 이름을 포함하는 userName 쿠키를 식별하는 이하의 FRAGMENTLINK를 사용하여 포함된다.

최상위 레벨 프래그먼트는 또한 토픽 쿠키를 식별하는 FOREACH 속성을 갖는 FRAGMENTLINK 태그를 갖게 되며, 이 쿠키는 그 사용자의 토픽 목록을 포함한다.

이 쿠키는 topicID의 목록을 포함한다.

을 값으로서 갖는 토픽 쿠키의 경우, FOREACH 속성을 포함하는 상기 FRAGMENTLINK는 이하의 간단한 FRAGMENTLINK를 생성한다.

동적으로 생성된 SRC 속성의 각각은 지정된 토픽을 처리하는 프래그먼트의 위치를 알아낸다.

웹 애플리케이션 서버에서의 "portalPage.jsp"의 구현은 질의 파라미터에 기초하여 프래그먼트를 호출하는 디스패처로서 작용한다. 어떤 파라미터도 최상위 레벨 프래그먼트를 반환하지 않는다. "topic=stocks" 질의 파라미터는 주식 토픽 프래그먼트를 반환한다. 주식 토픽 프래그먼트를 일례로서 사용하고 다시 FOREACH 특징을 사용하여, 주식 토픽 프래그먼트는 주식 쿠키를 식별하는 FOREACH 속성을 갖는 FRAGMENTLINK를 포함하며, 이 쿠키는 그 토픽에 대한 그 사용자의 주식 심볼의 목록을 포함한다.

이것의 전형적인 사용은 주식 쿠키에서의 각 주식 심볼마다 하나의 행을 갖는 테이블의 행을 생성하는 것이다.

의 값을 갖는 "stocks" 쿠키의 경우, FOREACH 속성을 포함하는 상기 FRAGMENTLINK는 이하의 FRAGMENTLINK를 동적으로 생성한다.

부모 프래그먼트로부터 자식 프래그먼트로의 데이터 전달의 일례

프래그먼트는 가능한 한 다 갖추고 있어야만(self-contained) 한다. 이렇게 해야하는 2가지 이유가 있다. 첫번째 이유는 양호한 소프트웨어 엔지니어링에서는 소프트웨어 모듈이 가능한 한 독립적이어야만 한다는 것이다. 모듈들 사이의 계약의 수 및 복잡도가 최소화되어야만 하며, 따라서 하나의 모듈에서의 변화가 국부적이 되어 다른 모듈로 전파되지 않는다. 예를 들어, 애플리케이션은 부모 모듈에 있는 데이터를 가져와 이 데이터를 포맷하는 자식 모듈로 그 데이터를 전달할 수 있다. 이것이 행해질 때, 무엇이 데이터이고 그 데이터가 어떻게 전달되어야 하는지를 기술하는 계약이 있어야 한다. 자식 모듈이 필요로 하는 데이터에 변화가 있게 되면 양쪽 모듈에 변경을 주어야 한다. 그 대신에, 자식 모듈이 그 자신의 데이터를 획득하는 경우, 그 변화는 국부적이 된다. 어느 한 모듈을 어떻게 그 데이터를 획득하는지와 상관없게 만들 필요가 있거나 그의 데이터를 획득하는 코드가 몇개의 모듈에서 동일한 경우, 개별적인 데이터 빈(data bean) 및 해당하는 계약이 이들 요건 중 하나를 달성하는 데 사용될 수 있다. 그렇지만, 부모 모듈과 자식 모듈 사이에 또다른 계약의 부가는 어떤 것도 달성하지 못하고 복잡도만 부가된다.

프래그먼트가 가능한 한 필요한 모든 것을 갖추고 있어야 하는 두번째 이유는 캐싱이 효율적이 되도록 하기 위해 프래그먼트를 생성하는 코드가 필요한 모든 것을 다 갖추고 있어야 하기 때문이다. 상기 일례에서, 부모 모듈이 자식 모듈을 위한 데이터를 모두 가져와서 이를 자식에게 전달하면, 자식 모듈만이 포맷팅을 행한다. 모듈 사이의 이러한 종속성으로, 자식 모듈이 필요로 하는 데이터가 유효 기간이 지난 것일 경우, 부모와 자식 모두는 무효화되고 다시 생성되어야만 한다. 이러한 종속성은 개별적인 프래그먼트의 캐싱을 훨씬 덜 효과적이게 만든다. 다수의 부모에 의해 공유되는 프래그먼트는 상기 문제점 모두를 복잡하게 한다.

JSP 프로그래밍 모듈은 데이터가 요청 속성 또는 세션 상태를 통해 JSP 사이에 전달될 수 있게 해준다. 중첩된 프래그먼트의 경우, 요청 속성 메카니즘은 부모 JSP와 자식 JSP가 애플리케이션 서버로의 서로 다른 요청에서 검색될 수 있기 때문에 동작하지 않는다. 또한, 세션 상태 메카니즘은 부모와 자식이 서로 다른 세션에서 실행될 수 있는 경우 동작하지 않을 수 있다. 그 대신에, 전달되어야만 하는 정보는 URI 질의 파라미터 또는 쿠키를 사용해야만 한다. 요청 속성을 사용하여 부모로부터 자식으로 전달된 복잡한 데이터 구조조차도 여전히 이를 직렬화하고 이를 FRAGMENTLINK 태그의 SRC 속성의 URI에 질의 파라미터로서 포함시킴으로서 전달될 수 있다.

프래그먼트가 그 자신의 데이터를 가져올 때조차도, 이들 사이에서 어떤 제어 데이터를 전달할 필요가 있다. 다시 상기 일례들을 참조하면, 사이드바 시나리 오에서, 최상위 레벨 프래그먼트로부터 사이드바로 데이터가 전달되지 않는다. 쇼핑객 그룹 시나리오에서, 최상위 레벨 제품 설명 프래그먼트는 제품 ID를 알고 있을 필요가 있으며, 자식 그룹 제품별 가격은 제품 ID와 쇼핑객 그룹 ID 모두를 필요로 한다. 제품 ID는 외부 요청에 의해 공급된다. 쇼핑객 그룹 ID는 사용자 ID를 사용하여 애플리케이션에 의해 생성되고, 이들 모두는 로그온시에 생성된다. 제품 ID와 쇼핑객 그룹 ID 모두는 제품 설명 프래그먼트를 통해 가격 프래그먼트로 전달되어야만 한다. URI 질의 파라미터와 쿠키 모두는 자식 프래그먼트로 자동적으로 전달된다.

개인화 시나리오에서, 최상위 레벨 제품 설명 프래그먼트는 제품 ID를 알고 있을 필요가 있으며, 자식 개인화 프래그먼트는 사용자 ID를 알고 있을 필요가 있다. 이들 파라미터 모두는 외부 요청에 의해 공급되고, 따라서 사용자 ID는 제품 설명 프래그먼트를 통해 개인화 프래그먼트로 전달되어야만 한다. 이것은 "userId"라는 쿠키를 자식 프래그먼트로 전달함으로써 행해진다.

주식 감시 목록 시나리오에서, 최상위 레벨 주식 감시 목록 프래그먼트는 사용자 ID 쿠키를 알고 있을 필요가 있으며, 자식 주식 시세 프래그먼트 각각은 주식 심볼을 알고 있을 필요가 있다. 주식 심볼 및 이들을 포함하는 FRAGMENTLINK 태그는 최상위 레벨 주식 감시 목록 프래그먼트의 일부로서 생성된다. 주식 심볼은 주식 시세 프래그먼트에 전달되어야만 한다. 이것은 FRAGMENTLINK의 SRC 속성에 URI의 질의 파라미터로서 주식 심볼을 집어넣음으로써 행해진다.

FRAGMEMTLINK 태그 및 FRAGMENT 헤더의 일례

이제 표 1a 내지 표 1c를 참조하면, 전술한 사이드바 일례에 대한 한 세트의 HTML 및 HTTP문이 나타내어져 있다. 이 시나리오 내의 2개의 프래그먼트 모두는 정적이다. 부모 최상위 레벨 프래그먼트는 JSP가 되는데 그 이유는 JSP가 "jsp:include"를 사용하여 다른 프래그먼트를 포함하고 캐시 제어 정보가 부모 프래그먼트와 연관될 필요가 있기 때문이다. 자식 사이드바 프래그먼트도 JSP인데 그 이유는 캐싱 제어 정보가 그와 연관될 필요가 있지만 어떤 JSP 태그도 포함하지 않기 때문이다.

표 1a는 사이드바 프래그먼트를 포함하는 최상위 레벨 프래그먼트에 대한 HTML문을 포함하는 JSP를 나타낸 것이다.

표 1b는 최상위 레벨 프래그먼트에 대한 웹 애플리케이션 서버에 의해 생성되는 HTTP 출력을 나타낸 것이다.

표 1c는 사이드바 프래그먼트에 대한 웹 애플리케이션 서버에 의해 생성되는 HTTP 출력을 나타낸 것이다.

이제 표 2a 내지 표 2d를 참조하면, 전술한 쇼핑객 그룹 일례에 대한 한 세트의 HTML 및 HTTP문이 나타내어져 있다. 이 시나리오 내에서의 양쪽 프래그먼트는 동적이다. 제품 그룹별 가격 프래그먼트를 포함하는 최상위 레벨 프래그먼트에 대해 JSP가 사용된다. 자식 프래그먼트도 JSP인데 그 이유는 적절한 가격을 획득하기 위해 비즈니스 애플리케이션 로직을 포함하고 있기 때문이다.

표 2a는 자식 프래그먼트를 포함하는 최상위 레벨 제품 설명 프래그먼트에 대한 HTML문을 포함하는 JSP를 나타낸 것이다.

표 2b는 제품 설명 프래그먼트에 대한 웹 애플리케이션 서버에 의해 생성되는 HTTP 출력을 나타낸 것이다.

표 2c는 제품 그룹별 가격의 자식 프래그먼트에 대한 HTML문을 포함하는 JSP를 나타낸 것이다.

표 2d는 제품 그룹별 가격 프래그먼트에 대한 웹 애플리케이션 서버에 의해 생성되는 HTTP 출력을 나타낸 것이다.

이제 표 3a 내지 표 3d를 참조하면, 전술한 개인화 일례에 대한 한 세트의 HTML 및 HTTP문이 나타내어져 있다. 최상위 레벨 제품 프래그먼트를 생성하는 JSP는 하나의 사용자별 개인화 프래그먼트를 포함한다. 자식 프래그먼트도 JSP인데 그 이유는 그것이 사용자에 적절한 개인화 데이터를 획득하기 위해 비즈니스 애플리케이션 로직을 포함하기 때문이다.

표 3a는 자식 프래그먼트를 포함하는 최상위 레벨 제품 설명 프래그먼트에 대한 HTML문을 포함하는 JSP를 나타낸 것이다.

표 3b는 제품 설명 프래그먼트에 대한 웹 애플리케이션 서버에 의해 생성되는 HTTP 출력을 나타낸 것이다.

표 3c는 사용자별 자식 프래그먼트에 대한 HTML문을 포함하는 JSP를 나타낸 것이다.

표 3d는 자식 프래그먼트에 대한 웹 애플리케이션 서버에 의해 생성되는 HTTP 출력을 나타낸 것이다.

이제 표 4a 내지 표 4f를 참조하면, 전술한 주식 감시 목록에 대한 한 세트의 HTML 및 HTTP문이 나타내어져 있다. 이 시나리오 내에서의 양쪽 프래그먼트는 동적이다.

표 4a는 다수의 주식 시세 프래그먼트를 포함하는 최상위 레벨 주식 감시 목록 프래그먼트를 생성하는 JSP를 나타낸 것이다. "jspext:cookie" 태그는 "userName"이란 이름의 쿠키 내에 있는 사용자 이름을 표시한다. 이 일례는 가변 횟수의 "RequestDispatcher.include" 메쏘드 호출을 동적으로 생성하며, 그 각각은 출력에 FRAGMENTLINK 태그를 생성한다.

표 4b는 주식 감시 목록 프래그먼트에 대한 웹 애플리케이션 서버에 의해 생성되는 HTTP 출력을 나타낸 것이다.

표 4c는 FOREACH 속성을 포함하는 최상위 레벨 주식 감시 목록 프래그먼트를 생성하는 JSP를 나타낸 것이다.

표 4d는 FOREACH 속성을 포함하는 최상위 레벨 주식 감시 목록 프래그먼트에 대한 웹 애플리케이션 서버에 의해 생성되는 HTTP 출력을 나타낸 것이다.

표 4e는 개개의 주식 시세를 생성하는 JSP를 나타낸 것이다.

표 4f는 심볼 질의 파라미터 "IBM"에 대한 웹 애플리케이션 서버에 의해 생성되는 HTTP 출력을 나타낸 것이다.

결론

본 발명의 양호한 실시예의 이점은 이상에 제공된 본 발명의 양호한 실시예에 대한 상세한 설명을 살펴보면 분명하게 될 것이다. 프래그먼트 캐싱 기술은 캐시 관리 유닛이 분산 프래그먼트 캐싱 메카니즘을 제공하도록 네트워크에 걸쳐 있는 컴퓨팅 장치들에 배포되어 있는 캐시 관리 유닛 내에서 구현될 수 있다.

FRAGMENT 헤더는 HTTP 등의 네트워크 프로토콜 내에서 사용되기 위해 정의된 것으로서, 이 헤더는 프래그먼트의 처리 및 캐싱과 관련된 여러가지 목적을 위해 메타데이터를 프래그먼트와 연관시킨다. 예를 들어, 헤더는 클라이언트, 서버, 또는 어떤 중간 캐시 중 어느 하나가 페이지 조립 기능을 갖는지를 식별하는데 사용된다. 헤더는 또한 프래그먼트에 대한 캐시 식별자를 형성하기 위해 캐시 ID 규칙을 지정하며, 이 규칙들은 그 프래그먼트에 대한 URI, 또는 URI 경로 및 URI로부터의 질의 파라미터의 어떤 조합 또한 그 요청에 수반하는 쿠키에 기초할 수 있다. 게다가, 이 헤더는 호스트 개시 무효화를 지원하여 프래그먼트의 종속성 관계를 지정할 수 있다.

FRAGMENTLINK 태그는 페이지 조립 또는 페이지 렌더링 동안에 삽입될 포함된 프래그먼트에 대한 페이지 내에서의 위치를 지정하는 데 사용된다. FRAGMENTLINK 태그는 캐시 내의 링크된 프래그먼트를 찾아내거나 서버로부터 이를 검색하기에 충분한 정보를 포함하도록 정의된다. 캐시 ID 규칙은 프래그먼트가 캐시에 저장되고 있을 때와 캐시 내에서 프래그먼트를 찾기 위해 요청으로부터 소스 식별자를 처리하고 있을 때 모두에서 사용된다. 캐시에서 프래그먼트를 찾아내기 위해, 프래그 먼트의 URI 경로와 연관된 캐시 ID 규칙은 캐시 ID를 결정하는 데 사용된다. 이 규칙들에 의해, 캐시 ID 형성을 위한 표준 구현을 강요하는 컴퓨터 프로그램을 배포할 필요없이 프래그먼트에 대한 캐시 ID를 형성하는 데 높은 정도의 유연성이 가능하게 된다. 다수의 캐시 ID 규칙들이 사용될 수 있다. 캐시 ID 규칙들에 의해 캐시 ID는 프래그먼트에 대한 전체 URI 또는 URI 및 질의 파라미터 또는 쿠키의 조합이 될 수 있다. 이러한 방식에 의해, 동일한 FRAGMENTLINK가 부모 프래그먼트의 질의 파라미터 및 쿠키에 따라 서로 다른 프래그먼트의 위치를 알아낼 수 있으며, 예를 들어 제품 설명 페이지에대한 요청에서의 사용자 ID 쿠키는 개인화 프래그먼트에 대한 캐시 ID를 형성하는 데 사용될 수 있다.

주목할 중요한 점은 본 발명의 양호한 실시예가 완전 기능하는 데이터 처리 시스템과 관련하여 기술되어 있지만, 당업자라면 본 발명의 양호한 실시예와 관련된 프로세스의 일부가 배포를 실시하는 데 실제로 사용되는 신호 전달 매체의 특정 유형에 관계없이 컴퓨터 판독가능한 매체 내의 명령어의 형태 및 각종의 다른 형태로 배포될 수 있다는 것을 잘 알 수 있다는 것이다. 컴퓨터 판독가능한 매체의 일례로는 EPROM, ROM, 테이프, 종이, 플로피 디스크, 하드 디스크 드라이브, RAM, 및 CD-ROM 등의 매체와, 디지털 및 아날로그 통신 링크 등의 전송형 매체가 있다.

Claims (26)

1. 네트워크 내의 데이터 처리 시스템에서 객체를 처리하는 방법으로서,

   컴퓨팅 장치에서 제1 메시지를 수신하는 단계와,

   상기 제1 메시지 내의 메시지 헤더가 상기 제1 메시지가 프래그먼트와 관련되어 있음을 나타내는 것으로 결정하는 단계와,

   상기 제1 메시지 내의 메시지 헤더로부터 상기 프래그먼트가 캐싱가능한 것인지 여부를 결정하는 단계

   를 포함하는 데이터 처리 시스템에서의 객체 처리 방법.
2. 제1항에 있어서, 상기 제1 메시지로부터의 프래그먼트를 상기 컴퓨팅 장치 내의 캐시 관리 유닛이 유지하는 캐시에 저장하는 단계를 더 포함하고,

   상기 캐시 관리 유닛은 상기 컴퓨팅 장치가 클라이언트, 서버 또는 상기 네트워크 전체에 걸쳐 배치된 허브로서 작용하는지에 관계없이 프래그먼트 캐싱 동작을 지원하여 동등하게 동작하는 것인 데이터 처리 시스템에서의 객체 처리 방법.
3. 삭제
4. 제1항에 있어서, 상기 프래그먼트가 그 다음 레벨 프래그먼트로의 링크를 포함하는 최상위 레벨 프래그먼트인지 여부를 결정하는 단계와,

   상기 프래그먼트가 그 다음 레벨 프래그먼트로의 링크를 포함하는 최상위 레벨 프래그먼트라고 결정한 것에 응답하여 상기 그 다음 레벨 프래그먼트를 검색하는 단계와,

   상기 최상위 레벨 프래그먼트와 상기 그 다음 레벨 프래그먼트를 결합하여, 조립된(assembled) 프래그먼트로 만드는 단계를 더 포함하는 것인 데이터 처리 시스템에서의 객체 처리 방법.
5. 제1항 또는 제2항에 있어서, 상기 제1 메시지로부터 종속성 식별자의 세트(set)를 검색하는 단계로서, 종속성 식별자는 상기 프래그먼트를 발신한 서버에 의해 생성되는 것인 검색 단계와,

   상기 프래그먼트에 대한 소스 식별자와 연관하여 상기 종속성 식별자 세트를 저장하는 단계를 더 포함하는 것인 데이터 처리 시스템에서의 객체 처리 방법.
6. 삭제
7. 제1항 또는 제2항에 있어서, 상기 제1 메시지로부터 프래그먼트 캐싱 규칙의 세트를 검색하는 검색 단계로서, 프래그먼트 캐싱 규칙은 상기 프래그먼트에 대한 캐시 식별자를 생성하는 방식을 결정하는 것인 검색 단계와,

   프래그먼트 캐싱 규칙에 따라 상기 프래그먼트에 대한 캐시 식별자를 생성하는 단계를 더 포함하는 것인 데이터 처리 시스템에서의 객체 처리 방법.
8. 삭제
9. 삭제
10. 삭제
11. 제1항, 제2항 또는 제4항 중 어느 한 항에 의한 방법을 수행하는, 네트워크 내의 데이터 처리 시스템에서 객체를 처리하는 컴퓨팅 장치.
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 네트워크 내의 데이터 처리 시스템에서 객체를 처리하기 위한 컴퓨터 프로그램을 포함하는 컴퓨터로 판독 가능한 기록 매체로서,

    상기 컴퓨터 프로그램은 청구항 제1항, 제2항 또는 제4항 중 어느 한 항에 기재된 방법의 각각의 단계들을 실행하기 위한 각각의 명령어들을 포함하는 것인 컴퓨터로 판독 가능한 기록 매체.
22. 네트워크 내의 데이터 처리 시스템에서 객체를 처리하는 방법으로서,

    프래그먼트에 대한 소스 식별자를 포함하는 요청 메시지를 서버에서 수신하는 단계와,

    상기 프래그먼트를 포함하는 응답 메시지를 생성하는 단계,

    상기 요청 메시지가 프래그먼트와 관련되어 있음을 나타내는 메시지 헤더를 상기 응답 메시지 내에 삽입하는 단계, 및

    상기 프래그먼트가 캐싱가능한 것인지 여부를 나타내는 메시지 헤더를 상기 응답 메시지 내에 삽입하는 단계

    를 포함하는 데이터 처리 시스템에서의 객체 처리 방법.
23. 네트워크 내의 데이터 처리 시스템에서 객체를 처리하는 컴퓨팅 장치로서,

    프래그먼트에 대한 소스 식별자를 포함하는 요청 메시지를 수신하는 수단과,

    상기 프래그먼트를 포함하는 응답 메시지를 생성하는 수단과,

    상기 요청 메시지가 프래그먼트와 관련되어 있음을 나타내는 메시지 헤더를 상기 응답 메시지에 삽입하는 수단과,

    상기 프래그먼트가 캐싱가능한 것인지 여부를 나타내는 메시지 헤더를 상기 응답 메시지에 삽입하는 수단

    을 포함하는 데이터 처리 시스템에서의 객체 처리용 컴퓨팅 장치.
24. 네트워크 내의 데이터 처리 시스템에서 객체를 처리하기 위한 컴퓨터 프로그램을 포함하는 컴퓨터로 판독 가능한 기록 매체로서,

    상기 컴퓨터 프로그램은 청구항 제22항에 기재된 방법의 각각의 단계들을 실행하기 위한 각각의 명령어들을 포함하는 것인 컴퓨터로 판독 가능한 기록 매체.
25. 삭제
26. 삭제

Images