KR20140038989A

KR20140038989A - 자동화된 사용자 인터페이스 객체 변환 및 코드 생성

Info

Publication number: KR20140038989A
Application number: KR1020137033266A
Authority: KR
Inventors: 러쉬 파텔; 커트 라슨; 루이스 마레스카; 브라이언 로니; 에릭 니센; 존 나넨가
Original assignee: 마이크로소프트 코포레이션
Priority date: 2011-06-13
Filing date: 2012-06-12
Publication date: 2014-03-31
Also published as: EP2718839A4; US20120317504A1; CA2838452A1; JP6210978B2; JP2014522542A; RU2013155469A; EP2718839A2; CN103608799A; MX2013014795A; WO2012174021A2; RU2604431C2; AU2012271774B2; WO2012174021A3; BR112013031998A2; CN103608799B

Abstract

자동화된 사용자 인터페이스 객체 변환 및 코드 생성 기법이 기재된다. 장치는 서버 애플리케이션을 실행하도록 구성된 로직 장치를 포함할 수 있다. 상기 서버 애플리케이션은, 그래픽 사용자 인터페이스(GUI) 독립적 객체를 수신된 사용자 이벤트 속성의 세트로부터 생성하기 위해 해석 런타임 엔진 등을 포함할 수 있다. 상기 GUI 독립적 객체는 템플릿 처리되어, 새로운 GUI 종속적 객체를 생성할 수 있고, 상기 GUI 종속적 객체는 렌더링되도록 클라이언트 애플리케이션으로 반환될 수 있다. 그 밖의 다른 실시예가 기재되고 청구된다.

Description

자동화된 사용자 인터페이스 객체 변환 및 코드 생성{AUTOMATED USER INTERFACE OBJECT TRANSFORMATION AND CODE GENERATION}

클라이언트-서버 아키텍처는 애플리케이션 프로그램에 대한 컴퓨팅 작업 또는 작업부하를 2개의 기본 개체들, 이른바, 서버와 클라이언트 간에 분할(partition)하는 분산 애플리케이션 구조이다. 서버는 자원 또는 서비스의 제공자이다. 클라이언트는 자원 또는 서비스의 요청자이다. 서버는 자신의 자원을 클라이언트와 공유하는 하나 이상의 서버 프로그램을 실행시키는 물리적 또는 논리적 장치이다. 클라이언트는 일반적으로 자신의 자원 중 어느 것도 공유하지 않고 서버로부터 콘텐츠 또는 서비스 기능을 요청하는 물리적 또는 논리적 장치이다. 일반적으로 클라이언트와 서버는 개별 하드웨어 상에서 컴퓨터 네트워크를 통해 통신한다. 그러나 일부 경우 클라이언트와 서버 모두 동일한 시스템에 상주할 수 있다. 따라서 클라이언트가 들어오는 요청(incoming request)을 기다리는 서버와의 통신 세션을 개시한다.

클라이언트-서버 아키텍처의 한 가지 형태는, 종종 n-티어 아키텍처(n-tier architecture)라고 일컬어지는 멀티-티어 아키텍처(multi-tier architecture)이다. n-티어 아키텍처는 애플리케이션 프로그램의 특정 양태가 복수의 티어(tier)로 분리되는 클라이언트-서버 아키텍처이다. 예를 들어, 사용자와 데이터베이스 간의 데이터 요청을 서비스하기 위해 미들웨어를 사용하는 애플리케이션은 멀티-티어 아키텍처를 채용한다. n-티어 애플리케이션 아키텍처는 개발자가 유연하고 재사용 가능한 애플리케이션을 생성하기 위한 모델을 제공한다. 애플리케이션을 복수의 티어로 분할함으로써, 개발자는 특정 티어(또는 계층(layer))를 수정 또는 추가하기만 하면 되며, 이로써 전체 애플리케이션을 다시 써야 할 필요성이 사라진다.

n-티어 아키텍처는 애플리케이션 프로그램을 개발하고 수정할 때 많은 이점을 제공한다. 그러나 많은 수의 클라이언트가 존재하는 웹-기반 환경을 위해 n-티어 아키텍처를 구현하는 것에는 어려움이 있다. 각각의 클라이언트가 서로 다른 웹 기술, 가령, 서로 다른 웹 브라우저, 웹 서비스, 및 웹 애플리케이션을 이용할 수 있다. 덧붙여, 웹 기술은 여러 다른 유형의 기저 하드웨어 및 소프트웨어 아키텍처, 가령, 서로 다른 입출력(I/O) 구성요소, 폼 팩터, 파워 요건, 처리 능력, 통신 능력, 메모리 자원 등을 갖는 다양한 장치와 함께 동작하도록 설계된다. 따라서 이들 많은 이종(heterogeneous) 장치들 및 아키텍처들에 걸쳐 하나 이상의 티어를 구현하는 것이 어려울 수 있다. 덧붙여, 웹 버전(web version)의 애플리케이션 프로그램은 비-웹 버전의 애플리케이션 프로그램과 호환되지 않을 수 있으며, 이로써 각각에 대해 개별적인 소프트웨어 아키텍처가 필요하게 된다. 이러한 단점 및 그 밖의 다른 단점과 관련해, 본원의 개선사항이 필요하다.

개요

이 개요는 이하의 상세한 설명에서 더 기재될 개념들의 모음을 간략화된 형태로 소개하기 위해 제공된다. 이 개요는 청구 대상의 핵심적 특징 또는 본질적 특징을 식별하려는 것이 아니며, 청구 대상의 범위 결정을 보조하려는 것도 아니다.

일반적으로 다양한 실시예가 여러 다른 유형의 애플리케이션 프로그램, 가령, 상업 종목(line-of-business) 애플리케이션 프로그램을 실행하기에 적합한 클라이언트-서버 아키텍처와 관련된다. 구체적으로, 일부 실시예는 애플리케이션 프로그램의 복수의 티어(또는 계층), 가령, 적어도 하나의 표현 티어(presentation tier)를 갖는 n-티어 클라이언트-서버 아키텍처와 관련된다. 일 실시예에서, 예를 들어, 3-티어 클라이언트-서버 아키텍처는 여러 다른 유형의 클라이언트와 동작하도록 해석 런타임 엔진(interpretive runtime engine) 애플리케이션을 적용할 때, 그래픽 사용자 인터페이스(GUI) 렌더링을 분리 및 개선하도록 설계된 기법을 이용해 구현되는 적어도 하나의 표현 티어를 포함할 수 있다.

일 실시예에서, 예를 들어, 장치는 서버 애플리케이션을 실행하도록 구성된 로직 장치를 포함할 수 있다. 상기 서버 애플리케이션은, 해석 런타임 엔진 등을 포함하여, 수신된 사용자 이벤트 속성의 세트로부터 그래픽 사용자 인터페이스(GUI) 독립적 객체를 생성할 수 있다. 상기 GUI 독립적 객체는 템플릿 프로세서에 의해 처리되어 새로운 GUI 종속적 객체를 생성할 수 있고, 상기 GUI 종속적 객체는 렌더링되도록 클라이언트 애플리케이션으로 반환될 수 있다. 그 밖의 다른 실시예가 기재되고 청구된다.

이들 및 그 밖의 다른 특징 및 이점이 이하의 구체적인 내용을 읽고, 이와 연관된 도면을 검토함으로써, 자명해질 것이다. 이상의 포괄적인 기재와 이하의 구체적인 내용 모두 설명을 위한 것에 불과하며 청구되는 사항을 제한하려는 것이 아님을 이해해야 한다.

도 1a는 종래의 데스크톱 애플리케이션 아키텍처를 도시한다.
도 1b는 종래의 2-티어 애플리케이션 아키텍처를 도시한다.
도 1c는 종래의 3-티어 애플리케이션 아키텍처를 도시한다.
도 2는 일 실시예에 따르는 복수의 클라이언트 및 클라이언트 어댑터를 갖는 개선된 n-티어 클라이언트-서버 아키텍처의 블록도를 도시한다.
도 3은 일 실시예에 따르는 단일 클라이언트와 클라이언트 어댑터를 갖는 개선된 n-티어 클라이언트-서버 아키텍처의 블록도를 도시한다.
도 4는 일 실시예에 따르는 클라이언트에 대한 그래픽 사용자 인터페이스(GUI) 독립적 객체 및 클라이언트 어댑터를 갖는 개선된 n-티어 클라이언트-서버 아키텍처의 블록도를 도시한다.
도 5는 일 실시예에 따르는 개선된 n-티어 클라이언트-서버 아키텍처의 제 1 논리 흐름도를 도시한다.
도 6a는 일 실시예에 따르는 GUI 독립적 객체의 논리도를 도시한다.
도 6b는 일 실시예에 따르는 특정 GUI 독립적 객체의 논리도를 도시한다.
도 7은 일 실시예에 따르는 개선된 n-티어 클라이언트-서버 아키텍처의 제 2 논리 흐름도를 도시한다.
도 8a는 일 실시예에 따라 GUI 객체 레이아웃을 나타내는 템플릿을 처리하기 위한 개선된 n-티어 클라이언트-서버 아키텍처의 블록도를 도시한다.
도 8b는 일 실시예에 따르는 대표적 GUI 객체 레이아웃으로부터 생성된 제 1 사용자 인터페이스 뷰를 도시한다.
도 8c는 일 실시예에 따라 대표적 GUI 객체 레이아웃으로부터 생성된 제 1 사용자 인터페이스 뷰를 도시한다.
도 9는 일 실시예에 따르는 템플릿 처리 시스템의 제 3 논리 흐름을 도시한다.
도 10은 일 실시예에 따르는 개선된 n-티어 클라이언트-서버 아키텍처에 적합한 컴퓨팅 아키텍처의 실시예를 도시한다.
도 11은 일 실시예에 따르는 개선된 n-티어 클라이언트-서버 아키텍처에 적합한 통신 아키텍처의 일 실시예를 도시한다.

일반적으로 다양한 실시예는 서로 다른 유형의 상업 종목(line-of-business) 애플리케이션 프로그램을 실행하기에 적합한 클라이언트-서버 아키텍처와 관련된다. 특히 일부 실시예는 개선된 n-티어 클라이언트-서버 아키텍처와 관련되며, 여기서 n은 임의의 정수를 나타내는 변수이다. 개선된 n-티어 아키텍처는 애플리케이션 프로그램의 복수의 티어(또는 계층(layer)), 가령, 적어도 하나의 표현 티어(presentation tier)를 포함할 수 있다. 일 실시예에서, 예를 들어, 상기 개선된 n-티어 아키텍처는, 적어도 하나의 표현 티어(presentation tier), 애플리케이션 처리 티어(application processing tier), 및 데이터 관리 티어(data management tier)를 포함하는 3-티어 아키텍처로서 구현될 수 있다. 일반적으로 표현 티어는 사용자 인터페이스 로직, 가령, 입/출력 연산을 다루는 것을 구현한다. 일반적으로, 애플리케이션 처리 티어는 애플리케이션 또는 비즈니스 로직, 가령, 애플리케이션 규칙의 세트에 따라 데이터를 처리하는 것을 구현한다. 일반적으로 데이터 관리 티어는 데이터 저장 및 액세스, 가령, 데이터 스키마 정의, 데이터 저장, 데이터 질의 처리 등을 구현한다.

개선된 n-티어 클라이언트-서버 아키텍처는 해석 런타임 엔진(interpretive runtime engine)을 이용하는 애플리케이션에서의 GUI 렌더링 및 사용자 이벤트의 분리 및 최적화를 용이하게 하도록 설계된 기법을 이용해 구현되는 적어도 하나의 표현 티어를 포함할 수 있다. 이는 해석 런타임 엔진 애플리케이션의 변경은 감소시키면서, 2-티어 클라이언트-서버 기반 아키텍처로부터 호스팅되는 3-티어 환경으로의 해석 런타임 엔진 애플리케이션의 채택을 가능하게 한다.

도 1a, 1b 및 1c는 개선된 n-티어 클라이언트-서버 아키텍처의 다양한 실시예에 대한 이점을 강조하기 위한 배경으로서, 애플리케이션 개발을 위한 3개의 종래의 아키텍처를 도시한다. 도 1a는 종래의 데스크톱 아키텍처를 도시한다. 도 1b는 종래의 2-티어 아키텍처를 도시한다. 도 1c는 종래의 3-티어(또는 n-티어) 아키텍처를 도시한다.

도 1a는 애플리케이션 프로그램(112)의 모든 부분(또는 애플리케이션 계층)이 클라이언트 컴퓨터(110)(가령, 데스크톱 컴퓨터) 상에서 구현되는 데스크톱 아키텍처(100)의 일례이다. 상기 애플리케이션 프로그램(112)은, 예를 들어, 사용자 인터페이스(UI) 로직, 비즈니스 로직, 및 데이터베이스 액세스 로직을 구현하는 다양한 애플리케이션 계층을 포함할 수 있다. 상기 애플리케이션 프로그램(112)은, 또한 클라이언트 컴퓨터(110) 상에서 구현되는 데이터베이스(114)에 애플리케이션 데이터를 저장 및 액세스할 수 있다.

