KR101581981B1

KR101581981B1 - 클라이언트-서버 환경에서의 애플리케이션의 동적 분할 방법 및 시스템

Info

Publication number: KR101581981B1
Application number: KR1020107028220A
Authority: KR
Inventors: 마이클 베이시걸; 주다 다이애멘트; 아브라함 레프; 토마스 마이칼센; 제임스 레이필드
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2008-06-16
Filing date: 2009-06-10
Publication date: 2015-12-31
Also published as: US8516037B2; EP2307977A1; EP2307977B1; WO2009155178A1; KR20110030461A; EP2307977A4; US20090313319A1

Abstract

클라이언트-서버 환경에서 애플리케이션을 동적으로 전개하는 방법은, 적어도 하나의 애플리케이션 또는 클라이언트-서버 환경의 적어도 하나의 제한 사항을 평가하는 단계와, 적어도 하나의 제한 사항에 따라, 런타임시에, 클라이언트-서버 환경에서 애플리케이션의 컴포넌트의 배치 및 실행을 동적으로 분할하는 단계를 포함한다.

Description

클라이언트-서버 환경에서의 애플리케이션의 동적 분할 방법 및 시스템{SYSTEM AND METHOD FOR DYNAMIC PARTITIONING OF APPLICATIONS IN CLIENT-SERVER ENVIRONMENTS}

본 발명은, 런타임시에 애플리케이션의 일부가 서버 상에서 자동적으로 실행되고, 애플리케이션의 일부가 클라이언트 상에서 자동적으로 실행될 수 있도록 하는, 클라이언트-서버 환경에서의 애플리케이션의 동적 분할 방법 및 시스템에 관한 것이다.

통상, Web 1.0 애플리케이션에 있어서, 클라이언트측(예를 들어, 브라우저)은 랜더링(rendering) 및 표시(presentation)로 제한되어 있다. 클라이언트 상에서 실행하는 로직은 특정한 뷰(view)를 지원하는데 사용된다. 모든 제어기 로직은 서버측에서 실행되고, 모든 모델 조작도 서버측에서 행해진다. 이와 같은 이른바 "씬 클라이언트(thin-client)" 방식은, 정적인 클라이언트/서버 분할을 제공한다. 비록 클라이언트 지정 프로그래밍 모델(예를 들어, HTML/JavaScript) 및 서버측 지정 프로그래밍 모델(예를 들어, Java Servlet)이 존재하지만, 클라이언트와 서버간의 분할은 명확하게 규정되어 있다.

씬 클라이언트 방식의 단점은 엔드 유저의 경험이다. 이는 종래의 리치 클라이언트(rich-client) 방식과 같이 매력적이지 않다. 또한, 클라이언트측은 서버측으로부터 모든 페이지를 계속적으로 포스팅하고 재로드하여, 즉 클라이언트는 자율성이 없다. 모든 실질적인 작업이 서버 상에서 발생하기 때문에, 상기 방식은 클라이언트 플랫폼의 컴퓨터 전력에 영향을 주지 않는다.

이른바 Web 2.0 애플리케이션은, 클라이언트의 역할을 확대함으로써 이들 문제를 해소하고자 한다. 그러나, Web 2.0 방식에 관한 여러 문제점들이 있다. 애플리케이션 개발은 클라이언트와 서버간의 소정의 분할을 "조정하는 것(tuning)"을 포함한다. 따라서, 더 이상 클라이언트측이 무엇이고 서버측이 무엇인지가 명확하게 규정되지 않는다. 소정의 애플리케이션 분할(클라이언트 대 서버)은 하나의 디바이스(예를 들어, PC 상에서 실행중인 브라우저)에 대해서는 적절할 수 있지만, 다른 디바이스(예를 들어, 핸드폰 상에서 실행중인 브라우저)에 대해서는 적절하지 않을 수 있다. 특히, 기업형 데이터와 관련하여, 소정의 클라이언트는 서버와 같이 동일한 서비스 품질(애플리케이션 코드의 실행에 대해서)을 제공할 수 없다. 또한, 클라이언트 상에서 실행중인 애플리케이션 코드가 변경되지 않았음을 신뢰하는 것에 관한 문제점이 있고, 또한, 애플리케이션 로직에 있어서 신뢰성 보장, 특히 트랜잭션 시맨틱(transaction semantics)을 제공하는데 문제점이 있다.

Web 2.0 애플리케이션과 같은 다음 세대의 소프트웨어 애플리케이션은, 주로 클라이언트측 애플리케이션이다. 그런데, 클라이언트 단독으로 만족될 수 없는 요구 조건이 종종 있다. 이러한 요구 조건은, 즉 통상적으로 비기능적인 요구 조건은, 데이터 공유, 보안, 신뢰성, 프라이버시 및 메모리 제한을 포함할 수 있다. 이들 요구 조건을 만족시키기 위해서, 일부 애플리케이션 로직은 서버 상에서 실행되어야 한다.

이러한 요구 조건을 만족시키기 위해서, 애플리케이션은 명시적인 서버측 프로그래밍 모델을 이용하여 구현되고, 또한 전개(deployment)시에 특수한 처리를 요구한다. 이러한 종래의 방식은 기능적인 문제와 비기능적인 문제의 긴밀한 결합을 초래한다. 개발자들은 상이한 모델(클라이언트측 대 서버측)로써 자신의 애플리케이션을 구현해야만 되어, 요구 조건의 통합 및 변경에 따라 상기 구현을 진행시키는데 어려움이 있다. 따라서, 이러한 방식은 애플리케이션 개발자의 기술과 예산의 양쪽에 부담이 된다.

따라서, 서버와 클라이언트를 위한 별도의 프로그래밍 모델이 요구되지 않도록, 클라이언트 서버 환경에서의 애플리케이션의 개발을 단순화할 필요성이 남아 있다. 또한, 애플리케이션 컴포넌트가 런타임시에 어디서 실행될 수 있는지에 대해 유연하게 구현되는 애플리케이션을 필요로 하고 있다.

