KR20070057806A - 엔터프라이즈 데이터 통합 시스템을 위한 아키텍처 - Google Patents

Abstract

데이터 통합 프로세스를 구축하고 관리하기 위한 아키텍처가 개시된다. 아키텍처는 유저 인터페이스, 프로그램식 인터페이스, 서비스, 컴포넌트, 런 타임 엔진, 및 외부 커넥터를 포함하는, 여러 태양의 통합 디자인 프로세스에 모듈성 및 확장성을 제공할 수 있다. 아키텍처는 데이터 통합 프로세스의 실행과 디자인의 각종 측면 사이에서 무결절성 전환을 가능하게 하도록, 디자인 프로세스를 통하여 공통 통합 메타데이터 공유 접근을 또한 채용할 수 있다.

엔터프라이즈 데이터 통합 시스템, 아키텍처, 유저 인터페이스, 메타데이터, 변환

Description

엔터프라이즈 데이터 통합 시스템을 위한 아키텍처{ARCHITECTURE FOR ENTERPRISE DATA INTEGRATION SYSTEMS}

본 출원은 2004년 8월 31일 제출된 "엔터프라이즈 데이터 통합 시스템을 위한 아키텍처(Architecture for Enterprise Data Integration Systems)" 명칭의 미국 가출원 번호 제60/606,237호의 우선권을 주장한다.

본 발명은 정보 기술 분야에 관한 것이며, 더욱 상세하게는 데이터 통합 시스템 분야에 관한 것이다.

컴퓨터 애플리케이션은 여러 비지니스 프로세스가 신속하고 더욱 효율적이게 한다. 하지만, 상이한 데이터 구조, 통신 프로토콜, 언어 및 플랫폼(platform)을 사용하는 상이한 컴퓨터 애플리케이션의 확산은 통상적인 비지니스 엔터프라이즈의 정보 기술 기반 주조의 큰 복잡성을 이끈다. 통상적인 엔터프라이즈 내의 상이한 비지니스 프로세스는 완전히 상이한 컴퓨터 애플리케이션을 사용할 수 있으며, 각 컴퓨터 애플리케이션은 전체로서 엔터프라이즈를 위한 것보다 특정 비지니스 프로세스를 위해 개발되고 최적화된다. 예컨대, 비지니스는 지불가능 계좌를 추적하기 위한 하나의 컴퓨터 애플리케이션과, 소비자 연락을 유지하기 위한 다른 컴퓨터 애플리케이션을 가질 수 있다. 엔터프라이즈가 중앙의 소비자 접촉 데이터베이스를 유지할 때와 같이, 동일한 비지니스 프로세스가 하나 이상의 컴퓨터 애플리케이션을 사용할 수 있지만, 종업원은 자기 자신의 접촉 정보를 개인 정보 매니저에서와 같이 유지한다.

특수화된 컴퓨터 애플리케이션의 장점은 그것들이 도입하는 비효율성, 예컨대 반복적인 엔트리, 중복적인 데이터 처리, 또는 엔터프라이즈가 자신의 엔터프라이즈 데이터 세트의 상호연결을 인식하고, 엔터프라이즈가 데이터로부터 이익이 될 수 있는 다른 프로세스를 실행할 때 하나의 프로세스와 관련된 데이터를 이용하는 데 실패하는 것과 같은 비효율성에 의해 상쇄된다. 예컨대, 계좌 지불 프로세스가 공급 체인 및 주문 프로세스와 분리된 경우, 엔터프라이즈는 주문을 거절할 수 있는 신용 이력을 갖는 고객으로부터의 주문을 수용하고 이행할 수 있다. 여러 다른 예는 엔터프라이즈가 각종 컴퓨터 애플리케이션에 걸쳐 모든 데이터에 일관적인 접속으로부터 이익을 얻을 수 있는 곳에 제공될 수 있다.

여러 회사는 비지니스 엔터프라이즈 내의 상이한 애플리케이션에 걸쳐 데이터를 공유할 필요성을 인식하고 강조하고 있다. 그리하여, 엔터프라이즈 애플리케이션 통합(enterprise application integration) 또는 EAI는 이산적인 소스로부터의 데이터를 어드레싱하기 위한 메시지 기반 전략으로서 부상되고 있다. 컴퓨터 애플리케이션이 복잡해지고 그 수가 증가함에 따라, EAI 노력은 상이한 프로토콜을 취급해야 하는 필요성, 계속 증가하는 데이터 용량 및 트랜잭션의 수, 및 데이터의 신속한 통합을 위한 계속 증가하는 욕구에 걸친 여러 도전에 직면한다. 최소 공분모 접근(least-common-denominator approach) 접근, 원자 접근(atomic approach), 브릿지 타입 접근(bridge-type approach)을 포함하는 EAI에 대한 각종 접근이 취해졌다. 하지만, EAI는 개별적 애플리케이션 사이의 통신에 기초한다. 현저한 단점으로는, EAI 솔루션의 복잡성이 플랫폼 및 애플리케이션의 선형적 부가에 응하여 기하학적으로 증가한다는 것이다.

제공된 데이터 통합 시스템이 엔터프라이즈의 필요성을 어드레싱 하는데 유용한 툴(tool)이지만, 그러한 시스템은 통상적으로 커스텀 솔루션(custom solution)으로서 전개된다. 그것은 긴 전개 사이클을 갖고, 비지니스 구조 및 정보 요건에서의 변화를 수용하기 위해서는 복잡한 기술적 트레이닝을 요구할 수 있다. 변화하는 비지니스 환경에서의 기능성의 사용, 재사용 및 변형을 허용하는 데이터 통합 시스템 툴에 대한 필요성, 및 데이터 통합 시스템의 디자인 및 사용을 지원하는 개선된 아키텍처에 대한 필요성이 존재한다.

데이터 통합 프로세스를 구축하고 관리하기 위한 아키텍처가 개시된다. 아키텍처는 유저 인터페이스, 프로그램식 인터페이스, 서비스, 컴포넌트, 런 타임 엔진, 및 외부 커넥터를 포함하는, 여러 태양의 통합 디자인 프로세스에 모듈성 및 확장성을 제공할 수 있다. 아키텍처는 데이터 통합 프로세스의 실행과 디자인의 각종 측면 사이에서 무결절성 전환을 가능하게 하도록, 디자인 프로세스를 통하여 공통 통합 메타데이터 공유 접근을 또한 채용할 수 있다.

일 태양에서, 본 개시에 따른 데이터 통합 시스템은, 복수의 데이터 통합 태스크를 수행하기 위한 유저 인터페이스 - 여기서, 유저 인터페이스는 프로젝트를 위한 워크플로우의 복수의 단계에 대응하는 복수의 메뉴를 포함함 - 와; 데이터 통합 태스크의 선택된 하나와 메뉴의 선택된 하나를 관련시키는 태스크 매트릭스와; 서비스의 레지스트리와, 유저 인터페이스의 데이터 통합 태스크의 각각과 관련된 하나 이상의 서비스를 포함하는 서비스 지향 아키텍처와; 유저 인터페이스와 서비스 지향 아키텍처의 서비스의 하나 이상의 서비스와 관련된 리포지토리 - 여기서, 리포지토리는 프로젝트를 위한 워크플로우의 하나보다 많은 단계에 대한 공통 메타데이터 모델을 저장함 - 와; 프로젝트를 실행하기 위한 하나 이상의 런 타임 엔진과; 하나 이상의 런 타임 엔진을 하나 이상의 외부 리소스에 접속하기 위한 하나 이상의 커넥터 - 여기서, 커넥터는 데이터 처리율을 위한 모듈식 컴포넌트 및 구성을 사용함 - 를 포함한다.

다른 태양에서, 데이터 통합 프로세스를 관리하는 방법은, 복수의 데이터 통합 태스크를 수행하기 위한 유저 인터페이스 - 여기서, 유저 인터페이스는 프로젝트를 위한 워크플로우의 복수의 단계에 대응하는 복수의 메뉴를 포함함 - 를 제공하는 단계와; 데이터 통합 태스크의 선택된 하나와 메뉴의 선택된 하나를 관련짓는 단계와; 서비스의 레지스트리를 포함하는 서비스 지향 아키텍처를 제공하는 단계와; 하나 이상의 서비스를 유저 인터페이스의 데이터 통합 태스크의 각각과 관련짓는 단계와; 서비스 지향 아키텍처의 서비스의 하나 이상의 서비스 및 유저 인터페이스를 리포지토리와 관련짓는 단계와; 프로젝트를 위한 워크플로우의 하나보다 많은 단계에 대한 공통 메타데이터 모델을 리포지토리에 저장하는 단계와; 하나 이상의 런 타임 엔진을 사용하여 프로젝트를 실행하는 단계 - 여기서, 런 타임 엔진은 프로젝트의 데이터 처리를 위하여 모듈식 컴포넌트 및 구성을 사용함 - 와; 하나 이상의 런 타임 엔진을 하나 이상의 외부 리소스에 접속하는 단계를 포함한다.

데이터 통합 시스템 및 방법은 유저 인터페이스와 서비스 지향 아키텍처 사이에 지능형 자동화 계층을 더 포함할 수 있으며, 지능형 자동화 계층은 컨텍스트 특정 콘텐츠를 유저 인터페이스의 유저에게 제공한다. 데이터 통합 시스템 및 방법은 런 타임 엔진을 위한 런 타임 최적화 계층을 더 포함할 수 있으며, 런 타임 최적화 계층은 런 타임 엔진 사이에 프로세스를 자동으로 할당한다.

다른 태양에서, 유저 인터페이스를 데이터 통합 시스템에 제공하는 방법은, 서비스 지향 아키텍처 내에 복수의 데이터 통합 시스템을 제공하는 단계와; 강하게 분리된 유저 인터페이스에 모듈식 제어를 제공하는 단계와; 그 제어를 서비스 지향 아키텍처의 하나 이상의 서비스와 관련짓는 단계와; 하나 이상의 서비스를 태스크로서 유저 인터페이스의 제어에 제시하는 단계를 포함한다. 데이터 통합 프로세스를 위한 유저 인터페이스 시스템은 서비스 지향 아키텍처 내의 복수의 데이터 통합 서비스와; 모듈식 제어를 갖는 강하게 분리된 유저 인터페이스 - 여기서, 유저 인터페이스는 하나 이상의 데이터 통합 서비스를 태스크로서 유저 인터페이스의 제어에 제시함 - 와; 유저 인터페이스의 제어를 서비스 지향 아키텍처의 하나 이상의 서비스와 관련짓는 태스크 매트릭스를 포함할 수 있다.

서비스는 공유된 메타데이터와의 라이브 관계를 가질 수 있다. 공유된 메타데이터에의 변경은 공유된 메타데이터의 다른 유저에게 즉각 가시적일 수 있다. 유저 인터페이스는 컨텍스트 감지 도움을 포함할 수 있다. 서비스는 외부 소스-코드 제어 시스템으로의 커넥터를 포함할 수 있다. 서비스는 매핑(mapping), 데이터 정제(data cleansing), 및 데이터 보강(data enrichment)의 적어도 하나를 포함할 수 있다. 유저 인터페이스는 태스크 지향적일 수 있다. 유저 인터페이스는 스킬 레벨 감지형 또는 역할 감지형일 수 있다. 역할은 감시, 개발, 및/또는 오퍼레이션 제어를 포함할 수 있다. 유저 인터페이스는 그것을 통하여 접속될 수 있는 모든 서비스를 스패닝(spanning)하는 통합 세션 히스토리를 포함할 수 있다. 유저 인터페이스는 유저 정의형일 수 있다. 유저 인터페이스는 이동 장치상에서 사용하도록 채택될 수 있다. 모듈식 제어는 로우 레벨 제어의 라이브러리에 제공될 수 있다. 방법 및 시스템은 재사용가능한 다이얼로그(dialog)의 라이브러리를 제공하는 단계를 포함할 수 있다.

데이터 통합 시스템 내의 서비스를 제공하기 위한 서비스 지향 아키텍처는, 서비스를 동적으로 위치 및 예시하기 위한 서비스 디렉토리 - 여기서, 서비스는 툴(tool), 외부 리소스 커넥터를 서비스로서 노출하는 컴포넌트 서비스, 및 리포지토리 내에 저장된 메타데이터를 접속하기 위한 하나 이상의 리포지토리 서비스로 구성되는 복수의 이산적인 재사용가능하고 공유가능한 서비스를 포함함 - 와; 서비스를 사용하는 데이터 통합 프로세스의 유저 디자인을 위한 분리된 유저 인터페이스를 포함한다. 데이터 통합 시스템 내의 서비스 지향 서비스를 제공하기 위한 방법은 복수의 서비스를 서비스 디렉토리에 등록하는 단계 - 여기서, 서비스는 , 외부 리소스 커넥터를 서비스로서 노출하는 컴포넌트 서비스, 및 리포지토리 내에 저장된 메타데이터를 접속하기 위한 하나 이상의 리포지토리 서비스로 구성되는 복수의 이산적인 재사용가능하고 공유가능한 서비스를 포함함 - 와, 복수의 서비스 중의 하나를 레지스트리 내에 동적으로 위치시키는 단계와; 위치된 복수의 서비스 중의 하나를 예시하는 단계와; 위치된 복수의 서비스 중의 하나를 사용하여, 데이터 통합 프로세스의 유저 디자인에 별도의 유저 인터페이스를 제공하는 단계를 포함한다.

하나 이상의 서비스는 내부 서비스 및/또는 외부 서비스일 수 있다. 서비스는 상이한 기술을 사용할 수 있다. 하나 이상의 서비스는 동기적 및/또는 비동기적일 수 있다. 서비스는 감사, 로깅(logging), 감시, 관리 및 운영, 보안, 유저 프로파일, 세선 관리 및 리포팅, 트랜잭션(transaction), 통합, 유저 디렉토리, 컴포넌트 서비스, 구성, 시스템 관리, 소스 제어, 소스 및 타깃 메타데이터의 임포트/익스포트, 메타데이터 질의, 접속, 분석, 리포팅 및 정기구독, 샘플 데이터, 데이터 프로파일링, 프로세스 편집, 프로세스 컴파일링, 데이터 유효화, 디자인 전개, 디자인 실행, 설치 및 업그레이드, 데모 셋업, 전개, 릴리스 관리, 동기화, 데이터 프로파일링, 데이터 정제, 조사 및 조정, 템플릿의 애플리케이션, 테스팅, 및 문제점 리포팅의 하나 이상을 제어하는 복수의 펑크션(function)을 포함할 수 있다.

다른 태양에서, 리포지토리 내의 메타데이터 모델을 공유하는 방법은, 메타데이터 모델을 리포지토리 내에 저장하는 단계와; 하나 이상의 리포지토리 서비스를 리포지토리 서비스의 동적 배치 및 예시를 위해 구성된 서비스 디렉토리 내에 등록하는 단계와; 서비스 지향 아키텍처 내의 하나 이상의 리포지토리 서비스 및 서비스 디렉토리를 전개하는 단계와; 하나 이상의 리포지토리 서비스의 적어도 하나를 통하여 메타데이터 모델에 접속하는 단계를 포함한다. 메타데이터 모델 리포지토리를 공유하는 시스템은, 적어도 하나의 메타데이터 모델을 저장하는 리포지토리와; 서비스 지향 아키텍처 내의 하나 이상의 리포지토리의 동적 배치 및 예시를 위해 구성된 서비스 디렉토리와; 하나 이상의 리포지토리 서비스의 적어도 하나를 통한 적어도 하나의 메타데이터 모델에의 공유된 접속을 위한 인터페이스를 포함한다.

하나 이상의 리포지토리 서비스는 하나 이상의 모델 등록, 임포트/익스포트, 버전 관리, 네비게이션 프로세스, 검색/질의 접속, 지속, 및 체크-인/체크-아웃 서비스를 포함할 수 있다. 리포지토리는 하나 이상의 개인 리포지토리, 팀 리포지토리, 프로젝트 리포지토리, 부서 기반 리포지토리, 엔터프라이즈 리포지토리, 중앙화된 리포지토리, 및 분산화된 리포지토리를 포함할 수 있다.

다른 태양에서, 데이터 통합 시스템을 외부 리소스에 접속하는 방법은, 데이터 통합 시스템을 서비스 지향 아키텍처 내의 복수의 서비스로서 전개하는 단계와; 하나 이상의 커넥터 컴포넌트를 데이터 통합 시스템의 서비스 디렉토리에 서비스로서 등록하는 단계 - 여기서, 각각의 커넥터 컴포넌트는 외부 리소스에 접속하도록 구성됨 - 와; 외부 리소스에의 접속을 확립하기 위하여, 데이터 통합 시스템 내로부터 서비스로서 커넥터 컴포넌트의 하나를 사용하는 단계를 포함한다. 데이터 통합 시스템을 외부 리소스에 접속하는 시스템은, 서비스 디렉토리와 복수의 서비스를 포함하는 서비스 지향 아키텍처와; 서비스 디렉토리 내에 서비스로서 등록된 하나 이상의 커넥터 컴포넌트 - 여기서, 각 커넥터 컴포넌트는 외부 리소스에 접속하도록 구성됨 -와; 외부 리소스에의 접속을 확립하기 위하여, 데이터 통합 시스템 내로부터 서비스로서 커넥터 컴포넌트의 하나를 사용하는 적어도 하나의 런 타임 엔진을 포함할 수 있다.

커넥터 컴포넌트는 외부 리소스 파일로의 모든 접속을 제공할 수 있다. 적어도 하나의 커넥터 컴포넌트는 변환 프로세스를 포함할 수 있다. 커넥터 컴포넌트는 데이터 통합 프로세스의 디자인 동안 및/또는 런 타임 동안에 이용가능할 수 있다. 커넥터 컴포넌트는 특정 외부 리소스에의 인터페이스를 포함할 수 있다. 외부 리소스에의 커넥션(connection)은 이벤트 리스닝(listening) 및 리소스 접속을 포함할 수 있다. 외부 리소스에의 커넥션은 지속적일 수 있다.

다른 태양에서, 데이터 통합 시스템을 여기에 기술한 외부 리소스에 접속하기 위한 방법은, 데이터 통합 시스템을 서비스 지향 아키텍처 내의 복수의 서비스로서 전개하는 단계와; 하나 이상의 커넥터를 서비스로서 데이터 통합 시스템의 서비스 디렉토리에 등록하는 단계 - 여기서, 각 커넥터 컴포넌트는 외부 리소스에 접속하도록 구성됨 - 와, 외부 리소스에의 접속을 확립하기 위하여, 데이터 통합 시스템 내로부터 서비스로서 커넥터 컴포넌트의 하나를 사용하는 단계를 포함할 수 있다.

커넥터 컴포넌트는 외부 리소스 파일로의 모든 접속을 제공할 수 있다. 적어도 하나의 커넥터 컴포넌트는 변환 프로세스를 포함할 수 있다. 커넥터 컴포넌트는 디자인 통합 프로세스의 디자인 동안에 이용가능할 수 있다. 커넥터 컴포넌트는 런 타임 동안에 이용가능할 수 있다. 커넥터 컴포넌트는 특정 외부 리소스에의 인터페이스를 포함할 수 있다. 외부 리소스로의 커넥션은 이벤트 리스닝 및 리소스 접속을 포함할 수 있다. 외부 리소스에의 커넥션은 지속적일 수 있다. 외부 리소스는 적어도 하나의 데이터 소스 또는 적어도 하나의 데이터 타깃을 포함할 수 있다. 커넥터 컴포넌트는 메타데이터로의 접속을 외부 리소스에 제공할 수 있다. 커넥터 컴포넌트는 데이터로의 접속을 외부 리소스에 제공할 수 있다.

다른 태양에서, 여기에 개시된 시스템은, 서비스의 디렉토리를 포함하는 서비스 지향 아키텍처와; 관련된 컴퓨터 프로그램 제품 슈트(suite)의 복수의 펑크션 - 여기서, 펑크션의 각각은 서비스의 디렉토리 내에 서비스로서 등록됨 - 과; 하나 이상의 서비스의 하나 이상의 인스턴스를 인보크(invoke) 하기 위한 인터페이스 - 이에 의해, 상기 관련 컴퓨터 제품 슈트는 서비스 지향 아키텍처로서 전개됨 - 를 포함할 수 있다.

관련된 컴퓨터 프로그램 제품 슈트는 데이터 통합 슈트를 포함할 수 있다. 펑크션은 감사, 로깅, 감시, 관리 및 운영, 보안, 유저 프로파일, 세선 관리 및 리포팅, 트랜잭션, 통합, 유저 디렉토리, 컴포넌트 서비스, 구성, 시스템 관리, 소스 제어, 소스 및 타깃 메타데이터의 임포트/익스포트, 메타데이터 질의, 접속, 분석, 리포팅 및 정기구독, 샘플 데이터, 데이터 프로파일링, 프로세스 편집, 프로세스 컴파일링, 데이터 유효화, 디자인 전개, 디자인 실행, 설치 및 업그레이드, 데모 셋업, 전개, 릴리스 관리, 동기화, 데이터 프로파일링, 데이터 정제, 조사 및 조정, 템플릿의 애플리케이션, 테스팅, 및 문제점 리포팅의 하나 이상을 포함할 수 있다. 하나 이상의 파라미터는 하나 이상의 서비스의 하나 이상의 인스턴스로 보내질 수 있다. 하나 이상의 서비스는 모든 관련된 컴퓨터 프로그램 제품에 공통인 적어도 하나의 공통 서비스를 포함할 수 있다.

다른 태양에서, 컴퓨터 프로그램 제품은 컴퓨터 판독 가능한 프로그램 코드를 포함하는 컴퓨터 사용 가능한 매체를 포함할 수 있으며, 컴퓨터 판독 가능한 프로그램 코드는 하나 이상의 컴퓨터 상에서 실행될 때, 하나 이상의 컴퓨터로 하여금 전술한 임의의 하나 이상의 방법을 실행하도록 한다.

여기에 사용된 "International Business Machines" 또는 "IBM"은 뉴욕 아르몽 소재의 "International Business Machines Corporation"을 칭한다.

여기에 사용되는 바와 같이, "데이터 소스" 또는 "데이터 타깃"은 그 용어와 일치하는 가능한 가장 광의의 의미를 갖도록 의도되며, 데이터베이스, 복수의 데이터베이스, 리포지토리 정보 매니저, 큐, 메시지 서비스, 리포지토리, 데이터 설비, 데이터 저장 설비, 데이터 제공자, 웹사이트, 서버, 컴퓨터, 컴퓨터 저장 설비, CD, DVD, 이동 저장 설비, 중앙 저장 설비, 하드 디스크, 복수 조정 데이터 저장 설비, RAM, ROM, 플래시 메모리, 메모리 카드, 임시 메모리 설비, 지속 메모리 설비, 자기 테이프, 국부적으로 접속된 연산 설비, 원격 접속된 연산 설비, 무선 설비, 유선 설비, 휴대용 설비, 중앙 설비, 웹 브라우저, 클라이언트, 랩탑, PDA, 전화기, 휴대폰, 이동 전화기, 정보 플랫폼, 분석 설비, 처리 설비, 비지니스 엔터프라이즈 시스템 또는 데이터가 취급되는 다른 설비, 또는 데이터나 정보뿐만 아니라 임의의 전술한 시스템에 사용되는 구축 또는 비구축된 데이터를 유지하기 위한 임의의 파일 또는 파일 타입을 저장하도록 제공된 다른 설비, 또는 스트리밍, 메시지, 이벤트 구동 또는 소스 데이터 및 특정 의미를 달리 지시하거나 어구의 문맥을 달리 지시하지 않는 한 전술한 임의의 조합을 포함할 수 있다. 저장 메커니즘은 임의의 물리적이거나 논리적 장치, 리소스, 또는 데이터 소스나 데이터 타깃으로서 역할할 수 있거나, 다르게는 검색가능한 형태로 데이터를 저장하는 설비이다.

"엔터프라이즈 자바 빈(EJB)"은 J2EE 플랫폼을 위한 서버측 컴포넌트 아키텍처를 포함한다. EJB는 분포되고, 트랜잭션적이며, 안전하고 이동가능한 자바 애플리케이션의 신속하고 단순한 전개를 지원한다. EJB는 메시지의 동시적인 소모를 허용하고, 분포된 트랜잭션을 위한 지원을 제공하는 컨테이너 아키텍처를 지지하여, 데이터베이스 갱신, 메시지 처리, 및 J2EE 아키텍처를 사용한 엔터프라이즈 시스템에의 접속이 동일한 트랜잭션 컨텍스트에 참여할 수 있다.

"JMS"는 자바 기반 J2EE 엔터프라이즈 아키텍처를 위한 엔터프라이즈 메시지인 자바 메시지 서비스(Java Message Service)를 의미한다. "JCA"는 이하에 상세히 기술할 J2EE 플랫폼의 J2EE 커넥터 아키텍처를 의미한다. EJB, JMS 및 JCA는 동시적으로 분포된 트랜잭션 환경에서의 공통으로 사용된 소프트웨어 툴 일지라도, 유사한 기능성을 제공하는 임의의 플랫폼, 시스템, 또는 아키텍처가 여기에 기술한 데이터 통합 시스템에 채용될 수 있다.

여기에 사용되는 바와 같은 "실시간"은 비지니스 트랜잭션 또는 비지니스의 기간에 근접하는 기간을 포함하고, 나이트 배치(nightly batch) 처리 오퍼레이션에서와 같이 오프 라인으로 발생하는 것과 대조적으로 비지니스 오퍼레이션 또는 비지니스 프로세스 동안에 발생하는 프로세스 또는 서비스를 포함한다. 비지니스 프로세스의 기간에 따라서, 실시간은 초, 초의 일부, 분, 시간, 또는 심지어 하루를 포함한다.

여기에 사용되는 바와 같은 "비지니스 프로세스", "비지니스 논리" 및 "비지니스 트랜잭션"은 판매, 마케팅, 풀필먼트(fulfillment), 재고 관리, 가격책정, 제품 디자인, 전문적 서비스, 금융 서비스, 관리, 파이낸스, 채권인수, 분석, 계약, 정보 기술 서비스, 데이터 저장, 데이터 마이닝, 정보의 전달, 상품의 라우팅, 스케줄링, 통신, 투자, 트랜잭션, 제공, 프로모션, 광고, 오퍼(offer), 엔지니어링, 제조, 공급 체인 관리, 인력 자원 관리, 데이터 처리, 데이터 통합, 워크플로우 관리, 소프트웨어 제조, 하드웨어 제조, 신상품 개발, 검색, 개발, 전략 펑크션, 품질 제어 및 보증, 패키징, 로지스틱스, 고객 관계 관리, 환불 및 반품 관리, 고객 지원, 제품 유지, 텔레마케팅, 협동 통신, 투자자 관계 등을 포함하여(비한정적임) 비지니스에 의해서 수행될 수 있는 임의의 방법, 서비스, 오퍼레이션, 프로세스 또는 트랜잭션을 포함한다.

여기에 사용되는 바와 같은 "서비스 지향 아키텍처(SOA)"는 비지니스 엔터프라이즈의 인프라구조의 일부를 형성하는 서비스를 포함한다. SOA에서, 서비스는 신속한 애플리케이션 개발을 허용하고 중복 코드를 회피하는 애플리케이션 개발 및 전개를 위한 빌딩 블록(building block)이 될 수 있다. 각각의 서비스는 서비스를 위한 데이터 입력의 소스 또는 서비스의 데이터 출력을 위한 타깃과 같은 주변환경에 구속될 수 있는 비지니스 논리 또는 비지니스 룰(rule)의 세트를 실시할 수 있다. SOA의 각종 인스턴스는 이하의 설명에 제공된다.

여기에 사용되는 바와 같은 "메타데이터"는 처리되는 데이터에 컨텍스트를 가져오는 데이터, 데이터에 관한 데이터, 관련 정보의 컨텍스트에 관한 정보, 데이터의 기원에 관한 정보, 데이터의 위치에 관한 정보, 데이터의 의미에 관한 정보, 데이터의 나이에 관한 정보, 데이터의 헤딩에 관한 정보, 데이터의 유닛에 관한 정보, 데이터의 필드에 관한 정보, 데이터의 컨텍스트에 관한 임의의 다른 정보에 관한 정보를 포함한다.

여기에 사용되는 바와 같은 "WSDL" 또는 "웹 서비스 기술 언어(Web Services Description Language)"는 문서 지향 또는 프로지서 지향 정보를 포함하는 엔드포인트 오퍼레이팅의 세트로서 네트워크 서비스(종종 웹 서비스)를 기술하기 위한 XML 포맷을 포함한다. 오퍼레이션 및 메시지는 요약적으로 기술되며, 엔드포인트(endpoint)를 정의하기 위하여 구체적인 네트워크 프로토콜 및 메시지 포맷으로 구속된다. 관련된 구체적인 엔드포인트는 요약 엔드포인트(서비스)로 조합된다. WSDL은 어느 메시지 포맷 또는 네트워크 프로토콜이 통신에 사용되는지에 관계없이 그들 메시지 및 엔드포인트의 기술을 허용하도록 확장적이다.

도 1은 각각이 복수의 상이한 컴퓨터 애플리케이션 및 데이터 소스를 포함할 수 있는 복수의 비지니스 프로세스를 갖는 비지니스 엔터프라이즈의 개략도이다.

도 2는 비지니스 엔터프라이즈의 복수의 비지니스 프로세스에 걸친 데이터 통합을 도시하는 개략도이다.

도 3은 복수의 데이터 소스에 대한 데이터 통합을 비지니스 프로세스에 제공 하기 위한 아키텍처를 도시하는 개략도이다.

도 4는 데이터 통합 작업을 위한 탐색 설비(discovery facility)의 세부 사향을 도시하는 개략도이다.

도 5는 데이터 통합 프로세스를 위한 탐색 스텝을 실행하기 위한 스텝을 도시하는 순서도이다.

도 6은 데이터 통합 프로세스를 위한 정제 설비(cleansing facility)를 도시하는 개략도이다.

도 7은 데이터 통합 프로세스를 위한 정제 프로세스를 위한 스텝을 도시하는 순서도이다.

도 8은 데이터 통합 프로세스를 위한 변환 설비(transformation facility)를 위한 개략도이다.

도 9는 데이터 통합 프로세스의 일부로서 데이터를 변환하기 위한 스텝을 도시하는 순서도이다.

도 10은 그래픽 유저 인터페이스를 사용하여 모델링된 저당 데이터(mortgage data)를 위한 변환 프로세스의 예를 도시한다.

도 11a은 데이터 통합 프로세스를 비지니스 엔터프라이즈의 다른 프로세스에 접속하기 위한 복수의 접속 설비를 도시하는 개략도이다.

도 11b는 브릿지 모델(bridge model)을 사용하는 복속의 접속 설비를 도시한다.

도 12는 데이터 통합 프로세스를 비지니스 엔터프라이즈의 다른 프로세스에 접속하기 위한 스텝을 도시하는 순서도이다.

도 13은 데이터 통합 시스템을 포함하는 엔터프라이즈 연산 시스템을 도시한다.

도 14a는 데이터 통합 작업에서 메타데이터(metadata)의 관리를 나타낸다.

도 14b는 데이터 통합 작업에 사용될 수 있는 영역 지향 프로그래밍(aspect oriented programming) 환경을 나타낸다.

도 15는 데이터 통합 작업과 연계하여 메타데이터 설비를 사용하기 위한 부가적인 스텝을 도시하는 순서도이다.

도 16은 데이터 통합 작업과 연계하여 메타데이터 설비를 사용하기 위한 부가적인 스텝을 도시하는 순서도이다.

도 16a는 데이터 통합 작업과 연계하여 메타데이터 설비를 사용하기 위한 부가적인 스텝을 도시하는 순서도이다.

도 17은 데이터 통합 프로세스의 복수의 프로세스의 병렬 실행(parallel execution)을 위한 설비를 도시하는 개략도이다.

도 18은 데이터 통합 프로세스의 복수의 프로세스를 병렬 실행하기 위한 스텝을 도시하는 순서도이다.

도 19는 복수의 데이터 소스로부터의 입력과 복수의 데이터 타깃으로부터의 출력을 포함하는 데이터 통합 작업을 도시하는 개략도이다.

도 20은 복수의 데이터 소스로부터의 입력과 복수의 데이터 타깃으로부터의 출력을 포함하는 데이터 통합 작업을 도시하는 개략도이다.

도 21은 비지니스 엔터프라이즈를 위한 데이터 관리자가 데이터 통합 작업을 디자인하게 할 수 있게 하는 그래픽 유저 인터페이스를 도시한다.

도 22는 데이터 관리자가 데이터 통합 작업을 디자인할 수 있게 하는 그래픽 유저 인터페이스의 다른 실시예를 도시한다.

도 23은 실시간 데이터 통합 서비스 설비를 데이터 통합 프로세스와 일체화시키기 위한 아키텍처의 개략도이다.

도 24는 비지니스 엔터프라이즈를 위한 서비스 지향 아키텍처를 도시하는 개략도이다.

도 25는 SOAP 메시지 포맷을 도시하는 개략도이다.

도 26은 웹 서비스를 위한 WSDL 기술(description)의 엘리먼트를 도시하는 개략도이다.

도 27은 엔터프라이즈를 위한 실시간 데이터 통합 프로세스를 가능하게 하는 엘리먼트를 도시하는 개략도이다.

도 28은 실시간 통합 서비스를 가능하게 하는 서버의 일 실시예를 도시하는 도면이다.

도 29는 통상적인 J2EE 서버의 아키텍처 및 기능을 도시한다.

도 30은 RTI 서비스를 관리하기 위한 RTI 콘솔(console)을 나타낸다.

도 31은 RTI 서비스를 가능하게 하는 아키텍처의 세부 사항을 더 도시한다.

도 32는 RTI 서비스의 내부 아키텍처의 개략도이다.

도 33은 RTI 서버와 RTI 에이전트의 상호작용의 태양을 도시한다.

도 34는 금융 서비스 비지니스에 사용되는 RTI 서비스를 도시한다.

도 35는 엔터프라이즈가 RTI 서비스를 사용하여 고객 기록을 어떻게 갱신할 수 있는지를 도시한다.

도 36은 마스터 고객 데이터베이스를 포함하는 데이터 통합 시스템을 나타낸다.

도 37은 데이터 변환, 유효화 및 표준화 루틴의 세트를 실시할 수 있는 RTI 서비스를 도시한다.

도 38은 실시간 통합 서비스를 접속하는 애플리케이션을 나타낸다.

도 39는 데이터 통합 서비스 없이 채권 인수 프로세스(underwriting process)를 도시한다.

도 40은 RTI 서비스를 채용하는 채권 인수 프로세스를 도시한다.

도 41은 복수의 RTI 서비스를 사용하는 엔터프라이즈를 도시한다.

도 42는 실시간 통합 서비스를 사용하는 운송 브로커 비지니스를 도시한다.

도 43은 드라이버가 예컨대, 휴대용 장치를 이용하여 웹 서비스에 접속할 수 있는 애플리케이션을 지지하는 데이터 통합 서비스의 세트를 설명한다.

도 44는 금융 리포팅에 사용되는 데이터 통합 시스템을 도시한다.

도 45는 소매 비지니스에서 신뢰 있는 고객 데이터베이스를 유지하는데 사용되는 데이터 통합 시스템을 도시한다.

도 46은 약품 공업에서 사용되는 데이터 통합 시스템을 도시한다.

도 47은 제조 비지니스에서 사용되는 데이터 통합 시스템을 도시한다.

도 48은 임상 시험 연구 결과를 분석하는데 사용되는 데이터 통합 시스템을 도시한다.

도 49는 과학 연구 데이터의 검토를 위해 사용되는 데이터 통합 시스템을 도시한다.

도 50은 복수의 비지니스 시스템에 걸쳐 고객 데이터를 관리하는데 사용되는 데이터 통합 시스템을 도시한다.

도 51은 인바운드(inbound) 고객 데이터와 존재하는 고객 기록과의 온 디멘드, 자동 매칭을 제공하는데 사용되는 데이터 통합 시스템을 도시한다.

도 52는 데이터 통합 서비스를 위한 아키텍처의 하이 레벨 개략도를 도시한다.

도 52a는 복수의 태스크(task)로서 유저 인터페이스를 정의하기 위한 태스크 매트릭스를 도시한다.

도 53은 GUI의 보다 상세한 개략도를 도시한다.

도 54는 아키텍처에서의 관계 및 SOA 역할의 UML 다이어그램을 도시한다.

도 55는 아키텍처를 위한 SOA 환경의 개략도를 도시한다.

도 56은 저장 서비스에서의 모델의 개략도를 도시한다.

도 57은 저장 서비스 아키텍처의 개략도를 도시한다.

도 58은 컴포넌트와 구성 모델의 고위 레벨 UML 클래스 다이어그램을 도시한다.

도 59는 구성 모델의 EIL 예를 도시한다.

도 60은 클라이언트, 서비스 및 컴포넌트 사이의 UML 클래스 다이어그램을 도시한다.

도 61은 일 컴포넌트로부터 다른 컴포넌트로 통과될 때의 데이터 표현의 개략도를 도시한다.

도 62는 아키텍처를 위한 공통 변환 골격구조를 도시한다.

도 63은 아키텍처를 위한 접속성을 도시한다.

후술하는 설명에 걸쳐, 특별히 달리 지시하지 않는 한 동일한 요소 번호는 동일한 요소를 칭하도록 의도된다.

여기에 개시된 본 발명은 전적인 하드웨어 실시예, 전적인 소프트웨어 실시예, 또는 하드웨어와 소프트웨어 컴포넌트 양쪽을 포함하는 실시예의 형태를 취할 수 있다. 바람직한 실시예에서, 본 발명은 한정적이지는 않지만, 펌웨어, 상주 소프트웨어, 마이크로코드 등을 포함하는 소프트웨어로 실행된다.

또한, 본 발명은 임의의 명령어 실행 시스템 또는 컴퓨터에 의해 또는 그것과 연계하여 사용하기 위한 프로그램 코드를 제공하는 컴퓨터 이용가능 또는 컴퓨터 판독 가능 매체로부터 접속가능한 컴퓨터 프로그램 제품의 형태를 취할 수 있다. 설명을 위해, 컴퓨터 이용가능 또는 컴퓨터 판독가능 매체는 명령어 실행 시스템, 장치, 또는 디바이스에 의해 또는 그것과 연계하여 사용하기 위한, 프로그램의 저장, 통신, 전파, 또는 전송을 포함할 수 있는 임의의 장치일 수 있다.

매체는 전자(電子), 자기(磁氣), 광(光), 전자기(電磁氣), 적외선 또는 반도 체 시스템(또는 장치 또는 디바이스) 또는 전파 매체일 수 있다. 컴퓨터 판독가능 매체의 예는 반도체나 고체 메모리, 자기 테이프, 분리가능 컴퓨터 디스켓, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 강성 자기 디스크 및 광 디스크를 포함한다. 광 디스크의 현재의 예는 콤팩트 디스크 판독 전용 메모리(CD-ROM), 컴팩 디스크 판독/기록(CD-R/W) 및 DVD를 포함한다.

프로그램 코드를 저장 및/또는 실행하기에 적합한 데이터 처리 시스템은 시스템 버스를 통하여 메모리 컴포넌트에 직접적으로 또는 간접적으로 결합되는 적어도 하나의 프로세스를 포함할 것이다. 메모리 컴포넌트는 프로그램 코드의 실제 실행 동안에 채용되는 로컬 메모리와, 벌크 스토리지를 포함할 수 있으며, 타임 코드(time code)의 수를 줄이기 위하여 적어도 일부 프로그램 코드의 임시 저장을 제공하는 캐시 메모리가 실행중 벌크 스토리지로부터 검색되어야만 한다.

입력/출력 또는 I/O 장치(키보드, 디스플레이, 포인팅 장치 등을 포함하지만 그것에 한정되지 않음)는 시스템에 직접적으로 또는 개재하는 I/O 컨트롤러를 통하여 접속될 수 있다.

데이터 처리 시스템이 개재하는 사설 또는 공중 네트워크를 통하여 다른 데이터 처리 시스템 또는 원격 프린터나 저장 장치에 데이터 처리 시스템이 결합될 수 있게 하기 위해 네트워크 어댑터(adaptor)가 시스템에 결합될 수 있다. 모뎀, 케이블 모뎀 및 이더넷 카드(ethernet card)는 현재 이용가능한 단지 몇몇 네트워크 어댑터이다.

도 1은 비지니스 엔터프라이즈의 각종 데이터의 통합을 실행하기 위한 플랫 폼(platform)(100)을 나타낸다. 플랫폼은 복수의 비지니스 프로세스를 포함하며, 그 프로세스의 각각은 복수의 상이한 컴퓨터 애플리케이션 및 데이터 소스를 포함할 수 있다. 플랫폼은 전술한 것과 같은 몇몇 데이터 소스(102)를 포함할 수 있다. 데이터 소스는 여러 물리적 위치로부터의 여러 데이터 타입을 포함할 수 있다. 예컨대, 데이터 소스는 Sybase, Microsoft, Informix, Oracle, Inlomover, EMC, Trillium, First Logic, Siebel, PeopleSoft, IBM, Apache, 또는 Netscape와 같은 공급자로부터의 시스템을 포함할 수 있다. 데이터 소스(102)는 IMS, DB2, ADABAS, VSAM, MD 시리즈, UDB, XML, 복합 플랫 파일(complex flat file), 또는 FTP 파일과 같은 데이터베이스 제품 또는 표준을 사용하는 시스템을 포함할 수 있다. 데이터 소스(102)는 Microsoft Outlook, Microsoft Word, Microsoft Excel, Mocrosoft Access와 같은 애플리케이션에 의해서 사용되거나 생성되는 파일뿐만 아니라, ASCII, CSV, GIF, TIF, PNG, PDF 등과 같은 표준 포맷의 파일을 포함할 수 있다. 데이터 소스(102)는 각종 위치로부터 오거나, 중심적으로 위치될 수 있다. 데이터 소스(102)로부터 공급되는 데이터는 각종 형태로 오거나, 다른 것과 서로 호환되거나 호환되지 않을 수 있는 다른 포맷을 가질 수 있다.

이하의 설명에서 데이터 타깃을 기술한다. 일반적으로, 이러한 데이터 타깃은 전술한 임의의 데이터 소스(102)일 수 있다. 그 차이점은 명명적으로 데이터 시스템이 데이터를 제공하거나 데이터 통합 프로세스 내의 데이터를 수신하는지의 여부를 통상적으로 나타낸다. 하지만, 통상적인 데이터 통합 시스템에서 데이터 소스는 데이터를 수신할 수 있고 데이터 타깃은 데이터를 제공할 수 있기 때문에, 이러한 차이는 (특별히 달리 언급하지 않는 한) 데이터 소스와 데이터 타깃 사이의 자격에서의 임의의 차이를 수반하도록 의도된 것은 아님을 이해해야 한다.

도 1에 도시된 플랫폼은 데이터 통합 시스템(104)을 또한 도시한다. 데이터 통합 시스템은 예컨대, 데이터 통합 시스템(104)이 수신하는 질의 또는 검색 명령의 결과로서 데이터 소스(102)로부터의 데이터 수집을 촉진할 수 있다. 데이터 통합 시스템(104)은 데이터 소스가 데이터를 데이터 통합 시스템(104)에 제공하도록 하나 이상의 데이터 소스(102)에 명령을 전송할 수 있다. 수신된 데이터는 다양한 메타데이터를 포함하는 복수의 포맷일 수 있기 때문에, 데이터 통합 시스템은 수신된 데이터가 일체적인 처리를 위해 나중에 결합될 수 있도록 그 데이터를 재구성할 수 있다. 데이터 통합 시스템(104)에 의해서 수행될 수 있는 기능은 이하에서 더욱 상세히 기술된다.

플랫폼(100)은 몇몇 검색 시스템(108)을 또한 포함할 수 있다. 검색 시스템(108)은 데이터 통합 시스템(104)으로부터 전송된 데이터를 추가로 조작하기 위해 사용되는 처리 플랫폼 또는 데이터베이스를 포함할 수 있다. 예컨대, 데이터 통합 시스템(104)은 검색 시스템(108)이 비지니스에 유용한 리포트(110)를 생성하는데 처리 데이터를 사용할 수 있도록 데이터 소스(102)로부터 수신한 데이터를 정화, 결합, 변환 또는 조작할 수 있다. 리포트(110)는 데이터 결합, 응답 복합 질의, 응답 단순 질의를 보고하거나, 또는 비지니스나 유저에 유용한 다른 리포트를 형성하는데 사용될 수 있으며, 원(原) 데이터, 테이블, 차트, 그래프, 및 검색 시스템(108)으로부터의 데이터의 임의의 다른 표현을 포함할 수 있다.

플랫폼(100)은 데이터베이스 또는 데이터 베이스 관리 시스템(112)을 또한 포함할 수 있다. 데이터베이스(112)는 정보를 일시적으로 또는 지속적이거나 장기간 저장을 위해서 저장하는데 사용될 수 있다. 예컨대, 데이터 통합 시스템(104)은 하나 이상의 데이터 소스(102)로부터의 데이터를 수집하고, 그 데이터를 서로 호환되거나 서로 결합되도록 호환되는 다른 형태로 변환할 수 있다. 데이터가 일단 변환되면, 데이터 통합 시스템(104)은 그 데이터를 분해된 형태, 결합된 형태 또는 나중의 검색을 위한 다른 형태로 데이터베이스(112)에 저장할 수 있다.

도 2는 비지니스 엔터프라이즈의 복수의 엔티티 및 비지니스 프로세스에 걸친 데이터 통합을 도시하는 개략도이다. 도시된 실시예에서, 데이터 통합 시스템(104)은 유저 인터페이스 시스템(202)과 데이터 소스(102) 사이의 정보 흐름을 촉진한다. 데이터 통합 시스템(104)은 인터페이스 시스템(202)으로부터 질의를 수신할 수 있고, 그 질의는 하나 이상의 데이터 소스(102)에 상주하는 데이터의 추출 및/또는 변환을 필요로 한다. 인터페이스 시스템(202)은 랩탑 또는 데스크탑 컴퓨터, 휴대 전화, PDA(personal digital assistant), 네크워크된 플랫폼 및 그것에 부착된 장치, 또는 데이터 통합 시스템(104)과 인터페이스 하는 다른 장치나 시스템상에서 오퍼레이팅하는 웹 브라우저와 같이 데이터 통합 시스템(104)과 통신하기 위한 임의의 장치나 프로그램을 포함할 수 있다.

예컨대, 유저는 WiFi 또는 WAP/WML(wireless access protocol/wireless markup language) 인터페이스를 통하여 데이터 통합 시스템(104)에 정보를 요구하거나 PDA를 오퍼레이팅할 수 있다. 데이터 통합 시스템(104)은 요구를 수신할 수 있고, 웹사이트나 FTP 파일 사이트와 같은 다른 데이터 소스(102)로부터의 정보에 액세스하기 위한 임의의 요구된 질의를 생성할 수 있다. 데이터 소스(102)로부터의 데이터는 추출되어, 요구 인터페이스 시스템(202)(본 예에서는 PDA)과 호환되는 포맷으로 변환된 후, 유저 뷰잉(viewing) 및 조작을 위해 인터페이스 시스템(202)에 전송될 수 있다. 다른 실시예에서, 데이터는 데이터 소스로부터 미리 추출되어, 데이터 웨어하우스(warehouse) 또는 데이터 통합 시스템(104)에 의해서 사용되는 다른 데이터 설비인 별도의 데이터베이스(112)에 저장될 수 있다. 데이터는 변환된 상태 또는 그것의 원래 상태로 데이터베이스(112)에 저장될 수 있다. 예컨대, 데이터는 복수의 데이터 소스(102)로부터의 데이터가 다른 변환 프로세스에서 결합될 수 있도록 변환 상태로 저장될 수 있다. 예컨대, PDA로부터의 질의는 데이터 통합 시스템(104)에 전송될 수 있고, 그 데이터 통합 시스템(104)은 데이터베이스(122)로부터 정보를 추출할 수 있다. 추출 후, 데이터 통합 시스템(104)은 데이터를 PDA로의 전송 이전에 PDA와 호환되는 결합된 포맷으로 변환할 수 있다.

도 3은 비지니스 엔터프라이즈에 복수의 데이터 소스(102)를 위한 데이터 통합을 제공하기 위한 아키텍처를 도시하는 개략도이다. 데이터 통합 시스템(104)의 실시예는 가능하게는 다른 프로세스 중에서, 데이터 소스로부터의 데이터 추출 및 소스 데이터를 위한 테이블 구조 및 칼럼(column) 값의 분석을 수행하기 위한 탐색 데이터 스테이지(302)를 포함할 수 있다. 탐색 데이터 스테이지(302)는 테이블 구조, 관계 및 데이터 타깃을 위한 키(key)에 관한 권고(recommendation)를 또한 생성할 수 있다. 더욱 정교한 프로파일링(profiling) 및 감사(auditing) 기능은 데 이터 범위 유효화, 연산의 정확도, 평가의 정확도 등을 포함할 수 있다. 탐색 데이터 스테이지(302)는 소스 데이터 내의 중복적인 종속성 및 변형을 제거하는 등에 의해 데이터를 표준화할 수 있다. 탐색 데이터 스테이지(302)는 추가의 분석 또는 메인프레임 데이터의 직접적인 프로파일링을 위하여, 데이터 소스(102) 내의 예외(exception)에 대한 드릴 다운(drill down)과 같은 부가적인 기능을 제공할 수 있다. 탐색 데이터 스테이지(302)의 상업적 실시예의 비한정예는 어센셜(Ascential)사의 프로파일스테이지 제품에서 발견될 수 있다.

데이터 통합 시스템(104)은 데이터가 준비되고, 표준화되고, 매치되고, 다른 경우에 나중에 변환될 품질 데이터(quality data)를 생성하도록 조작되는 데이터 준비 스테이지(304)를 또한 포함할 수 있다. 데이터 준비 스테이지(304)는 데이터 내의 불일치 조정과 올바른 매치(일대일 매치, 일대 다수 매치, 및 중복)에 대한 점검과 같은 공통 데이터 품질 기능을 수행할 수 있다. 데이터 준비 스테이지(304)는 특정 데이터 강화 기능을 또한 포함할 수 있다. 예컨대, 데이터 준비 스테이지(304)는 향상된 국제 통신을 위해 어드레스가 다국적 우편 기준에 순응하게 보장할 수 있다. 데이터 준비 스테이지(304)는 공간 정보 관리를 위해 위치 데이터를 다국적 좌표부여 표준(geocoding standard)에 순응시킬 수 있다. 데이터 준비 스테이지는 어드레스 정보가 정부 인증 미국 어드레스 커렉션(Goverment Certified U.S. Address Correction) 하에서 미국 우편 서비스 메일 레이트 디스카운트에 적격이 되게 보장하기 위해 어드레스에 수정을 하거나 부가할 수 있다. 적절히 어드레스된 메일을 위해 디스카운트 레이트를 제공하는 캐나다 및 호수 우편 시스템을 위해 유사한 분석 및 데이터 수정이 제공될 수 있다. 데이터 준비 스테이지(304)의 상업적 실시예의 비한정예는 어센셜사의 퀄리티스테이지(QualityStage) 제품에서 발견될 수 있다.

데이터 통합 시스템은 데이터를 변환하고, 보강하고, 변환된 데이터를 전달하는 데이터 변환 스테이지(308)를 또한 포함할 수 있다. 데이터 변환 스테이지(308)는 데이터의 재조직 및 재포맷과 같은 변환 서비스를 수행할 수 있고, 시스템 유저의 알고리즘 및 비지니스 규칙에 기초한 연산을 수행할 수 있다. 데이터 변환 스테이지(308)는 특정 분석적인 컨텍스트(context) 내의 데이터의 더욱 고도로 조정된 처리를 위한 데이터 마트(datamart) 또는 큐브(cube)로서 알려진 서브세트(subset)로 타깃 데이터(target data)를 조직화할 수도 있다. 데이터 변환 스테이지(308)는 데이터 통합 시스템(104)에 의해서 사용되는 각종 데이터 소스 및 데이터 타깃의 각종 소프트웨어 및 하드웨어 아키텍처를 파악하기 위하여 브릿지(bradge), 변환(translation) 기기 및 다른 인터페이스(일반적으로 후술하는 바와 같은)를 채용할 수 있다. 데이터 변환 스테이지(308)는 그래픽 유저 인터페이스, 명령 라인 인터페이스, 또는 이들의 조합을 플랫폼(100)에 걸쳐 데이터 통합 작업을 디자인하기 위해 포함할 수 있다. 데이터 변환 스테이지(308)의 상업적인 실시예의 비한정 예는 어센셜사의 데이터스테이지(DataStage) 제품에서 발견할 수 있다.

데이터 통합 시스템(104)의 스테이지(302, 304, 308)는 시스템의 성능을 최적화하기 위해, 병렬 실행 시스템(310) 또는 직렬 또는 조합 방식으로 실행될 수 있다.

데이터 통합 시스템(104)은 데이터 소스(102)와 결합된 메타데이터를 관리하기 위한 메타데이터 관리 시스템(312)을 또한 포함할 수 있다. 일반적으로, 메타데이터 관리 시스템(312)은 데이터 통합 환경 내의 모든 툴에 걸쳐 메타데이터의 상호교환, 통합, 관리, 및 분석을 위해 제공할 수 있다. 예컨대, 어센셜사의 'ODBC MetaBroker', 'CA ERwin', 'Ascential ProfileStage', 'Ascential DataStage', 'Ascential QualityStage', 'IBM DB2 Cube Views', 및 'Cognos Impromptu'와 같은, 분산 소스 내의 데이터의 공통의 보편적 접속가능한 뷰(view)를 제공할 수 있다. 메타데이터 관리 시스템(312)은 데이터 구조에 대한 변경을 위한 영향 분석과 데이터 계통을 위한 분석 툴을 또한 제공할 수 있다. 메타데이터 관리 시스템(312)은 데이터 통합 시스템(104) 내의 데이터를 위한 데이터 정의, 알고리즘, 및 비지니스 컨텍스트의 비지니스 데이터 용어집을 준비하는데 추가로 사용될 수 있으며, 그 용어집은 엔터프라이즈를 통한 사용을 위해 반포될 수 있다. 메타데이터 관리 시스템(312)의 상업적 실시예의 비한정 예는 어센셜사의 메타스테이지(MetaStage) 제품에서 발견할 수 있다.

도 4는 데이터 통합 작업을 위한 탐색 데이터 스테이지(302)를 실행하는 설비의 상세를 도시하는 개략도이다. 본 실시예에서, 탐색 데이터 스테이지(302)는 데이터베이스(402) 내의 데이터의 콘텐츠 및 구조를 결정하기 위하여, 전술한 임의의 데이터 소스(102)일 수 있는 데이터베이스(402)에 질의한다. 데이터베이스(402)는 탐색 데이터 스테이지(302)에 결과를 제공하며, 탐색 데이터 스테이 지(302)는 데이터 통합 시스템(104)의 다른 부위로의 추출 데이터의 후속 전송을 촉진한다. 일 실시예에서, 탐색 데이터 스테이지(302)는 데이터 통합 시스템(104)이 데이터를 정제하고 데이터를 중앙 데이터베이스나 리포지토리(repository) 정보 관리자에게 통합할 수 있도록 여러 데이터 소스(102)에 질의할 수 있다.

도 5는 데이터 통합 프로세스(500)의 탐색 스텝을 수행하기 위한 스텝을 도시하는 순서도이다. 특정 통합 프로세스(500)를 이하에 기술하지만, 여기에 사용되는 바와 같은 데이터 통합 프로세스(500)는 데이터 소스(102), 데이터 타깃, 데이터베이스(112), 데이터 통합 시스템(104), 및 여기에 기술된 다른 컴포넌트를 사용하는 임의의 프로세스를 칭할 수 있다. 일 실시예에서, 예시적인 탐색 스텝을 위한 프로세스 스텝은, 전술한 바와 같은 탐색 데이터 스테이지(302)와 같은 탐색 설비가 하나 이상의 데이터 소스(102)로부터 데이터를 추출하는 명령을 수신하는 제1 스텝 502를 포함할 수 있다. 추출 명령의 수신 후, 탐색 설비는 스텝 504에 나타낸 바와 같이 추출될 데이터가 상주하는 적절한 데이터 소스(102)를 식별할 수 있다. 데이터 소스(102)는 그 명령에서 식별되거나 식별되지 않을 수 있다. 데이터 소스(102)가 식별되면, 탐색 설비는 식별된 데이터 소스(102)에 질의할 수 있다. 데이터 소스(102)가 그 명령에서 식별되지 않으면, 탐색 설비는 데이터 추출 명령으로부터 요구된 데이터의 타입으로부터 또는 명령 내의 정보의 다른 부분으로부터, 또는 요구된 다른 데이터에의 결합을 판정한 후에, 데이터 소스(102)를 판정할 수 있다. 예컨대, 질의는 고객 어드레스를 위한 것일 수 있으며, 고객 어드레스 데이터의 제1 부위는 제1 데이터 소스(102)에 상주할 수 있으며, 제2 부위는 제 2 데이터 소스(102)에 상주할 수 있다. 탐색 설비는 추출 명령을 처리할 수 있으며, 명령에서의 추가의 지령 없이 그것의 추출 활동을 두 개의 데이터 소스(102)로 향하게 할 수 있다. 데이터 소스(102)가 일단 식별되면, 스텝 508에 도시된 바와 같이, 데이터 설비는 데이터를 추출하기 위한 프로세스를 실행할 수 있다. 데이터가 일단 추출되면, 탐색 설비는 데이터 통합 시스템의 다른 부위로의 데이터 전송을 촉진할 것이다.

도 6은 데이터 통합 프로세스(500)의, 전술한 바와 같은 데이터 준비 스테이지(304)일 수 있는 정제 설비를 도시하는 개략도이다. 일반적으로, 몇몇 데이터 소스(102)로부터 오는 데이터는 부정확할 수 있고, 이러한 부정확함은, 점검되지 않고 교정되지 않으면, 데이터 통합 시스템(104)에 의해서 궁극적으로 생성되는 데이터의 설명에 에러를 야기할 수 있다. 회사 합병, 취득, 재조직화 및 데이터 소스(102)의 다른 통합은 새로운 데이터 라벨, 머리글자, 메트릭, 연산 방법 등을 가져와서 데이터 품질 이슈를 더 합성할 수 있다. 도 6에 도시된 바와 같이, 정제 설비는 데이터 소스(102)로부터 데이터(602)를 수신할 수 있다. 데이터(602)는 하나 이상의 데이터 소스(102)로부터 올 수 있으며, 불일치하거나 부정확할 수 있다. 정제 설비는 스크린, 교정, 정제하거나, 다른 경우에 데이터(602)의 품질을 향상시키기 위하여 자동화, 반자동화, 또는 수동 설비를 제공할 수 있다. 데이터(602)가 정제 설비를 일단 통과하면, 데이터 통합 시스템(104)의 다른 부위에 전송된다.

도 7은 데이터 통합 프로세스(500) 내의 정제 프로세스(700)를 위한 스텝을 도시하는 순서도이다. 일 실시예에서, 정제 프로세스는 하나 이상의 데이터 소 스(102)로부터 (예컨대, 탐색 설비를 통하여) 데이터를 수신하는 스텝 702를 포함할 수 있다. 정제 프로세스(700)는 하나 이상의 데이터 정제 방법을 포함할 수 있다. 예컨대, 프로세스는 데이터를 자동으로 정제하는 스텝 704를 포함할 수 있다. 프로세스는 데이터를 반수동으로 정제하는 스텝 708을 포함할 수 있다. 프로세스는 데이터를 수동으로 정제하는 스텝 710을 포함할 수 있다. 데이터 또는 데이터 일부를 자동으로 교정하거나 정제하는 스텝 704는 자동 스펠 체크 및 교정, 데이터 비교, 데이터의 타임 라인 비교, 데이터의 상태 비교와 같은 몇몇 기술, 또는 데이터 품질 및 일치성을 향상시키기 위한 다른 기술을 포함할 수 있다. 반자동적으로 데이터를 정제하는 스텝 708은 유저가 프로세스 스텝의 일부와 상호작용하고 시스템이 할당된 태스크의 정제를 자동으로 수행하는 설비를 포함할 수 있다. 반자동 시스템은 그래픽 인터페이스 프로세스 스텝 712를 포함할 수 있으며, 유저는 데이터를 정제하기 위하여 프로세스(700)를 촉진하기 위하여 그래픽 유저 인터페이스와 상호작용한다. 프로세스(700)는 데이터를 수동으로 교정하는 스텝 710을 또한 포함할 수 있다. 이 스텝은 데이터의 수동 교정, 통합 및/또는 정제를 촉진하기 위하여 유저 인터페이스의 사용을 또한 포함할 수 있다. 정제 프로세스(700)로부터 정제된 데이터는 데이터 변환 스테이지(308)와 같은 데이터 통합 시스템의(104)의 다른 설비에 전송될 수 있다.

도 8은 전술한 바와 같이, 데이터 통합 프로세스(500)를 위한 데이터 변환 스테이지(308)일 수 있는 변환 설비를 도시하는 개략도이다. 변환 설비는 정제 설비로부터 정제된 데이터(802)를 수신하여 변환 프로세스를 수행할 수 있고, 그 데 이터를 보강하고, 그 데이터를 통합된 데이터가 뷰 되고, 사용되며, 추가로 변환되거나 달리 조작되는 데이터 통합 시스템(104)의 외부 또는 데이터 통합 시스템(104) 내의 다른 프로세스로 전달할 수 있다. 예컨대, 유저는 데이터 마이닝(data mining)을 통하여 조사하거나, 유저 또는 비지니스에 유용한 리포트를 생성할 수 있다.

도 9는 데이터 통합 프로세스(500)의 일부로서 데이터를 변환하는 스텝을 도시하는 순서도이다. 변환 프로세스(900)는 스텝 902에 나타낸 바와 같이, (예컨대, 전술한 데이터 준비 스테이지(308)로부터) 정제된 데이터를 수신하는 스텝을 포함할 수 있다. 스텝 904에 나타낸 바와 같이, 프로세스(900)는 원하는 변환의 타입을 결정할 수 있다. 변환 프로세스를 결정하는 스텝 904 후에, 스텝 908에 나타낸 바와 같이 변환 프로세스가 실행될 수 있다. 변환 데이터는 스텝 910에 나타낸 바와 같이 다른 설비로 전송될 수 있다.

일반적으로, 데이터 통합 시스템(104)은 제어될 수 있고 그래픽 유저 인터페이스를 사용하여 특정 엔터프라이즈 데이터에 적용될 수 있다. 인터페이스는 데이터 소스, 데이터 타깃, 데이터 상에서 작용하는 스테이지나 프로세스를 모델링하기 위한 비주얼 툴(visual tool)뿐만 아니라, 원하는 데이터 통합 태스크를 모델링하기 위하여 데이터 엔티티 사이의 관계를 확립하는 툴을 포함할 수 있다. 그래픽 유저 인터페이스는 나중에 상세히 설명한다. 이하에서는, 유저 인터페이스가 본 컨텍스트에서 어떻게 사용되는지를 기술하는 일반적인 예를 제공한다.

도 10은 그래픽 유저 인터페이스(1018)를 사용하여 모델링된 저당 데이터를 위한 변환 프로세스(1000)의 일 예를 설명한다. 본 예에서, 비지니스 엔터프라이즈는 특정 저당에 관한 보고를 생성하기를 원한다. 저당 밸런스 정보(mortage balance information)는 전술한 데이터 소스(102)의 하나일 수 있는 저당 데이터베이스 내에 상주할 수 있고, 자산 정보의 주소와 같은 개인 정보는 전술한 데이터 소스(102)의 하나일 수 있는 자산 데이터베이스 내에 상주할 수 있다. 그래픽 유저 인터페이스(1018)는 변환 프로세스를 조직화하기 위해 제공될 수 있다. 예컨대, 유저는 저당 데이터베이스(1002)의 그래픽 표현과 자산 데이터베이스(1012)의 그래픽 표현을 선택하고, 그 표현(1002, 1012)을 예컨대, 통상적인 드래그(drag) 및 드롭(drop) 오퍼레이션을 이용하여 인터페이스(1018) 내의 위치 내로 조작한다. 그 후, 유저는 열 변환 프로세스(1004)의 그래픽 표현을 선택하여 조합을 위한 열을 준비할 수 있다. 데이터베이스로부터의 데이터가 열 변환 프로세스로 흘러가도록, 유저는 일반적으로 도 10에서 화살표로 나타낸 프로세스 흐름 방향을 드래그 또는 드롭할 수 있다. 이러한 모델에서, 유저는 임의의 매치되지 않은 파일을 제거하도록 결정하고 그것을 저장 설비로 전송할 수 있다. 이를 달성하기 위해, 유저는 저장 설비(6114)의 그래프 표현을 인터페이스(1018) 내에 위치시킬 수 있다. 유저가 남아있는 매치된 파일을 추가로 처리하기를 원하는 경우, 유저는 예컨대, 두 데이터베이스로부터의 데이터를 결합하는 다른 변환 및 응집 프로세스(aggregation process)(1008)의 그래픽 표현을 부가할 수 있다. 마지막으로, 유저는 데이터 웨어하우스(1010)의 그래픽 표현을 부가함으로써 응집 데이터를 저장 설비에 전송하도록 결정할 수 있다. 유저가 그래픽 유저 인터페이스를 사용하여 그러한 프로세스를 셋업하면, 유저는 변환 프로세스를 구동시킬 수 있다.

도 11은 데이터 통합 프로세스(500)를 비지니스 엔터프라이즈의 다른 프로세스에 접속하기 위한 복수의 접속 설비를 도시하는 개략도이다. 일 실시예에서, 데이터 통합 시스템(104)은 전술한 데이터 소스(102)의 하나일 수 있는 통합 저장 설비(1102)와 결합될 수 있다. 통합 저장 설비(1102)는 몇몇 다른 데이터 소스(102)로부터 추출되고 데이터 통합 시스템(104)을 통과한 데이터를 포함할 수 있다. 통합된 데이터는 하나 이상의 컴퓨터 플랫폼(1108A 및 1108B)이 통합된 데이터 저장 설비(1102)로부터 데이터를 검색할 수 있게 허용하는 형태로 저장될 수 있다. 연산 플랫폼(1108A 및 1108B)은 통합된 데이터 설비(1102)로부터의 데이터를 변환 엔진(1104A 및 1104B)을 통하여 요구할 수 있다. 예컨대, 각각의 연산 플랫폼(1108A 및 1108B)은 별도의 변환 엔진(1104A 및 1104B)과 결합될 수 있다. 변환 엔진(1104A 및 1104B)은 저장 설비(1102)로부터의 통합된 데이터를 결합된 연산 플랫폼(1108A 및 1108B)과 호환되는 형태로 변환하도록 채택될 수 있다. 일 실시예에서, 변환 엔진(1104A 및 1104B)은 데이터 통합 시스템(104)과 결합될 수도 있다. 이러한 결합은 요구된 정보로 변환 엔진(1104A 및 1104B)을 갱신하는데 사용될 수 있다. 이러한 프로세스는 이하에서 추가로 정의되는 메타데이터의 핸들링을 또한 포함할 수 있다.

도 11a에 일반적으로 도시한 바와 같은 데이터 통합을 위한 허브 모델(hub model)이 상이한 연산 플랫폼(1108A, 1108B) 및 다른 데이터 소스(102)에 접속하기 위한 하나의 모델이지만, 도 11b를 참조하여 기술한 브릿지 모델과 같은 다른 모델 이 사용될 수 있다. 여기에 기술한 데이터 소스(102)에의 접속은 컨텍스트에 의해 특정되거나 달리 지시되지 않는 한, 그러한 모델의 하나 또는 다른 모델이 사용될 수 있다는 것을 이해해야 한다.

도 11b는 브릿지 모델을 사용하는 복수의 접속 설비를 도시한다. 이러한 시스템에서, 재고 시스템(inventory system), 고객 관계 시스템 및 어카운팅 시스템(accounting system)과 같은 복수의 데이터 소스(102)는 복수의 브릿지(1120) 또는 접속 설비를 통하여 엔터프라이즈 연산 시스템(1300)에 접속될 수 있다. 각 브릿지(1120)는 외부 데이터 소스(102)에 메타데이터 모델을 제공하고, 데이터 통합 시스템(104)과 데이터 소스(102) 사이에 정보의 쌍방향 전달을 가능하게 하는 벤더(vendor) 특정 변환 엔진일 수 있다. 엔터프라이즈 통합 벤더는 자기의 데이터 소스(102)를 위한 사유 포맷을 가질 수 있고, 그리하여 각각의 상이한 외부 모델에 대하여 상이한 브릿지(1120)가 요구될 수 있다. 각 브릿지(1120)는 데이터 소스(102) 내의 모든 데이터 또는 일부 데이터에의 접속 설비를 제공할 수 있고, 별도의 맵(map) 또는 모델이 각 데이터 소스(102)와의 접속을 위해 유지될 수 있다. 또한, 각 브릿지(1120)는 에러 점검, 조정, 또는 데이터 소스(102) 사이에서의 데이터 통합을 유지하기 위한 다른 서비스를 제공할 수 있다. 이러한 방식으로 상호 접속된 데이터 소스(102)에서, 데이터는 시스템 사이에서 공유되거나 조정될 수 있고, 각종 데이터 통합 태스크는 데이터 소스가 단일 데이터 소스(102) 또는 웨어하우스로 형성될지라도 데이터 소스(102) 내의 데이터 상에서 수행될 수 있다.

도 12는 데이터 통합 프로세스(500)를 비지니스 엔터프라이즈의 다른 프로세 스에 접속하는 스텝을 도시하는 순서도이다. 일 실시예에서, 접속 프로세스는 중앙 저장 설비에서 처리된 데이터를 데이터 통합 시스템(104)이 저장하는 스텝 1202를 포함한다. 데이터 통합 시스템(104)은 스텝 1204에서 하나 이상의 변환 엔진을 갱신할 수도 있다. 도 12의 설명은 직렬로 일어나는 프로세스를 도시하지만, 그 프로세스는 병렬로, 또는 이들의 일부 조합으로 일어날 수도 있다. 프로세스는 연산 플랫폼이 데이터 요구를 생성하고 그 데이터 요구가 결합된 변환 엔진에 전송되는 스텝 1208을 포함할 수 있다. 스텝 1210은 변환 엔진이 저장 설비로부터 데이터를 추출하는 것을 수반한다. 변환 엔진은 스텝 1212에서 데이터를 연산 플랫폼과 호환되는 형태로 변환할 수 있으며, 데이터는 스텝 1214에서 연산 플랫폼에 전송될 수 있다.

도 13은 데이터 통합 시스템(104)을 포함하는 엔터프라이즈 연산 시스템(1300)을 도시한다. 엔터프라이즈 연산 시스템(1300)은 하나 이상의 로컬 영역 네트워크를 통한 국부적인 접속된 및/또는 예컨대, 인터넷을 통한 가상 사설 네트워크를 사용하는 하나 이상의 광역(wide area) 또는 공중 네트워크를 통한 원격 접속된 컴퓨터, 메인프레임, 이동 장치, 데이터 소스, 및 다른 장치의 임의의 조합을 포함할 수 있다. 엔터프라이즈 연산 시스템(1300) 내의 장치는 데이터, 리소스, 통신, 및 정보 기술 관리를 공유하기 위하여 단일 엔터프라이즈에 접속될 수 있다. 통상적으로, 엔터프라이즈 연산 시스템(1300) 내의 리소스는 회사, 단체, 정부 기구 또는 대학교와 같은 공통 엔티티에 의해서 사용된다. 하지만, 특정 비지니스 모델에서, 엔터프라이즈 연산 시스템(1300)의 리소스는 애플리케이션 서비스 제공 자가 원격 실행 애플리케이션에 온 디멘드(on demand) 접속을 제공하는 경우와 같이, 복수의 상이한 엔티티에 의해서 소유되고 사용된다(또는 임대된다).

엔터프라이즈 연산 시스템(1300)은 각각의 변환 엔진(1308)(브릿지-기반 시스템에서는 전술한 브릿지(1120)일 수 있음)을 통하여 리포지토리 정보 관리자(RIM; repository information manager)(1304)라고 칭하는(또한, 이하에서는 "허브"라고도 함) 공통 데이터 구조에 접속하는 복수의 툴(1302)을 포함할 수 있다. RIM(1304)은 전술한 임의의 데이터 소스(102)를 포함할 수 있다. 3개의 변환 엔진(1308) 및 3개의 툴(1302)이 도시되지만, 3 이하의 수 및 3보다 현저히 많은 수를 포함하는 임의 수의 변환 엔진(1308) 및 툴(1302)이 하나의 엔터프라이즈 연산 시스템(1300) 내에서 사용될 수 있다는 것을 이해해야 한다. 툴(1302)은 예컨대, 다양한 타입의 데이터베이스 관리 시스템 및 RIM(1304) 내에 저장된 공유 데이터에 접속하는 다른 애플리케이션 프로그램을 일반적으로 포함한다. 툴(1302), RIM(1304) 및 변환 엔진(1308)은 단일 컴퓨터 시스템상에서 처리되고 유지될 수 있거나, 예컨대, 상이한 컴포넌트(1302, 1304, 1308) 사이에서 데이터 접속 요구, 변환된 데이터 접속 욕구, 및 응답을 전달하는 네트워크(도시 생략)에 의해서 상호접속될 수 있는 복수의 컴퓨터 시스템상에서 처리되고 유지될 수 있다.

실행중인 동안에, 툴(1302)은 데이터 접속 오퍼레이션, 즉, RIM(1304) 내의 데이터저장 또는 데이터로부터의 데이터 검색을 개시하기 위한 데이터 접속 요구를 생성할 수 있다. 데이터는 후술하는 원자 데이터 모델(atomic data model) 또는 포맷으로 RIM(1304) 내에 저장될 수 있다. 통상적으로, 툴(1302)은 후술하는 바와 같이 각종의 다양한 특성 데이터 모델 및 포맷으로 RIM(1304) 내에 저장된 데이터를 뷰 할 수 있을 것이며, 데이터 접속 요구를 수신 시, 각 변환 엔진(1308)은 필요한 경우 각 툴의 특성 모델 및 포맷과 RIM(1304)의 원자 모델 및 포맷 사이에서 데이터를 변환할 것이다. 예컨대, 데이터 아이템이 RIM(1304)으로부터 검색되는 검색 타입의 접속 구동 동안에, 변환 엔진(1308)은 접속 요구에 응하여 검색될 데이터 아이템을 포함하는 RIM(1304) 내의 하나 이상의 원자 데이터 아이템을 식별하고, RIM(1304)이 변환 엔진(1308)의 하나에 원자 데이터 아이템을 제공할 수 있게 할 것이다. 변환 엔진(1308)은 RIM(1304)으로부터 수신한 원자 데이터 아이템을 툴의 특성 모델 및 포맷, 또는 데이터의 "뷰"에 의해 요구되는 하나 이상의 데이터 아이템으로 응집하고, 그 응집된 데이터를 접속 요구를 발한 툴(1302)에 제공할 것이다. RIM(1304) 내의 데이터가 갱신되는 데이터 저장 동안에, 변환 엔진(1308)은 툴(1302)의 하나를 위한 특성 모델 및 포맷으로 저장될 데이터를 수신할 수 있다. 변환 엔진(1308)은 데이터를 RIM(1304)을 위한 원자 모델 및 포맷으로 변환하고, 그 변환된 데이터를 저장을 위해 RIM(1304)에 제공할 수 있다. 데이터 저장 접속 요구가 데이터가 갱신될 수 있게 하는 경우, RIM(1304)은 현재 데이터를 변환 엔진(1308)으로부터 새롭게 공급된 데이터로 대체할 수 있다. 한편, 데이터 저장 접속 요구가 새로운 데이터를 나타내는 경우, RIM(308)은 그 데이터를 변환 엔진(1308)에 의해서 제공된 바와 같은 원자 포맷으로 RIM(1308) 내의 현재 데이터에 부가할 수 있다.

엔터프라이즈 연산 시스템(1300)은 새로운 툴(1302)이 그 시스템(1300)에 부 가될 때 변환 엔진(1308) 및 RIM(1304)의 원자 포맷을 유지하고 갱신하는 데이터 통합 시스템(104)을 더 포함한다. 데이터 통합 시스템(104)에 의해서 수행되는 특정 오퍼레이션은 자동 또는 수동 제어되어 수행될 수 있다는 것을 이해해야 한다. 간단히 말해서, 시스템(1300)이 초기에 확립되거나 하나 이상의 툴(1302)이 데이터 모델 및 포맷이 현재의 데이터 모델 및 포맷과 다른 시스템(1300)에 부가되는 경우, 데이터 통합 시스템(104)은 차이점을 판정하고, 새로운 툴(1302)의 데이터 모델 및 포맷을 수용하기 위해서 RIM(1304) 내의 데이터의 데이터 모델 및 포맷을 수정할 수 있다. 그러한 구동에서, 데이터 통합 시스템(1304)은 부가될 새로운 툴(1302)과 현재 시스템(1300) 내에 있는 임의의 툴(1302)의 데이터 모델에 공통인 원자 데이터 모델을 결정하고, RIM(1304)의 데이터 모델이 새로운 원자 데이터 모델로 갱신되게 할 수 있다. 또한, 데이터 통합 시스템(104)은 RIM(1304)의 갱신된 원자 데이터 모델에 기초하여 현재 시스템(1300) 내의 임의의 툴(1302)과 결합된 변환 엔진(1308)을 갱신할 수 있고, 또한 새로운 툴(1302)을 위한 변환 엔진(1308)을 생성할 수 있다. 따라서, 데이터 통합 시스템(104)은 부가될 툴(1302) 뿐만 아니라, 현재 시스템 내의 임의의 툴(1302)을 포함하는 모들 툴(1302)의 변환 엔진(1308)이 RIM(1304)의 원자 모델 및 포맷에 순응하는 것을 보장한다.

추가의 진행 이전에, RIM(1304)에 유용한 원자 모델 및 포맷과, 각종 툴(1302)에 유용할 수 있는 특성 데이터 모델 및 포맷을 설명하는 특정 예를 제공하는 것이 도움이 될 것이다. 툴(1302)을 위한 특정 특성 데이터 모델 및 포맷은 현재 특정 엔터프라이즈 연산 시스템(1300) 내에 있는 특정 툴(1302)에 의존할 것 이라는 것이 이해될 것이다. 또한, RIM(1304)을 위한 특정 원자 데이터 모델 및 포맷은 툴(1302)에 사용된 원자 데이터 모델 및 포맷에 의존할 것이며, 시스템(1300) 내의 툴(1304)의 포맷 및 데이터 모델의 미립 컴포넌트의 응집 또는 결합을 나타낼 수 있다는 것을 이해될 것이다.

도 14a는 음료 컵이나 액체를 유지하기 위한 다른 컨테이너와 같은 컵을 위한 설계의 데이터베이스에 관련한 예를 제공한다. 데이터베이스는 컵을 디자인하고 제조하기 위해 사용될 수 있다. 이러한 애플리케이션에서, 툴(1302)은 디자인 도면, 치수, 외면 처리, 컬러, 재료, 핸들(또는 그것의 부재), 비용 데이터 등과 같은 컵 설계 컴포넌트를 RIM(1304)에 부가하는데 사용될 수 있다. 툴(1302)은 RIM(1302)에 저장된 컵 디자인 컴포넌트를 수정하고, RIM(1304) 내의 특정 컵 디자인 컴포넌트를 재사용하고 복수의 상이한 컵 디자인과 결합하는데 사용될 수 있다. RIM(1304) 및 변환 엔진(1308)은, 복수의 상이한 툴(1302)이 컴포넌트에 대한 공통 스키마(schema)나 모델 및 포맷 구성에 합의할 필요없이 RIM(1304) 내에 저장된 컴포넌트를 공유할 수 있는 메커니즘을 제공할 수 있다.

이러한 예에서, RIM(1304)은 후술하는 데이터 아이템을 엔티티 관계 포맷으로 저장할 수 있으며, 후술하는 바와 같이, 각각의 엔티티는 데이터 아이템이며, 관계는 데이터 아이템 사이의 관계를 반영한다. 엔티티는 객체(object) 지향 환경 내의 서브클래스(subclass) 및 클래스(class)의 인스턴스(instance) 또는 멤버일 수 있는 객체의 형태이다. 다른 모델 및 포맷이 RIM(1304)을 위해 사용될 수 있다는 것은 이해될 것이다.

도 14a는 컵 디자인 데이터베이스를 위한 예시적인 메타데이터 구조를 도시한다. 클래스 구조는 하나의 메인 클래스(1402)와, 메인 클래스(1402)에 의존하는 컨테이너 및 핸들을 위한 두 개의 서브클래스(1404)와, 컨테이너 서브클래스(1404)에 의존하는 사이드 및 베이스를 위한 두 개의 저위 레벨 서브클래스(1408)를 포함할 수 있다. 엔티티 관계 포맷에서 "엔티티"를 칭하는 클래스(1402) 내의 각 데이터 아이템은 재고 내의 컵의 특정 타입이나 특정 컵을 나타낼 수 있고, 컵의 각종 특징을 정의하는 관련 속성(attribute)을 가질 것이며, 각 속성은 특정 속성 식별자 및 속성용 데이터 값에 의해서 식별된다.

엔티티 관계 포맷에서 또한 "엔티티"인 핸들 및 컨테이너 서브클래스(1404) 내의 각 데이터 아이템은 재고 내의 컵의 타입 또는 특정 컵의 컨테이너 및 핸들 특징을 나타낼 수 있다. 더욱 상세하게는, 컨테이너 서브클래스(1404) 내의 각 데이터 아이템은 컬러, 측벽 특징, 베이스 특징 등과 같은 컵 클래스(1402) 내의 데이터 아이템에 의해서 나타내지는 컵의 컨테이너 특징을 나타낼 수 있다. 또한, 핸들 서브클래스(1404) 내의 각 데이터 아이템은 곡률, 조직, 컬러, 위치 등과 같은 컵 클래스(1402) 내의 데이터 아이템에 의해서 나타내진 컵의 핸들 특징을 나타낼 수 있다. 또한, 서브클래스(1404) 사이의 데이터 아이템을 링크(link)하는 컨테이너 서브클래스(1404)와 핸들 서브클래스(1404) 내의 데이터 아이템 사이의 하나 이상의 관계가 존재할 수 있다는 것은 이해될 것이다.

예컨대, 컨테이너가 핸들을 갖는지의 여부를 나타내는 관계가 존재할 수 있다. 추가적으로 또는 그것에 대체하여, 컨테이너가 얼마나 많은 핸들을 갖는지를 나타내는 관계가 존재할 수 있다. 또한, 컨테이너 상의 핸들의 위치를 특정하는 위치 관계가 존재할 수 있다. 수 및 위치 관계는 제1 관계(컨테이너가 핸들을 갖는)의 특성으로서 또는 별도의 관계로서 뷰 될 수 있다. 두 개의 저위 레벨 서브클래스(1408)는 컨테이너 서브클래스(1404)와 결합하고, 컨테이너의 각종 컴포넌트를 나타낼 수 있다. 도 14a에 도시된 예에서, 서브클래스(1408)는 컵 클래스(1402)의 컴포넌트를 각각 특정하는 측벽 타입 서브클래스(1408) 및 베이스 타입 서브클래스(1408)를 포함할 수 있다. 컨테이너 및 핸들과 같은 컵의 특징과 컵은 상세의 임의의 원하는 레벨을 이용하여 객체 지향 방식으로 정의될 수 있다는 것은 이해될 것이다.

도 14a에서는 명료히 도시하지 않았지만, 하나 이상의 변환 엔진(1308)은 데이터의 하나의 뷰를 필요로 하는 툴(1302)과, 상이한 포맷으로 데이터를 저장할 수 있는 RIM(1304) 사이의 통신을 조정할 수 있다는 것을 이해해야 한다. 더욱 일반적으로, 도 14a에 도시된 툴(1302)의 각각의 하나는 RIM(1304) 내에 저장된 컵 데이터를 뷰하기 위하여 다소 상이하거나 완전히 상이한 특성 데이터 모델 및 포맷을 가질 수 있다. 즉, 데이터 아이템이 컵인 경우, 컵의 특징은 그 데이터 아이템과 관련된 컵 디자인을 위한 속성 및 속성값(attribute value)으로서 RIM(1304) 내에 저장될 수 있다.

검색 접속 요구에서, 툴(1302)은 검색될 컵 클래스(1402) 내의 컵 데이터 아이템의 식별을 관련 변환 엔진(1308)에 저장할 수 있고, 요구에서 응하여 식별될 수 있는 데이터 아이템의 속성 데이터의 적어도 일부를 수신하도록 기대할 것이다. 유사하게, 저장 타입의 접속 요구에 응하여, 그러한 툴은 그것들의 관련 변환 엔진(1308)에 갱신되거나 생성될 컵 데이터 아이템의 식별 및 새로운 데이터 아이템을 생성하는데 사용되거나 갱신되는 관련 속성 정보를 제공할 것이다.

다른 툴(1302)은 컨테이너 및 핸들을 위한 속성을 갖는 메인 컵 클래스(1402)보다는, 서브클레스(1404) 내의 컨테이너 및 핸들 엔티티로서 별도로 컵을 뷰 하는 특성 데이터 모델 및 포맷을 가질 수 있다. 그러한 뷰에서, 두 개의 데이터 아이템, 즉, 각 컵과 관련된 "컨테이너" 및 "핸들"가 존재할 수 있으며, 그것의 각각은 각 컨테이너 및 핸들을 기술하는 속성을 갖는다. 그러한 경우에, 각 데이터 아이템은 독립적으로 검색되고 갱신될 수 있으며, 새로운 데이터 아이템은 두 클래스의 각각을 위해서 개별적으로 생성될 수 있다. 그러한 뷰를 위해서, 툴(1302)은 검색 타입의 접속 요구에서, 그것들의 관련 변환 엔진(1308)에 검색될 컨테이너 또는 핸들의 식별을 제공하고, 응하여 데이터 아이템의 속성 데이터를 수신하기를 기대할 것이다. 유사하게, 저장 타입의 접속 요구에 응하여, 그러한 툴(1302)은 그것의 관련 변환 엔진(1308)에 갱신되거나 생성될 "컨테이너" 또는 "핸들" 데이터 아이템의 식별과 관련 속성 데이터를 제공할 것이다. 따라서, 그러한 툴(1302)은 컨테이너 및 핸들을 개별적으로 뷰 하고, 핸들 및 핸들 속성 데이터를 개별적으로 검색, 갱신 및 저장할 수 있다.

RIM(1304) 내의 동일한 원자 데이터 구조를 사용하는 다른 예로서, 툴(1302)은 클래스(1402-1408) 내의 측벽, 베이스 및 핸들 엔티티로서 컵을 개별적으로 뷰 하는 특성 데이터 포맷을 가질 수 있다. 그러한 뷰에서, 3개의 데이터 아이템, 즉, 각 컵과 관련된 측벽, 베이스 및 핸들이 있을 수 있으며, 그것의 각각은 컵의 측벽, 베이스 및 핸들을 기술하는 속성을 갖는다. 그러한 경우에, 각 데이터 아이템은 독립적으로 생성, 검색 또는 갱신될 수 있다. 그러한 뷰를 위해, 툴(1302)은 데이터 아이템이 오퍼레이팅될 측벽, 베이스 또는 핸들의 식별을 관련 변환 엔진(1308)에 제공할 수 있고, 각각을 위해서 오퍼레이션(예컨대, 생성, 검색, 저장)을 독립적으로 수행할 것이다.

전술한 바와 같이, RIM(1304)은 컵 데이터를 "원자" 데이터 모델 및 포맷으로 저장할 수 있다. 즉, 도 14a에 기술한 바와 같은 클래스 구조에서, RIM(1304)은 데이터를 각 클래스 및 서브클래스에 대응하는 데이터 아이템으로서, 수집 툴(1302)에 의해서 채택된 클래스 구조에 가장 상세한 포맷을 반영하는 데이터 구조와 같이, 일관적인 데이터 구조로 저장한다.

변환 엔진(1308)은, RIM(1304) 내의 원자 데이터 구조와 툴(1302)에 의해 사용된 데이터의 뷰 사이의 관계에 기초하여, 각각의 툴(1302)에 의해서 유지된 뷰와 RIM(1304)에 의해서 유지된 원자 데이터 구조 사이에서 변환할 수 있다. 변환 엔진(1308)은 툴(1302) 뷰와 RIM(1304) 데이터 구조 사이에서 변환할 때 복수의 기능을 수행할 수 있다. 그러한 기능은 클래스 또는 서브클래스의 결합, 속성 이름 또는 식별자의 변환, 속성값의 생성 또는 제거 등이 있다. 요구된 변환은 데이터 아이템의 생성, 데이터 아이템의 검색, 데이터 아이템의 삭제, 또는 데이터 아이템의 수정과 같이 복수의 컨텍스트에서 일어날 수 있다. 새로운 툴(1302)이 데이터 통합 시스템(104)에 부가될 때, 시스템(104)은 RIM(1304) 내의 데이터 구조뿐만 아니 라, 새로운 툴(1302)에 필요할 수 있는 변환 엔진(1308)을 갱신할 수 있다. 새로운 툴(1302)을 수용하기 위해 RIM(1304) 내에 사용된 하부 데이터 구조가 변경되는 경우, 또는 다른 이유로 인하여 데이터 구조가 재조직화되는 경우에, 현존 변환 엔진(1308)은 또한 갱신될 필요가 있을 것이다.

더욱 일반적으로, 데이터 통합 시스템(104)이 새로운 요구 또는 현존 요구에 관한 새로운 생각에 적응되는 경우, 시스템(104)은 데이터에 대한 새로운 원자 모델을 생성하도록 RIM(1304)을 위한 하부 데이터 구조를 갱신하고 재생성할 수 있다. 동시에, 변환 엔진(1308)은 툴(1302)을 RIM(1304)의 새로운 데이터 구조에 재매핑하도록 수정될 수 있다. 이러한 후자 기능은 새롭게 구성된 데이터 구조에 특별히 관련된 변환 엔진(1308)만을 포함할 수 있고, 다른 것은 수정 없이 계속 사용될 수 있다. 데이터 통합 시스템(104)을 사용하는 오퍼레이터(operator)는 각각의 툴(1308)에 의해서 사용된 데이터 모델 및 포맷과, RIM(1304)에 의해서 사용된 데이터 모델 및 포맷 사이의 매핑 관계를 결정하고 특정할 수 있으며, 각각의 변환 엔진(1308)을 생성하고 갱신하는데 사용될 수 있는 매핑 관계로부터의 룰 데이터베이스를 유지할 수 있다.

RIM(1304)을 통한 갱신의 정확한 진행을 보장하기 위해서, 데이터 통합 시스템(104)은 각 툴(1302)을, 관련 데이터 아이템이 "마스터 물리적 아이템" 및 필요한 경우 다른 데이터 아이템에의 특정 관계로 간주될 수 있는 클래스와 관련지을 수 있다. 예컨대, 데이터 통합 시스템(104)은 툴의 데이터 모델의 객체와 가장 의미론적으로 동등하게 보이는 특정 클래스를 마스터 물리적 아이템으로서 선택할 수 있다. 만약에 있다면, 마스터 물리적 아이템과 관련된 다른 데이터 아이템이 그래프에서 2차 물리적 아이템으로 간주될 수 있다. 예컨대, 컵 클래스는 전체 컵 디자인에서 오퍼레이팅하는 툴(1302)을 위한 마스터 물리적 아이템을 포함할 수 있다. 도 14a에서 "관계"로 지시된 화살표는 마스터 물리적 아이템과 2차 물리적 아이템 사이의 가능한 관계를 보여준다. 갱신 오퍼레이션의 수행시, 갱신될 데이터 아이템과 관련된 방향성 그래프(directed graph)는 마스터 물리적 아이템으로부터 갱신된 적절한 속성 및 값과 트래버스(traverse)할 수 있다. 방향성 그래프를 트래버스할 때, 통상적인 그래프 트래버싱(traversing) 알고리즘은 그래프 노드로서의 그래프 내의 각 데이터 아이템이 적절히 방문되고 갱신되는 것을 보장하고, 그리하여 데이터 아이템이 갱신되는 것을 보장하기 위해 사용될 수 있다.

전술한 예는 객체 지향 프로그래밍 환경에서의 메타데이터 관리를 일반적으로 기술한다. 하지만, 각종 소프트웨어 패러다임(paradigm)이 엔터프라이즈 연산 시스템(1300) 내에서 유용하게 사용될 수 있다는 것은 이해될 것이다. 예컨대, 영역 지향 프로그래밍 시스템을 도 14b를 참조하여 기술하며, 전술한 엔터프라이즈 연산 시스템(1300)에 용이하게 사용될 수 있다. 펑크션(function)(1410)을 갖는 툴(1302)의 예가 도면에 도시된다. 각각의 펑크션(1410)은 ID 로깅(logging)(1412), 메타데이터 갱신(1414)과 같은 몇몇 외부 서비스와 상호작용하도록 기록될 수 있다. 통상적인 객체 지향 환경에서, 외부 서비스(1412-1418)는 그것을 호출(call)하는 펑크션(1410)에 응답하기 위해 종종 "크로스 컷(crosscut)"되어야 하며, 즉, 툴(1302)의 갱신된 펑크션(1410)의 호출에 응답하도록 기록되어 야 한다.

예로서, 골격 코드에서, 로그인 및 유효화(validation)를 수행하는 펑크션(1410)을 위한 객체 지향 프로그래밍("OOP") 코드는 다음과 같을 수 있다:

데이터 유효화(…)

//유저 코드 로그인

//접속 코드 유효화

//다른 펑크션 사용 코드에 대하여 데이터 객체를 잠금(lock)

//〓〓〓 데이터 유효화 코드 〓〓〓

//유저 코드 로그 아웃

//데이터 객체 코드 해제(unlock)

//최근 접속 코드로 메타데이터를 갱신

//상기한 바와 동일한 다수의 오퍼레이션

상기 예에서, 펑크션(1410)의 코드는 외부 서비스(1410-1414)에 액션을 인보크(invoke) 한다. 소위 크로스 컷은 애플리케이션 라이터(writer)가 외부 서비스(1410-1414)를 리코드(recode)해야 할 때마다 발생하며, 코드의 적절한 상호 작용을 위해 요구될 수 있다. 이는 재디자인의 복잡도와, 에러에 대한 시간 및 잠재성을 현저히 포함시킬 수 있다.

영역 지향 프로그래밍(AOP)에서, 펑크션(1410)을 대한 결과 코드는 OOP 코드와 유사할 수 있다(실제, AOP는 C++과 같은 OOP 플랫폼을 사용하여 전개될 수 있다). 하지만, AOP 환경에서, 애플리케이션 라이터는 펑크션(1410)에 대해서 펑크 션 특정 논리만을 코드(code)하고, 논리가 외부 서비스(1412-1418)에 어떻게 접속하는지를 정의하기 위해서 위버 룰(weaver rule) 세트를 사용할 것이다. 위버 룰은 펑크션(1402)이 다른 서비스와 언제 그리고 어떻게 상호작용하는지를 기술하고, 그리하여, 툴(1302) 및 외부 서비스(1412-1418)를 동시에 위브한다. 펑크션(1410)에 대한 코드가 컴파일되면, 위버는 최종 펑크션(1410)을 생성하는 적절한 독립 서비스를 호출하기 위해서 코어 코드와 지지 코드(support code)를 결합할 것이다. 골격 코드에서, 펑크션(1410)에 대한 통상적인 AOP 코드는 다음과 같을 수 있다:

데이터 유효화(…)

//데이터 유효화 논리

크로스커팅 코드(corsscutting code)는 펑크션(1410)을 위한 코드로부터 제거된다. 애플리케이션 라이터는 AOP 코드에 적용하기 위하여 위버 룰을 생성할 수 있다. 골격 코드에서, 펑크션(1410)을 위한 위버 룰은 이하를 포함할 수 있다:

1) 각각의 오퍼레이션 개시시 ID 로그

2) 각각의 오퍼레이션 종료시 ID 로그 아웃

3) 최종 오퍼레이션 후 메타데이터 갱신

펑크션(1410)을 위한 결과적인 AOP 골격 코드는 이하와 같을 수 있다:

데이터 유효화(…)

- ID 로그인

//데이터 유효화 논리

- ID 로그 아웃

- 메타데이터 갱신

애플리케이션 라이터에 의해서 생성된 단순한 코드는 필요한 크로스커팅 코드에 대한 관심이 없이 툴(1302)을 생성하는데 모든 집중이 이루어지도록 허용할 수 있다. 유사하게, 서비스(1412-1418)의 하나에 대한 변경은 툴(1302)의 펑크션(1410)에 대한 임의의 변경을 요구하지 않는다. 이러한 방식의 코드 구축은 툴(1302)의 생성 또는 수정시의 코딩 에러의 가능성을 현저히 줄이고, 외부 서비스(1412-1418)를 위한 서비스 갱신을 현저하게 단순화한다.

변환 엔진(1308)은 엔터프라이즈 연산 시스템(1300) 내의 데이터 및 메타데이터를 취급하는 유일하게 가능한 하나의 방법임을 이해될 것이다. 변환 엔진(1308)은 전술한 바와 같이 브릿지(1120)를 포함할 수 있거나, 변환 엔진(1308)을 통과한 데이터가 그 변환 엔진(1308)에 의해서 접속된 양 연산 시스템과 호환되는 최소 공통 인자법(least common factor method)을 채용할 수 있다. 추가의 실시예에서, 변환은 표준에 순응하는 모든 연산 플랫폼이 표준 설비를 통하여 데이터를 전송하고 추출할 수 있도록 표준화 설비 상에서 수행될 수 있다. 계획된 데이터와 그것의 관련 메타데이터를 취급하는 여러 다른 방법이 존재하며, 여기에 기술한 엔터프라이즈 연산 시스템(1300)에 유용하게 채용될 수 있다.

이러한 기반에서, 데이터 통합 시스템(104), 툴(1302) 및 변환 엔진(1304)에 의해서 수행되는 오퍼레이션에 대하여 이하에 상세히 기술한다.

도 15는 데이터 통합 시스템(104)과 연계하여 메타데이터 관리 시스템(312) 또는 메타데이터 설비를 사용하기 위한 프로세스(1500)를 도시하는 순서도이다. 처음에, 스텝 1502로 도시한 바와 같이, 새로운 툴(1302)은 데이터 통합 시스템에 부가될 수 있다. 도시된 바와 같이, 데이터 통합 시스템(104)은 (존재하는 경우) RIM(1304)의 현재 원자 데이터 모델 및 포맷과, 부가될 툴(1302)의 데이터 모델 및 포맷에 관한 정보를 수신할 것이다. 스텝 1503에 도시된 바와 같이, 새로운 툴(1302)이 데이터 통합 시스템(104)에 부가되는 최초의 툴(1302)인지의 여부에 대한 판정이 이루어질 수 있다. 새로운 툴(1302)이 최초의 툴(1302)인 경우에는, 프로세스(1500)는 스텝 1504로 진행하며, 그곳에서 원자 데이터 모델이 툴(1302)에 의해 요구된 뷰 또는 유저에 의해 선택된 임의의 미립 데이터 모델 및 포맷을 사용하여 선택된다.

새로운 툴(1302)이 최초의 툴(1302)이 아닌 경우에는, 프로세스(1500)는 스텝 1508로 진행할 수 있고, 그곳에서 새로운 툴의 클래스 및 속성 구조와 그 클래스와 속성 구조 사이의 연관(association)을 포함하는 새로운 툴의 데이터 모델 및 포맷과, RIM의 현재 원자 데이터 모델 및 포맷의 클래스 및 속성 구조 사이의 대응(correspondence)이 판정될 것이다. RIM(1304) 및 변환 엔진(1308) 갱신 룰 데이터베이스가 그곳으로부터 생성될 수 있다. 스텝 1510에 나타낸 바와 같이, 데이터 통합 시스템(104)은 전술한 바와 같은 RIM의 원자 데이터 모델 및 포맷과, 존재하는 변환 엔진(1308)을 갱신하기 위해 룰 데이터베이스를 사용할 수 있다. 데이터 통합 시스템(104)은 부가되는 툴(1302)을 위한 변환 엔진(1308)을 또한 확립할 수 있다.

도 16에 일반적으로 도시된 바와 같이, 변환 엔진(1308)이 툴(1302)을 위해 생성 또는 갱신되면, 변환 엔진(1308)은 툴(1302)의 각종 오퍼레이션과 연계하여 사용될 수 있다.

스텝 1602에 도시된 바와 같이, 툴(1302)은 관련 변환 엔진(1308)에 전송될 수 있는 접속 요구를 생성할 수 있다. 접속 요구를 수신한 후에, 스텝 1604에 나타낸 바와 같이, 변환 엔진(1308)은 요구가 검색 요구인지 저장 요구인지와 같은 요구 타입을 판정할 수 있다. 스텝 1608에 나타낸 바와 같이, 요구가 검색 요구인 경우, 변환 엔진(1308)은 그 요구를 RIM(1304)을 위한 하나 이상의 요구로 변환하기 위해 툴의 데이터 모델 및 포맷과 RIM의 데이터 모델 및 포맷 사이의 연관을 사용할 수 있다. RIM(1304)으로부터 응답 데이터 아이템을 수신 시, 변환 엔진(1308)은 그 데이터 아이템을 RIM(1304)으로부터 수신된 모델 및 포맷으로부터 툴(1302)에 의해 요구된 모델 및 포맷으로 변환할 수 있고, 그 데이터 아이템을 툴(1302)에 적절한 포맷으로 제공할 수 있다.

스텝 1614에 도시된 바와 같이, 변환 엔진(1308)은 미리 저장된 데이터 아이템을 갱신하기 위한 요구를 포함하여 요구가 저장 요구인지를 판정하고, 변환 엔진(1308)과 RIM(1304)은 툴(1302)과 관련된 마스터 물리적 아이템으로부터 각각의 클래스 및 서브클래스를 위한 방향성 그래프를 생성할 수 있다. 오퍼레이션이 갱신 오퍼레이션을 포함하는 경우, 방향성 그래프는, 그래프 노드로서, 각각의 클래스 및 서브클래스 내의 존재하는 데이터 아이템을 포함할 것이다. 오퍼레이션이 새로운 데이터를 저장하기 위한 것인 경우에, 그래프는, 그래프 노드로서, 요구에 포함되는 새로운 데이터를 저장하는데 사용될 수 있는 엠티(empty) 데이터 아이템 을 포함할 것이다. 방향성 그래프가 확립된 후에, 스텝 1618에 나타낸 바와 같이, 변환 엔진(1308) 및 RIM(1304)은 그래프를 트래버스 하고, 요구에서 요구된 데이터 아이템의 콘텐츠를 확립하거나 갱신하도록 오퍼레이팅한다. 그래프 트래버스 오퍼레이션이 완료된 후에, 스텝 1620에 나타낸 바와 같이, 변환 엔진(1308)은 저장 오퍼레이션이 완료된 것을 툴(1302)에 통지한다.

전술한 바와 같은 데이터 통합 시스템(104)은 현저한 장점을 제공할 수 있다. 예컨대, 시스템(104)은, 툴(1302)을 특정 데이터 모델에 구속하지 않고, 또한 상이한 툴(1302) 사이에서 정보를 교환하는 정보 교환 프로그램을 필요로 하지 않으면서, 엔터프라이즈 연산 시스템(1300) 내의 복수의 툴(1302)에 의해 정보의 효율적인 공유 및 갱신을 제공할 수 있다. 데이터 통합 시스템(104)은 시스템(104) 내의 임의의 툴(1302)을 위해 사용될 수 있는 원자 데이터 모델 및 포맷을 데이터를 유지하는 RIM(1304)을 제공할 수 있고, 그 포맷은 새로운 툴(1302)이 시스템(104)에 부가될 때 통상적인 방식으로 용이하게 갱신되고 변화된다. 또한, 각각의 툴(1302)을 마스터 물리적 아이템 클래스와 명시적으로 연관시킴으로써, 방향성 그래프는 RIM(1304) 내의 데이터 아이템 사이에서 확립될 수 있다. 그 결과로서, RIM(1304) 내의 정보의 갱신은 통상적인 방향성 그래프 트래버스 프로시저를 사용하여 효율적으로 달성될 수 있다.

도 17은 데이터 통합 프로세스의 복수의 프로세스의 병렬 실행을 위한 병렬 실행 설비(1700)를 도시하는 개략도이다. 일 실시예에서, 프로세스(1700)는 프로세스 개시 설비(1702)를 포함할 수 있다. 프로세스 개시 설비(1702)는 실행할 필 요가 있는 잡의 범주를 결정하고, 제1 프로세스 및 제2 프로세스가 동시에 실행될 수 있는지(예컨대, 두 프로세스는 의존적이지 않으므로)를 판정할 수 있다. 판정이 이루어지면, 두 프로세스 설비(1704 및 1708)는 제1 프로세스 및 제2 프로세스를 각각 실행할 수 있다. 그러한 두 잡의 실행 후에, 제3 프로세스는 다른 프로세스 설비(1712)에서 이루어질 수 있다. 제3 프로세스가 완료되면, 대응하는 프로세스 설비(1712)는 정보를 변환 설비(1714)에 전송할 수 있다. 일 실시예에서, 변환 설비(1714)는 제1 및 제2 프로세스 설비(1704, 1708)와 같이, 하나 이상의 병렬 프로세스로부터 정보(1718)를 수신할 때까지는 변환 프로세스를 시작하지 않을 수 있다. 모든 정보가 존재하면, 변환 설비(1714)는 변환을 수행할 수 있다. 이러한 병렬 처리 플로우는 몇몇 프로세스(예컨대, 서로 의존적이지 않은 프로세스)를 동시에 실행함으로써 런 타임(run time)을 최소화시키고, 2 이상의 병렬 실행으로부터의 정보를 공통 설비(예컨대, 공통 설비는 두 병렬 설비의 결과에 의존함)에 제공한다. 이러한 실시예에서, 몇몇 프로세스 설비는 설명의 용이성을 위해 별도의 설비로서 도시된다. 하지만, 그러한 2 이상의 설비는 동일한 물리적 설비일 수 있음을 이해해야 한다. 또한, 2 이상의 프로세스 설비는 상이한 물리적 설비일 수 있으며, 각종 물리적 위치에 상주할 수 있음도 이해해야 한다(예컨대, 설비(1704)는 하나의 물리적 위치에 상주할 수 있고, 설비(1708)는 다른 물리적 위치에 상주할 수 있다).

도 18은 데이터 통합 프로세스의 복수의 프로세스의 병렬 실행을 위한 스텝을 도시하는 순서도이다. 일 실시예에서, 병렬 프로세스는 잡 시퀀스(job sequence)가 결정되는 스텝 1802를 포함할 수 있다. 잡 시퀀스가 결정되면, 스텝 1804에 도시된 바와 같이, 잡은 2 이상의 프로세스 설비에 전송될 수 있다. 스텝 1808에서, 제1 프로세스 설비는 특정 루틴 및 프로그램을 수신하고 실행하며, 처리된 정보를 제3 프로세스 설비에 전송할 수 있다. 스텝 1810에서, 특정 루틴 및 프로그램을 수신하고 실행하며, 일단 완료되면, 처리된 정보를 제3 프로세스 설비에 전송한다. 제3 프로세스 설비는 정보의 두 소스 상에서의 자신의 루틴을 실행하기 이전에, 제1 프로세스 설비로부터 처리된 정보를 수신하기를 대기할 수 있다. 또한, 프로세스 설비는 동일한 설비이거나 동일한 위치에 상주할 수 있으며, 프로세스 설비는 상이하거나 및/또는 한 위치에 상주할 수 있다는 것을 이해해야 한다.

더욱 일반적으로, 평행 처리를 이용하는 스케일러블 아키텍처(scaleable architecture)는 SMP, 클러스터링(clustering), MPP 플랫폼, 및 그리드 연산 솔루션(grid computing solution)을 포함할 수 있다. 이들은 하부 데이터 통합 프로세스의 수정을 필요로 하지 않는 방식으로 전개될 수 있다. 여기에 기술한 시스템과 사용할 수 있는 현재 상업적으로 입수가능한 병렬 데이터베이스는 IBM DB2 UDB, 오라클(Oracle) 및 테라데이터(Teradata) 데이터베이스를 포함한다. 병렬 처리에 관련된 개념은 파이프라이닝(pipelining)의 개념이며, 잡의 데이터 플로우에 의해 정의된 일련의 처리 펑크션을 통하여 기록이 직접 이동된다. 파이프라이닝은 임시 데이터 저장에 대한 요건의 제거, 처리 스텝 사이의 입력/출력 관리의 제거와 같은 다수의 처리 장점을 제공한다. 파이프라이닝은 처리 효율을 향상시키기 위해서 데이터 통합 시스템에 채용될 수 있다.

도 19는 복수의 데이터 소스로부터의 입력과 복수의 데이터 타깃에의 출력을 포함하는 데이터 통합 잡(1900)을 도시하는 개략도이다. 전술한 임의의 데이터 소스(102)일 수 있는 몇몇 데이터 소스(1902A, 1902B 및 1902C)로부터의 데이터를 수집하고, 그 데이터의 조합을 엔터프라이즈에 사용하는 것이 바람직할 수 있다. 일 실시예에서, 데이터 통합 시스템(104)은 몇몇 데이터 소스(1902A, 1902B 및 1902C)로부터의 데이터를 수집하거나, 정제하거나, 수정하거나, 다르게 조작하고, 각종 툴, 타깃 또는 다른 연산 시스템으로부터 접속될 수 있도록, 그 데이터를 전술한 임의의 데이터베이스(112)일 수 있는 공통 데이터 웨어하우스나 데이터베이스(1908)에 저장하는데 사용될 수 있다. 이는 예컨대, 전술한 데이터 통합 프로세스(500)를 포함할 수 있다. 데이터 통합 시스템(104)은 수집된 데이터를 그 데이터가 전술한 툴(1302)일 수 있는 각종 툴(1910A 및 1910B)로부터 직접 접속될 수 있도록 저장 설비(1908)에 저장할 수 있거나, 여기에 기술한 바와 같이 자동으로, 수동으로 또는 반자동으로 생성되는지 간에, 툴은 전술한 변환 엔진(1308)일 수 있는 데이터 변환기(1904A 및 1904B)를 통하여 데이터를 접속할 수 있다. 데이터 변환기(1904A, 1904B)는 별도의 설비로서 도시된다. 하지만, 그것은 데이터 통합 시스템(104), 툴(1302)에 합체될 수 있고, 원하는 태스크를 수행하도록 위치될 수 있다는 것을 이해해야 한다.

도 20은 복수의 데이터 소스로부터의 입력 및 복수의 데이터 타깃으로의 출력을 포함하는 다른 데이터 통합 잡을 도시하는 개략도이다. 전술한 임의의 데이터 소스(102)일 수 있는 몇몇 데이터 소스(1902A, 1902B 및 1902C)로부터의 데이터 를 수집하고, 그 데이터의 조합을 엔터프라이즈에 사용하는 것이 바람직할 수 있다. 일 실시예에서, 데이터 통합 시스템(104)은 몇몇 데이터 소스(1902A, 1902B 및 1902C)로부터의 데이터를 수집, 정제, 수정 또는 다르게 조작하고, 그 수집된 정보를 전술한 임의의 데이터 소스(102)일 수 있는 몇몇 타깃(1910A 및 1910B)에 결합된 방식으로 보낼 수 있다. 이는 예컨대, 실시간 또는 배치 모드(batch mode)로 수행될 수 있다. 미래에 일부 시점에서 접속될 중앙 데이터베이스에 수집된 모든 정보를 저장하는 대신에, 데이터 통합 시스템(104)은 데이터에 대한 요구가 타깃(1910A 및 1910B)에 의해서 이루어진 시간에 또는 그 근방에서 소스(1902A, 1902B, 및 1902C)로부터의 데이터를 수집하고 처리할 수 있다. 데이터 통합 시스템(104)은 본 실시예와 같은 실시예에서 메모리를 여전히 포함한다는 것을 이해해야 한다. 일 실시예에서, 메모리는 처리가 완료된 때 타깃에 보내질 데이터를 임시 저장하는데 사용될 수 있다.

도 19 및 20을 참조하여 기술한 데이터 통합 잡(1900)의 실시예는 일반적인 것이다. 데이터 통합 잡(1900)은 여러 상업, 교육, 정부 및 다른 환경에 적용될 수 있으며, 여러 상이한 타입의 데이터 소스(102), 데이터 통합 시스템(104), 데이터 타깃, 및/또는 데이터베이스(112)를 포함할 수 있다.

도 21은 그래픽 유저 인터페이스(2102)를 도시하며, 그것에 의해 비지니스 엔터프라이즈를 위한 데이터 관리자가 데이터 통합 작업(1900)을 디자인할 수 있다. 일 실시예에서, 그래픽 유저 인터페이스(2102)는 데이터 통합 작업의 셋업을 용이하게 하도록 유저에게 제공될 수 있다. 유저는 사용자에 의해 사용될 데이터 베이스, 변환 툴, 타킷, 패쓰(path) 식별자, 및 다른 툴을 포함한 툴(2106)의 팔레트(palate)를 포함할 수 있다. 유저 인터페이스는 예컨대, 드래그 및 드롭 오퍼레이션, 드롭다운 메뉴, 명령 라인(command line), 및 임의의 다른 컨트롤, 툴, 툴박스나 다른 유저 인터페이스 컴포넌트를 사용하여 툴(2106)의 팔레트로부터 워크 스페이스(workspace)(2104)로 툴을 그래픽적으로 조작할 수 있다. 워크스페이스(2104)는 전술한 데이터 통합 작업(1900)과 같은 데이터 통합 작업을 구성하기 위해서 데이터베이스, 데이터 플로우의 패쓰, 변환 스텝 등을 레이아웃(layout) 하는데 사용될 수 있다. 일 실시예에서, 잡이 일단 구성되면, 잡은 후자로부터 또는 다른 유저 인터페이스로부터 실행될 수 있다. 유저 인터페이스(2102)는 애플리케이션 또는 다른 프로그래밍 환경에 의해서, 또는 유저가 웹 브라우저를 사용하여 접속할 수 있는 웹 페이지로서 생성될 수 있다.

도 22는 그래픽 유저 인터페이스(2102)의 다른 실시예를 도시하며, 그것을 이용하여 데이터 관리자는 데이터 통합 잡(1900)을 디자인할 수 있다. 일 실시예에서, 유저는 데이터 타깃/소스를 나타내는 아이콘을 선택하고, 그러한 아이콘을 펑크션이나 다른 관계와 관련짓기 위해 그래픽 유저 인터페이스(2102)를 사용할 수 있다. 그러한 환경에서, 유저는 전술한 임의의 데이터 통합 잡(1900)일 수 있는 데이터 통합 잡(2202)을 생성하기 위해서 몇몇 아이콘 사이의 연관 또는 명령 구조를 생성할 수 있다.

유저 인터페이스(2102)는 플랫폼(100) 및 데이터 통합 시스템(104) 내의 다수의 리소스 및 디자인 툴에의 접속을 제공할 수 있다. 예컨대, 유저 인터페이 스(2102)는 타입 디자이너 데이터 객체 모델링(type designer data object modeling)을 포함할 수 있다. 타입 디자이너는 데이터 구조의 특징을 정의하고, 데이터의 봉쇄를 정의하고, 데이터 유효화 룰을 생성하는 등의 타입 트리(type tree)를 생성하고 관리하기 위해 사용될 수 있다. 타입 디자이너는 XML, COBOL Copybook과 같은 포맷, 및 SAP R/3, BEA Tuxedo, 및 PeopleSoft EnterpriseOne과 같은 애플리케이션 특정 구조로 기술되는 데이터용 타입 트리(즉, 데이터 객체 정의)를 자동으로 생성하기 위해 임포터(importer)를 포함할 수 있다.

유저 인터페이스(2102)는 변환 및 비지니스 룰을 공식화하기 위해 사용되는 맵 디자이너를 포함할 수 있다. 맵 디자이너는 타입 디자이너에 의해 생성된 데이터 객체의 정의를 입력 및 출력으로서 사용할 수 있고, 데이터를 변환하고 루팅하기 위한 룰 뿐만 아니라, 전개되는 맵을 분석, 컴파일링 및 테스트하기 위한 환경을 특정하기 위해 사용될 수 있다.

데이터베이스 디자인 인터페이스는 질의, 테이블, 및 관련 데이터베이스에 저장된 데이터를 위한 저장 프로시저에 관한 메타데이터를 임포트(import) 하기 위한 모델링 컴포넌트로서 제공될 수 있다. 데이터베이스 디자인 인터페이스는 매핑 및 실행 요건을 충족시키기 위해 각종 객체의 갱신 키 및 데이터베이스 트리거와 같은 특징을 식별할 수 있다. 데이터 통합 프로세스를 정의하고 관리하기 위해 통합 플로우 디자이너가 사용될 수 있다. 통합 플로우 디자이너는 워크플로우의 논리적 일관성을 유효화하기 위해서 맵의 시스템과 맵 사이의 상호작용을 정의하는데 더욱 구체적으로 사용될 수 있다. 그래픽 유저 인터페이스 내의 명령 방식 실 행(command-driven execution)을 위해 명령 서버 컴포넌트가 제공될 수 있다. 이는 예컨대, 맵 디자이너 환경 내의 맵을 테스트하기 위해 채용될 수 있다. 리소스 레지스트리(resource registry)는 실행시 엔터프라이즈 내의 특정 리소스로 리졸브(resolve) 하는 에일리어스(alias)를 사용하여 파라미터 세팅을 요약하는데 사용되는 리소스 에일리어스 리포지토리를 제공할 수 있다.

유저 인터페이스(2102)는 각종 관리 툴에의 접속을 또한 제공할 수 있다. 예컨대, 이벤트 서버 관리 툴이 제공될 수 있고, 그것으로부터 유저는 전개 디렉토리를 특정하고, 유저 및 유저 접속 권리를 구성하고, 리스닝 포트(listening port)를 특정하고, 자바 RMI(Remote Method Invocation)에 대한 특성을 정의할 수 있다. 관리 콘솔(management console)은 이벤트 서버에 관리 및 모니터링을 제공하고, 그것으로부터 유저는 시스템을 정지, 일시정지 및 재시작할 수 있고, 실행중인 이벤트 서버 및 맵의 상태에 관한 정보를 뷰 할 수 있다. 이벤트 서버 모니터는 맵이 실행하고 특정 시간에 활동도의 스냅샷(snapshot)을 생성할 때, 단일 맵의 동적인 상세 뷰를 제공할 수 있다.

도 23은 비지니스 엔터프라이즈의 각종 데이터의 통합을 용이하게 하는 플랫폼(2300)을 나타낸다. 플랫폼은 예컨대, 전술한 플랫폼(100)일 수 있고, 각종 소스로부터의 데이터 추출, 원하는 포맷으로의 데이터 변환, 및 각종 타깃으로의 데이터 로딩(때때로, ETL(Extract, Transform, Load)이라 함)과 같은 알려진 엔터프라이즈 애플리케이션 통합(EAI) 서비스를 제공할 수 있는 통합 슈트(integration suite)를 포함할 수 있다. 플랫폼(2300)은 EJB(Enterprise Java Beans) 및 JMS(Java Messaging Service)와 같은 웹 서비스 프로토콜(2302)을 통하는 것을 포함하여, 엔터프라이즈의 컴퓨터 애플리케이션에 의해 접속될 수 있는 서비스로서 통상적인 데이터 통합 플랫폼(2702)을 노출하는 것을 용이하게 하는 실시간 통합(RTI) 서비스(2704)를 포함할 수 있다. 제품 슈트는 이하에서 상세히 설명하는 바와 같은 데이터 통합 또는 엔터프라이즈 통합 슈트일 수 있으며, 상호관련 프로그램 또는 펑크션의 임의의 슈트가 여기에 기술한 원칙을 사용하는 서비스 지향 아키텍처에서 서비스로서 전개 및 관리될 수 있다. 그리하여, 예컨대, 제품 슈트는 자동화된 문서 어셈블리, 워드 프로세싱, 스프레드시트 등과 같은 툴을 포함하는 오피스 자동화 또는 생산성 슈트를 포함할 수 있다. 또한, 제품 슈트는 디자인, 가상 대여, 비용 지불, 시뮬레이션 등을 위한 각종 서비스로서 전개되는 별도의 소프트웨어 패키지나 펑크션을 구비한 컴퓨터 자동화 디자인 슈트일 수 있다. 다른 예로서, 부기, 회계, 세금 준비 및 전자 세금 파일링 제품과 같은 금융 제품의 통합 슈트가 서비스 지향 아키텍처를 사용하는 서비스로서, 제품 레벨 또는 각 제품에 특정한 서비스 컬렉션으로서 전개될 수 있다. 유사하게, 결제 모델링 툴, 금융 분석 툴(예컨대, 개별 회사 금융, 주식 트랜잭션(transaction) 패턴, 시장 트랜잭션 패턴 등을 위한), 및 전자 트랜잭션 툴이 통합 주식 트랜잭션 슈트에서의 서비스로서 전개될 수 있다.

도 24는 서비스 지향 아키텍처(SOA)(2400)의 개략도를 도시한다. SOA는 비지니스 엔터프라이즈의 엔터프라이즈 연산 시스템(1300)의 인프라구조의 일부이다. SOA(2400)에서, 서비스는 신속한 애플리케이션 개발을 허용하고 중복 코드를 피하 게 하는 애플리케이션 개발 및 전개를 위한 빌딩 블록이 된다. 각 서비스는 서비스를 위한 데이터 입력의 소스 또는 서비스의 데이터 출력의 타깃과 같은, 주위 환경에는 무효가 될 수 있는 비지니스 논리 또는 비지니스 룰의 세트를 실시한다. 결과로서, 적절한 입력 및 출력이 서비스와 애플리케이션 사이에서 확립된다면, 서비스는 각종 애플리케이션과 연계하여 재사용될 수 있다. 서비스 지향 아키텍처(2400)는 환경 변화에 대하여 서비스가 보호될 수 있게 하고, 그리하여 주위의 컴퓨터 환경이 변경될지라도 아키텍처는 기능한다. 그 결과, 서비스는 인프라구조 변경의 결과로서 리코딩될 필요가 없고, 이로 인해 시간 및 노력을 저감할 수 있다. 도 24의 실시예는 웹 서비스를 위한 SOA(2400)의 실시예이다. 여기에 사용되는 바와 같이, "서비스 지향 아키텍처", "서비스-지향 아키텍처", "SOA" 등은 도 24를 참조하여 기술되는 바와 같이, 더욱 일반적으로는 명세서 전반을 통하여 기술되는 바와 같이, SOA(2400)를 일반적으로 칭하기 위해서 교환가능하게 사용되도록 의도된다.

도 24의 SOA(2400)에서, 세 엔티티인 서비스 제공자(2402), 서비스 요구자(2404) 및 서비스 레지스트리(2408)가 있다. 레지스트리(2408)는 공공적이거나 사유적일 수 있다. 서비스 요구자(2404)는 적절한 서비스를 위한 레지스트리(2408)를 검색한다. 적절한 서비스가 발견되면, 서비스 요구자(2404)는 서비스를 인보크 하는데 필요한 웹 서비스 기술 언어(WSDL) 코드와 같은 코드를 수신할 수 있다. 서비스 요구자(2404)는 서비스를 인보크 하기 위해, 적절한 포맷(예컨대, 웹 서비스 메시지를 위한 단순 객체 접근 프로토콜(SOAP) 포맷)을 통하여 서비 스 제공자(2402)와 인터페이스할 수 있다. SOAP 프로토콜은 웹 서비스에서 데이터를 전송하는데 바람직한 프로토콜이다. SOAP 프로토콜은 웹 서비스 클라이언트와 웹 서비스 서버 사이의 메시지를 위한 교환 포맷을 정의한다. SOAP 프로토콜은 XML(eXtensible Markup Language) 스키마를 사용하며, 다른 마크업 언어가 사용될 수 있을지라도 XML은 데이터를 태깅(tagging)하기 위해 웹 서비스에서 공통으로 사용되는 일반적인 언어 명세이다.

도 25는 SOAP 메시지의 예를 도시한다. SOAP 메시지(2502)는 전송 봉투(2504)(HTTP 또는 JMS 봉투 등), SOAP 봉투(2508), SOAP 헤더(2510) 및 SOAP 보디(2512)를 포함할 수 있다. 이하는 SOAP-포맷 요구 메시지 및 SOAP-포맷 응답 메시지의 예이다.

웹 서비스는 웹을 통하여 발행되고, 위치되며, 인보크될 수 있는 모듈러, 자가 기술(self-describing), 자가 공급(self-contained) 애플리케이션이다. 예컨대, 도 24의 웹서비스의 실시예에서, 서비자 제공자(2402)는 이용가능한 웹 서비스의 리스트, 또는 사설 레지스트리나 다른 공공 레지스트리를 제공하는 예컨대, UDDI(Universal Description, Discovery and Integration) 레지스트리일 수 있는 레지스트리(2408)에 웹 서비스를 발행한다. 웹 서비스는 예컨대, WSDL 포맷으로 발행될 수 있다. 서비스를 탐색하기 위해, 서비스 요구자(2404)는 서비스 레지스트리를 브라우징하고, WSDL 문서를 검색할 수 있다. 레지스트리(2408)는 브라우징 설비 및 검색 설비를 포함할 수 있다. 레지스트리(2408)는 WSDL 문서 및 자신의 메타데이터를 저장할 수 있다.

웹 서비스를 인보크하기 위해, 서비스 요구자(2404)는 WSDL로 기술되는 바와 같은 SOAP 메시지(2502)를 전송하고, 응하여 SOAP 메시지(2502)를 수신하고, 그 응답 메시지를 WSDL로 기술된 바와 같은 응답 메시지를 디코딩한다. 메시지의 복잡도에 따라, 웹 서비스는 데이터 요구와 같은 단순한 오퍼레이션으로부터 복잡한 비지니스 프로세스 오퍼레이션까지에 걸친 넓은 어레이의 펑크션을 제공할 수 있다. 일단 웹 서비스가 전개되면, 다른 애플리케이션(다른 웹 서비스를 포함)은 웹 서비스를 찾아서 인보크할 수 있다. 다른 웹 서비스 표준은 웹 서비스 상호 운용성(WS-I) 기관, 플랫폼에 걸쳐 웹 서비스의 상호 운용을 촉진하도록 면허된 개방 산업 기관(open industry organization)에 의해 정의된다. 예는 WS(웹 서비스) 조정, WS 보안, WS 트랜잭션, WSIF, BPEL 등을 포함하며, 여기에 기술된 웹 서비스는 임의의 그러한 표준에 의해서 시도된 서비스를 포함하는 것임을 이해해야 한다.

도 26을 참조하면, WSDL 정의(2600)는 웹 서비스를 위한 인터페이스, 위치 및 웹 인코딩 스키마를 정의하는 XML 스키마이다. 정의(2600)는 서비스(2602)를 정의하고, 서비스가 통하여 접속될 수 있는 포트(2604)를 식별하고(예컨대, 인터넷 어드레스), 웹 서비스를 인보크하고 그것과 통신하기 위해 사용되는 바인딩(2608)(예컨대, 엔터프라이즈 자바 빈 또는 SOAP 바인딩)을 정의한다. WSDL 정의(2600)는 포트 타입(2612), 웹 서비스를 위한 착신 메시지 파트(2616) 및 발신 메시지 파트(2618) 뿐만 아니라, 서비스에 의해서 수행되는 오퍼레이션(2614)을 정의할 수 있는 요약 정의(2610)를 포함할 수 있다.

웹 서비스를 인보크할 수 있는 각종 제공자로부터의 각종 웹 서비스 클라이 언트가 있다. 웹 서비스 클라이언트는 .Net 애플리케이션, 자바 애플리케이션(예컨대, JAX-RPC), 마이크로소프트 SOAP 툴 키트(마이크로소프트 오피스, 마이크로소프트 SQL 서비스 등) 내의 애플리케이션, SeeBeyond, WebMethods, Tibco 및 BizTalk로부터의 애플리케이션뿐만 아니라, 어센셜사의 데이터스테이지(WS PACK)를 포함한다. 다른 웹 서비스 클라이언트가 여기에 기술된 엔터프라이즈 데이터 통합 방법 및 시스템에 사용될 수 있다는 것을 이해해야 한다. 유사하게, .Net 애플리케이션, 자바 애플리케이션, Siebel 및 SAP로부터의 애플리케이션, I2애플리케이션, DB2 및 SQL 서버 애플리케이션, 엔터프라이즈 애플리케이션 통합(EAI) 애플리케이션, 비지니스 프로세스 관리(BPM) 애플리케이션, 및 어센셜 소프트웨어(Ascential Software)사의 실시간 통합(RTI) 애플리케이션이 있으며, 이 모두는 여기에 기술된 웹 서비스 클라이언트에 사용될 수 있다.

여기에 기술된 RTI 서비스(2704)는 데이터 통합 프로세스 서비스 인터페이스를 기술하기 위해 WSDL과 같은 개방 표준 스펙을 사용할 수 있다. 데이터 통합 서비스 정의가 완료되면, 일반적으로 전술한 바와 같이, 서비스의 이름, 서비스의 오퍼레이션, 각 오퍼레이션의 서명, 및 서비스에 대한 바인딩을 제공하는 요약 정의인 WSDL 웹 서비스 정의 언어(웹 서비스에 특정할 필요는 없는 언어)를 사용할 수 있다. WSDL 정의(2600)(XML 문서) 내에는 도 26과 연계하여 기술한 구조의 각종 태그가 있다. 각 서비스를 위해서, 각각 바인딩을 갖는 복수의 포트가 있을 수 있다. 요약 정의는 해당 데이터 통합 서비스를 위한 RTI 서비스 정의이다. 포트 타입은 오퍼레이션 세트를 위한 진입점이며, 그것의 각각은 입력 아규먼트(argument) 및 출력 아규먼트의 세트를 갖는다.

WSDL은 웹 서비스에 대해 정의되지만, 하나의 정의된 바인딩에 의해서만 정의된다(SOAP 오버 HTTP). WSDL은 EJB, JMS 등과 같은 각종 다른 바인딩을 위한 WSDL 확장을 포함하기 위해 산업체를 통하여 확장되고 있다. RTI 서비스(2704)는 각종 다른 프로토콜을 위한 바인딩을 생성하기 위해 WSDL 확장을 사용할 수 있다. 그리하여, 단일 RTI 데이터 통합 서비스는 동시에 단일 서비스에 복수의 바인딩을 지지할 수 있다. 그 결과로서, 비지니스는 데이터 통합 프로세스(500)를 취할 수 있고, 그것을 (프로토콜에 완전히 독립적인) 요약 프로세스의 세트로서 노출시키고, 바인딩을 부가한다. 서비스는 임의 수의 바인딩을 지지할 수 있다.

유저는 미리 존재하는 데이터 통합 잡(1900)을 취하고, 적절한 RTI 입력 및 출력 단계를 부가하고, 상이한 네이티브 프로토콜(native protocol)을 사용하는 각종 애플리케이션에 의해서 인보크될 수 있는 서비스로서 그 잡을 노출시킬 수 있다.

도 27을 참조하면, 데이터 통합 플랫폼(2700)을 위한 하이 레벨 아키텍처가 제시되며, 이는 예컨대, 전술한 바와 같은 플랫폼(100)을 통하여 전개되고 실시간 데이터 통합을 위해서 채택될 수 있다. 예컨대, 전술한 바와 같은 데이터 통합 시스템(104)일 수 있는 통상적인 데이터 통합 설비(2702)는 데이터 통합 잡을 처리하기 위한 방법 및 시스템을 제공할 수 있다. 데이터 통합 설비(2702)는 서비스 지향 아키텍처의 서비스를 포함하는 실시간 통합 설비 또는 RTI 서비스(2704)를 통하여 하나 이상의 애플리케이션에 접속될 수 있다. RTI 서비스(2704)는 인보크할 수 있거나 엔터프라이즈의 각종 애플리케이션(2708)에 의해서 인보크될 수 있다. 데이터 통합 설비(2702)는 매칭, 표준화, 변환, 정제, 탐색, 메타데이터, 병렬 실행, 및 데이터 통합 잡을 실행하는데 필요한 유사한 설비를 제공할 수 있다. 실시예에서, RTI 서비스(2704)는 데이터 통합 설비(2702)의 데이터 통합 잡을 엔터프라이즈의 애플리케이션(2708)에 의해서 실시간 인보크될 수 있는 서비스로서 노출시킨다. RTI 서비스(2704)는 데이터 통합 잡이 서비스로서 동기적으로 또는 비동기적으로 사용될 수 있도록 데이터 통합 설비(2702)를 노출시킨다. 예컨대, 잡은 엔터프라이즈 통합 플랫폼, 애플리케이션 서버 플랫폼뿐만 아니라 자바 및 .Net 애플리케이션으로부터 호출될 수 있다. RTI 서비스(2704)는 동일한 논리가 배치 및 실시간 서비스를 통하여 적용되거나 재사용될 수 있게 허용한다. RTI 서비스(2704)는 엔터프라이즈 자바 빈(EJB), 자바 메시지 서비스(JMS), 또는 웹 서비스 바인딩과 같은 각종 바인딩(2710)을 사용하여 인보크될 수 있다.

도 28을 참조하면, 실시예에서, RTI 서비스(2704)는 실시간 데이터 통합 프로세스의 각종 엘리먼트를 위한 접속 설비로서 작용하는 RTI 서버(2802) 상에서 실행한다. 예컨대, RTI 서버(2802)는 매사추세츠주 웨스트버로우의 어센셜 소프트웨어로부터의 데이터스테이지 서버와 같은 복수의 엔터프라이즈 애플리케이션을 접속시킬 수 있어서, RTI 서버(2802)는 다른 서버 사이에서의 풀링(pooling) 및 로드 밸런싱(load balancing)을 제공할 수 있다. RTI 서버(2802)는 J2EE 애플리케이션 서버상에서 실행하는 별도의 J2EE 애플리케이션을 포함할 수 있다. 하나 이상의 RTI 서버(2802)가 데이터 통합 프로세스 내에 포함될 수 있다.

J2EE는 엔터프라이즈 애플리케이션의 개발, 조립 및 전개를 디자인하기 위한 컴포넌트 기반 접근법을 제공한다. 무엇보다도, J2EE는 다층 분배 애플리케이션 모델, 컴포넌트를 재사용하는 능력, 통합 보안 모델, 트랜잭션 제어 메커니즘을 제공한다. J2EE 애플리케이션은 컴포넌트들로 이루어진다. J2EE 컴포넌트는 그것의 관련 클래스 및 파일과 함께 J2EE 애플리케이션에 조립되며, 다른 컴포넌트들과 통신하는 자가 공급 기능 소프트웨어 유닛이다.

J2EE 스펙은 클라이언트 측에서 실행하는 컴포넌트인 애플리케이션 클라이언트 및 애플릿; 서버상에서 실행하는 웹 컴포넌트인 자바 서브릿 및 자바 서버 페이지(JSP) 기술 컴포넌트; 서버상에서 실행하는 비지니스 컴포넌트인 엔터프라이즈 자바 빈(EJB) 컴포넌트(엔터프라이즈 빈)를 포함하는 각종 J2EE 컴포넌트를 정의한다. J2EE 컴포넌트는 자바로 기록되며, 임의의 프로그램으로서 동일한 방식으로 컴파일된다. J2EE 컴포넌트와, "표준" 자바 클래스 사이의 차이점은, J2EE 컴포넌트는 J2EE 애플리케이션에 조립되고, J2EE 스펙에 따라 잘-형성되는지 입증되고, J2EE 서버에 의해서 실행되며 관리되는 제조를 위해 전개된다는 것이다. 세 종류의 EJB, 즉, 세션 빈(session bean), 엔티티 빈, 및 메시지 구동 빈이 있다. 세션 빈은 클라이언트와의 일시적인 대화를 나타낸다. 클라이언트가 실행을 종료할 때, 세션 빈 및 그것의 데이터가 진행한다. 반대로, 엔티티 빈은 데이터 테이블의 하나의 열에 저장된 지속적인 데이터를 나타낸다. 클라이언트가 종료하거나 서버가 셧 다운되면, 하부 서비스는 엔티티 빈이 저장되는 것을 보장한다. 메시지 구동 빈은 세션 빈 및 자바 메시지 서비스(JMS) 메시지 리스너(listener)의 특징을 결합 하고, 비지니스 컴포넌트가 JMS 메시지를 비동기적으로 수신하게 허용한다.

J2EE 스펙은 컴포넌트와, 그 컴포넌트를 지지하는 저위 레벨 플랫폼 특정 기능 사이의 인터페이스인 컨테이너를 또한 정의한다. 웹, 엔터프라이즈 빈, 애플리케이션 클라이언트 컴포넌트가 실행될 수 있기 이전에, J2EE 애플리케이션으로 조립되고 그것의 컨테이너로 전개되어야만 한다. 조립 프로세스는 J2EE 애플리케이션 내의 각 컴포넌트 및 J2EE 애플리케이션 자체를 위한 컨테이너 세팅을 특정하는 것을 포함한다. 컨테이너 세팅은 보안, 거래 관리, 자바 네이밍(naming) 및 디렉토리 인터페이스(JNDI) 룩업(lookup), 및 원격 접속과 같은 서비스를 포함하는, J2EE 서버에 의해서 제공되는 하부 지지를 커스터마이즈(customize) 한다.

도 29는 통상적인 J2EE 서버(2908) 및 관련 애플리케이션을 위한 아키텍처(2900)를 도시한다. J2EE 서버(2908)는 J2EE 아키텍처의 런 타임 애스펙트(runtime aspect)를 포함한다. J2EE 서버(2908)는 EJB 및 웹 컨테이너를 제공한다. EJB 컨테이너(2902)는 J2EE 애플리케이션을 위한 엔터프라이즈 빈(2904)의 실행을 관리한다. 엔터프라이즈 빈(2904) 및 그것의 컨테이너(2902)는 J2EE 서버(2908)상에서 실행한다. 웹 컨테이너(2910)는 J2EE 애플리케이션을 위한 서브릿 컴포넌트(2914)와 JSP 페이지(2912)의 실행을 관리한다. 웹 컴포넌트 및 그것의 컨테이너(2910)는 J2EE 서버(2908)상에서 또한 실행한다. 한편, 애플리케이션 클라이언트 컨테이너(2918)는 애플리케이션 클라이언트 컴포넌트의 실행을 관리한다. 애플리케이션 클라이언트(2920) 및 그것의 컨테이너(2918)는 클라이언트 측에서 실행한다. 애플릿 컨테이너는 애플릿의 실행을 관리한다. 애플릿 컨테이너는 클라 이언트 상에서 함께 실행하는 웹 브라우저 및 자바 플러그 인(plug-in)을 포함할 수 있다.

J2EE 컴포넌트는 개별적으로 패키징 되고, 전개를 위해 J2EE 애플리케이션에 번들링 된다. 각 컴포넌트에서, GIG 및 HTML 파일과 같은 그것의 관련 파일 또는 서버측 유틸리티 클래스, 및 전개 디스크립터(descriptor)는 모듈로 조립되고 J2EE 애플리케이션에 부가된다. J2EE 애플리케이션 및 그것의 각 모듈은 자신의 전개 디스크립터를 갖는다. 전개 디스크립터는 컴포넌트의 전개 세팅을 기술하는 .xml 확장을 갖는 XML 문서이다. 자신의 모든 모듈을 갖는 J2EE 애플리케이션은 엔터프라이즈 아카이브(EAR) 파일로 전달된다. EAR 파일은 .ear 확장을 갖는 자바 아카이브(JAR) 파일이다. 각각의 EJB JAR 파일은 전개 디스크립터, 엔터프라이즈 빈 파일, 및 관련 파일을 포함한다. 각각의 애플리케이션 클라이언트 JAR 파일은 전개 디스크립터, 애플리케이션 클라이언트를 위한 클래스 파일, 및 관련 파일을 포함한다. 각각의 파일은 전개 디스크립터, 웹 컴포넌트 파일, 및 관련 리소스를 포함한다.

RTI 서버(2802)는 실시간 엔터프라이즈 애플리케이션 통합 환경을 위한 호스팅 서비스(hosting service)로서 작용할 수 있다. RTI 서버(2802)는 여기에 기술한 기능을 수행할 수 있는 J2EE 서버일 수 있다. RTI 서버(2802)는 엔터프라이즈 애플리케이션 통합 서비스에 안전한 스케일러블 플랫폼을 제공할 수 있다. RTI 서버(2802)는 세선 관리, 로깅(예컨대, Apache Log^4J 로깅), 구성 및 감시(예컨대, J2EE JMX), 보안(예컨대, J2EE JAAS, J2EE 관리자를 통한 SSL 암호화)을 포함하는 다양한 통상적인 서버 기능을 제공할 수 있다. RTI 서버(2802)는 국부적 또는 사설의 웹 서비스 레지스트리로서 작용할 수 있고, 여러 통상적인 웹 서비스를 위해 사용되는 UDDI 레지스트리와 같은 공공 웹 서비스 레지스트리에 웹 서비스를 발행하는데 사용될 수 있다. RTI 서버(2802)는 데이터 통합 잡을 실행하는데 사용되는 것과 같은 다른 서버 사이에서 리소스 풀링 및 로드 밸런싱 기능을 수행할 수 있다. RTI 서버(2802)는 RTI 서비스를 확립하고 관리하기 위한 관리 콘솔로서 또한 작용할 수 있다. RTI 서버(2802)는 JBOSS 3.0, IBM Websphere 5.0, BEA WebLogic 7.0, 및 BEA WebLogic 8.1과 같은 각종 환경과 연계하여 오퍼레이팅할 수 있다.

일단 확립되면, RTI 서버(2802)는 데이터 통합 잡(예컨대, 어센셜 소프트웨어 플랫폼에 의해서 수행되는 데이터스테이지 및 품질 스테이지)이 웹 서비스, 엔터프라이즈 자바 빈, 자바 메시지 서비스 메시지 등에 의해 인보크되게 허용한다. RTI 서버(2802)와 함께 서비스 지향 아키텍처를 사용하는 접근법은 바인딩 결정이 데이터 통합 잡 디자인과 독립적이게 허용한다. 또한, 복수의 바인딩이 동일한 데이터 통합 잡을 위해 확립될 수 있다. 데이터 통합 잡이 환경에 무관하고, 복수의 바인딩과 함께 작업가능하기 때문에, 복수의 애플리케이션에 걸쳐 그리고 배치 및 실시간 모드에 걸쳐 처리 논리를 재사용하는 것이 더 용이해질 수 있다.

도 30은 RTI 서비스를 관리하기 위해 제공될 수 있는 RTI 콘솔(3002)을 도시한다. RTI 콘솔(3002)은 RTI 서비스의 생성 및 전개를 가능하게 할 수 있다. 무엇보다도, RTI 콘솔은, 유저가 해당 RTI 서비스에 제공하기 위해 어느 바인딩이 사 용될 수 있는지를 확립하고, RTI 서비스의 런 타임 이용을 위한 파라미터를 확립하게 허용한다. RTI 콘솔에는 그래픽 유저 인터페이스가 제공될 수 있고, 마이크로소프트 윈도우 기반 환경 또는 웹 브라우저 인터페이스와 같은 인터페이스를 지지하기 위한 임의의 적합한 환경에서 실행할 수 있다. 그러한 RTI 콘솔 이용에 대한 세부 사항은 이하에 제공된다. RTI 콘솔(3002)은 서비스를 생성하고, 서비스의 오퍼레이션을 생성하고, 그 서비스의 오퍼레이션에 잡을 부가하고, 그 서비스를 각종 프로토콜로 실행하기 위해 유저에 의해서 원하는 바인딩을 생성하기 위해서 디자이너에 의해서 사용될 수 있다.

도 27을 다시 참조하면, RTI 서비스(2704)는 데이터 통합 플랫폼(2702)과 각종 애플리케이션(2708) 사이에 위치할 수 있다. RTI 서비스(2704)는 애플리케이션(2708)이 데이터 통합 플랫폼(2702)을 실시간 또는 배치 모드로, 동기적으로 또는 비동기적으로 접속하게 허용한다. 데이터 통합 플랫폼(2702)에서 확립된 데이터 통합 룰은 엔터프라이즈 연산 시스템(1300)에 걸쳐 공유될 수 있다. 데이터 통합 룰은 플랫폼(2702)의 지식을 요하지 않고, 임의의 언어로 기록될 수 있다. RTI 서비스(2704)는 실시간 데이터 통합을 용이하게 하기 위해 웹 서비스 정의를 레버리지(leverage)할 수 있다. 여기에 기술한 방법 및 시스템에 따른 데이터 통합 잡의 플로우는 배치 환경 또는 실시간 환경에 접속될 수 있다. 여기에 개시된 방법 및 시스템은 컨테이너의 개념, 프로세스 내의 정의된 진입점과 정의된 출구점 사이에 포함되는 비지니스 논리의 일부를 포함한다. 데이터 통합 프로세스를 컨테이너 내의 비지니스 논리로서 구성함으로써, 데이터 통합은 배치 모드 및 실시간 모드로 사용될 수 있다. 비지니스 논리가 컨테이너 내에 있는 경우, 배치 모드와 실시간 모드 사이의 이동이 단순화된다. 데이터 통합 잡은 실시간 서비스로서 접속될 수 있고, 동일한 변환을 실시간으로 수행하는 큰 배치의 파일 처리와 같이, 동일한 데이터 통합 잡이 배치 모드에서 접속될 수 있다.

도 31을 참조하면, RTI 서비스(2704)의 일 실시예를 가능하게 하는 아키텍처(3100)의 보다 상세한 세부사항이 제공된다. RTI 서버(2802)는 통상적인 J2EE-컴플라이언트 서버(compliant server)에 의해서 제공되는 것과 같은 감사(3104), 인증(3108), 인가(3110) 및 로깅(3112)을 위한 설비를 포함하는 각종 컴포넌트를 포함할 수 있다. RTI 서버(2802)는 데이터 통합 플랫폼(2702)상에서 실행하는 데이터 통합 잡과 관련된 리소스와 같은 리소스를 풀링하고 할당하도록 오퍼레이팅할 수 있는 프로세스 풀링 설비(3102)를 또한 포함할 수 있다. 프로세스 풀링 설비(3102)는 데이터 통합 잡을 실행하고 있는 각종 서버에 걸친 서버 및 잡 선택을 제공할 수 있다. 선택은 기기들 사이의 로드 밸런싱에 기초되거나, 어느 데이터 통합 잡이 기기상에서 실행할 수 있는지(또는 가장 효과적으로 실행할 수 있는지)에 기초될 수 있다. RTI 서버(2802)는 SOAP 바인딩 설비(3116), JMS 바인딩 설비(3118) 및 EJB 바인딩 설비(3120)와 같은 바인딩 설비(3114)를 또한 포함할 수 있다. 바인딩 설비(3114)는 웹 서비스 클라이언트(3122), JMS 큐(queue)(3124) 또는 자바 애플리케이션(3128)과 같은 각종 애플리케이션과 RTI 서버(2802) 사이의 인터페이스를 허용한다.

도 31을 참조하면, RTI 콘솔(3002)은 RTI 서버(2802)를 위한 관리 콘솔일 수 있다. RTI 콘솔(3002)은 관리자가 RTI 서비스를 생성하고 전개하며, 서비스의 런 타임 파라미터를 구성하고, 서비스에의 바인딩 또는 인터페이스를 정의할 수 있게 한다.

아키텍처(3100)는 매사추세츠주 웨스트버로우의 어센셜 소프트웨어에 의해 제공되는 데이터스테이지 서버와 같은 서버를 포함할 수 있는 하나 이상의 데이터 통합 플랫폼(2702)을 포함할 수 있다. 데이터 통합 플랫폼(2702)은, RTI 서버(2802)로의 요구 및 그 서버로부터의 요구를 배열하는 데이터 통합 플랫폼(2702) 상에서 실행하는 프로세스인 RTI 에이전트(3132)를 포함하여, RTI 서버(2802)와의 상호작용을 지지하기 위한 설비를 포함할 수 있다. 그리하여, 프로세스 풀링 설비(3102)가 실시간 데이터 통합 잡을 위한 데이터 통합 플랫폼(2702)으로서 특정 기기를 선택하면, 그 요구를 그 데이터 통합 플랫폼(2702)을 위하여 RTI 에이전트(3132)에 건넬 수 있다. 데이터 통합 플랫폼(2702) 상에서, 전술한 데이터 통합 잡(1900)과 같은 하나 이상의 데이터 통합 잡(3134)이 실행될 수 있다. 데이터 통합 잡(3134)은 호출시 개시되는 것보다, 선택적으로 항상 존재할 수 있다. 예컨대, 데이터 통합 잡(3134)은 처리시 새로운 접속을 오픈하기 보다는, 데이터베이스, 웹 서비스 등과 미리 오픈 접속되어, 데이터 통합 잡(3134)에 와서 인보크하는 데이터를 기다릴 수 있다. 그리하여, 준비 데이터 통합 작업(3134)의 인스턴스(instance)는 RTI 에이전트(3132)에 의해서 인보크될 수 있고, 파일, 데이터 열, 데이터 배치 등일 수 있는 RTI 서버(2802)로부터의 특정 입력을 사용하여 데이터 통합 잡(3134)의 실행과 즉시 시작할 수 있다.

각각의 데이터 통합 잡(3134)은 RTI 입력 스테이지(3138) 및 RTI 출력 스테이지(3140)를 포함할 수 있다. RTI 입력 스테이지(3138)는 RTI 에이전트(3132)로부터의 데이터 통합 잡(3134)의 진입점이며, RTI 출력 스테이지(3140)는 RTI 에이전트(3132)로 되돌아가는 출력 스테이지이다. RTI 입력 및 출력 스테이지에 의해, 데이터 통합 잡(3134)은 독립적인 플랫폼인 비지니스 논리의 일부일 수 있다. RTI 서버(2802)는 어느 입력이 각각의 RTI 데이터 통합 잡(3134)의 RTI 입력 스테이지(3138)에 필요한지를 알고 있다. 예컨대, 해당 데이터 통합 잡(3134)의 비지니스 논리가 소비자의 성과 나이를 입력으로서 취하는 경우에는, RTI 서버(2802)는 입력을 문자열 및 정수의 형태로 그 데이터 통합 잡(3134)의 RTI 입력 스테이지(3138)에 보낼 수 있다. RTI 입력 스테이지는 데이터 통합 잡(3134)을 실행하는데 어떠한 네이티브 애플리케이션 코드가 사용되더라도 적절한 입력 및 포맷을 취할 것이다.

실시예에서, 여기에 기술한 방법 및 시스템은 디자이너가 데이터 통합 프로세스로부터 RTI 서비스 인터페이스로 자동으로 커스터마이즈 가능한 매핑 기기를 정의하게 허용할 수 있다. 특히, RTI 콘솔(3002)은 디자이너가 데이터 통합 서비스를 위한 자동화된 서비스 인터페이스를 생성하게 허용할 수 있다. 무엇보다도, 유저(또는 룰의 세트, 또는 프로그램)가 특정 목적에 부합하도록 일반적인 서비스 인터페이스를 커스터마이즈하게 허용할 수 있다. 변환과 같은 트랜잭션의 플로우에서, RTI 입력 스테이지(3138) 및 RTI 출력 스테이지(3140)에 의한 데이터 통합 잡이 있는 경우, 잡을 위한 메타데이터는 예컨대, 잡의 스테이지 또는 컴포넌트들 사이에서 교환된 데이터의 포맷을 지시할 수 있다. 테이블 정의는 어느 RTI 입력 스테이지(3138)가 수신하기를 기대하는지를 기술하며, 예컨대, 데이터 통합 잡의 입력 스테이지는 3가지 호출, 즉, 하나의 문자열 및 두 정수를 기대할 것이다. 한편, 데이터 통합 잡 플로우의 마지막에서, 출력 스테이지는 (문자열 및 정수의 형태인) 호출을 리턴할 수 있다. 유저가 그러한 잡을 사용할 RTI 서비스를 생성할 때, 정의되는 오퍼레이션은 어느 데이터가 입력시 기대되고, 어느 데이터가 출력시 리턴되는 지를 반영하는 것이 바람직하다. 종래의 객체 지향 프로그래밍 방법과 비교하여, 서비스는 클래스에 대응하고, 오퍼레이션은 방법에 대응하며, 잡은 RTI 입력 스테이지(3138)와 관련된 RTI 입력 테이블(3414) 및 RTI 출력 스테이지(3140)와 관련된 RTI 출력 테이블(3418)과 같이, 메타데이터에 기초한 오퍼레이션의 서명을 정의한다.

예로서, 유저는 RTI 입력 테이블(3414)에서 특정 RTI 오퍼레이션을 위한 입력 아규먼트로서 문자열, 정수를 정의할 수 있다. 유저는 RTI 출력 테이블(3418) 내의 출력을 구조(문자열, 정수, 정수)로서 정의할 수 있다. 실시예에서, 입력 및 출력은 단일 문자열일 수 있다. 다른 필드(그 이상의 호출)가 있는 경우, 유저는 입력 매핑을 커스터마이즈할 수 있다. 15개 정수에 의한 오퍼레이션을 갖는 대신에, 유저는 Opt(구조(문자열, 정수, 정수)):구조(문자열, 정수)와 같은 구조(복수 필드에 의한 복합 타입, 여기서, 각 필드는 복합 오퍼레이션에 대응)를 생성할 수 있다. 유저는 하나의 복합 입력 타입으로 그룹화되도록 입력 파라미터를 그룹화할 수 있다. 그 결과, 어레이를 취급하는 것이 가능해지고, 그리하여 트랜잭션은 마 음과 같이 정의된다: Opt1(어레이(구조(문자열, 정수, 정수)로서 정의된다. 예컨대, 입력 구조는 (이름, SSN, 나이)일 수 있고, 출력 구조는 (이름, 생일)일 수 있다. 어레이는 RTI 서비스를 통하여 진행될 수 있다. 마지막으로, 서비스는 어레이에 대한 대응 응답을 출력한다. 어레이는 단일 트랜잭션으로의 복수 열의 그룹화를 허용한다. RTI 콘솔(3002)에서, 체크박스(5308)는 어레이를 이네이블(enable) 하기 위해 유저가 "복수열을 수용"하게 허용한다. 입력을 정의하기 위해, RTI 콘솔(3002)에서, 입력으로서 오퍼레이션의 서명의 일부가 될지의 여부를 결정하기 위해서, 특정 열이 체크되거나 체크되지 않을 수 있다. 유저는 오퍼레이션에 특정 칼럼(column)을 노출하는 것을 원하지 않을 수 있으며(예컨대, 특정 오퍼레이션에서 항상 동일할 수 있기 때문에), 그 경우에 유저는 입력을 위한 정적 값을 고정할 수 있어서, 오퍼레이션은 정적 값이 아닌 변수만을 볼 수 있다.

특정 오퍼레이션의 서명의 일부로서 저장될 수 있는 액션인, 출력의 특정 칼럼을 무시하기 위해 RTI 콘솔을 사용하는 것과 같이, 유사한 프로세스가 오퍼레이션을 위한 출력을 매핑하기 위해 사용될 수 있다.

실시예에서, RTI 서버(2802)로부터 데이터 통합 플랫폼(2702)을 통과하는 RTI 서비스 요구는 파일의 큰 세트나 배치보다는 개별 요구의 파이프라인으로 전달된다. 파이프라인 접근법은 개별 서비스 요구가 데이터 통합 잡(3134)의 이미 실행중인 인스턴스에 의해서 즉시 픽업되게 허용하여, 엔터프라이즈가 배치 통합 잡의 완료를 대기하게 요구하는 대신에 신속한 실시간 데이터 통합을 이끈다. 파이프라인을 통과한 서비스 요구는 웨이브로서 고려될 수 있고, 각 서비스 요구는 스 타트 오브 웨이브 마커(start of wave marker) 및 엔드 오브 웨이브 마커에 의해서 마크될 수 있어서, RTI 에이전트(3132)가 새로운 서비스 요구의 개시 및 특정 서비스 요구를 위한 데이터 통합 잡(3134)의 완료를 인식한다.

엔드-오브-웨이브 마커는 작업의 유닛의 연속을 묘사하며, 각 유닛은 엔드-오브-웨이브 마커에 의해서 분리된다. 엔드-오브-웨이브 마커의 이용은 시스템이 동일한 서비스에 의한 배치 및 실시간 오퍼레이션을 하게 허용할 수 있다. 배치 환경에서, 데이터 이동은 리소스 집약적이기 때문에, 데이터가 이동되는 횟수를 줄이기 위해서, 데이터 통합 유저는 해당 스테이지에서의 처리량을 최대화한 후, 다음 스테이지로 벌크로 전송하는 것과 같이, 데이터의 플로우를 최적화하기를 통상적으로 원한다. 반대로, 실시간 프로세스에서, 데이터 통합 유저는 각각의 트랜잭션 요구를 플로우를 통하여 가능한 한 빠르게 이동시키기를 원할 수 있다. 엔드-오브-웨어브 마커는 처리를 개시하기 위해서 더 많은 데이터를 대기하는 것 보다(시스템이 통상적으로 배치 모드에서 행하는 바와 같이), 데이터 통합 작업을 통하여 특정 요구를 플러시하기 위해 잡 인스턴스를 통지하는 신호를 전송한다. 엔드-오브-웨이브 마커의 이점은 해당 잡 인스턴스가 엔드-오브-웨이브 마커에 의해서 서로 분리되는 복수의 트랜잭션을 동시에 처리할 수 있다는 것이다. 두 엔드-오브-웨이브 마커 사이에 있는 것은 무엇이든지 트랜잭션이다.

파이프라이닝은 서비스에 의해 복수의 요구가 동시에 처리되게 허용한다. 프로세스 풀링 설비(3102)의 로드 밸런싱 알고리즘은 데이터 통합 잡의 새로운 인스턴스를 개시하기 이전에 단일 인스턴스를 그것의 최대 용량까지 충전할 수 있다 (파이프라인을 충전). 실시간 통합 모델에서, 실시간으로 처리되는 재호출(recall)을 갖는 경우(시스템이 배치를 처리하기 이전에 버퍼를 통상적으로 충전하는 배치 모드와는 달리), 엔드-오브-웨이브 마커는 복수의 트랜잭션을 데이터 통합 잡의 플로우로 파이프라이닝하게 허용할 수 있다. 잡은 사용되지 않은 처리율 용량을 갖는 동안에도 비지(busy)할 수 있기 때문에, 로드 밸런싱을 위해, 밸런스는 잡이 비지한 곳에만 기초하지 않는 것이 바람직할 수 있다.

한편, 파이프라인의 용량이 그것의 최대에 도달하기 이전에 새로운 데이터 통합 잡을 시작하는 것을 피하는 것이 바람직할 수 있다. 이는 로드 밸런싱은 동적일 필요가 있고 부가적인 특징에 기초할 필요가 있다는 것을 의미한다. RTI 에이전트 프로세스에서, RTI 에이전트(3132)는 RTI 서버(2802)에 의해서 접속된 각각의 데이터 통합 플랫폼(2702) 상에서 실행하는 인스턴스에 대하여 인지한다. RTI 에이전트(3132)에서, 유저는 데이터 통합 플랫폼(2702) 상에서 실행하는 각각의 잡을 위해 버퍼를 생성할 수 있다. 각종 파라미터는 동적 로드 밸런싱을 돕기 위해서 RTI 콘솔(3002)에 설정될 수 있다. 하나의 파라미터는 잡 인스턴스에 의한 처리를 대기하는 버퍼 내에 위치될 수 있는 버퍼를 위한 최대 사이즈(요구의 수로 측정)이다. 일정한 처리율을 낳는 단일 요구를 갖는 것이 바람직할 수 있지만, 실제로는 처리율에는 일반적으로 변수가 있어서, 각 잡 인스턴스에 버퍼를 갖는 것이 종종 바람직하다. 제2 파라미터는 파이프라인 임계값이며, 어느 지점에서 새로운 잡 인스턴스를 개시하는 것이 바람직할 수 있는지를 말하는 파라미터이다. 실시예에서, 지연이 트래픽에서의 이례적인 증가의 결과일 수 있기 때문에, 그 임계값은 새로운 인스턴스를 자동으로 개시하기보다는 경고 지시자(warning indicator)를 생성할 수 있다. 제3 파라미터는 임계값이 특정 기간 이상동안 초과하는지를 판정할 수 있고, 그 후 새로운 인스턴스가 개시될 것이다. 요약하면, 버퍼 사이즈, 임계값, 및 인스턴스 개시 지연과 같은 파이프라이닝 특징이 유저가 제어할 수 있는 파라미터이다.

실시예에서, 모든 데이터 통합 플랫폼(2702)은 어센셜 소프트웨어로부터의 데이터스테이지 서버를 사용하는 기기이다. 그 각각에서, 데이터스테이지 잡일 수 있는 데이터 통합 잡(3134)이 존재할 수 있다. RTI 입력 스테이지(3138)의 존재는 배치 처리시 잡 인스턴스가 개시되는 배치 모드와는 달리, 잡(3134)이 항상 활성화되어 실행중이고 요구를 대기하고 있다는 것을 의미한다. 오퍼레이션시, 데이터 통합 잡(3134)은 데이터베이스, 웹 서비스 등과의 모든 필요한 접속을 갖고 활성화되어 실행중이며, RTI 입력 스테이지(3134)는 리스닝하고, 일부 데이터가 오기를 대기하고 있다. 각 트랜잭션을 위해, 엔드-오브-웨이브 마커는 데이터 통합 잡(3134)의 스테이지를 통하여 이동할 수 있다. RTI 입력 스테이지(3138) 및 RTI 출력 스테이지(3140)는 데이터 통합 잡(3134)과 RTU 서비스 환경의 나머지 사이의 통신 포인트이다.

예컨대, 비지니스 엔터프라이즈의 컴퓨터 애플리케이션은 트랜잭션을 위한 요구를 전송할 수 있다. RTI 서버(2802)는 일 실시예에서 어센셜 소프트웨어로부터 데이터스테이지 서버인 각종 데이터 통합 플랫폼(2702) 상에서 RTI 데이터 통합 잡(3134)이 실행중인지를 판정할 수 있다. RTI 서버(2802)는 컴퓨터 애플리케이션 으로부터의 요구에서의 데이터를 RTI 입력 스테이지(3138)가 특정 데이터 통합 잡(3134)을 위해 찾아볼 필요가 있는 것에 매핑한다. RTI 에이전트(3132)는 각각의 데이터 통합 플랫폼(2702) 상에서 무엇이 실행하고 있는지를 추적할 수 있다. RTI 에이전트(3132)는 RTI 입력 스테이지(3138) 및 RTI 출력 스테이지(3140)와 공유된 메모리로 오퍼레이팅할 수 있다. RTI 에이전트(3132)는 엔드-오브-웨이브 마커로 트랜잭션을 마킹하고, 그 트랜잭션을 RTI 입력 스테이지(3138)로 전송한 후, 데이터 통합 잡(3134)이 완료된 때 그 엔드-오브-웨이브 마커를 인식하고, RTI 출력 스테이지(3140)로부터 결과를 취하고, 그 결과를 트랜잭션을 개시한 컴퓨터 애플리케이션에 다시 전송할 수 있다.

여기에 기술한 RTI 방법 및 시스템은 데이터 통합 프로세스가 최근의 바인딩 다중 접속 프로토콜에 의해서 접속 가능한 관리된 요약 서비스의 세트로서 노출되게 허용할 수 있다. 어센셜 플랫폼과 같은 데이터 통합 플랫폼(2702)을 사용함으로써, 유저는 데이터 통합 프로세스(그래픽 유저 인터페이스에서의 플로우에 의해 통상적으로 표현됨)를 생성할 수 있다. 그 후, 유저는 플로우에 의해서 정의된 프로세스를 각종 애플리케이션에 의해서 실시간으로 동기식 또는 비동기식으로 인보크될 수 있는 서비스로서 노출할 수 있다. RTI 서비스의 최대 장점을 취하기 위해서, JMS 큐(프로세스는 큐에 데이터를 포스트(post)하고 애플리케이션은 그 큐로부터 데이터를 검색할 수 있다), 자바 클래스 및 웹 서비스와 같은 각종 프로토콜을 지지하는 것이 바람직할 수 있다. 바인딩이 애플리케이션 특정 프로토콜 요건을 핸들링하기 때문에, RTI 서비스는 요약 서비스로서 정의될 수 있다. 요약 서비스 는 특정 프로토콜 환경보다는, 어느 서비스가 행해지는지에 의해서 정의된다. 더욱 일반적으로, RTI 서비스는 디렉토리 내에 발행되고, 여러 유저에 의해서 공유될 수 있다.

RTI 서비스는 복수의 오퍼레이션을 가질 수 있고, 각 오퍼레이션은 잡에 의해서 실시될 수 있다. 서비스를 생성하기 위해서, 유저는 특정 웹 서비스, 자바 클래스 등에 대하여 알 필요는 없다. RTI 서비스를 통하여 노출될 데이터 통합 잡을 디자인할 때, 유저는 어느 서비스가 호출되려하는지를 알 필요가 없다. 유저는 RTI 서비스를 구축하고, 해당 데이터 통합 요구를 위해, 시스템은 RTI 서비스를 실행할 수 있다. 일부 지점에서, 유저는 RTI 서비스를 웹 서비스, 엔터프라이즈 자바 빈(EJB), JMS, JMX, C++ 또는 그 서비스를 실시할 수 있는 임의의 대다수의 프로토콜 일 수 있는 하나 이상의 프로토콜에 구속한다. 특정 RTI 서비스를 위해서, 여러 바인딩이 존재할 수 있어서, 서비스는 상이한 프로토콜을 갖는 상이한 애플리케이션에 의해서 접속될 수 있다.

RTI 서비스가 정의되면, 유저는 하나의 바인딩, 또는 복수의 바인딩을 부가할 수 있어서, 상이한 프로토콜을 사용하는 복수의 애플리케이션이 RTI 서비스를 동시에 인보크할 수 있다. 통상적인 WSDL 문서에서, 서비스 정의는 포트 타입을 포함하지만, 서비스가 어떻게 호출되지 말할 필요는 있다. 유저는 특정 WSDL-정의 잡에 부가될 수 있는 모든 타입을 정의할 수 있다. 그 예는 'HTTP 오버 SOAP', EJB, 텍스트 오버(Text Over) JMS 등을 포함한다. 예컨대, EJB 바인딩을 생성하기 위해서, RTI 서버(2802)는 엔터프라이즈 자바 빈의 자바 소스를 생성할 것이다. 서비스 전개에서, 유저는 특징, 컴파일 코드를 정의하기 위해서 RTI 콘솔(3002)을 사용하고, 자바 아카이브 파일을 생성한 후, 유저에 자바 애플리케이션 서버를 전개하기 위해서 엔터프라이즈 애플리케이션의 유저에게 그 자바 아카이브 파일을 제공하여서, 각 오퍼레이션은 자바 클래스의 하나의 방법이 된다. 그 결과, RTI 서비스 이름과 자바 클래스 이름 사이의 일대일 대응뿐만 아니라, RTI 오퍼레이션 이름과 자바 방법 이름 사이의 대응이 존재할 수 있다. 그 결과, 자바 애플리케이션 방법 호출은 RTI 서비스 내의 오퍼레이션을 호출할 것이다. 그 결과, 'SOAP 오버 HTTP'를 사용하는 웹 서비스 및 EJB를 사용하는 자바 애플리케이션은 RTI 서비스를 통하여 정확히 동일한 데이터 통합 잡에 갈 수 있다. 진입점 및 출구점은 특정 프로토콜을 필요로 하지 않아서, 복수의 프로토콜 상에서 동일한 잡이 행해질 수 있다.

SOAP 및 EJB 바인딩은 동기적인 프로세스를 지지하는 반면, 다른 바인딩은 비동기적인 프로세스를 지지한다. 예컨대, 'SOAP 오버 JMS' 및 '텍스트 오버 JMS'는 비동기적이다. 예컨대, 실시예에서, 메시지는 큐에 부가될 수 있다. RTI 서비스는 입력 큐에의 비동기적인 입력을 감시하고, 그 출력을 다른 큐에 비동기적으로 포스트한다.

도 32는 RTI 서비스를 위한 내부 아키텍처의 개략도(3200)이다. 아키텍처는 J2EE-컴프라이언트 서버인 RTI 서버(2802)를 포함한다. RTI 서버(2802)는 데이터 통합 플랫폼(2702)의 RTI 에이전트(3132)와 상호작용한다. 프로세스 풀 설비(3102)는 데이터 통합 잡이 패스될 적절한 데이터 통합 플랫폼 기기(2702)를 선 택하여 프로젝트를 관리한다. RTI 서버(2802)는 데이터 통합 잡을 핸들링하기 위한 잡 풀 설비(3202)를 포함한다. 잡 풀 설비(3202)는 잡과 각각이 이용가능한지의 상태를 리스트하는 잡 리스트(3204)를 포함한다. 잡 풀 설비는 RTI 서버(2802)에 패스된 잡을 핸들링하기 위한 오퍼레이션 설비 및 캐시 관리자를 포함할 수 있다. RTI 서버(2802)는 RTI 서버(2802)를 통하여 접속될 수 있는 서비스를 위한 레지스트리에 WSDL 기술(description)을 발행하는 것과 같이, 적절한 공중 또는 사설 레지스트리와의 상호 작용을 관리하기 위한 레지스트리 설비(3220)를 또한 포함할 수 있다.

RTI 서버(2802)는, J2EE에 따라, RTI 서비스를 위한 RTI 세션 빈 런 타임 설비(3210)를 포함하는 EJB 컨테이너(3208)를 또한 포함할 수 있다. EJB 컨테이너(3208)는 RTI 서비스를 가능하게 하기 위하여 메시지 빈(3212), 세션 빈(3214), 및 엔티티 빈(3218)을 포함할 수 있다. EJB 컨테이너(3208)는 JMS 인터페이스(3222), EJB 클라이언트 인터페이스(3224) 및 액시스(axis) 인터페이스(3228)를 포함하는 각종 인터페이스를 용이하게 할 수 있다.

도 33을 참조하면, RTI 서버(2802)와 RTI 에이전트(3132)의 상호작용의 일 태양은, 데이터 통합 잡을 위하여 잡 인스턴스(3302)에 패스되는 서비스 요구의 파이프라인을 RTI 에이전트(3132)가 관리한다는 것이다. 잡 인스턴스(3302)는 데이터 통합 플랫폼(2702) 상에서 실행되며, RTI 입력 스테이지(3138) 및 RTI 출력 스테이지(3140)를 갖는다. 필요에 따라, 하나 이상의 잡 인스턴스(3302)가 특정 데이터 통합 플랫폼(2702) 상에서 실행될 수 있다. 서비스 요구가 RTI 서버(2802)로 부터 패스될 때, RTI 에이전트(3132)는 잡 인스턴스의 열림 및 닫힘을 관리한다. 종래의 배치-타입 데이터 통합과는 대조적으로, RTI 서비스를 위한 각 요구는 잡의 파이프라인(3304)에서 RTI 서버(2802), RTI 에이전트(3132) 및 데이터 통합 플랫폼(2702)을 통하여 이동한다. 파이프라인(3304)은 RTI 에이전트(3132)에 의해서 예컨대, 파이프라인(3304)의 각종 파라미터를 설정함으로써 관리될 수 있다. 예컨대, 파이프라인(3304)은 버퍼를 가질 수 있고, 그 사이즈는 최대 버퍼 사이즈 파라미터(3308)를 사용하여 유저에 의해 설정될 수 있다. 관리자는 새로운 잡 인스턴스(3302)의 개시 이전에 RTI 에이전트(3132)가 받을 수 있는 지연, 즉, 인스턴스 개시 지연(3310)의 주기와 같은 다른 파라미터를 또한 설정할 수 있다. 관리자는 파이프라인이 해당 잡 인스턴스(3302)를 위해서 받을 수 있는 서비스 요구의 수를 나타내는 파이프라인을 위한 임계값(3312)을 또한 설정할 수 있다.

RTI 서비스는 검색가능한 레지스트리 내에서 관리될 수 있다. RTI 서비스는 서비스에 부가되는 프로토콜을 사용 중인 이미 기록된 애플리케이션에 부가될 수 있다. 예컨대, 고객 부가, 고객 삭제, 고객 주소 유효화와 같은 고객 관리 오퍼레이션은 알려진 웹 서비스 프로토콜을 사용하거나 그것에 부가될 수 있다. 고객 관리 애플리케이션은 RTI 서비스에 부가될 수 있고, 여기서 그 애플리케이션은 RTI 서비스의 클라이언트이다. 다르게 말하면, 사전 정의된 애플리케이션이 RTI 서비스에 부가될 수 있으며, 여기서 그 애플리케이션은 RTI 서비스를 호출하거나 사용한다. 그 결과, 유저는 요청 서비스를 특정 장치에 다운로드 하고, 그 서비스를 그 장치로부터(또는 그 장치상에서) 실행할 수 있다.

예컨대, 포켓 PC와 같은 이동 연산 장치(mobile computing device)는 호스팅(hosting) 환경을 가질 수 있다. 이동 연산 장치는 복수의 다운로드 애플리케이션 및 이용 가능한 애플리케이션에서의 이동 데이터 통합 서비스를 위한 하나인 애플리케이션을 가질 수 있다. 이동 장치는 애플리케이션을 브라우징할 수 있다. 이동 장치가 RTI 서비스에 부가되는 애플리케이션을 다운로드 하는 경우, 애플리케이션은 이동 장치에 무선으로 다운로드 되지만, 그것에 부가되는 RTI 서비스를 동시에 인보크 한다. 그 결과, 유저는 이동 애플리케이션 전개를 가지면서, 동시에 엔터프라이즈로부터의 실시간 통합 데이터에 접속할 수 있다. 그리하여, RTI 서비스는 이동 연산 애플리케이션에 고 효율적인 모델을 제공할 수 있고, 엔터프라이즈는 유저가 최근 데이터를 갖게 함으로써 이익을 얻는다.

지금까지는 엔터프라이즈 연산 시스템(1300)을 위한 데이터 통합 시스템(104)의 각종 태양을 일반적인 형태로 기술하였으며, 각종의 상업적 애플리케이션 및 다른 애플리케이션을 포함하는 데이터 통합 시스템(104)의 몇몇 예를 이하 기술한다.

도 34에 도시된 바와 같이, RTI 서비스(2704)를 갖는 데이터 통합 시스템(104)은 금융 서비스 산업과 연계하여 사용될 수 있다. 실시간 데이터 통합 시스템은 금융 서비스 산업 내의 비지니스 엔터프라이즈가 존재할 수 있는 리스크를 피할 수 있게 한다. 예컨대, 금융 회사(3402)의 하나의 지점이 고객(3404)의 대출 애플리케이션(3410)을 취급하는 동안, 다른 지점이 재산 물건의 순가 거래(3408)를 실행하는 경우, 회사(3402)는 대출시에 다른 경우에 받을 리스크보다 많은 리스크 를 떠 않을 수 있다. 실시간 데이터 통합은 해당 트랜잭션이 실행될 때 고객(3404)의 더욱 정확한 프로파일을 금융 회사가 가질 수 있게 허용한다. 그리하여, RTI 서비스(3412)는 대출 애플리케이션과 관련된 컴퓨터 애플리케이션이 고객(3404)의 재산 물건의 순가 계좌에 관한 가장 최근의 데이터를 요구할 수 있게 허용하며, 그 데이터는 재산 물건의 순가 거래(3408)를 취급하는 금융 회사(3402)의 애플리케이션과 관련된 데이터로부터 RTI 서비스(3412)를 통하여 검색될 수 있다. 물론, 금융 회사뿐만 아니라, 여러 엔터프라이즈의 금융 부서는 유사한 금융 결정을 할 수 있어 실시간 데이터 통합으로부터 이점을 얻을 수 있다.

비지니스 엔터프라이즈는 각종 환경 및 여러 목적에서 여기에 기술한 RTI 서비스와 같은 실시간 데이터 통합 서비스로부터 이익을 얻을 수 있다. 일 예는 운영 보고 및 분석의 영역에서 이다. 무엇보다도, RTI 서비스는 실시간 거래 분석의 통합 뷰에 큰 용량의 배치 데이터를 제공할 수 있다. 도 35를 참조하면, 엔터프라이즈 데이터 웨어하우스, 데이터 마트, 데이터베이스 등과 같은 기업 엔터프라이즈의 모든 중요한 데이터소스(3504)를 실시간 호출하는 RTI 서비스(3502)가 구축될 수 있다. RTI 서비스(3502)는 데이터소스(3504)로부터의 데이터에 일관적인 데이터 레벨 변환을 적용할 수 있다. 이러한 방식을 이용하여, RTI 서비스는 소스 시스템 분석을 자동화하고, 실행중인 실시간 데이터 품질 관리를 또한 제공할 수 있다. 금융 서비스 영역에서의 도용 검출 및 리스크 분석, 소매 영역에서의 재고 제어, 예측 및 마켓 바스킷(market-basket) 분석, 금융 영역에서의 준수 활동, 및 소매 영역에서의 감소 분석 및 스태프 스케쥴링과 같은 그러한 RTI 서비스로부터 이 익을 얻을 수 있는 비지니스 엔터프라이즈의 여러 운영 보고 또는 분석 프로세스가 있다. 하나 이상의 소스로부터의 데이터로부터 이익을 얻을 수 있는 임의의 분석 또는 보고 태스크는 잘 정의된 데이터 통합 잡에 따라 실시간 실행 중인 데이터를 검색 및 통합하는 RTI 서비스로부터 유사하게 이익을 얻을 수 있다.

여기에 기술한 것과 같은 RTI 서비스로부터 이익을 얻을 수 있는 비지니스 프로세스의 다른 클래스는 기록 데이터베이스의 마스터 시스템을 생성하는 것을 포함하는 비지니스 프로세스의 세트이다. 도 36을 참조하면, 엔터프라이즈는 소비자(3604)와 같은 특정 토픽에 관한 데이터를 포함하는 여러 데이터베이스를 가질 수 있다. 예컨대, 소비자의 정보는 판매 데이터베이스(3608), CRM 데이터베이스(3610), 지원 데이터베이스(3612) 및 금융 데이터베이스(3614)에 나타날 수 있다. 사실, 실재 비지니스 엔터프라이즈에서, 각각의 이들 부서가 자신의 여러 데이터베이스를 갖는 것은 통상적이지 않다. 데이터 통합 효과로부터의 바람직한 이점의 하나는 여러 데이터베이스를 통하여 데이터 일치성을 확립하는 것이다. 예컨대, 고객 주소 변경과 같은 트리거링 이벤트(3618)의 경우, 비지니스의 단지 하나의 엔티티는 정보를 초기에 검색할 수 있지만, 모든 다른 부서가 그 변경에 접속할 수 있는 것이 바람직할 수 있다. RTI 서비스는 원 데이터베이스에서의 변경에 대한 요구 없이 마스터 시스템의 생성 가능성을 제공한다. 그리하여, 상이한 플로토콜을 사용하는 것을 포함하여, 정보의 상이한 리포지토리를 링크하는 RTI 프로세스(3602)가 정의될 수 있다. 복수의 바인딩을 지원함으로써, RTI 프로세스는 입력을 받아들이고, 상이한 포맷의 각종 애플리케이션에 출력을 제공할 수 있다. 한 편, RTI 서비스 내의 비지니스 논리는 모든 유입 데이터에 대한 데이터 표준화 수행, 모든 데이터에 대한 메타 리니지(lineage) 정보의 제공, 및 상이한 데이터 소스 사이의 링크를 유지하는 것과 같은 데이터 통합 태스크를 수행할 수 있다. 그 결과는 RTI 서비스로서 접속될 수 있는 실시간, 최근 마스터 기록 서비스이다.

마스터 기록으로부터 이익을 얻을 수 있는 애플리케이션의 여러 예가 있다. 금융 서비스에서, 회사는 전체 엔터프라이즈에 걸친 보안 마스터 기록뿐만 아니라 고객 마스터 기록을 갖기를 원할 수 있다. 전기통신에서, 많은 수의 고객을 관리하는 보험 및 다른 산업에서, 마스터 기록 서비스는 일치적인 빌링, 클레임 처리 등을 지원할 수 있다. 소매 엔터프라이즈에서, 마스터 기록은 판매 시점 관리(POS) 애플리케이션, 웹 서비스, 고객 마케팅 데이터베이스, 및 재고 동기화 기능을 지원할 수 있다. 제조 및 로지스틱스(logistics) 애플리케이션에서, 비지니스 엔터프라이즈는 디자인, 제조, 재고, 판매, 반품, 서비스 의미, 보증 정보 등과 같은 상이한 소스로부터의 제품에 관한 데이터를 위한 마스터 기록 프로세스를 확립할 수 있다. 다른 경우에, 비지니스는 ERP 인스턴스 통합을 지원하기 위해 RTI 서비스를 사용할 수 있다. 마스터 기록을 실시하는 RTI 서비스는 상이한 데이터 소스가 서로 토크(talk) 하게 허용하기 위한 네이티브 애플리케이션 내의 코딩을 요하지 않고 데이터 통합의 이익을 허용한다.

도 37의 실시예는 마스터 고객 데이터베이스(3700)를 제공한다. 마스터 고객 데이터베이스(3700)는 내부 및 외부 시스템을 포함하여 고객에 관한 일부 데이터를 포함하는 여러 다른 데이터베이스에 걸친 통합 고객 뷰를 포함할 수 있다. 마스터 고객 데이터베이스는 모든 다른 소스로부터의 고객에 관한 "베스트" 데이터를 포함할 수 있는 마스터 시스템일 수 있다. 마스터 고객 데이터베이스를 확립하기 위해서, 데이터 통합은 데이터의 매칭, 표준화, 통합, 변환 및 보강을 필요로 하며, 이 모든 것은 RTI 서비스(3702)에 의해서 수행된다. 일부 데이터가 배치 모드로 처리될 수 있는 반면, 신속히 변하는 데이터가 이용가능한 가장 정확한 데이터가 되는 것을 보장하기 위해서 새로운 데이터는 실시간으로 처리되어야 한다. 마스터 고객 데이터베이스는 소매, 금융 서비스, 제조, 로지스틱스, 전문 서비스, 의료 및 약국, 전기통신, 정보 기술, 바이오 기술, 또는 기타 여러 가지를 포함하는 대부분의 임의의 필드에서의 비지니스 엔티티에 의해서 사용될 수 있다. 유사한 데이터 관리는 단체, 학교 기관, 정부 기관, 또는 임의의 다른 큰 조직 또는 기관에서 바람직할 수 있다.

여기에 기술하는 바와 같은 RTI 서비스는 거래 비지니스 프로세스에, 변환, 유효화 및 표준화 루틴과 같은 데이터 통합 태스크를 노출하는 여러 서비스를 또한 지원할 수 있다. 그리하여, RTI 서비스는 실행 데이터 품질에 가동 및 변환을 제공할 수 있다. 애플리케이션은 전체 비지니스 엔터프라이즈에 걸쳐 표준 비지니스 논리의 재사용을 촉진하는 서비스 지향 아키텍처를 통하여 그러한 서비스에 접속할 수 있다. 도 38을 참조하면, 전술한 RTI 서비스(2704)일 수 있는 RTI 서비스(3802)는 어센셜의 데이터스테이지 플랫폼과 같은 데이터 통합 플랫폼(3804)에 의해서 실시되는 것들과 같이, 데이터 변환, 유효화 및 표준화 루틴의 세트를 실시한다. 애플리케이션(3808)은 실행중인 데이터 통합 태스크를 달성하기 위해서 RTI 서비스(3802)를 호출하는 이벤트를 트리거할 수 있다.

여러 비지니스 프로세스는 실시간 변환, 유효화 및 표준화 루틴으로부터 이득을 얻을 수 있다. 이는 텔레마케팅 산업에서 콜센터 업(up) 판매 및 크로스(cross) 판매, 금융 산업에서 재보험 리스크 유효화, 소매 비지니스에서 POS 계좌 생성, 및 건강 관리 및 정보 기술 서비스와 같은 분야에서의 향상된 서비스 품질을 포함할 수 있다.

도 39를 참조하면, 실시간 데이터 통합 서비스로부터 이익을 얻을 수 있는 비지니스 프로세스의 예는 손해 보험(property insurance) 등의 보험 정책을 위한 채권 인수(underwriting)와 같은 채권 인수 프로세스(3900)이다. 채권 인수 프로세스는 텍스트 파일(3902), 스프레드시트(3904), 웹 데이터(3908) 등과 같은 상이한 타입의 각종 상이한 데이터 소스에의 접속을 필요로 한다. 데이터는 일치하지 않고 에러가 발생할 수 있다. 보충 데이터의 조달 기간은 채권 인수 결정을 느리게 한다. 메인 채권 인수 데이터베이스(3910)는 일부 데이터를 포함할 수 있지만, 다른 상관 데이터는 환경 데이터베이스(3912), 점유 데이터베이스(3914), 지리적 데이터베이스(3918)와 같은 각종의 다른 데이터베이스 내에 포함될 수 있다. 그 결과, 다른 소스 및 데이터베이스가 결정시 통합되지 않는다면, 채권 인수 결정은 결함이 있는 가정에 기초하여 이루어질 수 있다.

실시간 통합 서비스를 사용하여 각종 데이터 소스(3902, 3904, 3908, 3912, 1914, 1918)에의 접속을 통합함으로써, 채권 인수 결정의 속도 및 정확도가 향상될 수 있다. 도 40을 참조하면, RTI 서비스는 채권 인수 결정의 품질을 향상시킬 수 있다. 텍스트 파일, 스프레드시트, 및 웹 파일은 전술한 임의의 RTI 서비스(2704)일 수 있으며, RTI 서버(3904) 상에서 실행중인 RTI 서비스에 웹 인터페이스(3902)를 통하여 입력될 수 있다. 환경 데이터베이스(3912), 점유 데이터베이스(3914), 및 지리 데이터베이스(3918)뿐만 아니라, 채권 인수 데이터베이스(3910)는, 어센셜 소프트웨어 퀄리티스테이지 제품에 의해서 실행되는 것과 같은 클래스 프로세스(4010)와 웨이브 프로세스(4008)를 포함할 수 있는 데이터 통합 잡(4012)에 의해서 모두 호출될 수 있다. RTI 서비스는 데이터베이스의 각각을 위한 프로토콜에 대한 바인딩을 포함할 수 있다. 그 결과, 통합된 채권 인수 결정 프로세스는 모든 스케쥴로부터의 현재 정보뿐만 아니라 RTI 서비스에 의해 모두 이네이블 되는 다른 데이터베이스로부터 이익을 얻는다. 예컨대, 채권 인수 프로세스는 현재의 주소 정보를 필요로 하고, 전술한 바와 같은 RTI 통합 잡은 다른 데이터소스로부터의 수천의 주소를 신속히 통합할 수 있다.

엔터프라이즈 데이터 서비스는 여기에 기술한 바와 같은 데이터 통합 서비스로부터 이익을 얻을 수도 있다. 특히, RTI 통합 프로세스는 표준 통합 데이터 접속 및 변환 서비스를 제공할 수 있다. RTI 통합 프로세스는 내부 및 외부의 다른 데이터 소스에의 가상 접속을 제공할 수 있다. RTI 통합 프로세스는 실행 데이터 품질 보강 및 변환을 제공할 수 있다. RTI 통합 프로세스는 그 프로세스를 통과하는 모든 메타데이터를 또한 추적할 수 있다. 도 41을 참조하면, 하나 이상의 RTI 서비스(4102, 4104)는 데이터 서비스를 제공하기 위해 엔터프라이즈 내에서 오퍼레이팅할 수 있다. 그것들 각각은 데이터 통합 잡(4108)을 지원할 수 있다. 데이터 통합 잡(4108)은 엔터프라이즈의 내부 및 외부의 다른 네이티브 언어 및 프로토콜을 갖는 상이한 데이터 소스일 수 있는 데이터베이스(4110)에 접속할 수 있다. 엔터프라이즈 애플리케이션은 RTI 서비스(4102, 4104)를 통하여 데이터 통합 잡(4108)에 접속할 수 있다.

도 42를 참조하면, 실시간 통합 서비스로부터 이익을 얻을 수 있는 다른 비지니스 엔터프라이즈는 운송 브로커와 같은 물류 엔터프라이즈이다. 운송 브로커는 일 위치로부터 다른 위치로 상품을 운반하는 다수의 트럭(4202)을 취급할 수 있다. 트럭(4202)은 트럭이 일 위치에 도착했을 때 트럭(4202)이 로그 인하게 허용하는 애플리케이션과 같은 단순 애플리케이션(4204)을 실행하는 원격 장치를 가질 수 있다. 트럭(4202)의 운전자는 체크포인트에의 도착과 같은 데이터를 운전자가 입력하는데 사용할 수 있는 랜드스타(LandStar) 위성 시스템 장치와 같은 이동 연산 장치를 종종 가질 수 있다. 엔터프라이즈 자체는 화물 운송 빌(freight bill) 애플리케이션(4208), 에이전트 프로세스(4210), 및 체크 콜(check call) 애플리케이션(4212)과 같은 몇몇 컴퓨터 애플리케이션 또는 데이터베이스를 가질 수 있다. 하지만, 드라이버에게 유용한 정보를 제공할 수 있는 프로세스를 처리하는 동안에, 이러한 네이티브 애플리케이션은 트럭(4202)의 이동 장치상에서 실행하도록 통상적으로 코딩되지 않는다. 예컨대, 드라이버는 트립(trip)을 스케줄링할 수 있기를 원할 수 있지만, 트립 스케줄링 애플리케이션은 트럭(4202)의 이동 장치에 상주하지 않는 데이터(예컨대, 어느 다른 트립이 완료되었는지와 같은)를 필요로 할 수 있다.

도 43을 참조하면, RTI 모델을 사용하여, 데이터 통합 서비스(4302)의 세트가 예컨대 이동 장치를 사용하여 웹 서비스에 접속할 수 있는 애플리케이션(4310)을 지원하도록 정의될 수 있다. 예컨대, 애플리케이션(4310)은 드라이버가 자신의 스케줄을 트럭 브로커 엔터프라이즈로부터의 데이터로부터 갱신하게 허용할 수 있다. RTI 서버(4304)는 데이터 통합 서비스(4302)로부터의 데이터 통합 잡을 발행하고, 애플리케이션(4310)이 그것을 웹 서비스(4308)로서 접속한다. 데이터 통합 서비스(4302)는 화물 운송 빌 애플리케이션(4208) 및 에이전트 프로세스(4210)로부터의 데이터를 포함하여, 어느 잡이 이미 완료되었는지에 관한 것과 같은 엔터프라이즈로부터의 데이터를 통합할 수 있다. 전술한 임의의 RTI 서비스(2704)일 수 있는 RTI 서비스는 예컨대, 스케줄링 애플리케이션을 제공하기 위하여, 드라이버의 애플리케이션을 위한 스마트 그래픽 유저 애플리케이션으로서 역할할 수 있다. 드라이버는 서비스를 인보크하기 위하여 애플리케이션을 이동 장치에 다운로드할 수 있다. 그 결과, RTI 서비스 모델을 사용함으로써, 이동 장치상에서 RTI 서비스를 사용하는 애플리케이션을 위한 인프라구조를 제공하는 것이 편리해진다.

다른 예로서(도시 생략), 데이터 통합은 재고 관리 및 부패하기 쉬운 상품 배달과 같은 공급 체인 관리를 향상시키는데 사용될 수 있다. 예컨대, 공급 체인 관리자가 각종 소매 스토어 위치에서의 현재 재고 수준의 현재 픽처(picture)를 갖는 경우, 관리자는 재고 수준이 낮거나 수요가 높은 스토어로의 추가의 배달 또는 부분적 선적을 지시하여 보다 효율적인 상품 배달을 달성할 수 있다. 유사하게, 마케팅 관리자가 소매 스토어 또는 웨어하우스에서의 재고 수준에 관한 현재의 정 보 및 수요에 관한 현재의 정보(국가의 다른 지역에서와 같은)를 갖는 경우, 관리자는 수요가 약하거나 재고 수준이 예상외로 높은 품목에 관한 가격을 낮추는 등과 같이 그 정보를 고려하여 가격, 광고 또는 프로모션을 구축할 수 있다. 물론, 이는 단순한 예이지만, 바람직한 실시예에서 관리자는 매우 복잡한 비지니스 결정이 실시간으로 이루어질 수 있게 하는 광범위의 데이터 소스에 접속할 수 있다.

그러한 시스템의 가능한 애플리케이션은 사실상 무한적이다. 체중 감소 회사는 데이터 통합을 사용하여, 현존 고객으로부터 회사로의 수익을 강화시키기 위하여 사용될 수 있는 새로운 마케팅 기회를 위한 고객 데이터베이스를 준비할 수 있다. 금융 서비스 회사는 데이터 통합을 사용하여, 은행원, 관리자, 및 분석가의 보고 및 분석을 위한 단일의, 유효한 소스를 준비할 수 있다. 제약 회사는 데이터 통합을 사용하여, 각종 텍스트 데이터 필드 내의 자유로운 형태의 데이터를 포함하는 상이한 표준 및 포맷을 사용하여 다양한 레거시 데이터 소스(legacy data source)로부터 데이터 웨어하우스를 생성할 수 있다. 웹 기반 마켓플레이스(marketplace) 제공자는 데이터 통합을 채용하여, 구입자와 온라인 상인 사이의 수백만의 일상 거래를 관리할 수 있다. 은행은 데이터 통합 서비스를 채용하여, 현재 고객에 관하여 더욱 많이 알 수 있고 저축 예금 계좌, 당좌 예금 계좌, 신용 카드, 기탁 증명, ATM 서비스와 같은 상품에 관한 제공을 개선할 수 있다. 전기통신 회사는 고 처리율의 병렬 처리 데이터 통합 시스템을 채용하여, 호출 캠페인 사업의 수를 증가시킬 수 있다. 수송 회사는 고 처리율의 병렬 처리 데이터 통합 시스템을 사용하여, 하루에 4회와 같이 하루 내의 서비스의 가격을 재책정할 수 있 다. 투자 회사는 고 처리율의 병렬 처리 데이터 통합 시스템을 채용하여, SEC 거래 안정화 시간 요건에 따르고 금융 거래를 안정화하기 위해 요구되는 시간, 비용 및 노력을 일반적으로 줄일 수 있다. 건강 관리 제공자는 데이터 통합 시스템을 사용하여, "U.S. Health Insurance Portability and Accountability Act"의 요건을 충족시킬 수 있다. 웹 기반 교육 제공자는 데이터 통합 시스템을 사용하여, 학생의 라이프사이클을 감시하고, 리쿠르팅 효과뿐만 아니라 학생 증가 및 유지를 향상시킬 수 있다.

데이터 통합 시스템의 특정 상업적 애플리케이션의 여러 부가적인 예를 이하 제공한다.

도 44는 금융 리포팅에 사용될 수 있는 데이터 통합 시스템(104)을 도시한다. 이러한 예에서, 시스템(4400)은 판매 및 주문 처리 시스템(4402), 총계정원장(general ledger)(4404), 데이터 통합 시스템(104), 및 금융 및 재무 회계 리포팅 데이터 웨어하우스(4408)를 포함할 수 있다. 판매 및 주문 처리 시스템(4402), 총계정원장(4404), 및 금융 및 재무 회계 리포팅 데이터 웨어하우스(4408)는 전술한 임의의 데이터 소스(102)와 같은 데이터 소스(102)를 각각 포함할 수 있다. 판매 및 주문 처리 시스템(4402)은 금액, 양, 일자, 시간, 주문 번호, 구매 주문 기간, 상태, 다른 데이터, 및 시스템(4400)에 의해서 처리 및/또는 기록될 수 있는 임의의 거래를 특정하는 임의의 다른 데이터를 포함할 수 있다. 총계정원장(4404)은 잔고 시트, 캐쉬 플로우, 손익 계산서, 및 금융 계약 데이터와 같은 자신의 금융을 추적하는 비지니스에 관련될 수 있는 데이터를 저장할 수 있다. 금융 및 재 무회계 리포팅 데이터 웨어하우스(4408)는 재무 및 회계 부서와, 다른 재무 및 회계 시스템으로부터의 데이터와 같은 비지니스의 펑크션에 관련한 데이터를 저장할 수 있다.

시스템(4400)은 전술한 임의의 데이터 통합 시스템(104)일 수 있으며, 판매 및 주문 처리 시스템(4402)과, 총계정원장(4404)으로부터 데이터를 추출하고, 그 데이터를 전술한 바와 같이 전달, 분석, 처리, 변환 및 조작할 수 있는 하나 이상의 데이터 통합 시스템(104)을 포함할 수 있다. 그러한 임의의 데이터 통합 시스템(104)은 그러한 데이터를 금융 및 회계 리포팅 데이터 웨어하우스(4408)와, 전술한 임의의 데이터 소스(102)일 수 있는 데이터 리포지토리나 다른 데이터 타깃에 로딩한다. 임의의 데이터 통합 시스템(104)은 임의의 다른 데이터 소스(102)로부터의 실시간 갱신 또는 입력을 수신하도록 구성되거나 및/또는 대응하는 금융 및 회계 리포팅 데이터 웨어하우스(4408) 또는 다른 데이터 타깃으로의 대응하는 실시간 출력을 생성하도록 구성될 수 있다. 선택적으로, 데이터 통합 시스템(104)은 비지니스 데이의 종료시나 리포팅 주기의 종료시, 또는 유저 요구와 같은 임의의 외부 이벤트에 응하여 주기적으로 데이터를 추출, 전송, 분석, 처리, 변화, 조작 및/또는 로딩할 수 있다.

이와 같은 방식에서, 데이터 웨어하우스(4408)는 생성 및 유지될 수 있고, 회사에 현재의 금융 및 회계 정보를 제공할 수 있다. 시스템(4400)은 회사가 자신의 재무 능력과 재무 목표를 실시간으로 비교하여 편차에 신속히 실시간으로 응하게 한다. 시스템(4400)은 회사가 임의의 법률 또는 규제 요건, 또는 개인 채무 또 는 다른 대출 계약에 대하여 추종성을 갖게 할 수 있어서, 액션과 관련된 임의의 부가적 비용 또는 벌금을 계산할 수 있게 한다.

도 45는 POS, 고객 관계 관리, 및 소매 또는 다른 스토어 또는 회사에서의 다른 애플리케이션 및/또는 데이터베이스에 사용되는 고객의 믿을만한 현재의 정확한 리스트를 생성 및 유지하는데 사용되는 데이터 통합 시스템(104)을 도시한다. 본 예에서, 시스템(4500)은 POS 애플리케이션(4502), POS 데이터베이스(4504), 고객 관계 관리 애플리케이션(4508), 고객 관계 관리 데이터베이스(4510), 통합 시스템(104) 및 고객 데이터베이스(4512)를 포함할 수 있다.

POS 애플리케이션(4502)은 네트워크연결되거나 독립형인 컴퓨터, 휴대형 장치, 팜 장치, 휴대폰, 바코드 리더, 또는 그것들의 임의의 조합, 또는 판매, 교환, 반품 또는 다른 거래를 처리하기 위한 임의의 다른 장치나 장치의 조합에서 실행하는 컴퓨터 프로그램, 소프트웨어 또는 펌웨어일 수 있다. POS 애플리케이션은 전술한 임의의 데이터 소스(102)를 포함할 수 있는 POS 데이터베이스(4504)에 링크될 수 있다. POS 데이터베이스(4504)는 판매, 교환, 반품 동안에 및/또는 POS 애플리케이션(4502)에 의해서 처리되거나 기록될 수 있는 임의의 거래를 특정하는 금액, 양, 일자, 시간 및 주문 번호 데이터, 및 임의의 다른 데이터와 같이 다른 거래 동안에 수집된 데이터를 포함할 수 있다. 고객 관계 관리 애플리케이션(4508)은 네트워크연결되거나 독립형인 컴퓨터, 휴대형 장치, 팜 장치, 휴대폰, 바코드 리더, 또는 그것들의 임의의 조합, 또는 이름, 주소, 협력 구조, 생일, 주문 이력, 신용 등급, 및 임의의 고객, 다른 개인이나 엔티티에 관련되거나 특정하는 임의의 다른 데이터와 같은 고객, 다른 개인 및/또는 엔티티에 관한 정보의 입력, 저장, 분석, 조작, 뷰잉 및 또는 검색을 위한 임의의 다른 장치나 장치의 조합에서 실행하는 컴퓨터 프로그램, 소프트웨어 또는 펌웨어일 수 있다. 고객 관계 관리 애플리케이션(4508)은 전술한 임의의 데이터 소스(102)를 포함할 수 있으며, 고객, 다른 개인 및/또는 엔티티에 관한 정보를 포함할 수 있는 고객 관계 관리 데이터베이스(4510)에 링크될 수 있다.

전술한 임의의 데이터 통합 시스템(104)일 수 있는 데이터 통합 시스템(104)은 독립적으로 임의의 POS 애플리케이션(4502)이나 데이터베이스(4504), 또는 고객 관계 관리 애플리케이션(4508)이나 데이터베이스(4510)나 고객 데이터베이스(4512)로부터 데이터를 추출하거나 데이터를 로딩할 수 있다. 데이터 통합 시스템(104)은 또한 그러한 데이터를 전술한 바와 같이 분석, 처리, 변환 또는 조작할 수 있다. 예컨대, 고객 서비스 대표 또는 다른 고용인은 냉장고나 세탁기와 같은 가정용 내구성 품목의 구매 후의 예방 중에 고객 관계 관리 애플리케이션(4508)을 이용하여 고객 주소를 갱신할 수 있다. 그 후, 고객 관계 관리 애플리케이션(4508)은 갱신된 주소 데이터를 고객 관계 관리 데이터베이스(4510)로 이동시킬 수 있다. 그 후, 데이터 통합 시스템(104)은 고객 관계 관리 데이터베이스(4510)로부터 갱신된 주소 데이터를 추출하고, 그것을 공통 포맷으로 변환하여, 고객 데이터베이스(4512)에 로딩할 수 있다. 다음에 고객이 구매할 때, 캐시어 또는 다른 고용인은 POS 애플리케이션(4502)을 사용하여 거래를 완료할 수 있으며, POS 애플리케이션(4502)은 데이터 통합 시스템(104)을 통하여 고객 데이터베이스(4512) 내의 갱신 된 주소 데이터에 접속할 수 있어서, 캐시어 또는 다른 고용인은 POS 애플리케이션(4502)에 주소 정보를 입력하는 것과 대조적으로 그 주소 정보를 확인하기만 하면 된다. 또한, POS 애플리케이션(4502)은 새로운 거래 데이터를 POS 데이터베이스(4504)에 전송할 수 있다. 그 후, 데이터 통합 시스템(104)은 POS 데이터베이스(4504)로부터 거래 데이터를 추출하고, 그것을 공통 포맷으로 변환하여, 고객 데이터베이스(4512)에 로딩할 수 있다. 그 결과, 새로운 거래 데이터는 POS, 고객 관계 관리 애플리케이션뿐만 아니라, 비지니스 엔터프라이즈에 의해 유지되는 다른 애플리케이션 또는 데이터베이스에 접속될 수 있다.

이와 같은 방식에서, 고객 데이터베이스(4512)는 생성 및 유지될 수 있으며, 소매나 다른 스토어 또는 회사에 자신의 고객에 관한 현재의 정확하고 완전한 데이터를 제공할 수 있다. 이러한 정보에 의해, 스토어 또는 회사는 자신의 고객에 잘 서비스할 수 있다. 예컨대, 고객 서비스가 고객에게 자신의 다음 구매시의 디스카운트를 보장한 경우, POS 애플리케이션(4502)을 사용하는 캐시어 또는 다른 고용인은 디스카운트를 입증하고, 디스카운트가 사용된 통지를 기록할 수 있다. 또한, 시스템(4500)은 스토어 또는 회사가 고객 사기를 방지할 수 있게 한다. 예컨대, 전화를 통하여 고객 불만을 수신하는 고객 서비스 대표자 또는 다른 종업원은 고객 관계 관리 애플리케이션(4508)을 이용하여, POS 정보에 접속하여 특정 제품의 구매 일자를 판정하고, 제품이 스토어 또는 제조자의 보증에 의해서 여전히 커버 되는지를 판단할 수 있다.

도 46은 소매 약국에서 생성되거나 저장되는 약 보충 또는 다른 정보를 산업 표준 XML 또는 약국 도매업자 또는 다른 부서에서 사용하기 위한 다른 언어로 변환하는데 사용될 수 있는 데이터 통합 시스템(104)을 도시한다. 본 예에서, 시스템(4600)은 소매 약국(4602), 약 보충 정보, 데이터 통합 시스템(104), 및 약국 도매업자(4604)를 포함할 수 있다.

소매 약국(4602)은 네트워크연결되거나 독립형인 컴퓨터, 휴대형 장치, 팜 장치, 휴대폰, 바코드 리더, 또는 그것들의 임의의 조합, 또는 약 보충 정보 또는 다른 정보를 수집하거나 생성하거나 저장하기 위한 임의의 다른 장치나 장치의 조합에서 실행하는 애플리케이션, 컴퓨터 프로그램, 소프트웨어 또는 펌웨어를 사용할 수 있다. 그러한 애플리케이션, 컴퓨터 프로그램, 소프트웨어 또는 펌웨어는 전술한 바와 같은 임의의 데이터 소스(102)와 같은 하나 이상의 데이터 소스(102)를 포함하며, 재고 수준, 취급 날짜, 보충할 순서와 같은 약 보충 정보를 포함하는 적어도 하나의 데이터 소스(102)를 포함할 수 있다. 그러한 애플리케이션, 컴퓨터 프로그램, 소프트웨어 또는 펌웨어는 전술한 바와 같은 임의의 데이터 통합 시스템(104)일 수 있는 하나 이상의 데이터 통합 시스템(104)에 링크될 수 있다. 약국 도매업자(4604)는 네트워크연결되거나 독립형인 컴퓨터, 휴대형 장치, 팜 장치, 휴대폰, 바코드 리더, 또는 그것들의 임의의 조합, 또는 약 보충 정보를 산업 표준 XML 또는 다른 언어나 포맷으로 수신하거나, 분석하거나, 처리하거나, 저장하기 위한 임의의 다른 장치나 장치의 조합에서 실행하는 애플리케이션, 컴퓨터 프로그램, 소프트웨어 또는 펌웨어를 사용할 수 있다. 그러한 애플리케이션, 컴퓨터 프로그램, 소프트웨어 또는 펌웨어는 전술한 바와 같은 임의의 데이터 소스(102)를 포함할 수 있으며, 약 보충 정보를 포함하는 데이터베이스에 링크될 수 있다.

시스템(4600)은 전술한 임의의 데이터 통합 시스템(104)일 수 있는 하나 이상의 데이터 통합 시스템(104)을 포함할 수 있다. 데이터 통합 시스템(104)은 소매 약국(4602)으로부터 약 보충 정보를 추출하고, 그 약 보충 정보를 산업 표준 XML로 변환하거나, 다르게는 그러한 정보를 분석, 처리, 변환 또는 조작한 후, 그러한 정보를 자동으로 또는 요구시 약국 도매업자(4604)에 로딩하거나 전송할 수 있다. 예컨대, 고객은 해당 소매 약국(4602)에서 감기약 X의 끝에서 두 번째 병을 구입할 수 있다. 그 판매 직후, 그 소매 약국의 시스템은 특정 일자 이전에 특정 수의 병만큼 감기약 X의 보유량을 증가시킬 필요가 있는지를 결정하고, 약 보급 정보를 데이터 통합 시스템(104)에 전송할 수 있다. 그 후, 데이터 통합 시스템(104)은 약 보충 정보를 산업 표준 XML로 변환하고, 그것을 약국 도매업자의 시스템에 업로드할 수 있다. 약국 도매업자(4604)는 해당 약국(4602)이 특정 일자 이전까지 요구된 수의 병을 수신하는 것을 자동으로 보장할 수 있다.

그리하여, 시스템(4600)은 소매 약국(4602)이 약국 도매업자(4604)와, 최소의 공급 체인 중단 및 비용이 가능하게 하는 방식으로 통신할 수 있다. 이러한 시스템(4600)은 소매 약국(4602)이 자신의 재고 필요를 약국 도매업자(4604)에게 자동으로 전송함으로써, 비용을 유지하는 잉여 재고와, 만료된 제품으로 인한 낭비와, 약국 도매업자에게 반품하는 것과 관련된 거래 및 다른 비용을 줄일 수 있게 한다. 이러한 시스템(4600)은 양호한 신용 리스크와 약국 도매업자에 대한 시기 적절한 지불을 보장하기 위하여, 신용 이력 검토, 지불, 및 다른 금융 서비스를 지 원하는 부가적인 데이터 통합 시스템(104)에 의해서 보충될 수 있다.

도 47은 운영 최적화, 의사결정 및 다른 펑크션에 데이터가 사용되게 허용하기 위해서, 엔터프라이즈 애플리케이션 통합, 메시지 지향 미들웨어 및 웹 서비스와 같은 비지니스 애플리케이션 및 통합 기술(4708)로부터 인보크 되는 프리빌트(pre-built) 서비스(4704)를 통하여, 제조 분석 데이터(4702)에의 접속을 제공하기 위해 사용될 수 있는 데이터 통합 시스템(104)을 도시한다. 본 예에서, 시스템(4700)은 재고, 지역, 판매, 페이롤(payroll), 인적 자원 및 다른 데이터와 같은 제조 분석 데이터(4702), 프리 빌트 서비스(4704), 비지니스 애플리케이션 및 통합 기술(4708), 단일 유저 또는 복수의 유저(4710), 데이터 통합 시스템(104), 및 유저 비지니스 애플리케이션(4712)을 포함할 수 있다.

유저(4710)는 네트워크연결되거나 독립형인 컴퓨터, 컴퓨터 시스템, 휴대형 장치, 팜 장치, 휴대폰 또는 그것들의 임의의 조합, 또는 임의의 다른 장치나 장치의 조합에서 실행하는 비지니스 애플리케이션 및 통합 기술(4708)을 사용하여, 제조 분석 데이터에의 접속을 제공하기 위하여 프리 빌트 서비스(4704)를 인보크할 수 있다. 프리 빌트 서비스(4704)는 전술한 바와 같은 데이터 통합 시스템(104), 또는 데이터나 다른 정보를 전송, 분석, 수정, 처리, 변환 또는 조작할 수 있는 다른 인프라구조일 수 있다. 프리 빌트 서비스(4704)가 사용될 수 있고, 제조 분석 데이터(4702)는 전술한 바와 같은 임의의 데이터 소스(102)와 같은 데이터 소스(102)를 포함할 수 있는 데이터베이스에 저장될 수 있다. 유저 비지니스 애플리케이션(4712)은 네트워크연결되거나 독립형인 컴퓨터, 컴퓨터 시스템, 휴대형 장 치, 팜 장치, 휴대폰 또는 그것들의 임의의 조합, 또는 제조 분석 데이터(4702) 또는 다른 정보의 분석 또는 처리를 위한 임의의 다른 장치나 장치의 조합에서 실행하는 컴퓨터 프로그램, 소프트웨어 또는 펌웨어일 수 있다. 유저 비지니스 애플리케이션(4712)은 전술한 바와 같은 임의의 데이터 소스(102)와 같은 데이터 소스(102)를 포함하는 데이터베이스에 링크될 수 있다.

시스템(4700)은 전술한 바와 같은 임의의 데이터 통합 시스템(104)일 수 있으며, 비지니스 애플리케이션 및/또는 통합 기술(4708)을 통한 유저 입력, 또는 관련된 다른 유저 또는 외부 이벤트에 응하거나 주기적으로 제조 분석 데이터(4702) 또는 다른 데이터를 추출, 분석, 수정, 처리, 변환 또는 조작할 수 있으며, 그 결과를 데이터의 표시, 저장이나 추가의 처리, 분석 또는 조작을 위해 유저 비지니스 애플리케이션(4712)이 이용할 수 있게 하는 하나 이상의 데이터 통합 시스템(104)을 포함할 수 있다.

예컨대, 존재하는 비지니스 애플리케이션 및 통합 기술(4708)을 사용하는 관리자는 프리 빌트 서비스(4704)를 통하여 특정 제조 분석 데이터(4702)에 접속할 수 있다. 관리자는 재고 내의 특정 부품 그룹의 수와, 그 부품을 조립하기 위해 충분한 종업원과 관련된 페이롤 비용을 결정할 수 있다. 데이터 통합 시스템(104)은 재고, 부품, 페이롤 및 인적 자원 데이터베이스로부터 필요한 데이터를 추출, 통합 및 분석하고, 그 결과를 관리자의 비지니스 애플리케이션(4712)에 업로드할 수 있다. 비지니스 애플리케이션(4712)은 그 결과를 몇몇 텍스트 및 그래픽 포맷으로 표시하고, 유저(관리자)에게 추가의 분석 요구를 촉구한다.

이와 같은 방식에서, 엔터프라이즈에 걸친 관리자 및 다른 의사 결정자가 그들이 요구한 데이터에 접속하게 허용하는 시스템(4700)이 생성될 수 있다. 이러한 시스템(4700)은 행위자가 해당 시점에 이용가능한 모든 데이터의 통합 뷰에 기초하여 많은 정보가 제공된 결정을 하게 허용할 수 있다. 또한, 이러한 시스템(4700)은 여러 상이한 데이터 소스(102)로부터의 데이터를 신속히 통합하고, 단기간에 기업 전체의 분석을 얻을 수 있기 때문에, 엔터프라이즈가 신속하게 결정하게 할 수 있다. 전체적으로, 이러한 시스템(4700)은 엔터프라이즈가 그것의 오퍼레이션, 의사결정 및 다른 펑크션을 최적화하게 허용할 수 있다.

도 48은 이벤트 구동 방식으로 약물 신체 반응 데이터 웨어하우스(4802)로 로딩하기 위하여 임상 실험 연구 결과를 분석적으로 처리하는데 사용될 수 있는 데이터 통합 시스템(104)을 도시한다. 본 예에서, 시스템(4800)은 임상 실험 연구(4804), 임상 실험 연구 데이터베이스(4808), 이벤트(4810), 데이터 통합 시스템(104) 및 약물 신체 반응 데이터 웨어하우스(4810)를 포함할 수 있다.

임상 실험 연구(4804)는 전술한 임의의 데이터 소스(102)와 같은 데이터 소스(102)를 각각 포함할 수 있는 하나 이상의 임상 실험 연구 데이터베이스(4808)에 저장될 수 있는 데이터를 생성할 수 있다. 각각의 임상 실험 연구 데이터베이스(4808)는 환자 이름, 주소, 의료 상태, 조정 및 투여, 흡수, 해당 약에 대한 분배 및 배출 속도, 정부 인증 및 윤리 위원회 승인 정보, 및 임상 실험(4804)과 관련될 수 있는 임의의 다른 데이터와 같이 임상 실험 연구(4804) 동안에 수집되는 데이터를 포함할 수 있다. 약물 신체 반응 데이터 웨어하우스(4802)는 약 상호작 용 및 특성, 생화학, 화학, 물리학, 생물학, 생리학, 의료 학문에 관련한 데이터 및 정보 또는 다른 상당한 정보 또는 데이터뿐만 아니라, 임상 실험 연구 데이터베이스(4808)에 수용된 것과 같은 데이터를 포함하여, 임상 실험 연구(4804)에 관련된 데이터를 포함할 수 있는 전술한 임의의 데이터 소스(102)를 포함할 수 있다. 외부 이벤트(4810)는 유저 입력, 특정 연구의 성과, 다른 결과, 또는 임의의 다른 특정 이벤트일 수 있다.

시스템(4800)은 외부 이벤트(4810)에 응답하여, 또는 비지니스 데이의 완료나 리포팅 사이클의 종료시와 같은 주기적인 기반으로, 임상 연구 데이터(4804) 또는 다른 데이터를 추출, 수정, 변환, 조작 또는 분석적으로 처리할 수 있으며, 그 결과를 약물 신체 반응 데이터 웨어하우스(4802)에 이용가능하게 하는 전술한 바와 같은 하나 이상의 데이터 통합 시스템(104)을 포함할 수 있다. 예컨대, 외부 이벤트(4810)는 연구 허가 애플리케이션과 연계한 특정 정보의 요건일 수 있다. 허가 검토 위원회는 관련 임상 실험을 위한 기금을 할당하는 것을 허용하기 이전에, 진행중인 임상 실험에서의 약 흡수 응답에 관한 데이터를 필요로 할 수 있다. 시스템(4800)은 임상 실험 연구 데이터 데이터베이스(4808)로부터 필요한 데이터를 추출하고, 예컨대, 약 흡수의 평균, 중간, 최대 및 최소 속도를 판정하고 그 결과와 다른 연구의 결과 및 유사한 약에 대한 결과를 비교하기 위하여 그 데이터를 분석적으로 처리하기 위해 사용될 수 있다. 이러한 모든 정보는 허가 검토 위원회에 제시될 수 있다.

이와 같은 방식에서, 연구 및 다른 신속한 접근이, 완료된 임상 실험 및 진 행중인 임상 실험으로부터의 정보를 포함하여 완결하고 정확한 약물 신체 반응 정보가 되게 하는 시스템(4800)이 생성될 수 있다. 이러한 시스템(4800)은 연구자 등이 예비 결과를 생성하고, 역효과 또는 심각해지기 이전의 경향을 검출할 수 있게 한다. 이러한 시스템(4800)은 연구자 등이 해당 연구의 진행 중 또는 최종 결과를 다른 연구자의 결과, 이론 또는 확립된 원리에 링크할 수 있게 한다. 또한, 시스템(4800)은 새로운 연구, 시험 및 실험의 설계시 연구자 등을 보조할 수 있다.

도 49는 과학자(4902)에게 이용가능한 연구(4904)를 자바 애플리케이션(4908)을 통하여 제공하고, 그들이 선택된 연구에 대한 추출, 변환 및 로딩 처리(4910)를 개시할 수 있게 허용하는데 사용될 수 있는 데이터 통합 시스템(104)을 도시한다. 본 예에서, 시스템(4800)은 과학자 그룹(4902), 이용가능한 연구 리스트(4904), 자바 애플리케이션(4908), 연구 데이터베이스(4912), 선택된 연구의 리스트(4914), 추출, 변환 및 로딩 처리(4910), 및 데이터 통합 시스템(104)을 포함할 수 있다.

연구 데이터베이스(4912)는 연구에 관련된 다른 정보뿐만 아니라 연구의 타이틀, 요약, 전체 텍스트, 데이터 및 결과를 저장할 수 있는, 전술한 것과 같은 임의의 데이터 소스(102)를 포함할 수 있다. 자바 애플리케이션(4908)은 컴퓨터, 휴대형 장치, 팜 장치, 휴대폰 또는 그것들의 임의의 조합, 또는 데이터베이스 내에 완전한 연구 목록을 생성하거나 특정 유저 정의 특징이나 다른 특징에 응하여 데이터베이스 내에 연구 목록을 생성할 수 있는 임의의 다른 장치나 그 장치의 조합에서 실행하거나 저장되는 하나 이상의 애플릿을 포함할 수 있다. 과학자, 연구실 인원 등은 그러한 리스트로부터 연구의 서브세트를 선택하고 선택된 연구(4914)의 리스트를 생성할 수 있다.

시스템(4900)은 이용가능한 연구 리스트(4904) 또는 연구 데이터베이스로부터의 데이터를 추출, 변형, 변환, 조작, 처리 또는 분석할 수 있는, 전술한 바와 같은 하나 이상의 데이터 통합 시스템을 포함할 수 있다. 예컨대, 과학자(4902), 실험실 인원 등은 웹 브라우저를 통한 자바 애플리케이션(4908)을 사용하여, 특정 약 또는 의료 상태에 관한 이용가능한 연구 리스트(4904)를 요청할 수 있다. 그 후, 과학자(4902), 실험실 인원 등은 그 리스트로부터 특정 연구를 선택하거나 그 리스트에 다른 연구를 부가하여 선택 연구 리스트(4914)를 생성할 수 있다. 그 후, 과학자(4902), 실험실 인원 등은 추출, 변환 및 로딩 처리(4910)를 위하여 그 선택된 연구 리스트를 데이터 통합 시스템(104)에 전송할 수 있다. 과학자(4902), 실험실 인원 등은 선택된 연구로부터의 특정 포맷의 모든 신진 대사 속도 또는 다른 특정 데이터를 출력으로서 요구할 수 있다.

이와 같은 방식으로, 과학자(4902), 실험실 인원 등이 그러한 연구로부터의 데이터 및 다른 정보를 추출하거나 조작하는 능력과 함께 관련 연구의 디렉토리에의 접속을 허용할 시스템(4900)이 생성될 수 있다. 시스템(4900)은 과학자(4902), 실험실 인원 등이 관련된 이전 데이터 또는 정보를 얻게 허용하여, 불필요한 실험의 반복을 피하거나 연구를 반복하거나 결과와 일치시킬 목적으로 자신 연구의 결과 또는 예측과 상반하는 특정 연구를 선택하게 할 수 있다. 시스템(4900)은 또한 과학자(4902), 실험실 인원 등이 실험실에서의 실험을 실제 수행하지 않고, 새로운 실험을 시뮬레이팅하기 위하여 연구 이전에 결과를 얻고, 통합하고 분석하도록 할 수 있다.

도 50은 POS(5004), 고객 관계 관리(5008), 및 영업 업무 자동화(sale force automation) 시스템(5010)과 같은 복수의 시스템에 걸쳐서 입력될 때, 향상된 고객 이해 및 상세한 지식 또는 다른 목적을 위해 고객 데이터(5002)의 크로스 참조(cross referencing)를 생성하고 유지하는데 사용될 수 있는 데이터 통합 시스템(104)을 도시한다. 본 예에서, 시스템(5000)은 POS(5004), 고객 관계 관리(5008), 영업 업무 자동화(5010)나 다른 시스템(5012), 데이터 통합 시스템(104) 및 고객 데이터 크로스 참조 데이터베이스(5002)를 포함할 수 있다.

POS(5004), 고객 관계 관리(5008) 및 영업 업무 자동화 시스템(5010)은 각각 하나 이상의 애플리케이션 및/또는 데이터베이스를 포함할 수 있다. 애플리케이션은 네트워크연결되거나 독립형인 컴퓨터, 휴대형 장치, 팜 장치, 휴대폰 또는 그것들의 임의의 조합, 또는 임의의 다른 장치 또는 그것의 조합에서 실행하거나 그것에 저장되는 컴퓨터 프로그램, 소프트웨어 또는 펌웨어일 수 있다. 데이터베이스는 전술한 바와 같은 임의의 데이터 소스(102)를 포함할 수 있다. POS 애플리케이션은 판매, 교환, 환불, 또는 다른 거래를 처리 또는 기록하기 위해 사용될 수 있으며, POS 데이터베이스는 가격, 양, 일자, 시간 및 주문 번호 데이터와, 시스템(5000)에 의해서 처리되거나 기록될 수 있는 임의의 거래를 특정하는 임의의 다른 데이터와 같이 판매, 교환, 환불 및/또는 다른 거래 동안에 수집되는 데이터를 포함할 수 있다. 고객 관계 관리 애플리케이션은 이름, 주소, 협력 구조, 생일, 주문 이력, 신용 등급, 및 임의의 고객, 다른 개인이나 엔티티에 관련되거나 특정하는 임의의 다른 데이터와 같은 고객, 다른 개인 및/또는 엔티티에 관한 정보의 입력, 저장, 분석, 조작, 뷰잉 및 또는 검색을 위해 사용될 수 있다. 고객 관계 관리 데이터베이스는 고객, 다른 개인 및/또는 엔티티에 관한 정보를 포함할 수 있다. 영업 관리 자동화 애플리케이션은 리드 생성(lead generation), 컨택(contact) 크로스 참조, 스케쥴링, 성능 추적 및 다른 펑크션을 위해 사용될 수 있고, 영업 관리 자동화 데이터베이스는 다른 데이터뿐만 아니라, 영업 관리의 개별 멤버의 스케쥴, 판매 리드 및 컨택, 성능 목표 및 실제 결과와 관련한 정보 또는 데이터를 포함할 수 있다.

시스템(5000)은 POS(5004), 고객 관계 관리(5008), 영업 업무 자동화(5010) 및 다른 시스템(5012)으로부터의 데이터를 추출, 수정, 변환, 조작, 처리 또는 분석할 수 있으며, 그 결과가 고객 데이터 크로스 참조 데이터베이스(5002)에 이용가능하게 할 수 있는, 전술한 바와 같은 하나 이상의 데이터 통합 시스템(104)을 포함할 수 있다. 예컨대, 시스템(5000)은 유저 요구와 같은 임의의 외부 이벤트에 응답하여, 또는 비지니스 데이의 완료나 리포팅 사이클의 종료시와 같은 주기적인 기반으로, 임의의 또는 모든 POS(5004), 고객 관계 관리(5008), 영업 업무 자동화(5010) 또는 다른 시스템(5012)으로부터의 데이터를 추출할 수 있다. 그 후, 시스템(5000)은 엔터프라이즈에 걸쳐 다른 애플리케이션에 이용될 수 있는 고객 데이터 크로스 참조 데이터베이스(5002)로의 로딩을 위해 그 데이터를 공통의 포맷으로 변환하거나, 다르게는 이동, 처리 또는 조작할 수 있다. 데이터 통합 프로세 스(104)는 또한 임의의 데이터 소스(102)로부터의 실시간 갱신 또는 입력을 수신하도록 구성 및/또는 고객 데이터 크로스 참조 데이터 데이터베이스(5002)로의 대응하는 실시간 출력을 생성하도록 구성될 수 있다.

이러한 방식으로, 엔터프라이즈에 걸쳐 크로스 참조 고객 데이터(5002)를 유저에게 제공하는 시스템(5000)이 생성될 수 있다. 시스템(5000)은 모든 시스템(5000)에 의해 사용하기 위한 정제되고, 일관적이며, 중복이 없는 고객 데이터를 엔터프라이즈에 제공할 수 있어서, 고객의 심층적 이해 및 견고한 고객 관계를 이끌 수 있다.

도 51은 중복을 피하기 위해 인바운드(inbound) 고객 기록(5104)의 온 디멘드 자동 크로스 참조 및 매칭(5102)을 내부 시스템에 걸쳐 저장된 고객 데이터에 제공하고, 임의의 해당 고객에 대한 데이터의 전체 시스템간 기록을 제공하는데 사용될 수 있는 데이터 통합 시스템(104)을 도시한다. 본 예에서, 시스템(5100)은 인바운드 고객 기록(5104), 데이터 통합 시스템(104) 및 내부 고객 데이터베이스(5108)를 포함할 수 있다.

인바운드 고객 기록(5104)은 거래 또는 상호작용 동안에 수집되거나, 이름, 주소, 협력 구조, 생일, 구매한 제품, 정기 유지 보수에 관한 정보 및 다른 정보를 포함할 수 있다. 내부 데이터베이스(5108)는 전술한 바와 같은 임의의 데이터 소스(102)를 포함할 수 있으며, 고객과의 거래 또는 상호작용 동안에 수집되거나 고객에 관한 데이터를 저장할 수 있다. 내부 데이터베이스(5108)는 네트워크연결되거나 독립형인 컴퓨터, 휴대형 장치, 팜 장치, 휴대폰 또는 그것들의 임의의 조합, 또는 임의의 다른 장치 또는 그것의 조합에서 실행하거나 그것에 저장되는 컴퓨터 프로그램, 소프트웨어 또는 펌웨어일 수 있는 내부 애플리케이션에 링크될 수 있다.

시스템(5100)은 인바운드 고객 기록(5104) 또는 내부 고객 데이터베이스(5108)로부터의 임의의 데이터를 추출, 수정, 변환, 조작, 처리 또는 분석할 수 있는 전술한 바와 같은 하나 이상의 데이터 통합 시스템을 포함할 수 있다. 또한, 데이터 통합 시스템(104)은 내부 고객 데이터베이스(5108)에 대하여 인바운드 고객 기록(5104)을 크로스 참조할 수 있다. 예컨대, 내부 고객 데이터베이스(5108)는 고객에 의해 구매된 제품에 관한 정보를 갖는 데이터베이스, 고객에 의해 구매된 서비스에 관한 정보를 갖는 데이터베이스, 각 고객 조직의 사이즈에 관한 정보를 제공하는 데이터베이스, 및 고객에 대한 신용 정보를 포함하는 데이터베이스일 수 있다. 시스템(5100)은 불일치를 드러내어 수정하고, 각 고객에 대한 데이터 기록의 정확성 및 특이성을 보장하기 위해, 제품, 서비스, 사이즈 및 신용 정보에 대하여 인바운드 고객 기록(5104)을 상호 참조할 수 있다.

이러한 방식으로, 정확하고 완전한 고객 기록을 허용하는 시스템(5100)이 생성될 수 있다. 이 시스템(5100)은 보다 나은 고객 서비스를 허용하는 엔터프라이즈 심층 고객 지식을 제공할 수 있다. 시스템(5100)은 고객 데이터베이스에 포함된 데이터에 의존하여 판매인이 고객의 비지니스의 사이즈에 조정되고, 고객에 의해 이미 구매된 것에 보충적인 제품 및 서비스를 제안하게 할 수 있다.

지금까지 각종 데이터 통합 시스템 및 비지니스 엔터프라이즈를 기술하였으 며, 엔터프라이즈 내의 데이터 통합 시스템을 제공하기 위한 아키텍처를 이하에서 상세히 기술한다.

도 52를 참조하면, 아키텍처의 하이 레벨 개략도는 데이터 통합 솔루션의 개발, 전개, 오퍼레이션 및 라이프 사이클을 통합하는 통합 애플리케이션으로서 기능하도록 다수의 서비스가 어떻게 결합될 수 있는지를 도시한다. 데이터 통합 태스크의 단일 플랫폼으로의 통합은 디자인 및 전개의 상이한 측면에 대한 별도의 소프트웨어 제품의 필요성을 없앨 수 있다.

아키텍처(5200)는 GUI/툴 프레임워크(5202), 지능형 자동화 계층(5203), 하나 이상의 클라이언트(5204), API(5208), 코어 서비스(5210), 제품 펑크션 서비스(5212), 메타데이터 서비스(5222), 메타데이터 리포지토리(5224), 구성요소 런 타임(runtime)(5220)과 커넥터(5218)를 갖는 하나 이상의 런 타임 엔진(5214)을 포함할 수 있다. 아키텍처(5200)는 전술한 바와 같은 임의의 서비스 지향 아키텍처(2400)와 같은 서비스 지향 아키텍처(5201) 상에서 전개될 수 있다.

메타데이터 리포지토리(5224)에 저장된 메타데이터 모델은 전개를 통하여 디자인으로부터의 모든 프로세스 단계에서 시스템에 걸친 데이터의 공통 내부 표현(common internal representation)을 제공한다. 모델은 다른 시스템 컴포넌트에 접속될 수 있는 디렉토리 내에 등록될 수 있다. 공통 모델은 메타데이터(데이터 프로파일 정보를 포함하는 데이터 기술 데이터), 데이터 통합 프로세스 스펙(process specification), 유저, 기기 및 소프트웨어 구성 등을 포함하는 수많은 슈트-와이드(suite-wide) 아이템의 공통 표현(모든 제품 펑크션 서비스에 공통인) 을 제공할 수 있다. 이들 공통 모델은 유저가 어느 제품 펑크션을 사용하고 있을지라도 통상의 유저가 엔터프라이즈 리소스 및 통합 프로세스를 뷰 하게 할 수 있고, 통합 제품 펑크션 사이에서의 모델 변환에 대한 필요성을 없앨 수 있다.

서비스 지향 아키텍처(SOA)(5201)는 모든 서비스를 포함하는 것으로서 도시되며, 실행시간 엔진(5214) 및 커넥션(5218)을 통한 GUI(5202)로부터 연산 환경으로의 모든 서비스의 조정(coordination)을 제공할 수 있다. 메타데이터 리포지토리(5224)에 저장될 수 있는 공통 모델은, SOA(5201)가 복수의 서비스 사이의 상호작용을 무결절성으로 제공하게 허용할 수 있다. SOA(5201)는 예컨대, 공통 코어 서비스(5210), 제품 펑크션 서비스(5212) 및 메타데이터 서비스(5222)의 사용에 의하여 모든 태양의 데이터 통합 디자인 및 전개에 GUI(5202)를 노출시킬 수 있고, 지능형 자동화 계층(5203)을 통하여 오퍼레이팅할 수 있다. 공통 모델 및 서비스는 디자인 및 전개 프로세스 동안의 각종 액션에 대하여 GUI(5202) 내의 객체의 공통 표현을 허용할 수 있다. GUI(5202)는 SOA(5201) 조정 서비스와 인터페이스 하는 복수의 클라이언트(5204)를 가질 수 있다. 클라이언트(5204)는 유저가 조직적으로 적절한 레벨에 걸쳐 팀으로서 작업할 수 있게 하는 복수의 스킬 레벨을 갖고 데이터 통합 디자인과 인터페이스 하게 허용할 수 있다. SOA(5201)는 공통 코어 서비스(5210) 및 제품 펑크션 서비스(5212)에의 접속을 제공할 수 있을 뿐만 아니라, 데이터 통합 디자인에서의 펑크션 및 서비스를 위하여 API(5208)에의 백 엔드 지원(back end support)을 제공할 수 있다. 서비스는 복수의 클라이언트(5204) 및 다른 서비스에 의해 공유되고 재사용될 수 있다.

지능형 자동화 계층(5203)은 해당 유저 선택, 또는 자동화한 공통의, 빈번한 및/또는 두드러진 오퍼레이션만을 보여주는 것과 같이, GUI(5202) 내의 유저 선택을 단순화시키기 위해 아키텍처(5200) 내에 메타데이터 및 서비스를 채용할 수 있다. 지능형 자동화 계층(5203)은 자동으로 특정 잡을 생성하고, 디자인 및 디자인 선택을 진단하고, 성능을 조정할 수 있다. 지능형 자동화 계층(5203)은 워크플로우 관리 또는 비지니스 컨텍스트의 모델링과 같은 고위 레벨 디자인 패러다임을 지원할 수 있고, 더욱 일반적으로는, 유저가 더 신속하고 효율적으로 데이터 통합 솔루션을 실행하는 것을 지원하기 위해서 프로젝트 또는 다른 컨텍스트 인식(conxtual awareness)을 인가할 수 있다.

공통 코어 서비스(5210)는 하나 이상의 공통 레지스트리를 위한 디렉토리 서비스, 로깅 및 감사 서비스, 감시, 이벤트 관리, 트랜잭션 서비스, 보안, 라이센싱(예컨대, 라이센싱 정책의 생성 및 집행, 외부 라이센싱 서비스와의 통신 등), SOA 서비스의 관리 및 공급과 같이, 데이터 통합 솔루션의 디자인 및 전개의 모든 태양에 걸쳐 공통으로 사용될 수 있는 공통 펑크션 서비스를 제공할 수 있다. 공통 코어 서비스는 공통 GUI(5202)에의 객체 및 펑크션의 공통 표현을 허용할 수 있다.

다른 제품 특정 펑크션 서비스는 제품 펑크션 서비스(5212) 내에 포함될 수 있고, 특정의 적절한 클라이언트(5204)에게 서비스를 제공할 수 있다. 그러한 서비스는 예컨대, 외부 메타데이터의 임포팅(importing) 및 브라우징뿐만 아니라, 리포트의 생성, 분석, 프로파일링을 포함할 수 있다. 다른 펑크션은 아키텍처를 통 한 데이터 통합 서비스의 디자인, 컴파일링, 전개 및 실행을 위한 서비스와 같은 여러 디자인 지향 서비스일 수 있다. 제품 펑크션 서비스(5212)는 적절한 태스크가 사용될 때 GUI(5202)에 접속될 수 있고, 태스크 지향 GUI(5202)를 제공할 수 있다. 태스크 지향 GUI는 유저에게 데이터 통합 디자인 내의 액션을 위해 적절한 펑크션만을 제공할 수 있다.

애플리케이션 프로그램 인터페이스(API)(5208)는 임의의 또는 모든 서비스, 리포지토리, 엔진, 및 그 안의 커넥터를 포함하여, 전체의 아키텍처에의 접속을 위한 프로그래밍 인터페이스를 제공할 수 있다. API(5208)는 각종 서비스에 의해 사용 및/또는 생성되는 펑크션의 공통 사용 라이브러리(library)를 포함할 수 있으며, 순환적으로 호출될 수 있다.

메타데이터 및 리포지토리 서비스(5222)는 메타데이터 리포지토리(5224)에의 접속을 제어할 수 있다. 모든 펑크션은 메타데이터가 메타데이터 리포지토리(5224) 내의 공통 리포지토리 내에 자신의 펑크션 특정 모델에 의해서 표현되게 유지할 수 있다. 펑크션은 공통 모델을 공유하거나, 각각의 모델 중의 시맨틱(semantic)을 동적으로 변환하기 위해 메타데이터 매핑을 사용할 수 있다. 데이터 통합 디자인에서 사용된 데이터 및 모든 내부 메타데이터는 메타데이터 리포지토리(5224)에 저장될 수 있고, 외부 메타데이터 및 데이터에의 접속은 메타데이터 리포지토리(5224) 내에 저장된 허브(메타데이터 모델)에 의해서 제공되거나, 메타데이터 및 리포지토리 서비스(5222)에 의해서 제어될 수 있다. 메타데이터 및 메타데이터 모델은 메타데이터 리포지토리(5224) 내에 저장될 수 있고, 메타데이터 및 메타데이터 리포지토리 서비스(5222)는 메타데이터 버전 관리(versioning), 지속, 메타데이터 및 메타데이터 모델의 체크 인 및 체크 아웃, 및 다른 메타데이터와 조정되기 전에 유저에 의해서 생성되는 임시 메타데이터를 위한 리포지토리 스페이스를 유지할 수 있다. 메타데이터 및 리포지토리 서비스(5222)는 복수의 서비스, GUI(5202), 내부 클라이언트(5204) 및 외부 클라이언트에 리포지토리 허브를 사용하여 메타데이터 리포지토리(5224)에의 접속을 제공할 수 있다. 메타데이터 리포지토리(5224)에의 다른 서비스 및 클라이언트(5204)에 의한 접속은 메타데이터가 SOA(5201)에 의해서 조정된 무결절성 트랜잭션 내에서 다른 서비스에 의해서 접속, 변환, 결합, 정제 및 질의 되게 허용할 수 있다.

여러 개가 존재할 수 있는 런 타임 엔진(5214)은 외부 소스와의 통신을 위해 어댑터 및 커넥터(5218)를 사용할 수 있다. 엔진(5214)은 유저에 의해서 생성된 디자인을 연산 환경에 기반하여 컴파일링되고 전개된 솔루션을 생성하기 위해 노출될 수 있다. 런 타임 엔진(5214)은 컴퓨터 환경에 최근의 바인딩을 제공하고, 컴퓨터 환경 고려와 독립하여 데이터 통합 솔루션을 디자인할 수 있는 능력을 유저에게 제공할 수 있다. 런 타임 엔진(5214)은 데이터 통합 솔루션을 컴파일링하고, 높은 처리율 및 높은 동시성을 위해 적절히 전개된 런 타임을 제공할 수 있다. 서비스는 각종 서비스에 대한 사용 스펙 및 인터페이스에의 접속을 제공하는 레지스트리로부터 J3EE 구조로서 전개될 수 있다. 서비스는 이질적인 하드웨어 및 소프트웨어 환경에서의 사용을 위해, HTTP, Corba/RMI, JMS, JCA 등과 같은 다중 프로토콜을 지원할 수 있다. 그러한 프로토콜에 대한 바인딩은 런 타임 엔진(5214)에 의해서 자동으로 선택되거나, 전개 프로세스의 일부로서 GUI(5202)로부터 유저에 의해 수동으로 선택될 수 있다.

외부 커넥터(5218)는 네트워크 또는 다른 외부 리소스에의 접속을 제공할 수 있고, 다중 실행 엔진 및 자바와 같은 다른 변환 실행 환경이나 저장된 프로시저를 위한 외부 리소스로의 공통 접속점을 제공할 수 있다.

각종 런 타임 엔진(5214)의 선택 및 사용을 지원하기 위해 부가적인 펑크션 계층이 제공될 수 있다는 점은 이해될 것이다. 이는 높은 처리율 또는 높은 동시성 전개의 지원시 제공될 때 특히 유용하다. 예컨대, 런 타임 엔진(5214)은 잠재적으로 비한정적 길이의 큰 트랜잭션뿐만 아니라, 실시간 트랜잭션의 연속적인 스트림을 분석하기 위해 채택되는 트랜잭션 엔진을 포함할 수 있다. 런 타임 엔진(5214)은 작은 독립적인 트랜잭션을 처리하기 위하여 채택되는 병행 엔진(parallelism engine)을 포함할 수도 있다. 병행 엔진은 파이프라인 플로우 또는 다르게 구획된 플로우로 분할된 사전처리된 입력(및 출력)을 수신하도록 채택될 수 있다. 다른 예로서, 동시성 런 타임 엔진(5214)은 큰 볼륨의 작은 독립적인 트랜잭션과 같은 상호작용 요구(interactive demand)에의 신속한 응답을 위해 최적화될 수 있다. 컴파일 및 최적화 계층은 예컨대, 병행 엔진으로의 출력을 작은 청크(chunk)로 사전처리함으로써 통합 프로세스를 이들 각종 엔진에 어떻게 할당할지를 결정할 수 있다. 아키텍처 내의 커넥터를 중앙화 함으로써, 각종 엔진 사이에서의 프로세스의 분포를 더욱 면밀하게 제어할 수 있고, 유저 인터페이스 레벨에서 그러한 제어에의 접속성을 제공할 수 있다. 또한, 변환 프로세스에서의 접속성의 공통의 중간 표현은 임의의 자동화 전략의 전개, 실행 엔진의 상이한 조합의 선택뿐만 아니라, 예컨대, 메타데이터 또는 프로파일링에 기초한 최적화를 가능하게 한다.

여기에 기술한 아키텍처(5200)는 유저의 작업 환경에 고도의 유연성 및 맞춤성(customizability)을 제공할 수 있다. 이는 예컨대, 주위의 존재하거나 계획된 워크플로우 및 디자인 프로세스에 걸쳐 유저 환경을 구축하는데 적용될 수 있다. 유저는 컴포넌트를 구축하고, 그것을 새로운 구성요소의 디자인에서의 모듈성의 순환적 함유를 허용하는 컴포넌트로서도 역할을 하는 구성으로 결합함으로써 특정 펑크션 서비스를 생성할 수 있다. 구성 요소 및 구성은 메타데이터 및 리포지토리 서비스(5222)에 의해 제공되는 접속에 의해 메타데이터 리포지토리(5224)에 제공될 수 있다. 메타데이터 및 리포지토리 서비스(5222)는 복수의 서비스와의 공통 인터페이스에 공통의 데이터 정의를 제공할 수 있고, 네이티브 데이터 포맷 및 산업 표준 포맷에 대한 지원을 제공할 수 있다. 여기에 기술한 아키텍처의 모듈 특성은 공통 코어 서비스(5210) 및 제품 펑크션 서비스(5212)의 하나로부터 선택된 컴포넌트뿐만 아니라, 전체 아키텍처의 다른 컴포넌트를 갖는 패키지로, 임의의 엔터프라이즈 펑크션 또는 통합 프로세스를 패키징할 수 있게 한다. 시스템 컴포넌트로부터 패키지를 만드는 능력은 공통 코어 서비스(5212)로서 제공될 수 있다. 아키텍처(5200) 내에 이미 존재하는 원자 서비스, 컴포넌트 및 구성의 조합으로서 표현될 수 있는 경우, 이러한 패키징 능력을 통하여, 임의의 펑크션이 구축될 수 있다. 아키텍처(5200)의 패키징 능력은 유저가 원하는 임의의 디자인 워크플로우 또는 디 자인 방법론에 구체적으로 채택되는 유저 인터페이스를 달성하기 위해 유저 인터페이스의 태스크 지향과 결합될 수 있다.

도 52a는 예컨대, 전술한 임의의 펑크션, 서비스 또는 패키지일 수 있는 다수의 태스크로서 유저 인터페이스를 정의하기 위한 태스크 매트릭스를 도시한다. 유저 인터페이스는 유리하게는 디자인 유연성을 유지하기 위하여 하위 기능성으로부터 강하게 분리될 수 있다. 그러한 아키텍처에서, 워크플로우에 의해 언급된 태스크는 유저에게 인터페이스를 제공하기 위해 해석되는 태스크 매트릭스(5250) 내에 조직화될 수 있다. 태스크 매트릭스(5250)는 하나 이상의 컨텍스트(5252)를 포함할 수 있고, 그것의 각각은 복수의 태스크(5254) 및 복수의 메뉴(5256)(이하의 인터페이스에서 기술되는 "필러(pillar)"를 포함한다.

하나 이상의 컨텍스트(5252)는 예컨대, 메뉴 내의 태스크의 복수의 상이한 프리젠테이션과 관련될 수 있다. 복수의 개별적으로 정의된 컨텍스트의 이용을 통하여, 인터페이스는 스킬 레벨 감지형 프리젠테이션 또는 보안 레벨 감응형 프리젠테이션과 같은 각종의 선택적인 프리젠테이션으로 디자인될 수 있다. 더욱 일반적으로, 복수의 선택적 컨텍스트를 제공함으로써, 디자인 유연성의 부가적 치수가 태스크 매트릭스(5250) 내에서 실현된다. 이는 여러 방식으로 사용될 수 있다. 일 예로서, 건강 관리 제공자 및 보험업자는 HIPPA와 같은 규제 방식하에서 내부 기록을 유지하고 다른 사람과 특정 방식으로 거래할 책임이 있다. 이러한 경우에, 제공자 및 보험업자는 개인 식별 정보의 암호화 또는 제공자에 의해 보험업자에 전송된 지불 요구에 대한 공통 포맷의 사용과 같은 복수의 태스크를 공통으로 가질 수 있다. 보험업자 및 제공자를 위한 데이터 통합 프로세스는 실질적인 복수의 태스크를 공통으로 공유하면서, 현저한 차이를 또한 요구할 수 있다. 두 컨텍스트(5252)는 더욱 일반적인 HIPAA-컴프라이언트 인터페이스 정의 하에 동일한 공통 태스크 세트에 기초하여 두 개의 상이한 워크플로우를 정의하기 위해 제공자 및 보험업자에게 사용될 수 있다.

각각의 태스크(5254)는 시스템에 의해서 제공되는 임의 수의 유저 정의 태스크 또는 공통 태스크, 펑크션, 서비스 등이거나, 워크플로우에 관련한 단일의 유용한 태스크로 결합된 그러한 태스크, 펑크션, 및/또는 서비스의 조합일 수 있다. 태스크(5254)는 인터페이스 내의 유용한 다이얼로그, 위저드, 도움창 등을 포함하거나 그것과 조합될 수 있다. 태스크 매트릭스(5250) 내의 식별된 태스크(5254)는 예컨대, 인터페이스 내의 자신의 위치, 인터페이스의 특정 제어 영역과의 조합, 태스크와 조합된 제어, 입력 및 출력 등에 대하여 사전 정의될 수 있다. 그리하여, 유저 인터페이스를 통하여 태스크가 접속될 수 있도록 태스크 매트릭스(5250) 내의 태스크의 존재를 지시하는 것이 단순히 필요하다. 선택적으로, 각 태스크(5254)와 메뉴(5256)의 인터섹션(intersection)은 태스크(5254)의 출현과 관련된 하나 이상의 스펙을 포함할 수 있다. 그리하여, 매트릭스(5250)는 비쥬얼 요소, 제어, 위치, 입력, 출력, 스킬 레벨 파라미터 등을 특정할 수 있다.

각 메뉴 아이템(5256)은 워크플로우의 측면에 대응할 수 있다. 태스크 매트릭스(5250)를 사용하여, 워크플로우를 위한 해당 태스크가 유저 환경 내의 적절한 위치에서 실현될 수 있다.

워크플로우 기반 인터페이스 디자인의 신속한 전개를 더 지원하기 위해, 유저 인터페이스 자체는 비쥬얼 스타일, 제어, 제어 패널, 워크스페이스, 툴, 위저드, 다이얼로그 등의 컬렉션으로서 정의될 수 있다. 동시에, 태스크는 예컨대, 서비스 지향 아키텍처 내의 서비스로서 정의될 수 있다. 그리하여, 태스크 매트릭스(5250)의 사용을 통하여, 각각 하나 이상의 지원 태스크(5254)를 갖는 메뉴 아이템(5256)의 임의의 조합은, 임의의 데이터 통합 또는 다른 워크플로우를 네비게이션 방법론으로 표현하도록 통상적으로 배열될 수 있다.

인터페이스는 공통의 데이터 세트에 대하여 유리하게 오퍼레이팅할 수 있어서, 워크플로우의 각종 측면(즉, 메뉴) 사이 및 일 측면 내의 태스크 사이에 변화가 잔존한다. 각 태스크(5254) 및 각 메뉴(5256)는 동일한 데이터 세트에 상이한 기능적 관점을 나타낼 수 있다. 그리하여, 아키텍처는 워크플로우가 워크플로우의 상이한 측면을 위해 애플리케이션으로부터 애플리케이션으로 데이터를 이동시키는 현존 애플리케이션 기반 환경에 걸쳐 현저한 개선을 제공할 수 있다. 추가의 장점으로서, 태스크 매트릭스(5250) 자체는 개인적 선호 또는 디자인 문제에 따라 유저에 의해 수정될 수 있다. 태스크 매트릭스(5250)를 수정하기 위한 툴은 서비스로서 노출될 수 있고, 유저 인터페이스 또는 서비스 지향 아키텍처 내의 서비스에 클라이언트로서 역할하는 다른 툴을 통하여 유저에 의해 접속될 수 있다.

워크플로우 내의 태스크를 조직화하기 위해 특정 구조가 식별되었을지라도, 임의 수의 데이터 구조 또는 다른 저장 메커니즘이 유저 인터페이스의 정의를 저장, 검색 및 수정하기 위해 사용될 수 있다는 것을 이해해야 하며, 유저 인터페이 스 자체의 아키텍처는 유연성과 디자인의 용이성 사이의 트레이드 오프에 따라, 특이성의 각종 레벨에서 정의될 수 있다는 것 또한 이해해야 한다.

도 53을 참조하면, 복수의 유저 스킬 레벨 및 공통의 디자인 라이브러리(5300) 상호작용의 이해를 제공하기 위해 GUI(5202)의 보다 상세한 개략도가 도시된다. GUI(5202)는 전체 시스템의 하위 기능성으로부터, 특히 메타데이터 리포지토리(5224) 내의 메타데이터 모델 및 디자인의 다른 태양으로부터 강하게 분리될 수 있다. 그러한 "분리된" 다지인에서, 아키텍처의 모든 기능성은 유저 인터페이스에 서비스로서 제시될 수 있다. 유저 인터페이스는 그러한 서비스에 접속하기 위한 유저 제어 및 낮은 레벨 툴의 공통 세트를 제공할 수 있다. 이러한 접근은 인터페이스 또는 하위 시스템에 대한 비교적 똑바른 확장성을 허용하며, 데이터 통합 프로세스의 모든 스테이지에 무결절성 작업 환경을 제공할 수 있다. 새로운 워크플로우 또는 상이한 유저가 발생하는 곳에서, 현존 작업 모델 및 데이터 통합 잡 또는 프로세스에 영향을 끼치지 않고서 인터페이스가 적절히 채택될 수 있다. 새로운 서비스 또는 모델이 개발되는 곳에서는 유저 인터페이스를 변형하지 않고 서비스 지향 아키텍처에 부가될 수 있다(물론, 그렇지 않은 경우에는 상이한 유저 인터페이스가 희망된다).

GUI(5202) 아키텍처는 시스템 아키텍처 또는 메타데이터 모델의 상세한 지식이 없이도 유저가 디자인(5304)을 조작하게 하는 제어 및 컴포넌트를 제공하는 비교적 낮은 스킬의 유저용 인터페이스와 같이 시스템의 대안적인 뷰를 제공할 수 있다. 다른 높은 스킬 레벨 유저 인터페이스는 동일한 메타데이터 모델 상에서 오퍼 레이팅하면서, 모델 디자인에 대한 더욱 상세한 제어를 제공할 수 있다. 높은 스킬 레벨 GUI는 예컨대, 더 많은 펑크션 및 더 큰 커스터마이제이션(customization)에 대한 접속을 제공할 수 있다. 유사하게, GUI(5202)는 감시, 전개, 및 선택적인 제어와 같이 거동적으로 정의되거나, 디렉터, 간부, 임원, 매니저, 애널리스트, 회계원, 엔지니어 등과 같이 계층적으로 정의될 수 있는 대안적인 역할(role) 감지형 뷰를 제공할 수 있다. 역할은 임원이 대표, 부대표 등으로서 분류되거나, 애널리스트가 마케팅 애널리스트, 비지니스 애널리스트, 금융 애널리스트 등으로 분류되는 것과 같이 계층적으로 또한 정의될 수 있다. 다른 예로서, GUI(5202)는 이동 장치를 위해 특별히 채택된 유저 인터페이스, 또는 "Research In Motion Limited"로부터의 "BackBerry 7730" 또는 "Dell Inc."로부터의 "Axim X30" 상에서 사용하기 위해 더욱 특별히 채택되는 플랫폼 감지형 뷰를 제공할 수 있다. 더욱 구체적으로는, 태스크 매트릭스는 랩탑 컴퓨터를 사용하는 기술 인원 또는 모토롤라 휴대폰을 사용하는 회사의 간부를 위해 정의될 수 있다. 각 유저 프로파일은 모두가 공통의 공유된 메타데이터 모델 상에서 오퍼레이팅 하며, 별도의 태스크 매트릭스로서 실현될 수 있다.

GUI(5202)는 다른 외부 툴에 대한 필요성이 없이 디자인의 시초부터 최종 전개까지 디자인 솔루션의 모든 태양에 통합된 유저 환경을 제공할 수 있다. GUI(5202)는 카탈로그 관리, 검색, 질의, 네비게이팅(navigating), 개인화, 스크립팅(scripting), 지속, 또는 데이터 통합 솔루션(5304)의 디자인과 관련된 다른 태스크와 같이 모든 유저 레벨에 공통의 펑크션을 제공할 수 있다. 유저는 스킬 특 정 또는 역할 특정 유저 인터페이스 기능성을 사용하여 데이터 통합 디자인 솔루션(5304)에 접속할 수 있다. 다른 유저 뷰(5302)는 디자인 능력의 복수 레벨의 복잡도를 허용할 수 있다. 일 예로서, 여러 데이터 통합 디자인 솔루션(5304)에서, 각종 스킬을 가진 각종 조직으로부터의 유저는 단일 디자인 솔루션(5304)을 개발하기 위해 서로 팀이 될 수 있다. GUI(5202)는 다양한 스킬의 유저가 그들의 전문 분야에 적용될 수 있는 서비스 및 펑크션을 갖고 작업하게 허용하도록 구성될 수 있다. 아키텍처(5200)는 그러한 팀이 동일한 메타데이터, 모델 및 디자인에 대하여 협력하게 할 수 있고, 라이브 모델이 모든 유저에게 공통이기 때문에, 여러 팀 멤버에 의한 변화가 존재할 때, 글로벌 가시성을 제공할 수 있다.

유저 스킬 레벨에 관계없이, 유저 뷰(5302)는 디자인 솔루션(5304)을 생성하는 각종 유저에 의한 사용을 위해 공통의 펑크션 라이브러리 및 디자인 위저드(5300)에 노출될 수 있다. 라이브러리 및 디자인 위저드(5300) 펑크션은 유저 뷰(5302) 스킬 레벨에 기초하여 접속을 제공할 수 있고, 스킬 레벨 기초로 이용가능한 펑크션을 제한할 수 있다. 유저 뷰(5302)는 메타데이터 및 모델에의 공유된 접속을 갖고 팀 협동을 가능하게 할 수 있다.

유저 뷰(5302)는 데이터 통합 디자인 솔루션(5304)에 대한 태스크 및 텍스트 지향 가이던스로 조직화될 수 있다. 데이터 통합 디자인이 더욱 복잡화됨에 따라, 유저가 디자인 솔루션(5304)에 대하여 작업하는 동안에 태스크 지향 옵션을 제공하는 것이 이로울 수 있다. 일 예로서, 유저가 질의를 개발하고 있는 경우, 이용 가능한 질의 태스크 옵션은 더 적합한 질의 디자인으로 유저를 안내하기 위해 표시될 수 있다. 디자인의 다른 태양이 부가되거나 변형될 때, 적절한 컨텍스트 펑크션 및 서비스는 확고한 디자인 솔루션(5304)에 유저를 안내하는 것을 돕기 위해 유저에게 이용가능해질 수 있다. 일 예로서, 유저는 데이터 소스 컴포넌트를 디자인에 부가할 수 있고, 인터페이스는 임의의 적절한 메타데이터 카탈로그, 임포트, 샘플 데이터 및 데이터 프로파일링 펑크션을 표시할 수 있다. 또한, 이용가능한 카탈로그는 현재의 디자인과 이미 관련된 데이터 소스만을 표시할 수 있다. 유저는 동일한 데이터 소스를 사용한 다른 데이터 통합 디자인을 볼 수 있어서, 유저는 다른 디자인 태양을 재이용할 수 있다.

디자인 솔루션(5304) 상에서 작업하는 동안에, 유저 뷰(5302)는 디자인 솔루션(5304)이 시각적으로 덜 복잡하게 하기 위해 디자인의 특정 상세사항의 표시를 제한할 수 있다. 유저는 모델, 통합 및 조합, 비지니스 프로세스, 제어 플로우, 데이터 접속, 에러 취급 또는 디자인의 다른 태양과 같이, 당시 작업중인 디자인 태양에 유저가 집중하게 허용하기 위해 복수의 계층을 감추거나 노출할 수 있다.

도 53의 태양은 내부 및 외부의 복수의 리소스를 사용하는 복수의 개발 사이트를 갖는 엔터프라이즈 환경에 적용될 수 있다. 유저 뷰는 상이한 위치에서의 관리, 모델링, 분석, 개발, 시험, 오퍼레이션과 같은 트랜잭션에서 복수의 지리적 위치로부터 디자인 솔루선(5304)으로 작업할 수 있다. 도 53에 도시된 모든 태양은 원격 위치에서 이용가능할 수 있다.

도 54는 SOA에 대한 역할 및 관계를 기술하는 UML 다이어그램을 도시한다. SOA 클라이언트(5412)는 서비스 디렉토리(5418)를 통하여 서비스(5414)를 찾아서 예시한다. 각 서비스(5414)는 컴포넌트 서비스(5420)와 같은 공통 공유 서비스를 포함하여 그것의 실행의 일부로서 다른 서비스(5414)를 사용할 수 있다. 컴포넌트 서비스(5420)는 디자인 시 사용될 수 있는 서비스로서 데이터베이스, 파일, 애플리케이션, 큐와 같은 임의의 외부 리소스 커넥터를 노출할 수 있다.

클라이언트(5412)는 서비스(5414)에의 클라이언트로서 역할하는 프로그램 또는 유저 인터페이스의 일반화를 나타낸다. 프로세스 디자이너(5402)는 예컨대, 모델 또는 프로세스를 조작하기 위한 그래픽 유저 인터페이스 또는 프로그램 접속을 제공할 수 있다. API(5410)은 전술한 아키텍처(5200)에 의해서 제공되는 임의의 서비스(5414)일 수 있는 서비스(5414)에 접속하도록 외부 프로그램에 애플리케이션 프로그래밍 인터페이스를 제공할 수 있다. 예컨대, 위저드(5408)는 예컨대, 메타데이터 모델을 생성하거나 통합 태스크의 순환적 컬렉션을 수행하는 디자인 스텝의 프리 패키징된 컬렉션을 제공할 수 있다. 컴파일러(5404)는 컴파일화 및 런 타임 서비스 또는 다른 전개 서비스를 위해 인터페이스를 제공할 수 있다. 이들 특정 인터페이스의 각각 뿐만 아니라, 임의 수의 다른 인터페이스 또는 이들 인터페이스의 조합은 전술한 아키텍처(5200) 내에서의 오퍼레이션을 수행하기 위한 서비스(5414)에의 클라이언트(5412)로서 역할할 수 있다.

각 서비스(5414)는 제1 서비스가 제2 서비스, 또는 제3 서비스나 자체의 다른 인스턴스를 사용할 수 있는 다른 인스턴스를 사용할 수 있다는 점 등에서 순환적일 수 있다. 서비스의 다른 조합을 사용할 수 있는 서비스의 순환적 또는 내포된 구조는 클라이언트(5412)에 일반적으로 투명하다. 더욱 일반적으로, 아키텍 처(5200) 내의 각 제품 펑크션 뿐만 아니라 서비스(5414)의 조합은 클라이언트(5412)에 의해 사용하기 위한 서비스에 고려될 수 있다. 클라이언트(5412)에게 노출된 서비스(5412)는 공통 코어 서비스(5210), 제품 펑크션 서비스(5212), 메타데이터 및 리포지토리 서비스(5222), 또는 서비스 디렉토리(5418)에 카탈로그 되는 임의의 다른 서비스의 일부일 수 있다.

클라이언트(5412)는 서비스 디렉토리(5418)를 통하여 서비스(5414)를 찾아서 예시할 수 있다. 서비스(5414)가 일단 예시되면, 그것은 디자인에서 사용될 수 있다. UML 다이어그램에서 볼 수 있는 바와 같이, 서비스 디렉토리(5418)로부터 정보를 수신하는 서비스(5414)에서, 서비스(5414)에 대한 서비스 디렉토리(5418)의 일대 다수의 관계가 존재할 수 있다. 일 예로서, 클라이언트(5412)는 예시되지 않은 서비스(5412)를 요구할 수 있다. 그 요구는 서비스(5414)를 예시하고 그 서비스(5414)를 클라이언트(5412)에게 노출할 수 있는 서비스 디렉토리(5418)로 보내질 수 있다. 이러한 프로세스는 예시중인 서비스(5414)에 의해서 사용되는 서비스와 같은 제2 서비스를 또한 예시할 수 있다.

컴포넌트 서비스(5420)는 개별 컴포넌트의 기능성에의 접속을 제공할 수 있고, 데이터베이스, 파일, 애플리케이션, 큐, 메타데이터 또는 서비스(5414)로서 이용가능한 다른 리소스와 같은 외부 리소스를 노출할 수 있다. 이들 노출된 외부 리소스는 디자인 시 유저에게 (프로세스 다자이너(5402)를 통하여) 서비스(5414)로서 이용가능하고, 런 타임 시 런 타임 엔진에 이용가능할 수 있다. 또한, 컴포넌트 서비스(5420) 및 커넥터(5218)를 통하여, 외부 리소스는 SOA 아키텍처(5200) 내 의 서비스에의 접속을 가질 수 있다.

도 55를 참조하면, SOA(5201) 환경의 개요는 SOA(5201)가 다른 아키텍처(5200) 클라이언트 및 서비스에 어떻게 인터페이스 하는지를 도시한다. SOA(5201)의 코어는 서비스 바인딩(5512), SOA 인프라구조(5514) 및 서비스 실행(5518)일 수 있다. 서비스 바인딩(5512)은 GUI(5508), 애플리케이션(5504), 스크립 통합(script orchestration)(5502), 관리 프레임워크(5500), 및 다른 클라이언트와 같은 클라인트의 SOA(5201)에 내적 또는 외적일 수 있는 서비스에의 바인딩을 허용할 수 있다. 바운드 서비스는 공통 코어 서비스(5520)의 일부일 수 있으며, 서비스 바인딩(5512)은 서비스를 예시하기 위해 서비스 기술 레지스트리(5510)에 접속할 수 있다. 서비스 바인딩(5512)은 동일하거나 다른 기술을 사용하여 클라이언트가 국부적 또는 외적일 수 있는 서비스를 사용하게 할 수 있다. 외부 서비스에 대한 바인딩은 외부 서비스를 노출할 수 있고, 외부 서비스는 내부 서비스와 동일한 방식으로 인보크될 수 있다. 서비스로의 통신은 동기적이거나 비동기적일 수 있고, 상이한 통신 경로를 사용할 수 있으며, 상태형(stateful) 또는 무상태형(stateless)일 수 있다. 서비스 바인딩(5512)은 HTTP, CORBA/RMI, JMS 또는 JCA와 같은 복수의 프로토콜에 지원을 제공할 수 있다. 서비스 바인딩(5512)은 컴퓨터 환경에 따라 자동적으로 서비스 바인딩에 적절한 프로토콜을 결정할 수 있거나, 유저가 디자인 솔루션(5304)의 일부로서 GUI(5508)로부터 프로토콜을 선택할 수 있다.

관리 프레임워크(5500) 클라이언트는 SOA(5201) 서비스의 인스톨, 노출, 카 탈로그, 구성, 감시, 및 다르게는 관리하기 위한 설비를 제공할 수 있다. 관리 프레임워크(5500)는 커넥션을 통한 외부 서비스, 내부 서비스, 클라이언트에의 접속, 또는 내부 또는 외부 메타데이터에의 접속을 제공할 수 있다.

통합 클라이언트(5502)는 복수의 SOA(5201) 서비스를 디자인 솔루션(5304)으로 구성하여 복수의 복잡한 제품 펑크션 및 워크플로우를 디자인하게 할 수 있다. 서비스는 공통 코어 서비스(5520), 내부 서비스(5524)에 외적인 서비스, 내부 프로세스(5528), 또는 유저 정의 서비스(5522)로부터 구성될 수 있다. SOA(5201)의 통합은 엔터프라이즈 환경에서 통일된 데이터 통합 디자인을 제공하기 위한 능력의 코어에서이다. 클라이언트, 코어 서비스, 메타데이터 리포지토리 서비스, 전개 엔진, 및 외부 서비스 및 메타데이터 사이의 통합은 광범위의 엔터프라이즈 필요를 충족시키는 디자인을 가능하게 한다. 통일된 접근은 전체 슈트를 함께 바인딩하기 위한 아키텍처를 엔터프라이즈 디자인에 제공할 수 있으며, 단일 GUI(5508)가 전개 디자인 솔루션(5304)에 전체 디자인 프로세스의 무결절성 표현이 가능하게 허용할 수 있다.

애플리케이션 클라이언트(5504)는 필요시 서비스가 공통의 펑크션을 호출할 수 있게 허용함으로써 SOA(5201) 조정 서비스에 부가적인 기능성을 프로그램식으로 제공할 수 있다. 애플리케이션 클라이언트(5504)의 펑크션은 서비스가 펑크션을 호출하게 허용함으로써 SOA(5201)의 서비스의 능력을 향상시킬 수 있고, 펑크션이 서비스의 일부인 경우 그것을 적용할 수 있다. GUI 클라이언트(5508)는 SOA(5201) 서비스 및 리소스에, 그 서비스 및 리소스가 그래픽적으로 표시되고 조작되게 허용 함으로써, 유저 인터페이스를 제공할 수 있다. GUI(5508)는 전술한 도 53에 더 완전하게 기술된다.

SOA 인프라구조(5514)는 J2EE 기반일 수 있고, 서비스가 전개 환경에 독립하여 전개되게 허용하는 설비를 제공할 수 있다. SOA 인프라구조(5514)는 전개 환경의 지원시 리소스 풀링(resource pooling), 인터셉션(interception), 직렬화(serializing), 로드 밸런싱(load balancing), 이벤트 리스닝(event listening), 및 감시(monitoring)와 같은 부가적인 기능성을 제공할 수 있다. SOA 인프라구조(5514)는 연산 환경에의 접속을 가질 수 있고, GUI(5508)에 이용가능한 서비스에 영향을 끼치고, 컨텍스트 지향 GUI(5508)를 지원할 수 있다.

SOA 인프라구조(5512)는 예컨대, 엔터프라이즈 자바 빈(EJB) 및 실시간 통합(RTI)을 사용하여 리소스 풀링을 제공할 수 있다. 리소스 풀링은 복수의 동시성 서비스 인스턴스가 내부 및 외부의 소수의 리소스를 공유하게 허용할 수 있다.

SOA 인프라구조는 다수의 유용한 툴 및 특징을 제공할 수 있다. 인터셉션은 암호화의 삽입, 압축, 트레이싱(tracing), 감시, 및 서비스에 투명한 다른 관리 툴을 위해 제공할 수 있고, 이들 서비스의 리포팅을 클라이언트 및 다른 서비스에 제공할 수 있다. 직렬화 및 역직렬화는 복수의 인보크 프로토콜 및 상이한 기술을 통해 복잡한 서비스 요구 및 데이터 전송 지원을 제공할 수 있다. 로드 밸런싱은 복수의 서비스 인스턴스가 복수의 서버에 걸쳐 분포되게 할 수 있다. 로드 밸런싱은 복수의 서버상에서 하나 또는 복수의 프로세서를 접속하는 높은 동시성 처리 또는 높은 처리율 처리를 지원할 수 있다. 이벤트 리스닝 및 생성은 관찰된 외부 이 벤트에 기초한 서비스의 인보크를 가능하게 할 수 있다. 이는 제1 서비스의 펑크션에 기초한 제2 서비스의 인보크를 허용할 수 있고, 그 경우 특정 상태가 발생할 수 있다. 이벤트 리스닝은 이전에 인보크될 때와 동일한 식별자를 사용하여 서비스가 인보크될 수 있는지를 특정하는 콜백(call back) 능력을 또한 지원할 수 있다.

서비스 기술 레지스트리(5510)는 모든 다른 서비스에 대한 사용 스펙 및 모든 인터페이스를 유지하는 서비스일 수 있다. 서비스 기술 레지스트리(5510)는 디자인 솔루션(5304)에 사용될 프로토콜, 바인딩, 및 서비스의 인스턴스를 생성하기 위한 질의 및 선택 서비스를 제공할 수 있다. 일 예로서, 서비스의 인스턴스는 클라이언트 또는 SOA(5201)로의 다른 서비스에 의해서 요구될 수 있으며, 여기서 SOA(5201)는 호출된 서비스의 선택 또는 질의를 요구할 것이다. 그 후, 서비스 기술 레지스트리(5510)는 서비스 바인딩(5512)에 의한 바인딩을 위해 서비스의 인스턴스를 리턴할 수 있고, 그 후 디자인 솔루션(5304)에 사용될 수 있다.

공통 코어 서비스(5520)는 디자인 솔루션(5304) 및 런 타임 전개 솔루션을 생성하도록 인보크될 수 있는 복수의 서비스를 포함할 수 있다. 공통 코어 서비스(5520)는 디자인 솔루션(5304)을 위한 모든 공통 서비스를 포함할 수 있어서, 다른 서비스가 그 서비스 자체의 능력을 유지해야 하는 것으로부터 자유롭게 한다. 그 서비스 자체는 디자인 솔루션(5304)을 완성하는데 필요한 때 공통 코어 서비스(5520) 내의 다른 서비스를 호출할 수 있다. 복수의 클라이언트는 서비스 바인딩(5512), SOA 인프라구조(5514) 및 서비스 기술 레지스트리(5510)를 통하여 공통 코어 서비스(5520)에 접속할 수 있다. 공통 코어 서비스는 또한 메타데이터 리포지토리 서비스(5222) 및 SOA 인프라구조(5514)를 통하여 외부 서비스에 의해서 접속될 수 있다.

부가적인 외부 서비스는 서비스 실행(5518)을 통하여 SOA 인프라구조(5512)에 의해서 지원되는 임의의 환경에 접속할 수 있다. 서비스 실행은 어댑터 및 커넥터(5218)의 이용을 통하여 외부 서비스에의 접속을 제공할 수 있다. 서비스 실행(5518)을 통하여, 서비스(5524)는 디자인 솔루션(5304)을 개발하기 위한 다른 소프트웨어 제품에 의해서 제공되는 특정 제품 기능성을 노출할 수 있다. 이 서비스(5524)는 조사, 디자인, 개발, 테스트, 전개, 오퍼레이션, 감시, 조정, 또는 다른 펑크션을 제공할 수 있다. 일 예로서, 서비스(5524)는 데이터 통합 잡을 수행할 수 있고 메타데이터, 메타 모델, 또는 서비스를 위해 SOA(5201)에 접속할 수 있다.

서비스 실행(5518)은 다른 툴에 의해서 생성되고 SOA 인프라구조(5514)에 서비스로서 노출된 통합 프로세스에 프로세스(5528)의 접속을 제공할 수 있다. 다른 툴의 유저는 그러한 통합 프로세스를 생성하고, 그러한 프로세스는 SOA(5201) 및 클라이언트에 서비스로서 노출될 수 있다.

또한 서비스 실행(5518)은 유저가 자기 자신의 고객 프로세스를 정의 또는 생성하도록 허용할 수 있는 유저 정의 서비스(5522)에의 접속을 제공하고, 그들을 SOA 서비스로서 노출할 수 있다. 유저 정의 서비스(5522)를 SOA 서비스로서 노출하는 것은 그 서비스가 모든 클라이언트 및 SOA(5201)의 서비스에 노출되게 허용한 다.

도 56은 툴(5604), 레거시 툴(5602), 및 외부 툴(5600)과 리포지토리 서비스(5222)와의 상호작용을 도시한다. 리포지토리 서비스(5222)는 메타데이터 모델에의 접속을 위한 서비스를 내부 툴(5604), 레거시 툴(5602), 및/또는 외부 툴(5600)에 제공할 수 있다. 각각의 서비스는 리포지토리 서비스(5224)에 의해서 유지된 리포지토리 스페이스에 메타데이터 또는 메타 모델을 유지할 수 있다. 리포지토리 서비스(5224)는 시맨틱 허브(5614)에의 모델 매핑(화살표로 지시됨)을 통하여 각종 툴이 다른 메타데이터에 접속하는 능력을 제공할 수 있다.

아키텍처(5200)에서, 툴(5604)은 자신의 작업 메타데이터를 위한 명확한 모델을 사용하고, 리포지토리 서비스(5222)에 의해서 제공된 리포지토리(5224)에 저장될 수 있다. 리포지토리(5224)는 툴 특정 모델, 메타데이터 모델, 및 SOA(5201)의 복수의 서비스에 의해서 공유될 수 있는 공통 모델을 저장할 수 있다. 툴(5604)은 SOA(5201)를 통하여 리포지토리(5224)에 접속할 수 있고, 디자인 솔루션(5304)에 데이터 및 메타데이터를 제공할 수 있다. 데이터 프로파일링, 데이터 정제, 디자인 솔루션(5304), 또는 다른 데이터 통합 관련 액션과 같은 활동을 위해 리포지토리(5224) 내에는 구별되는 기능 영역이 존재할 수 있다.

리포지토리 서비스(5222)는 레거시 툴(5602)과 상호작용할 수 있고, 레거지 모델 리포지토리(5612)를 유지할 수 있다. 레거시 모델은 메타데이터 공존, 메타데이터 이동, 메타데이터 동시성 버전(concurrent version), 또는 디자인 솔루션(5304)을 위한 다른 메타데이터 및 모델링 필요를 위해 사용될 수 있다. 레거시 모델 리포지토리(5612)는 레거시 모델 리포지토리(5612)로부터 리포지토리(5224)로의 매핑을 이용하여 리포지토리 서비스(5222)에 의해 유지될 수 있으며, 레거시 툴(5602)은 서비스로서 툴(5604)에 노출될 수 있다. 리포지토리(5224)로부터 레거시 툴(5612)로의 동일한 매핑의 사용은 툴을 서비스로서 레거시 툴(5602)에 노출할 수 있다. 레거시 모델 리포지토리(5612)가 리포지토리(5224) 및 툴(5604)에 노출되어, 레거시 모델 리포지토리(5612)로부터의 데이터 및 메타데이터는 동시성 메타데이터로서 유지되거나, 현존 리포지토리 메타데이터로 조정될 수 있다.

리포지토리 서비스(5222)는 외부 툴(5600)을 위한 모델 및 메타데이터를 임포트(import) 및 익스포트(export)하는 1차 서비스(5608)일 수 있다. 외부 메타데이터 및 모델은 리포지토리 서비스(5224)에 의해 유지될 수 있는 외부 뷰 모델(5610)을 생성하기 위해 임포트될 수 있다. 이러한 외부 뷰 모델은 디자인 솔루션(5304) 및 전개를 위해 SOA(5201)에 노출될 수 있다. 리포지토리 서비스(5222)에서, 모델은 다른 모델을 참조할 수 있고, 툴이 복수의 모델에 동시에 접속하게 허용할 수 있다. 리포지토리와 외부 리포지토리 사이의 모델 참조는 리포지토리(5224) 내의 동일한 메타데이터 또는 모델을 복수의 툴이 공유하게 허용할 수도 있다.

리포지토리 서비스(5222)는 외부 뷰 모델(5610), 레거시 모델(5612), 및 리포지토리 모델(5224)에의 접속을 외부 툴(5600), 레거시 툴(5602) 및 툴(5604)에 제공하기 위하여 시맨틱(semantic) 허브 모델을 사용할 수 있다. 시맨틱 허브 모델은 외부 뷰 모델(5610), 레거시 모델(5612), 및 리포지토리 모델(5224) 사이의 매핑을 유지하는 일관적인 모델일 수 있으며, 툴(5604)이 메타데이터를 공유하게 허용하는 부분적인 매핑만을 필요로 할 수 있다. 다른 시스템 컴포넌트 사이의 시맨틱 허브 모델(5614) 매핑 사용에 의해, 툴(5604)은 유저 디자인 솔루션(5304)을 위한 레거시 모델(5612) 및 외부 뷰 모델(5610)에의 접속을 가질 수 있다. 시맨틱 허브 모델(5614) 매핑은 SOA(5201) 서비스에 외부 뷰 모델(5610)의 라이브 메타데이터 분석을 제공할 수 있다. 툴(5604)은 레거시 모델에 접속할 수 있고, 리포지토리(5224)로의 모델 및 레거시 메타데이터의 이동 및 공존을 지원할 수 있다. 툴(5604)은 레거시 모델(5612)과 상호작용할 수 있고, 그것을 메타데이터 및 모델의 부가적인 버전으로서 지원할 수 있다. 레거시 모델(5612)은 리포지토리(5224) 모델로 이동될 수 있다. 시맨틱 허브 모델(5614)을 통하여, 외부 툴(5600) 및 레거시 툴(5602)은 SOA 커넥터(5218) 접속에 의해 SOA(5201) 서비스에 접속할 수 있다.

도 57은 전술한 리포지토리 서비스(5222)와 같은 리포지토리 서비스를 위한 아키텍처를 도시한다. 아키텍처는 GUI 클라이언트, 비(非)GUI 클라이언트, 및 서비스와 같은 인터페이스(5700)를 포함할 수 있다. 아키텍처는 XMI 스트림(5702), 애플리케이션 프로그래밍 인터페이스(5704), 임포트/익스포트 펑크션(5608), 정의 및 확장 펑크션(5710), 네비게이션 펑크션(5712), 질의 펑크션(5714), 내부 분배, 로킹(locking) 및 캐싱(cashing) 서비스(5708), 내부 지속 및 버전 관리 서비스(5718), 객체 관리 서비스(5720), 및 데이터베이스(5722)를 더 포함할 수 있다. 일반적으로, 아키텍처는 모델의 히스토리 및 지속성을 유지하는 데이터베이스 기능 성을 제공하면서, 여러 유저 및 유저 타입을 위해 데이터베이스(5722) 내의 모델에의 프로그램식 접속 또는 다른 접속을 제공한다. 리포지토리 서비스(5222)는 메타 모델(즉, 메타데이터의 모델)과 같은 디자인 모델뿐만 아니라, 잡, 서비스 또는 다른 펑크션 내의 실행을 위한 모델 인스턴스를 유지할 수 있다.

인터페이스(5700) 및 XML 스트림(5702)은 리포지토리 서비스(5222)와 외부 유저 사이의 임의의 적합한 포맷으로의 통신을 제공할 수 있다. 인터페이스(5700)는 프로그래밍 인터페이스, 메시지 지향 인터페이스, 및/또는 다른 인터페이스 또는 리포지토리 서비스(5222)로의 외부 접속을 위한 인터페이스를 제공할 수 있다. 예컨대, XML 메타데이터 교환(XMI) 스트림(5702)은 메타모델 및 인스턴스 파일 저장-복원-교환 포맷을 인코딩 및 전송하기 위한 표준의 메시지 지향 포맷을 제공할 수 있다. XML 스트림(5702)은 리포지토리 서비스(5222)의 임포트 및 익스포트 펑크션(5608)과 직접 통신할 수 있다.

애플리케이션 프로그래밍 인터페이스(API)(5704)는 예컨대, 속성값 및 객체 ID를 리포지토리 서비스(5222)에 접속하는 클라이언트로부터 수신할 수 있다. API는 리포지토리(5222)의 구조 또는 그 리포지토리(5222)에 접속하는 인터페이스(5700)의 특징 및 기능성, 또는 그 양자에 관한 정보를 독립적으로 유지하는 반사형 인터페이스를 포함할 수 있다. 유저는 예컨대, 리포지토리 서비스(5222)의 구조에 관한 적은 정보의 요구 및/또는 리포지토리 서비스에 접속하는 유저에 관한 인터페이스(5700)로부터의 덜 명시적인 정보의 요구를 할 수 있는 프로그래밍 인터페이스(5704)의 반사성 특징을 이용하거나, 직접 프로그램식 인터페이스(예컨대, 자바 클래스)를 사용하여 데이터베이스(5722) 내의 메타데이터를 접속할 수 있다. 예컨대, 애플리케이션 프로그래밍 인터페이스(5704)는 리포지토리 서비스(5710)에 접속하기 위해 알려진 인터페이스(5700)에 의해 사용된 모델을 검출 및/또는 기술하는 정의 및 확장 펑크션(5710)을 포함할 수 있다. 또한, 애플리케이션 프로그래밍 인터페이스(5704)는 알려진 GUI(또는 비GUI) 클라이언트 인터페이스(5700)에 의해 제공된 네비게이션의 특징 및 구조의 지각을 갖는 네비게이션 펑크션(5712)을 포함할 수 있다. 그러한 펑크션(5704, 5710, 5712)을 사용함으로써, 리포지토리 서비스(5222)는 알려진 구성을 갖는 각종 인터페이스(5700)로부터의 요구를 더 잘 해석하고 응답할 수 있다. 다른 방법으로, 임의의 모델-지각 클라이언트 또는 서비스가 모델 정의로부터 컴파일된 임의의 모델-특정 클래스에 직접 접속할 수 있다.

질의 펑크션(5714)은 GUI, 비-GUI, 및 서비스와 같은 인터페이스(5700)로부터의 적절히 포맷화된 요구를 위하여 리포지토리 서비스(5222)를 직접 노출할 수 있다. 예컨대, 질의 펑크션(5714)은 질의를 직접 수신하거나, 클라이언트 및 서비스(5700)로부터의 표현을 갱신할 수 있고, 반응적인 객체 ID와 직접 응답할 수 있다. 검색과 같은 다른 공통으로 사용된 데이터 검색 및 갱신 펑크션이 질의 펑크션(5714)과 함께 또는 그것에 부가적으로 포함될 수 있다. 질의 펑크션(5714)은 데이터베이스(5722)로서 사용되는 임의의 상업적으로 이용가능한 관련 데이터베이스 또는 리포지토리 서비스(5222) 내에 데이터를 저장하는데 유용한 임의의 다른 표준 또는 사설 데이터베이스에 의해서 정의될 수 있다.

객체 관리 서비스(5720)는 예컨대, 데이터베이스(5722)로의 접속을 제어하기 위한 객체 분배, 로킹, 및 캐싱 서비스(5708)를 사용하여 또는 데이터베이스(5722) 내의 객체의 버전 관리 및 다른 관련 특징을 관리하기 위한 객체 지속성 및 버전 서비스(5718)를 사용하여, 데이터베이스(5722) 내의 데이터를 관리할 수 있다. 예컨대, 지속성 및 버전 관리 서비스(5718)는 복수의 후속 브랜치 및 자동화되거나 반자동화된 합병에 의해, 메타 모델 및 모델 인스턴스 양쪽의 버전 관리를 지원할 수 있다. 또한, 지속성 및 버전 관리 서비스(5718)는 다른 시스템 개정 또는 갱신을 유지하는 인스턴스로 고객 또는 유저 정의 모델을 지원할 수 있다. 다른 예로서, 지속성 및 버전 관리 서비스(5718)는 복수의 동시성 모델 버전 사용을 지원할 수 있다. 동시에, 리포지토리 서비스(5222)는 예컨대, 마이크로소프트 SCCI 스펙에 따라 인터페이스를 외부 소스 제어 및 버전 관리 시스템에 제공할 수 있다. 크로스 모델 참조는 지속적일 수 있다. 더욱 일반적으로, 메타데이터 서비스는 리포지토리 아키텍처(전술한 데이터베이스 및 임의의 코어 서비스) 내의 임의의 계층에 상주할 수 있고, 예컨대, 임포트된 아이템과 같은 메타데이터의 조정, 영향 분석, 변화 전파 및 데이터 리니지(data lineage)와 같은 분석, 리포팅 및 문서화, 엔터프라이즈 범위 및 개인 카탈로그와 카테고리화 기술을 위한 카탈로깅(cataloging), 협동 및 워크플로우 지원, 및 스크립 능력과 같은 기능성을 제공할 수 있다.

데이터베이스(5722)는 예컨대, 전술한 임의의 데이터 소스(102)일 수 있다. 오퍼레이션(예컨대, 런 타임) 리포지토리 및 디자인 리포지토리(또한, 공통 리포지토리 또는 코어 리포지토리라고 함)를 포함할 수 있는 논리 리포지토리는, 개인, 팀/프로젝트, 부(division) 또는 엔터프라이즈 리포지토리 뿐만 아니라, 중앙화되거나 분산화된 리포지토리를 포함하여 복수의 및/또는 분포된 리포지토리로서 유연하게 구성될 수 있다는 것을 이해할 수 있을 것이다. 또한, 리포지토리는 상이한 리포지토리 인스턴스 사이에 자동화된 동기성을 제공할 수 있다. 리포지토리 서비스(5222)는 외부 클라이언트 및 서비스(5700)에 투명한 방식으로 리포지토리의 구성을 관리하는 펑크션 또는 서비스를 포함할 수 있다.

도 58을 참조하면, 컴포넌트 및 구성 모델을 도시하는 하이 레벨 UML 다이어그램을 도시한다. 컴포넌트는 각종 타입의 변환 및 통합과 같은 외부 리소스를 포함할 수 있는 디자인 솔루션(5304)의 미립 요소일 수 있다. 컴포넌트는 서비스로서 노출되고 SOA(5201)에 의해서 조정될 수 있는 구성으로 서로 링크될 수 있다. 그리하여, 데이터 통합 프로세스 내의 서비스의 컴포넌트 기반 디자인, 또는 기술이 개시된다. 컴포넌트의 요소를 이하에 개시한다.

컴포넌트는 적어도 하나가 스테이지 에디터와 같은 디자인 타임 객체인 디자인타임(5814)과 관련되는 정의인 컴포넌트데프(componentdef)(5810)를 가질 수 있다. 복수의 디자인타임(5814) 오브젝트는 디자인 요건에 따라 컴포넌트 데프(5810)와 관련될 수 있다. 컴포넌트데프(5810)는 그 컴포넌트의 이름 및 특성을 특정할 수 있는 복수의 특성 정의 객체인 특성데프(propertydef)(5802)를 포함할 수 있다.

유연한 솔루션 개발의 지원시, 아키텍처(5200)는 요약 및 구체적 컴포넌트를 지원한다. 요약 컴포넌트는 유연한 점진적 개발을 지원할 수 있고, 부분적인 스펙 만으로 객체를 표현할 수 있다. 요약컴포넌트데프(abstractcomponentdef)(5820)는 데이터베이스 또는 프로세스와 같은 특정 타입의 컴포넌트를 표현할 수 있고, 디자인 솔루션(5304)에서 나중에 구체적으로 될 수 있다. 구체적인 컴포넌트는 완전히 정의된 객체이고 구체적컴포넌트데프(concretecomponentdef)(5818)에 의해서 정의된다.

구체적인 컴포넌트는 생성된 코드, 높은 처리율, 디버그(debug), 체크포인트, 또는 프로세스 상태 지속성과 같은 각 개발 엔진에 대하여 런 타임(5814) 실행 객체를 가질 수 있다. 런 타임 실행 객체는 디자인 솔루션(5304)의 전개에서의 초기화, 오픈, 실행, 읽기, 출력, 엔드 오브 웨이브, 리셋 및 중단과 같은 컴포넌트 인스턴스 라이프 사이클 오퍼레이션을 지원할 수 있다. 커넥터데프(connectordef)(5828) 객체는 외부 리소스에 접속될 수 있는 구체적컴포넌트데프(5818)를 정의할 수 있고, 서비스 또는 메타데이터와 같은 외부 리소스에의 노출을 제공할 수 있다.

미립 컴포넌트는 더욱 복잡한 펑크션을 위한 구성을 형성하기 위해서 상호결합될 수 있다. 일반적으로, 특정 런 타임 환경 내에서 식별되는 바와 같이, 미립 컴포넌트는 고성능 인터페이스를 위해 서로 구성되거나 사용될 수 있다. 그리하여, 컴포넌트 기반 디자인은 여기에 기술한 서비스 지향 아키텍처와 독립적으로 유용해질 수 있다. 하지만, 구성은 다른 SOA(5201) 조정 서비스에 의해 재사용될 수 있으며 순환적일수도 있는 구성데프(compositiondef)(5822)에 의해서 정의될 수 있으며, 다른 SOA(5201) 클라이언트 및 서비스에 서비스로서 노출될 수 있다. 구성 데프(5822)의 최외 레벨은 특정화된 구성데프(5822)일 수 있는 프로세스데프(processdef)(5830)일 수 있다. 구성인스턴스(compositioninstance)(5812)는 각각의 새롭게 정의된 구성데프(5822)에 의해 생성될 수 있고, 구성인스턴스(5824)는 인스턴스용 특성 값을 포함할 수 있다.

구성은 모든 컴포넌트가 구체적일 때에만 실행될 수 있다. 디자인 프로세스 동안에, 요약 컴포넌트로서 시작하는 프로세스 또는 데이터베이스와 같은 임의의 컴포넌트는 구체적인 컴포넌트가 되도록 정의되어야 한다. 동시에, 요약 컴포넌트를 위한 디자인은 구체적인 컴포넌트의 최종 디자인 또는 다른 외부 디자인 인자에 응답하여 변경되거나 재배열될 수 있다. 그리하여, 순차적인 디자인이 실현될 수 있고, 디자인은 단일 디자인 또는 모델 내에서의 요약화의 각종 레벨에서 변형될 수 있다. 공통 구성 및 통합 프로세스 모델은 디자인 솔루션(5304)을 위해 GUI(5202)를 통하여 노출될 수 있다. 구성 자체는 컴포넌트로 고려될 수 있고, 구성은 유저로부터 현저한 프로그래밍 스킬을 요구하지 않고, 더욱 복잡한 구성 서비스를 생성하기 위해 서로 링크될 수 있다. 컴포넌트 및 구성은 GUI(5202) 내에서 생성될 수 있고, 덜 능숙한 유저에 의해 컴포넌트 및 구성 디자인을 위해 위저드에 접속할 수 있다. 아키텍처(5200) 구성 모델은 그것이 특성, 입력 및 출력, 작업의 유닛, 로컬 변수, 스코프(scope), 제어 제약, 이벤트, 무상태형 및 상태형 기반 세팅, 예외, 및 순환적 구성과 같은 SOA(5201)에 의해서 조정되게 허용하는 속성을 포함할 수 있다.

도 59를 참조하면, 구성 모델의 엔터프라이즈 통합 언어(EIL) 예가 XML 표 현(5914)으로 도시된다. 도시된 통합 프로세스는 일련의 작업 아이템 메시지를 클라이언트 또는 다른 서비스로부터 SOA(5201)를 통하여 수신할 수 있다. 본 예에서, 각각의 작업 메시지는 데이터베이스 룩업(5904), 변환(5908), 관련 열로의 서브 리코드의 프로모션(5910), 데이터베이스(5912)로의 삽입을 요구할 수 있다. 최외 원자(5900) 스코프는 실행을 위한 시퀀스를 특정할 수 있다. 본 예에서, 룩업(5904), 변환(5908), 관련 열(5910)로의 서브 리코드의 프로모션, 및 데이터베이스(5912)로의 삽입은 순차적으로 행해져야 한다. 원자 스코프(5900)를 위해서, 독립(5912) 스코프는 데이터베이스(5912)로의 삽입에 순차적으로 실행될 수 있는 완전한 시퀀스로서 노출될 수 있다.

내부 독립(5902) 스코프는 폐쇄 시퀀스, 룩업(5904), 변환(5908), 관련 열(5910)로의 서브 리코드의 프로모션은 파이프라인 형식으로 서로에 독립적일 수 있다는 것을 지시할 수 있다. 이는 파이프라인 또는 동시적인 처리를 사용한 실시를 촉진할 수 있다.

이러한 방식으로, EIL 모델은 구성의 상이한 시퀀스가 어떻게 상호작용하는지 정의할 수 있고, 모델은 동일한 시퀀스를 직렬로 및 다르게는 병렬로 실행하게 허용할 수 있다.

XML 표현(5914)은 EIL 모델의 스크립 해석을 도시할 수 있다. 당업자라면 EIL 모델에의 SML 스크립의 관련을 이해할 수 있다.

도 60을 참조하면, 클라이언트, 서비스 및 컴포넌트 관계의 UML 다이어그램이, 클라이언트와 서비스 관계를 기술한 도 54의 UML, 및 컴포넌트와 구성 관계를 기술한 도 58의 UML에서 기술된 바와 같이 도시된다. 그러한 두 모델의 전체 작업에 대한 상세한 설명을 위해서는 전술한 도 54 및 도 58의 기술을 참조한다.

클라이언트(5412)는 데이터 통합 개발을 위한 API 및 유저 상호작용에 SOA 서비스(5414)를 제공할 수 있다. 개별적인 컴포넌트는 SOA 서비스(5414)와 클라이언트(5412)와 인터페이스 하는 디자인 타임 및 런 타임 인터페이스를 제공할 수 있다. 디자인 타임(5808) 컴포넌트는 클라이언트(5412)와 인터페이스 하고, SOA 서비스(5414)에 의해서 디자인 솔루션(5304)을 위해 이용가능한 컴포넌트 능력으로 조정될 수 있다. 디자인 타임(5808) 컴포넌트 및 SOA 서비스(5414)와의 이러한 조정은 프로세스 디자이너(5402) 내의 유저에게 이용가능한 컨텍스트를 제공할 수 있고, 컨텍스트 감지형 GUI를 지원할 수 있다.

런 타임(5814) 컴포넌트는 디자인 솔루션(5304)의 전개를 이용가능한 서비스로 조정하기 위해서 SOA 서비스(5414)와 인터페이스 할 수 있다. SOA 서비스(5414)는 디자인 솔루션(5304)의 디자인 요건과 하드웨어 환경의 런 타임 요건에 SOA 서비스(5414)를 노출하는 디자인 타임 컴포넌트(5808)와 런 타임 컴포넌트(5814) 양쪽과의 커넥션을 가질 수 있다. SOA 서비스(5414)는 디자인 솔루션(5304)을 위한 디자인 타임 컴포넌트(5808) 및 런 타임 컴포넌트(5814)에 의해 전개를 조정할 수 있다. 외부 리소스와의 통신에 책임이 있는 컴포넌트 서비스(5420)는 통신 서비스를 SOA(5414)에 노출하기 위해 컴포넌트 인스턴스(5812)를 사용할 수 있어서, 디자인 솔루션(5304)의 디자인 및 전개를 위하여 외부 리소스로의 SOA 서비스(5414) 노출을 제공한다. SOA 서비스(5414)로의 외부 리소스의 노출 은 SOA(5201) 클라이언트 및 서비스를 외부 리소스 및 서비스에 노출할 수 있다.

도 61을 참조하면, 제1 컴포넌트(6100)로부터 제2 컴포넌트(6102)로 이동되고 있는 데이터의 개략적인 표현이 도시된다. 아키텍처(5200) 런 타임 데이터 표현은 복수의 서비스 및 커넥션이 데이터와 통상적인 방식으로 작업하게 허용하기 위하여 통상의 데이터 표현을 사용할 수 있다. 아키텍처(5200) 리포지토리 서비스(5222)는 XML, EDI, COBOL, 2진 구조, 네이티브 언어 포맷, 네이티브 기기 포맷 및 다른 산업 데이터 포맷과 같은 복수의 데이터 구조와 인터페이스 할 수 있다. 복수의 데이터 구조를 효과적으로 취급하기 위해서, 아키텍처(5200)는 공통의 내부 데이터 구조를 사용할 수 있다.

리포지토리 서비스(5222)는 불필요한 변환을 피하기 위해서 최소의 데이터 변환으로 데이터를 메모리(6114)에 이동시킬 수 있고, 그리하여 데이터 전송 효율성을 증가시킬 수 있다. 데이터는 공유 가능한 메모리(6114)로 이동될 수 있으며, 그곳에서 단지 필요한 데이터만 데이터 통합 잡을 수행하기 위한 컴포넌트를 위해 변환되고 분산/수집된다. BLOB 및 CLOB와 같은 큰 비(非)해석 데이터 아이템은 소스로부터 타깃으로 참조로 이동될 수 있다. 단지 참조만을 제공함으로써, 큰 비해석 데이터는 메모리에 복사될 필요가 없을 수 있고, 데이터가 요구될 때 그 데이터의 단지 필요한 부분만이 변환되어 메모리(6114)로 분산/수집된다.

데이터를 제1 컴포넌트(6100)로부터 제2제3넌트(6102)로 이동하는 일 예로 컴포넌트 접속 분산 수집 리스트(6104)를 도시한다. 분산 수집 리스트(6104)는 소스 또는 타깃 데이터 표현 내에서 데이터의 더 작은 부분으로의 포인터(pointer)를 갖는 공유가능한 메모리(6114) 내에 있을 수 있다. 데이터 표현은 XML 텍스트(6108), 데이터베이스 인출(fetch) 버퍼(6110), COBOL 리코드(6112), 또는 다른 데이터 포맷일 수 있다. 분산 수집 리스트(6104)는 데이터 표현이 공유가능한 메모리(6114)로 일단 로딩되게 허용할 수 있고 데이터 표현으로의 포인터는 필요한 데이터로 지시하기 위해 조작된다. 실제 데이터를 이동시키는 대신에 분산 수집 리스트 내의 포인터를 조작함으로써, 가장 반복적인 데이터 복사 및 메모리 재할당이 제거될 수 있다. 컴포넌트에 대한 포인터가 일단 확립되면, 필요한 데이터에 대한 데이터 변환은 자동적으로 발생하고, 그 데이터 변환은 대부분의 데이터를 변환 없이 공유된 메모리(6114)에 유지할 수 있다. 데이터 취급은 포인터를 갖는 변환된 데이터 값을 다른 컴포넌트에 의한 재사용을 위해 분산 수집(6104) 리스트에 캐시함으로써 더 향상될 수 있다.

이러한 기술을 사용함으로써, 데이터는 구성의 컴포넌트 사이에서 고성능 방식으로 이동될 수 있다.

도 62는 아키텍처(5200)를 위한 공통 엔진을 도시한다. 공통 엔진 프레임워크는 프로그래머(6204), 통합 디자이너(6202), 비지니스 애널리스트(6200)와 같은 유저를 포함할 수 있고, 유저는 플로우 디자이너(6210), 위저드(6212), 모델 또는 이전의 프로젝트에 저장된 것과 같은 예(6214), 템플릿(6216) 등과 인터페이스할 수 있다. 런 타임 컴파일화 및 최적화 계층(6230)은 고 처리율 엔진(6240), 고 동시성 엔진(6242), 저장된 프로시저(6244), 컴퓨터 프로그램 코드(6246) 등과 같은 엔진의 이용을 통한 자동 또는 수동 제어의 변화도를 제공할 수 있으며, 그러한 엔 진은 공통 컴포넌트 및 접속성(6250)을 통하여 외부 리소스와 통신할 수 있다.

여러 데이터 통합 서비스 및 펑크션은 전환, 유도, 응집, 라우팅, 메타데이터 매핑, 품질 단정, 및 다른 데이터 변환 등과 같은 변환을 필요로 할 것이다. 아키텍처(5200)는 GUI(5202) 및 변환 논리를 구속하는 단일 변환 스펙을 제공할 수 있다. 변환 프레임워크는 관계적, 계층적, XML, 임의적, 및 다른 산업 표준의 포맷과 같은 복수의 데이터 포맷을 위한 변환의 통일된 방법을 제공할 수 있다. 전술한 바와 같이, 변환과 같은 처리는 유리하게는 데이터의 서브세트에 제한되고, 데이터의 현저한 부분은 임의의 변환 없이 이동될 수 있다.

도 52에 도시된 바와 같이, 아키텍처(5200)는 각종의 조직 위치로부터의 유저가 자신의 능력에 적합한 환경에서 작업하게 허용하는 스킬 기반의 단일 GUI(5202)를 제공할 수 있다. 변환 프레임워크는 그러한 능력을 레버리지(leverage) 하고, 복수의 유저에게 데이터 변환에 작업하는 GUI의 일부로서 인터페이스를 제공할 수 있다. 변환 프레임워크는 비지니스 애널리스트(6200), 통합 디자이너(6202), 프로그래머(6204) 및 다른 유저에게 자신의 스킬 세트에 조정될 수 있는 인터페이스를 통하여 접속을 제공할 수 있다.

플로우 디자이너(6210), 위저드(6212), 예(6214) 및 템플릿(6216)은 임의의 메타데이터, 메타데이터 모델, 서비스, 컴포넌트, 구성 및 다른 전술한 다른 프로세스 디자인 요소를 포함할 수 있는 공통 중간 통합 프로세스 스펙(6220)을 디자인하고 수정하기 위하여 각종 유저(6200, 6204, 6206)에 의해 채용될 수 있는, 통합 프로세스를 디자인하기 위한 가능한 유저 인터페이스 툴의 비총망라 컬렉션(non- exhaustive collection)을 나타낸다. 또한, 이들의 각각 또는 부가적으로 가능한 디자인 유저 인터페이스는 유저 스킬 레벨, 롤, 기술 플랫폼 등과 일치적인 디자인 상세에 상이한 레벨의 유저가 접속하게 허용할 수 있다.

예컨대, 비지니스 애널리스트(6200)는 조건부 브랜칭, 이벤트 검출, 필터링 규칙과 같은 고위 레벨 논리 디자인에 더욱 관심을 가질 수 있다. 비지니스 애널리스트(6200)는 예컨대, 비지니스 애널리스트(6200) 프로그래밍 스킬과 조화적인 단순한 디자인 플로우 및 변환 표현 바인딩 능력을 허용할 수 있는 더욱 간단하거나 통합된 기능성을 사용하여 통합 프로세스 스펙(6220)을 개발하기 위해 위저드(6212), 예(6214) 또는 템플릿을 사용하려 할 수 있다.

통합 디자이너(6202)는 품질 단정, 데이터 변환, 중요 표현, 라우팅, 필드 레벨 변환, 및 데이터 정제를 생성하기 위해 더욱 복잡한 프로그래밍 능력을 가질 수 있다. 통합 디자이너는 위저드(6212), 예(6214) 및 템플릿(6216)뿐만 아니라 다른 하이 또는 로우 레벨 GUI 인터페이스를 채용하는 것에 부가하여, 프로세스의 일부를 명시적으로 모델링하기 위해서 플로우 디자이너(6210)를 사용할 수 있으며, 이는 직접적이고 명시적인 디자인을 위한 표현 언어로 작업하도록 더욱 깊이 있는 능력을 허용할 수 있다. GUI의 그러한 레벨은 통합 디자이너(6202)에게는 여전히 스킬 레벨 구속적일 수 있고, 지원을 필요로 다른 태스크나 표현 구축을 위해 위저드(6212)에의 접속을 가질 수 있다.

다른 인터페이스(6212, 6214, 6216)가 디자인 프로세스를 통하여 교환가능하게 사용될 수 있을지라도, 프로그래머(6204)는 커스텀 변환 펑크션 및 커스텀 컴포 넌트에 대하여 최대의 제어를 허용하게 하기 위해 바람직하게는 플로우 디자이너(6210) GUI 또는 명령 라인 인터페이스를 사용할 수 있다. 프로그래머(6204)는 데이터 세트 레벨 논리 및 리코드 레벨의 능력을 포함하여 통합 프로세스 디자인을 위한 상세의 최상 레벨에의 접속을 가질 수 있다. 프로그래머는 SOA(5201)를 통하여 접속된 유저 정의 서비스를 생성 및 사용하고, 컴파일화 및 최적화 처리 계층에 상세한 어드바이스(advice)를 제공하기 위해서, 공통 컴포넌트 및 접속성(6250)의 요소를 기록 또는 커스터마이즈하는 능력을 포함하여(비한정적임) 미립 능력에의 접속이 허용될 수 있다.

각종 인터페이스(6210-6216)를 사용함으로써, 비지니스 애널리스트(6200), 통합 디자이너(6202) 및 프로그래머(6204)와 같은 유저는, 통합 프로세스를 실행하는데 사용되는 이벤트적 엔진, 컴포넌트 및 접속성에 또한 독립적인 공통 중간 통합 프로세스 스펙(6220)을 사용하는 통합 프로세스를 디자인할 수 있다. 이 중간 통합 프로세스 스펙(6220)은 EIL(5900) 또는 임의의 대등한 표현과 같은 공통 중간 통합 프로세스 스펙 언어로 표현될 수 있다.

컴파일 및 최적화 프로세스 계층(6230)은 공통 중간 통합 프로세스 스펙(6230)을, 고 처리율 엔진(6240), 고 동시성 엔진(6242), 고 동시성 엔진(6242), 1이상의 데이터베이스 저장 프로시저(6244), 및/또는 생성된 컴퓨터 프로그램 코드(6246)의 하나 이상의 세그먼트를 포함하는(비한정적임) 하나 이상의 실행 엔진 환경에 특정한 실행 스펙으로 변환할 수 있으며, 생성된 컴퓨터 프로그램 코드(6246)는 C, C++, C#, COBOL, 및 자바빈과 엔터프라이즈 자바빈을 포함하는 자 바, 또는 여기에 기술한 시스템에 적합한 범용 연산 알고리즘을 변환, 해석 및/또는 실행할 수 있는 다른 실행 환경을 포함하는(비한정적임) 임의의 통상적인 프로그래밍 언어이다. 컴파일 및 최적화 프로세스 계층(6230)은 컴퓨터 시스템 환경 구성에 관한 정보뿐만 아니라, 데이터 소스(102) 및 데이터 타깃(102)에 관하여 메타데이터 리포지토리(5214)에 저장된 메타데이터의 지식을 사용하여, 통합 프로세스 스펙(6230)을 각종 엔진 및 실행 환경을 위한 지령의 적절하고 효율적인 조합으로 어떻게 변환할지를 결정할 수 있다. 컴파일 및 최적화 계층(6230)은 통합 프로세스 스펙(6220)을 어떻게 가장 잘 컴파일하고 최적화하기 위한 인폼드 결정(informed decision)을 하기 위하여 데이터 프로파일링 정보와 같은 부가적인 메타데이터를 유도하기 위해 SOA(5201)를 통하여 이용가능한 서비스(5414)의 임의의 플레서라(plethora)를 또한 사용할 수 있다.

다른 통합 프로세스 실행 엔진 및 환경(6240, 6242, 6244, 6246등)은 컴포넌트 실행(5814) 및 커넥터(6310)를 포함하여, 사전정의된 및/또는 유저 정의된 공통 컴포넌트 및 외부 데이터 소스 및 타깃 접속성(6250)을 사용할 수 있다.

비지니스 애널리스트(6200), 통합 디자이너(6202), 및 프로그래머(6204)와 같은 클라이언트에 의해서 생성될 수 있는 커스텀 디자인된 변환 컴포넌트 및 접속성 요소는 컴파일화 및 최적화 계층(6230)에 의해서 실행가능한 통합 프로세스를 생성하는데 사용될 수 있는 리포지토리 카탈로그로 별도의 공유가능한 요소로서 리포지토리(5224) 내에 저장될 수 있다.

도 63을 참조하면, 아키텍처(5200) 서비스(6300), 컴포넌트(6302) 및 엔 진(6304)에 커넥터 컴포넌트(6310)를 통한 외부 리소스로의 접속을 허용하는 접속성 아키텍처가 도시된다. 이러한 서비스는 전술한 도면에서 이전에 정의하였다.

커넥터 컴포넌트(6310)의 역할은 외부 리소스의 인터페이스를 인캡슐화하고 컴포넌트(6308) 및 서비스에 사용하기 위하여 그러한 외부 리소스를 표준화하는 것이다. 커넥터의 역할은 변환이 적은 정보를, 변환 컴포넌트와 같이 변환이 더 효율적으로 완료되는 다른 컴포넌트(6308)에 보내는 것일 수 있다. 전술한 바와 같이, 변환은 전송된 외부 데이터 내의 한정된 양의 데이터에 대해서만 일어날 수 있다. 커넥터(6310)에 의해, 데이터를 단지 최소로 변환하는 것은 커넥터(6310)가 데이터를 컴포넌트 및 서비스로 효율적으로 이동시키게 허용한다. 커넥터는 컴포넌트 서비스(6302) 또는 런 타임 인터페이스를 통하여 전개 엔진(6304)에 디자인 타임 인터페이스를 제공하는 특수화된 컴포넌트일 수 있다.

커넥터(6310)의 일부로서, 어댑터(6312)는 특정 외부 리소스에 컴포넌트 인터페이스를 제공하는 컴포넌트의 서브 클래스일 수 있다. 커넥터(6310)에서, 단일 외부 리소스의 라이프 사이클을 관리할 수 있는 로우 레벨 컴포넌트로서 복수의 커넥션(6314)이 존재할 수 있다. 커넥션(6314)은 외부 리소스를 판독, 기록, 전송, 수신, 질의, 또는 갱신할 수 있는 리소스 접속 및 관련 이벤트 리스닝을 가질 수 있다.

커넥션 관리 인터페이스(6312)는 커넥션(6314)을 지지하여 풀링 기능성을 제공할 수 있다. 풀링은 고 동시성 실행 환경을 위해 우선적으로 사용될 수 있고, 동시성 데이터의 매끄러운 이동을 허용할 수 있다. 고 처리율 실행 환경을 위해 서, 동일한 커넥션 관리 인터페이스(6312)가 사용될 수 있지만, 일관적인 커넥션을 제공하기 위해 높은 듀티 사이클 재사용을 허용할 수 있는 일관적인 커넥션을 유지할 수 있다. 커넥터(6310)는 인스톨, 디자인 타임 인터페이스, 메타데이터 인터페이스, 컴파일화, 유효화, 디버그, 감시, 예시, 상태 관리, 풀링, 캐싱, 트랜잭션, 예외 취급, 데이터 접속, 이벤트 검출, 지속, 리스, BOM 제조, 데이터 샘플링, 및 샘플 데이터 생성과 같은 복수의 외부 리소스 라이프사이클 펑크션을 제공할 수 있다. 커넥터(6310)는 모델에 의해서 기술될 수 있고, 리포지토리(5224) 내에 저장될 수 있으며, 외부 리소스에 대한 접속을 위해 시맨틱 허브 모델(5614)에 접속할 수 있다. 커넥터(6310)는 ODBC, JDBC, JCA, EJB, 및 웹 인터페이스와 같은 외부 리소스로의 인터페이스를 랩(wrap)할 수 있다.

본 발명은 특정 바람직한 실시예와 연계하여 기술하였지만, 다른 실시예가 당업자에게 인식될 수 있고 본 개시의 범주 내에 있도록 의도된다는 것을 이해해야 한다.

Claims (10)

1. 데이터 통합 시스템으로서,

   복수의 데이터 통합 태스크(task)를 수행하기 위한 유저 인터페이스로서, 상기 유저 인터페이스는 프로젝트를 위한 워크플로우의 복수의 단계에 대응하는 복수의 메뉴를 포함하는 것인, 유저 페이스;

   서비스의 레지스트리와, 상기 유저 인터페이스의 상기 데이터 통합 태스크의 각각과 관련된 하나 이상의 서비스를 포함하는 서비스 지향 아키텍처;

   상기 유저 인터페이스 및 상기 서비스 지향 아키텍처의 서비스의 하나 이상의 서비스와 관련된 리포지토리(repository)로서, 상기 리포지토리는 상기 프로젝트를 위한 워크플로우의 하나보다 많은 단계에 대한 공통 메타데이터 모델을 저장하는 것인, 리포지토리;

   상기 프로젝트를 실행하기 위한 하나 이상의 런 타임 엔진; 및

   상기 하나 이상의 런 타임 엔진을 하나 이상의 외부 리소스에 접속하기 위한 하나 이상의 커넥터로서, 상기 커넥터는 데이터 처리율을 위한 모듈식 컴포넌트 및 구성을 사용하는 것인, 커넥터

   를 포함하는 데이터 통합 시스템.
2. 데이터 통합 프로세스를 관리하는 방법으로서,

   복수의 데이터 통합 태스크를 수행하기 위한 유저 인터페이스를 제공하는 단 계로서, 상기 유저 인터페이스는 프로젝트를 위한 워크플로우의 복수의 단계에 대응하는 복수의 메뉴를 포함하는 것인, 단계;

   서비스의 레지스트리를 포함하는 서비스 지향 아키텍처를 제공하는 단계;

   하나 이상의 서비스를 상기 유저 인터페이스의 상기 데이터 통합 태스크의 각각과 관련짓는 단계;

   리포지토리를 상기 유저 인터페이스 및 상기 서비스 지향 아키텍처의 서비스의 하나 이상의 서비스와 관련짓는 단계;

   상기 프로젝트를 위한 상기 워크플로우의 하나보다 많은 단계에 대한 공통 메타데이터 모델을 상기 리포지토리에 저장하는 단계;

   상기 하나 이상의 런 타임 엔진을 사용하여 상기 프로젝트를 실행하는 단계로서, 상기 런 타임 엔진은 상기 프로젝트의 데이터 처리를 위하여 모듈식 컴포넌트 및 구성을 사용하는 것인, 단계; 및

   상기 하나 이상의 런 타임 엔진을 하나 이상의 외부 리소스에 접속하는 단계

   를 포함하는 데이터 통합 프로세스를 관리하는 방법.
3. 컴퓨터 판독가능한 프로그램 코드를 포함하는 컴퓨터 이용 가능한 매체를 포함하는 컴퓨터 프로그램 제품으로서,

   상기 컴퓨터 판독가능한 프로그램 코드는, 하나 이상의 컴퓨터 상에서 실행될 때 상기 하나 이상의 컴퓨터로 하여금 이하의 단계, 즉,

   복수의 데이터 통합 태스크를 수행하기 위한 유저 인터페이스를 제공하는 단 계로서, 상기 유저 인터페이스는 프로젝트를 위한 워크플로우의 복수의 단계에 대응하는 복수의 메뉴를 포함하는 것인, 단계;

   서비스의 레지스트리를 포함하는 서비스 지향 아키텍처를 제공하는 단계;

   하나 이상의 서비스를 상기 유저 인터페이스의 상기 데이터 통합 태스크의 각각과 관련짓는 단계;

   리포지토리를 상기 유저 인터페이스 및 상기 서비스 지향 아키텍처의 서비스의 하나 이상의 서비스와 관련짓는 단계;

   상기 프로젝트를 위한 상기 워크플로우의 하나보다 많은 단계에 대한 공통 메타데이터 모델을 상기 리포지토리에 저장하는 단계;

   상기 하나 이상의 런 타임 엔진을 사용하여 상기 프로젝트를 실행하는 단계로서, 상기 런 타임 엔진은 상기 프로젝트의 데이터 처리를 위하여 모듈식 컴포넌트 및 구성을 사용하는 것인, 단계; 및

   상기 하나 이상의 런 타임 엔진을 하나 이상의 외부 리소스에 접속하는 단계

   를 실행하도록 하는 것인 컴퓨터 프로그램 제품.
4. 데이터 통합 시스템 내의 서비스를 제공하기 위한 서비스 지향 아키텍처로서,

   서비스를 동적으로 위치 및 예시하기 위한 서비스 디렉토리로서, 상기 서비스는 툴(tool), 외부 리소스 커넥터를 서비스로서 노출하는 컴포넌트 서비스, 및 리포지토리에 저장된 메타데이터를 접속하기 위한 하나 이상의 리포지토리 서비스 로 구성되는 복수의 이산적인 재사용가능하고 공유가능한 서비스를 포함하는 것인, 서비스 디렉토리

   를 포함하는, 데이터 통합 시스템 내의 서비스를 제공하기 위한 서비스 지향 아키텍처.
5. 제 4 항에 있어서,

   상기 하나 이상의 서비스는 내부 서비스인 것인 서비스 지향 아키텍처.
6. 제 4 항에 있어서,

   상기 하나 이상의 서비스는 외부 서비스인 것인 서비스 지향 아키텍처.
7. 제 4 항에 있어서,

   상기 서비스는 상이한 기술을 사용하는 것인 서비스 지향 아키텍처.
8. 데이터 통합 시스템 내의 서비스 지향 서비스를 제공하는 방법으로서,

   복수의 서비스를 서비스 디렉토리에 등록하는 단계로서, 상기 서비스는 툴(tool), 외부 리소스 커넥터를 서비스로서 노출하는 컴포넌트 서비스, 및 리포지토리에 저장된 메타데이터를 접속하기 위한 하나 이상의 리포지토리 서비스로 구성되는 복수의 이산적인 재사용가능하고 공유가능한 서비스를 포함하는 것인, 단계;

   상기 복수의 서비스 중의 하나를 레지스트리 내에 동적으로 위치시키는 단 계;

   상기 위치된 복수의 서비스 중의 하나를 예시하는 단계; 및

   상기 위치된 복수의 서비스 중의 하나를 사용하여, 데이터 통합 프로세스의 유저 디자인에 별도의 유저 인터페이스를 제공하는 단계

   를 포함하는, 데이터 통합 시스템 내의 서비스 지향 서비스를 제공하는 방법.
9. 데이터 통합 시스템을 외부 리소스에 접속하는 방법으로서,

   데이터 통합 시스템을 서비스 지향 아키텍처 내의 복수의 서비스로서 전개하는 단계;

   하나 이상의 커넥터 컴포넌트를 상기 데이터 통합 시스템의 서비스 디렉토리에 서비스로서 등록하는 단계로서, 각각의 커넥터 컴포넌트는 외부 리소스에 접속하도록 구성되는 것인, 단계; 및

   외부 리소스에의 접속을 확립하기 위하여, 상기 데이터 통합 시스템 내로부터 서비스로서 상기 커넥터 컴포넌트의 하나를 사용하는 단계

   를 포함하는, 데이터 통합 시스템을 외부 리소스에 접속하는 방법.
10. 서비스의 디렉토리를 포함하는 서비스 지향 아키텍처;

    관련된 컴퓨터 프로그램 제품 슈트의 복수의 펑크션으로서, 상기 펑크션의 각각은 서비스의 디렉토리에 서비스로서 등록되는 것인, 펑크션; 및

    하나 이상의 서비스의 하나 이상의 인스턴스를 인보크(invoke) 하기 위한 인터페이스로서, 이에 의해 상기 관련 컴퓨터 제품 슈트가 상기 서비스 지향 아키텍처에 전개되는 것인, 인터페이스

    를 포함하는 시스템.

Images