KR20010052573A

KR20010052573A - 의사결정 지원 환경에서 객체 작업 공간 에이전트를구현하기 위한 시스템 및 방법

Info

Publication number: KR20010052573A
Application number: KR1020007013742A
Authority: KR
Inventors: 노타니란지트엔.; 파라스니스애브해이브이.; 휘플마크비.
Original assignee: 샌제이브 사이두; 아이2 테크놀러지즈, 인크.
Priority date: 1998-06-05
Filing date: 1999-06-03
Publication date: 2001-06-25
Also published as: WO1999063466A1; CA2333748A1; AU4415299A; JP2002517828A; US6334146B1; TW425517B; EP1084475A1

Abstract

복수의 저장된 객체를 갖는 제1 기업과 관련된 작업 공간을 포함하는 복합 기업 협력에 있어서, 원격으로 데이터에 접근하기 위한 컴퓨터 시스템이다. 컴퓨터 시스템은 제2 기업과 관련된 네트워크 노드를 추가로 포함하며, 네트워크 노드는 네트워크를 통하여 작업 공간과 통신한다. 상기 컴퓨터 시스템은 네트워크 노드에서 생성되는 에이전트를 추가로 포함하며, 에이전트는 네트워크를 통해 작업 공간에 접속할 수 있고, 에이전트는 또한 협력 동작을 수행하기 위하여 작업 공간 내에 저장된 복수의 객체 중 적어도 하나를 처리할 수 있다.

Description

의사결정 지원 환경에서 객체 작업 공간 에이전트를 구현하기 위한 시스템 및 방법 {SYSTEM AND METHOD FOR IMPLEMENTING OBJECT WORKSPACE AGENTS IN A DECISION SUPPORT ENVIRONMENT}

공급망, 기업체 및 사이트의 설계 분야 애플리케이션 및 환경은 제조 업체가 의사결정 지원(decision support)을 하고 관리 업무를 보조하는 데 널리 사용된다. 공급망, 기업체 및 사이트의 설계에 대한 의사결정 지원 환경은 단독 도메인 (single-domain) 통합(monolithic) 환경으로부터 다중 도메인(multi-domain) 통합 환경으로 발전하였다. 종래의 설계 소프트웨어 애플리케이션으로는 여러 회사들이 제공하는 광범위한 제품군이 있다. 기업체들은 이들 의사결정 지원 도구를 사용함으로써 복잡한 제조 업무를 더욱 효율적으로 관리할 수 있다. 하지만, 공급망은 흔히 복합적, 분산적, 이질적인 설계 환경이라는 특징을 갖는다. 따라서 종래 환경을 공급망의 설계 문제에 적용하는 경우에 통합 애플리케이션 구조 때문에 그 효율성에 제한이 있다. 또한, 이들 문제는 공급망 전체의 "소유자(owner)"가 한 사람이 아닌 경우에 더욱 심각해진다.

설계 환경을 위한 다음 발전 단계로는 관련된 다중 엔진 및 제품뿐 아니라 다중 도메인의 경우에도 사용할 수 있는 제품을 지원하는 다중 도메인 이질 구조를 수립하는 것이 바람직하다. 다양한 설계 환경을 일체형 솔루션(seamless solution)으로 통합하면 도메인간 및 기업체간의 공급망 설계가 가능해진다. 또한, 일부 설계 애플리케이션이 제공하는 중요한 기능은 단순히 트랜잭션 (transaction)을 추적하는 것이 아니라 처한 환경을 최적화하는 것이다. 특히, I2 TECHNOLOGIES사로부터 입수할 수 있는 RHYTHM 계열의 제품은 최적화 기능 (optimization functionality)을 제공한다. 하지만, 기업체 또는 공급망 수준에서의 설계에 대하여, SAP로부터 입수할 수 있는 애플리케이션 등 종래의 많은 애플리케이션은 전사적 자원 관리(enterprise resource planning, ERP) 엔진을 사용하며 최적화를 제공하지 않는다.

기업의 성공 또는 실패는 기업 내에서 이루어지는 의사결정의 질(quality)에 크게 좌우될 수 있다. 따라서, I2 TECHNOLOGIES사의 RHYTHM 계열 제품 같이, 기업 내에서 최적의 의사결정을 지원하는 의사결정 지원 소프트웨어는 특히 기업의 성공에 중요하다. 일반적으로, 최적의 의사결정은 도메인이 의사결정에 이를 때 고려하는 "전세계(world)"의 범위인 의사결정 지원의 도메인과 관련되어 있다.

예를 들어, 의사결정은 공장이 주어진 시간 동안 주어진 품목을 얼마만큼 생산해야 하는 것인지가 될 수 있다. "최적의" 답은 의사결정의 도메인에 달려 있다. 예를 들어, 도메인이 바로 공장 자체일 수 있고, 그 공장을 포함하는 공급망, 기업 전체, 또는 복합 기업 공급망일 수도 있다. (뒤의 두 개는 더 큰 도메인 또는 다수 공급망으로 여겨질 수도 있다.) 통상적으로 의사결정 지원의 도메인이 클수록, 의사결정은 더욱 최적화될 것이다. 결국, 의사결정 과정에서 더 큰 도메인을 포함하는 의사결정 지원 소프트웨어가 바람직하다. 하지만 이러한 적용 범위의 확장은 심각한 문제를 야기한다.

이러한 문제점 중 하나는 도메인 또는 다중 도메인 환경에서 지역 객체 작업 공간에 접근하는 원격 개체(entities)를 허용하지 않는 현재 의사결정 지원 소프웨어의 제한을 포함한다. 이러한 소프트웨어는 관리 태스크(administrative tasks), 루틴(routine)의 최적화 또는 지역 작업 공간에서의 다른 형태의 데이터 및 객체의 처리를 용이하게 실행하기 위한 그러한 원격 개체를 허용하지 않는다.

본 발명은 공급망(supply chain), 기업체 및 사이트 설계 분야에 관한 것으로, 특히 의사결정 지원 환경에서 객체 작업 공간 에이전트를 구현하기 위한 시스템 및 방법에 관한 것이다.

도 1은 기업간의 협력 작업을 지원할 수 있는 컴퓨터 구현 구조의 한 실시예를 나타낸 도면이고,

도 2는 전역(global) 협력 체제의 성분(component)들의 실시예의 도면이고,

도 3은 특수 모듈을 구성하는 특정 소프트웨어 요소가 강조된 도 2의 전역 협력 체제의 도면이고,

도 4는 최적의 의사결정을 위하여 기업내 및 기업간의 협력 작업을 돕는 시스템의 실시예의 도면이고,

도 5는 전역 협력 작업 공간 사용의 실시예의 도면이고,

도 6은 협력 작업을 위한 순환 과정(lifecycle)의 실시예의 도면이고,

도 7은 관계의 양쪽에 공통 소프트웨어가 존재하는 경우와 존재하지 않는 경우의 도면이고,

도 8은 허브(hub) 대 스포크(spoke) 및 허브 대 웹(web) 사이에 있어서, 보안 배치의 실시예의 도면이고,

도 9는 허브 대 허브 경우를 위한 보안 배치의 실시예의 도면이고,

도 10은 그룹간의 매개 변수화를 포함하는 기업간의 작업 흐름을 설계하는 실시예의 도면이고,

도 11은 작업 흐름 설계의 수정시 변경을 관리하는 한 실시예의 도면이고,

도 12는 외부 세계와 작업 흐름을 통합하는 한 실시예의 도면이고,

도 13은 단일 동작에서 실행되는 데이터 흐름의 한 실시예의 도면이고,

도 14는 다수 동작으로 나누어지는 데이터 흐름의 한 실시예의 도면이고,

도 15는 변형 모델에 기초한 공통 데이터 모델의 블록도이고,

도 16은 직접적인 변형의 한 실시예의 도면이고,

도 17은 서로 다른 접근 및 변형 레벨의 한 실시예의 도면이고,

도 18은 협력 작업 시 스포크 엔진을 허브 엔진으로 대체한 한 실시예의 도면이고,

도 19는 본 발명에 따라 구성된 작업 공간을 사용하는 컴퓨터 시스템의 한 실시예를 나타내는 블록도이고,

도 20은 본 발명에 따라 구성된 도 19의 작업 공간의 한 실시예를 나타내는 도면이고,

도 21은 본 발명에 따라 객체 작업 공간에 작업하기 위하여 에이전트를 이용하는 컴퓨터 시스템의 블록도이고,

도 22는 작업 공간에 접근하기 위하여 도 21의 에이전트를 이용하는 방법의 한 예를 나타내는 흐름도이다.

본 발명에 따른 의사결정 지원 환경에서 객체 작업 공간 에이전트를 구현하기 위한 시스템 및 방법은 종래의 공급망, 기업 및 사이트 설계 환경을 능가하는 이점을 제공한다.

본 발명의 한 특징에 따르면, 복합 기업 협력에서 원격으로 데이터에 접근하기 위한 컴퓨터 시스템은 복수의 저장된 객체를 갖는 제1 기업과 관련된 작업 공간을 포함한다. 컴퓨터 시스템은 제2 기업과 관련된 네트워크 노드를 추가로 포함하며, 네트워크 노드는 네트워크를 통하여 작업 공간과 통신한다. 상기 컴퓨터 시스템은 네트워크 노드에서 생성되는 에이전트를 추가로 포함하며, 에이전트는 네트워크를 통해 작업 공간에 접속할 수 있고, 에이전트는 또한 협력 동작을 수행하기 위하여 작업 공간 내에 저장된 복수의 객체 중 적어도 하나를 처리할 수 있다.

본 발명의 기술적 이점은 원격 작업 공간 내 에이전트의 프로그램된 목표를 만족시키기 위하여 에이전트로 원격 작업 공간에 접근하는 능력이다.

본 발명의 부가적인 기술적 이점은 접속(contact)을 상실한 에이전트를 갖고서 제2 기업, 노드 또는 플랫폼에서 실행을 개시하였음에도 불구하고 제1 기업, 노드 또는 플랫폼에서 태스크를 실행하는 에이전트의 능력이다.

본 발명의 부추가적인 이점은 에이전트가 근원지 노드(originating node)로 돌아가는 목적지(destination) 노드에서 태스크 실행 결과와 통신할 수 있는 것이다. 다른 이점은 에이전트가 작업 공간에 상주하는 다른 에이전트를 실행하거나 작동시킬 수 있는 것이다. 부가적인 기술적 이점은 다음의 도면, 서술 및 청구범위로부터 당업자에게 점차로 명백해 질 것이다.

본 발명 및 그 이점의 보다 완벽한 이해는 첨부 도면을 참조하여 행할 이하의 설명을 참조함으로써 이루어질 수 있으며, 도면에서 유사한 도면 부호는 유사한 부분을 나타낸다.

의사결정 지원 과정의 개선은 최적의 의사결정을 위하여 기업 수준 및 복합 기업 수준의 의사결정 지원으로의 확장을 포함한다. 기술적으로 및 개념적으로, 기업 수준 및 복합 기업 수준의 의사결정 지원은 공장 수준 및 공급망 수준 의사결정 지원과 다르다. 이러한 이유는 (기업 또는 복합 기업 내의 영업부 같은) 다수의 도메인인 경우, 서로 다른 도메인이 흔히 서로 다른 의사결정 지원 소프트웨어를 운영하기 때문일 수 있다. 또한 다수의 도메인인 경우, 일반적으로 한 도메인이 다른 도메인에게 특정한 의사결정을 하도록 강제할 수 없다. 바꾸어 말하면, 이러한 환경에서 최적의 의사결정 지원은 강제가 아닌 교섭을 통하여 실행되는 것이 때로는 필요하다.