도 1b는 현재 데이터베이스(114)가 클라이언트 컴퓨터(110)로부터 원격으로 위치하는 2-티어 아키텍처(120)의 일례이다. 2-티어 아키텍처(120)에서, 애플리케이션 프로그램(112) 및 이의 구성요소인 애플리케이션 계층은 여전히 클라이언트 컴퓨터(110) 상에 존재한다. 그러나 데이터베이스(114)가 클라이언트 컴퓨터(110)로부터 데이터베이스 서버(116)로 이동되었다. 상기 클라이언트 컴퓨터(110)에서 실행 중인 애플리케이션 프로그램(112)은 데이터베이스 애플리케이션 프로그램 인터페이스(API)를 통해, 데이터베이스(114)와 통신 가능하게 연결된 데이터베이스 서버(116)로 데이터에 대한 요청을 전송한다. 그 후, 요청된 데이터가 클라이언트 컴퓨터(110) 상에서 실행 중인 애플리케이션 프로그램(112)으로 반환(return)된다.

도 1c는 3-티어 아키텍처(130)의 일례이다. 3-티어 아키텍처(130)에서, 애플리케이션 프로그램(112)은 클라이언트 컴퓨터(110)와 서버(122) 상에서 각자 실행되는 분산 애플리케이션 프로그램(112, 124)으로 분리될 수 있다. 상기 애플리케이션 프로그램(112)은 UI 로직을 갖는 애플리케이션 계층을 구현할 수 있다. 상기 애플리케이션 프로그램(124)은 비즈니스 및 데이터베이스 액세스 로직을 갖는 애플리케이션 계층을 구현할 수 있다. 상기 클라이언트 컴퓨터(110)에서 실행되는 상기 애플리케이션 프로그램(112)이 상기 애플리케이션 프로그램(124)을 실행하는 서버(122)로 데이터를 전송한다. 그 후 상기 애플리케이션 프로그램(124)은 비즈니스 로직을 실행시키고 데이터에 대한 요청을 데이터베이스(114)와 통신 가능하게 연결된 데이터베이스 서버(116)로 전송한다. 요청된 데이터 및 실행된 비즈니스 로직의 결과가 애플리케이션 프로그램(112)으로 반환되고 클라이언트 컴퓨터(110)에서 렌더링된다. 데이터베이스 서버(116)는 서버(122)와 같은 곳에 위치하거나, 서버(122)의 일부분일 수 있다는 점이 이해되어야 한다. 즉, 단일 서버(122)가 애플리케이션 서버와 데이터 서버 모두의 기능을 하도록 하드웨어 아키텍처가 구성될 수 있다. 2-티어 아키텍처와 3-티어(또는 n-티어) 아키텍처를 구별하는 요인은 애플리케이션 계층 중 일부 또는 다수가 클라이언트 컴퓨터(110) 밖으로 이동하고, 하나 이상의 그 밖의 다른 서버(116, 122)들 간에 분포된다는 것이다.

n-티어 아키텍처, 가령, 3-티어 아키텍처(130)는 2-티어 아키텍처(120)에 비해, 애플리케이션 프로그램을 개발 및 수정할 때 많은 이점을 제공할 수 있다. 예를 들어, 전체 애플리케이션 프로그램의 완전한 다시 쓰기를 초래하지 않고 단일 티어가 수정 또는 추가될 수 있다. 그러나 많은 수의 클라이언트가 존재하는 웹-기반 환경에 대해 n-티어 아키텍처를 구현하는 데 어려움이 존재한다. 각각의 클라이언트는 서로 다른 웹 기법, 가령, 서로 다른 웹 브라우저, 웹 서비스, 및 웹 애플리케이션을 이용할 수 있다. 덧붙여, 웹 기법이, 여러 다른 유형의 기저 하드웨어 및 소프트웨어 아키텍처, 가령, 서로 다른 입/출력(I/O) 구성요소, 폼 팩터, 파워 요건, 프로세싱 능력, 통신 능력, 메모리 자원 등을 갖는 다양한 장치와 함께 동작하도록 설계된다. 따라서 각각의 클라이언트의 고유의 구성에 맞도록 표현 계층을 광범위하게 커스텀화하지 않고, 특정 애플리케이션 계층, 가령, 표현 계층을 이와 같은 많은 이종 장치 및 아키텍처에 걸쳐 균일하게 구현하는 것이 어려울 수 있다. 덧붙여, 웹 버전의 애플리케이션 프로그램은 비-웹 버전의 애플리케이션 프로그램과 호환되지 않을 수 있기 때문에, 각각에 대해 개별 소프트웨어 아키텍처가 필요할 수 있다.

다양한 구현예에서, 개선된 n-티어 아키텍처는 2-티어 클라이언트-서버 애플리케이션 아키텍처가 애플리케이션 프로그램의 표현 계층에 대해 씬 클라이언트(thin client)를 이용하는 3-티어 애플리케이션 아키텍처로 이주(migration)하는 것을 가능하게 하는 프레임워크를 제공한다. 일 실시예에서, 예를 들어, 각각의 클라이언트 장치는 웹 클라이언트(web client)의 형태로 된 씬 클라이언트를 구현할 수 있다. 일반적으로 웹 클라이언트는 웹 기법, 가령, 클라이언트 컴퓨터에서 동작하는 웹 브라우저를 이용해 구현되는 씬 클라이언트 애플리케이션을 일컫는다. 웹 클라이언트는 또한, 사이트 또는 서버로부터의 커스텀 서비스를 지원하기 위해 브라우저를 보강하는 플러그-인(plug-in) 및 헬퍼(helper) 애플리케이션을 일컬을 수도 있다. 본원에서 언급되는 웹 클라이언트는 웹 브라우저의 기능부(functionality)를 일컬을 수도 있다.

도 2는 클라이언트-서버 시스템(200)을 도시한다. 일 실시예에서, 상기 클라이언트-서버 시스템(200)은 개선된 n-티어 클라이언트-서버 시스템을 포함할 수 있다. 상기 개선된 n-티어 클라이언트-서버 시스템은 애플리케이션 프로그램을 적어도 하나의 표현 티어를 포함하는 복수의 티어로 분리시킬 수 있다. 상기 표현 티어는 해석 런타임 엔진(interpretive runtime engine)을 이용해 애플리케이션 프로그램 내 GUI 렌더링 및 사용자 이벤트의 분리 및 최적화를 촉진시키도록 설계된 기법을 이용해 구현될 수 있다. 이는 해석 런타임 엔진 애플리케이션에 대한 요구되는 변경은 감소시키면서, 2-티어 클라이언트-서버 기반 아키텍처로부터 호스팅된 3-티어 환경으로의 해석 런타임 엔진 애플리케이션을 채택하는 것을 가능하게 한다.

앞서 도 1a를 참조하여 기재된 바와 같이, 많은 애플리케이션이 2-티어 애플리케이션을 따르되, 이러한 2-티어 애플리케이션 아키텍처에서는, 애플리케이션이 2개의 상호 관련된 구성요소-데이터베이스 서버 및 클라이언트 애플리케이션으로 구성된다. 상기 데이터베이스 서버는 클라이언트에서 수행되기에 극도로 시간 소모적일 과중한 연산 중 일부를 처리할 수 있게 하는 확장된 비즈니스 로직과 함께, 시스템 및 회사 데이터(company data)를 호스팅할 수 있다. 한편, 클라이언트 애플리케이션은 UI를 전달하는 기능, 데이터 엔트리 검증(data entry validation)을 제공하는 기능, 및 리포트를 렌더링하는 기능 등을 수행할 수 있다.

도 2에 도시된 실시예에서, 클라이언트-서버 시스템(200)은 서버(202)와 복수의 클라이언트(204, 206)를 포함할 수 있다. 서로 다른 하드웨어 플랫폼에서 구현될 때, 서버(202)와 클라이언트(204, 206)는 네트워크(250)를 통해 서로와 통신할 수 있다. 동일한 하드웨어 플랫폼에서 구현될 때, 서버(202)와 클라이언트(204, 206)는 적절한 버스 기법 및 아키텍처를 통해 서로와 통신할 수 있다. 도 2가 간결성을 목적으로 단일 서버(202)와 2개의 클라이언트(204, 206)만 도시하고 있지만, 상기 클라이언트-서버 시스템(200)은 임의의 개수의 서버 및 클라이언트를 특정 구현예에서 원하는 대로 구현할 수 있음이 자명할 수 있다. 실시예는 이러한 맥락에 제한되지 않는다.

일 실시예에서, 서버(202)는 서버 애플리케이션(210)을 구현하는 전자 장치를 포함할 수 있다. 상기 서버 애플리케이션(210)은 임의의 유형의 서버 애플리케이션, 가령, 상업 종목 애플리케이션을 포함할 수 있다. 상업 종목 애플리케이션의 비-제한적 예로는, 회계 프로그램, 기업 자원 계획(ERP: enterprise resource planning) 애플리케이션, 고객 관계 관리(CRM: customer relationship management) 애플리케이션, 공급 체인 관리(SCM: supply chain management) 애플리케이션 등이 있을 수 있다. 이들 상업 종목 애플리케이션은, 일반적으로 클라이언트 장치, 가령, 데스크톱 컴퓨터가 아니라 상업적 기업 망 내 서버 또는 서버 어레이(server array)에 의해 실행되기 때문에, 때때로 "미들-티어(middle-tier)" 애플리케이션이라고 지칭된다. 특정 예로는 워싱턴, 레드몬드에 소재하는 Microsoft Corporation사의 Microsoft® Dynamics GP가 있을 수 있다. 상기 Microsoft® Dynamics GP는 상업적 회계 소프트웨어 애플리케이션이다. 상업 종목 애플리케이션의 또 다른 특정 예는 워싱턴, 레드몬드에 소재하는 Microsoft Corporation사의 Microsoft Dynamics® AX를 포함할 수 있다. Microsoft Dynamics AX는 상업적 ERP 소프트웨어 애플리케이션이다. 그러나 실시예는 이들 예시에 한정되지 않는다.

서버(202)가 서버 애플리케이션(210)에 대한 코드를 실행하는 중일 때, 상기 서버(202)는 해석 런타임 엔진(interpretive runtime engine)(212)을 형성한다. 상기 해석 런타임 엔진(212)은 서버 애플리케이션(210)에 대해, 클라이언트-서버 시스템(200)에서 애플리케이션 로직(214), 데이터베이스 로직(216), 및 서버 표현 로직(server presentation logic)(218)이라고 일컬어지는 복수의 애플리케이션 계층을 구현한다. 상기 서버 애플리케이션(210)은 클라이언트(204, 206)로부터 네트워크(250)를 통해 신호 또는 메시지의 형태로 수신된 제어 지시(control directive)를 통해 제어 및 동작될 수 있다.

일 실시예에서, 클라이언트(204, 206) 각각은 각자의 웹 클라이언트(230, 240)를 구현하는 전자 장치를 포함할 수 있다. 예를 들어, 상기 웹 클라이언트(230, 240) 각각은 각자의 클라이언트(204, 206) 상에서 실행 중인 웹 브라우저의 인스턴스를 포함할 수 있다. 상기 웹 브라우저는 또한 서버(202)로부터의 커스텀 서비스를 지원하기 위해 웹 브라우저를 보강하도록 설계된 플러그-인, 웹 애플리케이션 및 헬퍼 애플리케이션을 포함할 수 있다. 본원에서 언급되는 웹 클라이언트(230, 240)는 웹 브라우저의 기능을 지칭할 수도 있다.

상기 클라이언트(204, 206)는 각자의 클라이언트 어댑터(client adapter)(232, 242)를 포함할 수 있다. 클라이언트 어댑터(232, 242) 각각은 특정클라이언트(204, 206)에 의해 사용되도록 구성될 수 있다. 이러한 방식으로, 서로 다른 기법을 이용해 서로 다른 클라이언트에 의해 액세스될 때 서버 애플리케이션(210) 및 해석 런타임 엔진(212)은 수정될 필요가 없다.

상기 클라이언트 어댑터(232, 242)는 각자의 클라이언트 표현 로직(238, 248)을 포함할 수 있다. 상기 클라이언트 표현 로직(238, 248)은 클라이언트(204, 206)에 대한 출력 장치, 가령, 디지털 디스플레이 상에 사용자 인터페이스 요소 또는 뷰(view)를 표현(present)하도록 설계될 수 있다. 서버 애플리케이션(210)에 대해 구현되는 분산 n-티어 아키텍처에 따라, 상기 클라이언트 표현 로직(238, 248)은 서버(202) 상에서 실행되는 서버 애플리케이션(112)의 애플리케이션 로직(214), 데이터베이스 로직(216), 및 서버 표현 로직(218)과 상호운용(interoperate)되도록 설계될 수 있다.

