KR20100080822A - 네트워크 오퍼레이팅 시스템 - Google Patents

Abstract

일반적으로 설명하면, 본 발명은, 컴퓨터 네트워크들의 연결성을 상승시키는 더 효율적인 방법들을 제공하는 네트워크 오퍼레이팅 시스템에 관한 것이다. 일 실시예에서, XML 프로그래밍 랭귀지로 작성된 상위 레벨 어플리케이션 코드를 입력으로 받아들이는 XML 가상 머신이 구현된다. XML 프로그래밍 랭귀지로 작성된 어플리케이션 코드를 컴퓨터 플랫폼들에 걸쳐 실행하기에 적합한 코드로 해석 또는 번역하는 기능성이 제공된다. 또한, XML 가상 머신은, 어플리케이션으로부터 공통 데이터 모델까지 진정한 데이터 추상화를 가능하게 하는 모델 뷰 컨트롤러 디자인 패러다임을 지원한다. 각 인스턴스들이 잠재적으로 멀티 뷰들을 지원하는, 멀티 인스턴스 어플리케이션들이 생성되고 실행될 수 있다.

Description

네트워크 오퍼레이팅 시스템 {NETWORK OPERATING SYSTEM}

인터넷 프로토콜(Internet Protocol, IP)과 같은 일반 프로토콜들에 따라 데이터를 교환하는 컴퓨터 네트워크는 원격 시스템들과 사용자들간 다양한 태스크를 수행하기 위해 점점 더 사용된다. 컴퓨터 네트워크로부터 이용 가능한 연결성(connectivity)은 조직들과 다른 사람들이 협업 프로세스(collaborative process)에의 참여를 가능하게 하는 솔루션을 찾도록 하였다. 이에 관해, 현존하는 많은 웹 사이트들, 네트워크 포탈들 및 분산된 어플리케이션들은 사용자들이 다양한 방법들로 데이터를 공유하고 협업할 수 있도록 한다. 협업을 더 지원하기 위해, 자원들은 네트워크의 서비스로 이용 가능해지도록 점점 더 만들어지고 있다. 일반적으로 설명하면, 서비스는 기본 기술들로부터 독립된 네트워크로부터 접속 가능하도록 하는 소프트웨어와 하드웨어를 지칭한다. 따라서 네트워크 서비스는, 그 서비스가 구현된 오퍼레이팅 시스템, 프로그래밍 언어들 및 하드웨어 구성 요소들에 "느슨하게 결합(loosely coupled)"되어 있다고 자주 설명된다. 결과적으로, 서로 다른 기본 기술들이 이용되더라도, 네트워크 서비스들은 분산된 어플리케이션들을 생성하기 위해 결합될 수 있다.

"클라우드(Cloud)" 컴퓨팅이란 용어는 네트워크로부터 이용가능해진 서비스의 수가 증가하는 경향을 설명하기 위해 자주 사용된다. 네트워크 대역폭과 연결성이 증가하면서, 클라우드 컴퓨팅의 어플리케이션들과 경제적 이익들이 계속 증대될 것이다. 그러나, 현존하는 시스템들은 네트워크를 통한 통신들을 관리하고 협업을 이용하기 위해 기계 중심적인 오퍼레이팅 시스템을 이용한다. 이에 관해, 기계 중심적인 오퍼레이팅 시스템의 코어 디자인은 인터넷과 같은 컴퓨터 네트워크들의 개발 전에 확립되었다. 결과적으로, 현존하는 시스템들은, 네트워크 통신들이 어플리케이션들과 사용자 경험의 다른 측면들로 용이하게 집적되는, 일반화된 협업 환경을 제공할 수 없다. 대신에, 협업 프로세스에서 공유와 참여를 이용하도록 하는 개발중인 어플리케이션들은, 모든 사용자들 및/또는 조직들에게 여전히 몹시 힘들며 궁극적으로 너무 어렵거나 비싸다. 그러므로, 컴퓨터 네트워크들의 연결성에 영향을 미치는 더욱 효율적인 방법들을 제공하는 네트워크 오퍼레이팅 시스템에 대한 요구가 존재한다.

일반적으로 설명하면, 본 발명은 컴퓨터 네트워크들의 연결성에 영향을 미치는 더욱 효율적인 방법을 제공하는 네트워크 오퍼레이팅 시스템에 관한 것이다. 일 실시예에서, XML 프로그래밍 언어로 작성된 상위 레벨 어플리케이션 코드를 입력으로 받아들이는 XML 가상 머신이 구현된다. XML 프로그래밍 언어로 작성된 어플리케이션 코드를 컴퓨터 플랫폼들에서 실행되기에 적합한 코드로 해석하거나 번역하는 기능성이 제공된다. 더욱이, XML 가상 머신은 어플리케이션들로부터 공동 데이터 모델까지 진정한 데이터 추상화를 가능하게 하는 모델 뷰 컨트롤러(Model View Controller, MVC) 디자인 패러다임을 지원한다. 각 인스턴스가 멀티 뷰들을 지원하는 복수 인스턴스 어플리케이션들이 생성되고 실행될 수 있다.

본 발명의 상술한 측면들과 수반되는 이점들은, 첨부된 도면과 함께 이하의 상세한 설명을 참조하면, 용이하게 이해될 것이다.
도 1은 본 발명의 측면들을 설명하기에 적합한 서버측 데이터 센터와 복수의 클라이언트 컴퓨터를 포함하는 네트워킹 환경의 예시적인 그림 도시이다.
도 2는 본 발명의 측면들을 설명하기에 적합한 서버측 데이터 센터와 복수의 클라이언트 컴퓨터를 포함하는 네트워킹 환경의 예시적인 그림 도시이다.
도3은 본 발명의 측면들을 설명하기에 적합한 컴퓨팅 장치의 예시적인 하드웨어 아키텍쳐를 도시한 블록 다이어그램이다.
도 4A-C는 본 발명이 구현될 수 있는 예시적인 플랫폼 환경들의 블록 다이어그램들이다.
도 5A-B는 본 발명의 측면들을 설명하기에 적합한 서버측 데이터 센터와 복수의 클라이언트 컴퓨터를 포함하는 네트워킹 환경의 예시적인 그림 도시이다.
도 6A-B는 본 발명의 측면들을 설명하기에 적합한 어플리케이션에 연관된 예시적인 프로세스 및 UI XML 문서들을 도시한다.
도 7A-C는 도 6A-B에서 시맨틱하게 설명된 어플리케이션의 그래픽 요소들을 시각적으로 도시한 예시적인 그래픽 디스플레이를 도시하고 있다.
도 8A-B는 본 발명의 측면들을 설명하게 적합한 컴포넌트들의 그림 도시들이다.
도 9는 본 발명의 측면들을 구현하도록 설정된 예시적인 매니저들을 가진 블록 다이어그램이다.
도 10A-C는 본 발명의 일 실시예에 따른 어플리케이션 패키지를 오픈하기 위한 프로세싱을 처리하는 예시적인 어플리케이션 시작 루틴을 설명하는 다이어그램들이다.
도 11은 어플리케이션의 프로세스 코드에 정의된 로직을 오픈하고 초기화하는 루틴을 설명하는 예시적인 플로우 다이어그램이다.
도 12A-B는 작업들을 프로세스 단계에서 실행되도록 설정된 실행 메소드를 설명하는 예시적인 플로우 다이어그램을 도시한다.
도 13은 본 발명의 일 실시예에 따른 XML 문서를 오픈하는 오픈 핸들링 루틴의 다이어그램이다.
도 14A-14B는 본 발명의 측면들을 설명하기에 적합한 오브젝트들 사이의 상호작용들을 도시한 다이어그램들이다.
도 15는 본 발명의 일 실시예에 따른 기능성을 구현하는 동작 핸들링 루틴을 설명하는 예시적인 플로우 다이어그램이다.
도 16은 본 발명의 일 실시예에 따른 오브젝트를 데이터 모델에 바인드하는 바인드 핸들링 루틴의 다이어그램이다.
도 17A-B는 본 발명의 일 실시예에 따른 활성화된 트리거에 반응하여 어플리케이션 코드가 실행되도록 하는 트리거 활성화 루틴을 도시한 다이어그램들이다.
도 18은 이밸류에이션에 기초하여 어플리케이션 실행의 플로우를 지시하는 이밸류에이션을 수행하도록 설정된 판단 핸들링 루틴의 다이어그램이다.
도 19는 본 발명의 일 실시예에 따른 변경 작업을 구현하기 위한 로직을 도시한 변경 핸들링 루틴의 다이어그램이다.
도 20A-C는 본 발명의 일 실시예에 따른 데이터 모델의 컨텐츠를 수정하기 위한 로직을 구현하는 데이터 업데이트 루틴을 도시한 다이어그램들이다.
도 21은 본 발명의 일 실시예에 따른 데이터 모델에 컴포넌트들 규칙들을 설정하기 위한 로직을 도시한 설정 규칙 루틴의 다이어그램이다.
도 22는 본 발명의 일 실시예에 따른 데이터 업데이트를 오브젝트들에 통지하는 노티파이 리스너 루틴의 다이어그램이다.
도 23은 본 발명의 일 실시예에 따른 어플리케이션들 뷰를 렌더링되게 하는 렌더링 루틴의 다이어그램이다.
도 24는 본 발명의 일 실시예에 따른 어플리케이션들이 다양한 예시적인 데이터 소스들과 상호작용하는 방법들을 설명하기에 적합한 블록 다이어그램을 설명한다.
도 25는 본 발명에 의해 제공된 XML 파일 시스템을 설명하기에 적합한 블록 다이어그램을 설명한다.
도 26은 본 발명의 일 실시예에 따른 네트워크를 걸쳐 데이터의 동기화가 가능하도록 설정된 메시지 서버를 설명한다.
도 27은 본 발명의 다른 실시예들에 따른 메시지 서버의 추가적인 측면들을 설명한다.
도 28A-28D는 본 발명에 의해 제공된 파일 시스템으로부터 파일을 검색하는 예시적인 방법을 설명한다.
도 28E는 본 발명의 측면들을 설명하기에 적합한 예시적인 파일의 발췌를 설명한다.
도 29는 본 발명의 일 실시예에 따른 파일들의 목록을 검색하도록 설정된 메소드를 설명한다.
도 30A-30C는 본 발명의 다른 실시예에 따른 XML 파일 시스템 내에서 파일을 생성하는 메소드를 설명한다.
도 31A-31E는 본 발명의 다른 실시예에 따른 XML 파일 시스템 내에 존재하는 파일을 오픈하는 메소드를 설명한다.
도 32는 본 발명의 일 실시예에 따른 클라이언트 컴퓨터 상의 네트워크 오퍼레이팅 시스템의 시동을 시작하는 방법을 설명한다.
도 33은 본 발명의 다른 실시예에 따른네트워크 오퍼레이팅 시스템 그룹을 탑재하는 방법을 설명한다.
도 34A는 본 발명의 일 실시예에 따른 클라이언트 컴퓨터를 온라인 상태에서 오프라인 상태로 천이하는 메소드를 설명한다.
도 34B는 본 발명의 다른 실시예에 따른 네트워크 협업을 위해 사용될 수 있는 복수의 드라이브들의 예시적인 그림 도시를 설명한다.
도 35는 본 발명의 다른 실시예에 따른 클라이언트 컴퓨터가 오프라인 상태에서 동작할 때 온라인 상태로 클라이언트 컴퓨터를 다시 천이하는 방법을 설명한다.
도 36은 본 발명의 다른 실시예에 따른 개선된 네트워크 통신들을 가능하게 하는 방법으로 새로운 파일을 생성하는 요청을 처리하는 메소드를 설명한다.
도 37은 본 발명의 추가적인 측면들을 설명하기에 적합한 채팅 어플리케이션과 함게 이용되는 공유 데이터 파일을 설명한다.
도 38은 본 발명의 다른 실시예에 따른 컴포넌트들 사이의 관계와 채팅 어플리케이션에 의해 이용되는 데이터 모델을 설명한다.
도 39는 본 발명의 다른 실시예에 따른 채팅 대화를 가능하게 하는데 이용되는 공유 데이터 파일의 업데이팅을 설명한다.
도 40은 본 발명의 다른 실시예에 따른 채팅 대화에서 수행되는 통신들의 예시적인 세트를 설명한다.
도 41은 복수의 클라이언트들 사이에서 협업 통신을 수행할 때 공유 데이터의 이용을 설명한다.
도 42는 본 발명의 추가적인 측면등를 설명하기에 적합한 예시적인 어플리케이션의 유저 인터페이스를 도시한다.
도 43은 본 발명의 추가적인 측면들을 설명하기에 적합한 예시적인 어플리케이션의 유저 인터페이스를 도시한다.

일반적으로 설명하면, 본 발명의 측면들은 인터넷 수준의 클라우드 컴퓨팅의 개발을 가능하게 하는 네트워크 오퍼레이팅 시스템에 관한 것이다. 실제 실시예에서, 여기서 설명된 네트워크 오퍼레이팅 시스템은 데이터를 표현하는 범용 언어로 XML(eXtensible Markup Language, 확장 마크업 언어)을 이용한다. 따라서, 아래에 제공된 예시들은 XML 구조 데이터와 문서들에 관련된 네트워크 오퍼레이팅 시스템의 기능성을 설명할 수 있다. 이에 관해, 많은 이점들과 시너지들이 이와 관련된 XML을 사용함으로써 달성된다. 그러나, 청구된 기술적 특징의 범위를 벗어나지 않고도 여기서 설명되지 않은 다른 기본 기술들, 또는 기술들의 조합을 이용해서도 본 발명이 구현될 수 있음을 당업자라면 이해할 수 있다. 또한, 이하에서 제공될 설명을 위한 예시들과 설명들은 본 발명을 개시된 정확한 형태들로 철저하게 한정하려고 의도된 것이 아니다. 유사하게, 동일한 결과를 달성하기 위해서, 이하에서 설명될 단계들은 다른 단계들과 상호 변경되거나 조합될 수 있다.

도 1을 참조하면, 이하의 내용은 본 발명의 측면들을 구현하기 위해 사용될 수 있는 네트워킹 환경(100)의 개요를 제공하기 위한 것이다. 도 1에 도시된 바와 같이, 네트워킹 환경(100)은 서버들(104)에 연관(associated)된 서버측 데이터 센터(102)를 포함한다. 네트워킹 환경(100)은 이동 전화(106), 데스크탑 컴퓨터(108) 및 씬 클라이언트(110)를 포함하는 사용자(112)에 연관된 복수의 클라이언트 컴퓨팅 장치들을 또한 포함한다. 이에 관해, 서버측 데이터 센터(102)는 네트워크(114)를 통해 이동 전화(106), 데스크탑 컴퓨터(108) 및 씬 클라이언트(110)과 통신하며, 네트워크는 로컬 에어리어 네트워크(LAN), 무선 네트워크, 인터넷과 같은 와이드 에어리어 네트워크(WAN) 등으로 구현될 수 있다. 당업자에게 알려져 있듯이, 도 1에 설명된 컴퓨팅 장치들은 네트워크(114)를 통해 파일들, 명령들 및 다른 형태의 데이터를 교환할 수 있다. 그러나, TCP/IP와 같은 네트워크 통신 프로토콜들은 당업자에게 자명하므로, 그 프로토콜들은 여기서 설명되지는 않을 것이다.

현존하는 시스템들에서, 한 종류의 컴퓨팅 장치에서 이용 가능한 어플리케이션 프로그램들은 다른 종류의 장치들과는 호환되지 않을 수 있다. 이 비호환성은 다양한 문제점들을 생성한다. 예를 들어, 범용 컴퓨터에서, 사용자는 이메일 메시지들에 접속하는 특정 어플리케이션을 쓸 것이다. 한편, 이동 전화와 같은 자원이 제한적인 장치에서 이메일에 접속하기 위해서는, 동일하지 않은 특징들과 인터페이스를 가진 또 다른 프로그램이 요구될 수 있다. 이 비호환성은 공통된 사용자 경험을 제공하는데 좋지 않으며 사용자에게 요구되는 지식과 기술의 양을 줄이는데도 좋지 않다. 더욱이, 많은 어플리케이션들이 유사하거나 동일한 기능성을 구현하더라도 과도한 개발 시간이 다른 종류의 장치들을 위한 어플리케이션 개발에 소모된다.

본 발명의 측면들은 이하의 내용은 단지 예시인 복수의 다른 컨텍스트들에 적용될 수 있다. 일실시예에서, 사용자의 어플리케이션들과 데이터는 네트워크 오퍼레이팅 시스템에 사용할 수 있는 모든 컴퓨팅 장치로부터 접속 가능하다. 도 1에 설명된 바와 같이, 사용자(112)는 이동 전화(106), 데스크탑 컴퓨터(108) 및 씬 클라이언트(110)로부터 네트워크(114)에 접속할 수 있다. 응답으로, 서버측 데이터 센터(102)는 네트워크 오퍼레이팅 시스템 서비스들을 적합한 장치에 전달한다. 더 분명하게는, 네트워크 오퍼레이팅 시스템과 유저 어플리케이션들의 클라이언트측 컴포넌트는 사용자가 네트워크에 접속할 때마다 전달되고 구축될 수 있다. 어플리케이션들은 로컬에서 적합한 클라이언트 컴퓨팅 장치에서 실행되며, 서버들에서는 실행되지 않는다. 사용자 데이터는 클라이언트 컴퓨팅 장치에 일시 저장(cached)되지만, 서버측 데이터 센터(102)에 의해 유지되는 스토리지에서 지속될 것이다. 따라서 클라이언트 컴퓨팅 장치(106-110)와 서버측 데이터 센터(102)간 통신들은 문서들과 업데이트 데이터를 획득하기 위해 주로 수행된다. 클라이언트가 오프라인으로 되는 경우에, 네트워크 오퍼레이팅 시스템의 클라이언트측 컴포넌트는 데이터 업데이트가 로컬에 일시 저장되도록 한다. 이 업데이트들은 서버측 데이터 센터(102)로 전송되며 네트워크가 재설정되면 모든 변경들과 동기화된다.

일실시예에서, 네트워크 오퍼레이팅 시스템은 각 사용자의 컴퓨팅 장치들에 걸쳐 공통된 경험을 제공할 수 있다. 이에 관해, 공통 데스크탑 어플리케이션이 전달되고 이질적인 종류의 컴퓨팅 장치들에서 구축된다. 공통 데스크탑으로부터, 사용자의 모든 어플리케이션 프로그램들과 데이터는 접속될 수 있다. 예를 들어, 네트워크 오퍼레이팅 시스템에 사용할 수 있는 하나의 이메일 프로그램이 사용자(112)에 의해 모든 클라이언트 컴퓨팅 장치들(106-110)로부터 접속될 수 있다. 사용자 데이터는 서버측 데이터 센터(102)에서 이용 가능하고 서비스로 전달되므로, 동일한 어플리케이션들(예를 들어, 이메일 프로그램)과 데이터(예를 들어, 이메일 메시지들)는 어떤 컴퓨팅 장치가 사용되더라도 이용 가능하다.

네트워크 오퍼레이팅 시스템이 클라이언트 컴퓨팅 장치에 제공하는 서비스들은 사용자 선호들(preferences)과 다른 변수들에 따라 변경(customized)될 수 있다. 이에 관해, 어떻게 네트워크 오퍼레이팅 시스템 서비스들이 제공될 것인지를 정의한 설정 데이터가 유지된다. 예를 들어, 사용자는 사용중인 컴퓨팅 장치에 따라 사용 가능한 어플리케이션 프로그램들이나 데이터서로 다른 세트들을 가진 선호들을 설정할 수 있다. 다른 예에 의하면, 사용자는 보안되지 않은 무선 연결을 포함하는 많은 억세스 포인트들로부터 네트워크(114)에 연결할 수 있다. 이 예에서, 네트워크 연결의 보안되지 않은 특성 때문에 어떤 서비스들 및/또는 데이터가 접속할 수 없도록 보안 속성들이 설정될 수 있다. 당업자에 의해 이해될 수 있겠지만, 이상의 예들은 네트워크 오퍼레이팅 시스템 서비스들이 본 발명을 이용하여 변경될 수 있는 방법들의 일부를 표현한 것이다.

편의를 위해, 도 1은 상호 보완적인 태스크들이 네트워크(114)를 통해 연결된 원격 컴퓨팅 장치들에 의해 실행될 수 있는 네트워크 환경(100)에서 이용될 수 있는 서버측 데이터 센터(102), 서버 컴퓨터들(104), 이동 전화(106), 데스크탑 컴퓨터(108) 및 씬 클라이언트(110)를 설명하고 있다. 그러나, 본 발명은 랩탑 컴퓨터들, 태블릿 컴퓨터들, PDA(personal digital assistant), 하이브리드/임베디드 장치들, 셋탑 박스들, 미디어 센터들 등과 같은, 그러나 여기에 한정되지 않는, 다른 종류의 클라이언트 컴퓨팅 장치들을 이용해서도 수행될 수 있다. 더욱이, 당업자라면 본 발명이 다른 네트워크 구성들에서도 구현될 수 있으며 도 1에 도시된 예는 단지 예시인 것으로 해석되어야 한다는 것을 이해할 수 있다.

도 2를 참조하여, 본 발명의 추가적인 측면을 설명하는데 이용될 수 있는 다른 네트워킹 환경(200)을 설명한다. 도 2에 도시된 바와 같이, 서버측 데이터 센터(202)는 기업 네트워크(204)와 같은 사설 네트워크에 결합될 수 있다. 이 예에서, 추가적인 네트워크 오퍼레이팅 시스템 서비스들은 기업 네트워크(204)를 통해 클라이언트들(206, 208, 210)로 직접 제공된다. 그러나 네트워크 오퍼레이팅 시스템은 서버측 데이터 센터(216) 로부터 여전히 제공되고 관리되며, 기업 서버측 데이터 센터(202) 는 추가적인 서비스들을 제공할 뿐이다. 또한, 동일한 추가적인 서비스들은 기업 네트워크(204) 외부의 클라이언트들에도 제공될 수 있다. 이 예에서, 서버측 데이터 센터(202)는 인터넷(214)을 통해 네트워크 서비스들을 제공한다. 상술한 설명과 유사하게, 클라이언트들(206-212)은 네트워크 오퍼레이팅 시스템에 사용할 수 있는 모든 컴퓨팅 장치(이동 전화, 데스크탑 컴퓨터, 씬 클라이언트 등)일 있다. 또 다른 실시예에서, 네트워크된 오퍼레이팅 시스템은 추가적인 서비스들과 함께 기업 서버측 데이터 센터(202)에 의해 직접 제공될 수 있으며 기업 네트워크(204) 외부의 외부 서버측 데이터 센터(216)에 접속을 가능하게 하거나 그렇지 않을 수 있다(보안 설정들에 의함).

네트워크 오퍼레이팅 시스템은 협업 프로세스들에의 참여를 가능하게 한다. 본 발명의 일 측면은 XML 문서들, 실행 파일들, 바이너리 파일들, 멀티미디어 등 모든 종류의 데이터를 저장할 수 있는 네트워크 저장소(repository)의 역할을 하는 XML 파일 시스템이다. XML 파일 시스템은 물리적인 저장과 데이터 접속을 관리하는 서버측 데이터 센터(202 또는 216)에 구현될 수 있다. 일반적인 파일 시스템 기능들에 더하여, XML 파일 시스템은 정의될 수 있는 다양한 종류의 협업 공간들을 허용한다. 예시적인 실시예에서, 지원되는 협업 공간들의 종류들은 현존하는 협업 공간들 내에서의 부분 집합(예를 들어, 서브 커뮤니티, 서브 그룹 등)뿐만이 아니라 커뮤니티, 그룹, 친구도 포함한다. XML 파일 시스템 내의 루트 폴더는 생성된 각 커뮤니티, 그룹 또는 다른 협업 공간에 대한 저장소 역할을 한다. 또한, 폴더들과 파일들은 개인 사용자들에 연관된 XML 파일 시스템 내에서 생성될 수 있다. 다른 실시예에서, 서로 다른 사용자들간 협업은 XML 파일 시스템 내에서 협업 공간을 공유하는 사용자들이 없어도 동적으로 가능해질 수 있다. 이하에서 상세히 설명되듯이, 실시간으로 협업 세션을 생성하거나 요청들을 승인하도록 하는 메시징 서비스들이 제공된다. 따라서, 현존하는 협업 공간이 정의되지 않았더라도 사용자들은 동적으로 생성된 협업 세션들을 통해 새로운 관계들을 설정할 수 있다.

네트워크 오퍼레이팅 시스템의 클라이언트측 컴포넌트가 실행되기 시작하면, 로그인 프롬프트는 사용자 정보들(user credential)을 획득하는데 이용될 수 있다. 투명한 억세스(transparent access)를 가능하게 하기 위해, 사용자에 연관된 각 폴더는 클라이언트상의 가상 드라이브로서 XML 파일 시스템으로부터 매핑될 수 있다. 예를 들어, 사용자가 특정 그룹의 멤버이면, 그룹 폴더가 클라이언트 상에서 가장 드라이브로 나타난다. 일실시예에서, XML 파일 시스템 내의 폴더는 협업 공간의 공유된 자원들을 정의하는 XML 구조 데이터를 포함한다. 이 공유된 자원들은 어플리케이션들, 데이터 문서들, 접속 및 보안 설정들(access and security settings), 사용자 목록들, 통계, 일정 등을 포함하지만, 여기에 한정되지는 않는다. XML 파일 시스템은, 일실시예에서, 네트워크된 오퍼레이팅 시스템 환경에서 실행되는 하나 이상의 어플리케이션들에 대한 보관소 및 데이터베이스 대체물로 작업할 수도 있다. 이하에서 상세히 설명되듯이, 협업 및 분산 데이터베이스에서 유지되는 데이터는 본 발명에 의해 제공된 트랜잭션 관리를 통해 자동적으로 동기화될 수 있다. 이러한 종류의 협업 및 분산 데이터베이스를 이용하는 어플리케이션들을 구축함으로써, 어플리케이션들은 데이터베이스의 특징들을 상속하며, 데이터를 손쉽게 공유할 수 있다.

XML 파일 시스템에는 어플리케이션 프로그래밍 인터페이스(API)가 따라가기 때문에, 서버측 데이터 센터(202)의 다른 실시예들이 가능해진다. 이에 관해, XML 파일 시스템으로부터 제공될 수 있는 다른 XML 웹 서비스들은 기업 내에서 레거시 어플리케이션들(legacy applications)과 데이터베이스들 상에서 추상화들이 네트워크된 오퍼레이팅 시스템 환경에서 실행되는 새로운 어플리케이션을 제공하거나 복수의 어플리케이션들을 통할할 수 있도록 요구되는 경우에 바람직하다. XML 파일 시스템의 변경(customized)된 구현들은 지원할 기능의 레벨을 선택할 수 있다. 예를 들어, 트랜잭션들을 동기화하는 지원은 한 지원 레벨에서 생략될 수 있다.

데이터 접속의 관리에 더하여, XML 파일 시스템은 데이터를 동기화하고 데이터 업데이트들의 트랜잭션 제어를 조정하여 협업을 가능하게 하는 방법으로 사용자들간의 연관들을 생성하고 변경(customize)하는 통합된 프레임워크를 제공한다. 예를 들어, 어플리케이션은 연관된 사용자 데이터와 함께 한 그룹의 사용자들(예를 들어, 친구들)에게 공유될 수 있다. 공유된 어플리케이션과 연관된 사용자 데이터 모두의 기능성은, 다른 자원들과 함께, 그룹 또는 사용자 폴더에 의해 유지되는 XML 문서들에 의해 표현될 수 있다. XML 파일 시스템은 각 사용자들이 공유된 어플리케이션과 연관된 사용자 데이터에 접속할 수 있는 방법을 제공한다. 이러한 방법으로, 공유된 어플리케이션은 전달되고, 같은 그룹 또는 사용자 폴더의 데이터를 조작하는 각 그룹 멤버 조작 데이터에 의해 복수의 클라이언트들에 구축될 수 있다.

상술한 바와 같이, 기업 네트워크(204) 외부의 클라이언트들(예를 들어, 클라이언트(212))은 서버측 데이터 센터(202)로부터 서비스들을 획득할 수 있다. 예로서, 종업원 또는 다른 사용자는, 기업 네트워크(204) 외부에 있을 때, 기업 자원들에 대한 접속을 제공받을 수 있다. 따라서, 클라이언트(212)는 인터넷(214)을 통해 서버측 데이터 센터(202)에 접속하는 가정의 컴퓨터, 이동 전화 등이 될 수 있다. 이에 관해, 당업자라면 네트워킹 환경(200)이 도 2에 설명된 것 이외의 추가적인 네트워크들을 포함할 수 있으며, 도 2의 예시적인 구성은 다른 방법에 의해 네트워크 오퍼레이팅 시스템과 추가적인 XML 파일 시스템을 전달하도록 다양하게 재구성될 수 있음을 이해한다. 예를 들어, 클라이언트(212)에 대한 네트워크 억세스 포인트는 로컬 에어리어 네트워커, 무선 네트워크, 와이드 에어리어 네트워크 등으로부터 시작되며, 이는 서버측 데이터 센터(202, 216)에 대해서도 적용될 수 있다.

다른 실시예에서, 클라이언트들은 하나 이상의 변수들에 따라 기업 서버측 데이터 센터(202)로부터 다른 종류의 서비스들을 획득할 수 있다. 각 클라이언트에 동일한 네트워크 서비스들을 제공하는 대신에, 네트워크 서비스들은 클라이언트의 네트워크 억세스 포인트의 위치에 따라 설정될 수 있다. 예를 들어, 기업 네트워크(204)에 직접 접속하는 클라이언트들(206-210)은 기업에 특정된 추가적인 변경(customized) 서비스들을 제공받을 수 있다. 기업 네트워크(204) 밖에서는, 외부 서비스들이 서버측 데이터 센터(202)로부터 클라이언트(212)(예를 들어, 고객, 공급자, 종업원, 또는 기업에 관련된 사용자)에게 전달될 수 있다. 변경된 네트워크 서비스들의 안전한 전달을 가능하게 하기 위해, 자원들은 다른 종류들의 클라이언트들을 관리하는 서버측 데이터 센터(202)에 의해 할당될 수 있다. 도 2에 도시된 실시예에서, 서버측 데이터 센터(202)는 네트워크 내부의 클라이언트들(206-210)에 변경된 서비스들을 제공하도록 할당된 하드 드라이브(220)를 포함한다. 한편, 하드 드라이브(222)는 기업 네트워크 외부에 있는 클라이언트들, 예를 들어, 클라이언트(212)에 더욱 일반화된 서비스들을 제공하도록 할당될 수 있다. 또 다른 실시예들에서, 클라이언트에 제공되는 서비스들은 사용자 정보들, 설정 정보들, 클라이언트 종류 등과 같은 다른 변수들에 종속될 수 있다.

일측면에서, 네트워크 오퍼레이팅 시스템은 실시간 "비즈니스-투-비즈니스" 협업을 가능하게 하기 위한 더욱 일반화된 프레임 워크를 제공한다. 서로 다른 기업들이 공동 데이터 스토어의 자원들에 접속할 수 있도록 하는 협업 공간이 생성될 수 있다. 도 2에 도시된 예에서, 클라이언트(212)는 서버측 데이터 센터(202)를 유지하는 기업에 대한 협력 기업에 연관될 수 있다. 이에 관해, 도 2에 설명된 클라이언트들은 사용자들이나 서버측 데이터 센터(202)와 상호작용하는 소프트웨어 에이전트들에 의해 운영될 수 있다. 소프트웨어 에이전트들에 의해 운영될 때, 본 발명의 측면들은 기업에 연관된 사용자들 또는 개별적으로 XML 파일 시스템을 이용하는 자원들을 공유하는 EDI(Electronic Data Interchange) 관계를 효율적으로 생성한다. EDI 서비스들은, 보안 요구사항에 따라, 공개적으로 이용 가능한 서버측 데이터 센터(216)에 의해서도 제공될 수 있다. 그룹 폴더는 파트너쉽의 공유된 자원들을 저장 및/또는 EDI의 비즈니스 규칙들을 정의하는 XML 파일 시스템에서 생성될 수 있다. 상술한 설명과 유사하게, 그룹 폴더는 클라이언트(212)에서 가상 드라이브로 매핑될 수 있어서, 기업 네트워크(204) 외부의 공유된 자원들에 대한 투명한 억세스를 제공한다. 중요하게, 공유된 어플리케이션은 서버측 데이터 센터(202)에서 클라이언트들(206-212)로 XML 구조 데이터로서 전달될 수 있다. 각 클라이언트들(206-212)은 로컬에서 어플리케이션을 구축하고 실행하고, 데이터 업데이트들을 XML 파일 시스템 내의 공유된 폴더나 각 사용자들의 개인 폴더들에 보고한다. 일실시예에서, 서버측 데이터 센터(202)는 복수 클라이언트들이 동시에 동일한 문서들에 접속하고 업데이트할 수 있도록 데이터 업데이트 조정을 관리한다. 이 조정은, 데이터가 자체 XML 파일 시스템에 저장되어 있다면, 서버측 데이터 센터(216)에 의해서도 수행될 수 있다.

일 측면에서, 네트워크 오퍼레이팅 시스템은 클라이언트들(206-212)이 외부 네트워크 서비스들에 투명한 억세스를 하도록 허용한다. 어플리케이션 프로그램 인터페이스(API)를 이용하여, 모든(내부 또는 외부) 네트워크 서비스와 접속(interface)하는 데이터 핸들링 기능들을 추상화하는 커뮤니케이터(communicator)가 생성될 수 있다. 예로서, 개발자들은 그 중에서도 XML 웹 서비스들, REST 서비스들, XML 자원들, RSS 또는 Atom 피드들, 텍스트, csv 텍스트, HTML(Hypertext Markup Language) 기반 웹 사이트들을 호스팅하는 네트워크 서버들에 접속하는 커뮤니케이터들을 생성할 수 있다. 도 2를 참조하면, 커뮤니케이터 또는 "채널"의 인스턴스는 웹 서비스(218)과 상호작용하기 위해 클라이언트(212)에 의해 인스턴스화될 수 있다. 이 예에서, 네트워크 오퍼레이팅 시스템 서비스들은 공중 네트워크(예를 들어, 인터넷(214))에서 서버측 데이터 센터(216)를 프록시로 사용하는 클라이언트(212)에 대해 접속 가능하다. 또한, 네트워크 오퍼레이팅 서비스들이 사설 네트워크(예를 들어, 기업 네트워크(204))로부터 제공되더라도, 웹 서비스(218)는 커뮤니케이터를 이용하는 클라이언트들(206-210)에 대해 접속 가능하다. 이 예에서, 서버측 데이터 센터(216)는 클라이언트들(206-210)과 웹 서비스(218) 사이의 통신들을 관리하는 프록시 역할을 한다. 따라서, 네트워크 서비스들에 접속할 때, 클라이언트들은 데이터 핸들링 기능들을 추상화하기 위해 커뮤니케이터를 사용할 수 있다. 개발자들에게 클라이언트와 네트워크 서비스간 통신들을 관리하는 코드를 반복적으로 쓸 것을 요구하지 않기 때문에, 본 발명의 이러한 측면은 어플리케이션 개발을 단순화한다.

도 2가 기업 네트워크(204)를 설명하고 있지만, 당업자라면 이것은 단순한 예시임을 이해할 수 있다. 대신에, 본 발명은 다른 종류의 네트워크 환경들에서 데이터 동기화와 협업을 가능하게 할 수 있다. 따라서, 도 2를 참조하여 제공된 설명은 인터넷과 같은 와이드 에러이어 네트워크들뿐만 아니라 가정이나 소규모 비즈니스에 의해 유지되는 로컬 에어리어 네트워크들에도 동일하게 적용될 수 있다. 더욱이, 상술한 예들은 각 클라이언트(206-212)에 별개의 네트워크 서비스들을 제공하는 서버측 데이터 센터(202)를 참조하여 만들어졌다. 그러나, 서버측 데이터 센터(202)는 다른 장치나 네트워크의 자원들이나 서비스들을 보완하는 네트워크 서비스들을 제공하도록 구성될 수 있다. 예를 들어, 소규모 비즈니스는 로컬 에어리어 네트워크에 연결된 모든 클라이언트들을 위한 네트워크 드라이브를 유지할 수 있다. 서버측 데이터 센터(202)는 추가 스토리지를 제공하거나 공중 네트워크 장치에 오류가 발생하는 경우 백업을 허용함으로써 서버측 데이터 센터(216)의 공중 네트워크 드라이브를 보완하는 데이터 스토리지 서비스들을 제공할 수 있다. 또 다른 실시예로, 홈 네트워크는 디지털 미디어에 대한 각 로컬 클라이언트 접속을 제공하기 위해 미디어 센터 컴퓨터를 이용할 수 있다. 미디어 센터 컴퓨터의 스토리지를 보완하기 위해, 서버측 데이터 센터(202)에 의해 가상 드라이브가 홈 네트워크에 연결된 모든 장치들에 제공될 수 있다. 이에 관해, 사용자 선호들 또는 다른 설정 변수들에 기초하여, 가상 드라이브는 미디어 센터 컴퓨터와 서버측 데이터 센터(202) 사이에서 데이터의 실제 스토리지를 할당할 수 있다.

도 3을 참조하여, 컴퓨팅 장치(300)의 예시적인 하드웨어 구조가 설명된다. 도 3이 네트워크 상의 클라이언트로 구현된 컴퓨팅 장치를 참조하여 설명되지만, 이하의 설명은 본 발명을 구현하는데 이용될 수 있는 서버들이나 다른 장치들에도 적용 가능하다. 더욱이, 당업자라면 컴퓨팅 장치(300)가 현재 이용 가능하거나 추후에 개발될 장치들 중 어느 하나일 수 있음을 이해할 수 있다. 가장 기본적인 구성에서, 컴퓨팅 장치(300)는 적어도 하나의 중앙 처리 장치(CPU)(302) 및 통신 버스(306)에 의해 연결된 시스템 메모리(304)를 포함한다. 장치의 정확한 구성과 종류에 따라, 시스템 메모리(304)는, 리드 온리 메모리(Read only memory; ROM), 랜덤 억세스 메모리(Random access memory; RAM), EEPROM, 플래시 메모리 또는 유사한 메모리 기술과 같은, 휘발성 또는 비휘발성 메모리일 수 있다. 당업자라면 시스템 메모리(304)는 즉시 접근 가능 및/또는 CPU(302)에서 현재 작동중인 데이터 및/또는 프로그램 모듈들을 일반적으로 저장함을 이해할 수 있다. 이에 관해, CPU(302)는 명령어들의 실행을 지원함으로써 컴퓨팅 장치(300)의 연산 센터 역할을 한다.

도 3에서 더 설명된 것과 같이, 컴퓨팅 장치(300)는 네트워크를 통해 다른 장치들과 통신하는 하나 이상의 컴포넌트들을 포함하는 네트워크 인터페이스(310)을 포함한다. 이하에서 상세히 설명되듯이, 본 발명은 일반 네트워크 프로토콜을 이용한 통신들을 수행하는 네트워크 인터페이스(310)를 이용한 기본 서비스들에 접속할 수 있다. 도 3에 도시된 예시적인 실시예에서, 컴퓨팅 장치(300)는 저장 매체(308)를 더 포함한다. 그러나, 도 4A를 참조하여 더욱 상세히 설명되듯이, 네트워크 오퍼레이팅 시스템 서비스들은 로컬 저장 매체에 데이터를 유지하는 수단을 포함하지 않는 컴퓨팅 장치를 이용해도 접속 가능할 수 있다. 따라서, 도 3에 도시된 저장 매체(308)는 선택적인 것임을 나타내기 위해 점선에 의해 표시되고 있다. 어떠한 경우에도, 저장 매체(308)는 휘발성 또는 비휘발성, 이동식 또는 고정식, 정보를 저장할 수 있는 기술, 예를 들어, 하드 드라이브, 솔리드 스테이트 드라이브, CD-ROM, DVD 또는 다른 디스크 스토리지, 마그네틱 카세트들, 마그네틱 테이프, 마그네틱 디스크 스토리지 등을 이용하여 구현될 수 있으나, 여기에만 한정되지는 않는다.

여기서 이용되는, "컴퓨터 판독 가능 매체"는 컴퓨터 판독 가능 명령들, 데이터 구조들, 프로그램 모듈 또는 다른 데이터와 같은 정보를 저장할 수 있는 방법 또는 기술로 구현된 휘발성 및 비휘발성 및 이동식 및 고정식 매체를 포함한다. 이에 관해, 도 3에 도시된 시스템 메모리(304)와 저장 매체(308)는 컴퓨터 판독 가능 매체의 단순한 예들에 불과하다.

CPU(302), 시스템 메모리(304), 통신 버스(306), 저장 매체(308) 및 네트워크 인터페이스(310)를 포함하는 컴퓨팅 장치들의 적절한 구현들은 공지이며, 구매가 가능하다. 설명의 편의를 위해 그리고 특허청구범위에 기재된 사항을 이해하는데 중요하지 않기 때문에, 도 3은 많은 컴퓨팅 장치들의 전형적인 컴포넌트들을 생략하고 있다. 이에 관해, 컴퓨팅 장치(300)는 키보드, 마우스, 마이크로폰, 터치 입력 장치 등과 같은 입력 장치들을 일반적으로 포함할 수 있다. 유사하게, 컴퓨팅 장치(300)는 디스플레이, 스피커, 프린터 등과 같은 출력 장치들을 또한 포함할 수 있다. 이 모든 장치들은 공지되었으므로, 여기서는 설명하지 않는다.

도 4A-4C를 참조하면, 본 발명이 구현될 수 있는 예시적인 플랫폼 환경들이 설명된다. 이에 관해, 도 4A-4C는 컴퓨팅 장치(300)(도3)의 플랫폼 계층들간의 계층적인 관계들을 설명한다. 더 상세하게는, 도 4A-4C에서 설명된 컴퓨팅 장치(300)의 플랫폼 계층들은 맨 아래 계층에 하드웨어 플랫폼(403), 중간 계층에 머신 오퍼레이팅 시스템(404), 그리고 맨 위 계층에 어플리케이션 플랫폼(406)을 포함한다. 물론, 당업자라면, 도 4A-4C에 도시된 컴퓨팅 장치(300)의 플랫폼 계층들이 단지 예시임을 이해할 수 있다.

컴퓨팅 장치(300)의 예시적인 하드웨어 플랫폼(402)가 도 3을 참조하여 위에서 설명되었으므로, 이 컴포넌트들에 대한 추가적인 설명은 하지 않는다. 그러나, 도 4A-4C에 설명되었듯이, 컴퓨팅 장치(300)는 머신 오퍼레이팅 시스템(404)을 포함할 수 있다. 이에 관해, 머신 오퍼레이팅 시스템(404)은Microsoft® 오퍼레이팅 시스템, Apple® 오퍼레이팅 시스템, UNIX® 오퍼레이팅 시스템, Linux® 오퍼레이팅 시스템, Nokia® Symbian, Google® Android 등과 같은 범용 오퍼레이팅 시스템의 패밀리 중 어느 하나로부터일 수 있다. 머신 오퍼레이팅 시스템(404)는 씬 클라이언트들, 이동 전화들, 메인 프레임들, 슈퍼 컴퓨터들 등과 같은 특화된 하드웨어(non-generic hardware)를 이용하는 전문화된 컴퓨팅 장치들에 맞춰진 오퍼레이팅 시스템일 수 있다. 또한, 머신 오퍼레이팅 시스템(404)은 실시간 오퍼레이팅 시스템들, 임베디드 오퍼레이팅 시스템들 등과 같은 어떤 설정 파라미터들을 만족하도록 설계된 오퍼레이팅 시스템일 수 있다.

머신 오퍼레이팅 시스템들의 목적은 접속(accessing)과 그 밖의 하드웨어 자원들 이용의 상세를 추상화하는 것이다. 따라서, 머신 오퍼레이팅 시스템들은, 예를 들어 하드웨어 컴포넌트들과의 I/O(입력 및 출력)을 관리, 메모리 관리, 태스크 스케쥴링 등과 같은 거의 모든 기본 시스템 태스크들을 수행한다. 이에 관해, 머신 오퍼레이팅 시스템은 API를 통해 어플리케이션 프로그램에 서비스를 전형적으로 제공한다. API를 통한 서비스들의 제공은 어플리케이션 개발자들이 접속의 구현 상세를 관리하거나 하부 컴퓨터 플랫폼을 사용해야 하는 노력을 경감시킨다. 상당하게, 본 발명의 측면들은 모든 현대 컴퓨터 플랫폼들로부터 이용 가능한 기본 서비스들을 위해서만 머신 오퍼레이팅 시스템(404)을 이용한다. 이에 관해, 서비스들은 네트워킹 하드웨어와 인터페이스하고 TCP/IP 프로토콜을 이용하여 통신하는 네트워크 연결을 설정하는데 사용될 수 있다.

도 4A에 도시된 실시예에서, 컴퓨팅 장치(300)는 어플리케이션 플랫폼(406)의 맨 위 계층에서 동작하는 웹 브라우저(408)를 포함한다. 상술한 바와 같이, 네트워크 오퍼레이팅 시스템의 클라이언트측 컴포넌트(410)는 컴퓨팅 장치(300)에 전달되어 구축될 수 있다. 도 4A에 도시된 실시예에서, 클라이언트측 컴포넌트(410)는 웹 브라우저(408)의 컨텍스트 내에서 동작한다. 이에 관해, 웹 브라우저(408)는 Mozilla Firefox®, Microsoft's Internet Explorer®를 포함하는, 그러나 여기에 한정되지는 않는, TCP/IP 네트워크 통신 프로토콜들을 이용하여 원격 장치들과 통신하는 임의의 수의 브라우저 어플리케이션들일 수 있다.

도 4A에 도시된 실시예에서, 클라이언트측 컴포넌트(410)는 머신 오퍼레이팅 시스템(404)과 직접 상호작용하지 않는다. 그 대신, 클라이언트측 컴포넌트(410)에 의해 사용되는 기본 서비스들은 웹 브라우저(408)로부터 접속된다. 당업자라면 HTTP는, 무엇보다도, 유니폼 리소스 로케이터(URL)을 사용하여 네트워크 자원들이 요청되거나 수신될 수 있도록 하는 TCP/IP 보다 상위 프로토콜임을 이해할 수 있다. 전형적으로, 웹 브라우저들은 하이퍼텍스트 마크업 랭귀지(HTML), 익스텐서블 마크업 랭귀지(XML)와 같은 마크업 랭귀지로 포맷되거나 JSON(Java Script Object Notation) 및/또는 JavaScript로 포맷된 웹 페이지들을 획득하기 위해 HTTP 리퀘스트들을 생성한다. 일실시예에서, 웹 브라우저(408)는 HTTP를 이용한 네트워크 통신들을 수행하고, 웹 브라우저에서 이용 가능한 그래픽 표현 기술중에서 HTML로 표현된 그래픽 요소들을 렌더링하는 네트워크 오퍼레이팅 시스템의 클라이언트측 컴포넌트(410)에 의해 이용된다.

도 4B에 도시된 실시예에서, 네트워크 오퍼레이팅 시스템의 클라이언트측 컴포넌트(410)는 웹 브라우저를 이용하지 않고 머신 오퍼레이팅 시스템(404)의 서비스들에 직접 접속한다. 본 발명의 측면들은 어플리케이션들이 모든 컴퓨팅 장치들에 전달되고 구축되도록 한다. 그런, 웹 브라우저들은 미리 결정된 페이즈 사이즈 및/또는 레이아웃에 따라 그래픽 요소들을 디스플레이하도록 전형적으로 설정된다. 따라서, 범용 웹 브라우저는 본 발명이 구현될 모든 종류의 컴퓨팅 장치에서 그래픽 요소들을 렌더링하는데 적절하지 않을 수 있다. 예를 들어, 스몰 폼 팩터(small form factor) 컴퓨팅 디바이스에서 그래픽 요소들을 렌더링하는 브라우저를 사용하는 것은 문제가 될 수 있다. 이에 관해, 웹 브라우저에 의해 예상되는 미리 결정된 페이지 크기 및/또는 레이아웃은 주어진 이용 가능한 폼 팩터에 비해 너무 크거나 적당하지 않을 수 있다. 도 4B에 설명된 것과 같이, 네트워크 오퍼레이팅 시스템의 클라이언트측 컴포넌트(410)는 독립 어플리케이션(stand-alone application)이나, 머신 오퍼레이팅 시스템으로도 구현될 수 있다. 이 경우에, 클라이언트측 컴포넌트(410)는 웹 브라우저를 이용하지 않고 컴퓨팅 장치의 주어진 폼 팩터에 적절한 방법으로 그래픽 렌더링을 수행하도록 설정된다. 더욱이, 이 실시예에서, 네트워크 통신들을 수행하기 위한 기본 서비스들은 머신 오퍼레이팅 시스템(404)으로부터 직접 획득되거나 클라이언트측 컴포넌트(410)에 구축될 수 있다.

도 4C에 도시된 실시예에서, 컴퓨팅 장치(300)는 전통적인 머신 오퍼레이팅 시스템을 포함하지 않는다. 대신에, 하드웨어 플랫폼(402)과 인터페이싱하기 위한 기본 서비스들은 클라이언트측 컴포넌트(410)에 구축된다. 이 실시예에서, 클라이언트측 컴포넌트(410)는 메모리 관리, 태스크 스케쥴링 등에 대한 기본 시스템 태스크들을 구현한다. 이러한 종류의 기본 머신 서비스들을 클라이언트측 컴포넌트(410)에 구축함으로써, 본 발명의 측면들은 특정 하드웨어 플랫폼들과 사용하기 위해 용이하게 변경(customize)되고 배치될 수 있다. 바꿔 말하면, 클라이언트측 컴포넌트(410)는 머신 오퍼레이팅 시스템의 공급자가 제공한 서비스들로부터 독립되도록 설정될 수 있다.

상술한 바와 같이, 클라이언트 컴포넌트(410)는 네트워크 서비스로 전달되고 사용자가 네트워크에 연결할 때마다 구축될 수 있다. 도 4 A-4C에서 설명된 것과 같이, 클라이언트측 컴포넌트(410)는 독립 어플리케이션으로, 머신 오퍼레이팅 시스템으로, 또는 웹 브라우저의 컨텍스트 내에서 구현되기에 적합하다. 이 모든 실시예들에서, 서버측 데이터 센터(202 또는 216)는 네트워크 서비스로서 클라이언트측 컴포넌트(410)로 어플리케이션 로직을 제공할 수 있다. 따라서, 저장매체(예를 들어, 하드 드라이브, CD-ROM, DVD 등)를 갖지 않는 제한된 리소스의 컴퓨팅 장치는 본 발명에 의해 제공된 네트워크 오퍼레이팅 시스템에 접속하기 위해 이용될 수 있다. 이에 관해, 클라이언트측 컴포넌트(410) 및 다른 네트워크 오퍼레이팅 시스템 데이터는, 로컬 저장매체에 계속되지 않고, 시스템 메모리(ROM, RAM 등)에 일시 저장될 수 있다. 따라서, 네트워크 오퍼레이팅 시스템에 사용할 수 있는 수 있는 어플리케이션들은, 어플리케이션이 서비스로서 전달될 수 있으므로, 컴퓨팅 장치(300)에 "설치"될 필요가 없다.

도 5A-5B를 참조하면, 어떻게 공동 데이터 모델이 본 발명에 따른 네트워크 오퍼레이팅 시스템 서비스들을 전달하는데 이용될 수 있는지에 관한 설명이 제공된다. 네트워크 오퍼레이팅 시스템은, 어플리케이션 컴포넌트들을 서로 다른 계층들, 즉, 모델 뷰와 컨트롤러로 분리함으로써, 모델 뷰 컨트롤러(MVC) 디자인 패러다임을 지원한다. 실제 실시예에서, XML 문서들은 정보가 네트워크 오퍼레이팅 시스템 환경에서 표현되는 "모델" 또는 공동 데이터이다. 이 컨텍스트에서 공동 데이터 모델(예를 들어, XML 문서)의 사용은 많은 이익을 나으며, 아래 설명에서 더욱 명확해질 것이다.

도 5A-5B에 도시된 네트워킹 환경(500)은 네트워크(508)를 통해 각 클라이언트들(504, 506)에 통신 가능하게 연결된 서버측 데이터 센터(502)를 포함한다. 상술한 바와 같이, 네트워크 오퍼레이팅 시스템의 클라이언트측 컴포넌트는 서버측 데이터 센터(502)로부터 각 클라이언트들(504, 506)로 동적으로 전달될 수 있거나, 양 클라이언트(504, 506)에 로컬에서 설치될 수 있다. 양 경우에서, 네트워크 오퍼레이팅 시스템의 클라이언트측 컴포넌트는 XML 구조 어플리케이션들을 해석하거나 클라이언트들(504, 506)에서 실행되도록 하는 XML 가상 머신(510)을 제공한다. 서비스로서 전달될 때, 본 발명의 측면들은 서버측 데이터 센터(502)로부터의 프로세스 XML 문서를 전달함으로써, 네트워크 오퍼레이팅 시스템이 "부팅"되도록 한다. 이에 관해, 프로세스 XML 문서는 클라이언트들(504, 506)에 대한 시작 시퀀스(startup sequence)를 기술한 로직을 제공한다. 이하에서 상세히 설명되듯이, 이 프로세스 XML 문서는 XML 가상 머신(510) 내에서 실행된다. 시동 시퀀스는 XML 가상 머신(510)내의 한 세트의 오브젝트들을 전형적으로 인스턴스화하고 조작하여 다른 어플리케이션들이 실행될 수 있다.

상술한 바와 같이, XML은 네트워크 오퍼레이팅 시스템 환경에서 어플리케이션 로직과 다른 데이터가 표현되는 "모델" 또는 공동 포맷의 역할을 할 수 있으나, 다른 모델들, 데이터 포맷들, 및 데이터의 구조 또한 본 발명을 구현하는데 이용될 수 있다. 일 실시예에서, XML 어플리케이션들이 매우 높은 추상화 레벨에서 디자인 될 수 있도록 하는 프로그래밍 랭귀지들이 제공된다. 당업자라면 XML이 고도로 구조화(highly structured)되고, 전송가능(transferable)하며, 변형 가능(transformable)한 랭귀지임을 이해할 수 있다. 따라서, XML 구조 데이터와 같이 높은 추상화 레벨에서 어플리케이션 로직의 표현은 메모리 효율적이며, 컴팩트한 어플리케이션을 초래한다. 특히, 플랫폼이 하나 이상의 잘 구성된 XML 문서들에 표현된 어플리케이션의 로직을 실행하기 위해 제공된다. 어플리케이션 기능성은 MVC 디자인 패러다임에 따라 분리되어, 전통적인 시스템들에 의해 수행되던 반복 태스크들을 제거한다. 따라서, 현존하는 시스템들과 비교할 때, 서버측 데이터 센터(502)에서 클라이언트들(504, 506)로 어플리케이션 코드의 전송은 적은 양의 대역폭을 소모한다. 더욱이, 어플리케이션 로직이 XML 가상 머신(510)을 사용하여 실행되므로, 본 발명을 이용한 어플리케이션 로직의 실행은 소모되는 대역폭을 제거하거나 상당히 감소시킨다. 서버 "라운드 트립"을 수행하여서 처리되던 상호작용들은 요청하거나 서버측 데이터 센터(502)와 네트워크 통신들에 의하지 않고도 클라이언트들(504, 506)에서 직접 처리된다.

본 발명의 일 측면은 클라이언트(504, 506)에 어플리케이션들을 실행하고 개발하기 위한 어플리케이션 프로그래밍 인터페이스(API)를 제공하는 XML 가상 머신(510)이다. 이에 관해, XML프로그래밍 랭귀지로 작성된 상위 레벨 어플리케이션 코드는 입력으로 받아들여지며 XML 가상 머신(510)에 의해 클라이언트(504, 506)에서 로컬에서 실행된다. 상위 레벨 어플리케이션 코드를 해석 가능한 코드, 바이트 코드 또는 임의의 플랫폼에서 실행하기에 적합한 다른 하위 레벨 언어로 해석하거나 번역하는 기능성이 제공된다. 이에 관해, XML 가상 머신(510)은 어플리케이션들이 모든 종류의 컴퓨팅 장치에서 동일한 방법으로 실행되도록 하부 컴퓨터 플랫폼과 네트워크 자원들을 추상화한다. 따라서, XML 가상 머신(510)은 플랫폼과 하드웨어에 완벽하게 독립되며, 예를 들어, Microsoft .NET®, Java, C, C++, HTML, JavaScript, AJAX, Adobe® Flash, Microsoft® SilverLight 등과 같은, 그러나 여기에 한정되지 않는, 현재 이용 가능하거나 개발중인 어떠한 프로그래밍 기술들을 이용해도 구현될 수 있다.

도 5B를 참조하면, 공동 데이터 모델이 네트워크 오퍼레이팅 시스템 서비스들을 제공하는데 어떻게 이용되는지에 관한 추가적인 측면들이 설명된다. 도 5B에 설명된 네트워킹 환경(500)은 도 5A를 참조하여 상술한 동일 컴포넌트들을 포함한다. 한편, 스토리지와 다른 네트워크 서비스들을 제공하는 XML 파일 시스템(512)은 서버측 데이터 센터(502)에 도시되어 있다. 따라서, 네트워크 오퍼레이팅 시스템 서비스들이 제공되는 동안, XML 파일 시스템(512)에서 유지되는 데이터는 클라이언트들(504, 506)에 의해 접속될 수 있다. 일 측면에서, 본 발명은 문서들의 스토리지 및 클라이언트들(504, 506)의 다른 런-타임 데이터를 관리하기 위한 클라이언트측 캐시(514)를 구현한다. 도 5B에 설명된 바와 같이, 클라이언트측 캐시(514)에 저장된 데이터는 XML 가상 머신(510)에 쉽게 접속 가능하다. 일 실시예에서, 네트워크 연결이 잠시 불가능하거나, 클라이언트들(504, 506)이 오프라인이 되더라도, 클라이언트측 캐시(514)는 XML 가상 머신(510)이 실행중인 어플리케이션들을 계속할 수 있도록 한다. 예로서, 사용자가 버스, 기차 또는 비행기를 타고 있을 때와, 네트워크 연결이 불가능한 경우에, 클라이언트들(504, 506)에서 실행중인 어플리케이션들은 오프라인에서도 동작을 계속할 수 있다. 이하에서 상세히 설명되듯이, 네트워크 연결이 재설정되면, 클라이언트들(504, 506)에서 수행되는 데이터 변경들은 서버측 데이터 센터(502)에 있는 XML 파일 시스템(512)와 동기된다.

상술한 바와 같이, 본 발명은 개발자들이 최상위 레벨 추상화의 어플리케이션을 생성할 수 있도록 하는 프로그래밍 랭귀지를 제공한다. 실제 실시예에서, 이 프로그래밍 랭귀지들은 프로세스 XML 랭귀지, 유저 인터페이스(UI) XML 랭귀지, 및 어플리케이션 패키지 XML 랭귀지를 포함한다. 이 프로그래밍 랭귀지들로 작성된 어플리케이션 코드는 XML 구조 데이터로 표현되고 XML 문서에 저장되기에 적합하다. 도 5B에 설명된 예에서, 프로세스 XML 문서(516), 유저 인터페이스 XML 문서(518), 및 어플리케이션 패키지 XML 문서(520)는 이 프로그래밍 랭귀지들로 각각 작성된 어플리케이션 코드를 포함한다. 따라서, 어플리케이션은 서버측 데이터 센터(502)에서 유지되는 하나 이상의 XML 문서들에 정의될 수 있다. 또한, 어플리케이션은 서버측 데이터 센터(502)에서 또한 유지되는 데이터 XML 문서(522)와 같은 데이터 문서들을 전형적으로 이용할 수 있다. 이 XML 문서들(516-522)은 어플리케이션들이 XML 가상 머신(510)을 이용하여 실행될 수 있도록 하기 위해 클라이언트들(504, 506)에 의해 온 디맨드(on demand)로 접속될 수 있다.

일 실시예에서, UI XML 랭귀지는 MVC 디자인 패러다임에서 어플리케이션의 "뷰"를 정의하는데 이용된다. 이에 관해, 마크업 랭귀지들은 원래, 페이지들이 웹 브라우저에 의해 랜더링될 수 있도록 웹 페이지들의 레이아웃을 기술하도록, 개발되었다. 마크업 랭귀지들의 구조적 특성은 웹 브라우저의 구현이나 다른 관련된 기술들에 영향을 주지 않으면서 웹 페이지들의 외관(appearance)이 수정될 수 있도록 하였다. 이에 관해, UI XML 랭귀지는 XML 신택스(syntax)에 부합하는 스키마에 따른 어플리케이션 유저 인터페이스의 외관과 가동(behavior)을 정의한다. UI XML 랭귀지를 사용하여, 개발자들은 공통 데스크탑 어플리케이션들에 존재하는 동일한 그래픽 요소들(예를 들어, 메뉴들, 툴바들, 드롭다운 박스들 등)을 가진 어플리케이션들을 생성할 수 있다. 유저 인터페이스 로직은 특정 클라이언트에 특화된 방법에 의존하거나 그 구현을 기술하지 않으므로, UI XML 랭귀지는 서로 다른 플랫폼에 걸쳐서 동작하는 사용자 인터페이스들을 개발하는데 적합하다. 또한, UI XML 랭귀지로 기술된 유저 인터페이스들과 동작은 MVC 디자인 패러다임에 따라 상위 레벨 추상화된 XML 신택스에 따르는 이 요소들을 기술한다. 따라서, UI XML 랭귀지로 기술된 유저 인터페이스들과 가동은 다른 시스템들에 영향을 주지 않고도 용이하게 변형되거나 수정될 수 있다. UI XML 랭귀지를 변형하는 능력은 어플리케이션의 기능성이 하나 이상의 변수들에 따라 변경(customized)될 수 있도록 한다. 예를 들어, 변형은, 사용되는 장치의 종류에 의존하는 어플리케이션 기능성의 어떤 측면들을 감소하거나 제거하도록 정의될 수 있다. 다른 예로, 변형은, 사용자 접속 정보(user access credential)에 의존하거나 다른 언어들 및/또는 시장들에 대해 어플리케이션을 로컬화하는 어떤 기능성을 제거하거나 제한하도록 UI XML 랭귀지에 정의될 수 있다.

일실시예에서, 프로세스 XML 랭귀지는 MVC 디자인 패러다임에서 어플리케이션의 "컨트롤러" 컴포넌트를 정의하는데 이용된다. 이에 관해, 프로세스 XML 랭귀지는 개발자들이 어플리케이션의 로직을 한 세트의 프로세스 단계들로 기술할 수 있도록 한다. 각 프로세스 단계는, 전통적인 프로그래밍 랭귀지의 명령들(instructions) 및/또는 메소드 콜들(method calls)과 근사적으로 동일한 하나 이상의 작업들(operations)을 포함한다. MVC 디자인 패러다임에서, 프로세스 XML 랭귀지는 유저 인터페이스("뷰") 로직과 XML 데이터("모델") 사이의 컨트롤러나 글루(glue)로 사용된다. 따라서, 본 발명의 측면들은 어플리케이션 로직이 전통적인 프로그래밍 랭귀지들보다 더 높은 추상화 레벨에 있는 프로세스 XML 랭귀지를 이용해서 기술될 수 있도록 한다. 이에 관해, 사용자 인터페이스 로직("뷰")은 프로세스 XML 로직("컨트롤러")로부터 완전히 분리된다. 결과적으로, 현존하는 시스템들에서 다수의 어플리케이션 코드를 포함하는 데이터 핸들링 기능들은 본 발명에 의해 자동적으로 처리된다. 특히, 프로세스 XML 랭귀지를 사용하여, 지능적인 데이터 바인딩들은 뷰 로직과 데이터 모델 사이에서 정의될 수 있다. 어플리케이션들을 실행할 때, 로컬에 일시 저장된 데이터 모델로 그리고 원격 파일 시스템과 원격 리스너들(remote listeners)로의 I/O(입력 및 출력) 또는 데이터는 네트워크 오퍼레이팅 시스템에 의해 자동적으로 처리된다. 개발자들이 데이터 핸들링 로직을 제공하지 않으므로, 프로세스 XML 랭귀지를 이용하여 생성된 어플리케이션들은 자주 더 빨리 개발되며, 전통적인 어플리케이션들보다 더 적은 어플리케이션 코드를 포함한다. 이하에서 상세히 설명되듯이, 프로세스 XML 랭귀지는 도 5A를 참조하여 설명한 것 이외에, 네트워킹 환경에서 어플리케이션들을 생성하고 배포하는 다른 장점들을 제공한다.

상술한 랭귀지 이외에, 어플리케이션 패키지 XML 랭귀지가 또한 제공된다. 어플리케이션 패키지 XML 랭귀지는 개발자들이 어플리케이션에 의해 이용되는 자원들을 기술할 수 있도록 한다. 이에 관해, 어플리케이션의 기능성을 정의한 UI와 XML 문서들은 어플리케이션 패키지에서 식별될 수 있다. 어플리케이션 패키지 내의 로직은 개발자들이 어플리케이션의 자원들을 통제되고 안전한 방법에 의해 클라이언트로 패키징하고 배포할 수 있도록 한다. 더욱이, 어플리케이션 패키지의 이용은 XML 가상 머신(510)이 어플리케이션 내부 보안(intra-application security)을 가능하게 하는 방법에 의해 어플리케이션의 복수 인스턴스들이 생성될 수 있도록 한다.

. 일 측면에서, 본 발명은 네트워킹 환경에서 어플리케이션들과 소프트웨어 업데이트들을 배포하기 위한 개선된 방법들을 제공한다. 현존하는 시스템들을 사용하면, 어플리케이션은, 실행됐을 때, 컴퓨팅 장치에 어플리케이션을 "설치"하는 실행 파일(executable) 포맷으로 전형적으로 배포된다. 실행 파일은 특정 컴퓨팅 플랫폼에 특정된 머신 명령들로 어플리케이션 로직을 표현한다. 따라서, 실행 파일은 네트워킹 환경에서 배포될 때 상대적으로 많은 양의 대역폭을 소모하는 어플리케이션의 메모리 집중 표현(memory intensive representation)이다. 따라서, 복잡하고 자원 집중적인 시스템들은 실행 파일을 이용하여 어플리케이션을 배포하고 설치하도록 요구된다.

네트워크를 통해 어플리케이션들과 소프트웨어 업데이트들을 배포하는 개선된 방법들은 네트워크 오퍼레이팅 시스템에 합체된다. 네트워크 오퍼레이팅 시스템에 사용할 수 있는 어플리케이션은 실행파일을 사용하여 클라이언트 컴퓨팅 장치에 "설치"되지 않는다. 대신, 본 발명은 어플리케이션 로직이 전체적으로 XML 구조 데이터로 표현되도록 한다. 클라이언트가 네트워크 연결을 설정하면, 하나 이상의 XML 문서들로 표현된 어플리케이션은 서비스 공급자로부터 자동적으로 획득될 수 있으며, 서비스 공급자는 인터넷 상의 로컬/사설 서버 또는 임의의 웹 서버로부터 XML 문서들을 제공할 수 있다. 따라서, 합체된 프레임워크는 네트워크를 통해 어플리케이션을 클라이언트들로 배포하기 위해 제공된다. 또한, "패치들"과 같은 업데이트들과 어플리케이션의 더 최신 버전들은 클라이언트로 자동적으로 전파될 수도 있다. 이에 관해, 어플리케이션 로직이 네트워크 서비스로서 자동적으로 배포되는 XML 문서에 표현되어 있으므로, XML 문서에 대한 수정들도 네트워크 서비스로서 클라이언트들로 전파된다. 네트워크 오퍼레이팅 시스템 환경에서, 어플리케이션 로직은 다른 데이터와 같은 방법으로 네트워크를 통해서 동기화될 수 있다. XML 가상 머신(510)과 XML 파일 시스템(512)은 트랜잰션 핸들링을 통해 데이터를 동기화하고 변경들을 관리하도록 설정되었으므로, 어플리케이션들에 대한 변경은 실시간으로 협업 방법으로 수행될 수 있다. 예를 들어, 공유 폴더에서 유지되는 어플리케이션들은 클라이언트(504)에서 오픈되고 실행될 수 있다. 동시에, 클라이언트(506)에 연관된 사용자는 어플리케이션 로직을 수정할 수 있고, 변경들이 클라이언트(504)로 자동적으로 전파되도록 할 수 있다. 어플리케이션 로직에 대한 변경들은 실시간으로 구현될 수 있고, 따라서 변경이 발생하면 클라이언트(504)에서 쉽게 관측될 수 있다.

도 5A-5B를 참조하여 상술한 바와 같이, 어플리케이션의 XML 표현은 서비스 제공자에 의해 배포되며 XML 가상 머신을 사용하여 클라이언트에서 실행된다. 결과적으로, 클라이언트들은 서버측으로부터 런타임 프로세싱을 요구하지 않고 "오프라인"으로 어플리케이션들을 계속 실행할 수 있다. 이 경우에, 하나 이상의 어플리케이션들을 표현하는 XML 문서들은 클라이언트상의 메모리에 일시 저장된다. XML 가상 머신은, 네트워크 연결을 가지지 않고도 실행중인 어플리케이션들을 계속하기 위해, 이 일시 저장된 XML 문서들에 접속할 수 있다. 더욱이, 오프라인시 발생하는 데이터 업데이트들도 일시 저장되며 네트워크 연결이 재설정되면 서버측으로 전송된다.

특히, 본 발명은, 컴퓨터 자원들의 가상화(virtualization)를 요구하지 않으면서 네트워크 오퍼레이팅 시스템 서비스들을 제공한다. 이에 관해, 컴퓨터 자원들을 가상화하는 다수의 기술들이 "클라우드" 스토리지와 같은 네트워크 서비스들을 제공하는데 이용되고 있다. 일반적으로 설명하면, 이 가상화 기술들은, 하부 플랫폼들로부터 떨어져 있는 서버와 전형적으로 연관된 컴퓨터 자원들을 추상화한다. 추상화된 자원들은 네트워크로부터 접속되기에 적합한 인터페이스에 독립적인 플랫폼에서 전형적으로 캡슐화된다(encapsulate). 이에 관해, 추상화될 수 있는 컴퓨터 자원들은 어플리케이션들, 하드웨어, 데스크탑들, 머신 오퍼레이팅 시스템들 등을 포함한다. 그러나, 복잡한 시스템들은 컴퓨터 자원들을 이러한 방법으로 추상화하고 캡슐화하도록 요구된다. 예를 들어, 서버의 하부 하드웨어를 시물레이션하고 성능에 적어도 영향을 미치는 가상화 계층이 요구될 수 있다. 또한, 이 가상화 기술들은 자원들이 구현되고 실행되는 위치를 서버측으로 이동시키는 서버 중심 모델을 홍보한다. 네트워크 서비스들이 늘어만가는 사용자들에게 제공될 때, 서버에 부가된 증가된 프로세싱과 다른 요구들은 측정할 수 없다. 따라서, 네트워크 서비스를 구현하는 가상화 기술들의 사용은 서비스가 온 디맨드로 사용 가능함을 보장하기 위해 서버들의 과잉 공급이 요구되는 통합 데이터 센터를 필요로 할 수 있다. 또한, 어플리케이션 로직이 원격 서버에서 실행되고 클라이언트에서 직접 실행되지 않으므로, 가상화 기술들은 더 많은 대역폭을 소모하며, 더 느린 사용자 경험을 초래한다. 네트워크 연결이 다운되거나 클라이언트가 오프라인이 되면, 이는 어플리케이션이 이용 불가능해지게도 한다.

컴퓨터 자원들을 가상화하지 않은 네트워크 서비스의 구현은 많은 이점을 제공한다. 이에 관해, 네트워크 서비스들이 지속적으로 증가하는 사용자들에 의해 접속되어질 수 있도록 하는 더 스케일러블한 구조가 제공된다. 클라이언트측에서 어플리케이션들을 실행하는 XML 가상 머신들을 이용함으로써, 클라이언트들로부터의 프로세싱과 다른 자원들이 최대한으로 이용될 수 있다. 이 구현은 더 스케일러블한 구조를 제공하는데, 고유한 관련성이 네트워크 서비스에 접속한 사용자의 수, 대역록 사용, 프로세싱 파워, 및 어플리케이션 로직을 실행하기 위해 클라이언트측으로부터 사용 가능한 다른 자원들 사이에 존재하기 때문이다. 더 스케일러블한 것에 더하여, XML 가상 머신을 이용하여 클라이언트에서 실행중인 어플리케이션들은 어플리케이션 기능성이 "오프라인"인 동안에 사용자들에 의해 쉽게 접속되도록 한다. 클라이언트가 "오프라인"이 되면, 하나 이상의 XML 문서들로 표현된 어플리케이션들과 사용자 데이터는 클라이언트측 캐시에 저장될 수 있다. 따라서, 모든 어플리케이션 로직은, 활성화된 네트워크 연결이 존재하느냐에 상관없이, 이용 가능하며 캐시에 있는 데이터를 이용하여 실행될 수 있다. 그러나, "오프라인"인 동안에는 어플리케이션이 네트워크 자원들에 접속할 수 없으며, 어플리케이션의 모든 기능성을 구현하기 위해서는 네트워크 연결을 재설정할 필요가 있다. 이에 반해, 가상화 기술들을 이용하여 네트워트 서비스가 구현될 때 제공되는 "오프라인" 기능성은 더 제한된다. 이에 관해, 일부 현존하는 네트워크 서비스들은, 네트워크 서비스에 접속하던 어플리케이션과 상호작용을 계속할 수 있는 "오프라인" 모드를 구현한다. 그러나, 이 기능성을 제공하기 위해, 실행파일이나 어플리케이션의 다른 하위 레벨 표현이 배포되고 클라이언트에 설치된다. 사용자가 "오프라인"이면, 이 어플리케이션의 하위 레벨 표현이 로컬에서 실행된다. 그러나, 이 "오프라인" 기능성을 제공하기 위해 클라이언트에 어플리케이션들을 설치하는 것은 실현 가능하거나 편리하지 않을 수 있다. 예를 들어, 자원이 제한적인 컴퓨팅 장치는 실행파일이나 다른 어플리케이션의 하위 레벨 표현을 설치할 충분한 스토리지를 갖지 않을 수 있다. 더욱 일반적으로, 활성화된 네트워크 연결 없이 클라이언트에서 이용 가능한 기능성은 로컬에서 설치되었던 어플리케이션들에 한정된다. 그러나, 클라이언트는 실행파일이나 어플리케이션의 하위 레벨 표현을 이용하여 원하는 어플리케이션을 설치하는 충분한 컴퓨팅 자원들(스토리지, 메모리, 대역폭 등)을 갖지 않을 수 있다.

일 측면에서, 본 발명은 이동, 무선 또는 불안정한 네트워크들을 통하여 네트워크 서비스들에 접속하기 위한 개선된 방법들을 구현한다. 당업자라면, 유선 네트워크들과 비교했을 때 이동 또는 무선 네트워크들은 덜 신뢰할만하며 대역폭이 제한된다는 것을 이해할 수 있다. XML 구조 데이터와 반복적인 데이터 핸들링 기능들을 자동적으로 수행하도록 설정된 XML 가상 머신(510)으로 어플리케이션 로직을 표현하는 프로그래밍 랭귀지의 제공은 매우 컴팩트하며 메모리 효율적인 어플리케이션들을 초래한다. 이에 관해, 어플리케이션 로직을 구현할 때, 어플리케이션들은 XML 가상 머신(510)의 기능성과 재생 오브젝트들(reuse objects)을 공유할 수 있다. 결과적으로, 현존하는 어플리케이션 배포 시스템들과 비교할 때, 네트워크 오퍼레이팅 시스템에 사용 가능한 어플리케이션들의 배포는 일부 대역폭을 소모한다. 또한, 본 발명은 어플리케이션들의 XML 표현들이 클라이언트측 캐시에 유지되고 XML 가상 머신(510)을 이용하여 로컬에서 실행되도록 한다. 어플리케이션 로직과 데이터가 로컬에서 일시 저장될 수 있으므로, 지속적인 네트워크 연결이 필요하지 않을 수 있다. 대신에, 본 발명은 네트워크 연결성이 간헐적인 무선 네트워크를 통하여 네트워크 서비스들로의 접속을 제공하는데 매우 적합하다. 또한, 어플리케이션들이 로컬에서 실행되므로, 서비스를 보장하는 더욱 신뢰할 수 있는 네트워크 서비스들이 제공될 수 있다. 예를 들어, 본 발명은 인터넷과 같은 네트워크의 서비스로서 기업 등급 어플리케이션들(enterprise class applications)을 제공하는데도 매우 적합하다. 이에 관해, 당업자라면 기업 등급 어플리케이션들은 네트워크 연결이 일시적으로 불가능하거나 인터넷 연결의 품질이 네트워크 접속에 영향을 미치더라도 기업 내에서는 접속이 가능할 필요가 있음을 이해할 수 있다. 여기서 설명된 발명은 이 문제를 해결한다.

네트워크 오퍼레이팅 시스템의 클라이언트측 컴포넌트

당업자라면 XML이 추가적인 랭귀지들의 생성을 위한 기초를 제공하는 확장 가능한 랭귀지임을 이해할 수 있다. XML 문서는 계층적인 트리 구조를 가지는데, 트리의 루트는 문서를 식별하며 문서의 다른 노드들은 루트의 파생이다. 트리의 노드들은 컨텐츠의 구조를 정의하는 데이터 뿐만이 아니라 문서 컨텐츠를 포함할 수 있다. XML에 의해 부여된 신텍스에 더하여, 요소들과 그에 연관된 속성들은XML문서의 구조와 컨텐츠에 대한 다른 시맨틱 제한들(semantic constraints)을 설정하도록 정의될 수 있다. 일 실시예에서, 본 발명은XML에 의해 부가된 것들에 대한 추가적인 시맨틱 제한들을 적용하는 스키마들과 용어들(vocabularies)을 구현할 수 있다. 본 발명에 의해 제공된 XML 랭귀지들을 이용하면, 개발자들은 MVC 디자인 패러다임에 따라 어플리케이션의 로직을 시맨틱하게 표현한다.

MVC 디자인 패러다임은 Smalltalk 프로그래밍 랭귀지에서 처음으로 구현되었으며 이후 다른 엔지니어링 컨텍스트들에서 이용되었다. 당업자라면 MVC 디자인 패러다임은 기능성을 계층들로 분리하기 위한 일반적인 구조적 패러다임을 단순히 표현한 것임을 이해할 수 있다. 따라서, MVC 디자인 패러다임은 다양한 컨텍스트들에서 종속성을 제거하고 플랫폼 독립성을 제공하기 위해 구현되었다. 예로서, HTML 데이터를 저장하고, 동적 웹 페이지 컨텐츠를 수집하며 웹 페이지를 렌더링하던 현존하는 시스템들은 MVC 디자인 패러다임에 고착되었다고 자주 설명된다. 또한, 웹 어플리케이션들을 생성하던 개발 환경들은 MVC 디자인 패러다임에 따라 기능성을 계층들로 분리할 수 있다. 이 맥락에서, 웹 어플리케이션의 그래픽 유저 인터페이스는 모듈라 어플리케이션(modular application) 개발을 지원하기 위해서 데이터 모델에서 분리되었다. 그러나, 이 현존하는 시스템들은 기능성을 구현하고 본 발명보다 더욱 도메인 특정적인 하부 데이터 모델을 이용한다.

현존하는 시스템과 달리, 본 발명의 측면들은 모든 종류의 어플리케이션이 MVC 디자인 패러다임에 따라 생성되도록 한다. 다시 말해, 로직과 하부 데이터 모델로부터 유저 인터페이스의 분리는 웹 어플리케이션들, 웹 페이지들 등에 한정되지 않는다. 각 인스턴스가 잠재적으로 멀티 뷰들을 지원하는 멀티 인스턴스 어플리케이션들은 네트워크 오퍼레이팅 시스템 환경에서 생성되고 실행될 수 있다. 또한 이 어플리케이션 인스턴스들 각각은 공동 데이터 모델로부터 데이터를 조작한다. 개발자들이 데이터 모델로부터 데이터를 설정하고 접속하며 동기화와 유저 인터페이스("뷰")와 데이터 모델간 데이터 교환을 관리하기 위한 프로그램 로직을 제공할 필요가 없으므로, 어플리케이션 개발을 대단히 간단해진다.

도 6A-B를 참조하면, 본 발명의 측면들을 설명하는데 사용될 수 있는 예시적인 프로세스와 UI XML 문서들이 설명될 수 있다. 도 6A는 "MyTasks" 어플리케이션에 대한 컨트롤러 로직의 시맨틱 설명을 제공하는 예시적인 프로세스 XML 문서(600)("MyTasks.xml")을 도시한다. 도 6A에 설명되어 있듯이, MyTasks.xml 문서(600)는"<trigger>" XML 요소에서 정의된 트리거(602)를 포함한다. 이 트리거(602)는 뷰, 컴포넌트, 이벤트 및 단계 속성들을 포함하는 한 세트의 속성들을 유지한다. 더욱이, 프로세스XML 랭귀지로 작성된 어플리케이션 로직은 일련의 프로세스 단계들을 정의할 수 있다. 이 예에서, MyTasks.xml 문서(600)는"<step>" XML 요소들에 의해 기술된 복수의 프로세스 단계들(604-610)을 포함한다. 도 6A에 도시된 바와 같이, 두 속성들은 숫자 속성("id")와 이름 속성을 포함하는 각 프로세스 단계들(604-610)에 연관된다. 각 프로세스 단계내에서, 적어도 하나의 작업이 정의된다. 예로서, 이름 속성 "Initialize Application"에 연관된 프로세스 단계(604)는 "<operation>" XML 요소들에 의해 기술된 세 작업들(612-616)을 포함한다.

도 6B는 MyTasks 어플리케이션에 대한 예시적인 "뷰"로직의 시맨틱 설명을 제공하는 UI XML 문서("MyTasks_gui.xml")로부터의 발췌를 도시한다. 도 6B에 설명된 바와 같이, MyTasks_gui.xml 문서(650)는 "<button>" XML 요소에 의해 기술된 두 버튼 컴포넌트들(652, 654)을 포함한다. 각 버튼 요소는 이름, 텍스트 및 폭 속성들을 포함하는 한 세트의 속성들을 유지한다. 또한, MyTasks_gui.xml 문서(650)는 "<input>" XML 요소들에 의해 기술된 두 입력 컴포넌트들(656, 658)을 포함한다. 이 예에서, 입력 컴포넌트들(656, 658)은 이름, 폭, 높이 속성들을 포함하는 한 세트의 속성들을 유지한다.

어플리케이션을 시작하면, XML 가상 머신의 역할을 하는 본 발명의 측면들은 MyTasks.xml 문서(600)를 해석하기 시작할 수 있다. 일 실시예에서, 실행 전에 전체가 컴파일되기 보다는, 어플리케이션 로직은 한 번에 한 스테이트먼트가 해석된다. 그러나, 다른 실시예에서는, 본 발명에 의해 제공된 XML 랭귀지들로 작성된 어플리케이션 코드가 실행 가능한 코드나 바이트 코드로 컴파일 될 수도 있다. 이 예에서, MyTasks.xml 문서(600)는 트리거의 활성화에 반응하여 실행될 어플리케이션에서의 프로세스 단계(606)를 식별하는 트리거(602)를 정의한다. 최초에, 예시적인 실시예에서 XML 가상 머신이 MyTasks.xml 문서(600) 해석을 시작하면, 트리거(602)는 트리거의 활성화에 반응하여 적절한 프로세스 단계(606)로 플로우가 지시(directed)되도록 하기 위해 트리거(602)가 등록된다.

도 6A에 도시된 MyTasks.xml 문서(600)에서, 어플리케이션은, 어플리케이션에서 트리거들이 등록되면 제어 플로우가 지시될 기본 프로세스 단계(604)를 이름 속성 "Initialize Application"로 정의한다. 이름 속성 "open" 과 값 속성 "apps/mytasks_gui.xml"을 갖는 작업(612)은 실행될 Initialize Application process 단계(604)에서의 첫 번째 작업이다. Open 작업(612)의 실행은MyTasks_gui.xml 문서(650)로 표현된 어플리케이션의 뷰가 해석되고 컴퓨터 디스플레이에 렌더링되게 한다. 이 예에서, 어플리케이션의 뷰는 MyTasks_gui.xml 문서(650)에서 시맨틱하게 정의된 컴포넌트들(652-658)을 포함한다. MyTasks_gui.xml 문서(650)가 오픈되면, 실행은 이름 속성 "action"과 값 속성 "#MyTasks"를 갖는 작업(614)로 진행한다. 일반적으로 설명하면, Action 작업(614)의 실행은, MyTasks_gui.xml 문서(650)가 오픈되면, 버튼 컴포넌트(654)가 뷰에서 감춰지도록 한다.

도 7A-C를 참조하면, MyTasks 어플리케이션에 연관된 예시적인 그래픽 디스플레이(700)가 설명된다. 특히, 도 7A에 도시된 그래픽 디스플레이(700)는, MyTasks_gui.xml 문서(650)에서 시맨틱하게 정의된 버튼 컴포넌트들(652-654)에 대응하는 Button 1 컴포넌트(702)와 Button 2 컴포넌트(704)를 포함한다. 또한 그래픽 디스플레이(700)는, 입력 컴포넌트들(656-658)의 시맨틱 설명에 각각 대응하는 Input3 컴포넌트(706)와 Input4 컴포넌트(708)를 포함한다. 이에 관해, 도 7A의 그래픽 디스플레이(700)는 MyTasks_gui.xml 문서(650)의 시각적 묘사를 표현한다. 상술한 바와 같이, MyTasks 어플리케이션이 시작되면, MyTasks_gui.xml 문서(650) 내의 프로세스 로직은 Button2 컴포넌트가 감춰지도록 한다. 따라서, Button2 컴포넌트(704)는 Button2 컴포넌트(704)가 Action 작업(614)의 실행 이후 처음에는 사용자에게 보이지 않음을 나타내기 위해 도 7A에 점선으로 도시된다.

일반적으로 설명하면, 예시적인 MyTasks 어플리케이션은 "data/tasks.xml" 문서에 저장된 태스크 설명들의 목록을 디스플레이하도록 설정된다. 더 상세하게는, 어플리케이션이 시작될 때, 태스크 설명들은 기본적으로 Input3 컴포넌트(706)에 디스플레이 된다. 일 측면에서, 사용자는 Inpu3 컴포넌트(706)와 직접 상호작용하고 태스크 설명들의 항목들을 변경함으로써 태스크 목록을 수정할 수 있다. 다른 측면에서, 사용자는 Input4 컴포넌트(708)로 신규 태스크 설명을 입력하고 Button1 컴포넌트(702)를 선택하여 트리거(602)를 활성화시킬 수 있다. 유효한 입력이 수신되면, 신규 태스크 설명은 "data/tasks.xml"에 추가되고 Input3 컴포넌트(706)에 의해 자동적으로 디스플레이된다. 반대로, 사용자가 Input4 컴포넌트(708)에 아무 입력도 제공하지 않고 Button1 컴포넌트(702)를 단지 선택하면, Button2 컴포넌트(704)는 사용자가 유효한 태스크 설명을 제공할 것을 요청하는 문구와 함께 디스플레이된다.

다시 도 6A를 참조하면, 이름 속성 "bind"와 값 속성 "data/tasks.xml"를 갖는 작업(616)은 Initialize Application 프로세스 단계(604)에서 실행될 다음 작업이다. 일반적으로 설명하면, Bind 작업(616)의 실행은 Input3 컴포넌트(706)가 태스크 설명들의 목록을 디스플레이하는 데이터 바인딩 컴포넌트가 되게 한다. 특히, Bind 작업(616)에서 제공된 로직과 이에 연관된 컴포넌트 요소(618)는, Input3 컴포넌트(706)를 "data/tasks.xml" 문서에 표현된 태스크 설명들의 목록에 바인드(bind)한다. 이 예에서, 태스크는 "data/tasks.xml" 문서 안에서 연관된 설명 속성을 유지하는 요소로서 정의된다. 컴포넌트 요소(618)에 의해 제공된 로직은, Input3 컴포넌트(706)에서 디스플레이할 태스크 요소의 "/tasks/task/@description" 속성을 선택한다. 도 6A에 도시된 바와 같이, Bind 작업(616)은 Initialize Application 프로세스 단계(604)에서 실행되는 마지막 작업이다

이제 도 7B를 참조하면, Bind 작업(616)의 실행 다음의 그래픽 디스플레이(700)의 상태가 설명된다. 이에 관해, 도 7B는 도 7A를 참조하여 상술한 동일한 버튼 및 입력 컴포넌트들(702-708)을 도시한다. 그러나, Bind 작업(616)의 실행 후, 한 세트의 태스크 설명들이 Input3 컴포넌트(706)에 의해 디스플레이된다. 특히, Input3 컴포넌트(706)는 "data/tasks.xml" 문서에서 정의된 태스크 요소들의 설명 속성에 바인드된다. 따라서, Bind 작업(616)이 실행된 후, 데이터 모델(예를 들어, 문서 오브젝트(710))에 표현된, 이 태스크 설명들에 할당된 값들은 Input3 컴포넌트(706)에 디스플레이 된다.

. Initialize Application 프로세스 단계(604)를 실행하면, MyTasks.xml 문서(600)에 표현된 어플리케이션 로직의 실행은, 트리거가 활성화되기 전까지 다시 시작하지 않는다. 이 예에서, MyTasks.xml 어플리케이션은, Button1 컴포넌트(702)가 "select" 이벤트를 경험하면 실행 플로우를 프로세스 단계 "2"로 지시하는 트리거(602)를 정의한다. 따라서, 트리거는, 선택된 Button1 컴포넌트(702)에 대한 응답으로, 실행 플로우를 "Press Button"으로 명명된 프로세스 단계(606)로 지시한다. 이 예에서, 이름 속성 "decision"과 값 속성 "#MyTasks#input4"을 갖는 작업(602)은 Press Button 프로세스 단계(606)에서 실행될 작업이다. 일반적으로 설명하면, 결정 작업(620)은, Button1 컴포넌트(702)가 선택되면 어떤 텍스트가 Input4 컴포넌트(708)에 입력되었지를 결정하는 테스트를 수행한다. "<when>" XML 요소(622) 내의 로직은, Button1 컴포넌트(702)가 선택될 때 Input4 컴포넌트(708)에 텍스트가 입력되었으면, 실행 플로우를 프로세스 단계(608)로 지시한다. 반대로, 결정 작업(620)은, 트리거의 출현시 Input4 컴포넌트(708)에 텍스트가 입력되지 않았으면, 실행 플로우를 프로세스 단계(610)로 지시한다.

예에서, Input4 컴포넌트(708)로 텍스트가 입력되면, 실행 플로우는 "Add Task" 프로세스 단계(608)로 진행한다. 따라서, 이름 속성 "change"와 값 속성 "data/tasks.xml"을 갖는 작업(624)은 실행될 다음 작업이다. 변경 작업(624)은 적합한 설명 속성을 갖는 신규 태스크 요소가 "data/tasks.xml" 문서에 추가되도록 한다. 이에 관해, 변경 작업(624) 내의 "<store>" XML 요소(626)는 Input4 컴포넌트(708)에 입력된 텍스트가 신규 태스크의 설명 속성에 저장되도록 하는 로직을 제공한다.

Accordingly, 이제 도 7C를 참조하면, 신규 태스크의 입력과 Button1 컴포넌트(702)의 선택 다음의 그래픽 디스플레이(700)의 상태가 도시된다. 따라서, 도 7C는 도 7A-7B를 참조하여 상술된 동일한 컴포넌트들(702-708)을 포함한다. 이 예에서, 사용자가 텍스트 "purchase airline tickets"를 Input4 컴포넌트(708)에 의해 제공된 텍스트 영역에 입력했다. 상술한 변경 작업(624)은, 상응하는 문서 오브젝트(710)을 이용하여, 이 태스크 설명의 값을 "data/tasks.xml" 문서에 추가한다. Input3 컴포넌트(706)는, 변경 작업(624)에 의해 영향을 받는 설명 속성들의 선택에 바인드되어 있으므로, Input3 컴포넌트(706)에 의해 디스플레이된 태스크들의 목록은 문서 오브젝트(710)에서 자동적으로 업데이트된다. 다시 말해, 개발자들은, 동기화와 Input3 컴포넌트(706)와 데이터 모델 사이의 데이터 교환을 위한 어플리케이션 코드를 제공하지 않아도 된다.

일 측면에서, 사용자는 신규 태스크 설명을 Input4 컴포넌트(708)에 입력하고, Button1 컴포넌트(702)를 선택하여 태스크 목록을 업데이트할 수 있다. 또한, 사용자는, input3 컴포넌트(706)에 디스플레이된 항목들과 직접 상호작용하여 태스크 설명들을 수정할 수 있다. 예로서, 사용자는, inpu3 컴포넌트(706)에 의해 현재 디스플레이되고 있는 "update presentation" 태스크를 삭제할 수 있다. 데이터 바인딩이 정의되어 있으므로, 삭제는 자동적으로 "data/tasks.xml" 문서로 전파된다. 이에 관해, 하나 이상의 컴포넌트들 및/또는 로컬이나 원격 어플리케이션들은, "data/tasks.xml" 문서에서 표현된 태스크 설명들에 대한 데이터 리스너들일 수 있다. 각 로컬 데이터 리스너들은, 삭제중인 "update presentation" 태스크에 응답한 문서 오브젝트(710)에 의해 통지되고 업데이트된다. 특히, 태스크의 삭제는, 개발자들은 데이터 업데이트를 처리하기 위한 어플리케이션 코드를 제공하도록 요구되어지지 않으면서, 하부 데이터 모델로 전파되며, 이후 네트워크를 통해 어떠한 리스너들에게도 전파된다.

다시 도 6A를 참조하면, Button1 컴포넌트(702)가 선택될 때 텍스트가 Input4 컴포넌트(708)에 입력되지 않으면, 실행 플로우는 "Show Button" 프로세스 단계(610)로 진행한다. 따라서, 이름 속성 "action"과 값 속성 "#MyTasks"을 갖는 작업(628)은 실행될 다음 작업이다. 일반적으로 설명하면, 이 Action 작업(628)의 실행은, 처음에 감춰졌던(도 7A) Button2 컴포넌트(704)가 디스플레이 되도록 한다. MyTasks_gui.xml 문서(650)에 표시되었듯이, Button2 컴포넌트(704)는, 사용자에게 유효한 태스크 설명을 제공하도록 요청하는 텍스트 스트링을 디스플레이한다.

당업자에 의해 이해될 수 있듯이, 도6A-7C 를 참조하여 설명된 MyTasks 어플리케이션은 본 발명의 측면들을 설명하기 위해 이용될 수 있는 한 어플리케이션의 매우 간략한 예이다. 추가적인 어플리케이션들은, 네트워크 오퍼레이팅 시스템 환경 안에서 생성되고 실행될 수 있다. 따라서, 여기에서 MyTasks 어플리케이션을 참조한 예들과 설명은 예시적인 것으로 해석되어야만 한다.

현대 어플리케이션들을 개발하는데 이용되는 프로그래밍 랭귀지들(C++,Java™, Python™ 등)은 어플리케이션의 프로세스 로직에서 생성되고 유지되는 유저 인터페이스 컴포넌트들을 포함한다. 다시 말해, 개발자는, 유저 인터페이스 컴포넌트들상에서 데이터를 생성하고 설정하는 로직을 명시적으로 제공한다. 또한, 개발자는, 어플리케이션의 유저 인터페이스에 영향을 주는 이벤트를 듣거나(listen) 적어도 데이터 변경들을 모니터하는 코드를 어플리케이션의 프로세스 로직 내에서 제공한다. 이 이벤트 리스너들은, 데이터 변경들이 어플리케이션의 유저 인터페이스와 도메인 특정적인 데이터 구조 사이에서 유지되도록 한다. 그러나, 어플리케이션의 유저 인터페이스에서 데이터 구조 사이의 입력/출력은 표준화되어 있지 않다. 따라서, 어플리케이션의 유저 인터페이스 상에서 데이터의 제시는 데이터 구조 내에서 데이터가 어떻게 표현되었는가에 강하게 결합되어 있다. 결과적으로, 유저 인테피이스 또는 데이터 구조에 대한 수정들은 어플리케이션의 다른 측면들에 영향을 줄 수 있다.

네트워크 오퍼레이팅 시스템은, 유저 인터페이스와 MVC 디자인 패러다임을 고수하는 어플리케이션들의 실행을 지원하는 하부 데이터 모델 사이의 자동화된 통신 경로를 제공한다. 이에 관해, 개발자들은, 유저 인터페이스 컴포넌트(다른 프로그래밍 환경 랭귀지들에서 자주 제어 또는 위젯(widget)으로 언급됨)와 하부 데이터 모델간의 바인딩을 정의할 수 있다. 하부 데이터 모델에 대한 데이터 업데이트들과 컴포넌트들에 영향을 미치는 데이터 변경들의 조정은 본 발명에 의해 관리되므로, 어플리케이션 개발을 단순하게 한다. MyTasks 어플리케이션의 설명에서 설명되듯이, 하부 데이터 문서에서 표현된 데이터가 변경되면, 데이터 변경을 듣는 어떤 데이터 바운드 컴포넌트들은 자동적으로 업데이트된다. 더 상세하게는, MyTasks 어플리케이션의 바인드 작업(616)은 Input3 컴포넌트(706)을 데이터 모델에서 표현된 한 세트의 데이터에 바인드하는 어플리케이션 로직을 제공한다. 따라서, "update presentation" 태스크의 하부 데이터 XML 문서로부터의 삭제는, 네트워크를 통해 동일한 문서를 듣고 있는 어플리케이션들과 컴포넌트들을 포함하는 리스닝 컴포넌트들에 자동으로 전파된다. 또한, 데이터 바인딩들은, 네트워크를 통해 로컬과 원격 클라이언트들의 유저 인터페이스 컴포넌트들 사이의 데이터 교환과 동기화를 가능하게 한다. 예로서, MyTasks 어플리케이션의 변경 작업(624)은, Input4 컴포넌트(708)에 입력된 텍스트로 하부 데이터 문서를 업데이트하는 어플리케이션 로직을 제공한다. 이에 관해, Input3 컴포넌트(706)는 하부 데이터 문서에 대한 변경을 듣고 있다. Input3 컴포넌트(706)의 시각적 디스플레이는, 텍스트가 input4 컴포넌트(708)에 입력되고 트리거(602)가 활성화되면 업데이트된다. 이 예에서, 데이터 바인딩과 변경 작업(624)의 조합은 유저 인터페이스 컴포넌트들간의 데이터의 동기화된 교환을 가능하게 한다.

상술한 바와 같이, 바인딩은, 유저 인터페이스 컴포넌트들과 하부 데이터 모델 사이의 자동화된 통신 경로를 제공한다. 일 측면에서, 본 발명은, 유저 인터페이스 컴포넌트들 사이에서 바인딩이 공유 및/또는 전달될 수 있도록 한다. 본 발명의 이 측면은 도 8A-B에 표현되어 있는데, 사용자의 파일 시스템 폴더들의 서로 다른 시각적 표현들을 디스플레이하도록 설정된 컴포넌트들(800, 850)을 도시하고 있다. 특히, 도 8A는, 사용자의 폴더를 트리 구조로 디스플레이하도록 설정된 컴포넌트(800)을 도시한다. 사용자가 폴더들이 목록으로 디스플레이하도록 요청하는 입력을 생성하면, 하부 데이터 모델에 대한 컴포넌트(800)의 데이터 바인딩은 컴포넌트(850)로 전달되며, 컴포넌트(800)의 상태 또한 전달된다. 이 예는 본 발명이 데이터 모델의 설정으로부터 데이터의 표현과 처리 사이의 의존성을 제거했음을 설명한다. 또한, 데이터 바인딩의 전달과 공유는, MVC 디자인 패러다임에 따른 어플리케이션 계층간 자동화된 통신 경로를 제공할 뿐만 아니라, 개발중인 어플리케이션에 대한 개량된 플랫폼을 제공한다.

본 발명은 한 세트의 유저 인터페이스 컴포넌트들(예를 들어, 버튼들, 입력 박스들, 드롭다운 박스들, 디스플레이 패널 등)을 제공한다. 어플리케이션 개발을 가능하게 하기 위해, 표준 프레임워크는, 어플리케이션들이 관련된 유저 인터페이스 컴포넌트들로부터 구축되도록 한다. 이에 관해, 유저 인터페이스 컴포넌트들은, UI XML 랭귀지를 이용하여 페어런트 컴포넌트 (parent component)로부터 속성(property)들을 상속할 수 있으므로, 더욱 복잡한 유저 인터페이스 요소들을 표현하기 위해 결합될 수 있다. 결과적으로, 어플리케이션은, 각 컴포넌트가 연관된 문서를 인지하는 계층적 구조로 조직된 관련 컴포넌트들의 한 세트를 포함할 수 있다. 다른 실시예에서, 단일 유저 인터페이스 컴포넌트는, 어플리케이션의 전체 뷰를 표현하도록 정의될 수 있다. 또한, 개발자들이 본 발명과 함께 사용하기 위한 새로운 유저 인터페이스 컴포넌트들을 생성할 수 있도록 하는 컴포넌트 API(Application Programming Interface)가 제공된다.

일 측면에서, 본 발명은, XML 랭귀지를 이용하여 프로세스 지향적인(process-oriented) 어플리케이션들의 개발을 지원한다. 이에 관해, MyTasks.xml 문서(600)의 각 프로세스 단계는 프로세스 실행 플로우의 부분을 표현한다. 프로세스 단계 내의 작업들은 실행중인 어플리케이션에서의 상태 변화를 정의할 수 있다. 프로세스들간의 통신들은, 어플리케이션의 런타임 상태를 설명하는 데이터에 대한 제어된 접속을 통해 그리고 메시징 포트들의 이용을 통해 지원된다. 개발자들은, 뷰들, 컴포넌트들, 및 전역적으로 명명된(globally-named) 오브젝트들을 이용하는 익스프레션들(expressions)을 가진 다른 런타임 변수들을 참조할 수 있다. 이에 관해, 오브젝트를 참조하고 조작하는 익스프레션 랭귀지 또는 일반적인 방법이 제공된다. 일반적으로 설명하면, 익스프레션들 및 프로세스 XML 랭귀지들은 실행중인 멀티 인스턴스 어플리케이션들의 복잡성을 집합적으로 추상화한다. 대신에, 개발자들은, 어플리케이션이 단일 인스턴스 실행시 존재하는 것처럼 어플리케이션을 생성할 수 있다. MyTasks.xml 문서(600)가 설명하듯이(도 6A), 익스프레션들은 XML 신택스와 호환되도록 구조화되며 다른 프로그래밍 랭귀지 내에서 사용되기 위해 범위가 정해지거나 태그가 붙여진다. 익스프레션이 이밸류에이션되면, XML 가상 머신은, 수신된 익스프레션에 따라 요청된 데이터를 식별, 병합, 및 조작하는 태스크를 수행한다. 결과적으로, 전역적으로 명명된 오브젝트들은, 어플리케이션의 다중 런타임 인스턴스들이 실행되더라도 어플리케이션 코드 내에서 개발자들에 의해 이용될 수 있다.

본 발명은, 어떤 "오브젝트들"이 인스턴스화될 것인지로부터 복수의 "클래스들"로 구현되는 클라이언트측 컴포넌트를 제공한다. 다시 말해, 클라이언트측 컴포넌트는, 객체 지향적 프로그래밍 특징을 이용하는 JavaScript와 같은 프로그래밍 랭귀지를 이용하여 구현될 수 있다. 다른 실시예에서, 본 발명은, C 프로그래밍 랭귀지와 같은 비 객체 지향적 랭귀지나 구조들이 오브젝트들로 표현될 수 있는 다른 랭귀지를 이용하여 구현될 수 있다. 당업자에 의해 이해될 수 있듯이, 클래스로부터 생성된 오브젝트들은, 그 오브젝트의 기능성을 구현하는 알고리즘을 캡슐화하거나 감추는 메소드들을 전형적으로 포함한다. 이 구현 상세를 공개하는 대신에, 오브젝트들은, 다른 모듈들이 추상적으로 그 기능성에 접속할 수 있는 인터페이스들을 제공한다. 따라서, 본 발명의 일 실시예에 따른 XML 가상 머신을 구현한 기능성은, 객체 지향(object orientation)과 상속을 이용하는 오브젝트들의 컨텍스트에 존재한다.

상술한 바와 같이, 클라이언트측 컴포넌트는, XML 신택스를 고수하는 랭귀지들로 작성된 어플리케이션들을 실행하는 XML 가상 머신 역할을 한다. 실제 실시예에서, XML 가상 머신은, 프로세스 모델링 랭귀지(예를 들어, 프로세스 XML 랭귀지), 유저 인터페이스 모델링 랭귀지(예를 들어, UI XML 랭귀지) 및 어플리케이션 패키지 모델링 랭귀지(예를 들어, 어플리케이션 패키지 XML 랭귀지)로 시맨틱하게 설명된 어플리케이션 코드를 실행하도록 설정된다. 특히, XML 가상 머신은, 여기서 설명되지 않은 기능성을 제공하는 추가적인 XML 랭귀지들이나 XML 기반 어플리케이션들을 이해하기 위해 확장될 수 있다. 또한, 여기서 설명된 XML 랭귀지들을 이용한 프로그래밍 로직을 실행하는 대신에, 다른 실시예들이 가능하다. 예를 들어, JavaScript API 또는 라이브러리들은 동일한 기능성을 구현한 어플리케이션들을 구축하는데 이용될 수 있다. 따라서, XML 기반 랭귀지들의 이용은 단순히 예시적이며, 본 발명은 전통적인 프로그래밍 랭귀지들을 이용해서도 구현될 수 있다.

언제든지, XML 가상 머신에 의해 해석중인 어플리케이션은 특정 실행 상태에 있는 것으로 이해될 수 있다. 프로세스 XML 랭귀지는, 개발자들이 상태들 사이에서 천이하기 위한 조건들을 정의할 수 있도록 한다. 무엇보다도, XML 가상 머신은, (1) 실행중인 어플리케이션의 상태를 설명하는 런타임 변수들/오브젝트들의 한 세트를 정의, (2) 어플리케이션 상태에 천이가 발생하면 구동하는 로직을 구현, (3) 어플리케이션 상태에 적절한 변경을 구현하는 하위 레벨 구조체들(constructs)을 제공함으로써, 상태 천이들을 관리하는 기능성을 구현한다.

이제 도 9를 참조하면, XML 가상 머신을 구현하는 클라이언트측 컴포넌트와 클래스들과 오브젝트들의 측면들이 설명된다. 클라이언트측 컴포넌트는, 네트워크 오퍼레이팅 시스템의 클라이언트측 컴포넌트의 시동시 인스턴스화되고 사용자 세션 동안 활성화를 유지하는 복수의 "매니저" 또는 오브젝트들을 포함한다. 상술한 바와 같이, 예시적인 실시예에 따라 클라이언트측 컴포넌트에 의해 제공된 오브젝트들은, 객체 지향과 상속을 이용한다. 이에 관해, 매니저들과 다른 오브젝트들이 런타임시 임베디드되는 플레이스 홀더 역할을 하는 시스템 컨텍스트 오브젝트(902)는 인스턴스화된다. 따라서, 시스템 컨텍스트 오브젝트(902)는, 어플리케이션 매니저(904), 프로세스 매니저(906), 뷰 매니저(908), 트랜잭션 매니저(910), 문서 매니저(912) 및 이벤트 매니저(914)를 포함하는 도 9에 도시된 매니저들의 인스턴스들을 생성하는데 이용될 수 있다.

각 매니저는 시스템 컨텍스트 오브젝트(902)로부터 접속 가능한 인터페이스를 통해 노출된 특정 태스크를 전형적으로 수행한다. 따라서, 본 발명에 의해 구현된 다른 오브젝트들은, 원하는 태스크를 수행하는 매니저의 기능성을 호출하고 사용할 수 있다. 예를 들어, 프로세스 매니저(906)는, 어플리케이션의 프로세스 코드를 실행할 준비중인 프로세스 오브젝트의 인스턴스화하도록 호출될 수 있다. 다른 측면에서, 매니저들은, 내부 어플리케이션 및 내부 프로세스 보안의 기초를 제공하는 제어된 인스턴스 생성과 오브젝트들간의 통신을 허용한다. 여기서 설명이 특정 매니저들 및 매니저가 수용한 연관된 오브젝트들을 참조하여 제공되었지만, 당업자라면 특정 종류의 매니저로의 기능성의 캡슐화는 예시적인 것임을 이해할 것이다. 다른 실시예들에서, 특정 매니저들 및 그들의 대응되는 오브젝트들에 관련되어 여기서 설명된 기능성은, 캡슐화되지 않고 수행되거나, 설명된 것과 다른 방법으로 캡슐화될 수 있다. 또한, 다른 툴들이 청구된 주제의 범위를 벗어나지 않고도 이용될 수 있는 것과 같이, 여기서 설명된 객체 지향적 프로그래밍 랭귀지들과 특징들은 단지 예시적이다.

도 9에 도시된 바와 같이, 클라이언트측 컴포넌트는, 어플리케이션의 수명(lifecycle)을 관리하는 로직을 제공하는 어플리케이션 매니저(904)를 포함한다. 이에 관해, 함수들은, 어플리케이션들을 생성하고, 오픈하고, 종료하기 위해 어플리케이션 매니저(904)에 의해 노출된다. 어플리케이션은, 어플리케이션 매니저(904)에 "등록"하는 어플리케이션 오브젝트로서 내부적으로 표현될 수 있다. 어플리케이션이 실행하도록 스케쥴되면, 어플리케이션 매니저(904)는 상응하는 어플리케이션 오브젝트를 생성하도록 호출될 수 있다. 따라서, 어플리케이션 매니저(904)는 시스템 내에서 모든 활성화된 어플리케이션들에 대한 참조들을 생성하고 수용한다.

상술한 바와 같이, 하나 이상의 어플리케이션들의 속성들은, 개발자에 의해 어플리케이션 패키지 XML 랭귀지를 이용하여 어플리케이션 페이지에서 시맨틱하게 설명될 수 있다. 어플리케이션 패키지에 설명된 속성들은 실행할 특정 어플리케이션에 의해 이용될 자원들과 시스템 설정들에 대한 참조들을 포함한다. 어플리케이션 패키지에서 식별된 자원들은 어플리케이션 뷰와 프로세스 로직의 시맨틱한 설명을 제공하는 XML 문서들을 포함한다. 일 측면에서, 어플리케이션 매니저(904)는, 어플리케이션이 실행하도록 스케쥴되면, 적합한 어플리케이션 패키지에서 정보를 추상화하고 식별된 자원들을 획득하도록 설정된다. 다른 실시예에서, UI와 프로세스 XML문서들을 포함하는, 어떤 XML 데이터 자원은 어플리케이션 패키지로 직접 임베디드될 수 있다. 다른 측면에서, 클라이언트가 "오프라인"이 될 때 어플리케이션들이 실행을 계속하도록 하는 기능성은 어플리케이션 매니저(904)에 의해 구현된다. 이에 관해, 적합한 어플리케이션 패키지가 대응하는 어플리케이션에 의해 사용된 자원들을 식별하는 어플리케이션 매니저(904)에 의해 참조될 수 있다. 이후, 로컬에서 일시 저장되지 않은 어떤 자원들이 식별되고 적합한 서비스 제공자로부터 획득된다.

도 9에 도시된 프로세스 매니저(906)는, 어플리케이션에서 프로세스 단계들을 실행하는데 이용되는 내부 프로세스 오브젝트들의 생성과 수용을 담당한다. 상술한 바와 같이, 프로세스 XML 랭귀지로 작성된 어플리케이션 로직은, 각각이 하나 이상의 작업들을 포함하는 일련의 프로세스 단계를 정의한다. 프로세스 매니저(906)에 의해 생성되고 수용되는 프로세스 오브젝트는 루프 쓰루(loop through) 및 하나 이상의 하위 레벨 구조체들이나 작업 핸들러들의 호출을 담당한다. 전통적인 플랫폼들과 달리, 네트워크 오퍼레이팅 시스템의 개념적인 기초는 하위 레벨 구조체들을 모델링하는 프로세스 지향적 작업들에 근거한다. 예를 들어, 모델 워크플로우들, 프로덕트 수명 관리, 사용자 협업 등과 같은 상위 레벨 구조체들은, 이 하위 레벨 구조체로부터 구축된다. 예로서, 본 발명에 의해 제공된 하위 레벨 구조체를 모델링하는 한 세트의 작업 핸들러들은, 오픈 작업 핸들러, 바인드 작업 핸들러, 변경 작업 핸들러, 결정 작업 핸드러 등을 포함하지만, 여기에 한정되지는 않는다. 또한, 개발자들이 추가적인 작업 핸들러들을 정의할 수 있도록 하는 작업 API가 제공된다. 이 방법으로, XML 가상 머신은 추가적인 하위 레벨 구조체들을 지원하고 실행하도록 확장될 수 있다. 한편, 어플리케이션에서 사용될 수 있는 작업들은 작업 API들에 따라 생성되거나 본 발명에 의해 제공된 작업들에 한정된다. 결과적으로, 오직 제한되고 잘 정의된 세트의 작업들이 어플리케이션 로직을 실행할 수 있으므로, 악성 소프트웨어를 생성하거나 악의적인 기능성을 구현하는 사용자의 능력은 심각하게 제한된다. 한편으로는, XML 문서를 조작할 수 있는 제한된 수의 방법들이 있기 때문에, 상대적으로 적은 수의 작업들이 제공될 필요가 있다. XML이 매우 일반적인 랭귀지이므로, 어떤 어플리케이션이나 도메인은 그 랭귀지를 이용하여 설명될 수 있다. 따라서, 본 발명에 의해 제공된 프로세스 XML 랭귀지와 그에 대응하는 작업들은 어떠한 수의 프로세스 로직을 설명할 수 있으며, 어떠한 종류의 어플리케이션을 설명하는데 이용될 수 있다.

일 실시예에 따르면, 실행중인 어플리케이션 또는 인스턴스의 "런타임 상태"를 추적하는 인스턴스 오브젝트는 본 발명에 의해 제공된다. 당업자라면 실행중인 어플리케이션의 런타임 상태는 로직이 실행되므로 지속적으로 발달할 수 있음을 이해할 수 있다. 인스턴스 오브젝트는 실행중인 어플리케이션의 런타임 상태를 추적하고 관리하며, XML 가상 머신을 구현하는데 이용된 다른 오브젝트들에 컨텍스트를 제공한다. 따라서, 인스턴스 오브젝트들은 작업의 의미를 프로세스들의 실행과 그들에 연관된 작업들에 결합한다. 결과적으로, 어플리케이션 인스턴스의 런타임 상태가 지속적으로 변경하더라도, 작업 핸들러들은 이 변경들을 설명하는 데이터를 공급받는다. 이 방법으로, 본 발명은, 상태가 없는 프로세스 오브젝트들을 사용하는 어플리케이션 로직의 동적인 실행을 지원한다. 다른 말로, 어플리케이션의 복수 인스턴스가 존재하더라도, 어플리케이션 코드의 단일 버전만이 필요하므로, 메모리를 절약할 수 있다.

도 9에 도시된 바와 같이, 클라이언트측 컴포넌트는 "뷰" 또는 실행중인 어플리케이션에 연관된 유저 인터페이스의 추적을 담당하는 뷰 매니저(908)를 포함한다. 어플리케이션의 유저 인터페이스를 렌더링하고 업데이트하는데 이용되는 내부 뷰 오브젝트를 생성하는 메소드들이 뷰 매니저(908)에 의해 제공된다. MVC 디자인 패러다임에 따라서, 어플리케이션의 유저 인터페이스는 UI XML 랭귀지를 이용하여 시맨틱하게 설명될 수 있다. 따라서, 컴포넌트들과 어플리케이션의 완전한 유저 인터페이스의 다른 그래픽 속성들은 UI XML 문서에 표현될 수 있다. 뷰 매니저(908)에 의해 인스턴스화되고 수용되는 뷰 오브젝트들은 UI XML 문서에 시맨틱하게 설명된 유저 인터페이스들을 렌더링하는데 이용된다. 일 실시예에서, 유저 인터페이스의 렌더링은 일련의 XML 트랜스포메이션들(transformations)을 통해 수행될 수 잇다. 그러나, 당업자라면 유저 인터페이스는 XML 트랜스포메이션들을 수행하지 않고도 렌더링 될 수 있으며 상술한 설명은 예시적인 것으로 해석되어야 한다는 것을 이해할 수 있다. 어떤 경우에도, 뷰 매니저(908)는 새로운 뷰 오브젝트들을 생성하고 시스템 내의 모든 활성화된 뷰들에 대한 참조를 수용하도록 설정된다.

도 9에 도시된 바와 같이, 클라이언트측 컴포넌트는 문서 오브젝트들의 인스턴스의 생성 및 문서 오브젝트들에 대한 참조의 수용을 담당하는 문서 매니저(912)를 포함한다. 상술한 바와 같이, XML 문서들은, 네트워크 오퍼레이팅 시스템 환경에서 공동 데이터 소스의 역할을 하는 데이터 모델이다. 어플리케이션 로직, 시스템 설정들, 어플리케이션 상태 등도 XML 문서들에서 표현된다. 일 측면에서, 문서 매니저(912)는, 클라이언트 컴퓨터 상의 메모리에 문서들이 로딩되거나 일시 저장되도록 하는 것을 담당한다. 따라서, 문서 매니저(912)는 문서들을 획득하기 위해 통신 매니저(이하에서 설명됨)와 같은 다른 매니저들과 상호작용할 수 있다. 문서들은 통신 채널 또는 로컬 하드 드라이브 상에 또는 클라언트 컴퓨터 상의 비휘발성 메모리에 유지되는 문서들에 접속하기 위해 생성될 수 있는 채널을 사용하여 원격 네트워크 위치로부터 획득될 수 있다. 다른 측면에서, 문서 매니저(912)는, 클라이언트 컴퓨터 상의 메모리에 로딩된 각 문서를 추적하는 클라이언트측 캐시 역할을 한다. 문서가 로컬에서 획득되면, 문서의 구조 객체 지향적 표현(structured object-oriented representation)을 제공하는 내부 문서 오브젝트가 인스턴스화될 수 있다. 이에 관해, 문서 매니저(912)는 시스템 내의 모든 문서 오브젝트들에 대한 참조들을 수용하며, 다른 것들 중에서, XML 문서들을 생성하고, 검색하고, 저장하고, 이름을 변경하는 메소드들을 노출한다.

도 9에 시각적으로 도시된 이벤트 매니저(914)는, XML 가상 머신의 측면들이 트리거의 활성화에 대한 응답으로 어플리케이션 로직을 실행하도록 하는 트리거 이벤트 버스 역할을 한다. 한편, 프로세스 오브젝트는, 트리거를 이벤트 매니저(914)에 리스너로 등록하는 노티파이어(notifier) 오브젝트를 이용할 수 있다. 컴포넌트 오브젝트들과 같은 시스템 내의 다른 오브젝트들은 자주 자기를 리스너로 이벤트 매니저(914)에 직접 등록한다. 무엇보다도, 노티파이어 오브젝트는, 활성화된 트리거에 대한 응답으로 실행될 어플리케이션 내의 프로세스 단계를 식별하는 데이터를 수신하고 저장한다. 또한, 노티파이어 오브젝트에 의해 제공된 데이터는 트리거를 오리지네이팅(originating) 오브젝트(즉, 종종 뷰 또는 컴포넌트 오브젝트)에 연관시킨다. 한편, 이벤트 매니저(914)는, 트리거가 활성화되면, 오브젝트들(즉, 뷰 또는 컴포넌트 오브젝트)이 등록된 리스너들을 푸쉬하거나 통지하도록 한다. 이 예에서, 컴포넌트 오브젝트는 이벤트 매니저(914)에 통지하고 데이터를 패스한다. 응답으로, 이벤트 매니저(914)는 활성화된 이벤드에 대한 리스너들을 식별하는 룩업(look-up)을 수행한다. 이후, 적합한 노티파이어 또는 다른 리스닝 오브젝트들은 경보를 받고, 어플리케이션 실행이 적합한 프로세스 단계로 진행하도록 하는 데이터를 제공받을 수 있다. 이하에서 상세히 설명되듯이, 개별 어플리케이션 인스턴스들은 동일한 세트의 트리거들과 노티파이어 오브젝트들을 각각 이용할 수 있다. 이 방법으로 동일한 자원들을 재사용하도록 설정된 이벤트 매니저(914) 및 관련된 시스템들의 제공은 성능을 향상시키면서 사용되는 메모리를 감소한다.

여기서 사용되는, "트리거"는 어플리케이션 코드가 실행되도록 하는 정의된 트리거링의 존재를 나타낸다. 따라서, 도 6A를 참조하여 상술한 예시적인 프로세스 XML 문서(600)에서, 트리거(602)의 활성화는, 어플리케이션 코드에 정의된 특정 프로세스 단계가 실행되도록 한다. 현존하는 시스템에 비해, 본 발명에 의해 구현된 트리거들은 데이터 업데이트의 존재시 정상적으로 활성화되지 않는다. 다시 말해, 데이터 바인딩과 같은 특정하는 작업들 이외에, 개발자들은 어플리케이션 유저 인터페이스로부터 데이터 모델로의 입력과 출력을 관리하는 로직을 제공하도록 요구되지 않는다. 대신에, 데이터 업데이트들은, 개별 데이터 업데이트 통지 이벤트 버스에 의한 본 발명에 의해 관리되며, 트리거의 활성화에 대응하지 않는다. 이하에서 상세히 설명되듯이, 본 발명의 측면들은, 컴포넌트들과 오브젝트들에 대한 데이터 업데이트의 전파를 자동적으로 처리하는 문서 오브젝트에 구현된 개별 이벤트 버스를 제공한다.

도 9에 또한 도시된 트랜잭션 매니저(910)는 XML 문선의 컨텐츠를 업데이트하는데 이용되는 트랜잭션들을 생성하고 전파하는 인터페이스를 제공한다. 따라서, 데이터 모델에 대한 변경이 수행되면, 이는 트랜잭션을 초래한다. 이에 관해, 트랜잭션은 상대적인 변경을 표현하며 데이터 모델에 대한 변경을 구현하거나 원상태로 회복하는데 이용되는 데이터를 포함하는 XML 데이터 조각(fragment)으로 표현될 수 있다. 예를 들어, 도 6A를 참조하여 상술한 MyTasks 어플리케이션에서, 하부 데이터 XML 문서에 태스크를 추가하는 변경 작업(624)은 트랜잭션의 생성을 초래한다. 트랜잭션에 반영된 데이터 업데이트는 어떤 원격 리스너들 뿐만이 아니라 데이터 모델에서도 지속될 수 있다. 일 실시예에서, 트랜잭션 매니저(910)는, 트랜잭션이 생성된 순서를 식별할 뿐만 아니라 트랜잭션에 표현된 데이터 업데이트를 "롤백"하는데 이용될 수 있는 트랜잭션이 언제 생성되었는지에 관한 식별 및 타임 스탬핑 데이터를 포함한다.

이제 도 10A를 참조하면, 어플리케이션 패키지를 오픈하는 프로세싱을 수행하는 어플리케이션 시작 루틴(1000)이 설명된다. 어플리케이션 시작 루틴(1000)은, 어플리케이션을 시작하는 명령을 생성한 사용자에 응답하여 수행될 수 있다. 상술한 바와 같이, 본 발명의 측면들은, 사용자가 메뉴 아이템, 아이콘 등의 선택을 통해 어플리케이션들을 시작할 수 있는 데스크탑 환경을 제공할 수 있다. 이 종류의 명령을 수신한 것에 대한 응답으로, 시스템 컨텍스트 오브젝트(902) 내부의 데이터 종류 인식자(data type recognizer)에 어플리케이션 패키지, XML 문서 또는 바이너리 파일에 연관된 위치를 식별하는 URL이 패스될 수 있다. 이하에서 상세히 설명되듯이, 데이터 종류 인식자는, 동작들을 식별하여 특정 종류의 문서들에 연관시키는 다양한 방법에 이용된다. 어떤 경우에도, 어플리케이션 시작 루틴(1000)은, 데이터 종류 인식자가 어플리케이션 패키지(예를 들어, 어플리케이션 패키지 XML 문서)에 대응하는 문서가 오픈되었다고 결정하면 수행될 수 있다.

도 10A에 도시된 어플리케이션 시작 루틴(1000)에서, 어플리케이션 매니저(904)는, 블록(1002)의 어플리케이션 오브젝트를 인스턴스화 하는데 이용된다. 각각이 다른 어플리케이션을 표현하는 다중 어플리케이션 오브젝트들은, 인스턴스화되고 어플리케이션 매니저(904)에 수용된다. 어플리케이션 시작 루틴(1000)을 통한 이 반복에서, 예를 들어 워드 프로세싱 프로그램을 표현하는 제1 어플리케이션 오브젝트가 인스턴스화될 수 있다. 어플리케이션 시작 루틴(1000)을 통한 다른 반복에서, 다른 프로그램(예를 들어, 이메일 프로그램)을 표현하는 제2 어플리케이션 오브젝트가 인스턴스화될 수 있다. 어플리케이션 오브젝트들에 대한 인스턴스 생성과 접속을 제어함으로써, 한 어플리케이션에 연관된 프로세스 로직은, 다른 어플리케이션에 연관된 내부 오브젝트들(예를 들어, 뷰 오브젝트들, 인스턴스 오브젝트, 프로세스 오브젝트 등)에 접속할 수 없다. 따라서, 워드 프로세싱 프로그램의 프로세스 로직을 실행할 때, 이메일 어플리케이션 패키지에 연관된 뷰 오브젝트는 접속할 수 없다. 이하에서 상세히 설명되듯이, 어플리케이션 오브젝트들를 인스턴스화하고 수용하는 어플리케이션 매니저(904)의 이용은 내부 어플리케이션 및 내부 프로세스 보안 모두를 보장하는 본 발명에 의해 제공된 더 큰 프레임워크의 일부이다.

블록(1004)에서, 대응하는 어플리케이션 패키지에서 특정된 오픈중인 어플리케이션의 자원들이 획득된다. 본 발명에 따라 형성된 어플리케이션 패키지 내의 로직은 자원들과 어플리케이션 설정의 전체 청사진을 제공한다. 따라서, 어플리케이션 패키지 XML 문서는, 다른 것들 중에서, 이미지들, 데이터 문서들, XSLT 문서들과 같은 다른 어플리케이션 자원들뿐만이 아니라, 어플리케이션에 연관된 프로세스와 UI XML문서들을 식별할 수 있다. 어플리케이션 패키지 XML 문서 자체를 포함한, 어플리케이션에 의해 이용되는 자원들은, 클라이언트 상의 메모리에 일시 저장되거나, 통신 채널(이하에서 설명됨)을 이용하여 서비스 제공자로부터 획득될 수 있다. 자원 및 설정 관리에 더하여, 어플리케이션 패키지 XML 랭귀지는, 개발자들이 어플리케이션 패키지들을 더 발전된 방법으로 설정할 수 있도록 한다. 예로서만, 어플리케이션 패키지 XML 문서 내의 조건부 로직은, 자원들이 패일오버 네트워크 위치(failover network location)로부터 획득되는 더욱 폴트-톨러런트(fault-tolerant) 네트워크 서비스를 구현하는데 이용될 수 있다. 주 네트워크 위치를 이용할 수 없는 경우에, 어플리케이션 패키지는 자원들을 획득할 수 있는 대체 네트워크 위치들을 식별할 수 있다. 그러나, 이는, 본 발명이 개발자들로 하여금 패키지 XML 랭귀지를 이용하여 어플리케이션 패키지를 설정하도록 하는 방법의 단지 한 예일 뿐이다.

도 10A에서 설명되듯이, 블록(1006)에서, 어플리케이션 시작 루틴(1000)은 어플리케이션의 추가적인 런타임 인스턴스(들)이 허용되었는지를 결정한다. 어플리케이션 패키지 XML 랭귀지는 개발자들이, 생성될 수 있는 어플리케이션 인스턴스들의 숫자를 제한하는 설정을 설정할 수 있도록 한다. 따라서, 블록(1006)에서 만들어진 결정은 어플리케이션 패키지 XML에 정의된 설정에 종속될 수 있다. 블록(1006)에서, 추가적인 인스턴스가 허용되지 않는다는 결정이 만들어지면, 어플리케이션 시작 루틴(1000)은 추가적인 인스턴스를 허용하지 않는 어플리케이션을 시작하는 명령이 처리되는 블록(1008)로 진행한다. 이에 관해, 블록(1008)에서의 명령 핸들링은 어플리케이션의 현존하는 런타임 인스턴스의 리프레싱(refreshing)을 포함할 수 있다. 추가적으로 또는 다른 실시예에서, 명령 핸들링은 어플리케이션의 추가적인 인스턴스가 허용되지 않는다는 다이얼로그를 통해 사용자에게 통지하는 것을 포함할 수 있다. 이후, 명령을 처리할 때, 어플리케이션 시작 루틴(1000)은 종료하는 블록(1014)로 진행한다.

. 한편, 블록(1006)에서 만들어진 결정이 어플리케이션의 추가적인 인스턴스를 허용하면, 어플리케이션 시작 루틴(1000)은 블록(1010)으로 진행한다. 블록(1010)에서, 시작된 어플리케이션의 런타임 상태를 추적하고 관리하는 인스턴스 오브젝트가 인스턴스화된다. 프로세스와 뷰 오브젝트들이 생성되면, 본 발명의 측면들은 이 오브젝트들을 그들에 상응하는 인스턴스에 연관시킨다. 블록(1010)에서 인스턴스화된 인스턴스 오브젝트는 프로스세와 뷰 오브젝트들, 앨리어스들, 및 다른 런타임 변수들을 추적하는 구조들을 유지한다. 따라서, 이 어플리케이션 인스턴스에 연관된 프로세스와 뷰 오브젝트들은 인스턴스 오브젝트에 잘 알려진다. 제어된 인스턴스 생성과 오브젝트들의 참조를 통해, 어플리케이션 인스턴스의 경계를 한정하는 로컬화된 관계 계층구조가 설정될 수 있다. 이하에서 설명되듯이, 이 프레임워크는 프로세스와 뷰 오브젝트들을 상응하는 인스턴스에 연관시키고 로컬화된 관계 계층구조 밖에서 이 오브젝트들에 대한 접속을 한정한다.

블록(1010)에서 인스턴스화된 오브젝트에 의해 제공된 컨텍스트는 어플리케이션 런타임 상태에 관한 기능성이 구현되도록 한다. 일 측면에서, 인스턴스 오브젝트는, 해석중인 어플리케이션 코드에서 접한 익스프레션들을 이밸류에이션하는 로컬 익스프레션 엔진을 인스턴스화하고 수용한다. 프로세스 오브젝트는 상응하는 인스턴스 오브젝트 및 익스프레션을 이밸류에이션하기 위해 인스턴스가 포함하고 있는 로컬 익스프레션 엔진을 이용할 수 있다. 또한, 블록(1010)에서 인스턴스화된 인스턴스 오브젝트는, 작업의 의미를 프로세스 로직의 실행에 결합하기 위해 작업들을 실행할 때 제공될 수 있다.

도 10A에서 상세히 설명되듯이, 블록(1012)에서, 블록(1002)에서 인스턴스화된 어플리케이션 오브젝트는 어플리케이션의 프로세스와 뷰 로직의 실행을 오픈하고 시작하는데 이용될 수 있다. 프로세스와 UI XML 문서들 내의 로직의 실행을 오픈하고 시작하는 루틴들은 이하에서 설명되며 여기서는 제공되지 않는다. 중요하게, 매번 어플리케이션 패키지에 연관된 어플리케이션이 시작될 때, 새로운 인스턴스 오브젝트가 어플리케이션의 런타임 상태를 추적하기 위해 제공된다. 예를 들어, 워드 프로세싱 프로그램을 표현하는 어플리케이션 오브젝트는 워드 프로세싱 어플리케이션이 시작될 때마다 다른 인스턴스 오브젝트를 제공한다. 이 방법으로 어플리케이션 오브젝트를 이용함으로써 본 발명의 측면들은 실행중인 어플리케이션에 연관된 오브젝트들에 대한 접속을 제어할 수 있다. 이후, 어플리케이션 시작 루틴(1000)은 종료하는 블록(1004)로 진행한다.

이제 도 10B를 참조하면, 어플리케이션들을 캡슐화하고 내부 어플리케이션 보안을 제공하는 어플리케이션 오브젝트의 사용은 추가적으로 상세하게 설명된다. 어플리케이션 패키지로부터 어플리케이션이 시작되면, 어플리케이션 매니저(904)는 어플리케이션의 캡슐화된 표현을 제공하는 어플리케이션 오브젝트를 인스턴스화한다. 도 10B에서 설명되듯이, 어플리케이션 매니저(904)는 Application Object A(1030)와 Application Object B(1032)를 인스턴스화할 수 있다. 일 실시예에서, 어플리케이션 오브젝트는 하나 이상의 인스턴스 오브젝트들를 인스턴스화하고 수용할 수 있다. 도 10B에 도시된 예에서, Application Object A(1030)는 Instance Object A1(1035), Instance Object A2(1038), 및 Instance Object AN(1040)를 인스턴스화하고 수용할 수 있다. 유사하게, Application Object B(1032)는 Instance Object B1(1042) 및 Instance Object BN(1044)를 인스턴스화하고 수용할 수 있다. 이에 관해, 도 10B에 도시된 오브젝트들간의 일방향 화살표는, 화살표가 시작된 소스 오브젝트가 화살표에 의해 식별된 데스티네이션 오브젝트를 수용함을 나타낸다. 따라서, 어플리케이션 매니저(904)로부터 어플리케이션 오브젝트들(1030-1034)로의 화살표는 이 오브젝트들이 어플리케이션 매니저(904)에 수용됨을 나타낸다. 도 10B의 설명으로부터, 어플리케이션 매니저(904), 어플리케이션 오브젝트들(1030-1034) 및 그들의 상응하는 인스턴스 오브젝트들(1036-1044)간의 관계가 명확해진다.

도 10B에 도시된 오브젝트들간의 관계는 본 발명이 내부 어플리케이션 보안을 보장할 수 있는지를 설명한다. 어플리케이션 오브젝트들에의 접속은, 어플리케이션들을 생성하고, 오픈하고, 종료하는 메소드들을 노출한 어플리케이션 매니저(904)에 의해 제어된다. 어플리케이션 오브젝트가 인스턴스화되면, 어플리케이션 매니저(904)는 어플리케이션 오브젝트를 분리된 메모리 공간으로 고립시킨다. 어플리케이션 오브젝트들이 메모리 공간을 공유하는 것을 방지함으로써, 한 어플리케이션으로부터의 코드는, 다른 어플리케이션에 할당된 메모리 공간에 주입되거나 영향을 미칠 수 없다. 또한, 어플리케이션 오브젝트는, 어플리케이션에 연관된 내부 데이터가 감춰진 어플리케이션의 캡슐화된 표현을 제공한다. 어플리케이션의 기능성과 내부 데이터로의 접속 모두는 노출된 메소드들의 생성을 통해 제어된다. 이러한 방법으로 어플리케이션들을 격리하고 캡슐화함으로써, 한 어플리케이션에 연관된 내부 오브젝트들(예를 들어, 뷰 오브젝트들, 인스턴스 오브젝트, 프로세스 오브젝트 등)은 다른 어플리케이션에게는 접속되어질 수 없게 된다. 따라서, Application Object A(1030)를 이용하는 코드를 실행하면, Application Object B(1032)에 연관된 내부 오브젝트들은 접속될 수 없다. 어플리케이션의 내부 데이터가 접속될 수 없더라도, 데이터는 하부 데이터 모델을 이용하여 공유될 수 있다. 따라서, 사용자가 충분한 접속 권한들을 가지면, 문서는 다중 어플리케이션에 의해 공유될 수 있다. 다시 말해, 본 발명에 의해 제공된 내부 어플리케이션 보안 프레임워크는 하부 데이터 모델을 이용하는 어플리케이션들 사이에서의 데이터의 인가된 고유를 금지하지 않는다.

. 이제 도 10C를 참조하면, 로컬화된 관계 계층구조를 구현하기 위한 인스턴스 오브젝트들의 사용이 추가적으로 상세하게 설명된다. 로컬화된 관계 계층구조를 정의함으로써, 본 발명의 측면들은 멀티 인스턴스 어플리케이션들이 안전하게 실행되도록 한다. 도 10C의 설명은 어플리케이션 오브젝트(1050)와 인스턴스 오브젝트(1052)를 포함한다. 또한, 도 10C는 어플리케이션의 프로세스와 UI XML 문서들이 오픈되면 인스턴스화 되는 프로세스 오브젝트(1054), 뷰 오브젝트(1056), 컴포넌트 오브젝트(1058) 및 다이얼로그 오브젝트(1060)를 도시한다. 일 실시예에서, 어플리케이션 오브젝트(1050)는 어플리케이션의 실행을 시작할 때 인스턴스 오브젝트(1052)를 제공한다. 어플리케이션 오브젝트(1050)에서 시작해서 뷰 오브젝트(1056)와 프로세스 오브젝트(1054)로 향하는 점선 일방향 화살표는, 이 오브젝트들이 제공된 인스턴스 오브젝트(1052)에 특정된 로컬화된 관계 계층구조 내에서 생성되었다는 것을 나타낸다. 이에 관해, 인스턴스 오브젝트(1052)는MiniView 매니저(1062)와 MiniProcess 매니저(1064)를 유지한다. 어플리케이션의 프로세스 XML 문서가 오픈되면, 인스턴스 오브젝트(1052)는, MiniProcess 매니저(1064)를 이용하여 추적된 결과적인 프로세스 오브젝트(1054)를 참조하여 제공된다. 유사하게, 어플리케이션 뷰가 오픈되면 발생하는 뷰 오브젝트(1056)가 인스턴스 오브젝트(1052)에 제공되며 MiniView 매니저(1062)에 의해 수용된다. 따라서, MiniView 매니저(1062)와 MiniProcess 매니저(1064)에 대한 업데이트들은 인스턴스 오브젝트(1052)가 특정 어플리케이션 인스턴스에 연관된 오브젝트들을 추적하고 식별할 수 있게 한다.

어플리케이션의 로직을 설명하는 코드를 통해, 개발자들은 어플리케이션의 로직을 정의하기 위해 전역적으로 명명된 오브젝트들을 이용할 수 있다. 이 전역적으로 명명된 오브젝트들은 본 발명에 의해 제공된 익스프레션 랭귀지에 따라 참조될 수 있다. 그러나, 어플리케이션 코드 내의 오브젝트들에 할당된 전역 이름들(global name)은 다른 인스턴스에 속한 런타임 오브젝트들을 참조할 수 있다. 예를 들어, 다음 익스프레션 "#MyTasks#"이 뷰 오브젝트(1056)을 참조하는 어플리케이션 코드에서 이용될 수 있다. 또한, 다음 익스프레션 "#MyTasks#button1"이, 상술한 뷰 오브젝트(1056)의 컨텍스트 내에서 생성된 컴포넌트 오브젝트(예를 들어 Button)를 참조하는데 이용될 수 있다. 애매함을 제거하고 보안을 강화하기 위해, 본 발명의 측면들은 어플리케이션 코드에서 접한 전역적으로 명명된 오브젝트들이 적절한 인스턴스에 관해서 이밸류에이션되도록 하는 기능성을 구현한다. 이에 관해, 전역적으로 명명된 오브젝트들의 이밸류에이션은 복제된 프로세스나 UI XML 문서들을 생성하지 않고 수행된다. 대신에, 어플리케이션의 프로세스와 UI 문서들은 멀티플 어플리케이션 인스턴스들에 대한 런타임 오브젝트들을 구축하기 위해 공유되고 사용된다. 이하에서 명확해지듯이, 로컬화된 관계 계층구조의 구현은, 익스프레션들이 이밸류에이션되고 인스턴스 안에서 적절한 뷰 오브젝트에 접속할 때 적절한 인스턴스의 식별 및/또는 공급에 대한 기초를 제공한다.

도 10C에 도시된 예에서, 양방향 화살표가 인스턴스 오브젝트(1052)와 뷰 오브젝트(1056) 사이에 도시되어 있다. 한편, 양방향 화살표는 인스턴스 오브젝트(1052)가 뷰 오브젝트(1056)는 이 특정 어플리케이션 인스턴스에 연관된다는 것을 알고 있음을 나타낸다. 인스턴스화 되면, 뷰 오브젝트(1056)는 인스턴스 오브젝트(1052)에 제공되며 MiniView 매니저(1062)에 의해 수용된다. 한편, 어플리케이션 뷰가 생성되어 뷰 오브젝트(1056)가 그에 연관된 인스턴스를 인식할 때 인스턴스 오브젝트(1052)에 대한 식별자가 공급된다. 결과적으로, 데이터 업데이트 또는 어플리케이션 로직이 실행되도록 하는 입력이 수신될 때 적합한 인스턴스가 식별된다. 예를 들어, 뷰 오브젝트(1056)이 어플리케이션 뷰를 오픈하도록 사용될 때 컴포넌트 오브젝트(1058)가 인스턴스화 될 수 있다. 컴포넌트 오브젝트(1058)는 어플리케이션 뷰의 컨텍스트 내에서 생성되므로, 뷰 오브젝트(1056)와 통신할 수 있다. 결과적으로, 컴포넌트 오브젝트(1058)는, 예를 들어 사용자가 어플리케이션 코드를 실행하게 하는 입력을 제공할 때, 적절한 인스턴스 오브젝트(1052)를 식별한다.

도 10C에 도시된 예에서, 일방향 화살표가 인스턴스 오브젝트(1052)와 프로세스 오브젝트(1054) 사이에 도시된다. 일 실시예에서, 어플리케이션 내의 프로세스 단계가 프로세스 오브젝트(1052)를 이용하여 실행된다. MiniProcess 매니저(1064)의 이용 및 업데이트를 통해, 인스턴스 오브젝트(1052)는 연관된 프로세스 오브젝트(1054)를 인식한다. 그러나, 본 발명에 의해 제공된 프로세스 오브젝트들은 프로세스 단계들 사이에서는 상태가 보존되지 않는다(stateless). 결과적으로, 프로세스 오브젝트들은 단일 인스턴스 오브젝트(1052)로부터 컨텍스트를 제공받는다. 다시 말해, 프로세스 오브젝트(1052)는, 프로세스 단계들의 실행 사이에서, 연관된 인스턴스 오브젝트(1052)를 인식하지 않는다. 그러나, 프로세스 오브젝트(1054)는, 제공된 인스턴스 오브젝트(1052)에 의해 수용된 익스프레션 엔진(이하에서 설명됨)의 서비스들을 이용할 수 있다. 도 10C에 도시된 로컬화된 관계 계층구조 및 연관된 설명은, 멀티 인스턴스 어플리케이션들을 여전히 지원하면서 어떻게 본 발명이 내부 프로세스 보안을 보장할 수 있는지를 설명한다. 프로세스 단계에서 작업들을 통해 반복하면, 프로세스 오브젝트(1054)는 한 인스턴스 오브젝트(1054)로부터 컨텍스트를 제공받을 수만 있다. 관계들이 설정되어 프로세스 오브젝트(1054)가 단일 인스턴스 오브젝트(1054)로부터 컨텍스트를 공급 받는 프레임워크는, 다른 인스턴스들에 연관된 오브젝트들 사이에 엄격한 분리를 허용한다. 따라서, 어플리케이션 코드를 실행할 때, 프로세스 오브젝트(1054)는 다른 인스턴스의 로컬화된 관계 계층구조 내에 있는 오브젝트들에는 접속할 수 없다.

본 발명의 측면들은, 페어런트 인스턴스에 의해 설정된 로컬화된 관계 계층구조 내에서 서브 인스턴스를 생성할 수 있다. 이 실시예에서, 서브 인스턴스와 결과적인 서브 뷰 오브젝트 및 서브 프로세스 오브젝트들은 페어런트 인스턴스에 의해 설정된 로컬화된 관계 계층구조 내에서 생성된다. 서브 인스턴스에 의해 설명된 로컬화된 관계 계층구조는 페어런트 인스턴스에 의해 설정된 로컬화된 관계 계층구조 내에서 생성된 오브젝트들에게 보여질 수 있다. 그러나, 서브 인스턴스 내에서 생성된 런타임 오브젝트들은 페어런트 인스턴스 또는 다른 서브 인스턴스들에 연관된 오브젝트들을 인식하지 못한다. 페어런트 인스턴스 내에 서브 인스턴스를 넣는(nest) 능력은, 다른 스코프들을 이용하는 능력뿐 아니라 모듈라 코드를 구축하는데 있어 어플리케이션 개발자들에게 큰 유연성을 제공한다.

이제 도 11을 참조하면, 어플리케이션의 프로세스 코드에서 정의된 로직의 실행을 오픈하고 시작하기 위한 프로세스 시작 루틴(1100)이 설명된다. 프로세스 시작 루틴(1100)은 프로세스 로직을 포함한 문서를 오픈하라는 호출이 생성되면 실행될 수 있다. 일 실시예에서, 파일을 오픈하라는 호출은, 호출하는 오브젝트로부터 URL을 수신한 데이터 종류 인식자에게 발행될 수 있다. 데이터 종류 인식자에 전달된 URL은 어플리케이션 패키지 XML 문서, 프로세스 XML문서 또는 UI XML 문서를 포함하는, 그러나 여기에 한정되지 않는, 어떠한 종류의 문서들에 대응할 수 있다. 프로세스 로직을 포함하는 문서를 오픈할 때, 데이터 종류 인식자는 어플리케이션 실행을 가능하게 하는 특정한 동작이 수행되도록 할 수 있다. 도 11에 도시된 예시적인 실시예에서, 데이터 종류 인식자는, 제공된 문서가 프로세스 XML 문서인지를 판단하고 이 파일의 종류에 특정된 동작들을 수행되도록 한다.

도 11에 도시된 프로세스 시작 루틴(1100)은, 프로세스 XML 문서가 오픈될 수 있는 두 예시적인 환경들을 설명한다. 그러나, 프로세스 XML 문서들이 청구된 주제의 범위를 벗어나지 않는 다른 환경에서도 오픈될 수 있으므로, 이하에서 제공된 예들은 예시적인 것으로 해석되어야 한다. 도 11에 설명된 바와 같이, 프로세스 시작 루틴(1100)은 블록(1102) 또는 블록(1104)에서 시작한다. 예시적인 실시예에서, 루틴(1100)은, 데이터 종류 인식자가 어플리케이션 패키지에 연관된 프로세스 XML 문서를 오픈하는 호출을 수신한 블록(1102)에서 시작한다. 이 실시예에서, 어플리케이션 오브젝트는, 호출시 블록(1102)에서 수신한 이전에 생성된 인스턴스 오브젝트를 제공한다. 이하에서 상세히 설명되듯이, 프로세스 시작 루틴(1100)은, 프로세스 XML 문서에서 정의된 프로세스 단계들을 실행할 것으로 예상된 프로세스 오브젝트를 인스턴스화한다. 이 프로세스 오브젝트에 대한 참조는, 호출시 블록(1102)에서 수시한 제공된 상응하는 인스턴스에 이후 제공될 수 있다.

다른 실시예에서, 프로세스 시작 루틴(1100)은, 데이터 종류 인식자가 독립형 어플리케이션을 표현하는 프로세스 XML 문서를 오픈하는 호출을 수신한 블록(1104)에서 시작한다. 어플리케이션들은 어플리케이션 패키지와 연관되어질 필요는 없다. 이 실시예에서, 데이터 종류 인식자는, 프로세스 XML 문서를 오픈하라는 호출시 블록(1104)에서 제공받은 인스턴스를 수신하지 않는다. 이러한 방법으로 독립적이 되도록 설정된 어플리케이션들은 실행의 멀티 인스턴스들을 지원하지 않으며 어플리케이션들이 적어도 메모리 공간 일부를 공유하도록 한다.

블록(1106)에서, 프로세싱은 오픈될 문서의 파일 종류를 식별하는 데이터 종류 인식자에 의해 실행된다. 이 예에서, 데이터 종류 인식자에 의해 수행되는 분석은, 수신된 호출에 연관된 문서가 프로세스 XML 문서인지를 판단한다. 상술한 바와 같이, 데이터 종류 인식자는 동작들을 특정 파일 종류에 연관시킬 수 있다. 프로세스 XML 문서를 오픈하라는 요청을 접하면, 데이터 종류 인식자는, 블록(1108)에서, 프로세스 XML 문서를 오픈하라는 요청이 수신되었음을 나타내는 프로세스 매니저(906)을 호출하도록 설정된다.

판단 블록(1110)에서, 프로세스 매니저(906) 내의 로직은 이 프로세스 XML 문서에 대한 프로세스 오브젝트가 메모리에 일시 저장되었는지를 판단한다. 일 측면에서, 프로세스 시작 루틴(1100)는, 어플리케이션이 최초로 시작되면 새로운 프로세스 오브젝트를 인스턴스화하는 것을 담당한다. 인스턴스화되면, 로직은, 새롭게 인스턴스화된 프로세스 오브젝트가 프로세스 단계를 실행할 수 있도록 하는 프로세스 시작 루틴(1100)에 의해 구현된다. 프로세스 오브젝트는 상태가 보존되지 않으므로, 재사용될 수 있다. 따라서, 동일한 프로세스 로직은 어플리케이션 패키지 또는 프로세스 XML 문서에 임베디드된 다른 프로세스들의 동일한 인스턴스로부터 어플리케이션 코드를 실행하는데 이용될 수 있다. 따라서, 어플리케이션이 시작될 때 인스턴스화된 프로세스 오브젝트는 프로세스 매니저(906)에 의해 메모리에 일시 저장될 수 있다. 프로세스 매니저(906)가 여전히 메모리에 있는 이 어플리케이션을 위한 프로세스 오브젝트를 인스턴스화하면, 블록(1110)에서 수행된 테스트의 결과는 "예"이며, 프로세스 시작 루틴(1100)은 블록(1120)으로 진행하며, 이하에서 상세히 설명된다. 반대로, 새로운 프로세스 오브젝트가 인스턴스화되어야 한다고 판단되면, 프로세스 시작 루틴(1100)는 블록(1112)으로 진행한다. 새로운 프로세스 오브젝트가 인스턴스화되기 전에, 오픈중인 프로세스 XML 문서는 로컬에서 이용 가능하여야 한다. 따라서, 프로세스 매니저(904)는, 블록(1112)에서, 적합한 프로세스 XML 문서를 획득하기 위해 문서 매니저(912)를 통해 라우팅되는 호출을 생성한다.

블록(1114)에서, 프로세스 매니터(904)에 의해 요청중인 프로세스 XML 문서가 클라이언트 컴퓨팅 장치의 메모리에 로딩되었는지가 판단된다. 상술한 바와 같이, 문서 매니저(912)는 클라이언트상의 메모리에 로딩되는 각 문서를 추적하는 클라이언트측 캐시 역할을 한다. 오픈중인 프로세스 XML 문서가 문서 매니저(912)에 의해 유지되는 클라이언트측 캐시에서 참조된다고 판단되면, 프로세스 시작 루틴(1100)은 블록(1118)로 진행하며, 이하에서 상세히 설명된다. 반대로, 요청된 프로세스 XML문서가 클라이언트측 캐시에 로딩되지 않았으면, 프로세스 시작 루틴(1100)은 문서 매니저(912)가 요청된 프로세스 XML 문서를 획득되도록 하는 블록(1116)으로 진행한다. 더욱 상세하게는, 블록(1116)에서, 문서 매니저(912)는, 적합한 프로세스 XML 문서가 제공된 URL에 의해 식별된 네트워크 위치로부터 획득되도록 요청하기 위해 통신 매니저(이하에서 설명됨)를 이용한다.

프로세스 XML 문서가 클라이언트측 캐시로부터 이용가능하면, 새로운 프로세스 오브젝트가 블록(1118)에서 인스턴스화된다. 특히, 프로세스 매니저(904) 내의 로직은 어플리케이션 코드를 실행하기로 한 새로운 프로세스 오브젝트를 인스턴스화하는데 이용된다. 이후, 새로운 프로세스 오브젝트는, 블록(1120)에서, 대응하는 프로세스 XML 문서에 리스너로 등록된다. 이하에서 상세히 설명되듯이, 데이터 모델 내의 문서에 리스너로 등록함으로써, 오브젝트는, 문서에 대한 특정 데이터 업데이트가 수행되면 통지를 받고 어떤 동작을 취할 수 있다.

블록(1122)에서, 노티파이어 오브젝트들은 어플리케이션에서 각 트리거에 대해 인스턴스화된다. 특히, 파싱(parsing)은, 오픈중인 프로세스 XML 문서에서 정의된 트리거 요소들을 식별하도록 수행될 수 있다. 예로서, MyTasks 어플리케이션은, 블록(1122)에서 인스턴스화되는 노티파이어 오브젝트를 초래하는 트리거(602)(도 6A)를 정의한다. 트리거들은 뷰, 컴포넌트, 이벤트 및 단계 속성을 포함하는 각 트리거를 가진 프로세스 XML 문서에서 요소로서 정의될 수 있다. 뷰와 컴포넌트 속성들에 할당된 값은 트리거가 활성화될 어플리케이션 뷰 및/또는 컴포넌트를 식별한다. 유사하게, 이벤트 속성에 할당된 값은 트리거를 활성화할 이벤트의 종류를 식별한다. 또한, 단계 속성에 할당된 값은 트리거에 대한 응답으로 실행이 지시될 어플리케이션의 프로세스 코드 내의 프로세스 단계를 식별한다. 어플리케이션 내의 각 트리거에 대해, 프로세스 매니저(906) 내의 로직은 노티파이어 오브젝트를 인스턴스화하고 특정 프로세스 단계를 수행하기 위해 이후에 이용될 수 있는 노트파이어 오브젝트에 데이터를 일시 저장한다.

도 11에서 상세히 설명되듯이, 어플리케이션에서 정의된 각 트리거는 블록(1124)에서 이벤트 매니저(914)에 등록된다. 일 실시예에서, 이벤트 매니저(914)는 한 세트의 트리거 데이터를 리스닝 노티파이어 오브젝트들에 연관시키는 내부 해쉬 데이터 구조를 유지한다. 따라서, 트리거들은 이벤트 매니저(914)에 의해 유지되는 해쉬 데이터 구조를 업테이트함으로써 등록될 수 있다. 이하에서 상세히 설명되듯이, 이벤트 매니저(914)는, 컴포넌트와 이벤트 종류에 대한 등록된 이벤트에 매치되는 이벤트가 발생하면 적합한 리스닝 오브젝트와 노티파이어 오브젝트들에 통지한다.

도 11에서 상세히 설명되듯이, 새로운 인스턴스가 인스턴스화될 것인지에 관한 판단이 블록(1126)에서 이루어진다. 프로세스 XML 문서를 오픈할 때, 인스턴스가 제공될 수 있다. 특히, 상술한 어플리케이션 시작 루틴(1000)은, 프로세스 XML 문서를 오픈할 때 인스턴스화하고 인스턴스를 제공한다. 또한, 인스턴스들은, 모듈라 어플리케이션 개발을 지원하기 위해서 그리고 컨텍스트를 공유하는 다른 프로세스들을 위하여 다른 환경들에 제공될 수 있다. 이 실시예들에서, 새로운 인스턴스는 인스턴스화되지 않으며, 프로세스 시작 루틴(1100)은 블록(1130)으로 진행하며, 이하에서 상세히 설명된다. 반대로, 인스턴스 오브젝트가 제공되지 않으면, 프로세스 시작 루틴(1100)은 블록(1128)로 진행하며, 인스턴스 오브젝트가 인스턴스화된다. 특히, 프로세스 매니저(906) 내부의 로직은, 블록(1128)에서 새로운 인스턴스 오브젝트를 인스턴스화하는 호출을 생성한다.

블록(1130)에서, 프로세스 XML 문서에서 정의된 프로세스 단계를 실행하는 호출이 생성된다. 실제 실시예에서, 프로세스 오브젝트는 프로세스 시스템이 수신한 두 개의 파라미터에 기초하여 실행되도록 설정된다. (1) 어플리케이션의 런타임 상태를 표현하는 제공된 인스턴스 및 (2) 실행될 프로세스 단계의 식별자. 이에 관해, 프로세스 오브젝트에 제공되는 인스턴스는 어플리케이션 패키지 또는 독립 어플리케이션의 컨텍스트 내에서 생성될 수 있다. 양 실시예에서, 프로세스 시작 루틴(1100)은, 프로세스 XML 문서에 정의된 각 프로세스 단계를 실행할 때 멀티 인스턴스들에 대해 프로세스 오브젝트가 재사용되도록 하는 파라미터를 프로세스 오브젝트에 제공하도록 설정된다. 이후, 프로세스 시작 루틴(1100)는 종료하는 블록(1132)으로 진행한다.

프로세스 단계가 시작되면, 제어 플로우는 프로세스 오브젝트 내에서 인코딩된 실행 메소드(execute method)에 지시된다. 일반적으로 설명하면, 실행 메소드는 루프 스루(loop through)하고 프로세스 단계에서 정의된 각 작업이 실행되도록 한다. 다시 말해, 실행 메소드는 프로세스 작업 API에 따라 개발된 프로세스 작업들에 대한 인터페이스이다. 따라서, 실행 메소드는 MyTasks 어플리케이션에서 정의된 프로세스 단계 "1"을 실행하기 위해서 프로세스 시작 루틴(1100)에 의해 호출될 수 있다. 응답으로, 실행 메소드는 Open, Bind 및 Action작업들(612-616)이 이 프로세스 단계(604) 내에서 실행되도록 할 수 있는 프로세싱을 수행한다.

이제 도 12A-B를 참조하면, 프로세스 단계에서 작업들이 실행되도록 설정된 실행 메소드(1200)가 설명된다. 도 12A에 설명되듯이, 실행 메소드(1200)는 프로세스 단계 내의 새로운 작업이 식별된 블록(1202)에서 시작한다. 일 실시예에서, 프로세서 단계 내의 작업들은 전형적으로 식별되고 순차적으로 실행된다. 새로운 작업을 접하면, 작업의 값 속성에서 제공된 익스프레션은 블록(1203)에서 이밸류에이션을 위해 선택된다. 예를 들어, 상술한 MyTasks 어플리케이션에서, MyTasks 문서(600)(도 6A)는 initialize Application 프로세스 단계(604)를 정의한다. 이 프로세스 단계(604) 내에서, 제1 작업은 값 속성 "apps/mytasks_gui.xml"을 갖는 Open 작업(612)이다. 실행 메소드(1200)를 통한 반복으로, 익스프레션 "apps/mytasks_gui.xml"은 블록(1203)에서 이밸류에이션을 위해 선택된다.

도 12를 참조한 설명은 프로세스 단계 이내에 있는 작업들이 순차적으로 실행되는 예들을 제공한다. 그러나, 본 발명의 측면들은 작업들의 비동기 실행을 지원해서, 프로세스 단계의 각 작업들이 순차적으로 실행되지 않을 수 있다. 예를 들어, 제1 작업이 원격 네트워크 위치에서만 이용 가능한 자원을 요청하면, 자원이 비동기적으로 획득되는 동안 (제1작업의 결과에 종속적이지 않은) 다른 작업들이 실행될 수 있다.

도 12A에서 상세히 설명되듯이, 블록(1203)에서 이밸류에이션을 위해 선택된 익스프레션은 블록(1204)에서 XBind로 이밸류에이션된다. 여기서 사용되는, XBind는 URL, 베이스 경로(예를 들어, 특정 URL에 의해 식별된 문서 내에 있는 XML 조각을 참조하는 XPath 표현), 및 선택(예를 들어, 복스의 XPath 익스프레션들)을 포함하는 데이터 종류이다. MyTasks 어플리케이션에서 정의된 예시적인 Open 작업(612)에서, "apps/mytasks_gui.xml" 익스프레션은 블록(1204)에서 다음의 XBind로 이밸류에이션된다.

URL = apps/mytasks_gui.xml

Base path = /

Selection =

이 XBind의 URL은 어플리케이션의 유저 인터페이스의 시맨틱 설명을 제공하는 UI XML 문서를 참조한다. 여기서 제공된 예들이 URL을 자원들을 식별하는 포맷으로 이용할 때, 이는 예시적인 것으로 해석되어야 한다. 자원을 고유하게 식별할 수 있는 어떠한 시스템도 본 발명과 함께 구현될 수 있다. 이하에서 상세히 설명되듯이, 네트워크 오퍼레이팅 시스템은, XML 파일 시스템, 데이터베이스, 및 URL을 이용한 XML 웹 서비스들에 접속하기 위한 프로토콜들과 추상화들을 제공한다. 그러나, 다른 프로토콜들은 URL이외의 자원 위치를 식별하는데 이용되었다는 것이 고려된다. 위 XBind의 베이스 경로는, URL에서 식별된 UI XML 문서의 루트 요소를 참조하는 "/"이다. 어플리케이션 뷰를 오픈할 때, 베이스 경로는 UI XML 문서의 조각을 참조한다. 이 경우에, 뷰 로직의 시맨틱 설명은 UI XML 문서의 루트 노드에 연관되지 않는다. 따라서, 이 변형(variation)에 대한 XBind는 뷰 로직에 대응하는 노드를 참조하는 베이스 경로를 포함한다. 이 예시적인 XBind에 대한 선택은 데이터를 포함하지 않는 "null"이다. 익스프레션이 이밸류에이션되면, 실행 메소드(1200)는 블록(1206)으로 진행하며, 이하에서 설명된다.

이제 도 12B를 참조하면, 익스프레션이 이밸류에이션될 때 발생하는 교환이 설명된다. 도 12B의 설명은 인스턴스 오브젝트(1250), 프로세스 오브젝트(1252) 및 뷰 오브젝트(1254)를 포함하는 한 세트의 오브젝트를 포함한다. 도 10C를 참조하여 제공한 설명에 유사하게, 도 12B에 도시된 점선 화살표는 프로세스와 뷰 오브젝트(1252-1254)가 인스턴스 오브젝트(1250)에 특정된 로컬화된 관계 계층구조와 이전에 연관되어 있음을 나타낸다. 실행 메소드(1200)내에서, 프로세스 오브젝트(1252)는 접하게 된 익스프레션을 이밸류에이션하기 위해 인스턴스 오브젝트(1250)를 이용할 수 있다. 프로세스 단계의 실행이 시작될 때 인스턴스 오브젝트(1250)가 제공되므로, 프로세스 오브젝트(1252)는, 익스프레션 엔진(1260)에 의해 익스프레션이 이밸류에이션되도록 하기 위해 프로세스 단계 내에서 인스턴스 오브젝트(1250)을 이용할 수 있다.

. 일 실시예에서, 본 발명은 인스턴스에 의해 제공된 컨텍스트 내에서 익스프레션들을 이밸류에이션하도록 설정된 익스프레션 엔진(1260)을 구현한다. 특히, 익스프레션 엔진(1260)에서 캡슐화된 기능성은, 익스프레션(1262)을 XBind(1264), XML 포맷 데이터 또는 일반 텍스트로 이밸류에이션하기 위해 인스턴스 오브젝트(1250)의 컨텍스트 내에서 이용될 수 있다. 이밸류에이션되면, 익스프레션 엔진(1260)에 의해 식별된 XBind(1264)는, 인스턴스 오브젝트(1250)에서 프로세스 오브젝트(1252)로 패스된다. 로컬 인스프레션 엔진(1260)을 인스턴스화하고 수용하기 위해 인스턴스 오브젝트(1250)을 이용함으로써, 익스프레션들의 이밸류에이션은, 인스턴스나 서브 인스턴스에 의해 제공된 컨텍스트에 관해 쉽게 수행된다. 무엇보다도, 이 방법으로 로컬 익스프레션 엔진(1260)을 이용하는 것은, 인스턴스와 스코프 핸들링이 다중 체인 스코프 깊이(multiple changed scope depth) 내에서 수행되도록 한다. 따라서, 익스프레션들은, 실행중인 어플리케이션 인스턴스에 따라서, 다르게 이밸류에이션될 수 있으며, 개발자들은 복수 인스턴스들이나 스코프들 관리의 복잡성을 설명할 필요가 없다. 익스프레션 엔진(1260) 내에서 구현된 기능성들의 추가적인 설명들과 본 발명에 의해 이밸류에이션될 수 있는 익스프레션들의 종류는 이하에서 상세히 설명된다. 이에 관해, 익스프레션 엔진(1260)은 작업 내에서 정의된 다중 익스프레션들을 이밸류에이션하는데 사용될 수 있다. 작업 내의 각 익스프레션들은 작업 핸들러가 호출되기 전에 이밸류에이션되며, 이하에서 상세히 설명된다.

다시 도 12A를 참조하면, 실행 메소드(1200)는 블록(1206)에서 적합한 작업 핸들러의 실행을 시작한다. 상술한 바와 같이, 복수의 작업 핸들러들이 본 발명에 의해 제공된다. 각 작업 핸들러는 접할 수 있는 작업의 종류에 특정된 기능성을 구현한다. 따라서, 현재 작업이 오픈 작업이면, 실행 메소드(1200)는 블록(1206)에서 오픈 작업 핸들러를 호출한다. 그러나, 다른 작업 핸들러(Bind, Decision, Action, Change 등)는 실행 메소드(1200) 내에서 호출될 수 있도록 구현된다. 따라서, 실행 메소드(1200)는 잘 정의된 프로세스 작업 API들을 이용하여 호출된 특정 작업 핸들러에 적절한 인수들(arguments)을 패스하도록 설정되며, 이는 아래 예들에서 설명된다. 그러나 각 작업 핸들러는 호출될 때 적어도 인스턴스 및 프로세스 오브젝트들과 이밸류에이션된 XBind를 제공받는다.

판단 블록(1208)에서, 실행 메소드(1200)는 프로세스 단계의 추가 작업들인 실행될지를 판단한다. 따라서, 현재 프로세스 단계의 모든 작업들이 이전에 실행되지 않았으면, 실행 메소드(1200)는 블록(1202)으로 돌아가고, 블록들(1202-1208)은 각 작업이 실행될 때까지 반복된다. 특히, 프로세스 단계는 어플리케이션 실행의 플로우를 지시하는 선언문(statement)을 포함할 수 있다. 예를 들어, "call" 선언문은, 현재 프로세스 단계의 모든 작업들이 실행되면 다른 프로세스 작업으로 실행의 플로우를 지시하는 프로세스 단계에서의 선언문으로 정의될 수 있다. 더 일반적으로, 개발자들이 한 프로세스 단계의 동작들과 다른 프로세스 단계들 사이에서 실행의 플로우를 지시하는 "call" 작업이 제공된다. "call" 작업이 정의되면, 플로우는 새로운 프로세스 단계로 진행하며, 완료하면, 시작된 프로세스 단계 내에 있는 위치로 복귀한다. 실제 실시예에서, 비동기 호출들, 시간 지연 호출들 및 시간 반복 간격 호출들이 "call" 작업을 이용하여 생성될 수 있다. 이후, 모든 작업이 실행되면, 실행 메소드(1200)는 종료하는 블록(1210)으로 진행한다.

상술한 바와 같이, 실행 메소드(1200)는, 어플리케이션 로직을 해석할 때 특정 작업 핸들러들의 실행을 시작한다. 상술한 MyTasks 어플리케이션을 계속 참조하여, 특정 작업 핸들러들에 의해 구현된 기능성이 설명된다. 작업 핸들러가 상태 변경을 구현하므로, 작업 핸들러가 이용하는 모든 데이터가 제공된다. 또한, 본 발명의 측면들은 작업 핸들러들이 데이터를 반환하지 않도록 설정된다. 따라서, 작업 핸들러들은, 데이터를 반환하지 않으면서 실행하는데 이용되는 모든 것을 공급받는 독립 함수들로 구현될 수 있다. 따라서, 어플리케이션의 프로세스 작업들은 로컬에서 실행될 수 있다. 그러나, 작업 핸들러들은 독립 함수들이므로, 서버측 데이터 센터로부터 웹 서비스로서 제공되어질 수 있다.

이제 도 13을 참조하면, 오픈 작업 핸들러를 이용하는 예시적인 오픈 핸들러 루틴(1300)이 설명된다. 상술한 예시적인 MyTasks 어플리케이션(도 12A)에서, 어플리케이션은 실행 메소드(1200)(도 12A) 내에서 XBind에 이밸류에이션되는 속성을 가진 Open 작업(612)을 정의한다. 따라서, 오픈 작업 핸들러는 오픈 작업(612)을 실행하기 위해 호출될 수 있다. 일 실시예에서, 인수들은, 이전에 이밸류에이션된 XBind와 적합한 인스턴스 및 프로세스 오브젝트들을 포함하는 오픈 작업 핸들러 호출시 오픈 작업 핸들러로 패스될 수 있다.

도 13에서 설명되듯이, 블록(1302)에서, 데이터 종류 인식자는 문서를 오픈하기 위한 오픈 작업 핸들러 내에서 호출된다. 상술한 바와 같이, 이전에 이밸류에이션된 XBind는 오픈되는 문서 내에서 문서 또는 조각(노드)를 가르킬 수 있다. 무엇보다도, 오픈 작업 핸들러는, 데이터 종류 인식자 호출시 오픈중인 문서를 식별하는 이전에 이밸류에이션된 XBind를 패스한다. 호출을 수신하면, 데이터 종류 인식자는 수신한 XBind에서 참조되는 문서의 파일 종류를 식별하기 위해 블록(1304)에서 프로세싱을 수행한다. 상술한 예시적인 MyTasks 어플리케이션에서, 데이터 종류 인식자로 패스된 XBind는 "MyTasks_gui.xml"으로 명명된 문서를 참조한다. 이 예에서, 데이터 종류 인식자는 UI XML 문서가 되는 파일 종류를 식별한다. 상술한 바와 같이, 로직은 동작들을 특정 파일 종류에 연관시키는 데이터 종류 인식자 내에서 제공된다. 데이터 종류 인식자가 UI XML 문서를 오픈하기 위해 사용될 때 시작된 예시적인 동작들의 한 세트는 이하에서 설명된다.

오픈 핸드링 루틴(1300)의 블록(1306)에서, 데이터 종류 인식자는 명령을 UI XML 문서를 오픈하라는 요청이 수신되었음을 나타내는 뷰 매니저(908)로 패스한다. 특히, 뷰 매니저(908)는 새로운 유저 인터페이스나 어플리케이션 뷰를 렌더링하는데 이용될 수 있는 뷰 오프젝트를 생성하기 위해 호출된다. 상술한 바와 같이, 어플리케이션의 유저 인터페이스는 UI XML 문서(예를 들어, "MyTasks_gui.xml")에 시맨틱하게 설명된다. 이에 관해, 다중 뷰 오브젝트들은 각 어플리케이션 인스턴스에 연관될 수 있다. 따라서, 뷰 매니저(908)에 대한 호출시, 적합한 인스턴스와 새로운 뷰를 설명하는 UI XML 문서의 식별자는 데이터 종류 인식자에 의해 제공될 수 있다.

도 13에서 설명되듯이, 블록(1308)에서, 새로운 어플리케이션 뷰의 시맨틱 설명을 제공하는 로직의 실행이 시작된다. 상술한 바와 같이, 뷰 매니저(908)는 뷰 오브젝트를 인스턴스화하고 UI XML 문서에 설명된 어플리케이션 뷰가 렌더링되록 하는 작업을 수행하는 것을 담당한다. 새로운 어플리케이션 뷰를 렌더링하기 위해, 컴포넌트와 다이얼로그 오브젝트들은 뷰 오브젝트를 이용하여 인스턴스화된다. 도 23을 참조하여 이하에서 상세히 설명되듯이, 본 발명에 의해 제공되는 이 오브젝트들은 UI XML 문서에서 시맨틱하게 설명된 그래픽 요소들이 컴퓨터 디스플레이 상에서 렌더링되게 하는 기능을 구현한다. 이후, 오픈 핸들링 루틴(1300)은 종료하는 블록(1310)으로 진행한다.

이제 도 14A-14B를 참조하면, 오프닝 프로세스에서의 데이터 종류 인식자와 UI XML 문서들의 사용이 추가적으로 상세하게 설명된다. 도 14A의 설명은, UI XML 문서가 오픈될 때 상호작용하는 프로세스 오브젝트(1400), 오픈 작업 핸들러(1402), 데이터 종류 인식자(1404), 인스턴스 오브젝트(1406), 뷰 매니저(908) 및 뷰 오브젝트(1408)를 도시한다. 따라서, 도 14A의 블록도는 도 13을 참조하여 상술한 오픈 작업 핸들링 루틴(1300)에 의해 이용되는 오브젝트들에 상응할 수 있다. 어플리케이션 뷰의 오프닝은 프로세스 오브젝트(1400)에 의해 시작될 수 있으며, 프로세스 오브젝트(1400)는 이밸류에이션된 XBind에 의해 식별된 특정 문서를 오픈하기 위해 오픈 작업 핸들러(1402)를 호출한다. 호출을 수신하면, 오픈 작업 핸들러(1402)는 파일 종류를 식별하기 위해 데이터 종류 인식자(1404)를 이용하며 적합한 동작들이 실행되도록 한다. 일 실시예에서, UI XML 문서가 오픈 작업 핸들러(1402)에서 데이터 종류 인식자(1404)로 전달될 때, 어플리케이션의 뷰 로직을 오픈하고 실행을 시작하게 하는 동작들이 정의된다. 또한, 데이터 종류 인식자(1404)는 결과 뷰 오브젝트(1408)을 적합한 인스턴스 오브젝트(1406)에 연관시키는데 이용된다.

도 14A에 도시된 예에서, 뷰 매니저(908)는 UI XML 문서를 오픈하라는 호출이 수신되면 데이터 종류 인식자(1404)에 의해 호출된다. UI XML 문서의 로직을 오픈하고 실행하기 위해, 뷰 매니저(908)는 뷰 오브젝트(1408), 인스턴스 오브젝트(1406)의 식별자 및 적합한 UI XML문서를 참조하는 XBind를 인스턴스화하고 공급한다. 데이터를 이 방법으로 패스함으로써, 뷰 오브젝트(1408)는 그것에 연관된 인스턴스를 인지하게 된다. 뷰 오브젝트(1408)가 인스턴스화되면, 새로운 어플리케이션 뷰의 시맨틱 설명을 제공하는 로직의 실행이 상술한 프로세스 시작 루틴(1100)(도 11)과 유사한 기능성을 이용하여 시작된다. 특히, 뷰 매니저(908)는 적절한UI XML이 클라이언트측 캐시에 로딩되도록 할 수 있다. 이후, 뷰 오브젝트(1408)는 인스턴스화될 수 있으며 어플리케이션의 유저 인터페이스 컴포넌트들과 다이얼로그들을 렌더링하는데 이용될 수 있다. 그러나, 프로세스들과 달리, 멀티 뷰 오브젝트들은 인스턴스화될 수 있으면 동일한 인스턴스에 연관될 수 있다.

실제 실시예에서, 본 발명의 측면들은 레이지 로딩(lazy loading) 및/또는 어플리케이션의 UI 로직의 렌더링을 지원한다. 이를 위해, World Wide Web Consortium에 의해 정의된 표준에 따르게 구현된 XLinks가 레이지 로딩 및/또는 하나 이상의UI XML 문서들의 렌더링을 수행하기 위해 이용될 수 있다. 당업자라면 XLink는 서로 다른 XML 자원들간의 링크를 설명하는 XML 문서에 포함될 수 있다는 것을 이해할 수 있다. 웹 페이지를 링크하는 의미를 사용자에게 제공하는 전통적인 HTML 기반 하이퍼링크들과 달리, XLinks는 소프트웨어 시스템들과 컴퓨터들에 의해 더욱 쉽게 해석된다. 특히, XLinks는 활성화시 취해질 동작 뿐만이 아니라 XLinks를 활성화하는 조건을 정의하는 로직을 포함할 수 있다. 결과적으로, XLinks는 어플리케이션 UI 로직의 온 디맨드 및/또는 레이지 렌더링 수행에 가장 적합하다. 어플리케이션이 실행될 때 어플케이션들의 UI 로직을 모두 로딩하는 대신, XLinks는 요구된 적합한 XML 자원들과 링크하기 위해 정의될 수 있다. 예를 들어, 상술한 예시적인 MyTasks 어플리케이션에서, Button2 컴포넌트(704)는 모든 어플리케이션들의 유저 인터페이스 로직이 로딩되고 렌더링된 이후에 "감춰"진다. 균등한 기능성과 개선된 성능은, 필요시 Button2 컴포넌트(704)의 UI 로직을 로딩하고 및/또는 렌더링하기 위해 XLinks를 이용함으로써 달성될 수 있다. 이 예에서, MyTasks_gui.xml 문서(650)의 Button2 컴포넌트(704)의 유저 인터페이스 로직은, 관련된 유저 인터페이스 로직을 정의한 로컬 또는 원격 자원(예를 들어, 다른 UI XML 문서)을 참조하는 XLinks를 포함할 수 있다. 어플리케이션 로직에 의해 지시받으면, 이 XLinks는 Button2 컴포넌트(704)에 상응하는 UI 로직을 로딩 및/또는 렌더링하는데 이용될 수 있다.

오픈 작업 핸들러(1402)가 완료되면, 결과 뷰 오브젝트(1408)가 데이터 종류 인식자(1404)에 반환된다. 이후 데이터 종류 인식자(1404)는 뷰 오브젝트(1408)를 적합한 인스턴스에 연관시킨다. 특히, 새로운 어플리케이션 뷰가 생성되면, 데이터 종류 인식자(1404)는 결과 뷰 오브젝트(1408)를 인스턴스 오브젝트(1406)으로 패스한다. 응답으로, MiniView 매너저(1412)가 업데이트 되어, 뷰 오브젝트(1408)가 상응하는 인스턴스에 연관된다. MiniView 매니저(1412)에 의해 동일한 오브젝트에 할당된 것보다 더 복잡한 이름이 뷰 매니저(908) 내의 뷰 오브젝트(1408)에 할당된다. 특히, 뷰 매니저(908) 내의 뷰 오브젝트(1408)에 할당된 이름은 상응하는 인스턴스 오브젝트(1406)의 식별자를 포함한다. 이하에서 상세히 설명되듯이, 이 방법으로 오브젝트들을 명명하는 시스템을 구현함으로써, 동일한 뷰는 다중 어플리케이션 인스턴스들 사이에서 구별될 수 있다. 이 방법으로 데이터의 패싱을 제어함으로써, 본 발명의 측면들은 어플리케이션 인스턴스의 경계를 정하는 로컬화된 관계 계층구조를 구현한다.

이제 도 14B를 참조하면, 프로세스 XML 문서를 오픈할 때의 데이터 종류 인식자(1404)의 이용이 추가적으로 상세하게 설명된다. 도 14A에 유사하게, 도 14B의 설명은, 프로세스 매니저(906)뿐만이 아니라, 프로세스 오브젝트(1400), 데이터 종류 인식자(1404), 인스턴스 오브젝트(1406)를 도시한다. 따라서, 도 14B에 도시된 블록도는 프로세스 시작 루틴(1100)(도11)에 의해 이용되는 오브젝트들에 상응할 수 있다. 프로세스 XML 문서가 오픈되면, 데이터 종류 인식자(1404)가 문서의 파일 종류를 식별하기 위해 어플리케이션 패키지의 컨텍스트 또는 독립 어플리케이션에서 이용된다. 이 예에서, 데이터 종류 인식자(1404)는 프로세스 XML 문서에 설명된 로직의 오픈과 실행의 시작을 가능하게 하는 동작들을 정의한다. 특히, 실행 플로우는 데이터 종류 인식자(1404)에서 프로세스 오브젝트(1400)를 인스턴스화하는 프로세스 매니저(906)로 진행한다. 프로세스 XML 문서가 오픈되면, 결과 프로세스 오브젝트(1400)에 대한 참조가 데이터 종류 인식자(1404)로 반환될 수 있다. 이후, 데이터 종류 인식자(1400)는 인스턴스 오브젝트(1406)에 결과 프로세스 오브젝트(1400)에 대한 참조를 제공한다. 응답으로, MiniProcess 매니저(1414)가 업데이트되어, 프로세스 오브젝트(1400)을 상응하는 인스턴스에 연관시킨다.

도 15A-B를 참조하면, 프로세스 실행을 가능하게 할 때 MiniView 매니저의 이용에 관한 예를 제공하는 동작 작업이 설명된다. MyTasks 어플리케이션의 Open 작업(612)이 실행되면, 실행 플로우는 Action 작업(614)(도 6A)으로 진행한다. 이에 관해, 동작 핸들링 루틴(1500)이 루틴(1500)을 구현하는데 포함된 오브젝트들간의 상호 작용뿐 아니라 로직도 설명하는 도 15A-B를 참조하여 설명된다.

도 15A에서 설명되듯이, Action 작업(614)의 값 속성으로 표현된 익스프레션은 블록(1502)에서 XBind로 이밸류에이션된다. 예시적인 MyTasks 어플리케이션에서, Action 작업(614)은 블록(1502)에서 XBind로 이밸류에이션되는 값 속성 "#MyTasks"을 포함한다. 도 15B를 특별히 참조하면, 익스프레션 엔진(1550)에서 캡슐화된 기능성은 "#MyTasks" 익스프레션을 XBind로 이밸류에이션하기 위해 인스턴스 오브젝트(1552)에 의해 이용될 수 있다. 이 예에서, 익스프레션 엔진(1550)은 "MyTasks"로 명명된 뷰 오브젝트에 대한 MiniView 매니저(1554)에서 룩업(lookup)을 수행하도록 설정된다. 새로운 어플리케이션 뷰가 생성되면, 결과 뷰 오브젝트는 그에 따라 MiniView 매니저(1554)를 업데이트하는 상응하는 인스턴스로 패스된다. 이에 관해, MyTasks 뷰 오브젝트는 전역 뷰 매니저(908)의 뷰들에 대해 사용되는 더 복잡한 식별자보다는 인스턴스에 의해 수용된 MiniView 매니저(1554) 안에서 간단한 이름이 할당된다. 복잡한 이름은 서로 다른 인스턴스들과 어플리케이션들에 속한 뷰를 구분하기 위해서 사용되므로, 더 복잡한 이름은 인스턴스 냉에서는 필요하지 않다. MiniView 매니저(1554)가 자체 뷰들을 수용하고 있으므로, 이 정보는 인스턴스와 MiniView 매니저(1554)가 이미 알고 있는 것이다. 이 아키텍쳐를 제공함으로써, 익스프레션 엔진(1550)은, MiniView 매니저(1554)의 도움으로, 서로 다른 인스턴스들과 어플리케이션들에 연관된 뷰들 사이에서 구별할 수 있다. 그러므로, 예시적인 MyTasks 어플리케이션에서, MiniView 매니저(1554)는 "MyTasks"로 명명된 뷰 오브젝트를 포함한다. 뷰 오브젝트는 이 뷰 오브젝트가 연관된 인스턴스에 대한 참조를 또한 포함한다. "#MyTasks" 익스프레션을 이밸류에이션할 때, 익스프레션 엔진(1550)은 MyTasks 뷰 오브젝트(1558)를 소스나 작업의 "에미터"로 식별한다. 특히, 인스턴스 오브젝트(1552)에 연관된 MyTasks 뷰 오브젝트(1558)는 에미터로 식별되며, 다른 인스턴스에 연관된 "MyTasks" 뷰 오브젝트가 아니다. 익스프레션 엔진(1550)이 인스턴스에 관한 익스프레션들을 이밸류에이션하므로, 이벤트의 소스였던 정확한 MyTasks 뷰 오브젝트(1558)는 MiniView 매니저(1554)를 이용하여 식별된다.

이 예에서, 프로세스 오브젝트(1556)에 반환된 XBind는 MyTasks_gui.xml 문서(650)와 MyTasks 뷰 오브젝트(1558)를 참조하는 URL을 포함한다. 지시자(indicator)가MyTasks 뷰 오브젝트(1558)가 실행중인 작업의 에미터나 소스인 XBind와 포함된다. MiniView 매니저(1554)의 룩업이 익스프레션에서 참조되는 오브젝트에 대한 일치를 식별하지 않으면, 익스프레션 엔진(1550)은 관련된 뷰 오브젝트를 획득하기 위해 뷰 매니저(908)에서 룩업을 수행하도록 설정된다.

루틴(1500)의 블록(1504)에서, 프로세스 오브젝트(1556)는 동작 작업 핸들러(1560)의 실행을 시작한다. 예시적인 MyTasks 어플리케이션에서, 익스프레션 엔진(1550)과 에미팅 MyTasks 뷰 오브젝트(1558)를 이용하여 이전에 이밸류에이션된 XBind는 프로세스 오브젝트(1556)에 의해 동작 작업 핸들러(1560)에 패스된다. 이후, 블록(1506)에서, 동작 작업 핸들러(1560)는 어플리케이션 프로세스 로직에 특정된 대로, 메소드가 수행되도록 한다. 이 예에서, MyTasks 어플리케이션의 동작 작업(614)는 메소드와 동작이 수행될 타겟을 식별하는 다음 "<component>" XML 요소를 정의한다.

<component name="button2" action="hide" value=""x/component>

이 요소를 정의함으로써, 어플리케이션 코드는 "button2"로 명명된 컴포넌트가 감춰지도록 지시한다. 일 측면에서, 뷰 오브젝트들은 enable, disable, hide, 및 show 메소드들 등을 포함하는, 그러나 여기에 한정되지 않는, 연관된 유저 인터페이스 컴포넌트들상에서 상태 노작들을 수행하는 제너릭 메소드들(generic methods)로 인코딩된다. MyTasks 뷰 오브젝트(1558)이 동작 작업 핸들러(1560)으로 패스되므로, 이 제너릭 메소드들은 오브젝트(1558) 상에서 직접 호출될 수 있다. 이 예에서, 동작 작업 핸들러는 "hide" 메소드를 MyTasks 뷰 오브젝트(1558) 상에서 호출하고 Button2 컴포넌트(1562)를 감춰질 타겟 컴포넌트로 식별한다. 이후 동작 핸들링 루진(1500)은 종료하는 블록(1508)로 진행한다.

이제 도 16을 참조하면, 바인드 작업 핸들러의 구현이 추가적으로 상세하게 설명된다. MyTasks 어플리케이션의 Open 및 Action 작업들(612-614)이 실행되면, 실행 플로우는 Bind 작업(616)(도 6A)로 진행한다. 도 16에 설명되듯이, 블록(1602)에서, Bind 작업(616)의 값 속성에서 표현된 익스프레션은 XBind로 이밸류에이션되며 적합한 프로세스 오브젝트로 반환된다. 상술한 설명에 유사하게, 프로세스 오브젝트는 제공된 익스프레션을 이밸류에이션하는 인스턴스에 로컬한 익스프레션 엔진을 이용한다. 예시적인 Bind 작업(616)에서, "data/tasks.xml" 익스프레션은 블록(1602)에서 다음 XBind로 이밸류에이션된다.

URL = data/tasks.xml

Base path = /

Selection =

XBind의 URL은 태스크 설명들을 저장하는 데이터 문서를 참조한다. 또한, 베이스 경로는 URL에 상응하는 데이터 문서의 루트 노드를 참조하며, 이 예시적인 XBind의 선택 측면은 null이다.

바인드 핸들링 루틴(1600)의 블록(1604)에서, 현 프로세스 단계를 실행하기 위해 이용중인 프로세스 오브젝트는 바인드 작업 핸들러의 실행을 시작한다. 호출시, 바인드 작업 핸들러는 이전에 이밸류에이션된 XBind와 적합한 프로세스 및 인스턴스 오브젝트들을 수신한다. 상술한 바와 같이, 개발자들은 작업의 바디 안에 존재할 수 있는 함수 호출 파라미터들과 XML 시맨틱 구조를 정의하는 프로세스 작업 API들에 따라 작업을 생성할 수 있다. 이 예에서, Bind 작업(616)(도 6A)은 다음 "<component>" XML 요소(618)를 정의한다.

<component view ="MyTasks" name= "input3" select="/tasks/task/@description">

따라서, 바인드 작업 핸들러(블록(1604)에서 호출됨)는 특정 컴포넌트를 XML 문서 내의 조각에 바인드하기 위해 이 로직을 해석하는 것을 담당한다. 더 일반적으로, 각 작업 핸들러는 작업 요소의 차일드 요소들에서 정의된 로직을 해석하는 것을 담당한다. 이에 관해, 프로세스 작업 API들은 개발자들이 작업 핸들러 내에서 실행되는 로직이 필요에 따라 설정되도록 하기 위해 작업의 바디에 XML 신택스를 정의할 수 있도록 한다.

블록(1605)에서, 하부 XML 문서에 바인드되는 컴포넌트에 대응하는 뷰 오브젝트는 식별되고 바인드 작업 핸들러에 반환된다. 이 예에서, 바인드 작업 핸들러에 의해 해석되는 컴포넌트 요소(618)는 "MyTasks" 뷰 오브젝트의 컨텍스트 안에서 생성되는 것으로 "Input3" 컴포넌트를 식별한다. 적합한 인스턴스 오브젝트가 바인드 작업 핸들러에 제공되므로, 옳은 뷰 오브젝트는 용이하게 식별될 수 있다. 특히, 인스턴스의 MiniView 매니저에서의 룩업이 실행되고, "MyTasks" 뷰 오브젝트가 바인드 작업 핸들러로 직접 반환된다.

도 16에서 설명되듯이, 번역된 XBind는 블록(1606)에서 바인드 작업 핸들러 내에서 생성된다. 바인드 작업 핸들러로 패스되는 XBind는 MyTasks 어플리케이션에 의해 이용되는 컨텐츠를 저장한다. 그러나, 식별된 XML 문서의 데이터의 서브셋만이 Input3 컴포넌트에 바인드된다. 따라서, 이 예의 바인드 작업(616)에 의해 수행된 바인딩은, Input3 컴포넌트의 바인딩을 XPath 익스프레션에 의해 식별된 "data/tasks.xml" 문서에서의 데이터의 조각으로 좁히도록 설정된다. 특히, 컴포넌트 요소(618)의 선택 특성은, 바인드 작업(616)의 값 속성에서 익스프레션이 적합하게 되도록 하는(qualify) XPath 익스프레션을 포함한다. 이 예에서, XPath 익스프레션은, 작업 핸들러를 바인드하고, 다음의 번역된 XBind를 생성하기 위해, 들어온(incoming) XBind가 적합하게 되도록 하는데 이용되는 XML 문서 내에서 적합한 조각을 식별한다.

URL = data/tasks.xml

Base path = /tasks/task/@description

Selection =

상술한 번역된 XBind는 data/tasks.xml#/tasks/task/@description와 같은 약칭으로 작성될 수 있다. 이에 관해, 번역된 XBind의 URL은 관련된 설명들을 저장하는 데이터 모델에서 XML 문서를 참조한다. URL에 의해 식별된 XML 문서 내에서, 베이스 경로는 태스크 요소와 이에 연관된 설명 속성을 참조하다. 이하에서 상세히 설명되듯이, XBind는 데이터 모델에서 조각들을 참조하는데 있어서 추가적인 특징으로 제공하는 "Selection"을 포함할 수 있다.

바인드 핸들링 루틴(1600)의 블록(1608)에서, 적합한 유저 인터페이스 컴포넌트에 의해 제공되는 설정 데이터 함수가 호출된다. 이 예에서, Input3 컴포넌트는 Bind 작업(616)의 대상이며, 태스크 설명들 목록에 바인드된다. 컴포넌트 API들은 특정 컴포넌트에서 데이터를 설정하는 어떤 메소드들을 정의하는데 사용될 수 있다. 일 실시예에서, Input3 컴포넌트는 블록(1608)에서 호출되는 설정 데이터 메소드를 포함할 수 있다. 특히, 적합한 컴포넌트가 뷰 오브젝트 및 바인드 작업 핸들러가 호출될 때 블록(1604)에서 수신한 컴포넌트 이름에 대한 참조에 기초하여 식별될 수 있다.

호출되면, 설정 데이터 메소드는, 컴포넌트가 데이터 모델의 XML 문서에 이미 바인드되지 않은 것을 보장하기 위해, 관리 기능들과 에러 핸들링을 수행한다. 이후 블록(1612)에서, 바인드 작업(616)의 대상인 Input3 컴포넌트는 업데이트 리스너로서 "data/tasks.xml" 문서에 추가된다. 상술한 바와 같이, 본 발명은 문서 오브젝트 형태로 XML 문서의 구조 객체 지향적 표현을 제공한다. 일 실시예에서, 문서 오브젝트들은, 웹 브라우저와 XML 파서(parser)에 의해 이용되는 DOM("Document Object Model") 오브젝트들에 대한 래퍼(wrapper) 역할을 한다. 이에 관해, 개선된 특징들은, 네트워크 오퍼레이팅 시스템 환경 내에 존재하는 어떠한 오브젝트들도 데이터 모델에 적용된 업데이트들에 대한 리스너들로 추가하는 능력을 포함하는 본 발명에 의해 제공되는 문서 오브젝트 내에서 인코딩된다. 오직 예로서, 데이터 업데이트 리스너들이 될 수 있는 오브젝트들은 프로세스들, 뷰들, 컴포넌트들, 통신 채널들 등을 포함하지만 여기에만 한정되지는 않는다. 블록(1612)에서, Input3 컴포넌트를 업데이트 리스너로서 "data/tasks.xml" 문서에 상응하는 오브젝트에 추가하도록 호출된다. 이에 관해, 각 문서 오브젝트는 데이터 업데이트에 대한 응답으로 통지될 리스너들의 목록을 유지한다. 블록(1612)에서 업데이트 리스너들을 추가하는 호출을 발행함으로써, Input3 컴포넌트는 동일한 문서 오브젝트 상에서 잠재적으로 많은 데이터 리스너들 중의 하나가 된다.

판단 블록(1614)에서, 업데이트 리스너로서 문서에 추가되는 컴포넌트가 규칙들을 이용하는지에 관해 판단이 된다. 일 측면에서, 본 발명은 규칙들이 데이터 바인딩 컴포넌트에 연관되도록 하는 기능성을 지원한다. 이에 관해, 규칙 핸들러가 컴포넌트들과 다른 오브젝트들이 그들의 데이터 바인딩을 해석할지를 정의하는 데이터 모델에 포함될 수 있다. 이하에서 상세히 설명되듯이, 규칙들은, 제네릭 컴포넌트들이 데이터 모델의 컨텐츠에 기초하여 해석하고, 학습하고, 적합한 동작을 취할 수 있게 한다. 따라서, 서로 다른 요소들, 속성들 및 계층구조들을 가진 XML 시맨틱스 또는 랭귀지들은 같은 종류의 제네릭 컴포넌트들을 이해 및/또는 바인드될 수 있다. 다시 말해, 규칙들을 사용하는 컴포넌트들은 어떤 데이터 모델에 특정되게 생성될 필요가 없다. 대신에, 규칙들은 컴포넌트들의 제네릭 세트가 어떠한 종류의 하부 데이터와 이용될 수 있도록 하므로, MVC 디자인 패러다임에서 진정한 데이터 추상화를 가능하게 한다. 컴포넌트는 하부 데이터 모델의 구조를 이해할 필요가 없으며, 원하는 기능성을 달성하기 위해 컨텐츠를 해석하는 규칙들을 이용할 수 있다. 규칙을 이용하는 컴포넌트와 바인딩을 설정할 때, 규칙들이 적용될 수 있도록 하기 위해 규칙 핸들러를 설정하고 업데이트하기 위한 기능성이 구현된다. 컴포넌트를 업데이트 리스너로 추가하는 호출시, 컴포넌트가 규칙 사용자인지를 나타내는 플래그가 포함될 수 있다. 따라서, 컴포넌트가 규칙 사용자가 아니라고 수신된 플래그가 나타내면, 블록(1614)에서 수행된 테스트의 결과는 "no"이며 바인드 핸들링 루틴(1600)은 블록(1618)로 진행하며, 이하에서 상세히 설명된다. 반대로, 컴포넌트가 규칙 사용자라고 수신된 플래그가 나타내면, 테스트의 결과는 "yes"이며 바인드 핸들링 루틴은 블록(1616)으로 진행한다. 블록(1616)에서, 데이터 바인딩 컴포넌트의 규칙들을 데이터 모델에서 유지되는 규칙 핸들러에 적용하거나 병합하는 설정 규칙 루틴(1600)이 실행된다. 이에 관해, 설정 규칙 루틴에 의해 구현된 로직은 도 21을 참조하여 이하에서 상세히 설명한다.

바인드 핸들링 루틴(1600)의 블록(1618)에서, 바인드 작업의 대상인 컴포넌트의 유저 인터페이스를 업데이트 하기 위한 호출이 생성된다. 컴포넌트 API들에 따라 정의된 메소드들은 유저 인터페이스의 업데이트를 수행하는데 이용될 수 있다. 특히, 컴포넌트 API들은 개발자들이 컴포넌트데 대한 "Update()" 메소드들을 구현하는데 이용되는 로직을 제공하도록 한다. 이에 관해, "Update()" 메소드 내에서 구현될 수 있는 로직이 도 22를 참조하여 이하에서 상세히 설명된다. 이 예에서, Input3 컴포넌트에 연관된 "Update()" 메소드는 디스플레이중인 데이터 모델에서 유지되는 태스크 설명들을 초래한다. 이후, 바인드 핸들링 루틴(1600)은 종료하는 블록(1620)으로 진행한다. Bind 작업(616)이 실행을 완료하면, 새로운 데이터 바인딩 컴포넌트는 데이터 모델("data/tasks.xml")에 영향을 미치는 업데이트들을 통지 받는다.

예시적인 MyTasks 어플리케이션(도 6A)에서, Bind 작업(616)은 실행되는 Initialize Application 프로세스 단계(604)에서 마지막 작업이다. Bind 작업(616)이 실행되면, MyTasks 어플리케이션의 프로세싱은 트리거가 생성될 때까지 아이들(idle) 상태를 유지한다. 이에 관해, 트리거 활성화 루틴(1700)이 도 17을 참조하여 이하에서 설명된다. 그러나, 트리거들의 이용을 설명하기 이전에, 본 발명에 의해 제공된 익스프레션 엔진에 의해 구현된 기능성의 설명이 추가적으로 상세하게 설명된다.

현존하는 플랫폼들에서, 개발자들은 데이터를 질의하고 어플리케이션의 연산 로직을 정의하는 동일한 프로그래밍 툴들을 제공받는다. 이에 관해, 사실상 명령형(imperative) 프로그래밍 랭귀지는, 모든 어플리케이션의 로직이 일련의 정렬된 선언문들로 결국 표현되도록 한다. 엄격한 프로그램밍 툴들의 정렬된 특성은 연산 로직을 구현하는데에는 적합한 반면, 엄격한 랭귀지의 데이터 쿼링 능력은 덜 견고(robust)해진다. 대신에, 비명령형(non-imperative) 랭귀지 프로그래밍 툴들은 데이터를 쿼링하거나 접속하는데 적합하다. 이를 위해, VO를 수행할 때, 개발자들이 비명령형 프로그래밍 랭귀지 툴들을 이용할 수 있는 익스프레션 랭귀지가 제공된다. 이에 관해, 익스프레션들은 XML 신택스와 호환되도록 구조화되며, 본 발명에 의해 제공된 XML 기반 프로그래밍 랭귀지들 안에서 한계가 정해진다. 어떻게 프로세스 XML 랭귀지가 익스프레션들을 용이하게 사용할 수 있는지에 대한 특정 예들이 여기에서 제공된다. 그러나, 익스프레션들은 다른 XML 랭귀지들에서 사용되기 위해 결합될 수 있으며 또한 직접적으로 오브젝트들 내의 프로그램 코드로부터 이밸류에이션되고 사용될 수 있으므로, 이 예들은 예시적인 것으로 해석되어야 한다.

MVC 디자인 패러다임을 고수하는 어플리케이션을 실행하도록 설정된 개발 플랫폼의 구현은 런타임시 변화할 수 있는 데이터에의 접속에 관한 도전들을 제공한다. 일 실시예에서, XBind는 내부 메모리(in-memory) 오브젝트들, 문서들, 데이터 서브셋들 등을 참조하는 표준화된 수단을 제공한다. 상술한 바와 같이, XBind는 URL, 베이스 경로(예를 들어, XML 문서 내의 조각 또는 전체 XML 문서를 참조하는 XPath 익스프레션), 및 선택(예를 들어, 복수의 XPath 익스프레션들)을 포함하는 3 차원 데이터 종류이다. 따라서, XBind는 헐겁게 결합된 시스템의 서로 다른 부분들이 표준화된 방법으로 자기들의 상태 정보를 효율적으로 송수신할 수 있도록 한다. 이에 관해, XBind들은 데이터를 유저 인터페이스 컴포넌트들에 바인딩하는 간단하고 쉬운 방법을 제공한다. 선택들의 이용을 통해, 컴포넌트의 상태는, 다른 시스템들에 입력으로 제공될 수 있는 XBind에서 설명되어 질 수 있다. 더 일반적으로, 네트워크 오퍼레이팅 시스템 환경 내에 있는 각 오브젝트는, 오브젝트의 상태를 설명하는 XBind에 대해 항상 질의될 수 있다. 따라서, 오브젝트의 상태를 설명하는 XBind는, 컴포넌트들의 상태를 "복제"하거나 전달하기 위해 다른 오브젝트에 설정될 수 있다. 다른 측면에서, 오브젝트에 연관된 XBind는 네트워크를 통해 동기화될 수 있다. 결과적으로, 원격 컴퓨터들상에서 실행되는 오브젝트들은 동기화된 상태를 유지하기 위해 XBind를 이용하여 업데이트될 수 있다. 이는 본 발명의 측면들이 네트워크를 통해 실시간 협업을 가능하게 하는 한 방법이다.

일 실시예에서, XPath 이밸류에이션들은 익스프레션 엔진에 의해 적용될 수 있다. 당업자라면 XPath는 특정 위치에서 XML 문서의 데이터를 식별하고 선택하는 랭귀지를 제공하는 World Wide Web Consortium(W3C)의 표준임을 이해할 수 있다. 또한 XPath는 특정 값들을 이밸류에이션하는 익스프레션들을 만들어내는 조약들(conventions)을 설정한다. 예를 들어, "description"으로 명명된 속성을 찾는 "@" 심볼의 축약된 신택스를 포함하는 XPath 익스프레션 "/tasks/task/@description"은 MyTasks 어플리케이션에서 이용된다. 이 신택스는 XPath 조약들에 부합하며, 특정한 선택 또는 매칭 파라미터를 만족하는 XML 문서에서 데이터의 서브셋을 참조하는데 이용된다.

본 발명에 의해 제공된 익스프레션 랭귀지는 개발자들이 런타임시 상태 변경들을 겪을 수 있는 내부 메모리(in-memory) 오브젝트들을 참조할 수 있도록 한다. 예를 들어, "#MyTasks"와 "#MyTask#input3" 익스프레션들은 다른 뷰와 컴포넌트 오브젝트들을 각각 참조한다. 간단한 표기를 이용하면, 개발자들은 이 내부 메모리 오브젝트들과 그들의 데이터 바인딩들을 구별할 수 있다. 예를 들어, 개발자가 오브젝트를 참조하는 대신에 "Input3" 컴포넌트에 바인드된 데이터에 접속하면, "{#MyTasks#input3}" 익스프레션이 이용될 수 있다. 이 특정 익스프레션은, MyTasks 뷰 안에 있는 Input3에 연관된 XBind에서 참조되는 XML 문서 안에서 발견된 값에 이밸류에이션한다. 구부러진 괄호({ 또는 })를 포함하는 익스프레션을 접하면, 익스프레션 엔진은 식별된 오브젝트에 바인드된 하나 이상의 XML 노드들을 텍스트나 XML로 변환한다. 이에 관해, 본 발명에 의해 제공된 뷰와 컴포넌트 오브젝들들은 그들의 데이터 바인딩들을 인지하며, 그들의 XBind에 대해 항상 질의받을 수 있다. 인스턴스에 관한 익스프레션들을 이밸류에이션함으로써, 익스프레션 엔진은 이러한 종류의 익스프레션들을 이밸류에이션할 때 적합한 오브젝트와 상응하는 데이터 바인딩을 식별할 수 있다. 따라서, 익스프레션 랭귀지는 개발자들이 내부 메모리 오브젝트들과 그들의 데이터 바인딩들을 같은 간단한 표기를 이용하여 참조할 수 있도록 한다. 또한, 익스프레션들은 통신 채널을 사용하여 자동적으로 획득될 수 있는 URL에 의해 식별된 외부 자원들을 참조할 수 있다.

문서들 내에서 데이터의 네비게이션과 선택을 위해 XPath를 이용하는 현존하는 시스템들과 달리, 본 발명의 측면들은 내부 메모리 오브젝트들과 그들에 연관된 데이터들이 XPath 조약들을 이용하여 참조될 수 있게 한다. "Input1"으로 명명된 컴포넌트가 "MyView"로 불리는 어플리케이션 뷰 안에 존재한다고 가정하면, 다음은 본 발명에 의해 이밸류에이션되는 유효한 익스프레션이다.

{ #My View#input 1 # @ name }

XML 문서, 변수, 또는 내부 메모리 오브젝트에 대한 참조 이후에, XPath 조약들은 컴포넌트들 XBind에 관한 익스프레션에서 마지막 "#" 문자 이후에 적용된다. 상대적인 XPath 익스프레션을 접하면, 베이스 경로 또는 컴포넌트 내에서의 선택은 바인드 핸들링 루틴(1600)(도 16)을 참조하여 설명된 제공된 XPath와 병합된다. 위에서 제공된 예시적인 익스프레션에서, 마지막 "#"은, XPath 익스프레션(예를 들어 "@name")이 상대적이므로 이 XPath 익스프레션은 컴포넌트들의 XBind와 병합되는 것을 나타낸다. 그러나, 본 발명에 의해 이밸류에이션된 XPath 익스프레션들은 또한 절대적일 수 있다. "/"으로 표기된 절대적 XPath 익스프레션을 이밸류에이션하는데 있어서, 본 발명의 측면들은 컴포넌트들의 XBind의 베이스 경로나 선택을 무시한다. 본 발명의 측면들은 상술한 것과는 다른 방법으로 XPath 조약들을 이용한다. XPath 조약들의 사용의 추가적인 예들은, 본 발명에 의해 이밸류에이션될 수 있는 다른 종류들의 익스프레션들에 더해, 공통적으로 양수된 미국 가특허출원 60/976,339 "Network-Based Operating System"(2007년 9월 28일 출원)에서 찾을 수 있으며, 이의 내용은 여기서 참조로서 명시적으로 결합된다.

일 실시예에서, 내부 메모리 오브젝트의 특성들은 익스프레션 랭귀지를 이용하여 접속될 수 있다. 이 특성들은 다음 신택스에 따라 그 데이터 종류에 상관없이 접속될 수 있다.

#MyView.id

내부 메모리 오브젝트에 동작들을 수행하는 메소드들은 익스프레션 랭귀지를 이용하여 호출될 수도 있다. 이에 관해, 본 발명에 의해 제공된 내부 메모리 오브젝트들은 이 메소드들로 인코딩될 수 있다. 익스프레션 랭귀지를 이용하면, 메소드들은 이 오브젝트들에서 직접 호출될 수 있다. 예를 들어, 다음은 오브젝트에서 메소드를 호출하는 본 발명에 의해 이밸류에이션된 익스프레션들의 종류이다.

#MyView#maximize()

#MyView#input1.clear ()

또한, 인수들로 다른 익스프레션들을 받아들이는 고차(higher-order)의 익스프레션들은 본 발명에 의해 이밸류에이션된다. 다시 말해, 익스프레션 랭귀지는, 다음의 예가 설명하는 것처럼, 비명령적 프로그래밍 테크닉들에 일치하는 익스프레션들의 반복적인 이밸류에이션을 지원한다.

# MyView#{#MyView#inputl.getName()}

이 예에서, Input1 컴포넌트의 이름은 getName() 메소드를 이용하여 내부 익스프레션에서 처음으로 이밸류에이션된다. 컴포넌트 이름을 식별하는 반복적으로 이밸류에이션된 익스프레션은 외부 익스프레션의 파라미터로 제공된다. 이것은 비명령적 프로그래밍 툴들이 본 발명에 의해 제공된 XML 프로그래밍 랭귀지들과 함께 결합되고 사용되는 방법의 한 예이다.

네트워크 오퍼레이팅 시스템 환경 내에서, 프로세스 단계들과 연관된 작업들은 트리거의 생성에 반응하여 실행될 수 있다. 다시 말해, 프로세스 단계들의 실행은 이벤트 주도적(event driven)일 수 있다. 따라서, MyTasks.xml 문서(600)가 오픈되면, 트리거(602)는 등록되어, 트리거가 활성화될 때 플로우는 적합한 프로세스 단계로 지시될 수 있다. 트리거 활성화 루틴(1700)은, 루틴(1700)을 구현하기 위해 이용된 오브젝트들 사이의 플로우와 상호작용들을 설명하는 도 17A-B를 참조하여 설명된다. 상술한 바와 같이, MyTasks.xml 문서(600)는 다음의 트리거(602)를 정의한다.

<trigger view = "MyTasks" component = "button 1" event = "select" step = "2">

도 17에 도시된 트리거 활성화 루틴(1700)은 사용자가 이 트리거 요소 내에서 식별된 Button1 컴포넌트를 선택하여서, 블록(1702)에서 트리거(602)를 활성화한다고 가정한다.

활성화된 트리거에 대한 응답으로, 트리거가 발생한 컴포넌트 오브젝트는, 블록(1704)에서 이벤트 매니저(914)에 노티파이 리스너들 호출(notify listeners call)을 패스한다. 호출시, 적합한 컴포넌트 오브젝트는 한 세트의 이벤트 데이터를 제공하며, 이벤트 매니저(914)가 노티파이어 오브젝트 또는 제공된 데이터에 매칭하는 오브젝트를 등록한 모든 이벤트 리스너들에게 통지하도록 지시한다. 도 17B를 특별히 참조하면, MyTasks 뷰 오브젝트(1752)에 연돤된 Button1 컴포넌트 오브젝트(1750)는 노티파이 리스너들 호출을 블록(1704)에서 이벤트 매니저(914)로 패스한다. 호출시, 이벤트 종류(예를 들어, "select") 뿐만이 아니라트리거 이벤트가 시작된 컴포넌트를 식별하는 익스프레션(예를 들어, "#MyTasks#button1")이 제공된다.

블록(1706)에서, 이벤트 매니저(914)는 이벤트의 활성화에 대한 하나 이상의 리스닝 오브젝트들에게 통지한다. 특히, 이벤트 매니저(914)는 Button1 컴포넌트 오브젝트(1750)으로부터 패스되는 이벤트 데이터가 이전에 이벤트 리스너가 등록될 때 제공된 데이터에 매치되는지에 대해 룩업을 수행한다. 이에 대해, 프로세스 시작 루틴(1100)(도 11)은 오브젝트들이 이벤트 매니저(914)에 이벤트 리스너를 등록할 수 있는지에 대한 설명을 제공한다. 일 실시예에서, 프로세스 XML 문서에서 접하는 각 트리거는 어플리케이션이 처음에 시작되면 상응하는 노티파이어 오브젝트가 이벤트 리스너로서 메모리에 미리 일시 저장되도록한다. 노티파이어 오브젝트는, 하나 이상의 어플리케이션 인스턴스들이 트리거를 활성화할 것으로 예상해서 어플리케이션의 최초 시작시 메모리에 미리 일시 저장된다. 미리 일시 저장된 노티파이어 오브젝트는 뷰 이름, 컴포넌트 이름 및 이벤트 종류에 연관되는데, 이들은 블록(1706)에서 룩업을 실행할 때 고유키(unique key) 역할을 한다. 다시 말해, 특정 뷰 안에서 컴포넌트가 트리거에서 식별된 이벤트의 종류를 경험할 때에만 상응하는 노티파이어 오브젝트가 이벤트 활성화를 통지받는다. 따라서, 단일 노티파이어 오브젝트만이, 실행중인 어플리케이션 인스턴스들의 수에 상관없이 프로세스 XML 문서에 정의된 트리거에 대한 이벤트 매니저(914)에 등록한다. 어플리케이션의 복수 인스턴스들이 존재해도, 이 아키텍쳐는 동일한 노티파이어 오브젝트가 각 어플리케이션 인스턴스들에 의해 재사용되도록 한다. 추가적으로, 이 아키텍쳐는, 단일 트리거가 이벤트 리스너를 이후에 다중 어플리케이션 인스턴스들에 의해 공유되는 노티파이어 오브젝트의 형태로 등록하므로, 이벤트 매니저(914)가 더 효율적으로 반복하고 리스너들에게 통지하도록 한다. 다른 말로, 블록(914)에서 수행되는 룩업의 성능은 실행중인 어플리케이션 인스턴스들의 숫자에 종속되지 않는다.

트리거 활성화 루틴(1700)의 블록(1708)에서, 활성화된 이벤트(트리거)에 연관된 적합한 인스턴스가 식별된다. 이벤트의 발생을 통지받으면, 인수들은 적합한 리스닝 오브젝트와 영향을 받는 인스턴스를 식별하는에 이용되는 이벤트 매니저(914)로 패스된다. 이 예에서, Button1 컴포넌트 오브젝트(1750)를 식별하는 익스프레션은 이벤트 매니저(914)에 제공되며, 속하는 인스턴스에 대한 참조를 수용하는 컴포넌트 뷰 오브젝트에의 접속을 통해 적합한 인스턴스를 식별하는데 이용될 수 있다. 상술한 바와 같이, 어플리케이션뷰를 오픈할 때, 인스턴스에 대한 참조는 결과 뷰 오브젝트에 제공된다. 따라서, MyTasks 뷰 오브젝트(1754)는 그에 연관된 인스턴스 오브젝트(1758)를 인지한다. 컴포넌트 오브젝트들은 뷰의 컨텍스트 내에서 생성되므로, Button1 컴포넌트 오브젝트(1750)는 MyTasks 뷰 오브젝트(1754)를 블록(1708)에서 적합한 인스턴스를 식별하는데 이용할 수 있다. 적합한 인스턴스가 알려지면, 인스턴스 오브젝트(1758)는 프로세스 오브젝트의 실행 메소드로 제공된다.

상술한 도 17B에 도시된 아키텍쳐와 설명은 어떻게 본 발명이 어플리케이션 로직의 이벤트 주도적 실행을 지원하는 시스템에서 상태가 보존되지 않는 프로세스 단계들의 실행을 지원하는지를 설명한다. 상술한 바와 같이, 단일 프로세스 XML 문서는 다중 어플리케이션 인스턴스들을 실행하는데 이용된다. 이에 관해, 프로세스 오브젝트는 다른 어플리케이션 인스턴스들에 의해 반복적으로 재사용될 수 있으므로, 어플리케이션들을 실행하는데 효율적인 플랫폼을 제공한다. 오직 단일 노티파이어 오브젝트(1756)가 어플리케이션에서 각 크리거에 대해 미리 일시 저장되지만, 본 발명은 적합한 인스턴스가 프로세스 오브젝트(1700)에 제공되도록 할 수 있다. 이에 관해, 노티파이어 오브젝트(1756)는, 뷰, 컴포넌트 및 이벤트 종류를 포함하는 고유 키에 매칭하는 이벤트가 이벤트 매니저(914)에 의해 수신되면 활성화된다. 또한, 이벤트 매니저(914)는, 제공받은 컴포넌트, 뷰 또는 이벤트 리스닝 오브젝트를 이용하여, 적합한 인스턴스 오브젝트(1758)를 식별하여 노티파이어 오브젝트(1758)에 제공할 수 있다. 트리거 활성화 루틴(1700)의 블록(1712)에서, 어플리케이션에서 프로세스 단계를 실행하는 호출이 생성된다. 상술한 바와 같이, 실행될 프로세스 단계는 노티파이어 오브젝트(1756)에 일시 저장되거나 이벤트 리스닝 오브젝트에 의해 알려진다. 따라서, 적합한 인스턴스가 제공되면, 노티파이어 오브젝트(1756)는 블록(1712)에서 (1) 어플리케이션의 현재 런타임 상태를 표현하는 인스턴스 오브젝트(1758)와 (2) 실행될 어플리케이션의 프로세스 로직에서의 프로세스 단계(예를 들어 "2")를 제공하는 실행 메소드(도 12)를 호출할 수 있다. 이후, 트리거 활성화 루틴(1700)은 종료하는 블록(1714)로 진행한다. 다른 이벤트 리스닝 오브젝트들은 프로세스 오브젝트 단계를 호출하거나 자체 커스텀 코드를 직접 실행할 수 있다.

MyTasks 어플리케이션의 트리거가 활성화되면, 실행 플로우는 판단 작업(620)으로 진행한다. 일반적으로 설명하면, 판단 작업(620) 내의 로직은, 트리거(602)가 활성화되면, 어떠한 텍스트가 Input4 컴포넌트에 입력되었는지를 판단하는 테스트를 수행한다. 이에 관해, 판단 작업(620)을 구현하는 판단 핸들링 루틴(1800)이 도 18을 참조하여 설명된다. 도 18에서 설명되듯이, 판단 핸들링 루틴(1800)은 익스프레션이 이밸류에이션을 위해 익스프레션 엔진에 패스되는 블록(1802)에서 시작한다. 이 예에서, 판단 작업(620)은, 블록(1802)에서 판단을 위해 익스프레션 엔진으로 패스되는 값 속성 "#MyTasks#input4"을 포함한다. 상술한 바와 같이, 개발자들은 내부 메모리 오브젝트들을 참조하기 위해 본 발명에 의해 제공된 익스프레션 랭귀지를 이용할 수 있다. 특히, 블록(1802)에서 선택되고 이밸류에이션을 위한 익스프레션 엔진에 패스되는 "#MyTask#input4" 익스프레션은 어플리케이션이 실행되면 상태 변경을 경험할 수 있는 컴포넌트 오브젝트를 참조한다.

블록(1804)에서, 이밸류에이션중인 익스프레션인 데이터 바인딩에 연관된 컴포넌트를 참조하는지에 관해 판단된다. 일부 경우에, 데이터 바인딩은 데이터 입력 및/또는 컴포넌트에 의해 디스플레이되는 데이터가 컴포넌트와 데이터 모델 사이에 자동적으로 전파되는지를 정의할 수 있다. 한편, 컴포넌트는 "아토믹(atomic)" 또는 존재하는 데이터 바인딩에 연관되지 않을 수 있다. 아토믹 컴포넌트들을 참조하는 익스프레션들을 이밸류에이션할 때, 익스프레션 엔진은 컴포넌트로부터의 데이터 입력/출력 또는 컴포넌트들의 상태에 영향을 미치는 다른 데이터가 작업 핸들러의 로직 내에서 접속될 수 있도록 하는 기능성을 구현한다. 이 기능성을 구현함으로써, 익스프레션 엔진은 이 데이터가 XML 기반 익스프레션을 이용하여 항상 접속 가능하도록 한다.

컴포넌트가 블록(1804)에서 데이터 바인딩에 연관되어 있는지를 판단하기 위해서, 익스프레션 엔진은 인스턴스를 이용하여 "Input4"로 명명된 컴포넌트 오브젝트를 식별할 수 있다. 상술한 바와 같이, 본 발명에 의해 제공되는 컴포넌트 오브젝트들는 그들의 데이터 바인딩들을 인지한다. 따라서, 적합한 컴포넌트 오브젝트가 식별되면, 익스프레션 엔진은, 컴포넌트가 아토믹하거나 데이터 바인딩에 연관되어 있는지를 용이하게 판단할 수 있다. 수행된 테스트의 결과가 익스프레션에서 참조되는 컴포넌트가 데이터 바인딩에 연관되어 있지 않다고 나타내면, 판단 핸들링 루틴(1800)은 블록(1808)로 진행하며, 이하에서 상세히 설명된다. 반대로, 블록(1804)에서 수행된 테스트의 결과가 익스프레션이 데이터 바인딩에 연관된 컴포넌트를 참조한다고 나타내면, 판단 핸들링 루틴(1800)은 블록(1806)으로 진행한다.

블록(1806)에 도달하면, 접한 익스프레션에서 참조되는 컴포넌트는 데이터 바인딩에 연관된다. 이 예에서, 데이터 바인딩의 비존재를 설명하는 임시 XBind를 생성하지 않고 익스프레션은 이밸류에이션된다. 더 상세하게는, 익스프레스 엔진은 블록(1806)에서 "#MyTasks#input4" 익스프레션을 이밸류에이션하고 Input4 컴포넌트로부터 XBind를 요청한다. 이 예에서, 익스프레션 엔진에 의해 반환되는 XBind는 작업 핸들러에 실행할 필요가 있는 모든것으르 제공한다.

일 실시예에서, 개발자들은 데이터에 억세스하거나 I/O를 수행하기 위해 XML 시맨틱 설명들을 제공할 수 있다. 그러나, 익스프레션은, 스크립팅 랭귀지(예를 들어, Java Script)로 구현된 내부 메모리 오브젝트로부터만 이용 가능한 데이터를 요구할 수 있다. 따라서, 컴포넌트가 바인드에 연관되지 않더라도, 본 발명은 익스프레션들이 상응하는 내부 메모리 오브젝트를 이용하여 컴포넌트에 연관된 데이터를 연산하고 접속할 수 있도록 한다. 예를 들어, MyTasks 어플리케이션의 판단 작업(620)은 다음 "<when>" XML 요소(622)를 포함한다.

<when test= "text() = " " step ="37>

<otherwise step="4"/>

when 요소(622)는 텍스트를 Input4 컴포넌트에 입력시키도록 요청하기 위해 XPath 이밸류에이션 조약들을 적용하는 XPath 익스프레션 "text()"를 포함한다. 컴포넌트가 아토믹하므로, 요청된 데이터는 현존하는 데이터 바인딩을 사용할 수 없다. 대신, 본 발명은 XML 기반 익스프레션을 이밸류에이션하고 요청된 데이터가 데이터 모델에서 현재 유지되지 않더라도 데이터에 접속할 수 있도록 한다. 대신에, 임시 XBind가 시스템 제공(system-provided) 상태 문서 내의 조각을 참조하는 오브젝트(예를 들어, 컴포넌트)에 대해 생성된다. 이하에서 상세히 설명되듯이, 시스템 제공 상태 XML 문서는 관련된 컴포넌트의 모든 상태 정보를 포함할 수 있다.

판단 핸들링 루틴(1800)의 블로(1808)에서, 요청된 데이터는 아토믹 컴포넌트에 연관된 내부 메모리 오브젝트로부터 획득된다. 작업 핸들러 내에 구현된 로직은 아토믹 컴포넌트의 상태를 포함하는 데이터를 이용할 수 있다. 예를 들어, 판단 핸들링 루틴(1800)의 블록(1808)에 도달하면, Input4 컴포넌트는 데이터 바인딩에 연관되지 않은 아토믹 컴포넌트이다. 따라서, 판단 작업(620)의 바디 내의 XPath 익스프레션 "text()"은 데이터 모델의 알려진 문서에 바인드되지 않은 컴포넌트의 상태를 포함하는 데이터를 요청한다. 이러한 종류의 익스프레션을 적절히 이밸류에이션하기 위해, 요청된 데이터는 데이터 모델로부터 이용 가능하여야만 한다. 이에 관해, 익스프레션에서 요청된 XBind가 존재하지 않으므로, 익스프레션 엔진은 관련된 데이터에 관한 Input4 컴포넌트를 질의할 수 있다.

일 실시예에서, 아토믹 컴포넌트가 이밸류에이션중인 익스프레션에서 참조될 때마다, 시스템 제공 상태 XML 문서가 컴포넌트의 현재 상태로 업데이트된다. 이하에서 상세히 설명되듯이, 요청된 데이터가 획득될 수 있는 시스템 제공 상태 XML 문서 내에서 적합한 조각을 지시하는 임시 XBind는 이후 생성될 수 있다. 다른 실시예에서, 시스템의 모든 컴포넌트들의 상태(컴포넌트가 아토믹이든 데이터 바인딩에 연관되든 상관없이)는, State Manger에 캡슐화된 기능성을 이용하여 시스템 제공 상태 XML 문서로 지속적으로 전파될 수 있다. 이 예에서, 요청된 데이터는 데이터 모델로부터 항상 이용 가능하며 번역된 XBind를 이용하여 접속 가능하며, 이하에서 설명된다. 특히, 이 실시예는 다중 클라이언트 컴퓨터들에 걸쳐 어플리케이션의 상태의 동기화를 가능하게 한다. 또한, 이 방법으로 데이터 모델에 상태 정보를 자동적으로 전파함으로써, 어플리케이션이 클로즈되고 뒤이어 오픈될 때, 어플리케이션의 상태는 쉽게 복구될 수 있다.

블록(1810)에서, 아토믹 컴포넌트로부터 획득된 데이터에 접속하기 위한 임시 XBind가 생성되고 적합한 프로세스 오브젝트로 반환된다. 어플리케이션이 아토믹 컴포넌트를 이용하는 작업을 포함하면, 데이터는 컴포넌트 오브젝트로부터 직업 획득될 수 있으며, 메모리 제공 상태 문서에 저장될 수 있다. 요청된 데이터가 획득된 상태 문서 내의 위치를 참조하는, 이 익스프레션을 이밸류에이션하는데 임시로 사용되는 번역된 XBind가 생성된다. "#MyTask#input4" 익스프레션을 이밸류에이션할 때, 익스프레션 엔진은 다음과 유사한 XBind를 생성할 수 있다.

URL = #State

Base path = /states/state[@qid = '#MyTasks#input4'] Selection =

이 XBind의 URL은, 컴포넌트 상태 정보를 저장하도록 할당된 시스템 제공 상태 XML 문서를 참조한다. 또한 베이스 경로는, 블록(1808)에서 Input4 컴포넌트로 입력된 텍스트가 저장된 상태 문서 내에서의 노드를 지시한다. 이밸류에이션되면, 임시 XBind는 익스프레션 엔진에서 적합한 프로세스 오브젝트로 반환된다. 이 방법으로 상태 정보를 저장하고 임시 XBind를 생성함으로써, 본 발명의 측면들은, 컴포넌트가 데이터 바인딩에 연관되어있는지에 상관없이 개발자들이 컴포넌트들과 그 데이터를 참조하기 위해 XML 기반 익스프레션들을 이용하도록 한다. 더욱 일반적으로, XML 문서들에 접속하는 모든 작업 핸들러들은, 데이터 바인딩에 연관되지 않은 아토믹 오브젝트들로 작업할 수 있고 참조할 수도 있다. 위에서 설명한 예와 같이, 익스프레션의 오브젝트들(예를 들어 컴포넌트들)에 대한 참조들은 XBind에 이밸류에이션된다. 결과적으로, 본 발명의 측면들은 컴포넌트들이 서로를 바인드하도록 한다. 이 종류의 바인딩이 정의되면, 두 번째 컴포넌트는 첫 번째 컴포넌트의 XBind를 효과적으로 "복제"한다. 다시 말해, 두 번째 컴포넌트에는 첫 번째 컴포넌트로부터의 동기화된 XBind가 제공된다. 컴포넌트들간의 데이터 바인딩은 바인딩의 타겟이 아토믹 컴포넌트인 경우에도 가능하다. 이 경우에, 두 번째 컴포넌트는, 첫 번째 컴포넌트의 상태를 설명하는 시세틈 제공 문서를 참조하는 XBind에 연관된다. 첫 번째 컴포넌트가 아토믹하므로, 이는 두 컴포넌트들간에 마스터-슬레이브 관계를 효과적으로 생성한다.

도 18에서 상세히 설명되듯이, 판단 작업 핸들러는, 판단 작업 (606)에서 정의된 이밸류에이션을 수행하도록 블록(1812)에서 호출된다. 이에 관해, 파라미터들은, 작업이 아토믹 컴포넌트를 포함하면, 호출시 임시 XBind를 포함할 수 있는 판단 작업 핸들러로 패스된다. 일 실시예에서, 개발자들은, 함수 호출 파라미터들 및 작업의 바디 내에 존재할 수 있는 XML 시맨틱 구조를 정의한 작업 API에 따른 작업들을 생성할 수 있다. 판단 작업(620)에서, 이밸류에이션된 XPath 익스프레션의 결과에 따라 프로그램 실행 플로우가 지시되도록 하는 요소들이 정의된다. 이 예에서, 텍스트가 Input4 컴포넌트로 입력되었는지를 판단하기 위해 판단 작업 핸들러 내에서 스트링 비교가 수행된다. 따라서, XPath 익스프레션(예를 들어 "text()")은 판단 작업 핸들러 내에서 텍스트로 이밸류에이션된다. 이밸류에이션중인 익스프레션이 아토믹 컴포넌트로부터 데이터를 참조하는 경우에, 특정 익스프레션을 이밸류에이션하기 위해 번역된 임시 XBind가 요청된 데이터를 획득하기 위해 사용된다. 특히, 판단 작업 핸들러에 패스되는 XBind는, Input4 컴포넌트로부터 이전에 추상화된 상태 데이터가 접속 가능한 시스템 제공 상태 문서에 대한 참조를 포함할 수 있다.

이후, 블록(1814)에서, 어플리케이션의 적합한 프로세스 단계를 수행하라는 호출이 생성된다. 판단 작업 핸들러 내에서 수행된 이밸류에이션의 결과는 실행 플로우를 프로세스 단계(608) 또는 프로세스 단계(610)로 지시할지를 결정한다. 판단 작업 핸들러가 호출되면, 프로세스 및 인스턴스 오브젝트들뿐만이 아니라 XBind도 수신된다. 이 수신된 인수들은 판단 작업 핸들러가 이밸류에이션의 결과에 따라 다음 적합한 프로세스 단계의 실행을 용이하게 시작하도록 한다. 이에 관해, 수신된 인수들은, 판단 작업 핸들러에 의해 수정되거나 직접 패스될 수 있다. 이후, 판단 핸들링 루틴(1800)은 종료하는 블록(1816)으로 진행한다.

상술한 바와 같이, 판단 작업(620)은, 트리거(602)의 발생시 텍스트가 Input4 컴포넌트에 입력되지 않으면, 실행 플로우가 프로스세 단계(610)으로 진행하도록 한다. 프로세스 단계(610) 에서의 유일한 작업은, 버튼 컴포넌트가 디스플레이하도록 하는 동작 작업(628)이다. 이에 관해, 동작 작업(628)은 도 15A-B를 참조하여 상술한 동작 작업 핸들러를 이용하여 실행될 수 있다. 따라서, 프로그램 플로우가 프로세스 단계(610)으로 지시될 때 구현된 기능성의 추가적인 설명은 여기서 상세하게 설명되지 않는다.

트리거(602)의 발생시 Input4 컴포넌트로 텍스트가 입력되면, MyTaks 어플리케이션의 실행은 프로세스 단계(608)로 진행한다. 프로세스 단계(608) 내에서 정의된 작업은, 컴포넌트로 입력된 텍스트가 XML 문서에 추가되도록 하는 변경 작업(624)이다. 이에 관해, 변경 작업 핸들러를 이용한 데이터 업데이트를 구현하는 예시적인 변경 핸들링 루틴(1900)이 도 19를 참조하여 설명된다.

도 19에 설명에서 설명되듯이, 변경 핸들링 루틴(1900)은, 익스프레션 이밸류에이션이 수행되는 블록(1902)에서 시작한다. 특히, 변경 작업(624)의 값 속성의 "data/tasks.xml" 익스프레션은, 블록(1902)에서 XBind로 이밸류에이션된다. 이 예에서, 이밸류에이션으로부터 발생된 XBind는, "data/tasks.xml" 문서의 루트 노드를 참조하는 URL과 베이스 경로를 포함한다.

상기 설명이 설명하듯이, 작업의 값 속성의 익스프레션은 어플리케이션의 각 작업들에 대한 XBind로 이밸류에이션된다. 일 실시예에서, 작업의 바디 내 익스프레션들은 오퍼레이터 핸들러에 의해 구현된 로직 내에서 이밸류에이션될 수 있다. 다른 실시예에서, 작업의 바디 내 익스프레션들은 적합한 작업 핸들러가 호출되기 전에 이밸류에이션될 수 있다. 양 실시예들이 지원되는 동안, 작업 핸들러의 로직의 작업의 바디 내 익스프레션들의 이밸류에이션이 더 효율적이므로 바람직하다. 이에 관해, 변경 작업(624)은 다음 "<store>" XML 요소(626)를 포함한다.

<store type="append" select="/tasks/task/@description" value=

" { #MyTasks#input4 } "

저장 요소(626) 내 익스프레션 "{#MyTasks#input4}"은 블록(1904)에서 텍스트로 이밸류에이션된다. 상술한 바와 같이, 본 발명에 의해 제공된 익스프레션 엔진은 개발자들이 구브러진 괄호 표기를 이용하여 익스프레션에 대한 이밸류에이션의 한계를 지을 수 있도록 한다. 이 익스프레션들은 속성들, 요소들간, 그리고 어플리케이션 코드의 다른 위치들에서 정의될 수 있다. 이 예에서, 익스프레션 엔진 내 로직은 익스프레션 "{#MyTasks#input4}"이 텍스트로 이밸류에이션되록 한다.

일반적으로, 본 발명에 의해 구현된 변경 작업은 개발자들에게 XML 문서의 컨텐츠에 대해 필요한 모든 수정을 수행하기 위한 원시 데이터 조작 툴(raw data manipulation tool)을 제공한다. 이에 관해, 본질적으로 World Wide Web Consortium의 DOM 표준과 일치하는 복수의 데이터 조작 프리미티브들(data manuplulation primitives)이 제공된다. 또한 본 발명의 측면들은, replaceText 와 삭제 칠드런 프리미티브들(delete children primitives)을 포함하는 추가 데이터 조작 프리미티브들을 제공한다. 따라서, 다음의 예시적인 프리미티브들은, 본 발명에 의해 제공되는 변경 작업(교체(replace), 텍스트 교체(replaceText), 붙임(append), 앞에 붙임(prepend), 삽입(insert), 제거(remove), 칠드런 제거(remove children), 신규(new), 및 삭제(delete))을 이용하여 XML 문서의 컨텐츠를 변경하도록 수행될 수 있다. 당업자라면, 제공된 프리미티브들이 데이터 모델에 대한 필요한 모든 수정들을 수행하기 위해 사용되거나 결합될 수 있음을 이해할 수 있다. 이하에서 상세히 설명되듯이, 데이터 모델에 영향을 주는 어떠한 변경 작업은, 만들어질 정확한 업데이트를 설명하는 트랜잭션 매니저(910) 내에서 트랜잭션이 생성되도록 한다.

변경 핸들링 루틴(1900)의 블록(1906)에서, 변경 작업 핸들러는 적합한 프로세스 오브젝트에 의해 호출된다. 블록(1906)에 다다르면, 현재 프로세스를 실행하는 프로세스 오브젝트는 적합한 인스턴스와 프로세스 오브젝트들뿐만이 아니라 이전에 이밸류에이션된 XBind를 변경 작업 핸들러에 패스할 수 있다. 이하에서 상세히 설명되듯이, 변경 작업 핸들러는 XML 문서의 컨텐츠를 수정하기 위해 수신한 인수들을 이용한다.

변경 핸들링 루틴(1900)의 판단 블록(1908)에서, 실행중인 변경 작업이 데이터 변형(data transform)을 정의하는지가 판단된다. 변경 작업(624)에서 정의된 값 속성은 변경 작업의 대상인 문서(예를 들어, "data/tasks.xml")를 식별한다. 저장 요소(626) 내에서, 셀렉트 속성은 데이터 수정이 실행될 특정 XML 문서 내 위치를 참조하는 XPath 익스프레션(예를 들어, tasks/task/@description)을 포함할 수 있다. 또한, 셀렉트 속성은, XML 문서에서 붙여지거나, 교체되거나 또는 포함될 컨텐츠를 이밸류에이션하는 익스프레션(예를 들어, "{#MyTasks#input4}")을 포함할 수 있다. 일 실시예에서, 본 발명의 측면들은, 데이터 모델에 붙여지거, 교체되거나, 추가되기 전에, 변경 작업 내에서 데이터가 변형되도록 한다. 예를 들어, 저장 요소(626)는, 특정 데이터 변형을 수행하기 위한 XSLT(Extensible Stylesheet Language Transformation)를 참조하는 변형 속성을 포함할 수 있다. 이런 종류의 데이터 변형이 정의되면, 블록(1908)에서 수행되는 테스트의 결과는 "yes"이며 루틴(1900)은 블록(1910)으로 진행한다. 그러나, 예시적인 MyTasks 어플리케이션의 변경 작업(624)은 변형 속성을 포함하지 않는다. 이 예에서, 블록(1908)에서 수행되는 테스트의 결과는 "no"이고, 루틴(1900)은 블록(1910)으로 진행하며, 이하에서 상세히 설명된다.

블록(1910)에서, 변경 작업 내에서 정의된 로직에 따라 데이터 변형이 적용된다. 실제 실시예에서, 변경 동작의 저장 요소는 XSLT 문서를 참조하는 변형 속성을 포함할 수 있다. XSLT 문서 내 로직은, 블록(1910)에서, 소스 포맷으로부터 목적 포맷으로 데이터를 변형하기 위해 적용될 수 있다. 전통적으로, XSLT는, 웹 페이지들의 동적 생성 및 수정들을 지원하기 위해 데이터를 변형하는데 이용되어 왔다. 또한, XSLT는, Electronic Data Interchange (EDI) 집적 서버들의 부분으로 XML 비즈니스 포맷 랭귀지들과 그들의 상응하는 구조들간 변형하는데 이용된다. 그러나, 이 예들은 단지 예시적인 것이며, XSLT는 다른 예들에서도 이용된다. 또한, 다른 트랜스폼 랭귀지들은 본 발명과 함께 사용될 수 있으며, XSLT의 사용이 제한하는 것으로 해석되어서는 안된다. 어떤 경우에도, 당업자라면 XSLT는 XML 스키마들과 다른 XML 스키마들 또는 DTD(Document Type Definition)을 구현하는 XML 문서들 사이뿐만이 아니라 다양한 마크업 랭귀지들(XML, HTML, XHTML 등)사이의 변형들을 정의하기 위한 XML 기반 랭귀지임을 이해할 것이다. 이에 관해, XSLT 프로세서는, 블록(1910)에서, 데이터 변형을 적용하기 위해 변경 작업 핸들러에 의해 사용될 수 있다. 이 방법으로 변형들의 동적 어플리케이션을 지원함으로써, 어플리케이션들이 데이터를 교환하고, 상호작용하며, 기능성을 집적하고/재사용하도록 잘 준비된 개량된 개발 플랫폼이 제공된다.

컴퓨터 사용자는, 이메일, 웹 브라우저, 캘린더 어플리케이션들, 워드 프로세서들, 미디어 플레이어들 등과 같은 복수 어플리케이션들을 일반적으로 이용한다. 그러나, 서로 다른 어플리케이션들에 의해 이용되는 데이터 포맷들과 로직은 현존하는 시스템을 이용해서는 호환되지 않는다. 예를 들어, 이메일 프로그램은 사용자들이 다른 사용자에 관련된 정보를 저장하고 접속하는데 이용되는 "연락처(contact)"를 정의하도록 할 수 있다. 한편, 캘린더 어플리케이션은 사용자들이 다른 사용자들, 그룹들 등을 포함하는 회의들과 약속들을 생성하도록 한다. 이메일 프로그램에서 정의된 연락처로부터의 메시지 검토에 대한 응답으로, 사용자는 캘린더 어플리케이션에서 새로운 회의를 자동적으로 생성하기를 원할 수 있다. 그러나, 서로 다른 어플리케이션들이 이 방법으로 상호작용하도록 하는 기능성을 지원하는 것은 현존하는 시스템을 이용해서는 용이하게 수행되지 않는다.

블록(1910)에서 적용되는 데이터 변형은, 변경 작업의 원시 데이터 조작이 수행되기 전에 발생한다. 이러한 종류의 데이터 변형들의 동적 어플리케이션을 지원함으로써, 본 발명의 측면들은, 어플리케이션 개발자들에게 다른 어플리케이션들로부터 이용 가능한 기능성과 데이터에 영향을 미치는 더 나은 기회들을 제공한다. 위에서 제공된 예에서, 이메일과 캘린더 어플리케이션이 상호작용하도록 용이하게 허용하는 데이터 변형이 수행될 수 있다. 예를 들어, XSLT 변형은 수신한 이메일 및/또는 연락처를 새로운 약속을 설명하는 데이터 항목(data item)으로 변환하기 위해 정의될 수 있다. 이에 관해, 변형은 연락처 정보, 이메일 메시지의 컨텐츠 및/또는 회의의 속성들을 설정하기 위한 사용자의 입력을 이용할 수 있다. 변경 작업 내에서, 서로 다른 하부 스키마들과 XML 구조가 이용되더라도, 서로 다른 어플리케이션들이 통신할 수 있도록 하는 이러한 종류의 XSLT 변형이 적용될 수 있다.

변경 핸들링 루틴(1900)의 블록(1912)에서, 변경 동작에서 표현된 특정 데이터 업데이트를 수행하는 호출이 적합한 URL 오브젝트에 대해 이루어진다. 이하에서 상세히 설명되듯이, 본 발명에 의해 제공된 URL 오브젝트는, 변경 작업 핸들러에 의해 지원되는 서로 다른 종류의 데이터 수정 프리미티브들(위에서 설명됨) 각각을 수핸하기 위한 메소드들을 노출하는 가벼운 포인터(lightweight pointer) 역할을 한다. 따라서, 변경 작업 핸들러는, 호출할 적합한 URL 오브젝트를 식별하기 위해 변경 작업(626) 내에서, 수신된 XBind와 로직을 이용한다. URL 오브젝트의 이용은 문서들과의 상호작용의 상세를 막기 위한 단순하게 구현되며, 본 발명은 다른 방법들로도 용이하게 구현될 수 있음이 이해될 수 있다. URL 오브젝트에 대한 호출이 이뤄지면, 실행 플로우는 이하에서 도 20을 참조하여 설명될 데이터 업데이트 루틴(2000)으로 진행한다. 이후, 변경 핸들링 루틴(1900)는 종료하는 블록(1914)으로 진행한다.

이제 도 20A-C를 참조하면, 데이터 업데이트 루틴(2000)과 루틴(2000)에 의해 사용되는 오브젝트들 사이의 상호작용이 설명된다. 도 20에 도시된 데이터 업데이트 루틴(2000)은 데이터 업데이트가 수행되는 블록들(2002 또는 2004)에서 시작하는 두 경우들을 설명한다. 데이터 업데이트 루틴(2000)이 블록(2002)에서 시작하는 실시예에서, URL 오브젝트는 변경 작업 핸들러(1250)의 컨텍스트 내에서 데이터 업데이트를 수행하는 호출을 수신한다. 상술한 바와 같이, 어플리케이션은 XML 문서의 컨텐츠를 수정하기 위한 변경 동작을 포함할 수 있다. 따라서, 변경 핸들링 루틴(1900)(도 19)은 블록(2002)에서 수신된 특정한 URL 오브젝트(1253) 상에서 데이터 업데이트를 수행하는 호출을 생성할 수 있다.

루틴(2000)이 블록(2004)에서 시작하면, 특정 URL 오브젝트(1253) 상에서 데이터 업데이트를 수행하는 호출은 유저 인터페이스 컴포넌트로부터 시작된다. 바인딩이 정의되면, 컴포넌트는 URL 및 바인딩에 연관된 XML 문서를 인지하게 된다. 예를 들어, Mytasks 어플리케이션의 Input3 컴포넌트는, Bind 작업(616)이 실행되면, "data/tasks.xml" 문서에 상응하는 URL 오브젝트를 수신한다. 이하에서 상세히 그리고 일 실시예에 따라 설명되듯이, HTML DOM을 이용하는 웹 브라우저는 유저 인터페이스를 렌더링하는데 이용될 수 있다. 이 실시예에서, 상응하는 뷰 오브젝트의 컨텍스트에서 생성된 컴포넌트 오브젝트들은 다양한 이벤트 리스너들이 웹 브라우저를 이용하여 HTML DOM 상에 등록되도록 한다. 컴포넌트는, 예를 들어, 사용자가 입력을 제공하거나 웹 브라우저에 디스플레이된 유저 인터페이스와 상호작용할 때 발생하는, HTML DOM에 영향을 미치는 이벤트들을 듣는다. 도 20B를 특별히 참조하면, 컴포너트(1252)는 수신한 데이터를 해석하고 데이터 업데이트 이벤트를 구현하도록 하는 호출을 URL 오브젝트(1253)로 생성한다. 예를 들어, "Update Presentation" 태스크가 예시적인 MyTasks 어플리케이션에서 삭제되면, "data/tasks.xml" 문서에 상응하는 URL 오브젝트가 생성되며 데이터 모델로부터 태스크 설명을 삭제하도록 호출된다. 이하에서 상세히 설명되듯이, URL 오브젝트(1253)는 이후 트랜잭션 매니저(910)과 데이터 업데이트를 통신한다. 차례로, 트랜잭션 매니저(910)는, 실제로 데이터 업데이트가 구현되도록 하는 하부 XML 문서 오브젝트로 데이터 업데이트를 전파한다. 데이터 업데이트를 구현하는 것에 더하여, 문서 오브젝트(1254)는 데이터 업데이트가 모든 적합한 리스닝 데이터 업데이트 오브젝트들로 전하되도록 한다. 이 리스닝 오브젝트들은 자주 컴포넌트들이지만, 다른 종류들의 오브젝트들이 될 수 있다. XML 문서는, XML 문서 오브젝트에 발생한 변경들을 듣는 원격 컴퓨터들에 걸쳐 공유될 수 있다. 그러나, 클라이언트측 캐시에서 유지되는 로컬 문서 오브젝트(1254)에 대한 데이터 업데이트는, 데이터 업데이트가 어떠한 원격 리스너들에게 전파되기 전에 구현된다. 다시 말해, 전체 네트워크 업데이트는 로컬에서 구현되는 데이터 업데이트에 이어서 수행된다.

데이터 업데이트 루틴(2000)의 블록(2006)에서, 업데이트될 문서 오브젝트(1254)에 대응하는 URL 오브젝트(1253)는 새로운 트랜잭션이 생성되도록 한다. 이에 관해, 트랜잭션 매니저(910)가 블록(2006)에서 호출되며, 새로운 "트랜잭션" 또는 XML 문서에 대한 상대적인 변경을 표현하는 XML 조각을 생성한다. 일 실시예에서, 트랜잭션 매니저(910)는 XML 조각에서 상대적인 변경을 구현하고 뒤바꾸기 위한 정보를 포함한다. 또한, 데이터 업데이트가 컴포넌트의 컨텍스트 또는 변경 작업 핸들로로부터 시작되는지에 상관없이, XML로 직렬화(serialized)된 XBind는 블록(2006)에서 생성된 트랜잭션과 함께 포함된다. 이하에서 상세히 설명되듯이, 트랜잰션 매니저(910)는 데이터 업데이트가 로컬에서 구현되고 어떠한 원격 리스너들에게 전파되도록 한다. 어느 경우에도, 데이터 업데이트가 수행될 데이터 모델에서의 위치 및 요청된 데이터 조작 작업을 되돌리는 로직(여기서는 "rollback" 수행이라고 함)을 포함하는 XML 포맷 데이터를 식별하는 XBind는 제공된다.

블록(2008)에서, 트랜잭션 매니저(910)는 데이터 업데이트가 로컬에서 구현되도록 한다. 트랜잭션은 데이터 모델에 대한 복수의 그리고 잠재적으로 다른 종류의 수정들을 포함하는 세션을 표현할 수 있다. 따라서, 데이터 통지 이벤트시, 데이터 모델에 대한 수정들이 설명되는 유닛을 표현하는 하나 이상의 업데이트 이벤트 오브젝트들이 생성된다. 한편, 트랜잭션은 데이터 모델에 대해 만들어지는 하나 이상의 변경들과 이 변경들을 되돌리는 로직을 완전히 설명한다. 또한, 데이터 통지 이벤트들을 송부하는 것에 더하여, 문서 오브젝트들은 업데이트 이벤트 오브젝트들에서 표현된 하부 XML 문서의 실제 컨텐츠를 수정하는 메소드를 제공한다. 특히, XML 문서상에서 실행될 수 있는 각 데이터 조작 프리미티브(replace, append, prepend, insert 등)는, URL 오브젝트(1253), 트랜잭션 매니저(910) 및 문서 오브젝트(1254)에 의해 제공된 상응하는 메소드들에서 구현된다.

도 20의 블록(2012)에서 설명되듯이, 트랜잭션 매니저(910)는 어떠한 원격 리스너들에게 트랜잭션을 전파하기 위해 통신 매니저(1256)를 호출한다. 이에 관해, 통신 매니저(1256)는 어플리케이션들이 원격 네트워크 서비스들과의 통신들을 추상화하는 채널들을 인스턴스화하도록 한다. 수신된 XBind에 기초하여, 통신 매니저(1256)는, 만약 있다면, 네트워크를 통해 트랜잭션을 전송하기 위한 적합한 통신 채널을 식별한다. 이하에서 상세히 설명되듯이, 통신 채널들은 URL 표준에 의해 정의된 대로 서로 다른 프로토콜들 하에서 동작한다. 예를 들어, 적합한 통신 채널은, "http://," "xios://," 또는 "database://" 같은 URL에서 식별된 트로토콜에서 식별될 수 있다. 통신 API들에 따라 획득된 로직을 이용하면, 트랜잭션 매니저(910)로부터 수신한 데이터는 원격 네트워크 서비스에 의해 이해될 수 있는 포맷으로 번역된다. 이에 관해, 통신 채널들을 이용한 네트워크 통신을 수행하기 위한 시스템들과 방법들은 이하에서 상세히 설명된다. 특히, 로털 데이터 리스너들에게 통지하고 업데이트하기 위한 로직은, 네트워크를 통해 전송되는 상응하는 트랜잭션 전에 그리고 독립해서 수행된다. 일 실시예에서, 본 발명은 비동기적으로 네트워크를 통해 트랜잭션들을 전파하도록 설정된다. 결과적으로, 로컬에서의 어플리케이션의 실행은, 네트워크 통신들에 내재된 네트워크 레이턴스(latency)나 다른 지연들에 의해 방해받지 않는다. 이후, 트랜잭션이 적합한 체널로 제공되면, 데이터 업데이트 루틴(2000)은 종료하는 블록(2014)로 진행한다.

이제 도 20C를 참조하면, 어떻게 트랜잭션들이 원격 클라이언트들 사이에서 전파되는지에 대한 설명에 적합한 예시적인 네트워킹 환경이 설명된다. 상술한 바와 같이, 트랜잭션 매니저(910)는, 로컬에 저장된 문서들에 대한 상대적인 변경을 표현하는 트랜잭션들 또는 데이터 조각들이 어떠한 원격 리스너들에게 전파되도록 한다. 도 20C에 도시된 예에서, 클라이언트들(2080, 2082)와 함께 시작된 트랜잭션들은 서버측 데이터 센터에서 유지되는 XML 파일 시스템(2084)로 연속적으로 전송된다. 특히, 각 클라이언트들(2080, 2082)은 트랜잭션들(2086-2088 및 2090-2092)을 능동적으로 공유된 문서(2093)에 전파한다. 클라이언트측 캐시(2098)에서 로컬하게 수행된 문서 오브젝트들(2094 또는 2096)에 대한 어떠한 데이터 업데이트들은, 식별되고 XML 파일 시스템(2084)으로 전파되어, 클라이언트들(2080, 2082)이 실시간으로 데이터를 공유할 수 있다.

이제 도 21을 참조하면, 어떻게 규칙들이 더욱 지능적인 컴포넌트들을 제공하기 위해 적용되는지에 대한 추가적인 설명이 제공된다. 데이터에 바인드될 때, 컴포넌트에 연관된 어떠한 규칙들은 데이터 모델에 고유한 네임스페이스(namespace)를 적용하고 할당한다. 일반적으로 설명하면, 규칙들은, 데이터 모델의 컨텐츠에 기초하여 제네릭 컴포넌트들이 해석하고, 학습하고, 적합한 동작을 취하도록 한다. 다시 말해, 컴포넌트를 이용하는 규칙은 특정 데이터 모델들을 위해 생성될 필요가 없다. 이에 관해, 상술한 바인드 핸들링 루틴(1600)(도 16)은 특정 컴포넌트가 규칙들을 이용하는지를 판단할 수 있다. 이 경우에, 도 21을 참조하여 설명된 설정 규칙 루틴(2100)은 새로운 컴포넌트의 데이터 바인딩에 연관된 규칙들을 적용하고 병합하기 위해 호출될 수 있다. 일 실시예에서, 컴포넌트의 규칙들의 고유한 XML 네임스페이스는 데이터 모델로 병합되고, 데이터 모델에 바인드된 컴포넌트들에게 용이하게 이용가능해진다. 다른 실시예에서, 컴포넌트에 연관된 규칙들은 원격에서 저장될 수 있으며, 웹 서비스들이나 추가적인 XML 문서들을 통해 접속가능할 수 있다.

도 21에서 설명되듯이, 설정 규칙 루틴(2100)은 블록(2102)에서 시작하며, 결정 블록(2104)에서, 적합한 문서에 대한 규칙 핸들러가 정의되었는지에 대해 결정된다. 이에 관해, 규칙 핸들러들은 서로 다른 컴포넌트들에 연관된 규칙들이 동일한 데이터에 관해서 실행될 수 있도록 한다. XML 문서에 바인드된 규칙 사용(rule-using) 컴포넌트 각각은 데이터 모델에서 유지되는 상응하는 규칙 핸들러에 로직(예를 들어, "규칙들")을 제공한다. 따라서, 규칙들을 이용하는 컴포넌트가 관련된 문서에 이미 바인드되었으면, 상응하는 규칙 핸들러는 존재하고, 루틴(2100)은 블록(2108)로 진행하며, 이하에서 상세히 설명된다. 이에 관해, 다수의 규칙 사용 컴포넌트들이 동일한 문서에 바인드되면, 동일한 규칙 핸들러는 모든 컴포넌트들에 대해 사용될 수 있다. 반대로, 규칙 사용 컴포넌트가 관련된 문서에 이미 바인드되어 있지 않으면, 루틴(2100)은 블록(2106)으로 진행한다. 도 21의 블록(2106)에서 상세히 설명되듯이, 새로운 규칙 핸들러가 동일한 하부 데이터에 바인드된 각 컴포넌트들의 규칙들을 수용하기 위해 생성된다.

상술한 바와 같이, 현대 그래픽 기반 어플리케이션들에 의해 사용되는 종류의 제네릭 컴포넌트들의 한 세트가 제공된다. 규칙들을 정의함으로써, 본 발명에 의해 제공된 제네릭 컴포넌트들은 하부 데이터 모델에 대해 어떠한 것도 이해할 필요가 없다. 이에 관해, 도 8A는 파일 시스템에서 폴더들의 계층 구조를 시각적으로 도시하고, 폴더 이름들, 아이콘들 등을 포함하는 트리 컴포넌트(800)를 설명한다. 데이터 모델에서 유지되는 컨텐츠로 제네릭 트리 컴포넌트를 만드는(ppopulate) 로직을 제공하는 규칙들은 정의될 수 있다. 예를 들어, 본 발명의 측면들은, 문서의 각 요소들이 서로 다른 폴더를 표현하는 folders.xml 문서의 파일 시스템의 컨텐츠들을 설명할 수 있다. 식별자, 아이콘 등과 같은 특정 폴더들에 연관된 데이터는 폴더 요소 내 속성들에 따라 식별될 수 있다. 오직 예로서, 다음 규칙들은 도 8A에 도시된 트리 컴포넌트(800)에 디스플레이 하기 위한 folders.xml 문서 안의 컨텐츠를 해석하도록 정의될 수 있다.

<tree name = "folder tree">

<rule match="folder" display=" @id"/>

<rule match="folder [@id ='email']'' display="@id" icon=

"icons/mailicon.png"/>

</tree>

이에 관해, "folder"의 매칭 속성과 "@id"의 디스플레이 속성을 갖는 첫번째 규칙 요소는 folder.xml 문서의 "id" 속성의 컨텐츠들이 폴더 이름으로 디스플레이되도록 한다. 따라서, 도 8A에 도시된 트리 컴포넌트(800)에서 폴더들에게 할당된 이름들은 규칙을 이용해서 정의될 수 있다. "folder[@id ='emair]"의 매칭 속성을 갖는 두번째 규칙 요소는 "email"의 이름 속성을 갖는 폴더들에 도 8A에 도시된 것과 같이 이메일 메세지들에 연관된 특정한 아이콘이 할당되도록 한다. 위에서 제공된 규칙들은 단순히 예시적인 것이며, 트리 컴포넌트(800)의 컨텐츠들을 만드는데 실제로 사용되는 로직의 서브셋만을 포함하는 것을 이해하여야 한다. folders.xml 문서의 구조가 수정되는 경우에, 컴포넌트의 규칙들은 그 변경을 설명하기 위해 용이하게 업데이트될 수 있다. 또한, 규칙 사용 컴포넌트들은 다른 데이터 업데이트들과 같은 방법으로 변경들을 통지 받는다. 특히, 이벤트 업데이트 오브젝트가 생성되고, 이하에서 상세히 설명될 데이터 업데이트 이벤트 통지 버스의 노티파이 리스너 루틴(notify listeners routine)(2200)을 이용하여 컴포넌트에게 변경들을 통지하는데 이용될 수 있다.

다시 도 21을 참조하면, 데이터 모델에 바인드된 컴포넌트의 규칙들이 블록(2108)에 적용된다. 규칙 핸들러가 생성되면, 바인드 작업의 대상인 컴포넌트는 규칙들은 적합한 규칙 핸들러에 제공한다. 이에 관해, 규칙 핸들러는 데이터 모델에 대한 확장(extension) 역할을 하며, 동일한 문서에 구석되는 서로 다른 데이터 바인딩 컴포넌트들의 규칙들을 관리한다. 일 실시예에서, 네임스페이스들은 컴포넌트들 또는 오브젝트들을 이용하여 서로 다른 규칙의 용어들을 분리하는 데이터 모델에 할당될 수 있다. 네임스페이스들을 이용하여 컴포넌트 규칙을을 할당하고 관리함으로써, 규칙 핸들러는, 데이터 모델 내에서 충돌들을 회피하는 방법으로 모든 컴포넌트 규칙들을 실행할 수 있다.

블록(2108)에서 새로운 규칙들을 적용할 때, 규칙 핸들러는 호출되어 관련된 문서에 바인드된 각 컴포넌트의 규칙들이 실행되도록 한다. 다시 말해, 잠재적으로 다수의 데이터 바인딩 컴포넌트들에 연관된 규칙들은 데이터 모델의 현재 버전에 관해서 실행된다. 이후, 모든 규칙들이 실행되면, 바인드 작업의 대상인 컴포넌트는 규칙 핸들러에 의해 상응하게 할당된 네임스페이스를 인지하게 된다. 특히, 규칙 핸들러는 컴포넌트의 규칙들에 할당된 데이터 모델에서 네임스페이스를 식별하는 새로운 데이터 바인딩에 연관된 컴포넌트에 대한 참조를 패스한다.

설정 규칙 루틴(2100)의 블록(2110)에서, 바인드 작업의 대상인 컴포넌트에 연관된 규칙들은 다른 컴포넌트들의 규칙들과 함께 병합된다. 개발자들은, 본 발명에 의해 제공된 XML 기반 랭귀지들을 이용하여 컴포넌트의 규칙들의 시맨틱 로직을 정의할 수 있다. 예로서, 규칙은 XPath 익스프레션들, UIXML 로직 참조들, 다른 컴포넌트들을 설명하는 요소들, 변수들, 앨리어스들 및 규칙 네임스페이스의 저장소 외부의 데이터에 대한 다른 참조들을 포함할 수 있다. 이에 관해, 서로 다른 컴포넌트들의 데이터 바인딩들은, 연관된 어플리케이션과 규칙 로직 덕분에 이행성(transive) 관계를 가질 수 있다. 따라서, 동일한 하부 데이터 상에서 동작하는 서로 다른 컴포넌트들의 규칙들은 데이터 모델에서 또한 유지된다. 컴포넌트가 그의 네임스페이스를 인지하게 되면, 컴포넌트에 새로운 데이터를 설정하는 호출이 생성된다. 이 경우에, 컴포넌트상에 새로운 데이터를 설정하는 호출은 컴포넌트 규칙의 시맨틱 로직이 서로 다른 컴포넌트들에 연관된 규칙들로부터 분리된 네임스페이스의 데이터 모델에 포함되도록 한다.

블록(2112)에서, 데이터 모델에 반영된 데이터 업데이트가 어떠한 데이터 업데이트 리스너들에게 전파되도록 하는 호출이 생성된다. 상술한 바와 같이, 문서 오브젝트는 데이터 업데이트에 대한 응답으로 통지되는 리스너들의 목록을 유지한다. 데이터 모델에 새로운 규칙들이 추가되면, 블록(2010)에서 발생하듯이, 상응하는 리스너들은 데이터 업데이트를 통지받는다. 이에 관해, 리스너들에게 업데이트를 통지하는 로직은 이하 도22를 참조하여 상세히 설명된다. 이후, 설정 규칙 루틴(2100)은 종료하는 블록(2114)으로 진행한다.

위의 예에서, 컴포넌트가 데이터 모델에서 유지되는 컨텐츠들을 자동적으로 디스플레이하도록 하는 바인딩들이 정의되었다. 바인딩들을 이 방법으로 이용함으로써, 개발자들은 유저 인터페이스 컴포넌트 상에서 데이터를 설정하고 업데이트하기 위한 로직을 어플리케이션 코드에서 제공해야 하는 것에서 해방된다. 그러나 위의 예들은 매우 단순화되었으며, 본 발명의 한 예시적인 측면을 반영한 것에 불과한다. 이에 관해, 바인딩들과 상응하는 XBind들은 복잡한 기능성을 구현을 가능하게 한다.

일 실시예에서, 본 발명은, 현재 상태를 설명하고, 저장하고, 통신하기 위한 오브젝트에 대한 표준화된 수단을 제공한다. 예로서, 도 8A는 사용자들이 찾아가고, 파일 시스템에서 폴더들을 선택할 수 있도록 하는 트리 컴포넌트(800)을 설명한다. 사용자 선택은, 네트워크 오퍼레이팅 환경에서 표준화된 변수 포맷을 제공하는 XBind에서 설명될 수 있다. 도 8A에 도시된 예에서, 사용자는 "video_encoding"으로 명명된 폴더에 찾아가기 위해 일련의 선택을 한다. 이 특정 폴더의 선택에 관한 트리 컴포넌트(800)의 상태는 다음 XBind에서 설명될 수 있다.

URL: folder s. xml

XPath: /

Selection: /folders/research/work/video_encoding/

위에 제공된 예는 단순화되었으며 설명하는 목적으로만 이용된다. 실제 실시예에서, 트리 컴포넌트(800)을 설명하는 XBind는 실제로 다음과 같다.

URL: folders.xml

XPath: /

Selection: /fs:folder/fs:folder[@name = 'research']/fs:folder[@name = 'work']/fs:folder[@name = 'videoencoding]

여기서 설명된 모든 XBind는 어디에 데이터가 저장되었는지에 상관없이 데이터를 참조하는데 이용될 수 있다. 따라서 하부 데이터가 네트워크 위치에서 유지되면, 상기 선택은 다음 XBind에서 설명된다.

URL: http://www.networkdomain.com.folders.xml

Base path: /

Selection: /folders/research/work/video_encoding/

어떤 경우에, 다른 오브젝트들은 동작들을 수행하거나 어플리케이션 기능성을 구현하기 위한 기초로서 사용자 선택을 설명하는 XBind를 자주 이용한다. 도 8B에 설명되듯이, 목록 컴포넌트(850)는 트리 컴포넌트(800)으로부터 만들어진 사용자 선택에 기초할 수 있는 파일 시스템 데이터를 디스플레이 한다. 예를 들어, 목록 컴포넌트(850)는 트리 컴포넌트(800)에서 선택된 폴더에 기초하여 문서들(예를 들어, "whitepaper.txt," "testresults.xml," 및 "blog.html")을 디스플레이하도록 설정된다. 선택을 설명하는 XBind는 트리 컴포넌트(800)에 의해 공유되는 데이터 모델에 대한 출력이다. 차례로, 이 XBind는 다른 리스닝 오브젝트들(예를 들어, 목록 컴포넌트(850))에 입력으로 제공될 수 있다. 따라서, 한 오브젝트(예를 들어, 목록 컴포넌트(850))에 제공된 입력은 다른 오브젝트로부터 데이터 모델에 이미 계속되는 출력에 끼워진다. XBind의 구현은, 데이터 모델로부터 접속되는 값들이 이전 I/O의 값들에 의존하는 이 I/O의 끼우기를 가능하게 하는 제네릭 변수 포맷을 제공한다. 이에 관해, XML 가상 머신을 구현하는 오브젝트들의 내부 연산 로직은 다른 오브젝트들과 시스템들과의 상호작용으로부터 분리된다. 일 측면에서, XBind들은, 상호작용들을 모델링하고 이를 분리하도록 하는데 이용되는 표준화된 변수 포맷을 제공한다. 본 발명에 의해 제공된 XBind들은 요청된 데이터에 대한 값들을 포함하지 않는다. 대신에, XBind들은 데이터를 획득할 수 있는 위치들을 참조함으로써, 서로 다른 오브젝트들과 시스템들이 동일한 하부 데이터를 가지고 동작할 수 있게 한다. 또한, XBind들은, XML 기반 시스템 사용을 위해 변형되거나, 병합되거나, 직렬화될 수 있다. 여기서 설명된 것처럼, XBind 는 XBind의 선택 측면을 이용하여 오브젝트 상태 정보의 전달자(carrier) 역할을 한다. 특히, XBind들은 오브젝트 상태 정보가 획득될 수 있는 위치들을 참조하므로, 상태 정보는 참조되는 정보나 오브젝트들을 바꾸거나 변경하지 않고 통신될 수 있다.

사용자가 파일 시스템을 찾아갈 때, 트리 컴포넌트(800)는, 선택을 설명하기 위해 XBind의 모든 차원들을 이용할 수 있다. 예를 들어, 사용자가 트리 컴포넌트(800)에서 "whitepaper.txt" 및 "testresults.xml" 문서들을 모두 선택하면, 선택은 다음 XBind에서 설명될 수 있다.

URL: folder s. xml

Base path: /folders/research/work/video_encoding/

Selection: /folders/research/work/video_encoding/document[ @ name = 'testresults.xml']

/folders/research/work/video_encoding//document[@name =

'whitepaper.txt']

다시, 위의 예가 예시적인 목적들을 위해 이용되며 본 발명의 실제 실시예를 표현하지는 않는다. 이 XBind의 URL은, 파일 시스템을 설명하는 하부 XML 문서를 참조하며, 베이스 경로는 바인딩을 "video_encoding" 폴더에 한정한다. 또한, 이 XBind의 선택은, 사용자에 의해 선택된 각 문서를 식별하는 XPath 익스프레션의 어레이를 포함한다. 위에서 제공된 설명과 유사하게, 이 XBind는 동작들을 수행하기 위해 다른 오브젝트들에 대한 기준 역할을 할 수 있다. 예로서, 사용자는 선택된 문서들을 삭제하는 이벤트를 생성한다. 트리 컴포넌트(800)의 선택 상태를 설명하는 위의 XBind는 파일 삭제를 구현하는 시스템에 입력으로 제공된다.

이전에 나타난 바와 같이, 컴포넌트들과 다른 오브젝트들은 데이터 모델에서의 변경에 대한 응답으로 통지된다. 본 발명의 측면들은 컴포너트들을 특정 문서 상에서 수행된 데이터 업데이트들에 대한 리스너로 등록하도록 한다. 데이터 업데이트가 발생하면, 문서 오브젝트에 등록된 각 리스너는 데이터 업데이트를 통지 받고 그에 따라 유저 인터페이스를 업데이트할 수 있다. 이제 도 22를 참조하면, 데이터 업데이트들을 리스닝 컴포넌트들에 전파하는 노티파이 리스너 루틴(2200)이 설명된다. 노티파이 리스너 루틴(2200)이 리스닝 컴포넌트 오브젝트들을 참조하여 설명되나, 다른 오브젝트들도 데이터 업데이트 리스너들이 될 수 있으므로 이는 단순한 예시이다.

도 22에서 설명되듯이, 노티파이 리스너 루틴(2200)는, 데이터 업데이트가 XML 문서 상에서 수행되는 블록(2202)에서 시작한다. 위의 예에서 설명되듯이, 데이터 모델에 대한 데이터 업데이트들은 서로 다른 환경들에서 수행될 수 있다. 데이터 바인딩 컴포넌트와 상호작용할 때, 사용자는 컴포넌트에 의해 데이터 모델에서 자동적으로 계속되는 입력을 생성할 수 있다. 한편, 데이터 업데이트는 변경 작업에서 정의된 어플리케이션 로직 실행의 결과로서 수행될 수 있다. 또한, XML 가상 머신을 구현하는 오브젝트들은, 공유 데이터 모델과 바인딩들을 통신 인터페이스로서 이용할 때, 데이터 업데이트를 수행한다. 예를 들어, 컴포넌트의 규칙들의 시맨틱 설명은, 서로 다른 컴포넌트들이 동일한 하부 데이터를 해석하도록 하는 데이터 모델에 계속된다.

블록(2204)에서, 데이터 업데이트가 상응하는 규칙 핸들러로 문서 상에서 수행되었는지 여부가 판단된다. 규칙 사용 컴포너트가 문서에 이전에 바인드되지 않아서 규칙 핸들러가 정의되지 않으면, 블록(2204)에서 수행된 테스트의 결과는 "no"이고 노티파이 리스너 루틴(2200)은 블록(2208)로 진행하며, 이하에서 상세히 설명된다. 반대로, 관련된 문서가 상응하는 규칙 핸들러를 가지면, 노티파이 리스너 루틴(2200)는 블록(2206)으로 진행한다.

블록(2206)에서, 데이터 업데이트를 경험한 문서에 연관된 규칙 핸들러가 호출된다. 규칙 핸들러를 호출함으로써, 로직은, 각 데이터 바인딩 컴포넌트들에 의해 이해되는 규칙 네임스페이스는 현재임을 보장하고 데이터 모델의 무결성을 지키기 위해 구현된다. 이에 관해, 블록(2002)에서 수행되는 데이터 업데이트는 규칙 핸들러에 로직을 추가하거나 수정하는 것을 포함할 수 있다. 예를 들어, 새로운 데이터 바인딩이 정의되면, 설정 규칙 루틴(2100)(도 21)은, 데이터 바인딩에 연관된 새 컴포넌트의 규칙들이 다른 컴포넌트들의 규칙들과 함께 데이터 모델에 병합되도록 한다. 동일한 하부 문서에 바인드된 어떠한 리스닝 컴포넌트들은 노티파이 리스너 루틴(2200)내에서 규칙 핸들러에 대한 데이터 업데이트에 대해서 통지받는다.

위에서 설명된 설정 규칙 루틴(2100)(도 21)에서, 규칙 핸들러는 현재 버젼의 데이터 모델에 반영된 모든 규칙이 실행되도록 한다. 이후 새로운 데이터 바인딩에 연관된 컴포넌트는, 데이터 모델에서 컴포넌트의 상응하는 규칙들에 관한 현재 네임스페이스 정보를 제공받는다. 그러나, 새로운 규칙의 추가가 다른 규칙 사용 컴포넌트들의 바인딩들에 영향을 줄 수 있으므로, 업데이트 통지는 이 규칙 사용 컴포넌트들에 또한 제공된다. 따라서, 블록(2206)에서 호출될 때, 규칙 핸들러는 현재 버젼의 데이터 모델에 반영된 모든 규칙들이 실행되도록 한다. 결과적으로, 규칙 핸들러는 현재 네임스페이스 정보와 최신 규칙들을 규칙 사용자인 어떠한 리스닝 컴포넌트에 제공할 수 있다. 교대로, 이 새로운 데이터는 컴포넌트 상에 설정되므로, 새로운 규칙들의 데이터 업데이트가 리스닝 컴포넌트들의 데이터 바인딩에 반영되도록 한다.

규칙 핸들러가 종료하면, 리스닝 컴포넌트에 연관된 "Update()" 메소드가 블록(2208)에서 호출된다. 컴포너트들은 컴포넌트 API들에 따라 정의되었으므로, "Update()" 메소드 내에서 수행되는 로직은 설정 가능하다. 다시 말해, 각 컴포넌트는 "Update()" 메소드 내에서 동일한 로직을 구현하지 않는다. 대신에, 개발자들은 이 로직을 채택하고 XML 가상 머신의 능력을 효율적으로 확장하는 새로운 컴포넌트들을 생성할 수 있다. 따라서, 이하에서 제공된 설명은 본 발명에 의해 제공된 컴포넌트들을 참조하여 이루어졌으며, "Update()" 메소드 내에서 구현될 수 있는 로직의 단순한 대표이다.

판단 블록(2210)에서, 초기 데이터 업데이트가 블록(2202)에서 수행되었는지 여부에 관해 판단된다. 일 실시예에서, 데이터 업데이트들은 트랜잭션 매니저(910)을 통해 지시된다. 데이터 업데이트를 구현하기 위한 아토믹 유닛을 포현하는 하나 이상의 이벤트 업데이트 오브젝트들 생성되고 이후에 리스닝 컴포넌트의 "Update()" 메소드(블록(2208)에서 수신함)에 대한 호출시 제공될 수 있다. 일실시예에서, 이벤트 업데이트 오브젝트가 "Update()" 메소드에 대한 호출시 수신되면, 데이터 업데이트는 최초 업데이트가 아니며, 노티파이 리스너 루틴(2200)은 블록(2214)로 진행하며, 이하에서 상세히 설명된다. 이벤트 업데이트 오브젝트가 "Update()" 메소드에 대한 호출시 수신되지 않으면, 이후 루틴(2200)은 최초 데이터 업데이트가 실행되고 있다고 판단하며, 블록(2212)로 진행한다.

블록(2212)에서, 컴포넌트의 유저 인터페이스는, 컴포넌트에 바인드된 하부 데이터의 완전한 표현을 이용하여 시각적으로 렌더링된다. 블록(2212)에 닿으면, 최초 데이터 업데이트가 수행되며, 컴포넌트 상의 모든 데이터 셋은 컴포넌트의 유저 인터페이스에 반영되어야 한다. 이에 관해 XML 포맷 데이터가 컴포넌트의 유저 인터페이스에 렌더링되게 하는 루틴은 도 23을 참조하여 이하에서 상세히 설명된다. 그러나, 어떻게 렌더링이 수행되는가는 개발자의 선택이며, 컴포넌트 API들에 의해 지시되지 않음이 이해되어야 한다. 이하에서 상세히 설명되듯이, 렌더링은 XSLT, JavaScript, HTML, VML/SVG or Adobe™ Flash를 포함하는, 그러나 여기에 한정되지는 않는 다양한 기술들에 의해 수행될 수 있다.

상술한 바와 같이, 하나 이상의 이벤트 업데이트 오브젝트들이 리스닝 컴포넌트의 "Update()" 메소드가 호출될 때 제공된다. 도 22에서 설명되듯이, 데이터 업데이트를 설명하는 아토믹 유닛을 표현하는 수신된 이벤트 업데이트 오브젝트는 블록(2212)에서 프로세싱을 위해 선택된다. 일 실시예에서, 하나 이상의 업데이트 오브젝트들에서 표현된 데이터 업데이트가 리스닝 컴포넌트의 유저 인터페이스에 반영되도록 하는 로직이 구현된다.

판단 블록(2214)에서, 선택된 이벤트 업데이트 오브젝트가 리스닝 컴포넌트에 영향을 미치는 데이터 업데이트를 표현하는지 여부가 판단된다. 상술한 바와 같이, 데이터 업데이트가 시작된 컴포넌트나 작업은, 데이터 업데이트에 의해 영향을 받는 데이터 모델내의 위치를 참조하는 XBind를 제공한다. 데이터 모델에 수행된 변경을 설명하는 이 변수는 각 리스닝 컴포넌트에 전파되는 이벤트 업데이트 오브젝트들에 포함되어 있다. 이에 관해, XBind는 리스닝 컴포넌트의 유저 인터페이스에 대한 데이터의 바인딩을 설명하는데도 이용된다. 일 실시예에서, 리스닝 컴포넌트의 데이터 바인딩을 설명하는 XBind는 데이터 업데이트를 설명하는 제공된 XBind와 비교될 수 있다. 공동 변수 포맷(예를 들어, XBind)의 사용은 리스닝 컴포넌트가 비교를 수행하고 컴토넌트의 유저 인터페이스가 데이터 업데이트에 의해 영향을 받는지 여부를 판단하도록 한다. 이 비교의 결과들이 리스닝 컴포넌트들이 데이터 업데이트에 영향을 받지 않는다고 나타내면, 노티파이 리스너 루틴(2200)은 블록(2222)로 진행하며, 이하에서 상세히 설명된다. 반대로, 리스닝 컴포넌트의 유저 인터페이스의 데이터 바인딩이 데이터 업데이트에 의해 영향을 받으면, 노티파이 리스너 루틴(2200)은 블록(2216)으로 진행한다.

일 실시예에서, 본 발명은 컴포넌트의 유저 인터페이스의 시각적 디스플레이에 대한 부분적 업데이트들을 지원한다. 블록(2216)에서, 부분적 업데이트가 리스닝 컴포넌트들에 의해 수행될 수 있는지 여부가 판단된다. 이에 관해, 로직이 부분적 업데이트들을 지원하는 "Update()" 메소드 안에서 제공되면, 노티파이 리스너 루틴(2200)은 블록(2220)으로 진행하며, 이하에서 상세히 설명된다. 반대로, 리스닝 컴포넌트가 부분적 업데이트들을 지원하지 않으면, 노티파이 리스너 루틴(2200)은 블록(2218)로 진행하며, "Update()" 메소드는 컴포넌트의 유저 인터페이스가 컴포넌트의 데이터 바인딩에 반영된 모든 데이터에 기초하여 렌더링되도록 한다. 이에 관해, XML 포맷이 컴포넌트의 유저 인터페이스 상에서 렌더링되도록 하는 루틴은 도 23을 참조하여 이하에서 설명된다.

노티파이 리스너 루틴(2200)의 블록(2220)에서, 컴포넌트의 유저 인터페이스에 대한 부분적 업데이트가 수행된다. 부분적 업데이트들이 지원되면, 컴포넌트들 데이터 바인딩에서 데이터 업데이트에 의해 영향을 받는 데이터만이 부분적 업데이트를 수행하기 위해 이용된다. 제공된 XBind를 이용하여, 블록(2220)에서, 이 데이터는 식별될 수 있으며, 컴포넌트 상에 설정될 수 있다. 컴포넌트의 "Update()" 메소드는 컴포넌트의 유저 인터페이스가 컴포넌트들 데이터 바인딩에 이제 반영된 부분적 업데이트에 기초하여 렌더링되도록 한다.

판단 블록(2222)에서, 추가 업데이트가 컴포넌트의 유저 인터페이스에 반영되어야 하는지에 대해 판단된다. 따라서, "Update()" 메소드 호출시 수신된 이벤트 오브젝트들이 이전에 선택되지 않았으면, 루틴(2200)은 블록(2212)로 진행하며, 블록들(2212-2220)은 각 이벤트 업데이트 오브젝트가 선택되고 처리될 때까지 반복된다. 이후, 데이터 업데이트에서 표현된 모든 변경들이 컴포넌트의 유저 인터페이스에 반영되면, 루틴(2200)은 종료하는 블록(2224)로 진행한다.

도 4A-B를 참조하여 상술한 바와 같이, 네트워크 오퍼레이팅 시스템은 클라이언트 컴퓨터 상에서, 독립 어플리케이션이나 머신 오퍼레이팅 시스템처럼, 웹 브라우저의 컨텍스트 내에서 구현될 수 있다. 이에 관해, 어플리케이션의 컴포넌트들과 다이얼로그들을 그래픽적으로 렌더링하고 초기화하는 프로세싱을 수행하는 렌더링 루틴(2300)은 도 23을 참조하여 설명된다. 아래 특정 웹 브라우저 기술들이 특별히 참조되지만, 본 발명은 웹 브라우저 없이도 구현될 수 있다는 것이 이해되어야 한다. 또한, 다른 실시예에서, 렌더링 루틴(2300)은 브라우저 특정 변형들(browser-specific variations)을 설명하기 위해 다르게 구현될 수도 있다. 따라서, 도 23을 참조하여 이하에서 제공된 설명은 단지 예시적이며 다양한 플랫폼들에서 다르게 수행될 수 있다.

도 23에서 설명되듯이, 렌더링 루틴(2300)은, 뷰 오브젝트가 인스턴스화되고 새로운 어플리케이션 뷰를 렌더링하도록 호출된 블록(2302)에서 시작한다. 상술한 바와 같이, 본 발명에 의해 제공된 데이터 종류 인식자는, UI XML 문서가 오픈되면, 새로운 뷰 오브젝트가 인스턴스화되도록 한다. 뷰 오브젝트는, 블록(2304)에서, 새로운 다이얼로그 오브젝트를 획득하는 요청을 생성한다. 일반적으로 설명하면, 다이얼로그는 어플리케이션의 컴포넌트들에 대한 프레임 역할을 하며, 어플리케이션의 뷰의 시각적 표현을 축소(minimizing), 확대(expanding) 및 조작(manipulating)하기 위한 제어들을 포함한다. 일 실시예에서, 다이얼로그 오브젝트들을 재활용하도록 설정된 다이얼로그 매니저가 제공되어 소모되는 메모리의 양을 감소시킨다. 따라서, 이전에 생성된 다이얼로그 오브젝트가 더 이상 이용되지는 않으나 여전히 메모리에서 유지되고 있다면, 존재하고 있는 다이얼로그 오브젝트는 새로운 어플리케이션 뷰에 재할당된다.

렌더링 루틴(2300)의 블록(2306)에서, 뷰 오브젝트는 상응하는 view.xml 문서 상에 리스너로 등록된다. 유저 인터페이스 컴포너트와 유사하게, 뷰 오브젝트는, 뷰를 설명하는 데이터 모델에 수행된 데이터 업데이트들에 대한 리스너로 등록한다. 이하에서 상세히 설명되듯이, 뷰 오브젝트가 리스너로 등록된 view.xml 문서는 웹 브라우저로부터 시작된 특정 이벤트들이 발생하면 업데이트된다. 전형적으로, 이벤트들은, 입력이 제공되거나 또는 사용자가 시스템과 상호작용할 때, 사용자에 의해 발생한다.

렌더링 루틴(2300)의 블록(2308)에서, 어플리케이션의 유저 인터페이스의 XML 기반 설명은, HTML 기반 표현으로 변형(transformed)되거나 변환된다. 상술한 바와 같이, 본 발명은 개발자들이 UI XML 랭귀지를 이용하여 어플리케이션의 뷰의 시각적 표현을 시맨틱하게 설명하도록 한다. 이에 관해, UI XML 프로그래밍 랭귀지는 개발자들이 어떠한 연산 또는 스크립팅 로직을 제공하게 하지 않는다. 대신에, 그래픽 요소들의 추상적 설명들과 그들의 관계들이 어플리케이션의 UI XML 문서에서 제공된다. 웹 브라우저가 이용될 때를 예를 들면, XSLT는 UI XML 로직을 웹 브라우저를 렌더링하기에 적합한 HTML이나 다른 마크업 포맷들로 변형하도록 정의될 수 있다. 특히, UI XML 로직이 블록(2308)에서 변형될 때, 어플리케이션의 컴포넌트들에 연관된 고유한 식별자들이, 웹 브라우저에 의해 렌더링되는 결과 HTML DOM 문서에 포함된다. 변형이 수행되면, 웹 브라우저는 어플리케이션의 뷰에 연관된 그래픽 요소들이 렌더링되도록 한다.

블록(2310)에서, 컴포넌트의 연산 로직을 포함하는 오브젝트는 인스턴스화되고, 상응한는 뷰 오브젝트에 연관된다. 일 실시예에서, 어플리케이션 유저 인터페이스 로직을 설명하는 UI XML 문서는 트래버스(traverse)된다. UI XML 문서에서 표현된 각 컴포넌트는 선택되고, 상응하는 컴포넌트 오브젝트가 인스턴스화된다. 일 실시예에서, 본 발명은 컴포넌트의 연산 로직과 그의 그래픽 표현 사이의 분리를 제공한다. 다시 말해, 컴포넌트의 시각적 표현의 UI XML 설명은 어떠한 연산 로직도 포함하지 않으며, 컴포넌트의 가동에 영향을 주시 않으면서 다양한 방법으로 및 다양한 플렛폼에 대해 변형될 수 있다. 이에 관해, 블록(2310)에서 인스턴스화된 컴포넌트 오브젝트는 컴포넌트의 연산 로직을 인코딩하며, 이는 JavaScript, SilverLight, 또는 AAdobe™ Flash와 같은 스크립팅 프로그래밍 랭귀지로 표현될 수 있다. 그러나, 개발자들은 스크립팅 랭귀지를 이용하여 컴포넌트의 바람직한 가동을 정의하지 않는다. 새로운 컴포넌트들이 필요하면, 개발자들은 컴포넌트 API들에 따른 새로운 컴포넌트들을 생성할 수 있다. 이에 관해, 각 컴포넌트 오브젝트는, 컴포넌트 API들에 따라 수신된 정보에 기초하는 메소드들을 구현한다. 이 메소드들은, 컴포넌트 상에 데이터를 설정하기 위한 "Initialize()" 메소드 및 컴포넌트의 유저 인터페이스에 대한 업데이트들으르 수행하기 위한 "Update()"를 포함한다. 어플리케이션 뷰가 클로즈될 때 컴포넌트를 제거하기 위한 "Upload()"와 같은 여기서 논의되지 않은 수 많은 메소드들이 컴포넌트들 내에서 구현될 수 있다. 그러나, 컴포넌트 API들에 의해 정의된 기본 메소드들이 존재하는한, 컴포넌트들은 어떠한 이용가능한 렌더링 기술을 이용하여 구현될 수 있다. 다시 말해, 컴포넌트들은 XSLT를 이용하여 유저 인터페이스를 HTML로 렌더링하도록 요구되어지지 않는데, 그것이 여기서 주요하게 설명되어진 실시예이더라도 그렇다. 또한, 렌더링 로직은, 전통적인 프로그래밍 로직을 이용한 컴포넌트로 설명될 수 있다.

블록(2312)에서, 블록(2310)에서 인스턴스화된 컴포넌트 오브젝트의 연산 가동이 초기화된다. 어플리케이션의 뷰의 UI XML 로직이 변형되면, 하나 이상의 컴포넌트들에 연관된 식별자들은, 웹 브라우저에 의해 렌더링되는 결과HTML DOM 문서에 포함된다. 블록(2312)에서 컴포넌트들의 가동을 초기화할 때, HTML DOM의 컴포넌트에 관련된 적합한 참조들은 view.xml 문서를 이용하여 뷰 오브젝트에 의해 식별될 수 있다. view.xml 문서를 해석함으로써, 뷰 오브젝트는 생성된 HTML DOM에 상응하는 컴포넌트 오브젝트들을 인스턴스화할 수 있고, 각 컴포넌트 오브젝트를 상응하는 유저 인터페이스에 연결시킬 수 있다. 이 방법으로, 컴포넌트의 연산 가동과 로직이 컴포넌트의 유저 인터페이스 상에서 호출된다. 컴포넌트가 각 유저인터페이스에 연관되었으면, 컴포넌트의 기본 상태들 및/또는 값들은 컴포넌트 API들을 이용하여 각 컴포넌트에 구현된 "Initialize()" 메소드에 따라 설정된다. 어플리케이션의 UI XML 문서에 표현된 모든 컴포넌트들이 초기화되면, 렌더링 루틴(2300)은 종료하는 블록(2314)로 진행한다.

일반적으로 설명하면, 렌더링 루틴(2300)에 의해 수행된 기능성은 뷰 오브젝트가 XML 기반 어플리케이션들과 웹 브라우저에 의해 이용되는 HTML DOM간 통신들을 가능하게 한다. 웹 브라우저에서의 이벤트의 발생에 대한 응답으로, 영향받은 컴포넌트와 뷰 오브젝트는 통지를 받으며, 프로세싱 후, 그 이벤트를 적합한 이벤트 리스너들(예를 들어, 프로세스 XML 문서의 트리거들 또는 이벤트 리스닝 오브젝트들)에게 전파한다. 바인딩이 정의되면, 상술한 바와 같이, 전체 또는 부분적 업데이트시 "Update()" 메소드에 상응하는 컴포넌트가 호출될 때, 웹 브라우저의 컴포넌트의 그래픽 표현은 변경될 수 있다.

특히, 컴포넌트 API들은 컴포넌트가 연산 로직의 기본 세트를 구현하도록 요구한다. 결과적으로, 컴포넌트들은 HTML 이외의 렌더링 기술들을 이용하도록 용이하게 설정될 수 있으며, 여전히 데이터 업데이트들을 인지하고 데이터에 바인드 할 수 있다. 다른 실시예들에서, 컴포넌트들은, AAdobe® Flash, Microsoft® SilverLight, Java® Applet, 또는 각 클라이언트측 컴포넌트들 연산 로직을 실행한느 XML 가상 머신의 연산 로직 냉에서 호출될 수 있는 다른 렌더링 기술을 이용해서 초기화되고 렌더링될 수 있다. 또한, 상술한 렌더링 루틴(2300)은, 본 발명을 서로 다른 종류의 컴퓨팅 장치들에서 구현할 때, 다른 방법으로 수행될 수 있다. 웹 브라우저가 이용되지 않을 때, 어플리케이션의 유저 인터페이스 로직은, 블록(2308)에서 XML과 HTML간 변형을 수행하지 않고 렌더링될 수 있다. 대신에, "Initialize()" 및/또는 "Update()" 메소드들 내에서 컴포넌트의 유저 인터페이스를 구현하고 호출하며, C, C++, Java 또는 Microsoft® SilverLight와 같은 전통적인 프로그래밍 랭귀지를 사용하여 구축되기에 적합한 그래픽 프리미티브들은 제공될 수 있다.

XIOS 통신 개요

네트워크 오퍼레이팅 시스템을 위해 작성된 XIOS 어플리케이션들은, 모델 뷰 컨트롤러(MVC) 모델을 이용한다. 이를 위해, XIOS 어플리케이션들은 데이터 모델과 주로 상호작용하며, 이는 데이터 소스의 컨텐츠들의 추상화이다. XIOS 어플리케이션과 데이터 소스 사이의 이 추상화 계층은, XIOS 어플리케이션이 데이터 소스에서 만들어진 변경들로부터 격리되도록 한다. 다시 말해, 데이터 소스에서의 변경들은 XIOS 어플리케이션에서의 변경들을 필연적으로 요구하지는 않는다.

도 24는 XIOS 어플리케이션들(2402)이 이 프레임워크 내에서 다양한 예시적인 데이터 소스들과 어떻게 상호작용하는지에 대한 일 실시예의 개요를 설명한다. MVC 용어들로, XIOS 어플리케이션들(2402)은 데이터 모델과 주로 상호작용한다. 이 아키텍쳐의 일 실시예에서, XIOS 어플리케이션들(2402)은, 각 데이터 소스의 데이터 모델을 표현하는 XML 문서들과 상호작용함으로써, 다양한 데이터 소스들에 대한 데이터 모델들과 상호작용한다. 다른 실시예에서, XIOS 어플리케이션들(2402)은, 상술한 바와 같이, 데이터 모델을 노출한 프로그래밍 오브젝트와 직접 상호작용한다. 아래 설명은 XIOS 어플리케이션들(2402)이 XML 문서들과 상호작용하는 실시예에 주로 관련되었으나, 당업자라면 MCV 패러다임의 다른 구현들로 대체될 수도 있음을 이해할 수 있다.

주어진 데이터 소스와의 통신은, 실행시 시스템 컨텍스트 오브젝트(902)(도 9)에 임베디드될 수 있는 통신 매니저(2412)에 의해 처리된다. 통신 매니저(2412)는 한 세트의 커뮤니케이터 인스턴스들을 관리하며, 각각은 커뮤니케이터 API(2410)를 구현한다. 커뮤니케이터 API(2410)는 임의의 데이터 소스에 적용가능한 제네릭 작업들을 노출한다. 예를 들어, 커뮤니케이터 API(2410)는 XIOS 어플리케이션(2402)가 데이터 소스에 연결, 데이터 소스에 저장된 데이터 수정, 데이터 소스에 새로운 데이터 생성, 데이터 소스로부터 데이터의 질의 또는 제거 등을 표현하는 문서를 로딩, 수정, 생성 또는 삭제할 수 있도록 한다.

커뮤니케이터 API(2410)는, 어떠한 데이터 소스도 단지 URL을 이용하여 접속될 수 있다는 개념을 중심으로 구축된다. 커뮤니케이터 API(2410)를 구현하는 커뮤니케이터는 URL을 통해 데이터에 접속할 수 있도록 하며, XIOS 어플리케이션(2402)이 데이터 모델로서 조작할 수 있는 XML 문서들을 반환한다. 이 간단한 방법론을 이용하여, 반환된 XML 문서를 이용하는 XIOS 어플리케이션(2402)은, 문서가 도착한 채널, 또는 그것이 생성된 하부 데이터 소스의 종류에 대한 어떠한 지식도 요구하지 않는다. 데이터를 사용하고, 조작하고, 생성하는 통일된 방법을 가지는 것은 어플리케이션 개발과 데이터 추상화 솔루션의 구현을 단순화한다. XIOS 어플리케이션들(2402)은 한 데이터 소스에서 다른 데이터 소스로 변경 및/또는 데이터 소스를 변형할 수도 있다.

통신 매니저(2412)는 주어진 커뮤니케이터를 인스턴스화하여, XIOS 어플리케이션(2402)로부터의 URL에 대한 요청에 대한 응답으로 채널을 생성한다. 채널의 이름 또는 종류는 URL 프로토콜으로 제공되며, URL의 나머지는 채널에 대한 정보를 제공한다. 채널은 이후 채널 특정 방법(channel specific manner)으로 정보를 처리한다. 예를 들어, 웹 서치 채널은 "websearch://example+search+terms"과 같은 URL을 접수한다. 프로토콜 "websearch"는 통신 매니저(2412)가 URL을 엡 서치 채널로 패스하도록 지시하며, 위치 "example+search+terms"는 웹 서치 엔진으로 전송될 서치 질의를 만들기 위해 웹 서치 채널에 의해 이용될 수 있다. 다른 채널의 예로, IMAP 폴더 스토어의 수신함에 있는 메시지는, "imap://servername/userl/inbox/messagel"와 같은 URL이 패스될 때, IMAP 채널을 통해 유사한 방법으로 접속될 수 있다.

일부 경우들에서, 간단한 URL은, 로딩 함수 또는 저장 함수와 같이, 특정 커뮤니케이터에 의해 구현된 커뮤니케이터 API(2410)의 함수로 패스된다. 다른 경우들에서, 동작 URL(action URL)은 커뮤니케이터로 패스될 수 있다. 동작 URL들은, 커뮤니케이터 API(2410)에 의해 제공된 표준 데이터 읽기/편집/쓰기/붙이기 작업들을 제외한 추가적인 기능성을 제공할 필요가 있을 때 커뮤니케이터에서 이용될 수 있다. 동작 URL은, 하부 데이터 모델, 다른 자원들, 또는 하부 데이터 모델을 다른 자원들과 함께 이용하는 커뮤니케이터 특정 함수들(communicator-specific functions)을 제공할 수 있다. 일 예는, 커뮤니케이터가 하부 데이터 모델의 복잡한 프로세싱을 수행하도록 하여, 프로그래머가 프로그램 코드에서 이 프로세싱을 하도록 하는 부담을 경감하는 동작 URL이 될 수 있다. 다른 예는 하부 데이터 모델의 외부에 있는 데이터 또는 함수들에 기초한 기능성을 제공하는 것이 될 수 있다. 동작 URL의 포맷은 커뮤니케이터 API(2410)에 패스되는 다른 URL에 유사하다. "channel_name://function(paraml, param2, . . . param n)" 여기서, "channel_name"은 동작 URL을 처리할 커뮤니케이터를 결정하며, "function"은 어떤 프로세싱이 수행될지를 판단하도록 커뮤니케이터에 의해 이용되며, "param1, param 2, . . . param n"은 함수로 패스될 파라미터들의 목록이다. 일 실시예에서, 동작 URL에 대한 요청은 XML 문서를 반환한다.

데이터 모델 문서들, 커뮤니케이터들 및 데이터 소스들의 세 예들이 도 24에 보여진다. 일 예는, Google, Yahoo!, MSN Live Search등과 같은 웹 서치 서비스(2426)과 통신하기 위헤 이용되는 데이터 모델 문서(2404)와 커뮤니케이터(2414)이다. XIOS 어플리케이션(2402)은 문서 매니저(912)로부터 웹 서치 서비스(2426)과의 통신을 추상화하는 웹 서치 모델 문서(2404)를 요청한다. 문서 매니저(912)는, XIOS 어플리케이션(2402)이 웹 서치 모델 문서(2404)와 상호작용할 때, 웹 서치 커뮤니케이터(2414)와 통신하기 위해 커뮤니케이터 API(2410)를 이용한다. 교대로, 웹 서치 커뮤니케이터(2414)는 커뮤니케이터 API(2410)를 통해 웹 서치 서비스(2426)의 기능성을 노출하는 SOAP인터페이스(2420)에 의해 이해되는 포맷으로 제출된 요청들을 번역한다. 따라서, XIOS 어플리케이션(2402)이 문서 매니저(912)로부터 "websearch://example+search+terms"와 같은 URL을 요청하면, 서치 결과들을 표현하는 웹 서치 모델 문서(2402)와 같은 XML 문서가 반환된다.

도 24에서 보여지는 다른 예는 SQL 모델 문서(2406)이다. 웹 서치 모델 문서(2404)와 마찬가지로, XIOS 어플리케이션(2402)은 SQL 모델 문서(2406)를 조작한다. 이 문서에 대한 변경은 문서 매니저(912)가 커뮤니케이터 API(2410)를 통해 SQL 커뮤니케이터(2416)를 호출하도록 한다. SQL 커뮤니케이터(2416)는 커뮤티케이터 API(2410)로부터의 호출을 SQL 웹 서비스(2422)에 의해 이해되는 포맷으로 번역한다. SQL 웹 서비스(2422)는 SQL API(2432)에 대한 전단(front end)이며, 이는 SQL 데이터베이스(2428)로의 접속을 허용한다.

도 24에서 보여지는 또 다른 예와 같이, XIOS 어플리케이션들(2402)은 IMAP 모델 문서(2408)과 같은 문서를 요청할 수 있다. XIOS 어플리케이션(2402)이 IMAP 모델 문서(2408)를 조작하면, 문서 매니저(912)는 커뮤니케이터 API(2410)를 통해 IMAP 커뮤니케이터(2418)와 통신한다. IMAP 커뮤니케이터(2418)는 커뮤니케이터 API(2410)로부터의 요청들을 IMAP 웹 서비스(2424)에 의해 이해되는 포맷으로 번역한다. IMAP 웹 서비스(2424)는 IMAP 서버(2430) 상의 표준 IMAP인터페이스(2434)에 대한 전단이다.

웹 서치 커뮤니케이터(2414), SQL 커뮤니케이터(2416) 및 IMAP 커뮤니케이터(2418)와 같은 각 커뮤니케이터 인스턴스는 클라이언트측 컴포넌트(2400)의 통신 매니저(2412)에 의해 호스팅된다. 통신 매니저(2412)는 URL들을 포함하는 문서 매니저(912)로부터의 요청들을 수신하고, 각 요청들에 대한 응답으로 채널을 형성하기 위해 필요한 커뮤니케이터들을 인스턴스화하는 것을 담당한다. 예를 들어, 통신 매니저(2412)가 imap://으로 시작하는 URL에 대한 요청을 수신하면, 통신 매니저(2412)는 IMAP 커뮤니케이터(2418)을 인스턴스화하며(현재 인스턴스화되어 있지 않으면), 요청을 IMAP 커뮤니케이터(2418)로 패스한다.

도 24에 도시되어 있듯이, 각 데이터 소스들-웹 서비스(2426), SQL 데이터베이스(2428) 및 IMAP 서버(2430)-은 SOAP 인터페이스(2420), SQL 웹 서비스(2422) 및 IMAP 웹 서비스(2424)와 같은 웹 기반 전단으르 통해 접속 가능하다. 클라이언트측 컴포넌트(2400)가 HTTP를 통해서 접속 가능한 데이터 소스들하고만 통신하면, 클라이언트측 컴포넌트(2400)는, 표준 웹 브라우저들, 프록시 서버들, 방화벽들 등에 포함된 기능성과 같은 현존하는 통신 기능성을 많이 재사용할 수 있는 혜택을 받는다. 그러나, 후단(back end)으로 HTTP 가능(HTTP-enabled) 데이터 소스를 요구하지 않는 커뮤니케이터를 생성하는 것도 가능하다. 예를 들어, 적합한 커뮤니케이터로, IMAP 웹 서비스(2424)나 SQL 웹 서비스(2422)가 제거되며, IMAP 커뮤니케이터(2418)와 SQL 커뮤니케이터(2416)가 IMAP 인터페이스(2434)나 SQL API(2432)와 각각 직접 통신할 수 있다.

XIOS 파일 시스템-서버측 컴포넌트

도 25는 XML 파일 시스템 서버측 컴포넌트(2500)의 일 실시예의 개요를 설명한다. 도 24에서와 같이, 클라이언트측 컴포넌트(2400)는, 문서 매니저(912)에 의해 XIOS 어플리케이션들(2402)에 이용 가능하게 된 XML-FS 모델 문서(2502)에 임베디드된 데이터 모델을 포함한다. 문서 매니저(912)는, XIOS 어플리케이션들(2402)이 XML-FS 모델 문서(2502)와 상호작용할 때 커뮤니케이터 API(2410)를 통해 통신 매니저(2412)에 의해 호스팅되는 XIOS 커뮤니케이터(2504)와 통신한다. XIOS 커뮤니케이터(2504)는, 교대로, 서버측 컴포넌트(2500)와 통신한다. 서버측 컴포넌트(2500)는 클라이언트 인터페이스 컴포넌트들(2506)과 데이터 스토리지 컴포넌트들(2514)를 포함한다.

클라이언트 인터페이스 컴포넌트들(2506)는 XIOS 커뮤니케이터(2504)와 통신하는 주요 컴포넌트들(primary components)이다. XML 기반 웹 서비스(2510)(웹 기반 HTTP 전단(2508)과 함께)와 트랜잭션 코디네이터(2522)는 XIOS 커뮤니케이터(2504)가 서버측 컴포넌트(2500)와 통신하는 주요 방법들이다. XML 웹 서비스(2510)는 XML 파일 시스템 내에서 파일 생성, 파일 검색, 파일 삭제, 파일 서치 등과 같은 기능성을 노출한다. 트랜잭션 코디네이터(2522)는, 이하에서 상세히 설명되듯이, 하나 이상의 클라이언트가 동일한 파일에 현재 접속할 때 데이터 스토리지(2514)에서 파일들에 대한 변경을 관리하는 것을 도우며, 캐싱 메커니즙으로 동작한다. 메시지 서버(2512), 이하에서 상세히 설명되듯이, XIOS 커뮤니케이터(2504)가 신청한 XML 파일 시스템(2500) 내의 오브젝트들의 변경들을, XIOS 커뮤니케이터(2504)를 통해, 클라이언트측 컴포넌트(2400)에 통지하는데 이용된다.

다이어그램에서 보이는 바와 같이, XIOS 커뮤니케이터(2504)와 XML 웹 서비스(2510) 사이의 통신은 양방향이다. 다시 말해, XIOS 커뮤니케이터(2504)는 XML 웹 서비스(2510)로 정보를 보내고, XML 웹 서비스(2510)로부터 정보를 받는다. 이에 반해, 메시지 서버(2512)는 XIOS 커뮤니케이터(2504)로 정보를 주로 푸쉬한다.

데이터 스토리지 컴포넌트들(2514)은 파일 서버(2516), 인덱스 서버(2518) 및 폴더 데이터베이스(2520)를 포함한다. 일 실시예에서, XML 파일 시스템은 파일 데이터를 세 가지 분리된 부분들로 저장한다. 파일 내에 포함된 원시 데이터는 파일 서버(2516) 상에 파일로 저장된다. 각 파일에 연관된 파일이름, 작성자, 수정일자, 접속 제어 목록(access control list, ACL) 및 다른 일반 파일 정보는 폴더 데이터베이스(2520) 내에 저장된다. 폴더 데이터베이스(2520)는, 각 폴더에 대한 ACL들 및 연관된 아이콘들, 폴더 렌더링 종류(예를 들어, 폴더가 그림들을 포함한다고 나타내고, 따라서 그림 썸네일로 렌더링 되어야 함) 등과 같은 추가적인 폴더 메타데이터를 포함하는, 파일들이 조직된 폴더 계층구조도 저장한다. 인덱스 서버(2518)는, 전문 서치를 이용하여 메타데이터를 서치하는 것과 같은, 파일들을 식별하고 위치시키는 추가적인 메타데이터를 저장한다.

이 컴포넌트들이 도 25에서 단일 서버 상의 분리된 컴포넌트로 도시되어 있지만, 당업자라면 하나 이상의 이 컴포넌트들은 분리된 물리적 하드웨어 상에 호스트될 수 있음을 이해할 수 있다. 다른 실시예에서, 하나 이상의 이 컴포넌트들은 복수의 컴포넌트들로 쪼개지거나, 서버측 컴포넌트((2500) 내에서 복제되거나, 그 기능성들이 단일 컴포넌트로 결합될 수도 있다. 예를 들어, XML 웹 서비스(2510), 메시지 서버(2512), 트랜잭션 코디네이터(2522), 인덱스 서버(2518), 파일 서버(2516) 및 폴더 데이터베이스(2520)는 모두 동일한 물리적 머신 상에 호스트될 수 있다. 다른 예로, 폴더 데이터베이스(2520)는, 독립 SQL 기반 데이터 스토어로서, 나머지 컴포넌트들로부터 분리될 수 있거나, 파일 서버(2516)는 특화된 고성능 파일 스토리지 시스템 상에 위치할 수도 있다. 또한, XML 파일 시스템은 오직 하나의 서버측 컴포넌트(2500)를 포함할 수도 있고, 다수를 포함할 수도 있다.

일 실시예에서, XIOS 커뮤니케이터(2504)는 항상 동일한 서버측 컴포넌트(2500)과 통신할 수 있다. 이후, 서버측 컴포넌트(2500)는, 요청을 서비스할 적합한 XML 웹 서비스(2510), 메시지 서버(2512) 등을 결정하기 위해, XIOS 커뮤니케이터(2504)에 의해 요청된 URL 내에 포함된 정보를 이용할 수 있다. XIOS 커뮤니케이터(2504)에 의해 접촉된 서버측 컴포넌트(2500)는 요청을 더 적합한 서버측 컴포넌트(2500)에 함께 전달할 수 있다. 이 방법으로, 클라이언트측 컴포넌트(2400)는, 로브 밸런싱, 리던던시, 또는 서버측 컴포넌트(2500)에 의해 구현된 스케일링 아키텍쳐로부터 격리된다.

도 26은 메시지 서버(2512)의 컨텐츠의 상세 일부의 일 실시예를 설명한다. 메시지 서버(2512)는 XML 파일 시스템을 이용하는 각 클라이언트에 대한 신청 목록(subscription list)을 포함한다. 예를 들어, 도 26은 두 클라이언트, 클라이언트 1(2606)과 클라이언트 2(2608)을 설명한다. 클라이언트 1(2606)은 클라이언트 1 신청 목록(2602)에 연관되어 있고, 클라이언트 2(2608)는 클라이언트 2 신청 목록(2604)에 연관되어 있다.

각 신청 목록은, 오브젝트가 업데이트되면 통지받기를 희망하는 클라이언트들에 대해 서버측 컴포넌트들에 의해 저장된 오브젝트들의 목록을 포함한다. 클라이언트 1 신청 목록(2602)는 클라이언트 1(2606)은, 서버측 컴포넌트들(2500)에 의해 저장된 다른 오브젝트들과 정보뿐만이 아니라, foo.doc (파일), bar.doc (역시 파일), 사용자 3의 상태에 대한 변경들, 그룹 1 폴더 목록에 대한 변경들을 통지 받기를 원한다. foo.doc 및 bar.doc에 대한 신청은, 이 파일들이 업데이트되거나, 삭제되거나, 이름이 변경되거나, 다른 클라이언트에 의해 오픈되거나 다른 방법으로 변경되면, 메시지 서버(2512)가 클라이언트 1(2606)을 업데이트하도록 한다. 사용자 3의 상태에 관한 항목(entry)은, 사용자 3이 온라인 또는 오프라인이 되거나, 사용자 3이 자기가 바쁘다고 나타내거나, 사용자 3이 아이들 상태에 들어가는 등과 같이 사용자 3의 상태가 변경될 때, 클라이언트1(2606)이 업데이트되도록 한다. 그룹 1 폴더에 관한 항목은, 그룹 1에 속한 폴더들이 업데이트되거나, 삭제되거나, 폴더들이 추가된 아이템을 가지거나, 다른 방법으로 변경되면, 클라이언트 1(2606)을 업데이트되도록 한다. 클라이언트 2 신청 목록(2604) 내 항목들은 클라이언트 1 신청 목록(2602) 내 항목들과 유사하며, 유사한 방법으로 행동하지만, 클라이언트 2(2608)가 클라이언트 1(2606)과 반대로 업데이트되도록 한다. 일 실시예에서, 통지는 롱 폴링(long polling)을 거쳐서 메시지 서버(2512)에 의해 전송되지만, 정보를 클라이언트들로 푸시하기 위한 다른 적합한 기술들이 그 대신에 사용될 수 있다.

클라이언트 1(2606)과 같은 클라이언트가 서버측 컴포넌트(2500)에 처음으로 연결하면, 클라이언트 1(2606)은, XIOS 커뮤니케이터(2504)를 통해, 오브젝트를 신청 목록에 추가하도록 요청할 수 있다. 일 실시예에서, XIOS 커뮤니케이터(2504)는 내부 신청 목록에 문서를 추가하고, 이에 응답하여, 문서 매니저(912)(또는 클라이언트측 컴포넌트(2400)의 다른 서브 컴포넌트)는 XML 웹 서비스(2510)에 요청을 발행한다. XIOS 커뮤니케이터(2504)는 XML 웹 서비스(2510)과 통신하며, 이는 메시지 서버(2512)가 오브젝트를 클라이언트 1(2606)에 대한 신청 목록에 추가하도록 지시한다. 클라이언트 1(2606)이 이전에 연결된 적이 없으므로, 메시지 서버(2512)는, 클라이언트 1 신청 목록(2602)와 같은 클라이언트 1(2606)에 대한 새로운 신청 목록을 생성한다. 이 목록은 키(2610)에 의해 식별된다. 키(2610)는 고유한 식별자를 포함하느데, 이는 바람직하게는 추측하기 어렵다. 이 키(2610)는, 클라이언트 1(2606)이 키(2620)를 인지하기 위해, XML 웹 서비스(2510)와 XIOS 커뮤니케이터(2504)를 통해 클라이언트 1(2606)으로 전송된다. 일 실시예에서, XML 웹 서비스(2510)와 메시지 서버(2512)는, 클라이언트 1(2606)으로 전송되는 키(2610)를 생성하기 위해 단순히 함께 동작한다. 이 실시예에서, 클라이언트 1(2606)(XML 웹 서비스(2510)와 반대로)은 클라이언트 1(2606)에 대한 오브젝트를 신청 목록에 추가하도록 메시지 서버(2512)를 지시한다.

상술한 바와 같이, 클라이언트 1(2606)과 같은 클라이언트는, 보안을 제공하기 위한 로그인시 XML 파일 시스템에 의해 인증된다. 일 실시예에서, 이 인증은 메시지 서버(2512)와 클라이언트 1(2606) 사이에 복사되지 않는다. 이 실시예에서 키(2610)의 추측하기 어려운(difficult-to-guess) 특성은, 이전 인증에 더하여, 클라이언트 1 신청 리스트(2602)를 엿듣는 제3자에 대한 적절한 보안을 제공한다. 메시지 서버(2512)의 클라이언트들에 대해 보안을 제공하기 위해 키(2610)를 사용하는 또 다른 이점은, 더 자원 집중적인 인증 기술과는 반대로, 메시지 서버(2512) 상에 부하를 경감시킨다는 것이다.

도 27은 메시지 서버(2512)의 작업의 일 실시예의 다른 측면을 설명한다. 이 그림에서, 메시지 서버(2512)는 세 신청 목록들(클라이언트 1 신청 목록(2602), 클라이언트 2 신청목록(2604) 및 클라이언트 3 신청 목록(2702))과 함께 도시되어 있다. XML 웹 서비스의 작업중에, 트랜잭션 코디네이터(2522)는, 모니터되고 있는 오브젝트들에 변경들이 발생하면 통지를 받는다. 트랜잭션 코디네이터(2522)는 이후 메시지 서버(2512)에 통지들이 그 오브젝트를 신청한 모든 클라이언트들에 전송되어야 한다는 것을 통지한다.

당업자라면, 메시지 서버(2512)가 XML 웹 서비스를 이용하는 각 클라이언트에 대한 신청 목록을 포함하고 있으며, 각 신청 목록은 연관된 클라이언트가 듣고 있는 각 오브젝트에 대한 항목을 포함하고 있으므로, 메시지 서버(2512) 상에 저장되어 있는 데이터의 양은 XML 웹 서비스에 연결된 클라이언트들의 수와 함께 빠르게 증가한다는 것을 이해할 수 있다. 메신저 서버(2512)에 의해 필요한 작업의 양을 줄이는 방법은 메시지 체인들(2704)을 통하는 것이다. 메시지 체인(2704)은 주어진 오브젝트를 듣고 있는 각 신청 목록을 연관시키는 연결된 목록(linked list)이다. 예를 들어, 도 27에서, 메시지 체인(2704)은, 오브젝트 bar.doc를 듣고 있는 메시지 서버(2512) 상의 각 신청 목록을 연결한다. 이 메시지 체인(2704)의 이용을 통해, 메시지 서버(2512)가 bar.doc에 변경이 있다고 통지받으면, 메시지 서버(2512)는, 처음에 클라이언트 1에 통지하고, 이후에 클라이언트 2에 통지하고, 그 후에 클라이언트 3에 통지함으로써, 메시지 체인(2704)의 연결된 목록을 먼저 트래버스하여야 한다. 이것은, 다수의 신청 목록들이 bar.doc에 대한 참조들을 포함하고 있는지를 결정해야 하는 메시지 서버(2512)에 대한 필요를 제거하므로써, 프로세싱 시간을 줄이며 메시지 서버(2512)의 효율을 증가시킨다. 하나의 메시지 체인(2704)이 도 27에 도시되어 있으나, 클라이언트에 의해 현재 모니터링되고 있는 XML 파일 시스템 내의 각 오브젝트들에 연관된 하나의 메시지 체인이 있을 수 있다는 것이 이해될 수 있다.

XIOS 파일 시스템-파일 작업들

상술한 바와 같이, XML 파일 시스템은 폴더 데이터베이스(2520) 내의 시스템에 저장된 폴더들의 계층구조를 표현하는 정보를 저장한다. XIOS 어플리케이션(2402)은, XIOS 커뮤니케이터(2504)에 의해 XML 웹 서비스(2510)으로부터 검색된 folders.xml 파일을 통해 폴더 계층구조와 상호작용할 수 있다.

도 28A-28D는 folders.xml 파일을 검색하기 위한 예시적인 메소드(2800)의 일 실시예를 도시하고 있다. 시작 블록(2802)로부터, 메소드(2800)는, XIOS 어플리케이션(2402)가 folders.xml 파일에 대한 파일 신청을 생성하고 파일 신청을 문서 매니저(912)에 제출하는 블록(2804)으로 진행한다. 일 실시예에서, 요청은 고유하게 폴더를 식별하고, 폴더 정보가 저장된 폴더 데이터베이스(2520)의 위치를 지시하기 위해 서버측 컴포넌트(2500)에 이용가능한 정보를 제공하는 폴더 식별자("folder ID")를 포함한다. folders.xml 파일은 폴더 ID에 연관된 폴더에 관련된 정보와, 또한 그 폴더 내의 서브 폴더들에 연관된 정보를 포함할 수 있다. folders.xml 파일은, 상술한 바와 같이, 각 폴더에 연관된 추가적인 메타데이터를 또한 포함할 수 있다. 일 실시예에서, XIOS 어플리케이션(2402)에 의해 제출된 요청은 URL의 형태를 취한다. 다른 실시예에서, XIOS 어플리케이션(2402)은 문서 매니저(912)로부터 folders.xml 파일을 단순하게 요청할 수 있으며, 이는 요청을 표현하는 URL을 생성한다.

일 실시예에서, 문서 매니저(912)는 folders.xml 파일의 일시 저장본을 이미 가지고 있을 수 있으며, 이 경우 문서 매니저(912)는 그 문서의 일시 저장본을 XIOS 어플리케이션(2402)에 단순히 제공한다. 그러나, 이 설명의 나머지는 요청된 문서의 일시 저장본이 문서 매니저(912) 내에 존재하지 않는다고 가정한다. 메소드(2800)는, 문서 매니저(912)가 통신 매니저(2412)로부터 XIOS 커뮤니케이터(2504)를 획득하고 파일 요청을 XIOS 커뮤니케이터(2504)의 로딩 함수에 패스하는 블록(2806)으로 진행한다. 메소드(2800)는 XIOS 커뮤니케이터(2504)가 folders.xml에 대한 폴더 ID를 포함하는 요청을 서버측 컴포넌트(2500)의 적합한 XML 웹 서비스(2510)으로 전송하는 블록(2808)로 진행한다. 다음에, 블록(2810)에서, 서버측 컴포넌트는 사용자를 인증하고, 요청을 XML 웹 서비스(2510)으로 라우팅한다. 메소드(2800)는 이후, XML 웹 서비스(2510)가 폴더 ID의 컨텐츠의 적어도 일부에 기초하여 폴더 ID에 연관된 폴더 트리를 호스팅하는 폴더 데이터베이스를 판단하는 블록(2812)로 진행한다. 메소드(2800)는 이후 연속 터미날(continuation terminal)("터미날 A1")로 진행한다.

터미날 A1(도 28B)로부터, 메소드(2800)는 XML 웹 서비스(2510)가 요청된 폴더에 연관된 정보를 검색하기 위해 적합한 폴더 데이터베이스(2520)에 질의하는 블록(2814)로 진행한다. 이 검색된 정보는 폴더 접속 제어 목록(ACL)을 포함할 수 있으며, 또한 추가적인 폴더 메타데이터 정보를 포함할 수 있다. 다음으로, 메소드(2800)는 연속 터미날("터미날 B")및 이후 XML 웹 서비스(2510)가 폴더 정보를 folders.xml파일에 추가하는 블록(2816)으로 진행한다. 일 실시예에서, folders.xml파일에 추가된 폴더 정보는 폴더 ACL을 포함하지 않는다. 대신에 folders.xml파일은 요청한 사용자가 folders.xml파일 내 모든 폴더에 적어도 읽기 접속할 수 있다는 것을 암시적으로 표시한다. 폴더들의 ACL들에 관한 더 상세한 정보는 분리된 요청을 통해 이 실시예에서 획득될 수 있다. 이 기술의 일부 이점들의 예들은 folders.xml파일의 크기와 서버측 컴포넌트(2500)에 의해 수행되는 프로세싱의 복잡성이 최소로 유지된다는 것이다.

여기서, XML 웹 서비스(2510)에 의해 해석되는 folders.xml파일은 폴더 ID에 의해 식별된 폴더만에 관련된 정보를 포함한다. 주어진 폴더에 대한 folders.xml파일에 대한 요청은 요청된 폴더의 서브 폴더들에 과한 정보를 또한 반환한다. 다수 폴더들에 대한 폴더 정보-각각은 서로 다르게 연관된 승인들(및 따라서 서로 다른 ACL들)을 가짐-는 단일 folders.xml파일로 클라이언트에게 반한되므로, 일치하는 ACL들을 가진 폴더들에 대한 정보만이 주어진 folders.xml파일에 포함되어야 한다는 것이 중요하다. 이를 위해, 메소드(2800)는, XML 웹 서비스(2510)가, 폴더 ID와 각 서브 폴더의 ACL을 포함하는 폴더 ID에 의해 식별된 폴더의 직속 서브폴더들에 연관된 정보를 추상화하기 위해 폴더 데이터베이스(2520)에 질의하는 블록(2818)로 진행한다. 이후 그 질의의 결과를 이용하여, 메소드(2800)는, 블록(282)과 시작하는 FOR 루프 및 FOR 루프의 시작을 나타내는 연속 터미날("터미날 C")로 진행한다. 터미날 C로부터, 메소드(2800)는 XML 웹 서비스(2510)이 서브 폴더의 ACL을 요청된 폴더의 ACL과 비교하는 블록(2822)으로 진행한다. 이후 메소드(2800)는 다른 연속 터미널("터미널 A2")로 진행한다.

터미널 A2(도 28C)로부터, 메소드(2800)는, 서브 폴더의 ACL이 요청된 폴더의 ACL과 일치하는지를 판단하기 위하여 테스트가 수행되는 판단 블록(2824)로 계속된다. 판단 블록(2824)에서 테스트에 대한 답이 YES이면, 메소드(2800)는 터미날 B로 되돌아가고, 블록(2816)에서 현재 서브폴더를 folders.xml 파일에 추가하며, 메소드(2800)는 현재 서브폴더의 다른 서브폴더들에서 반복된다. 달리, 판단 블록(2824)에서 테스트에 대한 답이NO이면, 메소드(2800)는, 서브폴더에 관한 다른 정보들과 반대로, XML 웹 서비스(2510)가 서브폴더를 참조하는 XLINK를 folders.xml 파일에 추가하는 블록(2826)으로 진행한다.

XLINK의 사용은, 별도의 승인 체크를 필요로 하는 정보를 클라이언트에 노출하지 않고도 서로 다른 ACL을 가진 서브폴더를 포함하는 새로운 folders.xml 파일을 요청하기에 충분한 정보를 클라이언트에 제공한다. 이는, 상술한 바와 같이, folders.xml 파일은 클라이언트가 적어도 그안에 포함된 각 폴더에 대한 적어도 읽기 접속을 할 수 있다는 암시적인 주장을 포함하고 있기 때문에 중요하다. 서브폴더가 요청된 폴더와 다른 ACL을 가지고 있다면(예를 들어, 서브폴더가 서로 다른 사용자에게 소유되어 있거나, 서브폴더가 서로 다른 그룹에서 공유되고 있는 등), 이 암시적인 주장은 그 서브폴더에 대해서는 참이 아니다. XLINK의 사용은, 이 암시적인 주장의 진실성이 여전히 유지되는 동안에 서브폴더에 대한 최소한의 정보가 클라이언트에 제공되도록 한다.

판단 블록(2828)에서 테스트에 대한 답이 YES이면, 메소드(2800)는 연속 터미날 C로 진행하며, 다음 서브 폴더가 처리된다. 달리, 판단 블록(2828)에서테스트에 대한 답이 NO이면, 메소드(2800)는 다른 연속 터미날("터미날 A3")로 진행한다.

터미날 A3로부터, 메소드(2800)는, 동일한 폴더에 대한 미래 요청들을 신속히 처리하기 위해(클라이언트 요청들 사이에는 폴더 계층구조에 변경들이(일시 저장된 folders.xml 파일이 재생성되어야 하는) 없었다고 가정함) XML 웹 서비스(2510)가 완전한 folders.xml 파일의 사본을 일시 저장하는 블록(2830)으로 진행한다. 다음으로, 블록(2832)에서, XML 웹 서비스(2510)는 완전한 folders.xml 파일을 XIOS 커뮤니케이터(2504)에 반환한다. 메소드(2800)는, XIOS 커뮤니케이터(2504)가 folders.xml 파일은 문서 매니저(912)에 제공하는 블록(2834)로 진행한다. 다음에, 블록(2836)에서, 문서 매니저(912)는 folers.xml 파일을 일시 저장하고, folders.xml 파일을 XIOS 어플리케이션(2402)에 제공한다. 메소드(2800)는 이후 종료 블록(2836)으로 진행하고 종료한다.

도 28E는 상술한 메소드(2800)의 실시예에 의해 생성된 folders.xml 파일(2840)의 일 실시예를 설명한다. 도 28E의 목적을 위해, XML 파일 시스템(2500)는 도 8A의 트리 컴포넌트(800)에 도시된 폴더 계층구조와 같은 폴더 계층구조를 저장하고, 사용자는 폴더 "RESEARCH"에 대한 folders.xml 파일을 요청했다고 가정한다. 또한 도 28E에는 한 세트의 줄 번호(2842)가 설명의 편의를 위해 포함되었다.

도 28E에서 보이는 바와 같이, 메소드(2800)는 요청에 대한 응답으로 folders.xml 파일(2840)을 생성하였다. 파일(2840)의 1-4줄은 XML 버전과 문서의 나머지 부분에 대한 스키마를 포함한다. 메소드(2800)는 요청된 폴더 "RESAERCH"에 대한 항목을 생성하였으며, 일치하는 ACL을 가진 다른 폴더들을 추가하기 위해 요청된 폴더의 서브폴더들을 열거하였다. 이 경우에, 도 8A에 도시된 폴더들 "PERSONAL", "WORK" 및 "LETTERS"와 파일(2840)의 7, 8, 12줄은 각각 일치하는 ACL들을 가졌음이 발견되었다. 메소드는 이 폴더들의 일치하는 ACL들을 가진 서브폴더들을 추가하기 위해 또한 진행하였다. 이 경우에, 폴더들 "PERSONAL" 및 "LETTERS"는 서브폴더를 가지지 않으나, 폴더 "WORK"는 9 및 10줄에서 발견된 일치하는 ACL들을 갖는 두 서브폴더 "BROWSERS" 및 "VIDEO ENCODING"를 가졌다. 각 폴더에 대해, 메소드(2800)는 제한된 메타데이터 정보를 파일(2840)에 추가하였다. 여기서 설명된 실시예에서, 메소드(2800)는 각 폴더에 대한 "이름", "id" 및 "종류"를 포함하는 메타데이터를 추가하였으나, 다른 실시예들에서는, 더 많거나 더 적은 메타데이터가 추가될 수 있다. 더욱이, "id" 요소들이 단순함을 위해 정수로 표시되었지만, 상술한 바와 같이, "id" 값들은 폴더 정보를 저장하고 있는 폴더 데이터베이스(2520)를 나타내기 위해 더 복잡한 정보를 포함할 수 있다. 다른 실시예에서, 정수값과 같은 단순한 값들은 "id" 요소들에 사용될 수 있으며, 룩업은 폴더 정보를 저장하고 있는 폴더 데이터베이스(2520)를 결정하기 위해 수행될 수 있다.

메소드(2800)는, 폴더 "RESEARCH"의 ACL과 일치하는 ACL을 가지지 않은 폴더 "EMAIL"에 대한 항목을 또한 생성하였다. "EMAIL"에 대한 항목은, 13-19줄에 도시된 것처럼, 폴더에 대한 최소한의 정보를 포함하고 있는데, 단지 "이름" 요소만을 보여준다. (폴더 "EMAIL"의 ACL에 일치하는 ACL을 가진 어떠한 서브폴더들뿐만이 아니라) 폴더 "EMAIL" 에 대한 정보를 포함하는 새로운 folders.xml 파일을 생성하기 위해 사용자에 의해 트래버스될 수 있는 XLINK를 포함한다.

일 실시예에서, folders.xml 파일은 폴더 계층구조에 관한 정보를 포함하지만, 폴더 내의 개별 파일들에 대한 정보는 포함하지 않는다. 도 29는, folders.xml 파일이 파일 목록 정보를 포함하지 않을 때 주어진 폴더에서 파일들의 목록을 검색하기 위한 메소드(2900)의 일 실시예를 설명한다. 시작 블록(2902)으로부터, 메소드(2900)는 XIOS 어플리케이션(2402)이 특정 폴더의 폴더 ID를 포함하는 파일 목록 요청을 생성하고 파일 목록 요청을 문서 매니저(912)에 제출하는 블록(2904)으로 계속한다. 상술한 바와 같이, 폴더 ID는 특정 폴더의 컨텐츠에 관한 정보를 저장하는 폴더 데이터베이스(2520)를 나타내는 정보를 포함한다. 파일 목록 요청은 희망하는 파일 종류들, 정렬 선호들(sorting preferences), 기간 필터들(date range filters) 등과 같은 추가 옵션을 더 포함할 수 있다. 다음에, 메소드(2900)는, 문서 매니저(912)가 통신 매니저(2412)로부터 XIOS 커뮤니케이터(2504)를 획득하고, 파일 목록 요청을 XIOS 커뮤니케이터(2504)로 패스하는 블록(2906)으로 계속한다. 다음에, 블록(2908)에서, XIOS 커뮤니케이터(2504)는 서버측 컴포넌트(2500)의 적합한 XML 웹 서비스(2510)로 질의를 전송한다. 메소드(2900)는 이후, 서버측 컴포넌트(2500)가 사용자를 인증하고, 그 요청을 요청된 폴더(2910)에 대한 승인들을 확인하는XML 웹 서비스(2510)로 라우팅하는 블록(2910)으로 계속한다. 요청된 폴더에 대한 승인들을 확인하기 위해, XML 웹 서비스(2510)는, 주어진 패어런트 폴더에 대한 ACL을 검색하고, ACL이 인증된 사용자에 대한 접속을 허가하는지를 판단하기 위해 폴더 데이터베이스(2520)에 질의한다.

사용자가 인증되고 승인들이 검증되면, 메소드(2900)는, XML 웹 서비스(2510)가 요청된 폴더 ID에 상응하는 인덱싱 서버(2518)를 결정하고, 질의를 인덱싱 서버(2518)로 전송하는 블록(2912)로 진행한다. 상술한 바와 같이, 폴더 ID 내에 포함된 정보는, 상응하는 인덱싱 서버(2518)를 결정하기 위해 XML 웹 서비스(2510)에 의해 이용될 수 있다. 다음에, 블록(2914)에서, 인덱싱 서버(2518)는 요청된 폴더에 대한 파일 목록을 검색하기 위해 인덱스를 질의하며, 목록의 각 파일의 ACL에 관한 결과를 처리한다. 일 실시예에서, 인덱싱 서버(2518)의 인덱스는 정보의 풀텍스트 인덱스이고, 각 파일에 대해 인덱스된 필드들은 패어런트 폴더의 폴더 ID를 포함한다. 목록내의 각 파일의 ACL에 관한 결과의 프로세싱은 인증된 사용자가 억세스 할 수 있는 파일들에 대해서만 폴더 목록에 추가되는 것을 보장한다. 일 실시예에서, 이 프로세싱은, 프로세싱 타임을 줄이기 위해 생략되며, 대신에 사용자 승인들은 사용자가 파일들 중의 하나에 접속하려고 할 때 강화된다.

다음에, 블록(2916)에서, 인덱싱 서버(2518)는 인덱스에 의해 반환된 파일들의 목록을, 인덱스로부터 검색된 제한된 파일 메타데이터와 함께, 적합한 포맷(예를 들어, ATOM, RSS 또는 다른 적합한 포맷)의 피드로서, 포맷을 만들며, 클라이언트측 컴포넌트(2400)로 이를 반환한다. 제한된 파일 메타데이터는 최종 수정일자, 작성자, 파일 종류 등과 같은 항목들을 포함할 수 있다. 메소드(2900)는 이후 종료 블록(2918)으로 계속하고 종료한다.

데이터는 XML 파일 시스템에서 협업적으로 저장되고 다수 클라이언트들이 주어진 패어런트 폴더를 업데이트하거나 동일한 파일을 생성할 수 있으므로, 어떤 실시예들에서 XML 파일 시스템에 파일의 단순한 생성은 파일 생성 클라이언트와 서버측 컴포넌트(2500)의 측면들 사이에 관리(coordination)를 포함할 수 있다. 도 30A-30C는 XML 파일 시스템 내에서 파일을 생성하는 메소드(300)의 실시예를 설명한다. 시작 블록(3002)으로부터, 메소드(3000)는, XIOS 어플리케이션(2402)이 파일 이름과 새로운 파일에 대한 목적 폴더를 특정하고, 원시 파일 데이터 컨텐츠를 초기화하는 블록(3004)으로 진행한다. 원시 파일 데이터 컨텐츠의 초기화는 새로운, 빈 파일을 생성하거나, 존재하는 컨텐츠를 원시 파일 데이터에 삽입(사용자가 이미 생성하기 시작한 컨텐츠를 처음에 저장하는 경우)할 수 있다. 다음에, 블록(3006)에서, XIOS 어플리케이션(2402)은 파일 생성 요청을 문서 매니저(912)로 제출하며, 파일 생성 요청은 파일 이름, 목적 폴더 ID, 및 원시 파일 데이터 컨텐츠를 포함한다. 일 실시예에서, 이 요청의 적어도 일부는 URL로 포맷이 만들어진다. 메소드(3000)는 이후, 문서 매니저(912)가 통신 매니저(2412)로부터 XIOS 커뮤니케이터(2504)를 획득하고 파일 생성 요청을 XIOS 커뮤니케이터(2504)로 패스하는 블록(3008)으로 진행한다. 다음에, 블록(3010)에서, XIOS 커뮤니케이터(2504)는 새로운 파일을 생성하는 요청을 서버측 컴포넌트(2500)의 XML 웹 서비스(2510)으로 전송한다. 메소드(3000)는 이후, 서버측 컴포넌트(2500)가 사용자를 인증하고, 그 요청을 XML 웹 서비스(2510)로 라우팅하는 블록(3012)으로 진행한다.

다음에, 메소드(3000)는 이후, XML 웹 서비스(2510)가 목적 폴더를 호스팅하는 폴더 데이터베이스를 결정하고, 사용자가 목적 폴더에서 파일을 생성하는 승인을 가지고 있는지를 판단하는 블록(3014)로 진행한다. 상술한 바와 같이, 목적 폴더의 폴더 ID는, XML 웹 서비스(2510)가 목적 폴더에 연관된 정보를 포함하는 폴더 데이터베이스를 결정하도록 하는 정보를 포함한다. 상술한 바와 같이, XML 웹 서비스(2510)는, 목적 폴더에 대한 ACL을 검색하기 위해 폴더 데이터베이스(2520)에 질의하고, ACL이 인증된 사용자에게 적합한 권한들을 부여했는지를 판단함으로써, 사용자가 파일을 생성하는 승인을 가지고 있음을 보장할 수 있다. 메소드(3000)는 이후, 연속 터미날("터미날 A1")로 진행한다.

터미날 A1으로부터, 메소드(3000)는, XML 웹 서비스(2510)가 특정된 목적 폴더가 특별한 폴더인지를 확인하는 블록(3016)으로 진행한다. 일 실시예에서, XML 파일 시스템에는, 스토리지 폴더와 특별 폴더라는 두 종류의 폴더들이 있다. 스토리지 폴더는, 주로 파일들과 다른 폴더들을 저장한다는 점에서, 일반 파일 시스템에 있는 폴더와 매우 동일하다. 특별 폴더는, 이에 반해, 통신의 다른 형태를 추상화하기 위해 XML 파일 시스템에 의해 이용된다. 이는 XIOS 어플리케이션(2402)이 스토리지 내의 파일과 상호작용하는 것과 동일한 방법으로 이 통신의 다른 형태와 상호작용하도록 하므로, 어플리케이션 개발을 단순화한다. 예를 들어, 특별 폴더는 이메일 특별 폴더로 지정될 수 있으며, 이메일 특별 폴더내에서의 새로운 파일 생성은 이메일이 전송되도록 한다. 일 실시예에서, 각 사용자에게는 도착 특별 폴더 또는 "수신함"과 발송 특별 폴더 또는 "발송함"이라는 두 개의 특별 폴더들이 있다. 다른 실시예들에서, 더 많거나 적은 특별 폴더들이 존재한다.

메소드(3000)는 특정된 목적 폴더가 특별 폴더인지를 판단하는 테스트가 수행되는 판단 블록(3018)으로 계속한다. 판단 블록(3018)에서 테스트에 대한 답이 YES이면, 메소드(3000)는 그 요청이 이후 프로세싱을 위해 특별 폴더에 연관된 서버 프로세스로 전송되는 블록(3019)로 진행한다. 그 프로세싱의 실시예의 예는 도 36과 첨부된 텍스트에 설명된 메소드(3600)에 관해 이하에서 설명된다. 메소드는 연속 터미날("터미날 B")로 진행한다.

도 30B가 메소드(3600)와 같은 메소드는 특별 폴더에서 새로운 파일이 생성되기 전에 발생한다고 설명하지만, 이는 반드시 그 경우일 필요는 없다. 일 실시예에서, 판단 블록93018)에서 수행된 테스트는 터미날 B(도 30C)와 같이, 파일이 생성된 이후에 수행될 수도 있다. 그러한 실시예에서, 특별 폴더를 모니터하는 서버 프로세스는, 특별 폴더에서 생성된 파일 상에서 작업하는데, 클라이언트로부터의 요청에 바로 작업하는 것에 반대된다. 서버 프로세스는 특별 폴더의 컨텐츠를 폴링함으로써 파일의 생성을 통지 받는다. 다른 실시예에서, 서버 프로세스는 메시지 서버 상에서 프로세스에 연관된 신청 목록을 생성하거나 특별 폴더를 신청 목록에 추가함으로써 파일의 생성을 통지 받으며, 그로 인해 예를 들어, 메소드(3000)의 블록(3030)에서, 파일의 생성에 대하여 메시지 서버로부터 통지를 수신한다.

판단 블록(3018)에서 테스트의 답이 NO이면, 메소드(3000)는, 파일 서버(2516)가 새로운 파일의 원시 파일 데이터를 위한 공간을 파일 서버에 연관된 스토리지 장소에 할당하고, 그 스토리지 위치에 초기 원시 파일 데이터를 저장하는 블록(3020)으로 진행한다. 다음에, 블록(3022)에서, 폴더 데이터베이스(2520)는 폴더 데이터베이스에 새로운 파일에 대한 항목을 생성하며, 그 항목은 파일에 연관된 제한된 메타데이터를 포함하며, 파일 이름, 생성일자, 고유 파일 ID, 스토리지 위치 등을 포함한다. 일 실시예에서, 파일은 단일 파일 ID에 연관된 하나 이상의 파일 스트림을 가질 수 있다. 그 경우에, 파일 서버(2516)는 각 스트림에 대하여 스토리지 위치에 분리된 공간을 할당하며, 폴더 데이터베이스(2520)에 저장된 메타데이터는 파일 ID를 모든 스토리지 위치들과 연관시킨다. XML 파일 시스템은 파일에 연관된 모든 스트림들을 이용가능한 파일의 메타데이터를 통해 클라이언트에 노출한다.

메소드(3000)는 이후, 폴더 데이터베이스(2520)가 새로운 파일을 특정된 목적 폴더에 연관시티는 블록(3024)로 진행한다. 패어런트 폴더와 새로운 파일 사이에 생성된 연관은, 폴더 내에 저장된 파일들을 검색할 때, XML 웹 서비스(2510)가 폴더 데이터베이스(2520)와 인덱스 서버(2518)에 폴더 ID를 이용하여 질의할 수 있도록 한다. 메소드(3000)는 이후 다른 연속 터미날("터미날 A2")로 진행한다.

터미날 A2로부터(도 30C), 메소드(3000)는 XML 웹 서비스(2510)가 새로운 파일에 대한 메타데이터를 인덱스 서버(2518)로 전송하는 블록(3026)으로 계속한다. 이 메타데이터는 폴더 데이터베이스에 의해 저장된 동일한 메타데이터일 수 있으며, 이는 메타데이터의 빠른 풀텍스트를 검색을 가능하게 하기 위해 인덱스 서버(2518)로 카피된다. 인덱스 서버(2518)로 전송된 메타데이터는, 풀텍스트 인덱싱이 유익하도록 하는 폴더 데이터베이스에 저장된 이상의 정보, 예를 들어, 사용자 또는 어플리케이션 특정 속성들, 작성자 정보, 사용자 코메트들 등을 추가적으로 포함할 수 있다. 인덱스 서버(2518)로 전송된 메타데이터는 그 파일에 연관된 하나 이상의 파일 스트림들로부터 직접 추상화된 정보를 또한 포함할 수 있다.

다음에, 블록(3028)에서, XML 웹 서비스(2510)는, 새로운 파일이 특정된 목적 폴더에서 생성되었다는 통지를 메시지 서버(2512)로 전송한다. 다른 실시예에서, 이 통지는, 패어런트 폴더에 대한 새로운 파일의 연관을 검출하면 폴더 데이터베이스(2520) 또는 인덱스 서버(2518)에 의해 전송될 수도 있다. 메소드(3000)는 이후, 메시지 서버(2512)가 신청 목록에 특정된 목적 폴더를 갖는 각 클라이언트에게 업데이트 통지를 전송하는 블록(3030)으로 진행한다. 다음에, 블록(3032)에서, 클라이언트는, 새로운 파일을 클라이언트의 신청 리스트에 추가하라는 요청을 XML 웹 서비스(2510)를 통해 메시지 서버로 전송하며, 그 요청은 파일 ID를 포함한다. 다음에, 블록(3034)에서, 메시지 서버(2512)는 클라이언트의 신청 리스트에 새로운 파일을 추가한다. 이후, 메소드는 터미날 B로 진행하며, 이후 메소드(3000)이 종료하는 종료 블록(3036)으로 진행한다.

도 31A-31E는, XML 파일 시스템 내에서 현존하는 파일들을 오픈하기 위한 메소드(3100)의 일 실시예를 설명한다. 시작 블록(3102)으로부터, 메소드(3100)는, 연속 터미날("터미날 B")와 출구 터미날("터미날 C") 사이에 정의된 한 세트의 메소드 단계들(3104)로 계속한다. 메소드 단계들(3104)의 세트는 공유되지 않고 있는 현존하는 파일(다시 말해, 다른 클라이언트에 의해 현재 오픈되지 않은 파일)을 오픈하는 메소드를 설명한다. 터미날 B(도 31B)로부터, 메소드(3100)는 제1 클라이언트 상의 XIOS 어플리케이션(2402)이 문서 매니저(912)로부터 파일을 요청하는 블록(3110)으로 진행하며, 그 요청은 파일 ID를 포함한다. 일 실시예에서, 요청은 URL의 형태이다. 요청은 새롭게 생성된 URL에 합체된 파일 ID를 포함할 수 있거나, 제1 클라이언트는 파일 목록 안에 포함된 파일 URL과 같이, 파일에 접근할 수 있는 URL을 이미 가지고 있을 수 있다. 일 실시예에서, URL은 파일 ID 자체를 포함하지 않을 수 있으나, 대신에 파일 ID가 유도될 수 있는 정보는 포함한다.

다음에, 블록(3112)에서, 문서 매니저(912)는 통신 매니저(2412)로부터 XIOS 커뮤니케이터(2504)를 획득하며, 파일 요청을 XIOS 커뮤니케이터(2504)로 패스한다. 메소드(3100)는 이후, XIOS 커뮤니케이터(2504)가 파일에 대한 요청을 서버측 컴포넌트(2506)의 적합한 XML 웹 서비스(2510)로 전송하는 블록(3114)로 진행하며, 요청은 파일 ID를 포함한다. 상술한 바와 같이, 요청은 파일 ID를 포함하는URL 형태일 수 있거나, 대신에 파일 ID가 유도될 수 있는 정보를 포함할 수 있다. 다음에, 블록(3116)에서, 서버측 컴포넌트(2506)는 사용자를 인증하고, 요청을 XML 웹 서비스(2510)로 라우팅한다.

일 실시예에서, 요청 내에 포함된 파일 ID 또는 파일 URL은, XML 웹 서비스(2510)가 파일을 획득하기 위해 적합한 폴더 데이터베이스(2520), 파일 서버(2516) 또는 트랜잭션 코디네이터(2522)를 결정하는 것을 돕기 위해, 파일이 존재하는 파일 서버(2516)를 나타내는 정보를 또한 포함할 수 있다. 다른 실시예에서, 요청은 패어런트 폴더의 폴더 ID를 또한 포함할 수 있으며, XML 웹 서비스(2510)는 폴더 ID 내에 포함된 정보에 기초하여 파일을 획득하기 위해 적합한 데이터 스토리지 서버들을 결정할 수 있다. 단일 파일 요청에 대해 반드시 접촉되어야 하는 서로 다른 서버들의 수와, 따라서 파일 ID 또는 파일 URL에서 제공하는 정보의 양은 데이터베이스가 어떻게 분할되어 있는지에 의존하며, 스케일러빌러티의 양은 특정 실시예에 의해 제공된다.

다음에, 블록(3117)에서, XML 웹 서비스(2510)는 제1 클라이언트의 사용자가 파일을 오픈하는 승인을 가지고 있는지를 확인하며 파일에 대한 요청을 적합한 트랜잭션 코디네이터(2522)에 제출한다. 일 실시예에서, XML 웹 서비스(2510)는 적합한 폴더 데이터베이스(2520로부터 파일에 대한 ACL을 검색하고, ACL이 인증된 사용자가 파일에 접속할 수 있도록 하는지를 확인함으로써 클라이언트 승인들을 확인한다. 다음에, 블록(3118)에서, 트랜잭션 코디네이터(2522)는 메시지 서버(2512)가 요청된 파일을 제1 클라이언트의 신청 목록에 추가하도록 지시한다. 메소드(3100)는 이후 트랜잭션 코디네이터(2522)가 파일이 현재 공유되고 있는지를 판단하는 블록(3119)로 진행한다. 메소드(3100)는 이후 연속 터미날("터미날 B1")로 진행한다.

터미날 B1(도 31C)로부터, 메소드(3100)는 파일이 현재 공유되고 있는지를 판단하는 테스트가 수행되는 판단 블록(3120)으로 진행한다. 판단 블록(3120)에서 테스트에 대한 답이 YES이면, 메소드는 연속 터미널("터미날 D1")로 진행한다. 이와 달리, 판단 블록(3120)에서 테스트에 대한 답이 NO이면, 메소드(3100)는 트랜잭션 코디네이터(2522)가 원시 파일 데이터를 저장하는 파일 서버(2516)을 결정하기 위해 적합한 폴더 데이터베이스(2520)에 질의하는 블록(3122)로 진행한다. 다음에, 블록(3124)에서, 트랜잭션 코디네이터(2522)는 적합한 파일 서버(2516)로부터 원시 파일 데이터를 검색한다. 이후, 블록(3126)에서, 트랜잭션 코디네이터(2522)는 원시 파일 데이터를 FALSE로 설정된 공유 플래그와 함께 XML 웹 서비스(2510)으로 반환한다. 다음에, 블록(3128)에서, XML 웹 서비스(2510)는 원시 파일 데이터를 FALSE로 설정된 공유 플래그와 함께 제1 클라이언트의 XIOS 커뮤니케이터(2504)로 반환한다. 메소드(3100)는 이후, XIOS 커뮤니케이터(2504)가 원시 파일 데이터에 대한 접속을 문서 매니저(912)로 제공하는 블록(3129)로 진행하며, XIOS 커뮤니케이터는 차례로 원시 파일 데이터에 대한 접속을 XIOS 어플리케이션(2402)로 제공한다. 메소드(3100)는 이후 다른 연속 터미날("터미날 C")로 진행한다.

터미날 C(도 31A)로부터, 메소드(3100)는 터미날 D와 터미날 E사이에 정의된 한 세트의 메소드 단계들(3106)로 진행하며, 이는 다른 클라이언트에 의해 공유되고 있는 현존하는 파일을 오픈하는 방법을 설명한다. 이 설명의 목적을 위해, 이 메소드 단계들(3106)의 세트는 메소드 단계들(3104)의 세트가 제1 클라이언트에 의해 이미 실행되었고, 따라서 요청된 파일이 제1 클라이언트에 의해 이미 오픈되었다고 가정한다.

터미날 D(도 31D)로부터, 메소드(3100)는 제2 클라이언트 상의 XIOS 어플리케이션(2402)이 문서 매니저(912)를 통해 서버측 컴포넌트(2514)로 파일 요청을 전송하는 블록(3130)으로 진행하며, 파일 요청은 파일 ID를 포함한다. 상술한 바와 같이, 요청은 파일 ID를 포함하는URL 형태일 수 있거나, 파일 ID가 유도될 수 있는 정보를 포함하는 URL 형태일 수 있다. 블록(3130)에서 동작들을 포함하는 개별 동작들은 이하에서 상세히 설명되므로, 이들에 대한 상세한 설명은 간결하게 하기 위해 여기서 생략된다. 다음에, 블록(3132)에서, 서버측 컴포넌트(2514)는 제2 클라이언트의 사용자를 인증하고, 요청을 XML 웹 서비스(2510)로 라우팅한다. 메소드(3100)는 이후, XML 웹 서비스(2510)가 제2 클라이언트의 사용자가 파일을 오픈하는 승인을 가지고 있는지를 확인하고, 파일에 대한 요청을 적합한 트랜잭션 코디네이터(2522)로 제출하는 블록(3134)로 진행한다. 메소드(3100)는 이후 트랜잭션 코디네이터(2522)가 제2 클라이언트의 신청 리스트에 파일을 추가하도록 메시지 서버(2512)에 지시하는 블록(3136)으로 진행한다. 당업자라면, 여기까지, 블록들(3110-3116) 사이에 정의된 메소드와 상응하는 블록들(3130~3136) 사이의 유사점들을, 즉, 공유된 파일을 오픈하는 것과 공유되지 않은 파일을 오픈하기 위한 방법 사이에는 거의 차이가 없다는 것을 인식할 수 있다.

다음에, 블록(3138)에서, 트랜잭션 코디네이터(2522)는 요청된 파일이 현재 공유되고 있는지를 판단한다. 여기서, 공유되는 파일을 오픈하는 메소드는 공유되지 않는 파일을 오픈하는 메소드와 달라진다. 메소드(3100)는 터미날 D1으로 진행하고, 이후 원시 파일 데이터를 저장하는 파일 서버(2516)를 판단하기 위해 트랜잭션 코디네이터(2522)가 폴더 데이터베이스(2520)에 질의하는 블록(3140)으로 진행한다. 다음에, 블록(3142)에서, 트랜잭션 코디네이터(2522)는 적합한 파일 서버(2516)로부터 원시 파일 데이터를 검색하고 그 사본을 일시 저장한다. 다음에, 블록93144)에서, 트랜잭션 코디네이터(2522)는 파일이 공유되고 있는 제1 클라이언트에 통지하라고 메시지 서버(2512)에 지시한다. 메소드(3100)는 이후 다른 연속 터미날("터미날 D2")로 진행한다.

터미날 D2(도 31E)로부터, 메소드(3100)는 트랜잭션 코디네이터(2522)가 TRUE로 설정된 공유 플래그와 함께 원시 파일 데이터를 XML 웹 서비스(2510)로 전송하는 블록(3146)으로 진행한다. 이는 XML 웹 서비스(2510)와 XIOS 커뮤니케이터에게 원시 파일 데이터를 파일이 공유되지 않았을 때와는 다르게 취급하라고 통지한다. 다음에, 블록(3148)에서, XML 웹 서비스(2510)는 TRUE로 설정된 공유 플래그와 함께 원시 파일 데이터를 제2 클라이언트에 반환한다. 메소드(3100)는 이후, 메시지 서버(2512)가 파일이 현재 공유되고 있는 적어도 제1 클라이언트에 통지하는 블록(3150)으로 진행한다. 메소드(3100)는 이후, 파일이 현재 공유되고 있다는 통지의 수신에 대한 응답으로, 제1 클라이언트가 어떠한 이전에 기록되지 않는 트랜잭션들을 XML 웹 서비스(2510)로 전송하는 블록(3152)로 진행한다.

이하에서 설명하듯이, 제1 클라이언트 상의 파일 데이터 모델에 변경이 이루어지면, 제1 클라이언트의 트랜잭션 매니저(910)는 이 변경들을 저장을 위해 XML 웹 서비스(2510)로 즉시 전송하지 않은채 이 변경들을 모을 수 있다. 제1 클라이언트가 오프라인 코드에서 작업하는 경우 이는 특히 그렇게 할 수 있으나, 높은 네트워크 레이턴시, 높은 프로세서 부하 등에 의해서도 발생할 수 있다. 제1 클라이언트가 파일이 현재 공유되고 있다는 통지를 수신하면, 트랜잭션 매니저(910)는 기록되지 않는 트랜잭션들을 취하고, 이들을 XML 웹 서비스(2510)로 전송한다.

메소드(3100)의 블록(3154)에서, XML 웹 서비스(2510)는, 이 트랜잭션들을 수신한 후, 기록되지 않는 트랜잭션들을 트랜잭션 코디네이터(2522)로 전송하며, 이는 트랜잭션 코디네이터(2522)에 의해 저장된 원시 파일 데이터의 일시 저장 버전에 저장되지 않은 트랜잭션들을 기록한다. 이 트랜잭션들은 파일 서버(2516) 상의 원시 파일 데이터에 결국 기록된다. 일 실시예에서, 트랜잭션들은 파일을 수용하고 있는 클라이언트가 저장 명령을 실행하면 기록된다. 또 다른 실시예에서, 변경들은 문서의 모든 클라이언트 사용자들이 연결을 끊으면 기록된다. 다음에, 블록(3156)에서, 트랜잭션 코디네이터(2522)는 모든 리스닝 클라이언트들에게 기록된 변경들을 통지하라고 메시지 서버(2512)에 지시한다. 메소드(3100)는 이후, 제1 클라이언트와 제2 클라이언트가 메시지 서버로부터 기록된 변경의 통지를 수신하는 블록(3158)로 진행한다. 다음에, 메소드(3100)는 터미날 E로 진행하고 종료한다.

네트워크 오퍼레이팅 시스템 클라이언트 컴포넌트 시동(startup)

도 32A는 네트워크 오퍼레이팅 시스템의 클라이언트측 컴포너트(2400)를 시작하는 메소드(3200)의 일 실시예를 설명한다. 시작 블록(3202)로부터, 메소드(3200)는 클라이언트측 컴포넌트(2400)의 부트 로더(boot loader)가 시스템 컨텍스트 오브젝트(902)를 이에 연관된 매니저들과 함께 인스턴스화하고 XML 파일 시스템(2500)에 대한 통신 채널을 시작하는 블록(3204)로 진행한다. 일부 실시예들에서, XML 가상 머신이 클라이언트측 컴포넌트(2400)에 이미 포함되어 있으므로, 부트 로더의 이용은 요구되지 않는다. 예를 들어, 이는 클라이언트측 컴포넌트(2400)가 이동 장치 이내, 셋톱 박스나 씬 클라이언트 컴포넌트 상에서와 같이 독립 어플리케이션으로 웹 브라우저 외부에서 구현되는 실시예들에서의 경우가 될 수 있다. 이는 실행을 위해 호스트 오퍼레이팅 시스템을 요구하지 않는 머신 오퍼렝팅 시스템으로 구현된 실시예들에 대한 경우가 또한 될 수 있다. 네트워크 오퍼레이팅 시스템은, 인터넷을 통한 HTTP 프로토콜의 이용을 포함한, 그러나 여기에 한정되지는 않는 네트워크 연결을 통해, 시작 프로세스를 정의한 파일들을 검색함으로써 동작한다. 메소드(3200)에서 설명된 시동 프로세스가 없어도, 네트워크 오퍼레이팅 시스템은 동작할 수 있으나 초기 설정은 설정 단계들을 수동으로 실행하는 사용자에 의해 구동될 수 있다.

전통적인 오퍼레이팅 시스템들과 달리, 클라이언트측 컴포넌트의 일부 실시예들은 예를 들어, 현존하는 웹 브라우저와 같은 다른 프로그램 내에 호스팅될 수 있다. 그 실시예들에 대해, 어떤 특정 XML 파일 시스템(들)(2500)에 연결하거나 통신 채널이 시작하는지를 포함하는 시동 시퀀스에 관련된 특별한 설정들은, 호스트 프로그램, HTTP, 질의 파라미터들, HTTP 쿠키들, 또는 클라이언트에 연관된 다른 설정 파라미터들(IP, 위치, 머신, 브라우저 ID 등)을 이용하여 찾아가야하는 위치 URL에 의해 결정될 수 있다. 예를 들어, 웹 브라우저를 http://os1.icloud.com으로 지시하는 것은 클라이언트측 컴포넌트(2400)가 제1 XML 파일 시스템(2500)에 연결하도록 할 수 있으며, 웹 브라우저를 http://os2.icloud.com으로 지시하는 것은 클라이언트측 컴포넌트(2400)가 제1 XML 파일 시스템(2500)으로부터 다른 위치에서 호스팅되고 있는 제2 XML 파일 시스템(2500)에 연결하도록 할 수 있다.

일 실시예에서, 클라이언트측 컴포넌트(2400는, 시동 시퀀스 중에, XML 파일 시스템(2500)이 아닌(또는 이에 더하여) 데이터 소스에 대한 통신 채널을 시작할 수 있으며, 원격 데이터 소스에 연결하거나 로컬 데이터 소브에 연결한다. 예를 들어, 한 파일 시스템은 서비스 제공자 데이터 센터를 통해 제공된 전역 XIOS 파일 시스템일 수 있다. 시동 시퀀스 동안에 연결된 다른 파일 시스템은 기업 네트워크 상에 로컬하게 설치될 수 있다. 시동 시퀀스 동안에 연결된 세 번째 파일 시스템은 사용자의 로컬 하드 드라이브에 대한 접속을 줄 수 있다. 도 32B는 드라이브들로 시동하는 동안 클라이언트측 컴포넌트(2400)에 바인드된 데이터 소스들의 몇 가지 예들을 설명한다. 예를 들어, 로컬 머신의 드라이브는 "Local Drive"로 바인드되어 있다. 또한, XML 파일 시스템(2500) 상의 폴더는 "Shared Family Folder"로 바인드되어 있다. 또 다른 실시예로, 그룹에 대한 루트 폴더는 "Class of 1992 Reunion"으로 바인드되어 있다. 중요하게, 이 데이터 소스들 각각이 서로 다른 장소에 저장되고 서로 다른 기술을들 통해 접속되는 반면, 차이들은 각 데이터 소소들을 단순하게 접속 가능한 드라이브로 보는 XIOS 어플리케이션들(2402)로부터 감춰진다. 이 예들은 완전하지는 않지만, 그들은 시동 시퀀스가 하나 이상의 파일 시스템에 연결할 수 있다는 것을 보이도록 의도된다. 사용자가 인증되면, 시동 시퀀스는 추가적인 파일 시스템들에 대한 연결과 추가적인 채널들의 초기화를 포함하는 사용자 특정 시동 시퀀스로 연속될 수 있다.

다른 프로그램 내에 호스팅된 네트워크 오퍼레이팅 시스템의 실시예들과 전통적인 오퍼레이팅 시스템 사이의 다른 차이는 호스트 프로그램에 관해 수행되는 작업들이 클라이언트측 컴포넌트(2400)의 실행을 인터럽트할 수 있다는 것이다. 예를 들어, 사용자가 시동 시퀀스를 성공적으로 마치고 네트워크 오퍼레이팅 시스템에 로그인 한 후에, 호스트 프로그램은 클라이언트측 컴포넌트(2400)를 재로딩하는 작업을 수행할 수 있다. 일 실시예에서, 클라이언트측 컴포넌트(2400)는, 상태를 복구하기 위해, 재로딩 이전의 네트워크 오퍼레이팅 시스템의 로그인 상태가 재로딩 이후의 클라이언트측 컴포넌트(2400)에 이용가능하게 함으로서, 이 상황을 처리한다. 이를 위해, 블록(3206)에서, 클라이언트측 컴포넌트(2400)는 사용자가 이미 로그인되었는지를 확인한다. 메소드(3200)는 사용자가 이미 로그인되었는지를 판단하기 위한 테스트가 수행되는 판단 블록(3208)로 진행한다. 판단 블록(3208)에서 테스트에 대한 답이 YES이면, 메소드(3200)는 연속 터미날("터미날 A")로 진행하므로, 시동 메소드의 로그인 부분을 생략한다.

판단 블록(3208)에서 테스트에 대한 답이 NO이면, 메소드(3200)는 클라이언트측 컴포넌트(2400)가 통신 채널에 연관된 로그인 어플리케이션을 오픈하는 블록(3210)으로 진행한다. 시작될 특정 로그인 어플리케이션은 통신 채널에 의해 결정될 수 있지만, 전형적으로, 로그인 어플리케이션은, 사용자 이름과 패스워드와 같은 사용자 정보를 사용자에게 안전하게 요청한다. 로그인 절차의 다른 실시예들은, 로그인 정보가 부트 로딩이 시작하기 전에 요청되고, 더 이상의 사용자 상호작용 없이 그 로그인 정보가 인증을 위한 통신 채널로 직접 패스되는 곳에 존재한다. 부트 로더가 없는 실시예들에서, 클라이언트측 컴포넌트(2400)는 로그인 정보를 인증을 위한 통신 채널로 직접 패스할 수 있다. 변형들(variations)들이 부트 로더가, 직접 로딩된 후, 스스로 로그인 정보를 요청하고, 이후에 별도의 로그인 어플리케이션을 사용하지 않고 통신 채널로 정보를 패스하는 경우 발생할 수도 있다. 다음에, 블록(3212)에서, 통신 채널을 사용자 정보들을 처리한다. 통신 채널은 인증 서비스로 이들을 전송하거나, 이들을 로컬에서 처리함으로써 사용자 정보들을 처리할 수 있다.

메소드(3200)는 이후 터미날 A로 진행한다. 터미날 A로부터, 메소드(3200)는, 통신 채널이 사용자의 setting.xml 파일을 클라이언트측 컴포넌트(2400)에 제공하는 블록(3214)로 진행하며, 클라이언트측 컴포넌트는 사용자 특정 시동 시퀀스를 수행하고 모든 특정 가상 드라이브들을 탑재하기 위해 setting.xml 파일을 이용한다. 통신 채널은 setting.xml 파일을 원격 데이터 서버로부터 획득하거나, setting.xml 파일을 로컬 데이터 소스에서 획득하거나 또는 통신 채널 특정 기본값들에 기초하여 기본 setting.xml 파일을 생성할 수 있다. setting.xml 파일은 네트워크 오퍼레이팅 시스템의 설정을 위한 사용자 특정 설정들의 모음을 포함한다. 이 설정들은 사용자 이름, 이메일 주소, 다양한 어플리케이션의 설정들, 시동시 탐재될 가상 드라이브들의 모음(통신 채널들) 및 연관된 루트 폴더 ID(그룹들을 포함. 이하에서 설명됨), 친구 목록, 및 시동 시퀀스를 포함하지만, 이에 한정되지는 않는다. setting.xml 파일에 포함된 시동 시퀀스는 성공적인 로그인 후, 어느 데스크탑 매니저, 콘솔, 또는 오픈하는 시작 어플리케이션 등을 포함하는, 무슨 프로그램들을 클라이언트측 컴포넌트(2400)가 시작해야 하는지를 특정한다. 다음에, 메소드는 종료 블록(3216)으로 진행하며, 종료한다.

일부 실시예들에서, setting.xml 파일은 네트워크 오퍼레이팅 시스템에서 다양한 항목들을 표현하는 메타데이터의 수동적인 저장소이며, 시동 어플리케이션은 시동 시퀀스를 가동하는데 더 중심적인 역할을 한다. 예를 들어, 일 실시예에서, 시동 어플리케이션이 실행되고, 이후 데스크탑을 사용자에게 디스플레이하는 데스크탑 어플리케이션과 같은 두 번째 어플리케이션을 실행한다. 이 시퀀스는 이 실시예에서 시동 어플리케이션에 의해 실행되었으나, 시동 어플리케이션은 setting.xml 파일에 문의하여 어떤 두 번째 어플리케이션이 실행되어야 하는지를 그럼에도 불구하고 결정할 수 있다.

네트워크 오퍼레이팅 시스템 그룹들과 친구들

네트워크 오퍼레이팅 시스템에서, 그룹들은 사용자들간에 협업과 파일 공유를 빠르고 효율적으로 가능하게 하는데 이용된다. 다른 시스템들과 달리, 네트워크 오퍼레이팅 시스템에서 새로운 그룹의 생성과 협업과 파일 공유를 가능하게 하는 것은 매우 가볍다. 예를 들어, 일 실시예에서, 사용자는 새로운 그룹을 생성하기 위해 단순히 오른쪽 클릭을 필요로 하며, 이는 공동 스토리지 폴더를 자동적으로 생성하고 그룹의 멤버들이 메시지들을 교환하고, 그룹의 다른 멤버들과 상호작용하기 위한 새로운 신원(identity)을 생성하며, 다른 사람과 실시간으로 협업할 수 있도록 한다.

그룹은, 생성시, 그룹 정보의 모음을 저장한다. 이 그룹 정보는, 상술한 바와 같이, XML 파일 시스템에서 스토리지 위치에 대한 참조로서 역할을 하는 루트 폴더 ID를 포함한다. 이 스토리지 위치에 위치한 폴더들과 파일들은 그룹의 멤버들에게만 접속가능한다. 상술한 바와 같이, 클라이언트측 컴포넌트(2400)를 시작하면, settings.xml 파일이 로그인된 사용자를 위해 획득된다. 이 settings.xml 파일은 사용자가 멤버인 그룹들에 대한 참조들의 모음을 포함한다. 이 참조들은, 적합한 커뮤니케이터와 통신 채널을 시작하기 위해, 원하는 그룹에 대한 참조를 통신 매니저(2412)에 제공함으로써, 그것이 어떤 다른 스토리지 위치 또는 파일 시스템인 것처럼 그룹을 탑재하기 위해 클라이언트측 컴포넌트(2400)에 의해 사용된다.

도 33은 네트워크 오퍼레이팅 시스템 그룹을 탑재하기 위한 메소드(3300)의 일 실시예를 설명한다. 시작 블록(3302)으로부터, 메소드(3300)는, 클라이언트측 컴포넌트(2400)가 그룹에 대한 통신 채널을 시작하는 블록(3304)으로 진행한다. 다음에, 블록(3306)에서, 통신 채널을 사용자에 연관된 사용자 정보를 처리한다. 통신 채널을 멤버쉽 이름과 암호와 같은, 그룹에 특정된 추가적인 사용자 정보를 사용자에게 요청할 수 있거나, 간편한 싱글 사인 온(single sign-on)을 위해 사용자 로그인 정보들을 재사용할 수 있다. 통신 채널이 사용자 정보들을 검증할 수 있다고 가정하고, 메소드(3300)는 이후, 통신 채널이 사용자 settings.xml 파일로부터 획득한 루트 폴더 ID를 이용하여 그룹 folders.xml 파일을 획득하는 블록(3308)로 진행한다. 다음에, 블록(3310)에서, 클라이언트측 컴포넌트(2400)는 그룹 folders.xml 파일에 대한 참조를 클라이언트 상의 현존하는 folders.xml 파일에 초가한다. (현존하는 folders.xml 파일의 생성은 도 28A-28D를 참조하여 상술하였다) 이 참조는, 클라이언트 상에서의 모든 오픈 통신 채널들의 목록을 포함하는 가상 통신 매니저 XML 문서 채널 #CommunicationManager를 표현한다. 다음에, 블록(3312)에서, 통신 채널은, 존재한다면, 그룹에 대한 autostart.xml 파일을 획득하고, 클라이언트측 컴포넌트(2400)는 명령들 또는 autostart.xml 파일에 특정된 어플리케이션들을 실행한다. 이 autostart.xml 파일은, 그룹 관리자(group administrator)가 그룹 멤버들에 의해 로그인시 항상 실행되어야 하는 감사 프로그램들(auditing programs), 환영 스크린들, 공통 데스크탑 설정들, 그룹을 표현하는 커뮤니티 등과 같은 공통 프로그램들을 특정할 수 있도록 한다. 그룹들은, 시스템 로그인시 사용자가 그들의 사용자 시동 시퀀스로 가지기 위해 선택할 수 있는 대안적인 시동 시퀀스들을 특정할 수도 있다. 메소드(3300)는 이후 종료 블록(3314)으로 진행하며, 종료한다.

일부 실시예들에서, 메소드(3300)는, 파일 스토리지 위치들이 그룹들의 대부분 동일한 특징등을 가지므로, 파일 스토리지 위치들을 탑재하는데에 사용될 수도 있다. 파일 스토리지 위치들은 파일 스토리지 위치(그룹들에 대해서 위에서 설명됨)의 멤버들인 연관들을 가지는 개념이 없으나, 파일 스토리지 위치를 탑재하기 위한 프로세스와 그 안에 있는 파일들에의 접속은 매우 유사하다. 파일 스토리지 위티들은 상술한 autostart.xml 파일에도 포함될 수 있다.

그룹 기능성 또는 파일 스토리지 위치들은 커뮤니티들을 구현하는데 사용될 수도 있다. 파일 스토리지 위치는, 특정 멤버쉽을 요구하지 않는 커뮤니티들을 생성하기 위해 사용될 수 있다. 다시 말해, 모든 사용자들은 커뮤니티의 회원들이 자동적으로 될 수 있다. 그룹 기능성은, 한편, 회원 전용 커뮤니티들을 생성하는데 이용될 수도 있다.

상술한 그룹 정보는 멤버쉽들의 모음을 포함할 수도 있다. 멤버쉽은 사용자와 그룹 사이의 연관이며, 사용자가 그룹의 멤버라는 사실을 표현한다. 각 멤버쉽은 그룹의 다른 멤버들에게 보여질 연관된 이름을 포함할 수 있으며, 따라서 그룹내에서 상호작용할 때 그 사용자에 대한 새로운 신원을 생성한다. 멤버쉽 이름들은 그룹에 가입할 때 사용자에 의해 생성될 수 있으므로, 사용자는 그들의 프라이버시를 유지하면서 넓게 변화하는 주제들을 가진 그룹들에 가입할 수 있다. 예를 들어, "Group One"으로 명명된 그룹은, 사용자 이름 "Alice"를 가진 사용자와 사용자 이름"Bob"을 가진 사용자가 모두 Group One의 멤버임을 나타내는 멤버쉽의 모음을 가질 수 있다. Alice가 Group One의 멤버임을 나타내는 첫 번째 멤버쉽은 "AliceGourpOne"과 같이 Alice의 사용자이름과 동일하거나 유사할 수 있다. Bob이 Group One의 멤버임을 나타내는 두 번째 멤버쉽은, "AnonymousGroupMember"과 같이 Bob의 사용자이름과 다를 수 있다. Alice가 다른 그룹 멤버들을 검색할 때, 그녀에게는 멤버쉽 이름들의 목록에의 접속이 주어지지만, 연관된 사용자 이름들은 아니다. 그러므로, 그녀는 "AnonymousGroupMember"가 그룹의 멤버임을 볼 수 있으나, "AnonymousGroupMember"가 실제로는 "Bob"과 연관되어 있다는 것을 알 수 없다. 다른 실시예에서, 그룹 내의 멤버들은 연관된 사용자 이름을 골개적으로 하도록 선택할 수 있는데, 그 경우에, Alice는 "AnonymousGroupMember"가 "Bob"에 연관되어 있다는 것을 알 수 있다.

메시징 서비스들은 사용자간 통신에서 사용자들의 많은 신원들을 처리할 수 있다. 이는, 한 사용자가 그의 친구들 리스트에서 동일한 친구를, 실제로 동일한 사람인지를 알지 못하면서, 두 개의 서로 다른 참가자들로 가질 수 있다는 점에서, 시스템의 친구들 핸들링에 대해서도 적용된다. 사용자는 서로 다른 인스턴트 메시지들을, 이것들이 동일한 사람으로부터 전송되었다는 것을 알지 못한채, 서로 다른 두 참가자들로부터 수신할 수도 있다.

온라인과 오프라인 상태들간의 천이(transitioning)

네트워크 오퍼레이팅 시스템의 일부 실시예들에서, 클라이언트측 컴포넌트(2400)는 정상, 온라인 상태 및 오프라인 상태에서 동작할 수 있되, 클라이언트측 컴포넌트(2400)는 어떠한 서버측 자원들에 대한 접속을 가지지 않는다. 클라이언트측 컴포넌트(2400)에서 이 기능성 제공의 이점은, 클라이언트측 컴포넌트(2400)가 온라인과 오프라인 모드들 모두에서 작동하는 단일 어플리케이션을 중단 없이(seamlessly) 지원하는 것을 돕는다는 것이며, 반면에 양 모드를 지원하기 위해 어플리케이션 개발자에게 요구되는 일의 양을 줄인다.

도 34는 제1 클라이언트의 클라이언트측 컴포넌트(2400)를 온라인 상태에서 오프라인 상태로 천이하기 위한 메소드(3400)의 일 실시예를 설명한다. 이 메소드(3400)는 제1 클라이언트의 클라이언트측 컴포넌트(2400)가 이미 시동하였고 메소드(3200)와 같은 메소드를 통해 XML 파일 시스템(2500)에 접속하였다고 가정한다. 시작 블록(3402)으로부터, 메소드(3400)는, XML 파일 시스템(2500)의 XML 웹 서비스(2510)로 통지를 전송함으로써 제1 클라이언트의 클라이언트측 컴포넌트(2400)가 제1 클라이언트의 상태를 오프라인 상태로 설정하는 블록(3404)로 진행한다. 이 상태는 이후 제1 클라이언트가 오프라인인지를 판단하기 위해 동일한 XML 웹 서비스들을 이용하여 다른 클라이언트들에 의해서도 확인될 수 있다. 다음에, 블록(3406)에서, XML 웹 서비스(2510)는 제1 클라이언트의 상태에 대해 신청한 다른 모든 클라이언트들에게 제1 클라언트가 오프라인이 되었다는 통지를 전송하도록 메시지 서버(2512)에 지시한다. 전형적으로, XML 파일 시스템(2500)에 연결된, 제1 클라이언트와 동일한 그룹에 연관된 다른 클라이언트들은 메시지 서버(2512)상에 있는 그들의 신청 리스트에 제1 클라이언트를 추가한다. 통지들은 메시지 서버(2512)에 의해 업데이트들에 관한 통지들과 동일한 방법으로 발송되며, 이는 상술되었다.

클라이언트측 컴포넌트(2400) 및 클라이언트측 컴포넌트(2400)에 의해 실행되는 어플리케이션들이 XML 파일 시스템(2500)에 접속을 가지지 않고도 계속 기능하도록 하기 위해, 클라이언트측 컴포넌트(2400)는 XML 파일 시스템(2500)으로부터 어떠한 필요한 자원들을 제1 클라이언트 상에 일시 저장하여야 한다. 이를 위해, 메소드(3400)는, 제1 클라이언트의 어플리케이션 매니저(904)가 클라이언트측 컴포넌트92400)에 의해 현재 실행중인 각 인스턴스들에 연관된 어플리케이션 패키지에서 나타난 아직 처리되지 않은, 다운로드되지 않은 자원들을 다운로드하는 블록(3408)로 진행한다. 어플리케이션 개발자는, 어플리케이션의 오프라인 사용을 가능하게 하기 위해, 어플리케이션 패키지에서 어떤 자원들이 클라이언트측 컴포넌트(2400)에 의해 반드시 일시 저장되어야 하는지를 나타낼 수 있다. 다른 실시예에서, 클라이언트측 컴포넌트(2400)는, 어플리케이션 패키지의 컴포넌트들에 의해 이용되는 참조들을 분석함으로써, 무슨 자원들이 일시 저장되어야 하는지를 자동적으로 판단할 수 있다.

일부 실시예들에서, 어플리케이션 매니저(904)는 제1 클라이언트 상에 무슨 자원들이 일시 저장되어야 하는지에 대해 판단하기 위하 추가적인, 선택적인 단계들을 수행할 수 있다. 예를 들어, 메소드(3400)는, 제1 클라이언트의 어플리케이션 매니저(904)가 각 인스턴스에 의해 동적으로 로딩되는 어떤 자원들을 다운로드하는 블록(3410)으로 진행할 수 있다. 이 자원들은 인스턴스에 연관된 어플리케이션 패키지에 의해 참조되지 않으나, 대신에 실행중에 인스턴스에 의해 판단될 수 있다. 메소드(3400)는 이후, 제1 클라이언트의 어플리케이션 매니저(904)가 각 오픈 뷰 파일에 연관된 자원들을 다운로드하는 블록(3412)로 진행할 수 있다. 동적으로 로딩된 자원들과 마찬가지로, 각 오픈 뷰 파일은 어플리케이션 패키지에 의해 참조되지 않은 자원들에 연관될 수 있다. 메소드(3400)는 어플리케이션 매니저(904)가 각 프로세스에 연관된 자원들을 유사하게 다운로드하는 블록(3414)로 또한 진행할 수 있다. 당업자라면 블록들(3410-3414)이 선택적이므로, 하나 또는 하나 이상의 블록이 메소드(3400)의 실시예에서 실행될 수 있거나, 어느 블록도 실행되지 않을 수 있음을 인식할 수 있다.

블록(3408)에서 자원들이 다운로드되고, 0 이상의 블록들(3410-3414) 이후에, 메소드(3400)는 제1 클라이언트의 클라이언트측 컴포넌트(2400)가 제1 클라이언트가 오플라인임을 나타내는 시스템 플래그를 설정하는 블록(3416)으로 진행한다. 이 시스템 플래그는 클라이언트측 컴포넌트(2400)와 제1 클라이언트에서 실행되는 어플리케이션들 모두의 가동(behavior)을 변경하는데 이용될 수 있다. 예를 들어, 일 실시예에서, 메소드(3400)는, 파일 작업들과 트랜잭션들을 XML 파일 시스템(2500)으로 즉시 전송하는 대신에, 제1 클라이언트의 클라이언트측 컴포넌트(2400)가 후속하는 파일 작업들을 큐에 대기시키고(queue), 제1 클라이언트의 각 채널들이 파일에 대한 수정을 설명하는 후속하는 트랜잭션들을 일시 저장하는 블록(3418)으로 계속한다. 오프라인인 동안에 클라이언트측 컴포넌트(2400)가 파일 작업들을 큐에 대기시키고 트랜잭션들을 일시 저장하므로, 네트워크 오퍼레이팅 시스템의 사용자들에게는 제1 클라이언트가 오프라인일 때 아무런 변경도 클라이언트측 컴포넌트(2400)에 의해 실행되는 어플리케이션들은, 네트워크 연결성을 요구하는 기능성을 불능으로 하는 것과 같이, 시스템 플래그에 기초하여 그들의 가동을 변경할 수도 있다. 클라이언트측 컴포넌트(2400) 자체는, 제1 클라이언트의 사용자가 네트워크 연결성을 요구하는 동작을 수행하려고 시도하면, 에러 메시지를 디스플레이 하는 것과 같이, 그 가동을 더 변경할 수 있다. 메소드(3400)는 이후 종료 블록(3420)으로 진행하며, 종료한다.

도 35는 제1 클라이언트가 메소드(3400)와 같은 메소드를 이미 실행하고 오프라인 상태에서 동작할 때 온라인으로 돌아오는 메소드(3500)의 일 실시예를 설명한다. 시작 블록(3502)으로부터, 메소드(3500)는 제1 클라이언트가 온라인이 되며, 제1 클라이언트의 클라이언트측 컴포넌트(2400)가 XML 웹 서비스(2510)로 온라인 상태의 통지를 전송하는 블록(3504)로 진행한다. 제1 클라이언트는 로컬 에어리어 네트워크, 무선 네트워크, 다이얼업 네트워크 등 중 하나와, 여기에 한정되지는 않는, 연결을 설정하거나 재설정함으로써, 온라인이 될 수 있다. 다른 실시예에서, 제1 클라이언트는 사용자가 온라인으로 하려는 희망을 나타낼 때, 네트워크 연결이 이미 설정되어 있으면, 온라인이 될 수 있다. 다음에, 블록(3506)에서, XML 웹 서비스(2510)는 제1 클라이언트가 온라인이 되었다는 통지를 제1 클라이언트이 상태에 대해 신청한 모든 클라이언트에 전송하라고 메시지 서버(2512)에 지시한다.

메소드(3500)는 이후, 제1 클라이언트의 트랜잭션 매니저(910)가 XML 웹 서비스(2510)로부터 제1 클라이언트 상에 일시 저장된 문서들에 대한 변경들을 다운로드하는 블록(3508)으로 진행한다. 일 실시예에서, 이 다운로드된 변경들은 제1 클라이언트가 오프라인 동안 다른 클라이언트들에 의해 XML 파일 시스템(2500)의 문서들에 만들어진 변경이다. 다음으로, 블록(3510)에서, 제1 클라이언트의 트랜잭션 매니저(910)는 일시 저장된 문서들과 다운로드된 변경들 사이의 충돌들을 해결한다. 일 실시예에서, 트랜잭션 매니저(910)는 충돌이 존재하는 것을 단지 감지하고, (일시 저장된 변경들을 포함하는 새로운 파일을 생성하고, 다운로드된 변경들을 위해 일시 저장된 변경들을 삭제하는 등) 사용자에게 수동으로 충돌을 해결하도록 요청할 수 있다. 다른 실시예에서, 트랜잭션 매니저(910)는 어떤 변경들이 유지되어야 하고 어떤 것들이 버려져야 하는지를 판단하는 알고리즘을 실행한다.

다음에, 블록(3512)에서, 제1 클라이언트의 트랜잭션 매니저(910)는 큐에 대기된 파일 작업들을 XML 웹 서비스(2510)으로 전송한다. 예를 들어, 오프라인인 동안에 제1 클라이언트의 사용자가 XML 파일 시스템(2500)의 어떤 파일들을 생성하고, 삭제하고, 이름을 변경하려고 시도하면, 파일 작업들은 이 때 XML 파일 시스템(2500)으로 전송될 수 있다. 일 실시예에서, XML 파일 시스템(2500)은 다른 사용자들에 의해 만들어진 변경들(이미 삭제된 파일의 이름을 변경하려는 시도와 같은)과의 충돌을 감지하고, 적절하게 대응한다.

메소드(3500)는 이후, 제1 클라이언트의 신청 리스트에 모니터된 오브젝트들을 재추가하기 위해, 제1 클라이언트의 클라이언트측 컴포넌트(2400)가 XML 웹 서비스(2510)를 통해 메시지 서버(2512)에 접촉하는 블록(3514)로 진행한다. 다음에, 블록(3516)에서, 제1 클라이언트의 클라이언트측 컴포넌트(2400)는 제1 클라이언트가 온라인임을 나타내는 시스템 플래그를 설정한다. 일 실시예에서, 이 시스템 플래그의 설정은 클라이언트측 컴포넌트(2400)와 어플리케이션들을 정상, 즉 네트워크 연결된 작업 상태로 복귀시킨다. 메소드(3500)는 이후 종료 블록(3518)로 진행하며, 종료한다. 여기서, 제1 클라이언트의 XML 파일 시스템은 이후 네트워크 오퍼레이팅 시스템의 서버측 컴포넌트(2500)와 동기화되며, 온라인이 된다.

XML 파일 시스템 특별 폴더들

상술한 바와 같이, XML 파일 시스템(2500) 내의 어떤 폴더들은 특별 폴더로 지정될 수 있다. 일 실시예에서, 특별 폴더에 대한 항목은 일반 폴더들에 대한 항목과 같은 방법으로 폴더 데이터베이스(2520)에 저장되지만, 그 폴더가 특별 폴더임을 나타내는 플래그가 설정된다. 일 실시예에서, 특별 폴더에 대한 폴더 데이터베이스(2520) 내의 항목은, 특별 폴더에 파일들을 생성하는 요청을 처리하는 많은 서버 프로세스 중 하나의 지시를 포함할 수 있다. 다른 실시예에서, 한 서버 프로세스는 특별 폴더에서의 파일들을 생성하는 모든 요청들을 처리하며, 그 파일의 파일 종류와 같은, 파일의 컨텐츠에 따라 파일을 어떻게 처리할지를 결정한다.

이 특별 폴더들은, 파일 스토리지를 제공하는 대신에, 사용자들간의 비동기적인 메시징과 같은 일부 다른 데이터 핸들링 루틴에 대한 추상화 역할을 할 수 있다. 그러한 비동기적인 메시징의 일 예는 다른 사용자들에게로 의도된 발신 메시지들을 수신하고 처리하기 위한 발신함의 이용이 될 수 있다. 사용자간 통신을 위한 특별한 폴더의 이용은 많은 이점들을 제공한다. 예를 들어, 클라이언트 어플리케이션 개발을 단순화한다. XIOS 어플리케이션(2402)은 익숙한 파일 생성 루틴들을 단지 이용함으써 특별 폴더에 연관된 메시징 프로토콜을 이용할 수 있으며, 통신 프로토콜의 하부 상세와 씨름할 필요가 없다. 다른 예로, 사용자간 통신을 위한 특별 폴더들의 이용은 XIOS 어플리케이션(2402)이, 상술한 바와 같이, XML 파일 시스템(2500)에 포함된 그룹 기능성에 영향을 미치도록 한다. 그러므로, XIOS 메시징을 위해 특별 폴더들을 이용하는 어플리케이션(2402)은 보안, 그룹 멤버쉽, 친구 목록들, 주소지정, 익명성 등을 구현하기 위한 추가적인 코드를 추가할 필요가 없는데, 그러한 특징들에 대한 XML 파일 시스템(2500)의 하부 기능성에 의존하면 되기 때문이다.

도 36은 발신함 특별 폴더에서 새로운 파일을 생성하는 요청을 처리하는 메소드(3600)의 일 실시예를 설명한다. 그러한 요청이 클라이언트 상에서 실행하는 XIOS 어플리케이션(2402)에게 파일을 생성하는 요청인 것처럼 보이지만, 서버는 그 요청을 제2 사용자에게 메시지를 전송하라는 요청으로 취급한다. 시작 블록(3602)로부터, 메소드(3600)는 제1 사용자의 발신함 폴더에 연관된 서버 프로세스가 발신함 특별 폴더에 새로운 파일을 생성하는 요청을 수신하는 블록(3604)로 진행한다. 다음에, 블록(3606)에서, 서버 프로세스는 그 요청으로부터 의도된 수신자의 주소를 추상화한다. 메소드(3600)는 서버 프로세스가 의도된 수신자의 주소와 연관된 제2 사용자를 식별하는 블록(3608)로 진행한다.

상술한 XML 파일 시스템(2500)의 그룹과 친구 목록 기능성은 많은 서로 다른 종류의 주소 지정(addressing)이 제2 사용자를 식별하도록 한다. 예를 들어, 제1 사용자는 메시지를 제2 사용자의 사용자 이름으로 직접 주소 지정할 수 있다. 다른 예로서, 제1 사용자는 제2 사용자에 연관된 멤버쉽 이름으로 메시지를 주소 지정할 수 있다. 이 경우에, 제2 사용자의 익명성은 보장되지만, 제1 사용자는 제2 사용자로 메시지를 여전히 주소 지정할 수 있다. 또 다른 예로, 제1 사용자는 제2 사용자에 연관된 메타데이터에 저장된 주소, 예를 들어, 전화 번호로 메시지를 주소 지정할 수 있다. 서버 프로세스는 어떤 종류의 주소 지정이 이용되었는지를 판단하며, 그에 따라 제2 사용자를 식별한다.

다음에, 블록(3610)에서, 서버 프로세스는 제2 사용자의 수신함 폴더 ID를 결정한다. 일 실시예에서, 이는 제2 사용자에 연관된 수신함 폴더에 대하여 폴더 데이터베이스(2520)를 검색하는 것을 단순히 포함한다. 메소드(3600)는 이후, 수신함 폴더 ID를 이용하여, 서버 프로세스가 제2 사용자의 수신함 폴더에서 새로운 파일을 생성하는 블록(3612)으로 진행하며, 새로운 파일은 그 요청에 포함된 데이터를 포함한다. 특별 폴더에서 파일이 생성된 실시예들에서(파일 생성 요청을 직접적으로 처리하는 서버 프로세스에 반대로), 서버 프로세스는 새로운 파일을 제1 사용자의 발신함 폴더로부터 제2 사용자의 수신함 폴더로 단순히 이동한다. 다음에, 메소드(3600)는 종료 블록(3514)으로 진행하고 종료한다.

예제 어플리케이션-채팅

위에서 강조된 것처럼, 네트워크 오퍼레이팅 시스템의 이점은 네트워크 오퍼레이팅 시스템에 임베디드된 특징들이 재사용가능하고 스케일러블하고, 여러 플랫폼에 적용되고(cross-platform), 풍부한 보안과 익명성 기능성을 포함하는 협업 컴포넌트들을 신속하게 개발할 수 있도록 한다는 것이다. 이 많은 특징들의 이점을 이용하는 예시적인 어플리케이션의 일 실시예는 아래에서 설명할 채팅 어플리케이션이다.

도 37은, 상위 레벨에서, 채팅 어플리케이션(3700)과 상응하는 공유 데이터 파일(3710)의 일 실시예를 설명한다. 새로운 통신 프로토콜들과 인증 방법들을 고안하고 코딩하는 대신에, 채팅 어플리케이션(3700)은 XML 파일 시스템(2500)에 존재하는 공유 데이터 파일(3710)의 이용을 통해 채팅 대화에 참여한 참가자들 사이에 통신을 수행한다. 채팅 어플리케이션(3700)의 인터페이스는 네 개의 주요 컴포넌트들인, 호스트 윈도우 컴포넌트(3712), 텍스트 디스플레이 컴포넌트(3702), 텍스트 항목 컴포넌트(3704) 및 버튼 컴포넌트(3706)를 포함한다. 채팅 대화의 시작시, 텍스트 디스플레이 컴포넌트(3702)는 바인딩(3708)을 통해 공유 데이터 파일(3706)에 바인드되어, 채팅 대화에 참가한 어느 참가자에 의해 공유 데이터 파일(3710)에 만들어진 변경들은 텍스트 디스플레이 컴포넌트(3710)(명확성을 위해 이 텍스트는 도 37에서 생략되었음)에 반영된다.

도 38은, 상위 레벨에서, 채팅 어플리케이션(3700)의 일 실시예의 텍스트 디스플레이 컴포넌트(3702)와 버튼 컴포넌트(3706)가 공유 데이터 파일(3710)에도 바인드되는 것을 설명한다. 사용자가 텍스트를 텍스트 항목 컴포넌트(3704)에 입력하고 버튼 컴포넌트(3706)를 클릭하면, 변경이 공유 데이터 파일(3710)에 만들어진다. 이 변경은, 텍스트 디스플레이 컴포넌트(3702)를 포함하는, 공유 데이터 파일(3710)에 바인드된 모든 컴포넌트들에 이후 전파된다.

도 39는, 상위 레벨에서, 제1 사용자(3902)의 채팅 어플리케이션과 제2 사용자(3904)의 채팅 어플리케이션 사이의 채팅 대화중에 공유 데이터 파일(3710)의 업데이트를 설명한다. 이 도면에서, 제1 사용자(3902)의 채팅 어플리케이션의 텍스트 디스플레이 컴포넌트(3702)와 제2사용자(3904)의 채팅 어플리케이션의 텍스트 디스플레이 컴포넌트(3702)는 모두 공유 데이터 파일(3710)에 바인드되므로, 공유 데이터 파일(3710)의 컨텐츠를 디스플레이한다. 제1 사용자가 텍스트 입력 컴포넌트(3704)에 텍스트를 입력하고, 버튼 컴포넌트(3706)를 클릭한다. 버튼 컴포넌트(3706)는 트리거에 연관되어 있으며, 이는 버튼 컴포넌트가 클릭되면, 텍스트 항목 컴포넌트(3704)로부터 텍스트를 읽고, 텍스트(3906)를 공유 데이터 파일(3710)에 붙이고, 텍스트 항목 컴포넌트(3704)에서 텍스트를 지우는 단계들이 실되도록 한다.

공유 데이터 파일(3710)을 업데이트하는 이 절차는, 개발자는 이 기능성을 가능하게 하기 위해 상술한 네 개의 컴포넌트들을 단순히 연관시켜야 하며, 텍스트 항목 컴포넌트에 바인드되는 규칙을 생성하여야 한다는 점에서, 네트워크 오퍼레이팅 시스템의 적어도 하나의 이점을 보여주는 것을 돕는다. 장면들 너머에는, 네트워크 오퍼레이팅 시스템이 공유 데이터 파일(3710)을 업데이트하는 수 많은 상세들을 처리한다. 예를 들어, 일 실시예에서, 일시 저장된 공유 데이터 파일의 사본(3710)은 문서 매니저(912)에 의해 유지되는 클라이언트측 캐시에 저장된다. 상응하는 URL 오브젝트는 공유 데이터 파일(3710)을 업데이트하는 요청을 수신하고, 이는 트랜잭션 매니저(910)가 변경들을 표현하는 트랜잭션을 생성하도록 한다. 트랜잭션 매니저(910)는, 트랜잭션이 XIOS 커뮤니케이터(2504)와 XIOS 채널을 통해 XML 웹 서비스(2510)으로 제출되도록 함으로써, 이 트랜잭션을 원격 리스너들로 전파한다. XML 웹 서비스(2510)는 파일이 공유되었음을 언급하고, 제출된 트랜잭션을 트랜잭션 코디네이터(2522)로 전달한다. 트랜잭션 코디네이터(2522)는 XML 파일 시스템 내에서 공유 데이터 파일(3710)을 업데이트하는 트랜잭션을 이후 기록한다.

도 40은, 상위 레벨에서, 채팅 어플리케이션(3700)의 일 실시예에서 공유 데이터 파일(3710)에 대한 변경의 전파를 통한 채팅 메시지의 전송을 설명한다. 상술한 바와 같이, 제1 클라이언트(3902)의 채팅 어플리케이션과 제2 클라이언트(3904)의 채팅 어플리케이션의 텍스트 디스플레이 컴포넌트(3702)는 공유 데이터 파일에 바인드된다. 그러므로, XML 파일 시스템(2500)이 공유 데이터 파일(3710)을 업데이트하면, 바인드된 각 컴포넌트들은 변경을 통지받으며, 따라서 업데이트된다.

유리하게, 이는 개발자가, 데이터 업데이트 이벤트 전파를 통해, 자동적으로 항상 공유된 데이터 파일(3710)에 동기화된 정확한 정보를 표시하는 UI 컴포넌트들을 갖도록 하며, 대신에 컴포넌트를 공유 데이터 파일(3710)에 바인딩 함으로써, 코드를 작성하지 않아도 채팅 통신을 완료하도록 한다. 공유 데이터 파일(3710)의 업데이트와 마찬가지로, 네트워크 오퍼레이팅 시스템은 이 트랜잭션의 다수의 상세들을 처리한다. 예를 들어, 일 실시예에서, 트랜잭션 코디네이터(2522)가 트랜잭션을 기록하면, 메시지 서버(2512)가 공유 데이터 파일(3710)에서의 변경에 신청된 각 클라이언트에 공유 데이터 파일(3710)이 업데이트되었음을 통지하도록 지시한다. 메시지 서버(2512)는 이 통지들을 각 클라이언트에 전송하며, 클라이언트들은 통지로부터 업데이트된 정보를 추상화하거나 그 파일의 최신 버전을 획득하기 위해 XML 파일 시스템(2500)에 접촉한다. 이에 관해, 다른 클라이언트들의 트랜잭션 매니저(910)는 변경이 제1 클라이언트에 의해 제출되었음을 인지하고, 그의 공유 데이터 파일(3710)의 일시 저장 버전을 반복적으로 업데이트하지 않는다. 다른 클라이언트들의 트랜잭션 매니저(910)는 변경들이 그들의 각 공유 데이터 파일의 일시 저장 버전들에 일체되도록 한다. 다른 데이터 업데이트들이 발생하는 것과 같이, 제1 클라이언트(3902)의 채팅 어플리케이션의 텍스트 디스플레이 컴포넌트들(3702)과 제2 클라이언트(3904)의 채팅 어플리케이션을 포함하는, 리스닝 컴포넌트들은 파일이 업데이트되었음을 통지받는다. 텍스트 디스플레이 컴포넌트들(3702)는 추가된 컨텐츠(3906)으로 따라서 자동적으로 업데이트된다.

도 41은 클라이언트들간 협업 통신을 위해 공유 데이터 파일(3710)을 이용하여 가능하게 된 추가적인 특징을 설명한다. 즉, 주어진 공유 데이터 파일(3710)에 대한 업데이트들이 공유 데이터 파일(3710)을 신청한 어떤 수의 클라이언트들에 전파되므로, 둘 이상의 참가자들간의 협업적인 통신을 가능하게 하기 위한 추가적인 작업이 필요하지 않다. 도 41에 도시된 바와 같이, 제1 클라이언트(3902)와 제2 클라이언트(3904)간 대화는, 어떠한 추가적인 디자인 변경들 없이도, 제3 클라이언트와 제4 클라이언트와 같은, 어떤 수의 다른 클라이언트들에 의해서도 참가될 수 있다. 각 클라이언트는 공유 데이터 파일(3710)에 바인드되며, 상술한 업데이트들을 수신한다.

주어진 사용자의 채팅 친구 목록에 대한 연락처들의 추가와 개별 채팅 세션들의 설정은 네트워크 오퍼레이팅 시스템 내에 포함된 많은 특징들을 또한 설명한다. 일 실시예에서, 제1 사용자는 제1 사용자의 친구 목록의 멤버이고 제1 사용자와의 채팅 통신을 동의한 제2 사용자와 채팅 메시지를 주고 받을 수만 있다. 제1 사용자의 친구 목록은 XML 파일 시스템(2500) 내의 문서에 저장될 수 있거나, settings.xml 파일의 일부에 저장되고 전송될 수 있다. 제2 사용자를 친구 목록에 추가하기 위해, 제1 사용자는 먼저 사용자를 검색하여야 한다. 일 실시예에서, 그룹에 속할 때 사용자들의 익명성을 보존하기 위해, 제1 사용자는 멤버쉽 이름들을 검색할 수만 있으며, 각 멤버쉽 이름들은 사용자와 제1 사용자가 속한 그룹에 연관된다. 일 실시예에서, 제1 사용자는 전역 그룹을 또한 검색할 수 있으며, 여기에는 사용자의 실제 이름의 지시가 있으나, 그룹들에서 발견한 이름과의 연결은 없다.

어느 경우에도, 검색은 제1 사용자에게 제2 사용자에 연관된 주소를 반환한다. 제1 사용자는 이후 제2 사용자의 주소로 제2 사용자를 제1 사용자의 친구 리스트에 추가하는 요청을 전송한다. 일 실시예에서, 이는 상술한 메소드(3600)를 이용해서 할 수 있으며, 제1 사용자는 제1 사용자의 발신함 폴더에 친구 목록 요청을 구성하는 파일을 생성하며, 이는 이후에 서버 프로세스에 의해 라우팅되고 제2 사용자의 수신함 폴더로 전송된다. 제2 사용자의 클라이언트 상에서, 요청은 제2 사용자의 수신함으로부터 검색되고, 제2 사용자에게 제1 사용자가 친구 목록에 추가하기를 원하는지를 묻는 다이얼로그가 디스플레이된다. 제2 사용자가 응답하면, 메시지는 제1 사용자의 친구 목록에 제2 사용자의 추가를 종료하기 위해 제1 사용자에게 비슷한 방법으로 다시 전송되며, 제1 사용자는 이후 제2 사용자와의 채팅 대화를 시작할 수 있다.

제1 사용자가 채팅 세션을 제2 사용자와 시작하기 위해, 유사한 프로세스가 발생한다. 제1 사용자의 채팅 어플리케이션은 공유 데이터 파일(3710)을 생성하고, 텍스트 디스플레이 컴포넌트(3702)를 공유 데이터 파일(3710)에 바인드하고, 제2 사용자의 주소로 채팅 세션을 시작하자는 요청을 전송한다. 요청은 상술한 바와 같이 전달된다. 제2 사용자가 요청을 수락하면, 통지가 제1 사용자의 채팅 어플리케이션으로 전달되고, 이는 이후 공유 데이터 파일(3710)의 문서 ID를 제2 사용자의 채팅 어플리케이션으로 전송한다. 제2 사용자의 채팅 어플리케이션은 그의 텍스트 디스플레이 컴포넌트(3702)를 공유 데이터 파일(3710)에 바인드하고, 채팅 대화는 상술한 바와 같이 진행한다.

이 특징들이 채팅을 참조하여 설명되었지만, 당업자라면 메시지 보드들, 이메일 등과 같은 서버 중재 통신(server-mediated communication)이 공유 데이터 파일들을 이용하여 구현될 수 있음을 인지할 수 있다. 또한, 공유 데이터 파일들은 중재를 위한 서버를 요구하지 않는 다른 형태의 통신을 조정하는데 이용될 수 있다. 예를 들어, 제1 사용자와 제2 사용자는 VOIP 또는 화상 회의 같은 피어-투-피어 통신을 위한 대역폭 설정들, 암호 설정들 등을 협상하기 위해 공유 데이터 파일을 이용할 수 있다.

더욱이, 위의 채팅의 설명이 채팅 어플리케이션이 단순화를 위해 수신함 폴더에 도착한 모든 메시지들을 처리하고 있지만, 클라이언트 상의 추가적인 컴포넌트가 수신 메시지들을 관리하는 것도 가능하다. 일실시예에서, 클라이언트 상의 컴포넌트는 수신함 폴더에 나타난 각 메시지들을 분석하고 메시지를 처리할 적합한 어플리케이션을 결정한다. 컴포넌트는 이후 어플리케이션을 시작하고, 이후 처리를 위해 메시지를 어플리케이션으로 패스한다. 이렇게, 수신 채팅 요청들 또는 친구 리스 요청들이 이미 구동중인 채팅 어플리케이션을 가지지 않아도 처리될 수 있다.

도 42는 XIOS 어플리케이션들 생성시 재사용가능한 컴포넌트들의 이용의 다른 이점을 설명한다. 도면은 웹 브라우저 내에 호스팅된 네트워크 오퍼레이팅 시스템의 일 실시예를 설명하며, 네트워크 오퍼레이팅 시스템이 독립 어플리케이션이나 클라이언트측 컴포넌트(2400)의 머신 오퍼레이팅 시스템 구현과 같은 다른 실시예들에서 어떻게 보여지는지를 나타낼 수 있다. 웹 브라우저 내의 각 박스들은 이메일 컴포넌트, 시계 컴포넌트, 웹 서치 컴포넌트, 그룹 메시지 컴포넌트 및 날씨 예보 컴포넌트와 같은 재사용 가능한 컴포넌트들로 생성된 XIOS 어플리케이션(2402)을 표현한다. 단순히 독립 채팅 어플리케이션 내에 있는 것과는 반대로, 아래 오른쪽의 박스는 이 웹 브라우저 내의 채티 어플리케이션 컴포넌트의 재사용을 보여준다. 컴포넌트들이 다른 컨텍스트에서 작동하기 위해 다시 작성될 필요가 없으므로, 재사용 가능한 컴포넌트들의 사용은 그러한 복잡한 어플리케이션들의 신속한 개발을 가능하게 한다. 복잡한 어플리케이션들을 생성할 수 있는 다른 이점은 데이터 모델들로부터 어플리케이션에 주는 하부 데이터가 복수의 이질적인 소스들로부터 병합될 수 있으며, 따라서 어플리케이션들이 다수의 데이터 소스들의 합성으로부터 작동할 수 있게 한다.

예제 어플리케이션-동창회

도 43은 시스템의 실시예들을 이용하여 쉽게 생성된 예제 협업 어플리케이션을 설명한다. 1992년 학급 동창회 어플리케이션은 그룹의 멤버들에게 제공될 수 있는 기능성의 일 예이다. 도 42를 참조하여 상술한 바와 같이, 도 43은 복수의 데이터 소스들을 참조하는 컴포넌트들의 모음을 설명한다. 1992년 학급 동창회 어플리케이션에 의해 설명되는 것은 그룹 폴더를 바인딩할 때 로딩되는 autostart.xml 파일의 일부로서 시작되는 컴포넌트들의 모음이다. 도 32B에 도시된 바와 같이, 1992년 학급 동창회 그룹 폴더는 데이터 소스로서 클라이언트에 바인드될 수 있으며, 그 경우에 사용자 인터페이스 내에서 드라이브로 디스플레이된다. 사용자가 그후에 그 데이터 소스를 오픈하면(또는 사용자가 처음으로 데이터 소스를 바인드하면), 그 그룹 폴더에 연관된 autostart.xml 문서는 Schedule of Events, the Map to Reunion Events, the Countdown to Reunion 등과 같은 컴포넌트들의 모음이 디스플레이되도록 한다.

이 컴포넌트들의 자동 디스플레이와 함께, 그룹 기능성은 보안을 또한 제공한다. 예를 들어, 그룹의 멤버들만이, 그룹 폴더 계층구조 내에서 저장된 폴더의 뷰일 수 있는 Photo Album 내의 항목들을 볼 수 있다. 그룹 기능성은 그룹의 다른 멤버들과의 쉬운 협업을 또한 제공하며, 도 43의 Chat 컴포넌트에 보여지는 바와 같이, 이는 사용자에게 다른 그룹 멤버들을 친구 리스트에 추가하도록 요구하지 않고도, 그룹의 다른 온라인 멤버들을 보여준다.

설명적인 실시예들이 설명되고 묘사되었지만, 다양한 변경들이 본 발명의 사상과 범위를 벗어나지 않고도 만들어질 수 있음은 이해될 수 있다.

Claims (5)

1. XML 프로그래밍 랭귀지로 작성된 어플리케이션 코드를 입력으로 받아들이고 어플리케이션 코드가 컴퓨팅 장치 상에서 실행되도록 하는 방법들을 구현하는 플랫폼 독립된 XML 가상 머신에서, 상기 방법은,
   동작의 의미를 어플리케이션의 프로세스 코드의 실행에 결합하도록 설정된 인스턴스 오브젝트를 포함하는 어플리케이션을 실행하기 위한 한 세트의 런타임 오브젝트들을 정의하고;
   어플리케이션의 프로세스 코드에 정의된 작업들을 실행하는 하위 레벨 구조체("작업 핸들러들")를 제공하며;
   상태가 정의되지 않는 프로세스 오브젝트들이 작업 핸들러들에게, 어플리케이션의 프로세스 코드를 실행할 때 어플리케이션의 런타임 상태에서의 변경을 설명하는 인스턴스 오브젝트를 제공하도록 하는 로직을 구현하는 XML 가상 머신.
2. 제1항에 있어서, 어플리케이션을 실행하기 위한 한 세트의 런타임 오브젝트들을 정의하는 것은, 어플리케이션 인스턴스의 경계를 한정하는 인스턴스 오브젝트에 특정된 로컬화된 관계 계층구조를 정의하는 것을 포함하는XML 가상 머신.
3. 제1항에 있어서, 상태가 정의되지 않는 프로세스 오브젝트들이 어플리케이션의 프로세스 코드를 실행할 때 이용되도록 하는 로직을 구현하는 것은, 복수의 어플리케이션 인스턴스들에 의해 공유되는 단일 노티파이어 오브젝트를 이용하여 트리거를 어플리케이션에 등록하도록 설정된 트리거 이벤트 버스를 제공하는 것을 포함하는 XML 가상 머신.
4. 제1항에 있어서, 상태가 정의되지 않는 프로세스 오브젝트들이 어플리케이션의 프로세스 코드를 실행할 때 이용되도록 하는 로직을 구현하는 것은, 적합한 어플리케이션 인스턴스에 관해 어플리케이션 코드에서 이용되는 전역적으로 명명된 오브젝트들을 평가하도록 설정된 익스프레션 엔진을 제공하는 것을 포함하는 XML 가상 머신.
5. 여기에서 기술되고 설명된 것과 동일한 것을 이용하는 XML 가상 머신과 방법.
   

Images