애플리케이션의 개개의 사용자의 특정한 클라이언트측 능력에 근거하여, 애플리케이션의 자동적이고 저스트 인 타임(just in time)의 분할을 허용하는, 클라이언트/서버 불가지론적(agnostic)인 프로그래밍 모델을 필요로 한다.

발명의 개시

본 발명에 의하면, 클라이언트-서버 환경에서 애플리케이션을 동적으로 전개하는 방법을 제공한다. 적어도 하나의 애플리케이션 또는 클라이언트-서버 환경의 적어도 하나의 제한 사항이 평가된다. 애플리케이션의 컴포넌트의 배치 및 실행은, 적어도 하나의 제한 사항에 따라, 런타임시에 클라이언트-서버 환경에서 동적으로 분할된다.

본 발명의 다른 측면에 의하면, 클라이언트-서버 환경에서의 애플리케이션의 동적인 전개 방법을 제공한다. (a) 시스템, 디바이스, 또는 네트워크 성능 및/또는 (b) 적어도 하나의 애플리케이션 컴포넌트에 대한 비기능적이거나 또는 서비스 품질의 요구 조건을 포함하여, 적어도 하나의 제한 사항이 평가된다. 런타임시에, 애플리케이션은, 적어도 하나의 제한 사항에 따라, 적어도 하나의 클라이언트측 서브셋과 적어도 하나의 서버측 서브셋으로 자동으로 분할된다.

본 발명의 다른 측면에 의하면, 클라이언트-서버 환경에서 애플리케이션을 동적으로 전개하는 시스템을 제공한다. 이 시스템은, 적어도 하나의 클라이언트와, 적어도 하나의 서버와, 애플리케이션의 런타임시에 적어도 하나의 제한 조건에 따라, 클라이언트측 서브셋, 서버측 서브셋, 또는 그것들의 조합으로 애플리케이션을 자동으로 분할하는 에이전트를 구비한다.

여기서 사용되는 바와 같이, "실질적", "비교적", "일반적", "약", 및 "대략"은, 변형되는 특성으로부터 허용가능한 변화를 나타내기 위한 관계 수식어이다. 그것들은, 변경하는 절대값 또는 특성에 제한되는 것이 아니라, 물리적 또는 기능적인 특성에 근접시키거나 근사화시키는 것이다.

상세한 설명에서, "일실시예", "실시예" 또는 "실시예에서"라고 불리는 것은, 언급되고 있는 특징이 본 발명의 적어도 하나의 실시예에 포함되는 것을 의미한다. 또한, "일실시예", "실시예" 또는 "실시예에서"라고 구분해서 불리는 것은, 반드시 동일한 실시예를 지칭하는 것은 아니지만, 그렇게 기재되어 있지 않는 이상, 당업자에게 있어서 명백한 것을 제외하면, 이것들 중 어느 것도 상호 배타적인 실시예가 아니다. 따라서, 본 발명은 여기서 설명되는 실시예의 임의의 복수의 조합 및/또는 통합을 포함할 수 있다.

도면에 대한 이하의 설명에 의해, 당업자에게 있어서 시스템 및 방법이 자명해져야 한다.

도 1은 본 발명의 실시예에 따라 클라이언트-서버 환경에서 애플리케이션을 자동으로 분할하는 흐름도를 나타낸다.
도 2a는 본 발명의 실시예에 따른 트랜잭션 웹 애플리케이션의 예시를 나타낸다.
도 2b는 도 2a의 트랜잭션 웹 애플리케이션의 예시적인 구현예를 나타낸다.
도 3a는 도 2a의 트랜잭션 웹 애플리케이션의 런타임 분할의 예시를 나타낸다.
도 3b는 도 3a의 런타임 분할의 예시적인 구현예를 나타낸다.
도 4는 본 발명에 따른 시스템의 블록도이다.
도 5는 본 발명의 실시예에 따른 시스템의 상세한 블록도이다.

도 1~5는 클라이언트-서버 환경에서의 애플리케이션의 개발 및 자동적이고 동적인 전개를 위한 시스템 및 방법을 나타낸다. 이하의 설명은 주로 서버-브라우저 환경에서의 웹 애플리케이션에 주로 초점이 맞춰져 있지만, 본 발명은 다른 클라이언트-서버 환경에서, 예컨대 명시적인 클라이언트측(예를 들어, JDBC) 및 서버측(예를 들어, 저장된 프로시저) 프로그래밍과, 전개 모델을 이용하는 데이터베이스 기술 환경에서 채택될 수 있다.

본 발명에 의하면, 개발자는, 예컨대 클라이언트(예를 들어, 브라우저) 상에서 전체적으로 실행하는 것과 같이 전체 웹 애플리케이션을 개발함으로써, 단일의 프로그래밍 모델을 이용하여 애플리케이션을 형성하기 때문에, 별도의 서버측 프로그래밍 및 전개 모델에 대한 필요성이 없어진다. 애플리케이션 로직은 서버 또는 클라이언트 상에서의 결과적인 배치와는 무관하다. 런타임시에, 웹 애플리케이션의 일부는 적어도 하나의 서버, 적어도 하나의 클라이언트, 또는 양쪽 상에서 자동적으로 실행될 것이다.

I. 애플리케이션 컴포넌트

본 발명에 의하면, 웹 애플리케이션은 적어도 하나의 애플리케이션 컴포넌트를 포함해서 개발된다. 적어도 하나의 애플리케이션 컴포넌트는, 스코프(scope)라고 불리는 적어도 하나의 연산 컴포넌트와, 리소스라고 불리는 적어도 하나의 데이터 컴포넌트와, 또는 연산 컴포넌트와 데이터 컴포넌트의 임의의 조합을 포함할 수 있다.