클라이언트 어댑터(232, 242) 및 이들 각자의 클라이언트 표현 로직(238, 248)은, 서버 표현 로직(218)과 상호운용됨으로써, 상기 서버 애플리케이션(210)은 서로 다른 클라이언트(204, 206)를 통해 액세스될 수 있다. 각각의 클라이언트(204, 206)는 서로 다른 버전의 서버 표현 로직(218)을 각자의 클라이언트 표현 로직(238, 248)으로서 구현하여, 클라이언트(204, 206)에 대해 특정 구성(configuration)을 맞출 수 있다. 이는 서버 표현 로직(218)를 다시 쓸 필요 없이 이뤄질 수 있고, 더 중요한 것은, 비즈니스 로직(214) 및 데이터베이스 로직(216)을 다시 쓸 필요 없다는 것이다. 덧붙여, 서버 표현 로직(218) 및 클라이언트 표현 로직(238, 248)은 네트워크(250)에 대한 통신 트래픽 및 오버헤드를 감소시키는 방식으로 상호대화할 수 있음으로써, 통신 딜레이와 연관된 대기시간(latency)을 감소시키면서 속도와 성능은 증가시킬 수 있다.

다양한 실시예에서, 상기 서버 표현 로직(218) 및 상기 클라이언트 표현 로직(238, 248)은 그래픽 사용자 인터페이스(GUI: graphical user interface) 독립적 객체(260)를 활용하여 효율적인 방식으로 상호대화할 수 있다. 상기 GUI 독립적 객체(260)는 GUI 요소, 가령, GUI 스크린(가령, Microsoft Windows® Forms)이 데스크톱 환경과 웹 환경 사이에 자유롭게 이동할 수 있게 한다. 상기 GUI 독립적 객체(260)에 의해 상기 서버 애플리케이션(210)은 전통적인 OS 폼(form)을 통해 또는 웹 클라이언트 폼을 통해 수신될 수 있고, 제출됐던 폼의 유형에 무관하게 스크립트 이벤트를 실행시킬 수 있는 사용자 이벤트를 기다리면서 배경(background) 서비스로서 실행될 수 있다.

GUI 독립적 객체(260)는, 애플리케이션 로직 이벤트에 영향을 미칠 수 있는 사용자 이벤트 속성에 추가로, 클라이언트 어댑터(232, 242)에 의한 GUI 종속적 렌더링에 영향을 미칠 수 있는 사용자 이벤트, 임의의 사용자 이벤트 속성, 및 그 밖의 다른 유형의 정보를 포함할 수 있다. 상기 GUI 독립적 객체(260)는 해석 런타임 엔진(212)으로부터 생성되고 클라이언트 어댑터(232, 242)에게로 전송되며, 이는 추후 각자의 클라이언트 표현 로직(238, 248)을 통해 클라이언트 사용자 인터페이스에서 렌더링된다.

도 3은 n-티어 클라이언트-서버 시스템(300)의 특정 구현예를 도시한다. 상기 클라이언트-서버 시스템(300)은 서버(302) 및 클라이언트(304)를 포함할 수 있다. 상기 서버(302)는, 예를 들어, 도 2를 참조하여 기재된 서버(202)를 나타낼 수 있다. 상기 클라이언트(304)는, 예를 들어, 도 2를 참조하여 기재된 클라이언트(204, 206) 중 하나 또는 둘 모두를 나타낼 수 있다.

클라이언트-서버 시스템(300)에서 나타난 실시예에서, 상기 서버(302)는 서버 애플리케이션(310)을 구현할 수 있다. 일 실시예에서, 예를 들어, 서버 애플리케이션(310)은 Microsoft Dexterity® 프로그래밍 언어, 그 밖의 다른 적절한 유형의 프로그래밍 언어를 이용해 코딩될 수 있다. Microsoft Dexterity 애플리케이션으로서 구현될 때, 일반적으로 서버 애플리케이션(310)은 2개의 개별 요소로 나뉠 수 있다. 제 1 요소는 애플리케이션 환경의 기술적인 면, 가령, 운영 체제(OS)와의 통신, 및 파일 관리자(316)를 통한 데이터베이스(320)로의 연결 구축 및 관리를 해결하는 해석 런타임 엔진(312)이다. 제 2 요소는 애플리케이션 로직(315), 가령, 애플리케이션 규칙, 비즈니스 규칙, 폼, 리포트, 자원, 메타데이터, 및 사용자 명령(user command) 및 입력에 대한 응답을 가능하게 하는 애플리케이션 코드를 호스팅하는 애플리케이션 딕셔너리(application dictionary)(313)이다. 이 아키텍처는 애플리케이션 로직(315)을 UI 스타일 변경 및 플랫폼 진보, 가령, 플랫폼 OS의 업그레이드로부터 격리시킨다.

산스크립트(sanScript) 코드는 애플리케이션이 동작하는 방식을 제어하기 위해 사용된다. 일반적으로 상기 산스크립트 코드는 애플리케이션 딕셔너리(313) 내 객체, 가령, 필드, 메뉴, 스크린 및 폼에 첨부되는 작은 세그먼트, 또는 스크립트로 써진다. 스크립트는 사용자가 애플리케이션 내 특정 객체와 상호대화할 때 실행된다. 예를 들어, 푸시 버튼(push button)에 적용되는 스크립트는 사용자가 버튼을 클릭할 때 실행될 것이다.

나타난 바와 같이, 클라이언트(304)는 웹 클라이언트(330)를 포함할 수 있다. 상기 웹 클라이언트(330)는, 예를 들어, 웹 클라이언트(230, 240) 중 하나 또는 둘 모두를 나타낼 수 있다. 상기 웹 클라이언트(330)는 사용자 인터페이스 및 사용자 상호대화에 적응된 컴포넌트와 서비스의 세트, 가령, 서버 애플리케이션(310)에 의해 사용되기 위한 사용자 입력 및 경량 사용자 인터페이스 컨트롤(lightweight user interface control)을 전달할 수 있다. 그러나 3-티어 아키텍처로의 매끄러운 이주(smooth migration)를 이루기 위해, 효율적인 웹 클라이언트 인터페이스를 가능하게 하도록, 웹 클라이언트 아키텍처의 도입에 의해 발생된 다양한 기술적 과제가 극복될 필요가 있다.

본원에 기재된 실시예의 목표는 기존 코드 및 GUI 메타데이터에 대해 필요한 변경을 감소시키는 것이다. 앞서 언급된 과제들 중 일부를 해결하기 위해, 다양한 실시예가 사용자 인터페이스 관리자(318)와 OS 렌더링 엔진(322)을 해석 런타임 엔진(312)으로부터 연결해제(decouple)하기 위한 기법과 관련된다. 사용자 인터페이스 관리자(318)는 특정 GUI 시스템 내, 다양한 인터페이스 요소, 가령, GUI 스크린의 배치 및 외관을 제어하는 시스템 소프트웨어이다. 상기 OS 렌더링 엔진(322)은 콘텐츠를 디스플레이하기 위한 시스템 소프트웨어이다. 해석 런타임 엔진(312)은 서버 애플리케이션(310)의 실행된 버전(executed version)이다.

폼(또는 스크린)의 사용은 임의의 Microsoft Dexterity 애플리케이션의 핵심 구성요소이다. 상기 폼은 사용자가 서버 애플리케이션(310)과 상호대화할 때 이용할 메커니즘이다. 서버 애플리케이션(310)은 Microsoft Dexterity 애플리케이션, 가령, 일반적으로 상기 스크린을 위한 컨트롤과 연관된 산스크립트 코드를 포함하는 Microsoft Dexterity 애플리케이션 스크린으로서 구현된다. 스크립트 인터프리터(script interpreter)(314)의 지시 하에 스크린 및 컨트롤의 의도된 기능이 주어질 때 상기 산스크립트 코드는 사용자 이벤트에 응답하여 실행된다.

서버 애플리케이션(310)의 비-웹 버전(non-web version)에서, UI는 사용자 인터페이스 관리자(318)에 의해 관리되며, 그 후 OS 렌더링 엔진(322)과 통신하여 실제 Microsoft Dexterity 스크린을 개발자에 의해 이전에 배치된 컨트롤 요소와 함께 디스플레이 스크린 상에 디스플레이할 수 있다.

그러나 클라이언트-서버 시스템(300)의 웹 클라이언트 3-티어 아키텍처로의 전환(transition)을 촉진하기 위해, 상기 사용자 인터페이스 관리자(318) 및 OS 렌더링 엔진(322)은 해석 런타임 엔진(312)의 기능으로부터 연결해제될 수 있다. 이는 웹 클라이언트(332)가 사용자 인터페이스 관리자(336) 및 렌더링 엔진(338)의 클라이언트 버전을 클라이언트(304) 상에서 구현할 수 있게 해준다. 이는 또한 서버(302) 상에서 실행 중인 해석 런타임 엔진(312)이 웹 클라이언트(332)에 의해 사용되기 위한 GUI 독립적 객체(360)를 생성할 수 있게 해준다. GUI 독립적 객체(360)를 이용해, 서버 애플리케이션(310)의 기저 애플리케이션 클라이언트 로직(315) 중 어느 것도 변경할 필요 없이, 클라이언트(304)의 웹 클라이언트(330)가 동일한 스크린의 웹-기반 표현을 제공할 수 있도록 하면서, 전통 클라이언트는 통상의 GUI 스크린(가령, Microsoft Win32® 스크린)을 계속 제공할 수 있다.

사용자 인터페이스 관리자(318) 및 OS 렌더링 엔진(322)을 해석 런타임 엔진(312)으로부터 연결해제함으로써, 스크린(폼)이 비-웹(가령, 데스크톱 또는 Win32) 환경과 웹 환경 사이를 자유롭게 이동할 수 있다. 연결해제된 사용자 인터페이스 관리자(318) 및 OS 렌더링 엔진(322)을 이용해, 상기 서버 애플리케이션(310)은 전통적인 Win32 폼 또는 웹 클라이언트 폼을 통해 수신될 수 있고 제출됐던 폼의 유형에 무관하게 스크립트 이벤트를 실행시킬 수 있는 사용자 이벤트를 기다리면서, 배경(background) 서비스로서 실행될 수 있다.

연결해제를 촉진시키기 위해, 서버 애플리케이션(310)의 GUI 종속적 처리 계층과 GUI 독립적 처리 계층이 먼저 서로 분리된다. 이들 2개의 계층 간 직접 통신 대신, GUI 독립적 객체(360)를 이용해 렌더링 및 이벤트 메타데이터가 노출(expose)된다. 상기 GUI 독립적 객체(360)는, 애플리케이션 로직 이벤트에 영향을 미칠 수 있는 사용자 이벤트 속성에 추가로, 클라이언트 어댑터(332)에 의한 GUI 종속적 렌더링에 영향을 미칠 수 있는 임의의 사용자 이벤트 속성을 포함할 수 있다. 그 후 상기 GUI 독립적 객체(360)는 클라이언트(304)를 위한 디스플레이 상의 클라이언트 사용자 인터페이스 스크린에서 렌더링된 (GUI 종속적) 클라이언트 어댑터(332)로 전송된다. 일부 클라이언트 어댑터(332)의 비-제한적 예시는, Microsoft Silverlight®, HTML, Win32 GDI, .Net Forms 등을 포함할 수 있다.

도 4는 n-티어 클라이언트-서버 시스템(400)의 특정 구현예를 도시한다. 상기 클라이언트-서버 시스템(400)은 서버(402)와 클라이언트(404)를 포함할 수 있다. 상기 서버(402)는, 예를 들어, 도 2, 3을 참조하여 기재되는 서버(202, 302)를 나타낼 수 있다. 클라이언트(404)는, 예를 들어, 도 2, 3을 참조하여 기재되는 클라이언트(204, 206, 304) 중 하나 또는 모두를 나타낼 수 있다.

서버(402) 상에서, 하나 이상의 애플리케이션 계층을 실행하는 역할을 하거나 하나 이상의 애플리케이션 계층을 실행하는 그 밖의 다른 구성요소와 연결된 해석 런타임 엔진(412)을 포함하는 서버 애플리케이션(410)이 존재할 수 있다. 해석 런타임 엔진(412)은 스크립트 인터프리터(script interpreter)(414), 파일 관리자(416), 및 사용자 인터페이스 관리자(418)를 더 포함할 수 있다. 상기 스크립트 인터프리터(414)는 파일 관리자(416) 및 서버 사용자 인터페이스 관리자(418)와 통신할 수 있다. 파일 관리자(416)는 또한 데이터베이스(420)와 통신할 수 있다.

클라이언트(404) 상에, 클라이언트 어댑터(432)를 실행하는 웹 클라이언트(430)가 존재한다. 상기 클라이언트 어댑터(432)는 도 2에 도시된 클라이언트 표현 로직(238, 248)에 따라, 클라이언트 사용자 인터페이스, 가령, 클라이언트 사용자 인터페이스에 콘텐츠를 디스플레이하기 위해 사용자 인터페이스 관리자(436) 및 렌더링 엔진(438)을 포함할 수 있다.

