KR20060112589A - 워크플로우 서비스 아키텍처 - Google Patents

Abstract

자동 워크플로우 서비스 시스템은 광범위한 워크플로우 시나리오들을 수용할 수 있다. 구성 서비스, 제한 서비스, 및 추적 서비스가 클라이언트 프로그램들에 제공될 수 있다. 구성 서비스는 활동 흐름들을 위한 액션들의 클라이언트에 따른 인스턴스화를 지원할 수 있다. 활동 흐름들은 활동 모델에 기초하거나 임시 기반으로 구성되거나, 양자의 조합일 수 있다. 액션들은 활동 흐름의 실행시에 활동 흐름에 추가될 수 있다. 추적 서비스는 액션들로의 그리고 액션들로부터의 메시지들을 추적할 수 있다.

구성 서비스, 인스턴스화, 활동 모델, 제한 서비스, 추적 서비스

Description

워크플로우 서비스 아키텍처{WORKFLOW SERVICES ARCHITECTURE}

<관련 출원에 대한 기재>

본 출원은, 2002년 11월 25일에 출원된, Teegan 등의 "SYSTEM AND METHOD FOR COMPOSING AND CONSTRAINING AUTOMATED WORKFLOW"라는 명칭의 미국 특허출원 제10/304,589호의 CIP(continuation-in-part)인, 2003년 12월 19일에 출원된 미국 특허출원 제10/742,696호에 대한 우선권을 주장하는데, 이들 각각은 참조로써 여기에 포함되어 있다.

본 기술분야는 일반적으로 자동 워크플로우 기술들에 관한 것이다.

자동 워크플로우 기술들(automated workflow technologies)은 작업장의 생산성을 향상시키기 위한 만병통치약으로 추천되어 왔다. 비지니스 프로세스들에 컴퓨터의 자동화 과학을 접목하는 것에 의해, 워크플로우 기술들은 컴퍼니들의 비지니스 방식에 소프트웨어의 능력을 적용할 것을 약속한다.

자동 워크플로우 기술들은 비지니스 프로세스를 소프트웨어의 워크플로우로서 표현할 수 있다. 워크플로우 설계자들은 통상적으로 비지니스 프로세스를, 미리 정해진 완결 기준들이 실현될 때까지 수행되고 모니터링되어야 하는 별개의 부분들로 분해한다.

워크플로우 기술들에서의 지속적인 문제점은, 워크플로우 기술들이 보통의 비지니스 작업자에게는 통상적으로 불가해하다는 것이다. 예를 들어, 워크플로우를 구성하는 것은 통상적으로 프로그래밍 스킬들과 워크플로우 시스템에 대한 광범위한 지식을 요한다. 정보에 밝은 작업자들이라 하더라도 대개는 필요한 프로그래밍 스킬들을 갖고 있지 않으며, 워크플로우 기술들을 이용하기 위해 또 다른 정보 시스템을 배울 수는 없거나 배우려고 하지 않는다.

또한, 정보 작업자들은, 워크플로우 시스템이 그들이 실제로 비지니스를 수행하는 방식을 반영하지는 않기 때문에, 워크플로우 시스템에서 흥미를 상실하기 쉽다. 예를 들어, 프로세스의 작은 예외는 통상적으로 워크플로우 시스템에 의해 수용될 수 없으므로, 프로세스의 작은 예외가 그것을 조장하기보다는 오히려 대개는 비지니스 프로세스의 실현에 방해가 될 수 있다.

자동 워크플로우에 대한 종래의 접근 방법들은 통상적으로, 실제 작업자의 필요들보다 지나치게 복잡하고 고정적이다. 따라서, 자동 워크플로우를 위한 향상된 기술들의 필요성이 여전히 존재한다.

여기에서 설명된 기술들은 광범위한 자동 워크플로우 시나리오들에서 사용될 수 있다. 예를 들어, 워크플로우 서비스는 구성 가능한 액션들의 실행을 제공할 수 있다. 액션들은, 표준 인터페이스들에 의해 포맷이 특정될 수 있는, 메시지들의 표준 세트를 송수신할 수 있다.

워크플로우 서비스는 구성 서비스, 제한 서비스, 및 추적 서비스를 포함할 수 있다. 구성 서비스는 선험 방식(priori basis), 임시 방식(ad hoc basis), 또는 양자의 조합에 기초한 액션들의 구성을 지원할 수 있다. 선험 구성은 활동 모델(activity model)에 기초할 수 있다.

제한 서비스는, 액터의 식별 정보에 기초한 제한들을 포함하여, 광범위한 제한들을 지원할 수 있다. 제한들은 액션들 또는 타깃 액터들을 제한할 수 있다. 제한들은 상대적이거나 부정적일 수 있다. 또한, 이행 액션들(transitive actions)에 대한 제한들이 지원될 수도 있다.

서비스는 SOAP(Simple Object Access Protocol)-기반 프로토콜을 통해 클라이언트들과 통신할 수 있고, 서비스는 클라이언트 관용적(client agnostic)일 수 있다. 서비스에 액세스하기 위한 사용자 인터페이스들은 사용자들의 데스크탑들에 이미 표시되고 있는 흔히-사용되는 애플리케이션들로 통합될 수 있다. 예를 들어, 워크플로우 운용들은 익숙한 이메일 또는 워드 프로세싱 인터페이스들로 쉽게 통합될 수 있다.

액션들로의 메시지들 및 액션들로부터의 메시지들은 추적될 수 있다. 그에 따라, 워크플로우 프로세싱의 상태가 제공될 수 있다.

예기치 못한 시나리오들을 수용하는 탄력적인 워크플로우 서비스가 여기에 설명되어 있는 기술들을 통해 구현될 수 있다.

광범위한 액션 기능 및 액션 협동을 제공하는 구성 가능한 액션들이 여기에 설명되어 있는 기술들을 통해 구현될 수 있다.

상기한 특징들 및 이점들과 다른 특징들 및 이점들이, 첨부 도면들을 참조하여 진행하는, 개시된 실시예들에 대한 다음의 상세한 설명으로부터 좀더 명백해질 것이다.

도 1은 자동 워크플로우를 지원하는 예시적 시스템을 나타내는 블록도이다.

도 2는 도 1의 자동 워크플로우와 같은, 자동 시스템에서 워크플로우를 프로세싱하는 예시적 방법의 흐름도이다.

도 3은 구성 가능한 액션을 위한 예시적 패턴을 나타내는 블록도이다.

도 4는 구성 가능한 액션에서 메시지들을 프로세싱하는 예시적 방법의 흐름도이다.

도 5는 메시지들을 통한 예시적인 액션-대-액션 통신을 나타내는 블록도이다.

도 6은 액션-대-액션 통신을 통해 동기화를 실현하는 예시적 방법의 흐름도이다.

도 7은 태스크들의 예시적인 구현을 나타내는 블록도이다.

도 8은 태스크들을 프로세싱하는 예시적 방법의 흐름도이다.

도 9는 제한들의 예시적 구현을 나타내는 블록도이다.

도 10은 구성 가능한 액션들에 대한 제한들을 구현하는 예시적 방법의 흐름도이다.

도 11은 지식 기반 어댑터들을 통한 사실 수집(fact collection)을 나타내는 블록도이다.

도 12는 제한들을 적용할 때 사실들을 사용하는 예시적 방법의 흐름도이다.

도 13은 예시적인 활동 모델을 나타내는 블록도이다.

도 14는 구성 가능한 액션들을 통해 활동 모델을 구현하는 예시적 방법의 흐름도이다.

도 15는 임시 액션 구성을 통해 구성된 예시적 활동 흐름을 나타내는 블록도이다.

도 16은 구성 가능한 액션들을 통해 임시 활동 흐름을 구축하는 예시적 방법의 흐름도이다.

도 17은 활동 모델에 기초해 활동 흐름에 추가되는 예시적 임시 액션을 나타내는 블록도이다.

도 18은 활동 모델에 기초해 활동 흐름에 임시 활동들을 추가하는 예시적 방법의 흐름도이다.

도 19는 사용자 식별 정보에 기초한 예시적 제한을 나타내는 블록도이다.

도 20은 액터 제한들에 기초한 액션 및 목표 옵션들을 제시하는 예시적 방법의 흐름도이다.

도 21은 이행 액션에 대한 예시적 제한을 나타내는 블록도이다.

도 22는 제한들의 관점에서 액터에 대해 정해진 것에 기초해 옵션들을 제시하는 예시적 방법의 흐름도이다.

도 23은 예시적인 추적 구성을 나타내는 블록도이다.

도 24는 구성 가능한 액션들의 활동 흐름에 대한 상태를 추적하는 예시적 방 법의 흐름도이다.

도 25는 추적에 기초한 워크플로우 상태의 예시적인 그래픽 표현을 나타내는 스크린 샷이다.

도 26은 활동 흐름 상태를 그래프로 표현하는 예시적 방법의 흐름도이다.

도 27은 이메일 사용자 인터페이스 내의 침투성 워크플로우 사용자 인터페이스(pervasive workflow user interface)의 예시적 구현을 나타내는 스크린 샷이다.

도 28은 태스크를 수용하는 침투성 워크플로우 사용자 인터페이스의 예시적 구현을 나타내는 스크린 샷이다.

도 29는 침투성 워크플로우 사용자 인터페이스를 통해 선택들을 표현하고 수용하는 예시적 방법의 흐름도이다.

도 30은 워드 프로세싱 사용자 인터페이스 내에서 항목을 승인하거나 거절하는 침투성 워크플로우 사용자 인터페이스의 예시적 구현을 나타내는 스크린 샷이다.

도 31은 액션을 활성화하기 위한 파라미터들의 스펙에 대한 발견 가능성을 위한 예시적 구성을 나타내는 블록도이다.

도 32는 액션에 대한 활성화 파라미터 스펙을 찾아내기 위한 예시적 방법의 흐름도이다.

도 33은 구성 가능한 액션에 대한 패턴을 지원하는 예시적 템플릿을 나타내는 블록도이다.

도 34, 도 35, 도 36 및 도 37은 워크플로우 기술들의 예시적 실행을 나타낸 다.

도 38은 하이퍼링크들을 이용한 태스크의 예시적 통지를 나타낸다.

도 39는 워크플로우 시스템을 구현하기 위한 예시적 아키텍처를 나타내는 블록도이다.

도 40은 워크플로우의 상태를 나타내고 후속 액션들의 선택을 수용하기 위한 사용자 인터페이스의 예시적 구현을 나타내는 스크린 샷이다.

도 41은 구성 가능한 액션을 위한 예시적 템플릿을 나타내는 스크린 샷이다.

도 42는 구성 가능한 액션을 위한 예시적 템플릿의 일부를 나타내는 스크린 샷이다.

<제1 실시예>

예시적인 워크플로우 시스템

도 1은 구성 가능한 액션들을 통해 자동 워크플로우를 구현하기 위한 예시적 시스템(100)을 나타낸다. 본 실시예에서는, 복수의 클라이언트 프로그램들(122A-122N)이 네트워크(132)를 통해(예를 들어, 네트워크 접속을 통해) 워크플로우 서비스(140)에 액세스한다. 실제로, 클라이언트 프로그램들(122A-122N)은 개개의 인간 액터들에 의해 조작된다. 인간 액터들은 워크플로우 서비스(140)에서 수행되는 워크플로우 프로세싱의 인간 참가자들이고 시스템에서는 식별 정보(예를 들어, 정보 125)로 표현될 수 있다.

워크플로우 서비스(140)는 사용자 인터페이스들 및 클라이언트 프로그램들 (122A-122N)의 다른 세부 사항들과 독립적으로 운용될 수 있다. 따라서, 클라이언트 프로그램들(122A-122N)은 필요에 따라 다양한 형태들을 취하거나 균일할 수 있다. 서비스(140)는 다양한 클라이언트들(예를 들어, 클라이언트 소프트웨어의 상이한 유형들)에 의해 액세스될 수 있기 때문에, 때때로 이들을 "클라이언트 관용적(client agnostic)"이라고 한다.

워크플로우 서비스(140)는 구성 서비스(141; composition service)를 통해 워크플로우 프로세싱을 수행할 수 있는데, 구성 서비스(141)는 구성 가능한 액션들(예를 들어, 액션 142)을 활동 흐름들로 모을 수 있다. 구성 가능한 액션들은 표준 인터페이스들에 따라 메시지들(예를 들어, 메시지 143)을 송수신할 수 있다.

메시지들의 지시들은, 활동 흐름들의 상태를 추적하는 것과 같은, 이후의 검색을 위해 추적 서비스에 의해 (예를 들어, 추적 데이터베이스(162)에) 저장될 수 있다. 제한 서비스(152)는 제한들을 구현해 워크플로우 프로세싱 동안 사용자들을 안내할 광범위한 제한들을 부여할 수 있다. 제한 서비스는 제한들을 적절하게 적용하기 위해 사실 저장 장치(fact store)를 조회할 수 있다. 이러한 사실 저장 장치는 조직화를 위한 광범위한 정보를 포함할 수 있고, 새로운 사실 유형들이 수용될 수 있다.

