KR20080060243A

KR20080060243A - 라인 오브 비지니스 애플리케이션과 생산성 제품군애플리케이션 간에서 정보를 동기화하기 위한 장치, 방법및 컴퓨터 판독가능 매체

Info

Publication number: KR20080060243A
Application number: KR1020087009149A
Authority: KR
Inventors: 마틴 더블유. 멀렌더; 데이비드 코론탈리; 자레드 알 파커; 토마스 케이 거스틴; 토드 제이. 아벨; 로렌스 산체스; 롤란도 지메네즈 살가도
Original assignee: 마이크로소프트 코포레이션
Priority date: 2005-09-16
Filing date: 2006-09-18
Publication date: 2008-07-01
Also published as: CA2624272A1; AU2006292299A1; SG165396A1; EP1934783A4; EP1934783A1; NO20081591L; WO2007035680A1

Abstract

생산성 제품군 애플리케이션과, 고객 관계 관리(CRM) 애플리케이션 등의 LOB 애플리케이션 간의 동기화를 허용하도록 동기화 방법이 구성된다. LOB 애플리케이션 내의 새로운 엔터티를 갱신, 삭제 또는 생성하기 위하여, 웹 서비스 호출을 통하여 생산성 제품군 애플리케이션으로부터 LOB 애플리케이션으로 요청이 보내진다. LOB 애플리케이션은 수신된 웹 서비스 호출로부터 각 요청을 추출하며, 이 요청은 XML 데이터 표현으로 제공될 수 있다. 생산성 제품군 애플리케이션 내의 아이템을 갱신, 삭제 또는 생성하기 위해, 이메일 내에 임베드된 제어 메시지를 통해, 요청이 생산성 제품군 애플리케이션에 보내진다. 제어 메시지는 사용자로부터 숨겨지고, LOB 엔터티와 생산성 제품군 애플리케이션 아이템 간의 바인딩, 평가, 충돌 해결, 및 속성 프로모션을 위해 이메일 메시지로부터 추출된다.

생산성 제품군 애플리케이션, LOB 애플리케이션, 바인딩, 동기화, 바운드 아이템

Description

라인 오브 비지니스 애플리케이션과 생산성 제품군 애플리케이션 간에서 정보를 동기화하기 위한 장치, 방법 및 컴퓨터 판독가능 매체{PRODUCTIVITY SUITE TO LINE OF BUSINESS SYNCHRONIZATION MECHANISM}

이벤트들의 일정을 기입하는 것, 연락처 정보를 저장하는 것, 이메일을 지원하는 것, 작업 정보를 저장하는 것 등을 위한 애플리케이션들을 비롯하여, 사용자가 이용할 수 있는 많은 생산성 제품군들이 있다. 일례로는 워싱턴주 레드몬드의 마이크로소프트사로부터 입수할 수 있는 마이크로소프트 아웃룩

이 있다. 마이크로소프트 아웃룩

은 마이크로소프트 오피스

생산성 제품군의 일부분이다. 많은 사용자들은 그러한 생산성 제품군 애플리케이션들에 친숙하며, 일상적으로 사용하고 있다.

일부 생산성 제품군 사용자들은 특정 비지니스용으로 개발된 비지니스 소프트웨어 애플리케이션 또는 시스템(라인-오브-비지니스, 즉 LOB 시스템이라고도 칭함)도 이용한다. 일례로는, 많은 기업들로부터 입수할 수 있는 고객 관계 관리(Customer Relationship Managament, CRM) 시스템이 있다. LOB 시스템에 의해 관리되는 많은 정보는, 몇가지 예를 들자면, 연락처 관리, 이벤트 및 작업의 일정 기입을 포함할 수 있다.

많은 경우에서, 생산성 제품군은 정보를 LOB 시스템과 자동으로 교환 또는 동기화하지 못한다. 예를 들어, 사용자가 자신의 생산성 제품군에서 비지니스 작업을 추가하면, 그 작업 정보는 LOB 시스템으로 자동으로 마이그레이션(migration)하지 않을 것이다. 대신에, 그 정보는 각각의 다른 시스템에서 사용자에 의해 발견된다. 전형적으로, 사용자는 LOB 시스템에서 그 작업 정보를 두번째로 입력해야 할 것이다. 일부 사용자들은 LOB 정보가 이메일 시스템에 저장되고, 백엔드 시스템에서 LOB 정보와 동기화되기를 원할 것이다.

개시되는 실시예들의 다양한 양태에 따르면, 동기화 방법은, 생산성 제품군 애플리케이션을 포함하는 클라이언트 머신과, LOB 애플리케이션을 포함하는 서버 머신 간의 동기화를 허용하도록 구성된다. 생산성 제품군 애플리케이션은 아웃룩

(워싱턴주 레드몬드의 마이크로소프트사로부터 입수가능), Lotus Notes, Star Office 등과 같은 개인 정보 관리자(PIM) 애플리케이션일 수 있다. 예시적인 생산성 제품군 애플리케이션은 이메일 관리, 약속 관리, 일정 정하기/일정 기입하기 관리, 노트 관리, 작업 관리, 연락처 관리 및 다른 것들을 포함한다. XML 데이터 표현 및 저장된 바인딩 정보를 이용하여, 생산성 제품군 애플리케이션 내의 데이터 아이템들과 LOB 애플리케이션 내의 엔터티들 간의 동기화가 다루어질 수 있다.

특정한 일 구현예에서, 동기화를 위해 사용되는 정보는 XML 데이터 표현으로 저장된다. XML 데이터 표현은 생산성 제품군 애플리케이션 내의 데이터 아이템에 대한 속성으로서 저장될 수 있다. XML 데이터 표현은 LOB 애플리케이션에 전해질 수 있고, 그러면, 그 LOB 애플리케이션은 자체의 충돌 해결과 LOB 엔터티들을 위한 데이터 저장을 다룰 수 있다. 그러면, LOB 애플리케이션 내의 엔터티들에 대한 변경은 XML로서 제공될 수 있고, 그것은 후속하여 생산성 제품군 애플리케이션에 전해지는 제어 메시지로 포맷될 수 있다. XML 데이터 표현은 각각의 개별 애플리케이션에 의해 단순하게 관리되는 단일 인터페이스를 제공한다.

다른 양태에서, 정보의 암호화는 사용자별로 수행된다. 이 양태는, 이메일 수신자에게 보내진 임의의 PIM 아이템 내에 포함된 정보가 그 수신자에 의해서는 읽힐 수 없으며, 따라서 부주의하게 공유될 수 없음을 확실시하는 것을 유리하게 돕는다. 관련된 양태에서, 암호화는, 정보가 수신자측에서 예상되지 않은 행동을 유발하는 것을 방지하는 것을 도울 수 있다. 예를 들어, 몇몇 종래 시스템에서, 약속에 포함된 정보는 그 약속에 대한 초대장을 보낼 때 쉽게 공유될 수 있다. 따라서, 사용자는 깨닫지 못한 채로 정보를 공유할 수 있다. 정보의 암호화는 이와 같은 부주의한 정보 공유의 발생을 방지한다. 그러나, 사용자가 다수의 장치를 가지고 있는 경우에, 위에서 설명한 암호화는 정보가 사용자의 다수의 장치에서 공유되는 것을 막지 않을 것이다.

다른 양태에서, 정보를 개인 속성 내에 저장하여, 덮어쓰기의 가능성을 감소시킨다. 일부 종래의 시스템들에는, 요청자가 깨닫지 못한 채로, 약속 요청 내의 피초대자들과 정보가 암시적으로 교환될 수 있다. 요청자 및 피초대자가 명시적으로든 암시적으로든 정보를 보냄으로써 그 정보를 공유할 때는, 정보가 동일 속성 내에 저장될 가능성이 있다. 마지막으로 저장된 정보가 유지될 것이므로, 사용자들 중 하나로부터 온 정보가 덮어쓰기될 수 있다. 본 개시의 한 양태에서는, 추가 정보를 저장하기 위해 특정한 속성 이름이 할당되어, 충돌이 회피된다.

다른 양태에서, 정보가 프로모션(promotion) 또는 디모션(demotion)되어, (XML로 된) 그 정보의 요소 또는 속성이 그 정보를 포함하는 PIM 아이템 내의 속성에 복제될 수 있다. 예를 들어, 한 구현예에서, 표준의 마이크로소프트 아웃룩

UI가 이 값들을 표시 또는 조작하기 위해 사용될 수 있고/있거나, 이 값들은 다른 사용자들과 공유될 수 있다. 본 개시의 한 양태에서, XML 데이터 표현은 LOB 아이템들이 LOB 애플리케이션에 의해서만 변경될 수 있도록, LOB 애플리케이션에 제공된다. 다른 양태에서, LOB 아이템은 XML 데이터 표현으로 포맷되고, 그 XML 데이터 표현은 생산성 제품군 애플리케이션 아이템들과의 동기화를 위해 이용된다. XML은 정보를 전달하기 위한 메커니즘으로서 사용될 수 있으므로, 생산성 제품군 애플리케이션에 대하여 간단한 사용자 인터페이스가 구현될 수 있다.

다른 양태에서, 생산성 제품군과 LOB 애플리케이션 간에서 대화들이 상호 동기화된다. 대화는 예를 들어 XAML(extensible application markup language)와 같은 임의의 적절한 언어로 개발될 수 있다. 유리하게도, 대화들 간의 동기화는 완전히 동일한 아이템을 보여주는 다수의 대화가 동시에 오픈될 수 있게 해 준다. 사용자가 한 대화에서 정보를 입력하면, 그 정보는 그것이 보여지고 있는 다른 모든 곳에서 자동으로 변경된다. 예를 들어, 마이크로소프트 아웃룩

구현에서, 동일한 정보가 마이크로소프트 아웃룩

대화(인스펙터)와 작업창 또는 액션창에서 보여질 때, 이들은 동기화되어야 한다. 이러한 양태는 마이크로소프트 아웃룩

내의 다수의 대화가 (편집 중에) 데이터의 동일 인스턴스를 공유할 수 있게 해 주는 메커니즘을 제공한다.

또 다른 양태에서, 클라이언트 머신 상의 생산성 제품군 애플리케이션은 LOB 애플리케이션 내의 새로운 엔터티를 갱신, 삭제 또는 생성하라는 요청을 웹 서버를 통해 보내도록 구성된다. LOB 애플리케이션은 클라이언트 머신으로부터 요청을 추출하며, 그 요청은 XML 데이터 표현으로 제공될 수 있다. 서버 머신은 이메일 내에 임베드된 제어 메시지를 통해, 생산성 제품군 애플리케이션 내의 아이템을 갱신, 삭제 또는 생성하라는 요청을 보내며, 이 아이템은 LOB 엔터티와 관련지어진다. 제어 메시지는 사용자에게는 숨겨지고, LOB 엔터티와 생산성 제품군 애플리케이션 아이템 간의 바인딩, 평가, 충돌 해결, 및 속성 프로모션을 위해 클라이언트 머신에 의해 추출된다.

다른 양태에서, LOB 애플리케이션은 이메일 통신으로 LOB 식별자를 통신할 수 있으며, LOB 식별자는 생산성 제품군 아이템과 LOB 엔터티 간의 이전(previous) 바인딩에 관련지어진다. LOB 식별자는 이메일 통신에서, 이메일 메시지와 관련된 헤더에 임베드될 수 있다. LOB 식별자가 LOB 엔터티를 참조하므로, 이메일 통신은 (임베드되거나 다른 방식으로) LOB 엔터티 자체를 포함할 필요가 없다. 이메일 메시지가 수신되고 나면, 생산성 제품군을 위한 이메일 핸들러는 LOB 식별자를 참조함으로써, 동기화 쉐도우 또는 동기화 데이터 저장소 내의 특정 생산성 제품군 아이템을 식별할 수 있다. 일례에서, 사용자는 이메일 메시지 내의 LOB 식별자에 관련되어져 있는 링크(예를 들어, HTTP, HTTPS, FTP, FTPS, OBA 등과 같은 임의의 수의 형태로 된 URL 링크), 및 임베드된 기타 정보(예를 들어, XML 데이터 표현, 또는 기타 데이터 표현)을 선택함으로써 생산성 제품군 아이템에 액세스할 수 있다. 다른 예에서는, 특정 생산성 제품군 아이템으로의 액세스를 위해 액션창 또는 작업창이 활성화될 수 있다. LOB 식별자는 링크 내에 임베드될 수 있으므로, 생산성 제품군 아이템과 관련지어져 있는 임의의 원하는 액션은 핸들러(예를 들어, URL 핸들러)를 구성함으로써 취해질 수 있다.