도 4는 3-티어 애플리케이션 아키텍처를 나타낼 수 있고, 여기서 특정 애플리케이션 계층이 서버(402)와 클라이언트(40) 간에 분산될 수 있다. 예를 들어, 클라이언트 표현 로직(238 및/또는 248)이 클라이언트(404) 상에 상주할 수 있고, 반면에, 도 2에 도시된 것처럼, 애플리케이션 로직(214) 및 데이터베이스 로직(216)은 서버(402) 상에 분산되어 있을 수 있다. 도 4의 도시된 아키텍처는 사용자 인터페이스 관리자(436) 및 렌더링 엔진(438)의 기능을 서버(402) 상의 해석 런타임 엔진(412)으로부터 연결해제했고, 이를 클라이언트(404) 상에 클라이언트 어댑터(432)와 함께 위치시켰다.

일 실시예에서, 해석 런타임 엔진(412)은 스크립트 인터프리터(414)를 포함할 수 있다. 일반적으로, 상기 스크립트 인터프리터(414)는 사용자 이벤트, 비-제한적 예를 들면, 트랜잭션(transaction)의 저장 또는 배치(batch)의 포스팅에 응답하여 스크립트된 코드를 실행하도록 구성될 수 있다. 스크립트된 코드의 예시는 프리-스크립트(pre-script), 변경 스크립트(change script), 포스트-스크립트(post-script), 및 그 밖의 다른 유형의 스크립트를 포함할 수 있다.

일 실시예에서, 해석 런타임 엔진(412)은 파일 관리자(416)를 포함할 수 있다. 일반적으로 파일 관리자(416)는 데이터베이스(420)에 저장된 파일에 대한 파일 관리 동작을 수행하도록 구성될 수 있다. 파일 관리 동작의 예시는 파일 생성, 파일 열기, 파일 복사, 파일 이동, 파일 삭제 등을 포함할 수 있다.

일 실시예에서, 해석 런타임 엔진(412)은 사용자 인터페이스 관리자(436)를 포함할 수 있다. 일반적으로, 상기 사용자 인터페이스 관리자(436)는 특정 GUI 시스템을 구현하는 사용자 인터페이스 내, 다양한 사용자 인터페이스 요소, 가령, 스크린 요소의 배치 및 외관을 제어하도록 구성될 수 있다.

동작 중에, 사용자는 웹 클라이언트(430)를 통해 클라이언트 사용자 인터페이스와 상호대화할 수 있다. 상기 웹 클라이언트(430)는 웹-기반 콘텐츠를 렌더링하기 위한 사용자 인터페이스 코드를 갖는 웹 브라우저를 포함할 수 있다. 상기 웹 클라이언트(430)는 다양한 웹 기법, 가령, HTML, XHTML, XML 등을 이용해 구현될 수 있다. 웹 클라이언트(430)의 비-제한적 예를 들면, 워싱턴, 레드몬드에 소재하는 Microsoft Corporation사의 Internet Explorer®, 및 그 밖의 다른 유형의 웹 브라우저 소프트웨어가 있을 수 있다.

일 실시예에 따라, 동작 중에 사용자는 웹 클라이언트(430)를 통해 클라이언트 사용자 인터페이스와 상호대화할 수 있고, 클라이언트 어댑터(432)에 의해 수신되고 처리될 수 있는 사용자 이벤트를 입력할 수 있다. 사용자 이벤트의 비-제한적 예를 들면, 포인터를 필드로 이동시키기, 필드 위에서 호버링(hover)하기, 필드를 선택하기, 버튼을 마우스로 클릭하기, 텍스트 필드를 채우기, 및 이와 유사한 동작들이 있을 수 있다. 사용자 이벤트는 사용자 이벤트 속성의 세트를 이용해 정의될 수 있다. 일 실시예에서, 사용자 이벤트 속성의 완전한 세트 대신, 사용자 이벤트 속성에 대한 변경만 웹 클라이언트(430)에서 서버 애플리케이션(410)으로 전송될 필요가 있다. 이러한 차분 기법이 통신 대역폭을 보존하고 대기시간을 감소시킬 수 있다.

사용자 이벤트 속성은 사용자 인터페이스 레이아웃에 디스플레이되는 사용자 인터페이스 요소, 가령, 필드, 스크린 또는 그래픽 객체로 할당될 수 있는 임의의 속성(attribute)일 수 있다. 사용자 이벤트 속성은 대응하는 사용자 인터페이스 요소에 대한 표현 스타일(presentation style) 또는 표현 포맷(presentation format)의 속성을 기술한다. 사용자 이벤트 속성은, 사용자 인터페이스 요소 식별자(ID), 속성(가령, 테두리(border), 폰트, 폰트 크기, 폰트 색상, 배경, 배경 색상, 스타일, 우정렬, 중앙 정렬, 우정렬, 싱글 스페이스(single space), 더블 스페이스 등), 속성 값(가령, 거짓(false), 참(true), 0, 1 등), 및 그 밖의 다른 유형의 정보를 포함할 수 있다. 예를 들어, GUI 스크린은 거짓(False)으로 설정된 크기 조절 가능함 속성(Resizeable property)과 함께 식별자 "윈도 001"을 가지며, 이는 GUI 스크린이 런타임 시 사용자에 의해 크기 조절될 수 없음을 의미한다. 이는 단지 몇 가지 예에 불과하며, 임의의 사용자 인터페이스 요소 및 사용자 인터페이스 속성이 특정 구현예에 따라 원하는 대로 구현될 수 있다. 이러한 맥락으로 실시예는 제한되지 않는다.

웹 클라이언트(430)는 변경된 사용자 이벤트 속성(451)의 세트를 메시지(450)로 서버 애플리케이션(410)에게 전송할 수 있다. 서버(402) 상에서 동작하는 상기 사용자 인터페이스 관리자(418)는 변경된 사용자 이벤트 속성(451)을 메시지(450)로 스트립트 인터프리터(41)에게 포워드(forward)하여 처리되도록 한다. 상기 서버 애플리케이션(410)은 서버 애플리케이션(410)에 대해 임의의 애플리케이션 로직을 실행하기 전에 애플리케이션 입력 및 애플리케이션 상태가 적절함을 보장할 수 있다. 그 후 클라이언트(404)로부터 수신된 메시지(450) 내 변경된 사용자 이벤트 속성(451)으로부터 도출된 임의의 애플리케이션 규칙의 실행 시 필요한 경우, 상기 스크립트 인터프리터(414)는 데이터베이스(420)를 액세스하는 파일 관리자(416)와 통신할 수 있다. 적절한 애플리케이션 로직의 실행 후, 해석 런타임 엔진(412)은 GUI 독립적 객체(452)를 생성할 수 있다. 상기 GUI 독립적 객체(452)는 업데이트된 사용자 이벤트 속성(454) 및 그 밖의 다른 정보를 포함할 수 있다. 서버(402)에 의해 구현되는 사용자 인터페이스 관리자(418)는 임의의 업데이트된 사용자 이벤트 속성(454)과 함께 GUI 독립적 객체(452)를 클라이언트(404)에게 다시 되전송할 수 있다. 그 후 클라이언트 어댑터(432)는 클라이언트 사용자 인터페이스 관리자(436) 및 렌더링 엔진(438)을 통해 이전에 GUI 독립적 객체(452)를 이용해 렌더링된 이미지를 서버 애플리케이션(410)에 의해 생성되고 이로부터 수신된 업데이트된 사용자 이벤트 속성(454)과 함께 업데이트할 수 있다.

앞서 기재된 실시예에 대한 동작은 하나 이상의 논리 흐름을 참조하여 추가로 기재될 수 있다. 나타나는 논리 흐름은, 명확히 언급되지 않는 한, 제시되는 순서로, 또는 임의의 특정 순서로 실행될 필요가 없다. 덧붙여, 논리 흐름과 관련하여 기재된 다양한 활동이 순차적으로 또는 병렬로 실행될 수 있다. 논리 흐름은, 설계 및 수행 제약사항의 특정 세트에 대해 원하는 대로, 기재된 실시예의 하나 이상의 하드웨어 요소 및/또는 소프트웨어 요소 또는 대안적 요소를 이용해 구현될 수 있다. 예를 들어, 논리 흐름은 로직 장치(가령, 범용 또는 특수 컴퓨터)에 의해 실행되기 위한 로직(가령, 컴퓨터 프로그램 명령)으로서 구현될 수 있다.

도 5는 논리 흐름(500)의 일 실시예를 도시한다. 상기 논리 흐름(500)은 하나 이상의 실시예에 따라 수행되는 동작을 도시할 수 있다. 예를 들어, 상기 논리 흐름(500)은 웹 클라이언트(430) 및/또는 서버 애플리케이션(410)에 의해 수행되는 동작을 도시할 수 있다.

상기 논리 흐름(500) 중, 블록(502)에서 사용자는 클라이언트 측 사용자 인터페이스에서 실행되는 웹 클라이언트와 상호대화한다. 예를 들어, 웹 클라이언트(430)는 렌더링 엔진(438)에 의해 표현(present)될 때 사용자 인터페이스의 하나 이상의 사용자 인터페이스 요소에 영향을 미치는 입력 장치로부터 수신된 하나 이상의 제어 지시(control directive)의 형태로 된 사용자 입력을 수신할 수 있다. 상기 사용자 입력은 사용자 이벤트를 야기하는 사용자 인터페이스 요소와 상호대화할 수 있다. 예를 들어, 사용자는 GUI 스크린에 표현되는 폼 상에서 하나의 필드를 선택하고 상기 필드에 대한 값을 수정할 수 있다.

논리 흐름(500) 중, 블록(504)에서, 클라이언트 상에서 실행 중인 클라이언트 어댑터가 서버 상에서 실행되는 서버 애플리케이션과 호환 가능한 방식으로 사용자 이벤트를 나타내는 제어 지시를 해석(interpret)할 수 있다. 예를 들어, 웹 클라이언트(430)에 의해 실행되는 클라이언트 어댑터(432)는 사용자 이벤트를 서버 애플리케이션(410)과 유사한 방식으로 해석할 수 있다. 사용자 이벤트는 웹 클라이언트(430) 상에서 실행 중인 사용자 인터페이스와의 하나 이상의 사용자 상호대화, 가령, 비-제한적 예를 들면, 버튼 클릭하기, 텍스트 필드 채우기 등을 포함할 수 있다.

논리 흐름(500) 중, 블록(504)에서의 해석 동작은 새로 입력된 사용자 이벤트 속성을 검사하여, 서버 애플리케이션이 알 필요가 있는 범위까지 다이아몬드(506)에서, 사용자 이벤트 속성이 변경됐는지 여부를 결정할 수 있다. 예를 들어, 클라이언트 어댑터(432)는 임의의 사용자 입력 및 이에 대응하는 영향 받은 사용자 인터페이스 요소의 속성의 변경을 검사하여, 사용자 이벤트 속성이 일부 임계치보다 크게 변경됐는지 여부를 결정할 수 있다. 예를 들어, 필드를 선명하게 만들기 위해 상기 필드 위에서 호버링하는 것은 사용자 이벤트 속성의 어떠한 변경을 트리거하기엔 불충분할 수 있으며, 반면에, 필드를 선택하는 것은 서버 애플리케이션(410)에게 통지하기에 충분할 것이다.

논리 흐름(500) 중, 통지가 필요한 경우, 블록(508)에서 클라이언트 어댑터는 임의의 계류 중인 변경된 사용자 이벤트 속성을 서버 애플리케이션에게 전송할 수 있다. 예를 들어, 클라이언트 어댑터(432)는 사용자 이벤트 속성(451)을 메시지(450)로 네트워크(250)를 통해 서버 애플리케이션(410)에게 전송할 수 있다. 일부 실시예에서, 클라이언트 어댑터(432)는 복수의 사용자 이벤트에 대해 변경된 사용자 이벤트 속성(451)의 복수의 세트를 메시지(450)로 서버(402) 상에서 실행 중인 서버 애플리케이션(410)에게 전송할 수 있다. 이러한 "배치(batch)" 전송은 많은 점에서 유용할 수 있는데, 가령, 사용자 이벤트 타이밍 설정 시 서버 애플리케이션(410)을 보조한다. 예를 들어, 스크립트 인터프리터(414)는 서버 애플리케이션(410)으로의 업데이트의 정확한 시퀀스를 보장하기 위해, 다양한 스크립트(가령, 프리-스크립트, 변경 스크립트, 포스트-스크립트 등)의 실행의 타이밍을 설정할 수 있다. 또한 배치 전송은 네트워크(250)를 통해 더 적은 메시지(450)를 전송함으로써 통신 오버헤드를 감소시킬 수 있다. 그 밖의 다른 이점도 존재하며, 이 맥락에서 실시예는 제한되지 않는다.