실제로, 시스템(100)은 임의 갯수의 클라이언트 프로그램들을 가질 수 있고, 복수의 네트워크들에 대해 실행될 수 있으며, 현재적으로-실행 중인 광범위한 액션들 및 활동 흐름들을 지원할 수 있다.

<제2 실시예>

워크플로우들을 프로세싱하는 예시적인 방법

도 2는 도 1의 자동 워크플로우 시스템과 같은, 자동 워크플로우 시스템에서 워크플로우를 프로세싱하는 예시적인 방법(200)을 나타낸다. 본 방법(200)은 소프트웨어에 의해 수행될 수 있다.

212에서는, 구성 가능한 액션들이 제한들의 관점에서 활동 흐름들로 구성된다. 예를 들어, 제한 서비스는 사실 저장 장치에 기초해 가능한 액션들 및 목표 액터들을 지시할 수 있다. 222에서는, 워크플로우 서비스에 의해 액션들이 실행된다. 실행은 다양한 형태들을 취할 수 있고, 인간 액터들로부터 정보 또는 지시들을 수신하는 것을 포함하여, 광범위한 프로세싱을 포함할 수 있다. 실행 동안, 태스크들이 할당될 수 있고 태스크들에 관한 정보가 수집될 수 있다.

232에서는, 활동 흐름들의 진행이 추적된다. 예를 들어, 구성 가능한 액션들로 송신된 그리고 구성 가능한 액션들로부터 송신된 메시지들이 이후의 검사를 위해 기록될 수 있다. 활동 흐름들과 관련된 태스크들에 관한 정보 또한 추적될 수 있다.

실제로, 워크플로우 시스템은, 워크플로우 서비스에서의 실행을 위한 액션들의 세트를 특정하는 활동 모델들을 구축할 수 있는 능력을 포함하여, 광범위한 다른 기능을 제공할 수 있다.

<제3 실시예>

예시적인 액션들

여기에서 설명되는 실시예들 중 어디에서든, 구성 가능한 액션은 도 3에 나 타낸 예시적인 구성 가능한 액션(300)의 형태를 취할 수 있다. 액션(300)은 구성 가능한 액션 정의로부터 인스턴스화될 수 있는데, 구성 가능한 액션 정의는 통상적으로 액션의 액션-특정 워크플로우 프로세싱(308; 예를 들어, 비지니스 로직)에 대한 정의를 포함한다.

액션은 광범위한 구성 가능 시나리오들을 지원하기 위한 통신 인터페이스들(312, 322, 332, 342, 352, 362 )의 세트를 통해 메시지들을 송수신할 수 있다. 예를 들어, 사용자에 의해 지시될 때 또는 워크플로우내의 적절한 위치에 있을 때, 워크플로우 서비스는 액션을 인스턴스화하고 그것을 활성화 메시지(activation message)로 송신할 수 있다.

도 3에 나타낸 구성은, 구성 가능성이 자동 워크플로우 서비스를 통해 지원될 수 있도록 하기 위한, 액션들의 패턴으로서 사용될 수 있다.

인터페이스들(312, 322, 332, 342, 352, 362)은 표준 인터페이스들의 형태를 취할 수 있다. 예를 들어, 인터페이스들(312, 322, 332, 342, 352, 362)은 워크플로우 시스템 전체에 걸쳐 사용되는 XML 스키마(예를 들어, XSD 스펙)에 상응하는 메시지들을 수용할 수 있다. 이런 식으로, 개발자는 새로운 액션들을 개발할 수 있는데, 액션들이 XML 스키마에 상응한다면, 액션들은 워크플로우 서비스에서 다른 액션들과 함께 구성될 수 있고 워크플로우 서비스 사양들로부터의 이점을 취할 수 있다. 인터페이스들(312, 322, 332, 342, 352, 362) 각각에 대해 상이한 스키마가 사용될 수도 있다. 예를 들어, 태스크 인터페이스(322)에 관련된 스키마는 태스크와 관련된 액터를 특정하는 방법을 포함할 수 있다.