제한적인 것도 아니고 모든 경우를 다 설명하는 것도 아닌 실시예들이 첨부 도면들을 참조하여 설명되며, 이 도면들에서 다르게 명시되지 않는 한, 유사한 참조 번호는 도면들 전체에서 유사 부분들을 지칭한다.

도 1은 일 실시예에 따라, 여기에서 설명되는 기술들을 구현하기 위해 사용될 수 있는 예시적인 일반 컴퓨팅 환경을 나타낸 블록도이다.

도 2는 클라이언트 장치가 LOB 시스템과의 동기화를 위해 구성된 예시적인 시스템을 도시한 것이다.

도 3은 새로운 바운드 아이템이 LOB 시스템에 의해 생성될 때, 바운드 아이템과 LOB 엔터티 간의 상관관계가 어떻게 설정되는지를 도시한 것이다.

도 4는 새로운 바운드 아이템이 생산성 제품군 내에 생성될 때, 바운드 아이템과 LOB 엔터티 간의 상관관계가 어떻게 설정되는지를 도시한 것이다.

도 5는 바운드 아이템이 생산성 제품군 내에서 갱신 또는 삭제될 때, 바운드 아이템과 LOB 엔터티 간의 상관관계가 어떻게 변경되는지를 도시한 것이다.

도 6은 바운드 아이템이 LOB 시스템에 의해 갱신 또는 삭제될 때, 바운드 아이템과 LOB 엔터티 간의 상관관계가 어떻게 변경되는지를 도시한 것이다.

도 7은 푸쉬 동작 동안, 클라이언트와 서버 간에서의 예시적인 통신 흐름을 도시한 것이다.

도 8 및 도 9는 다른 예시적인 시스템에서 이용될 수 있는 풀 동작을 도시한 것이다.

도 10은 클라이언트 머신에서 사용되는 생산성 제품군을 위한 동기화 서브시스템의 예시적인 설계를 도시한 것이다.

도 11은 클라이언트와 서버 간의 다른 예시적인 통신 흐름을 도시한 것이다.

도 12는 예시적인 동기화 시스템을 도시한 것이다.

도 13은 예시적인 동기화 방법을 위한 흐름도이다.

이하에서는, 본 명세서의 일부이며 다양한 구현을 위한 구체적인 실시예들을 보여주는 첨부 도면들을 참조하여 다양한 실시예들이 더 상세하게 설명될 것이다. 그러나, 다른 실시예들은 다른 다양한 형태로 구현될 수 있으며, 여기에 개시된 실시예들로 제한되는 것으로 이해되어서는 안되며, 오히려 이 실시예들은 본 명세서가 철저하고 완전해지도록 제공된 것이다. 실시예들은 방법, 시스템 또는 장치로서 구현될 수 있다. 따라서, 실시예들은 하드웨어적인 구현, 완전히 소프트웨어적인 구현, 또는 소프트웨어적 측면과 하드웨어적 측면을 조합한 구현의 형태를 취할 수 있다. 따라서, 이하의 상세한 설명을 제한적인 의미로 받아들여서는 안 된다.

요약하면, 동기화 방법은 생산성 제품군 애플리케이션을 포함하는 클라이언트 머신과, 소비자 관계 관리(CRM) 애플리케이션과 같은 라인-오브-비지니스(LOB) 애플리케이션을 포함하는 서버 머신 간의 동기화를 허용하도록 구성된다. 클라이언트 머신은, LOB 애플리케이션 내에 새로운 엔터티를 갱신, 삭제 또는 생성하라는 요청을 웹 서버 호출을 통해 송신한다. LOB 애플리케이션은 클라이언트 머신으로부터 수신된 요청을 추출하며, 이 요청은 XML 데이터 표현으로 제공될 수 있다. 서버 머신은 이메일에 임베드된 제어 메시지를 통해, 생산성 제품군 애플리케이션 내의 아이템을 갱신, 삭제 또는 생성하라는 요청을 송신하며, 여기에서 아이템은 LOB 엔터티와 관련지어진다. 제어 메시지는 사용자에게 숨겨지고, LOB 엔터티와 생산성 제품군 애플리케이션 아이템 간의 바인딩, 평가, 충돌 해결 및 속성 프로모션을 위해 클라이언트 머신에 의해 추출된다.

다양한 실시예들의 논리 동작들은 (1) 컴퓨팅 시스템 상에서 실행되는 컴퓨터-구현된 단계들의 시퀀스로서, 및/또는 (2) 컴퓨팅 시스템 내의 상호접속된 머신 모듈들로서 구현된다. 구현은 실시예를 구현하는 컴퓨팅 시스템의 성능 조건에 의존하는 선택의 문제이다. 따라서, 여기에 설명되는 실시예를 구성하는 논리 동작들은 다르게는 동작, 단계 또는 모듈이라고도 불리운다.

다양한 모듈, 기술 및 방법은, 일반적으로 하나 이상의 컴퓨터 또는 기타 장치에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어와 관련하여 기술될 것이다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 개체, 컴포넌트, 데이터 구조 등을 포함 한다. 전형적으로, 다양한 프로그램 모듈들의 기능성은 다양한 실시예들에서의 필요에 따라 조합되거나 분산될 수 있다.

이러한 모듈 및 기술들의 구현은 소정 형태의 컴퓨터 판독가능 매체에 저장되거나 그를 통해 전송될 수 있다. 컴퓨터에 의해 액세스 가능한 매체는 그 어떤 것이든지 컴퓨터 판독가능 매체가 될 수 있다. 제한적이지 않은 예를 들면, 컴퓨터 판독가능 매체는 "컴퓨터 저장 매체" 및 "통신 매체"를 포함할 수 있다.

"컴퓨터 저장 매체"는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보를 저장하는 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 컴퓨터에 의해 액세스되고 원하는 정보를 저장할 수 있는 임의의 기타 매체를 포함하지만 이에 제한되는 것은 아니다.

"통신 매체"는 통상적으로 반송파(carrier wave) 또는 기타 전송 메커니즘(transport mechanism)과 같은 피변조 데이터 신호(modulated data signal)에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등을 구현한다. 통신 매체는 임의의 정보 전달 매체도 포함한다. "피변조 데이터 신호"라는 용어는, 신호 내에 정보를 인코딩하도록 그 신호의 특성들 중 하나 이상을 설정 또는 변경시킨 신호를 의미한다. 제한적이지 않은 예로서, 통신 매체는 유선 네트워크 또는 직접 배선 접속(direct-wired connection)과 같은 유선 매체, 그리고 음 향, RF, 적외선, 기타 무선 매체와 같은 무선 매체를 포함한다. 상술된 매체들의 모든 조합이 또한 컴퓨터 판독가능 매체의 영역 안에 포함되는 것으로 한다.

본 명세서 전체에서, "일 실시예" 또는 "실시예"라는 용어가 참조되는데, 이는 설명되는 특정 특징, 구조 또는 특성이 적어도 하나의 실시예에 포함됨을 의미한다. 따라서, 그러한 구문의 사용은 단 하나의 실시예보다 많은 것을 참조할 수 있다. 설명되는 특징, 구조 또는 특성들은 하나 이상의 실시예에서 적절한 방식으로 조합될 수 있다.

그러나, 당업자라면, 이 실시예들이, 구체적인 세부사항들 중 하나 이상을 빼고서, 또는 다른 방법, 자원, 재료 등과 함께 구현될 수 있음을 알 것이다. 한편, 단지 실시예들의 양태가 불명료해지는 것을 막기 위해, 공지된 구조, 자원 또는 동작은 상세하게 도시 또는 설명되지 않았다.

예시적인 컴퓨팅 환경

도 1은 여기에 설명되는 기술을 구현하는 데에 사용될 수 있는 일반적인 컴퓨터 환경(100)을 도시하고 있다. 컴퓨터 환경(100)은 컴퓨팅 환경의 일례에 불과하며, 컴퓨터 및 네트워크 아키텍쳐의 용도 또는 기능성의 범위에 관해 어떤 제한을 암시하고자 하는 것이 아니다. 컴퓨터 환경(100)이 예시적인 컴퓨터 환경(100)에 도시된 컴포넌트들 중 임의의 하나 또는 그 컴포넌트들의 임의의 조합과 관련하여 어떤 의존성 또는 요구사항을 갖는 것으로 해석되어서는 안된다.

컴퓨터 환경(100)은 컴퓨터(102) 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(102)의 컴포넌트들은 하나 이상의 프로세서 또는 처리 장치(104), 시스템 메 모리(106), 및 처리 장치(104)를 비롯한 각종 시스템 컴포넌트들을 시스템 메모리(106)에 연결시키는 시스템 버스(108)를 포함하지만 이에 제한되는 것은 아니다.

시스템 버스(108)는 메모리 버스 또는 메모리 컨트롤러, 주변 장치 버스, 가속 그래픽 포트, 및 각종 버스 아키텍처 중 임의의 것을 이용하는 프로세서 또는 로컬 버스를 비롯한 몇몇 유형의 버스 구조 중 하나 이상의 임의의 것을 나타낼 수 있다. 예로서, 이러한 아키텍처는 ISA(industry standard architecture) 버스, MCA(micro channel architecture) 버스, EISA(Enhanced ISA) 버스, VESA(video electronics standard association) 로컬 버스, 그리고 메자닌 버스(mezzanine bus)로도 알려진 PCI(peripheral component interconnect) 버스, PCI 익스프레스 버스, USB(universal serial bus), SD(secure digital) 버스, 또는 IEEE 1394, 즉 FireWire 버스 등을 포함하지만 이에 제한되는 것은 아니다.

컴퓨터(102)는 다양한 컴퓨터 판독가능 매체를 포함할 수 있다. 컴퓨터(102)에 의해 액세스될 수 있는 어떠한 이용가능한 매체라도 그러한 매체가 될 수 있고, 이동식/비이동식, 휘발성/비휘발성 매체가 거기에 포함된다.

시스템 메모리(106)는 랜덤 액세스 메모리(RAM)(110)와 같은 휘발성 메모리, 및/또는 판독 전용 메모리(ROM)(112) 또는 플래시 RAM과 같은 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 시동 중과 같은 때에, 컴퓨터(102) 내의 구성요소들 사이의 정보 전송을 돕는 기본 루틴을 포함하는 기본 입/출력 시스템(BIOS)(114)은 통상적으로 ROM(112) 또는 플래시 RAM에 저장되어 있다. RAM(110)은 통상적으로 처리 장치(104)가 즉시 액세스할 수 있고 및/또는 현재 동 작시키고 있는 데이터 및/또는 프로그램 모듈을 포함한다.

컴퓨터(102)는 또한 기타 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장매체를 포함한다. 단지 예로서, 도 1은 비이동식·비휘발성 자기 매체(도시되지 않음)에 기록을 하거나 그로부터 판독을 하는 하드 디스크 드라이브(116), 이동식·비휘발성 자기 디스크(120)(예를 들어, 플로피 디스크)에 기록을 하거나 그로부터 판독을 하는 자기 디스크 드라이브(118), CD-ROM, DVD-ROM 또는 기타 광 매체 등의 이동식·비휘발성 광 디스크(124)에 기록을 하거나 그로부터 판독을 하는 광 디스크 드라이브(122)를 포함한다. 하드 디스크 드라이브(116), 자기 디스크 드라이브(118) 및 광 디스크 드라이브(122)는 하나 이상의 데이터 매체 인터페이스(125)에 의해 시스템 버스(108)에 각각 연결된다. 다르게는, 하드 디스크 드라이브(116), 자기 디스크 드라이브(118) 및 광 디스크 드라이브(122)는 하나 이상의 인터페이스(도시되지 않음)에 의해 시스템 버스(108)에 각각 연결된다.