논리 흐름(500) 중, 블록(512)에서 비즈니스 로직 이벤트가 실행되기 전에, 블록(510)에서 서버 상에서 실행 중인 런타임 엔진이 서버 애플리케이션에 대한 적절한 입력/상태를 보장할 수 있다. 예를 들어, 서버(402) 상에서 실행 중인 해석 런타임 엔진(412)이, 임의의 애플리케이션 또는 비즈니스 로직을 실행하기 전에, 서버 애플리케이션(410)에 대해 적절한 애플리케이션 입력 및 애플리케이션 상태를 보장할 수 있다.

논리 흐름(500) 중, 블록(514)에서, 비즈니스 로직의 실행으로부터 야기된 업데이트된 사용자 이벤트 속성은 GUI 독립적 객체와 함께 클라이언트 어댑터로 다시 되전송될 수 있다. 예를 들어, 애플리케이션 또는 비즈니스 로직의 실행으로부터 야기된 업데이트된 사용자 이벤트 속성(454)은 GUI 독립적 객체(452)와 함께 서버 애플리케이션(410)으로부터 웹 클라이언트(430)로 전송되어 클라이언트 어댑터(432)로 다시 되전송되게 할 수 있다.

논리 흐름(500) 중, 그 후 클라이언트 어댑터는 업데이트된 사용자 이벤트 속성 및 GUI 독립적 객체를 이용해 블록(516)에서 클라이언트 사용자 인터페이스에 이전에 렌더링된 이미지를 업데이트할 수 있다. 예를 들어, 클라이언트 어댑터(432)는 GUI 독립적 객체(452)를 수신하고 렌더링 엔진(438)은 업데이트된 이벤트 속성(454) 및 GUI 독립적 객체(452)를 이용해 클라이언트 사용자 인터페이스에 이전에 렌더링된 이미지를 업데이트할 수 있다.

도 6a는 서버 애플리케이션(410)으로부터의 데이터를 이용해 클라이언트 어댑터(432)에 대해 GUI 독립적 객체(452)가 생성될 수 있는 방식에 대한 일 실시예를 도시한다. 앞서 기재된 바와 같이, 클라이언트 어댑터(432)는 업데이트된 사용자 이벤트 속성(454)을 갖는 GUI 독립적 객체(452)를 수신할 수 있다. 업데이트된 사용자 이벤트 속성(454)은 GUI 독립적 객체 메타데이터(602) 및 그 밖의 다른 정보를 포함할 수 있다. 일 실시예에서, GUI 독립적 객체 메타데이터(602)는 고정적(fixed) 또는 정적(static) 메타데이터를 포함할 수 있다. 업데이트된 사용자 이벤트 속성(454)은 속성/값 집합(property/value collection)(604)을 더 포함할 수 있다. 고정적/정적 GUI 독립적 객체 메타데이터(602)가 GUI 독립적 속성/값 집합(604)과 조합되어, 클라이언트 어댑터(432)에 의해 웹 클라이언트(430)에 렌더링될 수 있는 GUI 독립적 객체(606)를 산출할 수 있다.

도 6b는 도 6a에 제공된 구성을 이용해 특정 GUI 독립적 객체(452)가 생성될 수 있는 방식에 대한 일 실시예를 도시한다. 업데이트된 사용자 이벤트 속성(454)은 객체 메타데이터(612), 속성/값 집합(614), 및 그 밖의 다른 정보를 포함할 수 있다.

업데이트된 사용자 이벤트 속성(454)은 하나 이상의 인터페이스 요소를 갖는 객체 메타데이터(612)를 포함할 수 있다. 이러한 예에서, 객체 메타데이터(612)는 필드의 형태를 가지며, 필드 A, 필드 B, 및 필드 C로 라벨링된 3개의 사용자 인터페이스 요소를 포함한다. 필드 A, B, 및 C 각각은 일반적으로 구절 '필드 A', '필드 B', 및 '필드 C' 각각으로 구성된 디폴트 폰트 텍스트를 감싸는 테두리를 갖는 텍스트 박스로서 나타난다.

업데이트된 사용자 이벤트 속성(454)은 속성/값 집합(614)을 더 포함할 수 있다. 일 실시예에서, 속성/값 집합(614)은 데이터 구조, 가령, 하나 이상의 튜플(tuple)(또는 행)을 갖는 테이블로 구현될 수 있으며, 이때 각각의 튜플은 사용자 인터페이스 요소에 대한 식별자, 사용자 인터페이스 요소에 대한 속성(property), 및 상기 속성에 대한 값을 포함하는 속성(attribute)(또는 열)을 포함한다. 식별자, 속성 및 값의 테이블은 객체 메타데이터(612)의 필드에 대응할 수 있다.

함께 조합될 때 결과는 GUI 독립적 객체(616)일 수 있다. GUI 독립적 객체(616)에 도시된 것처럼, 필드 A는 일반적 메타데이터 버전으로부터 변경되지 않는데, 이의 속성 또는 값 중 어느 것도 속성/값 집합(614)에서 변경되지 않았기 때문이다. 속성/값 집합(614)에서 속성 '테두리'가 값 '거짓'으로 설정되었기 때문에 필드 B는 자신의 테두리 없이 나타난다. 속성/값 집합(614)에서 속성 '볼드(bold)체'가 값 '참'으로 설정되었기 때문에, 필드 C의 텍스트는 볼드체로 나타난다. 이제, 클라이언트 어댑터(432)의 렌더링 엔진(438)에 의해 객체(616)가 웹 클라이언트(430) 내 클라이언트(404) 상에서 렌더링될 수 있다.

도 7은 논리 흐름(700)의 일 실시예를 도시한다. 상기 논리 흐름(700)은 하나 이상의 실시예에 따라 수행되는 동작을 도시할 수 있다. 예를 들어, 논리 흐름(700)은 파괴됐던 클라이언트 어댑터(432)를 복원하기 위한 목적으로 웹 클라이언트(430) 및/또는 서버 애플리케이션(410)에 의해 수행되는 동작을 도시할 수 있다.

본원에 기재된 실시예의 또 다른 이점은 클라이언트 어댑터(432)가 파괴되는 경우 특정 클라이언트(404)에 렌더링되는 이미지가 복원될 수 있다는 것이다. 클라이언트 어댑터(432)가 파괴되는 경우, 다양한 GUI 종속적 객체(452)로 구성된 렌더링된 이미지도 역시 파괴된다. 그러나 서버 애플리케이션(410)은 GUI 독립적 객체(452)의 형태로 상태를 계속 보유할 수 있다. 도 7에 도시된 것처럼, 블록(702)에서 사용자는 클라이언트 측 사용자 인터페이스에서 실행 중인 웹 클라이언트(430)와 상호대화하여 클라이언트 어댑터(432)의 새로운 인스턴스를 생성할 수 있다. 그 후 블록(704)에서 상기 클라이언트 어댑터(432)의 새로운 인스턴스는 서버 애플리케이션(410)으로 재-연결될 수 있다. 재-연결 후, 서버 애플리케이션(410)은 모든 GUI 독립적 객체(452)에 대해 마지막으로 알려진 상태를 여전히 유지할 수 있다. 블록(706)에서, 모든 GUI 독립적 객체(452)에 대해 마지막으로 알려진 상태가 클라이언트(404)에게 다시 되전송되고 상기 클라이언트(404)에 의해 수신된다. 그 후 블록(708)에서 모든 GUI 독립적 객체(452)에 대해 마지막으로 알려진 상태가 클라이언트(404)의 웹 클라이언트(430)와 동기화될 수 있다. 결과적으로, 클라이언트 어댑터(432)에 대한 현재 상태가 서버 애플리케이션(410)에 의해 저장된 정보를 이용해 효과적으로 복원될 수 있다.

지금까지의 개시 내용은 사용자 인터페이스 뷰, 가령, Microsoft Windows® 폼(Form) 또는 Microsoft Silverlight® UI 인터페이스 등으로서 렌더링될 수 있는 GUI 독립적 객체(452)를 생성하기 위해, 렌더링 엔진(438)이 해석 런타임 엔진(412)으로부터 연결해제(decouple)되는 방식을 기재한 것이다. 이하의 기재는 GUI 독립적 객체(452)가 사용자 인터페이스 뷰, 가령, Microsoft Windows 폼 또는 Microsoft Silverlight UI의 렌더링된 이미지로 변환될 수 있는 방식에 초점이 맞춰진다.

일 실시예에 따라, 시스템(400)은 본래의 메타데이터 코드를 마스터 코드 베이스(master code base)로서 유지하면서 해석 런타임 엔진(412)에 의해 생성된 GUI 독립적 객체 메타데이터(602)를 사용자 인터페이스 템플릿(user interface template)으로 변환할 수 있다. GUI 독립적 객체(452)는 렌더링과 이벤트 메타데이터 모두를 포함한다. 앞서 기재된 바와 같이, GUI 독립적 객체(452)는 해석 런타임 엔진(412)으로부터 직접 생성되거나 GUI 독립적 객체(452)와 관련된 세부사항을 제공할 수 있는 객체 모델로부터 생성될 수 있다.

렌더링 엔진(438)이 클라이언트(404) 상의 사용자 인터페이스를 최종 사용자에게 제공하도록 역할하는 동안 해석 런타임 엔진(412)의 일부분인 사용자 인터페이스 관리자(418)가 여전히 UI 이벤트를 처리하도록 역할함을 주지해야 한다. 해석 런타임 엔진(412)은 이들 작업을 주로 수행하는 것으로부터 해방되었기 때문에, 최종 GUI 독립적 객체(452)가 클라이언트 어댑터(432)에 의해 처리되어 인터페이스들 중 어느 하나를 생성할 수 있다. 이는 예를 들어 템플릿 프로세서의 구현을 통해 이뤄질 수 있다.

다양한 실시예에서, 템플릿 프로세서는 GUI 스크린의 일반적인 표현을 취하고, GUI 스크린 템플릿으로서 알려질 수 있는 이의 콘텐츠(가령, 필드, 버튼, 및 이벤트)의 XML(extensible markup language) 버전을 적용할 수 있다. 덧붙여, 템플릿 프로세서는 해석 런타임 엔진(412)이 적어도 스크린에 대한 어떠한 GUI 템플릿도 없는 경우 베이스 변환(base conversion)을 하는 전통적 클라이언트에서 디스플레이할 수 있는 베이스 템플릿으로 알려진 버전을 적용시킬 수 있다. 상기 GUI 스크린 및 베이스 템플릿은 메타데이터 및 GUI 스크린 레이아웃을 나타내는 콘텐츠를 포함한다. 상기 GUI 스크린 템플릿은 베이스 템플릿과 관련되지만 상기 베이스 템플릿의 커스텀화된 버전이다.

템플릿은 기존 GUI 독립적 객체의 레이아웃을 변경시키도록 설계될 수 있다. 앞서 제시된 예를 들면, 두 유형의 템플릿, 즉, 베이스 템플릿과 GUI 스크린 템플릿이 존재할 수 있다. 다양한 구현예가 필요에 따라 여러 다른 템플릿을 사용할 수 있음을 알 수 있다.

제 1 템플릿이 베이스 템플릿이라고 일컬어질 수 있다. 많은 경우, 수 천 개의 GUI 스크린이 존재할 수 있고, 각각에 대해 하나의 템플릿(즉, 새로운 레이아웃)을 개발하고 적용하는 데 상당한 시간과 노력을 소비할 수 있다. 그러나 베이스 템플릿은 각각의 GUI 스크린에 대해 새로운 템플릿 레이아웃을 생성할 필요없이, 베이스 변환(base conversion)을 적용할 수 있다. 오히려 하나의 새로운 레이아웃 GUI 스크린을 생성하기 위해 변환 로직을 적용할 수 있다. 상기 베이스 템플릿은 하나의 GUI 스크린을 출력할 수 있으며, 일반적으로 복수의 GUI 스크린을 하나로 결합하도록 설계된 것이 아니다.

제 2 템플릿이 GUI 스크린 템플릿이라고 일컬어질 수 있다. GUI 스크린 템플릿은 특정 GUI 스크린에 대한 템플릿을 포함할 수 있다. GUI 스크린 템플릿 레이아웃은 헤더(header) 섹션과 콘텐츠(content) 섹션 모두에 대한 베이스 템플릿 레이아웃을 무효화(over-ride)할 수 있다. 무효화된 콘텐츠 레이아웃은 격자(grid) 레이아웃처럼 표형식(tabular)이거나, 및/또는 아코디언 레이아웃(accordion layout)처럼 그룹화된 것일 수 있다. 새로운 레이아웃은 XML 파일로 정의될 수 있다. GUI 스크린 템플릿 레이아웃이 복수의 GUI 스크린을 하나로 결합시킬 수 있고, 자신이 변경 중인 GUI 스크린에 특정될 수 있다.

