KR20060087994A - 작업 흐름 모델을 주시하는 컴퓨터화된 시스템 - Google Patents

작업 흐름 모델을 주시하는 컴퓨터화된 시스템 Download PDF

Info

Publication number
KR20060087994A
KR20060087994A KR1020050074226A KR20050074226A KR20060087994A KR 20060087994 A KR20060087994 A KR 20060087994A KR 1020050074226 A KR1020050074226 A KR 1020050074226A KR 20050074226 A KR20050074226 A KR 20050074226A KR 20060087994 A KR20060087994 A KR 20060087994A
Authority
KR
South Korea
Prior art keywords
activity
workflow
activities
code
schedule
Prior art date
Application number
KR1020050074226A
Other languages
English (en)
Inventor
달마 케이. 슈클라
로버트 비. 슈미트
아브헤이 파라스니스
아카쉬 제이. 사갈
쿠마스와미 피. 벨르저르푸라
마얀크 메타
아디티야 지. 반달카
Original Assignee
마이크로소프트 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/047,017 external-priority patent/US7451432B2/en
Application filed by 마이크로소프트 코포레이션 filed Critical 마이크로소프트 코포레이션
Publication of KR20060087994A publication Critical patent/KR20060087994A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0633—Workflow analysis

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

본 발명은 컴포넌트화된 작업 흐름 모델을 구축하는 것에 관한 것이다. 작업 흐름의 각 단계는 작업 흐름 단계의 디자인시 측면, 컴파일시 측면, 및 런타임 측면을 기술하는 메타데이터를 갖는 활동으로서 모델링된다. 사용자는 사용자 인터페이스 또는 애플리케이션 프로그래밍 인터페이스를 통해 작업 흐름을 생성하는 활동들을 선택하고 정렬한다. 작업 흐름 내의 활동들 각각에 연관된 메타데이터는 작업 흐름의 영속적 표현을 생성하기 위해 수집된다. 사용자는 커스텀 활동을 작성함으로써 작업 흐름 모델을 확장시킨다. 작업 흐름은 컴파일되고 실행될 수 있다.
작업 흐름, 컴포넌트화, 메타데이터, 복합 활동, 활동 트리

Description

작업 흐름 모델을 주시하는 컴퓨터화된 시스템{COMPONENTIZED AND EXTENSIBLE WORKFLOW MODEL}
도 1은 태스크 및 제어 흐름 복합 활동을 포함하는 전형적인 작업 흐름을 나타낸 도면.
도 2는 전형적인 활동 상속 트리를 나타낸 도면.
도 3은 전형적인 컴포넌트 모델을 나타낸 도면.
도 4는 전형적인 컴포넌트 모델 라이프사이클을 나타낸 도면.
도 5은 작업 흐름의 상세에 대해서는 마법사에 의존하여 작업 흐름을 작성하기 위한 상위 레벨 애플리케이션 사용자 인터페이스를 나타낸 도면.
도 6은 전형적인 작업 흐름 디자이너를 나타낸 도면.
도 7은 수신 활동 및 그에 뒤이은 전송 활동을 포함하는 조정 프로그램을 나타낸 도면.
도 8은 객체의 직렬화를 그래프에 나타낸 도면.
도 9는 스케쥴 정의, 그리고 시각적 작업 흐름, 작업 흐름의 직렬화된 XOML 표현, 및 작업 흐름의 코드 비사이드(code beside) 간의 관계를 나타낸 도면.
도 10은 본 발명이 구현될 수 있는 적당한 컴퓨팅 시스템 환경의 한 예를 나타낸 블록도.
부록 A는 전형적인 활동을 기술한다.
부록 B는 전형적인 활동 디자이너 인터페이스를 기술한다.
부록 C는 활동 검증을 기술한다.
부록 D는 본 발명의 전형적인 애플리케이션 프로그래밍 인터페이스를 기술한다.
<도면의 주요 부분에 대한 부호의 설명>
134: 시스템 메모리
132: 프로세싱 유닛
136: 시스템 버스
190: 비디오 인터페이스
본 출원은 2004년 1월 10일자로 출원된 미국 가특허출원 제60/615,543호의 우선권을 주장한다.
본 발명의 실시예들은 작업 흐름 모델링의 분야에 관한 것이다. 특히, 본 발명의 실시예들은 컴포넌트화되고 확장가능한 작업 흐름 모델에 관한 것이다.
기존의 시스템은 비지니스 문제를 모델링함으로써 그 비지니스 문제를 상위 레벨 작업 흐름으로 매핑하려고 한다. 그렇지만, 실세계 작업 흐름은 (a) 실행 및 모델링 복잡성, (b) 디자인시에 흐름의 구조를 숙지, (c) 정적으로 정의되거나 또 는 임시적으로/동적으로(ad-hoc/dynamic) 정의됨, (d) 흐름을 그의 라이프사이클 내의 여러 지점에서 작성 및 편집하는 것의 용이성, 및 (e) 비지니스 로직과 핵심 작업 흐름 프로세스의 약한 또는 강한 연관성 등의 다양한 차원에 있어서 달라진다. 기존의 모델은 이런 모든 요소를 수용하지는 못한다.
게다가, 대부분의 기존의 작업 흐름 모델은 언어 기반 방식(예를 들어, BPEL4WS, XLANG/S 및 WSFL) 또는 애플리케이션 기반 방식에 기초한다. 언어 기반 방식은 사용자/프로그래머가 작업 흐름 프로세스를 모델링하는 것을 돕는 사전 정의된 구문의 폐집합(a closed set of predefined constructs)을 갖는 상위 레벨 작업 흐름 언어이다. 작업 흐름 언어는 사용자가 작업 흐름 모델을 구축할 수 있게 해주는 구문 폐집합에 대한 모든 시맨틱 정보를 전달한다. 그렇지만, 이 언어는 개발자에 의해 확장가능하지 않으며 작업 흐름 모델을 구성하는 프리미티브 폐집합(a closed set of primitive)을 나타낸다. 이 언어는 작업 흐름 시스템 벤더에 의해 출하된 언어 컴파일러에 의존하고 있다. 작업 흐름 시스템 제품 벤더만이 그 제품의 장래의 버전에서 일련의 새로운 구문으로 그 언어를 확장시킴으로써 그 모델을 확장시킬 수 있다. 이것은 종종 그 언어와 연관된 컴파일러의 업그레이드를 필요로 한다.
애플리케이션 기반 방식은 도메인 관련 문제(domain specific problem)를 해결하기 위해 애플리케이션 내에 작업 흐름 기능들을 갖는 애플리케이션이다. 이들 애플리케이션은 정말로 확장가능하지도 않고 또 프로그램가능 모델도 갖지 않는다.
기존의 방식에서는, 복잡성, 사전 숙지, 동적 작업 흐름, 작성의 용이, 그리 고 비지니스 로직과 핵심 작업 흐름과의 관련 정도의 문제가 적절히 해소되지 않고 있다. 여러가지 부류의 작업 흐름을 모델링하기 위해 시각적 작업 흐름 디자이너를 구축하는 데 이용할 수 있는 확장가능하고 커스터마이즈가능하며(customizable) 또 재호스팅가능한 작업 흐름 디자이너 프레임워크가 존재하지 않는다. 기존의 시스템은 사용자로 하여금 그래픽적으로 작업 흐름 프로세스를 디자인하고 또 개발자가 선택한 프로그래밍 언어로 비지니스 로직을 연관시킬 수 있게 해주는 RAD(rapid application development) 스타일 작업 흐름 디자인 경험을 제공하지 못한다. 게다가, 잉크가 지원되는(ink-enabled) 작업 흐름 디자이너가 없다.
또한, 기존의 시스템은 작업 흐름을 실행하기 위한 매끄러운 임시적이거나 동적인 편집을 제공하지 못한다. 작업 흐름 프로세스는 현실적으로 동적이고 유동적이며 그의 형태는 디자인시 전적으로 예측될 수 없다. 작업 흐름 프로세스는 구조화된 방식으로 시작되며 궁극적으로 그의 실행 수명 동안에 진화하고 변화한다. 작업 흐름 구축자가 디자인 시에 여러가지 타입의 작업 흐름 모델을 작성할 수 있을 뿐만 아니라 실행 중인 작업 흐름에 대한 임시적이거나 동적인 변경을 깔끔하게 행할 수 있게 해주는 작업 흐름 작성 프레임워크가 필요하다. 작업 흐름 프로세스가 설치되어 실행되고 있는 후에도, 비지니스 요건의 변화로 인해 어쩔 수 없이 현재 실행 중인 작업 흐름 프로세스를 변경 또는 편집해야만 하는 경우가 있다. 작업 흐름 프로세스의 런타임 작성을 제공하는 시스템이 필요하다.
게다가, 작업 흐름 프로세스는 작업 흐름 프로세스 모델의 다수의 단계들에 걸쳐 있는 횡단적이고 복잡한 관심사(cross cutting orthogonal and tangled concerns)를 처리한다. 예를 들어, 작업 흐름 프로세스의 일부는 장기 실행 중인 트랜잭션에 참여하도록 디자인되어 있는 반면, 동일 프로세스의 다른 부분은 동시 실행을 위해 디자인되어 있다. 동일 작업 흐름 프로세스의 또다른 부분은 추적(tracking)을 필요로 하는 반면, 다른 부분은 비지니스 또는 애플리케이션 레벨 예외 처리를 한다. 작업 흐름 프로세스의 하나 이상의 부분들에 일정한 거동들을 적용할 필요가 있다.
어떤 작업 흐름 모델링 방식은 모든 예외 및 사람 개입을 비롯한 전체 비지니스 프로세스의 흐름-기반(flow-based)에 대한 완벽한 설명을 필요로 하기 때문에 비현실적이다. 이들 방식 중 어떤 것은 예외가 발생할 때 부가 기능을 제공하는 반면, 다른 방식들은 비지니스 프로세스를 모델링하는 흐름-기반 방식 대신에 오로지 제약-기반(constraint-based) 방식만을 이용한다. 기존의 시스템은 흐름-기반 방식 또는 제약-기반 방식 중 하나를 구현한다. 이러한 시스템은 너무 융통성이 없어서 많은 통상의 비지니스 상황을 모델링하지 못한다.
따라서, 이들 및 다른 단점 중 하나 이상을 해소하기 위한 컴포넌트화되고 확장가능한 작업 흐름 모델이 요망된다.
본 발명의 실시예들은 컴포넌트화된 작업 흐름 모델을 구축하기 위한 확장가능한 프레임워크를 제공한다. 특히, 작업 흐름 프로세스의 각 단계는 작업 흐름 단계의 디자인시 측면, 컴파일시 측면, 및 런타임 측면을 기술하는 관련 컴포넌트 모델을 갖는다. 게다가, 어떤 개발자라도 이들 컴포넌트를 작성함으로써 핵심 작 업 흐름 모델을 확장할 수 있다. 본 발명은 고도로 형식적인 기계-대-기계 프로세스, 제약-기반의 임시적인 사람 작업 흐름, 그리고 흐름-기반 방식과 제약-기반 방식이 혼합된 작업 흐름을 비롯한 여러가지 종류의 작업 흐름의 실행을 조정하기에 충분히 유연성있고 강력한 작업 흐름 엔진을 포함한다. 작업 흐름 엔진은 활성화, 실행, 쿼리 및 실행 중인 작업 흐름에 대한 제어 기능을 가능하게 해준다. 예를 들어, 본 발명은 실행 중인 작업 흐름에 대한 임시적이고 동적인 변경을 가능하게 해준다. 작업 흐름 엔진은 서버 환경 및 클라이언트 환경 둘다를 비롯하여 다양한 호스트 환경에서 재호스팅되거나 그에 내장될 수 있다. 각각의 특정의 호스트 환경은 작업 흐름 엔진을 일련의 서비스 프로바이더들과 융합시킨다. 서비스 프로바이더들의 전체 기능들이 특정의 호스트 환경에서 실행될 수 있는 작업 흐름의 종류를 결정한다.
본 발명의 다른 실시예들은 작업 흐름 모델을 직렬화하기 위한 확장가능 조정 마크업 언어(extensible orchestration markup language, XOML) 등의 선언적 포맷(declarative format)을 제공한다. 이 선언적 포맷에 의해 사용자는 일련의 컴포넌트를 작성함으로써 작업 흐름 모델을 확장시킬 수 있다. 작업 흐름 프로세스의 여러가지 단계에 대응하는 시맨틱스(semantics)는 컴파일 시에 주어진 컴포넌트에 대한 시맨틱스를 검증하고 시행하는 활동 검증자 컴포넌트(activity validator component) 내에 캡슐화된다. 본 발명의 선언적 포맷의 실시예들은 또한 데이터를 선언하는 것 및 그 데이터를 작업 흐름 모델의 여러가지 요소들과의 연관시키는 것을 가능하게 해준다. 선언적 포맷은 작업 흐름을 통한 데이터의 변환을 지원한다. 예를 들어, 이 포맷은 작업 흐름 모델 내에 데이터베이스 또는 파일, 코드 스니펫(code snippet), 및 비지니스 규칙 등의 외부 데이터 소스를 선언적으로 표현한다.
본 발명의 실시예는 여러가지 부류의 작업 흐름을 모델링하는 그래픽/시각적 작업 흐름 디자이너를 구축하기 위한 확장가능하고 커스터마이즈가능하며 재호스팅가능한 작업 흐름 디자이너 프레임워크를 제공한다. 본 발명의 다른 실시예는 사용자가 임의의 프로그래밍 언어에서 그래픽적으로 작업 흐름 프로세스를 디자인하고 또 비지니스 로직을 연관시킬 수 있도록 RAD(rapid application development) 스타일 작업 흐름 디자인 경험을 지원한다. 본 발명의 실시예에서, 펜과 타블릿 기술을 이용하는 잉크 지원도 제공한다. 본 발명은 사용자에 의해 작성된 작업 흐름이 내부 표현으로 변환되는 자유 형식 드로잉 화면(free form drawing surface)을 제공한다. 본 발명은 기존의 드로잉 화면 상에서의 잉크 편집(ink editing)(예를 들어, 활동의 부가/삭제) 및 기존의 작업 흐름의 잉크 주석 첨부(ink annotation)(예를 들어, 디자인 화면 상에 손으로 작성한 설명, 제안, 알림)를 통한 작업 흐름의 생성 및 수정을 지원한다.
본 발명의 또다른 실시예들은 선언적 방식으로 횡단적 거동을 포착하고 그 거동을 작업 흐름 모델의 선택된 일부분에 적용시키는 컴포넌트들을 제공한다. 본 발명의 다른 실시예들은 작업 흐름 모델의 선택된 부분을 그와 관련된 거동의 관점에서 실행한다. 본 발명의 실시예들은 작업 흐름 프로세스 모델의 다수의 단계들에 걸쳐 있는 횡단적이고 복잡한 관심사를 처리하는 프레임워크, 재사용가능한 컴포넌트, 및 언어를 제공한다.
본 발명의 한 측면에 따르면, 컴퓨터 구현 방법은 작업 흐름을 모델링한다. 작업 흐름은 활동들을 포함하고, 작업 흐름은 비지니스 프로세스를 모델링한다. 이 방법은 복수의 활동들을 제공하는 단계, 사용자에 의해 제공된 활동들 중 선택된 것을 수신하는 단계, 및 작업 흐름의 영속적 표현을 생성하기 위해 수신된 활동들을 직렬화하는 단계를 포함한다.
본 발명의 다른 측면에 따르면, 하나 이상의 컴퓨터 판독가능 매체는 작업 흐름을 모델링하는 컴퓨터 실행가능 컴포넌트를 갖는다. 이 작업 흐름은 활동들을 포함하고, 작업 흐름은 비지니스 프로세스를 모델링한다. 컴포넌트들은 복수의 활동들을 제공하는 팔레트 컴포넌트(palette component)를 포함한다. 컴포넌트들은 또한 사용자로부터 팔레트 컴포넌트에 의해 제공된 활동들 중 선택된 것 및 이것의 계층적 구성을 수신하는 인터페이스 컴포넌트를 포함한다. 컴포넌트들은 또한 작업 흐름의 영속적 표현을 생성하기 위해 인터페이스 컴포넌트에 의해 수신된 활동들을 직렬화하는 선언적 컴포넌트를 포함한다.
본 발명의 또다른 측면에 따르면, 컴퓨터 구현 시스템은 작업 흐름을 모델링한다. 작업 흐름은 활동들을 포함하고, 작업 흐름은 비지니스 프로세스를 모델링한다. 컴퓨터 구현 시스템은 복수의 활동들을 식별하는 패키지를 포함한다. 이 시스템은 또한 작업 흐름을 생성하기 위해 패키지로부터 활동들 중 하나 이상을 선택하고 서로 관련시키는 인터페이스를 포함한다. 이 시스템은 또한 작업 흐름의 영속적 표현을 생성하기 위해 수신된 활동들을 직렬화하는 직렬화기(serializer)를 포함한다.
다른 대안에서, 본 발명은 여러가지 다른 방법 및 장치를 포함할 수 있다.
다른 특징들은 부분적으로 명백하고 또 부분적으로 이후에 지적될 것이다.
도면 전체에 걸쳐 대응하는 도면 부호는 대응하는 구성요소를 나타낸다.
본 발명의 실시예들은 비지니스 프로세스 등의 프로세스를 나타내는 작업 흐름을 모델링한다. 비지니스 프로세스란 예측가능하고 반복가능한 결과를 가져오는 의존적이고 순서화된 태스크, 활동 등을 말한다. 조직의 운영 절차, 제도적인 실무 지식, 및 정보 자원을 비롯하여, 비지니스 프로세스는 정의된 비지니스 목적을 효율적이고 적시에 만족시키도록 디자인된다. 효율적인 환경에서, 계속 변화하는 회사 요구 사항을 해소하기 위해, 프로세스의 기능 컴포넌트들은 용이하게 식별, 적응 및 설치될 수 있다. 작업 흐름은 비지니스 프로세스에서의 태스크와 상호작용하는 최종 사용자의 경험이다. 태스크는 활동, 컴포넌트, 기타 등등으로서 모델링되며, 각 태스크는 사람 또는 기계에 의해 수행되는 작업 단위를 나타낸다. 일 실시예에서, 복수의 활동들이 사용자에게 제공된다. 사용자는 활동들을 선택하고 이를 조직화하여 작업 흐름을 생성한다. 생성된 작업 흐름은 비지니스 프로세스를 모델링하기 위해 실행된다. 먼저, 도 1을 참조하면, 전형적인 작업 흐름(100)은 태스크들 및 제어 흐름 복합 활동들을 포함한다.
일례에서, 조정 엔진 작업 흐름 모델은 여러가지 부류의 작업 흐름의 모델링, 작성 및 실행을 지원한다. 예들로서는 주어진 문제점을 순서화된 시퀀스로 또는 일련의 비동기적인 이벤트로서 일어나는 일련의 구조화된 단계(a structured set of steps)로서 모델링하는 것이 있다. 조정 엔진은 스케쥴의 실행을 조율한다. 스케쥴은 트리 구조로 계층적으로 정렬된 일련의 조직화된 활동(an organized set of activities)이다. 실행 중인 활동의 실행 컨텍스트(execution context) 및 그 활동이 볼 수 있는 공유 데이터는 스코프(scope)에 의해 제공된다. 각각의 활동은 작업 흐름 프로세스 내의 단계들에 대한 메타데이터를 캡슐화하는 컴포넌트를 나타낸다. 활동은 작업 흐름 모델에서의 기본적인 실행 단위이며, 관련 프로퍼티, 핸들러, 제약 및 이벤트를 갖는다. 각각의 활동은 임의의 프로그래밍 언어로 사용자 코드로써 구성될 수 있다. 예를 들어, 사용자 코드는 CLR(common language runtime, 공통 언어 런타임) 언어로 작성된 비지니스 또는 애플리케이션 로직 또는 규칙을 나타낼 수 있다. 각각의 활동은 사용자 코드로 실행되면서 사전-가로채기 후크(pre-interception hook) 및 사후-가로채기 후크(post-interception hook)를 지원한다. 각각의 활동은 관련 런타임 실행 시맨틱스 및 거동(예를 들어, 상태 관리, 트랜잭션, 이벤트 처리 및 예외 처리)을 갖는다. 활동들은 다른 활동들과 상태를 공유할 수 있다. 활동들은 프리미티브 활동(primitive activity)일 수 있거나 복합 활동(composite activity)으로 그룹화될 수 있다. 프리미티브 활동, 또는 기본적인 활동은 하위구조(substructure){예컨대, 자식 활동(child activity)}를 갖지 않으며, 따라서 트리 구조에서 리프 노드(leaf node)이다. 복합 활동은 하위구조를 포함한다(예를 들면, 이것은 하나 이상의 자식 활동들의 부모가 된다).
일 실시예에서, 활동들은 3가지 유형, 즉 단순 활동(simple activity), 컨테이너 활동(container activity) 및 루트 활동(root activity)이 있다. 이 실시예 에서, 모델 내에 하나의 루트 활동이 있으며, 루트 활동 내에 단순 활동 또는 컨테이너 활동이 전혀 없거나 얼마든지 있다. 컨테이너 활동은 단순 활동 또는 컨테이너 활동을 포함할 수 있다. 전체 작업 흐름 프로세스는 상위 차원의 작업 흐름 프로세스를 구축하기 위한 활동으로서 사용될 수 있다. 게다가, 활동은 인터럽트가능(interruptible)이거나 비인터럽트가능(non-interruptible)일 수 있다. 비인터럽트가능 복합 활동은 인터럽트가능 활동을 포함하지 않는다. 비인터럽트가능 활동은 활동을 방해하는 서비스를 갖지 않는다.
조정 엔진은 일련의 전형적인 활동을 제공한다. 도 2를 참조하면, 활동 상속 트리는 전형적인 활동을 예시하고 있다. 도 2에 열거된 전형적인 활동은 부록 A에 상세히 기술되어 있다. 게다가, 어떤 사용자라도 작업 흐름 모델을 확장시키기 위해 하나 이상의 활동을 작성할 수 있다. 예를 들어, 사용자는 특정의 비지니스 문제점, 도메인, 작업 흐름 표준(예를 들어, 비지니스 프로세스 실행 언어) 또는 타겟 플랫폼에 대한 활동들을 작성할 수 있다. 조정 엔진은 예를 들어 코드, 타입 해석(type resolution) 및 타입 시스템을 분석하는 서비스들, 직렬화 및 렌더링을 위한 서비스들을 비롯하여, 활동을 작성하기 위한 풍부한 일련의 서비스를 사용자에게 제공할 수 있다.
일 실시예에서, 각각의 활동은 적어도 3개의 부분, 즉 메타데이터, 인스턴스 데이터 및 실행 로직을 갖는다. 활동의 메타데이터는 구성될 수 있는 데이터 프로퍼티를 정의한다. 예를 들어, 어떤 활동들은 활동 추상 베이스 클래스(activity abstract base class)에 정의되어 있는 일련의 공용 메타데이터를 공유할 수 있다. 각각의 활동은 이 클래스를 확장함으로써 그의 필요에 따라 그 자신의 부가의 메타데이터 프로퍼티를 선언한다.
메타데이터 프로퍼티의 값은 활동이 구성되어 있는 스케쥴의 인스턴스들 중에서 해당 활동의 모든 인스턴스들에게 공유된다. 예를 들어, 사용자가 스케쥴 A를 생성하고 그에 전송 활동(send activity)을 부가하는 경우, 전송 활동은 그의 메타데이터의 일부로서 식별 정보(예를 들어, "001")를 부여받는다. 스케쥴에 부가된 제2 전송 활동은 그 자신의 고유한 식별 정보(예를 들어, "002")를 받는다. 스케쥴 A의 다수의 인스턴스들이 생성되고 실행되면, 전송 "001"의 모든 인스턴스들이 메타데이터 값들을 공유하게 된다. 이와 반대로, 활동 인스턴스 데이터는 실행 중인 스케쥴 인스턴스 내에서 그 활동 인스턴스에 관련된 일련의 데이터를 정의한다. 예를 들어, 지연 활동(delay activity)은 지연 활동의 타임아웃 값을 나타내는 날짜 및 시각인 자신의 인스턴스 데이터에 대하여 읽기전용 프로퍼티를 부여할 수 있다. 이 값은 지연 활동이 실행되기 시작할 때 이용가능하고, 지연 활동의 매 인스턴스마다 달라질 가능성이 많다. 스케쥴의 인스턴스들과 특히 활동 및 태스크의 인스턴스들을 참조하는 것은 통상적인 일이며, "인스턴스"로만 참조가 한정되는 것은 아니다.
복합 활동은 일련의 그의 자식 활동을 또다른 요소로서 갖는다. 자식 활동은 일 실시예에서는 메타데이터로 간주된다. 조정 엔진 모델은 스케쥴의 인스턴스 내에서 이 메타데이터를 런타임 시에 처리하는 것을 명시적으로 허용한다. 실행 중인 스케쥴 인스턴스에 대한 메타데이터(활동 트리)만이 영향을 받도록 그 스케쥴 의 일부인 복합 활동에 새로운 자식 활동을 부가하는 것이 가능하다.
그 다음에 도 3을 참조하면, 각각의 활동은 그 활동에 대한 컴포넌트 모델을 형성하는 일련의 관련 컴포넌트를 갖는다. 일련의 관련 컴포넌트로는 활동 실행자(activity executor), 활동 디자이너(activity designer), 활동 직렬화기(activity serializer), 활동 검증기(activity validator)(예를 들어, 시맨틱 검사기) 및 활동 코드 생성기(activity code generator)가 있다. 활동 실행자는 그 활동에 대한 실행 시맨틱스를 구현하는 무상태 컴포넌트(stateless component)이다. 활동 실행자는 활동을 구현하기 위해 그 활동의 메타데이터에 대해 작업한다. 코어 스케쥴러(core scheduler)는 활동 실행자에 서비스를 제공하기 위해 활동 실행자에 대한 서비스 프로바이더로서 기능한다.
활동 디자이너는 활동의 디자인시 시각적 표현을 시각적으로 디스플레이한다. 활동 디자이너는 디자이너 계층 구조 내의 노드이며, 테마(theme) 또는 스킨(skin)이 지정될 수 있다. 활동 디자이너는 디자인 환경(예를 들어, 애플리케이션 프로그램)에서 호스팅되고 서비스를 통해 호스트 디자인 환경과 상호작용한다. 활동 디자이너 인터페이스는 부록 B에 상세히 기술되어 있다. 활동 검증기는 런타임시 뿐만 아니라 컴파일시에도 활동 시맨틱스를 시행한다. 활동 검증기는 작업 흐름 모델의 컨텍스트에 대해 작용하고 환경(예를 들어, 컴파일러, 디자이너 또는 런타임)에 의해 제공되는 서비스를 사용한다. 작업 흐름의 라이프사이클 내의 여러 지점에서 검증이 행해진다. 작업 흐름의 직렬화된 표현을 생성할 때, 컴파일할 때, 및 사용자의 요청에 응답할 때 구조적 부합성 검사(structural compliance check)가 행해진다. 실행 중인 인스턴스의 활동 트리에 활동을 부가하거나 이를 교체하는 등의 런타임 동작을 안전하게 하기 위해, 시맨틱 검사는 컴파일 시에 수행된 것보다 더 엄격하게 런타임 시에 시행될 수 있다. 본 발명은 예를 들어 미리 정해진 인터페이스 요건과 부합 또는 일치하는지를 알아보기 위해 각각의 활동과 연관된 시맨틱스를 평가한다. 활동 검증은 부록 C에 상세히 기술되어 있다.
활동 직렬화기는 활동의 메타데이터를 직렬화하는 컴포넌트이다. 활동 직렬화기는 여러가지 모델/포맷 직렬화기로부터 호출된다. 전체 작업 흐름 모델은 확장가능 스키마(extensible schema)에 기초하여 선언적 마크업 언어(declarative markup language)로 직렬화되는데, 원하는 바에 따라 나중에 다른 작업 흐름 언어로 변환될 수 있다.
일 실시예에서, 활동에 대한 컴포넌트 모델은 컴퓨터 판독가능 매체 상에 데이터 구조로서 저장된다. 데이터 구조에서, 활동 디자이너는 활동을 시각적으로 표현하기 위한 데이터를 저장하는 이미지 필드(image field storing data)(예를 들어, 아이콘)에 의해 표현된다. 게다가, 하나 이상의 작성시 필드(author time field)는 활동과 연관된 프로퍼티, 메소드 및 이벤트를 정의하는 메타데이터를 저장한다. 활동 직렬화기는 작성시 필드에 저장된 메타데이터를 활동의 선언적 표현으로 전달하기 위한 데이터를 저장하는 직렬화기 필드에 의해 표현된다. 활동 생성기는 작성시 필드에 저장된 메타데이터와 연관된 소프트웨어 코드를 저장하는 비지니스 로직 필드에 의해 표현된다. 활동 실행자는 비지니스 로직 필드에 저장된 소프트웨어 코드를 실행하기 위한 데이터를 저장하는 실행자 필드에 의해 표현된 다.
스코프(scope) 및 스케쥴
실행 중인 활동의 실행 컨텍스트 및 그 활동이 볼 수 있는 공유 데이터는 스코프에 의해 제공된다. 스코프는 코어 활동들 중 하나이다. 스코프는 트랜잭션 시맨틱스, 에러-처리 시맨틱스, 보상, 이벤트 핸들러, 및 데이터 상태 관리를 갖는 장기 실행 서비스의 상태 및 변수들을 한데 모으기 위한 통합 구문(unifying construct)이다. 스코프는 관련 예외 및 이벤트 핸들러를 가질 수 있다. 한 실시예에서, 스코프는 트랜잭션적(transactional)이거나, 원자적(atomic)이거나, 장기 실행(long running)되거나 또는 동기화(synchronized)될 수 있다. 사용자 변수에 대한 읽기-쓰기 또는 쓰기-쓰기 액세스가 충돌하는 경우에, 병행 제어(concurrency control)가 사용자에게 제공된다. 스코프는 또한 트랜잭션 경계, 예외 처리 경계, 및 보상 경계이기도 하다. 스코프가 스케쥴 내에 내포될 수 있기 때문에, 이름이 충돌하기 않게 (스코프들이 내포되어 있을지라도) 동일한 이름을 갖는 변수, 메시지, 채널 및 상관 세트(correlation set)를 서로 다른 스코프에 선언하는 것이 가능하다.
스케쥴 내에 내포된 스코프는 그 스케쥴의 컨텍스트 내에서만 실행가능하다. 스케쥴은 애플리케이션(예를 들어, 독립적인 실행가능 엔티티)으로서 또는 라이브러리(예를 들어, 다른 스케쥴로부터 호출되기 위한 것임)로서 컴파일될 수 있다. 라이브러리로서 컴파일되는 모든 스케쥴은 다른 스케쥴 내부로부터 호출될 수 있는 새로운 활동 타입을 효과적으로 구성한다. 스케쥴의 메타데이터는 파라미터의 선 언을 포함한다.
스케쥴이 개발되면, 개발된 스케쥴의 인스턴스들이 실행될 수 있다. 스케쥴인스턴스를 활성화 및 제어하는 프로세스는 조정 엔진이 내장되어 있는 호스트 환경의 함수이다. 조정 엔진은 스케쥴을 테스트하는 데 사용될 수 있는 실속형 "단순 호스트"를 제공한다. 게다가, 조정 엔진은 서비스 환경(즉, 호스트)과 상호작용하기 위해 엔진 및 외부 애플리케이션에 의해 똑같이 사용되는 "서비스 프로바이더" 모델(예를 들어, 애플리케이션 프로그래밍 인터페이스)의 표준화를 촉진하는 활성화 서비스(activation service)를 제공한다. 활성화 서비스는 선택적으로 파라미터를 전달하여 특정 스케쥴 타입의 스케쥴 인스턴스를 생성한다. 그 스케쥴 인스턴스는 기본적으로 실행 중인 스케쥴 인스턴스에 대한 프록시이며, 그 인스턴스를 고유하게 식별해주는 식별자, 그 스케쥴의 메타데이터(활동 트리)에 대한 참조, 및 인스턴스를 정지(suspend), 재개(resume) 및 종료(terminate)시키는 메소드를 포함한다. 활성화 서비스는 또한 주어진 스케쥴 인스턴스 식별자에 기초하여 스케쥴 인스턴스를 찾는 것을 지원한다.
코드-비사이드(Code-Beside)
스코프 활동(scope activity)은 스코프 활동에 대한 비지니스 로직을 포함하는 관련 코드-비사이드 클래스를 가질 수 있다. 스케쥴은 그 자체가 스코프이기 때문에, 스케쥴도 역시 코드-비사이드 클래스를 가질 수 있다. 스케쥴 내에 내포된 어떤 스코프라도 역시 그 자신의 코드-비사이드 클래스를 가질 수 있다. 스코프 내에 내포된 활동들은 그들의 공유된 데이터 상태 및 비지니스 로직에 대한 컨 테이너로서 기능하는 스코프의 코드-비사이드 클래스를 공유한다. 예를 들어, 코드 활동에 대한 메타데이터는 코드-비사이드 내에 특정 서명을 갖는 메소드에 대한 참조를 포함한다. 다른 예에서, 전송 활동에 대한 메타데이터는 특정 서명의 코드-비사이드 메소드에 대한 선택적인 참조(optional reference)와 메시지 선언 및 채널 선언에 대한 필수적인 참조(mandatory reference)를 포함한다.
코드-비사이드의 전형적인 사용으로는, 변수, 메시지, 채널 및 상관 세트의 선언, in/out/ref 파라미터의 선언, 부가적인 커스텀 프로퍼티의 선언, 전송될 메시지의 선언, 수신된 메시지의 처리, 부울 값을 반환하는 코드로 표현된 규칙의 구현, 지역적으로 정의된 변수의 처리, 활동 메타데이터 및 인스턴스 데이터의 읽기, 활동 인스턴스 데이터의 쓰기(예를 들어, 실행될 활동에 관한 프로퍼티를 설정하기), 이벤트의 발생, 예외 던짐, 내포된 스코프 및 스케쥴 호출 경계를 넘는 것을 비롯하여 실행 중인 스케쥴 인스턴스의 활동 트리에서 활동의 계층 구조를 열거(enumerate)하거나 네비게이션하기(navigate), 새로운 활동들을 실행 중인 스케쥴 인스턴스 내의 복합 활동에 부가, 실행 중인 스케쥴 인스턴스 내의 활동들과 연관된 선언적 규칙들을 변경, 및 다른 실행 중인 스케쥴 인스턴스에 대한 참조 및 처리를 획득하는 것이 있다.
도 4를 참조하면, 블록도는 전형적인 컴포넌트 모델 라이프사이클을 나타낸다. 사용자는 하나 이상의 컴퓨터 판독가능 매체 상에 저장되어 있는 컴퓨터 실행가능 컴포넌트와 상호작용한다. 컴퓨터 실행가능 컴포넌트로는 복수의 활동들을 제공하는 팔레트 컴포넌트(402), 팔레트 컴포넌트(402)에 의해 제공된 활동들의 계 층적 구성 및 그 중 선택된 것을 수신하는 인터페이스 컴포넌트(404), 작업 흐름의 영속적 표현을 생성하기 위해 인터페이스 컴포넌트(404)에 의해 수신된 활동들을 직렬화하는 선언 컴포넌트(406), 및 선언 컴포넌트(406)에 의해 직렬화된 작업 흐름 표현 및 인터페이스 컴포넌트(404)에 의해 수신된 소프트웨어 코드를 작업 흐름의 실행가능 표현을 포함하는 단일 어셈블리로 컴파일하는 런타임 컴포넌트(408)가 있다. 인터페이스 컴포넌트(404)는 사용자 인터페이스(예를 들어, 그래픽) 및/또는 애플리케이션 프로그래밍 인터페이스(API)를 포함한다. 사용자는 XOML(extensible object markup language) 등의 언어로 코드-비사이드 및 직렬화된 표현을 포함하는 작업 흐름을 생성하기 위해 컴퓨터 실행가능 컴포넌트와 상호작용한다. 런타임 컴포넌트(408)는 어셈블리(예를 들어, 생성된 코드, XOML, 및 코드-비사이드)를 생성하고 그 어셈블리를 실행한다. 본 발명은 실행 중인 작업 흐름에 대한 임시적인 수정을 지원하며, 그 결과 수정된 XOML이 얻어진다.
다른 실시예에서, 본 발명의 컴퓨터 실행가능 컴포넌트는 작업 흐름과 연관된 스케쥴을 생성하는 스케쥴 인터페이스, 그 스케쥴과 연관된 스코프를 생성하는 스코프 인터페이스, 및 하나 이상의 활동을 선택하는 활동 인터페이스를 제공한다. 본 발명은 생성된 스코프 내에서 실행되도록 생성된 스케쥴 내에 작업 흐름을 생성하기 위해 선택된 활동을 정렬한다. 스케쥴 인터페이스, 스코프 인터페이스, 및 활동 인터페이스는 일 실시예에서 애플리케이션 프로그래밍 인터페이스(API)이다.
프로그램 객체 모델에서, 작업 흐름에 정렬되어 있는 복수의 활동을 컴파일하는 단계는 메타데이터 인터페이스를 통해 복수의 활동들 각각에 대한 메타데이터 를 그와 연관된 컴포넌트 모델로부터 수신하는 단계를 포함한다. 메타데이터를 수신하는 단계는 복수의 활동들 각각에 대한 프로퍼티, 메소드 및 이벤트를 수신하는 단계를 포함한다. 메소드는 또한 수신된 메타데이터에 연관된 시맨틱스를 검증 인터페이스를 통해 검사함으로써 수신된 메타데이터를 검증한다. 메소드는 또한 검증 함수로서, 수신된 메타데이터에 연관된 소프트웨어 코드를 코드 생성기 인터페이스를 통해 생성한다. 생성된 소프트웨어 코드는 코드 컴파일 인터페이스를 통해 컴파일된다. 하나 이상의 컴퓨터 판독가능 매체는 메소드를 수행하는 컴퓨터 실행가능 명령어를 갖는다. 일 실시예에서, 본 발명은 메타데이터 인터페이스, 검증 인터페이스, 코드 생성기 인터페이스, 및 코드 컴파일 인터페이스 중 하나 이상을 제공한다.
작업 흐름 스텐실(workflow stencil)
작업 흐름 스텐실(예를 들어, 작업 흐름 템플릿 또는 활동 패키지)은 루트 활동 및 일련의 활동들을 포함한다. 스텐실은 도메인(domain) 및/또는 호스트 특정된(host specific) 것일 수 있다. 전자의 예로는 구조화된 작업 흐름 스텐실, 사람 작업 흐름 스텐실, 및 비구조화된 작업 흐름 스텐실이 있다. 어떤 스텐실은 아마도 특정의 호스트 환경에서 함께 동작하도록 디자인된 하나 이상의 루트를 포함하는 일련의 활동으로서 "닫혀" 있을 수 있다. 다른 스텐실들은 다양한 정도로 "열려" 있을 수 있다. 스텐실은 그의 확장 사항(extensibility point)을 정의한다. 예를 들어, 개발자는 CustomRoot 및 새로운 추상 CustomActivity를 작성하고, CustomRoot와 CustomActivity로부터 파생되는 임의의 활동이 더해진 패키지를 선언 한다.
전형적인 BPEL 또는 XLANG/S 스텐실은 이하의 특성을 갖는, 즉 상태 관리 및 트랜잭션에 참여하고, 관련 이벤트 및 예외 핸들러를 가지며, 계약 우선 모델(contract first model)을 지원하고, 분석 가능하고 또 잘 정의된 활성화 및 종료 거동을 갖는 루트 활동을 포함한다. 전형적인 스텐실은 또한 일련의 메시징 관련 활동(예를 들어, Send 및 Receive 및 그의 변형(variant)) 및 Scope, Loop, Condition, Listen 및 Throw 등의 다른 구조화된 활동을 포함한다.
전형적인 Halifax 스텐실은 이하의 특성을 갖는, 즉 묵시적인 상태 관리, 관련 예외 핸들러(0-n), 이벤트 기반 모델을 지원하고, 잘 정의된 활성화 거동을 가지며, 또 미정의된 종료를 갖는 루트 활동을 포함한다. 루트 활동은 0-n EventDriven 활동을 포함한다. 각각의 EventDriven 활동은 Halifax Action을 나타낸다. 각각의 EventDriven 활동은 관련 상태 관리 프로토콜을 가지며 원자적 스코프(atomic scope) 내에서 실행된다.
디자이너 프레임워크(사용자 인터페이스)
조정 엔진은 여러가지 부류의 작업 흐름 모델을 위지위그(WYSWYG) 방식으로 디자인하기 위한 프레임워크를 제공한다. 예를 들어, 도 5를 참조하면, 작업 흐름을 작성하기 위한 상위 레벨 애플리케이션 사용자 인터페이스는 작업 흐름의 상세에 대해 마법사에 의존한다. 프레임워크는 개발자가 시각적인 작업 흐름 디자이너를 작성할 수 있게 해주는 일련의 서비스 및 거동을 포함한다. 이들 서비스는 작업 흐름 프로세스를 렌더링하는 효율적인 방법, 그 흐름을 드로잉하기 위한 잉크/ 태블릿에 대한 지원, 및 실행 취소/재실행, 드래그/드롭, 잘라내기/복사/붙여넣기, 줌(zoom), 펜(pan), 찾기/바꾸기, 북마크(bookmark), 장식, 검증 오류에 대한 스마트 태그(smart tag), 활동들에 대한 유효 드롭-타겟 지시자(valid drop-target indicator), 자동 레이아웃(auto layout), 쪽번호 보기(view pagination), 네비게이션 마커(navigation marker), 드래그 지시자(drag indicator), 머리말/꼬리말을 갖는 인쇄 및 미리보기 등의 디자이너 동작을 지원한다. 이러한 사용자 인터페이스를 통해, 태스크 및 제어 흐름 복합 활동(예를 들어, 순차(sequential), 병렬(parallel) 및 조건부(conditional))을 포함하는 간단한 작업 흐름이 구성될 수 있다. 규칙 상세(예를 들어, 조건부 분기 논리, while 루프 논리) 또는 데이터 흐름 상세(예를 들어, 태스크 A의 출력이 태스크 B에 입력됨)를 위해 코드 입력(또는 기존의 컴파일된 코드에 대한 의존)이 필요하지 않다. 스케쥴(규칙 및 데이터흐름을 포함함)의 직렬화된 표현은 코드-비사이드가 필요하지 않은 어떤 시나리오의 경우에서는 독자적(self-contained)이고 완벽하다.
본 발명의 디자이너 프레임워크를 사용하면, 본 발명의 조정 엔진은 시각적 방식으로 소프트웨어 코드를 작업 흐름 모델과 연관되도록 지원하는 RAD(rapid application development) 스타일의 시각적 작업 흐름 디자이너를 포함한다. 작업 흐름 내의 각 활동은 관련 활동 디자이너를 갖는다. 각각의 활동 디자이너는 프레임워크 서비스의 관점에서 작성된다. 본 발명의 프레임워크는 또한 시각적 디자이너 모델을 포함한다. 시각적 디자이너 모델은 작업 흐름 모델에 기술되어 있는 관계(relationship)를 통해 서로 링크되어 있는 일련의 활동 디자이너를 포함한다. 도 6은 전형적인 작업 흐름 디자이너를 예시한 것이다. 본 발명은 실시간으로 사용자 코드를 작업 흐름 모델로 라운드 트립핑(round-tripping)하는 것을 가능하게 해주는 "코드-비사이드(Code-Beside)", "코드-위드인(Code-Within)" 및 "코드-온리(Code-Only)"를 비롯하여 코드를 작업 흐름 모델과 연관시키는 여러가지 모드를 포함한다. 본 발명은 또한 사용자가 작업 흐름을 구축하는 동안 실시간 시맨틱 에러를 제공한다.
한 실시예에서, 본 발명은 디자이너 프레임워크 사용자 인터페이스에서의 복수의 활동을 식별해주는 패키지를 사용자에게 제공한다. 본 발명은 또한 제공된 활동들의 계층적 구성 및 그 중 선택된 것을 사용자로부터 수신한다. 본 발명은 작업 흐름의 영속적 표현을 생성하기 위해 수신된 활동들을 직렬화한다. 본 발명은 또한 작업 흐름 내의 복수의 활동 중 하나에 연관된 비지니스 로직을 나타내는 소프트웨어 코드를 사용자로부터 수신한다. 본 발명은 또한 연관된 하나 이상의 시맨틱스를 갖는 사용자 정의된 활동을 수신할 수 있다. 본 발명은 미리 정의된 인터페이스 요건에 부합하는지를 알아내기 위해 시맨틱스를 평가하기 위한 시맨틱 검사기(semantic checker) 또는 검증기를 포함한다. 시맨틱스가 미리 정의된 인터페이스 요건에 부합하는 경우, 본 발명은 사용자 정의된 활동을 복수의 활동 중 하나로서 제공한다. 본 발명은 또한 하나 이상의 바이너리 파일을 생성하기 위해 소프트웨어 코드를 컴파일한다. 예를 들어, 본 발명은 직렬화된 작업 흐름 표현 및 소프트웨어 코드를, 작업 흐름의 실행가능 표현을 포함하는 단일 어셈블리로 컴파일한다. 본 발명은 생성된 작업 흐름을 실행한다. 일 실시예에서, 하나 이상의 컴퓨터 판독가능 매체가 이 방법을 수행하는 컴퓨터 실행가능 명령어들을 갖는다.
조정 엔진 디자이너는 사용자가 다른 생성된 스케쥴과 고차적 스케쥴(higher order schedule) 자신을 사용하여, 고차적 스케쥴을 재귀적으로 작성할 수 있게 해준다. 스케쥴의 인라인 확장(inline expansion)은 사용자가 스케쥴 내용을 인라인 방식으로 보고 그 내용을 잘라내기 또는 복사할 수 있게 해준다. 스케쥴의 인라인 확장을 가능하게 하고 또 스케쥴을 읽기 전용으로 만들기 위해, 인라인 스케쥴을 위한 별도의 디자인 화면 및 디자이너 호스트가 생성된다. 게다가, 복합 스케쥴 디자이너는 그 자신의 계층 구조를 갖는다. 디자이너가 사용자에 의해 확장될 때 호출된 스케쥴이 로드되어 디스플레이된다. 일 실시예에서, 활동이 디자인 화면 상에서 드롭되거나 복사될 때 디자이너가 축소(collapse)된다. 프로퍼티는 호출측 활동 디자이너와 호스팅된 스케쥴의 루트 디자이너를 연관(chain)시킨다. 이하의 함수는 디자이너로부터 활동을 부가하거나 제거하는 것을 방지한다.
internal static bool AreAllComponentsInWritableContext(ICollection components)
internal static bool IsContextReadOnly(IServiceProvider serviceProvider)
하부 구조가, 활동이 삽입되고 있는 컨텍스트가 쓰기가능(writable)인지를 검사하기 위해 이들 함수를 호출한다. 호스팅된 디자이너의 경우, 이들 함수는 false를 반환한다. 게다가, 프로퍼티는 수정되지 못하게 되어 있다. 다른 함수들은 적절한 컴포넌트들로부터 활동 디자이너를 페치(fetch)한다.
internal static ServiceDesigner GetSafeRootDesigner(IServiceProvider serviceProvider)
internal static ICompositeActivityDesigner GetSafeParentDesigner(object obj)
internal static IActivityDesigner GetSafeDesigner(object obj)
일례에서, 사용자는 스케쥴을 생성하고 이를 활동으로서 컴파일한다. 성공적인 컴파일이면, 스케쥴은 도구 상자에 나타난다. 사용자는 컴파일된 스케쥴을 사용하도록 요구되는 경우 그 스케쥴을 열거나 생성한다. 사용자는 컴파일된 스케쥴을 도구 상자로부터 드래그하여 드롭한다. 축소된 스케쥴 디자이너가 디자인 화면 상에 보여진다. 사용자가 드롭된 컴파일된 스케쥴의 내용을 보기를 원하는 경우, 사용자는 호출된 스케쥴의 내용을 읽기 전용 상태에서 인라인 방식으로 보여주기 위해 스케쥴 디자이너를 확장시킨다. 호출된 스케쥴의 인라이닝(inlining)은 사용자로 하여금 서로 다른 스케쥴 디자이너들 간을 전환하지 않고도 호출된 스케쥴을 볼 수 있게끔 해준다. 이 특징은 기존의 스케쥴을 재사용함으로써 고차적 스케쥴을 작성하는 개발자들에게 유용하다.
테마/스킨을 사용하는 디자이너 프레임워크 커스텀화의 지원
디자이너 프레임워크를 사용하여 작성된 작업 흐름 디자이너는 작업 흐름 테마를 사용하여 커스터마이즈될 수 있다. 이것들은 디자이너의 다양한 측면을 선언적으로 기술하는 XML(extensible markup language, 확장 가능 마크업 언어) 파일일 수 있다. 작업 흐름 디자이너는 활동들을 확장하기 위해 파트너들에 대한 마법사 지원을 제공한다. 작업 흐름 디자이너에 의해 지원되는 전형적인 사용자 인터페이스 특징으로는, 실행 취소/재실행, 드래그/드롭, 잘라내기/복사/붙여넣기, 줌, 팬, 찾기/바꾸기, 북마크, 장식, 검증 에러에 대한 스마트 태그, 활동들에 대한 유효 드롭-타겟 지시자, 자동 레이아웃, 쪽번호 보기, 네비게이션 마커, 드래그 지시자, 머리말/꼬리말을 갖는 인쇄 및 미리보기, 그리고 문서 개요 통합을 포함하지만, 이에 한정되는 것은 아니다. 작업 흐름 디자이너는 XML 메타데이터를 사용하여 디자이너의 룩앤필(look and feel)을 커스터마이즈할 수 있게 해주는 커스텀 디자이너 테마/스킨을 지원한다. 작업 흐름 디자이너는 백그라운드 컴파일을 지원한다. 일례에서, 스케쥴을 디자인하는 동안 검증 에러에 대한 스마트 태그 및 스마트 동작이 제공된다. 작업 흐름 디자이너는 임의의 컨테이너(예를 들어, 애플리케이션 프로그램, 쉘, 기타 등등)에서 호스팅될 수 있다.
전형적인 조정 엔진 프로그램은 수신 활동 및 그에 뒤이은 전송 활동을 포함한다. 프로세스는 메시지를 수신하고 그 메시지를 전송한다. 사용자는 "Hello World"라는 프로젝트를 생성하고 그 프로젝트에 조정 아이템(orchestration item)을 부가한다. 사용자는 이어서 디자인 화면 상에서 스코프 활동을 드래그 및 드롭한다. 그 다음에, 사용자는 수신 활동 및 그에 뒤이은 전송 활동을 스코프 상으로 드롭한다. 도 7은 디자이너에서의 작업 흐름(700)을 결과적으로 예시한 것이다. 각각의 활동 디자이너는 객체 모델에 관한 사용자 인터페이스 표현을 제공한다. 개발자는 객체 모델을 직접 프로그램하고 활동들에 관한 프로퍼티를 설정하거나 디자이너를 사용할 수 있다. 조정 엔진 디자이너는 개발자로 하여금 도구 상자로부 터 활동을 선택하고 이를 디자이너 화면 내로 드래그할 수 있게 해준다. 활동이 이미 스케쥴 내에 배치었으나 이동할 필요가 있는 경우, 개발자는 그 활동을 (그 위에서 클릭함으로써) 선택하여 이동해야 할 스케쥴의 영역으로 드래그할 수 있다. 개발자가 드래그 및 드롭을 하는 동안 콘트롤 키를 누르고 있는 경우, 선택된 활동들의 복사본이 만들어진다.
능동 배치(active placement)는 가능한 드롭 지점(타겟)을 디자인 화면 상에 시각적 지시자로서 제공한다. 자동 스크롤링도 역시 드래그 및 드롭의 컨텍스트에 참여한다. 대규모 스케쥴을 처리할 때, 현재 뷰 포트(view port)에 있지 않은 디자이너의 영역들로의 네비게이션은 배치될 스케쥴의 영역으로 활동을 드래그함으로써 액세스가능하다.
드래그 및 드롭은 동일한 프로젝트 내의 스케쥴들에 걸쳐 지원되고 또 동일한 솔루션으로 다른 프로젝트 내의 스케쥴들에 걸쳐서도 지원된다. 활동이 디자이너 화면 상으로 배치된 후에, 개발자는 그 활동을 구성한다. 각각의 활동은 유효한 스케쥴이 되기 위해 개발자에 의해 구성된 일련의 프로퍼티를 갖는다. 이들 프로퍼티는 프로퍼티 브라우저에서 편집가능하다. 각각의 활동은 프로퍼티 브라우저에서 볼 수 있는 프로퍼티가 어느 것인지를 제어한다. 개발자가 여러가지 활동을 구성하는 것을 돕기 위해, 디자이너는 다양한 대화 상자 또는 "하위-디자이너"를 제공한다. 대화 상자들 각각은 활동들의 여러가지 프로퍼티를 위해 호출된다.
조정 엔진은 도구 상자에 제공된 활동들을 커스터마이즈할 수 있다. 개발자가 커스텀 활동 또는 스케쥴을 생성할 때, 최종 결과는 어셈블리이다. 대화 상자 를 사용하여, 개발자는 어셈블리 위치로 브라우징하여 그 어셈블리가 조정 엔진 활동으로서 나타나게 만들기 위해 그 어셈블리를 선택할 수 있다. 다른 대안으로서, 개발자는 그 어셈블리를 조정 엔진 설치 경로에 배치할 수 있고 그 어셈블리는 조정 엔진 활동으로서 존재하게 된다.
애플리케이션 프로그래밍 인터페이스(API)
다른 실시예에서, 본 발명은 여러가지 작업 흐름 동작을 수행하는 애플리케이션 프로그래밍 인터페이스(API)를 제공한다. 본 발명은 작업 흐름을 작성하는 디자인 애플리케이션 프로그래밍 인터페이스를 포함한다. 디자인 애플리케이션 프로그래밍 인터페이스는 작업 흐름을 작성하는 수단 및 작업 흐름을 생성하기 위해 활동들 중 하나 이상을 선택하는 수단을 포함한다. 본 발명은 또한 디자인 애플리케이션 프로그래밍 인터페이스를 통해 작성된 작업 흐름을 컴파일하는 컴파일 애플리케이션 프로그래밍 인터페이스를 포함한다. 컴파일 애플리케이션 프로그래밍 인터페이스는 작업 흐름을 직렬화하는 수단, 작업 흐름의 시각적 외관을 커스터마이즈하는 수단, 디자인 애플리케이션 프로그래밍 인터페이스를 통해 작성된 작업 흐름을 컴파일하는 수단, 및 작업 흐름을 검증하는 수단을 포함한다.
본 발명은 또한 작업 흐름 내의 활동들 각각에 타입을 연관시키는 타입 프로바이더 애플리케이션 프로그래밍 인터페이스도 포함한다. 타입 프로바이더 애플리케이션 프로그래밍 인터페이스는 작업 흐름 내의 활동들 각각에 그 타입을 연관시키는 수단을 포함한다.
부록 D는 전형적인 API를 기술하고 있다. 부록 D 내의 API는 작업 흐름을 작성하는 전형적인 수단, 작업 흐름을 생성하기 위해 활동들 중 하나 이상을 선택하는 전형적인 수단, 작업 흐름을 직렬화하는 전형적인 수단, 작업 흐름의 시각적 외관을 커스터마이즈하는 전형적인 수단, 작업 흐름을 검증하는 전형적인 수단, 작업 흐름을 컴파일하는 전형적인 수단, 및 작업 흐름 내의 활동들 각각과 어떤 타입을 연관시키는 전형적인 수단을 구성한다.
활동 실행 프레임워크
스케쥴 및 스코프를 제외하고, 엔진은 활동들을 추상 엔티티로서 간주하며 임의의 특정 활동의 특정 데이터 또는 시맨틱스를 알지 못한 채로 활동들의 실행을 단순히 조정한다. 일 실시예에서, 활동의 실행 동안에 4개의 엔티티, 즉 활동 그 자체, 실행 중인 활동의 부모 활동, 실행 중인 활동을 포괄하는 스코프, 및 조정 엔진이 상호작용한다. 각각의 엔티티는 서로 다른 기능을 갖는다.
활동의 실행 메소드(execute method)가 그의 활동 조정자(activity coordinator)에게 완료 신호를 보내지 않고 복귀하는 경우, 그 활동이 논리적 대기 상태(logical waiting state)에 있다고 말한다. 이러한 활동은 조정 엔진에 의해 취소되거나 계속된다(예를 들어, 활동이 기다리고 있는 아이템 또는 이벤트가 이용가능하게 되거나 발생하면, 엔진은 그 활동에게 이것을 통지한다).
논리적 대기 상태에 들어가지 않는 어떤 활동들은 절대로 취소될 수 없다. 예로서 전송 활동 및 코드 활동이 있는데 왜냐하면 이들은 외부 이벤트 또는 신청(subscriptions)에 대한 아무런 요구도 없이 실행되기 때문이다. 쓰레드를 건네받으면(즉, 그 실행 메소드가 조정 엔진에 의해 호출되면), 이들 활동은 완료될 때까 지 동작한다. 조정 엔진은 이들을 취소시킬 기회를 결코 부여받지 못하는데 그 이유는 그 활동들이 완료 신호를 보낼 때까지 쓰레드를 반환하지 않기 때문이다.
조정 엔진 런타임(orchestration engine runtime)은 활동들이 어느 조정 엔진 상에서 실행되는지에 관한 이벤트를 트리거하기 위해 규칙들을 사용한다. 조정 엔진 디자이너는 이벤트를 트리거하기 위해 런타임 시에 사용자가 연관된 규칙들을 평가할 수 있는 기능을 제공한다. 조정 엔진 디자이너는 확장성 아키텍처(extensibility architecture)를 제공함으로써 사용자가 여러가지 타입의 규칙 기술을 사용할 수 있게 해준다. 디자이너는 사용된 규칙 기술의 타입을 모른다.
일 실시예에서, 디자이너는 규칙을 활동과 연관시키기 위한 방법으로서 부울 표현식 핸들러를 지원한다. 이것은 사용자 코드 파일에서 사용자가 true 또는 false 값을 반환하는 메소드를 작성하며, 그 값에 기초하여 규칙이 트리거되는 것을 의미한다. 현재 Info Agent 및 BRE(Business Rules Engine)를 비롯하여 규칙을 평가하는 데 사용될 수 있는 다수의 기술이 있다. 이를 달성하기 위해, 디자이너는 규칙 기술 개발자가 디자이너에서 커스텀 사용자 인터페이스를 호스팅할 수 있게 해주는 확장성 아키텍처를 포함한다. 디자이너는 커스텀 사용자 인터페이스 작성자에게 코드 명령문 컬렉션(code statement collection)의 형태로 규칙을 직렬화하는 방법을 제공한다. 디자이너는 코드 명령문 컬렉션이 그 안에 삽입되어 있는 사용자 코드 파일에서 부울 핸들러를 발행한다. 조정 엔진은 규칙 작성자(rule writer)에 의해서도 사용될 수 있는 디폴트 사용자 인터페이스를 포함한다. 규칙 기술 프로바이더는 커스텀 규칙 선언을 생성, 커스텀 규칙 선언에 연관된 사용자 인터페이스 타입 에디터를 작성, 규칙 사용자 인터페이스를 호스팅하기 위해 커스텀 사용자 인터페이스를 생성, 및 저장 시에 코드 명령문을 생성함으로써 조정 엔진 디자이너에 규칙들을 부가한다.
일례에서, 사용자는 규칙이 첨부될 필요가 있는 활동 디자이너를 선택하고, 프로퍼티 브라우저에서 규칙 프로퍼티를 찾아내어 드롭 다운으로 "RuleExpressionHandler"를 선택하며(이에 의해 "Statements" 프로퍼티가 사용자 인터페이스에서 규칙 프로퍼티(Rule Property) 아래쪽에 나타남), "Statements" 프로퍼티에서 사용자 코드 메소드 이름을 지정하고, 규칙 관련 사용자 인터페이스를 호스팅하게 될 대화 상자를 호출하기 위해 사용자 인터페이스 타입 에디터를 호출하며, 새로운 서술식 행(predicate row)을 생성하고 이들을 함께 그룹화함으로써 대화 상자에서 규칙을 정의한다. 사용자 인터페이스는 사용자 코드 파일에서 메소드를 발행한다. 메소드 이름은 프로퍼티 브라우저에서 사용자에 의해 지정된 것과 동일할 것이다. 규칙을 생성하는 것과 동등한 코드 명령문이 규칙에 대한 사용자 코드 메소드에 삽입된다.
실행 중의 메시징
실행 중인 작업 흐름에서, 스케쥴로 전송되는 메시지는 특정의 스케쥴 인스턴스를 위한 것이다. 예를 들어, 구매 주문 #123에 대한 송장은 그 구매 주문의 발원지인(예를 들어, 그 주문을 내보냈던) 동일한 스케쥴 인스턴스로 다시 보내져야만 한다. 인바운드 메시지를 적절한 스케쥴 인스턴스와 매칭시키기 위해, 메시지 및 스케쥴 인스턴스는 상관 세트(correlation set)를 공유한다. 상관 세트는 단일값 상관 세트(single-valued correlation set)일 수 있으며, 이는 메시지 내의 식별자 필드가 스케쥴 인스턴스에 의해 보유된 동일한 유형의 식별자와 매칭됨을 의미한다. 다중 프로퍼티 상관 세트(multi-property correlation set)도 또한 가능하며, 데이터베이스 테이블에서의 다중 컬럼 일차키(multi-column primary key)와 유사하다.
스케쥴 인스턴스에 의해 보유된 상관 세트 값은 스케쥴 인스턴스가 메시지를 내보내거나(예를 들어, 값은 아웃바운드 구매 주문의 식별자 필드로부터 가져올 수 있음) 메시지를 수신할 때 초기화된다. 이 상관 세트 값은 그러면 그 스케쥴 인스턴스의 상태의 일부이다. 차후의 인바운드 메시지가 도착할 때, 스케쥴 인스턴스 상태 내에 보유된 상관 세트 값은 예상된 타입의 인바운드 메시지에 의해 보유된 식별자와 매칭된다. 일치가 발견되면, 상관 세트는 충족되고 메시지는 스케쥴 인스턴스로 전달된다.
상관 세트의 구현이 조정 엔진 및 호스트 환경의 함수이지만, 일 실시예에서 사용자는 스케쥴 인스턴스가 제대로 동작하도록 상관 세트를 선언한다. 다른 실시예에서, 어떤 활동들(예를 들어, SendRequest/ReceiveResponse 활동 및 ReceiveRequest/SendResponse 활동)은 사용자와 무관하게 상관 세트를 설정한다. 상관 세트가 적절히 초기화되고 준수되도록 하기 위해 광범위한 검증 검사가 전송 및 수신 활동에 의해 수행된다.
실행 중인 작업 흐름의 동적 편집
조정 엔진은 다양한 타입의 작업 흐름을 작성(이어서 시각화 및 실행)하기 위한 프레임워크를 제공한다. 예로는 이벤트-조건-동작(event-condition-action, ECA) 스타일 작업 흐름 또는 구조화된 흐름 또는 규칙 구동 흐름이 있다. 게다가, 작업 흐름이 모델링된 방식에 상관없이, 프레임워크는 사용자가 작업 흐름 프로세스를 재컴파일할 필요없이 디자인 시에 또는 작업 흐름 프로세스가 실행되고 있을 때조차도 작업 흐름을 동일한 방식으로 작성 또는 편집할 수 있게 해준다. 프레임워크는 사용자가 고충실도로 런타임시 표현과 디자인시 표현 간을 라운드 트리핑할 수 있게 해준다. 임시적인 변경은 런타임 시에 프로세스 모델에 행해진 변경이다. 사용자는 그의 스케쥴 모델에 대한 실행 중인 인스턴스를 요청하여 그 모델을 변경할 수 있다. 예를 들어, 사용자는 일괄적으로 활동을 부가, 제거 또는 교체하고, 이어서 일괄 처리된 변경을 수용 또는 롤백할 수 있다. 일 실시예에서, 모델은 업데이트 후에 검증된다. 본 발명의 많은 작업 흐름 시나리오에서, "디자인시 작성"과 "런타임시 실행" 간의 구별이 모호해지거나 심지어 구별이 되지 않는다.
스케쥴 인스턴스는 그 인스턴스들의 스케쥴 타입에 대해 정의된 활동 타입 (메타데이터) 트리를 다른 인스턴스들과 공유한다. 그렇지만, 어떤 스케쥴 인스턴스라도 실행되기 시작하였으면 새로운 활동의 부가 또는 선언적 규칙의 조작을 통해 동작 중에 변경될 수 있다. 이러한 수정된 스케쥴 인스턴스를 받아서 새로운 스케쥴 타입으로 "다른 이름으로 저장(save as)"하거나 또는 보다 일반적으로는 그 인스턴스로부터 직렬화된 표현을 간단히 복원하는 것이 가능하다. 즉, 실행 중인 스케쥴 인스턴스는 직렬화된 다음에 임의의 디자이너(예를 들어, 작성 환경) 또는 런타임 시각화 도구로 보내질 수 있다.
게다가, 고급 개발자가 스케쥴를 완전히 소프트웨어 코드로서 작성하는 것도 가능하다. 스케쥴 타입을 직접 작성하기 위해, 개발자는 단순히 스케쥴에 대한 코드-비사이드 클래스 내의 소프트웨어 코드에 InitializeScheduleModel이라고 하는 정적 메소드를 포함하고 이 메소드에 [ScheduleCreator] 속성을 갖도록 표시를 한다. 일 실시예에서, 정적 메소드는 파라미터를 갖지 않으며 스케쥴(Schedule) 객체를 반환한다. 도우미 직렬화된 파일(companion serialized file)이 없지만, 스케쥴의 직렬화된 표현이 생성된 스케쥴 객체로부터 복원될 수 있다. 이것은 스케쥴이 단일 소프트웨어 코드 파일을 사용하여 개발될 수 있으나, 그 파일에 대해 검증 검사는 수행될 수 없음을 의미한다. 조정 엔진 컴파일은 스케쥴 타입의 바탕을 이루는 활동 트리의 구조적 및 시맨틱 유효성을 보장한다. 다른 실시예에서, 컴파일 및 검증은 실행되는 실제 타입을 생성하기 위해 내부적으로 실행되지만, 어떤 코드 입력도 필요하지 않다. 스케쥴 타입 컴파일은 초경량 프로세스가 되는데 그 이유는 컴파일시 객체 모델로부터 런타임시 객체 모델로의 변환이 없기 때문이다. 기본적으로, 컴파일은 단순히 스케쥴의 객체 모델 표현을 코드-비사이드와 결합하여 새로운 타입을 생성하는 것이다. 일 실시예에서, 컴파일된 코드-비사이드가 객체 모델 내의 활동들에 의해 요구되는 것과 일치하는 경우나 코드-비사이드가 컴파일된 형태(어셈블리)로 이미 존재하는 경우는 특정 스케쥴을 위해 기본적으로 어떤 코드-비사이드도 전혀 제공할 필요가 없다. .
직렬화된 스케쥴을 컴파일할 때, 스케쥴에 대한 코드-비사이드로서 효과적으로 기능하는 기존의 컴파일된 타입을 가리키는 것이 가능하다. 이 컴파일된 타입 의 파생형(dervative)이 생성되고, 새로운 스케쥴을 나타내는 고유한 타입이 생성되도록 보장하기 위해 이 새로운 타입은 코드-비사이드로서 기능한다.
직렬화 아키텍처
직렬화 하부구조는 조정 엔진 활동 트리를 직렬화하는 모듈형(modular), 포맷 중립형(format neutral) 및 용이하게 확장가능한 메카니즘을 제공한다. 도 8은 객체들의 직렬화를 그래프로 나타낸 것이다.
특히, 호출자(예를 들어, 애플리케이션 프로그램 또는 사용자)는 직렬화 관리자에게 객체(또는 활동) A에 대한 직렬화기를 요청한다. 객체 A의 타입의 메타데이터 속성은 객체 A를 요청된 타입의 직렬화기에 바인딩시킨다. 호출자는 이어서 직렬화기가 객체 A를 직렬화하도록 요청한다. 객체 A의 직렬화기는 이어서 객체 A를 직렬화한다. 직렬화 동안에 만나게 되는 각 객체에 대해, 직렬화기는 직렬화 관리자에게 부가적인 직렬화기들을 요청한다. 직렬화의 결과가 호출자에게 반환된다.
조정 엔진 컴포넌트 모델에서의 모든 활동은 직렬화에 참여할 수 있다. 일 실시예에서, 직렬화기 컴포넌트는 활동 클래스 자체의 일부는 아니다. 그 대신에, 이 컴포넌트는 그 활동과 연관된 클래스의 직렬화기 속성에 주석을 첨부함으로써 지정된다. 직렬화기 속성은 그 활동 타입의 객체들을 직렬화하는 데 사용되는 클래스를 가리킨다. 다른 실시예에서, 활동 타입에 대한 프로바이더 컴포넌트는 활동에 의해 제공된 디폴트 직렬화기를 오버라이드한다.
디자이너 직렬화는 메타데이터, 직렬화기, 및 직렬화 관리자에 기초하고 있 다. 메타데이터 속성은 직렬화기에 타입을 관련시키는데 사용된다. "bootstrapping(부트스트래핑)" 속성은 직렬화기를 갖지 않는 타입들에게 직렬화기를 제공하는 객체를 설치하는데 사용될 수 있다. 직렬화기는 특정 타입 또는 일정 범위의 타입들을 어떻게 직렬화하는지를 알고 있는 객체이다. 각각의 데이터 포맷에 대한 베이스 클래스가 있다. 예를 들어, 객체를 XML로 어떻게 변환하는지를 알고 있는 XmlSerializer 베이스 클래스가 있을 수 있다. 본 발명은 임의의 특정의 직렬화 포맷에 독립적인 일반적인 아키텍처이다. 직렬화 관리자는 객체 그래프를 직렬화하는데 사용되는 다양한 직렬화기 모두에 대한 정보 저장소를 제공하는 객체이다. 예를 들어, 50개의 객체의 그래프는 모두가 그 자신을 출력을 생성하는 50개의 서로 다른 직렬화기를 가질 수 있다. 직렬화 관리자는 이들 직렬화기가 필요한 경우 서로 통신하는 데에도 사용될 수 있다.
일 실시예에서, 객체가 주어진 타입에 대한 직렬화기를 제공할 기회를 부여받는 경우, 일반 객체 메타데이터를 사용하는 직렬화기에 결합된 직렬화 프로바이더의 사용은 콜백 메카니즘을 제공한다. 직렬화 관리자는 AddSerializationProvider 등의 메소드를 통해 직렬화 프로바이더를 부여받는다. 직렬화 프로바이더는 DefaultSerializationProviderAttribute 등의 속성을 직렬화기에 부가함으로써 직렬화 관리자에 자동적으로 부가될 수 있다.
일 실시예에서, 포맷은 이하의 규칙에 의해 좌우된다. 즉, 객체는 xml 엘리먼트로서 직렬화되고, 객체의 프로퍼티는 단순 프로퍼티(simple property)(예를 들어, xml 속성으로서 직렬화됨) 또는 복합 프로퍼티(complex property)(자식 엘리먼 트로서 직렬화됨)으로서 분류되고, 객체의 자식 객체는 자식 엘리먼트로서 직렬화된다. 자식 객체의 정의는 객체마다 다라질 수 있다. 이하의 예는 while 활동의 직렬화이며, 이는 그의 자식 객체 중 하나로서 Send 활동을 갖는다.
<While ID=""while1>
<ConditionRule>
<CodeExpressionRuleDeclaration>
<Expression Name="whileCondition"/>
</CodeExpressionRuleDeclaration>
</ConditionRule>
<Send HasTypedChannel="True" ID="send1">
<Message Name="msg1" Type="System.UInt32"/>
<OnBeforeSend Name="onBeforeSend1"/>
<TypeChannel Type="System.Collections.IList"
Operation="AddIndex" Name="Foo"/>
</Send>
</While>
직렬화를 위해 사용된 언어가 XOML인 실시예에서, 각각의 XOML 엘리먼트는 스케쥴이 컴파일될 때 그 각자의 객체에 대해 직렬화된다. 객체는 단순 타입(simple type) 및 복합 타입(complex type) 모두를 포함한다. 각각의 활동의 XOML 표현과 그의 작성 객체 모델로의 매핑에 대해서는 다음에 기술된다. XOML의 직렬 화는 프리미티브(Primitive) 활동과 복합(Composite) 활동에 있어서 서로 다르다.
프리미티브 활동에 대한 단순 타입은 활동 타입에 관한 속성으로서 직렬화된다. 프리미티브 활동에 대한 복합 타입은 자식 엘리먼트로서 직렬화된다. 예로서, 여기에 Send 활동의 XOML 표현이 있다.
<Send ID="send1" HasTypedChannel="False">
<Message Name="message1" Type="System.String"/>
<UntypedChannel Name="c1"/>
</Send>
프리미티브 타입 직렬화와 유사한 방식으로, 복합 활동에 대한 단순 타입은 활동 타입에 관한 속성으로서 직렬화된다. 그렇지만, 정의에 의해, 복합 활동은 내포된 활동을 캡슐화한다. 각각의 내포된 활동은 또다른 자식 엘리먼트로서 직렬화된다. 예로서, 여기에 While 활동의 XOML 표현이 있다.
<While ID="while1">
<ConditionRule>
<CodeExpressionRule>
<Expression Name="test"/>
</CodeExpressionRule>
</ConditionRule>
</While>
프로세스/작업 흐름 뷰와 직렬화된 표현 간에 밀접한 관계가 존재한다. 도 9는 스케쥴 정의, 및 시각적 작업 흐름, 작업 흐름의 직렬화된(예를 들어, XOML) 표현, 그리고 작업 흐름의 코드 비사이드 사이의 관계를 나타낸 것이다. 어느 한 표현으로 작성할 때, 상대편에 변화를 가져오게 된다. 따라서, 활동(또는 복합 활동인 경우 그의 구성 부분)에 대한 XOML을 수정하는 것은 개발자가 둘 사이에서 전환할 때 프로세스/작업 흐름 뷰에 직접 반영된다. 그 역도 역시 마찬가지이다. 프로세스/작업 흐름 뷰에서 활동을 수정하면 그 결과 XOML 내에 적절한 수정이 있게 된다. 예로서, 프로세스/작업 흐름 뷰에서 활동을 삭제하면 그 결과 동일한 활동에 대한 XOML 내의 XML 엘리먼트가 제거된다. 프로세스/작업 흐름 뷰와 코드 비사이드 사이에도 역시 라운드 트리핑이 일어난다.
XOML 코드의 생성 동안, XOML 정의가 사전 정의된 인터페이스 요건에 부합하지 않는 경우, 위반하는 XML 엘리먼트에는 밑줄이 그어지거나 또는 다른 방식으로 개발자에게 시각적으로 식별된다. 개발자가 프로세스 뷰로 전환하면, 개발자는 XOML 내에 에러가 있음을 경고받으며, 디자이너는 개발자가 위반하는 엘리먼트를 클릭하여 그로 네비게이션될 수 있는 링크를 제공한다. 이 동일한 에러는 작업창(task pane)에 나타나며, 그 에러의 더블 클릭 시, 개발자는 XOML 내에 위반하는 엘리먼트로 이동된다.
XOML 파일로부터 활동 트리를 생성(역직렬화)
일 실시예에서, CreateEditorInstance() 함수는 DesignSurface 객체를 생성한 다음에 DesignSurface 객체로의 BeginLoad() 함수를 호출하여 실제 로더 객체를 그 안으로 전달하며, 이는 궁극적으로 DesignerLoader() 함수에 대한 BeginLoad() 호출로 종료된다. PerformLoad() 함수는 텍스트 버퍼 객체를 읽어서 이를 조정 엔진 컴포넌트 모델 계층 구조로 역직렬화한다. 본 발명은 이 계층 구조를 살펴보고 비쥬얼 스튜디오 내의 컴포넌트를 로드하기 위해 그 활동들을 디자인 화면 내에 삽입한다.
본 발명은 또한 계층 구조를 추적하기 위해 XOML 파일에 대한 변화에 주목하고 또 비쥬얼 스튜디오 캐쉬 내의 값들을 업데이트하기 위해 아이템 식별자 변화에 주목한다. 2차 문서 데이터 리스트(secondary document data list)는 조정 엔진 디자이너가 작업하고 있는 사용자에게는 보이지 않는 2차 문서의 리스트를 포함한다. 예를 들어, 사용자가 코드 비사이드 파일을 열지 않고, 사용자가 조정 엔진 디자이너를 변경하려는 경우, 그 변경은 코드 비사이드 파일에 행해진다. 이 파일이 사용자에게는 보이지 않기 때문에, 그 파일은 2차 문서로서 유지된다. XOML 파일이 저장될 때마다, 2차 문서는 자동으로 저장된다. 이들 파일 중 한 파일의 이름이 변하거나 그 파일이 삭제되면, 본 발명은 대응하는 2차 문서 객체를 그에 따라 업데이트한다.
객체 트리에 대한 전형적인 역직렬화 가이드라인은 다음과 같다. xml 엘리먼트가 먼저 부모 객체의 프로퍼티로서 취급된다. 부모 객체가 그 엘리먼트의 태그명을 갖는 프로퍼티를 갖지 않는 경우, 그 엘리먼트는 부모 객체의 자식 객체로서 취급된다. xml 속성은 부모 객체에 관한 단순 프로퍼티로서 취급된다.
상기 직렬화된 코드를 사용하는 전형적인 역직렬화에서, <While> 엘리먼트는 xml 네임스페이스 정보를 사용하여 생성되는 객체로서 취급된다. <ConditionRule> 엘리먼트는 While 활동의 프로퍼티로서 취급된다. <CodeExpressionRuleDeclaration> 엘리먼트는 객체로서 취급되며 그의 값이 ConditionRule 프로퍼티에 적용된다. <Send> 엘리먼트는 먼저 While 활동의 프로퍼티로서 시도되지만, 'While' 활동은 이름 'Send'를 갖는 프로퍼티를 갖지 않으며, 따라서 <Send> 엘리먼트는 객체로서 취급되어 while 활동의 자식 활동으로서 취급된다. <Message> 엘리먼트는 Send 활동의 프로퍼티로서 취급된다. Send에 관한 Message 프로퍼티가 읽기 전용이기 때문에, Message 엘리먼트의 내용(contents)은 Message 객체의 내용으로서 간주된다. 유사한 규칙이 <OnBeforeSend> 엘리먼트 및 <TypedChannel> 엘리먼트의 역직렬화에 적용된다.
이하의 조건 하에서, 즉 XOML 코드가 제대로 작성되지 않은 경우, XomlDocument이 XOML 코드에서 첫번째 엘리먼트가 아닌 경우, 및 XOML 코드에서의 첫번째 활동이 역직렬화될 수 없는 경우, XOML 역직렬화는 결정적으로 실패하게 된다. 개발자는 에러 메시지를 제공받게 되며, 이 에러 메시지를 사용하여 개발자는 XOML 뷰로부터 프로세스/작업 흐름 뷰로 전환할 때 위반하는 XML 엘리먼트로 네비게이션할 수 있다.
조정 엔진 디자이너의 호스팅
디자이너 프레임워크는 어떤 애플리케이션 프로그램에서도 호스팅될 수 있다. 이것은 제3의 애플리케이션이 작업 흐름을 그의 개별적인 환경에서 렌더링하는데 아주 유용한 특징이다. 이것은 또한 제3자가 디자인 화면을 재호스팅 및 커스터마이즈함으로써 조정 엔진 디자이너 곳곳에서 도구를 개발할 수 있게 해준다. 본 발명의 프레임워크는 호스팅측 컨테이너 애플리케이션이 에디터 및/또는 텍스트 버퍼 등의 일련의 서비스를 제공할 것으로 기대한다.
디자이너를 재호스팅함에 있어서의 제1 단계는 로더 및 디자인 화면을 생성하는 것이다. 로더는 XOML 파일을 로드하는 일과 활동을 유지하는 디자이너 호스트 하부구조를 구축하는 일을 맡고 있다. 디자인 화면은 그 안에 디자이너 호스트 하부구조를 유지하며 디자인 화면을 호스팅 및 그와 상호작용하기 위한 서비스를 제공한다. 디자인 화면은 서비스 프로바이더 뿐만 아니라 서비스 컨테이너로서 기능한다. 일례에서, 이하의 코드는 XOML 문서를 로드하고 활동을 그 안에 유지하는 디자이너 호스트를 구축하기 위해 실행된다.
this.loader.XomlFile = filePath;
if(this.surface.IsLoaded == false)
this.surface.BeginLoad(this.loader);
이하의 서비스들은 디자이너에서 여러가지 함수를 가능하게 해준다. ISelectionService 함수는 선택된 객체들을 유지한다. IToolboxService 함수는 도구 상자와의 상호작용을 관리한다. IMenuCommandService 함수는 메뉴와의 상호작용을 관리한다. ITypeProvider 함수는 타입 시스템(type system)을 가능하게 해준다. 게다가, 진보된 디자이너 특징을 가능하게 해주기 위해 디자이너 호스팅 환경에 의해 제공되는 부가의 서비스가 있을 수 있다.
타입 시스템은 본 발명의 컴포넌트 모델 프레임워크 내의 컴포넌트이다. 디자이너가 프로젝트 시스템 내에서 호스팅될 때, TypeProvider 객체는 프로젝트마다 생성된다. 프로젝트 내의 어셈블리 참조(assembly reference)는 타입 프로바이더(type provider)로 푸시(push)된다. 게다가, 프로젝트 내의 사용자 코드 파일들은 파싱되고 단일의 코드 컴파일 단위(code compile unit)가 생성되어 타입 프로바이더로 푸시된다. 게다가, 본 발명은 타입들이 타입 시스템에서 변경되게 할 수 있는 프로젝트 시스템 내의 이벤트들에 주목하고 그 변경에 응답하여 타입들을 재로드하기 위해 타입 프로바이더에 대한 적절한 호출을 행한다.
실행 취소/재실행(undo/redo)
스케쥴을 생성하고 제대로 구축한 후에, 개발자는 일련의 수행된 동작들을 롤백하고자 할 수 있다. 본 발명의 실행 취소 및 재실행 함수는 어느 활동이 직접 영향을 받았는지를 보여주는 시각적 피드백을 제공한다. 예를 들어, 활동에 관한 프로퍼티 변경을 실행 취소시키려면, 영향을 받은 활동이 선택하게 된다. 다수의 객체의 삭제를 실행 취소시켜서, 관련된 모든 객체들이 스케쥴로 복원되도록 할 때 그 모든 객체들을 선택하게 된다. 실행 취소/재실행은 다른 분야의 많은 애플리케이션에걸쳐 사용되는 공통적인 특징이며, 그의 의미는 잘 알려져 있다. 조정 엔진 디자이너에서, 실행 취소/재실행 아이템은 저장(Save)과 동시에 제거(purge)되지 않는다. 또한, 실행 취소/재실행은 개발자가 뷰들 사이를 전환할 때 프로세스/작업 흐름 뷰, XOML 뷰에서 또한 코드 비사이드에서 수행될 수 있다.
실행 취소/재실행은 프로세스/작업 흐름 뷰에서 이하의 동작, 즉 활동 드래그 및 드롭(예를 들어, 활동을 도구 상자로부터 디자인 화면으로 드래그, 활동을 스케쥴의 한 부분에서 다른 부분으로 이동, 및 활동을 한 디자이너로부터 다른 디 자이너로 이동), 활동의 구성(예를 들어, 활동에 대한 프로퍼티를 지정), 및 잘라내기/복사/붙여넣기/삭제에 대하여 제공된다.
일 실시예에서, 직렬화된 뷰(예를 들어, XOML 뷰)는 텍스트 에디터의 표준 실행취소/재실행 동작을 제공하는 XML 에디터이다. 본 발명의 디자이너는 프로세스/작업 흐름 뷰에서 변경이 행해지고 이어서 직렬화된 뷰에서 실행취소되면 직렬화된 코드가 상실될 것임을 알려주는 피드백을 개발자에게 제공한다. 개발자가 프로세스/작업 흐름 뷰에서 스케쥴의 일부분을 구축하고, 직렬화된 뷰로 전환한 다음에 실행취소/재실행 동작을 수행하기로 결정하면, 경고가 나타나게 된다.
전형적인 운영 환경
도 10은 컴퓨터(130) 형태의 범용 컴퓨팅 장치의 일례를 나타낸 것이다. 본 발명의 일 실시예에서, 컴퓨터(130) 등의 컴퓨터는 본 명세서에 예시되고 기술된 다른 도면들에서 사용하기에 적합하다. 컴퓨터(130)는 하나 이상의 프로세서 또는 프로세싱 유닛(132) 및 시스템 메모리(134)를 갖는다. 예시된 실시예에서, 시스템 버스(136)는 시스템 메모리(134)를 비롯한 여러가지 시스템 컴포넌트들을 프로세서(132)에 연결시킨다. 버스(136)는 메모리 버스 또는 메모리 콘트롤러를 비롯한 몇가지 유형의 버스 구조 중 임의의 것, 주변 장치 버스, AGP(accelerated graphics port) 및 다양한 버스 아키텍처 중 임의의 것을 사용하는 프로세서 또는 로컬 버스 중 하나 이상을 나타낸다. 예로서, 이러한 아키텍처는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 및 메자닌 버스 라고도 하는 PCI(Peripheral Component Interconnect) 버스를 포함하나, 이에만 한정되지는 않는다.
컴퓨터(130)는 일반적으로 적어도 어떤 형태의 컴퓨터 판독가능 매체를 갖는다. 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체 둘다를 포함하는 컴퓨터 판독가능 매체는 컴퓨터(130)에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함하나, 이에만 한정되지 않는다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등의 정보를 저장하기 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 포함한다. 예를 들어, 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨터(130)에 의해 액세스될 수 있는 임의의 다른 매체를 포함한다. 통신 매체는 일반적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 기타 데이터를 반송파 또는 기타 전송 메카니즘 등의 변조된 데이터 신호에 구현한 것이며, 임의의 정보 전달 매체를 포함한다. 당업자라면 변조된 데이터 신호를 잘 알고 있으며, 하나 이상의 특성을 그 신호에 실린 정보를 부호화하는 방식으로 설정 또는 변경시킨 신호를 의미한다. 유선 네트워크 또는 유선에 의한 직접 연결과 같은 유선 매체와, 음향, RF, 적외선, 및 기타 무선 매체 등의 무선 매체가 통신 매체의 예들이다. 상기의 임의의 것들을 조 합한 것도 역시 컴퓨터 판독가능 매체의 범위 내에 포함된다.
시스템 메모리(134)는 분리형 및/또는 비분리형, 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 예시된 실시예에서, 시스템 메모리(134)는 판독 전용 메모리(ROM)(138) 및 랜덤 액세스 메모리(RAM)(140)를 포함한다. 시동 중과 같은 때에 컴퓨터(130) 내의 구성요소들 간의 정보의 전달을 돕는 기본적인 루틴을 포함하는 기본 입출력 시스템(142)(BIOS)은 일반적으로 ROM(138)에 저장된다. RAM(140)은 일반적으로 프로세싱 유닛(132)이 즉각적으로 액세스가능하고 및/또는 현재 그에 의해 처리되고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 예로서, 도 10은 운영 체제(144), 애플리케이션 프로그램(146), 기타 프로그램 모듈(148), 및 프로그램 데이터(150)를 예시하고 있으나, 이에만 한정되지 않는다.
컴퓨터(130)는 또한 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 예를 들어, 도 10은 비분리형, 비휘발성 자기 매체로부터 판독하거나 그에 기록하는 하드 디스크 드라이브(154)를 예시하고 있다. 도 10은 또한 분리형, 비휘발성 자기 디스크(158)로부터 판독하거나 그에 기록하는 자기 디스크 드라이브(156), 및 CD-ROM 또는 기타 광학 매체 등의 분리형, 비휘발성 광학 디스크(162)로부터 판독하거나 그에 기록하는 광디스크 드라이브(160)를 도시하고 있다. 전형적인 운영 환경에서 사용될 수 있는 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래쉬 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태 RAM, 고체 상태 ROM, 및 기타 등등을 포함하지만, 이에 한정되는 것은 아니다. 하드 디스크 드라이브(154), 자기 디스크 드라이브(156) 및 광학 디스크 드라이브(160)는 일반적으로 인터페이스(166) 등의 비휘발성 메모리 인터페이스에 의해 시스템 버스(136)에 연결된다.
앞서 논의되고 도 10에 예시된 드라이브 또는 다른 대용량 저장 장치 및 그와 관련된 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 컴퓨터(130)에 제공한다. 도 10에서, 예를 들어 하드 디스크 드라이브(154)는 운영 체제(170), 애플리케이션 프로그램(172), 기타 프로그램 모듈(174), 및 프로그램 데이터(176)를 저장하는 것으로 예시되어 있다. 유의할 점은 이들 컴포넌트가 운영 체제(144), 애플리케이션 프로그램(146), 기타 프로그램 모듈(148), 및 프로그램 데이터(150)와 동일할 수도 있고 서로 다를 수도 있다는 것이다. 운영 체제(170), 애플리케이션 프로그램(172), 기타 프로그램 모듈(174), 및 프로그램 데이터(176)는 최소한 이들이 다른 복사본이라는 것을 예시하기 위해 여기서는 다른 번호가 부여되어 있다.
사용자는 키보드(180) 및 포인팅 장치(182)(예를 들어, 마우스, 트랙볼, 펜, 또는 터치 패드) 등의 입력 장치 또는 입력 인터페이스 선택 장치를 통해 명령 및 정보를 컴퓨터(130)에 입력할 수 있다. 다른 입력 장치(도시 생략)으로는 마이크로폰, 조이스틱, 게임 패드, 위성 안테나, 스캐너 또는 기타 등등이 있을 수 있다. 이들 및 다른 입력 장치는 시스템 버스(136)에 연결되어 있는 사용자 입력 인터페이스(184)를 통해 프로세싱 유닛(132)에 연결되지만, 병렬 포트, 게임 포트, 또는 USB(Universal Serial Bus) 등의 다른 인터페이스 및 버스 구조에 의해 연결될 수 도 있다. 모니터(188) 또는 다른 유형의 디스플레이 장치도 역시 비디오 인터페이스(190) 등의 인터페이스를 통해 시스템 버스(136)에 연결된다. 모니터(188) 이외에, 컴퓨터는 종종 출력 장치 인터페이스(도시 생략)을 통해 연결될 수 있는 프린터 및 스피커 등의 다른 주변 출력 장치(도시 생략)를 포함한다.
컴퓨터(130)는 원격 컴퓨터(194) 등의 하나 이상의 원격 컴퓨터로의 논리적 연결을 사용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(194)는 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타 통상의 네트워크 노드일 수 있으며, 일반적으로 컴퓨터(130)와 관련하여 전술한 구성요소들 대부분 또는 그 전부를 포함한다. 도 10에 도시한 논리적 연결은 근거리 통신망(LAN)(196) 및 광역 통신망(WAN)(198)을 포함하지만, 다른 네트워크를 포함할 수 있다. LAN(196) 및/또는 WAN(198)은 유선 네트워크, 무선 네트워크, 이들의 조합일 수 있다. 이러한 네트워킹 환경은 사무실, 기업 규모의 컴퓨터 네트워크, 인트라넷, 및 전세계 컴퓨터 네트워크(예를 들어, 인터넷)에서 흔한 것이다.
지역 네트워킹 환경에서 사용되는 경우, 컴퓨터(130)는 네트워크 인터페이스(186) 또는 어댑터를 통해 LAN(196)에 연결된다. 광역 네트워킹 환경에서 사용되는 경우, 컴퓨터(130)는 일반적으로 인터넷 등의 WAN(198)을 통해 통신을 설정하는 모뎀(178) 또는 다른 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(178)은 사용자 입력 인터페이스(184) 또는 기타 적절한 메카니즘을 통해 시스템 버스(136)에 연결된다. 네트워크화된 환경에서, 컴퓨터(130)와 관련하여 도시된 프로그램 모듈 또는 그의 일부분은 원격 메모리 저장 장치(도시 생략)에 저장될 수 있 다. 예로서, 도 10은 원격 애플리케이션 프로그램(192)을 그 메모리 장치에 존재하는 것으로 예시하고 있으나 이에만 한정되지 않는다. 도시된 네트워크 연결은 전형적인 것으로서 컴퓨터들 사이에 통신 링크를 설정하는 다른 수단이 사용될 수 있다.
일반적으로, 컴퓨터(130)의 데이터 프로세서는 컴퓨터의 여러가지 컴퓨터 판독가능 저장 매체에 서로 다른 시점에 저장된 명령어들에 의해 프로그램될 수 있다. 프로그램 및 운영 체제는 일반적으로 예를 들어 플로피 디스크 또는 CD-ROM으로 배포된다. 그로부터, 프로그램 및 운영 체제는 컴퓨터의 보조 기억 장치에 설치 또는 로드된다. 실행 시에, 이들은 적어도 부분적으로 컴퓨터의 전자적인 주기억 장치에 로드된다. 본 명세서에 기술된 본 발명은 이들 및 다른 여러가지 유형의 컴퓨터 판독가능 저장 매체가 마이크로프로세서 또는 다른 데이터 프로세서와 연계하여 이하에 기술되는 단계들을 구현하기 위한 명령어 또는 프로그램을 포함하는 경우 이러한 매체를 포함한다. 본 발명은 본 명세서에 기재된 방법 및 기술에 따라 프로그램되어 있는 컴퓨터 그 자체도 포함한다.
설명을 위해, 운영 체제 등의 프로그램 및 다른 실행가능 프로그램 컴포넌트는 본 명세서에서 별개의 블록으로서 예시되어 있다. 그렇지만, 이러한 프로그램 및 컴포넌트는 다양한 시점에서 컴퓨터의 서로 다른 저장 컴포넌트에 존재하며 또 컴퓨터의 데이터 프로세서(들)에 의해 실행된다는 것을 잘 알 것이다.
컴퓨터(130)를 비롯하여 전형적인 컴퓨팅 시스템 환경과 관련하여 기술되어 있지만, 본 발명은 수많은 다른 범용 또는 전용 컴퓨팅 시스템 환경 또는 구성에서 동작한다. 컴퓨팅 시스템 환경은 본 발명의 사용 또는 기능의 범위에 관한 어떤 제한을 가하려는 것이 아니다. 게다가, 컴퓨팅 시스템 환경은 전형적인 운영 환경에서 예시된 컴포넌트들의 임의의 것 또는 조합에 관하여 어떤 의존관계 또는 요구사항을 갖는 것으로 해석되어서는 안된다. 본 발명에서 사용하기에 적합한 공지의 컴퓨팅 시스템, 환경, 및/또는 구성의 예들은 퍼스널 컴퓨터, 서버 컴퓨터, 핸드-헬드 또는 랩톱 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 셋톱 박스, 프로그램가능 가전 제품, 휴대 전화, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기 시스템 또는 장치 중 임의의 것을 포함하는 분산 컴퓨팅 환경, 및 기타 등등을 포함하지만, 이에 한정되는 것은 아니다.
본 발명은 하나 이상의 컴퓨터 또는 다른 장치에 의해 실행되는 프로그램 모듈 등의 컴퓨터 실행가능 명령어의 일반적인 관점에서 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정의 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 및 데이터 구조를 포함하지만 이에 한정되는 것은 아니다. 본 발명은 또한 태스크들이 통신 네트워크를 통해 링크되어 있는 원격 프로세싱 장치들에 의해 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 비롯한 로컬 및 원격 컴퓨터 저장 매체 둘다에 위치될 수 있다.
소프트웨어 아키텍처의 관점에서의 인터페이스는 소프트웨어 모듈, 컴포넌트, 코드 부분 또는 다른 컴퓨터 실행가능 명령어 시퀀스를 포함한다. 인터페이스는 예를 들어 제1 모듈 대신에 컴퓨팅 태스크를 수행하는 제2 모듈을 액세스하는 제1 모듈을 포함한다. 제1 및 제2 모듈은 일례에서 운영 체제에 의해 제공된 것 등의 애플리케이션 프로그래밍 인터페이스(API), COM(component object model, 컴포넌트 객체 모델) 인터페이스(예를 들어, 피어-투-피어 애플리케이션 통신을 위한 것임), 및 XMI(extensible markup language metadata interchange format, XML 메타데이터 교환 포맷) 인터페이스(예를 들어, 웹 서비스간의 통신을 위한 것임)를 포함한다.
인터페이스는 J2EE(Java 2 Platform Enterprise Edition), COM, 또는 DCOM(distributed COM) 예에서와 같은 밀접하게 결합된 동기적 구현(tightly coupled, synchronous implementation)일 수 있다. 다른 대안으로서 또는 그에 부가하여, 인터페이스는 웹 서비스에서와 같은 느슨하게 결합된 비동기적 구현(loosely coupled, asynchronous implementation)일 수 있다[예를 들어, SOAP(simple object access protocol, 단순 객체 액세스 프로토콜)을 사용함]. 일반적으로, 인터페이스는 이하의 특성, 즉 밀접하게 결합, 느슨하게 결합, 동기적, 및 비동기적의 임의의 조합을 포함한다. 게다가, 인터페이스는 표준 프로토콜(standard protocol), 독점적 프로토콜(proprietary protocol), 또는 표준 프로토콜과 독점적 프로토콜의 임의의 조합에 부합한다.
본 명세서에 기술된 인터페이스는 모두 단일 인터페이스의 일부이거나 개별적 인터페이스들로서 또는 그들의 임의 조합으로서 구현될 수 있다. 인터페이스는 기능을 제공하기 위해 지역적으로 또는 원격적으로 실행될 수 있다. 게다가, 인터페이스는 본 명세서에 예시되거나 기술된 것보다 더 많거나 더 적은 기능을 포함할 수 있다.
본 명세서에 예시되고 기술된 방법의 실행 또는 수행의 순서는 달리 언급하고 있지 않는 한 필수적인 것은 아니다. 즉, 본 방법의 구성요소들은 달리 언급하지 않는 한 임의의 순서로 수행될 수 있으며, 본 방법은 본 명세서에 개시된 것보다 더 많거나 더 적은 구성요소들을 포함할 수 있다. 예를 들어, 특정의 구성요소를 다른 구성요소보다 이전에, 그와 동시에 또는 그 이후에 실행 또는 수행하는 것은 본 발명의 범위 내에 속하는 것으로 본다.
본 발명의 구성요소 또는 본 발명의 실시예(들)를 소개할 때, 이, 그, 저, 및 상기 등의 관형사는 하나 이상의 구성요소가 있음을 의미하기 위한 것이다. 용어 "구성하는", "포함하는", 및 "갖는"은 포함적 의미를 위한 것으로서 열거된 구성요소 이외에 부가의 구성요소가 있을 수 있음을 의미한다.
상기의 관점에서, 본 발명의 몇 가지 목적이 달성되고 다른 유익한 결과가 얻어짐을 알 수 있다.
본 발명의 범위를 벗어나지 않고 상기 구성, 제품, 및 방법에 여러가지 변경이 행해질 수 있기 때문에, 상기 설명에 포함되고 첨부 도면에 도시된 모든 것들은 예시적인 것으로 해석되어야 하며 한정적 의미로 해석되어서는 안된다.
부록 A
전형적인 활동 및 그의 전형적인 구현
전형적인 활동으로는 다음과 같은 것, 즉 Send, SendRequest, SendResponse, Receive, ReceiveRequest, ReceiveResponse, Code, Delay, Fault, Suspend, Terminate, InvokeSchedule, InvokeSchedules, InvokeWebService, DotNetEventSource, DotNetEventSink, Sequence, Parallel, While, ConditionalBranch, Conditional, Constrained, ConstrainedActivityGroup(CAG), EventDriven, Listen, EventHandlers, ExceptionHandler, ExceptionHandlers, Compensate, CompensationHandler, Scope, 및 Schedule이 있다.
상기 열거된 활동 클래스는 그의 메타데이터 선언을 지원하는 일련의 타입에 의존한다. 이들 타입으로는 DataElement, LiteralElement, MemberDeclaration, VariableDeclaration, TypedVariableDeclaration, MessageDeclaration, CorrelationSetDeclaration, ChannelDeclaration, TypedChannelDeclaration, HandlerDeclaration, TypedHandlerDeclaration, RuleDeclaration, CodeExpressionRuleDeclaration, DeclarativeExpressionRuleDeclaration, ParameterDeclaration, ParameterDeclarationCollection, ParameterBinding, 및 ParameterBindingCollection이 있다.
게다가, 어떤 활동들이 메타데이터로서 필요로 하는 코드-비사이드 메소드의 타입으로 매핑되는 정의된 일련의 표준 델리게이트 타입(standard delegate type)이 있다. 게다가, 스케쥴의 직렬화[XomlSerializer 및 관련 타입] 및 컴파일 [XomlComplier 및 관련 타입]을 지원하는 일련의 유틸리티 클래스(utility class)가 있다. 스케쥴을 컴파일하기 위한 커맨드 라인 도구인 유틸리티 wfc.exe(예를 들어, "작업 흐름 컴파일러")가 있다.
Send 활동들
조정 엔진은 메시지를 전송하기 위한 3개의 활동을 제공하며, 그 각각은 서로 다른 사용 사례(use case)에 대처한다. 게다가, 3개의 활동이 어떤 메타데이터를 공유하기 때문에, 추상 베이스 클래스(abstract base class)가 정의되고 셋 모두의 상위 클래스(superclass)로서 사용된다.
SendBase
메타데이터:
■ 메시지 참조
■ 선택적인 코드-비사이드 메소드
■ 선택적인 상관 세트 컬렉션
Send
메타데이터:
○ 메시지 참조
○ 선택적인 코드-비사이드 메소드
○ 선택적인 상관 세트 컬렉션
■ untyped(타입 비지정)이거나 typed(타입 지정)일 수 있는 아웃바운드 채널 참조. 채널이 typed이면, 동작도 역시 채널 선언 상에 지정된다.
실행
Send 활동은 지정된 메시지를 지정된 채널 상으로 전송한다. typed 채널이 사용되는 경우, Send 활동은 특정의 동작을 이용한다. 이 동작은 void를 반환하도록 정의되어야만 한다. untyped 채널은 임의의 타입의 메시지를 접수한다. 메시지가 전송되기 전에, 선택적인 코드-비사이드 핸들러가 호출된다. 이 핸들러의 통상의 용도는 전송하게 될 메시지를 초기화하거나 그렇지 않으면 준비하는 것이다. Send 활동은 또한 지정되어 있는 임의의 상관 세트를 초기화한다. Send 활동은 상관 세트를 따르지 않는다. Send는 동기 방식으로 실행된다(Send는 완료될 때까지 그의 쓰레드를 양보하지 않는다).
SendRequest
목적: 요청-응답 메시지 패턴의 일부로서 요청 메시지를 전송함
메타데이터:
○ 메시지 참조
○ 선택적인 코드-비사이드 메소드
○ 선택적인 상관 세트 컬렉션
■ untyped 또는 typed 일 수 있는 아웃바운드 채널 참조. 채널이 typed인 경우, 동작도 역시 지정된다.
실행:
SendRequest 활동은 지정된 메시지를 지정된 채널 상으로 전송한다. typed 채널이 사용되는 경우, Send 활동은 특정의 동작을 이용한다. 이 동작은 void가 아닌 다른 타입을 반환하도록 정의되어야만 한다(주의: 이것이 SendRequest가 Send와 다른 점이다). untyped 채널은 임의의 타입의 메시지를 접수한다. 메시지가 전송되기 전에, 선택적인 코드-비사이드 핸들러가 호출된다. 이 핸들러의 통상의 용도는 전송되어질 메시지를 초기화하거나 그렇지 않으면 준비하는 것이다. SendRequest 활동은 또한 지정되어 있는 임의의 상관 세트를 초기화한다. SendRequest/ReceiveResponse 쌍만을 포함하고 다른 수신 활동은 포함하지 않는 간단한 스케쥴에서, 상관 세트는 명시적으로 생성되거나 초기화될 필요가 없으며, 요청 및 응답 메시지의 상관은 자동으로 수행될 것이다. Send 활동은 상관 세트를 따르지 않는다. SendRequest는 동기 방식으로 실행된다(SendRequest는 완료될 때까지 그의 쓰레드를 양보하지 않는다).
SendResponse
목적: 요청-응답 메시지 패턴의 일부로서 응답 메시지를 전송함
메타데이터:
○ 메시지 참조
○ 선택적인 코드-비사이드 메소드
○ 선택적인 상관 세트 컬렉션
■ ReceiveRequest 활동의 ID
실행:
SendResponse 활동은 관련 ReceiveRequest 활동 상에서 선언된 채널 상으로 지정된 메시지를 전송한다. typed 채널이 사용되는 경우, SendResponse 활동은 ReceiveRequest 활동에 의해 지시된 동작을 이용한다. 이 동작은 void가 아닌 다른 타입을 반환하도록 정의되어야만 한다. untyped 채널은 임의의 타입의 메시지를 접수한다. 메시지가 전송되기 전에, 선택적인 코드-비사이드 핸들러가 호출된다. 이 핸들러의 통상의 용도는 전송되어질 메시지를 초기화하거나 그렇지 않으면 준비하는 것이다. SendResponse 활동은 또한 지정되어 있는 임의의 상관 세트를 초기화한다. Send 활동은 상관 세트를 따르지 않는다. SendResponse는 동기 방식으로 실행된다(SendResponse는 완료될 때까지 그의 쓰레드를 양보하지 않는다).
Receive 활동들
조정 엔진은 메시지를 수신하기 위한 3개의 활동을 제공하며, 그 각각은 서로 다른 사용 사례에 대처한다. 게다가, 3개의 활동이 어떤 메타데이터를 공유하기 때문에, 추상 베이스 클래스(abstract base class)가 정의되고 셋 모두의 상위 클래스(superclass)로서 사용된다.
ReceiveBase
목적: 수신 활동에 대한 추상 베이스 클래스
메타데이터:
■ 메시지 참조
■ 선택적인 코드-비사이드 메소드
■ 선택적인 상관 세트 컬렉션
Receive
목적: 메시지를 수신함
메타데이터:
○ 메시지 참조
○ 선택적인 코드-비사이드 메소드
○ 선택적인 상관 세트 컬렉션
■ 이것이 작동 중인 수신(activating receive)인지 여부를 가리키는 부울값
■ untyped 또는 typed 일 수 있는 인바운드 채널 참조. 채널이 typed인 경우, 동작도 역시 지정된다.
실행:
Receive 활동은 지정된 채널 상으로 메시지가 도달하길 기다리는 블로킹 대기(blocking wait)를 수행한다. typed 채널이 사용되는 경우, Receive는 채널의 특정 동작에 관한 특정의 타입의 메시지의 도착을 기다린다. 이 동작은 void를 반환하도록 정의되어야만 한다. untyped 채널은 임의의 타입의 메시지를 전달한다. Receive가 작동 중인 수신인 경우, 지시된 채널 상으로 메시지가 도달한다면 Receive가 그의 일부인 스케쥴의 새로운 인스턴스가 생성되어 실행되도록 하는 특별한 신청이 구성될 것이다. Receive 보다 앞서서 상관 세트가 채널 상으로 설정되는 메시지 신청에 사용된다. 이렇게 함으로써 스케쥴 인스턴스는 그 인스턴스로 향해오는 메시지만을 수신한다. 메시지를 수신한 후에, Receive 활동은 초기화를 필요로 하는 것으로 지정되어 있는 임의의 상관 세트를 초기화한다. 그 다음에, 선택적인 코드-비사이드 핸들러가 호출된다. 이 핸들러의 통상의 용도는 어떤 방식으로 메시지를 처리하는 것이다.
ReceiveRequest
목적: 요청-응답 메시지 패턴의 일부로서 요청 메시지를 수신함
메타데이터:
○ 메시지 참조
○ 선택적인 코드-비사이드 메소드
○ 선택적인 상관 세트 컬렉션
■ 이것이 작동 중인 수신(activating receive)인지 여부를 가리키는 부울값
■ untyped 또는 typed 일 수 있는 인바운드 채널 참조. 채널이 typed인 경우, 동작도 역시 지정된다.
실행:
ReceiveRequest 활동은 지정된 채널 상으로 메시지가 도달하길 기다리는 블 로킹 대기(blocking wait)를 수행한다. typed 채널이 사용되는 경우, ReceiveRequest는 채널의 특정 동작에 관한 특정의 타입의 메시지의 도착을 기다린다. 이 동작은 void가 아닌 다른 타입을 반환하도록 정의되어야만 한다(이것이 ReceiveRequest가 Receive와 다른 점이다). untyped 채널은 임의의 타입의 메시지를 전달한다. ReceiveRequest가 작동 중인 수신인 경우, 지시된 채널 상으로 메시지가 도달한다면 ReceiveRequest가 그의 일부인 스케쥴의 새로운 인스턴스가 생성되어 실행되도록 하는 특별한 신청이 구성될 것이다. ReceiveRequest 보다 앞서서 상관 세트가 채널 상으로 설정되는 메시지 신청에 사용된다. 이렇게 함으로써 스케쥴 인스턴스는 그 인스턴스에 대한 것인 메시지만을 수신한다. 메시지를 수신한 후에, ReceiveRequest 활동은 초기화를 필요로 하는 것으로 지정되어 있는 임의의 상관 세트를 초기화한다. 그 다음에, 선택적인 코드-비사이드 핸들러가 호출된다. 이 핸들러의 통상의 용도는 어떤 방식으로 메시지를 처리하는 것이다. ReceiveRequest/SendResponse 쌍만을 포함하고 다른 수신 활동은 포함하지 않는 간단한 스케쥴에서, 상관 세트는 명시적으로 생성되거나 초기화될 필요가 없으며, 요청 및 응답 메시지의 상관이 자동으로 수행될 것이다.
ReceiveResponse
목적: 요청-응답 메시지 패턴의 일부로서 응답 메시지를 수신함
메타데이터:
○ 메시지 참조
○ 선택적인 코드-비사이드 메소드
○ 선택적인 상관 세트 컬렉션
■ SendRequest 활동의 ID
실행:
ReceiveResponse 활동은 관련 SendRequest 활동에 관해 지정된 채널 상으로 메시지가 도달하길 기다리는 블로킹 대기(blocking wait)를 수행한다. typed 채널이 사용되는 경우, ReceiveResponse 활동은 SendRequest 활동에 의해 지시된 동작을 이용한다. 이 동작은 void가 아닌 다른 타입을 반환하도록 정의되어야만 한다. untyped 채널은 임의의 타입의 메시지를 전달한다. ReceiveResponse 활동은 상관 세트를 따르지 않는다. 메시지가 수신된 후에, 선택적인 코드-비사이드 핸들러가 호출된다. 이 핸들러의 통상의 용도는 수신된 메시지를 처리하는 것이다. 메시지를 수신한 후에, ReceiveResponse 활동은 초기화를 필요로 하는 것으로 지정되어 있는 임의의 상관 세트를 초기화한다. 그 다음에, 선택적인 코드-비사이드 핸들러가 호출된다. 이 핸들러의 통상의 용도는 메시지를 어떤 방식으로 처리하는 것이다.
Code
목적: 코드-비사이드로 구현된 메소드를 실행함
메타데이터:
■ 코드-비사이드 메소드
실행:
Code 활동은 메타데이터에 지시된 코드-비사이드 메소드를 실행한다. Code는 동기 방식으로 실행된다(Code는 완료될 때까지 그의 쓰레드를 양보하지 않는다). 따라서, 코드-비사이드 메소드의 실행은 수행될 것으로 기대되고 어떤 외부 리소스에 대한 의존성으로 인해 블로킹되어서는 안된다. 예를 들어, 이 코드는 일반적으로 웹 서비스를 호출해서는 안된다. Code 활동의 통상의 용도는 스케쥴 인스턴스 상태를 검사하고 지역 변수 및 메시지를 조작하는 것이다.
Delay
목적: 장래의 특정의 DateTime에 도달될 때까지 기다림
메타데이터:
■ DateTime을 반환하는 코드-비사이드 메소드
인스턴스 데이터:
■ Delay가 그 때가 되기를 기다리고 있는(또는 기다렸던) DateTime 값. 이 값은 Delay가 실제로 실행을 시작할 때까지 널(null)로서 보고된다.
실행:
Delay 활동은 DataTime 값을 생성하기 위해 그의 필수적인 코드-비사이드 메소드를 실행한다. Delay 활동은 내부적으로 그의 인스턴스 데이터에 관한 TimeoutValue 프로퍼티를 이 값으로 설정한다. DateTime이 과거인 경우, Delay는 즉각 완료된다. 그렇지 않은 경우, 타이머가 기동될 때 통지를 받도록 Delay는 타 이머 신청(timer subscription)을 설정한다. 타이머가 기동될 때, Delay가 통지 되고 완료된다. 수신 활동과 마찬가지로, Delay는 그의 실행을 동기적으로 완료하지 않는다. 그 대신에, Delay는 그의 쓰레드를 양보하고 DataTime에 도달되었다는 통지를 기다린다.
엔진에 의해 표면화되는 하부 타이머 서비스의 특성에 기초하여, Delay 활동은 지시된 DateTime이 되자마자 완료하도록 보장되어 있지만, 사실은 더 오래 걸리게 되는데 그 이유는 타이머 통지가 (예를 들어, 서버 환경에서의 높은 시스템 스트레스(system stress)로 인해) DateTime에 도달된 얼마간 후에 일어날 수 있기 때문이다. 유의할 점은 Delay가 예상되로 동작하기 위해서는 UTC 시각이 반환되어야만 한다는 것이다. 많은 경우에, 이것은 DateTime 값을 반환하는 코드 핸들러에서 DateTime.Now 대신에 DateTime.UtcNow를 사용하는 것을 의미한다.
Fault
목적: 예외를 던짐
메타데이터: 예외를 반환하는 코드-비사이드 메소드
실행:
Fault 활동은 Exception 객체를 생성하기 위해 그의 필수적인 코드-비사이드 메소드를 실행한다. Fault 활동은 이어서 이 예외를 던진다. 기능적으로, Fault 활동은 ExceptionProvider에 의해 생성된 예외를 던지기만 하는 코드-비사이드 메소드를 갖는 Code 활동과 동등하다. Fault의 목적은 스케쥴에 대한 프로세스 메타 데이터의 일부로서 비지니스 예외의 던짐을 포착하는 것이다. 그것이 예외를 던진다른 사실로 인해, Fault 활동은 Faulted라는 보고된 결과를 갖는데, 이것이 이 활동의 통상의 실행을 구성한다는 사실에도 불구하고 그렇다.
Suspend
목적: 실행 중인 스케쥴 인스턴스를 정지함
메타데이터:
■ 관리자에게 보고할 에러 메시지
실행:
Suspend 활동은 현재의 스케쥴 인스턴스를 정지시킨다. 이것이 의미하는 것은 엔진이 정지된 인스턴스의 큐잉된 임의의 아이템에 대한 쓰레드의 처리를 즉각 중단한다는 것이며, "Cancel" 신호가 발생되지 않는다. 호스트(예를 들어, 인스턴스 관리자 및 영속성 제공자(persistence provider))는 에러 메시지가 어디로 가는지를 결정한다.
Terminate
목적: 실행 중인 스케쥴 인스턴스를 종료함
메타데이터:
■ 관리자에게 보고할 에러 메시지
실행:
Terminate 활동은 현재의 스케쥴 인스턴스를 종료시킨다. 이것이 의미하는 바는 Suspend에서와 같이 엔진이 종료된 인스턴스의 아이템에 대한 쓰레드의 처리를 즉각 중단한다는 것이다. Terminate에서, 큐잉된 아이템들도 역시 삭제되는데 그 이유는 인스턴스가 재개될 가능성이 없기 때문이다. Suspend에서와 같이, "Cancel" 신호가 발생되지 않는다. 호스트(예를 들어, 인스턴스 관리자 및 영속성 제공자(persistence provider))는 에러 메시지가 어디로 가는지를 결정한다.
InvokeSchedule
목적: 스케쥴을 호출함
메타데이터:
● 호출될 스케쥴의 타입
● 그 호출이 CALL 또는 EXEC 시맨틱스를 갖는지 여부를 가리키는 enum
● 일련의 파라미터 바인딩
● 스케쥴에 호출되기 전에 호출되는 선택적인 코드-비사이드 메소드
실행:
InvokeSchedule 활동은 먼저 OnInitializeCalle 코드-비사이드 메소드가 지정되어 있는 경우 그를 호출한다. 일반적으로, 이 메소드는 호출될 스케쥴 인스턴스에 대한 In 파라미터를 설정하는 데 사용된다. InvokeSchedule은 이어서 지정된 타입의 스케쥴 인스턴스를 생성 및 호출하고, 제공된 파라미터를 전달한다. InvokeSchedule 활동은 호출 시맨틱스가 CALL인 경우 블록킹된다(그리고 그의 쓰레 드를 양보한다). 다른 대안에서, 호출 시맨틱스가 EXEC인 경우, InvokeSchedule 활동은 스케쥴 인스턴스가 호출되면 즉각 완료된다. InvokeSchedule은 OnCompletedCalle 코드-비사이드 메소드가 지정되어 있는 경우 그를 호출한다. 일반적으로, 이 메소드는 호출된 스케쥴 인스턴스에 대한 Out 파라미터를 처리한다.
InvokeWebService
목적: 웹 서비스를 호출함
메타데이터:
● 웹 서비스를 호출하는 데 사용되는 프록시 클래스의 이름
● 호출될 웹 서비스 상의 메소드의 이름
● 호출이 동기화되어 있는지 여부를 가리키는 부울값
● 일련의 파라미터 바인딩
실행:
프록시 클래스를 통해 웹 서비스를 호출하고, 지정된 파라미터를 전달 및 수신한다.
DotNetEventSink
목적: 이전에 호출된 (자식) 스케쥴 내에서 RaiseEvent 메소드 또는 DotNetEventSource 활동을 통해 발생되는 이벤트의 처리를 모델링함
메타데이터:
● 처리될 이벤트의 발생에서 지시된 델리게이트(delegate)와 동일한 타입인 코드-비사이드 내의 메소드
인스턴스 데이터: ActivityState를 넘지 않음
실행:
이전에 호출된 스케쥴 인스턴스에 의해 지정된 이벤트가 발생되었다는 통지를 기다리면서 블록킹한다. 호출된 스케쥴 인스턴스는 CALL 시맨틱스 하에서 실행되고 있어야만 한다.
DotNetEventSource
목적: 기능상 RaiseEvent 메소드를 통해 코드-비사이드에서 이벤트를 발생하는 것과 동등한 이벤트의 발생을 모델링함
메타데이터:
● 발생되고 있는 이벤트의 타입을 가리키는 델리게이트 타입(및 이벤트를 처리하는 데 필요한 핸들러의 타입)
● 델리게이트 타입 상에서 정의된 메소드 파라미터들에 대한 파라미터 바인딩
실행:
지정된 이벤트를 발생시키고 즉각 실행을 종료한다. 이 이벤트에 대한 가입자의 수에 관한 보장이 없으며(0 이상일 수 있다), 이 이벤트의 잠재적인 핸들러(들)로부터 데이터를 다시 가져오기 위한 메카니즘도 없다. 즉 시맨틱이 fire-and- forget(발사하고 잊어버리기, 즉 결과를 생각하지 않음)이다.
Sequence
목적: 단일의 정의된 순서에 따라 일련의 자식 활동을 실행함
실행:
Sequence 활동은 순서화된 방식으로 한번에 하나씩 일련의 자식 활동의 실행을 조정한다. Sequence는 마지막 자식 활동이 완료될 때 완료된다.
Parallel
목적: 일련의 자식 활동을 동시에 실행함
실행:
Paralle 활동은 일련의 자식 활동을 병행하여 실행한다. 실행을 위해 자식 활동들이 인에이블되는 순서는 비결정적이다. Paralle은 모든 자식 활동이 완료될 때 완료된다. 조정 엔진의 쓰레딩 모델로 인해, 실제로 Paralle 내의 단지 하나의 활동만이 주어진 시점에서 실행되고 있을 수 있다.
While
목적: 자식 활동을 반복적으로 실행함
메타데이터:
● 반복을 통제하는 규칙
실행:
자식 활동을 반복적으로 실행한다. (첫번째 것을 포함하여) 각각의 반복 이전에, 규칙이 평가되고, 규칙이 false로 평가되면, While 활동은 완료된다.
ConditionalBranch
목적: Conditional의 분기를 나타냄
메타데이터:
● 래핑된 활동(wrapped activity)(분기)의 조건부 실행을 통제하는 규칙
실행:
Sequence 시맨틱스에 따라 자식 활동을 실행한다. 부모 Conditional 활동은 ConditionalBranch가 실행되어야만 하는지 여부를 결정하기 위해 메타데이터(규칙)을 검사하는 일을 맡고 있다. Conditional 활동 그 자체는 (ID 및 Description 이외의) 어떤 부가의 프로퍼티도 제공하지 않는다. 그렇지만, Conditional은 프로퍼티를 노출시키는 조건부 분기로 이루어져 있다. ConditionalBranch의 선택 시에, 2개의 부가 컨텍스트 메뉴 동작, Move Left(선택된 ConditionalBranch를 conditional에서 그의 바로 왼쪽으로 이동시킴) 및 Move Right(선택된 ConditionalBranch를 conditional에서 그의 바로 오른쪽으로 이동시킴)이 나타난다.
Conditional
목적: n개의 ConditionalBranch 활동 중 하나를 조건부로 실행함
실행:
Conditional 활동은 일련의 순서화된 ConditionalBranch 활동을 포함한다. Conditional은 TRUE로 평가되는 규칙을 갖는 첫번째 ConditionalBranch 활동을 실행한다. 마지막 ConditionalBranch 활동은 규칙을 지정하도록 허가되어 있지 않으며, 이 경우 그 활동은 항상 TRUE로 평가되는 것으로 간주된다. Conditional이 어떤 자식 활동도 실행하지 않고 완료되는 것이 가능하다. 기본적으로, 이것은 IF-ELSEIF-ELSE 시맨틱스를 제공한다.
Constrained
목적: 활동을 CAG에 부가하기 위해 그 활동을 래핑함.
메타데이터:
● 래핑된 활동에 대한 인에이블 규칙(enable rule)
● 래핑된 활동에 대한 디스에이블 규칙(disable rule)
런타임 프로퍼티:
● 래핑된 활동이 적어도 한번 완료되었는지를 가리키는 정수
실행:
Constrained 활동의 유일한 허용된 부모는 CAG이다. CAG 자체는 Constrained 활동을 언제 실행해야하는지를 결정하기 위해 그에 대해 인에이블 규칙 및 디스에이블 규칙을 이용한다. Constrained 활동이 CAG에 의해 실행되도록 지시받은 경우, Constrained 활동은 단지 자신이 래핑하고 있는 활동을 실행할 뿐이다.
Constrained 활동이 그의 실행을 완료할 때 Performed 프로퍼티가 증가된다. 이 프로퍼티는 부모 CAG 자체가 재실행될 때에만(예를 들어, While 루프 내에서 또는 두번째 외부 CAG 내에서) 0으로 리셋된다.
CAG(Constrained Activity Group)
목적: 일련의 자식 Constrained 활동의 제약 기반 실행을 제공함
메타데이터:
● 완료 규칙(completion rule)
실행:
CAG는 Constrained 활동만을 포함한다. CAG가 실행될 때, CAG는 자식 활동들의 인에이블 및 디스에이블 제약의 평가에 기초하여 그 활동들을 실행(및 재실행)한다. 자식 활동은 그의 인에이블 규칙이 true로 평가되고 그의 디스에이블 규칙이 false로 평가될 때에만 CAG에 의해 실행된다. 구체적으로는, CAG는 그의 서브트리를 살펴보고 모든 활동에 대한 활동 상태 변경을 신청하며, 이것은 호출 경계에서 중단된다. CAG는 활동이 그의 서브트리에 동적으로 부가될 때마다 신청을 부가한다. CAG는 스케쥴 경계에 이르기까지 그의 둘러싸는 스코프 및 모든 부모 스코프에 대한 데이터 변경을 신청하며, 이들 신청은 CAG 내의 모든 Constrained 활동에 대한 인에이블 및 디스에이블 규칙에 대한 분석에 의해 결정된다. 엔진은 데이터 변화의 일괄적인 통지를 전달하며, CAG는 어느 규칙을 평가해야 하는지를 결정할 것이다. 유의할 점은 호출이 완료될 때 호출된 스케쥴에 의해 이루어진 데이터 변경이 통지된다는 것이다. 그 변수들이 코드-비사이드 메소드를 통해 간접적으로 액세스되더라도 스코프 변수 종속성을 식별하는 것이 가능하다. 그 자체로서, 변수가 변경될 때 어느 제약이 재평가되어야만 하는지를 결정함에 있어서 아주 구체적으로 하는 것이 가능하다. 이러한 동일 메카니즘이 선언적 규칙 및 코드 규칙 둘다에 대해 동작된다. constrained 활동이 인에이블 규칙을 갖지 않는 경우, 그것은 항상 true로 된다.
constrained 활동이 디스에이블 규칙을 갖지 않는 경우, 그것은 항상 Performed>0으로 된다. 따라서, constrained 활동에 대해 어떤 규칙도 지정되지 않은 경우, 그 활동은 CAG가 실행될 때 즉각 실행되며, 재실행되지 않는다. 이와 마찬가지로, constrained 활동에 대해 커스텀 인에이블 규칙만이 제공되어 있는 경우, 그 활동은 인에이블 규칙이 true로 평가될 때 실행되고, 그 한번만 실행될 뿐이다. 제약 기반 재실행이 요망되는 경우, 적절한 커스텀 디스에이블 규칙이 적절한 인에이블 규칙과 함께 제공되어야만 한다.
이하의 표는 constrained 활동을 실행하는 데 필요한 조건을 예시한 것이다.
Constrained 활동 실행
인에이블 규칙 디스에이블 규칙 활동이 실행될 수 있는가?
TRUE FALSE 예
TRUE TRUE 아니오
FALSE FALSE 아니오
FALSE TRUE 아니오
활동의 실행 동안에 그 활동에 대한 디스에이블 규칙이 true로 평가되는 경우, CAG는 그 활동의 실행을 취소한다. 이것이 그 활동의 재실행을 막지는 않는다. CAG의 완료 규칙이 true로 평가되자마자, CAG는 현재 실행 중인 어떤 자식 활동이라도 즉각 취소시키고, 이어서 그 자신이 완료된다. 모든 규칙(인에이블, 디스에이블, 완료)은 그의 데이터 및 상태 변화 종속성에 기초하여 필요할 때마다 평가된다.
CAG는 2가지 동작 모드, Preview(미리보기) 및 Edit(편집)를 제공한다. CAG 디자이너가 Preview 모드에 있는 경우, 개발자는 슬라이드로 나타나는 활동만을 선택할 수 있다. 개발자가 임의의 활동을 선택했을 때, 프로퍼티 브라우저는 Enable 및 Disable 규칙 옵션(이하에 상세히 기술함)을 노출시킨다. 이것에 의해 개발자는 CAG로 각 활동에 대한 인에이블 및 디스에이블 규칙을 설정할 수 있다. CAG 디자이너가 Design(디자인) 모드에 있는 경우, 개발자는 미리보기 윈도우(Constrained 라고 함)에서 그 활동을 클릭할 수 있다. 이어서, 프로퍼티 브라우저는 특정 활동에 의해 통상 노출되는 프로퍼티 이외에 Enable 및 Disable 규칙 옵션(Preview 모드 등에서)을 디스플레이한다.
CAG 디자이너는 몇가지 부가의 컨텍스트 메뉴 옵션을 제공한다.
Preview Activity(활동 미리보기)
선택된 활동이 주어지면, CAG는 디자인 모드로부터 미리보기 모드로 전환된다.
Edit Activity(활동 편집)
선택된 활동이 주어지면, CAG는 Preview 모드에서 Design 모드로 전환된다.
View Previous Activity(이전 활동 보기)
슬라이드에서 현재 선택된 활동 바로 앞에 있는 활동으로 이동한다. CAG 슬라이드에서 첫번째 활동에 도달하면, 이 메뉴 옵션은 디스에이블된다.
View Next Activity(다음 활동 보기)
슬라이드에서 현재 선택된 활동 바로 뒤에 있는 활동으로 이동한다. CAG 슬라이드에서 마지막 활동에 도달하면, 이 메뉴 옵션은 디스에이블된다.
일 실시예에서, CAG 내의 각 활동은 "constrained 활동" 내에 래핑된다. 이것은 이어서 CAG의 슬라이드를 통해 개발자에게 노출된다. CAG가 미리보기 모드에 있고 개발자가 이 활동을 선택하여 그를 복사하면, 그 활동이 붙여넣기될 수 있는(따라서 결과로 얻어지는 컨텍스트 메뉴가 인에이블되는) 유일한 곳은 또하나의 CAG 내이다. 그렇지만, 개발자가 CAG 모드에서 "Design"으로 전환하고 미리보기 창 내에서 그 활동을 선택하면, 복사/붙여넣기 및 드래그-드롭이 나머지 활동들에서와 같이 유사한 방식으로 인에이블된다.
Task
목적: 하나 이상의 주체(principal)에 의해 수행되는 외부 작업 단위를 모델링함. InvokeSchedule 또는 커스텀 활동인 템플릿 활동을 래핑함.
메타데이터:
● 병렬 또는 순차 실행을 가리키는 실행 모드
● 하부 태스크 구현의 타입(템플릿이라고 함)
● 태스크의 양수인을 가리키는 역할
● 개발자가 양수인별로 태스크 프로퍼티를 설정할 수 있게 해주는 선택적인 코드-비사이드 메소드
실행:
태스크가 실행될 때, 먼저 역할이 일련의 주체들(양수인)로 변환된다. 역할이 비어있는 경우, 예외가 던져진다. 템플릿 활동이 각 양수인에 대해 한번 복제(clone)되고, 클론의 프로퍼티를 초기화하기 위한 선택적인 코드-비사이드 메소드(예가 이하에 있음)가 있는 경우 그것이 호출된다. 실행 모드에 따라, 개별적인 양수인 태스크가 병렬로 또는 순차로 실행된다. 이것을 달성하기 위해, 각각의 양수인 태스크(클론)는 적절한 인에이블 및 디스에이블 규칙 세트를 갖는 constrained 활동 내에 효과적으로 래핑된다. 유의할 점은 실행 모드가 순차적일 경우 그 시퀀스가 역할 변환(role resolution)에 의해 반환되는 양수인의 순서에 의해 결정된다는 것이다. CAG(태스크의 부모 활동)에서와 같이, 완료 규칙이 true가 되면, 태스크는 완료되고 미처리된 클론은 취소된다. 그렇지 않은 경우, 태스크는 모든 양수인 태스크(클론)가 완료될 때 완료된다.
EventDriven
목적: 그의 실행이 "이벤트" 활동에 의해 트리거되는 활동을 래핑함
실행:
EventDriven 활동은 Listen 또는 EventHandlers 복합 활동인 부모를 가져야만 한다. EventDriven 활동은 IEventActivity 및 임의의 타입의 제2 활동 둘다를 포함한다. IEventActivity는 정의에 의해 타이머의 기동 또는 메시지의 도착 등의 어떤 이벤트의 발생 중에 블로킹된다. 이벤트가 발생하면, IEventActivity는 그의 실행을 완료하고, 이어서 제2 활동이 실행된다.
(일반적으로 EventHandlers 또는 Listen 활동 내에서) EventDriven의 선택 시에, 2개의 부가 컨텍스트 메뉴 동작, Move Left(선택된 EventDriven을 conditional에서 그의 바로 좌측으로 이동시킴) 및 Move Right(선택된 EventDriven을 conditional에서 그의 바로 우측으로 이동시킴)이 나타난다.
Listen
목적: n개의 자식 EventDriven 활동 중 하나를 조건부로 실행함
실행:
Listen 활동은 그의 EventDriven 자식의 이벤트가 발생하도록 하는 그의 자식 EventDriven 활동 중 첫번째 것만이 실행될 수 있도록 보장한다. 다른 모든 것들은 취소된다. 개념적으로, n개의 분기 중 정확히 1개가 실행되며, 이 때 그 분기의 선택이 절차적 비지니스 로직에 의하기 보다는 이벤트의 발생에 의해 결정된다는 점에서, Listen은 Conditional과 유사하다.
EventHandlers
목적: 일련의 EventDriven 활동을 래핑함. EventHandlers 활동은 단지 관련 스코프가 사용하기 위한 일련의 EventDriven 활동을 보유한다. EventHandlers 활동은 Scope에만 관련될 수 있다.
ExceptionHandler
목적: 스코프에 대한 catch 블록(catch block)을 나타내는 메타데이터로 활동을 래핑함
메타데이터:
● catch 블록의 타입을 가리키는 enum
○ All - 모든 예외를 잡아냄(catch)
○ Type - 지정된 타입의 예외를 잡아냄
○ Variable - 지정된 타입의 예외를 잡아내고 그 예외를 코드-비사이드의 지역 변수에서 검사할 수 있도록 함
● 잡아낸 예외의 타입을 가리키는 프로퍼티(enum이 Type로 설정된 경우에만 사용됨)
● 예외가 배치될 지역 변수에 대한 참조(enum이 Variable로 설정된 경우에만 사용됨)
실행:
일 실시예에서, ExceptionHandler 활동은 ExceptionHandlers 활동에만 부가될 수 있다. ExceptionHandlers 활동과 연관된 Scope는 Scope가 예외를 수신할 때 그의 일련의 ExceptionHandler 활동들 중 어느 것을 실행할지를 결정하기 위해 그 활동들에 관한 메타데이터를 이용한다. Scope에 의해 ExceptionHandler 활동이 실행되도록 지시된 때, ExceptionHandler 활동은 단지 그가 래핑하고 있는 활동을 실행할 뿐이다. ExceptionHandlers의 선택 시에, 2개의 부가 컨텍스트 메뉴 동작, View Previous Activity, View Next Activity가 나타난다.
ExceptionHandlers
목적: 일련의 순서화된 ExceptionHandlers 활동들을 래핑함. ExceptionHandlers 활동은 단지 관련 Scope가 사용하기 위한 일련의 ExceptionHandler 활동을 보유할 뿐이다. 일 실시예에서, ExceptionHandlers 활동은 Scope에만 관련될 수 있다. 2개 이상의 ExceptionHandler 활동이 존재하는 경우, "Move Left" 및 "Move Right" 컨텍스트 메뉴 옵션이 인에이블된다.
Compensate
목적: 완료된 자식 스코프를 보상함.
메타데이터:
● 보상할 자식 스코프의 ID
실행:
Compensate 활동은 스코프에 대한 보상 핸들러(compensation handler) 또는 예외 핸들러 내에만 존재할 수 있다. 그의 목적은 완료된 자식 스코프의 보상 핸들러를 트리거하는 것이다.
CompensationHandler
목적: 스코프에 대한 보상 핸들러로서 정의된 자식 활동을 래핑함.
실행:
그의 자식 활동을 실행함. CompensationHandler 활동은 Scope에만 관련될 수 있다.
Scope
목적: 스코프는 트랜잭션 경계, 예외 처리 경계, 보상 경계, 이벤트 처리 경계, 및 메시지, 변수, 상관 세트, 및 채널 선언(즉, 공유 데이터 상태)에 대한 경계이다. Scope 활동은 논리적 컨테이너로서 기능하는 일군의 활동이다. 종종 Scope의 목적은 일련의 포함된 활동들에 트랜잭션 시맨틱스를 적용시키는 것이다.
메타데이터:
● 스코프의 코드-비사이드 클래스의 Type
● 스코프가 동기화된 스코프인지 여부를 가리키는 부울값
● 스코프의 트랜잭션 특성에 관련된 몇가지 프로퍼티
○ 트랜잭션의 타입: 없음(none), 원자적(atomic), 또는 장기 실행(long-running)
○ 격리 수준(트랜잭션이 원자적인 경우)
■ Chaos: 보다 고도로 격리된 트랜잭션으로부터의 보류 중인 변경은 오버라이트될 수 없다.
■ ReadCommitted: 데이터가 더티 리드(dirty read)를 회피하기 위해 읽혀지고 있는 동안 공유 로크(shared lock)가 보유되지만, 데이터는 트랜잭션의 종료 이전에 변경될 수 있고, 그 결과 비반복가능 읽기(non-repeatable read) 또는 유령 데이터(phantom data)로 된다.
■ ReadUncommitted: 더티 리드가 있을 수 있으며, 공유 로크가 발행되지 않고 배타적 로크(exclusive lock)가 존중되지 않음을 의미한다.
■ RepeatableRead: 쿼리에서 사용되는 모든 데이터에 로크가 걸리고, 다른 사용자들이 데이터를 업데이트하지 못하도록 함. 비반복가능 읽기를 방지하지만 유령 행(phantom row)이 여전히 있을 수 있다.
■ Serializable: DataSet에 범위 로크가 걸리고, 트랜잭션이 완료될 때까지 다른 사용자들이 행을 업데이트하거나 데이터세트에 행을 삽입하지 못하도록 한다.
■ Snapshot: 한 애플리케이션이 읽을 수 있는 데이터의 버전을, 다른 애플리케이션이 동일 데이터를 수정하고 있는 동안 저장함으로써 블로킹을 감소시킴. 재쿼리를 하는 경우조차도 한 트랜잭션에서 행해진 변경을 다른 트랜잭션으로부터는 볼 수 없음을 알려줌.
■ Unspecified: 지정된 것과 다른 격리 수준이 사용되고 있지만, 그 수준이 확정된 것일 수는 없음.
○ 타임아웃(단위: 초)(트랜잭션이 원자적일 경우)
○ 트랜잭션이 재시도될 수 있는지 여부(트랜잭션이 원자적일 경우)
○ 트랜잭션이 일괄 처리 가능(batchable)한지 여부(트랜잭션이 원자적일 경우)
○ 타임아웃 값을 가리키는 DateTime을 반환하는 코드-비사이드 메소드(트랜잭션이 장기 실행인 경우)
● 스코프가 실행되기 시작할 때 실행되는 코드-비사이드 메소드. 이것은 기본적으로 스코프 내의 첫번째 활동으로서 Code 활동과 동등하다. 이 메소드는 스코프에 대한 어떤 이벤트 핸들러도 실행될 수 있기 전에 완료되도록 보장된다. 여기서 예외는 단지 스코프 내부의 Code 활동 내에서의 예외로서 취급된다.
● 스코프가 실행을 종료할 때 실행되는 코드-비사이드 메소드. 이것은 스코프 내의 마지막 활동으로서 Code 활동과 거의 동등하며, 이 코드는 임의의 인스턴스화된 이벤트 핸들러가 그의 실행을 종료한 후에만 실행된다. 여기서 예외는 단지 스코프 내부의 Code 활동 내에서의 예외로서 취급된다.
● 일련의 선택적인 이벤트 핸들러
● 선택적인 일련의 순서화된 예외 핸들러(원자적 트랜잭션인 스코프에 대해서는 유효하지 않음)
● 선택적인 보상 핸들러
실행:
Scope 내에서의 활동들의 실행은 순차적이며, 따라서 Sequence에서처럼 스코프가 구축될 때 내포된 활동들은 명시적으로 순서화된다. 다른 복합 타입에서와 같이, 스코프는 어떤 제한들의 구속을 받으면서 내포될 수 있다. 개발자가 스코프 내에서 선언되지 않은 그 스코프 내의 임의의 프로퍼티에 대한 타입을 참조하고 있는 경우, 그 프로퍼티는 프로퍼티 브라우저 내에서 외부 호출 스케쥴 이름으로 완전히 자격을 갖추게(full qualified) 된다. 통상의 상황하에서, Scope 활동은 단순히 기동하는 그의 이벤트 핸들러 중 임의의 것 뿐만 아니라 그의 "메인" 자식 활동을 실행한다. OnScopeInitialized 코드-비사이드 메소드가 지정되면, 그 메소드는 스코프 내에서의 첫번째 아이템으로서의 Code 활동인 것처럼 실행된다. 이벤트 핸들러는 Scope의 "메인" 자식 활동과 동시에 실행되며 Scope의 실행의 선택적이지만 정상적인 측면인 것으로 간주된다. Listen 활동에서와 같이, 이벤트 핸들러 내의 첫번째 활동은 IEventActivity이어야만 한다. 일반적으로, 이것은 수신 활동 또는 Delay이지만, 적절한 인터페이스를 구현하는 임의의 커스텀 활동일 수 있다. 특정의 이벤트 핸들러가 주어진 Scope에 대해 2회 이상 실행될 수 있으며, 이벤트 핸들러의 이들 인스턴스가 동시에 실행되는 것도 가능하다. 새로운 인스턴스가 각각의 이벤트 핸들러에 대해 기동하는 각각의 "이벤트"에 대해 생성되도록 보장되어 있다. Scope의 "메인" 자식 활동이 그의 실행을 완료할 때, 모든 현재 실행 중인 이벤트 핸들러 인스턴스는 그의 실행을 정상적으로 종료할 수 있다. 그렇지만, 임의의 이벤트 핸들러의 새로운 인스턴스가 차후에 생성되지 않는다. OnScopeCompleted 코드-비사이드 메소드가 지정되어 있는 경우, 그 메소드는 스코프의 메인 보디가 종료되고 또 모든 보류 중인 이벤트 핸들러가 종료된 후에 실행된다.
기본적으로, 스코프의 OnInitialized 및 OnCompleted 메소드는 확실히 스코프 내에 있다. 그 메소드가 받는 유일한 "특별 취급"은,
● OnInitialized 메소드가 완료되기 전에는 어떠한 이벤트 핸들러도 시작될 수 없다.
● (Scope의 메인 보디와 함께) 모든 현재 실행 중인 이벤트 핸들러가 완료될 때까지 OnCompleted 메소드가 실행되지 않는다.
● OnCompleted 메소드가 시작되면, 어떤 이벤트 핸들러도 더 이상 실행될 수 없다. 이벤트 핸들러에서 발생하는 예외는 Scope의 "메인" 자식 활동에서 발생되는 예외와 완전히 똑같은 방식으로 처리된다. Scope가 동기화된 스코프로 표시되어 있는 경우, 이것은 공유 데이터에 대한 안전한 동시 액세스를 보장해준다. 동기화된 스코프는 내포될 수 없다. 동일한 공유 데이터(둘다에 대해 외부적인)에 액세스하는 동기화된 스코프는 그 데이터에 대한 그의 읽기/쓰기 동작의 결과가 스코프가 직렬로 실행된 경우와 다르지 않도록 보장된다. Scope는 또한 예외 처리 경계로서도 기능하며, 이는 Scope의 예외 핸들러가 그 스코프 내의 모든 내포된 활동들(임의의 이벤트 핸들러를 포함함)에 의해 공유된다는 것을 의미한다. 비원자적인 Scope 내에서 실행 중인 활동에 의해 예외가 던져진 경우, 스코프는 다른 모든 실행 중인 활동 및 이벤트 핸들러 인스턴스를 취소하고, 이어서 그 스코프가 예외를 잡아낼 수 있는 예외 핸들러를 갖는 경우 그 예외를 처리한다. 예외 핸들러가 실행되면, Scope는 Failed의 결과로 완료된다. 특정의 예외 타입에 대한 비원자적 스코프에 대해 예외 핸들러가 정의되지 않은 경우, 또는 예외 핸들러가 예외를 던지는 경우, (잡아내지 못한 예외 모두에 대해) 자식 스코프에 대한 모든 설치된 보상 핸들러(이하에 설명함)를 그 자식 스코프의 완료의 역순으로 실행하고 이어서 그의 부모 스코프로 예외를 다시 던지는 디폴트 핸들러가 생성된다.
원자적 스코프는 관련 예외 핸들러를 가질 수 없다. 원자적 스코프의 실행 동안에 예외가 발생하면, 그 스코프의 실행이 그러한 것처럼 트랜잭션이 실패한다. 스코프는 자체적으로 그 예외를 처리하는 기능을 갖고 있는 그 다음의 외곽 스코프(next outer enclosing scope)로 전파되는 예외를 생성한다. 실행이 정상적으로(예외가 발생되지 않았음을 의미함) 완료된 스코프는 그의 보상 핸들러가 "설치(install)"되어 있다. 이 보상 핸들러는 부모 스코프의 예외 핸들러 또는 부모 스코프의 보상 핸들러 내부로부터 Compensate 활동을 통해 차후에 호출될 수 있다. 완료된 스코프에 대해 보상 핸들러가 정의되어 있지 않은 경우, 자식 스코프의 완료의 역순으로 자식 스코프에 대한 모든 설치된 보상 핸들러를 실행하는 디폴트 핸들러가 설치된다. 이러한 경우, 어떤 예외 핸들러의 관점에서만 보상이 행해진다. 보상 핸들러의 실행 동안에 예외가 발생하면, 그것은 그 예외 핸들러 내의 예외로서 취급된다.
표준 컨텍스트 메뉴 옵션 이외에, Scope 활동은 이하의 부가의 메뉴 옵션을 노출한다.
View Scope
이것은 디자이너에 부가될 때 스코프의 디폴트 뷰이다. 이 옵션을 선택하면 개발자는 다시 이 뷰로 가게 된다.
View Exceptions
이 옵션을 선택하면 Scope와 연관된 예외를 적소에 디스플레이하기 위해 UI를 변경한다. 이것은 Transaction Type(트랜잭션 타입)이 Long Running(장기 실행) 또는 None(없음)인 경우에만 인에이블된다. 달리 말하면, 이 메뉴는 트랜잭션 타입이 Atomic(원자적)인 경우에는 이용할 수 없다.
View Events
이 옵션을 선택하면 Scope와 연관된 이벤트 핸들러를 적소에 디스플레이하기 위해 UI를 변경한다.
View Compensation
이 옵션을 선택하면 Scope로 정의된 Compensation을 적소에 디스플레이하기 위해 UI를 변경한다. 이것은 트랜잭션 타입 프로퍼티가 Long Running 또는 Atomic로 설정되어 있는 경우에만 인에이블된다.
Schedule
목적: Schedule은 조정 엔진이 실행하는 유일한 상위 레벨 활동이다.
메타데이터(Scope 메타데이터 이외의 것):
● 스케쥴 타입의 네임스페이스
● 스케쥴이 독립형 애플리케이션인지 라이브러리(다른 스케쥴로부터 호출됨을 의미함)인지를 나타내는 CompilationType enum
● XOML 포맷으로 된 전체 스케쥴의 표현
● 파라미터 선언
실행:
In 및 Optional-In 파라미터를 사용하여 Out 파라미터를 생성할 필요가 있는 것을 제외하고는, Schedule은 Scope와 완전히 동일하게 실행된다.
파라미터:
스케쥴의 메타데이터의 일부는 그의 실행에 참여하는 파라미터의 세트이다.
Composite 활동
제어 흐름을 가능하게 해주는 복합 활동 타입은 Sequence, Parallel, Constrained Activity Group, Conditional, While, Listen이 있다. 그 밖에, Scope 및 Schedule도 그 안에 활동들의 암시적인 시퀀스를 갖는 컨테이너로서 기능하는 복합 활동 타입이다.
ID 및 Description 프로퍼티
모든 활동은 ID 및 Description 프로퍼티를 제공한다. 활동을 도구 상자로부터 디자인 화면으로 드래그할 때, 이 ID는 자동적으로 생성된다. Description 프로퍼티는 개발자가 타이핑하기 위한 위치 보유자(placeholder)이다. 일반적인 용도 시나리오는 개발자가 특정의 조건 분기가 무엇을 위해 사용될 수 있는지의 짧은 설명을 제공하는 것을 포함한다. 개념적으로, 이 프로퍼티를 비쥬얼 베이직 및 C# 코드 에디터에서의 //와 동등한 것으로 생각하라.
도움말 텍스트
프로퍼티 브라우저에서 프로퍼티를 선택할 때, 개발자는 F1 키를 쳐서 그 프로퍼티에 대한 온라인 도움말을 인덱싱할 수 있다. 각각의 활동에 대한 각각의 프로퍼티는 관련 도움말 텍스트를 제공한다.
태스크 에러 리스트 및 프로퍼티 브라우저 통합
활동의 프로퍼티가 불충분하게 구성되어 있을 때, 개발자는 느낌표를 포함하는 아이콘을 제공받는다. 그러면, 개발자는 그 아이콘을 클릭하여 구성 에러의 드롭다운 리스트를 볼 수 있다. 에러들 중 하나를 선택하면 포커스가 프로퍼티 브라우저로 이동하여 에러가 있는 프로퍼티를 하이라이트한다. 활동의 프로퍼티가 완벽하면 그 아이콘은 사라진다. 에러가 있는 구성은 또한 "태스크 리스트"에서도 볼 수 있다. 태스크 리스트에 제공된 에러 메시지를 더블클릭하면 개발자는 직접 프로퍼티 브라우저 내의 프로퍼티로 간다.
ID 생성
디자이너에 부가되는 임의의 활동의 디폴트 식별자는 이미 존재하는 유사한 활동의 개수에 기초하여 생성된다. 활동이 부가 및 제거될 때, 식별자가 범위 내의 개방 슬롯에 의해 생성된다. 예로서, 부가된 첫번째 Send 활동은 '1'을 식별자로 가지며, 두번째 것은 '2'를 가지고, 이하 마찬가지이다. 그렇지만, 5개의 Send 활동이 존재하는 경우, 개발자는 (삭제 또는 잘라내기를 통해) 번호 3을 제거하고 이어서 나중에 (복사/잘라내기/붙여넣기를 통해 또는 도구 상자를 통해) 다른 Send를 재부가하면, 식별자는 '3'이 되어야 한다.
ID에 유효한 이름
개발자는 (유효한 이스케이프드 이름(escaped name)을 비롯하여) 프로젝트의 언어에서 유효한 ID에 대한 임의의 이름을 제공할 수 있다.
활동의 다중 선택
개발자는 종종 일군의 활동을 선택하고 이들을 스케쥴의 다른 영역으로 이동시키기를 원한다. 이것은 활동별 레벨에서(on an activity by activity level) 달성될 수 있지만, 개발자가 한번에 다수의 활동을 선택하여 이들을 이 새로운 영역으로 드래그할 가능성이 더 많다.
활동들이 동일한 타입인 경우, 프로퍼티 브라우저는 공통 프로퍼티의 대량 구성을 가능하게 하도록 인에이블된다. 예를 들어, 선택된 활동들 모두가 제약된(constrained) 활동 그룹인 경우, 개발자가 구성하는 데 Completion Condition 프로퍼티가 이용가능하다.
개발자가 다양한 서로 다른 타입을 선택하는 경우, 프로퍼티 브라우저는 활동들이 공유하는 프로퍼티(예를 들어, ID 및 description)를 구성하는 기능을 제공할 뿐이다. 다중 선택 동안, 선택된 활동들은 활동의 코너 상의 파란색 표시자로 장식된다. 이들 표시자는 파란색 점들로 표시된다. 키보드 포커스를 갖는 활동은 다르게 장식된다. 이 활동은 포커스 상태의 활동임을 나타내기 위해 꽉찬 부분 대 빈 부분으로 된 채움 패턴(solid versus hollow fill)이 된다.
핸들러 및 변수 생성
많은 활동들은 코드 비사이드에 변수 및/또는 코드 핸들러를 생성하는 프로퍼티를 노출한다. 어느 한 활동을 수행하는 모든 프로퍼티는 각 활동에 대한 프로퍼티 브라우저 통합에서 호출된다. 새로운 변수 또는 핸들러의 생성은 개발자가 프로퍼티 브라우저를 통해 새로운 변수 또는 핸들러 이름을 지정할 때 수행된다. Send에 대한 메시지 변수를 예로서 보자. 타입 System.String의 'm1'을 지정할 때, 그 결과 얻어지는 비사이드 코드는 다음과 같다.
public OEMessage<System.String> m1 = new OEMessage<System.String>();
코드 비사이드 변수 또는 핸들러를 생성하는 프로퍼티에 대해 다른 값을 지정함으로써, 새로운 변수 또는 핸들러가 생성된다. 기존의 변수/핸들러는 그대로 있다. 생성된 변수(또는 개별적인 핸들러)를 삭제하는 것은 개발자의 책임이다. 개발자가 코드 비사이드에서 기존의 변수의 이름을 변경하는 시나리오에서, 그것을 참조하는 활동들은 업데이트되지 않는다. 다시 말하면 이 새로운 변수를 갖는 원래의 변수를 참조한 각각의 활동을 업데이트하는 것은 개발자가 할 일이다.
특정의 활동들에 대한 핸들러에 적용될 때 스케쥴 전반에 걸친 복사/붙여넣기 및 드래그-드롭 동작은 그와 연관된 핸들러에는 적용되지 않는다. Scope에 적용될 때, 변수 및 코드 핸들러의 생성은 약간 다른 방식으로 거동한다. 보다 구체적으로는, 생성된 변수 및 코드 핸들러는 Scope 클래스의 정의 내에 배치된다. 활동의 스코프로부터 모든 private, protected, internal 및 public 메소드 및 변수는 (타입과 서명이 일치하는 한) 활동 상에서 설정될 수 있다. 활동의 둘러싸는 스코프들로부터의 모든 public 및 internal 메소드 및 변수는 (타입 및 서명이 일치하는 한) 활동 상에서 합법적으로 설정될 수 있다.
결과적으로, 메뉴로부터 또는 프로퍼티 브라우저로부터 이들 변수 및 핸들러를 생성하는 동안, 규칙들은 다음과 같다.
● 변수 또는 메소드가 활동의 스코프 내에서 생성되는 경우, 그것은 private로 생성된다.
● 변수 또는 메소드가 활동의 둘러싸는 스코프 중 임의의 것에서 생성되는 경우, 그것은 public로 생성된다.
컨텍스트 메뉴
활동 상에서 우측 클릭을 하면, 그의 관련 디자이너는 개발자에게 활동 관련 동작들을 제공한다. 예를 들어, 스코프 상에서 우측 클릭을 하면, 표준의 "View Code", Cut/Copy/Paste 파라미터 이외에 "View Scope, View Exceptions, View Events"가 제공된다.
여기에 공통점에 기초하여 택할 수 있는 가능한 동작들의 리스트가 있다.
View Code
선택된 활동과 연관된 코드를 봄. 활동이 선택되고 핸들러가 지정된 경우, 이 옵션을 선택하면 개발자는 지정된 핸들러로 가게 된다.
Cut
선택된 활동을 디자이너로부터 제거하고 그를 클립보드로 복사함
Copy
선택된 활동을 클립보드로 복사함
Paste
이전에 복사된 활동을 클립보드로부터 디자이너로 붙여넣기를 함. 어떤 선택 영역도 선택되지 않은 경우, 활동은 스케쥴 내의 활동으로서 복사된다.
Delete
선택된 활동을 삭제함
Properties
선택된 활동에 대한 프로퍼티 브라우저를 채워 넣고 포커스를 그에게로 설정함
Generate Handlers
선택된 활동에 대한 대응하는 핸들러들을 생성함
Expand
그의 구성 부분들을 노출시키도록 디자이너를 확장시킴
Collapse
그의 구성 부분들을 숨기도록 디자이너를 축소시킴
핫링크/하이퍼링크 프로퍼티 브라우저 통합
각각의 활동은 프로퍼티 브라우저 내의 하이퍼링크 등의 컨텍스트 메뉴 옵션을 제공한다. 모든 프리미티브 활동에 있어서, 이것은 "Generate Handlers"를 포함한다. 각각의 복합 활동은 "Expand/Collapse" 및 활동에 관련한 컨텍스트 메뉴 옵션을 제공한다. 이들은 활동별 레벨에서 상세히 기술한다.
활동 코멘팅(Activity Commenting)
조정 엔진 디자이너는 사용자가 복잡한 계층적 스케쥴을 생성할 수 있게 해준다. 이들 스케쥴은 아주 복잡하고 데뷰(dubut)하기 어려울 수 있다. 코멘팅 기능은 코멘트된 활동이 런타임 시에 실행되지 않도록 사용자에게 스케쥴의 일부를 코멘트 아웃(comment out)하는 기능을 제공한다. 이것은 디버깅을 단순화시키고 사용자가 한꺼번에 스케쥴의 일부의 실행을 모니터링할 수 있게 해준다. 활동들은 스케쥴로부터 그의 "의사" 제거를 가능하도록 하기 위해 부울 프로퍼티를 노출시킨다. 이 활동은 여전히 스케쥴에 존재하지만, 런타임 시에 그의 존재는 무시되고 실행되지 않는다. 개발자는 프로퍼티 브라우저에 노출된 프로퍼티를 설정하는 것에 의해 또한 컨텍스트 메뉴를 통해 코멘팅을 인에이블/디스에이블할 수 있다.
코멘팅 기능은 런타임 의미 뿐만 아니라 디자인시 의미도 갖는다. 사용자는 디자이너에 의해 제공된 사용자 인터페이스를 사용할 수 있을 뿐만 아니라 프로그램적으로 활동을 코멘트할 수 있다. 디자이너는 형상을 선택하고 프로퍼티 브라우저를 사용하여 코멘트 프로퍼티를 true로 설정하며 활동들을 러버밴딩(rubberbanding) 및 다중 선택(multi selecting)하고 컨텍스트 메뉴 상에서 코멘트 메뉴 옵션을 선택함으로써 사용자가 형상들을 코멘트할 수 있게 해준다. 코멘트에 응답하여, 디자이너는 활동 디자이너를 반투명하게 렌더링한다. 사용자가 활동 디자이너를 선택하여 그에 관한 프로퍼티를 설정하는 것이 가능하다. Xoml은 그 안에 코멘트된 형상을 계속하여 가지고 있으며, 유일한 차이점은 코멘트 프로퍼티가 true로 설정된다는 것이다. 디자인시 검증은 코멘트된 활동을 건너뛰고 활동이 존재하지 않는 것처럼 거동한다. 런타임 시에, 저작 객체 모델은 활동 및 실행가능 활동을 반환하는 2가지 컬렉션을 제공한다. 런타임은 실행가능 활동에 작용한다.
부록 B
활동 디자이너
IActivityDesigner 인터페이스는 작업 흐름에 참여할 필요가 있는 모든 활동 디자이너에 의해 구현된다. 이것은 디자이너가 다른 디자이너 및 작업 흐름 뷰와 대화하는 데 사용하는 프로토콜이다. 작업 흐름 뷰는 이벤트를 렌더링, 레이아웃 또는 디자이너로 포워드하기 위해 IActivityDesigner 인터페이스를 찾는다. IActivityDesigner 인터페이스를 지원하면 디자이너가 실제로 윈도즈 콘트롤로부터 파생되지 않았지만 모든 디자이너는 윈도즈 콘트롤처럼 기능할 수 있다. 이 인터페이스는 또한 작업 흐름 뷰 및 장식 서비스, 메뉴 커맨드 서비스와 같은 다른 디자이너 하부 구조가 디자이너와 정보를 교환할 수 있게 해준다. IActivityDesigner 인터페이스로부터 도출된 디자이너는 계층 구조를 가질 수 없으며, 계층 구조를 가지기 위해서는 디자이너는 ICompositeActivityDesigner 인터페이스를 구현할 필요가 있다. 이하는 IActivityDesigner의 정의를 프로퍼티 및 메소드에 관한 상세와 함께 나타낸 것이다.
IActivityDesigner의 프로퍼티 및 메소드
프로퍼티
Visible 디자이너가 현재 볼 수 있는지 여부를 가져옴
Location 논리 좌표에서의 디자이너의 위치를 가져옴
Size 논리 좌표에서의 디자이너의 크기를 가져옴
Bounds 논리 좌표에서의 디자이너의 경계 직사각형을 가져옴
ConnectionPoints 작업 흐름에서 디자이너가 연결될 수 있는 위치들을 가리키는 점들의 어레이를 가져옴
AssociatedBitmap 디자이너와 연관된 시각적 비트맵을 가져옴
Glyphs 디자이너에 의해 지원되는 글리프를 가져옴
DesignerActions 구성을 수정하기 위해 디자이너와 연관된 동작들을 가져옴
메소드
Draw 디자이너를 드로잉하기 위해 작업 흐름 뷰에 의해 호출됨. 드로잉 컨텍스트가 DesignerData 구조체를 사용하여 전달됨
HitTest 마우스 좌표가 디자이너 상에 있는지를 검사하기 위해 작업 흐름 뷰에 의해 호출됨
OnLayoutPosition 레이아웃 이벤트에 응답하여 호출됨. 이것은 디자이너에게 위치 프로퍼티를 업데이트하도록 지시함. 복합 디자이너는 이 함수에 응답하여 자식들에 대한 레이아웃 위치를 호출함
OnLayoutSize 레이아웃 이벤트에 응답하여 호출됨. 이것은 디자이너에게 그의 크기를 업데이트하도록 지시함. 복합 디자이너는 이 함수에 응답하여 자식들에 대한 레이아웃 크기를 호출함.
OnMouseDragBegin 메소드는 마우스 드래그가 디자이너 상에서 시작되었음을 나타냄. 러버밴딩 및 드래그 드롭 지원을 위해 사용됨.
OnMouseDragMove 메소드는 마우스가 디자이너 상에서 드래그되고 이동된 것에 응답하여 호출됨
OnMouseDragEnd 마우스 드래그가 끝날 때 통지하기 위해 호출됨
OnMouseEnter 마우스가 디자이너 영역에 들어갈 때 통지함
OnMouseDown 마우스가 디자이너의 임의의 부분 상에서 클릭되는지를 통지함
OnMouseHover 마우스가 디자이너 상에서 움직이고 있음을 통지함
OnMouseUp 사용자가 디자이너 상에서 마우스 버튼을 클릭한 후 놓았음을 통지함
OnMouseLeave 마우스가 디자이너를 떠났음을 통지함
OnDragEnter 사용자가 현재 드래그 드롭 모드에 있고 드래그하면서 디자이너에 들어갔음을 디자이너에게 통지함
OnDragOver 디자이너 상에서 현재 드래그 활동이 행해지고 있음을 통지함
OnDragLeave 드래그 드롭이 진행중인 동안 마우스가 디자이너를 떠났거나 드래그 드롭 활동이 종료되었음을 통지함
OnDragDrop 성공적인 드래그 드롭 이벤트를 통지함
OnGiveFeedback 드래그 드롭이 진행중일 때 디자이너에게 피드백을 제공하도록 요청함
OnQueryContinueDrag 드래그 드롭 이벤트가 계속되어야 하는지 종료되어야 하는지를 질문함
OnKeyDown 디자이너가 선택되었을 때 선택된 디자이너에게 키가 눌러져 있음을 통지함
OnKeyUp 디자이너가 선택되었을 때 선택된 디자이너에게 키가 릴리스되었음을 통지함
RefreshDesignerActions 디자이너 동작의 컬렉션을 리프레쉬하도록 디자이너에게 요청함. 이것은 또한 검증을 트리거하는 요청이기도 하다.
CanSetParentActivity 복합 활동이 현재 활동의 부모로서 설정될 수 있는지를 반환함
ICompositeActivityDesigner :
ICompositeActivityDesigner는 그 아래에 계층 구조를 가질 수 있는, 즉 자식들을 가질 수 있는 디자이너에 의해 구현된다. 복합 디자이너는 그 자신 및 모든 그의 자식들을 보유할 책임을 지고 있다. ICompositeActivityDesigner 인터페이스를 사용하여, 복합 디자이너는 그의 자식에 관한 정보를 공개하고, 자식 디자이너를 부가 및 제거하는 기능을 제공하며 키보드 네비게이션을 가능하게 해준다. 이하는 ICompositeActivityDesigner의 정의를 프로퍼티 및 메소드에 관한 상세와 함께 나타내었다.
ICompositeActivityDesigner의 프로퍼티 및 메소드
프로퍼티
ActivityDesingers CompositeActivityDesigner의 계층 구조를 이루는 활동 디자이너들의 컬렉션을 가져옴
CanCollapse 활동 디자이너가 축소될 수 있는지를 가져옴. 확장/축소 버튼은 이 프로퍼티에 응답하여 보여지거나 감추어짐
Expanded CompositeActivityDesigner가 확장되는지 축소되는지를 가져오거나 설정함
FirstSelectableObject CompositeActivityDesigner 계층 구조에서 첫번째 선택가능 객체를 가져옴
LastSelectableObject CompositeActivityDesigner 계층 구조에서 마지막 선택가능 객체를 가져옴
메소드
IsChildVisible CompositeActivityDesigner 계층 구조 내에 포함된 자식 활동이 보이는지를 반환함
EnsureChildIsVisible CompositeActivityDesigner 계층 구조 내의 자식 활동을 가시 범위 내로 스크롤함
GetNextSelectableObject 전달된 방향 플래그에 기초하여 CompositeActivityDesigner 계층 구조에서 마지막 선택가능 객체를 가져옴
CanInsertActivities 활동이 CompositeActivityDesigner 내에 삽입되기에 유효한지를 반환함. 이 함수로 전달되는 컨텍스트는 자식 활동이 어디에 삽입되고 있는지를 식별함
InsertActivities 컨텍스트를 통해 전달된 지정된 위치에서 CompositeActivityDesigner 계층 구조에 자식 활동을 삽입함
CanRemoveActivities 컨텍스트를 사용하여 지시된 특정 위치에 있는 활동이 CompositeActivityDesigner 계층 구조로부터 제거될 수 있는지를 반환함
RemoveActivities CompositeActivityDesigner 계층 구조 내의 특정 위치로부터 활동을 제거함
간단한 디자이너
ActivityDesigner 클래스는 디자이너의 가장 간단한 구현을 나타낸다. 작업 흐름 내의 활동들과 연관된 모든 디자이너는 ActivityDesigner로부터 파생된다. ActivityDesigner 클래스는 IActivityDesigner 인터페이스로부터 상속되며 인터페이스에 대한 디폴트 구현을 제공한다. 작업 흐름 뷰는 IActivityDesigner 인터페이스를 사용하여 디자이너와 대화한다. ActivityDesigner 클래스는 일반적으로 디자이너의 드로잉을 위한 초경량급 구현을 필요로 하는 디자이너에 의해 상속받는다. 이들 디자이너는 어떤 자식이나 계층 구조를 갖지 않는다. 활동 디자이너에 의해 제공된 특징으로는 기본적인 레이아웃 로직, (예를 들어, 드로잉 아이콘, 설명, 경계, 인테리어 및 배경에 의한) 렌더링 지원, 도움말 텍스트의 렌더링, 모든 디자이너가 필요로 하는 디폴트 글리프(default glyph)의 반환, DesignerVerbs를 통한 컨텍스트 메뉴 보여주기, 디자인시 특정 프로퍼티의 필터링, 디폴트 이벤트 생성, 디폴트 히트테스팅, 검증 트리거링, 도구팁 보여주기, 및 키보드 네비게이션에의 참가가 있다.
public abstract class ActivityDesigner : ComponentDesigner, IActivityDesigner
System.Object
System.ComponentModel.Design.ComponentDesigner
System.Workflow.ComponentModel.Design.ActivityDesigner
System.Workflow.ComponentModel.Design.CompositeActivityDesigner
System.Workflow.ComponentModel.Design.CodeDesigner
System.Workflow.ComponentModel.Design.CompensateDesigner
System.Workflow.ComponentModel.Design.DelayDesigner
System.Workflow.ComponentModel.Design.FaultDesigner
System.Workflow.ComponentModel.Design.CompositeScheduleDesigner
System.Workflow.ComponentModel.Design.InvokeWebServiceDesigner
System.Workflow.ComponentModel.Design.BaseReceiveDesigner
System.Workflow.ComponentModel.Design.BaseSendDesigner
System.Workflow.ComponentModel.Design.GenericTaskDesigner
System.Workflow.ComponentModel.Design.STSTaskDesigner
복합 디자이너
CompositeActivityDesigner는 계층 구조를 갖는 디자이너이다(예를 들어, 그 아래쪽에 자식들을 갖는다). CompositeActivityDesigner는 그의 자식들 뿐만 아니라 그 자신의 모든 측면을 관리할 책임이 있다. 또한, CompositeActivityDesigner는 이벤트를 포워드하기 위해 그 자식들과 상호작용할 책임이 있다. CompositeActivityDesigner가 포함하고 있는 활동 디자이너 컬렉션을 수정하라는 요청이 있을 때마다, CompositeActivityDesigner는 활동이 제거될 필요가 있는 장소를 지정하는 컨텍스트(ContextBase)를 전달받는다. ContextBase는 그와 관련된 컨텍스트를 지정하기 위해 각각의 CompositeActivityDesigner 파생 클래스에 의해 특화될 수 있다. 이것의 예가 ConnectorContext라고 하는 클래스를 그로부터 파생시킴으로써 ContextBase를 특화시키는 SequentialActivityDesigner이다. CompositeActivityDesigner 클래스는 ICompositeActivityDesigner 인터페이스로부터 파생되고 그에 대한 디폴트 구현을 제공한다. CompositeActivityDesigner에 의해 제공되는 특징으로는 디자이너의 확장/축소, 드래그 및 드롭 표시자, 자기 자신 및 자식들의 레이아웃, 자기 자신 및 자식들의 드로잉, 자식들의 히트테스팅(hittesting), 및 활동들을 계층 구조에 삽입/그로부터 제거가 있다.
public abstract class CompositeActivityDesigner : ActivityDesigner, ICompositeActivityDesigner
System.Object
System.ComponentModel.Design.ComponentDesigner
System.Workflow.ComponentModel.Design.ActivityDesigner
System.Workflow.ComponentModel.Design.CompositeActivityDesigner
System.Workflow.ComponentModel.Design.SequentialActivityDesigner
System.Workflow.ComponentModel.Design.ParallelActivityDesigner
System.Workflow.ComponentModel.Design.ConstrainedActivityDesigner
CompositeActivityDesigner는 추상 클래스이며 그 스스로 존재할 수 없기 때문에 인스턴스화될 수 없다. Sequential, Parallel 및 CA 디자이너는 모두 이 클래스를 특화한 것이다.
SequentialActivityDesigner
SequentialActivityDesigner 클래스는 그 아래에 자식들을 갖는 모든 디자이너를 나타내며, 자식들 모두는 순차적으로 순서화되어 있다. 자식들은 자식들의 시퀀스를 수정하는 데도 사용되는 커넥터라고 하는 링크로 연결되어 있다. SequentialActivityDesigner 클래스는 CompositeActivityDesigner를 특화한 것이며, 이하의 일련의 특징, 즉 커넥터 시작 및 끝 비트맵 드로잉, 모든 자식을 순차적으로 레이아웃하고 그들을 연결하는 모든 커넥터를 업데이트, 자식들 간의 커넥터의 드로잉, 드래그 드롭이 있을 때 드롭 영역을 하이라이트, 커넥터를 히트테스팅, 위 및 아래 화살표를 사용한 순차적 키보드 네비게이션, 및 커넥터에 대한 글리프의 반환을 제공한다.
internal abstract class SequentialActivityDesigner: CompositeActivityDesigner
System.Object
System.ComponentModel.Design.ComponentDesigner
System.Workflow.ComponentModel.Design.ActivityDesigner
System.Workflow.ComponentModel.Design.CompositeActivityDesigner
System.Workflow.ComponentModel.Design.SequentialActivityDesigner
System.Workflow... ... ...Design.ActivityPreviewDesigner
System.Workflow... ... ...Design.CompensationHandlerDesigner
System.Workflow... ... ...Design.ConditionedDesigner
System.Workflow... ... ...Design.EventHandlerDesigner
System.Workflow... ... ...Design.ExceptionHandlerDesigner
System.Workflow... ... ...Design.ScopeDesigner
System.Workflow... ... ...Design.SequenceDesigner
System.Workflow... ... ...Design.WhileDesigner
상기 디자이너 모두는 SequentialActivityDesigner를 특화한 것이다. 이들 모두는 드로잉에서 주로 다르다. 이들 디자이너 모두는 작업 흐름에서 그 자신을 나타내는 특별한 방법을 가지지만 이들 모두는 SequentialActivityDesigner에 의해 제공된 공통 기능에서 벗어나 동작한다.
ParallelActivityDesigner
ParallelActivityDesigner는 다수의 SequentialActivityDesigner를 포함하는 CompositeActivityDesigner의 다른 특화이다. 이들 SequentialActivityDesigner 각각은 병렬 디자이너에서의 분기이다. 병렬 디자이너는 이하의 특화된 특징, 즉 다수의 순차적 디자이너의 레이아웃, 부가의 분기를 부가하기 위한 드래그 및 드롭 표시자, 좌 및 우 화살키를 사용하여 병렬 분기 간의 횡단하기 위한 키보드 네비게이션, 및 다수의 병렬 분기를 연결하는 커넥터의 드로잉을 제공한다.
internal abstract class ParallelActivityDesigner: CompositeActivityDesigner＼
System.Object
System.ComponentModel.Design.ComponentDesigner
System.Workflow.ComponentModel.Design.ActivityDesigner
System.Workflow.ComponentModel.Design.CompositeActivityDesigner
System.Workflow.ComponentModel.Design.ParallelActivityDesigner
System.Workflow... ... ...ConditionalDesigner
System.Workflow... ... ...ListenDesigner
System.Workflow... ... ...ParallelDesigner
Conditional, Listen 및 Parallel 디자이너는 그와 연관된 부가의 드로잉 로직을 갖는 ParallelActivityDesigner의 특화이다.
ActivityPreviewDesigner
ActivityPreviewDesigner는 순차적 디자이너이지만 컬렉션 백(collection bag) 형태로 다수의 디자이너의 컬렉션을 보여주는 기능을 갖는다. ActivityPreviewDesigner는 이 컬렉션을 디스플레이하기 위해 슬라이드의 메타포어를 사용한다. 특정의 디자이너가 선택될 때, 그의 표현은 활동 미리보기 디자이너가 호스팅하는 미리보기 윈도우에 보여진다. ActivityPreviewDesigner는 2가지 모드, 편집 모드 및 미리보기 모드를 갖는다. 미리보기 모드에서, 사용자는 선택된 디자이너를 수정할 수 없다. 이 모드는 사용자가 스크롤할 필요없이 디자이너의 전체 표현을 볼 수 있게 해준다. 편집 모드는 디자이너가 수정될 수 있게 해준다. ActivityPreviewDesigner에 의해 제공되는 특징으로는, 활동들의 컬렉션을 보여주는 미리보기 스트립, 현재 선택된 활동의 미리보기, 및 선택된 디자이너를 편집하는 기능이 있다.
internal abstract class ActivityPreviewDesigner: SequentialActivityDesigner
System.Object
System.ComponentModel.Design.ComponentDesigner
System.Workflow.ComponentModel.Design.ActivityDesigner
System.Workflow.ComponentModel.Design.CompositeActivityDesigner
System.Workflow.ComponentModel.Design.SequentialActivityDesigner
System.Workflow... ... ...Design.ActivityPreviewDesigner
System.Workflow... ... ...Design.GenericCollectionDesigner
System.Workflow... ... ...Design.CAGDesigner
스코프 및 서비스 디자이너
스코프 및 서비스 디자이너는 특별한 디자이너이다. 이들 각각은 그와 연관된 예외, 이벤트, 및 보상을 가질 수 있다. 스코프 및 스케쥴도 또한 사용자 코드 파일 내에 그와 연관된 클래스를 가지며, 사용자는 이들 클래스 내의 변수들을 스코핑할 수 있다. 스코프 및 서비스 디자이너는 다른 디자이너와 다르게 나타내어지며 워터마크를 보여주고 드롭 쉐도우(drop shadow)를 드로잉함으로써 이들을 하이라이트한다.
스코프 및 서비스 디자이너는 디자이너와 연관된 예외, 이벤트 및 보상을 드러내기 위해 사용자가 뷰를 플립(flip)할 수 있도록 뷰를 변경하는 기능을 가지고 있다. 사용자가 서비스 또는 스코프 아이콘 위를 돌아다니면, 사용자가 예외, 이벤트 또는 보상 뷰 중 하나를 선택할 수 있게 해주는 드롭다운 팔레트가 나타난다. 이어서, 디자이너 뷰는 플립되고, 선택된 뷰 내에 포함된 활동들이 보여진다. 사용자는 임의의 시점에서 임의의 뷰에 속하는 활동들만 볼 수 있다. 뷰의 플리핑(flipping)은 스코프 또는 스케쥴에 포함된 자식 활동들을 필터링함으로써 달성된다. 스코프 및 스케쥴은 기껏해야 ExceptionHandlers, EventHandlers 및 Compensation 중 하나를 그의 자식으로서 가질 수 있다. 사용자가 보고 있는 뷰에 기초하여, 디자이너는 선택된 뷰에 나타날 수 있는 자식 활동만을 보여주기 위해 이들 자식을 필터링 아웃하며, 따라서 다수의 뷰를 지원하는 효과를 달성한다. 스케쥴 디자이너는 보통 작업 흐름 뷰에서 루트 디자이너로서 설정된다.
internal class ScopeDesigner: SequentialActivityDesigner
internal class ServiceDesigner: ScopeDesigner
System.Object
System.ComponentModel.Design.ComponentDesigner
System.Workflow.ComponentModel.Design.ActivityDesigner
System.Workflow.ComponentModel.Design.CompositeActivityDesigner
System.Workflow.ComponentModel.Design.SequentialActivityDesigner
System.Workflow... ... ...Design.ScopeDesigner
System.Workflow... ... ...Design.ServiceDesigner
ServiceRootDesigner
ServiceRootDesigner는 Designer Host에 의해 포함되는 루트 컴포넌트와 연관되어 있다. ServiceRootDesigner는 이어서 디자이너 윈도우 창에서 호스팅되는 작업 흐름 뷰를 생성하는 일을 맡고 있다. ServiceRootDesigner는 또한 도구 상자 아이템을 더블클릭함으로써 작업 흐름에서 도구 상자 아이템을 부가하는 기능을 제공하는 IToolBoxUser 인터페이스를 지원한다.
디자인시 기술자(Design-time Descriptor)
저작 객체 모델에서의 각 활동은 디자인시의 그의 거동을 기술하는 메타데이터를 갖는다. 이것은 프로퍼티 그리드 거동(네이밍, 설명, 필터링, 프로퍼티 에디터 등) 뿐만 아니라 활동(디자이너)을 연관시키는 것을 포함한다. 타입＼프로퍼티＼이벤트 디자인시 거동은 이하의 애트리뷰트 중 0개 이상을 사용하여 기술된다.
- SRCategoryAttribute - 조정 엔진 애트리뷰트. 로컬화된 카테고리 이름을 제공함.
- SRDescriptionAttribute - 조정 엔진 애트리뷰트. 로컬화된 설명을 제공함.
- EditorAttribute - UITypeEditor를 제공함.
- TypeConverter - 필터링, 값 리스트, 및 타입 간의 변환을 제공함.
- BrowsableAttribute - 디자인시 동안 멤버들을 보여줌/감춤.
SRCategory 및 SRDescription은 단지 리소스 이름과 스트링 간의 매핑이다. 대부분의 에디터(UITypeEditor)는 대화 상자(CorrelationSetsDialog) 또는 드롭다운 리스트를 처리하기 위한 관리자이다. PropertyDescriptor는 디자인시에 프로퍼티를 처리하고 디폴트 TypeConverter, 커스텀 TypeConverter(상기와 같이 애트리뷰트로서 선언되어 있음), 또는 TypeDescriptor에 의해 프로퍼티를 건내받는다.
UITypeEditor는 조정 엔진 컴포넌트 모델에서 여러가지 프로퍼티에 대한 에디터를 제공한다. 프로퍼티 브라우저는 이들을 사용하여 생략 부호 또는 드롭다운을 디스플레이하고 또 에디터를 기동시킨다.
타입 변환기
타입 변환기는 객체를 다른 타입으로/그로부터 변환하는 메소드를 제공하고, 디자인시에 객체 프로퍼티를 나타내는 PropertyDescriptor 리스트를 제공하며, 프로퍼티그리드의 프로퍼티의 드롭다운에서 사용될 값들을 제공할 수 있다.
이하는 조정 엔진 컴포넌트 모델에서 구현되는 타입 변환기 중 일부이다.
- DeclTypeConverter
모든 활동의 타입 변환기에 대한 베이스 클래스. (프로퍼티 그리드에 활동의 이름을 디스플레이하고 이름 편집이 활동을 생성할 수 있게 해주기 위해) 활동 객체를 스트링으로/로부터 변환하는 CanConvertFrom(), CanConvertTo(), ConvertFrom(), ConvertTo()를 구현함.
- HandlerDeclTypeConverter
이벤트에 대한 타입 변환기. DeclTypeConverter로부터 파생됨. 호환가능한 핸들러를 디스플레이하기 위해 IEventBindingService를 사용하는 GetStandardValues()를 구현함.
- VariableDeclTypeConverter
변수(메시지, 채널, 상관 등)에 대한 타입 변환기. DeclTypeConverter로부터 파생됨. 호환가능한 변수 필드를 디스플레이하기 위해 IFieldBindingService를 사용하는 GetStandardValues()를 구현함. 게다가, 이 타입 변환기는 "Name" 프로퍼티를 필터링 아웃하고 일반 타입으로서 나타나는 타입 프로퍼티에 대한 특별한 프로퍼티 기술자를 설정함.
프로퍼티 기술자
프로퍼티 기술자는 활동 객체들에 디자인시 서비스를 제공한다. 프로퍼티 값을 가져올 때/설정할 때, 프로퍼티 기술자는 이름, 설명, 카테고리, 타입 변환기 정보는 물론 부가의 기능을 제공한다. 기본적으로, TypeConverter는 모든 프로퍼티에 PropertyDescriptor를 제공한다. 그렇지만, TypeConverter는 그 타입의 다른 디자인시 거동을 제공하기 위해 이들을 제거, 부가 또는 래핑할 수 있다.
이하는 저작 객체 모델에서 구현되는 PropertyDescriptor 중 일부이다.
- DynamicPropertyDescriptor
저작 객체 모델에서 모든 프로퍼티 기술자에 대한 베이스 클래스. 디폴트 프로퍼티 기술자 주변의 래퍼를 구현하며 모든 메소드를 그것으로 델리게이트함. 게다가, 객체로부터 직접(객체가 컴포넌트인 경우) 또는 IReferenceService를 통해 객체 사이트로의 액세스를 제공함.
- VariableDeclTypeConverter
모든 변수(메시지, 채널, 상관 등)에 대한 프로퍼티 기술자. 다음과 같이 코드 비사이드 필드를 제공하기 위해 SetValue()를 오버로드함.
- 설정할 변수 및 그의 사이트를 가져옴
- 포함하는 스코프(containing scope)의 사이트를 가져옴
- 포함하는 스코프의 IFieldBindingService를 가져옴. 유의할 점은 각 스코프가 그 자신의 일련의 필드를 갖는 그 자신의 IFieldBindingService를 갖는다는 것이다.
- 그 서비스로 필드 이름을 검증함
- 디자이너 트랜잭션의 열기
- 값을 저장함
- 필드를 코드 비사이드 파일에 부가하기 위해
IFieldBindingService.CreateField()를 호출함
- 트랜잭션을 커밋함
- HandlerDeclTypeConverter
모든 핸들러에 대한 프로퍼티 기술자. 다음과 같이 코드 비사이드 필드를 제공하기 위해 SetValue()를 오버로드함
- 설정할 HandlerDeclaration 객체 및 그의 사이트를 가져옴
- IEventBindingService를 가져옴
- 디자이너 트랜잭션의 열기
- LocalEventDescriptor를 생성함
- (eventBindingService.GetEventProperty()를 사용하여) 이벤트에
대한 프로퍼티 기술자를 가져오고 그에 대해 HandlerDeclaration을 설정함
- HandlerDeclaration 객체의 "Name" 프로퍼티를 설정함
- 트랜잭션을 커밋함
- ArrayElementPropertyDescriptor
컬렉션 내의 아이템을 나타내는 프로퍼티 기술자. 컬렉션 아이템 - 예를 들어, 상관 세트 -은 프로퍼티 기술자를 갖지 않기 때문에(컬렉션 아이템은 프로퍼티가 아님), ArrayElementPropertyDescriptor는 컬렉션 아이템이 프로퍼티인 것처럼 기술자를 위조하고, 따라서 그 아이템을 프로퍼티 브라우저 내에 디스플레이할 수 있게 된다. 이 프로퍼티 기술자는 전술한 프로퍼티 기술자 중 임의의 것에 의해 래핑되도록 디자인되어 있다.
- LocalEventDescriptor
핸들러 선언을 나타내기 위한 EventDescriptor. 저작 객체 모델에서의 핸들러는 실제 이벤트가 아니고 프로퍼티이며, 따라서 사용될 IEventBindingService에 대한 우리 자신의 EventDescriptor을 소개한다.
ICustomTypeDescriptor의 사용
ICustomTypeDescriptor는 컴포넌트에 대한 기술자를 설정하는 다른 방법이다. 컴포넌트 자체는 인터페이스를 구현하며 기술자를 타입 변환기, 디폴트 등으로서 제공한다. GenericActivity, InvokeWebServiceActivity 및 InvokeSchedule은 이 인터페이스를 구현한다.
IExtenderProvier의 사용
이것은 컴포넌트에 디자인시 프로퍼티를 소개하는 또다른 기술이다. 확장 클래스(extension class) RulePropertyProviderExtender는 ServiceDesigner에 규칙 프로퍼티를 제공한다. 프로퍼티는 ProvidePropertyAttribute를 통해 익스텐더 클래스(extender class)를 장식하고, 그 애트리뷰트에 대한 getter 및 setter를 구현하며 컴포넌트의 사이트(Schedule.Site)를 통해 액세스가능한 IExtenderProviderService 클래스(여기서의 경우, RulePropertyProviderExtender에 의해 구현됨)에 익스텐더 클래스를 부가함으로써 부가된다.
확장성 지원
System.Workflow.ComponentModel.Design 네임스페이스는 사용자가 그 자신의 활동 디자이너를 생성하고 이들을 조정 엔진 디자이너에 플러깅하는 데 사용하는 여러가지 재사용가능한 클래스를 제공한다. 이하는 사용자가 사용할 수 있는 클래스들의 리스트이다.
- ActivityDesigner: ActivityDesigner는 그 아래에 다른 활동의 계층 구조를 갖지 않는 간단한 활동을 부가하는 기능을 사용자에게 제공한다. 사용자는 이 디자이너로부터 상속할 필요가 있으며, 비트맵, 설명 및 드로잉을 커스터마이즈할 수 있다.
- SequentialActivityDesigner: SequentialActivityDesigner는 사용자가 그 안에 다수의 활동들을 포함할 수 있는 디자이너를 작성할 수 있게 해준다. 이들 활동 모두는 순차적으로 정렬되어 있으며 커넥터 라인(connector line)을 사용하여 연결되어 있다. 사용자는 이 클래스로부터 커스텀 컬러링, 설명, 아이콘 등을 파생시켜 제공한다.
- ParallelActivityDesigner: ParallelActivityDesigner는 사용자가 병렬 방식으로 정렬되어 있는 다수의 복합 활동들을 그 안에 가질 수 있는 활동 디자이너를 작성할 수 있게 해준다. 이 클래스는 또한 사용자가 설명, 아이콘, 컬러 등을 커스터마이즈할 수 있게 해준다. 이 클래스는 상속을 통해 확장가능하다.
- OrchestrationEngineToolboxItem: OrchestrationEngineToolboxItem은 사용자가 커스텀 도구 상자 아이템을 생성할 수 있게 해준다. 이 클래스는 직렬화를 제어하는 기능을 사용자에게 제공한다. 이 클래스는 후크(hook)를 제공하며 활동이 디자이너 내에서 부가될 때 사용자는 후크를 사용하여 커스텀 UI를 팝업할 수 있다. 사용자는 상속을 통해 이 클래스를 재사용할 수 있다. 사용자는 ToolBoxItem 애트리뷰트를 사용하여 도구 상자 아이템을 제공할 필요가 있다.
- TypeBrowerEditor: TypeBrowerEditor는 사용자가 디자이너에서 이용가능한 타입들을 브라우징할 수 있게 해준다. 이 클래스는 System.Type 타입을 갖는 프로퍼티와 이 클래스를 연관시킴으로써 사용된다. 사용자는 이 클래스를 프로퍼티와 연관시키기 위해 UITypeEditor 애트리뷰트를 사용한다.
- TypeConverter 클래스: 조정 엔진 컴포넌트 모델은 사용자가 그 자신의 타입 변환기를 정의할 수 있게 해주는 여러가지 타입 변환기를 제공한다. 모든 타입 변환기는 상속을 통해 이들을 확장시킴으로써 사용될 수 있다.
- DesignerGlyph: DesignerGlyph 클래스는 사용자가 디자이너의 상부에 커스텀 글리프를 드로잉하는 데 사용될 수 있다. 사용자는 최상위 Z 차원에 드로잉할 필요가 있는 어떤 시각적 글리프를 디스플레이하고자 할 수 있다. DesignerGlyph 클래스는 이러한 글리프를 드로잉하는 데 사용될 수 있다. 이 클래스는 상속을 통해 그를 확장함으로써 사용될 수 있다.
- DesignerAction: 사용자는 DesignerAction을 DesignerGlyph와 연관시킬 수 있다. 사용자가 DesignerGlyph를 클릭할 때 동작들이 나타난다. 커스텀 디자이너 동작들은 DesignerAction 클래스로부터 상속함으로써 생성될 수 있다.
부록 C
활동의 시맨틱 검증
이들 전형적인 검증 검사는 조정 엔진에 의해 개발된 다수의 활동들에 공통된 것이다.
모든 활동
- 활동의 ID 프로퍼티는 프로젝트의 언어(C# 또는 VB)에서 유효한 식별자이어야만 한다.
- 비스코프 활동(non-Scope activity)의 ID는 포함하는 스코프 내에서 고유한 것이어야만 한다. 스코프 활동의 ID는 모든 스코프에 걸쳐 고유한 것이어야만 한다.
- 변수인 어떤 프로퍼티도 볼 수 있는(visible) 변수로 설정되어야만 한다. - 예를 들어, 활동의 스코프 내에 또는 포함하는 스코프 내에 정의되고 public이어야만 한다.
코드-비사이드 핸들러
- 활동의 ID 프로퍼티는 프로젝트의 언어(C# 또는 VB)에서 유효한 식별자이어야만 한다.
- 핸들러는 핸들러를 포함하는 활동의 코드-비사이드 스코프 클래스에 존재해야만 하며 일치하는 메소드 서명을 가져야만 한다.
메시지
- OEMessage<T>의 파라미터 타입 T는 직렬화가능한 것이어야 한다.
상관
- OECorrelation<T>의 파라미터 타입 T는 IComparable을 구현해야만 한다.
규칙
- 규칙의 핸들러는 핸들러 검증을 통과해야만 한다. 핸들러의 서명은 규칙의 타입에 의해 정의된다.
활동별 검증 검사
이들 전형적인 검증 검사는 활동 타입에 특유한 것이다.
Code
- UserCodeHandler 프로퍼티는 지정되어야만 하고 signature void Method()를 가져야만 한다.
Compensate
- Compensate 활동은 트랜잭션 타입이 None가 아닌 스코프의 ExceptionHandler 활동 또는 Compensation 활동 내부에서만 나타날 수 있다.
- CompensateScope가 True인 경우, Scope 프로퍼티는 Compensate가 그로부터 나오는 스코프의 직계 자식이거나 그 자신인 Scope 활동으로 설정되어야만 한다.
- CompensateScope가 False인 경우, Invoke 프로퍼티는 Compensate가 그로부터 나오는 스코프의 직계 자식인 CompositeSchedule 활동으로 설정되어야만 한다.
Conditional
- Conditional 활동은 적어도 하나의 자식을 가져야만 한다.
- ConditionalBranch 활동만이 자식으로서 허용된다.
ConditionalBranch
- 부모 활동은 Conditional이어야만 한다.
- ConditionalBranch가 그의 부모의 마지막 자식이 아니라면, Rule 프로퍼티는 지정되어 있어야만 한다.
ConstrainedActivityGroup
- CompletionRule 프로퍼티는 유효한 규칙으로 설정되어야만 한다.
- Constrained 활동들만이 자식으로서 허용된다.
Constrained
- 부모 활동은 ConstrainedActivityGroup이어야만 한다.
- Constrained는 정확히 하나의 자식을 가져야만 한다.
- DisableRule 및 EnableRule이 지정되어 있는 경우 이들은 유효한 것이어야만 한다.
Delay
- TimeoutProvider 프로퍼티는 유효한 핸들러로 설정되어야만 한다.
EventHandlers
- 부모는 Scope 활동을 가져야만 한다.
- EventDriven 활동만이 자식으로서 허용된다.
- 임의의 자식 EventDriven 활동의 첫번째 자식이 True로 설정된 Activiation을 갖는 Receive인 경우, 모든 자식 EventHandlers는 첫번째 자식으로서 True로 설정된 Activiation을 갖는 Receive를 가져야만 한다.
- 하나의 자식 EventDriven 활동만이 그의 첫번째 자식으로서 Delay 활동을 가져야만 한다.
EventDriven
- 부모는 Listen 활동 또는 EventHandlers 활동이어야만 한다.
- 첫번째 자식은 Delay 또는 Receive 활동 중 하나이어야만 한다.
- 적어도 하나의 자식 활동이 존재해야만 한다.
Fault
- ExceptionProvider 프로퍼티는 서명 System.Exception Method()를 갖는 유효한 Handler로 설정되어야만 한다.
- Fault 활동은 Atomic으로 설정된 TransactionType을 갖는 Scope 활동 내에 내포될 수 없다.
InvokeSchedule
- 피호출자(invokee)의 타입은 InvokeSchedule로부터 파생되어야만 하고 디폴트 생성자(default constructor)를 가져야만 한다.
- InAttribute, OutAttribute 또는 OptionalAttribute를 갖는 호출자의 어떤 public 프로퍼티는 할당가능 타입의 가시 변수에 할당될 수 있다.
- ExecutionMethod 프로퍼티가 Exec로 설정된 경우, OutAttribute를 갖지만 InAttribute를 갖지 않는 프로퍼티는 할당될 수 없다.
- ExecutionMethod 프로퍼티가 Exec로 설정된 경우, 변수는 직렬화가능한 것이어야만 한다.
- Channel 또는 Correlation은 OutAttribute를 갖는 프로퍼티에 할당될 수 없다.
- 재귀적 호출이 허용되지 않는다.
InvokeWebService
- ProxyClassName 프로퍼티가 유효한 프록시 클래스로 설정되어야만 한다.
- MethodName 프로퍼티는 프록시 클래스 내의 웹 메소드로 설정되어야만 한다.
- 웹 메소드에 대한 모든 파라미터는 지정되어야만 하고 가시적이어야 하며 그의 타입은 할당가능이어야만 한다. 게다가, 임의의 out/ref 파라미터 및 반환 값의 경우, 지정된 파라미터는 읽기 전용이어서는 안된다.
Listen
- EventDriven 활동만이 자식으로서 허용된다.
- 적어도 2개의 자식이 존재해야만 한다.
- 임의의 자식 EventDriven 활동의 첫번째 자식이 True로 설정된 Activation을 갖는 Receive인 경우, 모든 자식 EventDriven 활동은 첫번째 자식으로서 True로 설정된 Activation을 갖는 Receive 또는 Delay 활동을 가져야만 한다.
- 하나의 자식 EventDriven 활동만이 그의 첫번째 자식으로서 Delay 활동을 가질 수 있다.
Parallel
- Sequence 활동만이 자식으로서 허용된다.
- 적어도 2개의 자식이 존재해야만 한다.
- 임의의 자식 Sequence 활동의 첫번째 자식이 True로 설정된 Activation을 갖는 Receive인 경우, 모든 자식 Sequence 활동은 첫번째 자식으로서 True로 설정된 Activation을 갖는 Receive를 가져야만 한다.
Receive
- Message 프로퍼티는 설정되어야 하고 또 유효한 것이어야 한다.
- HasTypedChannel 프로퍼티가 True인 경우, TypedChannel 프로퍼티는 설정되어야 하고 또 유효한 것이어야 한다 - 타입 OEInboundChannel<T>의 가시적 변수(단, T는 인터페이스임).
- HasTypedChannel 프로퍼티가 True인 경우, TypedChannel의 Operation은 signature void Method(Type parameter)를 갖는 인터페이스로부터의 메소드이어야만 한다.
- HasTypedChannel 프로퍼티가 True인 경우, Message의 Type은 Operation의 파라미터의 Type으로부터 할당가능해야만 한다.
- HasTypedChannel 프로퍼티가 False인 경우, UnTypedChannel 프로퍼티는 설정되어야 하고 또 유효한 것이어야 한다 - 타입 InboundChannel의 가시적 변수.
- Activation 프로퍼티가 True인 경우, Receive는 Schedule에서 첫번째 실행가능 명령문이어야만 하고 조상으로서 Sequence, Parallel, EventDriven, Listen, Scope 또는 Schedule 활동만을 가질 수 있다.
- Activation 프로퍼티가 True인 경우, Schedule은 Activity로 설정된 CompileAs 프로퍼티를 가져서는 안된다.
- Activation 프로퍼티가 True인 경우, Receive는 Compensation 또는 ExceptionHandler 또는 While 활동 내에 내포되어서는 안된다.
- Activation 프로퍼티가 False인 경우, Receive는 적어도 하나의 Correlation을 준수해야만 한다.
- Correlation은 기껏해야 한번 지정될 수 있으며 초기화와 준수가 동시에 행해질 수 없다.
- OnAfterReceive 핸들러가 설정되어 있는 경우 이것은 signature void Method()를 가져야만 한다.
ReceiveRequest
- TypedChannel 프로퍼티의 Operation은 (설정될 필요가 있는 경우) signature ReturnType Method(Type parameter)를 가져야만 한다.
ReceiveResponse
- TypedChannel 프로퍼티의 Operation은 (설정될 필요가 있는 경우) signature ReturnType Method(Type parameter)를 가져야만 한다.
- Operation의 ReturnType은 Message의 Type로부터 할당가능해야만 한다.
- SendRequest 프로퍼티는 유효한 SendRequest 활동의 qualified name이어야만 한다.
- SendRequest 활동은 ReceiveResponse 전에 발생해야만 한다.
- SendRequest 및 ReceiveResponse 활동은 동일한 Atomic Scope 내에 내포되어서는 안된다.
- ReceiveResponseActivity는 Correlation을 준수할 수 없다.
Send
- Message 프로퍼티는 설정되어야 하고 또 유효해야만 한다.
- HasTypedChannel 프로퍼티가 True인 경우, TypedChannel 프로퍼티는 설정되어야 하고 또 유효한 것이어야 한다 - 타입 OEOutboundChannel<T>의 가시적 변수(단, T는 인터페이스임).
- HasTypedChannel 프로퍼티가 True인 경우, TypedChannel의 Operation은 signature void Method(Type parameter)를 갖는 인터페이스로부터의 메소드이어야만 한다.
- HasTypedChannel 프로퍼티가 True인 경우, Operation의 파라미터의 Type은 Message의 Type으로부터 할당가능해야만 한다.
- HasTypedChannel 프로퍼티가 False인 경우, UnTypedChannel 프로퍼티는 설정되어야 하고 또 유효한 것이어야 한다 - 타입 OutboundChannel의 가시적 변수.
- Correlation은 기껏해야 한번 지정될 수 있으며 초기화와 준수가 동시에 행해질 수 없다.
- OnBeforeSend 핸들러가 설정되어 있는 경우 이것은 signature void Method()를 가져야만 한다.
SendRequest
- TypedChannel 프로퍼티의 Operation은 (설정될 필요가 있는 경우) signature ReturnType Method(Type parameter)를 가져야만 한다.
SendResponse
- TypedChannel 프로퍼티의 Operation은 (설정될 필요가 있는 경우) signature ReturnType Method(Type parameter)를 가져야만 한다.
- Operation의 ReturnType은 Message의 Type로부터 할당가능해야만 한다.
- ReceiveRequest 프로퍼티는 유효한 ReceiveRequest 활동의 qualified name이어야만 한다.
- ReceiveRequest 활동은 SendResponse 전에 발생해야만 한다.
- SendResponseActivity는 Correlation을 준수할 수 없다.
Scope
- True로 설정된 Synchronized를 가지는 Scope 활동은 True로 설정된 Synchronized를 갖는 다른 Scope 활동 내에 내포될 수 없다.
- TransactionType Atomic을 갖는 Scope 활동은 ExceptionHandler 활동 내에 내포될 수 없다.
- TransactionType Atomic 또는 LongRunning을 갖는 Scope 활동은 (Scope가 Schedule이 아닌 경우) TransactionType LongRunning을 갖는 Scope 활동 내에 내포되어야만 한다.
- TransactionType가 Atomic인 경우, Synchronized 프로퍼티는 True이어야만 한다.
- TransactionType가 LongRunning인 경우, TimeoutProvider 핸들러는 signature System.DateTime Method()로 설정되어야만 한다.
Schedule
- 코드 비사이드 클래스는 정확히 하나의 생성자를 가져야만 한다.
Sequence
검증 없음
Suspend
- Suspend 활동은 Atomic으로 설정된 TransactionType을 갖는 Scope 내에 내포될 수 없다.
- ErrorString 프로퍼티는 유효한 스트링이어야만 한다.
Terminate
- ErrorString 프로퍼티는 유효한 스트링이어야만 한다.
While
- ConditionalRule 프로퍼티는 유효한 규칙이어야만 한다.
상관 세트 및 콘보이 검증 검사(Convoy Validation Check)
이들 전형적인 검증 검사는 상관 세트 및 콘보이 시나리오에 특유한 것이다.
- Correlation은 그것이 준수될 수 있기 전에 초기화되어야만 한다.
- Correlation은 어떤 예외를 가지고 기껏해야 한번 초기화될 수 있다.
- 상관을 초기화하는 Send 및 상관을 준수하는 Receive는 동일한 Atomic Scope에 존재한다.
- 순차적 콘보이의 검출
- 병렬 콘보이의 검출 및 검증
○ 병렬 콘보이 내의 모든 Receive 활동은 동일한 일련의 Correlation을 초기화해야만 한다.
○ 병렬 콘보이 내의 모든 비작동 Receive 활동은 동일한 일련의 Correlation을 준수해야만 한다.
○ Paralle 내의 작동 Receive는 Correlation을 초기화해야만 한다.
작동 Receive가 작업 흐름에서 첫번째 실행가능한 비복합 활동이고(예를 들어, Scope, Parallel, Listen 등을 무시함) 그의 조상이 Parallel 또는 Listen인 경우, Parallel 또는 Listen의 모든 분기는 그의 첫번째 실행가능한 활동으로서 동작 Receive를 가져야만 한다.
부록 D
전형적인 네임스페이스 API
System.Workflow.ComponentModel 네임스페이스는 표준 작업 흐름 활동들의 구현을 포함한다. Activity 객체 모델은 조정 프로그램을 작성하는 API를 포함한다. 게다가, 선언 객체 모델 내의 모든 객체는 디자인시 거동을 컴포넌트와 연관시키는 것을 가능하게 해주는 상속을 갖는다. 이하는 메시지를 수신하고 선언 객체 모델을 사용하여 이를 전송하는 조정 프로그램을 나타낸 예이다.
service Service1
{
message msg1;
port port1;
port port2;
receive(port1, msg1);
send(port2, msg1);
}
이러한 서비스를 구축하기 위한 대응하는 저작 API는 이하를 포함한다.
//이름 "service1"을 갖는 서비스를 선언함
Schedule schedule = new Schedule("Service1");
schedule.TransactionType = TransactionType.Atomic;
//포트 "port1" 및 메시지 "msg1"을 사용하는 이름 "receive1"을 갖는 receive를 선언함
Receive receive1 = new Receive("receive1");
receive1.Port = "port1";
receive1.Message = "msg1";
schedule.AddActivity(receive1);
//포트 "port2" 및 메시지 "msg1"을 사용하는이름 "send1"을 갖는send를 선언함
Send send1 = new Send("send1");
send1.Port = "port2";
send1.Message = "msg1";
schedule.AddActivity(send1);
//서비스 선언에 외부 사용자 코드를 제공함
serviceDeclaration.ExternalUserCode = "<어떤 외부 사용자 코드, 여기에서 사용자는 'port1', 'port2' 및 'msg1' 변수를 선언함>";
이하의 표는 이 네임스페이스에 대한 설명 및 그 용도를 간략히 기술한다.
System.Workflow.ComponentModelNamespace.Model
네임스페이스 System.Workflow.ComponentModel
설명 이 네임스페이스는 모든 표준 작업 흐름 활동들의 구현을 포함한다. 이 네임스페이스에 정의된 모든 활동들은 작업 흐름 런타임에 의해 지원된다. 또한, 이 네임스페이스는 커스텀 활동을 작성하는 인터페이스 및 프로토콜을 정의한다.
용도 Schedule을 프로그램적으로 생성하기 위해, 이들을 xoml 파일로/로부터 직렬화/역직렬화함. 스케쥴을 컴파일하고 런타임 실행가능 코드를 생성함. 이 객체 모델의 최상단에 커스텀 디자이너를 작성함 커스텀 활동, 그의 직렬화 및 컴파일 루틴을 작성함
바이너리 System.Workflow.ComponentModel.dll
작업 흐름 컴포넌트 모델은 계층적 선언 객체 모델이다. 객체 모델의 루트는 Schedule이다. 이 객체 모델은 런타임 실행 뿐만 아니라 도구 작성기(tool writer)에 의해 사용된다. 컴포넌트 모델 내의 모든 활동은 IActivity 인터페이스에 의해 표현된다. IActivity 인터페이스는 IComponent로부터 상속된다. IComponent는 활동이 디자인 시에 통신할 수 있게 해주는 Site 프로퍼티를 갖는다. 이 객체 모델은 써드 파티 활동 작성기에 의해 확장될 수 있다. 활동들은 다음과 같이 분류될 수 있다.
1) 프리미티브 활동(Primitive Activity): 프리미티브 활동은 자식 활동을 갖지 않으며 프로퍼티의 단순 리스트(flat list)를 포함한다.
2) 복합 활동(Composite Activity): 복합 활동은 프리미티브 활동으로부터 상속되며 자식 활동의 리스트를 유지한다.
상기의 프리미티브 및 복합 활동 분류 이외에, Scope 및 Schedule 활동은 다르게 취급된다. Scope 및 Schedule은 그와 연관된 대응하는 User Code 클래스를 갖는다. 모든 활동들과 함께, 이 네임스페이스도 역시 이하의 특징, 즉 xoml 파일로/로부터 직렬화/역직렬화, Schedule 활동의 컴파일, 및 각 활동에 대한 검증 구현을 제공한다.
IActivity 인터페이스는 IComponent로부터 상속된다.
public interface IActivity: IComponent
{
//이것은 그의 부모 스코프 내의 활동의 고유한 식별자이다.
//스코프들에 걸쳐 이 id는 똑같은 값을 가질 수 있다. 스코프들에 걸쳐
//활동들을 식별하기 위해, 스코프 적격 이름(qualified name)이
//사용되어야만 한다.
//또한 Scope 및 Schedule에 있어서, 이 프로퍼티는 그들이 작용하는 사용자
//코드 클래스의 이름을 알려준다.
string ID {get; set;}
//이 프로퍼티는 활동의 적격 ID(qualified ID)를 반환한다.
//활동의 적격 ID는 "." 및 활동 ID와 결합된 ParentScope ID이다.
string QualifiedID {get;}
//이것은 프로세스 내의 활동에 관한 설명을 보유하는 데 사용되는 get set
//프로퍼티이다.
String Description {get; set;}
//이것은 활동을 코멘트(comment) 또는 언코멘트(uncomment)하는 get set
//프로퍼티이다. 활동이 코멘트된 경우, 활동은 실행 및 검증 검사에
//참여하지 않는다.
bool Commented {get; set;}
//이것은 활동이 RuntimeMode에 대해 인스턴스화되는지를 알려주는 get
//프로퍼티이다. 보통 활동 그래프가 런타임 모드에 대해 인스턴스화될 때
//활동들은 사용자가 그의 프로퍼티를 변경할 수 없도록 그 모두를
//읽기 전용으로 만든다.
bool IsRuntimeMode {get;}
//이 메소드는 런타임 시에 활동의 상태를 반환한다. 다수의 통합
//인스턴스가 동일한 활동 트리를 공유하기 때문에, 그 특정의 활동 및
//인스턴스에 대해 // IActivityState 인터페이스가 반환될 것이라는 것에
//기초하여 이 메소드는 통합의 인스턴스에 대한 포인터를 취한다.
//IActivityState 인터페이스는 Status 및 Outcome 프로퍼티를 가져오는
//방법을 제공한다.
IActivityState GetState(object scopeBoundObject);
//이 프로퍼티의 목적은 어떤 커스텀 데이터를 활동과 프로그램적으로
//연관시킬 수 있도록 하는 것이다. 이것은 활동 DOM에 대해 프로그래밍
//하는 데 사용된다.
IDictionary UserData {get;}
//이 프로퍼티는 이 활동의 부모 활동을 알려준다.
ICompositeActivity Parent {get; set;}
//이 프로퍼티는 활동의 부모 스코프를 알려준다. 이 프로퍼티는 여러분이
//스코프를 가져올 때까지 모든 부모들을 살펴본다. 또한 스코프의
//ParentScope가 부모 스코프만을 반환한다는 것에 유의한다.
IScope ParentScope {get;}
//이 함수는 활동을 검증하는 데 사용된다. 이 함수는 IServiceProvider의
//형태의 컨텍스트로 전달되며, IServiceProvider로부터 활동 작성자는
//활동의 내용을 검증하기 위한 다른 서비스를 가져올 수 있다. 현재,
//이 함수는 디자이너 뿐만 아니라 Xoml 컴파일러로부터 호출된다. 2가지
//서비스로는 1) ITypeProvider 2)IEnvironmentService가 있다.
IValidationError[] Validate(IServiceProvider context);
}
이하는 IValidationError의 정의이다. 이 에러는 활동에 대해 Validate를 호출할 때 반환된다.
public interface IValidationError
{
//에러 텍스트는 에러의 설명을 반환한다.
string ErrorText {get;}
//이 프로퍼티의 목적은 어떤 커스텀 데이터를 에러와 프로그램적으로
//연관시킬 수 있도록 하는 것이다. 예를 들어, 이 프로퍼티 내의
//'typeof(string)' 키는 프로퍼티의 이름을 유지하고 있어야만 한다.
IDictionary UserData {get;}
}
모든 복합 활동은 ICompositeActivity로부터 상속된다. 복합 활동은 프리미티브 활동과 비교하여 부가의 프로퍼티 "Activities" 및 ExecutableActivities를 갖는다. 이하는 ICompositeActivity의 인터페이스 정의이다.
public interface ICompositeActivity: IActivity
{
//이 프로퍼티는 자식 활동들을 가져오는 데 사용된다. 유의할 점은
//이것이 활동들의 IList가 아니라 활동들의 IItemList를 반환한다는
//것이다. IItemList는 활동 DOM에서 정의된 인터페이스이며, 이는 활동이
//리스트에 부가 또는 그로부터 제거될 때 통지하기 위한 여분의 이벤트를
//갖는다.
IActivityCollection Activities {get;}
//실행가능 활동은 비코멘트된 활동의 컬렉션을 반환한다. 이 프로퍼티는
//단지 활동의 읽기 전용 컬렉션을 반환한다. 사용자가 활동들을 변경,
//부가 또는 삭제하기를 원하는 경우, "Activities" 컬렉션이 사용되어야만
//한다.
IList<IActivity> ExecutableActivities {get;}
}
IActivityCollection은 IList로부터 상속되고, 그것은 리스트의 수정 및 런타임 모드에서의 컬렉션의 동적 업데이트에 관련한 더 많은 메소드의 결합에 관한 하나의 부가의 이벤트를 갖는다.
public interface IActivityCollection<T>:IList<T>
{
//어떤 아이템이 이 리스트로부터 부가, 제거 또는 대체될 때 기동되는
//이벤트
event ItemListChangeHandler<T> ListChanged;
//활동의 ID 프로퍼티에 기초하여 활동에 도달하는 인덱서 프로퍼티
IActivity this[string key] {get;}
//런타임시에 활동 컬렉션을 동적으로 변경시키는 메소드. 이들 메소드는
//ScopeBoundObject(수정이 적용되고 있는 인스턴스)에 대한 포인터를 취함.
//활동을 부가함
void Add(object scope, IActivity activity);
//활동 범위를 부가함
void AddRange(object scope, ICollection<IActivity> activities);
//활동을 제거함
void Remove(object scope, IActivity activity);
//활동을 교체함
void Replace(object scope, IActivity replaceThis, IActivity withThis);
}
런타임 값 프로바이더
활동 프로퍼티의 값은 코드-비사이드 파일 내의 변수 또는 메소드에 대한 상수 또는 포인터이다. 예를 들어, Send 활동에 대한 Message 프로퍼티는 코드 비사이드 파일 내의 숫자 변수를 가리키고, Terminate 활동의 ErrorString 프로퍼티는 리터럴 형태로 실제 스트링을 유지하고자 원할 수 있거나 코드 비사이드 파일 내의 변수를 가리키기를 원할 수 있다. 런타임 관점에서 볼 때, 그것은 프로퍼티의 값을 가져오는 것에만 관심이 있을 뿐이며, 이것은 값이 그로부터 검색되는 리터럴 또는 코드 비사이드 파일 내의 변수일 수 있다.
public abstract class RuntimeValueProvider
{
//이 프로퍼티는 이 객체가 반환하는 값의 타입을 가져온다.
Type RuntimeType {get;}
//이 메소드는 런타임시에 프로퍼티의 값을 검색하는 데 사용된다.
object GetValue(object scopeBoundObject);
}
일 실시예에서, 2가지 서로 다른 종류의 값 프로바이더, 즉 1) Literal Declaration, 2) Member Declaration이 있다.
MemberDeclaration
이들 객체는 특정 런타임 타입의 사용자 코드 파일 내의 변수 또는 메소드 이름을 나타낸다. 예를 들어, Send에 대한 Message 프로퍼티는 사용자 코드 비사이드 파일 내의 변수를 가리키며, 이는 타입 "System.Workflow.Runtime.OEMessage<T>"를 가져야만 한다. 이러한 프로퍼티는 타입 "string"을 가지며, 그의 값은 변수의 이름이다. Non-Activity 클래스는 string 값 이외에 그와 연관된 어떤 메타 데이터를 갖는다. 예를 들어, 이들은 이들 변수가 어떤 런타임 타입을 말하는지를 알려줄 수 있다.
public class MemberDeclaration
{
//이름 프로퍼티는 코드 비사이드 파일 내의 멤버 변수 또는 메소드를
//가리킨다. 이름은 Scope 적격(qualified)일 수 있다.
string Name {get; set;}
//이 프로퍼티는 코드 비사이드 파일 내의 변수 또는 핸들러 선언의 타입을
//저장한다.
Type RuntimeType {get; set;}
//이 프로퍼티는 런타임 시에 값을 가져오기만 한다. 그것은 이 클래스의
//객체가 런타임 모드에 대해 인스턴스화될 때만 값을 가져온다.
Scope Scope {get;}
//이 프로퍼티는 객체가 런타임 사용을 위해 인스턴스화되었는지를
//알려준다.
bool IsRuntimeMode {get;}
//validate 메소드는 이 객체를 검증하고 검증 에러의 컬렉션을 반환한다.
//그것은 이 객체가 그 일부인 활동 및 부모 프로퍼티의 이름을 넘겨준다.
IValidationError[] Validate(IServiceProvider serviceProvider, IActivity activity, string parentPropName);
}
MemberDeclaration으로부터 2개의 메인 상속 분기, 즉 1) VariableDeclaration, 2) HandlerDeclaration가 있다. VariableDeclaration은 사용자 코드 비사이드 파일 내의 변수를 언급하는 데 사용되고, HandlerDeclaration은 사용자 코드 비사이드 파일 내의 메소드를 언급하는 데 사용된다. VariableDeclWithOneArg는 variableDecl로부터 상속되고 사용자 코드 비사이드 파일 내의 변수를 언급하는 데 사용되며, 그의 런타임 타입은 하나의 인수를 갖는 일반 타입(generic type)이다.
또한, 이들 선언 클래스와 연관된 많은 디자인시 기능이 있다. 예를 들어, 여러분의 활동에 대한 프로퍼티 타입으로서 VariableDeclaration을 사용하는 것은 프로퍼티 브라우저 윈도우 내에 특정 런타임 타입의 코드 비사이드 파일 내의 모든 변수를 열거하기 위한 콤보 박스를 자동적으로 제공한다. 또한, 이들 클래스는 시맨틱 검사를 하는 기능을 갖는다. 예를 들어, HandlerDeclaration은 메소드 이름이 유효한지, 메소드가 사용자 코드 파일 내에 있는지, 및 메소드의 서명이 런타임 타입 프로퍼티에 의해 식별된 것과 일치하는지를 검사한다.
VariableDeclaration
VariableDeclaration은 MemberDeclaration으로부터 상속되고, 코드 비사이드 파일 내의 변수의 이름을 저장한다. 그것은 런타임 모드에서 3개의 부가의 메소드를 갖는다.
public class VariableDeclaration: MemberDeclaration
{
...
//런타임 시에 코드 비사이드 파일 내의 변수를 가리키는 FieldInfo 객체
public FieldInfo FieldInfo {get;}
//스케쥴의 특정 인스턴스에 대해 런타임 시에 변수의 값을 가져오는 메소드
public object GetRuntimeValue(object scopeObj);
//스케쥴의 특정 인스턴스에 대해 런타임 시에 변수의 값을 설정하는 메소드
public void SetRuntimeValue(object scopeObj, object value);
}
TypedVariableDeclaration은 VariableDeclaration으로부터 상속되고 런타임 타입 프로퍼티를 읽기 전용으로 만든다.
HandlerDeclaration
HandlerDeclaration은 MemberDeclaration으로부터 상속되고 코드 비사이드 파일 내의 메소드 이름을 가리킨다. 그것은 코드 비사이드 클래스 내의 메소드를 가리키는 델리게이트 객체를 반환하는 런타임 시의 하나의 부가의 메소드를 갖는다.
TypedHandlerDeclaration은 HandlerDeclaration으로부터 상속되고 그것은 런타입 타입 프로퍼티를 읽기 전용으로 만든다.
LiteralDeclaration
LiteralDeclaration 객체는 코드 비사이드 파일 내의 변수를 가리키지 않고 리터럴 값을 포함한다. 이하의 이 클래스의 정의이다.
public class LiteralDeclaration: RuntimeValueProvider
{
//이 프로퍼티는 리터럴 값을 가져오거나 설정하는 데 사용된다.
string LiteralValue {get; set;}
}
RuleDeclaration
규칙은 통합의 거동을 동적으로 변경하기 위해 비지니스 프로세스에서 사용된다. 작업 흐름 컴포넌트 모델은 임의적인 규칙 기술을 플러그인하는 방법을 정의한다. 커스텀 규칙 기술을 구현하기 위해서는, RuleDeclaration으로부터 상속되는 클래스를 정의해야만 한다. 그것은 규칙을 검증하고 런타임 초기화 모드에 관해 상속된 클래스들에 알려주는 추상 메소드를 갖는다. 커스텀 규칙 기술 제공자는 RuleDeclaration 클래스로부터 상속되며 이들 메소드를 오버라이드한다. 또한, 그것은 규칙 정의를 정의하는 데 사용되는 부가의 프로퍼티를 제공한다.
현재 작업 흐름 컴포넌트 모델은 2개의 RuleDeclaration 클래스를 가지며, 하나는 코드 기반 규칙 선언으로서 규칙을 평가하여 true 또는 false 값을 반환하는 그와 연관된 부울 핸들러 메소드를 갖는다. 또하나의 기술은 BRE 기반 규칙 선언으로서 규칙을 정의하는 객체 모델을 제공한다. 규칙 선언 클래스의 런타임 대응물은 RuleEvaluator이다. 작업 흐름 엔진은 RuleDeclaration 클래스에 대한 RuleEvaluator 애트리뷰트를 찾는다. 이 애트리뷰트는 IRuleEvaluator 인터페이스를 구현하는 타입의 이름을 알려준다. IRuleEvaluator 인터페이스는 부울값을 반환하는 단지 하나의 메소드 Evaluate()를 갖는다.
런타임 모드
디자인 시에 조정 프로그램을 작성하는 데 사용되는 동일한 활동 그래프도 또한 런타임 시에 인스턴스화된다. 런타임 시에, 작업 흐름 엔진은 활동 그래프의 루트 객체를 호출하여 그 자신을 실행시키고, 이는 이어서 그의 자식 활동들을 호출하여 그들 자신을 실행시키며, 이하 마찬가지이다. 복합 활동인 자식 활동들은 그의 자식 활동들에게 그들 자신을 실행하도록 요청한다. 활동 그래프가 런타임 사용을 위해 인스턴스화될 때, 활동들은 그의 프로퍼티를 변경할 수 없다.
활동은 OnRuntimeInitialize() 메소드를 오버라이드함으로써 런타임 초기화에 관해 알 수 있으며, 이 메소드는 Activity 클래스 내에 정의된 protected 메소드이다. 활동들은 이 메소드에서 런타임 관련 초기화를 할 수 있다. 보통, 활동들의 런타임 초기화 시에, 활동들은 그의 스트링화된 정보를 실제 런타임 타입 정보로 분해한다. 예를 들어, InvokeWebService 활동은 디자인 시에 프록시 클래스의 이름을 스트링 형태로 유지한다. 호출 웹 서비스가 런타임을 위해 인스턴스화될 때, 그 서비스는 프록시 클래스 이름을 실제의 System.Type 객체로 분석한다.
작업 흐름 엔진은 실행 중인 통합의 다수의 인스턴스들에 대해 하나의 활동 그래프만을 유지한다. 활동에 대한 GetState(object scopeBoundObject) 메소드는 통합의 특정 인스턴스에 대해 IActivityState를 반환한다. IActivityState 인터페이스를 사용하여, 활동의 Staus 및 Outcome 프로퍼티를 가져올 수 있다.
public interface IActivityState
{
//활동의 상태를 가져옴. 런타임 실행 모드에서, 활동은 다수의 상태 천이,
//예를 들어 Enabled, Executed, Completed, Closed, Cancelled를 통과한다.
//status 프로퍼티는 활동의 정확한 현재 상태를 알려준다.
Status Status {get;}
//작업 흐름 엔진은 활동의 실행의 Outcome을 유지한다. 활동 실행이 취소되는 경우, Outcome가 취소되고, 활동 실행이 예외를 던지는 경우 Outcome이 Failed로 되며, 그렇지 않고 활동이 완료되어 종료되면 Outcome은 Succeeded로 된다.
Outcome Outcome {get;}
}
활동들의 런타임 인스턴스화와 병렬로, 비활동 선언도 또한 런타임 모드를 위해 인스턴스화된다. 예를 들어, 이름이 "art"이고 런타임 타입이 "System.String"인 VariableDeclaration은 런타임 인스턴스화 시에 System.Reflection.FieldInfo 객체를 가지며, 이는 코드 비사이드 파일 내의 "Art" 변수를 가리키게 된다. 타입 VariableDeclaration 또는 HandlerDeclaration을 갖는 활동의 프로퍼티는 또한 런타임 모드에 관해 통지받기 위해 OnRuntimeInitialized()를 오버라이드할 수 있다. MemberDeclaration에 대한 'Scope' 프로퍼티는 Member가 속해 있는 Scope 객체로 초기화된다. 또한, VariableDeclaration 및 HandlerDeclaration에 대한 GetRuntimeValue() 및 SetRuntimeValue() 메소드는 스케쥴의 특정 인스턴스에 대해 변수 또는 메소드의 값을 반환하기 시작한다.
커스텀 활동의 작성
커스텀 활동을 작성하기 위해, 활동 클래스는 ActivityDecl 또는 CompositeActivityDecl로부터 상속된다. 활동의 커스텀 직렬화를 지원하기 위해, SerializerAttribute가 활동 클래스에 부가되어 있다. 디자이너 애트리뷰트는 디자이너를 활동과 연관시킨다. 여기에 간단한 활동 코드가 있다.
[ToolboxItem(typeof(WorkflowToolboxItem))]
[Designer(typeof(FooActivityDesigner), typeof(IDesigner))]
[ActivityExecutor(typeof(FooExecutor))]
public sealed class FooActivity: Activity
{
public FooActivity()
}
{
private string foo = string.Empty;
public string Foo
{
get
{
return this.foo;
}
set
{
this.foo = value;
}
}
}
컴포넌트 모델을 사용하는 샘플 프로그램
이하는 컴포넌트 모델에 대해 프로그램하는 샘플 코드이다. Schedule은 객체 모델의 루트이다. 이 샘플은 새로운 Schedule을 생성한다. 아이템 리스트로의 변경에 대한 이유를 알려주기 위해 열거(enumeration)가 사용된다.
//스케쥴을 생성함
Schedule schedule = new Schedule();
schedule.NamespaceName = "SampleUserCode";
schedule.ID = "MySchedule";
//스코프를 생성함
Scope scope = new Scope();
scope.ID = "MyScope";
schedule.Activities.Add(scope);
//어떤 것을 내보내는 send 활동을 생성함
Send.send1 = new Send();
send1.ID = "send1";
send1.Message.Name = "msg1";
send1.Message.Type = typeof(System.String).FullName;
send1.HasTypedChannel = true;
send1.TypedChannel.Name = "port1";
send1.TypedChannel.Type = typeof(SampleUserCode.IFoo).FullName;
send1.TypedChannel.Operation = "Foo";
scope.Activities.Add(send1);
//스케쥴 실행에서의 지연을 두는 delay 활동을 생성함
DelayDecl delay1 = new DelayDecl();
delay1.ID = "delay1";
delay1.TimeoutProvider.Name = "delay1_TimeoutProvider";
schedule.Activities.Add(delay1);
//receive 활동을 생성함
Receive receive1 = new Receive();
receive1.ID = "receive1";
receive1.Message.Name = "msg2";
receive1.Message.Type = typeof(string).FullName;
receive1.HasTypedChannel = true;
receive1.TypedChannel.Name = "port2";
receive1.TypedChannel.Type = typeof(SampleUserCode.IFoo).FullName;
receive1.TypedChannel.Operation = "Foo";
scope.Activities.Add(receive1);
Xoml 컴파일러
Xoml 컴파일러는 Xoml 파일을 컴파일하고 그에 대한 런타임 코드를 생성하는 데 사용된다. Xoml 컴파일러에 의해 제공되는 에러는 XomlCompilerError에 의해 제시된다. 또한 컴파일러는 입력으로서 XomlCompilerParameter를 취한다. 컴파일러 결과는 XomlCompilerResults에 의해 외부로 주어진다.
Xoml 컴파일러는 xoml 파일을 역직렬화하고 이어서 활동 그래프를 살펴본다. 이 컴파일러는 각 활동에 주어진 컨텍스트에서 그 자신을 검증하도록 요청한다. 활동이 검증에 참여하기를 원하는 경우, 그 활동은 IActivityValidator로부터 상속된다. 임의의 활동에 의해 주어진 검증 에러가 없는 경우, 컴파일러는 각 활동에 그 자신에 대한 코드를 생성하도록 요청한다. 활동이 코드 생성에 참여하기를 원하는 경우, 활동은 IActivityCodeGenerator로부터 상속된다.
XomlCompiler 클래스
Xoml 컴파일은 많은 다른 언어 컴파일러와 다르다. Xoml 컴파일러는 xoml 파일, 사용자 코드 파일을 입력으로서 받아서 런타임 프로세스 코드를 생성한다. 이하는 Xoml 컴파일에 관여하는 단계들이다.
1) 모든 Xoml 파일을 역직렬화하고 그로부터 활동 그래프를 생성한다.
2) 어셈블리 참조에 기초하여, 사용자 코드 파일 및 파라미터 형태로 컴파일러에 전달되는 코드 컴파일 유닛은 TypeProvider 컴포넌트를 생성한다.
3) 각각의 개별적인 xoml 파일의 활동 그래프를 살펴보고 그들에 대해 validate를 호출한다.
4) 검증 에러가 없는 경우, 각각의 xoml 활동 그래프의 최상위 활동에 대해 IActivityCodeGenerator.GenerateCode를 호출하며 이는 CodeStatementCollection을 생성한다.
5) 생성된 프로세스 코드의 CodeCompileUnit을 내보내거나 건네받은 사용자 코드로 프로세스 코드를 컴파일하고 C# 또는 VB 컴파일러를 사용하여 어셈블리를 구성한다.
이하는 XomlCompiler에 대해 이용가능한 public 메소드이다.
public class XomlCompiler
{
XomlCompilerResults CompileFromDom(XomlCompilerParameters parameters,
Schedule scheduleDecl);
XomlCompilerResults CompileFromDomBatch(XomlCompilerParameters
parameters, Schedule[] scheduleDecls);
XomlCompilerResults CompileFromFile(XomlCompilerParameters parameters,
string file);
XomlCompilerResults CompileFromFileBatch(XomlCompilerParameters
parameters, string[] files);
XomlCompilerResults CompileFromSource(XomlCompilerParameters
parameters, string xomlSource);
XomlCompilerResults CompileFromSourceBatch(XomlCompilerParameters
parameters, string[] xomlSources);
void GenerateSkeletonCompanionCode(Schedule schedule,
SupportedLanguages language, System.IO.TextWriter writer);
void GenerateSkeletonCompanionCode(string file, SupportedLanguages
language, System.IO.TextWriter writer);
}
CompileFromDom 메소드
XomlCompilerResults CompileFromDom(XomlCompilerParameters parameters, Schedule scheduleDecl);
CompileFromDom은 단지 입력 파라미터로서 단일의 Schedule를 취하며 그를 컴파일하여 프로세스 코드를 생성한다. 이 함수는 한번에 하나의 스케쥴을 컴파일하기를 원하는 사용자에 도움을 준다. 이 함수는 내부적으로 CompileFromDomBatch를 호출한다.
CompileFromDomBatch 메소드
XomlCompilerResults CompileFromDomBatch(XomlCompilerParameters
parameters, Schedule[] scheduleDecls);
CompileFromDomBatch는 입력 파라미터로서 다수의 Schedule를 취하고 이들을 컴파일하여 프로세스 코드를 생성한다.
CompileFromFile 메소드
XomlCompilerResults CompileFromFile(XomlCompilerParameters parameters,
string file);
CompileFromFile은 입력 파라미터로서 단일의 xoml 파일을 취한다. 두번째 파라미터는 xoml 파일로의 경로로서 취급된다. 이 함수는 한번에 하나의 xoml 파일을 컴파일하기를 원하는 사용자에게 도움을 준다. 이 함수는 내부적으로 CompileFromFileBatch를 호출한다.
CompileFromFileBatch 메소드
XomlCompilerResults CompileFromFileBatch(XomlCompilerParameters
parameters, string[] files);
CompileFromFileBatch는 입력으로서 다수의 xoml 파일을 취하며 이들을 컴파일하여 프로세스 코드를 생성한다. 두번째 파라미터는 xoml 파일들로의 경로의 어레이이다. 이 함수는 모든 xoml 파일들을 역직렬화한다. XOML 파일이 역직렬화될 수 없는 경우, 이 함수는 CompilerResults 내의 Errors 컬렉션에 SerializationError를 부가한다. 이 함수는 컴파일을 하기 위해 CompileFromFileBatch를 호출한다.
CompileFromSource 메소드
XomlCompilerResults CompileFromSource(XomlCompilerParameters
parameters, string xomlSource);
CompileFromSource는 입력 파라미터로서 Xoml 파일의 텍스트를 취하고 이를 컴파일하여 프로세스 코드를 생성한다. 이 함수는 실제 컴파일을 수행하기 위해 CompileFromSourceBatch를 호출한다.
CompileFromSourceBatch 메소드
XomlCompilerResults CompileFromSourceBatch(XomlCompilerParameters
parameters, string[] xomlSources);
CompileFromSourceBatch는 입력 파라미터로서 xoml 파일들의 다수의 소스를 취하고 이들을 컴파일하여 프로세스 코드를 생성한다. 이 함수는 활동 DOM을 얻기 위해 소스들을 역직렬화한다. 역직렬화 에러가 있는 경우, 이 함수는 그 에러들을 XomlCompileError로 변환하고 XomlCompilerResults를 통해 그것들을 보고한다.
GenerateSkeletonCompanion 메소드
void GenerateSkeletonCompanionCode(Schedule schedule,
SupportedLanguages language, System.IO.TextWriter writer);
이 함수는 핸들러, 활동 dom에서 사용된 변수 이름들에 기초하여 스켈러튼 사용자 코드 비사이드 파일을 생성하는 데 사용된다. 이 함수는 활동 그래프를 살펴보고 스코프, 변수 및 핸들러에 대한 템플릿 코드를 생성한다. 두번째 파라미터는 코드를 생성하는 데 사용될 필요가 있는 언어를 알려 준다. 세번째 파라미터는 텍스트 작성기(text writer)로서, 생성된 코드가 기록될 버퍼를 보유한다.
void GenerateSkeletonCompanionCode(string file, SupportedLanguages
language, System.IO.TextWriter writer);
이 함수는 입력 파라미터로서 xoml 파일 경로를 취한다. 이 함수는 xoml 파일을 역직렬화하고 이전의 함수를 호출한다.
XomlCompilerParameters
XomlCompilerParameters는 사용자 코드에서 컴파일러에 전달할 프로퍼티를 갖는다. 이하는 XomlCompilerParameters에 대한 public 인터페이스이다.
public class XomlCompilerParameters: CompilerParameters
{
bool GenerateCodeCompileUnitOnly {get; set;}
bool GenerateDebugCode {get; set;}
SupportedLanguages LanguageToUse {get; set;}
StringCollection LibraryPaths {get;}
IServiceProvider ServiceProvider {get; set;}
IList<CodeCompileUnit> UserCodeCompileUnits {get;}
StringCollection UserCodeFiles {get;}
}
GenerateCodeCompileUnitOnly 프로퍼티
bool GenerateCodeCompileUnitOnly {get; set;}
이 플래그는 컴파일러에게 사용자가 CodeCompileUnit를 생성하는 데만 관심이 있고 실행가능 파일 또는 dll을 생성하는 데는 관심이 없음을 알려주는 데 사용된다. 이 경우, 컴파일러는 코드를 생성하기 위해 C# 또는 VB 컴파일러를 호출하지 않는다.
GenerateDebugCode 프로퍼티
bool GenerateDebugCode {get; set;}
이 플래그는 디버그 코드가 사용되어야만 하는지 여부를 알려주는 데 사용된다.
LanguageToUse 프로퍼티
SupportedLanguages LanguageToUse {get; set;}
적어도 2개의 지원되는 언어, 즉 VB 및 C#이 있다. 컴파일러는 사용할 언어를 알고 있을 필요가 있는데, 그 이유는 그 언어에 기초한 많은 검증을 가지고 있기 때문이다.
LibraryPaths 프로퍼티
StringCollection LibraryPaths {get;}
이것은 디렉토리 이름의 컬렉션으로서 그 아래에서 컴파일러는 참조된 어셈블리를 탐색한다. 유의할 점은 컴파일러도 역시 어셈블리 참조를 분석하기 위해 어떤 표준 라이브러리 경로를 이 컬렉션에 부가한다는 것이다. 이 거동은 C# 및 VB 컴파일러와 유사하다.
ServiceProvider 프로퍼티
IServiceProvider ServiceProvider {get; set;}
이 프로퍼티는 컴파일러가 프로젝트 시스템으로부터 호출될 때만 사용된다. 이 프로퍼티의 목적은 컴파일이 프로젝트 시스템으로부터 호출될 때 성능을 달성하는 것이다. 프로젝트 시스템이 프로젝트별로 생성된 TypeProvider를 갖기 때문에, 컴파일러는 동일한 TypeProvider를 사용한다. 이것은 프로젝트 시스템으로부터 호출될 때 컴파일러의 성능을 상당히 향상시킨다.
UserCodeCompileUnits 프로퍼티
IList<CodeCompileUnit> UserCodeCompileUnits {get;}
이 프로퍼티는 사용자 코드 비사이드 파일의 Code 컴파일 유닛을 컴파일러로 전달하는 데 사용된다.
UserCodeFiles 프로퍼티
StringCollection UserCodeFiles {get;}
이 프로퍼티는 사용자 코드 비사이드 파일의 파일 경로를 컴파일러에 전달하는 데 사용된다.
XomlCompilerResults
XomlCompilerResults는 생성된 프로세스 코드의 CodeCompileUnit을 검색하는 프로퍼티를 갖는다. 이하는 XomlCompilerResults의 public 인터페이스이다.
public class XomlCompilerResults: CompilerResults
{
CodeCompileUnit CompiledUnit {get; set;}
}
CompiledUnit 프로퍼티는 프로세스 코드로의 액세스를 제공한다.
XomlCompilerError
XomlCompilerError는 Dictionary 타입을 갖는 UserData 프로퍼티를 가져오는 메소드를 갖는다. 이 프로퍼티의 목적은 에러에 관한 추가의 상세를 삽입하는 것이다. 예를 들어, 프로퍼티 검증 중 하나가 실패한 경우, 활동은 dictionary에 대한 키로서 typeof(string)을 갖는 프로퍼티 이름을 갖는다. 이하는 이 클래스에 의해 노출되는 public 인터페이스이다.
public class XomlCompilerError: CompilerError
{
System.Collections.IDictionary UserData {get;}
}
XomlCompilerError는 또한 IWorkflowError 인터페이스도 구현하며, 이 인터페이스의 목적은 에러에 대한 COM 상호운영성을 제공하는 것이다. 이하는 IWorkflowError 인터페이스의 정의이다.
public interface IWorkflowError
{
String Document {get;}
bool IsWarning {get;}
String Text {get;}
String ErrorNumber {get;}
int LineNumber {get;}
int ColumnNumber {get;}
}
프로퍼티들은 System.CodeDom에 정의된 CompileError의 프로퍼티들로 매핑된다.
검증 하부 구조
모든 활동은 Validate 메소드를 갖는 IActivity로부터 상속된다. Validate 메소드는 IServiceProvider를 취한다. 예를 들어, ITypeProvider는 활동의 프로퍼티인 타입 이름이 실제 타입으로 분석될 수 있는지 여부를 결정한다. validate 메소드는 IValidationError의 컬렉션을 반환한다. 이하는 Validate 메소드의 서명이다.
IValidationError[] Validate(IServiceProvider context);
이하는 IValidationError에 대해 이용가능한 public 메소드이다.
public interface IValidationError
{
string ErrorText {get;}
IDictionary UserData {get;}
}
샘플 검증 루틴:
이하는 DelayDecl 활동의 검증 루틴의 일례이다. Delay는 TimeoutProvider 핸들러가 실제로 null이 아니고 메소드 이름이 부모 스코프 클래스에 존재하는지를 검증하기를 원한다.
public override IValidationError[] Validate(IServiceProvider context)
{
ArrayList validationErrors = new ArrayList(base.Validate(context));
//TimeoutProvider 프로퍼티를 검증함
validationErrors.AddRange(this.TimeoutProvider.Validate(context, this, "TimeoutProvider"));
return(IValidationError[])validationErrors.ToArray(typeof(IValidationError));
}
이하는 HandlerDeclaration의 검증 루틴이다.
public override IValidationError[] Validate(IServiceProvider context, IActivity activityDecl, string propName)
{if(context == null) throw new ArgumentNullException("context");
if(activityDecl == null) throw new
ArgumentNullException("activityDecl");
ArrayList validationErrors = new ArrayList();
string message = string.Empty;
if(this.Name == null || this.Name.Length == 0)
{message = SR.GetString(SR.Error_PropertyNotSet, propName);}
else
{ string methodName = string.Empty;
Type resolvedType = XomlValidationHelper.ParseInputName(context, activityDecl, this.Name, out methodName);
if(resolvedType == null)
{message = SR.GetString(SR.Error_TypeNotResolvedInMethodName, propName);}
else
{//invoke 메소드를 가져옴
MethodInfo invokeMethod = this.RuntimeType.GetMethod("Invoke");
if(invokeMethod == null)
throw new Exception(SR.GetString(SR.Error_DelegateNoInvoke,
this.Runtimetype.FullName));
// 메소드를 분석함
List<Type> paramTypes = new List<Type>();
foreach(ParameterInfo paramInfo in invokeMethod.GetParameters())
paramTypes.Add(paramInfo.ParameterType);
BindingFlags bindingFlags = BindingFlags.Public |
BindingFlags.Instance | BindingFlags.NonPublic |
BindingFlags.Static;
MethodInfo methodInfo = resolvedType.GetMethod(methodName,
bindingFlags, null, paramTypes.ToArray(), null);
if(methodInfo == null)
{if(resolvedType.GetMethod(methodName, bindingFlags) != null)
message = SR.GetString(SR.Error_MethodSignatureMismatch,
propName);
else message = SR.GetString(SR.Error_MethodNotExists, propName, methodName);}
else if(!invokeMethod.ReturnType.Equals(methodInfo.ReturnType))
{message = SR.GetString(SR.Error_MethodReturnTypeMismatch,
propName, invokeMethod.ReturnType.FullName);}}}
IValidationError error = null;
if(message.Length > 0)
{ error = new ValidationError(message);
error.UserData[typeof(string)] = propName;
validationErrors.Add(error);}
return(IValidationError[])validationErrors.ToArray(typeof(IValidationError));}
런타임 코드 생성
Xoml 컴파일러는 스케쥴에 대한 NamespaceName 프로퍼티로서 네임스페이스를 가지고 또 스케쥴에 대한 ID 프로퍼티로서 클래스 이름을 갖는 Schedule 클래스를 생성한다. 이어서, 이 컴파일러는 Schedule 객체를 xoml 스트링으로 직렬화하고 스케쥴 클래스에 그에 대한 XomlAttribute로 주석을 첨부시키고, 첫번째 파라미터가 xoml 스트링이다.
이하의 샘플 코드는 ScheduleDecl 객체를 생성하고 또 사용자 코드를 포함하는 CodeCompileUnit 객체를 생성한다. 이 코드는 또한 Schedule 객체 및 UserCode-Xoml 컴파일러도 제공한다.
특히, 이하의 코드는 스케쥴을 생성한다.
Schedule schedule = new Schedule();
schedule.NamespaceName = "SampleUserCode";
schedule.ID = "MySchedule";
Scope scope = new Scope();
scope.ID = "MyScope";
schedule.Activities.Add(scope);
Send send1 = new Send();
send1.ID = "send1";
send1.Message.Name = "msg1";
send1.Message.Type = typeof(System.String).FullName;
send1.HasTypedChannel = true;
send1.TypedChannel.Name = "port1";
send1.TypedChannel.Type = typeof(SampleUserCode.IFoo).FullName;
send1.TypedChannel.Operation = "Foo";
scope.Activities.Add(send1);
Receive receive1 = new Receive();
receive1.ID = "receive1";
receive1.Message.Name = "msg2";
receive1.Message.Type = typeof(string).FullName;
receive1.HasTypedChannel = true;
receive1.TypedChannel.Name = "port2";
receive1.TypedChannel.Type = typeof(SampleUserCode.IFoo).FullName;
receive1.TypedChannel.Operation = "Foo";
scope.Activities.Add(receive1);
DelayDecl delay1 = new DelayDecl();
delay1.ID = "delay1";
delay1.TimeoutProvider.Name = "delay1_TimeoutProvider";
schedule.Activities.Add(delay1);
이하의 코드는 코드 컴파일 유닛을 생성하고, 네임스페이스를 부가하며, MySchedule 클래스를 부가하고, 또 delay 메소드를 부가한다.
CodeCompileUnit ccu = new CodeCompileUnit();
CodeNamespace sampleUserCode = new CodeNamespace("SampleUserCode");
ccu.Namespaces.Add(sampleUserCode);
/*
public partial class MySchedule: Schedule
{
public MySchedule()
{
}
}
*/
CodeTypeDeclaration mySchedule = new CodeTypeDeclaration("MySchedule");
mySchedule.BaseTypes.Add(new
CodeTypeReference("System.Workflow.Runtime.Schedule"));
mySchedule.IsClass = true;
mySchedule.PartialType = PartialType.Partial;
mySchedule.TypeAttributes = TypeAttributes.Public;
sampleUserCode.Types.Add(mySchedule);
/*
public System.DateTime delay1_TimeoutProvider()
{
return new System.DateTime();
}
*/
CodeMemberMethod delayMethod = new CodeMemberMethod();
delayMethod.Name = "delay1_TimeoutProvider";
delayMethod.Attributes
= (MemberAttributes.Public|MemberAttributes.Final);
delayMethod.ReturnType.BaseType = typeof(System.DateTime).FullName;
delayMethod.Statements.Add(new CodeMethodReturnStatement(new
CodeSnippetExpression("new System.DateTime();")));
mySchedule.Members.Add(delayMethod);
이하에 나타낸 코드는 MyScope 클래스를 작성하고 필드를 부가한다.
/*
public partial class MyScope: Scope
{
}
*/
CodeTypeDeclaration myScope = new CodeTypeDeclaration("MyScope");
myScope.BaseTypes.Add(new
CodeTypeReference("System.Workflow.Runtime.Scope"));
myScope.IsClass = true;
myScope.PartialType = PartialType.Partial;
myScope.TypeAttributes = TypeAttributes.Public;
sampleUserCode.Types.Add(myScope);
/*
public System.Workflow.Runtime.OEMessage<System.String>msg1;
public System.Workflow.Runtime.OEOutboundChannel<SampleUserCode.IFoo>
port1;
public System.Workflow.Runtime.OEMessage<System.String> msg2;
public System.Workflow.Runtime.OEInboundChannel<IFoo> port2;
*/
CodeMemberField msg1 = new
CodeMemberField("System.Workflow.Runtime.OEMessage<System.String>",
"msg1");
msg1.Attributes = MemberAttributes.Public;
myScope.Members.Add(msg1);
CodeMemberField port1 = new
CodeMemberField("System.Workflow.Runtime.OEOutboundChannel<SampleUser
Code.IFoo>", "port1");
port1.Attributes = MemberAttributes.Public;
myScope.Members.Add(port1);
CodeMemberField msg2 = new
CodeMemberField("System.Workflow.Runtime.OEMessage<System.String>",
"msg2");
msg2.Attributes = MemberAttributes.Public;
myScope.Members.Add(msg2);
CodeMemberField port2 = new
CodeMemberField("System.Workflow.Runtime.OEInboundChannel<SampleUser
Code.IFoo>", "port2");
port2.Attributes = MemberAttributes.Public;
myScope.Members.Add(port2);
이하의 코드는 최종 C# 코드를 생성한다. 특히, 이 코드는 사용자 코드로부터의 CCU와 XOML OM의 CCU를 결합하여 어셈블리를 생성한다.
XomlCompiler compiler = new XomlCompiler();
XomlCompilerParameters parameters = new XomlCompilerParameters();
parameters.ReferencedAssemblies.Add(typeof(SampleUserCode.IFoo).
Assembly.Location)
parameters.UserCodeCompileUnits.Add(ccu);
parameters.OutputAssembly =
@"c:＼CreateAssemblyWithUserCodeInCodeDOM.dll";
XomlCompilerResults results = compiler.CompileFromDom(parameters,
schedule);
에러 네비게이션 하부 구조
Xoml 컴파일러가 호출될 때, 이 컴파일러는 에러가 있는 경우 IWorkflowError 객체들의 컬렉션을 반환한다. 각각의 IWorkflowError 객체에 대해, 태스크 아이템이 생성된다. 이하는 사용자가 태스크 아이템을 더블클릭할 때 디자이너 상의 에러로 네비게이션하는 데 관여하는 단계들이다.
1) 각각의 태스크 아이템은 IWorkflowError 객체와 연관되어 있다.
2) 처음으로 더블클릭 시에, 그 아이템은 IWorkflowError.Document 프로퍼티를 호출함으로써 파일의 이름을 가져온다.
3) 태스크 아이템은 파일을 열고 그와 연관된 DocView 객체를 가져오도록 디자이너에게 요구한다.
4) 태스크 아이템은 DocView 상에서 IWorkflowErrorNavigator 인터페이스를 본다.
5) 태스크 아이템은 IWorkflowErrorNavigator.Navigate() 메소드를 호출하고, 첫번째 파라미터로서 IWorkflowError를 전달한다.
6) IWorkflowErrorNavigator 인터페이스는 문서 뷰 객체 상에 구현된다. Navigate 메소드의 구현에서, 에디터는 IWorkflowError의 UserData 프로퍼티에서 "typeof(IActivity)" 객체를 찾으려고 하며, 발견된 경우 에디터는 활동의 스코프 qualified name을 가져오고 디자이너에서 동일한 이름을 갖는 활동을 검색한다. 활동이 발견되면 그것에 포커싱된다. 그 후, 에디터는 UserData 프로퍼티에서 "typeof(string)" 키를 찾으며, 발견되면 에디터는 그것이 포커싱을 필요로 하는 프로퍼티의 이름임에 틀림없는 것으로 가정하고, 따라서 첫번째 인수로서 프로퍼티 이름을 전달함으로써 IExtUIService.NavigateToProperty() 메소드를 호출한다.
이하는 IWorkflowErrorNavigator의 인터페이스 정의이다.
internal interface IWorkflowErrorNavigator
{
void NavigateToError([MarshalAs(UnmanagedType.IUnknown)]object obj);
}
작업 흐름 컴파일러 실행 파일(즉, WFC.EXE)
wfc.exe는 XomlCompiler의 커맨드 라인 버전인 제품 바이너리(product binary)이다. 이 실행 파일은 커맨드 라인 인수를 파싱하고 XompCompilerParameters 구조체를 채운다.
이하는 XomlCompiler에 전달될 수 있는 옵션들의 정의이다.
wfc.exe <schedule>.xoml/target:codebeside [/language:...]
wfc.exe <schedule>.xoml/target:xomlclass [/language:...]
wfc.exe <schedule>.xoml/target:assembly[<codebeside>.cs]
[/language:...][/out:...][/reference:...][/library:...][/debug:...]
- 출력 파일 -
/out:<file> 출력 파일 이름
/target:assembly 작업 흐름 어셈블리를 빌드(build)(디폴트)
/target:xomlclass 부분 클래스 정의를 생성
/target:codebeside 스켈러튼 코드 비사이드를 생성
- 입력 파일 -
<xoml file list> Xoml 소스 파일 이름(들)
<vb/cs file list> 코드 비사이드 파일 이름(들)
/reference:<file list> 지정된 어셈블리 파일(들)로부터의 참조 메타데이터. 단축형은 '/r:'임
/library:<path list> 참조를 탐색할 곳인 디렉토리의 세트. 단축형은 '/lib:'임
- 코드 생성 -
/debug:[yes|no] 전체 디버깅 정보를 발생함. 디폴트는 'yes'. 단축형은 '/d:'임.
/skipvalidation[+|-] 작업 흐름 검증을 건너뜀.
/emitruntimecode[+|-] 작업 흐름에 대한 런타임 코드를 발생함.
- 언어 -
/language:[cs|vb] 생성된 클래스에 사용하기 위한 언어. 디폴트는 'CS'(C#). 단축형은 '/l:'임.
/rootnamespace:<string> 모든 타입 선언에 대한 루트 Namespace를 지정함. 'VB' 언어에만 유효함.
- 기타 -
/help 용도 메시지를 디스플레이함. 단축형은 '/?'임.
/nologo 컴파일러 저작권 메시지를 억압함. 단축형은 '/n'임.
타입 시스템
타입 시스템은 디자이너에서 독립적인 컴포넌트이다. CodeCompileUnit 및 어셈블리는 타입 시스템으로 푸시될 수 있다. 이 시스템은 System.Type 객체들을 어샘블리 참조로부터 로드하고 이를 타입 트리로 푸시한다. 또한, CodeCompileUnit 내의 각각의 CodeTypeDeclaration 객체에 대해, 이 시스템은 System.Type로부터 상속되는 DesignTimeType을 생성하고 이를 타입 트리로 푸시한다. 이와 같이 타입 시스템으로부터의 타입들은 공통 추상 클래스 System.Type에 의해 노출된다. 많은 다른 타입 시스템들과 마찬가지로, 이 타입 시스템은 타입을 그에 로드할 때 트리 구조를 생성하며, 이는 타입 분석을 아주 빠르게 해준다. 타입 시스템은 타입을 분석하기 위해 타입 트리에 대한 사용자 인터페이스를 제공하고, 또한 타입 트리에서의 변경에 관해 통지하기 위해 이벤트를 기동시킨다.
이하는 타입 시스템 내의 주요 컴포넌트이다.
1. TypeProvider: 이는 어셈블리 참조 및 CodeCompileUnit을 타입 시스템에 부가/제거하는 public 메소드를 갖는다. 또한, 이는 타입 트리를 사용자에게 노출시키는 인터페이스를 구현한다.
a. TreeNode: 트리 노드는 타입 트리 내의 일반 노드이다. 이는 그와 연관된 모든 타입 정의를 유지한다.
2. CodeDOMLoader: CodeDOM 로더는 CodeCompileUnit으로부터의 모든 타입을 로드하고 이들을 타입 트리로 푸시한다. CodeDOM 로더를 폐기(dispose)할 때, 이 로더는 그가 타입 트리에 부가했던 모든 타입들을 제거한다.
3. AssemblyLoader: 어셈블리 로더는 어셈블리로부터 모든 타입들을 로드하고 모든 타입들을 타입 트리로 푸시한다. 이것을 폐기할 때, 이 로더는 타입 트리로부터 모든 타입들을 제거한다.
4. DesingTimeType: 이 클래스는 System.Type으로부터 상속된다. 이는 그의 생성자 인수로서 CodeTypeDeclaration CodeDOM 구문을 취하고 System.Type 클래스의 모든 프로퍼티 및 메소드를 구현한다. 또한 이하의 클래스는 CodeTypeDeclaration으로부터 System.Type로 변환하는 데 사용된다.
a. DesignTimeMethodInfo: 이 클래스는 CodeMemberMethod에 기초하여 MethodInfo의 모든 멤버를 구현하는 데 사용된다.
i. DesignTimeParameterInfo: 이 클래스는 ParameterInfo로부터 상속되고 CodeParameterDeclarationExpression Code DOM 구문에 기초한 구현을 제공한다.
b. DesignTimeEventInfo: 이 클래스는 CodeMemberEvent에 기초하여 EventInfo의 멤버를 구현하는 데 사용된다.
c. DesignTimeFieldInfo: 이 클래스는 FieldInfo로부터 상속되고 CodeMemberField에 기초하여 모든 메소드 및 프로퍼티의 구현을 제공한다.
d. DesignTimePropertyInfo: 이 클래스는 PropertyInfo로부터 상속되고 CodeMemberProperty code dom 구문에 기초하여 모든 메소드 및 프로퍼티의 구현을 제공한다.
e. DesignTimeConstructorInfo: 이 클래스는 ConstructorInfo로부터 상속되고 CodeMemberMethod에 기초하여 모든 메소드 및 프로퍼티의 구현을 제공한다.
f. AttributeInfo: AttributeInfo 클래스는 타입들에 대한 애트리뷰트에 관한 정보를 보유하는 데 사용된다.
타입 프로바이더 컴포넌트
타입 프로바이더는 타입 시스템에서 최상위 컴포넌트이다. 타입 프로바이더의 인스턴스가 생성될 수 있다. 타입 프로바이더는 타입 트리의 루트 노드를 유지한다. 타입 프로바이더에 어셈블리 참조 및 코드 컴파일 유닛을 부가할 때, 이 컴포넌트는 그들로부터의 모든 타입을 로드하고 이 타입들을 타입 트리로 로드한다.
여기 예에서, 어셈블리로부터 오는 이하의 타입을 가지고 있는 경우,
Art.Bar.Zoo
Art.Peter.Baz
System.String
대응하는 트리 구조는 다음과 같다.
Art
---Bar
---Zoo
---Peter
---Baz
System
---String
각 노드는 그 노드가 가리키는 타입 정의의 리스트를 유지한다. 예를 들어, 상기 시나리오에서 String 노드는 System.String 타입을 포함하게 된다. 타입 정의의 리스트는 각 노드 상에 유지되어 있다. 타입 시스템에 똑같은 타입이 있을 수 있다.
이하는 타입 프로바이더의 public 메소드이다.
AddAssemblyReference 메소드
public void AddAssemblyReference(string path)
이 메소드는 타입 시스템에 어셈블리 참조를 부가하는 데 사용된다. 어셈블리로부터의 모든 타입은 타입 시스템으로 로드된다.
RemoveAssemblyReference 메소드
public void RemoveAssemblyReference(string path)
이 메소드는 타입 시스템으로부터 어셈블리 참조를 제거하는 데 사용된다. 이 어셈블리로부터 타입 트리로 로드된 모든 타입들이 제거된다.
AddCodeCompileUnit 메소드
public void AddCodeCompileUnit(CodeCompileUnit codeCompileUnit)
이 메소드는 타입 시스템으로 CodeCompileUnit을 로드하는 데 사용된다. 이것은 코드 컴파일 유닛 내의 모든 CodeTypeDeclaration을 지나가며 그 각각에 대한 System.Type로부터 상속되는 적절한 DesignTimeType을 생성한다. 그리고, DesignTimeType은 타입 시스템으로 로드된다.
RemoveCodeCompileUnit 메소드
public void RemoveCodeCompileUnit(CodeCompileUnit codeCompileUnit)
이 메소드는 타입 시스템으로부터 CodeCompileUnit을 언로드하는 데 사용된다. CodeCompileUnit으로부터 로드된 모든 타입이 제거된다.
RefreshCodeCompileUnit 메소드
public void RefreshCodeCompileUnit(CodeCompileUnit codeCompileUnit,
CodeCompileUnitRefreshHandler refresher)
이 메소드는 타입 시스템 내의 코드 컴파일 유닛을 리프레쉬하는 데 사용된다. 이 메소드는 타입 시스템으로부터 컴파일 유닛을 제거하고 이어서 이를 타입 시스템에 다시 부가하는 것과 같다.
ITypeProvider 인터페이스
이 서비스는 호스팅 환경의 타입 시스템 내의 타입들을 액세스하여 분석하는 데 사용된다. 이것은 TypeProvider 컴포넌트에 의해 노출되는 인터페이스이다. ITypeProvider는 TypeProvider에 의해 사용자에게 노출된 인터페이스이다. 이는 타입 시스템 내의 타입들을 분석하는 데 사용된다. 이하는 이 인터페이스의 정의이다.
public interface ITypeProvider
{
Type GetType(string name);
Type GetType(string name, bool throwOnError);
Type[] GetType();
StringCollection TypeLoadErrors
{
get;
}
event EventHandler TypesChanged;
event EventHandler TypeLoadErrorChanged;
}
이하는 디자이너에서 TypeProvider를 호스팅하는 데 관여되는 컴포넌트들의 설명이다.
TypeProviderHost 컴포넌트
TypeProviderHost는 프로젝트마다 TypeSystem을 유지하기 위해 사용되는 메인 컴포넌트이다. TypeProviderHost는 프로젝트 시스템 포인터 및 대응하는 TypeProvider를 유지한다. 이는 모든 사용자 코드 파일을 파싱함으로써 하나의 CodeCompileUnit을 TypeSystem으로 푸시한다. 또한, 이는 타입 시스템에 포함된 타입들을 수정할 수 있는 모든 프로젝트 시스템 이벤트를 리스닝한다. 이하는 TypeProviderHost에 의해 행해지는 계층적 작업이다.
1. 사용자 코드 파일을 파싱하고 CodeCompileUnit을 생성함.(FileCodeModel-CodeDOM 계층)
2. 프로젝트 시스템에서의 이벤트를 리스닝하고 타입들을 리프레쉬하기 위해 TypeProvider에 적당한 호출을 함.
여기에 TypeProviderHost가 리스닝하는 이벤트들의 리스트 및 변경에 관한 통지를 하기 위해 그것이 행하는 대응하는 TypeProvider 호출이 있다.
ILangFileEvents: 이들 이벤트는 프로젝트에서의 파일 부가, 제거, 이동, 구축 동작 변경 기타 등등을 위해 추적된다. 이들 이벤트 중 어느 것이 일어나면, 타입 프로바이더는 CodeCompileUnit을 리프레쉬한다.
_dispCodeModelEvents: 이들 이벤트는 새로운 CodeElement가 사용자 코드 파일에 부가될 때마다 비쥬얼 베이직의 파일 코드 모델에 의해 기동된다. 이들 이벤트는 비쥬얼 베이직 프로젝트 시스템만을 위한 것이며, 유사한 이벤트가 C# 프로젝트 시스템에서는 기동되지 않는다.
_dispReferencesEvents: 이들 이벤트는 프로젝트로부터 어셈블리 참조를 부가 또는 제거할 때 기동된다. 어셈블리 참조 부가 이벤트를 가져올 때, 어셈블리는 대응하는 TypeProvider에 부가된다. 어셈블리 참조 제거 이벤트를 가져올 때, 어셈블리 참조는 타입 시스템으로부터 제거된다.
_dispBuildEvents: 빌드 이벤트는 프로젝트가 케이스를 참조하기 위해 추적된다. 참조된 프로젝트가 빌드된 경우에, 이전의 어셈블리가 타입 시스템으로부터 제거되고 새로운 어셈블리가 그로부터 새로운 타입을 로드하기 위해 TypeProvider로 리프레쉬된다.
_IVsRunningDocTableEvents: 실행중인 문서 테이블 이벤트는 여러가지 목적으로 추적된다. 예를 들어, 에디터에서 문서가 변경되었지만 이를 저장하지 않고 닫은 경우, 타입 시스템은 미저장된 상태로 다시 복귀하는데 그 이유는 타입 시스템이 그 파일에서의 변경으로 업데이트되었기 때문이다. 문서가 편집을 위해 에디터에서 열린 경우, 본 발명은 이들 이벤트를 가져와 코드 컴파일 유닛을 리프레쉬하기 위해 IVsTextStreamEvents를 리스닝한다.
_IVsTextStreamEvents: 이들 이벤트는 사용자에 의해 행해진 파일 편집을 리스닝하는 데 사용된다.
ITypeProviderCreator 서비스
ITypeProviderCreator 서비스는 디자이너 패키지 레벨에서 노출된다. 이 서비스를 사용하여 프로젝트에 대한 TypeProvider를 가져올 수 있다. 이하는 ITypeProviderCreator의 인터페이스 정의이다.
public interface ITypeProviderCreator
{
ITypeProvider GetTypeProvider(object obj);
}
이 서비스는 조정 디자이너 패키지에 의해 구현된다. 이 서비스의 구현은 IVsSolution 이벤트를 리스닝하며 솔루션 내의 각 프로젝트에 대한 타입 프로바이더 호스트를 유지한다. 또한, 이 서비스는 누군가 처음으로 이를 요구할 때 프로젝트에 대한 TypeProviderHost를 생성한다. 이 서비스를 사용하여 개발자는 임의의 프로젝트의 TypeSystem에 이를 수 있다. 또한, 솔루션이 닫힐 때, 이 서비스는 시스템 내의 모든 TypeProviderHost를 파기한다. 프로젝트를 닫을 때, 이 서비스는 시스템으로부터 대응하는 TypeProviderHost를 제거한다.
조정 엔진 도구 상자 페이지는 어셈블리에 의해 분류된 도구 상자 엔트리를 바이너리 파일에 버퍼링한다. 기동될 때, 이들 엔트리는 페이지로 로드된다. 도구 상자 내의 아이템들은 도구 상자에 의해 표시되는지는 나타내기 위해 체크되어 있다. 사용자는 브라우즈 버튼을 선택함으로써 서로 다른 어셈블리로부터 새로운 도구 상자 아이템을 부가할 수 있다. 브라우즈 버튼은 사용자가 부가의 도구 상자 아이템을 이로부터 로드할 수 있는 어셈블리를 선택하는 파일 선택 대화 상자를 나타나게 한다. 도구 상자 페이지는 사용자가 선택한 어셈블리를 별도의 애플리케이션 도메인에 로드하고 ToolboxService.GetToolBoxItems를 호출함으로써 그로부터 모든 도구 상자 아이템을 가져온다. 이어서, 이들 아이템은 도메인들에 걸쳐 마샬링되고 도구 상자 페이지로 로드된다. 이것은 사용자 어셈블리가 1차 도메인에 로드되어 로크되지 않도록 행해진다. 이어서, 사용자는 도구 상자에 나타낼 필요가 있는 도구 상자 아이템들을 체크 및 언체크할 수 있다. 대화 상자가 닫힐 때, 도구 상자 페이지는 그의 체크된 상태에 기초하여 도구 상자로부터 아이템들을 부가 및 제거하는 데 ToolboxService.AddTooBoxItems 및 ToolboxService.RemoveToolBoxItems를 사용한다. 바이너리 파일 내의 업데이트된 도구 상자 엔트리들이 도구 상자 페이지가 그 다음에 나타날 때 로드될 수 있도록 도구 상자 페이지는 또한 그 엔트리들을 직렬화한다.
GetType 메소드
Type GetType(string name);
이 메소드는 타입 트리 내의 타입을 분석하는 데 사용된다. 사용자는 스트링을 "A.B.C" 형태로 전달하고, 여기서 A.B는 네임스페이스이고 C는 네임스페이스 내의 타임의 이름이다. 이 메소드는 "널(null)"을 반환하며, 이는 이하의 이름을 갖는 타입이 분석될 수 없음을 의미한다.
GetType 오버로드 메소드
Type GetType(string name, bool throwOnError);
이 메소드는 타입이 발견되지 않을 때 예외를 던지는 것만 차이가 있을 뿐 상기 메소드와 동일하다.
GetTypes 메소드
Type[] GetTypes();
이 메소드는 타입 시스템에 존재하는 모든 타입들을 검색하는 데 사용된다.
TypeLoadErrors 프로퍼티
StringCollection TypeLoadErrors {get;}
타입 프로바이더로 타입들을 로드할 때, 몇가지 문제가 일어날 수 있다. 예를 들어, 이는 어셈블리 참조를 분석하지 못할 수 있다. 이 시나리오에서, TypeLoadErrors 프로퍼티는 모든 타입 로드 에러를 반환한다.
TypeChanged 이벤트
event EventHandler TypesChanged;
새로운 어셈블리 참조 또는 코드 컴파일 유닛이 타입 시스템에 부가될 때마다, 이 이벤트가 기동되어 사용자에게 타입 시스템 내의 타입들이 변경되었음을 알려준다. 이것은 일반 이벤트이며, 이는 어느 타입이 부가 또는 제거되었는지에 관한 어떤 구체적인 정보도 제공하지 않음을 의미한다.
지연 로딩 하부구조
타입 시스템은 지연 로딩(delay-loading) 기능을 갖는다. 어셈블리 참조 및 TypeProvider에 부가된 CodeCompileUnits은 누군가 타입 트리로부터 타입들을 분석할 필요가 있을 때까지는 로드되지 않는다. 따라서 AddAssemblyReference 및 AddCompileUnit 내의 코드는 어셈블리 경로 및 CodeCompileUNit를 캐싱하고 TypesChanged 이벤트를 기동시킨다. 누군가 이들을 요구할 때까지 또한 그러하지 않는 한 어떤 타입도 로드되지 않는다. 이 기술은 타입 시스템의 성능을 개선시킨다. 이 이유로 인해, 타입 로딩이 실패할 때 예외가 던져지지 않는다. 그 대신에, TypeLoadErrors가 기동된다.
이하의 코드 스니펫은 TypeProvider 컴포넌트를 어떻게 생성하는지를 설명한다.
//코드 컴파일 유닛을 생성함
CodeCompileUnit ccu = new CodeCompileUnit();
//네임스페이스를 부가함
CodeNamespace sampleUserCode = new CodeNamespace("SampleUserCode");
ccu.Namespace.Add(sampleUserCode);
CodeTypeDeclaration mySchedule = new CodeTypeDeclaration("MySchedule");
mySchedule.BaseTypes.Add(new
CodeTypeReference("System.Workflow.Runtime.Schedule"));
mySchedule.IsClass = true;
mySchedule.PartialType = PartialType.Partial;
mySchedule.TypeAttributes = TypeAttributes.Public;
sampleUserCode.Types.Add(mySchedule);
//타입 프로바이더를 생성함
TypeProvider typeProvider = new TypeProvider(null);
typeProvider.AddAssemblyReference(Assembly.GetExecutingAssembly().
Location)
typeProvider.AddCodeCompileUnit(ccu);
XomlSerializer 클래스
활동과 연관된 직렬화기 컴포넌트는 XomlSerializer로부터 상속된다. XomlSerializer는 또한 활동들에 대한 디폴트 직렬화기이다. 이는 활동 프로퍼티들을 살펴보고 이들을 직렬화한다. 복합 활동에 있어서, 디폴트 직렬화기 컴포넌트는 CompositeXomlSerializer이고, 이는 프리미티브 Xoml 직렬화기에 부가하여 자식 활동들도 직렬화시킨다.
이 클래스 내의 함수들은 xoml 파일을 직렬화 및 역직렬화하는 데 사용되는 public 함수, 객체의 직렬화를 제어하는 데 사용되는 함수, 및 객체의 역직렬화를 제어하는 데 사용되는 함수로서 추가로 분류될 수 있다.
xoml 파일을 직렬화/역직렬화하는 public 함수들
public object Deserializer(XmlTextReader reader)
XmlTextReader 객체가 주어지면, 이 메소드는 이를 역직렬화하고 객체를 반환한다. XmlTextReader는 xml 엘리먼트를 가리키고 있다. 이것은 xoml 파일을 역직렬화하는 public 메소드이다.
public object Deserializer(IDesignerSerializationManager sm,
XmlTextReader reader)
XmlTextReader 및 IDesignerSerializationManager가 주어지면, 이 메소드는 활동을 역직렬화한다. IDesignerSerializationManager 객체는 객체들에 대한 커스텀 역직렬화기를 제공하고 또한 타입들을 분석하는 데 사용된다.
public void Serialize(object obj, XmlTextWriter writer)
이 메소드는 XmlTextWriter 객체에 대한 첫번째 파라미터에 지정된 객체를 직렬화한다.
public void Serialize(IDesignerSerializationManager sm, object obj,
XmlTextWriter wr);
이 메소드는 객체를 XmlTextWriter 객체로 직렬화한다. 이는 타입 기타 등등을 분석하는 데 사용될 수 있는 부가의 디자이너 직렬화 관리자 객체를 취한다.
객체의 역직렬화
protected object DeserializeObject(IXomlSerializationManager sm,
XmlTextReader rd);
이 메소드는 엘리먼트를 역직렬화하고 객체를 생성한다. 이는 객체의 타입을 분석하는 데 xmlns to CLR 네임스페이스 및 어셈블리 매핑을 사용하고 이어서 타입과 연관된 직렬화기 컴포넌트에 타입의 인스턴스를 생성할 기회를 준다. XomlSerializer의 CreateInstance 메소드는 객체의 인스턴스를 생성하는 데 사용되고, 이는 파생된 클래스들에 의해 오버라이드될 수 있다. XmlTextReader는 엘리먼트 노드를 가리키고 있어야만 하며, 그렇지 않은 경우 이 메소드는 예외를 던진다. 이 메소드는 객체의 인스턴스를 생성한 후에 DeserializeContents를 호출한다.
protected void DeserializeContents(IXomlSerializationManager sm,
object obj, XmlTextReader rd);
이 메소드는 객체의 프로퍼티 및 자식 객체를 역직렬화하는 데 사용된다. 이는 파라미터로서 객체 및 XmlTextReader를 취한다. XmlTextReader는 XmlElement 노드를 가리킨다. 이는 엘리먼트의 모든 애트리뷰트를 지나가며 직렬화기에 대한 DeserializeSimpleProperty()를 호출한다. DeserializeSimpleProperty는 프로퍼티의 커스텀 역직렬화를 하기 위해 오버라이드될 수 있다. 그 후에, 이는 엘리먼트의 모든 자식 엘리먼트를 지나가고 이들을 자식 객체 또는 프로퍼티로서 인식한다. 자식 엘리먼트를 프로퍼티로서 인식하는 경우, 이는 직렬화기에 대한 DeserializeCompoundProperty()를 호출하고 그렇지 않은 경우 자식 엘리먼트를 역직렬화하기 위해 DeserializeObject()를 호출하고 반환된 객체를 메인 객체의 자식으로서 부가한다. 반환된 객체를 자식 객체로서 부가하기 위해, 이는 다른 부모-자식 관계를 구현하기 위해 오버라이드될 수 있는 직렬화기에 대한 AddChild() 메소드를 호출한다.
protected virtual void DeserializeSimpleProperty (IXomlSerializationManager sm, object obj, XmlTextReader rd);
이 메소드는 간단한 프로퍼티를 역직렬화하기 위해 DeserializeContents()에 의해 호출된다. 간단한 프로퍼티는 객체의 일부이고 XmlTextReader는 파라미터로서 전달된다. XmlTextReader는 애트리뷰트를 가리킨다. 애트리뷰트의 이름은 프로퍼티의 이름으로서 취급된다.
protected virtual void DeserializeCompoundProperty
(IXomlSerializationManager sm, object obj, PropertyDescriptor pd,
XmlTextReader rd);
이 메소드는 복합 프로퍼티(compound property)를 역직렬화하기 위해 DeserializeContents()에 의해 호출된다. 이는 객체, 프로퍼티 기술자 및 XmlTextReader를 전달받는다. XmlTextReader는 XmlElement를 가리킨다. 프로퍼티는 읽기 전용 또는 비읽기 전용일 수 있다. 프로퍼티가 읽기 전용인 경우, 그 객체에 대한 DeserializeContents가 객체의 내용을 역직렬화하기 위해 호출되기 때문에 그 객체를 제공하는 프로퍼티에 대한 getter 메소드가 호출된다. 첫번째 자식 엘리먼트는 역직렬화되고 반환된 객체는 프로퍼티 상에 설정된다.
객체의 직렬화
protected void SerializeObject(IXomlSerializationManager s, object o,
XmlTextWriter wr);
이 메소드는 객체를 직렬화하기 위해 호출된다. 이는 직렬화될 필요가 있는 객체 및 직렬화 내용이 기록되어야만 하는 XmlTextWriter를 전달받는다. 이 메소드는 객체에 대한 XmlQualifiedName을 구성하며, 이는 실제로 객체의 타입의 xml 네임스페이스 및 클래스 이름이다. xml 네임스페이스는 객체의 타입의 어셈블리 및 네임스페이스 정보를 사용하여 구성된다. 이는 그 qualified name을 갖는 xml 엘리먼트의 begin을 작성하고 객체의 프로퍼티 및 자식 객체를 추가로 직렬화하기 위해 SerializeContents()를 호출한다. 이는 엘리먼트를 닫기 위해 EndElement를 호출한다.
protected void SerializeContents(IXomlSerializationManager s, object o,
XmlTextWriter w);
이 메소드는 객체의 모든 프로퍼티 및 자식 객체들을 직렬화하는 데 사용된다. 이 메소드는 Xml 엘리먼트를 가리키는 XmlTextWriter 및 객체를 전달받는다. 이는 객체의 직렬화기 컴포넌트를 찾고 객체의 프로퍼티를 가져오기 위해 그에 대해 GetProperties()를 호출한다. 이는 프로퍼티에 대한 DesignerSerializationVisibility 애트리뷰트를 찾으며, Visibly가 Visible로 설정되어 있는 경우, 프로퍼티는 단순 프로퍼티로서 취급되고 SerializeSimpleProperty가 호출되며, Visibility가 Content로 설정되어 있으면, 프로퍼티는 복합 프로퍼티(complex property)로서 취급되고, SerializeCompoundPropery()가 호출되며, 그렇지 않고 Visibility가 Hidden으로 설정되어 있으면, 프로퍼티는 무시된다. 또한, 이는 프로퍼티의 DefaultValue 애트리뷰트에 대한 검사를 하며, 프로퍼티의 DefaultValue가 프로퍼티의 값과 동일한 경우 프로퍼티는 건너뛴다. 이는 모든 자식 객체들을 가져오기 위해 객체의 직렬화기 컴포넌트에 대한 GetChildren()을 호출한다. 이는 이어서 SerializeObject()를 사용하여 모든 자식 객체들을 직렬화한다.
protected virtual void SerializeSimpleProperty
(IXomlSerializationManager sm, object obj, PropertyDescriptor pd,
string parentPropName, XmlTextWriter wr);
이 메소드는 그의 프로퍼티가 직렬화될 필요가 있는 객체, 프로퍼티의 PropertyDescriptor, 및 XmlTextWriter 객체를 전달받는다. 이 함수는 프로퍼티 이름을 애트리뷰트 이름으로 사용하고 프로퍼티 값을 애트리뷰트 값으로 사용함으로써 XmlTextWriter에 xml 애트리뷰트를 기록한다.
protected virtual void SerializeCompoundProperty
(IXomlSerializationManager sm, object obj, PropertyDescriptor pd,
XmlTextWriter wr);
이 메소드는 객체의 복합 프로퍼티를 직렬화하는 데 사용된다. 이는 객체, 프로퍼티 기술자 및 XmlTextWriter 객체를 전달받는다. 프로퍼티가 읽기 전용인 경우, 이는 엘리먼트를 생성하고 프로퍼티의 getter 메소드 호출에 의해 반환된 객체에 대해 SerializeContents()를 호출하고, 그렇지 않은 경우 이는 프로퍼티의 이름을 이름으로 갖는 start 엘리먼트를 기록하고 프로퍼티의 getter 메소드 호출에 의해 반환된 객체에 대해 SerializeObject()를 호출한다.
도움말 함수들
protected virtual IList GetChildren(object obj);
이 메소드는 객체의 자식 객체들을 가져오는 데 사용된다. 보통 객체들은 부모-자식 관계를 기술하는 데 서로 다른 메카니즘을 사용한다. 예를 들어, ICompositeActivity는 Activities 프로퍼티를 사용하여 프로그램적으로 자식 객체를 나타낸다. 다른 직렬화기는 이 프로퍼티를 오버라이드하고 자식 객체의 리스트를 반환할 수 있다. 기본적으로 이는 <null> 값을 반환한다.
protected virtual PropertyDescriptorCollection GetProperties(object obj);
이 메소드는 객체의 프로퍼티들을 가져오는 데 사용된다. 기본적으로, 이 메소드는 true로 설정된 브라우징가능 애트리뷰트 및 Hidden으로 설정되지 않은 DesignerSerialization Visibility 애트리뷰트를 갖는 프로퍼티를 반환한다. 객체 직렬화기 컴포넌트는 이것을 오버라이드하고 반환된 프로퍼티들의 컬렉션을 제어할 수 있다.
protected virtual void AddChild(object obj, object childObj);
이 메소드는 부모 객체의 자식을 부가하는 데 사용된다. 이는 GetChildren()의 역을 행한다. 직렬화기 컴포넌트는 AddChild() 구현의 거동을 제어할 수 있다.
protected virtual object CreateInstance(Type type, XmlTextReader rd);
이 메소드는 그 타입의 인스턴스를 생성하는 데 사용된다. 기본적으로, 이는 객체를 생성하기 위해 Activator.CreatInstance()를 호출한다. 그렇지만, 파생된 클래스는 그의 컴포넌트 타입들의 CreateInstance()에 다른 기술을 사용할 수 있으며, 이들은 또한 XmlTextReader 객체를 사용하여 생성자에 대한 어떤 파라미터를 전달할 수 있다.
CompositeXomlSerializer 클래스
복합 Xoml 직렬화기는 복합 활동들을 직렬화하는 데 사용된다. 이는 자식 활동들을 역직렬화 및 직렬화하기 위한 베이스 클래스로부터 오버라이드된 2개의 메소드를 갖는다.
public override IList GetChildren(object obj)
{
protected override IList GetChildren(object obj)
{
... 인수 검사
ICompositeActivity compositeActivity = obj as ICompositeActivity;
return (IList)compositeActivity.Activities;
}
protected override void AddChild(object obj, object childObj)
{
... 인수 검사
ICompositeActivity compositeActivity = obj as ICompositeActivity;
IActivity activity = childObj as IActivity;
compositeActivity.Activities.Add(activity);
}
}
IXomlSerializationManager 인터페이스
IXomlSerializationManager는 IDesignerSerializationManager 클래스로부터 상속된다. 이는 xml qualified name가 주어지면 활동 타입을 제공하기 위한 부가의 함수들을 제공하며, 그 역도 마찬가지이다. 이하는 IXomlSerializationManager의 인터페이스 정의이다.
public interface IXomlSerializationManager: IDesignerSerializationManager
{
XmlQualifiedName GetXmlQualifiedName(Type type);
Type GetType(XmlQualifiedName xmlQualifiedName);
}
직렬화 에러
Xmol 직렬화기는 IDesignerSerializationManager.ReportError() 메소드를 사용하여 모든 역직렬화 에러를 부가한다. 역직렬화가 에러를 만날 때, 이는 단지 에러 객체를 부가하지만, xml 포맷이 불법일 때까지 또 그렇지 않는 한 역직렬화 프로세스를 중단시키지는 않는다. XomlSerializer는 XomlSerializerException 클래스를 사용하여 역직렬화 에러를 보고한다.
public class XomlSerializationException: Exception
{
private int lineNumber = -1;
private int columnNumber = -1;
public XomlSerializationException(string message, int line, int column)
:base(message)
{
..
}
public XomlSerializationException(string message, Exception
innerException, int line, int column)
{
..
}
public XomlSerializationException(string message)
{
}
public int LineNumber {get;}
public int LinePosition {get;}
}
작업 흐름 componentModel은 또한 웹 서비스 기술 언어(web services description language, WSDL) 포맷에 스케쥴의 직렬화를 제공한다.
조정 엔진 디자이너 아키텍처
조정 엔진 디자이너는 System.ComponentModel 및 System.ComponentModel.Design 네임스페이스에 정의된 클래스를 사용한다. 조정 엔진 디자이너에 의해 사용되는 프레임워크 하부구조 클래스는 DesignSurface, DesignSurfaceManager 및 DesignerLoader이다. 이들 클래스 모두는 System.ComponentModel.Design 네임스페이스의 일부이다.
이하의 테이블은 이 네임스페이스의 설명 및 용도를 간략히 기술한 것이다.
System.Workflow.ComponentModel.Design
네임스페이스 System.Workflow.ComponentModel.Design
설명 이 네임스페이스는 조정 엔진 디자이너에 의해 사용되는 모든 활동 디자이너 및 인터페이스의 구현을 포함한다.
용도 ● 디자이너를 작성하기 위한 베이스 클래스를 포함함 ● 활동 디자이너를 조정 엔진 디자이너에 플러그인하기 위한 인터페이스를 포함함 ● System.ComponentModel.Design 네임스페이스 내의 클래스와 대화할 필요가 있는 플러밍(plumbing)을 포함함 ● 커스텀 활동 디자이너를 작성하는 데 유용한 클래스 ● 활동이 도구 상자에 나타날 수 있도록 커스텀 도구 상자 아이템을 작성하는 데 유용한 클래스
바이너리 System.Workflow.ComponentModel.dll
DesignSurface 및 DesignSurfaceManager
DesignSurface는 디자이너를 표현하며, 디자이너가 필요로 하게 될 일련의 디폴트 서비스를 포함한다. DesignSurfaceManager는 기본적으로 디자이너들이 통신 목적으로 사용할 수 있는 어떤 애플리케이션 레벨 서비스들과 함께 디자이너들의 컬렉션을 제공한다. DesignSurface는 IServiceProvider 인터페이스를 사용하여 다수의 서비스를 노출시킨다. 노출된 마스터 서비스는 IDesignerHost이다. IDesignerHost는 그에 부가된 컴포넌트들의 컬렉션을 유지하고 컴포넌트에 대해 선언된 DesignerAttribute에 기초하여 그에 부가된 모든 컴포넌트들에 대한 디자이너를 생성한다. 디자이너 호스트에 부가된 모든 컴포넌트는 IComponent로부터 상속되어야만 한다. 또한, 그에 부가된 첫번째 컴포넌트는 RootComponent로서 알려져 있다. RootComponent에 대한 디자이너는 IRootDesigner라고 하는 인터페이스를 구현해야만 한다. 이 인터페이스는 GetView()라고 하는 메소드를 가지며, 이 메소드는 루트 컴포넌트에 대한 'Control' 객체를 반환한다. 디자인 화면은 그의 뷰 프로퍼티 구현에서 루트 컴포넌트의 GetView()에 의해 반환된 Control을 반환한다.
조정 엔진 디자이너는 Schedule을 RootComponent로서 사용하고 ServiceRootDesigner를 그의 루트 디자이너로서 사용한다. ServiceRootDesigner에 대한 GetView() 메소드는 'Workflow View' 콘트롤을 반환하고, 이는 호스팅 환경에 의해 직접 호스팅될 수 있다. 예를 들어, 조정 엔진 디자이너가 디자이너에서 호스팅될 때, Workflow View 콘트롤은 IVsWindowPane의 1차 윈도우에 의해 호스팅될 수 있다.
DesignerLoader
DesignerLoader는 객체 그래프의 역직렬화 및 직렬화를 맡고 있는 추상 클래스이다. 디자이너 로더는 생성되고 디자이너에 대한 직렬화된 상태를 포함하는 데이터의 파일 또는 블롭(blob)을 전달받는다. 데이터와 로더 사이의 관계는 로더의 구현에 공개되지 않는다. 디자이너 로더는 로딩 프로세스를 시작하도록 요청받는다. 이는 디자이너를 어떻게 생성하는지를 알고 있는 DesignSurface로의 액세스를 제공하는 IDesignerLoaderHost라고 하는 인터페이스 포인터를 전달받는다. IDesignerLoaderHost는 또한 어떤 공통 유틸리티 함수를 제공한다. 디자이너 로더는 그의 직렬화된 데이터 백(bag of serialized data)을 해석한다. 이는 컴포넌트들의 인스턴스를 생성하고, 이들을 컨테이너에 부가하며, 이들에 대한 프로퍼티를 설정한다. 조정 엔진 디자이너는 DesignerLoader 클래스에 대한 그의 구현으로서 ServiceDesignerLoader를 갖는다.
Xoml 파일로부터 WorkflowView 콘트롤러의 이동
이하는 Xoml을 역직렬화하여 이를 Window Form 콘트롤에 디스플레이하기 위해 이들 하부 구조 조각들 모두를 서로 후크하는 방법을 설명하는 의사 코드이다.
DesignSurface surface = new DesignSurface();
ServiceDesignerLoader loader = new ServiceDesignerLoader(surface);
loader.FilePath = "c:＼＼foo.xoml";
suface.BeginLoad(loader);
Control control = surface.View;
상기 코드는 먼저 DesignSurface를 생성한다. 이어서, 이 코드는 DesignerLoader를 생성하고 그의 생성자에서 surface 객체를 전달한다. 이어서, 이는 로더에 대한 FilePath 프로퍼티를 설정한다. 이제 이 코드는 surface가 지정된 로더를 사용하여 로딩을 시작하도록 요청한다. DesignSurface는 이어서 xoml 파일을 로드하기 위해 DesignerLoader.BeginLoad()를 호출한다. 이것은 활동들이 DesignSurface에 부가되게 하고, 이는 이어서 이들 활동들에 대한 디자이너를 생성하고 활동들 및 그의 디자이너들을 캐싱한다. 부가된 첫번째 컴포넌트는 RootComponent로 알려진 Schedule이고 이는 DesignerAttribute를 사용하여 디자이너로서 연관된 ServiceRootDesigner를 갖는다.
IComponent 및 IComponent.Site
DesignSurface에 부가된 모든 컴포넌트들은 IComponent를 구현한다. DesignSurface는 Site 객체를 생성하고 IComponent.Site 프로퍼티에 대해 그 객체를 설정한다. 컴포넌트가 사이트될 때, 이는 특정 컨테이너에 의해 "소유"된다고 말해진다. 컨테이너는 컴포넌트의 사이트를 통해 컴포넌트에 서비스들을 제공할 수 있고, 컨테이너 자체는 서비스 요청들을 부모 서비스 프로바이더에 델리게이트할 수까지 있다.
IDesigner 및 IActivityDesigner
디자인 화면에 부가된 컴포넌트는 IDesigner 화면을 구현하는, 그와 연관된 디자이너를 갖는다. IDesigner 인터페이스는 프리미티브이며, 제공되는 기능은 모든 컴포넌트들에 공통적이다. 조정 엔진 DesignSurface에서 디자이너를 호스팅하기 위해, 이는 UI 관련 작업, 예를 들어, 드래그/드롭, 마우스, 키보드, 레이아웃, 렌더링 기타 등등의 대부분을 하는 것으로 정의된 인터페이스인 IActivityDesigner를 구현해야만 한다. 디자이너들은 타입 DesignerAttribute의 클래스 레벨 애트리뷰트를 통해 컴포넌트들과 연관되어 있다. 디자이너들은 IContainer 인터페이스의 특별 구현에 의해 생성된다. 컴포넌트가 이 컨테이너에 부가될 때, 컨테이너는 컴포넌트의 메타데이터에서 디자이너 애트리뷰트를 검색한다. 존재하는 경우, 디자이너가 생성되고 초기화된다.
디자인시 서비스 요건
모든 디자이너가 그와 연관되어 있는 IComponent로 초기화된다. IComponent.Site는 디자이너가 외부 세계를 통해 통신할 수 있게 해준다. 컴포넌트가 IDesignerHost에 부가될 때, 디자이너 호스트는 컴포넌트에 대한 사이트를 생성하고 IComponent.Site 프로퍼티에 대해 이를 설정한다. 사이트는 디자이너가 외부 세계 서비스에 액세스할 수 있게 해주는 IServiceProvider로부터 상속된다.
DesignSurface가 미리 제공하는 서비스들
이들은 DesignSurface에 의해 미리 제공되는 표준 서비스들이다.
디자이너에 의해 제공되는 서비스들
대체가능 서비스 이하의 서비스가 기본적으로 제공되지만 protected ServiceContainer 프로퍼티 내의 그의 값을 교체함으로써 대체가능하다.
IExtenderProviderService 컨테이너의 컴포넌트들 컬렉션의 일부가 아닌 객체들이 그 자신의 익스텐더 프로바이더를 제공할 수 있게 해줌
IExtenderListService TypeDescriptor가 익스텐더 프로바이더의 리스트를 가져오는 데 사용됨. 이것은 익스텐더 프로바이더가 컨테이너 외부에서 존재할 수 있게 해줌
ITypeDescriptorFilterService 메타데이터 필터링을 위한 1차 인터페이스. 이것은 디자이너 메타데이터 후크를 제공함.
ISelectionService 디자이너에서 컴포넌트를 선택하는 방법을 제공함.
IReferenceService 객체들이 사이트되어 있지 않은 경우에도, 객체들의 이름을 가져오는 방법을 제공함.
DesignSurface 디자인 화면은 그 자신을 서비스로서 제공함.
DesignerAttributeService 이 서비스는 디자이너에 대한 애트리뷰트 발견을 제공함.
비대체가능 서비스 이하의 서비스가 기본적으로 제공된다.
IComponentChangeService 컴포넌트에 변경이 행해질 때 이벤트를 발생함
IDesignerHost 디자이너에 대한 마스터 인터페이스. 타입, 서비스 및 트랜잭션에 대한 액세스를 제어함
IContainer 각 디자이너는 디자인되고 있는 일련의 컴포넌트를 소유하는 IContainer를 갖는다.
IServiceContainer 이 인터페이스는 IServiceProvider로부터 파생되고 서비스를 디자이너에 부가/제거하는 방법을 제공한다.
호스팅 환경에 의해 미리 제공되는 서비스들
호스팅 환경에 의해 제공되는 서비스들
IFieldBindingService 필드를 생성, 코드 비사이드 파일에 선언된 필드를 열거(enumerate)하는 데 사용됨.
IEventBindingService 메소드를 생성, 코드 비사이드 파일에 선언된 메소드를 열거(enumerate)하는 데 사용됨.
ITypeBindingService 코드 비사이드 파일에 클래스를 생성하는 데 사용됨
IIdentifierCreationService 컴포넌트의 고유 식별자를 보장하는 데 사용됨
IExtUIService 프로퍼티 브라우저에서 프로퍼티들로 네비게이션하는 방법을 제공하고 TaskList에 태스크 아이템들을 부가할 수 있게 해줌
IMenuCommandService 컨텍스트 메뉴, 표준 메뉴 및 디자이너 버브(designer verb)를 디스플레이하는 데 사용됨
IUIService 이 서비스는 호스팅 환경에 모달 대화 상자를 디스플레이, 도구 윈도우를 디스플레이하는 것과 관련된 메소드를 가짐
IToolboxService 이것은 표준 서비스이다.
작업 흐름 뷰
작업 흐름 뷰는 XOML로 기술된 프로세스 흐름의 시각적 표현을 렌더링하는 디자인 화면이다. 작업 흐름 뷰는 활동 디자이너가 렌더링하고 여러가지 윈도즈 생성된 이벤트에 응답하는 데 필요한 풍부한 일련의 UI 기능을 제공한다. 이것 이외에, 작업 흐름 뷰는 어떤 활동들을 수행하기 위해 모든 디자이너들이 필요로 할 수 있는 일련의 공통적인 함수를 제공한다.
public class WorkflowView: UserControl, IDesignerService, IDesignerView, IServiceProvider
System.Object
System.MarshalByRefObject
System.ComponentModel.Component
System.Windows.Forms.Control
System.Windows.Forms.ScrollableControl
System.Windows.Forms.ContainerControl
System.Windows.Forms.UserControl[Visual Basic]
System.OrchestrationEngine.ComponentModel.Design.WorkflowView
UserControl: 사용자 콘트롤은 작업 흐름 뷰가 작업 흐름을 렌더링하기 위해 써드파티 애플리케이션으로 재호스팅될 수 있게 해준다.
IDesignerService: 디자이너 서비스는 활동 디자이너 및 다른 호스트가 여러가지 사용자 인터페이스 기능을 이용하기 위해 그와 상호작용할 수 있게 해주는 기능을 작업 흐름 뷰가 노출시킬 수 있게 해준다.
IDesignerView: 디자이너 뷰 인터페이스는 작업 흐름 뷰 컨테이너가 작업 흐름과 상호 작용할 수 있게 해준다. 이 서비스를 사용하여, 외부 컨테이너는 그의 활성 상태를 작업 흐름 뷰에 전달할 수 있고, 이 뷰는 이들 메시지에 응답하여 그의 UI 상태를 업데이트하고 초기화를 행할 수 있다.
IServiceProvider: 작업 흐름 뷰는 활동 디자이너들에 대한 서비스 프로바이더로서 기능한다. 작업 흐름 뷰를 사용하여, 활동 디자이너는 서비스 컨테이너에 미리 제공된 다른 서비스들로 액세스할 수 있다.
작업 흐름 뷰는 XOML로 기술된 프로세스 흐름의 시각적 표현을 렌더링하는 디자인 화면이다. 작업 흐름 뷰는 활동 디자이너들이 렌더링하고 여러가지 윈도즈 발생된 이벤트들에 응답하는 데 필요한 풍부한 일련의 UI 기능을 제공한다. 이것 이외에, 작업 흐름 뷰는 어떤 활동들을 수행하기 위해 디자이너들에 의해 사용될 수 있는 일련의 공통적인 기능을 제공한다.

Claims (20)

  1. 비지니스 프로세스를 모델링하는 작업 흐름을 작성하는 컴퓨터화된 시스템으로서,
    상기 작업 흐름과 연관된 복수의 활동들을 식별해주는 패키지,
    상기 복수의 활동들 중 하나 이상을 선택하여 상관시키는 인터페이스, 및
    상기 작업 흐름의 영속적 표현을 생성하기 위해 상기 식별된 활동들을 직렬화하는 직렬화기를 포함하는 컴퓨터화된 시스템.
  2. 제1항에 있어서,
    상기 작업 흐름을 작성하는 디자인 애플리케이션 프로그래밍 인터페이스-상기 복수의 활동들 각각은 그와 연관된 컴포넌트 모델을 가지며, 상기 컴포넌트 모델은 그와 연관된 활동의 프로퍼티를 지정함-, 및
    상기 디자인 애플리케이션 프로그래밍 인터페이스를 통해 작성된 상기 작업 흐름을 컴파일하는 컴파일 애플리케이션 프로그래밍 인터페이스를 더 포함하는 컴퓨터화된 시스템.
  3. 제1항 또는 제2항에 있어서,
    상기 지정된 프로퍼티들은 디자인시 거동, 컴파일시 거동, 및 런타임 거동 중 하나 이상을 포함하고,
    상기 복수의 활동들은 사용자 정의된 활동을 포함하며, 상기 사용자 정의된 활동은 하나 이상의 프로퍼티들을 가지며,
    상기 시스템은 상기 프로퍼티들 각각과 연관된 포맷을 검증하는 시맨틱 검사기(semantic checker)를 더 포함하는 컴퓨터화된 시스템.
  4. 제1항 내지 제3항 중 어느 한 항에 있어서,
    상기 인터페이스는 상기 선택된 활동들에 연관된 비지니스 로직을 구현하는 소프트웨어 코드를 수신하고,
    상기 직렬화된 작업 흐름 표현과 상기 소프트웨어 코드를 상기 작업 흐름의 실행가능한 표현으로 컴파일하는 컴파일러, 및
    상기 컴파일러에 의해 생성된 상기 작업 흐름의 상기 실행가능한 표현을 실행하는 런타임 엔진을 더 포함하는 컴퓨터화된 시스템.
  5. 제1항 내지 제4항 중 어느 한 항에 있어서,
    상기 디자인 애플리케이션 프로그래밍 인터페이스는 상기 작업 흐름을 작성하는 수단 및 상기 작업 흐름을 생성하기 위해 상기 활동들 중 하나 이상을 선택하는 수단을 포함하고,
    상기 컴파일 애플리케이션 프로그래밍 인터페이스는,
    상기 작업 흐름의 시각적 외관을 커스터마이즈하는 수단,
    상기 디자인 애플리케이션 프로그래밍 인터페이스를 통해 작성된 상기 작업 흐름을 컴파일하는 수단,
    상기 작업 흐름을 검증하는 수단, 및
    상기 작업 흐름을 직렬화하는 수단 중 하나 이상을 포함하는 것인 컴퓨터화된 시스템.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서,
    상기 작업 흐름 내의 복수의 활동들 각각에 타입을 연관시키는 타입 프로바이더(type provider) 애플리케이션 프로그래밍 인터페이스를 더 포함하고,
    상기 타입 프로바이더 애플리케이션 프로그래밍 인터페이스는 상기 작업 흐름 내의 복수의 활동들 각각에 상기 타입을 연관시키는 수단을 포함하는 것인 컴퓨터화된 시스템.
  7. 제1항 내지 제6항 중 어느 한 항에 있어서,
    상기 작업 흐름 내의 활동들 각각에 연관된 상기 컴포넌트 모델을 표현하는 데이터 구조를 더 포함하고,
    상기 데이터 구조는,
    상기 활동을 시각적으로 표현하기 위한 데이터를 저장하는 이미지 필드,
    상기 활동에 연관된 프로퍼티, 메소드 및 이벤트를 정의하는 메타데이터를 저장하는 하나 이상의 작성시 필드,
    상기 작성시 필드에 저장된 상기 메타데이터를 상기 활동의 선언적 표현으로 전달하기 위한 데이터를 저장하는 직렬화기 필드,
    상기 작성시 필드에 저장된 상기 메타데이터에 연관된 소프트웨어 코드를 저장하는 비지니스 로직 필드, 및
    상기 비지니스 로직 필드에 저장된 상기 소프트웨어 코드를 실행시키기 위한 데이터를 저장하는 실행자 필드를 포함하며,
    상기 시맨틱 검사기는 상기 비지니스 로직에 저장된 상기 소프트웨어 코드를 검증하는 것인 컴퓨터화된 시스템.
  8. 활동들을 포함하고, 비지니스 프로세스를 모델링하는 작업 흐름을 모델링하는 컴퓨터 구현 방법으로서,
    복수의 활동들을 제공하는 단계,
    상기 제공된 활동들 중 사용자가 선택한 것들을 수신하는 단계, 및
    상기 작업 흐름의 영속적 표현을 생성하기 위해 상기 수신된 선택된 것들을 직렬화하는 단계를 포함하는 것인 컴퓨터 구현 방법.
  9. 제8항에 있어서,
    상기 작업 흐름에 연관된 스케쥴을 작성하는 스케쥴 인터페이스를 제공하는 단계,
    상기 스케쥴에 연관된 스코프를 생성하는 스코프 인터페이스를 제공하는 단계,
    하나 이상의 활동들을 선택하는 활동 인터페이스를 제공하는 단계, 및
    상기 생성된 스코프 내에서 실행되기 위해 상기 생성된 스케쥴 내에 상기 작업 흐름을 생성하도록 상기 선택된 활동들을 정렬하는 단계를 더 포함하는 컴퓨터 구현 방법.
  10. 제8항 또는 제9항에 있어서,
    복수의 활동들 중 하나와 연관시키기 위해 사용자로부터 비지니스 로직을 표현하는 소프트웨어 코드를 수신하는 단계,
    상기 소프트웨어 코드를 컴파일하여 하나 이상의 바이너리 파일을 생성하는 단계, 및
    상기 생성된 바이너리 파일을 실행하여 상기 작업 흐름을 수행하는 단계를 더 포함하는 컴퓨터 구현 방법.
  11. 제8항 내지 제10항 중 어느 한 항에 있어서,
    상기 복수의 활동들 각각에 대한 메타데이터를 그와 연관된 컴포넌트 모델로부터 수신하는 메타데이터 인터페이스를 제공하는 단계-상기 수신된 메타데이터는 시맨틱스를 갖음-,
    상기 수신된 메타데이터에 연관된 시맨틱스를 검사함으로써 상기 수신된 메타데이터를 검증하는 검증 인터페이스를 제공하는 단계,
    상기 수신된 메타데이터에 연관된 소프트웨어 코드를 상기 검증의 함수로서 생성하는 코드 생성자 인터페이스를 제공하는 단계, 및
    상기 생성된 소프트웨어 코드를 컴파일하는 코드 컴파일 인터페이스를 제공하는 단계를 더 포함하는 컴퓨터 구현 방법.
  12. 제8항 내지 제11항 중 어느 한 항에 있어서,
    실행가능한 작업 흐름을 생성하기 위해 상기 정렬된 활동들을 컴파일하는 단계, 및
    상기 생성된 스코드 내에서 또한 상기 생성된 스케쥴에 따라 상기 생성된 작업 흐름을 실행하는 단계를 더 포함하는 컴퓨터 구현 방법.
  13. 제8항 내지 제12항 중 어느 한 항에 있어서,
    상기 직렬화된 작업 흐름 표현과 소프트웨어 코드를, 상기 작업 흐름의 실행가능한 표현을 포함하는 단일 어셈블리로 컴파일하는 단계,
    상기 정렬된 활동들 각각에 연관시키기 위해 상기 컴포넌트 모델을 제공하는 단계-상기 컴포넌트 모델은 상기 정렬된 활동들의 프로퍼티를 정의함-, 및
    상기 직렬화된 작업 흐름 표현을 다른 작업 흐름 언어로 변환하는 단계를 더 포함하는 컴퓨터 구현 방법.
  14. 제8항 내지 제13항 중 어느 한 항에 있어서,
    사용자로부터 사용자 정의된 활동을 수신하는 단계-상기 사용자 정의된 활동 은 그와 연관된 하나 이상의 시맨틱스를 갖음-,
    미리 정해진 인터페이스 요건에 부합하는지 알아보기 위해 상기 시맨틱스를 평가하는 단계, 및
    상기 평가의 함수로서 상기 사용자 정의된 활동을 상기 복수의 활동들 중 하나로 제공하는 단계를 더 포함하는 컴퓨터 구현 방법.
  15. 제8항 내지 제14항 중 어느 한 항에 있어서,
    상기 복수의 활동들을 제공하는 단계는
    각각이 디자인시 거동, 컴파일시 거동 및 런타임 거동을 지정하는 그와 연관된 하나 이상의 프로퍼티를 소유하는 상기 복수의 활동들을 제공하는 단계와,
    상기 사용자에게 상기 복수의 활동들을 시각적으로 제공하는 단계 중 하나 이상을 포함하는 컴퓨터 구현 방법.
  16. 제8항 내지 제15항 중 어느 한 항에 있어서,
    상기 선택된 활동들의 계층적 구성을 사용자로부터 수신하는 단계를 더 포함하며,
    상기 수신된 계층적 구성은 이벤트-조건-동작(event-condition-action) 작업 흐름, 구조화된(structured) 작업 흐름, 및 제약-구동(constraint-driven) 작업 흐름 중 하나 이상을 포함하는 컴퓨터 구현 방법.
  17. 활동들을 포함하고, 비지니스 프로세스를 모델링하는, 작업 흐름을 모델링하는 컴퓨터 실행가능 컴포넌트들을 갖는 하나 이상의 컴퓨터 판독가능 매체로서,
    상기 컴퓨터 실행가능 컴포넌트들은,
    복수의 활동들을 제공하는 팔레트 컴포넌트(402),
    상기 팔레트 컴포넌트(402)에 의해 제공된 상기 활동들의 계층적 구성 및 그 중 선택된 것들을 사용자로부터 수신하는 인터페이스 컴포넌트(404), 및
    상기 작업 흐름의 영속적 표현을 생성하기 위해 상기 인터페이스 컴포넌트(404)에 의해 수신된 상기 활동들을 직렬화하는 선언 컴포넌트(406)를 포함하는 컴퓨터 판독가능 매체.
  18. 제17항에 있어서,
    상기 인터페이스 컴포넌트(404)는 상기 복수의 활동들 중 하나에 연관시키기 위해 비지니스 로직을 표현하는 소프트웨어 코드를 사용자로부터 추가로 수신하고,
    상기 컴퓨터 실행가능 컴포넌트들은, 상기 선언 컴포넌트(406)에 의해 직렬화된 상기 작업 흐름 표현과 상기 인터페이스 컴포넌트(404)에 의해 수신된 상기 소프트웨어 코드를 상기 작업 흐름의 실행가능 표현을 포함하는 단일 어셈블리로 컴파일하는 런타임 컴포넌트(408)를 더 포함하는 컴퓨터 판독가능 매체.
  19. 제17항 또는 제18항에 있어서,
    상기 선언 컴포넌트(406)는 또한 검증을 위해 상기 직렬화된 활동들을 확장 가능한 스키마 정의 네임스페이스(extensible schema definition namespace)로 매핑하는 컴퓨터 판독가능 매체.
  20. 제17항 내지 제19항 중 어느 한 항에 있어서,
    애플리케이션 프로그램에서 상기 팔레트 컴포넌트(402), 상기 인터페이스 컴포넌트(404), 및 상기 선언 컴포넌트(406)를 호스팅하는 것을 더 포함하는 컴퓨터 판독가능 매체.
KR1020050074226A 2004-10-01 2005-08-12 작업 흐름 모델을 주시하는 컴퓨터화된 시스템 KR20060087994A (ko)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US61554304P 2004-10-01 2004-10-01
US60/615,543 2004-10-01
US11/047,017 2005-01-31
US11/047,017 US7451432B2 (en) 2004-10-01 2005-01-31 Transformation of componentized and extensible workflow to a declarative format
US11/063,954 US7464366B2 (en) 2004-10-01 2005-02-23 Programming interface for a componentized and extensible workflow model
US11/063,954 2005-02-23

Publications (1)

Publication Number Publication Date
KR20060087994A true KR20060087994A (ko) 2006-08-03

Family

ID=35276066

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020050074226A KR20060087994A (ko) 2004-10-01 2005-08-12 작업 흐름 모델을 주시하는 컴퓨터화된 시스템

Country Status (4)

Country Link
US (1) US7464366B2 (ko)
EP (1) EP1643428A1 (ko)
JP (1) JP4806240B2 (ko)
KR (1) KR20060087994A (ko)

Families Citing this family (176)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7802007B2 (en) 2004-05-19 2010-09-21 Salesforce.Com, Inc. Techniques for providing connections to services in a network environment
US7805324B2 (en) 2004-10-01 2010-09-28 Microsoft Corporation Unified model for authoring and executing flow-based and constraint-based workflows
US7451432B2 (en) * 2004-10-01 2008-11-11 Microsoft Corporation Transformation of componentized and extensible workflow to a declarative format
US9645712B2 (en) 2004-10-01 2017-05-09 Grand Central Communications, Inc. Multiple stakeholders for a single business process
US8170901B2 (en) * 2004-10-01 2012-05-01 Microsoft Corporation Extensible framework for designing workflows
US20060074735A1 (en) * 2004-10-01 2006-04-06 Microsoft Corporation Ink-enabled workflow authoring
US7464366B2 (en) * 2004-10-01 2008-12-09 Microsoft Corporation Programming interface for a componentized and extensible workflow model
US20060074703A1 (en) * 2004-10-04 2006-04-06 Grand Central Communications, Inc. Providing and managing business processes
US8375372B2 (en) * 2005-02-23 2013-02-12 International Business Machines Corporation Business process execution language program simulation
US7793255B1 (en) * 2005-03-01 2010-09-07 Oracle America, Inc. System and method for maintaining alternate object views
US7761848B1 (en) * 2005-03-15 2010-07-20 Open Invention Network, Llc Code generator tool for building software applications with reusable components
US8140373B2 (en) * 2005-04-07 2012-03-20 International Business Machines Corporation Data driven dynamic workflow
US20060253830A1 (en) * 2005-05-06 2006-11-09 Rajanala Arun K Guiding application building using business constraint metadata
US20060288332A1 (en) * 2005-06-21 2006-12-21 Microsoft Corporation Workflow debugger
JP2007025906A (ja) * 2005-07-13 2007-02-01 Konica Minolta Business Technologies Inc インストール支援方法、ワークフロー作成支援方法
US7707152B1 (en) 2005-07-29 2010-04-27 Adobe Systems Incorporated Exposing rich internet application content to search engines
US7949991B1 (en) * 2005-07-29 2011-05-24 Adobe Systems Incorporated Systems and methods for specifying states within imperative code
US7908162B2 (en) * 2005-10-11 2011-03-15 International Business Machines Corporation Method of delegating activity in service oriented architectures using continuations
US8365135B2 (en) * 2005-10-27 2013-01-29 International Business Machines Corporation Computer method and apparatus for connection creation in a software modeling system
JP4957226B2 (ja) * 2005-12-15 2012-06-20 富士通セミコンダクター株式会社 製品製造に係る品質改善を支援する情報処理端末及び品質改善支援サーバ
US8849691B2 (en) 2005-12-29 2014-09-30 Microsoft Corporation Modeling user input and interaction in workflow based applications
US8561048B2 (en) * 2005-12-29 2013-10-15 Sap Ag Late and dynamic binding of pattern components
EP1818813A1 (en) * 2006-02-02 2007-08-15 Research In Motion Limited System and method and apparatus for using UML tools for defining web service bound component applications
US8024405B2 (en) * 2006-03-30 2011-09-20 Microsoft Corporation Declarative model for concurrency-control across lightweight threads
US8069439B2 (en) * 2006-03-30 2011-11-29 Microsoft Corporation Framework for modeling continuations in workflows
US7739135B2 (en) * 2006-03-30 2010-06-15 Microsoft Corporation Asynchronous fault handling in process-centric programs
US20070239505A1 (en) * 2006-03-30 2007-10-11 Microsoft Corporation Abstract execution model for a continuation-based meta-runtime
US20070239498A1 (en) * 2006-03-30 2007-10-11 Microsoft Corporation Framework for modeling cancellation for process-centric programs
US7945891B2 (en) * 2006-04-12 2011-05-17 Microsoft Corporation Time business process validations within data context
US20070244910A1 (en) * 2006-04-12 2007-10-18 Microsoft Corporation Business process meta-model
US8396736B2 (en) * 2006-04-21 2013-03-12 Process Assets, Llc Systems and methods for providing documentation having succinct communication with scalability
US8181150B2 (en) * 2006-05-12 2012-05-15 The Mathworks, Inc. System and method for synchronized workflow management
US8111260B2 (en) * 2006-06-28 2012-02-07 Microsoft Corporation Fast reconfiguration of graphics pipeline state
US8095923B2 (en) * 2006-06-29 2012-01-10 Augusta Systems, Inc. System and method for deploying and managing intelligent nodes in a distributed network
US8015547B2 (en) * 2006-06-29 2011-09-06 Augusta Systems, Inc. Reconfigurable, hierarchical component-based architecture and framework and methods for rapidly developing sensor device-enabling software applications
US20080005721A1 (en) * 2006-06-29 2008-01-03 Augusta Systems, Inc. Method and System for Rapidly Developing Sensor-Enabled Software Applications
US8954947B2 (en) * 2006-06-29 2015-02-10 Microsoft Corporation Fast variable validation for state management of a graphics pipeline
US7735060B2 (en) * 2006-06-29 2010-06-08 Augusta Systems, Inc. Method and system for rapidly developing and deploying sensor-enabled software applications
US7685604B2 (en) * 2006-06-29 2010-03-23 International Business Machines Corporation Business process execution language (BPEL) application generator for legacy interfaces
US8332751B2 (en) 2006-11-14 2012-12-11 Microsoft Corporation Removal of redundant information from electronic documents
WO2008067307A2 (en) * 2006-11-27 2008-06-05 Sourcecode Technology Holding, Inc. Methods and apparatus for generating workflow steps using gestures
US20080141230A1 (en) * 2006-12-06 2008-06-12 Microsoft Corporation Scope-Constrained Specification Of Features In A Programming Language
EP1933242A1 (en) * 2006-12-11 2008-06-18 Sitecore A/S A method for ensuring internet content compliance
US20080162505A1 (en) * 2006-12-29 2008-07-03 Hill Charles R Context browser based navigation of pivotally related information for a document
TWI328191B (en) * 2007-01-24 2010-08-01 Ind Tech Res Inst Method and apparatus for inspecting radio frequency identification tag
US7743076B2 (en) * 2007-01-26 2010-06-22 Microsoft Corporation Extensible action sequences coordinating independently created components
US8850414B2 (en) * 2007-02-02 2014-09-30 Microsoft Corporation Direct access of language metadata
US20080195448A1 (en) * 2007-02-09 2008-08-14 May Darrell R Method Of Processing Calendar Events, And Associated Handheld Electronic Device
US20080215405A1 (en) * 2007-03-01 2008-09-04 Microsoft Corporation Component based applications running in a common shell
US8731998B2 (en) * 2007-03-01 2014-05-20 Sap Ag Three dimensional visual representation for identifying problems in monitored model oriented business processes
US20090006154A1 (en) 2007-06-29 2009-01-01 Microsoft Corporation Declarative workflow designer
US20090063217A1 (en) * 2007-08-31 2009-03-05 Sap Ag Multi-staged and multi-viewpoint choreography modeling
US7827127B2 (en) * 2007-10-26 2010-11-02 Microsoft Corporation Data scoping and data flow in a continuation based runtime
US20090112667A1 (en) * 2007-10-31 2009-04-30 Ken Blackwell Automated Business Process Model Discovery
US8825189B2 (en) * 2007-11-13 2014-09-02 Fisher Rosemount Systems, Inc. Methods and apparatus to execute an auxiliary recipe and a batch recipe associated with a process control system
US8150541B2 (en) 2007-11-13 2012-04-03 Fisher-Rosemount Systems, Inc. Methods and apparatus to modify a recipe process flow associated with a process control system during recipe execution
US8397207B2 (en) * 2007-11-26 2013-03-12 Microsoft Corporation Logical structure design surface
US9547841B2 (en) * 2007-12-21 2017-01-17 International Business Machines Corporation Deriving overlay information from a user input for a base message schema associated with a node in a message flow
US8555206B2 (en) * 2007-12-21 2013-10-08 Fisher-Rosemount Systems, Inc. Methods and apparatus to present recipe progress status information
US20090171730A1 (en) * 2007-12-28 2009-07-02 International Business Machines Corporation Non-disruptively changing scope of computer business applications based on detected changes in topology
US8868441B2 (en) * 2007-12-28 2014-10-21 International Business Machines Corporation Non-disruptively changing a computing environment
US8341014B2 (en) 2007-12-28 2012-12-25 International Business Machines Corporation Recovery segments for computer business applications
US9558459B2 (en) * 2007-12-28 2017-01-31 International Business Machines Corporation Dynamic selection of actions in an information technology environment
US8447859B2 (en) * 2007-12-28 2013-05-21 International Business Machines Corporation Adaptive business resiliency computer system for information technology environments
US8990810B2 (en) 2007-12-28 2015-03-24 International Business Machines Corporation Projecting an effect, using a pairing construct, of execution of a proposed action on a computing environment
US8326910B2 (en) * 2007-12-28 2012-12-04 International Business Machines Corporation Programmatic validation in an information technology environment
US20090171708A1 (en) * 2007-12-28 2009-07-02 International Business Machines Corporation Using templates in a computing environment
US8763006B2 (en) * 2007-12-28 2014-06-24 International Business Machines Corporation Dynamic generation of processes in computing environments
US8751283B2 (en) * 2007-12-28 2014-06-10 International Business Machines Corporation Defining and using templates in configuring information technology environments
US8682705B2 (en) * 2007-12-28 2014-03-25 International Business Machines Corporation Information technology management based on computer dynamically adjusted discrete phases of event correlation
US8346931B2 (en) * 2007-12-28 2013-01-01 International Business Machines Corporation Conditional computer runtime control of an information technology environment based on pairing constructs
US8677174B2 (en) * 2007-12-28 2014-03-18 International Business Machines Corporation Management of runtime events in a computer environment using a containment region
US8375244B2 (en) 2007-12-28 2013-02-12 International Business Machines Corporation Managing processing of a computing environment during failures of the environment
US8782662B2 (en) * 2007-12-28 2014-07-15 International Business Machines Corporation Adaptive computer sequencing of actions
US8365185B2 (en) 2007-12-28 2013-01-29 International Business Machines Corporation Preventing execution of processes responsive to changes in the environment
US20090172669A1 (en) * 2007-12-28 2009-07-02 International Business Machines Corporation Use of redundancy groups in runtime computer management of business applications
US8826077B2 (en) 2007-12-28 2014-09-02 International Business Machines Corporation Defining a computer recovery process that matches the scope of outage including determining a root cause and performing escalated recovery operations
US8352906B2 (en) * 2007-12-28 2013-01-08 Cadence Design Systems, Inc. Method, system, and computer program product for implementing external domain independent modeling framework in a system design
US20090235282A1 (en) * 2008-03-12 2009-09-17 Microsoft Corporation Application remote control
US8438539B2 (en) * 2008-04-11 2013-05-07 International Business Machines Corporation Using a menu slideshow framework for generating a custom menu-driven slideshow containing definable content
US8161492B2 (en) * 2008-04-15 2012-04-17 Microsoft Corporation Continuation based runtimes in transactions
EP2413656B1 (en) 2008-04-28 2017-01-04 Fujitsu Limited Re-establishing connection between a wireless terminal and a wireless base station
US8788460B2 (en) * 2008-06-12 2014-07-22 Microsoft Corporation Exploring attached and unattached content databases
US8327332B2 (en) 2008-09-02 2012-12-04 Microsoft Corporation Seamless debugging among different application views
US9354847B2 (en) 2008-12-29 2016-05-31 Microsoft Technology Licensing, Llc Interface infrastructure for a continuation based runtime
US8656346B2 (en) * 2009-02-18 2014-02-18 Microsoft Corporation Converting command units into workflow activities
US8683432B2 (en) * 2009-03-20 2014-03-25 Microsoft Corporation Providing execution context in continuation based runtimes
US20100241990A1 (en) * 2009-03-23 2010-09-23 Microsoft Corporation Re-usable declarative workflow templates
US20100251155A1 (en) * 2009-03-25 2010-09-30 Microsoft Corporation Placeholder activities and in-lining of code editors in workflow designer
SG166017A1 (en) * 2009-04-15 2010-11-29 Yokogawa Electric Corp Apparatus and method for configuring a workflow
US20100293538A1 (en) * 2009-05-15 2010-11-18 Microsoft Corporation Dynamic program updating in a continuation based runtime
US20100299170A1 (en) * 2009-05-19 2010-11-25 Microsoft Corporation Stages, Phases in a Project Workflow
US8307368B2 (en) * 2009-05-26 2012-11-06 Microsoft Corporation Locality-based scheduling in continuation-based runtimes
JP4861452B2 (ja) 2009-05-29 2012-01-25 シャープ株式会社 文書処理自動化システム及び画像形成装置
US8561015B2 (en) * 2009-06-15 2013-10-15 Microsoft Corporation Source code semantic zoom and spatial layout
US8812796B2 (en) 2009-06-26 2014-08-19 Microsoft Corporation Private memory regions and coherence optimizations
US8413150B2 (en) * 2009-07-31 2013-04-02 Sap Ag Systems and methods for data aware workflow change management
US8707158B2 (en) * 2009-08-05 2014-04-22 Microsoft Corporation Customizing a form in a model-based system
US8635331B2 (en) * 2009-08-05 2014-01-21 Microsoft Corporation Distributed workflow framework
US8122292B2 (en) * 2009-08-19 2012-02-21 Oracle International Corporation Debugging of business flows deployed in production servers
JP5232748B2 (ja) * 2009-09-17 2013-07-10 東芝テック株式会社 ワークフロー表示支援装置及びワークフロー表示プログラム
US9112724B2 (en) * 2009-12-01 2015-08-18 Cisco Technology, Inc. Minimum disruption MST reconfiguration (MDMR)
US9122461B2 (en) * 2009-12-11 2015-09-01 Microsoft Technology Licensing, Llc Method and system for iteratively partitioning and validating program trees into environments at visibility space granularity
US8402218B2 (en) * 2009-12-15 2013-03-19 Microsoft Corporation Efficient garbage collection and exception handling in a hardware accelerated transactional memory system
US9141345B2 (en) 2010-01-27 2015-09-22 Microsoft Technology Licensing, Llc Simplified user controls for authoring workflows
US9317407B2 (en) * 2010-03-19 2016-04-19 Novell, Inc. Techniques for validating services for deployment in an intelligent workload management system
US10114678B2 (en) * 2010-03-19 2018-10-30 Micro Focus Software Inc. Techniques for managing service definitions in an intelligent workload management system
CN103460228A (zh) * 2010-04-08 2013-12-18 敏捷尖端公司 用以改良商业流程管理系统的方法及设备
US8429622B2 (en) 2010-04-15 2013-04-23 Oracle International Corporation Business process debugger with parallel-step debug operation
US20110283204A1 (en) * 2010-05-12 2011-11-17 Microsoft Corporation Pasting Various Data into a Programming Environment
US9589240B2 (en) * 2010-05-14 2017-03-07 Oracle International Corporation System and method for flexible chaining of distinct workflow task instances in a business process execution language workflow
US8819055B2 (en) 2010-05-14 2014-08-26 Oracle International Corporation System and method for logical people groups
US9852382B2 (en) 2010-05-14 2017-12-26 Oracle International Corporation Dynamic human workflow task assignment using business rules
US9741006B2 (en) 2010-05-14 2017-08-22 Oracle International Corporation System and method for providing complex access control in workflows
US8621421B2 (en) 2010-06-10 2013-12-31 Microsoft Corporation Workflow visualization
US20120023396A1 (en) * 2010-07-26 2012-01-26 Nicholas Wright Miller Method, apparatus, and storage media for parsing input strings
EP2420962A1 (en) * 2010-08-16 2012-02-22 Tata Consultancy Services Ltd. Efficient system for realizing business process families using model-driven techniques
US9069583B2 (en) * 2010-09-30 2015-06-30 Microsoft Technology Licensing, Llc Designer extensibility
US8645913B2 (en) * 2010-12-21 2014-02-04 Sap Ag Web-service based generation of business objects
US8538793B2 (en) * 2011-02-17 2013-09-17 Infosys Limited System and method for managing real-time batch workflows
US20130110730A1 (en) * 2011-10-28 2013-05-02 International Business Machines Corporation Integration of computerized project planning and project diagramming
US8954475B2 (en) 2011-11-10 2015-02-10 Microsoft Technology Licensing, Llc Deep cloning of objects using binary format
US9536264B2 (en) 2011-11-14 2017-01-03 Microsoft Technology Licensing, Llc Host agnostic messaging in a continuation based runtime
US20130139164A1 (en) * 2011-11-28 2013-05-30 Sap Ag Business Process Optimization
US9064220B2 (en) 2011-12-14 2015-06-23 Sap Se Linear visualization for overview, status display, and navigation along business scenario instances
US9070097B2 (en) 2011-12-14 2015-06-30 Sap Se Seamless morphing from scenario model to system-based instance visualization
US9355375B2 (en) 2011-12-14 2016-05-31 Holger Knospe Launch of target user interface features based on specific business process instances
US9081472B2 (en) 2011-12-14 2015-07-14 Sap Se Dynamic enhancement of context matching rules for business scenario models
US9286584B2 (en) 2011-12-14 2016-03-15 Sap Se Visualizing business processes or scenarios in a business software model using transit maps
US20130159063A1 (en) * 2011-12-14 2013-06-20 Joachim Fessler Process-based user authorization management
US20130159047A1 (en) * 2011-12-14 2013-06-20 Jochen Mayerle Dynamic business scenario key performance indicator definitions, real time calculations, and analysis
US9020883B2 (en) 2012-02-22 2015-04-28 Oracle International Corporation System and method to provide BPEL support for correlation aggregation
CN102707944A (zh) * 2012-04-13 2012-10-03 华为技术有限公司 用户界面的生成显示方法及用户界面设备
US10146510B2 (en) * 2012-07-02 2018-12-04 Salesforce.Com, Inc. Custom metametadata with packagable records
US10311107B2 (en) 2012-07-02 2019-06-04 Salesforce.Com, Inc. Techniques and architectures for providing references to custom metametadata in declarative validations
US10817819B2 (en) * 2012-07-16 2020-10-27 Micro Focus Llc Workflow compilation
CN102831497A (zh) * 2012-07-26 2012-12-19 深圳市融创天下科技股份有限公司 一种创建工作流程的方法、系统和终端设备
US10346776B2 (en) * 2012-10-24 2019-07-09 International Business Machines Corporation Project plan generation from an information architecture model
US9530115B2 (en) 2013-01-07 2016-12-27 Sap Se Message evaluation tool
JP2014182411A (ja) * 2013-03-15 2014-09-29 Ricoh Co Ltd 情報処理装置、ネットワークシステム、処理実行方法及び処理実行プログラム
US10037197B2 (en) 2013-03-15 2018-07-31 Oracle International Corporation Flexible microinstruction system for constructing microprograms which execute tasks, gateways, and events of BPMN models
US9508051B2 (en) * 2013-03-15 2016-11-29 Bmc Software, Inc. Business development configuration
US9600792B2 (en) * 2013-04-11 2017-03-21 Siemens Aktiengesellschaft Method and apparatus for generating an engineering workflow
CN104252391B (zh) * 2013-06-28 2017-09-12 国际商业机器公司 用于在分布式计算系统中管理多个作业的方法和装置
US9483307B2 (en) * 2013-09-04 2016-11-01 Swiftpage Act! Llc Asynchronous, interactive task workflows
KR20150033453A (ko) * 2013-09-24 2015-04-01 주식회사 엘지씨엔에스 빅데이터 처리 방법, 이를 수행하는 빅데이터 처리 장치 및 이를 저장하는 기록매체
US10216903B2 (en) * 2013-11-21 2019-02-26 Oracle International Corporation Medical adherence tracking framework
US10282396B2 (en) * 2014-05-07 2019-05-07 International Business Machines Corporation Markup language namespace declaration resolution and preservation
US9582254B2 (en) * 2014-05-22 2017-02-28 Oracle International Corporation Generating runtime components
US9696971B1 (en) * 2014-12-08 2017-07-04 Ca, Inc. Method and apparatus for generating and packaging integration workflow activities
CN105989204B (zh) * 2015-02-12 2019-04-05 北京仿真中心 一种基于克隆技术的模型组件信息流构建方法及系统
US9311083B1 (en) * 2015-04-10 2016-04-12 CypressX LLC Machine interface configuration system for coerced inconsistencies on different machine platforms
US20160321285A1 (en) * 2015-05-02 2016-11-03 Mohammad Faraz RASHID Method for organizing and distributing data
US9311144B1 (en) * 2015-05-08 2016-04-12 Xactly Corporation Processing virtual transactions of a workflow in atomic manner in a workflow management computer system
CN108369514B (zh) * 2015-07-31 2023-01-06 慧咨环球有限公司 用于可执行内容和可执行内容流创建的系统和方法
US9898261B1 (en) 2015-09-30 2018-02-20 Open Text Corporation Method and system for configuring processes of software applications using activity fragments
US10203939B2 (en) * 2015-10-30 2019-02-12 Sap Se Method and system for parameter model framework
US10528327B2 (en) * 2015-11-23 2020-01-07 Microsoft Technology Licensing Llc Workflow development system with ease-of-use features
US9652203B1 (en) * 2015-11-24 2017-05-16 Corpa Inc. Application development framework using configurable data types
US10592082B2 (en) 2015-11-24 2020-03-17 Microsoft Technology Licensing, Llc Parallel front end application and workflow development
US10339032B2 (en) 2016-03-29 2019-07-02 Microsoft Technology Licensing, LLD System for monitoring and reporting performance and correctness issues across design, compile and runtime
US10423393B2 (en) 2016-04-28 2019-09-24 Microsoft Technology Licensing, Llc Intelligent flow designer
US10635160B2 (en) * 2016-05-16 2020-04-28 Tibco Software Inc. Stepback mechanism to develop and diagnose process applications
JP2017157224A (ja) * 2017-04-24 2017-09-07 株式会社リコー 情報処理装置及びネットワークシステム
US10839011B2 (en) * 2018-04-18 2020-11-17 International Business Machines Corporation Application programing interface document generator
US10809987B2 (en) 2018-08-14 2020-10-20 Hyperblox Inc. Software acceleration platform for supporting decomposed, on-demand network services
US11119864B2 (en) 2018-10-02 2021-09-14 International Business Machines Corporation Achieving activity centric computing using portable containers
US11790224B2 (en) * 2018-10-20 2023-10-17 Oracle International Corporation Machine learning from the integration flow metadata
JP6739744B2 (ja) * 2018-11-05 2020-08-12 株式会社Ｚｅｎｐｏｒｔ 物流管理装置、物流管理方法及び物流管理プログラム
US11429514B2 (en) * 2019-12-06 2022-08-30 Cerner Innovation, Inc. Testing as a service
US11237895B2 (en) 2020-02-26 2022-02-01 Capital One Services, Llc System and method for managing software error resolution
US11348019B2 (en) 2020-08-06 2022-05-31 Cisco Technology, Inc. Advanced workflow based self-serve automation system
US20220129818A1 (en) * 2020-10-22 2022-04-28 Open Text Corporation Lifecycle fragment and dynamic discovery of lifecycle fragment at runtime
US20220327006A1 (en) * 2021-04-09 2022-10-13 Nb Ventures, Inc. Dba Gep Process orchestration in enterprise application of codeless platform
US20230083891A1 (en) * 2021-09-13 2023-03-16 DataRobot, Inc. Methods and systems for integrated design and execution of machine learning models
CN114004553B (zh) * 2021-11-02 2023-11-24 广州新科佳都科技有限公司 一种预案可视化生成系统、服务端以及客户端

Family Cites Families (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0697652A1 (en) 1994-08-16 1996-02-21 International Business Machines Corporation Method for re-executing a process on a computer system for fault correction
US5634127A (en) 1994-11-30 1997-05-27 International Business Machines Corporation Methods and apparatus for implementing a message driven processor in a client-server environment
US5774661A (en) 1995-04-18 1998-06-30 Network Imaging Corporation Rule engine interface for a visual workflow builder
US5930512A (en) 1996-10-18 1999-07-27 International Business Machines Corporation Method and apparatus for building and running workflow process models using a hypertext markup language
US6016394A (en) * 1997-09-17 2000-01-18 Tenfold Corporation Method and system for database application software creation requiring minimal programming
US6621505B1 (en) 1997-09-30 2003-09-16 Journee Software Corp. Dynamic process-based enterprise computing system and method
US6225998B1 (en) 1997-12-02 2001-05-01 Aspect Communications Visual design of workflows for transaction processing
US6115646A (en) 1997-12-18 2000-09-05 Nortel Networks Limited Dynamic and generic process automation system
US6430538B1 (en) 1998-04-30 2002-08-06 Enterworks Workflow management system, method and medium with personal subflows
US6567783B1 (en) 1998-06-05 2003-05-20 I2 Technologies Us, Inc. Communication across one or more enterprise boundaries regarding the occurrence of a workflow event
US6397192B1 (en) 1998-06-05 2002-05-28 I2 Technologies Us, Inc. Synchronizing one or more workflows using one or more synchronization-join activities that include synchronization logic
JP2003528358A (ja) 1998-08-24 2003-09-24 富士通株式会社 ワークフローシステムおよび方法
US6606740B1 (en) 1998-10-05 2003-08-12 American Management Systems, Inc. Development framework for case and workflow systems
US7133833B1 (en) 1998-10-27 2006-11-07 Netscape Communications Corporation Lightweight directory access protocol workflow management system
US7233952B1 (en) 1999-01-15 2007-06-19 Hon Hai Precision Industry, Ltd. Apparatus for visualizing information in a data warehousing environment
US6411961B1 (en) 1999-01-15 2002-06-25 Metaedge Corporation Apparatus for providing a reverse star schema data model
WO2000054202A2 (en) 1999-03-11 2000-09-14 Paysys International, Inc. Methods and systems for developing applications and for interfacing with users
US6405364B1 (en) * 1999-08-31 2002-06-11 Accenture Llp Building techniques in a development architecture framework
CA2281331A1 (en) 1999-09-03 2001-03-03 Cognos Incorporated Database management system
US7020697B1 (en) * 1999-10-01 2006-03-28 Accenture Llp Architectures for netcentric computing systems
US6898790B1 (en) 1999-12-06 2005-05-24 International Business Machines Corporation Mapping actions to tasks within customer service processing systems
AU2001242320A1 (en) * 2000-03-30 2001-10-15 Ideogramic Aps Method for gesture based modeling
US6768986B2 (en) * 2000-04-03 2004-07-27 Business Objects, S.A. Mapping of an RDBMS schema onto a multidimensional data model
US6964034B1 (en) * 2000-04-20 2005-11-08 International Business Machines Corporation Application development server and a mechanism for providing different views into the same constructs within a strongly encapsulated environment
US6918053B1 (en) 2000-04-28 2005-07-12 Microsoft Corporation Compensation framework for long running transactions
US6845507B2 (en) 2000-05-18 2005-01-18 Ss & C Technologies, Inc. Method and system for straight through processing
US6708186B1 (en) 2000-08-14 2004-03-16 Oracle International Corporation Aggregating and manipulating dictionary metadata in a database system
US20020032692A1 (en) 2000-09-08 2002-03-14 Atsuhito Suzuki Workflow management method and workflow management system of controlling workflow process
AU2002211405A1 (en) 2000-10-02 2002-04-15 International Projects Consultancy Services, Inc. Object-based workflow system and method
US6604104B1 (en) 2000-10-02 2003-08-05 Sbi Scient Inc. System and process for managing data within an operational data store
US6954747B1 (en) 2000-11-14 2005-10-11 Microsoft Corporation Methods for comparing versions of a program
US7174534B2 (en) 2001-01-22 2007-02-06 Symbol Technologies, Inc. Efficient system and method for running and analyzing multi-channel, multi-modal applications
US7240324B2 (en) 2001-02-28 2007-07-03 Hewlett-Packard Development Company, L.P. Event-based scheduling method and system for workflow activities
US7120896B2 (en) 2001-10-31 2006-10-10 Vitria Technology, Inc. Integrated business process modeling environment and models created thereby
US20020188644A1 (en) 2001-06-08 2002-12-12 Verano Workflow automated task component manager
US7069536B2 (en) 2001-06-28 2006-06-27 International Business Machines Corporation Method, system, and program for executing a workflow
US6898604B1 (en) 2001-06-29 2005-05-24 Microsoft Corporation XML serialization and deserialization
US7222334B2 (en) * 2001-07-24 2007-05-22 Hewlett-Packard Development Comapny, L.P. Modeling tool for electronic services and associated methods and businesses
AU2002355575A1 (en) 2001-08-08 2003-02-24 Trivium Systems Inc. Scalable messaging platform for the integration of business software components
US6985939B2 (en) * 2001-09-19 2006-01-10 International Business Machines Corporation Building distributed software services as aggregations of other services
US6895573B2 (en) 2001-10-26 2005-05-17 Resultmaker A/S Method for generating a workflow on a computer, and a computer system adapted for performing the method
US20030177046A1 (en) 2001-12-03 2003-09-18 John Socha-Leialoha Method and system for reusing components
US7089287B2 (en) 2002-01-16 2006-08-08 Xerox Corporation Message-based system having embedded information management capabilities
US7441197B2 (en) 2002-02-26 2008-10-21 Global Asset Protection Services, Llc Risk management information interface system and associated methods
US20030233374A1 (en) 2002-03-14 2003-12-18 Ulrich Spinola Dynamic workflow process
DE10215653A1 (de) 2002-04-09 2003-11-06 Bernhard Voslamber Verfahren und Anordung zur automatischen Erzeugung von Programmcodeabschnitten sowie ein entsprechendes Computerprogrammprodukt und ein entsprechendes computerlesbares Speichermedium
US7778717B2 (en) 2002-04-15 2010-08-17 Invensys Systems, Inc. Component object model communication method for a control system
US7424717B2 (en) 2002-05-01 2008-09-09 Bea Systems, Inc. Systems and methods for business process plug-in development
US7272816B2 (en) * 2002-07-31 2007-09-18 Sap Aktiengesellschaft Transformations between private and shared workflows
US20040078105A1 (en) 2002-09-03 2004-04-22 Charles Moon System and method for workflow process management
US7437703B2 (en) 2002-10-25 2008-10-14 Sap Ag Enterprise multi-agent software system with services able to call multiple engines and scheduling capability
US20040148213A1 (en) 2002-11-25 2004-07-29 Microsoft Corporation Automated workflow constraints
US7272820B2 (en) 2002-12-12 2007-09-18 Extrapoles Pty Limited Graphical development of fully executable transactional workflow applications with adaptive high-performance capacity
US7168077B2 (en) 2003-01-31 2007-01-23 Handysoft Corporation System and method of executing and controlling workflow processes
US20040162741A1 (en) 2003-02-07 2004-08-19 David Flaxer Method and apparatus for product lifecycle management in a distributed environment enabled by dynamic business process composition and execution by rule inference
US7114146B2 (en) 2003-05-02 2006-09-26 International Business Machines Corporation System and method of dynamic service composition for business process outsourcing
US20050066002A1 (en) 2003-07-31 2005-03-24 Arnold Teres Workflow compatible healthcare information message communication system
US7693973B2 (en) 2003-08-28 2010-04-06 International Business Machines Corporation Pluggable state meta-data processors based on meta information modeling in a service oriented architecture
CA2442796A1 (en) 2003-09-26 2005-03-26 Ibm Canada Limited - Ibm Canada Limitee Binding a workflow engine to a data model
CA2443447A1 (en) 2003-09-30 2005-03-30 Ibm Canada Limited-Ibm Canada Limitee System and method for conversion between graph-based representations and structural text-based representations of business processes
US7093207B1 (en) 2003-11-17 2006-08-15 Kla-Tencor Technologies Corporation Data analysis flow engine
US7650344B2 (en) 2004-02-09 2010-01-19 Coremetrics, Inc. System and method of managing software product-line customizations
US7359909B2 (en) 2004-03-23 2008-04-15 International Business Machines Corporation Generating an information catalog for a business model
US20060053120A1 (en) 2004-09-07 2006-03-09 Hong Kong Applied Science And Technology Research Institute Co., Ltd. Web service registry and method of operation
US7631291B2 (en) 2004-10-01 2009-12-08 Microsoft Corporation Declarative representation for an extensible workflow model
US7464366B2 (en) * 2004-10-01 2008-12-09 Microsoft Corporation Programming interface for a componentized and extensible workflow model
US7433887B2 (en) 2004-12-29 2008-10-07 Microsoft Corporation Method and apparatus for metadata driven business logic processing
US7493594B2 (en) 2005-03-14 2009-02-17 Research In Motion System and method for designing component based applications
US20060241954A1 (en) 2005-04-22 2006-10-26 International Business Machines Corporation Method and system for adaptive action management for business solutions
US7983943B2 (en) 2005-05-27 2011-07-19 Xerox Corporation Method and system for workflow process node synchronization

Also Published As

Publication number Publication date
US7464366B2 (en) 2008-12-09
US20060074736A1 (en) 2006-04-06
EP1643428A1 (en) 2006-04-05
JP4806240B2 (ja) 2011-11-02
JP2006107477A (ja) 2006-04-20

Similar Documents

Publication Publication Date Title
JP4806240B2 (ja) コンポーネント化された拡張可能なワークフローモデル
US7451432B2 (en) Transformation of componentized and extensible workflow to a declarative format
JP5173128B2 (ja) フローベースおよび制約ベースのワークフローをオーサリングし、実行するための統一モデル
JP5710852B2 (ja) 設計時および実行時にワークフローを継ぎ目なくオーサリングし編集するためのフレームワーク
US7631291B2 (en) Declarative representation for an extensible workflow model
US8170901B2 (en) Extensible framework for designing workflows
EP1643435B1 (en) An extensible framework for designing workflows
US20060074704A1 (en) Framework to model cross-cutting behavioral concerns in the workflow domain
JP5042993B2 (ja) ソフトウェアアプリケーションを構成する方法
US7886269B2 (en) XML application framework
Bukovics Foundation Overview

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid