KR20010052569A

KR20010052569A - 복합 기업 협력을 위한 시스템 및 방법

Info

Publication number: KR20010052569A
Application number: KR1020007013738A
Authority: KR
Inventors: 노타니란지트엔.; 파라스니스애브해이브이.; 휘플마크비.
Original assignee: 샌제이브 사이두; 아이2 테크놀러지즈, 인크.
Priority date: 1998-06-05
Filing date: 1999-06-03
Publication date: 2001-06-25
Also published as: JP2002517831A; US6397191B1; AU4415599A; TW451145B; EP1082685A1; CA2334241A1; WO1999063469A1

Abstract

적어도 하나의 이질캐스트 분할(heterocast split)과 적어도 하나의 이질캐트 결합(heterocast join)을 갖는 작업 흐름(workflow) 설계를 포함하는 복합 기업 협력을 위한 컴퓨터로 구현되는 기업 협력 방법이다. 이질캐스트 분할과 이질캐스트 결합은 매개 변수를 제공받는 적어도 하나의 동작(activity)을 허용하고, 노드 그룹 내의 노드를 포함하는 매개변수 중 적어도 하나를 허용한다. 작업 흐름은 동작이 각각 노드 그룹 내의 특정 노드에 맞추어 만들어지는 복수의 동작으로서 인스턴스를 생성시키도록 한다. 작업 흐름은 배치되고, 노드 그룹 내 노드에 걸친 동작 분산을 포함하며, 복합 기업 협력을 제공하기 위하여 실행된다. 다른 실시예에서, 작업 흐름 내에서 수행되는 동작과 관련된 객체를 포함하는 객체 지향 작업 흐름이 인스턴스를 생성시킨다. 객체는 기업 경계를 가로질러 관련된 동작들이 실행되는 노드 상에 배치되어, 복합 기업 협력을 제공하기 위하여 실행된다. 동작은 데이터와 작업 모두를 전달하는 객체를 이용하여 데이터 통신한다.

Description

복합 기업 협력을 위한 시스템 및 방법 {SYSTEM AND PROCESS FOR MULTI-ENTERPRISE COLLABORATION}

공급망, 기업체 및 사이트의 설계 분야 애플리케이션 및 환경은 제조 업체가 의사결정 지원(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)"의 범위인 의사결정 지원의 도메인과 관련되어 있다.

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

본 발명은 공급망(supply chain), 기업체 및 사이트 설계 분야에 관한 것으로, 특히 복합 기업 협력을 위한 시스템 및 방법에 관한 것이다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

도 14a는 지역 메모리 내 객체 모델을 포함하는 기업 협력을 위한 객체 지향 작업 흐름의 한 실시예를 나타내는 도면이다.

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

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

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

도 17a 및 도 17b는 데이터 접근과 작업 흐름 실행 중에 데이터가 다양한 형식으로 처리되는 것을 허용하는 변형의 한 실시예를 나타내는 도면이고,

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

본 발명에 따른 기업 협력을 위한 객체 지향 작업 흐름은 종래 공급망, 기업 및 사이트 설계 환경보다 우수하다.

본 발명의 한 특징에 따르면, 기업 협력을 위한 컴퓨터로 구현된 방법(프로세스)은 객체 지향 작업 흐름―여기서 객체 지향 작업 흐름은 작업 흐름 내에서 수행되는 동작들과 관련된 객체들을 포함함―의 인스턴스 생성을 포함한다. 게다가 객체 지향 작업 흐름의 객체는 기업 경계를 가로질러 관련된 동작들이 실행되는 노드 상에 배치된다. 배치 후, 배치된 객체는 실행되어 데이터와 작업(behavior) 모두를 전달하는 객체를 이용하여 데이터 통신하는 동작으로써 복합 기업간 협력을 제공한다. 또한, 한 실시예에서 프로세스는 노드에서 실행하는 객체가 접근할 수 있는 노드에서의 메모리 내 객체 모델의 생성을 추가로 포함한다.