본원에서 사용될 때 용어 "GUI 스크린"은 디스플레이의 표현 필드 또는 디스플레이 영역의 일부 또는 모두를 소비하도록 설계된 사용자 인터페이스 요소를 일컬을 수 있다. 예를 들어, 일부 사용자 인터페이스 요소는 디스플레이 상의 디스플레이의 일부분 또는 서브섹션, 가령, 테두리, 박스, 또는 그 밖의 다른 상업 종목 형태의 사용자 인터페이스 요소로 둘러진 부분만 소비하도록 설계된다. 일부 경우, GUI 스크린은 사용자가 디스플레이의 표현 필드 주변에서 GUI 스크린을 확대, 축소 또는 이동시킬 수 있게 하거나 디스플레이의 표현 필드로부터 완전히 GUI 스크린을 삭제할 수 있게 하는 UI 컨트롤의 세트를 가질 수 있다. GUI 스크린의 예시는 사용자 인터페이스 요소, 가령, Microsoft Windows 또는 Microsoft Window Form 사용자 인터페이스 애플리케이션, 및 그 밖의 다른 애플리케이션 및 운영 체제에 의해 생성된 GUI "상업 종목(window)"를 포함할 수 있다.

템플릿 프로세서는 상기에서 기재된 템플릿 등을 적용하여 GUI 스크린 레이아웃 상의 세부사항을 포함하는 커스텀화된 버전의 GUI 독립적 객체(452)를 생성할 수 있다. 상기 렌더링 엔진(438)은 UI 변환 로직과 함게 새로운 커스텀화된 버전의 GUI 독립적 객체(452)를 수신할 수 있고, 최종 사용자에게 표현되기 위해 클라이언트(404)에 대한 새로운 커스텀화된 GUI 뷰(가령, GUI 창)를 생성할 수 있다. 렌더링 엔진(438)은 GUI 객체 속성을 GUI 컨트롤 및 속성과 매핑(가령, 헤더 -> 리본)시킬 수 있고, 클라이언트(404)가 원하는 특정 GUI 컨트롤 및 레이아웃을 생성할 수 있다.

도 8a는 일 실시예에 따라 GUI 객체 레이아웃을 나타내는 템플릿을 처리하기 위한 템플릿 처리 시스템(800)의 블록도를 도시한다. 일 실시예에서, 상기 템플릿 처리 시스템(800)은 서버(802)에 대한 서버 애플리케이션(810)의 일부분으로서 구현될 수 있다. 상기 서버 애플리케이션(810) 및 서버(802)는, 예를 들어, 도 4를 참조하여 기재된 각각의 서버 애플리케이션(410) 및 서버(402)를 나타낼 수 있다. 그러나 템플릿 처리 시스템(800)은 n-티어 클라이언트-서버 아키텍처의 그 밖의 다양한 부분, 가령, 클라이언트(804)의 클라이언트 애플리케이션(830)으로서 구현될 수도 있다.

일 실시예에서, 클라이언트 애플리케이션(830)은 가령 도 4를 참조하여 기재된 클라이언트(404)의 웹 클라이언트(430) 및/또는 클라이언트 어댑터(432)를 나타낼 수 있다. 이에 추가로 또는 이를 대체하여, 클라이언트 애플리케이션(830)은 클라이언트 애플리케이션(430)과 상이한 클라이언트 애플리케이션, 가령, 원시(native) 또는 데스크톱 버전의 서버 애플리케이션(810)으로서 구현될 수 있다. 그 밖의 다른 클라이언트 애플리케이션도 구현될 수 있다. 실시예는 이러한 맥락으로 제한되지 않는다.

앞서 도 4를 참조하여 기재된 바와 같이, 변경된 사용자 이벤트 속성(451)을 갖는 메시지(450)는 서버 애플리케이션(430)으로 전송될 수 있다. 그 후 서버 애플리케이션(410)의 해석 런타임 엔진(412)은 변경된 사용자 이벤트 속성(451)을 처리하여 GUI 독립적 객체(452)를 생성할 수 있다.

도 8a에 도시된 실시예에서, GUI 독립적 객체(812)를 생성하기 위해 클라이언트(804)의 클라이언트 애플리케이션(830)이 사용자 인터페이스 관리자(806)를 통해 해석 런타임 엔진(850)으로 포워드할 수 있는 사용자 이벤트(804)에 의해 유사한 프로세스가 표현될 수 있다. 그러나 이때, GUI 독립적 객체(812)는 임시(interim) GUI 독립적 객체이며, 클라이언트 애플리케이션(830)에 의해 표현될 준비가 안 되어 있다. 특정 클라이언트 애플리케이션(830)에 의해 사용되도록 GUI 독립적 객체(812)를 정제(refine)하기 위해, 상기 GUI 독립적 객체(812)는 추가 처리되도록 템플릿 프로세서(814)로 포워드될 수 있다. 그 후, 상기 템플릿 프로세서(814)는 GUI 독립적 객체(812)로부터의 베이스 템플릿(816) 및 GUI 스크린 템플릿(818)을 적용할 수 있다.

베이스 템플릿(816)은 각각의 GUI 스크린에 대해 새로운 템플릿 레이아웃을 생성할 필요 없이 베이스 변환을 적용할 수 있다. 상기 베이스 템플릿(816)은 변환 로직을 적용하여, GUI 뷰(811)로서 나타난 하나의 새로운 레이아웃을 생성할 수 있다. 이 실시예에서, GUI 뷰(811)는 복수의 GUI 스크린을 하나로 결합시키도록 설계되지 않는다.

상기 GUI 스크린 템플릿 레이아웃은 헤더(header)와 콘텐츠(content) 섹션 모두에 대해 상기 베이스 템플릿(816)의 베이스 템플릿 레이아웃을 무효화할 수 있다. 무효화된 콘텐츠 레이아웃은 격자 레이아웃처럼 표 형식(tabular)이거나, 및/또는 아코디언 레이아웃(accordion layout)처럼 그룹화된 것일 수 있다. 일 실시예에서, 새로운 레이아웃은 XML 파일, 그 밖의 다른 적합한 웹-관련 레이아웃 포맷으로 정의될 수 있다. 상기 GUI 스크린 템플릿 레이아웃이 복수의 GUI 스크린을 하나로 결합시킬 수 있고, 변경 중인 GUI 스크린에 특정될 수 있다.

그 후 상기 템플릿 프로세서(814)는 앞서 기재된 템플릿(816, 818)을 적용시켜 상기 GUI 스크린 레이아웃 상의 상세사항을 포함하는 새롭고 고도로 커스텀화된 GUI 독립적 객체(820)를 생성할 수 있다. 새로운 GUI 독립적 객체(820)는 GUI 독립적 객체(812)에 대한 더 특정적 구현을 포함할 수 있고, 이는 도 3, 4를 참조하여 기재된 GUI 독립적 객체(360, 452)를 나타낸 것이다. 생기 새로운 GUI 독립적 객체(820)는 서버 애플리케이션(810)으로부터 클라이언트(804) 상에서 실행 중인 클라이언트 애플리케이션(830)의 렌더링 엔진(822)으로 반환된다.

렌더링 엔진(822)은 새로운 GUI 독립적 객체(820)를 수신하고, 최종 사용자에 대해 커스텀화된 새로운 GUI 뷰(824)를 생성하도록 설계된 UI 변환 로직을 실행시킨다. 상기 렌더링 엔진(822)은 GUI 객체 속성을 GUI 컨트롤 및 속성과 매핑시키고(가령, 헤더 -> 리본), 클라이언트 애플리케이션이 원하는 특정 GUI 컨트롤 및 레이아웃을 생성할 수 있다.

도 8b, 8c는 각각의 GUI 뷰(811, 824)에 대한 더 상세한 도시를 제공한다. 예를 들어, 베이스 템플릿을 나타내는 GUI 스크린은 도 8b의 GUI 뷰(811)에서 나타날 수 있고, GUI 스크린 템플릿으로부터 도출된 GUI 스크린은 도 8c의 GUI 뷰(824)에서 나타날 수 있다.

도 8b, 8c에서 도시된 실시예에서, 베이스 템플릿(816)으로부터 구성된 GUI 뷰(811)(도 8b)는 스크린 템플릿(818)으로부터 구성된 GUI 뷰(824)(도 8c)와 상이 하지만 유사하게 나타날 수 있다. 스크린 템플릿(818)은 베이스 템플릿(816)을 대체할 것임을 주지해야 한다. 즉, 베이스 템플릿(816)이 먼저 적용될 수 있고, 그 후 스크린 템플릿(818)이 적용되어 상기 베이스 템플릿(816)을 커스텀화할 수 있다. 도 8b(베이스 템플릿 도시) 및 도 8c(스크린 템플릿 도시)의 도시된 예시에서, 버튼 및 필드 박스 중 다수가 재배열되었다. 예를 들어, 베이스 템플릿(816)으로부터 구성된 GUI 뷰(811)의 하단 좌측 버튼이 스크린 템플릿(818)으로부터 구성된 GUI 뷰(824)의 상단 좌측 부분 상의 메뉴 바에 재배치되었다. GUI 뷰(811)(도 8b) 및 (824)(도 8c) 모두 리본 UI 표현(926)을 도시한다. 리본은 기능별로 구성된 메뉴 및 버튼의 그룹을 포함하는 큰 툴바이다. 각각의 리본은 기능적으로 하나씩의 탭과 연관된다. 도 8c의 GUI 뷰(824)를 참조하면, 탭은 "제조사(Vendor)"이다. 덧붙여, 제조사 탭에 대한 레이아웃이 2개의 섹션으로 배열되었다. 섹션 1은 "일반(General)"(828)으로 라벨링되고 섹션 2는 "주소(Address)"(860)로 라벨링된다. 이는 도 8b의 GUI 뷰(811)와, GUI 뷰(824)의 탭(주소(Address), 계정(Account), 옵션(Option), 이메일(Email), 원천징수(Withholding))이 GUI 뷰(811)의 버튼(옵션(Option), 주소(Address), 계정(Account), 이메일(Email))을 대체한다는 점에서 상이하다. GUI 뷰(811)와 (824) 사이에 그 밖의 다른 수정 및 변형이 이뤄졌고, 이뤄질 수 있음이 자명할 수 있다. 이러한 방식으로 템플릿 처리 시스템(800)은 서로 다른 클라이언트 어댑터(가령, 클라이언트 어댑터(232, 242))를 구현하는 서로 다른 웹 클라이언트(가령, 웹 클라이언트(230, 240))에 대해 커스텀화된 GUI 뷰를 제공할 수 있으며, 이때 커스텀화된 GUI 뷰가 서버 애플리케이션(가령, 410, 810)에 의해 제공되는 원시 GUI 뷰로부터 얻어진다.

도 9는 논리 흐름(900)을 도시한다. 상기 논리 흐름(900)은 하나 이상의 실시예에 따라 수행되는 동작을 도시할 수 있다. 예를 들어, 논리 흐름(900)은 도 8에 도시된 서버 애플리케이션(810) 및/또는 클라이언트 애플리케이션(830)에 의해 수행되는 동작을 도시할 수 있다. 이에 추가로 또는 이를 대체하여, 논리 흐름(900)은 도 4에 도시된 바와 같이 서버 애플리케이션(410) 및/또는 웹 클라이언트(430)에 의해 수행되는 동작을 도시할 수 있다. 상기 실시예는 이러한 맥락에서 제한되지 않는다.

논리 흐름(900)에서, 사용자는 사용자 이벤트를 입력하기 위해 클라이언트 측 사용자 인터페이스에서 실행되는 웹 클라이언트와 상호대화한다. 블록(902, 904, 및 906)은 도 5에서 더 완전히 기재된 논리 프로세스의 간략한 표현을 나타낸다.

논리 흐름(900)에서, 블록(906)에서의 런타임 엔진에 의한 GUI 독립적 객체의 생성 후, 블록(908)에서 상기 GUI 독립적 객체는 템플릿 프로세서로 포워드될 수 있다. 예를 들어, GUI 독립적 객체(812)는 클라이언트 애플리케이션(830)에 의해 추가 처리를 위해 서버 애플리케이션(810) 내에서 실행 중인 템플릿 프로세서(814)로 포워드될 수 있다.

논리 흐름(900)에서, 템플릿 프로세서는 생성된 베이스 템플릿 및 스크린 템플릿을 적용하여, 블록(912)에서 새로운 GUI 객체를 생성할 수 있다. 예를 들어, 템플릿 프로세서(814)는 생성된 베이스 템플릿(816) 및 스크린 템플릿(818)을 적용하여 커스텀화된 새로운 GUI 독립적 객체(820)를 생성할 수 있다.

논리 흐름(900)에서, 블록(914)에서 새로운 GUI 독립적 객체는 클라이언트로 다시 되전송될 수 있다. 예를 들어, 커스텀화된 새로운 GUI 독립적 객체(820)는 (네트워크(250))를 통해 클라이언트 애플리케이션(830)으로 다시 되전송될 수 있고, 여기서 추가 처리되도록 렌더링 엔진(822)으로 포워드될 수 있다.

논리 흐름(900)에서, 블록(916)에서 렌더링 엔진은 GUI 객체를 변환할 수 있고, 새로운 GUI 스크린을 생성할 수 있다. 예를 들어, 렌더링 엔진(822)은 GUI 독립적 객체(820)를 변환할 수 있고, 클라이언트 애플리케이션(830)(또는 클라이언트 어댑터 또는 클라이언트 OS)에 의해 렌더링된 커스텀화된 GUI 뷰(824)를 생성할 수 있다.

