KR20060082353A

KR20060082353A - 실행가능 웹 컨텐트 제공 및 처리 시스템 및 방법

Info

Publication number: KR20060082353A
Application number: KR1020050003032A
Authority: KR
Inventors: 전윤호
Original assignee: 와이더댄 주식회사
Priority date: 2005-01-12
Filing date: 2005-01-12
Publication date: 2006-07-18
Also published as: CN101103352A; JP2008527564A; EP1839189A4; WO2006075872A1; EP1839189A1; US20100005527A1; CN100543724C

Abstract

본 발명은 실행가능 웹 컨텐트를 단말기로 제공하는 시스템으로서, 선언적 언어로 된 선언적 언어부 및 비선언적 부분을 포함하는 실행가능 웹 컨텐트를 제공하는 서버와, 상기 실행가능 웹 컨텐트를 상기 서버로부터 전송받아서 상기 단말기의 웹 브라우저에서 실행될 수 있는 형태로 변환하여 상기 단말기에 전송하는 게이트웨이를 포함하는 시스템을 제공한다.

실행가능 웹 컨텐트, 무선 인터넷, 휴대용 단말기

Description

실행가능 웹 컨텐트 제공 및 처리 시스템 및 방법{System and method for providing and handling executable web content}

도 1은 본 발명에 따라 실행가능 웹 컨텐트(XC)를 제공하기 위한 네트워크 시스템의 개략도이다.

도 2는 도 1의 상세한 세부 블록도이다.

도 3은 본 발명에 따라 실행가능 웹 컨텐트(XC)를 제공하기 위한 네트워크 시스템의 다른 개략도로서, 본 발명에 따른 보안 기능을 설명하기 위한 개략도이다.

도 4는 자바의 클래스 파일의 구조의 일례를 도시한다.

도 5a 및 도 5b는 본 발명의 일실시예에 따라 트랜잭션의 수를 줄이는 기본적인 방법을 설명하기 위한, 네트워크 시스템의 개략도이다.

도 6은 본 발명의 일 실시예에 따른, 캐쉬를 이용하여 불필요한 전송을 방지하는 알고리즘을 설명하기 위한 도면으로서 브라우저 측 알고리듬을 도시한다.

도 7은, 본 발명의 일 실시예에 따른, 캐쉬를 이용하여 불필요한 전송을 방지하는 알고리즘을 설명하기 위한 도면으로서 게이트웨이측에서 실행되는 알고리듬을 도시한다.

도 8은 종래기술의 브라우저의 공유 리소스를 관리하는 방법을 도시한 도면 이다.

도 9는 본 발명의 일실시예에 따라 공유 리소스를 관리하는 방법을 도시한 도면이다.

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

100: 웹 서버 200: 게이트웨이

210: XCML-자바 변환부 220: 자바 컴파일러

230: 자르 처리부 240: 보안관리부

250; 프로토콜 스택 269: 캐쉬

300: 단말기 310: 브라우저

본 발명은 휴대전화 등 데이터 통신을 위한 네트워크 접속이 가능한 휴대용 단말기에서, 다양한 콘텐츠 및 서비스를 제공할 수 있는 방법 및 시스템을 제공하기 위한 것이다. 보다 구체적으로는 종래의 웹 방식 및 다운로드 어플리케이션 방식의 기술적 특징과 장점을 동시에 제공할 수 있는 무선 인터넷 플랫폼을 제공하기 위한 것이다.

종래에는 휴대용 단말기에서 인터넷을 사용하기 위해서 WAP(Wireless Application Protocol) 브라우저로 대표되는 무선 인터넷 전용의 브라우저가 사용되었다. WAP 브라우저의 여러 버전 중에서 1.x 버전과 2.x 버전은 동작하는 방식 이 서로 많이 다르다. WAP 1.x 버전에서는 WML(Wireless Markup Language)과 WMLScript라는 고유의 컨텐트 형식을 사용한다. 즉, 유선 인터넷의 마크업언어인 HTML(HyperText Markup Language)에 해당하는 WML을 사용하고, 간단한 코드를 단말에서 실행하기 위해서는 유선 인터넷의 자바스크립트(JavaScript)에 해당하는 WMLScript를 사용한다. 이와 같은 형식으로 표현된 컨텐트는 먼저 유선 네트워크를 통해 WAP 게이트웨이에 전달되고, 게이트웨이에서 보다 컴팩트하고 효율적인 바이너리 형식("WBXML"로 호칭됨)으로 변환된 후 무선 네트워크를 통해 전송된다.

한편 WAP 2.x 버전은 유선 인터넷의 HTML 표준에 보다 가까운 XHTML (eXtensible HyperText Markup Language) Mobile Profile(XHTMLMP) 마크업 언어를 사용하며 자바스크립트와 유사한 에크마 스크립트(ECMAScript)가 곧 도입될 전망이다.

유무선에 관계없이 브라우저는 기본적으로 어휘가 제한되고 선언적인 (declarative) 문법을 갖는 마크업 언어를 컨텐트 형식으로 사용하기 때문에 표현형식의 자유도가 높은 컨텐트를 만드는 것이 어렵다. 이러한 제약을 극복하고자 크게 다음과 같은 기술이 도입되었거나 도입될 예정이다.

스크립트: 자바스크립트(JavaScript)로 대표되는 스크립트는 텍스트 형식으로 된 프로그램 코드를 웹서버에 올려놓으면 텍스트 형식 그대로 브라우저에 전송되거나, 혹은 WAP의 경우 게이트웨이에서 바이트코드로 변환되어 브라우저에 전송된다. 스크립트는 마크업 언어에 비하여 상대적으로 더 강력한 기능을 갖는 프로그래밍 언어로서 HTML, WML등 선언적 문법 형식으로는 구현이 불가능한 기능을 단 말기에서 구현하기 위해 사용된다.

애플릿(Applet): 선 마이크로시스템스 사에서 개발한 자바 애플릿 (Java Applet)은 자바 언어로 작성된 작은 프로그램이다. 이와 같은 애플릿을 미리 컴파일해서 웹서버에 올려두면 브라우저가 이를 다운로드하여, 브라우저 내의 자바 가상 머신(Java Virtual Machine)을 이용하여 실행하고 그 결과를 다른 컨텐트와 함께 화면에 보여준다.

플러그인(Plug-in): 예를 들어 마이크로소프트사 윈도우스의 액티브엑스(ActiveX) 플러그 인은 단말 플랫폼에 고유한 고유코드(native code)로 만들어지고, 대개 DLL(Dynamic Load Library) 형식을 갖는다. 브라우저에 의해 다운로드된 후 동적으로 로드(load)되어 실행되며 단말 플랫폼이 제공하는 모든 API(Application Programming Interface)를 사용할 수 있어, 강력하고 다양한 기능을 제공할 수 있으나 반면에 포인터 연산이 가능하고, 프로그램의 기능을 미리 검사하는 것이 어려운 등의 이유로 바이러스나 악성소프트웨어(malware) 등이 클라이언트 컴퓨터에서 실행되는 것을 방지하기 어렵다는 단점을 갖는다.

HTML 계열의 마크업 언어들은 원래 단순한 텍스트의 디스플레이를 주 목적으로 만들었던 것으로서 이에 따르는 기본적인 한계를 가지고 있다. 이러한 마크업 언어의 한계를 극복하기 위해 위에 설명한 것과 같은 기술이 HTML 혹은 WML을 주 언어로 하는 컨텐트에 보조적으로 도입되고 있으며 이들은 각각 서로 다른 장단점을 갖기 때문에 최근의 PC용 브라우저에서는 위의 기술들을 모두 지원하고 있다. 따라서 브라우저의 구조가 복잡해지고 크기가 커지며, 위와 같은 기술을 사용하는 데 있어서 보안 문제가 발생할 수 있고, 또한 브라우저가 불안정해질 가능성이 있다. 휴대폰과 같이 상대적으로 PC등에 비하여 컴퓨팅 파워가 약하고 메모리 등의 리소스가 부족한 휴대용 단말기에서도, 점점 다양한 브라우저의 기능이 요구되고 있으며, 이에 따라 PC용 브라우저와 유사한 기능이 점진적으로 도입되고 있다. 그러나, 휴대폰에서는 PC에 비해 브라우저의 크기와 복잡도, 불안정성의 문제가 더 큰 제약으로 작용한다.