디스크 드라이브들 및 이들과 관련된 컴퓨터 판독가능 매체는, 컴퓨터(102)를 위해, 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터를 저장한다. 하드 디스크(116), 이동식 자기 디스크(120), 및 이동식 광 디스크(124)가 예로서 도시되어 있지만, 자기 카세트 또는 기타 자기 저장 장치, 플래시 메모리 카드, CD-ROM, DVD 또는 기타 광 저장 장치, RAM, ROM, EEPROM 등과 같이, 컴퓨터에 의해 액세스가능한 데이터를 저장할 수 있는 다른 유형의 컴퓨터 판독가능 매체도 예시적인 컴퓨팅 시스템 및 환경을 구현하기 위해 사용될 수 있음을 알 것이다.

예를 들어, 운영 체제(126), 하나 이상의 애플리케이션 프로그램(128), 기타 프로그램 모듈(130), 및 프로그램 데이터(132)를 포함하는 임의의 개수의 프로그램 모듈이 하드 디스크(116), 자기 디스크(120), 광 디스크(124), ROM(112) 및/또는 RAM(110)에 저장될 수 있다. 이러한 운영 체제(126), 하나 이상의 애플리케이션 프로그램(128), 기타 프로그램 모듈(130), 및 프로그램 데이터(132)(또는 이들의 소정 조합)은 분산형 파일 시스템을 지원하는 상주 컴포넌트들의 전부 또는 일부를 구현할 수 있다.

사용자는 키보드(134) 및 포인팅 장치(136)(예를 들어, 마우스) 등의 입력 장치를 통해 명령 및 정보를 컴퓨터(102)에 입력할 수 있다. 다른 입력 장치(138)로는 마이크, 조이스틱, 게임 패드, 위성 안테나, 직렬 포트, 스캐너 등을 포함할 수 있다. 이들 및 기타 입력 장치는 종종 시스템 버스에 결합된 입출력 인터페이스(140)를 통해 처리 장치(104)에 접속되지만, 병렬 포트, 게임 포트 또는 USB(universal serial bus) 등의 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다.

모니터(142) 또는 다른 유형의 디스플레이 장치도 비디오 어댑터(144) 등의 인터페이스를 통해 시스템 버스(108)에 접속될 수 있다. 모니터(142) 외에, 기타 주변 출력 장치는 스피커(도시되지 않음) 및 프린터(146)와 같은 구성요소들을 포함할 수 있고, 이들은 입출력 인터페이스(140)를 통해 컴퓨터(102)에 접속될 수 있다.

컴퓨터(102)는 원격 컴퓨팅 장치(148)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 사용하여 네트워크화된 환경에서 동작할 수 있다. 예를 들어, 원격 컴퓨팅 장치(148)는 PC, 휴대형 컴퓨터, 서버, 라우터, 네트워크 컴퓨터, 피어 장치 또는 기타 통상의 네트워크 노드 등일 수 있다. 원격 컴퓨팅 장치(148)는 통상적으로 컴퓨터(102)와 관련하여 상술된 구성요소들 및 특징들의 대부분 또는 그 전부를 포함하는 휴대형 컴퓨터로서 도시되어 있다. 다르게는, 컴퓨터(102)는 네트워크화되지 않은 환경에서도 동작할 수 있다.

컴퓨터(102)와 원격 컴퓨터(148) 간의 논리적 접속은 LAN(150) 및 일반 WAN(152)으로서 도시되어 있다. 이러한 네트워킹 환경은 사무실, 전사적 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷, 및 인터넷에서 일반적인 것이다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(102)는 네트워크 인터페이스 또는 어댑터(154)를 통해 LAN(150)에 접속된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(102)는 통상적으로 WAN(152)을 통해 통신을 설정하기 위한 모뎀(156) 또는 기타 수단을 포함한다. 컴퓨터(102)에 대해 내장형 또는 외장형일 수 있는 모뎀(156)은 입출력 인터페이스(140) 또는 기타 적절한 메커니즘을 통해 시스템 버스(108)에 접속된다. 도시된 네트워크 접속은 예시적인 것이며 컴퓨터(102)와 컴퓨터(148) 사이에 적어도 하나의 통신 링크를 설정하는 기타 수단이 사용될 수 있다는 것을 이해할 것이다.

컴퓨팅 환경(100)으로 도시된 것과 같은 네트워크화된 환경에서, 컴퓨터(102)와 관련하여 도시된 프로그램 모듈들 또는 그 일부는 원격 메모리 저장 장 치 내에 저장될 수 있다. 예를 들어, 원격 애플리케이션 프로그램(158)은 원격 컴퓨터(148)의 메모리 장치에 상주한다. 설명을 위해, 애플리케이션 또는 프로그램, 및 운영 체제와 같은 기타 실행가능 프로그램 컴포넌트들은 여기에서 별개의 블록들로 도시되지만, 그러한 프로그램 및 컴포넌트들은 다양한 시간들에서 컴퓨팅 장치(102)의 다양한 저장 컴포넌트들에 존재하며, 컴퓨터의 적어도 하나의 데이터 프로세서에 의해 실행된다는 점을 알 것이다.

이하는, 마이크로소프트 아웃룩

정보를 LOB 시스템과 동기화하는 것을 지원하기 위해 마이크로소프트 아웃룩

에 구현되는 예시적인 인터페이스 및 구성에 관한 설명이다. 다른 실시예들에서는, 마이크로소프트 아웃룩

을 대신하여, 또는 그와 더불어, 다양한 생산성 제품군 애플리케이션들이 사용될 수 있다.

예시적인 구성

도 2는 클라이언트 장치가 LOB 시스템과의 동기화를 위해 구성된 예시적인 시스템을 도시한 것이다. 도면에 나타나 있는 바와 같이, 마이크로소프트 아웃룩

과 같은 생산성 제품군(220)이 클라이언트 장치 상에서 이용가능하다. 마이크로소프트 아웃룩

은 일정표, 약속, 연락처, 이메일 등과 같은 하나 이상의 아이템을 유지한다. 각각의 생산성 제품군 아이템(230)은 그 생산성 제품군에 관련된 표준 속성들의 집합(231), 및 LOB 시스템에 관련된 하나 이상의 데이터 아이템(LOB 데이터(232))을 포함한다. 데이터 및 속성들을 아이템에 바인딩하는 데에 필요한 것 등의 추가의 시스템 속성들도 아이템에 관련지어진다(예를 들어, 시스템 속성(233) 내의 바인딩 정보). 외부의 아이템(240)에는, 동기화 데이터(241)를 캐싱하는 데에 이용되는 데이터 저장소와, 동기화에 관련된 시스템 속성들의 집합(242)이 존재한다.

한명의 사용자가 클라이언트 소프트웨어를 다수의 머신에 설치할 수 있어야 한다. 그러나, 1차 머신만이 LOB 시스템에 동기화할 수 있다. 다른 머신들은 2차 머신으로 취급된다. LOB 시스템은 1차 머신에 동기하여 비지니스 응답을 리턴한다. LOB 시스템은 생성, 갱신 또는 삭제 커맨드와 같은, LOB 시스템이 발행한 "커맨드"를 1차 머신에 제공하기 위하여, 포맷터와 인터페이스한다. 어느 시간에서든, 하나의 1차 머신만이 존재할 수 있다. 자기 소유의 생산성 제품군(270) 사본을 포함하는 2차 머신(예를 들어, 클라이언트(260))은 바운드 아이템들(예를 들어, 속성(281-283)을 포함하는 생산성 아이템(280))의 비지니스 및 동기화 상태를 비롯하여, 1차 머신에서 이용가능한 정보의 사본을 포함한다. 설명되는 시스템은 서버로부터의 비지니스 상태 응답을 2차 클라이언트들에게 배포하기 위하여, 서버 상에 동기화 캐시를 유지하도록 구성될 수 있다.

생산성 제품군 아이템(예를 들어, 아이템(230))은 시스템이 바운드 아이템들을 인식하고 렌더링하기에 충분한 정보를 보유하여야 한다. LOB 데이터(프로모션된 속성들을 포함)는 생산성 제품군 아이템과 관련지어지고 저장되어야 한다. 생산성 제품군 아이템 내에 저장된 시스템 정보는 정적(static)이어야 한다. 즉, "인공적인(artificial)" 동기화 충돌의 도입을 막기 위해, 일단 설정되고 나면 변경되어서는 안 된다. 시스템은 생산성 제품군 아이템들 외부의 동기화에 관련된 동 기화 데이터 및 시스템 속성들을 저장해야만 한다. 어느 머신이 1차 머신인지를 지정하기 위하여, 속성 내에 숨겨진 토큰이 사용될 수 있다. 일부 경우들에서는, 재난 복구 등에서 1차 머신이 변경될 수 있도록, 토큰 캔이 전달될 수 있다.

도 3은 새로운 바운드 아이템이 LOB 시스템에 의해 생성될 때, 바운드 아이템(330)과 LOB 엔터티(370) 간의 상관관계가 어떻게 설정되는지를 도시한 것이다. 첫번째로, 스텝 1(391)로 표시된 바와 같이, LOB 엔터티(370)가 LOB 시스템(360) 내에서 생성되는데, 이 LOB 엔터티(370)는 식별자(LOBID(372))를 포함한다. 스텝 2로 표시된 바와 같이, LOB 시스템(360)은 LOBID(372)에 의해 식별되는 LOB 엔터티를 바운드 아이템으로서 생성하라는 요청(392)을 서버(340)에게 보낸다. 서버(340)는 요청(392)을 수신하고, 그 요청(392)에 포맷터(350)를 적용하여, 바인딩을 생성하기 위한 커맨드(394)가 1차 클라이언트(310)에 보내지게 한다. 클라이언트(310) 상의 생산성 제품군(예를 들어, 아웃룩)을 위한 동기화 서브시스템(320)은, 다음 동기화 동안 커맨드(394)를 수신하고, 스텝 5로 표시된 바와 같이 아웃룩 아이템(330)으로의 바인딩을 생성한다. 바운드 아이템은 그에 할당된 고유한 식별자(BIID(332))를 가지며, LOBID(334)에 의해 식별되는 LOB 엔터티에 관련지어진다.

도 4는 새로운 바운드 아이템이 생산성 제품군 내에서 생성될 때, 바운드 아이템과 LOB 엔터티 간의 상관관계가 어떻게 설정되는지를 도시한 것이다. 먼저, 스텝 1(491)로 표시된 바와 같이, 아이템(430)이 생산성 제품군 내에서 생성된다. 다음으로, 스텝 2(492)로 표시된 바와 같이, 생산성 제품군(예를 들어, 아웃룩) 내의 동기화 서브시스템(420)은 바인딩 생성 커맨드를 LOB 시스템(460)에 보낸다. LOB 시스템(460)은 클라이언트와의 다음 동기화 동안 바인딩 생성 커맨드를 수신하고, 스텝 3(493)으로 표시된 바와 같이 LOBID(472)에 의해 식별되는 LOB 엔터티(470)를 생성한다. LOB 시스템(460)은 선택적으로 스텝 4에서 LOBID(472)를 클라이언트(410)에게 보낼 수 있으며, 그러면, 클라이언트(410)는 스텝 5(495)로 표시된 바와 같이 그 LOBID(434)를 바운드 아이템(430)과 관련지을 수 있다. 일부 경우들에서는, LOBID(472)가 생산성 제품군에 보내지지 않는다.