본 발명의 다른 특징에 따르면, 데이터 접근과 객체 지향 작업 흐름의 변형(transformation)을 위한 컴퓨터로 구현된 프로세스(process)가 제공된다. 프로세스는 기본 데이터 형식(primary data format)으로서 객체의 통신 지원과, 기초가 되는 고유 데이터 형식(native data format)으로부터 만들어지는 유도 형식 객체(derived format objects)의 지원을 포함한다. 또한 고유 데이터 형식, 유도 형식 객체 및 객체 사이에 변형을 지원한다. 프로세스는 객체와 유도 형식 객체를 이용하는 작업 흐름 실행의 동작과 고유 데이터 형식, 유도 형식 객체 및 객체 사이에 변형을 이용하는 작업 흐름 실행 동작 사이의 정보 통신을 추가로 포함한다.

본 발명의 기술적인 이점은 객체를 이용하여 동작들 사이의 정보를 전달하는 객체 지향 작업 흐름을 구현하는 것이다. 이는 객체가 데이터와 작업 모두를 전달할 때 강화된 능력을 제공한다.

본 발명의 다른 기술적인 이점은 실행 중에 동작에 의해 접근될 수 있는 메모리 내 객체 모델을 국지적으로 구현하는 것이다. 이 접근은 객체의 생성, 수정 및 파기를 포함할 수 있다.

부가적인 기술적 이점은 데이터 접근과, 복합 기업 협력을 위한 동작과 작업 흐름 사이의 데이터 통신에 상당한 유연성을 제공하는 체제(framework)의 처리이다.

부가적인 기술적 이점은 다음의 도면, 서술 및 청구범위로부터 당업자에게 점차로 명백해 질 것이다.

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

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

다수의 도메인에서의 의사결정 지원은 의사결정 지원에 대한 강제적인 접근 방식보다는 협력적인 접근 방식을 추구함으로써 실현될 수 있다. 다양한 통신 및 분산 처리 기술들은 인터넷, 웹, 자바(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는 복잡한 복합 기업 작업 흐름을 구축, 배치, 감시 및 변경할 수 있다.

대체로 "작업 흐름"은 여러 태스크(task)를 함께 달성하는 데이터 흐름으로 결합된 한 벌의 "동작(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의 모델에 기초할 수 있다.

도 14a는 지역 메모리 내 객체 모델을 포함하는 기업 협력을 위한 객체 지향 작업 흐름의 한 실시예를 나타내는 도면이다. 나타낸 바와 같이, 작업 흐름은 도면 부호 170으로 표시한 것처럼 논리적으로 또는 도면 부호 172로 표시한 것처럼 물리적으로 나타낼 수 있다. 논리 작업 흐름(170)은 물리 작업 흐름(172)에서 특정 기업이 실행하는 다수의 동작을 가질 수 있다. 예를 들면 논리 작업 흐름(170)은 제2 기업(E2)에서 실행하는 동작(176)(A2)을 뒤이은 제1 기업에서 실행하는 동작(174)(A1)을 포함할 수 있다. 논리 작업 흐름(170)은 제1 기업(E1)으로 돌아가 실행하는 부가적인 동작(178, 180) (A3, A4)을 추가로 포함할 수 있다. 따라서, 물리 작업 흐름(172)은 제1 기업(182)(E1)에서 실행되는 동작(A1, A2, A3)과 제2 기업(184)(A2)에서 실행되는 동작(A2)을 포함할 수 있다.

또한 나타낸 바와 같이 기업(182)은 기업(182)에서 실행하는 동작(A1, A2, A3)에 의해 접근 가능한 메모리 내 객체 모델(186)을 가질 수 있다. 유사하게 기업(184)은 기업(184)에서 실행하는 동작(A2)에 의해 접근 가능한 메모리 내 객체 모델(188)을 가질 수 있다. 메모리 내 객체 모델(186, 188)에의 개별적인 접근은 동작(A1, A2, A3, A4)이 객체의 생성, 수정 및 파기는 물론 객체로부터의 정보 획득도 허용한다.

본 발명에 따르면, 작업 흐름(170)과 같은 작업 흐름의 실행은 종래의 작업 흐름 실행에서와 같은 서류가 아닌 객체를 통해 정보를 전달한다. 작업 흐름(170)의 이러한 객체 지향 특성은 객체가 일반적으로 자신과 함께 데이터와 작업 모두를 전달할 때 강화된 기능성을 제공한다. 또한, 작업 흐름(170) 내의 동작(A1, A2, A3, A4)에 공유 메모리 내 객체 모델(186, 188)의 생성, 수정 및 접근을 허용함으로써 부가적인 이점을 제공한다. 이러한 이점은 상태의 유지와 작업(work)을 메모리 내 객체 모델에 분담시킴으로써 작업 흐름의 복잡도 감소를 포함한다. 따라서, 기업(182, 184)에서 작업 흐름 엔진에 메모리 내 객체 모델을 내장함으로써 각 엔진이 필요한 정보에 국지적으로 접근하고 필요한 정보를 통해 제어하는 것을 허용한다. 예를 들면, 메모리 내 객체 모델(182 또는 184)은 공급망에서의 획득 작업을 모델링하는 획득 모델일 수 있으며, 여기서 작업 흐름(170)은 획득 프로세스와 관련된다. 또한 메모리 내 객체 모델(186, 188)은 동일한 인스턴스(instance)와 동일한 작업 흐름의 일부, 동일한 작업 흐름의 다수 인스턴스, 또는 기업(182, 184)에서 실행하는 다수 작업흐름의 인스턴스인 동작에 의해 접근될 수 있다.

현재의 전역 협력 관리자는 간단한 서류를 교환하는 것과는 대조적으로 객체를 사건(events)과 메시지로서 교환하는 객체 지향 작업 흐름을 구현할 수 있다. 이러한 객체는 데이터와 작업 모두를 포함하고, 전역 협력 관리자를 실행하는 기업 플랫폼(platforms)에서 실행 가능하다. 이들 객체를 사용함으로써, 예를 들면 사건은 트리거(trigger) 또는 작업 흐름 개시로 사용될 수 있으며, 작업 흐름을 종결시키는 신호를 전송할 수 있다. 메시지는 작업 흐름 내의 연속하는 동작들 사이에 정보를 전달할 수 있다. 이러한 방법으로 전역 협력 관리자는 서류 중심의 작업 흐름와는 대조적으로 객체 중심의 작업 흐름을 구현한다. 또한 접근/변형 객체 모델이 공개되며, 도 14a에 나타낸 바와 같은 개발자가 작업 흐름에 의해 보완되는 메모리 내 객체 모델 형성할 수 있도록 허용한다.

변형에 관하여, 한 실시예에서 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), 계획 등] 접근과 변형을 포함할 수 있다. 애플리케이션 형식간의 변형뿐만 아니라, 나타낸 것처럼 세 단계간의 변형이 있을 수 있다.