적어도 하나의 연산 컴포넌트(스코프)는, 웹 애플리케이션의 적어도 하나의 연산 측면을 나타내는 애플리케이션 로직 및 관련 코드를 포함한다. 실시예에서, 연산 측면은 하위 애플리케이션의 기능으로서, 애플리케이션의 상태를 조작한다. 다른 실시예에서, 연산 측면은 애플리케이션의 상태를 변경할 수 없고, 예를 들어 그래픽 랜더링 알고리즘과 같은 알고리즘을 포함할 수 있다. 연산 측면은, 폼 검증, 데이터베이스 액세스, 질의 관리, 통화 서비스, 트랜잭션 수행, 그래픽 변형, 이미지 처리, 계산, 맞춤법 검사기, 구문 강조, 사용자 인터페이스 컴포넌트와의 상호 작용 등을 포함할 수 있지만, 이에 제한되는 것은 아니다. 스코프는 다른 스코프를 참조할 수 있다.

적어도 하나의 데이터 컴포넌트(리소스)는 웹 애플리케이션의 상태를 표현하는 애플리케이션 데이터를 포함한다. 실시예에서, 리소스는 데이터 또는 객체의 검색가능한 집합(collection)을 포함할 수 있다. 이러한 데이터 또는 객체는, 입력된 명령과, 데이터베이스(예를 들어, 직원 데이터베이스, 데이터간의 관계를 규정하는 데이터베이스)와, 이미지 파일, 음악 파일, 또는 문서의 집합과, 지속적으로 저장되어야 하는 파일 등을 포함할 수 있지만, 이에 제한되는 것은 아니다. 본 발명에 의하면, 리소스는 다른 스코프에 의해 공유될 수 있다.

웹 애플리케이션은 적어도 하나의 제한 사항을 포함한다. 적어도 하나의 제한 사항은, 소정의 제한 사항을 구현하는데 사용되는 특수 코드가, 런타임시에 애플리케이션이 사용중인 컨텍스트(context)에 의존하는, 애플리케이션의 추가 기능적인(extra-functional) 시맨틱을 통신하는데 사용된다. 컨텍스트는, 예컨대, 클라이언트 디바이스의 적어도 하나의 성능, 사용자의 신원, 개발 모드 대 생산 모드 등을 포함할 수 있다. 시스템은 런타임 컨텍스트를 평가하고, 적어도 하나의 제한 사항의 적절한 구현이 제공될 수 있는 클라이언트 또는 서버(또는 양쪽) 상에 스코프 및/또는 리소스를 배치한다.

실시예에서, 적어도 하나의 제한 사항은, 스코프 또는 리소스가 실행될 수 있는 환경에 의존하는 강한 제한 사항(hard constraint), 예컨대 시스템, 디바이스, 또는 네트워크 성능과, 클라이언트 버전과, 또는 메모리 제한일 수 있다. 강한 제한 사항은 웹 애플리케이션에 연관되어 있지 않다.

실시예에서, 제한 사항은, 스코프 또는 리소스에 대한 개발자의 특정한 비기능적 및/또는 QoS 요구 조건에 근거하여, 스코프 또는 리소스를 어디서 실행할지를 런타임시에 시스템이 자동으로 결정하는 추상적인 제한 사항일 수 있다. 비기능적 및/또는 QoS 요구 조건은, 데이터 공유, 보안, 신뢰성, 프라이버시, 신뢰 코드(trusted code), 비밀성, 또는 사용자 신원을 포함하는 적어도 하나의 요구 조건을 포함할 수 있지만, 이에 제한되는 것은 아니다.

본 발명에 따른 애플리케이션은, 강한 제한 사항, 추상적인 제한 사항, 또는 그것들의 임의의 조합 중 적어도 하나를 가질 수 있다.

적어도 하나의 제한 사항은 애플리케이션 로직의 외부에 표현될 수 있고, 스코프 또는 리소스 내에 직접 인코딩되지 않는다. 따라서, 적어도 하나의 제한 사항은, 애플리케이션으로부터 뽑아낸 구현 코드(implementation code)를 나타낸다. 그러나, 실시예에서, 적어도 하나의 제한 사항은 코드와 통합되거나, 코드에 의해 암시될 수 있다. 예컨대, 트랜잭션 경계 API(transaction demarcation API)의 사용(또는 의존도)은 어토믹(atomic) 실행 트랜잭션의 제한 사항을 암시할 수 있거나, 또는 자바 프로그래밍 언어에서는, 자바 클래스가 트랜잭션 제한 사항을 암시할 수 있는 인터페이스를 불러와서 사용할 수 있다.

Ⅱ. 애플리케이션의 분할

본 발명에 의하면, 적어도 하나의 제한 사항을 평가하여, 런타임시에 웹 애플리케이션의 분할과, 적어도 하나의 애플리케이션 컴포넌트(스코프 및/또는 리소스)의 실행 및 배치를 행한다. 적어도 하나의 제한 사항이 웹 애플리케이션을 사용할 때마다 적용될 수 있기 때문에, 적어도 하나의 스코프, 적어도 하나의 리소스, 또는 그것들의 조합의 실행 및 배치는, 상이한 클라이언트-서버 환경에서 변화될 수 있다.

실시예에서, 적어도 하나의 클라이언트측 서브셋, 적어도 하나의 서버측 서브셋, 또는 클라이언트측 서브셋과 서버측 서브셋의 양쪽으로 애플리케이션을 분할할 수 있다. 서브셋은 해체될 수도 해체되지 않을 수도 있다. 웹 애플리케이션의 런타임시에, 적어도 하나의 서버, 적어도 하나의 클라이언트, 또는 양쪽 상에서의 적어도 하나의 컴포넌트(스코프 및/또는 리소스)의 실제 배치는 적어도 하나의 제한 사항에 의해 결정된다. 본 발명에 의하면, 웹 애플리케이션의 복수의 세션은 스코프 또는 리소스를 공유할 수 있다. 이와 달리, 각 세션은 자신들의 스코프 또는 리소스의 복사본을 가질 수 있다. 스코프 또는 리소스는 단일의 웹 애플리케이션 세션으로 제한될 수 있다. 실시예에서, 스코프 또는 리소스는 엄격하게 클라이언트측으로 또는 엄격하게 서버측으로 규정될 수도 있다.