PC의 경우 위에서 설명한 브라우저 및 마크업 언어의 한계와 단점을 극복하기 위해 종래의 HTML과 완전히 다른 방식의 기술이 제안되고 있다. 마이크로소프트사에서 2006년 출시 예정인 롱혼(Longhorn)이라는 코드명의 윈도우스 운영체계에는 "XAML(extensible Application Markup Language)"이라 불리는 새로운 마크업 형식을 지원하는 브라우저가 탑재될 예정이다. "XAML"은 "C#" 프로그래밍 언어 코드로 된 부분을 그 일부로 포함할 수 있으며, 마이크로소프트 닷넷 (.NET) 프레임워크의 CLR(Common Language Runtime)에서 실행 가능한 매개언어(IL: Intermediate Language) 바이트코드로 변환된 후 실행된다. 이러한 변환은 미리 오프라인으로 이루어져서 바이트코드를 직접 서버에서 브라우저로 전송할 수도 있고, 또는 텍스트 형태로 브라우저에 전송된 컨텐트가 브라우저 내에서 바이트코드로 변환되어 실행될 수도 있다. 어떤 경우이건 프로그래밍 언어 (C#등)와 선언적 마크업 언어(XAML)로 작성된 컨텐트는 최종적으로 직접 실행이 가능한 매개언어(IL) 바이트코드로 변환되어 브라우저에 의해 동적으로 로딩되어 실행된다. 이와 같은 기술을 이용하면 마크업 언어가 갖는 장점, 즉 컴팩트하고 쉬운 표현 형식 및 기존 웹 개 발 방식과의 호환성을 유지하면서도 범용 프로그래밍 언어의 장점(다양한 기능과 사용자 인터페이스의 제공)을 필요에 따라 수용할 수 있다. 따라서, 현재 HTML 및 부가 언어(스크립트, 플러그인 등)에 의해 만들어지는 웹사이트에 비해 훨씬 더 강력하고 편리한 사용자 인터페이스(User Interface)를 제공할 수 있을 것으로 예상된다. 하지만 이와 같은 기술은 강력한 CPU와 대용량의 메모리를 갖는 PC를 대상으로 개발되는 기술로서, 연산력이 적고 메모리 용량도 적은 휴대폰과 같은 휴대용 단말기에 구현되기에는 적합하지 않다.

한편, 유선 인터넷의 경우 바이러스나 개인정보유출 방지를 위하여 사용자가 다운로드하는 컨텐트나 프로그램에 대해 소정의 보안 장치가 필요하고 폭넓게 구현되어 있다. 무선 네트워크는 유선 네트워크에 비하여 통신의 비용이 고가이고, 사용자가 통신량에 따라 사용료를 부담하는 경우가 많으므로, 만일 사용자가 다운로드한 컨텐트가 사용자가 모르게 소기의 동작을 수행하는 경우 사용자가 원하지 않는 통신비용이 발생할 수도 있다. 따라서, 즉, 유선 인터넷의 경우의 바이러스 확포나, 개인정보유출 등의 문제에 더하여 사용자에게 직접적인 금전적 피해를 줄 수 있다.

보안기능의 필요성 및 종래의 구현방법을 좀더 구체적으로 살펴보면, 자바 애플릿, 액티브액스(ActiveX) 등과 같이 네트워크로부터 다운로드받은 코드를 직접 실행할 때에는 이 코드가 어떤 일을 할지 단말기 측에서 미리 알기 어렵기 때문에 보안 기능이 필요하다. 일반적인 바이너리 코드를 다운로드하여 실행하는 경우, 즉 ActiveX와 같은 네이티브 코드(CPU가 직접 수행하는 코드)의 경우는 그 코드가 어떤 일을 수행하는지 단말측에서 미리 검사하거나 런타임에 특정한 보안 정책을 강제할 수 없다. 따라서, 바이러스나 악성소프트웨어(malware)가 단말측에서 수행되는 것을 방지하기 위하여 이 코드를 다운로드할 때 인증을 받도록 하는 절차를 거치게 할 수 있다.

한편 데스크탑 PC 혹은 서버에서 실행되는, 자바의 대표적인 에디션인 "Java 2 Standard Edition(J2SE)"에는 처음부터 네트워크를 통해 코드를 다운로드하는 것을 전제로 규격이 만들어졌기 때문에, ActiveX의 경우보다 더 정교한 보안 기능을 갖고 있는데, 이 기능은 주로 코드를 어느 서버로부터 다운로드 받았는지에 따라서 해당 코드의 실행시, 허용이 되는 기능이 제한되는 방식을 취한다.

모바일 장치를 위한 자바(Java 2 Mobile Edition, J2ME), 특히 이 중에서도 휴대폰과 같이 메모리와 프로세싱 파워가 제약된 장치를 위한 컨피규레이션(configuration) 즉, CLDC(Connected Limited Device Configuration)의 가상머신(VM)과 런타임 라이브러리는 메모리 사용량을 줄이고 실행 속도를 향상시키기 위해 전술한 J2SE와 비교할 때 보다 간단한 보안 기능을 갖고 있다. MIDP 1.x 버전에서는 인증을 받은 어플리케이션인지 아닌지에 따라 민감한 기능에의 접근을 허용하거나 차단하는 간단한 구분만 가능하다. 최근 정의된 MIDP 2.0 버전의 규격에서는 기능별로 허용 여부의 정책을 설정할 수 있다.

종래 모바일용 자바의 보안 메커니즘은 모두 하나의 어플리케이션이 하나의 서버로부터 다운로드되는 것을 가정, 이 서버의 주소에 따라 보안 정책이 선택, 적용되었고 이 정책은 그 어플리케이션과 가상머신(virtual machine)이 종료될 때까 지 변경될 수 없다는 한계점을 갖는다. 따라서, 하나의 웹 컨텐트의 어플리케이션을 구성하는 코드가 여러 서버로부터 다운로드될 수 있는 경우는 전술한 것과 같은 기존의 자바의 보안 메커니즘을 이용해선 적절한 보안 기능을 구현할 수 없다. 또한 기타 다른 면에서도 충분히 경우에 따라 다양하게 적용할 수 있는 정교한 보안 기능을 제공하지 못하였다.

본 발명의 목적은 실행 가능한 웹 컨텐트를 제공하기 위한 새로운 웹 플랫폼에 관한 것으로, 구체적으로는 휴대용 단말기의 낮은 프로세싱 속도와 메모리의 한계를 극복하고 풍부하고 다양한 기능 및 형태를 갖는 컨텐트를 무선 네트워크를 통해 제공하고 단말기에서 실행할 수 있도록 하는 방법 및 시스템을 제공하는 것이다.

본 발명의 다른 목적은 무선 네트워크를 통하여 전송되는 무선 컨텐트 및 이를 실행하기 위한 단말기의 보안기능을 강화하며, 정교하게 하는 방법 및 시스템을 제공하기 위한 것이다.

본 발명의 또 다른 목적은 무선 네크워크를 통한 웹 컨텐트 전송의 효율성을 개선하는 방법 및 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은 무선 웹 컨텐트를 캐싱하는데 있어서, 캐쉬 일관성을 구현하기 위한 방법 및 시스템을 제공하는 것이다.

상기 목적을 달성하기 위하여, 본 발명의 일면에 의하면, 실행가능 웹 컨텐 트를 단말기로 제공하는 시스템으로서,

선언적 언어로 된 선언적 언어부 및 비선언적 부분을 포함하는 실행가능 웹 컨텐트를 제공하는 서버와,

상기 실행가능 웹 컨텐트를 상기 서버로부터 전송받아서 상기 단말기의 웹 브라우저에서 실행될 수 있는 형태로 변환하여 상기 단말기에 전송하는 게이트웨이를 포함하는 시스템을 제공한다.

상기 단말기는 무선통신 단말기이고, 상기 웹 컨텐트는 무선 웹 컨텐트이다.

상기 웹 서버와 상기 게이트웨이는 유선 네트워크에 의하여 연결되고, 상기 게이트웨이는 무선 네트워크를 통하여 단말기에 연결된다.

상기 단말기는 무선 웹 브라우저를 포함하고,

상기 게이트웨이는 상기 무선 웹 브라우저로부터의 소정의 웹 컨텐트의 요청을 무선 네트워크를 통해 수신하고, 유선 네트워크를 통해 상기 소정의 웹 컨텐트를 상기 서버에 요청하며,

상기 웹 켄텐트는 하나 이상의 파일을 포함하며,

상기 서버로의 웹 컨텐트의 요청은 상기 하나 이상의 파일의 요청을 포함하며,

상기 게이트웨이는 상기 서버로의 요청에 따라 서버로부터 수신한, 웹 컨텐트를 구성하는 하나 이상의 파일을 한번의 트랜잭션으로 단말기로 전송한다.

상기 웹 컨텐트를 구성하는 하나 이상의 파일은 웹 컨텐트 본문과 리소스 파일을 포함하며,

상기 웹 컨텐트의 요청은 웹 컨텐트의 본문의 요청과, 리소스 파일의 요청을 포함한다.

상기 웹 컨텐트는 정적 파일, 동적으로 생성되는 파일, 절차적 코드의 소스 코드, 실행가능 이진파일, 멀티미디어 파일 중 하나 이상을 포함한다.

상기 비선언적 부분은 절차적 코드를 포함하고,

상기 게이트웨이는 선언적언어부를 절차적 코드로 변환하는 수단과, 절차적 코드를 컴파일하여 실행가능 파일로 변환하는 수단을 포함할 수 있다.

상기 비선언적 부분은 절차적 코드를 포함하고, 상기 게이트웨이는 선언적언어부를 컴파일하는 수단과, 절차적 코드를 컴파일하는 수단과, 상기 선언적언어부를 컴파일한 결과와, 절차적 코드를 컴파일한 결과를 머지(merge)하여 실행가능 파일을 생성하는 수단을 포함할 수 있다.

상기 게이트웨이는 단말기의 웹 브라우저에서 실행될 수 있는 형태로 변환된 웹 컨텐트 내에 보안 정책에 위반하는 기능이 포함되어 있는지 검출하는 수단을 포함한다.

상기 검출수단은 웹 컨텐트 내에 보안 정책에 위반하는 기능을 갖는 파일이 포함되어 있는 경우 해당 파일을 단말기로 전송하지 않거나, 해당 파일을 단말기로 전송하기에 앞서 단말기 사용자의 허락을 받거나, 해당 파일에 런타임시, 시스템의 기설정된 보안정책에 따라 결정되는 소정의 동작을 수행하게 하는 코드를 삽입한다.

본 발명의 다른 일면에 따르면, 실행가능 웹 컨텐트를 단말기로 제공하는 시 스템으로서,

실행가능 웹 컨텐트를 제공하는 서버와,

상기 실행가능 웹 컨텐트를 상기 서버로부터 전송받아서 상기 단말기의 웹 브라우저에서 실행될 수 있는 형태로 변환하여 상기 단말기에 전송하는 게이트웨이를 포함하고 상기 웹 컨텐트는 정적 파일, 동적으로 생성되는 파일, 절차적 코드의 소스코드, 실행가능 이진파일, 멀티미디어 파일 중 하나 이상을 포함하고,

상기 게이트웨이는 선언적언어 및 절차적 코드를 컴파일하여 실행가능 파일로 변환하는 수단을 포함하는 시스템을 제공한다.

상기 절차적 코드의 소스코드는 자바 코드를 포함하고, 상기 실행가능 이진파일은 자르(jar) 파일을 포함할 수 있다.

본 발명의 또다른 일면에 따르면, 실행가능 웹 컨텐트를 서버로부터 받아서, 단말기의 웹 브라우저에서 실행될 수 있는 형태로 변환하는 게이트웨이로서, 상기 웹 컨텐트는 정적 파일, 동적으로 생성되는 파일, 절차적 코드의 소스코드, 실행가능 이진파일, 멀티미디어 파일 중 하나 이상을 포함하고, 선언적언어 및 절차적 코드를 컴파일하여 실행가능 파일로 변환하는 수단을 포함하는 게이트웨이를 제공한다.

게이트웨이는 선언적 언어부를 절차적 코드로 변환시키는 변환부와,

절차적 코드를 컴파일하는 컴파일러와

웹서버로부터 받은 실행가능 이진파일을 분석하여 추가의 외부 파일을 참조하는 경우 이를 페치하는 처리부와

웹서버로부터 받은 웹 컨텐트에 보안에 문제가 되는 기능이 포함되어 있는지 결정하는 보안 관리부를 포함한다.

상기 단말기는 무선 웹 브라우저를 포함하고,

상기 웹 컨텐트는 하나 또는 그 이상의 파일을 포함하며,

상기 게이트웨이는 상기 무선 웹 브라우저로부터의 소정의 웹 컨텐트의 요청을 무선 네트워크를 통해 수신하고,

상기 소정의 웹 컨텐트의 요청은, 웹 컨텐트 중 브라우저에 이미 캐싱되어 있는 파일의 이름 및 최종 변경시간 정보를 포함하고,

상기 게이트웨이는 유선 네트워크를 통해 상기 소정의 웹 컨텐트를 상기 서버에 요청하며,

상기 서버로의 웹 컨텐트의 요청은 상기 하나 또는 그 이상의 파일의 요청을 포함하며,

상기 게이트웨이는 상기 서버로의 요청에 따라 서버로부터 수신한, 웹 컨텐트를 구성하는 하나 또는 그 이상의 파일을 수신하고, 상기 캐싱되어 있는 파일의 이름 및 죄송 변경시간정보와 비교하여 캐싱된 파일로부터 변경되었거나 새로 추가된 파일만을 단말기로 전송한다.

본 발명의 다른 일면에 따르면, 실행가능 웹 컨텐트를 브라우징하기 위한 웹 브라우저를 포함하는 단말기로서, 상기 웹 브라우저는 바이너리 실행 코드 형태의 웹 컨텐트를 수신하여 실행하는 것을 특징으로 하는 단말기가 제공된다.

상기 웹 컨텐트는 하나 이상의 파일을 포함하고, 상기 하나 이상의 파일은 다른 파일에서 참조되는 공유 리소스 파일을 포함하며,

상기 단말기는 캐쉬를 포함하고,

상기 공유 리소스 파일이 상기 캐쉬에 캐싱될 때, 상기 공유 리소스 파일이 얼마나 많은 다른 파일에서 참조되는지를 나타내는 참조 회수가 같이 저장되는 것을 특징으로 한다.

상기 단말기가 상기 캐싱된 공유 리소스 파일의 캐싱된 버전보다 새로운 버전의 파일을 포함하는 웹 컨텐트를 전송받은 경우, 상기 새로운 버전의 공유 리소스 파일을 캐쉬에 저장하고, 상기 기 저장된 공유 리소스 파일의 참조회수를 1 감소한다.

상기 감소 후 참조회수가 0이면, 상기 기 저장된 공유 리소스 파일을 삭제한다.

본 발명에서는 새로운 방식의 마크업 언어인 실행가능 컨텐트용 마크업 언어(XCML: eXecutable Content Markup Language)와 이를 이용하여 웹 컨텐트를 제공하는 방법 및 시스템을 제공한다. 본 발명에서 제안하는 XCML은 기존 무선 인터넷 컨텐트의 표준 형식인 WML 혹은 XHTML과 마찬가지로 XML을 기반으로 하는 마크업 언어이다. 즉, XCML은 HTML이나 WML과 마찬가지로 선언적(declarative) 형식을 가지는 선언적 언어부(태그(tag)를 이용하여 표현된다는 의미로 이하, "태그부"라고 칭하기도 함)을 주 내용으로 하되, HTML 내에 자바스크립트가 포함되는 것과 마찬가지로 선언적 문법으로 표현하지 못하는 내용(비선언적 부분)은 자바 스크립트와 같은 절차적 코드에 의해 표현하여 텍스트 형태로 웹 컨텐트 파일 내에 포함하거나 ("자바 코드부"), 외부 자바 파일을 파일 내에서 참조할 수 있도록 한 마크업 언어의 형식이다.

본 발명에 따른, XCML 형식의 컨텐트 및 기타의 웹 컨텐트를 제공하기 위한 네트워크 시스템은 도 1에 도시된 바와 같이, 먼저 웹서버(100)와 유선 네트워크로 연결된 게이트웨이(gateway, 200)에서 컨텐트를 자바 등의 실행코드(자바의 경우 일반적으로 자바 바이트 코드로 칭함)로 변환한 후 무선 네트워크를 통해 단말기(300)에 전송, 실행하도록 구성되어 있다. 따라서, 종래의 네크워크 시스템이 웹 서버(서버단)과 브라우저(클라이언트단)으로 구성되는 것에 비하여, 본 발명에 따른 네트워크 시스템은 웹서버와, 게이트웨이 및 브라우저(클라이언트)로 구성되어 있다. 도 1은 이와 같이 구성된 네트워크 시스템을 도시하는 블록도이고, 도 2는 도 1에 도시된 각 구성요소인, 웹서버(100), 게이트웨이(200), 단말기(300)를 각각 더 상세히 도시한 블럭도이다. 이하 도 1 내지 2의 각 부분에 대해 설명한다. 이하에서 프로그래밍 언어로서는 자바를, 실행 코드로서 자바 바이트 코드(Java bytecode)를 가정하고 있으나 본 발명은 이에 한정되지 않고 유사한 성격의 다른 언어도 적용할 수 있다.

도 1 및 도 2에서 웹서버(100)는 HTTP 프로토콜에 의해 일반적인 웹 혹은 WAP의 컨텐트를 제공하는 일반적인 웹 서버일 수 있다. 웹서버가 제공하는 컨텐트는 정적인 텍스트나 이미지 파일일 수도 있고 CGI (Common Gateway Interface)나 서브렛(Servlet) 등에 의해 동적으로 생성되는 파일일 수도 있다. 이러한 파일은 본 발명에 따른 XCML (eXecutable Content Markup Language) 형식의 텍스트 파일( 도 2의 120, 130)이거나 자바 소스코드 파일(140), 자르(Jar) 파일 (150, 하나 이상의 Java classfile 및 기타 리소스 파일이 하나로 합쳐진 파일) 또는 이미지, 음악, 동영상 파일(160) 등을 포함할 수 있다. 본 발명에서 웹서버(100)가 제공하는 XCML 파일은 다양한 실행가능 요소를 자유롭게 포함할 수 있어, 기존의 무선 인터넷 컨텐트에 비하여 강력한 기능을 수행할 수 있는 컨텐트의 제공이 가능하다. 본 명세서에서 파일이라 함은 종래의 컴퓨터 파일 시스템에서 사용되는 파일의 개념 뿐 아니라, 네트워크를 통해 하나의 단위로서 전송되는 데이터(프로그램 코드, 이진파일 등 포함)의 모음을 포함하는 개념이다. 즉, 단말기의 브라우저가 제공하는 기능에 한정되지 않고, 무선 단말기의 플랫폼(운영체제) 자체에서 제공되는 다양한 기능을 이용하는 컨텐트의 개발 및 제공이 가능해진다. 예를 들어 단말기에 저장된 전화번호 정보를 이용하여 소정의 동작을 수행하는 컨텐트와 같이, 기존의 브라우저에서는 이용할 수 없던 컨텐트의 제공이 가능하다.

본 발명의 게이트웨이에서는, 단말기의 캐쉬저장 내용의 갱신 필요성 여부를 웹서버와 다수(즉, 무선구간인 단말기-게이트웨이간의 통신보다 많은 회수)의 통신으로 확인한다. 유선 구간에서는 여러 번의 트랜잭션이 일어나도 크게 시간이 소요되지 않지만, 무선구간에서는 왕복시간(round trip)이 길기 때문에 여러 번에 걸쳐 정보가 나누어져 전달되게 되면 시간 지연이 매우 커진다는 점을 이용하기 위하여 (캐싱을 위한) 무선구간의 단위통신(트랜잭션)의 회수를 줄이기 위한 것이다. 이런 방식에 따르면 단말기의 캐쉬의 기능을 완전히 이용하면서도, 게이트웨이와 단말기 간(즉, 무선구간)의 트래픽의 횟수를 줄여서 효율성을 높인다. 이와 같이 캐싱을 이용한 통신 효율성 향상에 대해서는 도 5a 내지 도 7을 참조하여 더 상세히 설명하기로 한다.

도 2를 참조하여, XC 게이트웨이(200) 내의 각 블록의 기능을 상세히 살펴보면 다음과 같다. XCML 자바 변환부(210)는 본 발명에 따른 XCML 형식으로 된 텍스트 파일을 미리 정해진 방법에 따라 자바 코드로 변환하는 기능을 수행한다. 이 때 생성되는 자바 코드는 텍스트 형식의 자바 소스 코드이거나 혹은 소스 코드의 단편(fragment)들을 포함하는 소정의 표현 형식의 코드일 수 있다. 전술한 바와 같이 XCML에는 XCML 고유의 태그로 이루어진 부분(기 설명한 "태그부")과 텍스트 형태로 포함된 자바 코드부가 있다. XCML 태그로 이루어진 선언적 부분은 게이트웨이(200)에서 자바 코드로 변환되어 서버측(100)에서 처음부터 자바로 작성된 부분(자바 코드부)과 합쳐지고 컴파일되어 자바 클래스를 이루게 된다. 이와 같이 태그부와 자바 코드부를 합쳐서 자바 클래스로 컴파일하기 위한 방법은 여러가지가 있을 수 있는데 그 중 하나는 태그부를 자바 소스 코드 텍스트로 변환한 후 기존의 자바 코드부와 결합하여 하나의 완전한 자바 프로그램 소스를 생성한 후 이를 컴파일하는 것이다. 이와 같은 방식에서 XCML 자바 변환부(210)는 XCML 텍스트 파일 중 태그부를 텍스트 형식의 자바 소스 코드를 전환하여 기존의 자바 코드부와 합쳐서 자바 컴파일러(220)에 전달하는 역할을 하고, 자바 컴파일러(220)는 자바소스코드를 컴파일하여 자바 클래스 파일로 만드는 역할을 수행한다.

본 발명의 다른 실시예에 따르면, 태그부를 자바 소스 코드 형태로 변환하는 대신 바로 자바 바이트 코드로 변환하고, 원래 자바 코드로 작성된 자바 코드부는 별도로 컴파일하며 태그부의 바이트 코드와 결합(merge)함으로써 하나의 자바 클래스를 만들 수 있다. 이 경우 XCML 자바 변환부(210)는 XCML 파일 중 태그부를 바이트 코드로 전환하고, 자바 컴파일러(220)는 자바코드부를 컴파일하면서, 태그부의 바이트 코드와 결합하여 자바 클래스 파일을 생성하는 역할을 수행한다.

XCML 파일 중에서 자바 코드(도 2의 140)를 참조하는 경우, 게이트웨이에서는 웹서버에 자바코드(140)를 요청하여 이를 전송받는다. 이 경우 XCML 자바 변환부(210)에서 생성된 자바코드와 웹 서버로부터 페치된 자바코드를 결합하여 실행파일을 만든다. 이 경우 자바 컴파일러(220)는 XCML 자바 변환부(210)에서 생성된 자바코드 뿐 아니라, 웹서버에서 페치한 자바코드도 같이 컴파일하고 결합하는 역할을 수행한다.

XCML 파일 중에서는 자바 코드(도 2의 140)뿐 아니라 자르(jar) 파일을 직접 참조하는 경우도 있을 수 있다. 이 경우, 게이트웨이가 XCML 파일을 해석하여 필요한 자르 파일를 웹서버로 요청하여 전송받는다. 또한 브라우저가 게이트웨이를 통해 서버에 요구하는 새로운 웹 컨텐트가 XCML이 아니라 처음부터 자바로 작성, 별도 컴파일된 자르 파일로 구성되어 있는 경우도 있다. 자르 파일 처리부(Jar file handler: 230)는 이와 같이 웹서버(100)로부터 다운로드받은 파일이 컴파일이 필요없는 자르(jar) 파일인 경우, 자바 컴파일러(220) 대신 다운받은 파일을 처리하는 블럭이다. 자르 파일 처리부(230)에서는 자르(jar) 파일이 참조하는 외부 파일이 있는 경우 그 리스트를 추출하여 웹서버(100)로부터 페치(fetch)하도록 한다.

이와 마찬가지로 웹서버(100)로부터의 XCML 파일에 이 파일들이 참조하는 별 도 파일들이 있는 경우 이와 같은 리소스도 별도로 웹 서버(100)로부터 페치된다. 이와 같이 참조되는 외부 리소스 파일 페치를 위한 별도의 리소스 페치부(도시되지 않음)가 XC 게이트웨이(200) 내에 구현될 수 있다.

캐쉬부(260)는 웹 서버(100)로부터 페치해온 파일이나 컴파일된 결과의 바이너리 파일 등을 보관하는 등 저장 기능을 수행하는 공간으로서, 다양한 기능을 수행하도록 설계될 수 있음이 당업자에게 알려져 있으므로 그 상세한 연결관계나 기능은 도시하지 않는다. HTTP 프로토콜 규격에 의해 캐쉬의 유효성(validity)을 체크한다는 점에서 종래의 웹 캐쉬와 유사하나, 웹서버로부터 받아온 형식이 아니라 컴파일된 결과를 저장하는 경우가 있다는 점에서는 차이가 있다.

보안 관리부(security manager, 240)는 바이트코드가 클라이언트 측 즉, 단말기(300)에 전송되기 전에 보안상 문제가 되는 코드를 포함하고 있는지를 검사한다. 만약 전송될 바이트코드가 보안상 문제가 되는 코드를 포함하고 있으면 다운로드를 거부하거나 혹은 단말기 사용자의 동의를 거쳐서 다운로드되도록 할 수 있다. 구체적인 보안 관리 방법에 대해서는 이하에서 상세하게 설명하기로 한다.

프로토콜 스택 (Protocol Stack, 250)은 통신 프로토콜의 각 층(layer)을 구현한 프로그램 요소의 세트로서, 단말기와의 접속을 위한 무선 인터넷 망의 특성을 고려, 왕복거리(round-trip)를 최소화할 수 있도록 변형된 HTTP 프로토콜을 사용한다. 본 발명에 따른 이와 같은 프로토콜의 보다 구체적인 사항에 대해서는 이하에서 상세하게 설명하기로 한다.

다음은 단말기(300) 측의 구성요소를 더 상세히 설명하기로 한다. 단말기 (300)는 휴대전화, PDA(personal digital assistance) 등 무선 인터넷 컨텐트를 다운받아 실행 디스플레이하기 위한 다양한 종류의 장치를 포함할 수 있다.

도 1 및 도 2의 XC 브라우저(eXecutable Content Browser, XCB, 310)는 XC 게이트웨이(200)와 접속하여 바이트코드를 주 내용으로 하는 컨텐트를 다운로드받아 실행하는 클라이언트 어플리케이션으로서 단말기(300)에서 실행된다.

유저 인터페이스(User Interface, 320)는 공통 메뉴, 설정 등 브라우저(310) 자체의 유저 인터페이스를 의미한다. 즉, 컨텐트의 내용과 관련 없이 브라우저가 본래 가지고 있는 공통의 유저 인터페이스 요소들을 의미한다. 예를 들면 이전 페이지로 가기, 새로 고침, URL 열기, 북마크, 히스토리, 옵션등이 이에 포함된다.

도 2에서 페이지 1, 페이지 2 등은 웹서버(100)로부터 다운로드되어 실행되는 컨텐트의 단위를 나타내는 블록이다. 각 페이지는 URL(Uniform Resource Indicator)에 의해 고유하게 정의되고 하나 이상의 자바 클래스 및 리소스 파일로 구성될 수 있다.

UI(User Interface)요소(360)는 레이블(label, 한줄의 텍스트 박스), 버튼 (button) 등과 같은 UI의 요소를 의미하고, XCML 혹은 자바 프로그램에서 사용하거나 상속될 수 있다. 구체적으로 본 발명의 일실시예에 따르면 XCML에서는 각 UI 요소를 이에 해당하는 하나의 태그를 이용하여 표현할 수 있다. 예를 들어 "Help"라는 텍스트가 표시되는 버튼을 만들기 위해서는

와 같이 기술할 수 있으며 이 태그는 특정 클래스, 예를 들어 UI 요소인 "widerthan.xcb.Xbutton" 클래스의 한 인스턴스(instance)를 생성하는 코드로 변환된다. 본 발명에 따르면 컨텐트 내에서 시스템(XCB)이 제공하는 기본 UI 요소(360)의 외관(look & feel)이나 기능을 확장 또는 변경하는 것이 가능하게 된다. 즉, 기본 UI 요소를 확장 변경하기 위해 UI 요소에 해당하는 자바 클래스를 새로운 클래스로 상속하여 일부 기능을 추가하거나 변경할 수 있다. 예를 들어, widerthan.xcb.XButton 클래스를 상속하는 MyButton이라는 클래스를 XCML 콘텐츠 내의 "header" 부분에서 정의하고, 이 클래스를 이용하기 위해 XCML 콘텐츠의 "body" 부분에서는

과 같이 기술할 수 있다.

레이아웃 관리자(layout manager, 350)(혹은 레이아웃 엔진 (layout engine)이라고 칭하기도 함)는 UI 구성요소(360)들을, 컨텐트에 의해 결정된 조건에 따라 화면상에 배치하는 역할을 한다. 예를 들어 화면의 좌측에 소정의 형태의 버튼 구성요소가 배치되는 것으로 웹서버의 콘텐츠에 기술되어 있는 경우, 이 컨텐트가 게이트웨이(200)에서 변환된 바이트코드가 XC 브라우저(310)에서 실행될 때 레이아웃 관리자(350)는 원래의 컨텐트의 내용에 맞도록 구성요소를 배치하는 역할을 수행한다.

캐쉬(370)는 서버로부터 다운로드 받은 자바 바이트코드 및 기타의 리소스 파일들을 캐싱하는 역할을 수행한다. 이하에서 더욱 상세히 서술할 바와 같이 적절한 캐싱 기능을 통해 게이트웨이(200)와 단말기(300)간의 무선구간의 통신량을 적게 할 수 있다.

브라우저(310)의 프로토콜 스택은 XC 게이트웨이(200)의 프로토콜 스택(250)에 대응한다.

전술한 바와 같이, XCML은 HTML이나 WML과 마찬가지로 선언적(declarative) 형식을 가지는 부분을 주 내용으로 하며 HTML 내에 자바스크립트(JavaScript)가 포함되는 것과 마찬가지로 선언적 문법으로 표현하지 못하는 내용은 자바 코드에 의해 표현하여, 웹 컨텐트 파일 내에 포함하거나 웹 페이지 파일(XCML 파일) 내에서 외부 자바 파일을 참조할 수 있다.

종래의 웹 서버와 단말기로 구성된 네트워크 시스템에서, 선언적 마크업 언어와 자바스크립트 부분을 포함하는 웹 페이지 파일이 최종적으로 단말기 화면에 표시되는 과정의 일례는 다음과 같다.

(1) 단말기의 브라우저가 웹서버에 특정 URL에 의해 지정되는 웹 컨텐트 파일을 요구한다.

(2) 웹 서버에서 웹 페이지 파일을 생성하거나 혹은 URL에 의해 지정되는 웹 컨텐트 파일을 읽어 네트워크로 전송한다.

(3) 단말기의 브라우저가 상기 파일을 다운로드하여 파싱(parsing)한다.

(4) 파서(parser)가 정해진 방법에 따라 UI 컴포넌트들을 생성하여, 파일에서 지정하는 형식에 의해 초기화한다.

(5) 자바스크립트 부분은 실행 가능한 내부 표현 형식으로 변환, 저장한다.

(6) 사용자의 입력은 각 UI 컴포넌트를 초기화할때 지정된 속성에 따라 처리 하거나, 또는 UI 컴포넌트의 기본 기능이 아닌 기능을 수행하고 하는 경우에는 UI 컴포넌트에 연결된 자바스크립트를 호출하여 처리한다. 예를 들어, 버튼 입력등에 의해 여러 개의 UI중 특정 UI 컴포넌트에 포커스가 가도록 동작시켰을 때 색상이 변경되도록 초기화하는 것은 다음과 같은 코드로 구현될 수 있다.

<a href="http://www.foo.com"

onfocus="javascript:this.style.backgroundcolor='yellow'">

Link

</a>

이와 같은 초기화 내용에 따라, 특정 컴포넌트에 포커스를 이동시키는 사용자의 입력은 색상 변경이라는 동작을 야기시키도록 지정된다.

이에 비해 본 발명에 따른 XCML 파일을 단말기에 다운받아 수행하기 위해서는 예를 들어 다음과 같은 과정을 거치게 된다.

(1) 브라우저(단말기)가 사전에 지정된 XC 게이트웨이(200)에 접속하여, 특정 URL에 의해 지정되는 XCML 파일의 요청을 게이트웨이에 전송한다.

(2) 게이트웨이가 서버(100)에 단말기(300)에서 요청한 XCML 파일을 요청한다.

(3) 서버(100)에서 XCML 파일을 생성하거나 혹은 URL에 의해 지정된 파일을 읽어 네트워크로 전송한다.

(4) 게이트웨이(200)가 XCML 파일을 다운로드하고, 파싱하여 자바 실행 코드를 생성한다. 이 때 생성되는 코드는 위의 종래의 브라우저가 UI 컴포넌트를 생성 하고 초기화하는 것과 동일한 동작을 수행하는 코드이다.

(5) 게이트웨이가, 다운받은 XCML 파일 내에 포함되어 있거나 또는 XCML 파일이 참조하는 외부 자바 코드를 함께 자바 바이트코드(Java bytecode)로 컴파일하여 단말기(300)의 XC 브라우저로 전송한다.

(6) XC 브라우저(310)는 자바바이트코드(Java bytecode)를 다운로드받아 동적으로 클래스 로딩(class loading)하고 이 코드를 실행한다. 즉 자바 바이트코드를 네트워크로부터 다운로드 받은 후 현재 실행중인 자바 버츄얼 머신(virtual machine)에 로딩하여, 어플리케이션에서 이 바이트코드에 의해 정의되는 클래스를 사용할 수 있도록 한 후, 이 코드를 실행한다. 이 코드 실행과정에서 UI 컴포넌트들이 생성되고 초기화된다.

(7) 이때 사용자 입력은 상기 (6)의 과정에서 생성된 UI 컴포넌트들이 처리하거나 또는 별도로 포함된 자바 코드가 처리한다.

즉 종래의 웹 서버와 단말기의 브라우저를 이용한 브라우징 방식과 본 발명의 방식의 대표적인 차이점은 다음과 같다.

(i) 기존 브라우저에서는 브라우저 내에 웹 컨텐트 파일을 해석하고 UI 컴포넌트(360)를 생성, 초기화하는 기능이 포함되어 있는데 비해 본 발명에 따른 방식에서는 이와 같은 기능이 게이트웨이(200) 측에 있다. 즉, 게이트웨이가 자바 코드를 생성하여 단말기측으로 다운로드하고 클라이언트에서는 단지 이 코드를 실행하기만 한다.

(ii) 기존 브라우저에서 절차적 요소(procedural component)는 자바스크립트 로 표현되고, 이와 같이 자바스크립트로 표현된 부분은 이를 실행 가능한 형식(주로 고유한 바이트코드)으로 변환하는 브라우저 내의 자바스크립트(JavaScript) 컴파일러 및 바이트코드 해석기(bytecode interpreter)에 의해 수행된다. 반면에 본 발명에 따르면 자바로 표현된 절차적 코드가 선언적 언어부와 함께 컴파일되어 동일하게 자바 바이트코드로 변환된 후 단말기의 자바가상머신(JVM: Java Virtual Machine)에서 실행된다는 점이다.

이와 같은 본발명의 방식의 장점은 다음과 같은 점을 포함한다.

- (선언적 언어부의) 선언적 문법에 의해 생성되는 코드와 (비선언적 부분의) 절차적 코드가 동일한 API(Application Program Interface)와 객체(object)를 이용하므로 둘 사이의 연동이 보다 직접적이고 효율적이다.

- 단말기의 브라우저에 의해 제한받지 않고, 자바가상머신(JVM) 및 단말 라이브러리가 갖는 모든 API 및 기능을 이용할 수 있고 단말기에서는 웹 페이지 파일을 파싱하는 과정 없이 바로 코드를 실행하기만 하면 된다.

- 컨텐트를 표현하는 마크업 언어에 새로운 문법이 추가되어야 할 때에도 단말기의 브라우저에 해당 기능을 추가하는 등의 변경이 필요하지 않다.

보안 기능

이하에서는 도 3을 참조하여 본발명에 따른 보안 기능을 설명하기로 한다.

도 3은 본 발명에 따라 실행가능 웹 컨텐트(XC)를 제공하기 위한 네트워크 시스템의 개략도로서, 본 발명에 따른 보안 기능을 예시적으로 설명하기 위한 것이다. 도 3의 경우와 같이, 콘텐츠 제공자(Content Provider: CP)의 서버 B의 P라는 페이지를 단말기에서 실행하고자 할 때 P가 통신 사업자의 서버 A에 있는 라이브러리리 L을 참조하는 경우 XC 게이트웨이(200)는 P와 L이 합쳐진 자바 어플리케이션을 클라이언트(XC Browser, 310)에 다운로드한다. 이 때 통신사업자의 라이브러리와, 콘텐츠 제공자의 프로그램에는 다른 수준의 보안정책이 적용될 수 있다. 즉, 통신 사업자에 의해 그 내용이 관리되는 L에 대해서는 단말기의 모든 기능을 사용할 수 있도록 허용을 하고 P에 대해서는 전화걸기나 주소록등 특정 기능에 대한 접근을 막는 보안 정책이 필요할 수 있다.

본 발명에 따르면 이와 같이 하나의 컨텐트(P+L) 내에서도 서로 다른 보안 정책을 구현하는 것이 가능한 새로운 보안 메커니즘을 제공한다. 본 발명에서는 기존의 경우와 달리 게이트웨이가 각 서버로부터 다운로드받은 자바 코드를 정적으로(static) 검사하여 각 서버별로 지정된 보안 정책을 위배하는 코드가 포함되어 있는 경우 다운로드를 금지하거나 사용자의 허락을 받도록 하는 방안을 제시한다. 이하에서는 본발명에 따른 보안 메커니즘을 상세히 설명하기로 한다. 대상이 되는 페이지가 자바 코드가 아닌 마크업 언어로 작성되어 있는 경우 게이트웨이(200)가 이 파일을 파싱하여 자바 코드를 생성하는 과정에서 보안 정책을 강제하는 경우 구체적인 방법은 알려져 있으므로 이 경우에 대한 자세한 설명은 생략하고, 이하에서는 자바 클래스 파일의 구조 및 이에 따른 보안 메커니즘에 대해 설명하기로 한다.

게이트웨이(200)가 어떤 서버(100)로부터 자바 소스코드 혹은 바이너리 파일(클래스 파일 혹은 클래스 파일을 포함하는 jar 파일)을 다운로드 받은 경우, 게이트웨이에서 보안기능을 구현하기 위해서 게이트웨이가 다운받은 코드가 단말의 어 떤 기능을 액세스하는지 판단하고 이를 제어할 수 있어야 한다. 이를 위해서는 게이트웨이가 자바 클래스 파일을 분석할 필요가 있다. 도 4는 자바의 클래스 파일의 구조의 일례를 보여준다. 이 중에서 실제로 실행되는 바이트코드(bytecode)는 "methods" 영역에 포함되어 있다. 임의의 메모리에 대한 액세스가 가능한 네이티브 코드(native code)(예를 들어 어셈블리 코드)와 달리 자바 인터프리터나 JIT (just-in-time) 컴파일러를 거쳐 실행되는 자바 바이트코드는 클래스 파일 내의 콘스턴트 풀(constant pool: 도 4 참조)에 의해 지정되는 클래스와 함수만을 액세스할 수 있다. 따라서 콘스턴트 풀을 검색하면 이 클래스가 액세스하는 다른 클래스 및 함수가 무엇인지를 알 수 있다.

일단 어떤 코드가 정책상 접근이 금지된 클래스나 함수에 접근하고 있다는 것(예를 들어 전화번호부 읽는 동작을 금지시키는 것 가능)을 게이트웨이(200)가 발견하면 이 코드의 사용을 금지하거나 단말기의 사용자에게 해당 기능의 사용에 대한 허가를 받는 등의 기능을 수행하여야 하며 이렇게 하는 데에는 여러 가지 방법이 있을 수 있다. 이와 같은 방법의 몇 가지 예를 아래에 설명한다. 이와 같은 다수의 방법 중 어떤 방법을 적용할지 여부는 통신 사업자의 정책 혹은 보안 도메인별로 지정되는 보안 정책에 의해 결정될 수 있다.

(가) 다운로드를 금지하는 방법: 사용자(즉 클라이언트)가 다운로드하고자 하는 페이지를 이루는 클래스 파일들 중에 보안 정책에 위배되는 코드가 포함되어 있는 경우 이 파일의 게이트웨이부터 단말로의 다운로드를 중지시키고 사용자와 관리자에게 그러한 사실을 통보한다. 도 1 및 2에 도시된 실시예에서는 보안 메니저 (240)에 의해 위와 같은 기능이 수행된다.

(나) 다운로드 시 사용자의 확인을 받도록 하는 방법: 사용자가 요청하는 페이지가 어떤 기능에 접근하는지를 사용자에게 먼저 알리고 사용자가 이를 승인하는 경우에만 그 페이지로 이동한다. 예를 들어, 클라이언트가 게이트웨이에게 요구한 페이지가 전화걸기 함수를 참조하는 경우 게이트웨이는 먼저 이와 같은 사실을 사용자에게 알리고 (예를 들어, "이 프로그램은 전화를 거는 기능이 포함되어 있습니다. 진행하시겠습니까?" 라는 메시지를 단만 장치측에 보냄) 사용자의 승낙 여부를 클라이언트가 다시 게이트웨이에 알려 사용자가 승낙하는 경우만, 해당 페이지를 단말기로 다운로드한다.

(다) 런타임 시 사용자의 확인을 받는 방법: 위의 두가지 방법은 어떤 코드가 실제로 보안 정책에 위배되는 일을 하기 전에 다운로드가 원천적으로 차단된다는 특징을 갖고 있다. 하지만 실제로 그 코드를 실행할 때 이를 차단하거나 승낙을 받도록 하는 것이 더 바람직한 경우가 있을 수 있다. 즉, 일률적으로 소정의 기능의 코드가 차단되도록 하는 것이 아니라 실행 시 구체적으로 어떤 일을 하는가에 따라 보안정책을 다르게 적용하는 것이 바람직한 경우로서, 예를 들면, 모든 서버로의 접속을 통제하는 대신 소정의 서버로의 접속만 허용하거나, 단말기 측 파일을 액세스하는 코드를 전면적으로 막는 대신 소정의 파일(소정의 디렉토리 내의 파일)의 액세스만 허용하는 것 등이 있을 수 있다. 이와 같이 런타임시의 조건에 따라 보안정책이 선택적으로 적용되도록 하는 것은 게이트웨이에서는 불가능하고 단말기에서 런타임시에나 가능하다. 따라서, 게이트웨이에서는 런타임시 소정의 동 작을 수행하게 하는 코드를 프로그램에 삽입함으로써 원하는 기능을 구현할 수 있다. 런타임시 확인하는 방법을 프로그램에서 구현하는 방법의 실시예는 다음과 같다. 즉, 첫번째 방법은 참조되는 클래스를 대치하는 방법으로서, 소정의 무선 웹 페이지 P의 어떤 코드가 보안 정책상 접근이 금지된 클래스 C의 함수 F를 액세스할 때, 클래스 C를 상속하고 함수 F를 오버라이드(override)하는 새로운 클래스 C1을 미리 클라이언트에 만들어두거나 P에 포함시켜 다운로드한다. 단말기에서는, C1의 함수 F는 사용자의 승낙을 받았을 때만 C의 함수 F를 호출한다. 이와 같은 보안기능 구현을 위한 게이트웨이의 동작을 살펴보면, P에 포함된 클래스의 콘스탄트 풀(constant pool)에서 C를 참조하는 항목(entry)을 대신 C1을 참조하도록 수정하고 수정된 버전을 클라이언트에 다운로드한다. C1은 C를 상속하기 때문에 F 이외의 모든 함수는 C의 함수가 그대로 호출되게 되고, F의 실행여부를 제외하고는 모두 원래의 페이지 P의 기능이 모두 수행된다. 위의 방법은 클래스 C나 함수 F가 최종적인 속성을 갖고 있을 경우 오버라이드(override)가 불가능한 경우도 있을 수 있고 그런 경우는 적용할 수 없다는 단점이 있다.

두번째 방법은 이와 같은 단점을 극본하기 위한 방법으로서, C를 상속하는 C1이 아닌 새로운 클래스 D를 만들고 D의 F가 사용자의 승낙을 받은 후 C의 F를 호출하도록 한다. D는 C를 상속하는 클래스가 아니라 단지 F만 호출하는 역할을 하는 것이므로, 위에서처럼 콘스탄트 풀(constant pool)의 C에 대한 참조(reference)를 D로 대치하면 F 이외의 함수를 호출할 수 없게 된다. 따라서 콘스탄트 풀에 D를 위한 새로운 항목을 만들고 메쏘드(method) 영역의 바이트코드를 스캔하여 문제 가 되는 C의 F를 호출하는 코드를 대신 D의 F를 호출하도록 수정하는 한편, D의 F에는 C의 F를 호출하기 전에 사용자의 승낙을 받도록 하는 코드를 삽입한다.

위의 방법에 의하면 코드의 일부에 대해서만, 각각 다른 보안 정책을 설정, 강제할 수 있게 된다. 즉, 예를 들어 하나의 페이지가 각각 다른 서버로부터 다운로드되는 경우도 이 코드들에 대해 각각 다른 보안 정책을 설정, 강제할 수 있다.

이상 설명한 것 이외에도 런타임시의 조건에 따라 보안 정책을 적용하는 다양한 방법이 있을 수 있다.

통신 효율 개선

일반적으로 셀방식의 무선 인터넷에서 기존 방식(WAP, 특히 web)의 브라우저를 사용하면 반응속도가 유선 인터넷과 비교할 때 많이 느린데 이는 무선 인터넷의 느린 전송속도와 함께 특히 전송 속도에 비해서도 더 느린 왕복시간 (RTT: Round Trip Time)에 기인한다. 기존 브라우저의 경우, HTML 혹은 WML로 쓰여진 본문을 서버로부터 다운로드하여 파싱한 후에야 그 페이지가 필요로 하는 다른 파일들, 예를 들어 이미지 파일들, 자바스크립트 파일들, CSS(cascade style sheet) 파일들 등을 서버에 요구할 수 있기 때문에 한 페이지를 보여주기 위해 여러 차례의 트랜잭션(transaction, 요구(request)과 응답(response)을 포함)을 수행해야 한다. 유선 (PC) 브라우저들의 경우 여러 파일을 다운로드받는 시간을 줄이기 위해 HTTP 1.1의 파이프라인 프로토콜(pipelining protocol)을 이용하거나 서버와 둘 이상의 TCP 연결(TCP connection)을 여는 방법을 사용한다. 무선 인터넷에서 사용하는 WAP 브라우저의 경우 구현상의 문제로 인해 대부분 HTTP 1.1의 파이프라인이나 복 수 TCP 연결을 사용하지 않는다. 또한, 설사 구현이 가능하다고 하더라도 복수의 TCP 연결을 열게 되면 각 연결마다 초기 접속에 필요한 지연 및 초기속도가 느린 TCP의 특성에 따른 오버헤드를 갖게 되므로 특히 이러한 지연이나 오버헤드의 영향이 크게 나타나는 무선 인터넷에서는 효율적이지 않다. 또한, HTTP 1.1의 파이프라이닝은 전체적인 페이지 로딩 시간을 줄이는 효과가 있겠지만 이 경우에도 외부 파일을 참조하는 웹페이지의 경우 최소한 2번의 트랜잭션에 필요한 시간(즉, 페이지 본문을 받기 위한 트랜잭션과, 본문 파싱후 파악된 나머지 리소스/파일들을 요청하는 트랜잭션)과 수신한 파일들을 파싱하는데 소요되는 시간의 합이 필요하다.

후술하는 본 발명의 일실시예에 따른, 개선된 프로토콜을 사용하면, 트랜잭션의 수를 최소화하면서도 전송량이 늘어나지 않도록 하여, 페이지 로딩 시간을 줄일 수 있다.

도 5a 및 5b는 본 발명의 일실시예에 따라 트랜잭션의 수를 줄이는 기본적인 방법을 설명하기 위한 도면이다. 즉 도 5a는 종래의 무선인터넷 서버와 브라우저에서, 다수의 파일을 포함하는 하나의 웹페이지가 브라우저로 다운로드되는 과정을 도시한 것이고, 도 5b는 본 발명의 일실시예에 따라 다수의 파일을 포함하는 하나의 웹페이지를 브라우저로 다운로드하는 과정을 도시한 것이다. 도 5a에서 하나의 화살표는 한번의 트랜잭션을 의미하고, 작은 직사각형은 하나의 파일을 나타낸다. 도 5a에 도시된 방법에 따르면, 브라우저가 먼저 소정의 페이지의 본문 파일을 가져오고 이를 해석한 후 페이지 내에서 참조하는 파일들을 차례로 가져오고, 따라서 하나의 파일 당 한번의 트랜잭션이 발생하며, 모든 트랜잭션은 무선 네트워크를 통 하여 이루어진다. 설사 게이트웨이가 서버와 브라우저 사이에 있는 시스템(도 5a에서 점선으로 도시된 게이트웨이가 시스템 내에 존재하는 경우)이라고 하더라도, 종래의 게이트웨이는 파일요청과 그 결과를 그대로 통과시킬 뿐이고, 서버로부터 어떤 파일을 전송할지는 모두 브라우저에서 결정되므로, 무선 트랜잭션의 수에는 영향을 주지 않는다.

한편, 도 5b에 도시된 본 발명의 일실시예에 따르면, 브라우저(310)가 게이트웨이(200)에 소정의 웹 페이지를 요구하면, 게이트웨이(200)는 브라우저의 개입 없이도 상기 페이지가 필요로 하는 다른 파일들까지 모두 서버로부터 페치(fetch)해서 한꺼번에 브라우저에게 전송한다. 이러한 방식이 가능하기 위해서는 특정 페이지에서 필요로 하는 파일들이 무엇인지를 게이트웨이(200)가 파악할 수 있여야 한다. 소정 페이지에서 필요로 하는 파일을 모두 게이트웨이가 안다는 것은 브라우저가 특정 페이지를 대표하는 하나의 URL(대표 URL)만 명시하여 페이지를 요구하는 경우, 게이트웨이가 이 페이지에서 필요로 하는 다른 파일들이 무엇인지를 알아낸다는 의미이다. 본 발명에 따른 XC 게이트웨이(200)는 브라우저(310)로부터 전송되는 대표 URL에 해당하는 XCML 파일을 서버로부터 페치하여 이를 파싱하기 때문에 XCML 파일에서 정적(static)으로 참조하는 외부 파일들을 알 수 있고, 이에 따라 브라우저의 요구 없이도 웹 서버(100)에게 이들 파일을 다시 요구하고, 페이지 본문의 파일과 함께 다 모아서 단말기의 브라우저(310)로 한꺼번에 다운로드할 수 있다. 이렇게 하게 되면 유선 구간에서 여러 번의 트랜잭션에 의해 게이트웨이가 서버로부터 모은 데이터를 무선구간에서는 한번의 트랜잭션으로 단말기로 전송시키 게 된다. 도 5a와 도 5b는 모두 3개의 파일이 하나의 웹페이지에 포함되어 있는 경우를 상정한 예로서, 트랜잭션 수를 비교하면, 도 5a의 경우(게이트웨이가 없는 경우) 3회의 무선 트랜잭션을 포함하는 데 비하여, 도 5b는 1회의 무선 트랜잭션과 3회의 유선 트랜잭션을 포함한다. 일반적으로 유선 네트워크에서의 RTT는 무선의 RTT보다 훨씬 짧기 때문에 유선 네트워크 구간에서 여러 번의 트랜잭션을 하는 것은 전체 응답 시간에 큰 영향을 미치지 않는다. 따라서, 전체적으로 무선구간의 트랜잭션 수가 적은 도 5b의 방법은 도 5a의 방법에 비하여 통신 효율이 더 높다.

또한, 본 발명의 다른 실시예에 따르면, 통신 방식을 더욱 효율적으로 만들기 위해서 이미 브라우저의 해당 페이지의 최신 버전의 파일이, 단말기 내의 캐쉬에 캐싱되어 있는 경우 이를 다시 다운로드하지 않도록 하여 통신에 소요되는 시간을 최소화한다.

무선 인터넷의 경우 대개 사용자에게 전송 용량에 비례하는 패킷당 과금을 하기 때문에 불필요한 다운로드가 이루어지는 경우 부당하게 과다한 요금이 청구될 수 있고 응답시간도 느려지기 때문에 이미 어떤 파일이 브라우저에 캐쉬되어 있는 경우 이를 다시 다운로드하지 않는 것이 바람직하다. 도 6 및 도 7은, 본 발명의 일 실시예에 따른, 캐쉬를 이용하여 불필요한 전송을 방지하는 알고리즘을 설명하기 위한 도면으로서 각각 브라우저 측 및 게이트웨이측에서 실행되는 알고리듬을 도시한다. 이하에서는 도 6 및 7을 참조하여 브라우저 및 게이트웨이 각각의 동작을 설명하기에 앞서서 본 발명의 캐쉬 이용 알고리듬을 개괄적으로 설명한다.

1. 브라우저(100)가 특정 페이지를 대표하는 URL을 이용, 게이트웨이에(200) 이 페이지를 요구할 때, 이 페이지가 단말기에 캐쉬되어 있는 경우에는

- 캐쉬된 메인 페이지 파일의 최종변경시간(last modified time), 이 페이지에서 참조하는 파일 중 현재 캐쉬에 남아있는 파일들의 이름 및 각각의 최종변경시간을 포함하는 "캐싱된 페이지 파일 리스트"를 함께 게이트웨이에 알려준다. 이를 위하여 브라우저는 각 페이지의 관련 파일들(메인 페이지 및 참조파일)과 함께 캐싱된 페이지 파일 리스트를 함께 캐쉬에 저장한다. 본 발명의 일실시예에 따르면 캐쉬에 저장된 파일은 페이지 단위로 만료(expire)되어 캐쉬로부터 삭제되므로, 대부분의 경우 소정의 페이지가 필요로 하는 참조파일은 해당 페이지의 메인 페이지 파일과 함께 캐쉬에 저장되어 있게 되나, 페이지가 갱신되어 새로운 파일을 페이지에서 참조하는 경우는 캐쉬에 저장된 파일과 실제 참조파일이 차이가 나게 된다.

2. 게이트웨이는 브라우저가 요구한 대표 URL에 상응하는 서버에 메인 페이지 파일을 요구한다.

2a. 게이트웨이가 서버로부터 받은 메인 페이지가 XCML 형식인 경우: XCML을 파싱한다. 파싱의 결과로 이 페이지에서 참조하는 파일들의 리스트인 페이지 파일 리스트가 얻어진다. 이 페이지 파일 리스트는 전술한 것과 유사하게 소정의 페이지에서 필요로 하는 파일 이름들과 파일의 최종변경시간을 포함한다. 이 리스트에서 명시된 파일의 최신 버전을 서버로부터 가져와서 게이트웨이 캐쉬에 저장한다. 이 때 게이트웨이 캐쉬의 내용이 최신인 경우 HTTP If-Modified-Since 프로토콜에 의해 실제로 내용의 다운로드가 일어나지는 않는다. 동시에, 페이지 파일 리스트에는 각 파일의 최종변경시간 정보가 더해진다. 게이트웨이는 위의 1번 단계에서 브 라우저가 전송한 브라우저에 캐싱된 페이지 파일 리스트와 게이트에서 파싱의 결과로 얻은 페이지 파일 리스트를 비교한다. 비교결과 게이트웨이는 캐싱된 파일로부터 변경되었거나 새로 추가된 파일을 게이트웨이에서 얻은 페이지 파일 리스트와 함께 다운로드하고 서버측에서 없어진 파일은 삭제할 것을 단말기의 브라우저에 지시한다. 브라우저에 캐싱된 파일과, 서버에 있는 파일의 파일명 및 최종변경시간이 동일한 경우는 변경되지 않은 것으로 판단하고 다운로드하지 않는다.

2b. 서버로부터 받은 메인 페이지 파일이 바이너리 파일인 경우: 이와 같은 바이너리 파일은 자바 클래스 파일과 함께 해당 페이지의 메타 정보를 함께 가지고 있도록 구성되어 있다. 예를 들어 자바 프로그램의 패키징과 전송에 표준적으로 사용하는 자르(jar) 파일의 경우 META-INF라는 내부 디렉토리에 MANIFEST.MF라는 이름의 텍스트 파일을 포함하고 있으며 이 파일에는 버전, 프로그램의 이름, 시작 클래스 등이 명시되어 있다. 본 발명의 일실시예에 따르면 MANIFEST.MF 파일에 종래에 포함되는 정보에 추가적으로 해당 페이지가 참조하는 다른 파일들의 목록을 표기하도록 한다. 이 경우 게이트웨이는 이러한 메타정보 파일을 파싱하여 메인 페이지가 필요로 하는 참조 파일 명과 최종변경시간을 포함하는 페이지 파일 리스트를 얻고 이후 메인 페이지가 XCML인 경우와 동일한 절차에 의해 새로이 다운로드가 필요한 파일들만을 (즉, 브라우저에 캐싱된 것과 다른 파일만을) 브라우저로 다운로드한다.

단, 2a와 2b에 있어 1번 단계에서 브라우저가 대표하는 페이지 URL만을 전송하고 페이지 파일 리스트를 전송하지 않은 경우, 즉 브라우저가 해당 페이지를 캐 싱하고 있지 않은 경우에는 게이트웨이는 브라우저에 페이지 파일 리스트만을 먼저 전송하고 실제 파일을 전송하지는 않는다. 이는 브라우저가 해당 페이지를 캐싱하고 있지는 않으나 이 페이지에서 참조하는 파일 중 일부가 다른 페이지에서도 참조되어 브라우저의 캐쉬에 존재하는 경우 불필요한 다운로드를 막기 위한 것이다.

3. 위와 같은 동작에 의하여 브라우저는 게이트웨이가 보내는 파일들과 페이지파일리스트를 받는다(S60). 만약 리스트 내에 포함된 파일을 따로 받지 않았는데 이 파일이 캐쉬에도 저장되어 있지 않거나 캐쉬에 저장된 파일의 최종변경시간이 리스트에 표시된 최종변경시간보다 이전인 경우 이러한 파일들을 게이트웨이에 새로 요구한다(S80).

4. 브라우저는 기존에 캐쉬에 없었던 파일들을 캐쉬에 저장하고, 갱신된 파일의 경우 캐쉬를 갱신한다. 페이지에서 참조하는 파일 목록 등을 포함하는 페이지파일 리스트도 수신한 정보에 의해 갱신한다(S100).

5. 파일의 다운로드 및 저장이 완료되면 페이지에 해당하는 자바 클래스를 로드하여 실행한다(S110).

이러한 알고리즘에 의하면 브라우저와 게이트웨이간 최대 두번의 트랜잭션에 의해 필요한 모든 파일을 불필요한 전송 없이 다운로드할 수 있다.

이하에서는 도 6을 참조하여 위와 같은 알고리즘 구현하기 위하여, 단말기측에서 이루어지는 동작을 살펴본다.

단계 S10에서 사용자가 기존에 보던 페이지 또는 북마크에서 소정의 링크를 누르는 등의 방법으로 새로운 페이지를 요청하면, 단계 S20에서 단말기의 캐쉬에 선택된 해당 페이지의 내용이 캐쉬되어 있는지를 판단한다. 선택된 페이지가 캐쉬에 없는 경우, 단계 S50에서 해당 페이지를 게이트웨이에 요구한다. 해당 페이지가 캐쉬되어 있는 경우 브라우저는 캐쉬로부터 캐싱된 페이지 파일 리스트를 가져와서(S30), 선택된 페이지를 게이트웨이에 요청함과 동시에 캐싱된 페이지 파일 리스트를 게이트웨이로 전송한다(S40). 브라우저의 요청에 따라 게이트웨이에서 보내주는 메인 페이지 파일, 참조 파일 및 페이지 파일 리스트를 단계 S60에서 수신하고, 단계 S70에서는 게이트웨이로부터 받은 리스트 내에 포함되어 있으나 캐싱되어 있지 않은 파일이 있는지 확인한다. 캐싱되어 있지 않은 파일이 있는 경우는 추가로 필요한 파일을 게이트웨이에 요구하여(S80) 수신하며(S90), 수신이 완료되고 더 이상 받을 파일이 없으면 수신한 파일을 캐쉬에 저장(S100)한 후, 메인 페이지 파일을 실행한다(S110).

다음은 도 7을 참조하여, 본 발명의 일실시예에 따라 위와 같은 알고리즘 구현하기 위하여, 게이트웨이측에서 이루어지는 동작을 살펴본다.

단계 S210에서 게이트웨이는 단말기가 접속하여, 통신을 개시하는 것을 대기하다가, 단말기가 접속을 해오면, 소정의 접속 절차에 의해 통신을 개시시키고 단계 S220으로 넘어간다. 단계 S220에서는 단말기로부터의 요구(Request)를 기다리다가 요구가 오면 이를 수신한다. 단계 S230에서는 수신된 요구가 접속 종료 요구인지 판단하여 접속 종료 요구인 경우에는 해당 단말기의 접속에 관련된 동작을 종료한다. 접속 종료 요구가 아닌 경우에는 대표 URL의 요구인지 판단한다(S240). 대표 URL의 요구라 함은, 사용자가 URL을 입력하거나, 링크를 누르는 등의 방법으 로 소정의 페이지를 새로 요청하는 경우, 이 해당 URL의 데이터를 요청하는 것을 의미하는 것이다. 대표 URL의 요구는 브라우저에서 소기의 페이지의 파일을 일부 받은 후에 부족한 파일들을 마저 요구하는 것과 상대되는 개념이다. 즉, 전술한 바와 같이 하나의 메인 페이지 파일의 실행에 필요한 파일들이 브라우저로 전송된 후 브라우저가 하나의 페이지를 완성시키기에 필요한 파일이 모두 있는지 확인하여 부족한 파일이 있으면 이를 요청하게 되며, 브라우저의 게이트웨이에 대한 요구는 접속요구, 접속 종료 요구 등의 통신을 위한 기본적은 요구 이외에, 대표 URL의 요구 및 전술한 개별 파일의 요구(페이지 만들기 위한 일부 파일이 부족한 경우) 등을 포함한다. 대표 URL의 요구인 경우, 게이트웨이는 브라우저로부터 해당 페이지에 필요한 파일 중 캐쉬되어 있는 파일들의 이름 및 파일의 최종변경시간을 포함하는 캐싱된 페이지 파일 리스트를 같이 수신한다.

브라우저로부터의 요구가 대표 URL의 요구인 경우, 게이트웨이는 해당 URL의 메인 페이지 내용을 웹서버에 요구한다(S250). 게이트웨이는 메인 페이지를 수신한 후 수신한 페이지의 종류를 확인하고(S260) XCML 타입의 파일인 경우는 이 파일을 파싱하고, 그 결과로 페이지 파일 리스트를 작성한다(S270). 수신한 파일이 자르 파일(jar file)과 같은 바이너리 파일인 경우는 MANIFEST 파일을 파싱하여 페이지 파일 리스트를 작성한다(S280). 페이지 파일 리스트 작성 후에는 브라우저로부터 받은 캐싱된 페이지 파일 리스트와 비교하여, 브라우저로 새로 다운로드 해주어야 할 파일들의 목록을 작성한다(S290). 다운로드할 파일들이 결정된 후에는 이를 서버 혹은 게이트웨이 내의 캐쉬로부터 가져온 후(S300), 파일 리스트와 함께 브라우 저로 전송한다(S310).

단계 S240에서 브라우저로부터의 요청이 대표 URL이 아닌 경우는, 브라우저가 부족한 파일들을 요청하는 경우이다. 이 경우는 단계 S300으로 와서 해당 파일을 서버 또는 캐쉬로부터 가져온 후(S300), 해당 파일을 브라우저로 전송한다(S310).

진술한 방법 이외에도 단말기 측의 캐쉬를 효율적으로 사용하기 위해 게이트웨이에 미리 단말기에 저장된 파일에 대한 정보를 주고 게이트웨이는 필요한 태이만을 전송하는 다른 구체적인 방법이 있을 수 있다.

공유 리소스 관리 기능

일반 웹의 경우와 마찬가지로, XCB에서도 여러 페이지간에 공통되는 라이브러리나 이미지등은 공유를 하여 캐쉬 사용율을 높이는 것이 페이지 로딩 속도나 패킷 요금, 캐쉬 사용량등 여러 이유로 바람직하다. 그런데 서로 다른 페이지간에 라이브러리나 이미지 등의 리소스(이후 공유 리소스로 칭함)를 공유하다 보면 버전이 맞지 않는 상황이 발생할 수 있다.

도 8은 종래기술의 브라우저의 공유 리소스를 관리하는 방법을 도시한 도면이다. a.xhtml과 b.xhtml은 각각 다른 페이지를 나타내는 XHTML 파일이고 자바스크립트 라이브러리 c.js를 함께 공유하고 있다.

도 8a는 서버에 각 xhtml 파일의 버전 1.0이 있고, 이 파일들이 x.js 버전 1.0을 공유하며, 모든 파일이 단말기에 캐싱되어 있는 상황을 도시하고 있다.

서버의 파일들이 모두 버전 1.1로 업그레이드되었을 때, 도 8b는 단말기가 서버와 온라인으로 접속한 상태에서 a.xhtml 페이지를 액세스하여 단말기 캐쉬의 a.xhtml과 c.js 파일이 각각 ver 1.1로 업그레이드 된 상황을 도시한다.

이 상태에서 단말기가 오프라인 상태로 되면, 사용자가 b.xhtml페이지를 사용하려 할 때 b.xhtml은 버전 1.0인데 c.js는 버전 1.1이어서 도 8c에 도시된 바와 같이 버전 불일치 현상이 발생한다.

이와 같이 어떤 리소스를 서로 다른 페이지에서 함께 공유할 때 발생할 수 있는 버전 불일치 문제는 단지 웹페이지 뿐만 아니라 일반 데스크탑 운영체제에 여러 어플리케이션을 설치할 때에도 나타나는 현상이다. 이런 문제를 해결하기 위한 가장 간단한 방법은 웹페이지 간에 리소스를 공유하지 않고 웹페이지별로 서로 다른 위치에 각자 개별적인 사본파일을 두는 것이지만 이 방법은 단말기의 메모리가 제한되어 있고 특히 작은 크기의 페이지가 많은 경우에는 적용하기 곤란하다.

본 발명의 일실시예에 따르면 전술한 바와 같은 버전 불일치 문제를 해결하기 위해 도 9에 도시된 것과 같은 방법을 사용한다.

도 9a는 도 8a나 마찬가지로 서버에 버전 1.0의 a.xcml, b.xcml, c.java 파일이 있고 클라이언트의 캐쉬에도 같은 버전이 캐싱되어 있는 상황을 도시한다. 이때 본 발명의 일실시예에서, 공유될 수 있는 모든 리소스 파일은 해당 파일의 참조횟수(reference count) 값을 가지도록 한다. 참조횟수는 해당 리소스 파일이 얼마나 많은 다른 파일에서 참조되는지를 나타내는 숫자로서 도 9a에서 c.java의 참조횟수는 2이다.

도 9b에서는 단말기가 온라인 상태에서 a.xcml 페이지를 액세스하여, a.xcml 과 c.java의 버전 1.1 파일을 가져온다. 이 때 전술한 바와 같이 실제로 단말기에 전달, 저장되는 파일은 XCML과 자바의 소스 파일이 라니라 아니고 이들 파일이 게이트웨이에서 처리되어 생성된 클래스 파일들이나, 편의상 도 9에서는 소스파일의 이름으로 표현하기로 한다. 이때 버전 1.1의 c.java 파일을 단말기의 저장하기 전에 기존 캐쉬에 저장되어 있던 버전 1.0 c.java의 참조횟수를 1만큼 감소한다. 이때 도 9b에 도시된 것처럼 감소후 기존버전의 참조횟수가 0이 아니면 버전 1.0의 c.java를 삭제하지 않고, 버전 1.1의 c.java를 별도로 저장한다. 버전 1.1 a.xcml은 버전 1.0 a.xcml을 대치하고 버전 1.1 c.java를 액세스할 수 있는 링크를 가진다.

도 9c에 도시된 바와 같이 클라이언트가 오프라인 상태에서 b.xcml을 액세스하면 원래 링크되어 있던 버전 1.0의 c.java가 함께 이용된다. a.xcml을 액세스하면 버전 1.1의 c.java가 함께 액세스된다.

만일 참조횟수가 1이었던 공유 리소스 파일이 갱신되면 갱신된 파일만 남고 원래의 리소스 파일은 삭제한다. 이와 같은 방법에 따르면, 복수의 페이지에서 동일한 리소스의 동일 버전을 공유하는 경우 하나의 파일만 저장하여 효율을 높이면서도 버전이 달라지면, 서로 다른 버전을 저장하여 버전 불일치를 방지할 수 있다.

이하는 위와 같은 동작을 구현하기 위한 알고리즘의 예를 도시하는 의사코드(pseudo code)이다. 이하에서 "page"는 해당 "url"이 나타내는 페이지파일을 의미하고, "resources"는 "page"가 필요로 하는 리소스 파일들의 리스트이다.

function download_page(url):

page, resources = request_page(url)

for r in resources:

cache_resource(r)

cache_page(page)

function cache_page(page):

if page.url in cache:

; unlink previous page

for r in cache[page.url].resources:

r.ref_count--;

if r.ref_count==0:

delete cache[r.url+r.version]

; put new page

cache[page.url] = page

for r in page.resources:

cache[r.url+r.version].ref_count++

function cache_resource(r):

cache[r.url+r.versoin] = r

본 명세서에서 도면에 도시된 각 블록은 프로그램의 기능을 표시하기 위한 것으로서, 실제 프로그램으로 구현하는 과정에서 하나의 블록이 하나 또는 그 이상의 프로그램 부분(요소)로 구현될 수도 있고 또는 여러 개의 블록의 기능이 하나의 프로그램 요소에 의해 구현될 수도 있으며, 여러 개의 프로그램 요소에 의해 복합적으로 구현될 수 있다. 구체적인 기능 블록을 구현하는 방법은 당업자에 의해 다양한 변형과 조합이 가능하다.

단말기(300)에서 즉시 실행이 가능한 형태로 변환된 웹 컨텐트가 게이트웨이(200)로부터 단말기(300)로 전송되므로, 처리 능력에 한계가 있는 단말기에서도 컨텐트의 신속한 실행 및 디스플레이가 가능하다.

선언적 문법에 의해 생성되는 코드와 절차적 코드가 동일한 API(Application Program Interface)와 객체(object)를 이용하므로 둘 사이의 연동이 보다 직접적이고 효율적이다.

단말기의 브라우저에 의해 제한받지 않고, 자바가상머신(JVM) 및 단말기 라이브러리가 갖는 모든 API 및 기능을 이용할 수 있고 단말기에서는 웹 페이지 파일을 파싱하는 과정 없이 바로 코드를 실행하기만 하면 된다.

컨텐트를 표현하는 마크업 언어에 새로운 문법이 추가되어야 할 때에도 단말기의 브라우저에 해당 기능을 추가하는 등의 변경이 필요하지 않다.

무선 구간의 통신 회수를 최소화하여 캐쉬의 효율적 사용으로 트래픽양을 줄 이는 등의 방법으로 통신 효율을 높일 수 있다. 캐쉬 효율성을 유지하면서도 캐쉬된 파일의 일관성을 유지하고 버전 불일치 현상을 방지할 수 있다.

Claims

실행가능 웹 컨텐트를 단말기로 제공하는 시스템에 있어서,

선언적 언어로 된 선언적 언어부 및 비선언적 부분을 포함하는 실행가능 웹 컨텐트를 제공하는 서버와,

상기 실행가능 웹 컨텐트를 상기 서버로부터 전송받아서 상기 단말기의 웹 브라우저에서 실행될 수 있는 형태로 변환하여 상기 단말기에 전송하는 게이트웨이

를 포함하는 시스템.
제 1항에 있어서, 상기 단말기는 무선통신 단말기이고, 상기 웹 컨텐트는 무선 웹 컨텐트인 시스템.
제 1항에 있어서, 상기 웹 서버와 상기 게이트웨이는 유선 네트워크에 의하여 연결되고, 상기 게이트웨이는 무선 네트워크를 통하여 단말기에 연결되는 시스템.
제 3항에 있어서,

상기 단말기는 무선 웹 브라우저를 포함하고,

상기 게이트웨이는 상기 무선 웹 브라우저로부터의 소정의 웹 컨텐트의 요청을 무선 네트워크를 통해 수신하고, 유선 네트워크를 통해 상기 소정의 웹 컨텐트 를 상기 서버에 요청하며,

상기 웹 켄텐트는 하나 이상의 파일을 포함하며,

상기 서버로의 웹 컨텐트의 요청은 상기 하나 이상의 파일의 요청을 포함하며,

상기 게이트웨이는 상기 서버로의 요청에 따라 서버로부터 수신한, 웹 컨텐트를 구성하는 하나 이상의 파일을 한번의 트랜잭션으로 단말기로 전송하는 시스템.
제 4항에 있어서,

상기 웹 컨텐트를 구성하는 하나 이상의 파일은 웹 컨텐트 본문과 리소스 파일을 포함하며,

상기 웹 컨텐트의 요청은 웹 컨텐트의 본문의 요청과, 리소스 파일의 요청을 포함하는 시스템.
제 1항에 있어서, 상기 웹 컨텐트는 정적 파일, 동적으로 생성되는 파일, 절차적 코드의 소스 코드, 실행가능 이진파일, 멀티미디어 파일 중 하나 이상을 포함하는 시스템.
제 1항에 있어서, 상기 비선언적 부분은 절차적 코드를 포함하고,

상기 게이트웨이는 선언적언어부를 절차적 코드로 변환하는 수단과, 절차적 코드를 컴파일하여 실행가능 파일로 변환하는 수단을 포함하는 시스템.
제 1항에 있어서, 상기 비선언적 부분은 절차적 코드를 포함하고, 상기 게이트웨이는 선언적언어부를 컴파일하는 수단과, 절차적 코드를 컴파일하는 수단과, 상기 선언적언어부를 컴파일한 결과와, 절차적 코드를 컴파일한 결과를 머지(merge)하여 실행가능 파일을 생성하는 수단을 포함하는 시스템.
제 1항에 있어서, 상기 게이트웨이는 단말기의 웹 브라우저에서 실행될 수 있는 형태로 변환된 웹 컨텐트 내에 보안 정책에 위반하는 기능이 포함되어 있는지 검출하는 수단을 포함하는 시스템.
제 9항에 있어서, 상기 검출수단은 웹 컨텐트 내에 보안 정책에 위반하는 기능을 갖는 파일이 포함되어 있는 경우 해당 파일을 단말기로 전송하지 않는 것을 특징으로 하는 시스템.
제 9항에 있어서, 상기 검출수단은 웹 컨텐트 내에 보안 정책에 위반하는 기능을 갖는 파일이 포함되어 있는 경우 해당 파일을 단말기로 전송하기에 앞서 단말기 사용자의 허락을 받는 것을 특징으로 하는 시스템.
제 9항에 있어서, 상기 검출수단은 웹 컨텐트 내에 보안 정책에 위반하는 기 능을 갖는 파일이 포함되어 있는 경우 해당 파일에 런타임시 소정의 동작을 수행하게 하는 코드를 삽입하며,

상기 소정의 동작은 시스템의 기설정된 보안정책에 따라 결정되는 것을 특징으로 하는 시스템.
실행가능 웹 컨텐트를 단말기로 제공하는 시스템에 있어서,

실행가능 웹 컨텐트를 제공하는 서버와,

상기 실행가능 웹 컨텐트를 상기 서버로부터 전송받아서 상기 단말기의 웹 브라우저에서 실행될 수 있는 형태로 변환하여 상기 단말기에 전송하는 게이트웨이

를 포함하고 상기 웹 컨텐트는 정적 파일, 동적으로 생성되는 파일, 절차적 코드의 소스코드, 실행가능 이진파일, 멀티미디어 파일 중 하나 이상을 포함하고,

상기 게이트웨이는 선언적언어 및 절차적 코드를 컴파일하여 실행가능 파일로 변환하는 수단을 포함하는 시스템.
제 6항 또는 제 13항에 있어서, 상기 절차적 코드의 소스코드는 자바 코드를 포함하고, 상기 실행가능 이진파일은 자르(jar) 파일을 포함하는 것을 특징으로 하는 시스템.
실행가능 웹 컨텐트를 서버로부터 받아서, 단말기의 웹 브라우저에서 실행될 수 있는 형태로 변환하는 게이트웨이로서, 상기 웹 컨텐트는 정적 파일, 동적으로 생성되는 파일, 절차적 코드의 소스코드, 실행가능 이진파일, 멀티미디어 파일 중 하나 이상을 포함하고,

상기 게이트웨이는 선언적언어 및 절차적 코드를 컴파일하여 실행가능 파일로 변환하는 수단을 포함하는 게이트웨이.
제 15항에 있어서, 상기 단말기는 무선통신 단말기이고, 상기 웹 컨텐트는 무선 웹 컨텐트인 게이트웨이.
제 15항에 있어서, 상기 게이트웨이는 유선 네트워크에 의하여 상기 서버와 통신하고, 상기 게이트웨이는 무선 네트워크를 통하여 단말기와 통신하는 것을 특징으로 하는 게이트웨이.
제 17항에 있어서,

상기 단말기는 무선 웹 브라우저를 포함하고,

상기 게이트웨이는 상기 무선 웹 브라우저로부터의 소정의 웹 컨텐트의 요청을 무선 네트워크를 통해 수신하고, 유선 네트워크를 통해 상기 소정의 웹 컨텐트를 상기 서버에 요청하며,

상기 웹 컨텐트는 하나 이상의 파일을 포함하며,

상기 서버로의 웹 컨텐트의 요청은 상기 하나 이상의 파일의 요청을 포함하며,

상기 게이트웨이는 상기 서버로의 요청에 따라 서버로부터 수신한, 웹 컨텐트를 구성하는 하나 이상의 파일을 한번의 트랜잭션으로 단말기로 전송하는 것을 특징으로 하는 게이트웨이.
제 18항에 있어서,

상기 웹 컨텐트를 구성하는 하나 이상의 파일은 웹 컨텐트 본문과 리소스 파일을 포함하며,

상기 웹 컨텐트의 요청은 웹 컨텐트의 본문의 요청과, 리소스 파일의 요청을 포함하는 게이트웨이.
제 15항에 있어서, 상기 절차적 코드의 소스 코드는 자바 코드를 포함하고, 상기 실행가능 이진파일은 자르(jar)파일을 포함하는 게이트웨이.
제 15항에 있어서,

선언적 언어부를 절차적 코드로 변환시키는 변환부와,

절차적 코드를 컴파일하는 컴파일러와

웹서버로부터 받은 실행가능 이진파일을 분석하여 추가의 외부 파일을 참조하는 경우 이를 페치하는 처리부와

웹서버로부터 받은 웹 컨텐트에 보안에 문제가 되는 기능이 포함되어 있는지 결정하는 보안 관리부

를 포함하는 게이트웨이
제 15항에 있어서, 단말기의 웹 브라우저에서 실행될 수 있는 형태로 변환된 웹 컨텐트 내에 보안 정책에 위반하는 기능이 포함되어 있는지 검출하는 수단을 포함하는 게이트웨이.
제 22항에 있어서, 상기 검출수단은 웹 컨텐트 내에 보안 정책에 위반하는 기능을 갖는 파일이 포함되어 있는 경우 해당 파일을 단말기로 전송하지 않는 것을 특징으로 하는 게이트웨이.
제 22항에 있어서, 상기 검출수단은 웹 컨텐트 내에 보안 정책에 위반하는 기능을 갖는 파일이 포함되어 있는 경우 해당 파일을 단말기로 전송하기에 앞서 단말기 사용자의 허락을 받는 것을 특징으로 하는 게이트웨이.
제 22항에 있어서, 상기 검출수단은 웹 컨텐트 내에 보안 정책에 위반하는 기능을 갖는 파일이 포함되어 있는 경우 해당 파일에 런타임시 소정의 동작을 수행하게 하는 코드를 삽입하며,

상기 소정의 동작은 시스템의 기설정된 보안정책에 따라 결정되는 것을 특징으로 하는 게이트웨이.
제 17항에 있어서, 상기 단말기는 무선 웹 브라우저를 포함하고,

상기 웹 컨텐트는 하나 또는 그 이상의 파일을 포함하며,

상기 게이트웨이는 상기 무선 웹 브라우저로부터의 소정의 웹 컨텐트의 요청을 무선 네트워크를 통해 수신하고,

상기 소정의 웹 컨텐트의 요청은, 웹 컨텐트 중 브라우저에 이미 캐싱되어 있는 파일의 이름 및 최종 변경시간 정보를 포함하고,

상기 게이트웨이는 유선 네트워크를 통해 상기 소정의 웹 컨텐트를 상기 서버에 요청하며,

상기 서버로의 웹 컨텐트의 요청은 상기 하나 또는 그 이상의 파일의 요청을 포함하며,

상기 게이트웨이는 상기 서버로의 요청에 따라 서버로부터 수신한, 웹 컨텐트를 구성하는 하나 또는 그 이상의 파일을 수신하고, 상기 캐싱되어 있는 파일의 이름 및 죄송 변경시간정보와 비교하여 캐싱된 파일로부터 변경되었거나 새로 추가된 파일만을 단말기로 전송하는 것을 특징으로 하는 게이트웨이.
실행가능 웹 컨텐트를 브라우징하기 위한 웹 브라우저를 저장하는 컴퓨터 저장 매체로서, 상기 웹 브라우저는 바이너리 실행 코드 형태의 웹 컨텐트를 수신하여 실행하는 것을 특징으로 하는 저장 매체.
실행가능 웹 컨텐트를 브라우징하기 위한 웹 브라우저를 포함하는 단말기로 서, 상기 웹 브라우저는 바이너리 실행 코드 형태의 웹 컨텐트를 수신하여 실행하는 것을 특징으로 하는 단말기.
제 28항에 있어서,

상기 웹 컨텐트는 하나 이상의 파일을 포함하고, 상기 하나 이상의 파일은 다른 파일에서 참조되는 공유 리소스 파일을 포함하며,

상기 단말기는 캐쉬를 포함하고,

상기 공유 리소스 파일이 상기 캐쉬에 캐싱될 때, 상기 공유 리소스 파일이 얼마나 많은 다른 파일에서 참조되는지를 나타내는 참조 회수가 같이 저장되는 것을 특징으로 하는 단말기.
제 29항에 있어서,

상기 단말기가 상기 캐싱된 공유 리소스 파일의 캐싱된 버전보다 새로운 버전의 파일을 포함하는 웹 컨텐트를 전송받은 경우, 상기 새로운 버전의 공유 리소스 파일을 캐쉬에 저장하고, 상기 기 저장된 공유 리소스 파일의 참조회수를 1 감소하는 것을 특징으로 하는 단말기.
제 30항에 있어서, 상기 감소 후 참조회수가 0이면, 상기 기 저장된 공유 리소스 파일을 삭제하는 것을 특징으로 하는 단말기.