메시지들(예를 들어, 메시지 362)은, 액션을 활성화하는 것, 액션을 인터럽트하는 것, 액션을 종료하는 것, 또는 액션을 다른 구성 가능한 액션들과 동기화(예를 들어, 언블로킹(unblocking)하는 것을 포함하여, 다양한 원인들로 인해 액션에 의해 캡슐화된 로직(logic encapsulated by the action)에 의해 수신될 수 있다. 마찬가지로, 메시지들은, 액션이 활성화되었다는 것, 액션이 종료되었다는 것, 또는 태스크가 (예를 들어, 액터에게) 할당될 것이라는 것을 지시하는 것을 포함하여, 다양한 원인들로 인해 액션에 의해 캡슐화된 로직에 의해 송신될 수 있다.

더 적거나, 많거나, 상이한 인터페이스들과 같은, 인터페이스들의 다른 구성들이 가능할 수 있다. 그러나, 일치성을 원한다면, 동일한 미리 정해진 인터페이스들이 전체에 걸쳐(예를 들어, 활성화 및 인터럽트 메시지들을 수신하기 위한 인터페이스들에) 사용될 수 있다. 인터페이스들은 서로에 대한 구성 가능 액션들, 워크플로우 서비스, 및 클라이언트 시스템들의 접속을 용이하게 하기 때문에, 이들을 때로는 "핀들(pins)"이라고 한다. 핀들을 갖는 액션 정의들이 워크플로우 참가자들에 의한 사용을 위해 워크플로우 서비스에 설치될 수 있다. 설치된 액션들의 액세스 가능성에 관한 제한들은 관리자에 의해 특정될 수 있다. 그 다음, 워크플로우 시스템은 액션을 적절한 액터들에게만 옵션으로 제시할 수 있다.

<제4 실시예>

인터페이스들을 통해 메시지들을 프로세싱하는 예시적인 방법

도 4는, 도 3의 구성 가능한 액션(300)에 의한 것과 같은, 구성 가능한 액션에서 메시지들을 프로세싱하는 예시적인 방법을 나타낸다. 412에서는, 액션에 의 해 캡슐화된 로직을 거쳐 액션에 의한 표준 인터페이스들 중 하나에 의해 메시지가 수신된다. 422에서는, 메시지가 프로세싱된다. 432에서는, 액션에 의해 캡슐화된 로직을 거쳐 액션에 의한 표준 인터페이스들 중 하나로부터 메시지가 송신된다.

실제로, 메시지들을 송수신하는 것은, 메시지들 간의 동기화 및 액션에 의한 다양한 프로세싱을 포함하여, 훨씬 더 복잡할 수 있다. 그러나, 개발자들에게는 템플릿(template)이 제공될 수 있는데, 그에 의해, 액션의 미리 정해진 비지니스 로직은, 워크플로우 서비스의 세부 작업들에 익숙해지지 않고서도, 개발자들에 의한 액션들의 생성을 용이하게 하기 위한 템플릿으로 쉽게 통합될 수 있다.

<제5 실시예>

예시적인 활동 흐름들

하나 이상의 구성 가능 액션들의 실행 가능 세트는 활동 흐름의 형태를 취할 수 있다. 워크플로우 서비스는 액션들 간의 활성화, 인스턴스화, 및 실행을 조정할 수 있다. 실행되는 동안, 액션들은 워크플로우 서비스와 그리고 서로와 메시지들을 송수신할 수 있다. 또한, 액션들은 클라이언트 프로그램들과 (예를 들어, 워크플로우 서비스를 통해) 메시지들을 송수신할 수도 있다.

<제6 실시예>

예시적인 메시지들

워크플로우 서비스에 의해 광범위한 메시지들을 지원될 수 있다. 그러나, 한 세트의 가능한 메시지들을 선택하는 것에 의해, 액션들, 워크플로우 서비스, 및 워크플로우 서비스의 클라이언트들 간의 표준 통신 모드들이 실현될 수 있다. 표 1은 워크플로우 시스템에 대한 메시지들의 예시적인 세트를 나타낸다.

프로토콜 메시지들 각각은 XSD 스키마에 상응할 수 있다. 따라서, 메시지들은 XML로 송신될 수 있다.

<제7 실시예>

예시적인 동기화 시나리오

일부 시나리오들에서는, 액션들이 실행을 서로 동기화하는 것이 바람직할 수 있다. 예를 들어, 제1 액션이 제2 액션이 진행하는 것이 적합하다고 지시하는 것을 제2 액션이 대기하고 있는 동안에, 제1 액션이 실행될 수 있다. 이러한 접근 방법은 활동 흐름들에서 타임아웃들(timeouts)을 구현하는데 사용될 수 있다.

도 5는 메시지들을 통한 예시적인 액션-대-액션 통신을 나타낸다. 이러한 구성(500)은 비독립적인 액션의 구성 가능성 및 동기화 기능에 사용될 수 있다.

본 실시예에서는, 액터 A의 활동으로 인해, 활동 흐름의 실행이, 액터 B에게 태스크를 할당하는 액션(512)에 도달했다. 그 다음, 액터 B는, 액션(516)이 액션(514)에 의존하게 하면서, 액션들(514 및 516)을 활성화한다. 예를 들어, 액션(514)은 "위임(delegation)" 액션일 수 있고, 액션(516)은 "확대(escalation)" 액션일 수 있다. 액터 B는 위임을 위한 타깃으로 액터 C를 선택할 수 있으며, C가 미리 정해진 시간 제한 내에 응답하지 않으면, 확대가 C의 관리자에게로 송신될 것을 특정할 수도 있다. 이러한 경우, 액션(516)은, 액션(514)이 타임아웃되고 동기화 메시지(572)를 송신할 때까지, 블로킹될 수 있다.

동기화 메시지(572)는 인터페이스들(562 및 564) 사이에서 송신된다. 동기화 메시지(572)의 수신시에, 액션(516)은 언블로킹되고, 메시지를 C의 관리자에게 송신하는, 자신의 기능을 수행한다. 그 다음, C의 관리자는 흐름을 후속 액션(518)으로 확장할 수 있다.

도 6은 액션-대-액션 통신을 통해 동기화를 실현하기 위한 예시적인 방법(600)을 나타낸다. 612에서는, 액션의 실행이 블로킹된다. 622에서, 블로킹된 액션은 동기화 메시지를 수신한다. 632에서는, 블로킹된 액션이 실행을 재개한다.

구성(500 또는 600)은 병렬 실행 경로들에 따른 실행을 조정하는데 유용할 수 있으며, 액터에게 태스크가 할당되었지만, 액터가 타임아웃 기간내에 응답하지 않으면, 태스크가 다른 누군가에게로 확대되는 것과 같은, 타임아웃 조건들을 구현하는데 이용될 수 있다. 동기화 메시지들은 (예를 들어, 다른 액션의 진행을 모니터링하기 위한) 광범위한 여타 액션-대-액션 통신 시나리오들 중 어디에서도 사용될 수 있다.

<제8 실시예>

예시적인 태스크들

워크플로우 프로세싱에서, 대개는 인간 참가자들에게 작업을 할당하는 것이 바람직하다. 이러한 할당들은 액터들에게 태스크들을 할당하는 것에 의해 실현될 수 있다. 태스크 기능은 일반적으로, 워크플로우 서비스 클라이언트들에 의한 광범위한 구현들을 지원하기 위한 워크플로우 서비스에 의해 구현될 수 있다. 태스크들에 관한 세부 사항들은 클라이언트 소프트웨어에 의해 핸들링될 수 있다. 예를 들어, 워크플로우 서비스가, 미리 정해진 액터에게 할당된 태스크가 존재하는지는 추적할 수 있지만, 태스크가 실현되는 방법이 워크플로우 서비스에 의해 이해되거나 구현될 필요는 없다.

예를 들어, 클라이언트 소프트웨어는, 응답하여 태스크를 완결하기 위한 추가 단계들을 취할 수 있는 인간 액터에게 태스크를 제시할 수 있다. 많은 경우들에서, 인간-대-인간 상호 작용은 태스크를 실현하는 것과 관련되어 있으므로, 워크플로우 서비스내에서 일반적으로 태스크들을 구현하는 것은 워크플로우 서비스가 좀더 광범위한 시나리오들에서 사용될 수 있게 한다.

도 7은 워크플로우 서비스(712)가 태스크들을 지원할 수 있는 예시적인 구성(700)을 나타낸다. 본 실시예에서, 액션(714)은 표준 인터페이스(722)를 통해 태스크 메시지(724)를 송신할 수 있다. 태스크 메시지(724)는, 태스크 실현 기능, 태스크 완결 기능, 또는 양자(734)를 포함하는, 클라이언트 소프트웨어(732)로 방향 지정된다.

워크플로우 서비스(712)는 추적 목적을 위해 메시지(724)를 인터럽트하고 메시지(724)에 대한 지시를 데이터베이스(732)에 저장할 수 있다. 예를 들어, 표(734)는 할당된 태스크 및 관련 액터를 지시할 수 있다. 실제로, 추가 정보(예를 들어, 태스크가 할당된 때, 태스크 결과들 등)가 저장될 수도 있다. 액션들로 송신되고 액션들로부터 송신된 메시지들로부터 정보가 취해지거나 그러한 메시지들에 의해 정보가 표현될 수 있다.

도 8은 태스크들을 프로세싱하는 예시적인 방법(800)을 나타낸다. 812에서는, 태스크 메시지가 태스크-지원 소프트웨어로 송신된다. 822에서는, 태스크의 결과가 태스크-지원 소프트웨어로부터 워크플로우 서비스에 의해 수신된다.

832에서는, 워크플로우 서비스의 추적 시스템이 업데이트된다. 이런 식으로, 워크플로우 진행에 관한 질의들이 답변될 수 있고 워크플로우 진행(예를 들어, 태스크들의 진행)을 모니터링하고자 하는 사용자들에게 제시될 수 있다.

<제9 실시예>

액션들의 예시적인 구성 가능성

여기에서 설명된 실시예들 중 어디에서든, 액션들은 활동 흐름을 형성하도록 구성(예를 들어, 다같이 통합)될 수 있다. 워크플로우 서비스의 설계로 인해, 액션들은 활동 흐름의 실행시(예를 들어, 런타임)에 구성될 수 있다. 활동 흐름에 관련된 워크플로우 프로세싱이 진행함에 따라, 추가 액션들이 활동 흐름에 추가될 수 있다. 따라서, 시스템은 선험 방식으로(예를 들어, 활동 모델의 설계 동안에), 임의 방식으로(예를 들어, 활동 모델의 실행 동안에), 또는 그들의 미리 정해진 조합(예를 들어, 선험 방식으로 생성된 활동 흐름에 임의 방식으로 액션들을 추가하는 것)으로 생성된 활동 흐름들을 지원할 수 있다.

개발자는 새로운 액션들을 설계할 수 있는데, 새로운 액션들은 그것들이 워크플로우 서비스에 의해 지원되는 패턴에 적합하기만 하다면 시스템에 설치될 수 있다.

<제10 실시예>

예시적인 제한들

여기에서 설명된 실시예들 중 어디에서든, 워크플로우 서비스는 제한 서비스를 통해 제한들을 수용할 수 있다. 제한들은 일반적으로 광범위한 형태들을 지원하도록 정의될 수 있다. 예를 들어, 제한은 현재 시나리오의 다양한 측면들을 평가하고 그것을, 어떤 액션들 또는 타깃들이 현재 시나리오에 이용될 수 있는지를 지시하는 저장 장치와 비교할 수 있다. 이용가능한 액션들 또는 타깃들이 클라이언트 소프트웨어에 제공될 수 있는데, 클라이언트 소프트웨어는 활동 흐름의 실행 또는 구성 동안 참가 액터들에 의한 고려를 위해 그것들을 제시할 수 있다.

어떤 액션이 실행되기 전에 적용되는 것에 추가하여, 제한들은 관련된 활동 흐름들의 실행시에 적용될 수도 있다. 액터들이 다음에 할 수 있는 것을 제한하기 위해 제한들이 사용될 수도 있지만, 제한들은 워크플로우의 실행 동안 어떤 액션들이 이용가능한지에 관해 액터들을 안내하는 추론 효과(corollary effect)를 가질 수도 있다. 이런 식으로, 시스템은 다수의 무의미한 옵션들로 사용자들이 당황하게 되는 것을 방지할 수 있고, 단순하지만 효과적인 사용자 인터페이스가 제시될 수 있다.

예시적인 일 제한은, 어떤 액터들이 어떤 액션들을 수행할 수 있는지 또는 미리 정해진 활동 모델에 기초해 활동 흐름을 개시할 수 있는지를 제한한다. 예를 들어, 미리 정해진 액션 또는 활동 모델로의 액세스는 미리 정해진 역할, 그룹, 또는 액터에게로 한정될 수 있다. 제한 서비스는 일반적으로 사실들과 관련하여 제한들을 부과할 수 있다.

마찬가지로, 목표가 될 수 있는 액터들(예를 들어, 태스크가 할당될 수 있는 액터들)도 제한될 수 있다. 예를 들어, 액터는 경리 부서의 사람들에게만 경리 태스크를 할당하도록 허용될 수 있는 등이다.

제한 서비스에 의한 고려를 위해 광범위한 사실들이 포함될 수 있다. 예를 들어, 조직은 액터의 이름, 관련 부서, 액터가 관리자인지의 여부, 액터의 직속 상사들 등을 지시하는 정보를 저장할 수 있다. 이러한 사실들은, 본 명세서의 다른 곳에서 설명되는 바와 같이, 다양한 소스들로부터 유도될 수 있다. 제한들은 지식 기반들을 통해 이용가능한 사실들 중 하나에 대해 정의될 수 있다.

부가적으로, 워크플로우 서비스는 상대적인 제한들을 지원할 수 있다. 예를 들어, 태스크는 확대 액터의 관리자에게로만 확대-가능할 수도 있다. 또는, 액터는 그녀 부서의 타깃 액터들에게만 태스크를 할당하도록 허용될 수도 있다. 따라서, 액터들과 타깃들 간의 관계들이 고려될 수 있다.

또한, 제한들은 부정적인 방식으로 정의될 수도 있다. 예를 들어, 활동 흐름을 시작할 수 있는 액터들을 특정하는 대신, 활동 흐름을 시작할 수 없는 액터들이 특정될 수 있다.

더 나아가, 워크플로우 서비스는 이행 액션들을 위한 제한들을 지원할 수 있다. 예를 들어, 경리 부서의 누군가에게 태스크가 할당된 시나리오에서, 제한은 어떤 액터들이 태스크에 작용(예를 들어, 확대)하도록 허용되었는지를 특정할 수 있을 뿐만 아니라 이행 타깃(예를 들어, 태스크가 할당되는 새로운 사람)을 제한할 수도 있다. 또한, 제한은 정해진 액터(예를 들어, 태스크가 이미 할당되어 있는 타깃 액터)를 고려할 수도 있다. 이행 액션을 위한 제한은 상대적으로 특정될 수 있다(예를 들어, 소스 액터와 액터에 대해 정해진 것과의 관계).

다른 제한들은 문서 유형에 기초할 수 있다. 예를 들어, 태스크가 특정 문서 유형(예를 들어, 제안)을 갖는다면, 제한들은 어떤 액션들 및 어떤 타깃들이 이용가능한지를 제어할 수 있다. 활동 모델에서, 실행될 후속 액션을 판정하는 것은 제한의 형태로 구현될 수 있다.

또 다른 제한들은 활동 흐름 진행 상태(예를 들어, 활동 흐름이 활동 모델내의 어디까지 진행했는지)에 기초할 수 있다. 예를 들어, 활동 모델이 문서와 관련되어 있고 활동 모델이 아직까지 인스턴스화되지 않았다면(예를 들어, 진행 상태가 "시작되지 않은" 상태라면), 제한들은 이용가능한 액션들에 영향을 미칠 수 있다. 활동을 위한 활동 흐름이 시작된 후(예를 들어, 진행 상태가 "시작된" 상태라면), 상이한 제한들이 상이한 액션들을 제시할 수 있다. 마찬가지로, 활동 흐름이 종료되었을 때(예를 들어, 진행 상태가 "종료된" 상태라면), (예를 들어, 활동 흐름을 종료하는 것을 옵션으로 제시하지 않기 위해) 제한들이 그것을 반영할 수 있다. (예를 들어, 미리 정해진 액션이 종료된 등의) 다른 상태들이 지원될 수도 있다.

도 9는 이용가능한 후속 액션을 판정하기 위한 제한들과 관련된 예시적 구성(900)을 나타낸다. 본 실시예에서, 워크플로우 서비스는 액션(912)을 위해 가능한 후속 액션들을 판정한다. 본 실시예에서는, 액션들(922A-922N) 중 하나가 가능하다. 시나리오를 둘러싸고 있는 환경들(예를 들어, 후속 액션을 선택하는 액터의 식별 정보, 그룹, 또는 역할 등)에 따라, 후속 액션들(922A-922N)의 세트는 워크플로우 서비스에 의해 저장되어 있는 제한들에 의해 지시되는 액션들의 서브 세트로 한정된다. 후속 액션을 판정하는 것은, 제한들을 현재 시나리오에 적용하는 제한 엔진에 의해 수행될 수 있다.

도 10은 활동 흐름에 제한들을 구현하기 위한 예시적인 방법(1000)을 나타낸다. 1012에서는, 활동 흐름을 위한 액션들이 인스턴스화된다. 다음으로는, 실행이 시작될 수 있다. 활동 흐름의 실행시, 1022에서는, 구성을 위한 후속 액션으로 이용가능한 액션들이 사실들에 기초해 한정된다.

제한들을 일반적인 방식으로 이용하는 것은, 워크플로우 참가자가 워크플로우 실행 동안 안내되는 광범위한 메커니즘들을 가능하게 한다. 제한들은 통상적으로 관리자를 통해 관리되지만, (예를 들어, 활동 흐름을 구성할 때) 참가 액터들이 제한들에 기여할 수도 있다.

<제11 실시예>

제한들을 위한 사실들의 예시적인 획득

도 11은, 워크플로우 서비스(1112)가 제한들(1132)을 적용할 목적으로 하나 이상의 지식 기반들(1162A-1162N)과 상호 작용하는 예시적인 구성(1100)을 나타낸다. 본 실시예에서는, 하나 이상의 개별 어댑터들(1122A-1122N)을 사용해 사실들을 획득하기 위한 지식 기반들(1162A-1162N)과 인터페이스한다.

지식 기반(예를 들어, 지식 기반(1162A))에서의 사실들의 이용 가능성은 워크플로우 서비스에 개개의 지식 기반 어댑터(예를 들어, 어댑터 1122A)를 설치하는 것에 의해 실현될 수 있다. 어댑터(1122A)는, 지식 기반(1162A)의 정보가 워크플로우 서비스(1112)에 의한 사용을 위해 검색될 수 있는 매핑을 포함한다. 예를 들어, 워크플로우 서비스(1112)는, 제한들(1132)을 적용할 때, 액터들, 그들의 위치들, 보안 레벨 등에 관한 사실들을 조회하기를 원할 수도 있다. 이런 식으로, 워크플로우 서비스(1112)에서 이용가능한 사실들은 광범위한 소스들 중 어느 하나에 기인할 수 있다.

도 12는 제한들을 적용할 때 사실들을 사용하는 예시적인 방법(1200)을 나타낸다. 1212에서는, 제한 프로세싱 동안의 사실에 대한 요청이 수신된다. 예를 들어, 액터의 보안 레벨 또는 부서가 요청될 수 있다. 1222에서는, 사실이 검색된다. 그 다음, 1232에서는, 검색된 사실이 제한을 적용하는데 사용된다.

실제로, 사실들은 (예를 들어, 하나 이상의 지식 기반들로부터) 주기적으로 또는 일회적으로 검색되어, 요청들이 충족될 수 있는, 워크플로우 서비스 제어하의 중앙 사실 저장 장치에 저장될 수 있다.

또한, 사실들은 활동 흐름의 현재 진행 상태, 활동 흐름과 관련된 문서 유형, 또는 그들의 어떤 조합을 포함할 수도 있다.

<제12 실시예>

활동 모델들을 구성하기 위한 예시적 구성 가능성

여기에 설명되어 있는 실시예들 중 어디에서든, 하나 이상의 액션들은 활동 흐름을 생성하도록 인스턴스화될 수 있는 액션들 및 관련 제한들의 세트로 구성될 수 있다. 이러한 액션들의 세트를 흔히 "활동 모델"이라고 한다.

액션들이 활동 모델 설계자에 의해 이미 선택되어 있기 때문에, 활동 모델을 실행하는 것을 간혹은 선험적 활동 흐름이라고 한다. 원한다면, 활동 모델 설계자는, 관련된 활동 흐름의 실행 동안 변화가 수행되지 않도록 하기 위해, 활동 모델을 불변으로 정의할 수 있다.

도 13은 예시적인 활동 모델(1300)을 나타낸다. 본 실시예에서는, 액션 정의들(1322, 1324, 1326, 1338, 및 1330)에 대한 다양한 참조들이, (예를 들어, 제한들에 의해 허용되는) 액터에 의한 실행을 위해 선택될 수 있는 발음 불가능한 유닛(invocable unit)으로 조합되었다. 사용자의 편의를 위해, 활동 모델(1300)에는, 그에 의해 활동 모델(1300)이 선택될 수 있는 친근한 명칭이 부여될 수 있다.

도 14는 구성 가능한 액션들을 통해 활동 모델을 구현하는 예시적 방법(1400)을 나타낸다. 1412에서는, (예를 들어, 인간 액터로부터) 활동 모델을 구동하기 위한 요청이 (예를 들어, 워크플로우 서비스의 클라이언트 소프트웨어를 통해) 수신된다. 1422에서는, 활동 흐름의 구성 가능한 액션들이 활동 모델 정의에 기초해 인스턴스화된다. 1432에서는, 활동 흐름 정의에 기초해 액션들이 활동 흐름으로 구성된다. 예를 들어, 액션들의 시퀀스는, 액션의 완결시에, 활동 흐름의 후속 액션이 실행되도록, 활동 모델에 의해 정의될 수 있다.

<제13 실시예>

액션들의 임시 선택을 위한 예시적 구성 가능성

여기에 설명되어 있는 실시예들 중 어디에서든, 하나 이상의 액션들은 인간 액터에 의해 임시 기반의 활동 흐름을 형성하도록 액션들의 세트로 구성될 수 있다. 예를 들어, 인간 액터는 인스턴스화를 위한 액션을 선택할 수 있다. 원한다면, 인간 액터에 의해 인스턴스화된 액션에 미리 정해진 환경들을 위해 적절한 다양한 파라미터들이 (예를 들어, 전자 형태를 통해) 제공될 수 있다.

도 15는, 한 세트의 액션들(1522 및 1552)이 임시 기반으로 구성된 예시적인 활동 흐름(1500)을 나타낸다. 본 실시예에서, 사용자는 검토 액션(1522)을 인스턴스화하도록 선택되었는데, 이로 인해, 타깃 액터에 대해 태스크가 생성된다. 본 실시예에서, 태스크는, 타깃 액터가 항목(예를 들어, 첨부 문서)을 검토해야 한다는 것을 지시하는, 사용자 인터페이스(1532)의 형태로 타깃 액터에 대해 스스로를 명시한다. 타깃 액터는 항목을 승인(1534)하거나 거절(1536)할 것을 선택할 수 있다. 주석들(1538)이 제공될 수 있다. 실제로는, 좀더 포괄적이거나 다른 사용자 인터페이스들이 제공될 수 있다.

그러나, 본 실시예에서, 타깃 액터는 원하는 시간에 항목을 검토하지 않았다. 따라서, 액터(예를 들어, 검토 액션(1522) 또는 다른 액션을 인스턴스화할 것을 선택한 동일 액터)는 활동 흐름의 실행시에(예를 들어, 활동 흐름이 완결되기 전에) 확대 액션(1552)을 추가할 것을 선택했다. 따라서, 새로운 액션(1552)이 인스턴스화되어 활동 흐름(1500)에 배치된다. 그 결과, 태스크는 다른 타깃 사용자에게 재할당된다. 원한다면, 인터럽트 메시지가 검토 액션(1522)으로 송신될 수 있는데, 이것은 적절한 단계들(예를 들어, 제1 타깃 액터에 대해 태스크를 취소하는 단계)을 취할 수 있다.

새로운 태스크의 결과로서, 타깃 액터에 대해 새로운 사용자 인터페이스(1562)가 나타난다. 역시, 사용자 인터페이스는 요소들(1564, 1566, 및 1568)을 포함할 수 있다.

도시된 액션들은 예시일 뿐이다. 실제로는, 제한들의 관점에서 광범위한 임시 액션들이 제공될 수 있다.

도 16은 임시 활동 흐름들을 구현하기 위한 예시적인 방법(1600)을 나타낸다. 1612에서는, 활동 흐름의 실행시에 활동 흐름에 액션을 추가하기 위한 요청이 수신된다. 1622에서는, 액션이 활동 흐름의 실행시에 활동 흐름으로 구성된다.

<제14 실시예>

활동 모델에 임시 액션들을 추가하기 위한 예시적 구성 가능성

선험적 활동 흐름의 실행 및 활동 흐름들의 임시 구성을 위한 활동 모델들을 지원하는 것에 부가하여, 워크플로우 서비스는 임시 기반의 활동 모델에 기초해 활동 흐름들에 액션들을 추가하는 것을 지원할 수 있다.

도 17은, 액션(1788)이 임시 기반으로 추가된 활동 모델에 기초한 예시적 활동 흐름(1700)을 나타낸다. 본 실시예에서는, 활동 흐름이 활동 모델의 인스턴스이며, 액션들(1722, 1724, 1726, 1728, 및 1730)을 포함한다. 액션(1788)의 추가에 기초해, 실행 흐름이 변경될 수 있다. 액터들이 표시되지는 않았지만, 액션들은 (예를 들어, 태스크들을 할당하기 위해) 액터들로 방향 지정될 수 있다.

도 18은 임시 기반의 활동 모델에 기초해 활동 흐름에 활동들을 추가하는 예시적인 방법(1800)을 나타낸다. 1812에서는, (예를 들어, 제한들에 기초해) 이용가능한 임시 액션들이 판정된다. 예를 들어, 이용가능한 액션들은 선택을 위한 인간 액터로의 제시를 위해 클라이언트 소프트웨어로 송신될 수 있다.

1822에서는, 미리 정해진 임시 액션의 지시가 수신된다. 예를 들어, 클라이언트 소프트웨어는, 사용자가 어떤 옵션을 선택했는지를 지시할 수 있다.

1832에서는, 임시 액션이 활동 흐름으로 구성된다. 워크플로우 서비스의 추적 서비스는, 새로운 액션이 추가되었으며 어떤 액터가 그것을 추가했는지를 지시하도록 업데이트될 수 있다.

<제15 실시예>

태스크들을 위한 예시적 임시 액션들

임시 액션들의 특수한 태스크-특정 세트가 태스크들에 대해 이용 가능해질 수 있다. 이러한 임시 액션들은, (예를 들어, 임시 액션들이 관련된 활동 모델에 나타나지는 않았지만) 태스크가 관련될 때마다 액터에 의한 선택을 위해 제시될 수 있다. 이러한 임시 액션들은 제한들에 기초해 선택적으로 제시될 수 있다.

태스크들을 위한 예시적 임시 액션들은 확대, 위임 등을 포함한다. 예를 들어, 태스크가 제시될 때, 액터에게는 태스크를 확대 또는 위임시키기 위한 옵션이 제시될 수도 있다. 이러한 옵션이 이용가능한지의 여부 및 가능한 타깃들은 제한들에 의해 제어될 수 있다. 이러한 옵션들은 활동 흐름의 진행에 대한 그래픽 표현으로 제시될 수도 있다. 이런 식으로, 진행을 모니터링하는 액터는 확대 또는 위임에 의해 실행을 용이하게 이동시킬 수 있다.

태스크와 관련된 이러한 임시 액션들을 특정하는 능력은, 워크플로우 프로세싱이 예기치 못한 환경들에 좀더 잘 반응할 수 있게 하기 때문에, 워크플로우 서비스를 좀더 유용하게 할 수 있다.

<제16 실시예>

사용자 식별 정보에 기초한 예시적 제한들

도 19는, 워크플로우 서비스(1912)가 액터 식별 정보에 기초해 제한들을 지원하는 예시적 구성(1900)을 나타낸다. 본 실시예에서, 인간 액터는 워크플로우 서비스(1912)의 액터(1922)로써 표현된다.

정의된 제한들(1914)은, 액터(1922)(즉, 소스 액터)가 인스턴스화를 위해 액션(1931)을 선택할 수 있는지의 여부 및 어떤 타깃들(1934)이 선택될 수 있는지를 판정할 것이다. 판정은 액터(1922)의 식별 정보에 기초할 수 있다. 이러한 식별 정보 고려들은 액터의 사용자 이름, 액터가 어떤 그룹(들)의 멤버인지, 그리고 액터(1922)가 어떤 역할(들)의 멤버인지를 포함할 수 있다. 또한, 상대적 제한은, 액터(1922)가 다른 액터와 관련이 있다는 것을 특정할 수 있다.

또한, 제한들(1914)은, 어떤 타깃 액터들(1934)이 액션(1931)에 대해 특정될 수 있는지를 판정할 것이다. 타깃 액터(1934)는 단일 액터, 그룹, 또는 미리 정해진 다른 명칭일 수 있다. 다양한 제한들이 (예를 들어, 액션의 정의와 관련된 액션 ID를 통해) 액션을 (예를 들어, 특정 인스턴스화 액터에 대해) 허용된 인스턴스화 액터들 및 타깃 액터들과 관련지을 수 있다.

실제로, 제한들은, 액터(1922)와 관련된 인간 액터만이 제한들(1914)에 의해 지시되는 적절한 옵션들을 볼 수 있도록, 구현될 수 있다. 이런 식으로, 인간 액터는 지나치게 많은 선택들에 의해 압도되지 않으며 워크플로우 프로세싱 동안 안내된다.

도 20은 액터 제한들에 기초해 액션 및 타깃 옵션들을 표현하는 예시적 방법(2000)을 나타낸다. 2012에서는, 액터 식별 정보에 기초해 가능한 액션들이 제시된다. 2022에서는, 액터 식별 정보에 기초해 가능한 타깃 액터들이 제시된다. 실제로, 워크플로우 서비스는, (예를 들어, 픽 리스트, 라디오 버튼들, 콤보 박스 등으로부터) 선택들을 수신할 수 있는 클라이언트 소프트웨어에 의한 제시를 위해 옵션들을 제시하는 것에 의해 이러한 제시를 제어할 수 있다.

<제17 실시예>

예시적인 이행 액션들

워크플로우는 이행 액션들을 위한 제한들을 지원할 수도 있다. 이행 액션들은, 통상적으로 이미 타깃 액터들과 관련된, 다른 액션들에 적용될 수 있는 액션들을 포함한다. 이행 액션들의 예들은 위임 및 확대를 포함한다.

도 21은, 워크플로우 시스템(2112)이 제한들을 이행 액션들에 적용하는 예시적 구성(2100)을 나타낸다. 본 실시예에서, 액션(2131)은 타깃 액터(2134) 또는 액터에 대해 "정해진 것"에 이미 적용되었다. 액터(2122; 즉, 소스 액터)는 이행 액션(2144)을 액션(2131)에 적용하는 중이다.

이행 액션(2144)이 액터(2122)에 대한 옵션으로 나타날 것인지의 여부는 제한들(2114)에 의존할 것이다. 이러한 판정은 액터(2122)의 식별 정보, 이행 액션(2144)의 유형, 액션(2131)의 유형, 액터에 대해 정해진 것(2134), 또는 이들의 미리 정해진 조합에 기초할 수 있다. 마지막으로, 허용된 타깃들(2148)은 (예를 들어, 동일한 고려들 또는 옵션이 나타날 것인지의 여부에 대한 고려들의 다른 조합들에 기초해) 제한들(2114)을 통해 제어될 수 있다.

도 22는 사용자에 대해 정해진 것에 기초해 가능한 액션들 및 가능한 타깃들을 제시하는 예시적 방법을 나타낸다. 2212에서는, 적어도 액터에 대해 정해진 것에 기초해 가능한 액션들이 제시된다. 2222에서는, 적어도 액터에 대해 정해진 것에 기초해 가능한 타깃들이 제시된다.

상대적인 제한들이 시나리오들 중 어디에서든 사용될 수 있다. 예를 들어, 액터는 액터 등에 의해 관리되는 액터들에 대해서만 미리 정해진 이행 액션을 수행하도록 제한될 수도 있다.

<제18 실시예>

예시적인 추적

도 23은, 워크플로우 서비스(2312)가 추적을 지원하는 예시적 구성(2300)을 나타낸다. 본 실시예에서, 워크플로우 서비스(2312)는 하나 이상의 활동 흐름들(2322A-2322N)의 실행을 지원한다. 흐름들을 실행하는 것에 관한 정보는 이후의 검색을 위해 추적 데이터베이스(2332)에 저장될 수 있다. 예를 들어, 액션들로의 메시지들 및 액션들로부터의 메시지들에 대한 지시들은, 메시지들을 지시하는 정보를 인터럽트하여 저장하는 통상적인 인터셉터를 사용하는 것에 의해, 저장될 수 있다. 또한, 워크플로우 프로세싱의 진행을 지시하는 상태 보고들의 구성을 위해, 다른 정보도 저장될 수 있다.

도 24는 구성 가능한 액션들의 활동 흐름에 대한 상태를 추적하는 예시적인 방법(2400)을 나타낸다. 2412에서는, 구성 가능한 액션으로의 메시지 또는 구성 가능한 액션으로부터의 메시지가 인터럽트된다. 2422에서는, 메시지의 지시가 추적 데이터베이스에 저장된다.

<제19 실시예>

워크플로우 상태의 예시적인 묘사

도 25는 추적(예를 들어, 수집된 메시지들)에 기초한 워크플로우 상태의 그래픽 표현을 제시하는 예시적인 사용자 인터페이스(2500)를 나타낸다. 본 실시예에서, 다양한 박스들(2521, 2522, 2523, 2524, 2525, 및 2526)은, 태스크들을 할당한 또는 태스크들이 할당된, 워크플로우 프로세싱(예를 들어, 활동 흐름)에 참가하고 있는 액터들을 지시한다. 또한, 사용자 인터페이스(2500)는 액터들 간의 통신을 표현할 수 있다. 예를 들어, 화살표(2534)는, Julian이 문서를 승인해다는 지시를 포함할 수 있다. 이러한 지시들은 텍스트, 아이콘 등일 수 있다. 다른 화살표(2532)는, 태스크가 확대되었다는 지시를 포함한다.

도 26은 활동 흐름 상태를 표현하는 예시적 방법(2600)을 나타낸다. 2612에서는, 추적 저장 장치가 조회된다. 2622에서는, 조회 결과들에 기초해, 활동 흐름이 시각적으로 묘사된다.

실제로는, 광범위한 사용자 인터페이스들이 제시될 수 있다. 또한, 사용자 인터페이스는, 인간 액터들이 워크플로우를 모니터링할 때 워크플로우에 참가할 수 있는 추가 옵션들을 제시할 수 있다. 예를 들어, 옵션을 확대시키거나 인터럽트하기 위한 옵션이 제시될 수 있다.

<제20 실시예>

웹 서비스로서의 예시적인 구현

여기에서 설명된 실시예들 중 어디에서든, 워크플로우 서비스들은 웹 서비스로서 클라이언트들에게 제시될 수 있다. 예를 들어, 사용자 인터페이스들은, 클라이언트에 의해 렌더링될 수 있는, HTML의 형태로 제공될 수 있다.

<제21 실시예>

예시적인 침투성 인터페이스 기술들

여기에서 설명된 실시예들 중 어디에서든, 워크플로우 서비스는 침투성 사용자 인터페이스(pervasive user interface)를 통해 이용될 수 있다. 예를 들어, 워크플로우 서비스를 위한 사용자 인터페이스는, 이메일 프로그램 또는 워드 프로세싱 프로그램과 같은, 일반 소프트웨어 프로그램들로 통합될 수 있다. 이런 식으로, 보통의 익숙한 소프트웨어가 워크플로우 서비스를 위한 클라이언트로서 사용될 수 있다. 통신은 (예를 들어, SOAP 프로토콜에 따라) XML 메시지들을 송신하는 것에 의해 실현될 수 있고, 사용자 인터페이스들은 HTML을 통해 묘사될 수 있다.

도 27은, 워크플로우 서비스가 이메일 프로그램의 사용자 인터페이스의 일부로서 제시되는 예시적인 사용자 인터페이스(2700)를 나타낸다. 본 실시예에서, 이메일 프로그램은 익숙한 폴더 리스트(2712) 및 수신함(2722)을 포함한다. 수신함의 일부로서, 태스크가 표시된다. 선택될 경우, 이메일의 미리보기가 미리보기 창(2762)에 나타난다.

사용자 인터페이스는, 타깃 액터(예를 들어, 이메일을 검토 중인 사용자)에 대한 태스크가 예산 문서를 검토하는 것이라는 것을 지시한다. 사용자 인터페이스 요소들(2764, 2766, 및 2768)은 워크플로우 서비스를 역통신하는데 사용될 수 있다. 예를 들어, 푸시버튼(2764)의 활성화시에, 메시지는 타깃 액터에 대해 태스크를 개시했던 액션으로 역송신된다. 다음으로는, 관련된 활동 흐름에 의해 적절한 단계들이 취해질 수 있다.

창(2762) 대신에, 도 28의 창(2800)이 표시될 수 있다. 본 실시예에서는, 하부-창(2862)의 표준 태스크 옵션들(예를 들어, 사용자 인터페이스 요소들(2864, 2866, 및 2868))에 추가하여, 임시 액션들을 위한 옵션들(예를 들어, 사용자 인터페이스 요소 2876)이 하부-창(2872)에 나타난다.

도 29는 침투성 워크플로우 사용자 인터페이스를 통해 선택들을 표현하고 수용하는 예시적 방법(2900)을 나타낸다. 2912에서는, 워크플로우-관련 사용자 인터페이스가 침투성 애플리케이션에 제시된다. 2922에서는, 사용자(예를 들어, 인간 액터) 선택이 사용자 인터페이스를 통해 수신된다.

도 30은, 워크플로우 서비스에 액세스하기 위한 사용자 인터페이스 요소들이 문서 편집(예를 들어, 워드 프로세싱 또는 스프레드시트) 프로그램으로 통합되어 제시되는 사용자 인터페이스(3000)를 나타낸다. 본 실시예에서, 문서는 문서 창(3062)에 제시된다. 문서 창(3062) 옆에 워크플로우 옵션들(3072)이 나타난다. 본 실시예에서, 임시 액션들은, 그에 의해 액터가 액션 및 타깃 액션을 선택할 수 있도록, 표시된다. 액션의 개시는 사용자 인터페이스 요소(3076)를 통해 실현될 수 있다. 실제로는, (예를 들어, 편집 중인 문서를 승인하기 위해) 추가적이거나 상이한 옵션들이 제시될 수 있다.

<제22 실시예>

예시적인 발견 가능성

도 31은, 그에 의해 액션(3136)을 활성화하기 위한 활성화 파라미터들의 스펙이 획득될 수 있는, 예시적인 구성(3100)을 나타낸다. 본 실시예에서, 클라이언트 소프트웨어(3134; 예를 들어, 액션, 워크플로우 서비스, 또는 미리 정해진 여타 소프트웨어)는 액션(3136)으로 조회를 송신하는데, 조회는 액션을 활성화하기 위한 파라미터들의 스펙(예를 들어, 액션(3136)의 개발자에 의해 특정된 파라미터 리스트)으로 응답한다. 실제로는, 액션(3136)이 아직 인스턴스화되지 않았기 때문에, 조회(예를 들어, 액션 유형을 특정하는 것)는, 각각이 활성화 파라미터 스펙을 판정하기 위한 파라미터들 및 액션 유형들의 리스트를 조회할 수 있는, 워크플로우 서비스에 의해 처리될 수 있다.

스펙은, 파라미터들이 수집될 수 있는 HTML 형태로 제공되거나 HTML 형태로 변환될 수 있다. 예를 들어, 검토 액션은, 타깃들이 제공되어야 하며 그에 따라 액터에 의한 완결을 위해 적절한 HTML 형태를 발생시켜야 한다는 것을 특정할 수 있다. 제한들은 적절한 타깃 액터들을 채우는데 사용될 수 있다.

도 32는, 액션을 위해 활성화 파라미터 스펙을 발견하기 위한 예시적인 방법(3200)을 나타낸다. 3212에서는, 활성화 파라미터 스펙에 대한 조회가 수신된다. 3222에서는, 조회에 응답하여 스펙이 제공된다.

활동 모델에 대한 파라미터 스펙의 발견 가능성을 위해 유사한 접근 방법이 사용될 수 있다. 발견 가능성은 액션 또는 활동 흐름의 실행시에 수행될 수 있다.

<제23 실시예>

예시적인 액션 템플릿

액션들의 개발을 용이하게 하기 위해, 개발자들에게 템플릿이 제공될 수 있다. 도 33은 템플릿 액션 정의(3314)를 수반하는 예시적인 구성(3300)을 나타낸다. 템플릿은 비주얼 프로그래밍 언어로 편집된 다음 액션에 대해 적절한 실행 가능 코드를 발생시킬 수 있다.

본 실시예에서, 액션의 인터페이스들은 핀들(3322, 3324, 3326, 및 3328)에 의해 표현될 수 있다. 템플릿은 활성화 인터페이스(3322)에 의한 할성화 메시지의 수신을 책임진다. 액션에 의해 캡슐화된 활성화 로직(3332)은 활성화 메시지를 수신하고, 액션 템플릿에 의해 수신된 다른 메시지들을 상관짓는 값들을 초기화하기 위해, 활성화 응답 메시지를 활성화 로직(3332)으로 역루핑한다.

또한, 템플릿(3314)은 의존적인 구성(예를 들어, 동기화 시나리오들)을 책임진다. 예를 들어, 동기화 로직(3342) 및 청취 로직(3344)은 병렬로 실행될 수 있다. 액션이 의존적인 방식으로 구성되었다면(예를 들어, 그것의 추가적인 실행이 다른 액션으로부터의 메시지 수신에 의존한다면), 동기화 로직(3342)은, 동기화 인터페이스(3324)로부터 메시지가 수신될 때까지, 실행을 블로킹할 수 있다.

병행하여, 청취 로직(3344)은 인터럽트 또는 종료 메시지들을 청취할 수 있다. 인터럽트 메시지가 인터럽트 인터페이스(3326)로부터 수신되면, 인터럽트 로직(예를 들어, 복귀 상태)이 실행될 수 있다.

블로킹되지 않거나 언블로킹되면, 액션-특정 프로세싱(예를 들어, 비지니스 로직; 3352)이 실행될 수 있다. 마지막으로, 종료 로직(3362)이 실행될 수 있고, 종료 메시지가 종료 인터페이스(3328)로 송신될 수 있다. 메시지는 청취 로직(3344)에서의 액션에 의해 수신되고 또한 병렬 분기를 완결시킨다.

실제로는, 추가적이거나 다른 로직이 포함될 수 있다. 개발이 완결된 후에, 워크플로우 서비스에 액션 정의가 설치될 수 있고 적절한 제한들이 액션과 관련된 것으로 정의될 수 있다.

<제24 실시예>

워크플로우 기술들의 예시적인 실행

도 34, 도 35, 도 36, 및 도 37은 워크플로우 기술들의 예시적인 실행을 나타낸다. 본 실시예에서, 고객은, RFP(request for proposal)에 대한 응답을 조정하기 위한 전문가들의 팀을 거느린, 계정 관리자에게 RFP를 송신한다.

도 34는 관련된 액터들을 나타낸다. 고객(3410)은 계정 관리자(3420)에게 RFP 문서를 (예를 들어, 이메일을 통해) 송신한다. 예를 들어, 문서는 워드 프로세싱 문서일 수 있다. 계정 관리자는 RFP에 응답하는데 필요한 프로세싱을 완결짓기 위해 전문가들(3430A-3430D)에게 태스크들을 송신할 수 있다.

도 35 내지 도 37은 예시적인 스크린 샷들을 나타낸다. 도 35는, 계정 관리자에 의해 고객으로부터 이메일이 수신된 예시적인 이메일 프로그램(3510)을 나타낸다. 이메일에 포함되어 있는 것은 이메일 첨부(3530) 형태의 RFP 문서이다. 본 실시예에서, 계정 관리자는 이메일(3520)을 이메일 에일리어스(email alias; 예를 들어, "RFP Approval")로 전달하는 것에 의해 활동 모델에 기초한 활동 흐름을 시작할 수 있다. 이메일 소프트웨어는 활동 모델에 기초한 활동 흐름을 시작하기 위해 이메일 프로세싱 규칙들에 기초해 이메일을 프로세싱할 수 있는데, 이것은 전문가들(3430A-3430D)에 대한 적절한 태스크들을 발생시키며 태스크의 일부로서 첨부(3530; 또는 첨부로의 링크)를 포함할 수 있다.

도 36은, 태스크와 관련된 문서가 개방될 때, 전문가들(3430A-3430D) 중 하나에게 제시되는 예시적인 사용자 인터페이스를 나타낸다. 사용자 인터페이스는 익숙한 문서 편집(예를 들어, 워드 프로세싱) 프로그램(3610)일 수 있는데, 이것은 (예를 들어, 첨부(3530)에 기초해) 문서(3620)를 제시한다.

또한, 사용자 인터페이스는, 전문가들(3430A-3430D) 중 하나로 하여금 태스크를 다른 액터로 확대시키거나 위임할 수 있게 하는 창(3630)을 포함할 수도 있다. 본 실시예에서, 뷰잉 액터는 태스크를 액터 "Kerri"에게 위임하며 사용자 인터페이스 요소(3635)를 활성화한다.

워크플로우 기술들의 추적 사양으로 인해, 표현(3700)은 상술된 워크플로우의 상태를 나타낼 수 있다. 고객 Peter(3721)는 이메일을 송신하는 것에 의해 워크플로우를 개시했다. 예를 들어, 이메일을 수동으로 전달하는 대신에, 액터 Jenny(3722)는 메시지 주제에서 "New RFP"를 검출하는 것에 기초해 활동 모델을 자동적으로 시작하도록 그녀의 이메일 수신함에 규칙을 설정할 수도 있다. 전문가들(3723-3725)은 검토를 위한 RFP를 수신했다. Julian(3723)은 RFP를 승인했고, Michael(3725)은 그의 태스크를, 지시자(3732)에 의해 지시되는 바와 같이, Kerry(3726)에게 위임했다.

<제25 실시예>

태스크의 예시적인 통지

도 38은, 태스크가 수신 액터에게 할당될 때 (예를 들어, 이메일을 통해) 송신되는 예시적인 통지의 스크린 샷(3800)을 나타낸다. 통지는, 태스크에 응답하는 방법에 관한 지시들을 제시할 수 있다. 통지는 문서로의 하이퍼링크 및 태스크로의 하이퍼링크를 포함할 수 있다.

<제26 실시예>

메시지 유형들을 위한 예시적 스키마들

다양한 메시지 유형들에 대한 예시적 스키마들이 다음에 표시되어 있다. 메시지 유형들은 활성화, 응답 활성화, 동기화, 태스크, 종료, 및 인터럽트를 포함할 수 있다. 실시예들 중 일부는, 스키마에 상응하려는 목적들을 위해 스키마가 변경되지 않아야 한다는 것을 지시하지만, 다른 구현들은 유사한 기능을 실현하는 스키마들의 상이한 세트를 사용할 수 있다. 예를 들어, 본 실시예들에서는 GUID들이 특정되어 있지만, 대신에 다른 식별자들(예를 들어, 고유한 다른 식별자)이 사용될 수 있다. 본 실시예들에서는, 워크플로우 시스템을 때때로 HWS(human workflow system)라고 한다.

<제27 실시예>

활성화 메시지 유형을 위한 예시적 스키마

Hws_Activate 메시지는 액션의 활성화 동안 액션에 파라미터들을 공급하는데 사용되는 예시적인 활성화 메시지이다. 액션은 액션과 관련된, 많아야 하나의 활성화 메시지 스키마를 가질 수 있다. 본 실시예에서는, Hws_Activate 메시지가 HwsMessage 노드하에 3개의 자식 요소들을 갖는다. 이들은 HwsSection, ActionSection, 및 Payloads이다. 이들은 다음과 같이 설명된다.

HwsSection: HwsSection은 HWS 시스템에 의한 사용을 위해 보존되어 있는 XML 요소들 및 속성들의 정의들을 보유한다. 이 섹션하에 정의된 요소들 또는 속성들은 변경될 수 없다. 표 2는 HwsSection 노드하에 정의되어 있는 요소들/속성들의 예시적인 리스트를 나타낸다.

† 이러한 특성들은 템플릿에서의 참조 및 사용을 위해 디폴트로 장려된다.

ActionSection: ActionSection은 액션 개발자들에 의해 개별화될 수 있고 인스턴스화 동안 액션으로 전달될 임의의 액션 특정 파라미터들 및 값들을 포함할 수 있다. 이 섹션은 액션을 위한 인간 타깃들에 대응되는 요소들을 포함할 수도 있다. ActionSection의 요소들/속성들에 대한 값들은 Hws 인터셉터에 의해 추적되지 않는다. 추적되어야 하는 특성들이 필요하다면, 사전-정의된 HwsSection＼ActionProperties 수집하의 인스턴스 문서에서 이들을 특정한다.

Payloads: 스키마의 Payloads 노드는, 애플리케이션들이 액션에 의해 송신된 다른 메시지들에 포함되어야 할 수 있는 추가 정보를 특정하는 위치 보유자이다.

○ Annotations: 활성화 메시지 스키마는 Hws 시스템에 의해 사용되는 주석들을 전달한다. 스키마 루트 노드 레벨에서 정의되는 일부 특성들이 존재하며 일부는 요소 노드 레벨에서 정의된다.

■ 스키마 노드 특성들: 다음의 특성들은 스키마 노드 레벨에서 정의된다.

● Description: 이 특성의 값은 활성화 메시지와 관련되어 있는 액션을 설명하는데 사용된다.

● Incoming Sync 메시지들: 이 특성은, 활성화 메시지와 관련된 통합에 의해 수신되는 동기화 메시지들의 타깃 이름 공간을 특정한다.

● Outgoing Sync 메시지들: 이 특성은, 활성화 메시지와 관련된 통합에 의해 송신되는 동기화 메시지들의 타깃 이름 공간을 특정한다.

■ 요소 노드 특성들: 스키마 문서의 ActionSection 요소에 따라 정의된 요소 노드들에 대해, Hws는 다음의 특성을 정의한다.

● Target: 이것은 불 특성(Boolean property)이다. 참 값은, 요소 노드가 활성화 메시지와 관련된 액션에 의해 송신되는 하나 이상의 메시지들의 수신자인 인간 타깃이라는 것을 지시한다. 거짓 값 또는 값이 특정되지 않으면, 노드가 인간 타깃이 아니라는 것을 지시한다.

각각의 활성화 메시지 스키마는, 채택된 스키마들의 세트내에서 고유하게 그것을 식별하는 타깃 이름 공간을 가질 수 있다.

<제28 실시예>

응답 활성화 메시지 유형을 위한 예시적 스키마

Hws_ActivateResponse 메시지는, 템플릿에서 다른 메시지들을 수신하는데 사용되는 상관 변수들의 세트를 초기화하기 위해 액션 템플릿에 의해 내부적으로 사용되는 예시적인 활성화 응답 메시지이다.

Hws_ActivateResponse 메시지는 HwsMessage 노드하에 단 하나의 자식 요소만을 갖는다. 이것이 HwsSection이다. 이것은 다음과 같이 설명된다.

HwsSection: HwsSection은 Hws 시스템에 의한 사용을 위해 보존되어 있는 xml 요소들 및 속성들의 정의들을 보유한다. 이 섹션하에 정의된 요소들 또는 속성들은 변경될 수 없다. 표 3은 HwsSection 노드하에 정의되어 있는 요소들/속성들의 예시적인 리스트를 나타낸다.

† 이러한 특성들은 액션 템플릿에 의해 사용되는 상관 세트들을 초기화하기 위한 디폴트로 장려된다.

○ Annotations: 응답 활성화 메시지 스키마는 메시지 설명을 위한 주석을 갖는다. 이러한 주석을 위한 값은 편집에 이용될 수 없다.

이 스키마의 TargetNamespace는 URL(예를 들어, http://[base] /Hws_ActivateResponse)을 통해 정의된다. 이 스키마는 어셈블리(예를 들어, DLL)로 컴파일될 수 있고 액션 템플릿에 의해 참조된다. 메시지는 액션으로 구되고 다이렉트-바운드 포트(direct-bound port)를 통해 송수신된다.

<제29 실시예>

동기화 메시지 유형을 위한 예시적 스키마

Hws_Synchronize 메시지는, 수신 중인 액션의 실행을 블로킹하기 위해 하나의 액션에서 다른 액션으로 송신되는 예시적인 동기화 메시지이다. 수신 중인 액션 인스턴스는, 동기화 메시지를 대기할 수 있도록 참으로 설정되어 있는, 그것의 활성화 메시지에서의 IsDependentOnParent 특성으로 활성화되었을 것이다.

Hws_Synchronize 메시지는 HwsMessage 노드하에 3개의 자식 노드들을 갖는다. 이들은 HwsSection, ActionSection, 및 Payloads이다. 이들은 다음과 같이 설명된다.

HwsSection: HwsSection은 Hws 시스템에 의한 사용을 위해 보존되어 있는 xml 요소들 및 속성들의 정의들을 보유한다. 이러한 섹션하에 정의된 요소들 또는 속성들은 변경될 수 없다. 표 4는 HwsSection 노드하에 정의되어 있는 요소들/속성들의 예시적인 리스트를 나타낸다.

† 이러한 특성들은 액션 템플릿에서의 참조 및 사용을 위해 디폴트로 장려된다.

ActionSection: ActionSection은 액션 개발자들에 의해 개별화될 수 있고, 수신 중인 액션으로 전달될 임의의 시나리오 특정 파라미터들 및 값들을 포함할 수 있다.

Payloads:

○ Annotations: 동기화 메시지 스키마는 메시지의 설명을 위한 주석을 갖는다. 이 특성은 스키마 루트 노드 레벨에서 정의된다.

■ 스키마 노드 특성들: 다음의 특성들은 스키마 노드 레벨에서 정의될 수 있다.

● Description: 이 특성의 값은 동기화 메시지를 설명하는데 사용된다.

각각의 동기화 메시지 스키마는, 채택된 스키마들의 세트내에서 그것을 고유하게 식별하는 타깃 이름 공간을 가져야 한다. 동기화 메시지의 TargetNamespace이 변경되거나 새로운 동기화 메시지 스키마가 액션에 추가된다면, (이러한 동기화 메시지를 송신하거나 수신하는 액션의) 활성화 메시지상의 Incoming Sync 메시지들 및 Outgoing Sync 메시지들의 특성들 또한 업데이트되어야 한다. 동기화 메시지들은 다이렉트-바운드 포트들을 통해 송수신된다.

<제30 실시예>

태스크 메시지 유형을 위한 예시적 스키마

Hws_Task 메시지 스키마는 액션의 참가 타깃들로 송신되는 메시지들에 사용되는 예시적인 스키마이다. 액션은 하나 이상 유형들의 태스크 메시지들을 송신할 수 있다. 액션은 미리 정해진 태스크 메시지 유형의 하나 이상의 인스턴스들을 송신할 수도 있다. Hws_Task 메시지는 액션으로 응답들을 역제출하는데도 사용될 수 있다.

Hws_Task 메시지는 HwsMessage 노드하에 3개의 자식 요소들을 갖는다. 이들은 HwsSection, ActionSection, 및 Payloads이다. 이들은 다음과 같이 설명된다.

HwsSection: HwsSection은, Hws 시스템에 의한 사용을 위해 보존되어 있는 xml 요소들 및 속성들의 정의들을 보유한다. 이러한 섹션하에 정의된 요소들 또는 속성들은 변경될 수 없다. 표 5는 HwsSection 노드하에 정의되어 있는 요소들/속성들의 예시적인 리스트를 나타낸다.

ActionSection: ActionSection은 액션 개발자들에 의해 개별화될 수 있고 참가 중인 타깃들로 전달된 임의의 액션 특정 파라미터들 및 값들을 포함할 수 있다. 이것은, 타깃들이 그들의 응답들에 공급할 수 있는 임의의 파라미터들을 정의하는데도 사용될 수 있다.

Payloads: 스키마의 Payloads 노드는, 애플리케이션들이 액션에 의해 송신된 다른 메시지들에 포함되어야 할 수 있는 추가 정보를 특정하는 위치 보유자이다.

○ Annotations: 태스크 메시지 스키마는 Hws 시스템에 의해 사용되는 주석들을 전달한다. 이러한 특성들은 스키마 루트 노드 레벨에서 정의된다.

■ 스키마 노드 특성들: 다음의 특성들은 스키마 노드 레벨에서 정의될 수 있다.

● Description: 이 특성의 값은 태스크 메시지 스키마를 설명하는데 사용된다.

● Target XPath: 이 특성은, 이러한 태스크 메시지가 진행하는 사람에 대한 활성화 메시지의 타깃 노드들의 XPath들을 특정한다.

각각의 태스크 메시지 스키마는, 채택된 스키마들의 세트내에서 고유하게 그것을 식별하는 Target Namespace를 가져야 한다.

<제31 실시예>

종료 메시지 유형을 위한 예시적 스키마

Hws_Finish 메시지는 액션에 의해 내부적으로 사용되는 예시적인 종료 메시지이고 액션이 실행을 완결할 때 송신된다. Hws_Finish 메시지는 HwsMessage 노드하에 단 하나의 자식 요소를 갖는다. 이것이 HwsSection이다. 이것은 다음과 같이 설명된다.

HwsSection: HwsSection은 Hws 시스템에 의한 사용을 위해 보존되어 있는 xml 요소들 및 속성들의 정의들을 보유한다. 이 섹션하에 정의된 요소들 또는 속성들은 변경될 수 없다. 표 6은 HwsSection 노드하에 정의되어 있는 요소들/속성들의 예시적인 리스트를 나타낸다.

○ Annotations: 응답 활성화 메시지 스키마는 메시지의 설명을 위한 주석을 갖는다. 이러한 주석에 대한 값은 편집에 이용될 수 없다.

이러한 스키마의 TargetNamespace는 URL(예를 들어, http://[base] /Hws_Finish)을 통해 정의될 수 있다. 이러한 스키마는 어셈블리(예를 들어, DLL)로 컴파일될 수 있고 액션 템플릿에 의해 참조된다. 메시지는 액션으로 구성되고 다이렉트-바운드 포트를 통해 송/수신된다.

<제32 실시예>

인터럽트 메시지 유형을 위한 예시적 스키마

Hws_Interrupt 메시지는, 액션의 실행 중인 인스턴스를 인터럽트하는데 사용되는 예시적인 인터럽트 메시지이다. 인터럽트 메시지는 별개의 액션 인스턴스, 전체적인 활동 흐름, 또는 전체적인 활동 모델 인스턴스로 송신될 수 있다. 2가지 종류의 인터럽트들 - 중단 및 복귀(abort and rollback)가 존재한다.

Hws_Interrupt 메시지는 HwsMessage 노드하에 단 하나의 자식 요소만을 갖는다. 이것이 HwsSection이다. 이것은 다음과 같이 설명된다.

HwsSection: HwsSection은, Hws 시스템에 의한 사용을 위해 보존되어 있는 xml 요소들 및 속성들의 정의들을 보유한다. 이 섹션하에서 정의된 요소들 또는 속성들은 변경될 수 없다. 표 7은 HwsSection 노드하에서 정의된 요소들/속성들의 예시적 리스트를 나타낸다.

Annotations: 인터럽트 메시지 스키마는 메시지의 설명을 위한 주석을 갖는다. 이러한 주석에 대한 값은 편집될 수 없다.

이러한 스키마의 TargetNamespace는 URL(예를 들어, http://[base] /Hws_Finish)을 통해 정의될 수 있다. 이러한 스키마는 어셈블리(예를 들어, DLL)로 컴파일될 수 있고 액션 템플릿에 의해 참조된다. 인터럽트 메시지의 인스턴스는 템플릿의 ActionInterruptPort를 통해 수신된다. 활동 흐름 레벨 또는 활동 모델 인스턴스 레벨의 인터럽트 메시지가 활동 흐름 또는 활동 모델 인스턴스에서 현재적으로 활성화되어 있는 각각의 액션으로 제출된다. 인터럽트 유형 Abort는 인터럽트된 액션이, 액션에 의해 수행된 작업에 대한 보상없이 종결되게 한다. Rollback 인터럽트 유형은 액션이, 액션에 의해 이미 종결된 작업을 보상할 수 있게 한다.

<제33 실시예>

아키텍처의 예시적 구현

도 39는 워크플로우 서비스(3902)를 포함하는 시스템에 대한 아키텍처의 예시적 구현을 나타낸다. 본 실시예에서, 클라이언트 애플리케이션들(3900)은 워크플로우 서비스(3902)에 영향을 미쳐 액터들로 하여금 워크플로우를 생성하고 워크플로우에 참가할 수 있게 한다. 워크플로우 서비스(3902)는 클라이언트 애플리케이션들에 대해 3개의 주된 서비스들: 워크플로우 구성(3908), 워크플로우 제한들(3906), 그리고 워크플로우 추적 및 뷰잉(3910)을 제공할 수 있다.

워크플로우들은 활동 흐름내에서 액션들(3912)을 구성하는 것에 의해 생성될 수 있다. 액션들(3912)의 구성은, 워크플로우 서비스(3902)에 의해 강제되는 제한들(3914)에 의해 결정된다. 제한들(3914)은, 워크플로우 운영 및 관리(예를 들어, MMC)에 의한 것 또는 프로그램 방식의 운용 API에 의한 것을 포함하여, 임의 갯수의 공지 방법들로 정의될 수 있다.

이러한 제한들(3914)의 정의는 사실 리트리버들(fact retrievers)에 의해 노출되는 사실들에 영향을 미칠 수 있다. 사실 리트리버들은 표준 인터페이스를 구현해, 제한 서비스(3906)가 이러한 사실들을 조회하여 워크플로우에 적용하게 할 수 있다. 사실 리트리버는, Active Directory 또는 SQL 데이터베이스와 같은, 임의의 하부 데이터 소스(3916)로부터 사실들을 노출시킬 수 있다.

클라이언트 애플리케이션들(3904)은, 클라이언트 애플리케이션들(3904)이 활동 흐름에 참가하기를 원할 경우, 워크플로우 서비스(3902)에 등록할 수 있다. 구성 서비스(3908)는 고유한 ID를 클라이언트 요청과 연관지을 수 있고 이 ID를 사용해, 액터가 활동 흐름의 일부로서 수행하는 액션들(3912)을 계속해서 추적할 수 있다.

추적 서비스(3910)는 활동 흐름의 상태에 대한 추적을 유지하고 클라이언트에 의한 요청에 따라 활동 흐름을 재구성하는데 사용될 수 있다. 클라이언트가 활동 흐름에 액션(3912)을 첨부하고자 시도할 경우, 제한 서비스(3906)는, 어떤 액션들(3912)이 활동 흐름에 첨부될 수 있는지를 알아보기 위해 (예를 들어, 사실 저장 장치(3916) 또는 흐름의 상태에 기초해) 제한들을 점검할 수 있다. 예를 들어, 표시되는 옵션들은 제한들하에서 이용가능한 옵션들로 한정될 수 있다. 사용자가 제한된 세트로부터 액션을 선택한 후, 구성 서비스(3908)는 선택된 액션들을 이미 사용 중인 액션들과 함께 구성할 수 있다.

액션들은, 추적 서비스(3910)에 의해 소비되는 추적 이벤트들을 방출하도록 장비될 수 있다. 다음으로, 이러한 이벤트들은 최신 워크플로우를 액터에게 제공하도록 클라이언트에 의해 액세스될 수 있다.

<제34 실시예>

워크플로우 서비스에 액세스하기 위한 사용자 인터페이스의 예시적 구현

도 40은 워크플로우 서비스에 액세스하기 위한 사용자 인터페이스(4000)의 예시적 구현을 나타낸다. 본 실시예에는, 활동 흐름의 그래픽 표현이 도시되어 있고, 사용자에게는 (예를 들어, 액터상에서 바로 클릭하는 것에 의해) 태스크를 확대하기 위한 옵션이 제시된다.

<제35 실시예>

액션들을 구축하기 위한 템플릿의 예시적 구현

도 41은 액션들을 구축하기 위한 예시적 템플릿(4100)을 나타낸다. 본 실시예에서는, 템플릿(4100)이 비주얼 프로그래밍 환경으로 제시되지만, 다른 방법으로 제시될 수도 있다. 템플릿(4100)은 광범위한 시나리오들을 핸들링할 수 있으므로, 개발자들은 특정 시나리오를 위한 로직을 드롭인(drop in)하기만 하면 된다. 예를 들어, 의존적인 구성은 템플릿에 의해 지원될 수 있다.

템플릿(4100)은 활성화 수신기 로직(4110)을 포함할 수 있다. 액션은, HTTP 트랜스포트로 바운딩되는 일방 포트를 통해 활성화 메시지를 수신할 수 있다. 그 다음, 액션은 ActivateResponse 메시지의 인스턴스를 발생시킬 수 있다. 응답 메시지는 이후의 통합에 사용되는 상관 세트들을 초기화하는데 사용된다. 액션은 메시지를 스스로에게로 송신한다. 액션은 ActionDirectBoundOutPort의 SendOrReceiveActivateResponse 운용을 사용해 메시지를 송신하고 ActionDirectBoundOutPort를 사용해 그것을 역수신한다. 템플릿의 섹션(4110)은, ParentActionInstanceID 또는 ActivityModelInstanceID 에 대한 값이 공백 식별자들(예를 들어, 공백 GUID들)인지를 점검할 수도 있다. 그렇다면, 액션은 그러한 특성들에 대해 새로운 식별자 값들을 생성할 수 있다. 인스턴스화 중인 액션이 부모 액션을 갖지 않거나 액션이 활동 모델의 일부로서 인스턴스화되는 것이 아니라면, 값들은 공백 식별자들일 것이다. 이러한 액션 인스턴스들이 많다면, 종료 및 인터럽트 메시지 유형들에 대해 동일한 수의 비고유 가입들(non-unique subscriptions)이 발생될 수 있는데, 이것은 성능에 부정적인 영향을 미칠 수 있다.

새로운 식별자들을 생성하는 것에 의해 이러한 시나리오는 방지되며, 이러한 시나리오들에서는 어떤 식으로든 가입들이 충족되지 않을 것으로 예상되기 때문에, 안전하다. 가입의 고유성은, 유효한 가입자들에 대한 메시지의 라우팅 성능이 저하되지 않는다는 것을 보장한다.

병렬 스테이트먼트(4120)는 2개의 분기들을 갖는다. 왼쪽 분기는 다른 것에 대한 액션의 구성을 허용하고(예를 들어, 4130) 템플릿내에서의 통상적인 개발을 위한 사이트도 제공한다(예를 들어, 4140). 오른쪽 분기는, 액션으로 하여금 인터럽트 및 종료 메시지들을 청취할 수 있게 한다(예를 들어, 4150).

(도 42와 같이 확대되는) 판정 형태(4130)는, 액션이 그것을 다른 액션에 의존적인 것으로 구성할 의도로 활성화되었는지를 확인한다. 4210에서는, 활성화 메시지에서 장려된 특성이 IsDependentOnParent인지를 점검한다. 그렇다면, 액션은 4230에서 부모로부터의 동기화 메시지 또는 종료 메시지의 수신을 대기한다.

동기화 메시지(4250) 또는 종료 메시지(4240)를 위한 수신 형태들은 부모 액션의 인스턴스 ID에 기초한 상관 세트들을 사용한다. 동기화 메시지의 수신시에, 실행은 ScopeAllActionSpecificLogic으로 진행하고 4255에서 개발자에 의해 드롭인된 로직을 실행할 수 있다.

대신 종료 메시지의 수신은, 4245에서 액션이 종결되게 한다. 이러한 경우, 종결되기 전에, 액션은 그것의 종결을 지시하기 위해 다이렉트 바운드 포트를 통해 메시지-박스로 종료 메시지를 송신한다.

동기화 메시지에 사용되는 상관 세트는 활성화 메시지에서 장려된 추가 특성들을 포함하도록 확장될 수 있다. 추가 상관 세트들은 동기화 메시지를 위한 수신 형태(4250)에서도 사용될 수 있다.

동기화 메시지와 동시에 종료 메시지를 청취하는 것은, 부모 액션이 동기화 메시지의 송신없이 끝날 경우에, 의존 액션들을 소거할 수 있게 한다.

통상적인 로직(예를 들어, 비지니스 로직)은 통상적인 개발(4240)을 위한 사이트로 통합될 수 있다. 사이트(4240) 주위에는 정의된 트랜잭션 범위 및 보상 블록이 존재한다. 이로 인해, 액션이 복귀 운용을 요청 중인 인터럽트 메시지를 송신하거나 액션내에서 미지의 예외가 발생할 경우, 통상적인 보상이 구축될 수 있다.

4250은 다수의 가입들에 기초한 인터럽트 메시지의 인스턴스를 청취한다. 자신으로부터의 종료 메시지도 청취한다. 액션은 3가지의 세분 레벨들: 액션 인스턴스 레벨, 할동 흐름 레벨, 및 활동 모델 레벨에서 인터럽트 메시지에 가입한다. 인터럽트 메시지는 액션의 운용들에 대한 중단 또는 복귀를 요청할 수 있다. 인터럽트 메시지의 수신은 액션내에서 Abort 또는 Rollback의 예외를 발생시킨다. 이러한 예외들은 템플릿내에서(예를 들어, 4260에서) 포착되고 예외 핸들러 호출들은 4240에서 ScopeAllActionSpecificLogic 범위를 보상한다.

청취 블록(4250)의 다른 메시지는 자신으로부터의 종료 메시지이다. 이 메시지는 액션 자체에 의해 생성되고 병렬 스테이트먼트(4220)의 왼쪽 분기에서 다이렉트-바운드 포트를 통해 메시지 박스로 송신된다. 메시지는 ScopeAllActionSpecificLogic 범위가 (예를 들어, 4240에서) 완결된 직후에 송신된다. 오른쪽 분기에서의 이 메시지 수신은 청취 형태 ListenForAbortOrFinish를 완결시키며 분기를 종료시킨다.

액션의 섹션(4260)은 Abort, Rollback, 및 Unknown 예외들에 대한 예외 핸들러들을 갖는다. Abort 및 Rollback 예외들은 인터럽트 메시지의 수신시에 액션내에서 발생된다. Abort 예외에 대한 예외 핸들러는, 액션이 완결 중이라는 것을 지시하는 종료 메시지를 구축하여 송신한 다음, 종료 상태로 진입한다. Rollback 예외를 위한 예외 핸들러는, 종료 메시지를 구축하고 송신하기 전에, 보상 블록 CompensateForAllActionSpecificLogic을 호출한다. 그 다음, 종료 상태로 진입한다.

Unknown 예외에 대한 예외 핸들러 또한, 종료 메시지를 구축하고 송신하며 종결하기 전에 보상 블록 CompensateForAllActionSpecificLogic을 호출한다.

각각의 예외 핸들러는 다이렉트 바운드 포트를 통해 메시지 박스로 종료 메시지를 송신할 수 있다. 이 메시지는 다른 자식 액션들에게, 다른 자식 액션들이 의존적으로 구성되었으며 종결을 위한 동기화 메시지가 수신되지 않았다는 것을 지시한다. 종료 메시지는 의존적으로 구성된 자식 액션들에 의해 수신된다(예를 들어, 4230에서).

4270은 부모 액션으로부터 종료 메시지를 청취한다. 메시지가 수신되지 않으면 (예를 들어, 5초 후에) 타임아웃한 다음, 액션은 종결된다. 이로써, 액션으로 라우팅되었지만 소비되지 않은, 부모 액션으로부터의 종료 메시지를 액션이 소비한다. 이 조건은, 부모 액션이 동기화 메시지를 송신하면서 연속하여 종료 메시지도 송신할 경우에 발생한다. 청취 형태(예를 들어, 4230)의 의존적 자식 액션에 의해서는 동기화 메시지만이 소비된다. 종료 메시지는 자식 액션으로 전달되지만, 청취 형태가 2개의 메시지들 중 첫번째 메시지만을 수용하기 때문에, 소비되지 않는다. 자식 액션이 이 메시지의 소비없이 종결하고 다른 인스턴스들에 대해서도 이러한 패턴이 지속된다면, 성능에 부정적인 영향을 미치면서, 다수의 고아 메시지 엔트리들(orphaned message entries)이 메시지 박스 데이터베이스에 구축될 수 있다. 종료 메시지가 이미 액션으로 라우팅되었다면, 청취 형태(4270)를 갖는 것은 액션이 종료 메시지의 소비없이 종결하는 것을 방지한다.

<제36 실시예>

기술들의 조합들

여기에 설명되어 있는 임의 실시예로부터의 기술들은 여기에 설명되어 있는 하나 이상의 다른 실시예들의 임의 조합의 기술들과 조합될 수 있다.

<제37 실시예>

예시적인 컴퓨터 시스템

여기에 설명되어 있는 예시적 시스템들 중 어느 것이든, Microsoft(등록상표) Windows(등록상표) 오퍼레이팅 시스템 및 다른 것들을 포함하는, 다양한 오퍼레이팅 시스템들 중 하나를 실행 중인 마이크로프로세서-기반 시스템들을 포함하여, 프로그램 가능한 범용 컴퓨터와 같은, 컴퓨터 시스템상에서 실행 중인 소프트웨어에 의해 구현될 수 있다. 이러한 컴퓨터 시스템들은, RAM, ROM, 하드 디스크들, CD-ROM, DVD-ROM 등과 같은, 컴퓨터-판독 가능 매체를 포함하거나 컴퓨터-판독 가능 매체와 함께 동작할 수 있다.

<제38 실시예>

예시적인 컴퓨터-실행 가능 명령어들

여기에서 설명된 예시적인 방법들 중 어떤 것도, 컴퓨터-판독 가능 매체에 저장될 수 있는, 컴퓨터-실행 가능 명령어들을 구비하는 소프트웨어에 의해 구현될 수 있다.

<대안>

본 발명의 원리들이 적용될 수 있는 가능한 다수의 실시예들의 관점에서, 도시된 실시예들은 본 발명의 예들이며, 본 발명의 범위에 대한 한정으로 받아들여져서는 안된다는 것을 알 수 있어야 한다. 오히려, 본 발명의 범위는 다음의 청구항들에 의해 커버되는 것을 포함한다. 따라서, 이들 청구항들의 범위 및 정신내에 해당되는 모두를 본 발명으로 주장한다.

Claims (36)

1. 복수의 액션들을 하나의 활동 흐름으로 구성하도록 동작할 수 있으며, 클라이언트 프로그램에 의해 서비스로서 액세스될 수 있는 액션 구성 서비스;

   저장되어 있는 제한들에 따라, 이용가능한 옵션들을 제공하도록 동작할 수 있으며, 상기 클라이언트 프로그램에 의해 서비스로서 액세스될 수 있는 제한 서비스; 및

   상기 활동 흐름의 진행을 제공하도록 동작할 수 있으며, 상기 클라이언트에 의해 서비스로서 액세스될 수 있는 추적 서비스

   를 포함하는 자동 워크플로우 서비스 시스템.
2. 제1항에 있어서,

   상기 구성 서비스, 제한 서비스, 및 추적 서비스는 상기 클라이언트 서비스에 의해 액세스될 수 있는 단일 서비스로서 제공되는 자동 워크플로우 서비스 시스템.
3. 제2항에 있어서,

   상기 단일 서비스는 웹 서비스인 자동 워크플로우 서비스 시스템.
4. 제2항에 있어서,

   상기 단일 서비스는 SOAP(Simple Object Access Protocol)-기반 프로토콜을 통해 상기 클라이언트 프로그램과 통신하도록 동작할 수 있는 자동 워크플로우 서비스 시스템.
5. 제2항에 있어서,

   상기 단일 서비스는 클라이언트 관용적(client-agnostic)인 자동 워크플로우 서비스 시스템.
6. 제1항에 있어서,

   상기 제한 서비스는, 이용가능한 액션들이 옵션들로서 제시될 액터의 ID에 기초해, 상기 이용가능한 액션들을 제한하도록 동작할 수 있는 자동 워크플로우 서비스 시스템.
7. 제1항에 있어서,

   상기 제한 서비스는, 타깃 액터들이 옵션들로서 제시될 액터의 ID에 기초해, 액션에 대해 이용가능한 상기 타깃 액터들을 제한하도록 동작할 수 있는 자동 워크플로우 서비스 시스템.
8. 제1항에 있어서,

   상기 제한 서비스는, 액터에 대해 정해진 ID에 기초해, 이행 액션들을 제한 하도록 동작할 수 있는 자동 워크플로우 서비스 시스템.
9. 제1항에 있어서,

   상기 액션 구성 서비스는 상기 활동 흐름의 실행시 상기 활동 흐름에 실행 가능한 액션을 추가하도록 동작할 수 있는 자동 워크플로우 서비스 시스템.
10. 제1항에 있어서,

    상기 액션 구성 서비스는, 그와 관련된 복수의 액션들을 갖는 미리 정해진 활동 모델에 기초해, 상기 활동 흐름을 인스턴스화하도록 동작할 수 있는 자동 워크플로우 서비스 시스템.
11. 제1항에 있어서,

    상기 제한 서비스는 사실들에 대해 포괄적인 방식으로 옵션들을 제한하도록 동작할 수 있는 자동 워크플로우 서비스 시스템.
12. 제10항에 있어서,

    상기 액션 구성 서비스는 또한, 상기 활동 흐름의 실행시 상기 미리 정해진 활동 모델에 기초해 상기 활동 흐름에 실행 가능한 액션을 추가하도록 동작할 수 있는 자동 워크플로우 서비스 시스템.
13. 제12항에 있어서,

    상기 제한 서비스는 상기 활동 흐름의 일부로서 생성된 태스크에 대해 이용가능한 임시(ad hoc) 액션들의 세트를 지시하도록 동작할 수 있는 자동 워크플로우 서비스 시스템.
14. 제13항에 있어서,

    상기 이용가능한 액션들은 액터의 ID에 기초해 제한되는 자동 워크플로우 서비스 시스템.
15. 제13항에 있어서,

    상기 이용가능한 액션들은 액터의 ID와의 상대적인 관계에 기초해 제한되는 자동 워크플로우 서비스 시스템.
16. 제1항에 있어서,

    상기 자동 워크플로우 서비스 시스템은, 조회에 응답하여, 액션에 대한 활성화 파라미터들의 스펙을 제공하도록 동작할 수 있는 발견 가능성 기능(discoverability functionality)을 구비하는 자동 워크플로우 서비스 시스템.
17. SOAP-기반 프로토콜을 통해 클라이언트와 통신하며 상기 클라이언트로부터의 요청들에 응답하여 인스턴스화된 복수의 액션들을 인스턴스화하도록 동작할 수 있 으며, 또한 상기 클라이언트로부터의 통신에 응답하여 활동 흐름의 실행시 상기 활동 흐름에 액션의 인스턴스를 추가하도록 동작할 수도 있는 활성화 흐름 구성 서비스;

    지식 기반들에 대해 개개의 스키마들을 갖는 지식 기반 어댑터들을 통해 복수의 지식 기반들로부터 추출된 복수의 사실들을 구비하는 사실 저장 장치;

    상기 SOAP-기반 프로토콜을 통해 상기 클라이언트와 통신하도록 동작할 수 있으며, 상기 활동 흐름의 참가 액터의 ID에 기초해 제한들을 강요(enforce)하도록 동작할 수 있으며, 또한 상기 사실 저장 장치의 사실들에 기초해 제한들을 강요하도록 동작할 수도 있는 제한 서비스; 및

    상기 인스턴스화된 액션들로의 그리고 상기 인스턴스화된 액션들로부터의 메시지들을 추적하도록 동작할 수 있는 추적 서비스

    를 포함하는 자동 워크플로우 서비스 시스템.
18. 복수의 액션들을 하나의 활동 흐름으로 구성하도록 동작할 수 있으며, 클라이언트에 의해 서비스로서 액세스될 수 있는 구성 수단;

    저장되어 있는 제한들에 따라, 이용가능한 옵션들을 제공하도록 동작할 수 있으며, 상기 클라이언트 프로그램에 의해 서비스로서 액세스될 수 있는 제한 수단; 및

    상기 활동 흐름의 진행을 제공하도록 동작할 수 있으며, 상기 클라이언트에 의해 서비스로서 액세스될 수 있는 추적 수단

    을 포함하는 자동 워크플로우 서비스 시스템.
19. 서비스에서, 클라이언트 프로그램으로부터 액션을 활동 흐름의 일부로서 인스턴스화하기 위한 요청을 수신하고 그에 응답하여 상기 액션을 인스턴스화하는 단계;

    상기 서비스에서, 상기 활동 흐름의 실행 동안 이용가능한 옵션들에 대한 요청을 수신하고 그에 응답하여 옵션들의 리스트를 제공하는 단계; 및

    상기 서비스에서, 상기 활동 흐름의 상태에 대한 요청을 수신하고 그에 응답하여 상태 정보를 제공하는 단계

    를 포함하는 자동 워크플로우 서비스의 제공 방법.
20. 제19항의 방법을 수행하기 위한 컴퓨터-실행 가능 명령어들을 갖는 하나 이상의 컴퓨터-판독 가능 매체.
21. 제19항에 있어서,

    상기 서비스는 웹 서비스로서 구현되는 자동 워크플로우 서비스의 제공 방법.
22. 제19항에 있어서,

    상기 클라이언트 프로그램은 SOAP-기반 프로토콜을 통해 상기 서비스와 상호 작용하는 자동 워크플로우 서비스의 제공 방법.
23. 제19항에 있어서,

    상기 서비스는 클라이언트 관용적인 자동 워크플로우 서비스의 제공 방법.
24. 제19항에 있어서,

    상기 옵션들의 리스트는 액터의 ID 및 저장되어 있는 제한들에 기초해 제공되는 이용가능한 액션들의 리스트인 자동 워크플로우 서비스의 제공 방법.
25. 제19항에 있어서,

    상기 옵션들의 리스트는 액터의 ID 및 저장되어 있는 제한들에 기초해 제공되는 이용가능한 타깃 액터들의 리스트인 자동 워크플로우 서비스의 제공 방법.
26. 제19항에 있어서,

    상기 옵션들의 리스트는 이행 액션을 위해 정해진 타깃 액터에 기초해 제공되는 이용가능한 타깃 액터들의 리스트인 자동 워크플로우 서비스의 제공 방법.
27. 제19항에 있어서,

    상기 액션을 인스턴스화하기 위한 상기 클라이언트 프로그램으로부터의 요청은 상기 활동 흐름의 실행시에 수신되는 자동 워크플로우 서비스의 제공 방법.
28. 문서에 대한 워크플로우 프로세싱을 실현하는 방법으로서,

    상기 문서와 관련된 복수의 태스크들을 복수의 액터들에게 할당하는 활동 흐름을 개시하는 단계; 및

    상기 태스크들상의 액터들에 의한 액션들에 반응하여, 상기 활동 흐름의 상태를 업데이트하는 단계

    를 포함하는 워크플로우 프로세싱 실현 방법.
29. 제28항에 있어서,

    상기 개시하는 단계는 상기 문서의 검토자들에 대한 지시를 전자 형태로 수신하는 것에 응답하여 수행되고,

    상기 액터들은 상기 검토자들을 구비하는 워크플로우 프로세싱 실현 방법.
30. 제28항에 있어서,

    상기 액터들 중 하나의 액터에게 상기 태스크들 중 하나의 태스크를 할당할 때, 상기 액터에게 상기 문서로의 하이퍼링크를 갖는 이메일 통지를 송신하는 단계를 더 포함하는 워크플로우 프로세싱 실현 방법.
31. 제28항에 있어서,

    상기 액터들 중 하나의 액터에게 상기 태스크들 중 하나의 태스크를 할당할 때, 상기 액터에게 상기 태스크로의 하이퍼링크를 갖는 이메일 통지를 송신하는 단계를 더 포함하는 워크플로우 프로세싱 실현 방법.
32. 제28항에 있어서,

    상기 액터들에 의한 액션들은 태스크를 위임(delegate)하는 단계를 포함하는 워크플로우 프로세싱 실현 방법.
33. 제28항에 있어서,

    상기 액터들에 의한 액션들은 태스크를 확대(escalate)시키는 단계를 포함하는 워크플로우 프로세싱 실현 방법.
34. 제28항에 있어서,

    상기 액터들에 의한 액션들은 상기 문서의 승인을 제공하는 단계를 포함하는 워크플로우 프로세싱 실현 방법.
35. 제28항에 있어서,

    상기 액터들에 의한 액션들은 상기 문서들에 대한 주석들을 제공하는 단계를 포함하는 워크플로우 프로세싱 실현 방법.
36. 제28항에 있어서,

    상기 개시하는 단계는, 상기 활동 흐름을 개시하기 위해 이메일 에일리어스로 송신된, 첨부 문서를 구비하는 이메일을 수신하는 것에 응답하여 개시되는 워크플로우 프로세싱 실현 방법.

Images