도 1은 본 발명의 실시예에 따라 웹 애플리케이션의 분할 방법을 나타낸다. 사용자가 서버로부터 애플리케이션의 실행을 요구한다(100). 애플리케이션의 컴포넌트(스코프 및 리소스)에 대한 임의의 제한 사항(추상적인 제한 사항)이 결정된다(110). 디바이스, 네트워크, 애플리케이션을 요구하는 사용자 중 적어도 하나의 성능(강한 제한 사항)이 결정된다(115). 애플리케이션은 제한 사항을 만족시키는 서버측 애플리케이션 서브셋 또는 클라이언트측 애플리케이션 서브셋 중 적어도 하나로 자동으로 분할된다(120). 클라이언트측 애플리케이션 서브셋은 디바이스 상의 클라이언트에 의해 런타임시에 실행된다(125). 클라이언트측 런타임은 애플리케이션 컴포넌트간의 상호 작용을 중재한다(예컨대, 미들웨어가 스코프와 리소스간의 상호 작용을 중재한다)(130). 서버가 서버측 애플리케이션 서브셋을 실행한다(135).

Ⅲ. 예시

이하에, 본 발명에 따라 런타임시에 애플리케이션을 서버측 부분 및 클라이언트측 부분으로 자동으로 분할하여 전개하는 예시에 대해서 설명한다.

A. 신뢰성

본 발명에 의하면, 웹 애플리케이션은 신뢰성 제한 사항에 근거하여 분할될 수 있다. 적어도 하나의 애플리케이션 컴포넌트의 배치 및 실행은, 런타임시에 결정되고, 디바이스, 시스템 또는 네트워크의 신뢰성 속성 및/또는 개발자의 비기능적 요구 조건(추상적인 제한 사항)에 따라 변화될 수 있다. 예컨대, 스코프는, 동작 실행에 따라 발생할 수 있는 어떠한 고장에도 불구하고, 스코프 내의 동작이 어토믹 단위로서 실행한다는 요구 조건을 가질 수 있다. 동작들은 완전히 성공하거나 완전히 실패한다. 따라서, 이러한 제한 사항을 갖는 스코프는 어토믹 실행이 보장될 수 있는 서버 상에서 실행될 수 있다.

신뢰성이 중요한 애플리케이션은, 예컨대 트랜잭션 수행 또는 신뢰가능한 메시징을 포함할 수 있다. 실시예에서, 하나의 애플리케이션이 다른 애플리케이션에게 메시지를 보내거나 호출하면, 신뢰성 제한 사항은, 시스템이 고장난 경우에 전달을 보장하는 것일 수 있다. 결과적으로, 웹 브라우저에 의한 전달 요구의 중복 처리 또는 전달 실패를 없애기 위해 메시지 큐잉이 서버 상에서 발생할 수 있다.

도 2a~3b는 본 발명의 실시예 따라 신뢰성 제한 사항을 갖는 트랜잭션 애플리케이션의 개발 및 런타임 전개를 나타낸다. 도 2a에 나타낸 바와 같이, 트랜잭션 애플리케이션은 어카운트 X 리소스(200) 및 어카운트 Y 리소스(205)와, 어카운트 관리 스코프(210)와의 사이에서의 데빗(debits) 및 크레딧(credits)에 관한 것이다. 트랜잭션은 사용자가 어카운트 사용자 인터페이스 스코프(215)로부터 데빗 및 크레딧의 이동을 요구할 때에 발생한다. 저스트 인 타임 서버측 컴포넌트 또는 JTISS 코드(예를 들어, XML)에서의 도 2a의 트랜잭션 애플리케이션의 구현예를 도 2b에 나타낸다.

런타임시에, 도 3a에 나타낸 바와 같이, 어카운트 관리 스코프(210)와 어카운트 X 및 Y 리소스는, 서버 상에 자동적으로 배치되어 실행되는 반면에, 어카운트 사용자 인터페이스 스코프(215)는 클라이언트 웹 브라우저 상에 배치되어 실행된다. 제한 사항이 데빗 및 크레딧 정보의 신뢰가능한 이동을 요구하기 때문에, 어카운트 X 및 Y 리소스와 어카운트 관리 스코프는 서버 상에서 실행된다. 어카운트 UI 스코프는 클라이언트 웹 브라우저 상에서 실행된다. 애플리케이션의 런타임 분할의 구현예를 도 3b에 도시한다.

B. 풋프린트( footprint )

본 발명에 따라 개발된 웹 애플리케이션은 클라이언트측 풋프린트를 재분배하거나 감소시키는데 이용될 수 있다. 다수의 애플리케이션(예를 들어, 기업형 애플리케이션)은 추가적인 코드와 메모리를 갖는 라이브러리를 요구하는 프로토콜 및 미들웨어를 포함한다. 이러한 라이브러리를 실행하는 애플리케이션의 예로는, SOAP(Simple Object Access Protocol) 또는 JMS(Java Messgae Service)를 포함하지만, 이에 제한되는 것은 아니다.

이들 라이브러리의 사이즈 및 메모리 요구 조건은, 애플리케이션 컴포넌트가 본 발명에 따라 어디서 실행될 수 있는지에 대해 영향을 주는 강한(hard) 제한 사항이다. 예컨대, 대량의 메모리를 갖는 퍼스널 컴퓨터 시스템 상에서 실행중인 클라이언트에 있어서, 라이브러리를 요구하는 프로토콜 및 미들웨어는 클라이언트 상에서 실행될 수 있다. 그러나, 모바일 디바이스(예를 들어, 핸드폰) 상에서 실행중인 클라이언트에 있어서, 상기 라이브러리를 이용하는 동일한 애플리케이션 컴포넌트는 서버 상에서 실행될 수 있다.

C. 교차 도메인( cross - domain ) 요구