도 5는 바운드 아이템이 생산성 제품군 내에서 갱신 또는 삭제될 때, 바운드 아이템과 LOB 엔터티 간의 상관관계가 어떻게 변경되는지를 도시한 것이다. 우선, 스텝 1(591)로 표시된 바와 같이, 생산성 제품군 내에서 아이템(530)이 변경된다. 다음으로, 스텝 2(592)로 표시된 바와 같이, 생산성 제품군(예를 들어, 아웃룩) 내의 동기화 서브시스템(520)은 (예를 들어, 웹 서비스 호출을 통해) 갱신 또는 삭제를 LOB 시스템(560)에 보낸다. LOB 시스템(560)은 클라이언트(510)와의 다음 동기화 동안 갱신/삭제 바인딩 커맨드를 수신하고, 스텝 3(593)으로 표시된 바와 같이, LOBID(572)에 의해 식별되는 LOB 엔터티(570)를 수정 또는 삭제한다. LOBID(534)가 생산성 제품군에 의해 알려지지 않은 일부 경우들에서, LOB 시스템(560)은 어느 LOB 엔터티(570)를 수정 또는 삭제할지를 결정하기 위해, 바인딩 식별자(BIID(532))를 참조한다.

도 6은 바운드 아이템이 LOB 시스템에 의해 갱신 또는 삭제될 때, 바운드 아이템과 LOB 엔터티 간의 상관관계가 어떻게 변경되는지를 도시한 도면이다. 우선, 스텝 1(691)로 표시된 바와 같이, LOB 엔터티(670)가 LOB 시스템(660) 내에서 수정 또는 삭제된다. LOB 시스템(660)은 서버(640)로의 요청(692) 내의 LOBID(672) 및 BIID 중 적어도 하나에 의해 식별되는 LOB 엔터티를 갱신 또는 삭제하라는 요청(692)을 서버(640)에 보낸다. 서버(640)는 요청(692)을 수신하고 그 요청(692)에 포맷터(650)를 적용하여, 스텝 4로 표시된 바와 같이, 바운드 아이템을 변경 또는 삭제하라는 커맨드 또는 제어 메시지(694)가 보내지게 한다. 1차 클라이언트(610) 상의 생산상 제품군(예를 들어, 아웃룩)을 위한 동기화 서브시스템(620)은 다음 동기화 동안 커맨드를 수신하고, 스텝 5(695)로 표시된 바와 같이 적절한 바운드 아이템(630)으로의 바인딩(예를 들어, BIID(532) 및 LOBID(634))을 수정 또는 삭제한다.

위에 설명된 동기화 서브시스템은 기업 네트워크의 내부 또는 외부에 있을 수 있는 클라이언트 머신들에 배치된다. 마이크로소프트 익스체인지 서버와 같은 서버 애플리케이션을 통한 HTTP 타입 원격 동기화 접속과 같이, 기업 네트워크로의 가상 사설 네트워크(VPN) 접속도 예상된다. 생산성 제품군이 실행중인 한, LOB 동기화는 클라이언트 장치 상에서 백그라운드 쓰레드로서 동작할 수 있다. 생산성 제품군에 가해진 변경은 임의의 이용가능한 RPC 메커니즘(예를 들어, 기업 네트워크, VPN, HTTP 등)을 통해 LOB 시스템에 서브밋되는 한편, LOB 시스템에 가해진 변경은 기업 네트워크 상에서만 이루어질 것으로 예상된다. 파일 동기화는 그러한 목적을 위해 .NET API를 노출하도록 구성될 수 있는 마이크로소프트 액티브 디렉토리와 같은 임의의 적절한 방식으로 기업 네트워크 내에서 다루어질 수 있다.

예시적인 동기화 인터페이스 정의

각각의 바운드 아이템 타입에 대하여, 동기화 시스템은 발생하는 변경(생성/갱신/삭제)에 의존하는 다른 액션을 실행할 것이다. 이에 더하여, 질의 제어 메시지를 처리한 것의 결과로서, "질의" 액션이 인보크될 수 있다. 이하에서는, 이러한 액션들 각각에 전달되고 그들로부터 리턴되어야 하는 정보를 상술한다.

Create는 클라이언트측의 바운드 아이템 생성이 처리될 때마다, 시스템에 의해 인보크된다. Create를 위한 매개변수로는 BoundItemID, NewItemData 및 CultureName이 포함된다. Create를 위한 리턴값으로는 LOBID, BusinessStatus 및 Description이 포함된다. BoundItemID는 바운드 아이템에 대해 클라이언트가 생성한 고유 식별자 문자열이다. NewItemData는 바운드 아이템을 위한 LOB 데이터가 적절하게 제공되도록, LOB 시스템을 위한 스키마에 의해 정의되는 XML 문서이다. CultureName은 Create 호출로부터 유도된 비지니스 상태, 설명 및 임의의 기타 메시지를 위해 사용되어야 하는 컬쳐의 이름이다. LOBID는 아이템 타입에 대한 고유 식별자로서 LOB-생성된 문자열이다(예를 들어, ContactID는 연락처를 고유하게 식별함). BusinessStatus는 Create의 결과로서 바운드 아이템에 할당되어야 하는 새로운 비지니스 상태의 약식 명칭에 대응하는 문자열이다. 이것은 LOB 시스템에 의해 제공되는 임의의 값이며, 동기화는 이러한 값의 내용에 관하여 어떠한 가정도 하지 않는다. 이 값은 동일 상태에 있는 아이템들을 필터링하는 데에 사용된다는 개념이다. Description은 BusinessStatus에 관한 설명인 선택적인 문자열이다. 이것은 바운드 아이템 정보의 일부일 것이므로, 필요한 경우에는 UI 상의 노출된 Description일 수 있다.

Update는 클라이언트측의 바운드 아이템 갱신이 처리될 때마다 시스템에 의해 인보크된다. Update를 위한 매개변수들로는 BoundItemID, RequestID, LOBID, PreviousItemData, NewItemData 및 CultureName이 포함된다. Update를 위한 리턴값은 BusinessStatus 및 Description을 포함한다. RequestID는 LOB 시스템에 중복을 식별할 수 있게 하기 위한, 갱신 메시지에 대한 고유 식별자이다. 중복 갱신 메시지가 보내지는 경우에는, 반드시 동일한 RequestID가 보내져야 한다. PreviousItemData는 마지막 동기화된 상태의 바운드 아이템으로부터의 모든 LOB 데이터에 대응하는 XML 문서이다.

Delete는 클라이언트측의 바운드 아이템 삭제가 처리될 때마다 시스템에 의해 인보크된다. Delete를 위한 매개변수들로는 BoundItemID, LOBID, PreviousItemData, 및 CultureName이 포함된다. Delete를 위한 리턴값은 BusinessStatus 및 Description을 포함한다.

QueryResult는 질의 제어 메시지가 처리될 때마다 시스템에 의해 인보크된다. QueryResult를 위한 매개변수로는, 특정 타입의 현존하는 모든 바운드 아이템에 대하여, 바운드 아이템 ID 및 대응 LOBID의 목록을 포함하는 XML 문서이다. QueryResult를 위한 리턴값은 없다.

예시적인 제어 메시지 정의

이 섹션은 각각의 제어 메시지 타입에서 예상되는 정보를 상술한다. 제어 메시지는 생성 제어 메시지, 갱신 제어 메시지, 삭제 제어 메시지 및 질의 제어 메시지를 포함한다.

생성 제어 메시지는 BoundItemID, LOBID, BoundItemType, 및 LOBData를 위한 필드를 포함한다. 갱신 제어 메시지는 LOBID, BoundItemType, 및 LOBData를 위한 필드를 포함한다. 삭제 제어 메시지는 LOBID 및 BoundItemType을 위한 필드를 포함한다. 질의 제어 메시지는 BoundItemType을 위한 필드를 포함한다.

BoundItemID는 새로운 바운드 아이템에 할당될 고유 식별자이다. BoundItemID는 이하에 더 상세하게 설명되는 바와 같이 포맷터에 의해 생성된다. BoundItemType은 솔루션 및 버전을 포함하는 바운드 아이템 타입의 정규화된 이름(fully qualified name)에 대응하는 문자열이다. BoundItemType은 생산성 제품군 아이템에 바인딩될 속성들과, 생산성 제품군 아이템이 LOB 엔터티와 어떻게 동기화될지를 기술하는, 대응하는 바운드 아이템 정의를 찾기 위해 시스템에 의해 이용될 수 있다. 앞에서 설명한 바와 같이, LOBID는 LOB 시스템에 의해 바운드 아이템에 할당되는 고유 식별자이고, LOBData는 바운드 아이템에 대한 LOB 데이터의 전부를 포함하는 XML 문서이다.

예시적인 동기화 시스템

시스템은 동기화를 인보크하고 검출하기 위해 생산성 제품군(예를 들어, 마이크로소프트 아웃룩)으로부터의 이벤트들에 의존하지 않도록 구성될 수 있다. 변경(생성/갱신/삭제)을 검출하기 위하여, 시스템은 생산성 제품군, 동기화 데이터 저장소(SDS) 및 LOB 시스템으로부터 직접 획득한 정보 간의 3-웨이 동기화 방식을 이용한다. 데이터는 시스템 내의 다수의 엔트리 포인트들로부터 변경될 수 있다. 정보는 웹 액세스, 모바일 장치 및 다른 클라이언트 머신을 포함하는 다양한 많은 장소에서 변경될 수 있다. 변경들은 결국에는 (예를 들어, 아웃룩/익스체인지 동기화를 통해) 1차 클라이언트 머신에 동기화될 것이다.

LOB 시스템은 고유 RequestId에 기초하여 중복 요청을 검출하고 다룰 수 있다. LOB 시스템과의 아웃바운드(클라이언트-대-서버) 통신은 웹 서비스를 통해 이루어질 수 있는 한편, 인바운드(서버-대-클라이언트) 메시지는 서버 애플리케이션(예를 들어, 마이크로소프트 익스체인지)을 통해 클라이언트들로 흐를 것이다.

또한, 동일한 바운드된 아이템이 LOB 시스템과 생산성 제품군에 의해 변경될 때, 충돌 검출이 시스템에 의해 다루어진다. 동일한 바운드 아이템이 사용자와 LOB 시스템에 의해 갱신된 것을 시스템이 검출하면, 충돌이 식별될 것이고, 충돌 해결이 그것을 적절하게 처리할 것이다.

LOB 시스템은 동기 웹 서비스 호출이 수신된 때, 즉각적인 비지니스 응답을 제공하는 것을 지원한다. LOB 시스템은 생성, 갱신, 삭제 또는 질의 커맨드의 성공적인 처리에 관한 확인 또는 오류 통지를 수신할 필요가 없다.

이 섹션은 LOB 시스템과 클라이언트 간의 하이레벨 통신 흐름을 설명한다. 아래의 설명들은 지원되는 가능한 통신 흐름의 개관을 제공한다.

도 7은 푸쉬 동작 동안의 클라이언트와 서버 간에서의 예시적인 통신 흐름을 도시한 것이다. 이하에 설명되는 바와 같이, 푸쉬 동작은 클라이언트(710) 또는 서버(750)에 의해 개시될 수 있다.

스텝 1은 클라이언트(710)가 개시하는 흐름을 나타내는데, 여기에서 변경 검출 프로세스가 클라이언트 상의 시스템에 의해 실행된다. 스텝 1에서, 시스템 내 의 동기화 논리(730)는 새로운 바운드 아이템, 갱신된 바운드 아이템, 및 삭제된 바운드 아이템을 식별하고, LOB 시스템에 서브밋될 필요가 있는 변경 요청들의 가상 리스트를 생성한다(791). 가상 리스트는 가상 아웃바운드 큐(VOQ(712))와 같은 큐 내에 제공될 수 있다. 리스트는, 스텝 2에서 LOB 시스템(예를 들어, 서버(750))과의 접속(예를 들어, 웹 서비스 호출(792))이 있을 때, 처리된다. 스텝 2에서 LOB 시스템과의 접속이 확인되지 않으면, 리스트는 다음번에 변경 검출 프로세스가 실행될 때 재시도된다.