다수의 도메인에서의 의사결정 지원은 의사결정 지원에 대한 강제적인 접근 방식보다는 협력적인 접근 방식을 추구함으로써 실현될 수 있다. 다양한 통신 및 분산 처리 기술들은 인터넷, 웹, 자바(Java), XML(extensible markup language), CORBA(common object request broker architecture) 등 큰 규모의 협조적인 의사결정이 용이한 환경을 구현하도록 사용될 수 있다. RHYTHM-GLOBAL COLLABORATION MANAGER(GCM) 및 RHYTHM-GLOBAL COLLABORATION DESIGNER(GCD)등 의사결정 지원에 협조적으로 접근할 수 있게 하는 I2 TECHNOLOGIES사의 제품들을 곧 이용할 수 있게 될 것이다.

협력 시스템 및 과정 성분

도 1은 기업간의 협력 작업을 지원할 수 있는 컴퓨터 실현 구조의 한 실시예를 나타낸다. 나타낸 것처럼, 전역 의사결정 지원 구조를 연결(link), 비전 vision), 전역 메시징(global messaging) 및 데이터 저장소 성분에 기초하여 구축할 수 있다. 협력 작업은 의사결정 지원 구조가 지원하는 전역 협력 설계자 global collaboration designer, GCD) 및 전역 협력 관리자(global collaboration manager, GCM)를 포함한다. GCD는 협력 작업을 설계 및 인스턴스 생성하는 데 이용할 수 있고, GCM은 협력 작업을 실행하는 데 이용할 수 있다. 이러한 조직하에, 협력 작업은 모듈로서 참조되고 변형될 수 있다.

도 2는 전역 협력 체제의 성분의 한 실시예를 나타낸 도면이다. 나타낸 것처럼, 허브(hub) 기업(2)이 스포크(spoke) 기업(4) 및 웹(web) 기업(6)과 협력할 수 있는 체제로 되어 있다. 허브 기업(2) 및 스포크 기업(4) 각각은 GCM(8)을 포함한다. GCM(8)은 각각의 내부 전역 협력 작업 공간(10)과 연결되어 통신한다. 외부 전역 협력 작업 공간(12)은 허브 기업(2), 스포크 기업(4) 및 웹 기업(6) 간에 데이터를 공유하는 수단을 제공한다. 허브 기업(2)은 또한 전자 데이터 교환(electronic data interchange, EDI) 처리기(14)를 통하여 부가 가치 통신망(value added network, VAN)과 협력할 수 있다. 또한 허브 기업(2)은 전역 메시지 버스(15)를 이용하여 다른 허브 기업과 통신하고 협력할 수 있다.

동작을 할 때, 협력 작업의 주제어기는 허브 기업(2)의 GCM 엔진(8)이 될 수 있다. 허브 대 허브 관계는 전역 메시지 버스(15)를 통하여 용이하게 이루어질 수 있고, 허브 대 스포크 및 허브 대 웹의 관계는 외부 GCW(global collaboration workspace, 전역 협력 작업 공간)(12)를 통하여 용이하게 이루어질 수 있다. 나타낸 것처럼, 허브 기업(2)은 일반적으로 내부 GCW(10) 및 외부 GCW(12)를 가질 수 있다. 내부 GCW(10)는 EDI 처리기(14) 및 내부 사용자 인터페이스와 데이터를 공유하고 교환하는 데 이용할 수 있다. 외부 GCW(12)는 스포크 기업(4) 및 웹 기업들과 데이터를 공유하고 교환하는 데 이용할 수 있다.

보안상 외부 GCW(12)는 DMZ(demilitarized zone, 비무장 지대) 또는 허브 기업(2)의 단체(corporate) 방화벽 밖에 설치될 수 있다. 이러한 방법은 외부로부터 허브 기업(2)의 보호를 받는 기업 네트워크로 직접 연결될 필요가 없다. 외부 GCW는 예를 들어 IIOP(internet inter-orb protocol), HTTP(hypertext transfer protocol), HTTPS 연결을 받아들일 수 있다. 특히, 나중 두 개의 연결은 현존하는 방화벽 구조를 연결하는 데 유용하다. 이러한 방법으로, 솔루션을 더욱 빠르게 배치할 수 있는 방화벽 구조를 클라이언트쪽(스포크 노드 또는 웹 노드) 및 서버(허브 노드)쪽 중 어느 하나에 배치할 필요가 없다.

도 3은 특수 모듈을 이루는 특정 소프트웨어 성분을 강조한 도 2의 전역 협력 체제의 도면이다. 보는 바와 같이, 전역 협력 관리자 모듈용 소프트웨어는 허브 엔진(8), 스포크 엔진(8), 허브-사용자 UI(user interface, 사용자 인터페이스), 스포크-사용자 UI 및 웹-노드 UI 내에 존재할 수 있다. 또한 모듈은 허브 기업(2) 및 스포크 기업(4)에서 원시 애플리케이션(17)과 통신할 수 있다. 원시 애플리케이션(17)과의 통신은 동기식이거나(가는 선) 비동기식(굵은 선)일 수 있다. 나타낸 바와 같이, 원시 애플리케이션(17)과의 비동기식 통신은 내부 GCW(10)를 통하여 용이하게 이루어질 수 있다. 또한, GSDB(global series database, 전역 직렬 데이터 베이스)는 허브 기업(2)쪽에 존재할 수 있다.

도 4는 도면 부호(16)에 일반적으로 나타낸, 최적 의사결정을 위하여 기업내 및 기업간의 협력 작업을 허용하는 시스템의 한 실시예를 나타낸 도면이다. 나타낸 것처럼, 시스템(16)은 컴퓨터 시스템에서 실행되는 허브 엔진 내의 프로세스일 수 있는 허브 노드(18)를 포함한다. 허브 노드(18)는 컴퓨터 시스템에서 실행되는 허브 엔진 내의 프로세스일 수 있는 스포크 노드(20)와 연결되고 통신한다. 나타낸 바와 같이, 스포크 노드(20)는 허브 노드(18)의 기업 경계(22)의 외부에 있을 수 있다. 허브 노드(18)는 또한 하나 이상의 컴퓨터 시스템에서 실행되는 스포크 엔진 내의 프로세스일 수 있는 다수의 스포크 노드(24)와 연결되고 통신한다. 또한 허브 노드(18)는 컴퓨터 시스템에서 실행되는 웹 브라우저 내의 프로세스일 수 있는 다수의 웹 노드(26)와 연결되어 통신한다. 그리고 허브 노드(18)는 EDI 시스템에 게이트 웨이(gate way)를 제공할 수 있는 EDI 프록시(proxy)(28)와 연결되어 통신한다.

GCW와 함께 허브 엔진 및 스포크 엔진은 GCM의 주요한 개체가 될 수 있다. 이러한 환경에서, 허브 엔진은 협력 작업의 주제어기이다. 허브 엔진은 지역 (local) 협력 작업뿐만 아니라 전역 협력 작업에서도 호환될(coordinate) 수 있다. 전역 협력 작업은 허브 노드(18), 스포크 노드(20, 24), 그리고 웹 노드(26)를 연결하는 것이다. 지역 협력 작업은 특정 단일 역할 허브 또는 스포크/스포크-군에서 실행될 수 있다. 이러한 협력 작업은 분할될 수 있지만, 단일 기업의 경계 안에 머물러 있다. 허브 엔진은 또한 EDI 프록시(28)의 VAN-EDI 처리기뿐만 아니라 허브-사용자 UI와 호환될 수 있다. 한 실시예에서, 허브 엔진은 동일한 협력 작업의 다수 변형뿐만 아니라 다수 협력 작업도 동시에 연계할 수 있는 다중 스레디드 (multi-threaded) 엔진이다. 또한 허브 엔진은 협력 작업을 동적으로 로딩하고 실행할 수 있다.

스포크 엔진은 또한 협력 작업을 초기화하도록 동작할 수 있다. 이러한 환경하에서, 허브 엔진과는 달리 스포크 엔진은 독립적인 개체가 아니다. 대신에 스포크 엔진은 허브 엔진과 공동으로 협력 작업을 조정할 수 있을 뿐이다. 또한, 스포크 엔진은 다른 스포크 엔진이나 다른 웹 노드와 호환될 수 없다. 허브 엔진처럼, 스포크 엔진은 다중 스레디드(multi-threaded)일 수 있고, 이에 따라 동시에 동일한 협력 작업의 여러 변형뿐만 아니라 다중 협력 작업과 호환될 수 있다. 스포크 엔진은 또한 협력 작업을 동적으로 로딩하고 실행할 수 있다.

도 5는 GCW(30) 사용의 한 실시예의 블록도이다. 도 5에서, GCW(30)는 협력시 다양한 개체간의 데이터/객체를 공유하는 데 쓰이는 주요한 개체를 제공한다. 나타낸 것처럼, GCW(30)는 다수의 GCM(32), 지역 사용자 인터페이스(34), 웹 서버(36), 웹 사용자 인터페이스(37) 및 원시 애플리케이션(38)과 인터페이스 할 수 있다. 일반적으로 객체는 한 개체에 의하여 GCW(30)에 놓여질 수 있고, 다른 개체에 의하여 검색될 수 있다. 검색(retrieval)은 질의(query) 또는 가입 (subscription)으로 수행할 수 있다. 이러한 방법으로 GCW(30)는 메시지 버스뿐만 아니라 데이터 베이스의 속성과 결합한다.

GCW는 메모리 내(in-memory) 또는 영구 슬롯의 층으로 조직될 수 있다. 슬롯은 또한 대기 행렬화 되어 있거나 규칙적일 수 있고, 미세 그레인 허용성 (grain permissibility)이 각 슬롯에 부착되어 있다. 허용성은 바이 유저 바이 오퍼레이션(by-user-by-operation)에 의하여 할당된다. 주요 동작은 판독, 기록, 취득 및 가입(subscribe)일 수 있다.

메모리 내 슬롯은 휘발성 기억 장치에 데이터를 보관한다. 메모리 내 슬롯으로부터의 기록 및 검색은 매우 빠르지만, GCW(30)가 고장나면 데이터가 손상된다. 메모리 내 슬롯으로 사용되는 경우, GCW(30)는 빠르고, 안전하며, 보안 및 메시징 기능이 있는 메모리 내 객체 데이터 베이스로서 간주될 수 있다. 영구 슬롯은 안정한 기억 장치에 데이터를 보관한다. 영구 슬롯에서의 기록 및 검색은 메모리 내 슬롯보다는 느리지만, GCW(30)가 고장나더라도 데이터가 손상되지 않는다.

메모리 내 슬롯 또는 영구 슬롯 중에서 어떤 것을 사용할지에 관한 결정은 애플리케이션에 따라 다를 수 있다. GCW(30)는 객체의 형태로 데이터를 저장하며, Java 객체, CORBA 객체 또는 임의 바이트 어레이를 저장할 수 있다. 메모리 내 성능과 결합된 이들은 GCW(30)를 I2 TECHNOLOGIES사의 SUPPLY CHAIN PLANNER와 FACTORY PLANNER 등의 서로 다른 객체 지향 메모리 내 엔진간의 고속 데이터 공유 기구로 만든다.

GCD는 협력 설계자로 하여금 GCM을 사용하여 실행되는 협력 작업을 상호 유기적으로 설계하고, 인스턴스 생성하고(instantiate) 배치(deploy)하도록 한다. GCD의 출력은 GCM에 의하여 자동으로 로딩되고 실행될 수 있는 코드이다. 설계자는 GCD를 이용하여 새로운 협력 작업을 생성하고, 현존하는 협력 작업을 검색하며, 협력 작업을 변형(version)할 수 있다. 설계자는 또한 GCD를 이용하여 협력 작업용 허브 및 스포크 엔진을 설계하고, 협력 사건(events) 및 메시지를 설계할 수 있다. GCD는 자체 내에서 손쉽게 사용할 수 있도록 표준 객체 라이브러리와 표준 성분 라이브러리를 통합할 수 있다. GCD는 동기식, 비동기식, 하부 작업 흐름, 앤드-분할(and-splits), 오어-분할(or-splits), 동기화 결합(synchronization-joins), 이질 캐스트 분할(heterocast-splits), 이질 캐스트 결합(heterocast-joins) 등을 가진 복잡한 복합 기업 작업 흐름을 생성하는 데 사용할 수 있다. 전역 작업 흐름과 지역 작업 흐름 모두가 생성될 수 있다. GCD는 협력 작업을 자동 증명하고 GCM이 실행하는 코드를 자동 생성할 수 있는데, 원하는 경우 생성된 코드를 직접 수동으로 편집할 수 있다. 또한, GCD는 보안 관리자 구성 및 GCW 구성의 생성을 포함한 협력 작업의 인스턴스를 생성할 수 있다.

