 | |
|
난이도 : 초급 Joshy Joseph, 소프트웨어 엔지니어, IBM
Ken Beck, 관리 컨설턴트, IBM
German Goldszmidt, 고급 기술 위원, IBM
2004 년 12 월 28 일 IBM® WebSphere® Business Integration Modeler V5.1로 비지니스 프로세스를 그래픽으로 모델링하는 방법과 기술을 소개한다. 필자는 반복적인 모델링 방식을 수행하는 가이드라인을 제시한다. 태스크의 구분과 리스팅과 함께 단계별 프로세스, 태스크 순서, 태스크들간 흐름 제어 만들기, 데이터를 모델에 도입하기, 서비스를 프로세스 모델에 통합하는 방법들을 설명한다.
Introduction
이 시리즈는 실제 온 디맨드 변형 프로젝트인, Oneida-2("On demand business process life cycle, Part 1"참조)와 관련된 작업에 기반하고 있다.(참고자료) 이 시리즈에서는 생명주기의 한 측면인 비지니스 프로세스(BP) 모델의 설계에 초점을 맞춘다.
다음 회에 소개할 Elements of Business Process modeling에서는 WebSphere Business Integration Modeler를 이용한 프로세스 모델링의 기본 개념을 소개한다. 이 글에서 Order to Manufacturing Processing System (OTMPS) 시나리오를 사용한 모델링을 자세히 설명한다.
OTMPS의 모델링 단계를 따라가 본다. 개발에 맞는 가장 유용한 모델을 만들기 위해서는 수없이 많은 반복이 필요하다.
비지니스 프로세스(Business Process) 요구사항들
이 시나리오에서, 비지니스는 IBM® WebSphere® Business Integration Server Foundation의 Process Choreographer를 사용하여 주문 과정을 자동화 해야 한다. 이를 사용하면 온 디맨드 환경에서 훨씬 더 빨리 자동화된 프로세스를 변경할 수 있다.
WebSphere Business Integration Modeler에서 프로세스의 모델을 만든다면, 비지니스 분석가가 알아낸 프로세스가 작동하는 방법에 대한 정보는 Websphere Studio Application Developer Integration Edition의 워크플로우 개발자들이 사용하도록 반출될 수 있다.
비지니스 분석가는 이 시나리오에서 다음과 같은 핵심 액티비티들을 분석한다:
- 주문 받기
- 외부 밸리데이션 서비스로 주문 검사하기
- 무효 주문을 문서화하고 운영자에게 알리기
- 유효 주문을 해당 제조 공장으로 보내기
다음 단계는 인커밍 주문, 제조 데이터, 밸리데이션 데이터 같은 데이터 요소들을 구분하고 모델링하는 단계이다. 이 데이터 아이템들은 액티비티, 리파지토리, 서비스의 인풋과 아웃풋이 된다.
비지니스 아이템들의 모델링
비지니스 아이템, 비지니스 아이템 템플릿, 비지니스 아이템 인스턴스들을 만드는 방법을 단계별로 설명하겠다.
그림 1. 데이터 카탈로그와 비지니스 아이템
그림 1은 주문과 주문 상태 같은 모든 제조 관련 데이터 모델을 구성하는데 필요한 manufacturing이라고 하는 데이터 카탈로그를 보여주고 있다.
데이터 카탈로그의 생성은 선택적인 것이다. 또는 디폴트 비지니스 아이템 데이터 카탈로그(WebSphere Business Integration에서 제공) 데이터 모델을 만들 수 있다.
비지니스 아이템들은 생성되어 기존 데이터 카탈로그에 추가된다. 예를 들어, 그림 1은 "Orders" 비지니스 아이템을 "orderItems" "mfgNum" "valid" 같은 애트리뷰트로 나타내고 있다.
이 애트리뷰트들은 (스트링, 정수, 부울 같은) 간단한 유형이 될 수도 있고 또는 같은 데이터 카탈로그 또는 다른 데이터 카탈로그의 비지니스 아이템이 될 수 있다.
"Orders" 비지니스 아이템에는 같은 데이터 카탈로그에서 "OrderItem" 유형의 "orderItems" 애트리뷰트를 포함한다.
비지니스 아이템을 만드는 대신, 모델링 과정에 앞서 기존 XSD 스키마를 WebSphere Business Integration Modeler로 반입할 수 있다.
각 XML 스키마에 대해 하나의 데이터 카탈로그가 만들어지고 스키마 콘텐트는 비지니스 아이템과 템플릿 같은 데이터 카탈로그 요소들로 매핑된다.
서비스 모델링
WebSphere Business Integration Modeler에서 서비스들은 (모델링 되고 있는 프로세스의 밖에서)외부 엔터티로서 정의된다.
이는 조직의 프로세스 내에서 사용될 수 있다. OTMP 시나리오에서 우리는 Validate & Generate Topology 서비스와 Manufacturing 서비스 같은 외부 서비스들과 인터랙팅 하고 있다.
그림 2. 서비스 생성 위자드
|
프로세스 다이어그램이란?
프로세스 다이어그램은 BP 플로우를 그래픽으로 표현한 것으로서 BP 플로우들 간 액티비티와 연결들로 구성된다.
WebSphere Business Integration Modeler process editor는 팔레트 또는 프로젝트 트리에서 드래그&드롭(drag&drop)을 하는 엘리먼트를 사용하여 프로세스 플로우를 시각적으로 구성하는데 사용된다.
프로세스 다이어그램은 사전 정의된 프로세스, 태스크, 리파지토리, 서비스들을 포함할 수 있다. 이것은 프로젝트 트리에서 드래그&드롭 할 수 있다.
게다가, 프로세스 다이어그램은 재사용 할 수 없는 엘리먼트들도 포함하고 있는데 프로세스, 태스크, 리파지토리, start/stop/end 노드, 연결, 포크, 조인, 루프, 맵, 결정, 공지 방송, 공지 수신자, 관찰자, 타이머, 주석 같은 팔레트에서 드래그&드롭 할 수 있다.
|
|
그림 2는 외부 서비스용 인풋과 아웃풋을 정의하는데 쓰이는 WebSphere Business Integration Modeler 위자드를 보여주고 있다. "Validate In" 유형의 인풋과 함께
Validate & Generate Topology 서비스를 보여주고 있다. 이와 비슷하게 서비스에서 아웃풋 메시지들을 만들 수 있다. WebSphere Business Integration Modeler 에서 인풋 기준으로 알려진 인풋 세트를 그룹핑 할 수 있다.
Business Process Execution Language (BPEL)로 반출하기 때문에 엘리먼트 당 단 하나의 인풋 기준을 갖도록 제한된다. Web Services Description Language (WSDL) 인터페이스 모델 (portType 정의)에서 이 인풋 기준과 아웃풋 기준은 연산 인풋 메시지와 아웃풋 메시지로 각각 매핑된다.
모델링 프로세스의 다음 단계에서는 BP 모델에서 서비스 호출 태스크를 만드는 방법을 보게 될 것이다.
비지니스 정책 모델링
분석가들은 의도된 정책들을 자연 언어를 사용하여 주석으로서 지정할 것이다. 이 샘플 시나리오에서 제조 공장 선택에 대한 정책을 정의한다. 이 정책은 비지니스 소유자가 특정 주문에 맞는 제조 공장을 결정할 수 있도록 한다.
예를 들어, 가격이 1백만 달러를 초과하는 주문은 우선순위 기준에 따라 특정 제조 공장에 의해 처리되어야 한다는 것을 정책이 지정할 수 있다. 또 다른 정책은 선호하는 공장이 없을 때 주문을 핸들하는 방법을 지정할 수 있다.
분석가는 각 태스크의 주석 필드에 정책들을 문서화한다. 개발자들은 정책을 규칙으로 변환할 책임이 있다. 분석가는 실행 포인트를 제공하는 사전 서비스를 나타내는 모델 서비스 요소에 추가한다. 태스크를 추가하여 정책을 실행하는 코드용 플레이스홀더를 나타낸다.
개발자들은 필요한 코드를 추가하여 태스크를 구현하고 정확한 규칙을 실행한다. (참고자료)
프로세스 모델 개발
이 섹션에서는 다음의 프로세스 요소들을 정의하는 방법을 설명하겠다:
모델링 방식도 설명할 것이다:
- 태스크의 구분과 리스팅
- 태스크 순서 정하기
- 태스크들 간 흐름 제어 생성
- 데이터를 프로세스에 도입하기
- 프로세스 모델 내에서 서비스 통합하기
프로세스 만들기
|
프로세스 다이어그램 뷰
Swimlane 뷰. Swimlane은 액티비티들을 역할, 리소스, 조직 단위, 위치 등으로 그룹핑하는 프로세스 다이어그램 내의 분리된 열(row)들이다.
Swimlane은 특정 유형의 리소스, 역할, 조직 단위에 의해 수행되거나 또는 특정 위치와 관련된 액티비티들을 표현한다.
Free-form 레이아웃. Free-form 레이아웃에서는 다이어그램을 편집하고 다이어그램 내에서 엘리먼트의 위치를 변경할 수 있다.
|
|
Eclipse에서 Business Process modeling을 선택하여 WebSphere Business Integration Modeler 기능에 접근한다.
프로세스 카탈로그 또는 폴더를 만들어 프로세스, 태스크, 서비스, 리파지토리 모델 엘리먼트를 구성한다.
그림 3. 새로운 프로세스 모델 생성 다이얼로그
일단 프로세스 카탈로그가 만들어지면 다음 단계는 다이얼로그 박스를 연다. (그림 3) 이 그림은 두 개의 프로세스 카탈로그인 "Processes" 와 "Services"를 보여준다.
이 예제에서 "Processes" 카탈로그에 OrderProcessSystem 이라고 하는 BP를 만든다. 나중에 WebSphere Business Integration Modeler process editor 에서 이 프로세스를 열어 프로세스 다이어그램을 완성할 수 있다. (프로세스 다이어그램이란?참조)
그림 4는 비어있는 프로세스 에디터이다. 프로세스 다이어그램에서 사용할 수 있는 두 가지 유형의 뷰들이 있다: Swimlane view와 Free-Form layout
(프로세스 다이어그램 뷰 참조). 여기에서는 free-form 레이아웃 다이어그램을 사용한다.
그림 4. 비어있는 프로세스 다이어그램
그림 5는 WebSphere Business Integration Modeler V5.1의 Order Process
Subsystem 의 완성된 프로세스 세그먼트이다. 이 간단한 모델은 밸리데이션과 제조를 통한 주문의 흐름을 설명하고 있다.
이 모델은 Validate & Generate Topology 서비스 호출 단계를 통해 밸리데이션 서비스 파트너를 통합한다.
그림 5 는 결정 포인트인 "validation successful?", 두 개의 데이터 포맷 변환 태스크, 로컬 데이터 리파지토리, 프로세스 루프 등을 보여준다.
그림 5. OTMPS용 Business Process Model
그림 6은 while루프 (Manufacturing 루프)의 내용을 보여주고 있다.
이 모델은 Apply manufacturing Plant Selection 태스크와 제조 공장 서비스 호출 단계를 사용하여 프로세스 흐름 에서 정책 실행 포인트를 설명한다.
그림 6. BP Model -- OTMPS용 Manufacturing Loop While Loop의 하위 프로세스 모델
다음 섹션에서 그림 5와 그림 6에서 설명한 모델을 완성하는 방법을 설명하겠다.
태스크 만들기
프로세스 모델링에서, 태스크들은 액티비티의 최하위 레벨이다. 예를 들어, 그림 5에서 Data Format Conversion 은 구매 주문 메시지를 밸리데이션 서비스 메시지로 변환하는 책임을 가진 태스크이다.
태스크는 더 이상 분해될 수 없다. 각 태스크 스팩은 태스크를 완성하는데 필요한 인풋, 아웃풋, 리소스들을 기대한다.
Data Format Conversion 태스크는 "Orders" 비지니스 아이템을 인풋으로서 받고 "Validate In" 비지니스 아이템을 만들어낸다. 나중에 개발자는 태스크의 비지니스 로직 구현을 추가한다.
예를 들어, 위 태스크가 BPEL로 변환될 때 태스크는 BPEL 프로세스의 호출 메소드가 된다. Order Process Subsystem을 위해 만들어진 WSDL 파일에는 portType이 포함된다. (Listing 1)
Listing 1: 데이터 포맷 변환 태스크를 위한 WSDL portType 정의
<portType name="DataFormatConversionPT">
<operation name="sendDataFormatConversion_InputCriteria">
<input message="tns:InputCriteriaMessage"
name="InputCriteriaMessage3"/>
<output message="tns:OutputCriteriaMessage3"
name="OutputCriteriaMessage3"/>
</operation>
</portType>
|
|
Expression Builder
Expression Builder는 유형을 선택하고 식의 조건에 맞는 값을 지정하여 식을 작성하는데 사용된다.
타입은 Boolean, Date, Date/Time, Duration, Function (Contains-the-text, Starts-with-the-text, Select, Every, At-least-one, Get-all, Sum, Count), Modeling artifact, Negation, Not, Number, Sub expression, Text, Time 이 될 수 있다.
조건들은 연산자와 결합된다: AND, OR, is equal to, is not equal to, is greater than, is greater than or equal to, is less than, is less than or equal to, +, -, x, /, mod, is before, is after, +duration, -duration.
|
|
개발자는 나중에 위 portType에 맞는 서비스 구현 코드를 만들고 필요한 구현 코드를 추가한다. 자세한 내용은 "Workflow development, deployment, and testing"을 참조하라. (참고자료)
루프 만들기
루프는 프로세스 내에 포함된 액티비티의 반복되는 순서를 설명한다.
그림 6은 각 주문을 반복하는 while 루프 (Manufacturing Loop)이다. 정확한 제조 공장을 선택하고 각 주문을 선택된 제조 공장으로 제출한다. while 루프는 어떤 조건이 만족될 때 까지 액티비티들을 반복하는 루프이다.
이 조건은 Expression Builder를 사용하여 만들어진 식을 통해 지정된다. (Expression Builder 참조)
그림 7. Expression Builder
그림 7처럼 "Processes.OrderProcessSystem.Control Data.Order Count" 값을 가진
Modeling artifact 는 첫 번째 조건으로 선택된다. 그런 다음 "is greater than" 연산자가 선택되고 마지막으로 0.0 값을 가진 "Number" 유형이 마지막 조건으로 선택된다. 이는 다음 과 같은 식을 만들어낸다:
"Processes.OrderProcessSystem.Control Data.OrderCount' is greater than 0.0". 이것은 BPEL 파일에서 아웃풋이 될 수 있다. Listing 2는 이 while 루프와 보여주고 해당 조건을 보여준다.
Listing 2: 반출된 BPEL과 while 조건
<while condition="DefinedByJavaCode" name="ManufacturingLoopInputCriteria"
wpc:displayName="Manufacturing Loop">
<wpc:condition>
<wpc:javaCode>
<![CDATA[return
((getControlDataVariable().getControlDataPart().getOrderCount()) > (0.0));
]]>
</wpc:javaCode>
</wpc:condition>
. . .
|
결정 포인트 추가하기
하나의 결정은 인풋을 "true"에 대한 조건의 성공적인 평가에 기반을 둔 여러 대안 아웃고잉 경로들 중 하나로 라우팅한다.
간단한 결정은 하나의 인커밍 브랜치에 하나의 인풋을, 두 개의 아웃고잉 브랜치에 각 하나의 아웃풋을 갖는다.
런타임 시, 프로세스 플로우는 특정 조건이 true라면 하나의 아웃고잉 브랜치를 취하고 같은 조건이 false일 경우 다른 브랜치를 취한다.
그림 5는 간단한 결정 포인트인 "Validation Successful?"을 보여준다.
이것은 "service output" 비지니스 아이템을 취하고 밸리데이션이 성공했는지의 여부를 검사한 다음 다른 프로세싱으로 지속할 경로를 선택하거나 실행 프로세스를 종료한다.
이 조건은 Expression Builder를 사용하여 만들어진 이전 식을 통해 지정된다.
시퀀싱
커넥터들은 엘리먼트들 사이에 추가되어 이들이 적절한 시간에 시작하도록 한다. 다중 커넥터를 갖는 엘리먼트의 로직은
Input Criteria에 의해 제어된다. 분석가는 비지니스 규칙과 이전의 데이터 요구사항들을 사용하여 시퀀스에서 엘리먼트의 순서를 결정한다.
리파지토리 만들기
프로세스는 데이터를 저장했다가 나중에 프로세스 하는 동안 사용한다.
WebSphere Business Integration Modeler 에서는 이 데이터 저장 메커니즘을 리파지토리라고 한다.
이 개념은 프로그래밍 언어의 변수와 비슷하다. 모든 리파지토리는 이름과 관련 비지니스 아이템 유형을 갖고 있다.
리파지토리의 두 유형은 로컬과 글로벌이다. 로컬 리파지토리는 프로세스가 소유하고 해당 프로세스의 엘리먼트만이 사용할 수 있다.
이 데이터 엘리먼트들은 프로세스가 끝날 때 까지 사용할 수 있다. 글로벌 리파지토리는 프로젝트 레벨에서 만들어지고 다중 프로세스에 접근할 수 있다.
여기에서는 로컬 리파지토리에 대해 설명하겠다. 글로벌 리파지토리는 BPEL 실행을 지원하지 않는다.
그림 5는 세 개의 로컬 OTMPS 리파지토리이다:
- Orders Repository, " 비지니스" 아이템 보유.
- Subprocess Execution Control Data, 프로세스 실행 "control" 데이터 보유.
- Manufacture Data Input Repository, "manufacturing input" 데이터 보유.
예제에서 리파지토리를 사용하여 비지니스 아이템들(orders, control data, manufacturing data)을 저장했다.
이 아이템들은 while 루프(Manufacturing Loop) 내에서 액세스 된다. 커넥터 상으로 전달될 수 없기 때문이다. Listing 3은 로컬 리파지토리를 BPEL 변수로 변환하는 예제이다.
Listing 3: Order 리파지토리와 BPEL 변수
Repository "Orders Repository" becomes a Java snippet and repository content
becomes a BPEL variable:
<variable messageType="wsdl:OrdersRepositoryMessage"
name="OrdersRepositoryVariable"/>
and could be accessed from the workflow using the expression:
getOrdersRepositoryVariable(true).
|
비지니스 아이템들을 커넥션과 로컬 리파지토리로 연결하기
프로세스 모델에서 데이터는 태스크들을 통해 흐른다. 비지니스 아이템 또는 인스턴스들은 태스크에서 태스크로의 연결과 제휴 될 수 있다. 그림 8은 OTMPS 모델의 한 부분이다.
그림 8. 태스크와 커넥션과 제휴 된 비지니스 아이템
그림 8은 Order Process Subsystem태스크에서
Data Format Conversion 태스크로의, 그리고 Validate & Generate
Topology 서비스로의 제어 흐름을 보여주고 있다. 게다가 이 모델은 로컬 리파지토리로의 데이터 흐름도 보여주고 있다. 모든 태스크들은 팔레트의 커넥션 툴을 사용하여 연결된다.
(시퀀싱참조) 그런 다음, 비지니스 아이템들을 커넥션과 제휴할 수 있다. 예를 들어 Data
Format Conversion과 Validate & Generate Topology 서비스들 간 커넥션은 제휴 된 비지니스 아이템을 "Validate In" 으로 보여주고 있다. 비지니스 아이템들을 로컬 리파지토리로 제휴하는 프로세스는 같은 방식으로 수행된다.
일단 로컬 리파지토리가 만들어지고 커넥터 툴을 사용하여 태스크와 연결되면 비지니스 아이템은 커넥션과 제휴된다. 예를 들어,
그림 8은 Order Process Subsystem
태스크와 두 개의 로컬 리파지토리 사이의 커넥션을 보여주고 있다. 첫 번째 커넥션은 "Orders" 데이터와 Orders Repository리파지토리와 제휴시키는 동안 Controller Control
Data와 Subprocess Execution Control Data 리파지토리를 제휴시킨다.
WebSphere Business Integration 'Basic' mode 모드에 있는 동안 이미 연결되고 있는 엘리먼트들이 이미 비지니스 아이템들이 인풋과 아웃풋으로 할당되었다면 다이얼로그 박스(그림 9)는 엘리먼트들 간 커넥션을 그리면서 디스플레이 된다.
다이얼로그 박스는 기존 인풋 또는 아웃풋을 선택할 옵션을 제공하거나 새로운 인풋 또는 아웃풋이 만들어질 수 있다.
그림 9. 데이터 연결 다이얼로그
서비스와 하위 프로세스들을 프로세스 모델로 통합하기
서비스와 하위-프로세스 엘리먼트들은 다른 엘리먼트들이 추가되는 방식과 같은 방식으로 프로세스에 추가된다.
서비스들은 팔레트에서 선택되지 않고 만들어져서 (서비스 모델링) 프로젝트 트리에서 드래그된다.
재사용 가능한 엘리먼트이기 때문이다. 서비스들은 태스크와 같은 방식으로 BPEL로 반출된다. 각 서비스는 각자의 WSDL 파일을 갖고 있다는 점만 다르다.
모델링 되는 기존 서비스에 대한 알려진 정보는 서비스의 디스크립션 필드에 추가되는 것이 좋다. 이 정보에는 서비스 디스크립션, 바인딩 선택, 발견 메커니즘, 전개 옵션 등이 포함된다.
이 디스크립션으로 개발자들은 필요한 발견, 바인딩, 전개, 통합 코드를 만들 수 있다.
하위-프로세스들은 모델에 상세를 숨기는데 사용되고 액티비티로 구조화된 플로우를 가진
scopes으로서 BPEL로 반출된다. BPEL에서 scope은 중첩된 액티비티를 고유의 관련 변수, 오류 핸들러, 보상 핸들러와 함께 정의하는 것이 가능하다.
Map 엘리먼트
Map 엘리먼트는 다른 구조들 간 데이터 포맷을 변환하는데 사용된다. 실행 BPEL 워크플로우에서 이들은 자바로 나타난다.
그림 5에서 처럼 map 엘리먼트는 프로세스의 끝에 추가되어 비지니스 아이템인 "Service Output"을 "OrderProcessResponse"로 변환한다.
KPI와 평가
BP 모니터링 기능으로 프로세스 소유자와 관리자가 BP Key Performance Indicators (KPI)를 실시간으로 감시할 수 있다. OTMPS 시나리오에서 분석가는 KPI를 정의하고 관찰 포인트를 상응 태스크 또는 프로세스에 추가한다.
그림 10. KPI와 관찰 포인트
예를 들어, 그림 10은 KPI의 "Number of orders received each hour" 와 이것의 관찰 포인트를 보여주고 있다.
이 그림에서 우리는 Input Criteria와 Output Criteria를 관찰 포인트로 선택했다. 이 KPI는 프로세스 모델에서 Order Process Subsystem 태스크와 제휴된다.
KPI 정의와 관찰 포인트들이 구현되는 자세한 방법은 Part 7("Business Process monitoring using CEI")에서 다루도록 하겠다. (참고자료)
프로세스 모델 유효화와 반출
모델러를 BPEL 모드에 두는 것은 BPEL 밸리데이션 체커를 켜는 것이다. 에러 또는 경고가 Error View에 나타난다.
이 모델은 에러와 함께 반출될 수 있지만 결국 픽스되어 앞으로의 반출 시 재작동이 필요 없도록 해야한다.
일단 프로세스 모델이 준비되면 분석가는 WebSphere Studio Application Developer Integration Edition용 BPEL, XSD, WSDL 파일들을 반출하거나 기존 서비스 프로젝트 또는 서비스 프로젝트로 나중에 반입할 폴더로 반출한다.
생성된 파일과, 프로세스 모델 엘리먼트와 생성된 파일의 상응하는 것들과의 관계는 "Elements of Business Process modeling" 에서 다루도록 하겠다.
결론
온 디맨드 비지니스 프로세스들은 탑다운 방식으로 모델링 되고 Service-Oriented Architecture (SOA)을 구현한다.
비지니스 분석가에 의한 탑다운 모델링은 온 디맨드 비지니스 프로세스 수명 주기의 핵심 요소이다. BP 모델은 기술 프레임웍을 정의하여 비지니스 스팩을 IT 개발과 제휴시킨다.
공유된 모델은 비지니스 프로세스의 수명주기 동안 보존되면서 비지니스와 IT를 연결된다. 이 글에서는 WebSphere Business Integration Modeler V5.1를 사용하여 온 디맨드 비지니스 프로세스를 정의하는데 사용할 수 있는 기술과 가이드라인을 설명했다.
감사의 말
이 글을 검토해 주신 Samantha Shurety에게 감사를 전합니다.
참고자료
필자소개 | | | Joshy Joseph는 IBM 온 디맨드 개발 팀의 소프트웨어 엔지니어이다. |
| | | Ken Beck은 IBM Global Services Application Management Services Business Transformation Center of Excellence의 컨설턴트이다. |
| | | German Goldszmidt 박사는 IBM Software Group의 고급 기술 위원으로서 온 디맨드 솔루션의 커스터마이징과 전개를 위한 통합 플랫폼 아키텍쳐를 연구하고 있다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| |