요청들의 가상 리스트를 생성할 때, 시스템은 충돌을 검출하고 적절하게 해결하기 위하여, 새롭게 들어오는 제어 메시지(제어 메시지 리스트(714)에 있는, LOB 시스템으로부터 온 생성, 갱신, 삭제 통지)도 고려한다. 동일한 아이템이 생산성 제품군과 LOB 시스템에서 수정될 때, 또는 한쪽은 아이템을 갱신하려고 하는데 다른 한쪽은 그 아이템을 삭제하려고 하고 있을 때, 동기화 논리(730)는 충돌을 검출한다. 충돌을 발생시키지 않는 각각의 검출된 변경(생성, 갱신, 삭제)에 대해서, 시스템은 동기화 인터페이스 정의에 설명된 것과 같이 웹 서비스를 호출함으로써(792) LOB 시스템(예를 들어, 서버(750))에 요청을 서브밋한다.

또한, LOB 시스템(예를 들어, LOB 애플리케이션(760)을 갖는 서버(750))은, 관련 액션이 LOB 시스템에서 발생한 때에, 클라이언트(710) 상에서 생성, 갱신, 삭제 또는 질의 액션의 실행을 트리거할 수 있다. 스텝 3에서, LOB 시스템은 포맷터(770)에 의해 노출된 웹 서비스를 호출한다(793). 생성 요청의 경우, 포맷터(770)는 새로운 바운드 아이템을 식별하기 위하여 시스템에 의해 사용될 고유 ID 를 리턴한다. 웹 서비스 호출의 일부로서 보내지는 정보의 상세내용에 대해서는, 본 명세서에서 논의된 동기화 인터페이스 정의 섹션을 참고하기 바란다.

스텝 4에서, 포맷터(770)는 제어 메시지(794)를 생성하고, 그것을 생산성 제품군에 관련지어진 특정 우편함(예를 들어, 아웃룩 우편함)으로 보낸다. 제어 메시지(794)는 전용 계정으로부터 보내진다. 제어 메시지가 (예를 들어, 마이크로소프트 익스체인지 서버, 또는 소정의 다른 이메일 및 디렉토리 서버(780)에 의해) 대상 우편함에 배달될 때, 그 제어 메시지는 우연히 삭제되는 것이 방지되도록 하는 서버 규칙에 의해 히든 폴더에 자동으로 이동된다. 서버측 규칙은 클라이언트에 의해 유지(생성 및 재생성)된다 (상세내용에 대해서는 아웃룩 애드인 명세를 참고하기 바란다).

스텝 5에서, 제어 메시지(795)는 생산성 제품군 애플리케이션(720)용으로 포맷된 유형의 이메일 메커니즘을 통해 클라이언트(710)에 배달된다. 스텝 6에서, 클라이언트(710)는 필요에 따라 바운드 아이템을 생성, 갱신 및 삭제하는 동기화 프로세스를 실행함으로써 제어 메시지(795)를 처리한다. 또한, 시스템은 제어 메시지를 처리할 때, 충돌을 검출하고 적절하게 플래그 표시하기 위해 LOB 시스템에 보내질 필요가 있는 로컬 변경(바운드 아이템의 생성, 갱신, 삭제)을 고려한다.

도 8 및 도 9는, 또 다른 예시적인 시스템에서 이용될 수 있는 풀 동작을 도시한 것으로, 여기에서는 동기화 웹 서비스에 의해, 또는 LOB 시스템에 의해 모방된 넛지(nudge)에 의해 풀 동작이 개시될 수 있다.

동기화 논리

바운드 아이템은 사용자가 그것을 동기화(예를 들어, 웹 서비스 인터페이스)를 통해 직접적으로 또는 간접적으로 변경하는 것으로 인해 변경될 수 있다. 아이템들을 비교하고, 클라이언트와 LOB 시스템 간의 차이를 결정하여, 한쪽의 변경이 다른쪽에 전파되어야 할지를 판정하는 프로세스가 필요하다.

변경은 4가지 방식 중 하나로 발생할 수 있다. 첫째로, 사용자가 생산성 제품군 내에서 바운드 아이템을 변경할 수 있다. 시스템은 변경을 검출하고, 변경 요청을 LOB 시스템에 자동으로 서브밋한다. 두번째로, 변경은 다른 클라이언트를 통해 이루어질 수 있고, 이것은 동기화를 통해 생산성 제품군 클라이언트와, LOB 시스템 둘다에 영향을 미칠 수 있다. 생산성 제품군 및 LOB 시스템에 대한 변경은 임의의 지연을 갖고 임의의 순서로 발생할 수 있다. 셋째로, 변경은 스마트폰, 웹 액세스 또는 임의의 다른 수단을 통해 이루어질 수 있으며, 서버를 통해 생산성 제품군에 동기화된다. 이러한 변경은 동기화 프로세스를 통해 발견될 필요가 있다. 넷째로, 변경은 LOB 시스템 자체 내에서 이루어질 수 있다. 각각의 유형의 변경이 동기화 프로세스에 의해 고려되어야 한다.

로컬 동기화 데이터 저장소(SDS)는 원래의 버전을 저장한다. SDS는 생산성 제품군과 LOB 시스템 간의 델타(delta)에 동기화하고, 후속하여 그것을 추적하는 데에 사용된다. 그러면, 델타는 LOB 시스템으로의 모든 서비스 요청을 포함하는 가상 요청 큐에 추가된다. 변경이 LOB 시스템에 전파될 필요가 있을 때, 갱신 절차가 결정된다. 동기화 논리는 요청을 만들고, 접속이 존재할 때 그 요청을 LOB 시스템에 서브밋한다. 생산성 제품군을 갱신할 때, 동기화 논리는 LOB 시스템의 정보를 사용하여 아웃룩을 갱신한 후 SDS를 갱신한다.

대부분의 바운드 아이템은 2개의 장소에 존재한다. 예를 들어, 아이템은 생산성 제품군 내에, 그리고 LOB 시스템 내에 있다. 각 사본이 다른 사본에는 존재하지 않는 추가의 데이터를 포함한다고 가정하자. 동기화 시스템은, 바운드 아이템의 BoundData 속성 내에 저장된 속성들의 공유된 부분집합과, 바운드 아이템의 존재를 동기화할 책임이 있다(예를 들어, 아이템은 동기화의 결과로서 생성 또는 파괴될 수 있음). 동기화 시스템은 LOB 시스템이 항상 옳다는 하나의 진실 정의를 가정한다. 동시에, 동기화 시스템은 LOB 엔터티로의 어떠한 직접적인 액세스도 갖지 않으며, 따라서 LOB 시스템 내에 저장되어 있다고 자신이 가정하는 것의 별도 사본을 SDS 내에 보유한다.

동기화 프로세스는 수개의 개별 위상들로 분할될 수 있다. 스윕핑 위상(sweeping phase)에서, 우편함 내의 모든 바운드 아이템이 SDS에 대조된다. 우편함과 SDS 간의 참조 무결성(referential integrity)의 불일치를 검출하고 즉시 수정한다. 수정된 아이템이 검출되고, 추가의 처리를 위해 마킹된다. 그 다음, 삭제된 아이템이 검출되고 동기화기에 전달되어, 적절한 삭제 요청이 LOB 시스템에 보내질 수 있게 된다. 일부 구현예들에서, 위에 설명된 동기화 프로세스의 다양한 위상들은 하나의 통합된 프로세스로 병합될 수 있으며, 그러한 경우에서 다양한 기능들(예를 들어, 바인딩, 스윕핑, 해결 등)은 단순한 알고리즘으로 조합될 수 있다. 단순한 알고리즘은 실행 속도를 향상시키거나, 또는 소정의 다른 효율을 개선할 것이다 (예를 들어, 메모리/디스크 사용량 감소, 중복 제거 등).

식별된 임의의 제어 메시지가 제2 위상 동안 처리된다. 다음으로, 수정된 것으로 마킹된 모든 아이템에 대해 속성 프로모션이 발생한다. 그에 따라 갱신된 XML 데이터 표현은 SDS 사본과 비교되고, 동기화기는 통지를 받는다. 동기화기는 백그라운드 쓰레드로 실행되고, 이 실시예에서는 SDS 사본을 이용한다. 동기화기는 생성, 갱신 및 삭제 요청을 서브밋하는 것과, 질의를 처리하는 것을 책임진다.

SDS 사본은 위에서 언급된 것과 동일한 속성을 포함한다. 정상적인 상황에서, EntryId, BounditemId, BoundItemType 및 LOBID는 생산성 제품군 아이템과 SDS 사본에 대해 동일하다. 생산성 제품군 아이템과 SDS 사본 간의 임의의 차이는 LOB 엔터티를 갱신하라는 요청으로 해석된다. 그렇지 않으면, 참조 무결성이 손상되고, 생산성 제품군 아이템은 더 조사되어야 한다. 임의의 차이의 주된 원인은, 아이템이 사용자에 의해 생성되고, 그 아이템에 대한 SDS 사본은 아직 존재하지 않지만 BoundData 속성은 읽을 수 있고, 그 아이템이 사용자에 의해 복사, 이동 또는 삭제되고, EntryId와 BoundItemId 간의 맵핑이 손상된 것; 하나의 SDS 사본에 관련된 아이템이 없거나 하나이거나 더 많을 수 있고, BoundData 속성을 읽을 수 있으며, 갱신된 모임 요청 또는 작업 요청이 사용자에 의해 수신된 것; 대응하는 약속 또는 작업(바운드 아이템)을 손상시킨 것이 있다. 아이템의 EntryId는 보존되어 있지만, 대응하는 BoundData 속성은 더 이상 읽을 수가 없다. 외계의 바운드 아이템의 사본이 다른 사용자에 의해 수신되어 있다. BoundData 속성은 읽혀질 수 없고, SDS 내에 그 아이템에 대한 대응 사본이 존재하지 않는다. 사본 또는 바운드 아이템은 다른 사용자에게 보내졌고, 그 다음 다시 되돌려 보내졌다. 이것은 앞의 가능성들의 변형예이며, 특수한 경우로 인식되어서는 안 된다. 데이터 손상이 발생할 수 있었다.

BoundItemID는 고유하며(1차 키), BoundItemType + LOBID의 조합 또한 고유하다(2차 키)는 고유의 가정이 있다. 이러한 제약들은 SDS 데이터베이스 내에서 반드시 강제되어야 한다. 물론, 우편함 내에서는 EntryID도 고유하다. BoundData 속성을 읽을 수 없거나 내부에 저장된 중복 속성이 아웃룩 아이템에 대한 동일 속성(BoundItemId, BoundItemType 및 LOBID)과 일치하지 않는 임의의 아이템은 손상된 것으로 가정된다. 일반적인 규칙으로서, 이와 같이 손상된 아이템은 자동으로 언바인딩(unbinding)된다. 임의의 중복 아이템이 검출되고(2개 이상의 아웃룩 아이템이 동일 BoundItemId를 갖는 경우), 새로운 바운드 아이템으로 변환되거나 언바인딩된다. 원본은 SDS 사본과 일치한다 (이동의 경우에서는, 하나의 사본을 고른다).

통신 흐름