도 6은 협력 작업을 위한 순환 과정의 한 실시예의 블록도이다. 나타낸 것처럼, GCD를 이용하여 협력 작업을 단계적으로 설계할 수 있다. 따라서, 단계(42)에서 GCD를 이용하여 협력 작업의 인스턴스를 생성할 수 있다. 이 후, 인스턴스 생성된 협력 작업을 단계(44)에서 GCD 및 GCM을 이용하여 배치할 수 있다. 배치를 마친 후에, 단계(46)에서 GCM을 이용하여 협력 작업을 실행할 수 있다. 이어서, 새로운 인스턴스를 생성하거나 협력 작업의 새 버전을 생성할 수 있다. 새로운 인스턴스를 생성하기 위하여, 흐름은 단계(42)로 되돌아온다. 새 버전을 만들기 위하여, GCD를 사용하여 단계(48)에서 협력 작업을 수정할 수 있다.

단일 도메인 의사결정 지원에서 다수 도메인 의사결정 지원으로 확장하는 것도 복잡할 수 있다. 특히, 다음의 논의는 다수 도메인 의사결정 지원이 행하는 다수의 도전에 대하여 기재하고, 최적의 의사결정을 위한 기업내 및 기업간의 협력 작업을 허용하는 본 시스템 및 과정이 그러한 도전들을 착수하는 방법의 실시예에 대하여 설명한다.

표현의 이질성

협력 작업에서의 하나의 문제점은 기업간의 표현 이질성을 해결하는 것이다. 협력 작업이 성공적으로 이루어지기 위하여서는, 기업간의 표현 이질성을 해결할 필요가 있다. 기업들은 흔히 동일한 데이터를 서로 다른 방법으로 나타낸다. 이러한 차이점들은 의미의 차이에서부터 기술적 차이, 이름짓기의 차이 등에까지 이른다. 이러한 차이들을 해소하는 하나의 명백한 해법은 표준화이다. 그러나, 이는 동의하여야 할 표준이 무엇인지에 대한 쟁점을 곧 불러 일으킨다. 본 시스템 및 과정은 이러한 요구와는 관련이 없다.

주소화가 필요한 표준의 세 가지 관련 범주가 있을 수 있다. 이러한 세 개의 범주는 형식(format) 표준, 전송(transport) 표준 및 의미(semantic) 표준이다. 형식 표준은 데이터 및 객체가 부호화되는 기술적 형식에 관한 것이다. 예로서 XML, Java 시리얼 스트림(serial stream), IIOP 시리얼 스트림 및 EDI 형식을 포함한다. 전송 표준은 데이터를 넘겨 주는 데 사용된다. 이들은 HTTP, IIOP, RMI(remote method invocation), DCOM(distributed common object model, 분산 콤), FTP(file transfer protocol) 및 VAN과 MQ 시리즈(MQSeries)같은 비동기식 메시지 버스 등을 포함한다. 세 번째로, 의미 표준은 데이터의 의미 내용이 기재되는 방식이다. 예를 들어 EDI 및 I2 COMMON DATA MODEL(CDM)을 포함한다.

이러한 면에서 표준을 고려함으로써, 쟁점에 대한 이해를 도출할 수 있다. 많은 현존하는 표준이 위에 서술한 두 개 이상의 범주를 포함하고 다양한 표준에 대한 논의가 논의되어야 범주를 범주화하지 못한다는 사실에서 오늘날의 혼동이 비롯되었다. 예를 들어, EDI는 원칙적으로 의미 표준이지만, 통상적으로 형식 표준(EDI 파일 형식) 및 전송(부가 가치 통신망) 표준을 의미하기도 한다. 이러한 것을 이해하면, EDI 의미 표준이 나머지 두 개로부터 분리될 수 있다는 것이 명백해진다. 따라서, 의미 EDI 객체는 Java 시리얼 스트림 따위의 다른 형식으로 부호화될 수 있고, HTTP따위의 다른 전송 표준으로 건네질 수 있다. 이와 비슷하게, XML은 주로 다양한 의미 표준을 부호화하는 데 사용될 수 있는 형식 표준이다. XML에서 EDI를 부호화하기 위하여 노력중이다.

많은 형식 표준들이 XML, EDI 형식, Java 시리얼 스트림(Java 형식이라고 하여 Java 언어 또는 Java 플랫폼과 혼동하지 않아야 함) 및 IIOP 시리얼 스트림을 포함하는 본 GCM에 의하여 지원될 수 있다. 한 실시예에서, 이들 중 Java 형식은 주형식이며, 나머지는 파생 형식이다. Java 형식은 다른 형식을 생성하는 기능을 포함할 수 있기 때문에 주형식으로 선택된다. Java 형식으로부터 XML, EDI 및 IIOP 형식들을 파생시킬 수 있다.

도 7에서 (A), (B)는 각각 I2 TECHNOLOGIES사의 공유 소프트웨어가 관계의 양쪽에 있는 경우와 그렇지 않은 경우를 나타낸 도면이다. 나타낸 것처럼, 예를 들어 RHYTHM GCM이 양쪽에 있는 경우, 중간 형식으로 변환함으로써 얻어지는 것은 없다. 이는 불필요한 비효율성을 초래하며, 데이터만(객체는 아님)이 교환 가능하고, 애플리케이션의 범위가 제한된다. 따라서, 동일한 소프트웨어를 양쪽에 쓰는 경우, 이진(binary) Java 객체를 바로 교환할 수 있다. 한편, 예를 들어 RHYTHM GCM이 단지 한 쪽에만 있는 경우, XML 또는 EDI 형식의 "객체"를 (외부로) 산출할 수 있고 (내부로) 해석할 수도 있다.

전송 표준에 관하여, 본 GCM은 HTTP, IIOP 및 비동기식 메시지 버스들을 비롯한 다양한 전송 표준을 지원할 수 있다. 보다 상세한 것은 다수 관계 유형 처리에 대해 아래에서 설명한다.

의미 표준으로 말하자면, 본 GCM은 EDI와 RHYTHM-CDM, 두 의미 표준을 주로 지원할 수 있다. EDI가 일반적으로 가장 널리 사용하는 의미 표준이기 때문에 GCM은 이를 지원할 수 있다. 그러나 EDI는 설계 도메인의 범위를 넓게 제공하지 않는 결점이 있다. 한편, RHYTHM-CDM은 설계 도메인의 범위를 넓게 제공하고 복합 기업 의사결정 지원을 실행하기에 적합한 구조를 제공한다. 또한, I2 TECHNOLOGIES사의 모든 설계 엔진은 이러한 형식을 지원한다.

일반적으로, EDI 같은 공공 표준의 한 가지 문제점은 기업이 교환하고자 하는 데이터/객체의 종류를 이들이 적절히 포함하지 못할 수도 있다는 것이다. 또한, 특별한 표준화 기구가 객체를 표준화하는 것을 기다리는 것이 선택 사항이 아닐 수도 있고, 공급망이 공공 표준을 사용함으로써 특별히 경쟁력을 가지지 못할 것이다. 이러저러한 이유 때문에 본 GCM은 전용(proprietary) 공동체 표준을 지원함으로써 표준화로의 대안적인 접근을 지원한다. 예를 들어, RHYTHM-GCD를 사용하여 기업 공동체는 그 공동체에만 관련된 한 벌의 표준을 고안할 수 있다. RHYTHM-GCM은 이러한 전용 공동체 표준을 지원하고 강화할 것이다. RHYTHM-GCD는 또한 전용 공동체 표준으로 이루어질 수 있는 블록 객체 형성의 라이브러리를 지원한다. 전용 공동체 표준은 다음과 같은 많은 이점을 지닌다. 기업이 교환하고자 하는 데이터/객체의 종류를 정확히 포함하도록 표준을 설계할 수 있다. 관련 당사자만이 특정 표준에 동의할 필요가 있으므로 그 과정이 표준화 기구를 기다리는 것보다 훨씬 빨라질 것이다. 서로 다른 범주의 파트너에게 서로 다른 표준들을 개발할 수 있고, 특히 심한 경우에는 각 파트너마다 서로 다른 표준을 개발해 줄 수 있으며, 공급망에 경쟁 상대보다 우월한 경쟁력을 주는 표준을 개발할 수 있다.

다중 관계 유형

협력 작업의 허용에서의 또다른 문제점은 다중 관계 유형을 취급하는 것이다. 기업은 파트너들과 다양한 유형의 관계를 갖는다. 관계가 변할 수 있는 몇 가지 경우는 한 쪽이 대형 무역 파트너간이고 다른 한 쪽이 소형 무역 파트너간인 경우, 공급망에 대체로 같은 영향을 미치는 기업간이고 공급망에 동일하지 않은 영향을 미치는 기업간인 경우, 한편이 기술 정밀도가 높은 기업간이고 다른 한편이 기술 정밀도가 동일하지 않은 기업간인 경우와 같다. 이러한 서로 다른 관계 유형은 서로 다르게 취급되어야 한다.

본 GCM은 앞에서 설명하고 도 4에 나타낸 것처럼 허브와 스포크 망으로서 기업 관계를 모형화할 수 있다. 이러한 실시예에서 네 가지 관계의 유형은 허브 대 웹, 허브 대 Van-EDI, 허브 대 스포크 및 허브 대 허브이다. 각 관계 유형은 해당하는 용도가 있다.

허브 대 웹에 관하여, 사람들이 오늘날 전자 상거래에 대해 말할 때, 그들은 웹 브라우저가 몇몇 중앙 서버와 통신할 수 있는 구조를 종종 의미한다. 이러한 구조는 몇 가지 장점을 지니는 데, 이러한 구조를 지원하는 기반 구조 (infrastructure)는 보통 이미 자리 잡혀 있고 , 모든 관리는 서버 쪽에 집중될 수 있다. 그러나 이러한 구조는 또한 웹-브라우저 쪽에 사람이 필요하다는 점에서 큰 단점을 지닌다. 따라서 시스템 대 시스템 자동화는 불가능하다. 이러저러한 장단점에 기초하여, 이러한 관계 유형은 기업이 소수의 파트너 또는 기술적 정교함이 떨어지는 파트너와 데이터를 교환할 필요가 있는 경우에 적합할 수 있다.

허브 대 VAN-EDI에 관하여, 오늘날 대부분의 기업간 전자 상거래는 부가 가치 통신망을 통하여 EDI를 보냄으로써 이루어진다. 이러한 접근의 장점은 시스템간의 통합이 가능하고 현재 지원되는 방식이라는 것이다. 이러한 접근의 단점들은 다음과 같다. 전용 부가 가치 통신망을 통하여 데이터를 전송하므로 큰 비용이 들고, 진정한 표준화의 부족으로 많은 관리 비용이 들며, 진정한 표준으로부터 그 기업에 맞는 형태로 전환하는 데에만 제3의 수단이 필요하며, 시스템과 인간 간의 통합을 위한 지원이 없고, 전용 표준이나 단체 표준을 위한 지원이 없다. 이러저러한 장단점에 기초하여, 이러한 관계 유형은 레거시(legacy) VAN-EDI 환경을 지원하는 경우에 적합할 수 있다.