본 발명에 따라 개발된 웹 애플리케이션은, 교차 도메인 요구를 지원할 수 있다. 예컨대, 클라이언트 웹 브라우저는 보안성 제한을 가질 수 있기 때문에, 코드를 제공한 서버(오리진(origin) 서버)와 단지 통신만을 행할 수 있다. 그러나, 복합 애플리케이션(예를 들면, 애플리케이션의 그룹)은 항상 동일한 서버, 동일한 디바이스, 또는 동일한 네트워크 상에서 실행하는 것이 아닌 애플리케이션을 포함한다. 그 결과, 클라이언트측 보안 정책은 애플리케이션간의 상호 동작을 막을 수 있다.

본 발명에 의하면, 클라이언트와의 상호 동작을 시도하는 애플리케이션 컴포넌트(예를 들어, 스코프 또는 리소스)는 서버 상에서 실행될 수 있다. 이러한 특징은, 다수의 웹 애플리케이션, 예를 들어 매시업(mash-up) 애플리케이션이 보안벽을 극복해야 하기 때문에 중요하다.

D. 프라이버시

본 발명에 의하면, 웹 애플리케이션은 적어도 하나의 프라이버시 요구 조건을 포함하는 제한 사항을 포함할 수 있다. 적어도 하나의 프라이버시 요구 조건은, 패스워드, 사용자명, 금융 정보, 또는 재산 정보를 포함하지만, 이에 제한되는 것은 아니다.

런타임시에, 소정의 민감한 애플리케이션 로직/데이터가 서버 상에서 머무르도록 애플리케이션을 분할하는 것이 바람직하다. 따라서, 본 발명에 의해 웹 애플리케이션은 안전한 환경에서 실행될 수 있다. 실시예에서, 애플리케이션은 이러한 분할로 인해 비밀성 보장을 제공할 수 있다.

E. 신뢰 코드

본 발명의 실시예에 의하면, 웹 애플리케이션은 신뢰 코드가 신뢰 환경에서 실행되는 것을 요구할 수 있다. 예컨대, 데이터베이스에 액세스하는 애플리케이션 컴포넌트는 데이터베이스에 직접 액세스하도록 허용된 신뢰 코드를 포함할 수 있다. 이와 같이, 신뢰 코드를 포함하는 상기 컴포넌트가 변경되지 않음을 보장할 것을 시스템에게 요구하는 제한 사항이 존재한다. 런타임 컨텍스트에 따라, 이러한 보안성/신뢰 코드 제한 사항은, 애플리케이션 컴포넌트가 신뢰 환경(예를 들어 서버)에서 실행되는 것을 요구할 수 있다.

종래, 개발자들은 신뢰 코드를 위해 다른 코드 및 프로그래밍 모델을 이용해야 한다. 그러나, 본 발명에 의해 개발자는 클라이언트 상에서 전체적으로 실행되는 단일 프로그래밍을 이용하여 웹 애플리케이션을 제공할 수 있다.

F. 일관성

본 발명에 의하면, 적어도 하나의 제한 사항은 리소스에 관한 데이터 일관성의 다양한 레벨을 특정하는데 사용될 수 있다. 예컨대, 일관성 높은 제한 사항은, 다수의 클라이언트에 의해 액세스되는 리소스가 서버 상에서 배치되도록 할 수 있다. 일관성이 낮은 제한 사항은, 리소스가 클라이언트 상에서 실행되도록 할 수 있고, 그에 따라 성능이 보다 좋아진다.

G. 이질적인( heterogeneous ) 구현

본 발명에 의하면, 이질적인 웹 애플리케이션의 전개는 단순화된다. 이질적인 웹 애플리케이션은 상이한 프로그래밍 언어, 예를 들어 적어도 2개의 상이한 프로그래밍 언어의 조합을 포함할 수 있다. 예컨대, 자바 코드는 서버 상에서 실행할 수 있는 반면에, 자바 스크립트는 클라이언트 상에서 실행할 수 있다.

본 발명의 실시예에서, 웹 애플리케이션은 시스템, 디바이스, 또는 네트워크의 적어도 하나의 강한 제한 사항에 따라 런타임시에 분할되기 때문에, 애플리케이션 컴포넌트는 적절한 프로그래밍 언어를 지원하는 적어도 하나의 서버 및/또는 적어도 하나의 클라이언트 상에서 실행될 것이다. 예컨대, 본 발명에 따른 애플리케이션은 자바 코드가 서버뿐만 아니라 클라이언트 상에서도 실행될 수 있도록 한다.

본 발명에 의하면, 웹 애플리케이션 컴포넌트(스코프, 리소스, 및 제한 사항)는 프로그래밍 모델을 이용하여 기술될 수 있다. 실시예에서, 컴포넌트는 XML(Extensible Markup Language) 또는 자바 스크립트 중 적어도 하나로 기술될 수 있다.

Ⅳ. 시스템

도 4는 본 발명의 예시적 시스템을 나타내는 블록도이다. 예시적 시스템은, 적어도 하나의 전자 또는 디지털 디바이스(400)(예를 들어, 퍼스널 컴퓨터, 핸드폰, 퍼스널 디지털 어시스턴트 또는 PDA, 게임 디바이스, MP3 플레이어, 텔레비전)을 포함한다. 디바이스는 네트워크(405)(예를 들어, 인터넷, LAN(local area network), WAN(wide area network))에 연결될 수 있다. 본 발명의 실시예에서, 시스템은 적어도 하나의 클라이언트(410), 에이전트(420), 및 서버-클라이언트 애플리케이션을 실행하는 적어도 하나의 서버(415)를 포함한다. 에이전트(420)는, 애플리케이션의 런타임시에 적어도 하나의 제한 사항에 따라, 클라이언트측 서브셋, 서버측 서브셋, 또는 그것들의 조합 중 적어도 하나로 애플리케이션을 자동으로 분할한다.