도 10은 클라이언트 상의 생산성 제품군과 LOB 시스템 간의 다른 예시적인 통신 흐름을 도시한 것이다. LOB 시스템(1070)은 제어 메시지(생성, 갱신 및 삭제)를 통해 바운드 아이템에 대한 갱신을 시작할 수 있다. 포맷터(1080) 서비스는 LOB 시스템(1070)에 의해 요청된 대로 제어 메시지를 생성한다. 제어 메시지는 우편함(1010) 내의 이메일 메시지를 통해 생산성 제품군에 전달된다. 서버측 규칙은 제어 메시지를 지정된 (히든) 폴더(예를 들어, 제어 메시지 폴더(1020))로 이동시키고, 제어 메시지 프로세서(1030)는 그 폴더로부터 제어 메시지를 취한다. 생성, 갱신 및 삭제 요청은 즉시 처리되는 한편, 질의 요청은 SDS(1050) 내에 큐잉되고 동기화기(1060)에 의해 처리된다. 바인더/스윕퍼/리졸버(1040) 서비스(또는 구현에 따라서는 서비스들)는, 우편함 내의 모든 바운드 아이템을 SDS(1050)와 대조하고, 바운드 아이템들 내의 불일치/변경을 식별하도록 구성된다.

매우 흔한 것은 아니지만 그래도 중요한 시나리오는, LOB 시스템이 주어진 사용자에 대해 모든 바운드 아이템을 재생성하는 것에 관련된다. 이것은 우편함을 초기의 바운드 아이템으로 채우기 위해 사용될 수 있고, 또한 일부 아이템들이 상실되었거나 손상되었을 때의 재앙 복구의 일부로서 사용될 수 있다. 이러한 시나리오의 변형예는 기존의 바운드 아이템을 새로운 바인드 정의(스키마)로 업그레이드하는 데에 사용될 수 있다. 이것은 바운드 아이템의 현재 상태에 관한 정보를 요청할 수 있다 (질의). 다른 흔한 사용은 사용자의 우편함(1010)에 정기적인 메일 메시지를 보내는 것이다. 이 경우, 동기화 시스템은 관여하지 않는다.

발신자의 신분은 인가되지 않은 (또는 스푸핑된) 제어 메시지들로부터 유효한 제어 메시지를 구별해내기 위해 사용된다. 제어 메시지 내의 정보는 그 프라이버시를 보호하기 위해 암호화될 수 있다.

1차 머신은 제어 메시지를 처리하고, 속성을 프로모션하고, 충돌을 해결하고, 갱신을 LOB에 서브밋할 책임이 있다. 1차 머신은 SDS와 우편함을 동기화 상태로 유지한다. 2차 머신은 UI를 통해 바운드 아이템을 갱신하는 데에 이용될 수 있다. 2차 머신도 동기화를 이용하여 자기 자신의 SDS 데이터베이스를 구축하지만, 중요한 차이가 있다. 2차 머신은 제어 메시지를 처리하지 않으며, 동기화 동안 속 성 프로모션을 행하지도 않고, 변경을 LOB 시스템에 서브밋하지도 않는다. 2차 머신은 SDS를 구축할 때, 우편함 내의 데이터가 올바르다고 가정한다. 참조 무결성 문제로 인해 SDS의 갱신에 실패하면, 결국에는 1차 머신이 충돌을 해결할 것이고 또한 그 해결이 2차 머신으로 전파될 것으로 가정되기 때문에, 그 실패는 무시된다. 이러한 규칙들의 중요한 결과는, 2차 머신 상의 SDS가 임의의 진행 중인 변화의 완전한 상태를 포함하지 않으며, 따라서 1차 머신으로 프로모션될 수 없다는 것이다.

서버는 서버로부터 다양한 2차 클라이언트 머신들로 비지니스 상태 응답을 배포할 목적으로, 동기화 캐시(예를 들어, SDS와 유사하지만 바운드 데이터 정보를 배제함)를 유지하도록 구성될 수 있다. 주기적으로, 서버는 변경들을 2차 클라이언트로 푸쉬하여, 2차 클라이언트가 관련 SDS 데이터의 최신 사본을 갖게 한다.

동기화 서브시스템

동기화 서브시스템이 도 11에 도시되어 있으며, 주요 컴포넌트로서, 제어기(1102), 바운드 아이템 관리자(1106), 바운드 아이템 랩퍼(wrapper), 스윕퍼(1112), 리졸버(1109), 제어 메시지 프로세서(1110), 데이터 제공자(1107) 및 동기화기(1105)를 갖는다.

제어기(1102)는 동기화 프로세스를 제어하는 데에 사용되는 공용 컴포넌트이다.

바운드 아이템 관리자(1106)는 바운드 아이템을 생성하고/거나 직접 액세스하는 데에 사용되는 공용 컴포넌트이다. 바운드 아이템 랩퍼는 생산성 제품군 아 이템을 바운드 아이템으로서 캡슐화하거나 아이템을 언바인딩하는 공용 랩퍼이다. 일부 구현예에서, 바운드 아이템 관리자(1106)의 기능성은 제어기(1102)의 일부로서, 또는 다른 컴포넌트의 일부로서 포함될 수 있다.

스윕퍼(1112)는 (최종 동기화가 이루어진 이후로 변경되었기 때문에) 조사될 필요가 있는 바운드 아이템을 찾는 데에 사용되는 내부 컴포넌트이다. 일부 구현예에서, 스윕퍼(1112)의 기능성은 제어기(1102)의 일부로서, 또는 다른 컴포넌트의 일부로서 포함될 수 있다.

리졸버(1109)는 바운드 아이템을 조사하고, 변경을 (속성 프로모션을 통해) 국부적으로 해결하고/하거나 완전한 동기화를 위해 마킹하는 데에 사용되는 내부 컴포넌트이다. 일부 구현예에서, 리졸버(1109)의 기능성은 제어기(1102)의 일부로서, 또는 다른 컴포넌트의 일부로서 포함될 수 있다.

제어 메시지 프로세서(1110)는 포맷터에 의해 보내진 메시지에 대하여, 모니터링되는 지정 폴더(1111)로부터의 제어 메시지를 처리하는 데에 이용되는 내부 컴포넌트이다. 제어 메시지는 생성/갱신/삭제 동사의 경우에 생산성 제품군 아이템을 갱신하도록, 또는 동기화기 컴포넌트에 의해 처리될 질의 커맨드를 서브밋하도록 처리된다. 일부 구현예들에서, 제어 메시지 프로세서(1110)의 기능성은 제어기(1102)의 일부로서, 또는 다른 컴포넌트의 일부로서 포함될 수 있다.

데이터 제공자(1107)는 SDS 데이터 테이블(1108)로의 액세스를 제공하는 내부 컴포넌트이다. 일부 구현예들에서, 데이터 제공자(1107)의 기능성은 제어기(1102)의 일부로서, 또는 다른 컴포넌트의 일부로서 포함된다.

동기화기(1105)는 바운드 아이템이 클라이언트 상에서 생성, 갱신 또는 삭제될 때 LOB 시스템에게 통지하고, 성공적인 통지 이후에 동기화 데이터 저장소(SDS(1108))를 갱신하고, 질의 제어 메시지를 처리하고, 동기화 프로세스의 상태를 보고하는 것을 책임지는 내부 컴포넌트이다. 일부 구현예들에서, 동기화기(1105)의 기능성은 제어기(1102)의 일부로서, 또는 다른 컴포넌트의 일부로서 포함될 수 있다.

변경들의 동기화는 아래에 설명되는 것과 같은 도 12에 도시되어 있다. 바운드 아이템들에 대한 변경은 1차 머신(OBA-가능형 머신) 상에서, 또는 웹 서비스(예를 들어, 아웃룩 웹 액세스(OWA))나 소정의 다른 OBA-불가능형 클라이언트 및 모바일 장치들로부터와 같이 다른 외부 인터페이스를 통해 이루어질 수 있다. 변경들이 어디에서 이루어지는지에 따라, 시스템은 약간 다른 코드 경로를 이용하여 그 변경들을 동기화할 것이다.

바운드 아이템의 관리 : 가능형 클라이언트

사용자는 애드-인 또는 플러그-인 컴포넌트를 통하는 것 등에 의해 동기화 가능한 클라이언트에서, 바운드 아이템을 생성, 갱신 및 삭제할 수 있다. 시스템은 변경들을 검출하고, LOB 시스템에 변경 요청을 자동으로 서브밋한다. 요청이 처리되고, LOB 시스템은 애플리케이션 레벨의 성공 또는 실패 응답을 보낸다. 이 응답은 클라이언트에 의해 수신되며, 바운드 아이템의 애플리케이션 비지니스 상태가 갱신된다. 새로운 바운드 아이템(예를 들어, 아웃룩에서 생성된 것)의 경우에, LOB 시스템으로부터의 응답은 그 바운드 아이템을 LOB 엔터티에 상관시키기 위하여 시스템에 의해 사용된다.

바운드 아이템의 관리 : 웹 액세스

사용자는 웹 액세스를 통해 자신의 우편함에 액세스한다. 바운드 아이템은 표준 아이템으로서 사용자에게 노출된다. 사용자는 표준 정보는 정상적으로 변경할 수 있지만, 확장된 정보는 변경하지 못한다. 사용자는 기존의 바운드 아이템을 갱신 또는 삭제할 수는 있지만, 기존의 바운드 아이템을 복사(비간접 생성)하는 경우를 제외하고는, 새로운 바운드 아이템을 생성하지 못한다. 사용자가 자신의 1차 머신으로 되돌아갈 때, 웹 액세스를 통해 이루어진 변경은 서버 애플리케이션에 의해 (예를 들어, 마이크로소프트 익스체인지를 통해) 동기화된다. 시스템은 변경을 검출하고, 적절한 변경 요청을 LOB 시스템에 자동으로 서브밋한다.

바운드 아이템의 관리 : 불가능형 클라이언트

사용자는 가능형이 아닌 생산성 제품군 클라이언트를 이용하여 자신의 우편함에 액세스할 수 있다. 바운드 아이템은 표준 아이템으로서 나타난다. 사용자는 표준 정보는 정상적으로 변경할 수 있지만, 확장된 정보는 변경하지 못한다. 사용자는 기존의 바운드 아이템은 갱신 또는 삭제할 수 있지만, 새로운 아이템을 생성하지는 못한다. 그 다음, 사용자는 서버 애플리케이션(예를 들어, 마이크로소프트 익스체인지)과 동기화한다. 사용자가 자신의 1차 클라이언트 머신으로 되돌아갈 때, 불가능형 클라이언트에서 이루어진 변경들은 서버 애플리케이션으로부터 동기화된다. 시스템은 변경을 검출하고, 적절한 변경 요청을 LOB 시스템에 자동으로 서브밋한다.

바운드 아이템의 관리 : 모바일 장치

사용자는 모바일 장치를 통해 자신의 우편함에 액세스한다. 모바일 장치를 위한 특별한 지원은 없으며, 모바일 장치는 웹 서비스와 동일하게 취급된다. 바운드 아이템은 사용자에게 표준 아이템으로서 노출된다. 사용자는 표준 정보는 정상적으로 변경할 수 있지만, 확장된 정보는 변경하지 못한다. 사용자는 기존의 바운드 아이템을 갱신 또는 삭제할 수는 있지만, 새로운 아이템을 생성하지는 못한다. 사용자가 자신의 1차 클라이언트 머신으로 되돌아갈 때, 모바일 장치에서 이루어진 변경들은 서버 애플리케이션(예를 들어, 마이크로소프트 익스체인지)에 의해 동기화된다. 시스템은 변경을 검출하고, 적절한 변경 요청을 LOB 시스템에 자동으로 서브밋한다.

바운드 아이템의 관리 : 다수의 가능형 클라이언트

사용자는 "1차" 클라이언트 머신과, 임의의 개수의 "2차" 클라이언트 머신을 가지며, 각 머신에는 생산성 제품군 애플리케이션과 LOB 시스템 간의 동기화가 가능한 클라이언트 애플리케이션이 설치되어 있다. 사용자는 임의의 머신에서 바운드 아이템을 생성, 갱신 또는 삭제할 수 있다. 한 머신 상에서 이루어진 변경은 서버 애플리케이션(예를 들어, 마이크로소프트 익스체인지)을 통해 다른 머신들로 동기화될 것이지만, 일 실시예에서는 1차 머신만이 LOB 시스템과 동기화할 수 있을 것이다. "1차" 머신은 설치시에 지정되고, 다른 머신들은 "2차" 머신으로 간주될 것이다. 사용자가 가질 수 있는 2차 머신의 수에는 특별한 제한이 없다. 1차 머신 상에서 LOB 시스템으로의 접속을 이용할 수 있을 때, 시스템은 요구되는 변경 요청을 LOB 시스템에 자동으로 서브밋할 것이다.