허브 대 스포크에 관하여, 이러한 관계 유형은 또한 VAN-EDI 같은 시스템 대 시스템의 통합을 가능하게 한다. 구조적으로 허브 대 스포크는 허브 엔진과 스포크 엔진 간의 협력 작업이다. 허브 대 스포크 관계는 VAN-EDI에 비해 이점을 가지고 있다. 허브 대 스포크는 네트워크 비용을 절감하기 위하여 공공 인터넷을 사용할 수 있다. 허브 대 스포크의 관계 기반 구조의 많은 부분이 중앙 집중식으로 배치되고 관리될 수 있기 때문에 관리 비용이 VAN-EDI보다 훨씬 싸다. 데이터와 더불어 진정한 객체를 더욱 발전된 협력이 가능하도록 교환할 수 있고, EDI, I2-CDM 및 독점 공동체 표준을 비롯한 다수의 의미 표준을 지원할 수 있다. 위의 특성들에 기초하여, 허브 대 스포크 관계는 정교한 시스템간의 협력을 행하기를 바라는 기업간에 적합할 수 있다. 이것은 기업의 어느 한 쪽에도 I2 TECHNOLOGIES사의 소프트웨어가 존재하지 않는 경우에 또한 적합할 수 있다. 이는 허브 대 스포크의 관계가 허브 기업에 의하여 중앙 집중식으로 배치될 수 있기 때문이다.

허브 대 허브에 관하여, 그 관계가 허브 엔진과 스포크 엔진 간이 아니라 허브 엔진 간에 발생한다는 점을 제외하고는 허브 대 스포크와 비슷하다. 이러한 특성에 기초하여, 허브 대 허브는 복잡한 시스템 대 시스템 협력을 행하기를 바라는 기업간에 적합할 수 있다. 또한, 허브 대 허브 관계는 두 기업이 각각 따로 RHYTHM-GCM을 구입하고 허브 엔진을 설치한 경우에 적합할 수 있다.

허브 엔진과 스포크 엔진 간에는 차이점이 있다. 일반적으로, 허브 엔진의 능력은 스포크 엔진의 능력보다 상위에 있다. 표 1은 몇몇 차이점의 예를 제공한다.

표 1
	스포크 엔진	허브 엔진
구입 및 배치	스포크 엔진과 한 묶음으로 되어 있음. 따라서 허브 기업은 허브 엔진과 파트너에게 배치할 수 있는 다수의 스포크 엔진을 구입할 것임.	따로 판매됨.
지원되는 관계 유형	허브 대 스포크 관계를 지원할 수 있음. 또한 각 스포크 엔진은 특정 허브 엔진(허브)과만 통신할 수 있음.	허브 대 허브, 허브 대 스포크, 허브 대 웹, 허브 대 VAN-EDI 관계 유형을 지원함.
협력 작업 생성	협력 작업을 볼 수 있으나 협력 작업을 생성할 수 없음.	협력 작업을 보고 생성할 수 있음.
내부 사용자 역할	단일 내부 사용자 역할을 지원	다수의 내부 사용자 역할을 지원

보안

협력 작업의 또 다른 문제점은 포괄적인 보안에 대한 요구이다. 기업이 효율적으로 협력할 수 있으려면, 보안 문제에 신경 쓸 필요가 있다. 협력 환경에서 보안에 서로 다른 많은 면이 있다. 특정 복합 기업 협력 체제는 이러한 다른 모든 면에 신경을 써야 한다. 협력 보안 체제가 갖추어야 할 요건으로는 다음과 같은 것들이 있다. 두 파트너만이 두 파트너 간에 교환된 데이터를 볼 수 있어야 한다. 두 파트너 간에 교환된 데이터의 조작이 불가능해야 한다. 기업은 주장(claim)하는 자가 파트너임을 확인할 수 있어야 한다. 체제 (framework)는 파트너의 네트워크에 보안상의 새로운 허점을 만들지 말아야 한다. 체제의 설치 및 관리가 비교적 쉬워야 한다.

이러한 요건을 만족하는 포괄적인 보안 전략을 구현함으로써 보안 협력 체제를 제공할 수 있다. 한 실시예에서, 이 전략은 기술적 보안, 허용성 체제 및 데이터 분할(data partitioning)의 세 가지 다른 면을 갖는다.

기술적 보안이란 보안을 보장하는 데 사용되는 기술적 수단을 뜻할 수 있다. 이러한 보안은 개인 정보 보호(privacy), 인증, 데이터 통합을 제공하는 데 사용될 수 있다. 개인 정보 보호는 권한이 없는 사람이 데이터를 볼 수 없도록 보증한다. 인증은 협력의 당사자가 실제 그들이 주장하는 자인지를 인증하는 것을 포함한다. 데이터 통합은 권한이 없는 자가 어떤 형태로도 전송된 데이터를 수정하지 못하게 하는 것을 포함한다.

정확한 보안 접근은 앞서 기술한 관계 유형에 기초하여 변할 수 있다. 예를 들어, 한 구조를 표 2에 상세히 나타내었다.

표 2
관계 유형	기술적 접근	제공처
허브 대 웹	SSL 3.0을 통한 HTTP [보기:디피-헬멘(Diffie-Helman)]	전역 협력 작업공간
	SSL 3.0을 통한 HTTP (보기:RSA)
	SSL 3.0을 통한 IIOP	전역 협력 작업공간
허브 대 스포크	SSL 3.0을 통한 HTTP [보기:디피-헬멘(Diffie-Helman)]	전역 협력 작업공간
	SSL 3.0을 통한 HTTP	전역 협력 작업공간
	SSL 3.0을 통한 IIOP	전역 협력 작업공간
허브 대 허브	SSL 3.0을 통한 TCP/IP	전역 메시지 버스
	내용 기반 암호화	전역 메시지 버스
허브 대 VAN EDI	VAN을 통한 보안	VAN

표에 나타난 것처럼, 허브 대 VAN EDI를 제외하고는 모든 관계 유형이 SSL(secure socket layer, 보안 소켓 계층) 3.0을 통하여 보안을 지원할 수 있다.

SSL 3.0은 소켓 기초 연결(socket-based connection) 공공 열쇠 암호화(public key encryption)를 지원하는 데 사용되는 산업 표준 프로토콜이고, 개인 정보 보호, 서버 및 클라이언트 인증, 데이터 통합, 인증 관리를 제공한다. SSL 3.0은 RSA와 Diffie-Helman을 비롯해 많은 공공 열쇠 암호 알고리즘이 접속될 수 있는 높은 수준의 프로토콜이다.

SSL 핸드셰이크(handshake)가 완료되면, 다음 인스턴스는 사용자 이름-암호 (username-password) 인증이다. 이것은 SSL 3.0 자체가 제공하는 것 이상의 인증을 제공한다. 암호는 PKCS5 암호 기반 암호화(password-based encryption)(RSA 표준)를 사용하여 저장될 수 있다. 사용자 또는 스포크가 인증되면, 액세스 토큰 (Access Token)을 받는다. 이러한 액세스 토큰은 관리자가 지정 가능한 (administrator-specifiable) 수명을 가지고 있다. 사용자는 액세스 토큰의 유효 기간 동안 시스템에 접근할 수 있다. 이는 접근할 때 인증받지 않아도 되는 이로운 효과가 있다. 접근된 각 애플리케이션은 보안 관리자의 서명을 확인하여 액세스 토큰을 인증한다. 서명은 보안 관리자의 개인 열쇠를 이용한 축약된 암호이다.

기술 보안 체제는 보안 체계의 일부분이다. 다른 부분은 협력 작업 자체의 설계(design)와 관계가 있다. 체제(framework)는 기업들로 하여금 다른 기업이 행할 수 있는 다양한 활동에 쉽게 접근할 수 있도록 해야 한다. GCW는 계급 조직에서 서로 다른 데이터 요소에 개별적인 접근을 허락하는 계급 조직적 허용 모델 (permissibility model)을 지원할 수 있어야 한다. 특히, 이는 사용자 지정(user-specific) 및 스포크 지정(spoke-specific) 판독, 기록, 취득(take), 가입 (subscribe) 허용성을 지원할 수 있어야 한다. 따라서, 기업은 세밀하게 누가 어떤 데이터를 판독할 수 있고, 누가 어떤 데이터를 기록할 수 있으며, 어떤 데이터를 취득할 수 있고, 어떤 데이터에 누가 기록 통지문(write-notification)에 가입(subscribe)할 수 있는지를 조율할 수 있다.

협력 체제 보안 전략의 세 번째 요소는 다양한 협력 작업 공간으로 데이터를 분산시킬 수 있는 능력이다. 특히, 협력 작업 공간은 내부 협력 작업 공간 및 외부 협력 작업 공간으로 나누어진다. 파트너와의 진정한 공유를 필요로 하는 데이터만이 외부 협력 작업 공간 내에 있고, 나머지는 내부 협력 작업 공간에 있다. 외부 협력 작업 공간은 단체(corporate) 방화벽의 외부 또는 엑스트라넷(extranet)이나 DMZ의 내부에 위치하도록 설계된다. 협력 체제 설계는, 가능하기는 하지만, 외부 협력 작업 공간을 단체 방화벽을 통하여 인트라넷(intranet)으로 접속할 필요가 없다.

한 실시예에서, 전역 협력 작업은 외부 및 내부 협력 작업 공간을 모두 사용할 수 있다. 지역 협력 작업은 내부 협력 작업 공간만을 사용할 수 있고, 따라서 파트너 기업에게는 전혀 보이지 않을 수도 있다. 전역 협력 작업에서조차, 관련 부분만이 외부 협력 작업 공간을 사용한다. 또한, 상술한 허용성(permissibility) 체제 때문에, 각 파트너 기업은 오직 자신의 데이터만을 볼(판독, 기록, 취득, 가입할) 수 있다.

도 8은 허브 대 스포크 및 허브 대 웹 경우의 보안 구성(configuration)의 한 실시예의 블록도이다. 나타낸 것처럼, 허브 기업(50)은 내부 GCW(52) 및 외부 GCW(54)와 연결되어 통신한다. 스포크 기업(56)과 웹 기업(58)은 웹 서버(60)를 통하여 외부 GCW(54)에 연결된다. 허브 기업(50)처럼 스포크 기업(56)은 내부 GCW(62)를 갖는다. 웹 서버(60) 및 외부 GCW(54)로 이루어진 엑스트라넷 (extranet)이 여과 라우터(filtering router)와 SSL 3.0의 HTTP를 통한 통신에 의하여 보호될 수 있는 반면에 기업(50, 56, 58)은 해당 방화벽에 의하여 보호될 수 있다.

도 9는 허브 대 허브인 경우의 보안 구성의 한 실시예의 블록도이다. 도시한 것처럼, 허브 기업(64, 66)은 TCP/IP 연결로 보호된 SSL 3.0을 통하여(across an SSL 3.0 protected TCP/IP connection) 통신할 수 있다. 통신은 개별적 (separate) 전역 메시지 브로커(global message broker, GMB)(68, 69)간에 이루어질 수 있다. 양 허브 기업(64, 66)은 도시한 것처럼 방화벽에 의하여 보호된다.

기업간 작업 흐름

복합 기업의 의사결정 지원의 한 가지 문제점은 폐쇄 루프(closed loop) 협력 작업이 없다는 것이다. 대신에, 데이터를 일관된 작업 흐름이 없이 한 기업으로부터 다음 기업으로 천천히 보낼 수 있다. 폐쇄 루프 협력 작업을 실현하기 위하여, 복합 기업의 작업 흐름을 생성하기 위한 지원이 필요하다. 본 GCM 및 GCD는 복잡한 복합 기업 작업 흐름을 구축, 배치, 감시 및 변경할 수 있다.