실시예에서, 적어도 하나의 서버는 웹 서버와, 확장된 웹 서버와, 또는 자바 서브릿 컨테이너(Java servlet container) 중 적어도 하나일 수 있다. 실시예에서, 적어도 하나의 클라이언트는 웹 브라우저와, 독립형(standalone) 자바스크립트 엔진과, 또는 내장형 자바스크립트 엔진 중 적어도 하나일 수 있다. 그러나, 도 4의 예시적 시스템은 일례이며, 당업자라면 본 발명에 의해 고려되는 다수의 다른 변형예가 존재할 수 있음을 인지할 것이다.

도 5는 본 발명의 실시예에 따른 시스템 및 동작의 보다 상세한 블록도를 나타낸다. 클라이언트 디바이스(500)를 이용해서, 사용자(591)는 애플리케이션 서버(530)를 통해서 애플리케이션(560)을 요구한다. 애플리케이션(560)은 적어도 하나의 애플리케이션 컴포넌트(570)와 적어도 하나의 제한 사항(571)을 포함한다.

사용자 요구는 요구 컨텍스트(590) 내에서 발생한다. 이 요구 컨텍스트(590)는 클라이언트 디바이스의 성능(592), 사용자(591)의 신원, 전개 모드(594)를 포함할 수 있다. 예컨대, 전개 모드는 "독립형 테스팅" 및 "생성"을 포함할 수 있다.

런타임시에, 컴포넌트 배치 관리자(550)는 컨텍스트(590)를 평가한다. 애플리케이션 컴포넌트 제한 사항(571), 클라이언트에서의 제한 사항 구현(511), 서버에서의 제한 사항 구현(541)은, 모든 제한 사항이 만족되도록, 클라이언트측 컴포넌트(561)의 서브셋과 서버측 컴포넌트(562)의 서브셋으로 애플리케이션(560)을 분할한다.

애플리케이션 서버(530)는, 제로 이상의 클라이언트측 컴포넌트 런타임(510) 및 클라이언트측 애플리케이션 컴포넌트(561)의 집합을 클라이언트 디바이스(500)로 전달한다. 클라이언트측 컴포넌트 런타임은, 클라이언트측 실행에 적합한 적절한 제한 사항 구현(511)을 포함한 클라이언트측 컴포넌트를 위한 실행 환경을 제공한다.

애플리케이션 서버(530)는 서버측 컴포넌트(562)를 실행하기 위해 제로 이상의 서버측 컴포넌트 런타임(540)을 공급한다. 서버측 컴포넌트 런타임은, 서버측 실행에 적합한 적절한 제한 사항 구현(541)을 포함한, 서버측 컴포넌트를 위한 실행 환경을 제공한다.

클라이언트측 컴포넌트(561)가 다른 클라이언트측 컴포넌트(561)와 통신해야 되는 경우, 클라이언트측 컴포넌트 런타임(510)은 그 통신을 중재한다. 서버측 컴포넌트(562)가 다른 서버측 컴포넌트(562)와 통신해야 되는 경우, 서버측 컴포넌트 런타임(540)은 그 통신을 중재한다. 클라이언트측 컴포넌트(561)가 서버측 컴포넌트(562)와 통신해야 되는 경우, 클라이언트측 런타임(510), 서버측 런타임(540) 및 애플리케이션 서버(530)는 그 통신을 중재한다.

당업자에 의해 알 수 있는 바와 같이, 본 발명은 시스템, 방법 또는 컴퓨터 프로그램 제품으로서 구체화될 수 있다. 따라서, 본 발명은, 전체적으로 하드웨어 실시예, 전체적으로 소프트웨어 실시예(펌웨어, 상주 소프트웨어, 마이크로-코드 등을 포함), 또는 본 명세서에서 "회로", "모듈" 또는 "시스템"으로서 일반적으로 불리울 수 있는 소프트웨어와 하드웨어를 결합한 실시예의 형태를 취할 수 있다. 또한, 본 발명은 매체에서 실행되는 컴퓨터 사용가능한 프로그램 코드를 갖고서 표현되는 임의의 유형 매체에 있어서 구현되는 컴퓨터 프로그램 제품의 형태를 취할 수 있다.

컴퓨터 사용가능하거나 컴퓨터 판독가능한 하나 이상의 매체의 임의의 조합을 이용할 수 있다. 컴퓨터 사용가능하거나 컴퓨터 판독가능한 매체는, 예컨대 전자, 자기, 광학, 전자기, 적외선, 또는 반도체의 시스템, 장치, 디바이스, 또는 전송 매체일 수 있지만, 이에 한정되는 것은 아니다. 컴퓨터 판독가능한 매체의 보다 구체적인 예시(비완전 목록)는, 하나 이상의 배선을 갖는 전기 접속, 휴대용 컴퓨터 디스켓, 하드 디스크, RAM, ROM, 소거 및 프로그램 가능한 ROM(EPROM 또는 플래시 메모리), 광파이버, CD-ROM, 광저장 장치, 인터넷 또는 인트라넷을 지원하는 송신 매체, 또는 자기 저장 장치를 포함한다. 예를 들어 페이퍼 또는 다른 매체의 광학적 스캐닝을 통해서 프로그램이 획득되고, 그 다음에 컴파일되고, 해석되고, 또는 필요에 따라 적절한 방식으로 처리되고 나서 컴퓨터 메모리 저장될 수 있기 때문에, 컴퓨터 사용가능하거나 컴퓨터 판독가능한 매체는, 그 프로그램이 인쇄되는 페이퍼이거나 다른 적절한 매체일 수 있음을 유의한다. 본 명세서에 있어서, 컴퓨터 사용가능하거나 컴퓨터 판독가능한 매체는, 명령 실행 시스템, 장치, 또는 디바이스와 관련되어 있거나 또는 그것들에 의한 사용을 위한 프로그램을, 포함하고, 저장하고, 통신하고, 전파하고, 또는 전송할 수 있는 소정의 매체일 수 있다. 컴퓨터 사용가능한 매체는, 베이스밴드에서 또는 반송파의 일부로서 실행되는 컴퓨터 사용가능한 프로그램 코드를 갖는 전파 데이터 신호를 포함할 수 있다. 컴퓨터 사용가능한 프로그램 코드는, 무선, 유선, 광파이버 케이블, RF 등을 포함하지만 이에 한정되지 않는 임의의 적절한 매체를 이용해서 송신될 수 있다.