도 10은 이전에 기재된 바와 같은 다양한 실시예를 구현하기에 적합한 예시적 컴퓨팅 아키텍처(1000)의 일 실시예를 도시한다. 상기 컴퓨팅 아키텍처(1000)는 다양한 공통 컴퓨팅 요소, 가령, 하나 이상의 프로세서, 코-프로세서(co-processor), 메모리 유닛, 칩셋(chipset), 제어기, 주변장치, 인터페이스, 오실레이터(oscillator), 타이밍 장치(timing device), 비디오 카드, 오디오 카드, 멀티미디어 입/출력(I/O) 구성요소 등을 포함한다. 그러나 실시예는 상기 컴퓨팅 아키텍처(1000)에 의한 구현예로 한정되지 않는다.

도 10에 도시된 바와 같이, 컴퓨팅 아키텍처(1000)는 처리 유닛(1004), 시스템 메모리(1006) 및 시스템 버스(1008)를 포함한다. 상기 처리 유닛(1004)은 다양한 상용화된 프로세서들 중 임의의 것일 수 있다. 듀얼 마이크로프로세서 및 그 밖의 다른 멀티-프로세서 아키텍처가 또한 처리 유닛(1004)으로서 채용될 수 있다. 상기 시스템 버스(1008)는 시스템 구성요소, 비-제한적 예를 들면, 시스템 메모리(1006)에 대한 인터페이스를 처리 유닛(804)에게 제공한다. 상기 시스템 버스(1008)는 다양한 상용화된 버스 아키텍처 중 임의의 것을 이용해 메모리 버스(메모리 제어기를 포함하거나 포함하지 않음), 주변장치 버스, 및 로컬 버스로 추가로 인터커넥트될 수 있는 몇 가지 유형의 버스 구조 중 임의의 것일 수 있다.