대체로 "작업 흐름"은 여러 태스크를 함께 달성하는 데이터 흐름으로 결합된 한 벌의 "동작(activities)"일 수 있다. 작업 흐름은 통상적으로 작업 흐름 엔진에서 실행된다. "분산된(distributed) 작업 흐름"은 여러 작업 흐름 엔진에서 수행되는 하나의 작업 흐름을 의미할 수 있다. 바꾸어 말하면, 작업 흐름의 서로 다른 부분이 서로 다른 엔진에서 실행된다. "노드(node)"란 분산된 작업 흐름의 서로 다른 작업 흐름 엔진이 구동하는 추상적인 개체(abstract entity)를 뜻할 수 있고, "노드 군(node group)"은 여러 특징에 따라 그룹화된 한 벌의 노드일 수 있다. "복합 기업 분산 작업 흐름(multi-enterprised distributed workflow)"은 노드가 기업인 분산된 작업 흐름일 수 있다.

작업 흐름의 매개 변수화(parameterization)는 기업 간의 협력 작업에 중요할 수 있다. "매개 변수형 작업 흐름(parametric workflow)"은 여러 변수들로 매개 변수화된 작업 흐름으로서, 정규 또는 분산된 작업 흐름일 수 있다. 서로 다른 매개 변수 값을 가지는 매개 변수형 작업 흐름에 대하여 인스턴스 생성하면 그 작업 흐름의 서로 다른 인스턴스가 생성된다. " 한 노드 군의 노드로 매개 변수화된 분산 작업 흐름(distributed workflow parameterized over nodes in a node group)"은 작업 흐름의 매개 변수들이 한 노드 군의 노드인 분산된 작업 흐름을 의미할 수 있다. 따라서 작업 흐름이 인스턴스 생성되는 경우, 작업 흐름이 노드 군의 특정 노드에 맞추어진다.

본 전역 협력 작업이 지원할 수 있는 작업 흐름에는 많은 중요한 특성이 있다. 이러한 작업 흐름은 철저하게 유형화될 수 있다. 철저한 유형화는 로버스트 (robust)하고 오류 없는 작업 흐름을 생성하는 데 필수적일 수 있다. 본질적으로, 철저한 유형화는 설계시에 메시지 유형을 확실하게 한다. 예를 들어, 작업 흐름을 자재 청구서(Bill of Materials)를 보내도록 설계하는 경우, 철저한 유형화를 통하여 자재 청구서 이외의 객체가 보내지는 것이 물리적으로 불가능하도록 할 수 있다. GCD에 의하여 설계되고 GCM에 의하여 실행된 작업 흐름의 경우 부정확한 유형(incorrect type)의 객체를 보내는 것조차 불가능할 수 있다. 이러한 능력은 로버스트하고, 오류 없는 작업 흐름을 생성할 때 중요하다.

철저한 유형화에도 불구하고, 예를 들어 생각건대, 나쁜 객체 유형(wrong object type)이 작업 흐름을 통과할 수 있는 두 가지 각본이 있다. 하나는 작업 흐름 설계자의 일부의 오류로 인한 것이고 또 하나는 작업 흐름을 손상하려는 누군가의 사악한 시도로 인한 것이다. 이들 각본 모두를 예방할 수 있다. 첫 번째는 설계의 오류가 이러한 각본에 이르는 것을 불가능하게 하는 것일 수 있다. 두 번째는 앞에 기재한 공공 열쇠 암호화 또는 다른 암호화 체계(encryption scheme)[통합 특성(integrity characteristic)]를 사용함으로써 데이터 흐름을 조작할 수 없게 하는 것일 수 있다.

다른 중요한 특성은 그룹으로 매개 변수화된 작업 흐름을 지원하는 것이다. 몇몇 복합 기업 작업 흐름은 많은 수의 기업을 포함한다. 이러한 경우, 각 파트너마다 개별화된 작업 흐름을 생성하는 것이 비현실적일 수 있다. 그 대신에 파트너 그룹으로 매개 변수화된 작업 흐름을 생성하는 것이 나을 수 있다. 예를 들어, 조달 부문에서, 두 그룹이 제1 공급자 및 제2 공급자가 될 수 있다. 제1 공급자 그룹은 한 유형의 작업 흐름을 가질 수 있고 제2 공급자 그룹은 다른 유형의 작업 흐름을 가질 수 있다. 실제 작업 흐름이 실행시 그룹의 구성원에 특정되어 생성될 수 있다는 점에서 그룹 기반(group-based) 작업 흐름은 매개 변수형일 수 있다.

복합 기업 환경에서, 한 기업은 예를 들어 잠재적으로 수 백 또는 수 천의 다른 기업들과 협력할 수 있다. 각 협력 작업 또는 복합 기업 작업 흐름은 잠재적으로(또한 통상적으로) 유일할 수 있다. 그러나, 한 기업의 파트너들에게 수 천 개의 특화된 작업 흐름을 설계하여 주는 것은 바람직하지도 가능하지도 않다. 다른 한편으로, 이러한 많은 작업 흐름은 기본적인 매개 변수형 작업 흐름에서 단순히 매개 변수를 변화시킨 것일 뿐이다. 예를 들어, 회사 A는 소매상, 도매상 (distributor), 직거래 상인(direct sales) 등과 (판매에 대하여) 협력할 수 있다. 따라서, 다양한 파트너들을 그룹화(group)하는 것이 의미있다. 그룹 짓기 (grouping)는 Walmart(월마트), Sears(시어스), Walmart와 Sears를 제외한 나머지 소매상들 (그룹), 1차 도매상 (그룹), 2차 도매상 (그룹)을 예로 들 수 있다. 예를 들어 1차 도매상 그룹의 모든 구성원들에 대한 작업 흐름은 기본적인 매개 변수형 분산 작업 흐름을 그 그룹의 특정 도매상으로 매개 변수화한 변형이다.

그룹으로 매개 변수화된 작업 흐름을 HETERCASTING(이질캐스팅) 작업 흐름 정의 기술(definition technique)이 지원할 수 있다. HETEROCASTING 정의 기술은 일반적으로 매개 변수화된 작업 흐름의 정의를 사용하여 매개 변수들의 차이에 기초한 이질적인 작업 흐름에 대하여 인스턴스 생성하는 것을 포함한다. 따라서, HETEROCASTING 정의 기술을 사용하면 비 매개 변수형 분산 작업 흐름을 (시각 설계 수단을 통하여) 노드 군의 노드로 쉽게 매개 변수화할 수 있다. 이러한 정의를 달성하는 데 사용되는 두 개의 주요한 작업 흐름 동작(activity)이 있을 수 있다. HETEROCAST 분할 동작과 HETEROCAST 결합 동작이 그것이다. HETERCAST 분할과 HETEROCAST 결합 간의 모든 동작은 이러한 동작에 대응하는 노드 군의 노드로 매개 변수화된다.

도 10은 그룹의 매개 변수화를 포함한 기업간 작업 흐름을 설계하는 한 실시예를 나타낸다. 나타낸 것처럼, 작업 흐름은 어떤 사건(event)을 기다리는 탐색(listening) 동작(70)으로 시작할 수 있다. 동작(70)은 병렬 동작(71)에 연결될 수 있고, 동작(71)은 하부 작업 흐름 동작(72) 및 이질캐스트 분할 동작(73)에 연결된다. 하부 작업 흐름은 스스로 작업 흐름 정의를 포함할 수 있다. HETEROCASTING에 관하여, 이질 캐스트 분할 동작(73) 후의 작업 흐름이 매개 변수화된다. 따라서 도 10의 예에서 동작(74)은 매개 변수화된 동작이다. 동작(74) 다음에 이질캐스트 결합 동작(75)은 동작(74)으로부터 흐름을 이어 받는다. 하부 작업 흐름 동작(72) 및 이질캐스트 결합 동작(75)은 통합 사건(integrated event) 동작(77)(예를 들면 멀티캐스팅)에 연결된 동기식 또는 비동기식 결합 동작(76)에 연결된다. 도 10 같은 작업 흐름은 GCD를 이용하여 설계할 수 있고, 기업간 의사 결정 지원을 위한 작업 흐름을 완벽히 표현할 수 있게 한다. 본 GCM을 통하여 이러한 작업 흐름을 인스턴스 생성할 수 있고, 실행할 수 있다.

도 11은 작업 흐름 설계를 수정한 변형 형태를 관리하는 한 실시예를 나타낸다. 나타낸 것처럼, 초기의 작업 흐름 설계는 병렬 동작 분할(71)에 연결된 사건(70)을 가질 수 있다. 분할 동작(71)과 결합 동작(76) 사이에는 예를 들면 두 개의 동작(78)이 있을 수 있다. 일단 설계된 이러한 작업 흐름은 GCM을 이용하여 인스턴스 생성할 수 있고 실행할 수 있다. 작업 흐름을 변경할 필요가 있는 경우에 GCD는 변경의 어려움을 상당히 경감시킨다. 예를 들면, 새 동작(79)을 분할 동작(71)과 결합 동작(76)의 사이에 추가할 수 있다. 그 후, 작업 흐름을 중앙 집중식으로 인스턴스 재생성하고 실행할 수 있다.

특히, HETEROCAST 기술을 사용하여 한 노드 군의 노드로 매개 변수화한 분산 작업 흐름을 만들 수 있다. 이는 개별 그룹 구성원에 대하여 개별적인 작업 흐름을 설계하도록 하여 높은 생산성을 얻게 할 수 있다. 또한, 이러한 기술은 수 백 또는 수 천의 파트너가 실행할 수 있는 복잡한 기업간 작업 흐름의 설계와 원형을 신속하게 만들 수 있게 한다. 이 기술은 동일한 메시지가 다양한 노드(파트너)에 전송되는 종래의 "멀티캐스팅(multicasting)"과 구별되어야 한다. 본질적으로, 멀티캐스팅은 여러 개의 노드에 걸쳐 동일하게 실행되는 단일한 작업 흐름을 설계하도록 한다. 작업 흐름이 실행되는 노드를 기초로 서로 다르게 실행되는 HETEROCASTING 기술과 이점이 다르다.

세 번째 중요한 특성은 역할 기반(role-based) 작업 흐름을 지원하는 것이다. 역할 기반 작업 흐름은 일반 역할(generic role)을 이용하여 작업 흐름이 지정되도록 한다. 이러한 기능은 다양한 각본 상에서 인스턴스 생성될 수 있는 포괄적이거나(generic) 템플릿(templated) 작업 흐름을 생성하게 한다. 예를 들어, 역할의 유형으로는 파트너 역할, 스포크 역할, 스포크 그룹 역할, 웹 역할, 웹 그룹 역할, 사용자 역할 등이 있다. 역할의 예를 들면, 파트너 역할은 파트너가 수행하는 서로 다른 역할을 의미한다. 따라서, 조달의 경우, 파트너 역할 중 하나는 1차 공급자 및 2차 공급자이다.

역할 기반 작업 흐름은 작업 흐름의 설계와 실행의 3개의 다른 단계의 개념을 이끌어 낸다. 설계 단계는 역할 기반 작업 흐름을 정의하는 단계이다. 인스턴스 생성 단계는 역할을 인스턴스로 사상하는(map) 단계이다. 예를 들어, 1차 공급자는 제1 회사로 사상될 수 있고, PO 승인자(PO_approver)는 존 도(John Doe)로 사상될 수 있다. 세째로, 실행 시간 단계는 인스턴스 생성된 작업 흐름을 실행하는 단계가 될 수 있다.

보다 중요한 특성은 사용자 지향(user-oriented) 작업 흐름과 자동화된 작업 흐름을 통합하는 것이다. 작업 흐름은 흔히 두 부류로 기술될 수 있다. 자동화 시스템 대 시스템(automated system-to-system) 작업 흐름이 있고, 사용자 인터페이스 작업 흐름이 있다. 완전 자동화 작업 흐름과 완전 사용자 주도형(user driven)의 작업 흐름이 있는 반면에, 대부분의 작업 흐름은 사용자 인터페이스 요소뿐만 아니라 자동화 요소를 지닌다. 본 GCM 및 GCD는 작업 흐름 유형간에 이러한 인위적인 구분을 만들 필요가 없다. 따라서, 작업 흐름을 부분적으로 자동화할 수 있고, 다른 부분의 사용자들과 상호 작용할 수 있다. 자동화 부분 및 사용자 부분 모두 복합 기업에 적용될 수 있다.