도 17a 및 도 17b는 데이터 접근과 작업 흐름 실행 중에 데이터가 다양한 형식으로 처리되는 것을 허용하는 변형의 한 실시예를 나타내는 도면이다. 나타낸바와 같이, 도 17a는 데이터 접근과 다양한 형식으로의 데이터 처리를 제공하도록 전역 협력 관리자 내에 구현된 접근 모델을 상세하게 나타낸다. 전술한 바와 같이 객체(190)는 일반적으로 실행 중인 작업 흐름 내의 동작들 사이에 정보를 전달하기 위해 사용된다. 결국, 기본 데이터 형식은 객체 기반이다. 나타낸 바와 같이 객체(190)는 파일(file), 스트림(stream), CORBA, DCOM 및 OODB를 포함하는 다양한 유형의 기본적인 객체(192)일 수 있다. 이러한 유형의 외부 객체는 근원(source)과 목적지(destination) 둘 다로서 직접 접근될 수 있다.

그러나 다른 유도 객체 형식은 EDI 데이터(194), XML 데이터(196) 및 관계형 데이터(relational data)(198)와 같은 다양한 고유 형식으로 유연한 데이터 처리를 제공하도록 지원한다. 지원되는 유도 형식 각각은 대응하는 형식으로부터 형성된 객체를 포함하는 유도 형식 객체(Derived Format Object, DFO)일 수 있다. 지원되는 유도 형식(DFOs)은 EDI DFO(200), XML DFO(202) 및 관계형 DFO(204)를 포함할 수 있다. 기본적인 형식(elemental formats)(194, 196, 198)은 필요에 따라 그들 각각의 유도 형식 객체와 객체(190)로 추출될 수 있다.

