소개
요즘의 e-비즈니스
환경은 웹서비스와 같은 네트워크 어플리케이션들의 상호작용으로 이루어 집니다. 이를 위해서는 다양한 종류의
비즈니스 자원들을 실시간 통합할 수 있음과 동시에 기민하게 변화하는 기술적 성장을 따라잡을 수 있어야 합니다.
uEngine은 이러한 적응성과 유연성을 제공하는 웹서비스 기반 워크플로 엔진 입니다.
uEngine의 활용분야는 기업의 Business Process Management 뿐만
아니라 기업간 거래(B2B), 어플리케이션간의 통합(EAI)을
지원하는 통합 비즈니스 운영체제입니다. 또한 uEngine은 GNU 철학에 근거한 오픈소스 소프트웨어로서 개발자 정신에 기본하고 있습니다.
[노트]본 유저가이드는
uEngine version v1.0 RC-5 버전을 기준으로 작성되었습니다
이번 절에서는 uEngine의 근간인 워크플로와
웹서비스 기술 및 객체지향 프레임워크에 대해 간단히 소개하고, uEngine이 어떻게 이러한 기술들을 바탕으로 universal하고 적응성있는 BPM을 실현하는 가를 소개합니다.
워크플로
워크플로의 기본적 정의는 사람과 기계와의 작업들 즉, IT 어플리케이션들과 툴들로 이루어지는 업무의 흐름(프로세스)을 자동화하는것입니다. 워크플로의 최초 출현배경은 주로 사무실내 직원들
간의 긴밀한 작업들 – 보험, 뱅킹, 법무 등과 같은 문서기반의 작업흐름을 자동적으로 분배, 컨트롤해
주는 것이었으나, 최근에는 산업기계와의 연동, 기업간 거래, 기업어플리케이션과의 통합, 기업 내부와 인터넷 포탈과의 연계등 IT, 사람, 비즈니스 파트너가 상호 협업하고 연계되는 지점에서 접착제
역할을 수행하는 광범위한 개념으로 성장하고 있습니다.
워크플로 = ‘큰 프로그래밍’
워크플로를 한마디로 표현하자면 “업무 흐름을 모델링 툴로 그린 후, 서버에 업로드 시키면 모델링한
업무흐름대로 개발작업없이 바로 수행시켜 주는 엔진”이라고 할 수 있습니다. 그래서 워크플로는 일종의 큰 프로그래밍을 하는 개발툴처럼 보이기도 합니다. 아래
그림은 이러한 워크플로의 빌드타임/런타임 개념을 설명합니다.
그림 1. 워크플로 기반
개발 순서 (WfMC, 1995)
그림1은 워크플로
기반 개발의 전형적 순서를 보여줍니다. 크게 빌드타임(개발시간)과 런타임(실행시간)으로
나뉘게 됩니다.
빌드타임에는 업무의 흐름을 분석, 정의하는 툴을 제공하는데
이것을 Process Definition Tool이라고 합니다. 이
툴을 이용하여 어떤 역할의 사람이 어떤 툴을 이용해서 어떤 작업을 어떠한 순서로 하게 된다는 것을 그림 그리듯 정의하게 됩니다. 이렇게 정의한 업무의 흐름을 Process Definition이라고
합니다.
런타임에서는 이렇게 정의된 Process Definition를
실제로 동작시킬 수 있는 Workflow Enactment Server에 디플로이 한 후 실행시키게
됩니다. 그러면 아래 그림과 같이 프로세스 정의를 해석하여 작업이 필요한 순간에 작업자(사람)나 IT 리소스(소프트웨어)에게 작업을 시키고 결과를 자동적으로 관리하게 됩니다.
그림 2. 사람과 IT리소스간의 프로세스를 자동화하는 워크플로 (WfMC, 1995)
이러한 방법으로 기술을 전혀 모르는 업무 전문가도 그림을 그리듯이 ‘프로세스
정의’라는 형식으로 업무를 정의하기만 하면 개발작업 없이 시스템이 완성되는 것입니다[1].
워크플로의 구성요소
그림 3. 워크플로의 구성요소 (WfMC, 1995)
그림 3은 워크플로시스템의
구성요소를 보여줍니다. 프로세스의 설계와 동작을 위한 Process
Definition Tool과 Workflow Enactment Server, 프로세스를
관리하고 동작상황을 모니터링할 수 있는 Administration & Monitoring Tools, 작업을
직접수행하는 사용자가 수행할 업무 리스트를 관리하고 직접 업무를 수행할 수 있는 환경인 Workflow
Client Applications (또는 Work-list Handler), 또한 액티비티를
사람이 수행하는 것이 아니라 소프트웨어나 기계가 수행할 수도 있는데 이런 경우 Invoked
Application이라고 합니다. 마지막으로 다른 워크플로 시스템과 연동하여 다른 조직간에
이어진 프로세스를 수행할 수 도 있습니다[2].
워크플로는 일반 개발툴과 무엇이 다른가?
처음에 언급했다시피 워크플로는 일종의 개발툴 처럼 보이기도
합니다. 하지만 다음표가 비교하듯이 유사하지만 많은 부분에서 그 추상화 수준이 다릅니다:
|
|
일반 프로그래밍 |
워크플로 |
|
개발주체 |
설계의 경험, 사용
기술등에 대한 지식을 가진 개발자 |
역할, 업무의
흐름 등에 대한 이해가 있는 업무전문가 |
|
설계, 모델링의 목적 |
구현단계를 위한 아키텍쳐, 데이터베이스, 객체구조등의 기술적 설계 |
업무의 흐름, 전달되는
문서양식, 작업자 등의 고수준의 추상화된 업무설계에 집중 |
|
최소 작업의 단위 |
명령. 함수호출, SQL쿼리 수행등의 단위업무를 구성하는 명령 |
액티비티. 업무
참여자가 다른 참여자와 관련없이 수행하는 단위의 업무 |
|
데이터의 단위 |
문자열, 숫자형, 데이터베이스 레코드 등의 자료를 표현하기 위한 자료구조 |
워드문서, 송장, XML비즈니스문서 등의 엔드유저가 집적 사용하는 자료 |
|
운영과정 |
요구분석, 설계, 개발, 재배포 등의 단계별 리엔지니어링. |
운영중에 즉각적, 지속적으로
변화된 요구사항을 반영, 피드백
|
즉, 워크플로는
일반 개발툴에 비해 훨씬 거시적이고 비즈니스적인 관점의 표현과 구현에 중점을 두고 있습니다. 말하자면, ‘어플리케이션 생성기’라기 보다는 ‘업무환경 생성기’ 혹은 ‘업무
운영체제’라는 편이 보다 워크플로의 특징을 잘 설명한다고 할 수 있겠습니다.
워크플로 우산
워크플로는 이러한 엔드유저 입장의 추상적 개발모델을 위한 프로세스 설계, 관리, 모니터링, 업무환경
구현 등의 기능외에 이를 기반으로한 여러가지 상승효과를 주는 기능들을 제공합니다. 다음은 그러한 가치상승의
기능들을 나열하고 있습니다.
l
QoS측면: 비즈니스 프로세스의 특징상 아주 장기적으로 진행되고
결과가 누락되거나 업무가 단절되어서는 않되기 때문에 워크플로는 안전하고 견고한 비즈니스 환경을 지원해야 합니다.
이를 위해 시스템 하부에서 트랜잭션, Fail-Over, 메시지 큐잉 (될때까지 적절히 재시도)등의 메커니즘을 제공합니다.
l
B2B: 워크플로가 담당하는 비즈니스 영역은 기업 내부 뿐만아니라 외부에 걸쳐 진행될 수 있는데 이는 조직간 워크플로엔진의
연계를 통해 가능합니다.
l
EAI: 소프트웨어와의 통합과 안정적인 흐름제어의 특징을 지닌 워크플로는 기업 어플리케이션의 통합을 지원하는 기능으로
활용되기도 합니다.
워크플로는 이러한 추상적 개발과 다양한 지원기능들을 통해
기민하게 변화하는 비즈니스 요구의 변화에 일관적이고 안정적인 시스템 개발/운용 환경을 제공하는 우산과
같은 기능을 합니다.
그림 4. 워크플로 우산
웹서비스
이번절에서는 uEngine의 2번째 기술적 근간인 웹서비스에 대해서 설명합니다.
웹서비스란 “컴퓨터가 읽고 사용할 수 있는 웹사이트”
그림 5.웹서비스는 컴퓨터가
웹을 활용할 수 있도록 고안된 환경 (Google, 2004 & Hendler, 2001)
위의 그림은 웹서비스가 무엇인지 아주 잘 설명하고 있습니다. 웹서비스는 사람의 개입없이 컴퓨터가 어떤 웹사이트에 접속해서 자료를 공유하고 폼 전송을 통해 데이터를 전달할
수 있는 환경입니다. 이를 위해 기존의 웹사이트를 컴퓨터가 이해할 수 있도록 HTML이 아닌 XML로 데이터를 주고 받게 됩니다.
|
|
컴퓨터가 웹서비스를 활용하는 단계 (IBM, 2000) |
이를위해, 위의
그림에서 보듯이 사람이 웹사이트를 “검색해서à읽고à사용”하는 단계처럼 컴퓨터가 웹서비스를 “검색à연동à호출” 할 수 있도록 표준화된 방법 3가지인 UDDI, WSDL, SOAP을 제공합니다.
웹서비스의 특징
l
상호운용가능하게 정보를 교환 (Information exchange in the interoperable way)
XML/Text와 HTTP라는 대중화되고 가벼운 기술을 활용함으로써 대부분은 운영체제와 소형시스템에서 상호운용가능합니다.
l
동적 서비스 연동 및 광고 (Dynamic Service Binding & Advertizement)
웹서비스
환경에서는 통합의 대상이 되는 2개의 시스템이 사전의 기술적 합의가 없어도 UDDI검색을 통해 필요(적절)한
서비스를 검색하고 그 서비스에 대한 기술정보(WSDL)를 실시간 얻어와 바로 연동할 수 있습니다. 이 둘(UDDI와 WSDL)은
다수의 서비스에 대한 비교 후 거래를 가능케하는 실시간 웹서비스 기반 비즈니스 전략의 핵심 도구입니다.
웹서비스 비즈니스 전략과 유형
l
한 종류의 서비스에 대한 다수의 제공자 (Single product and variety of suppliers)
l
글로벌화된 아웃소싱: 조건에 맞는 최고의 서비스와 정보로 조합된 환경을 구성할 수 있습니다. 앞으로
가격비교나 벤치마킹 사이트들은 좀더
l
Short-term
partnership: 이익기반의 언제나 변할 수 있기 때문에 파트너 쉽의 생명주기는
점점 더 짧아집니다.
l
비즈니스 랩퍼(Wrapper): “웹서비스는 사람의 관여없이 다른 기업의 시스템이 내 기업의 시스템의 내부를 들여다 보고 서비스를
이용 할 수 있는 ‘인터넷 기반 서비스 창구’”
그림 6. 웹서비스는 기업(조직)이 컴퓨터에게 제공하는 “서비스
창구”
현재의 기업업무에서의 인터넷의 활용은 주로 사람이 홈페이지를
열어서 그 내용을 읽은 후 거기에 맞는 내용으로 폼을 채우고 “보내기”버튼을
클릭해서 업무를 진행한다. 이런것들을 우리 기업 내부의 전산 시스템이 자동으로 한다면 어떻겠습니까? 즉, 컴퓨터가 폼에 입력되어야 할 내용을 자동으로 인식하고 기업
내부 시스템에 미리 저장된 데이터베이스에서 입력할 값들을 읽어서 자동으로 처리한다면 어떻겠습니까. 이러한
환경이 점차 확대되었을 때 우리는 명함에 쓰인 웹서비스 주소만 가지고 그 회사의 홈페이지 주소만 알면 이제 바로 그 회사의 전산시스템과 연동이
가능하다면 어떻겠습니까.. 이것이 웹서비스입니다. 근대 컴퓨팅의
역사를 살펴보면 데이터 통합(data integration)과 분산 컴퓨팅의 역사라고 해도 과언이 아닙니다. 즉, 웹서비스는 기업 내부 시스템에 갇혀있던 데이터와 서비스를 네트워크를
통해 서로 공유하여 시너지를 낼 수 있는 가장 현실적이고 대중적 기술이 될 수 있습니다.
웹서비스 성공의 관건과 워크플로
웹서비스를 통해 많은 서비스들이 공유된다면 이는 초기 인터넷의
확산처럼 엄청난 파급효과를 가져줄 것 같습니다. 웹서비스 엔드포인트의 북마크 만으로 많은 서비스들을
연계해서 새로운 서비스로 재판매할 수도 있을 것입니다 (Web Service Intermediary). 또는
이렇게 잘 된 웹서비스들에 대한 카탈로그 서비스를 웹서비스로 제공할 수도 있을겁니다. 기업들의 아웃소싱은
거리와 시간, 기술적 한계를 뛰어넘어 최적의 전략화가 가능해 질 것입니다.
하지만 웹서비스의 장점을 극대화하고 비즈니스 전략을 현실화 하기 위해서는 다음과 같은 2가지 관건을 충족해야 합니다.
l
웹서비스간 프로세스 자동화
웹서비스들
간에 이루어지는 업무의 흐름, 즉, 기업간의 웹서비스 프로세스를
일일이 프로그래밍에 의존해서 개발한다면 개발 비용은 둘째치고 웹서비스의 최대 장점인 JIT-통합이란
것은 무색해 질 것입니다. 이는 “이익조건에 따라 매번 변화할
수 있는 파트너쉽”이라는 웹서비스의 전략을 반영하기에 너무 속도와 효율측면에서 부적합 할 것입니다. 따라서, 웹서비스간의 흐름을 고수준의 툴을 통해 모델링하고 이를
곧 운영시키고 수정하며 상태를 모니터링 할 수 있는 환경이 요구됩니다. 즉, 웹서비스 운영을 위한 워크플로 개념이 필요하다는 것입니다.
l
내용의 상호운영성을 위한 인간의 적절한
개입
컴퓨터가
인지능력을 따라하는 것의 한계점은 여전히 존재할 수 밖에 없습니다. 마찬가지로 WSDL을 통한 유연한 연동을 제공하는 웹서비스 또한 그 한계점은 존재합니다.
특히, 여러가지 예외사항과 거래상황에 따른 변수를 생각해야하는 비즈니스 환경에의 웹서비스
접목은 오히려 위험해 보이기도 합니다. 이를 해소하기 위해서는 아직은 어느정도 수준으로 각 건에 대해
사람의 개입이 필요하다는 것입니다. 즉, 데이터 타입 레벨의
상호운영성을 넘어서 내용(시맨틱)에 대한 상호운영성의 지원이
꼭 필요합니다. 워크플로는 프로세스에 대한 인간의 개입을 중시하며 사람의 업무를 관리하고 프로세스 흐름과
데이터에 적절히 조화되도록 하는 기능이 있습니다.
UEngine
워크플로의 미결 문제들
앞장에서 설명한 듯이 워크플로 기반의 개발은 구현과 설계
뿐만 아니라 프로세스 관리영역에서 까지 많은 영역에서의 개발 노력을 덜어줍니다. 하지만 이런 쉽고 효율적인
개발의 이면에 워크플로가 아직 개발의 모든 영역에서 활용되지 못하는 다음과 같은 결정적 미결 이쓔들이 존재합니다.
l
워크플로로 모든 개발의 요구를 충족할
수 있는가? (커스트마이징의 어려움)
워크플로가
개발에 필요한 아무리 많은 기능을 제공한다고 하더라도, 비즈니스 적,
기술적 요구나 변화에 따라 새로운 액티비티 유형을 추가할 필요는 반드시 생기게 됩니다. 대부분의 워크플로 엔진들에 새로운 액티비티를 추가하는 것은 그
제품에 대한 많은 기술적 이해와 구현 및 리펙토링 과정을 요구하게 됩니다. “이 워크플로 제품으로 프로젝트가
끝날때까지 제한된 시간과 비용으로 모든 구현이 가능하겠는가”하는 고민이 생기게 됩니다. 이는 프로젝트 초기나 진행중에서 발견되는 아주 큰 위험요소로 작용합니다.
l
워크플로로 만들어 놓으면 다음에 다른
환경에서 재활용 할 수 있는가?
앞에서와
마찬가지로 모든 패키지 성 제품이 갖고 있는 공통적인 문제라 할 수 있습니다. 특정 제품에 맞게 만들어
놓은 어플리케이션들은 그 제품의 엔진에 의해 잘 해석되어 활용되지만 다른 제품이나 환경에서는 다시 개발해야 하는 경우도 있습니다. 이는 프로젝트의 초기에 워크플로를 적용할 것인가 말것인가 하는 관건이 될 수도 있습니다.
l
다른 종류의 워크플로 엔진과 연동이
정말 잘 되는가? (상호운영성 문제)
조직간에
워크플로의 통합, 즉, 프로세스 연계를 통한 기업간 거래
방법은 워크플로의 가장 매력적이고 파워풀한 기능이라고 할 수 있습니다. 그러나 많은 표준화 노력에도
불구하고 다른 환경, 다른 언어에서 각기 개발된 워크플로 엔진들 간의 자유로운 연계는 현실적으로 힘든
것이 사실입니다.
UEngine의 설계원칙
uEngine은 기존의 워크플로 엔진들이 가진 한계점을 뛰어넘기 위해 1)컴포넌트
프레임워크 와 2) 웹서비스를 설계원칙에 반영하고 있습니다.
컴포넌트 기반 적응형/성장형 엔진
JavaBeans나 EJB에서 발견되는
Java 특유의 로직과 기술을 분리하는 컴포넌트 환경이 반영된 컴포넌트 프레임워크를 제공하여 개발자는 기능의 확장에 필요한 새로운
기능을 쉽게 추가할 수 있으며 제어권의 반전[3]을
통해 결과 시스템의 품질과 안정성을 보장받게 됩니다. 특히 유엔진의 추상적 컴포넌트 개발방식은 퍼시스턴스, XML, 웹서비스, 스윙, 메시지
큐잉, EJB 등에 대한 지식 없이 그 기능들을 개발할 수 있도록 합니다.
-
유엔진 컴포넌트
인터페이스는 다음과 같은 것들을 포함합니다: 액티비티 유형, 플로우
유형, 액티비티 디자이너, 액티비티 뷰어(렌더러), 프로세스 언어 변환기/출력기, 워크아이템핸들러 등.
웹서비스를 기반
uEngine으로 만든 프로세스는 그 자체로서 웹서비스가 됩니다. 이는 WSDL-SOAP의 웹서비스의 동적 통합 (사전기술지식 없이 바로
통합)의 장점을 그대로 활용할 수 있는데, 다른 워크플로
엔진들이 웹서비스의 단순하고 쉬운 통합방법으로 uEngine의 프로세스와 연계할 수 있도록 합니다. 또한 uEngine은 프로세스의 공개를 위한 수단만이 아니라, 웹서비스 간 프로세스 구현을 목표한 설계를 엔진개발에 반영했습니다.
-
XML 기반의 프로세스 변수: uEngine은 프로세스 변수의 선언, 할당, 처리 작업을 위한
XML-type시스템을 내장하고 있습니다. 이것은 웹서비스 간의 데이터를 전달과 웹서비스를
기반한 워크플로 리소스의 통합관리를 위한 기초를 제공합니다.
-
동적인 웹서비스 액티비티: 웹서비스의 발견, 연동, 호출
등의 동적 웹서비스를 구성할 수 있는 액티비티 타입들을 제공합니다. 이들의 조합으로 고도의 인터넷 비즈니스
환경을 생산성있게 구축토록 도와줍니다.
-
통합자원관리: 워크플로 리소스 (IT, 사람, 비즈니스
파트너)를 웹서비스로 래핑하여 다룸으로써 통합적인 자원관리를 지원합니다. 이를 통해 uEngine에 선언된 모든 리소스는 어디서나 재활용가능한
리소스로 유지됩니다.
UEngine의 개발전략
Bottom-Up 방식
기존의 워크플로 엔진들은 많은 기능들(액티비티 유형)을 하부에 제공하여 프로세스 모델링에 필요한 모든 것을
제공하는 전략을 가지고 있습니다. 이는 top-down의
전략이라고 할 수 있습니다. 이와 다르게 uEngine은
오히려 초기 기능을 최소화하고, 대신 기능추가를 통해 지속적으로 기능을 누적해 갈 수 있는 컴포넌트
프레임워크의 제공에 초점을 두는 bottom-up 전략입니다. 즉, 컴포넌트의 생산과 엔진의 재활용성 및 커스트마이징 용이성을 극대화하는 방향입니다.
누군가 한번 고민하여 개발했으면 다시 반복하지 않는다
여러분의 프로젝트에
uEngine을 적용할수록 유엔진 프레임워크에 의해 새로운 기능들은 컴포넌트의 형식(jar파일)으로 남게됩니다. 이는 여러분이 재활용할 수 있는 컴포넌트를 공유하여
서로간에 시너지 효과를 낼 수 있는 시작점이 됩니다. UEngine은 인터넷에 연결된 모든 개발자가
한번 작성한 컴포넌트를 서로 필요한 사람끼리 교환할 수 있는 “코드 바자회”(CSC, 2004)를 실현할 수 있도록 하는 것을 최종 목표로 생각합니다.
최소한의 기술적 이해를 요구한다 - 오픈아키텍쳐기반
아무리 좋은 소프트웨어라도 들여다 보는데 너무 어려우면 그만큼
가용성이 떨어집니다. 더 이상 어려운 기술을 남발하여 개발자들에게 그것들을 이해하게끔 강요하는 것은
급변하는 e-Business 환경을 위한 경쟁력있는 툴이 아닐 것입니다. UEngine은 ‘꼭 필요한 만큼만의 기술’과 ‘최대한 널리 알려진 기술’들만을
채용하여 ‘단순하지만 충분하게’ 구현되고 있습니다. 개발자 여러분이 최대한 단시간에 uEngine에 대한 아키텍쳐를
이해하고 활용할 수 있게 하기 위해 이미 이해되고 공개된 아키텍쳐인 J2EE와 디자인 패턴들을 기반하고
있습니다. 이는 uEngine을 가장 하부의 커널레벨까지
여러분이 필요한 환경에 최적화 할 수 있도록 많은 기술적 이해를 도와줄겁니다. 또한 복잡하고 잘된 UI나 기능의 초기 제공보다는 상대적으로 멋지지 않고 간단해 보이기 까지한 커널을 유지하여 여러분이 쉽게 적용할
수 있도록 하는것에 최대한 초점을 맞추겠다는 것입니다.
오픈소스 전략
극심하게 비싼 소프트웨어 라이센스비용은 정보시스템 프로젝트
전체예산에서 컨설팅과 개발 서비스에 대해 투자되어야 할 비용을 상대적으로 침범하게 되어, 프로젝트의
실패사례의 근원이 되기도 합니다. 이러한 결과로 말미암아, 고객사는
물론이고 개발사를 위한 것이 아닌 소프트웨어 벤더의 오너에게 개발수익이 집중되게 되는 악순환의 고리를 형성하게 됩니다. 오픈소스 비즈니스 전략은 기존의 ‘SW=공산품’위주의 소프트웨어 시장 원리에서 ‘SW=서비스’라는 변화된 가치관을 제시합니다. 이는 더 이상 소스코드가 SW의 실체가 아니고 그 SW를 통해 고객이 얻는 ‘서비스’가 SW의 실체라는
것입니다. 오픈소스는 인터넷에 소스를 공개하여 개발하는 새로운 개발모델을 제시하고 있습니다. 이는 개발자의 개발노력의 산물인 소스코드를 공개하여 서로 필요한 것들을 가져다 쓸 수 있게 하는 방법으로 (고통 분배[4]) 소프트웨어 제품을 만들고 그것을 프로젝트에 활용함으로써 로열티로 빠져나가던 수익의 부분을 개발자의 권익으로
돌려 개발의욕을 고취시키고 고객의 요구를 만족시켜 줄 수 있는 충실한 서비스로 돌려주게 한다는 전략입니다. (보다
자세한 오픈소스의 이념과 사업적 전략에 대해서는 GNU의 “마법의
솥”을 읽어보기를 추천합니다).
uEngine은 많은
조직에서 가능한 적은 비용으로 웹서비스와 워크플로를 기반한 개발을 시작할 수 있게 하기 위해 모든 소프트웨어와 소스코드를 무료로 제공하는 오프소스
비즈니스 모델을 지향합니다. 즉, uEngine을 통해 개발(SI), 컨설팅/교육과 같은 비즈니스를 하실 수 있고 또한 uEngine의 개발에 참여하여 자신의 코드를 공유하고 타인의 코드를 다운받아 서로 교환 할 수 있습니다.
uEngine의 구성요소
uEngine 아키텍쳐
-
JVM: JRE
1.4에서 개발/테스트 되었습니다.
-
J2EE
Container: J2EE의 Managed
Transaction, Container-Managed Persistence의 관리된, 안정된
환경아래 운영되게 해줍니다. JBoss 3.2.1에서 테스트되었습니다.
(OKF는 J2EE의 관리된 환경과 워크플로 기능 컴포넌트들 간의 매개 역할을 하여 기술적 이해 없이 쉽게 컴포넌트를 추가할
수 있게하는 프레임워크입니다.)
-
웹서비스 컨테이너: Apache Axis와 잘 연동되어 있습니다. Axis는 웹서비스
호출 을 위한 툴을 제공할 뿐만 아니라 프로세스 정의를 웹서비스로 공개/호스팅 합니다.
-
Portlet을 통한 Process 관리 툴의 제공: Process 관리 권한, 사용자 워크리스트, 포탈 화면 등을 위해 관리 화면들을 Portlet으로 제공합니다. 이는 다른 종류의 포탈엔진에서도 재활용할 수 있고 위치이동, 개인화
등이 쉽도록 해줍니다. UEngine 배포 버전은 오픈소스로 제공되는
EIP(Enterprise Information Portal)시스템인 ‘Liferay’와
통합되어 있습니다.
-
Java Web
Start를 통한 웹에서의 활용: 웹
브라우저에서 스윙으로 만들어진 프로세스 디자이너를 직접 사용할 수 있도록 합니다.
-
JMS(Java
Messaging Service) Provider: Jboss에 내장된 Jboss MQ를 사용합니다.
-
Database
Server: 보존메커니즘을 위해 EJB 엔티티
빈을 활용하기 때문에 기본적으로는 DB에 비종속적입니다. DB 서버는
기본적으로 Jboss에 내장된 오픈소스 데이터베이스인
Hypersonic 을 사용하고 있습니다.