외부 세계와의 통합

도 12는 작업 흐름을 외부 세계와 통합한 실시예를 나타낸다. 앞에 기술한 것처럼, 복잡한 기업간 및 기업 내 작업 흐름을 생성할 수 있다. 이러한 작업 흐름은 다양한 형태로 엮여 있는 동작들로 이루어질 수 있다. 작업 흐름의 서로 다른 동작이 할 수 있는 것에는 제한이 없지만, 이러한 동작의 주요 태스크 중의 하나는 외부 세계와 통합하는 것이다. 도 12는 통합을 위한 성분 기반 접근법을 이용하여 작업 흐름을 외부 세계와 통합할 수 있는 방법을 나타낸다. 성분(component)은 접근기(accessor)(80), 변형기(transformer)(82), 전송 객체(84), 어댑터 및 흐름 (adaptors and flows)(86)을 포함할 수 있다.

GCM은 성분 기반 통합 모델을 지원할 수 있다. 성분 기반 통합 모델을 이용하면 통합을 구축할 때 유연성을 발휘할 수 있다. 성분의 두 가지 유형으로는 원시 성분과 복합(compound) 성분이 있을 수 있다. 원시 성분은 접근기(80), 변형기 (82) 및 전송 객체(84)를 포함할 수 있다. 복합 성분은 어댑터 및 흐름(86)을 포함한다. 복합 성분들은 원시 성분으로 이루어진다. 이러한 체계에서, 접근기(80)를 SCP(supply chain planner, 공급망 설계자), SAP, 관계형 데이터 베이스, 웹 서버, 전자 우편, 메시지 버스 등의 외부 소스에 접근하는 데 사용한다. 접근기(80)는 데이터의 소스와 수신지를 판독, 기록 또는 청취하는 데 사용할 수 있다. 변형기(82)는 데이터를 한 형태에서 다른 형태로 변환하는 데 사용할 수 있다. 전송 객체(84)는 동작에서 동작으로 또는 기업에서 기업으로 건네질 수 있는 객체이다. 전송 객체(84)는 선택적으로 EDI, XML, CORBA 구조 등으로 변환할 수 있다. 접근기(80)와 변형기(82)는 서로 엮어 흐름을 이룰 수 있다. 전체 흐름은 도 13에 나타난 것처럼 단일 동작으로 실행될 수 있다.

도 13은 단일 동작(92)으로 실행되는 데이터 흐름의 한 실시예이다. 나타낸 것처럼, 데이터 소스(90)는 접근기 성분(94)에 접근하여 데이터를 공급할 수 있다. 그리고 접근기 성분(94)은 변형기 성분(96, 98)을 통하여 데이터를 전달할 수 있고, 이러한 변형기 성분(96, 98)은 제2 접근기 성분(100)에 데이터를 공급할 수 있다. 데이터는 데이터 수신지(102)에 저장될 수 있다.

도 14는 여러 동작(104, 106)으로 분할되는 데이터 흐름의 한 실시예를 나타낸다. 나타낸 것처럼, 도 14의 흐름은 변형기 성분(96, 98)이 개별 동작(104, 106) 내에 있고, 전송 객체를 통하여 통신한다는 점에서 도 13의 흐름과 다르다. 복합 기업 데이터 흐름은 도 13의 모델보다는 도 14의 모델에 기초할 수 있다.

변형에 관하여, 한 실시예에서 I2-CDM 기반 변형 및 직접 변형의 두 기본 변형 유형을 지원할 수 있다. I2-CDM 기반 변형은 I2 TECHNOLOGIES사의 COMMON DATA MODEL(CDM)에 기초한다. CDM은 관계형 및 객체형 양자에 사용할 수 있는 추상적인 스키마(abstract schema)이다.

도 15는 I2-CDM 기반 변형 모델의 한 실시예의 블록도이다. 나타낸 것처럼, 변형기와 접근기는 애플리케이션 데이터를 CDM 데이터 객체(110)로 변형하거나 그 역으로 변형하도록 연결될 수 있다. 예를 들면, SCP 접근기는 SCP 데이터(114)로부터 SCP 객체(112)를 생성할 수 있다. 그 후, SCP-CDM 변형기는 SCP 객체(112)를 CDM 객체(110)로 변형할 수 있다. 이와 유사하게, SAP 접근기가 SAP 데이터(118)로부터 SAP 객체(116)를 생성할 수 있다. SAP-CDM 변형기는 SAP 객체(116)를 CDM 객체(110)로 변형할 수 있다. 다른 접근기와 변형기처럼 SAP 접근기와 변형기는 표준 SAP-CDM 어댑터(120)로 결합될 수 있고, 이러한 어댑터를 다른 성분의 CDM 기반 변형에 사용할 수 있다. 다른 예처럼, BAAN 접근기는 BAAN 데이터(124)로부터 BAAN 객체(122)를 생성할 수 있다. BAAN-CDM 변형기는 BAAN 객체(122)를 CDM 객체(110)로 변형할 수 있다. 이러한 변형은 다른 방향으로도 가능하다.

도 16은 직접 변형의 한 실시예이다. 직접 변형기에서, 객체는 중간 형식을 거치지 않고 한 형식에서 다른 형식으로 변형된다. 예를 들어, 도 16에 나타난 것처럼, SCP(supply chain planner, 공급망 설계자) 접근기는 데이터(130)에 접근하여 SCP 객체(132)를 생성할 수 있다. SCP 객체(132)를 바로 FP(factory planner, 공장 설계자) 객체(134)로 변형할 수 있다. FP 객체(134)는 FP 접근기를 통하여 FP 데이터(136)가 될 수 있다. 이러한 데이터 흐름은 또한 다른 방향으로도 실행된다.

이러한 과정에서, 관계형 (테이블), 일반(generic) 객체(트리, 그래프, 행렬 등) 및 지정(specific) 객체[자재 청구서(Bill of Material), 설계 등] 단계를 비롯하여 접근 및 변형이 일어나는 다양한 단계의 세분성(granularity)이 있다. 접근은 한 단계(말하자면 테이블)에만 사용할 수 있지만, 변형은 다른 단계(말하자면 일반 객체)에 더 적합할 경우가 종종 있다. 예를 들면, 계층 군집(hierarchial aggregation)(변형의 한 형태)은 종종 트리 객체에 적합하다. 그러나, 데이터는 테이블형으로만 접근할 수 있다. 이러한 경우 예를 들면 데이터는 테이블형 단계로 접근되고, 트리로 변형되어, 이에 적용되는 계층 군집만을 가져야 한다.

도 17은 서로 다른 접근과 변형 단계의 한 실시예이다. 나타낸 것처럼, 접근과 변형은 3개의 단계를 가질 수 있다. 제1 단계(140)는 테이블 접근과 변형을 포함할 수 있다. 제2 단계(142)는 일반 객체(트리, 그래프 등) 접근과 변형을 포함할 수 있고, 제3 단계는 지정 객체[자재의 구축(build-of-materials), 계획 등] 접근과 변형을 포함할 수 있다. 애플리케이션 형식간의 변형뿐만 아니라, 나타낸 것처럼 세 단계간의 변형이 있을 수 있다.

협력 작업의 배치

복합 기업 협력 시스템에서 하나의 중요한 인자는 협력 작업을 배치할 때의 편리함이다. 앞의 언급처럼, 본 GCM은 네 가지의 서로 다른 범주의 파트너 관계를 지원할 수 있다. 네 가지 다른 종류의 파트너 관계는 허브 대 웹, 허브 대 스포크, 허브 대 허브 및 허브 대 VAN-EDI이다. 이 네 가지 중에서, 허브 대 웹은 종래의 웹 애플리케이션의 모든 배치 특성을 갖는다. 허브 대 VAN-EDI는 현존하는 VAN-EDI 기반 구조를 이용할 수 있는 한도까지 배치할 수 있다. 허브 대 웹 관계는 상당히 배치적이지만, 그 관계의 웹쪽에 인간을 필요로 하는 문제점이 있다. 바꾸어 말하면, 이는 시스템 대 시스템 협력 작업에 적합하지 않을 수 있다.

허브 대 스포크 솔루션(solution)은 시스템 대 시스템 협력 환경에서 최대의 배치성(deployability)을 제공할 수 있다. 허브 대 스포크 영역에서, 스포크 엔진은 웹 브라우저(web browser)와 유사하고, 협력 작업의 스포크 부분은 웹 페이지 또는 애플릿(applet)과 유사하다. 웹 페이지 또는 애플릿과 유사하게, 협력 작업의 스포크 부분이 중앙 집중식으로 설계되고 원격 스포크 엔진에 배치될 수 있다. 웹 페이지 또는 애플릿과 달리, 여전히 원격으로 실행될 필요가 있는 통합 (integration)일 수 있다. 이러한 원격 통합은 어쩔 수 없는 것이지만 협력 작업의 스포크 부분에 의하여 제한되고 정확하게 정의할 수 있다.

배치의 다른 특징은 변형(versioning)을 처리하는 것이다. 일단 설계 및 배치된 협력 작업은 시간이 진행됨에 따라 (많은 다른 방법으로) 변형될 필요가 있는 것처럼 보인다. 협력 작업의 뒤따른 변형은 초기 변형처럼 쉽게 배치되는 것이 중요할 수 있다. 본 GCM은 변형 및 중앙 집중식 협력 작업의 재배치를 완벽하게 지원할 수 있다. 또한, 협력 작업의 서로 다른 변형을 서로 충돌시키지 않고 동시에 실행할 수 있다. 이것은 현존하는 변형을 단계적으로 제거하면서 다른 변형을 단계적으로 도입할 수 있게 한다.

본 GCM 배치의 다른 요소는 현존하는 기반 구조를 이용하는 것이다. 예를 들면, 이러한 요소는 현존하는 웹 프로토콜간의 허브 대 스포크 관계를 지원시 명백하게 나타난다. 현존하는 웹 프로토콜간의 허브 대 스포크 관계를 지원하는 것은 현존하는 웹 기반구조의 수정이나 재구성(reconfiguration)을 요하지 않기 때문에 배치를 신속하게 하는 데 중요할 수 있다. 이러한 점에서 많은 시간의 절약은 설계되어 이미 자리잡은 방화벽 및 보안 기반 구조를 주의깊게 수정할 필요가 없는 데서 비롯된다.

다 대 다 협력 지원

본 허브 대 스포크 구조는 용이한 취급 및 배치를 제공한다. 그러나, 실제로 기업은 여전히 다른 기업들과 역시 협력하고 있는 많은 기업과 협력하고 있다. 따라서, 기업은 종종 협력 웹 또는 그래프를 형성한다. 언제라도 스포크 엔진을 허브 엔진으로 바꿀 수 있는 기능이 있어 이것 역시 지원 가능하다. 이러한 대체 능력은 다 대 다 협력 웹이 한꺼번에 모두가 아니라 유기적으로 성장하게 한다.

도 18은 협력 작업에서 스포크 엔진을 허브 엔진으로 바꾸는 한 실시예이다. 나타낸 것처럼, 기업(제1 개체)(E1)은 자신에게 허브 엔진(150)을, 모든 파트너 사이트(site)에 스포크 엔진(152)을 배치할 수 있다. 특히, 스포크 엔진(154)은 한 파트너 사이트(제2 개체)(E2)에 있을 수 있다. 파트너 사이트(제2 개체)(E2)가 자신의 협력 작업을 설계하거나 제어하기를 원하는 경우, 스포크 엔진(154)을 허브 엔진(156)으로 바꿀 수 있다. 제1 개체(E1) 쪽에서 보면, 제1 개체(E1)의 협력 작업에서 제2 개체(E2)는 여전히 스포크일 수 있다. 그러나 이러한 스포크는 스포크 엔진(158)과의 자신의 협력 작업을 제어할 수 있는 허브 엔진(156)에서 실행한다. 또한, 스포크 엔진(160, 162)은 제3 개체(E3)를 대리하여 두 허브 엔진(150, 156)과 상호 작용하는 제3 개체(E3)와 관련이 있을 수 있다.