시스템 메모리(1006)는 다양한 유형의 메모리 유닛, 가령, 리드 온리 메모리(ROM: read only memory), 랜덤 액세스 메모리(RAM: random-access memory, 동적 RAM(DRAM: dynamic RAM), 더블 데이터율 DRAM(DDRAM: Double-Data-Rate DRAM), 정적 RAM(SRAM: static RAM), 프로그램 가능한 ROM(PROM: programmable ROM), 소거 가능하고 프로그램 가능한 ROM(EPROM: erasable programmable ROM), 전기적으로 소거 가능하고 프로그램 가능한 ROM(EEPROM: electrically erasable programmable ROM), 플래시 메모리, 폴리머 메모리, 가령, 강유전체 폴리머 메모리(ferroelectric polymer memory), 오보닉 메모리(ovonic memory), 상 변화 또는 강유전체 메모리, 실리콘-옥사이드-니트라이드-옥사이드-실리콘(SONOS) 메모리, 자성 또는 광학 카드, 또는 정보를 저장하기에 적합한 그 밖의 다른 임의의 유형의 매체를 포함할 수 있다. 도 10에 도시된 실시예에서, 시스템 메모리(1006)는 비휘발성 메모리(1010) 및/또는 휘발성 메모리(1012)를 포함할 수 있다. 기본 입/출력 시스템(BIOS: basic input/output system)이 비휘발성 메모리(1010)에 저장될 수 있다.

컴퓨터(1002)는 다양한 유형의 컴퓨터 판독형 저장 매체, 가령, 내부 하드 디스크 드라이브(HDD: hard disk drive)(1014), 이동식 자기 디스크(1018)로부터 읽거나 쓰기 위해 자기 플로피 디스크 드라이브(FDD: floppy disk drive)(1016), 및 이동식 광학 디스크(1022)(가령, CD-ROM, 또는 DVD)로부터 읽거나 쓰기 위해 광학 디스크 드라이브(1020)를 포함할 수 있다. HDD(1014), FDD(1016) 및 광학 디스크 드라이브(1020)는, 각각 HDD 인터페이스(1024), FDD 인터페이스(1026) 및 광학 드라이브 인터페이스(1028)를 통해 시스템 버스(1008)로 연결될 수 있다. 외부 드라이브 구현을 위한 상기 HDD 인터페이스(1024)는 전역 직렬 버스(USB: Universal Serial Bus) 및 IEEE 1394 인터페이스 기법 중 적어도 하나 또는 둘 모두를 포함할 수 있다.

드라이브 및 이와 연관된 컴퓨터-판독형 매체는 데이터, 데이터 구조, 컴퓨터-실행형 명령 등의 휘발성 및/또는 비휘발성 저장을 제공한다. 예를 들어, 복수의 프로그램 모듈은 드라이브 및 메모리 유닛(1010, 1012), 가령, 운영 체제(1030), 하나 이상의 애플리케이션 프로그램(1032), 그 밖의 다른 프로그램 모듈(1034), 및 프로그램 데이터(1036)에 저장될 수 있다. 하나 이상의 애플리케이션 프로그램(1032), 그 밖의 다른 프로그램 모듈(1034), 및 프로그램 데이터(1036)는, 예를 들어, 클라이언트-서버 시스템(200, 300 및 400)을 위한 소프트웨어 구성요소를 포함할 수 있다.

사용자는 하나 이상의 유/무선 입력 장치, 예를 들어, 키보드(10310) 및 포인팅 장치, 가령 마우스(1040)를 통해 명령어 및 정보를 컴퓨터(1002)로 입력할 수 있다. 또 다른 입력 장치는 마이크로폰, 적외선(IR) 원격 제어, 조이스틱, 게임 패드, 스타일러스 펜, 터치 스크린 등을 포함할 수 있다. 이들 그리고 그 밖의 다른 입력 장치는 종종, 시스템 버스(10010)로 연결된 입력 장치 인터페이스(1042)를 통해 처리 유닛(1004)으로 연결되지만, 그 밖의 다른 인터페이스, 가령, 병렬 포트, IEEE 1394 직렬 포트, 게임 포트, USB 포트, IR 인터페이스 등에 의해 연결될 수 있다.

또한 하나 이상의 모니터(1044) 또는 그 밖의 다른 유형의 디스플레이 장치가 인터페이스, 가령, 비디오 어댑터(1046)를 통해 시스템 버스(1008)로 연결된다. 모니터(1044)에 추가로, 일반적으로 컴퓨터는 그 밖의 다른 주변 출력 장치, 가령, 스피커, 프린터 등을 포함한다. 또한 하나 이상의 모니터(1045)는 입력 장치 인터페이스(1042) 및/또는 허브, 가령, USB 허브(1043)를 통해 시스템 버스(1008)로 연결될 수 있다. 모니터(1045)는 다양한 구성요소, 가령, 비디오 카메라, 어레이 마이크로폰, 터치 센서, 모션 센서, 스피커, 등을 포함할 수 있다. 구성요소는 USB 허브(1043)를 통해 입력 장치 인터페이스(1042)로 연결될 수 있다.

컴퓨터(1002)는 유선 및/또는 무선 통신을 통한 하나 이상의 원격 컴퓨터, 가령, 원격 컴퓨터(10410)로의 논리적 연결을 이용해 네트워크 연결된 환경에서 동작할 수 있다. 상기 원격 컴퓨터(10410)는 워크스테이션, 서버 컴퓨터, 라우터, 개인 컴퓨터, 휴대용 컴퓨터, 마이크로프로세서 기반 엔터테인먼트 기기, 피어 장치(peer device) 또는 그 밖의 다른 공통 네트워크 노드일 수 있으며, 일반적으로 컴퓨터(1002)와 관련하여 기재된 요소들 중 다수 또는 전부를 포함하지만, 간결성을 위해, 메모리/저장 장치(1050)만 도시된다. 도시된 논리적 연결은 로컬 영역 네트워크(LAN)(1052) 및/또는 더 큰 네트워크, 가령, 광역 네트워크(WAN)(1054)로의 유/무선 연결성을 포함한다. 이러한 LAN 및 WAN 네트워크 연결 환경은 사무실 및 회사에서 일반적인 것이며, 기업내 컴퓨터 네트워크, 가령, 인트라넷을 용이하게 하고, 이들 모두 글로벌 통신 네트워크, 가령, 인터넷으로 연결될 수 있다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(1002)는 유선 및/또는 무선 통신 네트워크 인터페이스 또는 어댑터(1056)를 통해 LAN(1052)으로 연결된다. 상기 어댑터(1056)는 LAN(1052)으로의 유선 및/또는 무선 통신을 가능하게 할 수 있으며, 상기 LAN은 어댑터(1056)의 무선 기능과 통신하기 위해 배치된 무선 액세스 포인트를 더 포함할 수 있다.

WAN 네트워킹 환경에서 사용될 때, 컴퓨터(1002)는 모뎀(10510)을 포함할 수 있거나, WAN(1054) 상의 통신 서버로 연결되거나 WAN(1054)을 통해, 가령 인터넷을 이용해 통신을 구축하기 위한 그 밖의 다른 수단을 가진다. 내부 또는 외부의 유선 및/또는 무선 장치일 수 있는 모뎀(10510)이 입력 장치 인터페이스(1042)를 통해 시스템 버스(10010)로 연결된다. 네트워크 연결된 환경에서, 컴퓨터(1002) 또는 이들의 부분에 대하여 도시된 프로그램 모듈이 원격 메모리/저장 장치(1050)에 저장될 수 있다. 도시된 네트워크 연결은 예시적이며, 컴퓨터들 간 통신 링크를 구축하기 위한 또 다른 수단이 사용될 수 있음을 알 것이다.

상기 컴퓨터(1002)는 IEEE 802 표준 패밀리를 이용해 유선 및 무선의 장치 또는 개체, 가령, 무선 통신(가령, IEEE 802.11 오버-더-에어(over-the-air) 변조 기법)으로 동작 가능하게 배치된 무선 장치, 가령, 예를 들어, 프린터, 스캐너, 데스크톱 및/또는 휴대용 컴퓨터, 개인 디지털 어시스턴스(PDA: personal digital assistant), 통신 위성, 무선으로 검출 가능한 태그와 연관된 임의의 시설 또는 장소(가령, 키오스크, 뉴스 스탠드, 화장실), 및 전화기와 통신하도록 동작한다. 이는 적어도 Wi-Fi(즉, Wireless Fidelity), WiMax, 및 Bluetooth™ 무선 기법을 포함한다. 따라서 통신은 종래의 네트워크의 경우와 같은 지정된 구조 또는 단순히 적어도 2개의 장치 간의 애드 호크(ad hoc) 통신일 수 있다. 안전하고, 신뢰할만하며, 고속의 무선 연결성을 제공하기 위해 Wi-Fi 네트워크는 IEEE 802.11x (a, b, g, 등)이라 일컬어지는 라디오 기법을 이용한다. Wi-Fi 네트워크는 컴퓨터들을 서로 연결, 인터넷으로 연결, 그리고 (IEEE 802.3-관련 매체 및 기능을 이용하는) 무선 네트워크로 연결하도록 사용될 수 있다.

도 11는 이전에 기재된 바와 같이 다양한 실시예를 구현하기에 적합한 예시적 통신 아키텍처(1100)의 블록도를 도시한다. 통신 아키텍처(1100)는 다양한 일반적인 통신 요소, 가령, 송신기, 수신기, 트랜시버, 라디오, 네트워크 인터페이스, 기저대역 프로세서, 안테나, 증폭기, 필터 등을 포함한다. 그러나 상기 실시예는 통신 아키텍처(1100)에 의한 구현으로 한정되지 않는다.

도 11에 도시된 바와 같이, 통신 아키텍처(1100)는 하나 이상의 클라이언트(1102) 및 서버(1104)를 포함한다. 상기 클라이언트(1102)는 웹 클라이언트(430)를 구현할 수 있다. 상기 서버(1104)는 해석 런타임 엔진(412)을 구현할 수 있다. 상기 클라이언트(1102) 및 서버(1104)는 각각의 클라이언트(1102) 및 서버(1104)의 로컬 정보, 가령, 쿠키 및/또는 이와 연관된 맥락적 정보(contextual information)를 저장하도록 사용될 수 있는 하나 이상의 각자의 클라이언트 데이터 저장소(1108) 및 서버 데이터 저장소(1110)로 동작 가능하게 연결된다.

클라이언트(1102) 및 서버(1104)는 통신 프레임워크(1106)를 이용해 서로 간에 정보를 통신할 수 있다. 상기 통신 프레임워크(1106)는 임의의 잘 알려진 통신 기법, 가령, 패킷-교환식 네트워크(packet-switched network)(가령, 공중 네트워크, 가령 인터넷, 사설 네트워크, 가령, 기업 인트라넷 등), 회선-교환식 네트워크(circuit-switched network)(가령, 공중 교환 전화망(public switched telephone network)), 또는 패킷-교환식 네트워크와 회로-교환식 네트워크의 조합(적합한 게이트웨이 및 변환기(translator)를 포함)과 함께 사용되기 위한 적합한 기법을 구현할 수 있다. 상기 클라이언트(1102) 및 서버(1104)는 통신 프레임워크(1106)와 상호운용되도록 설계되는 다양한 유형의 표준 통신 요소, 가령, 하나 이상의 통신 인터페이스, 네트워크 인터페이스, 네트워크 인터페이스 카드(NIC: network interface card), 라디오, 무선 송신기/수신기(송수신기), 유선 및/또는 무선 통신 매체, 물리적 연결기 등을 포함할 수 있다. 비-제한적 예를 들면, 통신 매체는 유선 통신 매체와 무선 통신 매체를 포함한다. 유선 통신 매체의 예시로는 전선(wire), 케이블, 금속 도선(metal lead), 인쇄 회로 기판(PCB), 뒤판(backplane), 스위치 패브릭(switch fabric), 반도체 물질, 꼬임쌍 전선(twisted-pair wire), 동축 케이블(co-axial cable), 광섬유, 전파되는 신호 등을 포함할 수 있다. 무선 통신 매체의 예시는 음향, 라디오 주파수(RF) 스펙트럼, 적외선 및 그 밖의 다른 무선 매체를 포함할 수 있다. 클라이언트(1102)와 서버(1104) 간의 한 가지 가능한 통신은 둘 이상의 컴퓨터 프로세스 간에 전송되도록 구성된 데이터 패킷의 형태로 된 것일 수 있다. 데이터 패킷은 가령 쿠키 및/또는 이와 연관된 맥락적 정보를 포함할 수 있다.

하드웨어 요소, 소프트웨어 요소, 또는 이들의 조합을 이용해 다양한 실시예가 구현될 수 있다. 하드웨어 요소의 예시는 장치, 로직 장치, 구성요소, 프로세서, 마이크로프로세서, 회로, 회로 요소(가령, 트랜지스터, 레지스터, 커패시터, 인덕터 등), 집적 회로, 주문형 집적 회로(ASIC: application specific integrated circuit), 프로그램 가능한 로직 장치(PLD: programmable logic device), 디지털 신호 프로세서(DSP: digital signal processor), 현장 프로그램 가능한 게이트 어레이(FPGA: field programmable gate array), 메모리 유닛, 로직 게이트, 레지스터, 반도체 장치, 칩, 마이크로칩, 칩 셋 등을 포함할 수 있다. 소프트웨어 요소의 예시는 소프트웨어 컴포넌트, 프로그램, 애플리케이션, 컴퓨터 프로그램, 애플리케이션 프로그램, 시스템 프로그램, 기계 프로그램, 운영 체제 소프트웨어, 미들웨어, 펌웨어, 소프트웨어 모듈, 루틴, 서브루틴, 함수, 메쏘드, 프로시저, 소프트웨어 인터페이스, 애플리케이션 프로그램 인터페이스(API), 명령 세트(instruction set), 컴퓨팅 코드, 컴퓨터 코드, 코드 세그먼트, 컴퓨터 코드 세그먼트, 워드, 값, 심볼, 또는 이들의 임의의 조합을 포함할 수 있다. 실시예가 하드웨어 요소 및/또는 소프트웨어 요소로 이용해 구현되는지 여부를 결정하는 것은 임의의 개수의 요인들, 가령, 바람직한 계산 속도(computational rate), 파워 레벨, 열 허용오차, 프로세싱 사이클 예산, 입력 데이터 속도, 출력 데이터 속도, 메모리 자원, 데이터 버스 속도 및 그 밖의 다른 설계 또는 성능 제약 사항에 따라, 주어진 구현예에 대해 바람직한 대로 달라질 수 있다.

일부 실시예는 제조 물품을 포함할 수 있다. 제조 물품은 로직을 저장하도록 구성된 컴퓨터-판독형 저장 매체를 포함할 수 있다. 컴퓨터-판독형 저장 매체의 예는 전자 데이터를 저장할 수 있는 임의의 저장 매체, 가령, 휘발성 메모리 또는 비휘발성 메모리, 이동식 또는 비이동식 메모리, 소거식 또는 비소거식 메모리, 쓰기 가능한(writeable) 또는 다시 쓰기 가능한(re-writeable) 메모리 등을 포함할 수 있다. 로직의 예는 다양한 소프트웨어 요소, 가령, 소프트웨어 구성요소, 프로그램, 애플리케이션, 컴퓨터 프로그램, 애플리케이션 프로그램, 시스템 프로그램, 기계 프로그램, 운영 체제 소프트웨어, 미들웨어, 펌웨어, 소프트웨어 모듈, 루틴, 서브루틴, 함수, 메쏘드, 프로시저, 소프트웨어 인터페이스, 애플리케이션 프로그램 인터페이스(API), 명령 세트, 컴퓨팅 코드, 컴퓨터 코드, 코드 세그먼트, 컴퓨터 코드 세그먼트, 워드, 값, 심볼 또는 이들의 임의의 조합을 포함할 수 있다. 일 실시예에서, 예를 들어, 제조 물품은, 컴퓨터에 의해 실행될 때, 컴퓨터로 하여금 기재된 실시예에 따르는 방법 및/또는 동작을 수행하게 하는 실행 가능한 컴퓨터 프로그램 명령을 저장할 수 있다. 실행 가능한 컴퓨터 프로그램 명령은 임의의 적합한 유형의 코드, 가령, 소스 코드, 컴파일된 코드, 해석된 코드(interpreted code), 실행 가능한 코드, 정적 코드, 동적 코드 등을 포함할 수 있다. 상기 실행 가능한 컴퓨터 프로그램 명령은 컴퓨터에게 특정 함수를 수행할 것을 명령하기 위해 지정된 컴퓨터 언어, 방식 또는 신택스(syntax)에 따라 구현될 수 있다. 임의의 적합한 하이-레벨, 로우-레벨, 객체-지향, 비주얼, 컴파일된, 및/또는 해석된 프로그래밍 언어를 이용해 상기 명령은 구현될 수 있다.

일부 실시예는 "일 실시예" 또는 "한 실시예"라는 표현 및 이들의 파생어를 이용해 기재될 수 있다. 이들 용어는 실시예와 관련하여 기재되는 특정 특징, 구조 또는 특성이 적어도 일 실시예에 포함됨을 의미한다. 본 명세서의 다양한 곳에서 "일 실시예에서"라는 구문의 등장이 모두 반드시 동일한 실시예를 언급하는 것은 아니다.

일부 실시예는 "결합된" 및 "연결된"이라는 표현 및 이들의 파생어를 이용해 기재될 수 있다. 이들 용어는 반드시 서로 동의어로 의도된 것은 아니다. 예를 들어, 일부 실시예는, 둘 이상의 요소가 서로 직접 물리적 또는 전기적 접촉하고 있음을 나타내기 위해 용어 "연결된" 및/또는 "결합된"을 이용해 기재될 수 있다. 그러나 용어 "결합된"은 또한 둘 이상의 요소가 서로 직접 접촉하지는 않지만, 서로 협업하거나 상호대화하는 것을 의미할 수 있다.

본원의 요약서는 읽는 자가 기술적 개시 내용의 본질을 빠르게 알아낼 수 있도록 제공된 것이다. 특허청구범위의 범위 또는 의미를 해석하거나 제한하기 위해 사용되지 않을 것임을 이해해야 한다. 덧붙여, 상기 상세한 설명에서 다양한 특징들이 개시 내용을 간결하게 하기 위한 목적으로 일 실시예로 그룹지어짐을 알 수 있다. 이러한 개시 방법은 청구되는 실시예가 각각의 청구항에서 명시적으로 기재되는 것보다 더 많은 특징들을 필요로 한다는 의도를 반영하는 것으로 해석되어서는 안 된다. 오히려, 이하의 특허청구범위가 나타내는 것처럼, 발명은 하나의 단일 개시된 실시예의 모든 특징들보다 적은 것으로 구성된다. 따라서 다음의 특허청구범위는 상세한 설명에 속하며, 각각의 청구항은 그들 자체가 개별적인 실시예이다. 이하의 특허청구범위에서, "포함하는(including)" 및 "여기서(in which)" 라는 용어는 각각의 용어 "포함하는(comprising)" 및 "여기서(wherein)"의 동의어로서 사용된다. 덧붙여, 용어 "제 1", "제 2", "제 3" 등은 라벨로서 사용되는 것에 불과하며, 이들의 목적어에 어떠한 수치적 요건도 부여하고자 하는 것이 아니다.

본 발명이 구조의 특징부 및/또는 방법의 동작에 특정적인 언어로 기재되었지만, 이하의 특허청구범위에서 정의되는 발명은 앞서 기재된 특정 특징부 또는 동작으로 반드시 제한되지 않음을 이해해야 한다. 오히려, 앞서 기재된 특정 특징부 및 동작은 특허청구범위를 구현하는 예시적 형태로서 개시된 것이다.

Claims

컴퓨터에 의해 구현되는 방법으로서,
클라이언트 컴퓨터 상에서 실행 중인 클라이언트 애플리케이션으로부터 사용자 이벤트 속성을 수신하는 단계,
수신된 상기 사용자 이벤트 속성을 기초로 하여 그래픽 사용자 인터페이스(GUI) 독립적 객체를 생성하는 단계,
상기 GUI 독립적 객체에 베이스 템플릿(base template) 및 스크린 템플릿(screen template)을 적용하여 새로운 GUI 독립적 객체를 생성하는 단계,
상기 새로운 GUI 독립적 객체를 클라이언트 컴퓨터 상에서 실행 중인 상기 클라이언트 애플리케이션으로 전송하는 단계를 포함하는
컴퓨터에 의해 구현되는 방법.
제1항에 있어서,
복수의 사용자 이벤트에 대한 복수의 사용자 이벤트 속성을 상기 클라이언트 애플리케이션으로부터 상기 서버 애플리케이션에게 단일 메시지로 전송하는 단계를 포함하는
컴퓨터에 의해 구현되는 방법.
제1항에 있어서,
상기 베이스 템플릿은 GUI 스크린 레이아웃의 단일 표현(single representation)에 대한 메타데이터 및 콘텐츠를 포함하고, 상기 스크린 템플릿은 상기 베이스 템플릿과 관련된 GUI 스크린 레이아웃의 커스텀화된 표현(customized representation)에 대한 메타데이터 및 콘텐츠를 포함하고, 상기 베이스 템플릿 데이터를 무효화(over-ride)하는
컴퓨터에 의해 구현되는 방법.
제1항에 있어서,
상기 커스텀화된 새로운 GUI 레이아웃 스크린은 복수의 스크린을 단일 스크린으로 결합시키는
컴퓨터에 의해 구현되는 방법.
제1항에 있어서,
사용자 이벤트 속성을 수신하는 단계 - 상기 사용자 이벤트 속성은, 하나 이상의 사용자 인터페이스 요소를 갖는 객체 메타데이터, 또는 하나 이상의 튜플(tuple)을 갖는 속성/값 집합 중 적어도 하나를 포함하고, 각각의 튜플은 사용자 인터페이스 요소에 대한 식별자, 상기 사용자 인터페이스 요소에 대한 속성, 및 속성에 대한 값을 포함함 - 를 더 포함하는
컴퓨터에 의해 구현되는 방법.
실행될 때, 시스템으로 하여금 청구항 제1항, 제2항, 제3항, 제4항 및 제5항 중 어느 한 항에 따르는 방법을 수행하게 하는 명령을 포함하는 저장 매체를 포함하는
제조 물품.
장치로서, 상기 장치는
로직 장치, 및
상기 로직 장치 상에서 동작 가능한 서버 애플리케이션을 포함하되,
상기 서버 애플리케이션은
클라이언트 컴퓨터 상에서 실행 중인 클라이언트 애플리케이션으로부터의 사용자 이벤트 속성을 수신하고, 수신된 사용자 이벤트 속성을 기초로 그래픽 사용자 인터페이스(GUI) 독립적 객체를 생성하도록 동작하는 해석 런타임 엔진(interpretive runtime engine) 및 베이스 템플릿과 스크린 템플릿을 상기 GUI 독립적 객체로 적용하여 새로운 GUI 독립적 객체를 생성하도록 동작하며 상기 새로운 GUI 독립적 객체를 클라이언트 컴퓨터 상에서 실행 중인 상기 클라이언트 애플리케이션으로 전송하도록 동작하는 템플릿 프로세서를 포함하는
장치.
제7항에 있어서,
상기 해석 런타임 엔진은 데이터베이스와 동작 가능하게 연결되는
장치.
제7항 또는 제8항에 있어서,
상기 해석 런타임 엔진은 수신된 사용자 이벤트 속성에 응답하여 스크립트된 코드를 실행하도록 동작하는 스크립트 인터프리터(script interpreter)를 더 포함하는
장치.
제7항 또는 제8항에 있어서,
상기 해석 런타임 엔진은 데이터베이스에 저장된 파일에 대한 파일 관리 동작을 실행 수행하도록 동작하는 파일 관리자를 더 포함하는
장치.