설명되는 시스템은, 서버로부터 다양한 2차 클라이언트 머신들로 비지니스 상태 응답을 배포할 목적으로, 서버 상에 동기화 캐시를 유지하도록 구성될 수 있다. 이 예를 위하여, 서버의 동기화 캐시는 각각의 1차 클라이언트 스윕의 전후에 갱신된다. 서버의 동기화 캐시는 BoundData를 제외한 SDS로부터의 모든 데이터로 이루어질 수 있다. 스윕 간격 일정에 따라, 서버의 동기화 캐시는 서버로부터 각 2차 클라이언트 소유의 SDS로 다운로드될 수 있다.

바운드 아이템의 관리 : 변경들의 전파

LOB 시스템에서 비지니스 엔터티에 관련된 변경이 이루어지면, 서버 애플리케이션은 포맷터를 통해 통지를 받을 것이다. 변경 통지는 바운드 아이템에 대한 변경을 적용할 필요가 있을 수 있는 가능형 클라이언트들에게 배달된다. 변경 통지는 푸쉬되므로, 클라이언트는 갱신을 위해 핑(ping)을 할 필요가 없으며, 일정이 정해진 동기화 시간을 기다리지 않고서 즉시 응답할 수 있다.

동기화 방법

도 13은 예시적인 동기화 방법을 위한 흐름도이다. 주기적으로, 시스템 스윕퍼 프로세스는 동기화될 필요가 있는 바운드 아이템을 찾아서 마킹하며, 여기에서 그러한 아이템은 동기화를 위한 논리 리스트(동기화 리스트)에 배치된다. 동기화 리스트 내의 각 아이템에 대하여, 생성, 갱신 또는 삭제 요청(CUD 요청)이 생성되어 아웃바운드 큐(예를 들어, 도 7의 VOQ(712)) 내에 저장된다. 그 다음, 웹 서비스 호출이 개시되어, LOB 시스템으로의 접속이 확립된다. 웹 서비스 호출은 성 공하거나, 실패하거나, 또는 접속 예외를 생성한다.

웹 서비스 호출에 응답하여 LOB로부터 응답이 얻어지면, 성공적인 연결이 확립된 것이다. 웹 서비스로의 성공적인 접속에 대하여, 시스템은 응답으로부터의 정보를 이용하여 SDS 내의 바운드 아이템 사본을 갱신한다. 동기화 리스트 내의 각 아이템에 대하여, 추가의 CUD 요청이 마찬가지로 처리된다.

웹 서비스 호출에 응답하여 LOB 시스템으로부터 접속 예외 이외의 예외가 제공되면, 접속 실패가 발생한다. 웹 서비스에 대한 접속 실패에 대하여, CUD 요청은 아웃바운드 큐 내에 유지되고 재시도를 위해 마킹된다. 최초의 접속 실패가 식별된 때, CUD 요청에 대한 재시도 카운트가 초기화될 수 있다. 성공적인 접속이 확립될 때까지, 또는 미리 정해진 시간 간격 동안 허용된 최대 시도 횟수가 한계에 도달할 때까지, 재시도가 계속될 것이다. 성공하지 못하고 허용된 최대 시도 횟수에 도달한 때, CUD 요청은 실패 요청 큐로 이동된다. 성공적인 접속이 확립되지 않으면, 추가의 CUD 요청은 처리되지 않을 것이다.

클라이언트가 유효한 인증 쿠키를 가지고 있고, 대상 서버로의 핑이 실패한 때, 접속 예외가 발생할 수 있다. 웹 서비스 호출로부터 접속 예외가 발생하면, 시스템은 동기화 리스트 내의 다음 아이템으로 스킵한다.

동기화를 위한 예시적인 프로세스 흐름이 아래에 설명되는 바와 같이 도 13에 도시되어 있다. 처리는 블럭(1301)에서 시작하고, 판정 블록(1305)으로 진행한다.

판정 블록(1305)에서, 생산성 제품군 동기화 시스템은 동기화 리스트를 평가 하여, 생산성 제품군 애플리케이션과 LOB애플리케이션 간에서 동기화가 필요한 임의의 바운드 아이템을 식별한다. 동기화 리스트 상에 바운드 아이템이 없으면, 처리는 블록(1310)으로 진행하고, 시스템은 동기화 리스트를 다시 평가하기 전에 미리 정해진 시간(예를 들어, X분) 동안 기다린다. 동기화 리스트 내에서 바운드 아이템이 발견되면, 블록(1315)에서 시스템은 실패 요청의 최대 횟수에 도달했는지를 판정한다. 최대 요청 횟수에 도달했으면, 처리는 다시 블록(1310)으로 진행한다. 다르게는, 처리는 블록(1320)으로 계속될 수 있고, 거기에서 CUD 요청이 생성된다.

블록(1325)으로 진행하여, CUD 요청은 도 7의 VOQ(712)와 같은 발송용 요청 큐 내에 배치된다. 블록(1330)에서, 생산성 제품군 애플리케이션 동기화 시스템은 웹 서비스 호출과 같은 서비스 호출을 통하여, 발송용 요청 큐 내의 각 요청을 LOB 시스템에 서브밋한다. 판정 블록(1335)으로 진행하여, CUD 호출 요청이 평가되어, 요청이 LOB 시스템에 성공적으로 서브밋되었는지가 판정된다. CUD 호출 요청이 성공적이면, 처리는 판정 블록(1335)으로부터 블록(1340)으로 진행한다 (동기화 데이터 저장소, 즉 SDS가 갱신된다). CUD 호출 요청이 실패하면, 처리는 판정 블록(1335)으로부터 블록(1345)으로 진행한다. 일부 경우들에서, 접속 예외가 발생되고, 처리는 판정 블록(1335)으로부터 판정 블록(1305)으로 진행한다.

블록(1345)에서, 생산성 제품군 애플리케이션을 위한 동기화 시스템은 CUD 호출 요청에 대해 재시도한다. 판정 블록(1350)에서, 시스템은 호출 요청으로부터 응답이 수신되었는지를 판정한다. 응답이 성공적이면, 처리는 판정 블록(1350)으로부터 블록(1340)으로 진행하고, 거기에서 SDS가 갱신된다. 응답이 실패하면, 처 리는 판정 블록(1350)으로부터 판정 블록(1360)으로 진행한다. 응답이 수신되지 않으면, 처리는 판정 블록(1350)으로부터 블록(1355)으로 진행하고, 거기에서 시스템은 블록(1345)에서 다른 재시도를 하기 전에 타임아웃이 만료하기를 기다린다.

판정 블록(1360)에서, 시스템은 CUD 호출 요청에 대한 최대 재시도 횟수에도달했는지를 판정한다. 최대 재시도 횟수에 도달했으면, 처리는 블록(1365)으로 진행하고, 거기에서 CUD 요청은 실패 큐로 이동된다. 최대 재시도 횟수가 초과되지 않았으면, 시스템은 블록(1370)에서 내부 재시도 카운터를 증분시키고, 블록(1355)으로 진행하여 다른 재시도를 기다린다.

동기화된 아이템들의 참조

앞에서 설명한 바와 같이, LOB 엔터티와 PS 아이템 간에 바인딩이 생성된다. 동기화 시스템은 LOB 엔터티에 대한 어떠한 직접적 액세스도 갖지 않는 한편, SDS는 LOB 시스템에 저장되어 있다고 자신이 가정하는 것의 별도의 사본을 보유한다. LOB 엔터티와 PS 아이템 간의 바인딩이 생성되면, 동기화된 PS 아이템의 사본은, 그 PS 아이템이 LOB 엔터티에 관련지어진 LOBID로 인덱싱될 수 있도록 SDS 내에 배치될 수 있다. 즉, LOB 엔터티와 관련지어진 PS 아이템은 LOBID를 참조하여 SDS로부터 검색될 수 있다. PS 아이템이 LOBID를 참조하여 검색될 수 있으므로, 그 PS 아이템을 이용할 수 있는 다수의 대상 애플리케이션, 플러그인, 또는 기타 소프트웨어 메소드들이 구현될 수 있다(예를 들어, 벡엔드 워크플로우 시스템).

일례에서, LOB 애플리케이션은 이메일 통신을 통하여 LOB 식별자(예를 들어, LOBID)를 생산성 제품군 애플리케이션에 보낼 수 있다. 이메일 통신은 LOB 아이템 을 참조하는 임베드된 정보를 포함한다. 예를 들어, LOBID는 이메일 메시지와 관련지어진 헤더 내에 임베드될 수 있다. LOBID가 LOB 엔터티를 참조하므로, 이메일 통신은 LOB 아이템 자체를 (임베드하거나 다른 방식으로) 포함하지 않아도 된다. 이메일 메시지가 수신되고 나면, 생산성 제품군을 위한 이메일 헤더는 LOB 식별자를 참조함으로써 동기화 쉐도우 또는 동기화 데이터 저장소 내의 특정 생산성 제품군 아이템을 식별할 수 있다.

다른 예에서, 사용자는 SDS 내의 PS 아이템에 관련지어진 LOB 식별자를 참조하는 링크(예를 들어, HTTP, HTTPS, FTP, FTPS, OBA 등과 같은 임의의 개수의 형태들로 된 URL 링크)로 생산성 제품군 아이템을 참조할 수 있다.

또 다른 예에서, LOB 시스템이 생산성 제품군 시스템에 이메일 메시지를 보내면, 액션창, 작업창 또는 기타 소프트웨어 메소드들이 활성화될 수 있다. 활성화되고 나면, 소프트웨어 메소드들은 LOBID를 참조함으로써 SDS로부터 생산성 제품군 아이템을 검색한 후, 그 생산성 제품군 아이템에 액션을 수행할 수 있다.

소프트웨어 메소드들에 의해 생산성 제품군 아이템에 대해 수행될 수 있는 액션은, 생산성 제품군 아이템의 생성, 갱신 또는 삭제를 유발할 것이고, 이것은 앞에서 설명한 바와 같이 LOB 시스템과 동기화될 수 있다. LOB 시스템은 이메일 통신 내의 LOBID 및 소프트웨어 메소드들을 참조함으로써 생산성 제품군 사용자에게 작업을 효과적으로 보낼 수 있다.

소프트웨어 메소드들에 관한 일례에서, LOB 시스템으로부터의 이메일 통신은 LOBID로 식별되는 LOB 엔터티와 동기화되는 특정 생산성 제품군에 관련된 검토 또 는 승인을 완료하라는 요청을 사용자에게 보낼 수 있다. 이메일 통신은, LOB 시스템의 마감에 도달했을 때, 또는 LOB 시스템의 특정 사용자에 의해 제공될 때, LOB 시스템에 의해 자동으로 보내질 수 있다. 이메일은 포맷터에 (예를 들어, XML 데이터 표현, 텍스트, 임베드된 데이터 등을 통해,) 정보를 보낸 후 그 포맷터가 이메일 및 디렉토리 서버(예를 들어, 도 7 참조)와 협력하여 이메일 메시지를 생성하는 것에 의해, LOB 시스템에 의해 생성될 수 있다. 이메일은 생산성 제품군 아이템에 관련된 액션을 완료할 필요성을 강조할 수 있고, 추가의 설명을 제공할 수 있으며, 여기에서 이메일은 벡엔드 워크플로우 시스템 내의 작업들을 참조할 수 있다. 생산성 제품군 애플리케이션은 이메일 통신 내에 임베드된 링크를 작업으로 해석할 수 있으므로, 실제 작업 정보는 자동으로 제시될 수 있다. 그러면, 사용자는 링크를 선택하고, 그 링크를 따라가서 생산성 제품군 애플리케이션 내의 작업 아이템을 열 수 있으며, 여기에서 관련지어진 동기화된 벡엔드 정보는 XML 데이터 표현으로 저장될 수 있다. LOB 식별자는 링크 내에 임베드될 수 있으므로, 생산성 제품군 아이템과 관련지어진 임의의 바람직한 액션은 핸들러(예를 들어, URL 핸들러)를 적절하게 구성함으로써 취해질 수 있다.