체제(framework)의 확장 가능성

본 체제의 중요한 특성은 확장 가능성이다. 체제는 확장 가능성이 없으면 직면한 새로운 상황과 도전을 처리할 수 없다. 이러한 확장 가능성에는 많은 서로 다른 차원이 있을 수 있다. 예를 들면, 확장 가능성의 하나의 주요한 영역은 의미 객체 표준의 영역에 있다. 지원되는 표준이 특별한 문제점을 해결하지 못하는 경우, 체제는 새 의미 표준으로 커질 수 있다. 또한 체제는 전용(proprietary) 의미 표준의 구축을 가능하게 한다. 더욱이, 체제를 새로운 접근기, 변형기, 어댑터 등을 추가함으로써 확장할 수 있다. 표준 성분 라이브러리는 일반적으로 및 최종 사용자(end-user)에 의하여 확장될 수 있다.

객체 작업 공간

도 19는 컴퓨터 시스템(205) 내의 컴퓨터 작업 공간(200)의 한 실시예를 나타낸 블록도이다. 컴퓨터 작업 공간(200)은 형용성 체제(220) 및 사건 관리자(event manager)(230)와 통신하는 복수의 메모리 슬롯(210)을 포함한다. 허용성 체제 관리자(permissibility framework manager)와 사건 관리자(230)는 컴퓨터 작업 공간(200) 내에 상주할 수 있거나 상주하지 않을 수 있다. 네트워크 노드(240)는 네트워크(250)를 통해 컴퓨터 작업 공간(200)에 접근한다. 일반적으로 형용성 체제(220)는 네트워크 노드(240)가 컴퓨터 작업 공간(200) 내의 메모리 슬롯(210)에 접근하는 것을 제어한다. 사건 관리자(230)는 메모리 슬롯(210)에 저장된 데이터 또는 객체와 관련된 사건이나 조건에 응답하여 네트워크 클라이언트(240)로 메시지를 생성한다.

네트워크(250)는 임의 개수의 허브(hubs), 라우터(routers), 브리지(bridges), 게이트웨이(gateways), 교환기(switches) 또는 다른 적당한 통신 장치의 조합이나 이들의 조합 및 네트워크 노드(240) 사이에 데이터를 전송하는 관련 소프트웨어를 포함한다. 한 실시예에서 네트워크(250)는 독립적으로 구현되거나 광역망(Wide Area Network, WAN), 이더넷(Ethernet) 네트워크, 토큰 링(token ring) 네트워크 또는 광섬유 분산 데이터 인터페이스(Fiber Distrubuted Data Interface, FDDI) 네트워크와 같은 근거리망(Local Area Network, LAN)과 연결되어 구현되는 네트워크를 포함한다. 네트워크(250)는 인터넷 프로토콜(Internet Protocol, IP)과 같은 고레벨의 비접속 프로토콜, 프레임 릴레이(frame relay)와 같은 고레벨 접속 지향 프로토콜 또는 다른 적당한 네트워킹 프로토콜을 지원한다. 네트워크(250)는 하나 이상의 기업들 중 또는 하나 이상의 기업들 사이에 발생하는 동작을 포함하는 작업 흐름을 구현하기 위해 네트워크(250)를 복합 기업 협력에 사용할 수 있다. 복합 기업 협력에서 네트워크(250)의 각 네트워크 노드(240)는 다른 기업과 관련되어 각 기업들과의 통신을 가능하게 하고, 기업들의 동작 및 작업 흐름의 성능이 대등해질 수 있도록(coordinated) 한다.

네트워크 노드(240)는 네트워크(250)에 연결된 임의의 단말기(terminal), 서버(sever), 클라이언트(client), 허브(hub), 스포크(spoke) 또는 다른 장치일 수 있다. 각 네트워크 노드(240)는 특정 기업과 관련된다. 네트워크(240)는 특정 작업 흐름, 동작 또는 다른 프로세스에 관여할 수 있거나 관여하지 않을 수 있다. 네트워크 노드(240)는 작업 흐름 또는 협력 작업의 일부로서, 또는 작업 흐름이나 협력 작업과 관련되지 않는 다른 동작이나 프로세스의 일부로서 작업 공간(200)에 접근할 수 있다.

각 메모리 슬롯(210)은 데이터와 객체를 저장할 수 있다. 본 실시예에서 사용된 바와 같이, 각각은 적어도 식별 항목(identified item)의 각 서브셋(subset)을 의미한다. 객체는 Java 객체, C++ 객체, CORBA 객체 또는 정보와 동작(behavior) 모두를 저장할 수 있는 다른 구조일 수 있다. 메모리 슬롯(210)은 메모리 슬롯 내에서 대기 행렬화되거나 임의로 접근되는 임의 메모리 구조일 수 있으며, 데이터 또는 객체를 보유(holding)할 수 있다. 메모리 슬롯(210)은 예를 들면 임의의 데이터 구조, 해시 테이블(hashtable) 또는 메모리 어레이를 포함할 수 있다. 메모리 슬롯(210)은 예를 들면 메모리 슬롯(21) 내에서 대기 행렬화된(enquequd) 복수의 객체를 포함할 수 있거나 하나의 객체를 포함할 수 있다. 메모리 슬롯(210)은 디스크 또는 다른 기록 매체에 저장되거나 임의의 프로세스 또는 동작이 컴퓨터 시스템(205)에 의해 처리되는 동안에 메모리 내에 유지될 수 있다. 메모리 내에 유지되는 메모리 슬롯(210)은 RAM(Random Acess Memory, 임의 접근 메모리)에 저장될 수 있으며, 예를 들면 메모리 슬롯(210)의 내용이 디스크 또는 주변 구성요소에 저장될 수 있는 메모리 슬롯(210)을 거쳐 접근될 때의 속도를 향상시킬 수 있다. 디스크 또는 다른 기록 매체에 저장되는 메모리 슬롯(210)은 메모리 내에 저장되는 메모리 슬롯(210)보다 더 느린 속도로 접근 가능하지만 영구(persisten) 데이터나 객체를 비휘발성으로 저장할 수 있도록 한다. 메모리 슬롯(210)은 프로그래머, 사용자 또는 다른 적당한 매커니즘에 의해 정의된 조직적인 계층 구조(organization hierarchy)로 배열될 수 있다. 이러한 계층화는 도 20을 참조하여 이하에 설명하는 바와 같이 메모리 슬롯(210)의 범주화와 참조를 용이하게 한다.

허용성 체제 관리자(220)는 메모리 슬롯(210)에 대한 접근을 유지하고 제어한다. 허용성 체제 관리자(220)는 메모리 슬롯(210)에 대한 접근 권리(access right)를 유지할 수 있고, 유지된 접근 권리에 기초하여 메모리 슬롯(210)에 대한 접근을 제어할 수 있는 하드웨어 및 소프트웨어의 임의 조합을 포함할 수 있다. 한 실시예에서, 접근 권리는 각 메모리 슬롯(210)의 내용 판독, 각 메모리 슬롯(210)으로의 내용 기록, 각 메모리 슬롯(210)의 임의 내용 제거 및 하나 이상의 특정 메모리 슬롯(210)에 대한 사건 통지의 가입(subscribe)과 가입을 탈퇴하는(unsubscribe) 노드의 권리를 포함한다.

사건 관리자(230)는 메모리 슬롯(210) 내의 특정 사건에 응답하여 노드(240)로 메시지를 생성한다. 사건 관리자(230)는 사건을 발생시킬 수 있고, 특정 네트워크 노드(240)나 컴퓨터 시스템(205)의 다른 적당한 구성요소로의 이러한 사건의 경로 지정(routing)을 개시할 수 있는 하드웨어 및 소프트웨어의 임의 조합을 포함할 수 있다. 허용성 체제(220)에 의해 결정된 바와 같이, 특정 메모리 슬롯(210)에 대한 사건 통지에 가입하기 위한 접근 권리를 가지고, 특정 메모리 슬롯(210)에 대해 그러한 가입을 실행하는 네트워크 노드(240)는 통지를 필요로 하는 특정 메모리 슬롯(210)에 관련된 변경이 발생할 때마다 사건 관리자(230)가 생성한 사건에 의해 통지 받는다.

예를 들면, 네트워크 노드(240) 중 하나는 허용성 프레임 워크 관리자(220)에 의해 검증될 때 특정 메모리 슬롯(210)에 대한 통지에 가입하기 위한 접근 권리를 가질 수 있으며, 네트워크 노드(240) 중 하나가 특정 메모리 슬롯(210)에 쓸 때마다 이 특정 메모리 슬롯(210)에 대해 통지하도록 가입할 수 있다. 네트워크 노드(240)가 그 특정 슬롯에 대한 통지로부터 탈퇴할 때까지 네트워크 노드(240) 중 하나가 그 특정 메모리 슬롯(210)에 쓸 때마다 메시지 관리자(230)는 메시지를 생성시키고, 쓰여진 그 특정 메모리 슬롯(210)을 지적한 네트워크 노드(240)로의 메시지의 경로 지정을 개시한다.

한 실시예에서, 특정 메모리 슬롯(210)에 대한 사건 통지를 가입 및 탈퇴하기 위한 접근 권리는 사건의 분류에 따라 변화할 수 있다. 예를 들면 특정 네트워크 노드(240)는 특정 메모리 슬롯(210)이 제거될 때마다 통지 받지만 동일한 메모리 슬롯(210)이 쓰여질 때는 통지 받지 않는 가입 권리를 가질 수 있거나, 특정 네트워크(240)는 이 두 가지 경우 모두를 통지 받는 가입 권리, 즉 그러한 메모리 슬롯(210)에서 데이터가 제거되거나 쓰여지는 것에 응답하여 통지를 발생시키는 가입 권리를 가질 수 있다. 허용성 체제(220)가 승인한 접근 권리와 사건 관리자(230)로부터의 메시지에 대한 가입은 또한 임의의 적당한 조합으로 그룹지워 질 수 있다. 예를 들면, 사건 통지는 개별 메모리 슬롯(210), 모든 메모리 슬롯들(210), 또는 지정된 기준들(criteria)에 따라 선택된 메모리 슬롯(210)의 서브셋에 대한 가입을 받을 수 있다. 또 허용성 체제(220)는 모든 메모리 슬롯들(210) 또는 메모리 슬롯의 임의 서브셋에 대한 접근 권리를 승인할 수 있다.

도 20은 도 19에 나타낸 작업 공간의 한 실시예를 나타낸 것이다. 작업 공간(300)은 계층적 체제(hierarchcal framework)로 배열된 메모리 슬롯(310)에 데이터와 객체를 저장하기 위한 작업 공간이다. 체제 내의 특정 메모리 슬롯(310)에 대한 계층 구조(hierarchy)와 배치의 정확한 특성(nature)은 관리자, 다른 사용자 또는 다른 적당한 메커니즘에 의해 정의 가능하다.

일반적으로 작업 공간(300)은 개별 메모리 슬롯(310)과 그룹(320)으로 더 분리되는 섹션(sections)(305)으로 조직된다. 그룹(320)은 메모리 슬롯(310) 및/또는 더 나눠지는 서브 그룹을 차례로 포함할 수 있다. 도 20에서, 적용 가능하다면 메모리 슬롯(310)은 섹션 번호, 그룹 번호를 부여한 후, 적용 가능한 섹션(305) 또는 그룹(320) 내에 s 및 식별 번호를 부여한다. 예를 들면 "섹션2.그룹1.s2"로 명명되어 식별되는 메모리 슬롯(310)은 작업공간의 섹션2의 그룹1 내의 "s2"라는 슬롯을 의미한다. 상기 슬롯은 연속적으로 존재할 수 있다. 다른 계층 구조나 조직 스킴(organizational scheme)은 본 실시예에서 설명하는 계층 구조를 대신할 수 있다. 설명한 바와 같은 계층 구조는 메모리 슬롯(310)의 용이한 범주화와 그룹화를 허용한다. 이러한 범주화는 접근 권리를 유지하기 위한 목적으로 메모리 슬롯(310)의 범주화를 용이하게 하는 데 사용될 수 있다. 예를 들면, 도 19의 네트워크 노드(240)는 단지 메모리 슬롯(310)의 특정 계층(tier)에 대한 특정 접근 권리만을 승인 받을 수 있다. 이러한 계층(tier)은 그룹 레벨에서 모든 메모리 슬롯(310), 예를 들면 도 19에서 섹션1.s1 및 섹션2.s1로 나타낸 메모리 슬롯(310)일 수 있다. 접근 권리는 또한 특정 섹션(305), 그룹(320), 서브 그룹 도는 이들의 조합에 대해 승인될 수 있다.