도 17b는 앞서 논의된 객체와 유도 형식 객체를 사용하는 변형 모델을 상세하게 나타낸 도면이다. 나타낸 바와 같이, 객체(206)는 두 동작 사이에서 직접적으로 교환될 수 있다. 또한 데이터는 동작들 사이에서 유도 형식 객체(207)로서 교환될 수 있다. 또한, 데이터는 기본적인 데이터 형식으로 교환될 수 있다. 일반적으로 이러한 스킴(scheme)은 지원되는 변형의 두 기본 카테고리를 포함할 수 있다. 그 첫번째는 직접 변형으로, 여기서 형식 객체는 능률적이고 맞춤화된 변형을 제공하기 위하여 직접 변형된다. 두 번째 변형은 공통 데이터 모델 변형으로, 여기서 형식 객체는 공통 데이터 모델(CDM)로서 참조되는 중간 표현을 통하여 변형된다. 변형에 대해서는 또한 도 13 내지 도 16에 관련하여 앞서 설명하였다. 이러한 데이터 접근과 체제의 처리는 동작과 복합 기업 협력을 위한 작업 흐름 사이의 데이터 통신에 상당한 유연성을 제공한다.

협력 작업의 배치

복합 기업 협력 시스템에서 하나의 중요한 인자는 협력 작업을 배치할 때의 편리함이다. 앞의 언급처럼, 본 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)에 의하여 확장될 수 있다.

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

Claims

적어도 하나의 이질캐스트 분할(heterocast split)과 적어도 하나의 이질캐스트 결합(heterocast join)을 포함하는 작업 흐름을 설계하는 단계;

상기 이질캐스트 분할과 이질캐스트 결합이 매개 변수화를 제공받는 적어도 하나의 동작과 노드 그룹 내의 노드를 포함하는 매개변수 중 적어도 하나를 허용하는 단계;

적어도 하나의 동작이 각각 노드 그룹 내의 특정 노드에 맞추어 만들어지는 복수의 동작으로서 인스턴스를 생성시키도록 상기 작업 흐름의 인스턴스를 생성하는 단계;

상기 노드 그룹 내 노드에 걸친 동작 분산을 포함하는 상기 작업 흐름을 배치하는 단계; 및

복합 기업 협력을 제공하도록 상기 작업 흐름을 실행하는 단계

을 포함하는 컴퓨터로 구현된 기업 협력 방법.
객체 지향 작업 흐름―여기서 객체 지향 작업 흐름은 작업 흐름 내에서 수행되는 동작과 관련된 객체를 포함함―의 인스턴스를 생성하는 단계;

상기 객체 지향 작업 흐름의 객체를 기업 경계를 가로질러 관련된 동작들이 실행되는 노드 상에 배치하는 단계; 및

상기 배치된 객체를 복합 기업 협력을 제공하기 위하여 실행하고, 상기 동작이 데이터와 작업 모두를 전달하는 객체를 이용하여 데이터 통신하는 단계

를 포함하는 컴퓨터로 구현된 복합 기업간 협력 방법.
제2항에 있어서,

하나 이상의 노드에서 메모리 내 객체 모델을 생성하여 하나 이상의 노드에서 실행하는 객체가 메모리 내 객체 모델에 접근할 수 있도록 하는 단계를 추가로 포함하는 컴퓨터로 구현된 복합 기업 협력 방법.
기본 데이터 형식(primary data format)으로 객체 통신을 지원하는 단계;

기초가 되는 고유 데이터 형식(native data format)으로부터 형성되는 유도 형식 객체(derived format objects)를 지원하는 단계;

고유 데이터 형식, 유도 형식 객체 및 객체 사이에 변형을 지원하는 단계; 및

객체와 유도 형식 객체를 이용하는 작업 흐름 실행의 동작과, 고유 데이터 형식, 유도 형식 객체 및 객체 사이에 변형을 이용하는 작업 흐름 실행의 동작 사이의 정보를 통신하는 단계

를 포함하는 데이터 접근과 객체 지향 작업 흐름의 변형을 위한 컴퓨터로 구현된 방법.
제4항에 있어서,

지원되는 객체가 파일 객체, 스트림 객체, CORBA 객체, DCOM 객체 및 OODB 객체를 포함하는 데이터 접근과 객체 지향 작업 흐름의 변형을 위한 컴퓨터로 구현된 방법.
제4항에 있어서,

지원되는 유도 형식 객체가 EDI 데이터, XML 데이터 및 관계형 데이터를 포함하는 고유 데이터 형식으로부터 형성되는 데이터 접근과 객체 지향 작업 흐름의 변형을 위한 컴퓨터로 구현된 방법.