예시적인 실시예들 및 응용예들이 도시되고 설명되었지만, 본 발명은 여기에 설명된 상세한 구성 및 자원들로 한정되지 않음을 알 수 있을 것이다. 당업자라면, 본 발명의 범위를 벗어나지 않고서, 여기에 개시된 방법 및 시스템의 구성, 동작 및 상세에 다양한 수정, 변화 및 변경이 가해질 수 있음을 분명히 알 수 있을 것이다. 본 발명의 취지 및 범위를 벗어나지 않고서, 본 발명의 많은 실시예들이 만들어질 수 있으며, 본 발명은 이하의 특허청구범위에 기재되어 있다.

Claims

라인-오브-비지니스(line of business, LOB) 애플리케이션과 생산성 제품군(productivity suite) 애플리케이션 간에서 정보를 동기화하기 위한 컴퓨터 실행가능 명령어들을 포함하는 컴퓨터 판독가능 매체로서,

상기 명령어들은,

상기 생산성 제품군 애플리케이션(720)에 푸쉬(push) 방식으로 통신된 이메일을 수신하고 - 상기 푸쉬 통신된 이메일에는 제어 메시지(795)가 임베드되고, 상기 제어 메시지는 LOB 엔터티에 대한 변경을 정의하는, 상기 LOB 애플리케이션(760)으로부터의 XML 데이터 표현(793)임 -,

클라이언트 머신(710) 상에서 생산성 제품군 애플리케이션(720)으로의 상기 이메일로부터 상기 제어 메시지(795)를 검색하고,

동기화 프로세스(796) 동안 상기 검색된 제어 메시지(795)에 응답하여 바운드 아이템에 대한 변경을 식별하여, 상기 바운드 아이템이 생산성 제품군 아이템(230) 및 LOB 엔터티(251) 둘다와 관련지어지게 하는 것 -상기 제어 메시지(795)는 LOB 엔터티 생성, LOB 엔터티 갱신 및 LOB 엔터티 삭제(214) 중 적어도 하나를 나타냄-

을 포함하는 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 명령어들은, 허가되지 않은 발신자들로부터의 스푸핑 이 방지되도록, 상기 제어 메시지(795)를 검색하기 전에 상기 이메일을 인증하는 것을 포함하는 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 명령어들은 상기 제어 메시지(795)가 상기 이메일로부터 검색될 때, 사용자에게 통지를 제공하는 것을 더 포함하는 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 명령어들은, 상기 검색된 제어 메시지(795)를 히든 폴더 및 인바운드 메시지 큐(714) 중 적어도 하나에 자동으로 배치하는 것을 더 포함하는 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 명령어들은, 상기 클라이언트 머신(710) 상에서 동기화 데이터 저장소(SDS, 1050) 내의 각각의 바운드 아이템을 저장하는 것을 더 포함하는 컴퓨터 판독가능 매체.
제5항에 있어서, 상기 명령어들은, SDS(1050)를 이용하여 생산성 제품군 애플리케이션 아이템(230)과 관련 LOB 엔터티(251) 간의 변경을 식별하고, 상기 LOB 시스템(250)과의 동기화를 위해, 식별된 변경들을 위한 요청을 가상 요청 큐(712) 내에 배치하는 것을 더 포함하는 컴퓨터 판독가능 매체.
제5항에 있어서, 상기 명령어들은, 상기 생산성 제품군 애플리케이션(720)을 위한 우편함(1010) 내의 모든 바운드 아이템을 상기 SDS(1050)에 비교하고, 상기 우편함(1010)과 상기 SDS(1050) 간의 참조 무결성을 검출하여 바로잡는 것을 더 포함하는 컴퓨터 판독가능 매체.
제7항에 있어서, 상기 명령어들은, 수정된 아이템들을 추가의 처리를 위해 마킹하고, 마킹된 아이템들을 위한 속성들을 프로모션하고, 그에 따라 갱신된 XML 데이터 표현을 상기 SDS 사본과 비교하는 것을 더 포함하는 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 동기화 프로세스는, 상기 바운드 아이템에 관련된 충돌(1230)을 식별하여 해결하는 것, 상기 바운드 아이템에 관련된 속성을 프로모션(promotion)하는 것, 상기 바운드 아이템에 관련된 속성을 디모션(demotion)하는 것, 및 상기 생산성 제품군 애플리케이션이 2차 머신(260)에 할당된 때 속성들을 프로모션하지 않고 상기 바운드 아이템을 갱신하는 것 중 적어도 하나를 포함하는 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 명령어들은,

상기 클라이언트 머신(210) 상에서의 생산성 제품군 아이템에 대한 변경에 응답하여 아웃바운드 요청(212)을 생성하고 -상기 아웃바운드 요청은 상기 생산성 제품군 아이템(230)에 관련된 생성, 갱신 및 삭제 중 적어도 하나(212)를 포함함-,

상기 LOB 애플리케이션(760)과의 동기화를 위해, 상기 아웃바운드 요청을 아웃바운드 큐(712)에 배치하고,

제1 시간에서 상기 LOB 애플리케이션에 대하여 상기 큐 내의 요청을 위한 웹 서비스 호출(792)을 개시하여, 상기 웹 서비스가 상기 LOB 애플리케이션(760)에 성공적으로 접속한 때에 상기 LOB 애플리케이션(760)이 상기 아웃바운드 요청을 검색할 수 있게 하고,

상기 웹 서비스가 상기 LOB 애플리케이션(760)에 성공적으로 접속한 때, 상기 아웃바운드 큐(712)로부터 상기 아웃바운드 요청을 제거하고, 동기화 데이터 저장소(SDS, 1050)를 갱신하는 것을 포함하는 컴퓨터 판독가능 매체.
제10항에 있어서, 상기 명령어들은,

상기 웹 서비스가 초기에 상기 LOB 애플리케이션에 성공적으로 접속하지 못한 때인 제2 시간에서, 상기 아웃바운드 큐(712) 내의 상기 아웃바운드 요청에 대해 제2 웹 서비스 호출(792)을 개시하는 것을 더 포함하는 컴퓨터 판독가능 매체.
제10항에 있어서, 상기 명령어들은,

상기 LOB 애플리케이션(760)에 의한 수신을 위해 상기 요청을 XML 데이터 표현으로 인코딩하는 것을 더 포함하는 컴퓨터 판독가능 매체.
LOB 애플리케이션과 생산성 제품군 애플리케이션 간에서 정보를 동기화하기 위한 장치로서,

프로세서(104),

컴퓨터 판독가능 매체(116, 118, 120, 122, 124),

상기 컴퓨터 판독가능 매체 상에 저장되어 상기 프로세서(104) 상에서 실행되는 운영 환경(126), 및

상기 운영 환경(126)의 제어 하에서 동작하고 액션들을 수행하도록 동작하는 애플리케이션(128, 130)

을 포함하고,

상기 애플리케이션(128, 130)은,

LOB 엔터티(251)에 대한 변경에 응답하여 요청(214)을 생성하고 -상기 요청은 상기 LOB 엔터티를 생성하기 위한 명령어, 상기 LOB 엔터티를 갱신하기 위한 명령어, 및 상기 LOB 엔터티를 삭제하기 위한 명령어 중 적어도 하나를 포함함-,

상기 LOB 엔터티(251) 내의 변경에 관련된 XML 데이터 표현(793)을 생성하고,

상기 XML 데이터 표현(770)을 이메일(780) 내에 인코딩되는 제어 메시지(794)로 포맷하고,

상기 이메일(780)을 상기 생산성 제품군 애플리케이션(720)으로 푸쉬 방식으로 통신하여, 상기 LOB 엔터티(251)에 대한 상기 변경이 상기 이메일로부터 상기 제어 메시지를 추출함으로써, 생산성 제품군 애플리케이션 아이템들과 동기화(730)될 수 있게 하도록 구성된, 정보를 동기화하기 위한 장치.
제13항에 있어서, 상기 애플리케이션은, 상기 이메일을 2차 클라이언트(260) 상에 존재하는 다른 생산성 제품군 어플리케이션(270)에 푸쉬 방식으로 통신하도록 구성된, 정보를 동기화하기 위한 장치.
제13항에 있어서, 상기 애플리케이션은,

웹 서비스 호출(792)을 수신하고,

상기 웹 서비스 호출(792)로부터 갱신 요청(791)을 추출하고 -상기 갱신 요청(791)은 생산성 제품군 애플리케이션 아이템에 대한 변경에 관련됨-,

상기 추출된 갱신 요청에 응답하여 LOB 엔터티를 갱신 -상기 추출된 갱신 요청은 상기 생산성 제품군 애플리케이션 아이템을 생성하기 위한 명령어, 상기 생산성 제품군 애플리케이션 아이템을 갱신하기 위한 명령어, 및 상기 생산성 제품군 애플리케이션 아이템을 삭제하기 위한 명령어 중 적어도 하나에 대응함- 하도록 더 구성된, 정보를 동기화하기 위한 장치.
제15항에 있어서, 상기 웹 서비스 호출(792)로부터의 갱신 요청은 다른 XML 데이터 표현인, 정보를 동기화하기 위한 장치.
제13항에 있어서, 상기 애플리케이션은, 상기 생산성 제품군 애플리케이션(720)으로부터 웹 서비스 호출(792)을 수신하고, 상기 웹 서비스 호출로부터 요 청을 추출하고, 상기 추출된 요청에 응답하여 LOB 엔터티를 생성하도록 더 구성된, 정보를 동기화하기 위한 장치.
LOB 애플리케이션과 생산성 제품군 애플리케이션 간에서 정보를 동기화하기 위한 방법으로서,

상기 LOB 애플리케이션(760)으로부터 XML 데이터 표현(793)을 수신하는 단계 -상기 XML 데이터 표현(793)은 상기 LOB 애플리케이션(760) 내의 적어도 하나의 엔터티에 관련된 변경을 식별함-,

상기 XML 데이터 표현(793)을 제어 메시지(740)로 포맷(770)하는 단계,

상기 제어 메시지(794)를 이메일(780) 내에 임베드하는 단계, 및

상기 이메일(780)을 상기 생산성 제품군 애플리케이션(720)에 푸쉬 방식으로 통신하여, 상기 LOB 애플리케이션(760) 내의 상기 적어도 하나의 엔터티에 관련된 변경이 상기 생산성 제품군 애플리케이션(720)과 동기화될 수 있게 하는 단계

를 포함하는, 정보를 동기화하기 위한 방법.
제18항에 있어서,

상기 생산성 제품군 애플리케이션(720)으로부터 다른 XML 데이터 표현(792)을 수신하는 단계,

상기 다른 XML 데이터 표현(792)으로부터 상기 생산성 제품군 애플리케이션 내의 적어도 하나의 아이템에 관련된 변경을 식별하는 단계, 및

상기 식별된 변경에 기초하여 상기 LOB 애플리케이션(760) 내의 적어도 하나의 엔터티를 갱신하여, 상기 LOB 애플리케이션(760) 내의 상기 적어도 하나의 엔터티가 상기 생산성 제품군 애플리케이션 내의 상기 적어도 하나의 아이템에 바인딩되게 하는 단계

를 더 포함하는, 정보를 동기화하기 위한 방법.
제19항에 있어서,

상기 갱신은, 상기 LOB 애플리케이션 내의 상기 적어도 하나의 엔터티를 생성하는 것, 수정하는 것 및 삭제하는 것 중 적어도 하나를 포함하는, 정보를 동기화하기 위한 방법.