도 21은 네트워크(400)를 통해 객체 작업 공간(400)을 접근하기 위하여 복수의 네트워크 노드(440) 중 하나에서 개시된 적어도 하나의 에이전트(460)를 이용하는 컴퓨터 시스템(405)의 블록도이다. 네트워크 노드(440)는 네트워크(450)를 통해 작업 공간(400)에 연결된다. 일반적으로 컴퓨터 시스템(405)에서, 에이전트(460)는 네트워크(450)를 통해 이동하기 위하여, 작업 공간(400)을 접근하기 위하여 그리고 프로그램된 명령에 따라 작업 공간(400) 내의 작업(operation) 또는 태스크 수행하기 위하여 적어도 하나의 네트워크 노드(440)에서 개시된다.

작업 공간(400)은 메모리 슬롯(410)을 포함하고, 도 19 및 도 20을 참조하여 설명한 바와 같이 작업 공간(200, 300)의 임의 또는 모든 특성이 구체화된다. 네트워크 노드(440)는 특정 기업과 관련되고, 도 19의 네트워크 노드(240)를 참조하여 설명한 바와 같이 구체화된다. 네트워크(450)는 특정 협력에 포함되는 네트워크 노드와 연결된 네트워크이고, 도 19의 네트워크(250)를 참조하여 설명한 바와 같이 구체화된다.

에이전트(460)는 임의 객체 지향 에이전트 또는 자율(automomy) 특성을 갖는 다른 항목(item)일 수 있다. 여기서 자율은 하나 이상의 목표를 가지고 프로그램되며, 근원지 프로그램과의 접속을 상실한 네트워크 내로, 그리고 다른 플랫폼 상으로 이동할 때조차도 근원지 프로그램 또는 애플리케이션(application)과 관계 없이 그러한 목표를 만족시키기 위하여 시도하는 능력으로 정의된다. 에이전트(460)는 협력 동작 달성을 목적으로 프로그램된다. 협력 동작은 작업 흐름의 실행에 포함된 동작이거나 작업 흐름의 외부에서 수행되는 동작일 수 있으며, 협력 내의 기업 또는 설비는 관리(administration), 최적화 또는 작업 공간(400) 내의 데이터나 객체와 관련된 태스크 실행을 수행하기 위하여 개시될 수 있다. 협력 동작은 또한 작업 공간(400)내의 데이터 수집 또는 데이터나 객체 처리를 위하여 의도된 질의(queries)일 수 있다. 관리 에이전트(administrative agent)(460)는 또한 근원지 네트워크 노드(440)의 가입 프로필(subscription profile)을 변경하기 위하여 개시되어, 그 네트워크 노드(440)에 의해 수신된 사건 통지의 유형을 변경한다. 특정 에이전트(460)는 허용성 체제를 변경시키는 권리를 갖는 특수 네트워크 노드(440)에서 시작될 수 있으며, 그리하여 에이전트(460)로 하여금 특정된 메모리 슬롯(410)에 대한 하나 이상의 네트워크 노드(440)의 접근 권리를 변경할 수 있도록 한다. 최적화 에이전트(460)는 작업 흐름 결정 또는 실행 중의 그 객체들의 성능을 향상시키기 위하여 작업 공간(400)에 저장된 객체의 특성 또는 동작(behavior)을 변경하도록 개시될 수 있다. 실행 에이전트(460)는 작업 공간(400) 내의 객체를 이용하여 일련의 태스크 또는 계산을 수행할 수 있으며, 그러한 태스크 또는 계산의 결과를 그것이 개시된 네트워크 노드(440)로 돌려준다. 질의 에이전트(460)는 작업 공간(400)에서 복잡한 질의를 수행할 수 있으며, 그러한 질의 결과를 그것이 개시된 네트워크(440)로 돌려준다. 마찬가지로 에이전트(460)는 작업 공간(400) 내부에서 동작할 수 있으며, 결과를 다른 에이전트(460) 또는 네트워크 노드(440)로 돌려준다.

작업 공간(400)은 작업 공간(200, 300)처럼 에이전트(460)와 대화하거나 에이전트(460)에 응답할 수 있는 허용성 체제 및/또는 사건 관리자를 가질 수 있다. 예를 들면, 에이전트(460)는 도 19에서 설명한 것처럼, 어느 에이전트(460)가 대화를 원하는 지에 대한 객체 또는 데이터를 포함하는 특정 메모리 슬롯(410)에 대한 접근 권리를 갖는 에이전트(460)의 근원지 네트워크 노드(440)를 검증하기 위하여 허용성 체제와 대화할 필요가 있을 수 있다. 유사하게 사건 관리자는 도 19를 참조하여 설명한 바와 같이, 가입한 네트워크 노드(440)로 사건 통지 메시지를 전송함으로써 특정 메모리 슬롯(460)내에서 에이전트(460)에 의해 수행되는 작업에 응답할 수 있다

도 22는 작업 공간을 접근하기 위하여 도 21의 에이전트를 사용하는 방법의 한 실시예를 나타낸 흐름도이다. 단계 510에서 네트워크의 노드는 원격 작업 공간에서 적어도 하나의 태스크를 실행하기 위하여 프로그램된 에이전트를 개시한다. 단계 520에서 에이전트는 네트워크를 통해 작업 공간으로 전송되어 네트워크의 제2 노드와 결합된다. 작업 공간은 각각 적어도 하나의 객체, 허용성 체제 및 사건 관리자를 저장할 수 있는 복수의 메모리 슬롯을 갖는다. 단계 530에서, 에이전트는 접근을 원하는 특정 메모리 슬롯 내의 허용성 체제를 지적한다. 단계 540에서, 허용성 체제는 지적된 메모리 슬롯에 대한 접근 권리를 갖는 에이전트가 개시된 네트워크의 노드를 검증한다. 단계 550에서, 에이전트는 도 21을 참조하여 설명한 바와 같은 하나 이상의 작업을 수행한다. 단계 560에서 에이전트는 만약 있다면 작업 결과를 돌려준다. 단계 570에서 사건 관리자는 에이전트가 수행한 작업과 에이전트가 접근하는 메모리 슬롯에 대응하는 사건 통지를 가입한 네트워크의 노드에 사건을 전송한다.

본 발명에 대하여 상세하게 기술하였지만, 첨부한 청구범위가 정하는 본 발명의 사상 및 범위를 벗어나지 않고 다양한 변경, 치환 및 개조가 이루어질 수 있다.

Claims

복합 기업 협력에서 원격으로 데이터에 접근하기 위한 컴퓨터 시스템에 있어서,

제1 기업과 관련된 네트워크 노드―여기서 네트워크 노드는 네트워크를 통해 작업 공간과 통신하며, 작업 공간은 제2 기업과 관련되고 복수의 저장된 객체를 가짐―; 및

상기 네트워크 노드에서 생성되는 에이전트―여기서 에이전트는 네트워크를 통해 작업 공간에 접근할 수 있으며, 에이전트는 협력 동작을 수행하기 위하여 작업 공간 내의 복수의 저장된 객체 중 적어도 하나를 처리할 수 있음―

를 포함하는 컴퓨터 시스템.
제1항에 있어서,

상기 에이전트가 관리 에이전트(administrative agent)인 컴퓨터 시스템.
제1항에 있어서,

상기 작업 공간이 계층 구조(hierarchy)로 조직되며, 상기 에이전트가 그 계층 구조의 특성을 변경할 수 있는 관리 에이전트인 컴퓨터 시스템.
제1항에 있어서,

상기 에이전트가 실행 에이전트(execution agent)인 컴퓨터 시스템.
제1항에 있어서,

상기 에이전트가 최적화 에이전트(optimization)인 컴퓨터 시스템.
제1항에 있어서,

상기 에이전트가 질의 에이전트(qury agent)인 컴퓨터 시스템.
제1항에 있어서,

복수의 메모리 슬롯―여기서 각 슬롯은 적어도 하나의 객체를 저장할 수 있음―을 포함하는 작업 공간을 추가로 포함하는 컴퓨터 시스템.
제7항에 있어서,

상기 메모리 슬롯은 복수의 네트워크 노드에 의해 접근할 수 있으며, 네트워크 노드에 의한 메모리 슬롯에 대한 접근은 허용성 체제에 의해 제어되는 컴퓨터 시스템.
제1항에 있어서,

상기 작업 공간이 메모리 내 작업 공간이고, 상기 에이전트가 최적화 에이전트인 컴퓨터 시스템.
제1항에 있어서,

상기 작업 공간이 영구 작업 공간인 컴퓨터 시스템.
제1항에 있어서,

작업 공간을 추가로 포함하며, 상기 작업 공간은 사건 관리자―여기서 사건관리자는 상기 작업 공간의 변경에 응답하여 네트워크 노드에 통지할 수 있음―를 포함하는 컴퓨터 시스템.
네트워크의 제1 노드에서 에이전트를 개시하는 단계;

상기 에이전트를 네트워크를 통해 네트워크의 제2 노드의 작업 공간―여기서 작업 공간은 각각 적어도 하나의 객체를 저장할 수 있는 복수의 메모리 슬롯을 가지며, 메모리 슬롯에 대한 접근을 제어하기 위하여 허용성 체제를 추가로 가짐―으로 전송하는 단계;

특정 메모리 슬롯에 대한 접근 권리를 갖는 에이전트를 검증하기 위하여 상기 허용성 체제를 이용하는 단계; 및

상기 에이전트와 상기 특정 메모리 슬롯 내에 저장된 적어도 하나의 객체를 이용하여 작업(operation)을 수행하는 단계

를 포함하는 객체 작업 공간 내의 데이터를 원격으로 접근하는 방법.
제12항에 있어서,

작업 결과를 상기 제1 노드로 전송하는 단계를 추가로 포함하는 객체 작업 공간 내의 데이터를 원격으로 접근하는 방법.
제12항에 있어서,

상기 작업 수행에 응답하여 네트워크의 제3 노드로 메시지를 전송하는 단계를 추가로 포함하는 객체 작업 공간 내의 데이터를 원격으로 접근하는 방법.
제12항에 있어서,

상기 작업 수행에 응답하여 작업 공간의 조직적인 계층 구조(oranizational hierarchy)를 변경하는 단계를 추가로 포함하는 객체 작업 공간 내의 데이터를 원격으로 접근하는 방법.
제12항에 있어서,

상기 제1 노드가 상기 작업 수행에 응답한 사건 통지에 가입하는 단계를 추가로 포함하는 객체 작업 공간 내의 데이터를 원격으로 접근하는 방법.
제12항에 있어서,

상기 작업 수행에 응답하여 허용성 체제를 변경하는 단계를 추가로 포함하는 객체 작업 공간 내의 데이터를 원격으로 접근하는 방법.
제12항에 있어서,

상기 작업 수행은 작업 공간 내의 관리 태스크(administrative tasks) 수행을 포함하는 객체 작업 공간 내의 데이터를 원격으로 접근하는 방법.
제12항에 있어서,

상기 작업 수행은 객체 성능(performance of the object)의 최적화를 포함하는 객체 작업 공간 내의 데이터를 원격으로 접근하는 방법.