본 발명의 동작을 수행하기 위한 컴퓨터 프로그램 코드는, 자바, 스몰토크, C++ 등의 객체 지향 프로그래밍 언어와, "C" 프로그래밍 언어 또는 그와 유사한 프로그래밍 언어 등의 종래의 절차적 프로그래밍 언어를 포함한 하나 이상의 프로그래밍 언어의 소정의 조합으로 기록될 수 있다. 프로그램 코드는 전체적으로는 사용자의 컴퓨터 상에서 실행되고, 독립형 소프트웨어 패키지와 같이, 부분적으로는 사용자의 컴퓨터 상에서, 또한 부분적으로는 리모트 컴퓨터 상에서, 또는 전체적으로는 리모트 컴퓨터 또는 서버 상에서 실행될 수 있다. 마지막의 시나리오에서, 리모트 컴퓨터는 LAN 또는 WAN을 포함한 소정 형태의 네트워크를 통해서 사용자의 컴퓨터에 접속될 수 있고, 또는 (예컨대, 인터넷 서비스 공급자를 이용하는 인터넷을 통해서) 외부 컴퓨터로 접속될 수도 있다.

본 발명은, 발명의 실시예에 따른 방법, 장치(시스템) 및 컴퓨터 프로그램 제품의 블록도 및/또는 흐름도 설명을 참조해서 개시되어 있다. 흐름도 설명 및/또는 블록도의 각 블록과, 흐름도 설명 및/또는 블록도에서의 블록의 조합이 컴퓨터 프로그램 명령에 의해 구현될 수 있음을 이해해야 할 것이다. 이들 컴퓨터 프로그램 명령이, 범용 컴퓨터, 특수 목적 컴퓨터의 프로세서, 또는 다른 프로그래밍가능한 데이터 처리 장치로 제공될 수 있고, 컴퓨터의 프로세서 또는 다른 프로그래밍가능한 데이터 처리 장치를 통해서 실행되는 명령은 흐름도 및/또는 블록도에서 구체화된 기능/동작을 구현하기 위한 수단을 형성한다.

또한, 이들 컴퓨터 프로그램 명령이, 컴퓨터 또는 다른 프로그래밍가능한 데이터 처리 장치가 특정한 방식으로 기능하도록 지시할 수 있는 컴퓨터 판독가능한 매체에 저장될 수 있어, 컴퓨터 판독가능한 매체에 저장된 명령은 흐름도 및/또는 블록도에서 구체화된 기능/동작을 구현하는 명령 수단을 포함한 제조품을 생성한다.

또한, 컴퓨터 또는 다른 프로그래밍가능한 장치 상에서 일련의 동작 단계들이 수행되도록 하여, 컴퓨터 구현 프로세스를 생성하기 위해, 컴퓨터 프로그램 명령이 컴퓨터 또는 다른 프로그래밍가능한 데이터 처리 장치 상에 로드될 수 있어, 컴퓨터 또는 다른 프로그래밍가능한 장치 상에서 실행되는 명령은 흐름도 및/또는 블록도에서 구체화된 기능/동작을 구현하기 위한 프로세스를 제공한다.

도면에서의 흐름도 및 블록도는, 본 발명의 다양한 실시예에 따른 시스템, 방법 및 컴퓨터 프로그램 제품의 가능한 구현예의 구조, 기능, 동작을 도시한다. 이와 관련하여, 흐름도 또는 블록에서의 각 블록은, 특정한 로직 기능을 구현하기 위한 하나 이상의 실행가능한 명령을 포함하는 모듈, 세그먼트, 또는 코드의 일부를 나타낼 수 있다. 일부 다른 구현예에서, 블록에 표시된 기능이 도면에 표시된 순서를 벗어나서 발생할 수 있음도 유의해야 한다. 예컨대, 연속해서 도시된 2개의 블록은, 사실, 실질적으로 동시에 실행될 수 있거나, 또는 그 블록들은 종종 관련된 기능에 따라 반대 순서로 실행될 수 있다. 또한, 블록도 및/또는 흐름도 설명의 각 블록과, 블록도 및/또는 흐름도 설명에서의 블록의 조합이, 구체화된 기능 또는 동작을 수행하는 특수 목적의 하드웨어 기반의 시스템, 또는 특수 목적의 하드웨어와 컴퓨터 명령의 조합에 의해 구현될 수 있음도 유의해야 한다.

Ⅵ. 산업상 이용가능성

런타임시에 애플리케이션의 일부가 서버 상에서 자동으로 실행될 수 있고, 애플리케이션의 일부가 클라이언트 상에서 자동으로 실행될 수 있도록, 클라이언트-서버 환경에서 애플리케이션을 동적으로 분할하는 시스템 및 방법을 제공한다. 따라서, 서버와 클라이언트에 대한 별도의 프로그래밍 모델을 필요로 하지 않는다.

상기한 예시적이고 대안적인 실시예는 서로 다양한 방식으로 조합될 수 있다. 또한, 단계와, 도면에 도시된 여러 단계들의 번호는 도시되어 있는 것으로부터 조정될 수 있다.

본 발명은 예시적이고 대안적인 특정한 실시예에 대해서 설명되었지만, 그러한 실시예에 제한되는 것은 아니다. 본 발명에 포함되는 대안적인 실시예, 예시, 및 변형예는, 특히 앞서의 교시 내용에 근거하여 당업자에 의해 만들어질 수 있다.

Claims

클라이언트-서버 환경에서 애플리케이션을 동적으로 전개하는 방법으로서,
웹 브라우저 상에서 전적으로 실행되기 위한 웹 애플리케이션을 생성하는 단계 - 상기 애플리케이션은 적어도 하나의 애플리케이션 컴포넌트 및 적어도 하나의 추상적 제한 사항을 포함하고, 애플리케이션 로직은 서버 또는 클라이언트 상에 배치되는 것과 독립적이고, 상기 적어도 하나의 추상적 제한 사항은 상기 애플리케이션 로직의 외부에 표현되고, 상기 적어도 하나의 추상적 제한 사항은 상기 적어도 하나의 애플리케이션 컴포넌트에 대한 신뢰성, 프라이버시, 보안, 또는 신뢰 코드 중 적어도 하나의 요건을 포함함 -;
상기 클라이언트-서버 환경에서 상기 애플리케이션의 런타임 컨텍스트를 평가하는 단계; 및
상기 적어도 하나의 추상적 제한 사항의 구현을 제공하기 위해, 런타임시에 상기 적어도 하나의 애플리케이션 컴포넌트의 배치 및 실행을 동적으로 분할하는 단계(partitioning);를 포함하고, 상기 적어도 하나의 애플리케이션 컴포넌트의 배치 및 실행은 상이한 클라이언트-서버 환경들에서 달라지는
방법.
제1항에 있어서, 상기 적어도 하나의 애플리케이션 컴포넌트는,
적어도 하나의 연산 컴포넌트, 적어도 하나의 데이터 컴포넌트, 또는 연산 컴포넌트와 데이터 컴포넌트의 조합을 포함하는
방법.
제1항에 있어서,
상기 적어도 하나의 추상적 제한 사항에 따라, 상기 애플리케이션을 클라이언트측 서브셋 및 서버측 서브셋으로 자동으로 분할하는
방법.
제2항에 있어서,
상기 적어도 하나의 연산 컴포넌트는 상기 애플리케이션의 상태를 조작하고,
상기 적어도 하나의 연산 컴포넌트는 폼(form) 검증, 데이터베이스 액세스, 질의 관리, 통화 서비스, 트랜잭션 수행, 그래픽 변형, 이미지 처리, 계산, 맞춤법 검사기, 구문 강조, 또는 사용자 인터페이스 컴포넌트와의 상호 작용을 포함하는,
방법.
삭제
삭제
제2항에 있어서,
상기 적어도 하나의 데이터 컴포넌트는,
데이터 또는 객체들의 검색가능한 집합(collection)을 포함하는
방법.
제2항에 있어서,
상기 적어도 하나의 데이터 컴포넌트는,
입력된 명령과; 데이터베이스; 이미지 파일, 음악 파일, 또는 문서의 집합(collection)과; 지속적으로 저장되어야 하는 파일;을 포함하는
방법.
삭제
제1항에 있어서,
상기 신뢰성 제한 사항은,
상기 적어도 하나의 애플리케이션 컴포넌트의 동작들이, 상기 동작들이 실행될 때 발생하는 실패(failure)에도 불구하고, 원자적 단위(atomic unit)로 동작하는 것을 포함하는
방법.
삭제
삭제
삭제
제1항에 있어서,
상기 애플리케이션은,
상기 적어도 하나의 애플리케이션 컴포넌트를 상기 서버 상에서 실행시키고, 보안 제약을 갖는 클라이언트 웹 브라우저와 상호 작용시킴으로써, 상이한 서버들, 상이한 디바이스들, 또는 상이한 네트워크들 중 적어도 하나에서 실행중인 애플리케이션 간의 교차 도메인(cross-domain) 요구를 지원하는
방법.
제1항에 있어서,
상기 적어도 하나의 추상적 제한 사항은 프라이버시 요건을 포함하고,
상기 분할하는 단계는 민감한 정보가 서버 상에 유지되도록 하는
방법.
제15항에 있어서, 상기 민감한 정보는,
금융 정보 또는 재산 정보 중 적어도 하나를 포함하는,
방법.
제1항에 있어서,
상기 애플리케이션은, 데이터베이스에 직접 액세스하는 것이 허용되는 신뢰 코드(trusted code)를 포함하고, 상기 적어도 하나의 추상적 제한 사항은 상기 신뢰 코드가 변경되지 않는 것을 보장하여, 상기 신뢰 코드가 신뢰 환경에서 실행되도록 하는
방법.
제1항에 있어서,
프로그래밍 모델은 상기 애플리케이션의 개별 사용자들의 클라이언트측 성능에 기초하여 상기 애플리케이션의 자동화된 적시 분할(automated, just-in-time partitioning)을 가능하게 하는
방법.
제1항에 있어서,
상기 적어도 하나의 제한 사항은 상기 적어도 하나의 애플리케이션 컴포넌트에 인코드되지 않는
방법.
제1항에 있어서,
상기 적어도 하나의 애플리케이션 컴포넌트는 클라이언트 및 서버 둘 다에 배치되는
방법.
제1항에 있어서,
상기 웹 애플리케이션의 다수의 세션들은 동일한 적어도 하나의 애플리케이션 컴포넌트를 공유하는
방법.
제1항에 있어서,
상기 신뢰성 제한 사항은, 시스템이 고장나면(fails), 하나의 애플리케이션의 메시지들을 다른 애플리케이션으로 전달하는 것을 보장하는
방법.
제1항에 있어서,
상기 적어도 하나의 추상적 제한 사항은 개발자에 의해 명시된 비기능적 요건을 포함하는
방법.
제1항에 있어서,
상기 적어도 하나의 추상적 제한 사항은,
프라이버시, 보안, 또는 신뢰 코드 중 적어도 하나의 요건을 포함하는
방법.
컴퓨터 판독가능 프로그램을 포함하는 컴퓨터 판독가능 매체에 있어서,
상기 컴퓨터 판독가능 프로그램은 컴퓨터 상에서 실행되는 경우 상기 컴퓨터로 하여금 상기 청구항 제1항 내지 제4항, 제7항, 제8항, 제10항, 제14항 내지 제24항 중 하나의 항에 기재된 방법의 모든 단계들을 수행하도록 하는
컴퓨터 판독가능 매체.